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

Данные в такой модели представлены в виде коллекции записей, а связи – в виде наборов.

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

Эта модель использует ту же термино­логию, что и иерархическая модель: «узел», «уровень» и «связь». Единственное отличие между иерархической и сетевой моделями данных заключается в том, что в последней каждый элемент дан­ных (узел) может быть связан с любым другим элементом (узлом). Сетевой граф мо­жет быть преобразован в граф-дерево.

Основные операции манипуляции с сетевой БД:

- поиск элемента в БД;

- переход от предка к некоторому потомку;

- переход от потомка к предку;

- вставка новой записи;

- удаление записи и др.

Достоинства:

1. Эффективное использование затрат памяти (ресурсов) при манипулировании данными.

2. Используются для решения многих задач из–за различных типов связей.

Недостатки:

1. Сложность физической реализации.

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

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

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

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

Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- все столбцы в таблице – однородные (имеют одинаковый тип);

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

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

Таким образом, модель данных представляется множеством таблиц–отношений (называемых также R–таблицами). Отсюда название «реляционная», т.е. модель, представленная отношениями.

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

Если записи однозначно определяются значениями нескольких полей, то такая таблица БД имеет составной ключ.

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

Достоинства:

1. Простота моделирования и физической реализации.

2. Высокая эффективность обработки данных.

Недостатки:

Отсутствие стандартных средств идентификации каждой отдельной записи.

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

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

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

Основные операции реляционной алгебры.

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

Пусть заданы два отношения A={a}, B={b}, где a и b – соответственно кортежи отношений A и B, то объединение AB = {c | cAcB}. Здесь c – кортеж нового отношения,  – операция логического сложения «ИЛИ».

Пример1: Объединим, приведенные на Рис. 1, отношения Лекарстенные средства1 (содержащее лекарства, имеющиеся в аптеке) и Лекарстенные средства 2 (содержащее лекарства, поставляемые поставщиком P2). Результатом объединения станет отношение R1 (Рис. 2), содержащее лекарства, которые или имеются в аптеке или поставляются поставщиком P2 (либо и то и другое). Обратите внимание, что дублирующие кортежи исключены из результирующего отношения R1.

Лекарственные средства 1

КодЛС	ЛС	КодПоставщика
1	Парацетамол	Р1
16	Виброцил	Р1
29	Нокспрей	Р1
354	Папазол	Р2
218	Адельфан	Р2
701	Раунатин	Р2
52	Сибазон	Р2
10	Дуавит	Р3
112	Настойка пустырника	Р3

Лекарственные средства 2

КодЛС	ЛС	КодПоставщика
354	Папазол	Р2
218	Фастум гель	Р2
701	Раунатин	Р2
52	Сибазон	Р2
10	Мультитабс	Р2
112	Настойка пустырника	Р2

Рис.1

R1 = Лекарственные средства 1  Лекарственные

средства 2

КодЛС	ЛС	КодПоставщика
1	Парацетамол	Р1
16	Виброцил	Р1
29	Нокспрей	Р1
354	Папазол	Р2
218	Адельфан	Р2
701	Раунатин	Р2
52	Сибазон	Р2
10	Дуавит	Р3
112	Настойка пустырника	Р3
218	Фастум гель	Р2
10	Мультитабс	Р2

Рис. 2. Пример объединения.

Пересечением двух совместимых по типу отношений А и В называется отношение с тем же заголовком, как в исходных отношениях, и с телом, состоящим из множества всех кортежей, принадлежащих одновременно обоим отношением А и В. AB = {c | cA  cB}, Здесь  – операция логического умножени я (логическое «И»).

Пример2: Пересечением отношений Лекарстенные средства1 и Лекарстенные средства 2 (Рис. 1) станет отношение R2 (Рис. 3), содержащее лекарства, имеющиеся в аптеке и поставляемые поставщиком P2.

R2 = Лекарственные средства 1  Лекарственные

средства 2

КодЛС	ЛС	КодПоставщика
354	Папазол	Р2
701	Раунатин	Р2
52	Сибазон	Р2
112	Настойка пустырника	Р2

Рис.3. Пример пересечения.

Вычитанием двух совместимых по типу отношений А и В называется отношение с тем же заголовком, как в исходных отношениях, и с телом, состоящим из множества всех кортежей, принадлежащих отношению А и не принадлежащих отношению В.

A \ B = {c | cA  cB}.

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

Пример 3: При вычитании отношения Лекарстенные средства 2 из отношения Лекарстенные средства 1 (Рис. 1) получится отношение R3 (Рис. 4), содержащее лекарства, имеющиеся в аптеке, кроме тех лекарств, которые поставляет поставщик P2.

