2.2.1 Идентификация сущностей и связей. Er-диаграмма логического уровня
Erwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные. Объекты модели, представляемые на нем, называются сущностями и атрибутами.
Для отображения информационной модели рассматриваемого процесса на логической модели используются следующие сущности:
«Блюда» – для хранения информации о блюдах;
«Вид блюда» – для хранения информации о видах блюд, которые есть в кафе;
«Заказы» – содержит информацию о сделанных заказах;
«Клиенты» – информация о клиентах, посещающих кафе;
«Должности» хранит данные о должностях, которые существуют в кафе;
«Персонал» – информация о работниках кафе.
Для однозначного определения записей в каждом из отношений выделен первичный ключ (простой или составной).
Внешние ключи для отношений информационной системы:
в отношениях «Блюда» и «Заказы» - это ключ «kod_bluda»;
в отношениях «Вид блюда» и «Блюда» - это ключ «vid_vida»;
в отношениях «Клиенты» и «Заказы» - это ключ «kod_klienta».
в отношениях «Персонал» и «Заказы» - это ключ «kod_rabotnika».
в отношениях «Персонал» и Должности» - это ключ «kod_dolshnosti».
На логическом уровне проектирования в моделируемой информационной системе присутствует неиденцифицирующая связь.
Связь
между сущностями «Блюда» и «Заказы»
неидентифицирующая, не разрешающая
присутствие нулей, т.к. каждое блюдо
входит в определенный заказ. Тип связи
1 ко многим, т.к. одно блюдо можно заказать
несколько раз. и
1 ко многимттствие нулейтрудники
библиотеки
Связь между сущностями «Вид блюда» и «Блюда» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждое блюдо имеет свой вид. Тип связи 1 ко многим, т.к. несколько блюд могут быть одного вида.
Связь между сущностями «Клиенты» и «Заказы» неидентифицирующая, не разрешающая присутствие нулей, т.к. определенный заказ закреплен за определенным клиентом. Тип связи 1 ко многим, т.к. один клиент может сделать несколько заказов.
Связь между сущностями «Персонал» и «Заказы» неидентифицирующая, не разрешающая присутствие нулей, т.к. каждый заказ закреплен за определенным работником. Тип связи 1 ко многим, т.к. один работник может выполнить несколько заказов.
Связь между сущностями «Должности» и «Персонал» инеидентифицирующая, не разрешающая присутствие нулей, т.к. каждый должность закреплена за каждым работником. Тип связи 1 ко многим, т.к. одна должность может быть у нескольких работников.
ER-диаграмма логического уровня представлена на рисунке 8.
Рисунок 8 – ER-диаграмма логического уровня
2.2.2 ER-диаграмма физического уровня. Ограничения ссылочной целостности. Определение триггеров
Физическая модель данных зависит от конкретной СУБД. В ней содержится информация обо всех объектах информационной системы. Одной и той же логической модели может соответствовать несколько разных физических. В физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах.
Проверим, удовлетворяют ли все имеющиеся отношения соответствующим наборам ограничений.
Первая нормальная форма требует, чтобы значения всех атрибутов отношения были атомарными. При рассмотрении информационной модели было отмечено, что значения атрибутов всех отношений логически разделить на элементы нельзя и, следовательно, они удовлетворяют условию первой нормальной формы. Пример, рассмотрим таблицу «Блюда». Ключевой атрубут в ней – «код_блюда» не может быть разделен на элементы. Неключевые атрибуты – «наименование_блюда», «состав_блюда», «каллорийность», «вес», «время_приготовления» и «стоимость» также являются атомарными.
Вторая нормальная форма требует, чтобы отношение находилось в первой нормальной форме, и каждый неключевой атрибут функционально полно зависел от первичного ключа. И это требование также выполняется в рассматриваемой модели. Пример, рассмотрим таблицу «Блюда». Ключевой атрибут в ней – «код_блюда». Неключевые атрибуты – «наименование_блюда», «состав_блюда», «каллорийность», «вес», «время_приготовления» и «стоимость» зависят функционально полно только от первичного ключа.
Для нормализации схем отношений к третьей нормальной форме необходимо чтобы каждый детерминант (любой атрибут, от которого функционально полно зависит некоторый другой атрибут) является возможным ключом. В рассматриваемой модели это условие соблюдается. Пример, рассмотрим таблицу «Блюда». Как было отмечено выше, все неключевые атрибуты функционально полно зависят от первичного ключа, т.е. первичный ключ является детерминантом.
Опишем реализацию ссылочной целостности:
при изменении информации о каком-либо заказе из таблицы «Заказы», в таблицах «Блюда», «Клиенты» и «Персонал» информация будет автоматически меняться (каскадное обновление).
при изменении поля код_блюда из таблицы «Блюда» в таблице «Заказы» информация будет автоматически изменяться (каскадное обновление);
в таблице «Блюда» разрешено изменение записей (каскадное обновление), при добавлении данных поле название_блюда не может оставаться не заполненым (запрет добавления). Проверку осуществляет триггер;
в таблице «Должности» разрешено изменение записей (каскадное обновление), при добавлении данных поля название должности, оклад и выполняемые функции не могут оставаться незаполненными. Проверку осуществляет триггер;
в таблице «Персонал» при изменении информации о работниках происходит каскадное обновление данных. При добавлении данных поле адрес должно быть обязательно заполнено, иначе программа выдаст ошибку. Проверку осуществляет специальный триггер;
в таблице «Клиенты» при изменении данных происходит каскадное обновление. Разрешается удаление информации только в случае, если скидка больше 10%. Проверку осуществляет специальный триггер;
в таблице «Блюда» не разрешается удаление записей, если стоимость блюда меньше 10000 р. Проверку осуществляет триггер;
Опишем используемые типы данных.
Рассмотрим таблицу «Блюда». Ключевое поле этой таблицы kod_bluda содержит коды блюд. Код представляет собой набор цифр (например, 1178). Следовательно, тип данных поля kod_bluda должен быть числовой. Выбираем тип int.
В таблице «Клиенты» имеется поле «Фамилия». Это поле содержит фамилии клиентов. Тип данных для неё – nvarchar(50).
Рассмотрим таблицу «Персонал». Ключевое поле этой таблицы (kod_rabotnika) представляет собой номер, который присваивают каждому сотруднику при принятии на работу. Он представляет собой набор цифр (например, 2431). Следовательно, тип данных поля kod_rabotnika должен быть числовым целым. Выбираем тип int.
Для приложения были разработаны следующие триггеры:
– blud1 срабатывает при вставке нового элемента в таблицу «Блюда». Триггер проверяет поле название блюда. Если оно остается не заполненным, то грограмма выдает ошибку;
– bluda2 запрещает удалять из таблицы «Блюда» запись, если стоимость блюда меньше 10000 р.
– dolshnosti срабатывает при вставке нового элемента в таблицу «Должности». Триггер проверяет поля название должности, оклад и выполняемые функции. Если хотя бы одно из них остается не заполненным, то грограмма выдает ошибку;
– klienti запрещает удалять из таблицы «Клиенты» запись, если скидка у клиента на весь ассортимент блюд в данном кафе меньше 10.
– personal срабатывает при вставке нового элемента в таблицу «Персонал». Триггер проверяет поле adres. Если оно остается не заполненным, то грограмма выдает ошибку;
ER-диаграмма физического уровня показана на рисунке 9.
Рисунок 9 – ER-диаграмма физического уровня