Добавлен: 21.10.2018
Просмотров: 858
Скачиваний: 5
Поэтому целесообразно выделить информацию о городе в отдельное поле
«gorod_zakazchika».А поле «adres_zakazchika» будет указывать улицу, дом и
квартиру заказчика.
Поле «telephon» в таблице “Zakazi” содержит информацию о домашнем
и
контактном
телефоне
заказчика.
Поэтому
делим
его
на
«dom_tel_zak»,«kont_tel_zak».
Поле «yslugi» в таблице “Zakazi” включает в себя услуги по
оформлению книги( цветность страниц, качество обложки, формат книги) .
Поле «stoimost_yslugi» в той же таблице включает перечень стоимости услуг.
Т.е. эти поля образуют повторяющиеся группы. Выделим их в отдельную
таблицу “Yslugi”.
Поле «adres_sotrudnika» в таблице “Sotrudniki” считаем атомарным,
т.к. постоянная работа в издательстве подразумевает проживание сотрудника
в городе, где находится издательство.
Поле «pasportnie_dannie» в таблице “Sotrudniki” содержит несколько
значений – данные о серии, номере и дате выдачи документа, а также о
наименовании государственного органа, выдавшего документ.
С
целью
поддержания
целостности
данных
о
сотрудниках
целесообразно разбить данное поле на три поля: «sn_pasp_sotr»,
«data_pasp_sotr» и «mest _pasp_sotr».
Поле «telephon» в таблице “Sotrudniki” содержит информацию о
домашнем и контактном телефоне сотрудника. Поэтому делим его на
«dom_tel_sotrudnika»,«kont_tel_sotrudnika».
Поле «adres_avtora» в таблице “Avtori” разделим на два поля:
«gorod_avtora», «adres_avtora»,т.к. с издательством могут сотрудничать
авторы из разных городов.
Поле «pasportnie_dannie» в таблице “Avtori” является многозначным.
Аналогично полю «pasportnie_dannie» в таблице “Sotrudniki” разбиваем это
поле на три «sn_pasp_avt», «data_pasp_avt» и «mest_pasp_avt».
Также
поле
«telephon»
в
таблице
“Avtori”,
делим
на
«dom_tel_avtora»,«kont_tel_avtora».
В поле «uchastniki_kontrakta» в таблице “Kontrakti” выделим два поля
«avtor_kontrakt» и «menedger_kontrakt», значения которых определяют
участников заключения контракта. Но в ранее рассмотренном анализе
предметной области отмечено, что контракт подписывается всеми авторами
книги, а также, что для каждого автора устанавливается свой гонорар, в
зависимости от порядкового номера, под которым указан автор. Таким
образом поля «avtor_kontrakt» и «gonorar_avtora» являются многозначными.
Поэтому необходимо ввести отдельную таблицу “Avtor_knigi”, в которой
будут
содержаться
поля:
«avtor_kontrakt»,
«gonorar_avtora»,
«poryadkovii_nomer» и поле «ISBN», указывающее на книгу за которую
выплачивается гонорар.
Таким образом, получили список атомарных полей без повторяющихся
групп, т.е. первое требование 1НФ выполнено.
Чтобы обеспечить второе требование необходимо определить
первичные ключи в каждой таблице.
Первичный ключ в таблице “Knigi” -поле «ISBN», которое однозначно
определяет остальные не ключевые поля данной таблицы.
В таблице “Sotrudniki” для первичного ключа выделим поле
«tabelnii_nomer», приняв при этом допущение - каждому сотруднику
присваивается свой табельный номер, а записи об уволенных сотрудниках
деактивируются.
В таблице “Zakazi” выделяем составной первичный ключ из полей
«Nomer_zakaza» и «FIO_zakazchika», однозначно определяющие остальные
не ключевые поля данной таблицы.
В таблице “Kontrakti” в качестве первичного ключа выделим поле
«nomer_kontrakta».
В таблицах “Yslugi”, «Avtori» и “Avtor_knigi” нет подходящих полей
для первичного ключа, поэтому вводим в данные таблицы семантически
незначащие поля «Id_yslugi», «Id_avtora» и «Id_avt_knigi» соответственно,
которые однозначно определяют остальные не ключевые поля.
Поскольку ключевые поля всех таблиц не имеют пустот (Рис.2), то
процесс приведения таблиц к 1НФ считаем завершенным.
Рис. 2 – Структура таблиц в первой нормальной форме
Вторая
нормальная форма
Таблица находится во 2НФ, если она удовлетворяет следующим
требованиям:
а) таблица должна быть приведена к 1НФ;
б) поля, которые зависят только от части первичного ключа должны
быть выделены в состав отдельных таблиц ;
в) все таблицы должны быть связаны между собой.
В рассматриваемом примере таблицы приведены к 1НФ, то есть одно из
требований 2НФ выполнено. Для обеспечения второго требования,
необходимо проанализировать каждую из полученных таблиц (Рис.2), на
предмет зависимостей неключевых полей таблицы от части первичного
ключа.
Так ключевые поля всех таблиц,представленных на рис.2,за исключением
“Sotrudniki” и “Zakazi” , являются простыми и однозначно определяют
детальные неключевые поля соответствующих таблиц. Эти таблицы
оставляем без изменений.
В таблице “Sotrudniki” поле «oklad» зависит от не ключевого поля
«dolgnost», поэтому необходимо создать отдельную таблицу “Dolgnosti” и
перенести в нее поля «dolgnost» и «oklad». В качестве первичного ключа этой
таблицы введем семантически незначащее поле «Id_dolgnosti».
В таблице “Zakazi” первичный ключ состоит из полей «Nomer_zakaza» и
«FIO_zakazchika». Поэтому разделим эту таблицу на две “Zakazi” и
“Zakazchiki”. В таблице “Zakazi” будут содержаться поля : «nomer_zakaza»,
«data_post_zakaza»
,
«data_vidachi»,
«stoimost_zakaza»,
которые
характеризуют сделанный заказ. «Nomer_zakaza» будет первичным ключом.
Таблица
“Zakazchiki”
будет
содержать
поля
:
«FIO_zakazchika»,
«dom_tel_zak»,«kont_tel_zak»,«gorod_zakazchika»,«adres_zakazchika»,
характеризующие заказчика. Для обеспечения уникальности записей
таблицы вводим семантически незначащее поле «Id_zakazchika» .
Второе требование 2НФ выполнено, перейдем к выполнению третьего
требования.
В обязанности сотрудников входит редактирование книг, составление
контрактов и принятие заказов. Таким образом, таблицы “Kontrakti”, “Knigi”
и “Zakazi” должны быть связаны с таблицей “Sotrudniki”, т.е. внешним
ключом в данных таблицах будет поле «tabelnii_nomer».
ISBN книги однозначно определяет редактируемую книгу, редакторов,
авторов книги, подписанный контракт, менеджера, а также заказ. Поэтому в
таблицах “Kontrakti”, “Avtor_knigi” и “Zakazi” добавим поле «ISBN»-
внешний ключ,который будет являться полем связи с таблицей книги.
Таким образом получается,что в ряде таблиц присутствуют одинаковые поля
связи,в результате чего появляется избыточность, а это противоречит
основной цели нормализации –устранение избыточности данных.
Для решения этой задачисоздадим отдельную таблицу, называемую
ассоциативной, “Rabota_sotr” . Данная таблица будет содержать общие поля
«tabelnii_nomer», «ISBN», а также «vid_rabot»,для указания вида работ
сотрудников. Первичным ключом в этой таблице назначим семантически не
значащее поле «Id_rab_sotr».
Между тем каждую книгу могут редактировать несколько редакторов, т.е.
одну и ту же работу могут выполнять несколько сотрудников, а один
менеджер может принимать заказ и составлять контракт,т.е. один сотрудник
может выполнять несколько видов работ. Поэтому необходимо вынести поле
«vid_rabot» в отдельную таблицу. Введем семантически не значащее поле
«Id_vid_rabot»-первичный ключ.
Каждому заказу соответствуют различные наборы услуг, поэтому образуется
связь типа «многие-ко-многим». Эту проблему также можно решить с
помощью ассоциативной таблицы. Добавим таблицу “Yslugi_knigi”,
содержащую поля «Id_yslugi», «nomer_zakaza». В качестве первичного ключа
введем семантически незначащее поле «Nomer_zapisi».
Таблицы “Knigi” и “Avtori” связаны между собой через таблицу
“Avtor_knigi”. Поле «avtor_kontrakt» в таблице “Avtor_knigi” содержит
информацию об уникальном номере автора, т.е. «Id_avtora». Поэтому
заменим название поля «avtor_kontrakt» на «Id_avtora» и установим связь
“Avtori”-“Avtor_knigi”, посредством поля «Id_avtora». При этом тип связи
будет «один-ко-многим» , т.к. один автор может написать несколько
книг.Установим связь “Knigi”-“Avtor_knigi” посредством поля «ISBN». Тип
связи «один-ко-многим»,т.к. у одной книги может быть несколько авторов.
Далее переходим к таблице “Rabota_sotr”, посредством внешних ключей
«ISBN» и «tabelnii_nomer» связываем ее с таблицами “Knigi” и “Sotrudniki”
соответственно. Тип связей «один-ко-многим».
Также таблицу “Rabota_sotr” необходимо связать с таблицей “Zakazi” .Для
этого добавляем в таблицу “Zakazi” внешний ключ «Id_rab_sotr» и
устанавливаем связь один-ко-многим посредством этого поля.
Поле «menedger_kontrakt» в таблице “Kontrakti” содержит информацию
содержит информацию о работе сотрудника,в данном случае менеджера-
«Id_rab_sotr». Поэтому заменим название поля «menedger_kontrakt» на
«Id_rab_sotr» и свяжем с таблицей “Rabota_sotr” .
Для установления связи с ранее выделенной таблицей “Vid_rabot” добавим в
таблицу “Rabota_sotr” поле «Id_vid_rabot» - внешний ключ и проведем связь
«один-ко-многим».
Таблицу “Sotrudniki” необходимо связать с таблицой “Dolgnosti”, поэтому
добавляем в таблицу “Sotrudniki” поле «Id_dolgnosti»-внешний ключ и
проведем связь типа «один-ко-многим» посредством этого поля.
Таблицы “Zakazi” и “Zakazchiki” должны быть связаны между собой,
поэтому вводим в таблицу “Zakazi” поле «Id_zakazchika» и посредством
этого поля проводим связь типа «один-ко-многим», т.к. один заказчик может
сделать несколько заказов.
Далее связываем между собой таблицы “Zakaz” и “Yslugi_knigi”, для этого
добавим в таблицу “Yslugi_knigi” внешний ключ «nomer_zakaza».
И наконец ,посредством поля «Id_yslugi» проводим связь “Yslugi”-
“Yslugi_knigi”. Тип данных связей «один-ко-многим».
Поскольку все таблицы связаны между собой (Рис.3), то процесс приведения
таблиц ко 2НФ считаем завершенным.
Рис.3- Структура таблиц во второй нормальной форме
Третья
нормальная форма
Таблица находится в 3НФ, если она удовлетворяет следующим
требованиям:
а) таблицы должны быть приведены ко 2НФ;
б) не должно быть транзитивных зависимостей между не ключевыми
полями;
В данном примере таблицы приведены к первой и второй нормальным
формам, то есть одно из требований выполнено. Перейдем к выполнению
второго требования.
Транзитивная зависимость имеет место, если какое-либо неключевое
поле функционально зависит от другого неключевого поля, а тот в свою
очередь функционально зависит от ключа.
В нашем случае поле «kategoriya» в таблице “Knigi” определяется только
ISBN книги, поэтому одна и таже категория будет многократно повторяться
в разных экземплярах данного информационного объекта. При этом
наблюдаются затруднения в корректировке , например, при удалении какой-