При вычитании отношения Лекарстенные средства 1 из отношения Лекарстенные средства 2 получится другое отношение R4 (поскольку операция вычитания не коммутативная). Отношение R4 (Рис. 4) будет содержать лекарства, поставляемые поставщиком P2, кроме тех лекарств, которые имеются в аптеке.

Рис.4. Примеры вычитания.

Алгоритм перехода от модели «сущность-связь» к реляционной модели

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

Рассмотрим на примере, как осуществить переход от модели «сущность-связь» к реляционной модели. Возьмем пример, приведенный в предыдущей теме.

1. В указанной модели мы имеем дело со следующими сущностями: Лекарственные средства, Поставщики, Города, Продажи. Следовательно, и в реляционной модели будут участвовать четыре отношения с такими же именами.

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

Таблица 1 содержит типы данных для каждого атрибута.

3. Первичные ключи отношений, описанных в Таблица 1, помечены знаком √.

ЛекарстСредст

КодЛС

ЛС

Ед Изм

Срок Хран

Усл Хран

Продажи

КодЛС

ДатаПрод

ЦенаПрод

Количество

Города

КодГорода

Город

Рис. 5. Переход от сущностей ER-модели к отношениям реляционной модели

Таблица 1.

Атрибут	Тип данных (СУБД Access)	Первичный ключ	Внешний ключ
Отношение Лекарственные средства
КодЛС	Целое	√
ЛС	Текстовый (30)
ЕдИзм	Текстовый (5)
СрокХран(дней)	Целое
УсловияХран	Текстовый (200)
Отношение Поставщики
КодПост	Целое	√
Поставщик	Текстовый (50)
КодГорода	Целое		√
Адрес	Текстовый (100)
Отношение Продажи
КодЛС	Целое	√	√
ДатаЛС	Дата/время
ЦенаПрод	Денежный
Количество	Одинарное с плавающей точкой
Отношение Города
КодГорода	Целое	√
Город	Текстовый (30)

4. Степень связи между сущностями Поставщики и Города – N:1, поэтому первичный ключ КодГорода (сущности Города) должен войти в сущность Поставщики в качестве внешнего ключа (мы это сделали еще на этапе создания модели «сущность-связь»);

степень связи между сущностями Продажи и Лекарственные средства – N:1, поэтому первичный ключ КодЛС (сущности Лекарственные средства) должен войти в сущность Продажи в качестве внешнего ключа (мы это сделали еще на этапе создания модели «сущность-связь»).

5. Для внешнего ключа КодГорода (отношение Поставщики) устанавливаем свойство допустимость Null-значений: «Да», т.к. в модели «сущность-связь» сущность Поставщики имела необязательный класс принадлежности;

6. В нашем примере две связи имеют степень M:N. Это связи Поставляют и Заказаны. Следовательно, дополнительно появляются еще два отношения Поставки и Заказы соответственно. Таблица 2 содержит описание атрибутов этих отношений.

Таблица 2.

Атрибут	Тип данных (СУБД Access)	Первичный ключ	Внешний ключ
Отношение Поставки
ДатаПоставки	Дата/время	√
КодПост	Целое		√
КодЛС	Целое		√
КоличествоП	Одинарное с плавающей точкой
ЦенаПоставки	Денежный
ДатаИзгот	Дата/время
Отношение Заказы
ДатаЗаказа	Дата/время	√
КодПост	Целое		√
КодЛС	Целое		√
КоличествоЗ	Одинарное с плавающей точкой

Окончательный вариант реляционной модели (схемы БД) приведен на Рис. 6.

Продажи

КодЛС

ДатаПрод

ЦенаПрод

Количество

Поставки

ДатаПост

КодПост

КодЛС

КоличествоП

ЦенаПост

ДатаИзгот

КодЛС= КодЛС

КодПост=КодПост

Поставщики

КодПост

Постащик

КодГорода

Адрес

КодЛС= КодЛС

ЛекарстСредст

КодЛС

ЛС

Ед Изм

Срок Хран

Усл Хран

КодПост=КодПост

Заказы

ДатаЗакаэа

КодПост

КодЛС

КоличествоЗ

Усл Хран

КодЛС= КодЛС

КодГорода=КодГорода

Города

КодГорода

Город

Рис. 6. Реляционная модель данных учета продажи лекарственных средств

в аптеке

Этап даталогического или логического проектирования БД приводит к разработке схемы БД.

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

Основой анализа корректности схемы являются анализ функциональных зависимостей между атрибутами отношений БД.

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

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