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

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

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

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

Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.

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

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

Экземпляр записи – запись с конкретными значениями полей.

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

Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.

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

Введем понятие «группа», обобщающее понятия «файл» и «запись».

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

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

Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом.

База данных – поименованная совокупность экземпляров групп и групповых отношений.

 

Для представления группового отношения используется две формы:

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

По типу графов различают:

· иерархическую модель ( граф без циклов – дерево );

· сетевую модель (ориентированный граф общего вида).

 

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

 

Модель данных СУБД описывается следующим образом:

· определены возможные типы и характеристики логических структур данных (полей, записей, файлов);

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

· определен способ представления связей (отношений) между файлами и записями) с помощью дополнительных полей;

· определены возможные действия над структурами и правила их выполнения, включающие:

- основные элементарные операции над данными;

- обобщенные операции (процедуры);

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

- средства контроля сколь угодно сложных условий корректности выполнения определенных действий (правила);

- специальный класс процедур (триггеры).

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

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

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

 

Построение модели данных базы данных (отображение концептуальной модели в модель данных СУБД)

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

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

 

6.2 Типовые модели данных СУБД и представление концептуальной модели

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

Это одна из наиболее ранних моделей данных СУБД. Типовая сетевая модель данных характеристику наиных (Data Base Task Group – DBTG) системного комитета CODASYL (Conference of Data System Languages), основными функциями которого были анализ известных фирменных систем обработки управленческих данных с единых позиций и в единой терминологии, обобщение опыта организации таких систем и разработка рекомендаций по созданию соответствующих систем. Результаты работы комитета CODASYL изложены в [12]. Структура данных сетевой модели определяется в терминах раздела 36.1 (элемент, агрегат, запись, группа, групповое отношение, файл, база данных).

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

Рассмотрим для примера представление группового отношения M: N. В модель вводится дополнительная группа (дополнительный вид записей). Элементы этой записи представляют собой указатели на две исходные группы и указатели на экземпляры рассматриваемой дополнительной записи, связывающие их в список (цепь), соответствующий M и (или) N членам группового отношения (рис. 6.1.).

 

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

 

Представление связей 1:1, 1: M, N: 1 является частным случаем связи типа M: N и осуществляется аналогично рассмотренному выше.

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

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

 

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

 

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

 

Рассмотрим пример записи части ER-диаграммы ПРИМЕР(СТУДЕНТ и ФАКУЛЬТЕТ) из предыдущей лекции в терминах сетевой СУБД. Для примера рассмотрим несколько экземпляров сущности СТУДЕНТ и сущности ФАКУЛЬТЕТ (рис. 6.2.).

 

Рис. 6.2. Примеры экземплярв сущностей

 

.

 

Пусть студенты Иванов, Петров, Мишин учатся на факультете ВМК, Сидоров и Кашин на механико-математическом факультете. Тогда сетевая модель соответствующего фрагмента ER-диаграммы будет выглядеть следующим образом (рис. 6.3).

 

Рис. 6.3. Пример сетевой модели концептуального представления.

Заметим, что в дополнительном файле один из указателей не потребовался, так как рассматриваемая связь имеет тип 1: N, а не M:N. Значок Χ обозначает отсутствие дальнейшей связи.

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

СУБД, поддерживающие сетевую модель, широко использовались на вычислительных системах серии IBM 360/370 (ЕС ЭВМ). В качестве примеров таких систем можно указать IDMS, UNIBAD (БАНК), и их аналоги СЕДАН, СЕТОР. На персональных компьютерах сетевые СУБД не получили широкого распространения. Примером сетевой СУБД для персонального компьютера является db_VISTA III. Отметим, что система db_VISTA реализована на языке С и поэтому является переносимой. Система может эксплуатироваться на ПЭВМ типа IBM PC, SUN, Macintosh.

 

 

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

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

1. Групповые отношения являются отношениями соподчиненности. Группа (запись) – владелец отношения имеет подчиненные группы – члены отношений. Исходная группа называется предком, подчиненная – потомком.

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

- имеется единственная особая вершина (соответствующая группе), называемая корнем, в которую не заходит ни одно ребро (группа не имеет предков);

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

- отсутствуют циклы.

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

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

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

СУБД, поддерживающие иерархическую модель, достаточно широко использовались на вычислительных системах IBM 360/370 (ЕС ЭВМ). В качестве примеров таких систем можно указать IMS, OKA и широко тиражируемую в СССР отечественную разработку ИНЕС. Примером иерархической СУБД для персональных ЭВМ является отечественная система НИКА (адаптация системы ИНЕС к IBM PC).

 

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

Учитывая отмеченные в предыдущих разделах недостатки сетевых и иерархических моделей, можно сформулировать желательные требования к модели данных:

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

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

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

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

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

Рассмотрим пример записи ER-диаграммы (см. рис. 5.2.) в терминах реляционных баз данных.

Сначала представим таблицы, соответствующие сущностям.

Таблица СТУДЕНТ

Код

Фамилия

Дата рождения

Место рождения

ПРИМЕР

 

Таблица ФАКУЛЬТЕТ

Номер

Название

Таблица СПЕЦИАЛЬНОСТЬ

Номер

Название

 

Представим таблицы, описывающие связи.

 

Таблица «Студент учится на факультете»

Код студента

Номер факультета

Таблица «Студент учится по специальности»

Код студента

Номер специальности

Таблица «На факультете имеются специальности»

Номер факультета

Номер специальности

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

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

Код студента

Фамилия

Дата рождения

Место рождения

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