Введение в реляционные базы данных

mySQL | Amber | Комментировать запись

Системы управления базами данных (СУБД) – это программы, которые позволяют пользователям взаимодействовать с БД. СУБД позволяет управлять доступом к базе данных, записывать данные, отправлять запросы и выполнять любые другие задачи, связанные с управлением БД.

Однако для решения любой из этих задач СУБД должна иметь какую-то базовую модель, которая определяет, как организованы данные. Реляционная модель – это один из подходов к организации данных, который появился в конце 1960-х и нашел настолько широкое применение в программном обеспечении СУБД, что на момент написания этой статьи четыре из пяти самых популярных СУБД – реляционные.

В этой статье мы поговорим об истории реляционной модели, о том, как реляционные БД организуют данные и как они используются сегодня.

История реляционной модели

Базы данных – это логически смоделированные кластеры информации. Любая коллекция данных является базой данных, независимо от того, как и где она хранится. Даже физическая папка, содержащая информацию о заработной плате, является базой данных, как и стопка больничных бланков пациентов. До того, как хранение и управление данными с помощью компьютеров стало обычной практикой, физические базы данных, подобные этим, были очень широко распространены.

Примерно в середине ХХ века развитие информатики привело к увеличению вычислительной мощности, а также к увеличению емкости локальной и внешней памяти машин. И тогда ученые начали осознавать потенциал этих машин и стали использовать их для хранения и управления все большими объемами данных.

Однако тогда не было никаких теорий о том, каким образом компьютеры могут логически организовать данные. Одно дело хранить несортированные данные на машине, но разработать систему, которая бы позволили добавлять, извлекать, сортировать и иным образом управлять данными единообразным и практичным способом гораздо сложнее. Потребность в логической структуре для хранения и организации данных привела к возникновению ряда предложений о том, как использовать компьютеры для управления данными.

Одной из первых моделей БД была иерархическая модель, данные в которой организованы в древовидную структуру, аналогичную современным файловым системам.

Иерархическая модель широко применялась в ранних СУБД, однако оказалась недостаточно гибкой. Отдельные записи в ней могут иметь несколько дочерних записей, однако по иерархии каждая запись может иметь только одного «родителя». Поэтому ранние иерархические базы данных были ограничены только отношениями «один к одному» и «один ко многим». Отсутствие поддержки отношения «многие ко многим» становилось проблемой при работе с точками данных, которые нужно связать с несколькими родителями.

В конце 1960-х ученый-компьютерщик Эдгар Ф. Кодд, работавший в IBM, разработал реляционную модель управления базами данных. Реляционная модель Кодда позволяет связывать отдельные записи более чем с одной таблицей, тем самым создавая между точками данных отношения «многие ко многим» (в дополнение к отношениям «один ко многим»). Когда дело касалось проектирования структур БД, эта модель обеспечила большую гибкость, чем другие существующие на тот момент модели. Это означало, что реляционные системы управления базами данных (РСУБД) могли удовлетворить гораздо более широкий спектр потребностей.

Кодд предложил язык для управления реляционными данными по имени Alpha, который повлиял на развитие более поздних языков БД. Двое коллег Кодда из IBM, Дональд Чемберлин и Рэймонд Бойс, создали свой язык, вдохновленный Alpha. Они назвали его SEQUEL (Structured English Query Language), но такая торговая марка уже существовала, и тогда они сократили название языка до SQL (Structured Query Language).

Из-за аппаратных ограничений ранние реляционные базы данных были очень медленными. Чтобы технология получила широкое распространение, потребовалось некоторое время. Но к середине 1980-х годов реляционная модель Кодда была реализована в ряде коммерческих продуктов для управления базами данных как от IBM, так и от ее конкурентов. Эти вендоры последовали примеру IBM, разработав и внедрив свои собственные диалекты SQL. К 1987 году и Американский национальный институт стандартов, и Международная организация по стандартизации ратифицировали и опубликовали стандарты для SQL, укрепив его статус как принятого языка для управления СУБД.

Благодаря такому широкому использованию реляционной модели во многих отраслях она стала стандартной моделью для управления данными. Даже с появлением баз данных NoSQL реляционные БД остаются доминирующими инструментами для хранения и организации данных.

Как реляционные БД организуют данные

Теперь у вас есть общее представление об истории развития реляционной модели. Давайте же подробнее рассмотрим, как модель организует данные.

Основными элементами реляционной модели являются отношения (relations), которые пользователи и современные РСУБД распознают как таблицы. Отношение – это набор кортежей или строк в таблице, где каждый кортеж имеет набор атрибутов или столбцов.

Столбец – это наименьшая организационная структура реляционной базы данных. Он представляет различные аспекты, определяющие записи в таблице. Отсюда их более формальное название – атрибуты. Вы можете рассматривать каждый кортеж как уникальный экземпляр любого типа ассоциаций, содержащихся в таблице. В качестве примера можно привести сотрудников компании, продажи в онлайн-бизнесе или результаты лабораторных тестов. Допустим, в таблице, содержащей записи о школьных учителях, кортежи могут иметь такие атрибуты, как name, subjects, start_date и т.п.

При создании столбцов нужно указать тип данных, который определяет, какие записи разрешено хранить в этом столбце. РСУБД часто поддерживают уникальные типы данных, которые не могут быть напрямую взаимозаменяемы с аналогичными типами данных в других системах. Но есть и общие типы данных, к которым относятся даты, строки, целые числа и логические значения.

