Материал: Базы данных и их безопасность. Плотников Д.Г
ссылкам между записями, не входящими в одну иерархию, не поддерживается.
Сетевая модель
В сетевой модели данные представлены в виде коллекции записей, а связи – в виде наборов. В отличие от реляционной модели, связи здесь явным образом моделируются наборами, которые реализуются с помощью указателей. Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в виде его ребер.
Практически по всех СУБД, поддерживающих сетевые модели, между парой типов записей может быть объявлено несколько связей, направление и характер связи в сетевых моделях не являются очевидными, как в случае иерархической модели, поэтому имена и направления связей должны указываться как при графическом изображении БД, так и при ее описании.
Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc.,
предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.
Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора
36
типов записи и набора экземпляров каждого типа из заданного набора типов связи.
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:
Каждый экземпляр типа P является предком только в одном экземпляре L;
Каждый экземпляр C является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:
а) Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).
б) Данный тип записи P может быть типом записи предка
влюбом числе типов связи.
в) Данный тип записи P может быть типом записи потомка в любом числе типов связи.
д) Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.
ж) Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.
з) Предок и потомок могут быть одного типа записи.
Простой пример сетевой схемы БД:
37
Работают в отделе
|
|
|
|
|
|
|
|
|
Отдел |
|
Сотрудники |
|
Начальник |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Состоит из сотрудников
Имеет начальника
Манипулирование данными в сетевой модели
Примерный набор операций может быть следующим:
Найти конкретную запись в наборе однотипных записей (инженера Сидорова);
Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 352);
Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
Создать новую запись;
Уничтожить запись;
Модифицировать запись;
Включить в связь;
Исключить из связи;
Переставить в другую связь и т.д.
Ограничения целостности в сетевой модели
В принципе их поддержание не требуется, но иногда требуют целостности по ссылкам (как в иерархической модели).
Реляционная модель
Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и
38
связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. В реляционной модели данных единственное требование состоит в том, что база данных с точки зрения пользователя выглядела как набор таблиц. Однако, такое восприятие относится только к логической структуре базы данных, т.е. ко внешнему и концептуальному уровням архитектуры. Оно не имеет отношения к физической структуре базы данных, которая может быть реализована с помощью разнообразных структур хранения.
Подробно реляционная модель рассматривается далее (риздел 3.1).
39
3. МАТЕМАТИЧЕСКИЕ ОСНОВЫ ПОСТРОЕНИЯ РЕЛЯЦИОННЫХ СУБД. РЕЛЯЦИОННАЯ АЛГЕБРА И БЕЗОПАСНЫЕ ВЫРАЖЕНИЯ. РЕЛЯЦИОННЫЕ ИСЧИСЛЕНИЯ, ПОСТРОЕННЫЕ НА ДОМЕНАХ
ИКОРТЕЖАХ
3.1.Реляционная модель
Остановимся более подробно на реляционной модели данных.
Реляционная модель впервые была предложена Э.Ф.Коддом в 1970 году. Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД. Примерами реляционных СУБД являются СУБД Access и FoxPro фирмы
Microsoft, Paradox и Visul dBase фирмы Borland, а также R:Base фирмы Microrim.
Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица.
Поясним используемую в реляционной модели терминологию, а также основные структурные понятия.
ОТНОШЕНИЕ – это плоская таблица, состоящая из столбцов и строк.
АТРИБУТ – это поименованный столбец отношения
ДОМЕН – это набор допустимых значений для одного или нескольких атрибутов.
КОРТЕЖ – это строка отношения.
Описание структуры отношения вместе со спецификацией доменов и любыми другими ограничениями возможных значений атрибутов иногда называют его
заголовком (содержанием). Кортежи называются
40