1

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

  • BookAuthors (ISBN, AUTHORNAME, пол, название, yearPublished, PubID, pubName, телефон)
  • FD = {ISBN -> в заголовке , pubId, yearPublished; authorName -> gender; 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) 
); 

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

+1

'AuthorName' - очень плохая идея для первичного ключа - в первую очередь, есть абсолютно возможность иметь двух авторов ** с тем же именем, а во-вторых, такой большой столбец переменной длины является * * ужасный выбор ** для первичного ключа в SQL Server и будет иметь крайне низкую производительность –

+0

Так как насчет authorName в книгах? А как насчет нескольких Терри Митчел - как мужчин, так и женщин? – Paparazzi

+0

Могу ли я добавить свои собственные столбцы, например authId или FD, когда задание дает мне схему? – Veasst

ответ

0

Проблемы возникают из-за того, что в ваших функциональных зависимости отсутствующей зависимость от 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 к своим исходным данным и изменить функциональные зависимости.

0

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

Авторы (AuthorID: целое число, AUTHORNAME NVARCHAR (32), пол: символ (1)) первичный ключ (AuthorID)

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

Книги (BookID: целое число, ISBN: NVARCHAR (32), название: NVARCHAR (32), AuthorID: целое число, бар ID: целое число, yearPublished: целое число) первичного ключ (BookID, autorID) ключ (AuthorID) ссылок чуждых Авторов ключевых (PubID) ссылка зарубежных издателей.

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

Успехов,

B

+0

Как насчет FD? Добавление столбцов, таких как идентификаторы Я меняю FD. Могу я тоже это сделать? – Veasst

+0

Можете ли вы определить FD, пожалуйста, никогда не происходило это во время курса или, возможно, мы используем другое имя на голландском языке. – IrateB

+0

Функциональная зависимость - это ограничение, в котором X подразумевает Y. Что-то вроде первичного ключа, я думаю. Значение Y всегда одинаково для некоторых X. – Veasst

Смежные вопросы