В реляционной модели каждая таблица содержит по крайней мере один столбец, который можно использовать для однозначной идентификации каждой строки, он называется первичным ключом. Такой ключ важен, потому что позволяет пользователям не думать о том, где их данные хранятся физически; вместо этого СУБД будет отслеживать каждую запись и возвращать ее на разовой основе. В свою очередь, это значит, что записи не имеют определенного логического порядка, и пользователи имеют возможность возвращать свои данные в любом порядке или через любые доступные фильтры.

Если у вас есть две таблицы, которые вы хотите связать друг с другом, вы можете сделать это с помощью внешнего ключа. Внешний ключ – это, по сути, копия первичного ключа одной таблицы (родительской), вставленная в столбец другой таблицы (дочерней).

Если вы попытаетесь добавить запись в дочернюю таблицу, а значение, введенное в столбец внешнего ключа, не существует в первичном ключе родительской таблицы, оператор вставки будет недействительным. Это помогает поддерживать целостность на уровне отношений, поскольку строки в обеих таблицах всегда будут связаны правильно.

Структурные элементы реляционной модели помогают хранить данные в организованном порядке, но хранение данных как таковое полезно только в том случае, если вы можете их извлечь. Чтобы получить информацию из СУБД, вы можете отправить запрос. Как упоминалось ранее, для управления данными и запросов к ним большинство реляционных БД используют SQL. SQL позволяет фильтровать и управлять результатами запроса с помощью различных операторов, предикатов и выражений, давая нам точный контроль над тем, какие данные будут отображаться в наборе результатов.

Преимущества и недостатки реляционных баз данных

Ознакомившись с организационной структурой реляционных баз данных, давайте теперь рассмотрим некоторые из их преимуществ и недостатков.

Современный SQL и базы данных, реализующие его, несколько отличаются от реляционной модели Кодда. Например, модель Кодда диктует, что каждая строка в таблице должна быть уникальной, в то время как из соображений практичности большинство современных РБД допускают дублирование строк. Некоторые пользователи не считают базу данных SQL «настоящей» реляционной базой, если она не соответствует каждой из спецификаций реляционной модели, описанной Коддом. Однако на практике любая СУБД, использующая SQL и хотя бы в некоторой степени придерживающаяся реляционной модели, скорее всего, будет относиться к РСУБД.

Популярность реляционных баз данных быстро росла, а вместе с этим росла и ценность данных. В связи с этим начали проявляться некоторые недостатки реляционной модели. Во-первых, реляционную базу данных сложно масштабировать по горизонтали. Горизонтальное масштабирование – это практика добавления новых машин к существующему стеку, чтобы распределить нагрузку и обеспечить более быструю обработку трафик.

Примечание: Горизонтальное масштабирование часто противопоставляется вертикальному, которое подразумевает обновление оборудования существующего сервера (обычно путем добавления дополнительной оперативной памяти или процессора).

Причина, по которой реляционную базу данных сложно масштабировать по горизонтали, связана с тем фактом, что реляционная модель предназначена для обеспечения согласованности. Следовательно, клиенты, запрашивающие одну и ту же базу данных, всегда будут получать одни и те же данные. Но если реляционную базу данных масштабировать по горизонтали и разместить на нескольких машинах, ей становится сложно обеспечить согласованность, поскольку клиенты могут записывать данные на одну ноду, но не на другие. Вероятно, между внесением записи и ее отражением на других нодах пройдет некоторое время, а подобная задержка приведет к несогласованности данных.

Еще одно ограничение, представленное РСУБД, заключается в том, что реляционная модель была разработана для управления структурированными данными (то есть данными, которые соответствуют предопределенному типу или, по крайней мере, организованы некоторым заранее определенным образом, благодаря чему их легко сортировать и искать). Однако с распространением персональных компьютеров и появлением Интернета в начале 1990-х годов широкое распространение получили неструктурированные данные (сообщения электронной почты, фотографии, видео и т.п.).

Конечно, ничто из вышеописанного не означает, что реляционные базы данных бесполезны. Напротив, даже по прошествии более 50 лет реляционная модель по-прежнему остается доминирующей структурой для управления данными. Ее распространенность и долговечность означают, что реляционные базы данных – зрелая технология, что само по себе является одним из их основных преимуществ. Существует множество приложений, предназначенных для работы с реляционной моделью, а также множество профессионалов и экспертов в области реляционных баз данных. Для тех же, кто хочет начать работу с РДБ, доступен широкий спектр самых разных обучающих и справочных ресурсов.

Еще одно преимущество реляционных баз данных состоит в том, что почти каждая СУБД поддерживает транзакции. Транзакция состоит из одного или нескольких отдельных SQL-операторов, выполняемых последовательно как единая задача. Транзакции представляют собой подход «все или ничего»: каждый SQL-оператор в транзакции должен быть действительным; в противном случае вся транзакция не будет выполнена. Это обеспечивает целостность данных при внесении изменений в несколько строк или таблиц.

В конце концов, реляционные базы данных чрезвычайно гибки. Они использовались для создания множества приложений и по сей день эффективно справляются даже с очень большими объемами данных. SQL также является чрезвычайно мощным инструментом, он позволяет добавлять и изменять данные на ходу, а также менять структуру схем и таблиц БД, не влияя на существующие данные.

Заключение

Благодаря своей гибкости и дизайну, обеспечивающему целостность данных, даже спустя более 50 лет после выхода реляционные БД остаются основным способом управления и хранения данных. Сегодня существуют более современные базы данных NoSQL, но несмотря на это умение работать с реляционной моделью является ключевым моментом для любого, кто хочет создавать приложения.

Читайте также: Краткий обзор реляционных систем управления базами данных