Стоит ли нормализовать?

Я изучаю базы данных, и я столкнулся с этим вопросом. Если у меня есть таблица product_supply, которая содержит Invoice_Id (pk), Product_Id (pk), Date_Of_Supply, Quantity и Value_Of_Product.Стоит ли нормализовать?

| Invoice_ID | Product_ID | Date_Of_Supply | Quantity | Value_Of_Product | 
    ------------------------------------------------------------------------- 
    | AA111111111|  5001 | 08-07-2013  |  50 |  200$  | 
    | AA111111111|  5002 | 08-07-2013  |  20 |  300$  | 
    | BB222222222|  5003 | 10-09-2013  |  70 |  50$  | 
    | CC333333333|  5004 | 15-10-2013  |  100 |  40$  | 
    | CC333333333|  5005 | 15-10-2013  |  70 |  25$  | 
    | CC333333333|  5006 | 15-10-2013  |  100 |  30$  |

Как мы можем видеть таблицу уже в вопросе 1NF form.My здесь is.In с точки зрения нормализации, если это целесообразно, чтобы нормализовать эту таблицу в виде 2НФ и иметь другую таблицу, например supply_date с Invoice_ID (pk) и Date_Of_Supply или если верхняя таблица в порядке?

| Invoice_ID | Date_Of_Supply | 
    ------------------------------- 
    |AA111111111 | 08-07-2013 | 
    |BB222222222 | 10-09-2013 | 
    |CC333333333 | 15-10-2013 |

источник

2013-06-12 Izanagi

Это определенно стоит нормализовать. Если вам нужно изменить дату поставки, с 1NF, вам нужно обновить несколько записей; с 2NF, вам нужно только обновить одну запись. Также обратите внимание на избыточность данных в 1NF, где дата поставки хранится несколько раз для каждого идентификатора счета. Это не только пространство для отходов, тем сложнее обрабатывать запрос типа «список всех счетов-фактур, которые были поставлены между датами X и Y».

EDIT

Как Роберт Харви отмечает в своих комментариях (что мне потребовалось некоторое время, чтобы понять, потому что я был толстым по какой-то причине), если у вас уже есть таблица, которая имеет одну строку для каждого Invoice_ID (скажем, «таблица счетов»), то вы, вероятно, должны добавить столбец для Date_Of_Supply в эту таблицу, а не создавать новую таблицу.

источник

2013-06-12 03:22:19

Я понимаю вашу логику, но мне кажется, что вы можете просто ввести дату поставки в таблицу счетов-фактур, если в счете нет более одной даты поставки. Вы, кажется, очень уверены в своем ответе, но вы не задали OP никаких вопросов, и использование не кажется очевидным из ограниченной информации, представленной в вопросе. –

@RobertHarvey - Опубликованные данные показывают несколько строк с одинаковой датой для каждого идентификатора счета. Если вторая нормальная форма приводит к описанию таблицы OP, то должно быть, что существует одна дата для ID счета. –

Это означает, что другая таблица не нужна, правильно? –

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

Если существует избыточность, мы должны иметь возможность создать вторую таблицу, которая НЕ включает первичный ключ (Invoice_ID) первого. Основываясь на столбцах не PK в первой таблице (а именно Product_ID, Date_Of_Supply, Quantity и Value_Of_Product), неясно, что любой из них зависит друг от друга.

Как правило, если у вас есть таблица, в которой все столбцы не PK зависят только от столбца PK этой таблицы, она уже находится в 2NF.

источник

2013-06-12 03:33:29

Что это значит без geek-ese? Чтобы он мог просто поставить дату поставки в свою запись заголовка счета (при условии, что он существует)? –

@RobertHarvey _Work работает, чтобы привнести совершенство к грубо задуманной идее машины, которая не только обеспечивала бы обратный реактивный ток для использования в односторонних факультаторах, но также могла бы автоматически синхронизировать кардинальные граммометры. Такая машина является «Turbo-Encabulator ...» _ –

@MattBall: Awesome. Я прекрасно понимаю. Теперь извините меня, пока я отложил шляпу из фольги. Святое дерьмо, на самом деле есть статья [Wikipedia] (http://en.wikipedia.org/wiki/Turboencabulator). –

Стоит ли нормализовать?

ответ

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