Это все еще нормализованная схема БД? база данных - PullRequest
Новая
       30

Это все еще нормализованная схема БД? база данных

1 голос
/ 22 сентября 2010

У меня есть следующая db-схема.

FILE , GROUP и BLOCK представляют структуру объекта файла XML. ФАЙЛ является корнем. ГРУППА имеет FK для ФАЙЛ . BLOCK имеет один FK для GROUP и еще один FK для UNIT .

UNIT группы "похожих" BLOCKs из различных GROUP в контексте FILE

База данных в настоящее время в 3NF.Тем не менее, я хотел бы знать, какие ЕДИНИЦЫ принадлежат FILE .id = 1.Чтобы сделать это еще, я должен сделать запрос, который объединяет все 4 таблицы.Чтобы оптимизировать эту схему, я могу создать новое отношение UNIT n - FK -> 1 FILE .Пока что мой запрос объединяет только две таблицы в оптимизированной db-схеме.И вот вопрос: эта БД (с этим новым FK) все еще в 3 NF?Что говорит теория?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

или 

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Ответы [ 3 ]

1 голос
/ 24 сентября 2010

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

0 голосов
/ 23 сентября 2010

Я не думаю, что ваша диаграмма "гусиная лапка" поддерживает другие зависимости, изложенные в вашем вопросе.Как вы пришли к соотношению 1: Много между FILE и UNIT?

Это функциональные зависимости, которые вы описываете ...

  • GROUP -> ФАЙЛ
  • БЛОК -> ГРУППА
  • БЛОК -> БЛОК

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

  • FILE -> другие атрибуты файла
  • GROUP -> другие атрибуты группы
  • BLOCK -> другие атрибуты блока
  • UNIT -> другие атрибуты блока

Создание набораОтношения 3NF из приведенных выше функциональных зависимостей дают:

  • FileRelation: ( FILE , другие атрибуты файла)
  • GroupRelation: (* GROUP , FILE , другие атрибуты группы)
  • UnitRelation: (* UNIT , другие атрибуты блока)
  • BlockRelation: ( BLOCK , GROUP , UNIT , другие атрибуты блока)

Это в значительной степени соответствует тому, что вы описали.

Чтобы определить, какие UNIT экземпляры относятся к данному FILE , требуется объединение FileRelation с GroupRelation в FILE и затем GroupRelation в BlockRelation в GROUP затем BlockRelation to UnitRelation для UNIT .

Вы хотите избежать этого объединения нескольких таблиц, вставив новое отношение где-то в модель, которое дает прямое отображение из UNIT в FILE .Такое отношение подразумевает функциональную зависимость:

  • UNIT -> FILE

Это похоже на бит, который вы добавили кдиаграмма "гусиная лапка".Добавление этого вводит логическое противоречие.Исходная схема поддерживает наличие заданного UNIT , относящегося к нескольким FILE экземплярам.как в:

  • FileRelation (F1, ...)
  • FileRelation (F2, ...)
  • GroupRelation (G1, F1, ...)
  • GroupRelation (G2, F2, ...)
  • BlockRelation (B1, G1, U1, ...)
  • BlockRelation (B2, G2, U1, ...)
  • UnitRelation (U1, ...)

Экземпляр UNIT U1 относится к экземплярам FILE F1 и F2.В этой ситуации функциональная зависимость UNIT -> FILE не может поддерживаться или исходный набор функциональных зависимостей был неполным, а схема не в 3NF.

Вс этой точки зрения вам нужно решить, поддерживает ли реальный мир зависимость FILE -> UNIT или нет.Если это так, то исходная модель не в 3NF, и немного больше переделки схемы в порядке.Если зависимость не поддерживается, тогда лучше всего сказать:

  • FILE , UNIT -> Ничего

и соответствующее соотношение:

  • FileUnit: ( FILE , UNIT )

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

================================================================================

РЕДАКТИРОВАТЬ

На основании ряда комментариев, сделанных к этому и другим ответам, представляется, что:

  • UNIT -> FILE

- это истинная функциональная зависимость, функциональная зависимость:

  • БЛОК -> БЛОК

, хотя и не является неправильным, должен быть избыточным.Я считаю, что правильный набор отношений 3NF для этой модели сейчас:

  • FileRelation: ( FILE , другие атрибуты файла)
  • GroupRelation: ( GROUP , FILE , другие атрибуты группы)
  • UnitRelation: ( UNIT , FILE , другие атрибуты блока)
  • BlockRelation: ( BLOCK , GROUP , другие атрибуты блока)

Обратите внимание, что внешний ключ UNIT удален из BlockRelation. Это связано с тем, что UNIT -> FILE FD сделал его избыточным. ( BLOCK , UNIT ) теперь формируется путем соединения UnitRelation с FileRelation в FILE затем FileRelation для GroupRelation для FILE затем GroupRelation для BlockRelation для GROUP .

Исходная схема не была в 3NF из-за неустановленной функциональная зависимость: UNIT -> FILE . Предлагаемый набор отношений выше в 3НФ.

Примечание. При нормализации схемы необходимо указывать каждую функциональную зависимость впереди Пропавший может изменить всю картину!

0 голосов
/ 23 сентября 2010

Непонятно, как таблица UNIT вписывается в схему, прежде чем вносить изменения.

Очевидно, что после внесения изменений все, что вам нужно сделать, чтобы узнать, какие единицы принадлежат файлу, это объединить таблицы FILE и UNIT.

Поскольку таблицы имеют формат 3NF, когда все функциональные зависимости определяются ключами, целыми ключами и только ключами (поэтому помогите мне, Кодд), вы должны взглянуть на свою схему в этом свете.

Учитывая имеющуюся информацию, скорее всего, все таблицы в 3NF (и BCNF, и AFAICT в 4NF и 5NF тоже).

...