50351 (588704), страница 3
Текст из файла (страница 3)
(Ответственное лицо — отвечает - Компьютеры)
Степень связи «один ко многим» т.к. за каждый компьютер несёт ответственность один человек, и один человек может нести ответственность за несколькими компьютерами. Класс принадлежности обоих сущностей обязательный т.к. за каждый компьютер несёт ответственность ответственное лицо, и каждое ответственное лицо несёт ответственность за компьютеры;
к) Связь «работают» объединяет сущности «Отделы» и «Пользователи»
(Пользователи — работают - Отделы)
Степень связи «один ко многим» т.к. каждый пользователь может работать в одном отделе, и в одном отделе может работать много пользователей. Класс принадлежности сущности пользователи обязателен т.к. все пользователи должны работать в отделах, а класс принадлежности сущности отделы необязателен, потому что в отделе может не быть пользователей.
3.1.4 Отношения
а) Компьютеры (id-Компьютер, Инвентарный номер, iр- Адрес, Название, Цена, id-Ответственное лицо, id-Отделы);
б) Комплектующие (Инвентарный номер, id- Компьютер, id- Документы, id-Комплектующие);
в) Словарь комплектующие (id-Комплектующие, Название, Модель id-Производители, id - Поставщики);
г) Производители (id-Производители, Название, Web-сайт, Е-mail, Адрес, Телефон);
д) Поставщики (id-Поставщики, Название, ‚Web-сайт, Е-mail, Адрес, Телефон);
е) Программное обеспечение (Инвентарный номер, Цена, id- Программное обеспечение);
ж) Словарь ПО (id-Программное обеспечение, Название, Версия, Регистрационный ключ, Web-сайт);
з) Отделы (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 строится из трех основных блоков - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи - глаголами.
Рисунок 3.2 – Логическая модель данных
Рисунок 3.3 – Физическая модель данных
3.2.1 ERWin скрипт
/*Таблица для документов*/
СRЕАТЕ ТАВLЕ Документы (
id_Документы VARCHAR(20) NOT NULL,
№_ документа INTECER NULL,
Дата_ создания DATE NULL
);
ALTER TABLE Документы
ADD (PRIMARY KEY (id_документы));
/ *Таблица для комплектующих*/
СRЕАТЕ ТАВLЕ Комплектующие (
Инвентарный_ номер СНАR(20) NOT NULL,
id_Компьютеры VАRСНАR(20) NOT NULL,
id_Документы VАRСНАR(20) NOT NULL,
id_Комплектующие VАRСНАR(20) NULL,
Цена FLOAT NULL
);
ALTER TABLE Комплектующие
ADD (РRIМАRУ КЕУ (Инвентарный_ номер));
/*Таблица для компьютеров*/
СRЕАТЕ ТАВLЕ Компьютеры (
id_Компьютеры VАRСНАR(20) NOT NULL,
id_Ответственное_ лицо СНАR(20) NOT NULL,
id_Отделы VАRСНАR(20) NOT NULL,
Инвентарный_ номер СНАR(20) NULL,
iр_ Адрес СНАR(20) NULL,
Название СНАR(20) NULL,
Цена FLOAT NULL
);
АLТЕR ТАВLЕ Компьютеры
АDD (РRIМАRУ КЕУ (id_Компьютеры));
/*Ассоциация компьютеры- программное обеспечение*/
СRЕАТЕ ТАВLЕ Компьютеры_ Программное_ обеспеч (
id_Компьютеры VАRСНАR(20) NOT NULL,
Инвентарный_ номер VАRСНАR(20) NOT NULL
);
АLТЕR ТАВLЕ Компьютеры_ Программное_ обеспеч
АDD (РRIМАRУ КЕУ (id_Компьютеры, Инвентарный_ номер));
/* Таблица для ответственного лица*/
СRЕАТЕ ТАВLЕ Ответственное_ лицо (
id_Ответственное_ лицо СНАR(20) NOT NULL,
Имя VАRСНАR2(20) NULL,
Должность VАRСНАR2(20) NULL
);
АLТЕR ТАВLЕ Ответственное_ лицо
АDD (РRIМАRУ КЕУ (id_Ответственное лицо));
/*Таблица для отделов*/
СRЕАТЕ ТАВLЕ Отделы (
id_Отделы VАRСНАR2(20) NOT NULL,
Название VАRСНАR2(20) NULL,
Руководитель VАRСНАR2(20) NULL,
№_ комнаты VАRСНАR2(10) NULL ,
Телефон VАRСНАR2(11) NULL
);
АLТЕR ТАВLЕ Отделы
АDD (РRIМАRУ КЕУ (id_Отделы));
/* Таблица для пользователей*/
СRЕАТЕ ТАВLЕ Пользователи (
id_Пользователи VАRСНАR2(20) NOT NULL,
Id_Отделы VАRСНАR2(20) NOT NULL,
Имя VАRСНАR2(20) NULL,
Должность VАRСНАR2(20) NULL,
Логин VАRСНАR2(20) NULL,
Пароль VАRСНАR2(20) NULL
);
АLТЕR ТАВLЕ Пользователи
АDD (РRIМАRУ КЕУ (id_Пользователи));
/*Таблица для поставщиков*/
СRЕАТЕ ТАВLЕ Поставщики (
id_Поставщики СНАR(20) NOT NULL,
Название СНАR(20) NULL,
Web_сайт СНАR(20) NULL,
Е_mail СНАR(20) NULL,
Адрес СНАR(20) NULL,
Телефон СНАR(11) NULL
);
АLТЕR ТАВLЕ Поставщики
АDD (РRIМАRУ КЕУ (id_Поставщики));
/*Таблица для программного обеспечения*/
СRЕАТЕ ТАВLЕ Программное_ обеспечение (
Инвентарный_ номер VАRСНАR2(20) NOT NULL,
id_ Программное_ обеспечение VАRСНАR2(20) NOT NULL,
Цена FLOAT NULL
);
АLТЕR ТАВLЕ Программное_ обеспечение
АDD (РRIМАRУ КЕУ (Инвентарный_ номер));
/*Таблица для производителей*/
СRЕАТЕ ТАВLЕ Производители (
id_Производители VАRСНАR2(20) NOT NULL,
Название СНАR(20) NULL,
Web_сайт СНАR(20) NULL,
Е_mail СНАR(20) NULL,
Адрес СНАR(50) NULL
);
АLТЕR ТАВLЕ Производители
АDD (РRIМАRУ КЕУ (id_Производители));
/*Таблица для словаря комплектующих*/
СRЕАТЕ ТАВLЕ Словарь_комплектующие (
id_Комплектующие VАRСНАR2(20) NOT NULL,
id_Производители VАRСНАR2(20) NOT NULL,
id_Поставщики СНАR(20) NULL,
Название VАRСНАR2(20) NULL,