Проектирование реляционной базы данных на основе декомпозиции универсального отношения
Как мы видели из предыдущего материала, проектирование реляционной базы данных фактически сводится к устранению избыточных функциональных зависимостей (при необходимости избыточных многозначных зависимостей и зависимостей по соединению) из предварительного набора отношений, полученного каким-либо способом (например, из диаграммы «сущность — связь»), В случае если проектируемая база данных сравнительно невелика (общее число атрибутов не превышает 20—30), предварительный набор отношений можно представить в виде одного отношения, называемого универсальным. В него включаются все представляющие интерес атрибуты.
В качестве примера построим универсальное отношение для базы данных publications:
PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBLJJRL, SITE, SITE_URL)
Здесь:
- • AUTHOR — имя автора
- • TITLE — название книги
- • YEARPUB — год издания книги
- • PUBLISHER — наименование издательства
- • PUBLJJRL — ссылка на веб-сервер издательства
- • SITE — наименование Internet-pecypca
- • SITEJJRL — указатель на Internet-pecypc Функциональные зависимости, имеющиеся в полученном отношении, представлены на следующей схеме:
- (1) TITLE |=^> YEARPUB I
- (2) l=t> PUBLISHER ~> PUBJJRL
- (3) SITEI=?>SITEJJRL
Для устранения избыточной функциональной зависимости (3) декомпозируем исходное отношение на два:
PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBLJJRL, SITE) WWWSITES(SITE,SITE_URL)
Приняв во внимание, что атрибут SITE требует типа данных «строка» и, следовательно, его использование в качестве первичного ключа не очень удобно, введем в отношении WWWSITES первичный ключ SITE ID, основанный на целом типе данных. (Такая подстановка, хотя и ведет к избыточности с точки зрения теории, на практике позволяет ускорить обработку данных. Поэтому в дальнейшем примем за правило заменять подобным образом строковые первичные ключи, не оговаривая это в каждом отдельном случае.)
Теперь наши отношения примут вид:
PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBL_URL, SITEJD) WWWSITES(SITE_ID,SITE,SITE_URL)
Устраним функциональную зависимость (2):
PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBJD, SITEJD) PUBLISHERS(PUBJD, PUBLISHER, PUBLJJRL)
WWWSITES(SITE_ID,SITE,SITE JJRL)
Теперь мы имеем следующие избыточные функциональные зависимости в отношении PUBLICATIONS:
TITLE |=> YEARPUB I
'=> PUBJD
Для их устранения необходимо вынести атрибуты
TITLE, YEARPUB и PUBJD в отдельное отношение: PUBLICATIONS(AUTHOR, TITLEJD, SITEJD)
TITLES(TITLEJD,TITLE,YEARPUB,PUBJD)
PUBLISHERS(PUBJD, PUBLISHER, PUBLJJRL)
WWWSITES(SITEJD,SITE,SITE JJRL)
Теперь наша база данных находится в третьей нормальной форме, однако мы видим, что полученный набор отношений не совпадает с набором, полученным из модели «сущность — связь». Для того чтобы разобраться в причинах этого противоречия, рассмотрим отношение PUBLICATIONS вместе с его данными.
Добавим автора, который имеет две книги и две web-страницы (см. табл. 6.4):
Таблица 6.4
|
AUTHOR |
| TITLEJD |
SITEJD |
|
J. Doe |
1 |
1 |
|
J. Doe |
2 |
1 |
|
J. Doe |
1 |
2 |
|
J. Doe |
2 |
2 |
Из таблицы 6.4 становится ясно, что в рассматриваемом отношении существует многозначная зависимость AUTHOR (=^> (=^> TITLE_I D | SITE_ID. Для ее устранения приведем отношение к четвертой нормальной форме, для чего разобьем его на три.
AUTHORS(AU_ID, AUTHOR)
PUBLICATIONS(AUTHOR,TITLE_ID,SITE_ID) ‘=>TITLEAUTHORS(TITLE_ ID.AUJD)
WWWSITEAUTHORS(AU_ID,SITE_ID)
Окончательно получим:
AUTHORS(AU_ID, AUTHOR)
TITLEAUTHORS(TITLEJD,AU_ID)
WWWSITEAUTH ORS( AU_I D, SITE J D)
TITLES(TITLE_ID,TITLE, YEARPUB,PUB JD)
PUBLISHERS(PUBJD,PUBLISHER,PUBL_URL) WWWSITES(SITEJD,SITE,SITE_URL)
Теперь схема базы данных соответствует структуре, полученной другими способами. Анализ показывает, что избыточные функциональные зависимости в ней отсутствуют.
