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

Question

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

ФАЙЛ, ГРУППА а также БЛОКИРОВАТЬ представляют структуру объекта файла XML.ФАЙЛ является корнем.ГРУППА имеет fk to. ФАЙЛ. БЛОКИРОВАТЬ имеет один FK к ГРУППА и другой ФК ЕДИНИЦА ИЗМЕРЕНИЯ.

ЕДИНИЦА ИЗМЕРЕНИЯ Группы "Аналогичные" Блоки от дифракции Группы в контексте ФАЙЛ.

База данных в настоящее время находится в 3НФ. Тем не менее, я хотел бы знать, какой Единицы принадлежать ФАЙЛ.ID = 1. Для этого я должен сделать запрос, который присоединяется к всему 4 столам. Чтобы оптимизировать эту схему, я могу создать новое отношение ЕДИНИЦА ИЗМЕРЕНИЯ N - FK -> 1 ФАЙЛ. Отказ И все же мой запрос присоединяется только к двум столам на оптимизированной DB-схеме. И вот вопрос: это дБ (с этим новым fk) еще в 3 NF? Что говорит теория?

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

или

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

Я не думаю, что ваши «воровствующие» с диаграммой поддерживают другие зависимости, изложенные в вашем вопросе. Как вы придумали 1: многие отношения между файлом и единицей?

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

• ГРУППА -> ФАЙЛ
• БЛОКИРОВАТЬ -> ГРУППА
• БЛОКИРОВАТЬ -> ЕДИНИЦА ИЗМЕРЕНИЯ

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

• ФАЙЛ -> Другие файловые атрибуты
• ГРУППА -> Другие-группы-атрибуты
• БЛОКИРОВАТЬ -> Другие-блочные атрибуты
• ЕДИНИЦА ИЗМЕРЕНИЯ -> Другие атрибуты

Создание набора 3НФ соотношений от вышеуказанных функциональных зависимостей дает:

• ФИЛЬНЕЛЕНИЕ: (ФАЙЛ, другие файловые атрибуты)
• Грузоподъемность :(ГРУППА, ФАЙЛ, другие групповые атрибуты)
• UnitRelation: (ЕДИНИЦА ИЗМЕРЕНИЯ, другие атрибуты
• Брусие: (БЛОКИРОВАТЬ, ГРУППА, ЕДИНИЦА ИЗМЕРЕНИЯ, другие блок-атрибуты)

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

Определение, которое ЕДИНИЦА ИЗМЕРЕНИЯ экземпляры относится к данному ФАЙЛтребует присоединения к заявлению о поручениях ФАЙЛ а затем погрузиться к блокированию на ГРУППА затем братреляция в унитурирование на ЕДИНИЦА ИЗМЕРЕНИЯ.

Вы хотите избежать этого многочисленного соединения, вставляя новые отношения где-то в модели, которая дает прямое сопоставление от ЕДИНИЦА ИЗМЕРЕНИЯ к ФАЙЛ. Отказ Такое отношение подразумевает функциональную зависимость:

• ЕДИНИЦА ИЗМЕРЕНИЯ -> ФАЙЛ

Это выглядит как бит, который вы добавили в диаграмму «Вороны для ног». Добавление этого вводит логическое противоречие. Оригинальная схема поддерживает данную ЕДИНИЦА ИЗМЕРЕНИЯ относящийся к кратнему ФАЙЛ экземпляры. как в:

• Filerelation (F1, ...)
• Фланцерация (F2, ...)
• Грузоподъемность (G1, F1, ...)
• Грузоподъемность (G2, F2, ...)
• Братрослотие (B1, G1, U1, ...)
• Братрография (B2, G2, U1, ...)
• UnitRelation (U1, ...)

Экземпляр единиц U1 относится к экземплярам файла F1 и F2. Учитывая эту ситуацию либо ЕДИНИЦА ИЗМЕРЕНИЯ -> ФАЙЛ Функциональная зависимость не может быть поддерживалась, или исходный набор функциональных зависимостей был неполным, и схема не в 3НФ.

На данный момент вам нужно решить, поддерживает ли реальный мир ФАЙЛ -> ЕДИНИЦА ИЗМЕРЕНИЯзависимость или нет. Если это делает, то исходная модель не в 3НФ и немного больше переработки схемы, в порядке. Если зависимость не поддерживается, то лучшее, что вы можете сказать:

• ФАЙЛ, ЕДИНИЦА ИЗМЕРЕНИЯ -> ничего

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

• FileNit: (ФАЙЛ, ЕДИНИЦА ИЗМЕРЕНИЯ)

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

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

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

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

• ЕДИНИЦА ИЗМЕРЕНИЯ -> ФАЙЛ

является настоящей функциональной зависимостью, функциональная зависимость:

• БЛОКИРОВАТЬ -> ЕДИНИЦА ИЗМЕРЕНИЯ

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

• ФИЛЬНЕЛЕНИЕ: (ФАЙЛ, другие файловые атрибуты)
• Грузоподъемность :(ГРУППА, ФАЙЛ, другие групповые атрибуты)
• UnitRelation: (ЕДИНИЦА ИЗМЕРЕНИЯ, ФАЙЛ, другие атрибуты
• Брусие: (БЛОКИРОВАТЬ, ГРУППА, другие блок-атрибуты)

Обратите внимание, что то ЕДИНИЦА ИЗМЕРЕНИЯ Иностранный ключ упал с братроплаты. Это потому, что ЕДИНИЦА ИЗМЕРЕНИЯ -> ФАЙЛ FD сделал его избыточным. (БЛОКИРОВАТЬ, ЕДИНИЦА ИЗМЕРЕНИЯ) Соотношение теперь формируется путем объединения унитации к заявлению ФАЙЛТогда заявление на грузоподъемность на ФАЙЛ Тогда грузоподъемность к блокированию на ГРУППА.

Оригинальная схема не была в 3НФ из-за неставленной функциональной зависимости: ЕДИНИЦА ИЗМЕРЕНИЯ -> ФАЙЛ. Отказ Предлагаемый набор соотношений выше находится в 3НФ.

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