8. Разработайте ER-схему БД Книжный магазин: авторы, книги, продавцы, покупатели, регистрация продаж Определим ключи независимых сущностей. В сущности Авторы можно было
сделать составной ключ из всех полей, но тогда неудобно было бы использовать его в дальнейшем, поэтому вводим Код автора. Для Покупателя тоже лучше создать атрибут Код покупателя, хотя можно взять ключом номер телефона например, аналогично поступаем и с сущностью Продавцы. В книгах не повторяются серийные номера, а в регистрации продаж уникальные номера чехов, значит эти атрибут подходят в качестве ключей.
Связи: Один автор может написать несколько книг, а у книги может быть несколько автором, связь м:м, нужна сущность связка. Автор и связка, а также Книги и связка связаны 1:м с кп обязательно на стороне много (связка). В одном чеке указан только один продавец, но он может быть в нескольких чеках: связь 1:м, причем в каждом чеке обязательно указан продавец, значит кп на стороне много (сущность Регистрация продаж) обязательный. В одном чеке указан только один покупатель, но он может быть в нескольких чеках: связь 1:м, причем в каждом чеке обязательно указан покупатель, значит кп на стороне много (сущность Регистрация продаж) обязательный. В одном чеке может быть указано несколько книг, но книга с таким серийным номером есть только в одном чеке: связь 1:м, причем распроданы не все книги, значит кп на стороне много (Книги) необязательный, нужна сущность связка.
9. Разработайте ER-схему БД Парикмахерская: клиенты, прайс-лист услуг, сотрудники, кассовый журнал.
Добавим атрибуты Код клиента, Код услуги, Код сотрудника и Код записи, так как использовать номера телефонов неудобно, названия услуг могут повторятся, а на одну запись в салон может приходится несколько процедур. Связи: обычно любой сотрудник парикмахерской может делать любую услугу, поэтому связывать эти таблицы дополнительно не имеет смысла, аналогично любой клиент может заказать любую услугу у любого мастера. Тогда сущности будут связываться только с Кассовым журналом, причем каждая запись должна иметь обязательно Данные об услугу, Сотруднике и клиенте, и записей с каждым будет много, то есть связь 1:м (м для кассового журнала) и кп у м обязательное.
10. Дано отношение БОЛЬНИЦЫ (первые 7 записей):
Номер |
Наименование |
Профильное |
Количество больных, |
больницы |
больницы |
заболевание |
лечивших в данной |
|
|
|
больнице данное |
|
|
|
заболевание |
|
|
|
|
1 |
Боткинская |
Глаукома |
100 |
|
|
|
|
1 |
Боткинская |
Гастрит |
120 |
|
|
|
|
2 |
им. Семашко |
Колит |
20 |
|
|
|
|
2 |
им. Семашко |
Остеохондроз |
100 |
|
|
|
|
3 |
им. Пирогова |
Палеотрит |
200 |
|
|
|
|
3 |
им. Пирогова |
Бронхит |
100 |
|
|
|
|
3 |
им. Пирогова |
Глаукома |
200 |
|
|
|
|
и т.д.
Номера и наименования больниц – уникальны, одна и та же болезнь может лечиться в разных больницах. Определите потенциальные ключи, аномалии, зависимости. Нарушение какой нормальной формы наблюдается? Нормализуйте отношение. Постройте реляционную схему БД.
Потенциальные ключи: Номер больницы+профильное заболевание; наименование больницы+профильное заболевание Аномалии:Удаления, включения и модификации
Зависимости: Номер больницы->Профильное заболевание; Номер больницы+Профильное заболевание->Количество больных, лечивших в данной
больнице данное заболевание; Наименование больницы->Профильное заболевание; Наименование больницы+Профильное заболевание->Количество больных, лечивших в данной больнице данное заболевание Нарушение 2НФ
11. Разработайте ER-схему БД Школа: учителя, предметы, ученики, журнал успеваемости.
Определим ключи независимых сущностей. В сущности Учителя ключом мог бы стать атрибут Телефон, как и в сущности Ученик. Однако надежнее ввести для этой цели в число атрибутов этих сущностей специальные атрибуты с уникальными значениями: Код Учителя и Код Ученика. В сущности Предметы все атрибуты могут представлять составной клюю, так как один учитель может вести несколько разных предметов, а также один предмет может вести один учитель у разных классов, но можно ввести также уникальный ключ - Код предмета. Для таблицы успеваемость введем поле код записи, так как в противном случае могут повторяться строки, что является нарушение правила. Связи: один учитель может вести несколько предметов, а также один предмет у разных классов могут вести разные учителя, значит связь М:М, значит нужна сущность-связка. Аналогично М:М между ученики и предметы, учителя и ученики и связь журнал успеваемость со всеми остальными, но можно ввести одну сущность, которая будет показывать какой учитель ведет у какого ученика и какой предмет, именно через нее можно связать все сущности и ее связь с Учителя, Ученики, Предметы будет один ко многим (многие на стороне новой сущности) и, поскольку у каждого ученика есть и предметы и учителя, каждый учитель обязательно ведет предмет и имеет учеников и так далее, тогда кп на стороне много обязательное. Связка-Журнал тоже 1:м, м обязательное.
12. Даны отношения:
СТУДЕНТЫ (№ЗачКн, ФИО) ПРЕДМЕТЫ (КодПредм, Название)
ОЦЕНКИ (КодПредм, №ЗачКн, Балл, Группа)
Нарушение какой нормальной формы наблюдается? Нормализуйте отношения. Постройте реляционную схему БД.
НФБК
13. Разработайте ER-схему БД Ремонтная мастерская: виды работ, исполнители, заказы на ремонт, заказчики.
Добавим атрибуты Код заказчика, Код работы, Код исполнителя и Код заказа, так как использовать номера телефонов неудобно, названия услуг могут повторятся, а на одну запись в салон может приходится несколько процедур. Связи: исполнитель может делать несколько видов работ и одну работу могут исполнить несколько заказчиков, связь м:м, добавляем сущность связку со связью 1:м и кп на м обязательно. Заказчик может у кого угодно заказать что угодно и уто можно увидеть только в сущности заказы на ремонт, значит связь только с этой сущностью, причем один заказчик может сделать много заказов,