Локальная компьютерная сеть (стр. 4 из 15)
з) Отделы (id-Отделы, Название, Руководитель, Телефон, № комнаты);
и) Ответственное лицо (id-Ответственное лицо, Имя, Должность);
к) Пользователи (id-Пользователи, Имя, Должность, Логин, Пароль, id-Отделы);
л) Документы (id-Документы, Номер документа, Дата создания);
м) Связь компьютеры - программное обеспечение (id-Компьютер, Инвентарный номер).
3.1.5 Исследование на НФБК
Проведем проверку: соответствует ли спроектированная база данных нормальной форме Бойса-Кодда.
Как видно из логической и физической модели ни одно отношение не может быть представлено проекцией атрибутов другого отношения. Также ни одно отношение не может быть получено путем проведения последовательных JOIN операций. Это свидетельствует об отсутствии избыточности в спроектированной базе данных.
Компьютеры
| Возможный ключ | Детерминант |
| id-Компьютер | id-Компьютер |
Комплектующие
| Возможный ключ | Детерминант |
| Инвентарный номер | Инвентарный номер |
Словарькомплектующих
| Возможный ключ | Детерминант |
| id-Комплектующие | id-Комплектующие |
Производители
| Возможный ключ | Детерминант |
| Id- Производители | id- Производители |
Поставщики
| Возможный ключ | Детерминант |
| id- Поставщики | id- Поставщики |
Пользователи
| Возможный ключ | Детерминант |
| id- Пользователи | id- Пользователи |
Ответственноелицо
| Возможный ключ | Детерминант |
| id-Ответственное лицо | id-Ответственное лицо |
Отделы
| Возможный ключ | Детерминант |
| id-Отделы | id- Отделы |
Программное обеспечение
| Возможный ключ | Детерминант |
| Инвентарный номер | Инвентарный номер |
Словарь ПО
| Возможный ключ | Детерминант |
| id-Программное обеспечение | id- Программное обеспечение |
Документы
| Возможный ключ | Детерминант |
| id-Документы | id- Документы |
Так как для каждой таблицы внутри существует функциональная зависимость только между первичным ключом и любым набором атрибутов таблицы. То, следовательно, все детерминанты являются первичными ключами. Таким образом, выполняется второе условие необходимое для того, чтобы база данных находилась в нормальной форме Бойса-Кодда.
Как было выяснено для созданной базы данных, выполняются оба необходимых и достаточных условия, для того чтобы созданная база данных находилась в нормальной форме Бойса-Кодда. Следовательно, проектированная база данных находится в НФБК.
3.1.6 Проверка на избыточность
Функциональная зависимость, не заключающая в себе такой информации, которая не могла быть получена на основе других зависимостей, из числа использованных называется избыточной функциональной зависимостью. Поскольку избыточная функциональная зависимость не содержит уникальной информации, она может быть удалена из набора функциональных зависимостей без влияния на результат.
Не одно из отношений не избыточно так как:
а) Все атрибуты одного отношения не могут быть найдены в другом отношении проекта (т.е. атрибуты одного отношения не являются подмножеством множества атрибутов другого отношения);
б) Все атрибуты одного отношения не могут быть найдены в отношении, полученном из других отношений проекта.
3.2 Разработка модели данных, используя CASE – средства ERwin
Построение модели данных предполагает определение сущностей и атрибутов, то есть необходимо определить какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить “технических” наименований и быть достаточно важными для того, чтобы их моделировать.
ЕRwin - средство разработки структуры базы данных (БД). Он имеет развитый инструмент для облегчения проектирования модели данных. ЕRwin сочетает графический интерфейс Windows, инструменты для построения ЕR- диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.
В ERwin, как было сказано уже ранее, существуют два уровня представления и моделирования - логический и физический. На логическом уровне (Рисунок 3.2) не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ЕRwin (Рисунок 3.3).
Диаграмма ERwin строится из трех основных блоков - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи - глаголами.
