Лекции ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / Проектирование БД_уч пособие v02

−препроцессор языка DML – преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функций базового языка (взаимодействуя с процессором запросов); DML (Data Manipulation Language) – язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в базе данными (вставки, модификации, извлечения и удаления данных); DML может быть двух типов: процедурный – указывает, как можно получить результат оператора DML (обычно оперирует данными по одной записи), непроцедурный – описывает, какой результат будет получен (обычно оперирует наборами записей – SQL);

−компилятор языка DDL – преобразует DDL-команды в набор таблиц, содержащих метаданные (сохраняются в системном каталоге и частично в заголовках файлов с данными); DDL (Data Definition Language) - описательный язык, который позволяет описывать сущности (объекты), необходимые для работы некоторого приложения, а также связи, имеющиеся между различными сущностями (теоретически, в архитектуре ANSISPARC, можно выделить языки DDL для каждой схемы, но на практике есть один, позволяющий задавать спецификации как минимум для внешней и концептуальной схем);

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

2.4 Преимущества и недостатки СУБД

К преимуществам СУБД (по отношению к файловым системам) принято относить следующее [16]:

−контроль за избыточностью данных (вводится контролируемая избыточность – хранятся только те данные, что необходимы для описания модели, все данные хранятся централизованно);

−непротиворечивость данных (легче отслеживать возникновение противоречивых состояний в БД, чем в файлах, разбросанных по отделам, кроме того, меньше избыточность данных);

−больше полезной информации при том же объеме хранимых данных (т.к. в БД хранится вся информация, а не только данные одного отдела (как в файловых системах), то возможно использование совместных данных для анализа некоторых ситуаций и подготовке отчетов);

31

−совместное использование данных (фактически учет и ведение данных на новом уровне – не для себя одного (отдела), а в многопользовательском режиме – вся организация (больший объем данных для сотрудника));

−поддержка целостности данных (корректность и непротиворечивость хранимых данных – в одном месте легче настраивать, проверять и изменять);

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

−применение стандартов (установка требуемых форматов данных для обмена, отчетов, обновления и правил доступа);

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

−возможность нахождения компромисса для противоречивых требований (потребности одних пользователей (отделов) могут противоречить потребностям другим пользователей (отделов), имея общий взгляд на всю структуру БД, администратор БД может контролировать такие противоречия и оперативно их устранять (обычно производительность отдается важным приложениям за счет менее важных));

−повышение доступности данных и их готовности к работе (т.е. устраняется время на распространение общих данных по отделам, данные становятся доступными сразу по их внесении в БД);

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

−упрощение сопровождения системы за счет независимости от данных (т.к. в СУБД описания данных отделены от приложений, поэтому приложения защищены от изменений в описании данных, что упрощает обслуживание и сопровождение приложений);

32

−улучшенное управление параллельностью (в файловых системах при одновременной записи в файл возможна потеря данных или их целостности, СУБД позволяет вести параллельный доступ к БД);

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

К недостаткам СУБД относят следующее:

−сложность и размер (при проектировании БД, разработчики должны хорошо представлять функциональные возможности СУБД, непонимание может приводить к неудачным результатам проектирования, более сложные СУБД занимают значительный объем дискового пространства (при равных качествах кода);

−стоимость СУБД и дополнительные затраты на аппаратное обеспечение (чем больше возможностей у СУБД (и число пользователей БД при равной производительности), тем выше ее стоимость, стоимость ее сопровождения и аппаратных затрат);

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

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

исоответственно «притормаживать»);

−серьезные последствия при выходе системы из строя (централизация повышает уязвимость системы, выход из строя компонента СУБД

– прекращение работы организации).

Вопросы для самопроверки

1)Дайте определение термина «базы данных».

2)Дайте определение термина «СУБД».

3)Перечислите основные функции СУБД и кратко их поясните.

4)Что такое транзакция?

33

5)Для чего используется журнализация?

6)Перечислите, какие компоненты входят в состав типовой СУБД.

7)Кратко охарактеризуйте компоненты СУБД.

8)Перечислите преимущества СУБД по отношению к файловым системам.

9)Перечислите недостатки СУБД.

3 Ранние подходы к организации БД

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

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

К достоинствам ранних СУБД относят [15]:

−развитые средства управления данными во внешней памяти на низком уровне;

−возможность построения вручную эффективных прикладных

систем;

−возможность экономии памяти за счет разделения подобъектов (в сетевых системах).

К недостаткам относят:

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

−прикладные системы напрямую зависят от этой физической ор-

ганизации;

34

− логика работы ранних СУБД перегружена деталями организации доступа к БД.

К дореляционным система принято относить:

1)иерархические системы;

