Лекция 3. Общая теория баз данных
С момента появления понятия "база данных" возникла необходимость в теоретической математической поддержке процессов в ней. Постепенно выявились три относительно самостоятельные части теории баз данных: 1) построение баз данных; 2) использование баз данных; 3) функционирование баз данных. Они выстроились в относительно стройную систему позднее в рамках реляционных БД.
В настоящее время при проектировании структур данных применяют три основных подхода.
1. Сбор информации в рамках одной таблицы и поВперед ее декомпозиция.
2. Использование CASE-технологии [2].
3. Структурирование информации в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Первоначально на роль теории баз данных независимо от используемой модели данных претендовала CASE-технология. Позже выяснилось, что CASE-технология охватывает лишь процедуру построения БД, да и то не полностью.
Широкое распространение реляционных БД привело к необходимости добавления в CASE-технологию процедуры нормализации, являющейся частью теории реляционных баз данных, на основе ER-диаг- рамм. Процедура нормализации была формализована и реализована на компьютере (в диалоговом варианте) в ряде СУБД (Access, Oracle). Вместе с тем, построение ER-диаграмм – процедура специфическая.
Возникают сложности и с процедурой нормализации [2,3].
В связи с этим реляционные БД чаще проектируют, применяя понятие "отношение".
В то же время в CASE-технологии заложены возможности автоматизации процедуры проектирования баз данных, что особо важно при создании баз данных большой размерности (20 Гбайт и выше).
Модели представления данных
БД, как элемент системы принятия решений (например, в АСУ) есть отражение предметной области реального мира [9]: ее объекты, отношения между ними и отношения в БД должны соответствовать друг другу. Компьютер (и АСУ в частности) оперирует только формальными понятиями (моделями), соответствующими объектам и связям внешнего мира. В настоящее время имеется свыше тридцати моделей представления данных, которые до последнего времени не были систематизированы.
Их можно разделить на две группы:
1) формальные (математические, скорее теоретические), предполагающие разработку БД обязательно с участием человека;
2) математические представления, рассчитанные на автоматизацию процесса проектирования БД ("компьютерное представление").
Вторая группа рассмотрена в парагр. 3.2, а первую обсудим здесь.
Сразу отметим разницу двух понятий [9|: "модель данных" – средство моделирования; "модель БД" – результат разработки БД. Модель (представление) БД – множество конкретных ограничений над объектами и операциями с ними.
Модель данных (точнее – модель представления данных) есть множество элементов (объектов, типов данных) и связей (отношений) между ними, ограничений (например, целостности, синхронизации многопользовательского доступа, авторизации) операций над типами данных и отношениями.
Множество допустимых типов данных и их отношений образуют структуру данных. В модели данных, следовательно, выделяется три компоненты: структура данных; ограничения, определяющие допустимое состояние БД; множество операций, применяемых для поиска и обновления данных. Эти компоненты отображаются языковыми и программными средствами описания и манипулирования данными.
Описание часто проводят последовательно: структура, ограничения, операции. Начнем с описания структур данных.
Проще всего структуру (отношение) можно задать таблицей с "плоской" (см. табл. 1.11) или сложной (см. табл. 1.12) структурой. При таком задании хорошо видны элементы (столбцы, поля), однако плохо просматриваются отношения, которые могут быть четырех типов: 1:1, 1:М, M:l, M:N.
Более наглядным (особенно для представления типа 1:1) является представление в виде ориентированного графа (рис. 3.1), восходящее к математике, теории автоматического управления и теории информации. Элементами п (п принадлежит N) графа Г(N, U) являются столбцы (поля), а связи между ними определяются дугами и (и принадлежит U). Такому графу соответствует матрица смежности (табл. 3.1) или двудольный граф. Разновидностью графов являются предложенные Д. Мартиным овал-диаграммы (рис. 3.2).
Рис. 3.1. Ориентированный граф:
1–5 – узлы графа
Рис. 3.2. Овал-диаграмма: 1–5 – узлы диаграммы
Таблица 3.1
Матрица смежности
1 |
2 |
3 |
4 |
5 |
|
1 |
0 |
0 |
1 |
1 |
1 |
2 |
0 |
0 |
0 |
0 |
1 |
3 |
0 |
0 |
0 |
0 |
0 |
4 |
0 |
0 |
0 |
0 |
0 |
5 |
0 |
0 |
0 |
0 |
0 |
Теория графов достаточно хорошо развита, однако прямое ее применение для представления данных встречает затруднения, вызванные следующими обстоятельствами:
• связи в моделях представления данных относительно просты (см. рис. 3.1), матрицы смежности получаются разреженными, что снижает ценность их использования;
• в графах отражается чаще всего один тип связи (например, 1:1): выходом здесь может быть использование овал-диаграмм;
• при постановке задачи представления (моделирования) данных, в отличие от теории управления и математики, в которых широко используются начальные предположения, велик объем неформальной составляющей.
Для преодоления третьего затруднения сформировались модели представления данных "сущность – связь" (Entity – Relationship), называемые также "ER-моделями (диаграммами)" или "моделями Чена". Базовыми структурами в ER-модели являются "типы сущностей" и "типы связей".
Отличие типа связи от типа сущности – в установлении зависимости существования реализации одного типа от существования реализации другого. (Например, ЛИЧНОСТЬ – тип сущности, тип СОСТОИТ В БРАКЕ – нет, поскольку реализация последнего типа не существует, если не существует двух личностей. Тип связи может рассматриваться поэтому как агрегат двух или более типов сущностей.)
Выделяют три типа связи: связь "один к одному" (1:1), связь "один ко многим" (1:М), связь "многие ко многим" (M:N).
Примеры этих связей могут быть следующие:
Следует отметить особенности отображения ER-модели. Выделяют следующие типы связей:
• рекурсивное (по "кольцу") множество связей, в котором участвуют несколько сущностей;
• два множества связей между одними и теми же двумя множествами сущностей;
• множество n-арных связей, например тернарных (четыре связи, "исходящие от одной сущности").
Выделение этих связей является крайне важным, так как связи 1:М и M:N имеют внутреннюю неопределенность, что сказывается при операциях модификации. Для преодоления неопределенности на этапе реализации логической модели требуется вводить избыточную информацию.
Отметим, что сущность примерно соответствует таблице, а атрибут – полю реляционной базы данных.
Фрагмент концептуальной модели предметной области "Учебный процесс" представлен на рис. 3.3, а пример представления атрибутов для конкретного объекта показан на рис. 3.4. Выделяют многозначный атрибут, атрибут множества связей.
В общем случае атрибуты отображаются либо на самой ER-диаг- рамме (при небольшом количестве объектов), либо в виде отдельных приложений по каждому объекту.
Рис. 3.3. ER-диаграмма предметной области "Учебный процесс"
При построении ER-моделей в ряде случаев целесообразно выделять ряд ограничений:
• ограничение целостности применительно к атрибутам: (например: N – студенты, целое, положительное, число студентов – диапазон от 5 до 35);
• ограничение Е по существованию сущностей (рис. 3.3);
• ID-зависимость (рис. 3.3): сущность не может быть идентифицирована в ряде случаев по значениям собственных атрибутов.
Здесь прямоугольниками показаны типы сущностей и атрибуты, ромбами – типы связей.
Покажем свойства этих моделей на примере БД "Учебный процесс" в институте (рис. 3.4). Укрупненно (и в несколько другом начертании, чем на рис. 3.3) он может быть представлен в виде отношений трех групп атрибутов (рис. 3.4, а) со связями Μ:Ν и 1:М. Поскольку группы 1 и 3 – множества, схему можно представить в виде рис. 3.4, б. Известно, что ни одна модель данных не может реализовать отношения Μ:Ν. В связи с этим схема связей после преобразования окончательно выглядит, как показано на рис. 3.4, в.
Рис. 3.4. Модель БД "Учебный процесс": а – исходная структура; б – промежуточная структура; в – результат
Заметим, что перечисленные методы обладают следующими недостатками:
• слабо ориентированы на использование компьютеров в проектировании БД;
• оперируют со статическими (неизменными) данными, тогда как в реальных системах управления используются динамические данные (потоки данных);
• отражают потоки данных не системно.
Названные недостатки устранены в CASE-технологии [25].