7.1.7.Сетевая модель

Основным элементом сетевой модели является набор, который описывает двухуровневую структуру, состоящую из одного владельца и нескольких связанных с ним компонентов (на Рис. 23 пример набора выделен пунктиром). Компоненты могут быть связаны одновременно с владельцами разных типов. На Рис. 23 заказы имеют в качестве владельцев одного продавца и один товар. Эта конструкция позволяет реализовать связи «многие ко многим» без присущей иерархической модели избыточности.

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

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

7.1.8. Рис. 23. Представление данных о заказах в сетевой модели Реляционная модель

Основы реляционной модели данных были сформулированы Э.Ф.Коддом в 1970 г. Основной структурой этой модели является отношение – таблица со следующими свойствами:

1. Каждый столбец содержит информацию одного типа.

2. Ячейки – поля таблицы не содержат агрегатов (структур или массивов) данных.

3. Таблицы не содержат одинаковых строк.

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

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

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

Рис. 24. Представление данных о заказах в реляционной модели данных

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

Реляционный подход часто критикуют за отсутствие иерархии абстракций данных и объектно-ориентированных средств.