Модели данных СУБД

 

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

· языки описания данных;

· языки запросов;

· физическую организацию данных;

· возможности и свойства СУБД.

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

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

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

В этой модели каждая запись БД представляла конкретную деталь. Между записями существовали отношения предок/потомок, связывающие каждую часть с деталями, входящими в неё.

Чтобы получить доступ к данным, содержащимся в БД, программа могла:

· найти конкретную деталь (правую дверь) по её номеру;

· перейти "вниз" к первому потомку (ручка двери);

· перейти "вверх" к предку (корпус);

· перейти "в сторону" к другому потомку (правая дверь).

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены преимущества IMS и реализованной в ней иерархической модели.

· Простота модели. Принцип построения IMS был легок для понимания. Иерархия БД напоминала структуру компании или генеалогическое дерево.

· Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".

· Быстродействие. В СУБД IMS отношения предок/потомок были реализованы в виде физических указателей из одной записи на другую, вследствие чего перемещение по БД происходило быстро. Поскольку структура данных в этой СУБД отличалась простотой, IMS могла размещать записи предков и потомков на диске рядом друг с другом, что позволяло свести к минимуму количество операций записи-чтения. СУБД IMS все ещё является одной из наиболее распространенных СУБД для больших ЭВМ компании IBM.

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

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

Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

Сетевые СУБД обладали рядом преимуществ:

· Гибкость. Множественные отношения предок/потомок позволяли сетевой СУБД хранить данные, структура которых была сложнее простой иерархии.

· Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых СУБД были недостатки. Как и иерархические СУБД, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры БД обычно означало перестройку всей БД.

Как иерархическая, так и сетевая СУБД были инструментами программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее часто заказывает компания Acme Manufacturing?", программисту приходилось писать программу для навигации по БД. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Э.Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру БД. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы. Таблицы представляют собой частный случай более общего математичкского понятия – отношения.

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

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

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

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

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

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