Я продолжаю портить 1NF

Question

Для меня наиболее понятным описанием того, что я нашел до 1NF, является «Первичный ключ - это столбец (или группа столбцов), который уникально идентифицирует каждую строку.На сайте www.phlonx.com я понимаю, что избыточность означает, что для каждого ключа не должно быть более 1 значения для каждой строки.Тогда более 1 значение будет «избыточным».Правильно?

И все же мне часто удается испортить 1 НФ.Я разместил вопрос для моего онлайн-пиццерии http://foo.com pizzashop здесь

, где я был озадачен чем-то во второй нормальной форме, только чтобы заметить, что я началнеправильно в 1 нф.Сейчас я думаю, что мне нужно 3 ключа в 1NF, чтобы однозначно идентифицировать каждую строку.В этом случае я обнаружил, что order_id, pizza_id и topping_id сделают это для меня.Так что это 3 колонки.Потому что, если вы хотите узнать, какая именно пицца является какой, вам нужно знать, какой у нее order_id, какой тип пиццы (pizza_id) и какая начинка там.Если вы знаете это, вы можете посмотреть все остальное.Тем не менее, из ответа на предыдущий вопрос это кажется неправильным, поскольку topping_id попадает в другую таблицу, которую я не понимаю.Вот список столбцов:

Идентификатор заказа
Дата заказа
Идентификатор клиента
Имя клиента
Телефон
Акция
Черный список Y или N
Адрес клиента
Почтовый индекс
Город
Электронная почта
Pizza_id
Pizza_name
Размер
Pizza_price
Сумма
Topping_id
Topping_name
Topping_prijs
Доступно
Delivery_id
Delivery_zone
Deliveryguy_id
Deliveryguy_name
Delivery Y или N

Редактировать: я пометил идентификаторы для первого связанного ключажирным шрифтом.Они являются только списком ненормализованных столбцов.Они не 1 стол или 3 стола или что-то еще

Answer 1

Я бы использовал для этого еще несколько таблиц, чтобы убрать дубликаты для клиентов, заказов, начинки и пиццы:

Таблица: Клиент

   Customer_id
    Customer_name
    Customer_name
    Phone
    Promotion
    Blacklist Y or N
    Customer_address
    ZIP_code
    City
    E_mail

Таблица: Заказ

Order_id
Order_date
Customer_id
Delivery_zone
Deliveryguy_id
Deliveryguy_name
Delivery Y or N

Стол: Order_Details

Order_ID (FK on Order)
Pizza_ID (FK on Pizza)
Amount

Стол: Pizza

Pizza_id
Pizza_name
Size
Pizza_price

Стол: Topping

Topping_id
Topping_name
Topping_prijs
Availabitly

Стол: Pizza_Topping

Pizza_ID
Topping_ID

Pizza_topping и Order_details - это так называемые таблицы переборов («вспомогательные» таблицы для моделирования отношения am: n между двумя таблицами).

Теперь предположим, что у нас есть только одна пицца, несколько начинок и заказы нашего клиента Билли Смита2 quattro stagione pizze - наши таблицы будут содержать это содержимое:

Пицца (Pizza_ID, Pizza_name, Pizza_price)

  1 Quattro stagioni 12€

Topping (Topping_id, topping_name, topping_price)

  1 Mozzarrella 0,50€
  2 Prosciutto 0,70€
  3 Salami 0,50€

Pizza_Topping (Pizza_ID, Topping_ID)

 1 1
 1 3

(здесь пицца quattro stagioni содержит только моцареллу и салями).

Заказ (order_ID, Customer_name - остальные пропущены)

1 Billy Smith

Order_Details (order_id, Pizza_id, сумма)

1 1 2  

Я удалил идентификатор доставки, поскольку для меня нет различий между Заказом и доставкой - или вы поддерживаете частичные поставки?

Answer 2

используйте Моделирование ролей объектов (скажем, с помощью NORMA), чтобы получить информацию о дизайне, нажмите кнопку, и она выдаст SQL.

Это будет проще, чем вернуться назади далее между 1NF, 2NF и т. д. Дизайн ORM гарантированно будет в 5NF.

Некоторые примечания:

• вы можете иметь составные ключи
• суррогатные ключи могут быть добавлены после как концептуального, так и логического дизайна: вы добавили их заранее, что плохо.Они добавлены из-за производительности СУБД, а не во время разработки
• Вы прочитали несколько источников по 1NF?
• , начните с простого английского и некоторых фактов.Вот что ORM делает с вербализацией.

Итак:

1. У клиента много пицц (от нуля до n)
2. У пиццы много начинок (от нуля до n)
3. У клиента есть адрес
4. У пиццы есть база
5. ...

Answer 3

На 1NF, из Википедии, дата цитирования:

Согласно определению Даты 1NF, таблица в 1NF тогда и только тогда, когда она «изоморфно некоторому отношению», которое означает, в частности, что он удовлетворяет следующие пять условий:

• Нет упорядочения строк сверху вниз.
• Нет упорядочения по столбцам слева направо.
• Нет повторяющихся строк.
• Каждое пересечение строк и столбцов содержит ровно один значение из соответствующего домена (и больше ничего).

• Все столбцы являются обычными [т.е. строки не имеют скрытых компонентов, таких как идентификаторы строк, идентификаторов объектов или скрытые метки времени].

  - Крис Дата, «Что действительно означает первая нормальная форма», стр. 127–8 [4]

Первые два гарантированы в любой современной СУБД.

Дублирующие строки возможны в современной СУБД, но только если у вас нет первичных ключей (или других уникальных ограничений).

Четвертый - самый сложный (и зависит от семантики вашей модели) - например, ваше поле Customer_address может нарушать 1NF. Возможно, потому что, если вы заключите договор с самим собой (и с любым потенциальным пользователем системы), что вы всегда будете рассматривать адрес в целом и не захотите разделять название улицы, номер улицы и / или этаж, вы все равно можете требовать что 1NF не сломан.

Было бы правильнее разорвать адрес клиента, но есть сложности, с которыми вам затем придется столкнуться, и которые могут не принести никакой пользы (при условии, что вам никогда не придется заглядывать в субатомную часть адресная строка).

Пятый нарушается некоторыми современными RDBM, однако реальная важность заключается в том, что ваша модель или система не должны зависеть от скрытых элементов, что обычно верно, даже если ваша RDBMS использует OID для внутренних операций для определенных операций, если только вы не начинаете использовать их для неадминистративных, необслуживаемых задач, вы можете считать, что это не нарушает 1NF.

Answer 4

Сильные стороны реляционных баз данных обусловлены разделением информации на разные таблицы.Один полезный способ просмотра таблиц состоит в том, чтобы сначала идентифицировать в качестве таблиц сущностей те понятия, которые являются относительно постоянными (в вашем случае, возможно, Pizza, Customer, Topping, Deliveryguy).Затем вы думаете об отношениях между ними (в вашем случае, заказ, доставка).Реляционные таблицы связывают воедино таблицы сущностей, используя внешние ключи , указывающие на соответствующие сущности: у Заказа есть внешние ключи для Customer, Pizza, Topping);Доставка имеет внешние ключи для доставки заказа и заказа.И да, отношения могут связывать отношения, а не только сущности.

Только в таком контексте вы можете достичь чего-то вроде нормализации.Бросив кучу атрибутов в одну единственную таблицу, вы не сделаете вашу базу данных реляционной в каком-либо значимом смысле.