2.2.1. Системы управления реляционными базами данных (СУРБД)

Вообще, лишь немногие реальные базы данных могут быть описаны при помощи единственной таблицы. Большинство приложений используют множество таблиц, которые содержат столбцы (поля) с одинаковым именем. Эти общие данные позволяют объединяя две (или несколько) таблицы, строить осмысленные ассоциации. Лучше всего это иллюстрируется примером (далее рассмотрим пример, который лучше всего раскрывает все достоинства и недостатки рассматриваемых технологий). Рассмотрим два отношения "Служащий" и "Отдел", показанные на рис.2.1.

Рис 2.1. Объединение двух отношений через общее поле

В этом примере поля Номер Служащего и Номер Отдела выделены; это указывает на то, что эти поля - первичные ключи. Это означает, что элементы данных в этих полях единственным образом определяют запись (т.е. никакие две записи не имеют одинакового элемента данных в ключевом поле). Более того, поле N отдела обнаруживается в обеих таблицах. Это позволяет объединить две таблицы таким образом, чтобы, например, определять Название отдела для любого заданного Служащего.

Простой реальный пример может потребовать более сложной структуры. Пусть Служащий является членом более чем одного Отдела. Правила соединения в реляционных базах данных не разрешают связей "многие-ко-многим". Чтобы представить отношение с такими связями (например, каждый Отдел имеет многочисленных Служащих и каждый Служащий может быть членом Многочисленных Отделов), нам надо создать отдельное отношение, которое является гибридом двух столбцов (рис. 2.2).

Рис. 2.2. Объединение двух отношений через третье отношение

"Естественный подход" с использованием таблиц может оказаться еще более "притянутым за уши", когда данные - разреженные. Разреженные данные означают, что не каждое поле в каждой записи содержит данные. В некоторых приложениях данные очень разреженные - только несколько из большого числа столбцов, определенных для данного отношения, могут содержать данные в каком-либо заданном ряду. Если в реальном приложении типично, что данные разреженные, то обычно пользователь не рассматривает их как табличные. Например, представим отношение, описывающее посещение пациентом врача. Оно может иметь поля, которые содержат результаты обследования: радиограмма, ультразвук, температура, вес и т.д. Большинство из этих полей может быть пусто для какого-либо пациента. Представить их в качестве полей таблицы в лучшем случае противоестественно. Более естественно представить эти данные в виде списка элементов, чем в качестве полей таблицы. Воплотить в жизнь эту точку зрения пользователя в реляционной базе данных нелегко. Эти различные элементы нельзя занести в одну таблицу, так как они нарушают однородность столбца - данные, хранящиеся в полях, не все одного типа, как это требуется в реляционных таблицах.

В настоящее время модель реляционной базы данных - лидирующая в компьютерной индустрии и занимает эту позицию уже приблизительно 20 лет. Но по иронии судьбы эта позиция силы может превратиться в позицию слабости. Несмотря на то, что РБД стали доминирующими в индустрии баз данных за последние 20 лет, многие эксперты почувствовали, что РБД приближаются к концу своей "карьеры" доминирующего игрока и будут вытесняться более современными и гибкими моделями, в первую очередь моделью объектно-ориентированной базы данных. Существуют некоторые сомнения относительно того, смогут ли такие гиганты как Oracle, Informix, Sybase, Gupta и т.д. произвести изменения своевременно, имея так много клиентов. Требование поддерживать обратную совместимость может резко препятствовать их возможности идти в ногу с прогрессом технологии БД. С другой стороны, прекрасное финансирование этим огромным количеством клиентов упрощает разработки. Все продавцы больших реляционных баз данных добавляют объектно-ориентированные средства, помещая их поверх нижележащей реляционной структуры. Эти средства полезны при разработке базы данных, но по-видимому бесполезны во время выполнения, так как лежащая в основе реляционная модель сохраняется.