Соответствуют ли эти таблицы нормализации базы данных 3NF? - PullRequest
Новая
       16

Соответствуют ли эти таблицы нормализации базы данных 3NF?

6 голосов
/ 10 апреля 2010

AUTHOR стол

  • Author_ID, ПК
  • First_Name
  • Last_Name

TITLES таблица

  • TITLE_ID, ПК
  • NAME
  • Author_ID, FK

DOMAIN стол

  • DOMAIN_ID, ПК
  • NAME
  • TITLE_ID, FK

READERS стол

  • READER_ID, ПК
  • First_Name
  • Last_Name
  • ADDRESS
  • CITY_ID, FK
  • PHONE

CITY стол

  • CITY_ID, ПК
  • NAME

BORROWING стол

  • BORROWING_ID, рк
  • READER_ID, фк
  • TITLE_ID, фк
  • DATE

HISTORY стол

  • READER_ID
  • TITLE_ID
  • DATE_OF_BORROWING

  • DATE_OF_RETURNING

    1. Соответствуют ли эти таблицы нормализации базы данных 3NF?
    2. Что, если 2 автора работают вместе под одним названием?
    3. Адрес столбца должен иметь свою собственную таблицу?
    4. Когда читатель одалживает книгу, я делаю запись в таблице ЗАИМСТВОВАНИЕ. После того, как он вернул книгу, я удаляю эту запись и делаю еще одну запись в таблице HISTORY. Это хорошая идея? Я нарушаю какое-либо правило? Должен ли я иметь вместо одной таблицы BORROWING столбец DATE_OF_RETURNING?

Ответы [ 4 ]

2 голосов
/ 10 апреля 2010

Это немного похоже на домашнее задание, но позвольте мне все равно ответить:

  1. Нет, таблицы не в 3NF; Таблицы с суррогатными ключами редко бывают. Например, таблица READERS имеет два возможных первичных ключа: READER_ID и (First_Name, Last_Name). Конечно, это зависит от вашей проблемной области: если вы хотите иметь двух отдельных лиц с одинаковыми именем, адресом и телефоном, то это в 3NF. Кроме того, по моему опыту, 3NF обычно больше проблем, чем стоит.
  2. Опять же, это зависит от вашей проблемной области. Вы можете создать отношение «многие ко многим» между авторами и заголовками через промежуточную таблицу.
  3. См. 1.
  4. Вы можете обойтись без BORROWING и создать отлично работающее приложение, так как HISTORY содержит всю необходимую вам информацию. Чем меньше информации нужно отслеживать, тем лучше.
1 голос
/ 11 апреля 2010

Как вы ожидаете, что кто-нибудь серьезно ответит на этот вопрос, не зная вашего бизнеса?

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

Например, чтобы ваша схема была в 3NF, потребуется, чтобы domainID -> titleID или, другими словами, для каждого домена был только один заголовок, а знание домена означает, что вы можете заглавие. На первый взгляд, это кажется любопытным, но единственный, кто может точно сказать, является ли это точным представлением бизнес-реальности, с которой вы имеете дело, - это вы.

1 голос
/ 10 апреля 2010

Я бы поменял заголовки на МНОГО-МНОГИЕ и оставил бы адреса.

TITLES стол

  • TITLE_ID, ПК
  • NAME

TitleAutors таблица

  • TITLE_ID
  • AUTHOR_ID

Вы можете изменить таблицу BORROWING, чтобы иметь статус записи (OUT, IN, MISSING, UNKNOWN) и иметь STATUS_DATE.

0 голосов
/ 23 апреля 2010

Еще одна мысль, которая пришла мне в голову после прочтения других комментариев.

  • Может ли автор быть читателем? (И наоборот)

Если это так, возможно, в вашу систему введены избыточные имена и фамилии, и это может привести к обновлению аномалий. Например, если Джейн Смит была читателем и автором и вышла замуж, а ее фамилия изменилась на Уильямс, тогда существовала бы возможность обновить ее фамилию Читателя, а не ее фамилию автора.

Вы могли бы исправить это, возможно, создав таблицу пользователя, в которой у вас есть два внешних ключа для таблицы авторов и читателей. Просто мысль ...;)

...