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

недостатком. Сетевой подход к организации данных является расширением иерархического. Цель разработчиков сетевой модели – создание модели, позволяющей описывать связи M:N, чтобы одна запись могла участвовать в нескольких отношениях предок/потомок.

Существенную роль в эволюции и стандартизации БД сыграла группа CODASYL (Conference on Data Systems Languages – конференция по языкам систем обработки данных, англ.), которая была создана в 1959 г. для разработки стандартов по языкам программирования. В 1965 г. в рамках этой группы была сформирована рабочая группа по базам данных (DBTG, Data Base Task Group, англ.). Через два года ею была опубликована концепция сетевой БД, широко известной также под названием «модель данных CODASYL» [3].

Идеологом сетевой модели был Чарлз Бахман (Charles Bachman) – один из выдающихся исследователей и практиков в области компьютерных наук, удостоенный в 1973 г. премии Тьюринга за вклад в развитие баз данных. Бахман предложил разделить логическое и физическое описание данных. Архитектура баз данных CODASYL стала прообразом современных архитектур и включала в себя:

−схему, отражающую полную логическую структуру данных;

−подсхема – различные «взгляды» на БД с точки зрения разных прикладных программ;

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

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

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

41

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

Структурными элементами сетевой модели данных CODASYL являются элемент данных, агрегат данных, запись, набор записей (Рис. 10).

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

mЭлемент данных

СОТРУДНИК

Рис. 10. Пример типа записи, записи, агрегата данных в наборе ОТДЕЛ-СОТРУДНИК

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

Запись – поименованная совокупность элементов данных и/или агрегатов, которая не входит в состав никакого другого агрегата. Запись мо-

42

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

Связи между записями выполняют так называемые наборы. Набор

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

Структура сетевой базы данных основана на следующих правилах:

1)База данных содержит любое количество типов записей и типов наборов.

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

3)Тип записи может быть владельцем и одновременно членом нескольких типов наборов

Ограничения на типы записей и связей сетевой модели:

1) Все типы связей должны быть функциональными (1:1, 1:M,

M:1).

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

3)Экземпляр записи может быть потомком в одном наборе L1 и предком в другом наборе L2.

4)Экземпляр записи P может быть предком в любом числе наборов, и аналогично, может быть потомком в любом числе наборов.

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

6)Для представления связи M:N вводится дополнительный тип записи и две функциональные связи типа 1:M и M:1. При необходимости запись-связка может содержать дополнительную информацию (Рис. 11).

43

Рис. 11. Представление связи M:N

Достоинства сетевой модели

Главными достоинствами сетевой модели данных являются:

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

−простота реализации часто встречающихся в реальном мире взаимосвязей «многие ко многим».

Недостатки сетевой модели

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

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

3.3 Основные особенности систем, основанных на инвертированных списках

Одной из самых сложных задач в работа с плоскими файлами является поиск и доступ к нужной записи. Наиболее эффективным решением этой задачи является индексирование записей по первичному ключу [3]. Допустим, в БД (плоском файле) хранятся записи о заказах (Рис. 12),

44

включающие в себя следующие поля Заказ (idЗаказа, Клиент, Товар и Количество). Очевидно, что запись о заказе можно найти по его id – первичному ключу записи. Сформировав индекс по idЗаказа, можно существенно ускорить поиск заказа. Однако в ряде случаев требуется выполнить более гибкий поиск, например, найти все заказы на яблоки или найти все заказы конкретного клиента. Такой поиск называется поиском по вторичному ключу. Вторичный ключ – это поле, одному значению которого соответствуют несколько полей. В нашем примере роль вторичных файлов могут выполнять поля Товар и Клиент. Поиск по вторичным ключам существенно облегчится, если для каждого такого ключа создать свой индекс. На рис. 3 показаны такие индексы для полей Товар и Клиент. Эти индекс получили название инвертированных списков 1.

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

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

1 Другие названия – инвертированный файл, инвертированная таблица, инвертированный индекс

45

Файл данных (записи по линейному списку)

Рис. 12. Пример инвертированного списка

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

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

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

46

ступа к инвертированным спискам (индексам). Особенности БД, организованных с помощью инвертированных списков [3, 15]:

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

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

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

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

В системах, основанных на инвертированных списках, поддерживаются 2 класса операторов:

− операторы, которые устанавливают адрес записи:

oпрямые операторы поиска (например, нахождение первой записи таблицы по определенному пути доступа);

oоператоры, которые находят запись относительно определенной позиции от предыдущей записи по определённому пути доступа);

−операторы над записями по адресу.

К достоинствам рассмотренного метода построения базы данных следует отнести [2]:

−более быстрый поиск (особенно поиск уникальной записи по нескольким условиям),

−возможность хранения элементов данных со сложной структурой.

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

47

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

1)Какие подходы относятся к дореляционным моделям данных?

2)Укажите сильные и слабые стороны дореляционных моделей.

3)Приведите характеристику иерархической модели данных.

4)Перечислите и дайте определение основных понятий иерархической БД: поле, тип сегмента, сегмент, экземпляр сегмента.

5)Что относится к достоинствам и недостаткам иерархической модели?

6)Приведите характеристику сетевой модели данных.

7)Перечислите и дайте определение основных понятий сетевой модели: элемент данных, агрегат данных, запись, набор записей.

8)Что относится к достоинствам и недостаткам сетевой модели?

9)Приведите характеристику систем, основанных на инвертированных списках.

10)Перечислите особенности БД, организованных с помощью инвертированных списков.

11)Что относится к достоинствам и недостаткам систем, основанных на инвертированных списках?

4 Общие понятия реляционного подхода к организации базы данных

По существу реляционная модель (от английского слова relation – отношение) – это возврат к плоским файлам. Появление этой модели предшествовали работы британского ученого Эдгара Кодда (Edgar Codd). Работая в компании IBM, он в 1970 г. опубликовал статью о реляционной модели данных для больших банков данных (статья «A Relational Model of Data for Large Shared Data Banks»), предназначенных для совместного использования [2]. Кодд является прародителем современной технологии хранилищ данных. В 1981 г. он был удостоен Тьюринговской премии.

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

48

тов) на физическом уровне, что, в свою очередь, усиливает зависимость между приложениями и данными.

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

Реляционный подход является наиболее распространенным в настоящее время, хотя наряду с общепризнанными достоинствами обладает и рядом недостатков. К числу достоинств реляционного подхода можно отнести:

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

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

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

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

49

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

4.1 Базовые понятия реляционных баз данных

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации (Рис. 13).

Рис. 13. Основные компоненты реляционного отношения

50