База данных кинопроката

{id_prokat} будет являться супер-ключом.

Доказательство:

Множество функциональных зависимостей:

Prokat

{id_film, id_manager, id_client} -> {date_out, date_in}

{id_prokat } -> {id_film, id_manager, id_client}

Суперключ k2 = {id_prokat}

Докажем, что k2+ = R2

Применим правила: самоопределение, объединение.

k2+ = {id_prokat}

k2+ = {id_prokat, id_film}

k2+ = {id_prokat, id_film, id_manager}

k2+ = {id_prokat, id_film, id_manager, id_client}

k2+ = {id_prokat, id_film, id_manager, id_client, date_out}

k2+ = {id_prokat, id_film, id_manager, id_client, date_out , date_in}

Все атрибуты зависят от замыкания k2+, следовательно, k2+ = R2 и {id_prokat} является супер-ключом R2

Также составным супер-ключом является  {id_film, id_manager, id_client}

 

R3 “Клиент”

{id_client} -> {address}

{id_client} -> {fio}

{id_prokat} -> {id_client}

В данном случае любое подмножество атрибутов отношения R3, содержащее атрибут

{id_client} будет являться супер-ключом.

Доказательство:

Множество функциональных зависимостей:

Client

{id_client} -> {address, fio}

{id_prokat} -> {id_client}

Применим правила: самоопределение, объединение.

k3+ = {id_client}

k3+ = {id_client, address}

k3+ = {id_client, address, fio}

k3+ = {id_client, address, fio, id_prokat}

Все атрибуты зависят от замыкания k3+, следовательно, k3+ = R3 и {id_client} является супер-ключом R3

 

R4 “Администратор”

{id_admin} -> {birth}

{id_admin} -> {pol}

{id_admin} -> {fio}

В данном случае любое подмножество атрибутов отношения R4, содержащее атрибут

{id_admin} будет являться супер-ключом.

Доказательство:

Множество функциональных зависимостей:

Administrator

{id_admin} -> {birth, pol, fio}

Применим правила: самоопределение, объединение.

k4+ = {id_admin}

k4+ = {id_admin, birth}

k4+ = {id_admin, birth, pol}

k4+ = {id_admin, birth, pol, fio}

Все атрибуты зависят от замыкания k4+, следовательно, k4+ = R4 и {id_admin} является супер-ключом R4

 

R5 “Менеджер”

{id_manager} -> {birth}

{id_manager} -> {fio}

{id_manager} -> {pol}

{id_prokat} -> {id_manager}

В данном случае любое подмножество атрибутов отношения R5, содержащее атрибут

{id_manager} будет являться супер-ключом.

Доказательство:

Множество функциональных зависимостей:

Manager

{id_manager} -> {birth, pol, fio}

{id_prokat} -> {id_manager}

Применим правила: самоопределение, объединение.

k5+ = {id_manager}

k5+ = {id_manager, birth}

k5+ = {id_manager, id_prokat}

k5+ = {id_manager, id_prokat, fio}

k5+ = {id_manager, id_prokat, fio, pol}

Все атрибуты зависят от замыкания k5+, следовательно, k5+ = R5 и {id_manager} является супер-ключом R5

 

2.6 Множество потенциальных ключей

По множеству супер-ключей построим множество потенциальных ключей. Для построения множества потенциальных ключей необходимо выбрать из множества супер-ключей  все не избыточные, уникальные ключи. Для этого рассмотрим минимальные по мощности супер-ключи.

 

Потенциальным ключом в отношении R1 является  {id_film}.

Составным потенциальным ключом в отношении R2 является  {id_film, id_manager, id_client}

Док-во:

Проверим  k = {id_film}

k+ = {id_film}, нет атрибутов, которые зависят от k.

k+ = <> R2, значит k не является потенциальным ключом

 

Проверим  k = {id_manager}

k+ = {id_manager}, нет атрибутов, которые зависят от k.

k+ = <> R2, значит k не является потенциальным ключом

 

Проверим  k = {id_client}

k+ = {id_client}, нет атрибутов, которые зависят от k.

k+ = <> R2, значит k не является потенциальным ключом

Значит {id_film, id_manager, id_client} является потенциальным ключом.

Тогда, как {id_prokat} не является потенциальным ключом, так как является избыточным, содержит атрибуты {id_film}, {id_manager}, {id_client} – которые всегда являются уникальными.

 

Потенциальным ключом в отношении R3 является  {id_client}.

Тогда, как {id_prokat} не является потенциальным ключом, так как является избыточным, содержит атрибут {id_client} – который всегда является уникальным.

 

Потенциальным ключом в отношении R4 является  {id_admin}.

 

Потенциальным ключом в отношении R5 является  {id_manager}.

Тогда, как {id_prokat} не является потенциальным ключом, так как является избыточным, содержит атрибут {id_manager} – который всегда является уникальным.

 

2.7 Первичные ключи

R1 “Фильм”

В данном случае простым первичным ключом является {id_film).

 

R2 “Прокат”

В данном случае составным первичным ключом является {id_film, id_manager, id_client}.

 

R3 “Клиент”

В данном случае простым первичным ключом является {id_client}.

 

R4 “Администратор”

В данном случае простым первичным ключом является {id_admin}.

 

R5 “Менеджер”

В данном случае простым первичным ключом является {id_manager}.

 

2.8 Нормализация отношений

Проведём нормализацию отношений для удаления всех противоречий.

 

1 НФ.

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Поэтому всё остаётся без изменений.

 

