Базы данных. Учебное пособие

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

Каждая СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например,

основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархиче- ских СУБД — иерархическая модель данных и т. д.

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

дительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но если данные не имели древовидной структуры, то возникала масса сложно- стей при построении иерархической модели и желании до- биться нужной производительности.

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

Сложность практического использования иерархиче- ских и сетевых СУБД заставляла искать иные способы пред- ставления данных. В конце 60-х годов появились СУБД на

31

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

Реляционная модель решала проблемы ранних СУБД,

на настоящий момент она является основой большинства СУБД.

2.4.1.Иерархическая модель данных

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

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

ризуется фиксированной длиной и конкретным разбиением на поля данных.

Две связанные записи, расположенные на соседних уровнях, называются исходными (для более высокого уровня) и порожденными (для более низкого).

Иерархическая запись есть система иерархически взаи- мосвязанных записей, в которой каждая порожденная запись представлена столько раз, сколько необходимо для полного раскрытия исходной записи. В каждой логической структуре БД имеется единственная запись, которая не зависит ни от какой другой записи. Эта запись называется головной или корневой (рис. 2.8).

32

Исполнитель

Рис. 2.9. Иерархическое представление данных

Наряду с явными достоинствами иерархическая модель имеет следующие недостатки: затруднения при выполнении операций включения и удаления, а также сложность реализа- ции отображения М:М.

2.4.2.Сетевая модель данных

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

34

К основным понятиям сетевой модели базы данных от- носятся: уровень, элемент (узел), связь.

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

Сетевые базы данных подобны иерархическим, за ис- ключением того, что в них имеются указатели в обоих на- правлениях, которые соединяют родственную информацию.

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

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

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

Рассмотрим сетевую модель данных об исполнителях и научно-исследовательских работах (рис. 2.10). Узлами сети являются отдельные экземпляры записи, которые являются единицей доступа. Сеть является более общей структурой в сравнений с иерархией (деревом) , так как отдельный узел

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

35

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

Исполнитель

Рис. 2.10. Сетевое представление данных

36

В примере (рис.2.10) - это количество работ, выпол- няемых исполнителем. Все экземпляры связующей записи, соответствующие одному исполнителю, помещается в цепоч- ку, начинающуюся и возвращающуюся к этому исполнителю.

Аналогичным образом устанавливаются связи для каждой отдельной научной работы

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

Недостатки сетевой модели: сложная структура памяти;

необходимость понижать сложность сетевой модели, а имен- но исключать имеющиеся циклы.

2.5.Реляционная модель данных

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

37

извлекаются значения для данного атрибута. Связи между отношениям и неявно определены на перекрывающихся до- менах.

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

žвсе строки таблицы должны быть уникальны;

žвсе строки таблицы должны иметь одну и ту же струк- туру, т. е. одно и то же количество атрибутов с соответ- ственно совпадающими именами;

žимена столбцов таблицы должны быть различны, а зна- чения столбцов должны быть однотипными;

žзначения атрибутов должны быть атомарными, т.е. от-

ношения не могут иметь в качестве компонент другие отношения;

žпорядок следования строк в таблице несущественен, так как влияет лишь на скорость доступа к строке.

Каждое отношение (таблица) в ЭВМ представляется в виде файла. Между ними существуют следующие соответст- вия:

Реляционные СУБД в наибольшей степени соответст-

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

∙Среда пользователя, дающая возможность непосред- ственного управления данными с клавиатуры.

∙Алгоритмический язык для программирования при- кладных систем обработки данных, реализованный как ин- терпретатор. Последнее позволяет быстро создавать и отла- живать программы.

38

∙Компилятор для придания завершенной программе вида готового коммерческого продукта в форме независимого ЕХЕ-файла.

∙Программы - утилиты быстрого программирования, рутинных операций (генераторы программ отчетов, форматов экранов, меню и других приложений).

∙Встроенная программа интерактивной помощи, а ино- гда и наличие интерактивной обучающей программы.

Количество

Работы

Исполнитель

Рис.2.11. Реляционное представление данных

Анализируя реляционное представление ранее рассмот- ренной БД, содержащей информацию о научно- исследовательских работах и об исполнителях (рис. 2.11), и сравнивая его с иерархическим (рис. 2.9) и сетевым ( рис. 2.10) представлениями этих же данных, наглядно убеждаемся

в преимуществе представления данных в виде реляционной модели.

Эта модель представляет собой обычную двумерную таблицу, с которой пользователю удобно и привычно рабо-

39

тать. Пользователю не нужно помнить пути доступа к данным (что обязательно для иерархической и сетевой моделей).

И, наконец, языки общения с иерархической и сетевой базами данных довольно сложны, в то время как реляционные

языки легко изучаются и доступны в применении обычным рядовым пользователям.

2.5.1.Преимущества реляционной БД

1.Простота. Использование двумерных таблиц для представления большинства структур данных является безус- ловно самым простым способом работы с Б.Д. Операции про- екции и соединения позволяют легко "разрезать" и "склеи- вать" отношения; таким образом, прикладные программисты

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

вбазах данных, могут быть опущены (см. рис. 2.10.).

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

3.Контроль секретности, санкционированности дос- тупа упрощается, так как для каждого отношения задается правомерность, возможность доступа.

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

5.Снижение требований не только к программиро- ванию обработки данного файла, но и к аппаратуре, разраба- тываемой с ориентацией на ускоренный поиск (например, на- личие ассоциативного процессора не обязательно) за счет

исключения сложных указателей связи в файле

6.Простота расширения БД и модификации данных.

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

40