5.6.Проектирование реляционной базы данных на основе декомпозиции универсального отношения.

Как мы видели из предыдущего материала, проектирование реляционной базы данных фактически сводится к устранению избыточных функциональных зависимостей (а при необходимости избыточных многозначных зависимостей и зависимостей по соединению) из предварительного набора отношений, полученного каким-либо способом (например, из диаграммы сущность связь). В том случае, когда проектируемая база данных сравнительно невелика (общее число атрибутов не первышает 20-30), предварительный набор отношений можно представить в виде одного отношения, называемого универсальным. В него включаются все представляющие интерес атрибуты.

В качестве примера построим универсальное отношение для базы данных publications:

PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBL_URL, SITE, SITE_URL)

здесь Фунциональные зависимости, имеющиеся в полученном отношении, представлены на следующей схеме:
   (1)  TITLE --> YEARPUB
          |
   (2)     -----> PUBLISHER --> PUB_URL

   (3)  SITE ---> SITE_URL
Для устранения избыточной функциональной зависимости (3) декомпозируем исходное отношение на два:
   PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBL_URL, SITE)
   WWWSITES(SITE,SITE_URL)
Приняв во внимание, что атрибут SITE требует типа данных "строка" и следовательно его использование в качестве первичного ключа не очень удобно, введем в отношении WWWSITES первичный ключ SITE_ID, основанный на целом типе данных. (Такая подстановка, хотя и ведет к избыточности с точки зрения теории, на практике позволяет ускорить обработку данных. Поэтому, в дальнейшем примем за правило заменять подобным образом строковые первичные ключи, не оговаривая это в каждом отдельном случае). Теперь наши отношения примут вид:
   PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUBLISHER, PUBL_URL, SITE_ID)
   WWWSITES(SITE_ID,SITE,SITE_URL)
Устраним функциональную зависимость (2):
   PUBLICATIONS(AUTHOR, TITLE, YEARPUB, PUB_ID, SITE_ID)
   PUBLISHERS(PUB_ID,PUBLISHER,PUBL_URL)
   WWWSITES(SITE_ID,SITE,SITE_URL)
Теперь мы имеем следующие избыточные функциональные зависимости в отношении PUBLICATIONS:
     TITLE --> YEARPUB
       |
        -----> PUB_ID
Для их устранения необходимо вынести атрибуты TITLE, YEARPUB и PUB_ID в отдельное отношение:
   PUBLICATIONS(AUTHOR, TITLE_ID, SITE_ID)
   TITLES(TITLE_ID,TITLE,YEARPUB,PUB_ID)
   PUBLISHERS(PUB_ID,PUBLISHER,PUBL_URL)
   WWWSITES(SITE_ID,SITE,SITE_URL)
Теперь наша база данных находится в третьей нормальной форме, однако мы видим, что полученный набор отношений не совпадает с набором, полученным из модели "сущность-связь". Для того, чтобы разобраться в причинах этого противоречия, рассмотрим отношение PUBLICATIONS вместе с его данными. Добавим автора, который имеет две книги и две web-страницы:
    | AUTHOR | TITLE_ID | SITE_ID |
    |--------|----------|---------|
    | J.Doe  |   1      |    1    |
    | J.Doe  |   2      |    1    |
    | J.Doe  |   1      |    2    |
    | J.Doe  |   2      |    2    |
Из этой таблицы становится ясно, что в рассматриваемом отношении существует многозначная зависимость AUTHOR ->> TITLE_ID | SITE_ID. Для ее устранения приведем отношение к четвертой нормальной форме, для чего разобъем его на три.
                                               AUTHORS(AU_ID,AUTHOR)
    PUBLICATIONS(AUTHOR,TITLE_ID,SITE_ID) ->   TITLEAUTHORS(TITLE_ID,AU_ID)
                                               WWWSITEAUTHORS(AU_ID,SITE_ID)

Окончательно получим:

   AUTHORS(AU_ID,AUTHOR)
   TITLEAUTHORS(TITLE_ID,AU_ID)
   WWWSITEAUTHORS(AU_ID,SITE_ID)
   TITLES(TITLE_ID,TITLE,YEARPUB,PUB_ID)
   PUBLISHERS(PUB_ID,PUBLISHER,PUBL_URL)
   WWWSITES(SITE_ID,SITE,SITE_URL)
Теперь схема базы данных соответствует структуре, полученной другими способами. Анализ показывает, что избыточные функциональные зависимости в ней отстутствуют.
Литература:

Следующая глава: 5.7.Обзор некоторых CASE-систем.

Введение в базы данных. (c) Зеленков Ю.А. (yz@yars.free.net) 1997 г.
(c) Центр Интернет ЯрГУ