2)сетевые системы;

3)системы, основанные на инвертированных списках.

3.1 Иерархические системы

Как правило, любая предметная область содержит не один, а несколько объектов, о которых необходимо хранить информацию. Очевидно, что для каждого из таких объектов необходимо создавать собственный файл. Является ли совокупность этих файлов базой данных? Вопрос неоднозначный. Аналогом БД принято считать классическую бумажную библиотечную картотеку, состоящую из двух файлов. Как известно, в библиотеке имеются две картотеки – в первой, называемой тематическим каталогом, книги упорядочены по отраслям знаний, а во второй – алфавитном каталоге – по авторам. Итак, мы имеет хорошо структурированную и упорядоченную информацию. Но работать одновременно с двумя частями библиотечного каталога не всегда удобно: нам приходится переходить от каталога к каталогу (от файла к файлу), держа в уме фамилию автора, к тому же мы не всегда можем быстро найти нужную карточку (запись). Очевидно, что современные пользователи скажут: «Все просто, необходимо установить связи между отдельными карточками». Действительно, связь – это ключевое слово, отличающее БД от простого файла или набора файлов. Но как представить эту связь в БД?

Впервые эта задача была решена в конце 1960-х гг. с появлением иерархических СУБД, позволявших устанавливать между элементами информации отношение «один-к-многим» [3].

Иерархическая модель данных – представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

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

35

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

Самой известной иерархической СУБД является система Information Management System (IMS) компании IBM, появившаяся на рынке в 1968 г. и используемая в свое время для поддержки лунного проекта «Аполлон». Иерархическая модель данных используется и для организации реестра операционных систем семейства Microsoft Windows [18].

Иерархическая модель данных представляет собой упорядоченный граф (дерево) (Рис. 3). В этой модели данные представляются как дерево связанных записей. Имеется один корневой (родительский) тип записи – корень дерева. С ним в подчиненной связи типа 1: N находятся дочерние записи. Связи между записями выражаются в виде отношений предок/потомок, а у каждой записи есть ровно одна родительская запись. Это помогает поддерживать ссылочную целостность: когда запись удаляется из дерева, все ее потомки должны быть также удалены [2].

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

Рис. 3. Иерархическая структура данных

Минимальной структурной единицей в иерархической модели является поле, считающееся неделимым элементов данных (Рис. 4). Поимено-

36

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

Рис. 5. Экземпляры сегментов иерархической БД

Схема иерархической БД представляет собой дерево, вершинами которого являются типы сегментов (Рис. 6). Между типами сегментов установлены отношения «исходный – порожденный». Тип сегмента, у которого нет предка, называется корневым. На уровне экземпляров каждое такое отношение реализуется в виде связей между одним экземпляром сегмента-родителя и несколькими экземплярами сегмента-потомка. Таким образом, иерархическая БД – это совокупность деревьев, корнями которых являются экземпляры корневого типа сегмента. Каждое такое дерево назы-

37

вается набором и образует физическую запись иерархической БД. Так, например, набор, принадлежащий отделу D1, представляет собой следующую последовательность экземпляров сегментов: {D1, E1, E2, E3, P1, T1, T2, T3, P2, T4, T5}, где D1 – экземпляр сегмента ОТДЕЛ, E1-E3 – экземпляры сегмента РАБОТНИК, P1, P2 – экземпляры сегмента ПРОЕКТ, T1T5 - экземпляры сегмента ЗАДАЧА.

Рис. 6. Дерево типов (слева) и экземпляров (справа) сегментов

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

Рис. 7. Пример иерархической БД больницы

38

Рис. 8. Экземпляры логических записей иерархической БД больницы

Достоинства иерархической модели [2, 15]:

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

2)Использование отношений предок/потомок. Иерархическая модель позволяет легко представлять отношения предок/потомок, например, «А является частью В» или «А принадлежит В».

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

Недостатки иерархической модели:

1) Операции манипулирования данными в иерархических системах ориентированы, прежде всего, на поиск информации сверху-вниз, т.е. по данному экземпляру сегмента-отца можно найти все экземпляры сег- ментов-сыновей. Обратный поиск затруднен, а часто и невозможен. Например, попытка реализовать запрос типа «В скольких сборниках статей опубликовал свои статьи автор Петров?» может оказаться весьма трудной задачей.

39

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

3)Отношение «многие-ко-многим» непосредственно не поддерживается, что и является основным недостатком иерархических моделей. Для представления связи M:N необходимо дублирование деревьев (Рис. 9), что приводит к хранению избыточных данных.

Рис. 9. Дублирование деревьев для представления связи «многие-ко-многим»

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

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

3.2 Сетевые системы

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

40