Попытка нормализовать к BCNF

Я не уверен, в BCNF это или нет, но учитель сказал мне, что INSTRUMENT находится в BCNF.. Он что, издевается надо мной? Учитель постоянно путает мои мысли о том, что правильно, а что неправильно, и заставляет меня сомневаться. Он продолжает говорить вещи, о которых я уже подумал, и я даже не понимаю, что он говорит.

ИНСТРУМЕНТ(InstrumentID,Тип инструмента, Мелодия, Исполнитель, Адр, Телефон, Доступность) ПРИМЕЧАНИЯ(TitleNr,Tune, Композитор, Копии, Название, Исполнитель)

Так это нормализовано? в БКНФ:

Инструмент(InstrumentID, InstrumentType, Tune, Availability, PerformerID*)
ПРИМЕЧАНИЯ(TitleNr, Title, Tune, Composer, Copies, PerformerID*)
ИСПОЛНИТЕЛЬ(PerformerID, Имя, Адр, Телефон)

Настройка находится как в INSTRUMENT, так и в NOTES. Может быть в обоих?


database-normalization
person jdnhldn    schedule 03.08.2010    source источник
comment
Основываясь (немного) на моем ответе ниже, что заставляет вас думать, что доступность как-то связана с инструментом, а не с исполнителем? Или, если на то пошло, мелодия, если мелодия означает что-то вроде оркестровой партитуры?   -  person Mike Sherrill 'Cat Recall'    schedule 15.01.2011

Ответы (3)


arrow_upward
1
arrow_downward

Каждая нормальная форма требует предыдущей нормальной формы.

1 NF — в вашей таблице есть только атомарные значения, т. е. нет наборов.

2 NF - Неключевые атрибуты требуют, чтобы каждая часть вашего ключа была определена.

3 NF - Неключевые атрибуты не требуют определения ничего, кроме ключа.

3.5 NF. Если неключевой атрибут может определять ключевой атрибут, они должны создать уникальный кортеж.

Меня в первую очередь беспокоит то, что означает TitleNr. Если это уникальный идентификатор, то это не 2 NF, поскольку неключевые атрибуты не требуют определения заголовка.

Моя вторая проблема заключается в том, что InstrumentID не является подходящим ключом-кандидатом, если включена настройка Tune. Один инструмент может воспроизводить несколько мелодий, если Instrument.Tune представляет, какие мелодии были сыграны на этом конкретном инструменте. Было бы лучше разделить эти атрибуты в другую таблицу, иначе другие неключевые атрибуты сделают ее не 2 NF.

Если он просто представляет, какие мелодии доступны, это уже можно определить по идентификатору исполнителя, который не является частью ключа инструмента. Тогда это не 3 НФ.

person Thomas Langston    schedule 03.08.2010
comment
Каждая нормальная форма требует предшествующей ей нормальной формы. Хотя в целом это верно, это не верно для BCNF. Текущие определения НФБК не говорят, например, что отношение находится в НФБК тогда и только тогда, когда а) оно находится в 3НФ и б) (независимо)... Вместо этого BCNF определяется в терминах тривиальных зависимостей и суперключей. - person Mike Sherrill 'Cat Recall'; 13.09.2013

arrow_upward
1
arrow_downward

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

Функциональные зависимости определяются данными, а не именами столбцов. Ваш инструктор не дал вам никаких данных. Попытка определить функциональные зависимости только по именам столбцов является рискованным делом, даже если столбцы названы правильно. Ваши столбцы неправильно названы.

Разработчик базы данных с богатым воображением мог бы, вероятно, придумать предикат и примеры данных для первой таблицы «Инструменты», демонстрирующей BCNF.

Возможно, ваш инструктор тоже этого не понимает. Не был бы первым.

person Mike Sherrill 'Cat Recall'    schedule 14.01.2011
comment
«Функциональные зависимости определяются данными». Я бы сказал, что это немного назад. Функциональные зависимости обычно представляют бизнес-правила. Разработка FD на основе данных в экземпляре таблицы так же рискованна, как и угадывание по именам столбцов. - person beldaz; 13.09.2013
comment
Бизнес-правила не могут определить, имеет ли доступность что-то делать с инструментом или с исполнителем. А бизнес-правила нередко показывают непонимание данных. (Прочитайте вопросы, помеченные как database-normalization, где много примеров.) Вот почему функциональные зависимости зависят от данных, а не от имен столбцов. Точнее, они зависят от того, что данные означают. Крис Дейт немного написал об этом в Введение в системы баз данных. - person Mike Sherrill 'Cat Recall'; 13.09.2013
comment
Ах, что эти данные значат. С этим я согласен, и это то, что я подразумевал под своими справочными бизнес-правилами (и да, они могут быть неправильными, но я имел в виду правильные бизнес-правила;) Моя точка зрения заключалась в том, что любой заданный набор данных, предполагая, что она полностью верна, может помочь только исключить некоторые ФД-кандидаты и предложить некоторые вероятные. - person beldaz; 16.09.2013

arrow_upward
0
arrow_downward

Это 2NF, а не BCNF.

INSTRUMENT(InstrumentID, InstrumentType, Tune, Performer, Adr, Phone, Availability)

Вам действительно нужно знать функциональные зависимости, но если предположить, я бы сказал, что adr и phone являются атрибутами исполнителя, а не инструмента. Если атрибуты не описывают ключ (полностью), то это не BCNF.

Предположим, что у каждого исполнителя есть не более одного номера телефона и адреса. Если это так, у вас будет функциональная зависимость:

Performer -> phone, adr

То есть может быть несколько инструментов, связанных с одним и тем же исполнителем, но в каждом случае их телефон и адрес будут одинаковыми (следовательно, записаны избыточно). Я предполагаю, что ключом для отношения к инструменту является InstrumentId, поэтому есть также FD, говорящий, что с каждым инструментом связан не более одного исполнителя;

InstrumentId -> Performer

В таком случае атрибуты phone и adr зависят не напрямую от InstrumentId, а косвенно через Performer. Следовательно, в рамках этого отношения FD Performer -> phone, adr является транзитивной зависимостью. Любое отношение, содержащее транзитивные зависимости, по определению не может быть выше 2НФ (вторая нормальная форма). Так что это не в 3NF и не в BCNF.

2NF не допускает частичных зависимостей. Хорошая новость заключается в том, что, поскольку ключ — это только один атрибут, вам не нужно беспокоиться о частичных зависимостях: вы не можете иметь часть одного атрибута.

person beldaz    schedule 13.09.2013