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

Я должен написать SQL-запрос из данной схемы:

  • BookAuthors (ISBN, authorName, пол, название, год публикации, pubId, pubName, телефон)
  • FD = { ISBN -> title, pubId, yearPublished; имя автора -> пол; pubId -> pubName, телефон }

Вот что я написал:

CREATE TABLE Authors
(
    authorName VARCHAR(64) PRIMARY KEY,
    gender CHAR(1)
);

CREATE TABLE Publishers
(
    pubId VARCHAR(32) PRIMARY KEY,
    pubName VARCHAR(64),
    phone NUMERIC(10)
);
GO

CREATE TABLE Books
(
    ISBN VARCHAR(32) PRIMARY KEY NOT NULL,
    title VARCHAR(32),
    pubId VARCHAR(32) FOREIGN KEY REFERENCES Publishers(pubId) NOT NULL,
    yearPublished NUMERIC(4)
);

Это правильный ответ? Меня беспокоит отсутствие связи между автором и книгой.


sql sql-server database-normalization sql-server-2014-express
person Veasst    schedule 24.01.2016    source источник
comment
AuthorName — очень плохая идея для первичного ключа — во-первых, абсолютно точно есть два автора с одинаковым именем, а во-вторых, такая большая колонка переменной длины — это ужасный выбор для первичного ключа в SQL Server и будет иметь крайне низкую производительность   -  person marc_s    schedule 24.01.2016
comment
Так что насчет authorName в книгах? А как насчет нескольких Терри Митчелов - как мужчин, так и женщин?   -  person paparazzo    schedule 24.01.2016
comment
Могу ли я добавлять сюда свои собственные столбцы, такие как authId или FD, когда задача дает мне схему?   -  person Veasst    schedule 24.01.2016

Ответы (2)


arrow_upward
0
arrow_downward

Проблемы возникают из-за того, что в ваших функциональных зависимостях отсутствует зависимость от ISBN к AuthorName: это потому, что каждая книга однозначно определяет своего автора. Итак, зависимости должны быть:

ISBN -> title, pubId, yearPublished,  authorName
authorName -> gender
pubId -> pubName, phone

Итак, третья нормальная форма выглядит следующим образом:

Books(ISBN authorName pubId title yearPublished) ,
{ ISBN → authorName pubId title yearPublished } >

Authors (authorName gender) ,
{ authorName → gender } >

Publishers (pubId pubName phone) ,
{ pubId → pubName phone } >

И это должен быть набор отношений, которые должны быть определены. Конечно, вы должны добавить правильные ограничения, такие как первичные и внешние ключи (и решение IrateB также является правильным).

Я думаю, что это упражнение, в противном случае вы должны добавить AuthorId к своим исходным данным и изменить функциональные зависимости.

person Renzo    schedule 24.01.2016

arrow_upward
0
arrow_downward

вот предложение;

Авторы (идентификатор автора: целое число, имя автора nvarchar(32), пол: char(1)) первичный ключ(идентификатор автора)

Издатели (pubID: целое число, pubName: nvarchar(32), телефон: nvarhcar(16)) первичный ключ(pubID)

Книги (bookID: целое, ISBN: nvarchar(32), title: nvarchar(32), authorID: целое, pubID: целое, yearPublished: целое) первичный ключ(bookID , autorID) внешний ключ(authorID) ссылается на авторов внешний ключ(pubID) ссылается на издателей.

В прошлую среду я закончил свой финальный тест "Базы данных" (и я прошел этот тест :-)) так что я не специалист. Но я думаю, что вы были бы тверды с этим. И да, вы можете добавить свои собственные столбцы, особенно если это способствует уникальности. Книга считается «слабой сущностью», поэтому первичные ключи также ссылаются на ее идентифицирующую сущность.

Удачи,

B

person IrateB    schedule 24.01.2016
comment
А ФД? Добавляя столбцы, такие как идентификаторы, я меняю FD. Могу ли я сделать это тоже? - person Veasst; 24.01.2016
comment
Можете ли вы дать определение FD, пожалуйста, этого никогда не было во время курса, или, может быть, мы используем другое имя на голландском языке. - person IrateB; 24.01.2016
comment
Функциональная зависимость — это ограничение, где X подразумевает Y. Я думаю, что-то вроде первичного ключа. Значение Y всегда одинаково для некоторого X. - person Veasst; 24.01.2016
comment
да, кажется, я понимаю. В моем примере это получается, если все значения атрибутов являются атомарными (неразделяемыми) и путем создания пользовательского атрибута, такого как authorID. Но, как вы можете видеть в ответе Ренцо, есть более высокие уровни «нормальной формы», удачи! - person IrateB; 24.01.2016
comment
Нормализация никогда не добавляет атрибуты, которых не было в исходных отношениях. - person Mike Sherrill 'Cat Recall'; 24.01.2016
comment
Нет, это не так, но это получается, если я прав? (1НФ) - person IrateB; 24.01.2016
comment
@IrateB: Вопрос о нормализации. Нормализация базы данных никогда не вводит новые атрибуты. Вы ввели два новых атрибута и несколько новых функциональных зависимостей. Вы не занимаетесь нормализацией. - person Mike Sherrill 'Cat Recall'; 01.01.2017