Какой ссылке вы следуете? Как вы можете застрять, если вы не следуете эталонной процедуре? Какие определения и алгоритмы вы используете для 2NF и 3NF?
i В какой нормальной форме находится приведенная выше таблица?
Ответ: Это в 1NF.
Вопрос (i) не имеет смысла. Предположительно имеется в виду, в какой высшей НФ (нормальной форме) находится эта таблица. (В списке 1НФ, 2НФ, 3НФ, ....)
Ваш ответ на (i) не имеет смысла; каждая таблица во 2NF также находится в 1NF. Вы имеете в виду, что он находится в 1NF, но не во 2NF, или его самый высокий NF равен 1NF.
ii Скажите, почему это не во 2NF.
Ответ: SingerID
не определяет songName
, songGenre
или songLength
.
Ваш ответ на (ii) не имеет смысла; он не обращается к определению или алгоритму для 2NF или выше.
iii Перепроектируйте таблицу Songs
и сделайте из нее таблицу во 2NF.
Отвечать:
Singer{singerID, SingerName}
Song{SongID, songName, songLength, songGenre}
Songs{singerID, SongID}
Вопрос (iii) не имеет смысла; нормализация заменяет таблицу другими таблицами. Возможно, они имели в виду что-то вроде «разложить его, пока у вас не будет компонента, находящегося во 2NF». Но ниже я объясню, почему они, вероятно, имели в виду «сделать из этого дизайн, который находится в 2NF».
Возможно, вы интерпретировали вопрос как «разложить его, пока у вас не будет компонента, находящегося во 2NF», соглашаясь с первым возможным намерением выше. Или неправильно истолковал это как «сделать из него кучу таблиц, которые являются 2NF», или, придав тот же смысл, неверно истолковал «таблицу» как «дизайн», согласившись со вторым возможным намерением выше. Если первое, вы не говорите, какой из ваших компонентов является ответом или что все они являются ответами. Однако у вас есть разложение на все таблицы 2NF.
iv Скажите, почему таблица, которую вы составили в части (iii), находится во 2НФ, а не в 3НФ. Сформулируйте любые предположения, которые вам нужны.
Для меня это 3NF.
Now I think all non-key attributes are functionally dependent on the primary key.
Два общих определения 2NF сформулированы в терминах отсутствия каких-либо FD определенных типов, которые считаются «нарушающими». Всегда можно разложить без потерь определенным образом, чтобы получить более мелкие компоненты, где этот FD больше не является проблемой, которую можно разумно расплывчато назвать «перемещением FD в его собственный компонент, оставив другой компонент». Если вы продолжите это делать, у вас, наконец, будут все компоненты 2NF — дизайн 2NF. (Это не является частью хорошего дизайна, даже для 2NF.) Но если вы «сохраните» другую таблицу по пути, вы «создаете» другую таблицу, которая «остается». Таким образом, не существует конкретной таблицы, к которой вы могли бы прийти, если бы вам не сказали какой-то необычный способ декомпозиции каким-то упорядоченным образом. Более того, мы всегда можем разложить напрямую в 3NF, но вопрос (iv) предполагает, что вы не будете этого делать.
Возможно, вопрос (iv) предполагает "эту" таблицу, предполагающую некоторое определение, определенный тип разложения и определенный порядок разложения. . Более вероятно, что вопрос (iv) означает "создать из него проект, который находится во 2НФ" - при условии определенного определения и определенного вида декомпозиции.
Предположительно, вы создали все таблицы 2NF, «переместив» определенные FD в соответствии с вышеизложенным. (Нетривиальные FD с атрибутом nonprime, зависящим от правильного подмножества CK). Но ваш ответ не объясняет этого. Более того, PK (первичные ключи) не имеют значения, важны CK (ключи-кандидаты). Если вы имеете в виду, что в каждой таблице есть только один CK, вы должны сказать об этом и обосновать это. Но это все еще не имеет/не имеет смысла, потому что это не относится к определению или алгоритму разложения до 2NF или выше.
Ваш ответ о 2NF против 3NF не имеет смысла, вы утверждаете, что таблицы находятся в 3NF, и вы должны сказать, почему, но вы этого не делаете. (Причина, по которой Song не находится в 3NF, заключается в том, что ее FD {songID} -> {songGenre}
является транзитивной зависимостью неосновного атрибута от CK через songName
, или ее FD {songName} -> {songGenre}
является зависимостью неосновного атрибута от несуперключа.
PS Когда нам дают PK или CK, должны выполняться определенные FD (функциональные зависимости), а некоторые FD не могут выполняться, а определенные комбинации FD могут и не могут выполняться. При заданном наборе FD, которые выполняются, набор всех FD, которые должны выполняться, задается аксиомами Армстронга, т. е. транзитивным замыканием данного набора. Обычно вопросы, которые дают набор FD, означают, что единственные FD, которые имеют место, являются этими, т. е. что набор является покрытием для FD в таблице. Иногда нам говорят, что это минимальное покрытие. Различные алгоритмы используют различные наборы. К сожалению, во многих вопросах говорится, что FD в наборе сохраняются, но неясно, является ли это покрытием, то есть могут ли другие FD, не входящие в транзитивное замыкание, сохраняться. Как и этот вопрос!
(Пожалуйста, узнайте, что пытаются сказать вопросы, найдите справочник по определениям и процедурам/алгоритмам и следуйте им, пока не застрянете. Затем задайте новый вопрос.)
person
philipxy
schedule
31.07.2017
songGenre
не должен зависеть ни от чего, кроме ключа. Но это зависит отsongName
, который не является ключом. - person Paul Spiegel   schedule 31.07.2017