Пытаясь понять нормализацию базы данных - 3NF - PullRequest
Новая
       14

Пытаясь понять нормализацию базы данных - 3NF

3 голосов
/ 23 ноября 2011

Я пытаюсь понять нормализацию базы данных, в частности 3NF.

Я строю базу данных магазина и, пытаясь нормализоваться до 3NF, придумал структуру ниже.

Структура ниже предполагает

  • Может быть несколько категорий для продукта
  • Существует только одна единица хранения и производитель для каждого продукта
  • Может быть неограниченное количество дополнительных полей

Кто-нибудь может мне сказать, нахожусь ли я на правильном пути, нижеприведенная структура в 3NF или близка? 

Products
----------------
pid (pk)
title
desc
price
weight_base
weight_additional
note
quantity
manufacturer_id (fk)
storage_location_id (fk)

Categories
-----------------
category_id (pk)
category_name
parent_id
description

Product_categories
-----------------
pid (pk)
category_id (pk)

Manufacturers
-------------------
manufacturer_id (pk)
name
description

Storage_locations
---------------------

storage_location_id (pk)
storage_ref
storage_note

Product_extra_field_values
-----------------------------------

PID (pk)
extra_id (fk)
value

Product_extra_fields
--------------------------------

extra_id (pk)
label

Две основные вещи, в которых я не уверен:

  1. Правильно ли использовать составной ключ для Product_categories для размещения нескольких идентификаторов PID в таблице?

  2. Правильно ли просто добавить внешний ключ в первичную таблицу продуктов для производителя и storage_location, поскольку они будут появляться только один раз для каждой записи продукта? Или же конкретный производитель и идентификатор storage_location должны быть удалены из основной таблицы Products, а новые таблицы должны быть созданы следующим образом: 

    Product_storage_locations
----------------------------------
PID (pk)
storage_location_id (pk)

Ответы [ 2 ]

1 голос
/ 23 ноября 2011

Да, то, что у вас есть, выглядит правильно для меня. То, что вы сделали, указав место хранения продукта и производителя в таблице Products, абсолютно правильно. Если вы поместите его в отдельную таблицу (внизу), вы просто создадите для себя больше работы со всеми объединениями, которые вам придется делать позже.

Единственная причина, по которой вы бы разбили это на новую таблицу Product_storage_locations, - это если продукт может находиться в нескольких местах (что, как вы сказали, не так). Однако в случае продуктов и категорий это - это , что вы хотите сделать - и это то, что вы сделали с таблицей Product_categories; и это абсолютно правильно.

Единственное, в чем я не уверен в вашем дизайне, это как вы сделали дополнительные поля. Без дополнительной информации о ваших намерениях трудно сказать, правильно ли вы сделали то, что вы сделали. Однако мне кажется, что то, что у вас есть, представляет собой особый тип поля, который может применяться ко многим продуктам; но при этом каждый из этих продуктов может иметь различное значение для этого поля. Если это ваше намерение, то этот дизайн выглядит хорошо.

1 голос
/ 23 ноября 2011

с помощью трех таблиц - product, category, product_category - вы устанавливаете отношение «многие ко многим» между продуктами и категориями. То есть любой один продукт может принадлежать нескольким категориям, а любая одна категория может быть назначена нескольким продуктам. Если это не намерение, то это не правильный дизайн.

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

Кстати, оба поля в таблице product_category являются внешними ключами (fk), а не первичными ключами, как вы указали.

...