2 НФ.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и при этом любой его атрибут, не входящий в состав потенциального ключа, функционально полно зависит от каждого потенциального ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного потенциального ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него частей. Или другими словами: во 2 НФ нет неключевых атрибутов, зависящих от части составного потенциального ключа.

Отношение R1 уже находится во 2 НФ, т.к. первичный ключ является простым.

Для нормализации R2 проведём декомпозицию:

R2 = {id_film, id_manager, id_client , date_out, date_in, id_prokat}

R2’ = {id_prokat, id_film, date_out, date_in}

R2’’ = {id_prokat, id_manager, date_out, date_in}

R2’’’ = {id_prokat, id_client, date_out, date_in}

Отношение R3 уже находится во 2 НФ, т.к. первичный ключ является простым.

Отношение R4 уже находится во 2 НФ, т.к. первичный ключ является простым.

Отношение R5 уже находится во 2 НФ, т.к. первичный ключ является простым.

 

3 НФ.

Отношение находится в 3 НФ, если оно находится в 2 НФ, и все его не ключевые атрибуты не транзитивно зависят от первичного ключа.

 

Отношения R1, R3, R4, R5 являются простыми и удовлетворяют этим условиям, поэтому они уже находятся в 3 НФ.

Составным потенциальным ключом данного отношения является {id_film, id_manager, id_client}

Для нормализации отношения R2, в котором содержатся транзитивные зависимости, проведём декомпозицию:

R2 = {id_film, id_manager, id_client , date_out, date_in, id_prokat}

R2’ = {id_prokat, date_out, date_in} – первичный ключ {id_prokat}

R2’’ = {id_client, date_out, date_in} – первичный ключ {id_client}

 

2.9 Предикат целостности базы данных

Целостность БД – это свойство БД, при соблюдении которого БД содержит полную и непротиворечивую информацию, необходимую и достаточную для корректного функционирования приложений.

Имеется два правила целостности:

• Целостность сущностей (относится к потенциальным ключам)
• Ссылочная целостность (относится к внешним ключам)

Для проверки целостностей сущностей требуется контролировать значения потенциальных ключей всех отношений. Ни один из атрибутов потенциального ключа не может иметь NULL значение, так как каждый потенциальный ключ уникальным образом определяет кортеж в отношении, а кортеж соответствует некоторому реальному объекту. Также недопустимы повторения всех значений атрибутов потенциальных ключей одного отношения.

Для проверки ссылочной целостности требуется контролировать:

• Арности и соответствия доменов атрибутов, внешних и потенциальных ключей (реализовано на этапе разработки схем отношений)
• Правильность ссылки в ссылающемся отношении (гарантию существования кортежа в ссылочном отношении)
• Модификацию или удаление кортежа в ссылочном отношении

 

Предикат целостности БД выглядит следующим образом:

{id_film, nazvanie, opisanie, god_vipuska, regisser, janre} Î Фильм <=> {(nazvanie, regisser – строка из 100 символов) AND (opisanie – строка из 500 символов) AND (janre – строка из 20 символов) AND (id_film – целое положительное из 4 символов) AND (god_vipuska – дата)} AND

{id_prokat, id_film, id_client, id_manager, date_in, date_out} Î Прокат <=> {(id_prokat – целое положительное из 4 символов) AND (id_film – целое положительное из 4 символов) AND (id_client – целое положительное из 4 символов) AND (id_manager – целое положительное из 4 символов) AND (date_in – дата) AND (date_out – дата)} AND

{id_client, address, id_prokat, name} Î Клиент <=> {(id_client, id_prokat – целое положительное из 4 символов) AND (address, name – строка из 100 символов)} AND

{id_admin, pol, fio, birth} Î Администратор <=> {(id_admin – целое положительное из 4 символов) AND (fio – строка из 100 символов) AND (pol – строка из 8 символов) AND (birth – дата)} AND

{id_manager, id_prokat, pol, fio, birth} Î Менеджер <=> {(id_manager, id_prokat – целое положительное из 4 символов) AND (fio – строка из 100 символов) AND (pol – строка из 8 символов) AND (birth – дата)}

 

Не должно быть кортежей с одинаковыми первичными ключами, т.к. первичный ключ однозначно идентифицирует кортеж. Целостность данных не гарантирует их достоверности, поэтому проверка достоверности данных должна опираться на домены атрибутов.

 

2.10 Описать требуемые  виртуальные отношения

1) “Фильмы”

По ключу “Номер фильма” получаем отношение содержащее год выпуска, описание, жанр, режиссёра и название.

П1,2,3,4,5(R1)

 

2) “Менеджер”

С помощью операции объединение производим объединение R3 и R4 по ключу –

“Номер проката”, получаем отношение, содержащее номер менеджера, отвечающего за прокат, Ф.И.О. менеджера и дату возврата:

П1,6(R2) Join П1,2(R4)

 

3) “Прокат”

С помощью операции объединение производим объединение R2 и R1 по ключу – “Номер проката”, получаем отношение, содержащее название и описание фильма, взятого в прокат.

П1(R2) Join П2,3(R1)

 

2.11 Реляционные выражения для реализации запросов

1) Вывести номера менеджеров, у которых количество прокатов = 10

R={δ (<id_prokat> =10)  (id_manager)}

2) Вывести все номера фильмов, у которых режиссёр Михалков

R={δ (<regisser> =”Михалков”)  (id_film)}

3) Вывести все прокаты, у которых номер клиента и  номер менеджера = 3

R={δ (<id_client>=3)&(<id_manager>=3) (id_prokat)}