Проблема в понимании 2НФ

[melnikoff]

Здравствуйте! У меня проблема в понимании 2НФ.
Есть 5 таблиц БД:

Покупатель..............Поставщик.................Товар...................Журнал покупок................Журнал поставок
id покупателя (PK)......id поставщика (PK)........id товара (PK).........id покупателя (FK) (PK).........id поставщика (FK) (PK)
ФИО........................Наименование.............Наименование........Дата (PK)..........................Дата (PK)
email.......................Адрес........................Цена....................id товара (FK) (PK)...............id товара (FK) (PK)
........................................................................................Количество.......................Количество

В тексте статьи пишут: "Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика). То есть таблица не находится в 2НФ."
Почему поле "Количество" не зависит от поля "id поставщика"? А если другой поставщик в ту же дату привезет тот же товар, но другого количества? Получается, что поле Количество должно зависеть от всех полей таблицы, а значит данная таблица уже находится в 2НФ. Где я ошибаюсь?

[Pphantom]

Тема перемещена из форума «Компьютерные сети и Web-технологии» в форум «Карантин»
по следующим причинам:

- наберите в текстовом виде текст с картинки. В общем-то таблицы тоже желательно (но уже не обязательно);
- сформулируйте вопрос внятно (в данный момент ответ "по условию задачи" кажется вполне очевидным).

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

[Pphantom]

Тема перемещена из форума «Карантин» в форум «Computer Science»

[rockclimber]

melnikoff в сообщении #1287531 писал(а):

Почему поле "Количество" не зависит от поля "id поставщика"?

А схему можете нарисовать? Сейчас у меня на телефоне все расползается, непонятно, в какой таблице какое поле находится. И проверьте, правильно ли вы переписали текст, потому что сейчас у вас поле "Количество" таки зависит от id поставщика (если я правильно разобрался в этом расползающемся тексте).

[melnikoff]

Схемы рисовать тут не умею, но могу показать скрин статьи (кликабельно):

Сама статья.

[rockclimber]

melnikoff в сообщении #1287658 писал(а):

Сама статья.

Глянул статью по диагонали - меня терзают смутные сомнения, стоит ли ее вообще читать. Как-то запутанно написано. Чуть попозже присмотрюсь повнимательнее.

Для рисования ER диаграмм могу посоветовать lucidchart.com или erdplus.com (ну это так, на будущее, вдруг пригодится).

[rockclimber]

Да, ерунда какая-то. В концептуальной модели покупатели покупают товары у поставщиков, при этом покупатель и поставщик вообще никак не связаны. Причем этот грубый ляп сделан только для того, чтобы потом показать, что такое 2 НФ, причем показать криво и не с той стороны. В той же Википедии нормальные формы и то понятнее объяснены.
Ну а вообще, К. Дж. Дейт, "Введение в системы баз данных" - неустаревающая классика. После нее точно вопросов не останется.

[melnikoff]

rockclimber в сообщении #1287707 писал(а):

Да, ерунда какая-то. В концептуальной модели покупатели покупают товары у поставщиков, при этом покупатель и поставщик вообще никак не связаны.

В модели вроде как покупатели покупают товары у магазина, в который эти товары поставляют поставщики. Или вы хотите сказать, что неплохо было бы понимать каким поставщиком поставлен товар, который купил покупатель? А в данной концептуальной модели мы это отследить не сможем?
Мне всё-таки интересно, таблица Журнал поставок (с составным ключом из трех полей: id поставщика, Дата и id товара) находится в 2НФ? На мой взгляд она находится даже в 3НФ, так как неключевое поле одно и оно функционально полно зависит от составного ключа и нетранзитивно зависит от составного ключа (неключевое поле-то одно).

[rockclimber]

В общем случае все зависит от задачи, которую вы решаете. В одном случае ваша таблица будет находиться в одной форме, в другом случае - в другой. Например, вам надо хранить адреса в таблице. Если это просто программа - записная книжка, вам достаточно сделать адрес одним атрибутом. Если у вас задача - вести огромную базу клиентов, и вам для оптимизации процессов важно иметь возможность выяснить (извлечь соответствующую информацию из базы), кто из клиентов живет на одной улице или в одном доме, вам надо будет сделать город, улицу, дом и квартиру как минимум отдельными атрибутами, а то и сущностями (таблицами). А если вы делаете БД кадастрового учета, там даже квартира будет отдельной сущностью с большим числом атрибутов, а может быть даже и несколько сущностей понадобится.
Что касается вашего примера, там с назначением этой БД не все ясно. В интернет-магазине может вообще нет надобности знать, товар какого именно поставщика купил покупатель. А на практике, насколько я знаю, идентичный товар разных поставщиков с точки хрения хранения в БД - это разные товары (то есть это будут две разные строки в таблице товаров), и если вы знаете, что купил покупатель, то вы автоматически знаете, у кого.

[melnikoff]

Всё же вопрос относительно таблицы "Журнал поставок" остается. Она находится согласно описанной концептуальной модели в 2НФ? А в 3НФ? Тогда какая мотивация отделять от таблицы "Журнал поставок" таблицу "Поставки"?

[rockclimber]

melnikoff в сообщении #1287738 писал(а):

Всё же вопрос относительно таблицы "Журнал поставок" остается. Она находится согласно описанной концептуальной модели в 2НФ? А в 3НФ?

Максимум в первой. Смотрите тут какая штука: если мы посмотрим на таблицу "Журнал поставок", то там первичный ключ - это (id поставщика, id товара, дата), что означает, что один поставщик может продать каждый товар только один раз за день - или это не первичный ключ (тут можно пуститься в дебри и предположить, что в реальной системе мы будем фиксировать время поставки с точностью до микросекунд, но это всего лишь немного уменьшит степень маразма и вероятность коллизий, а не уберет их полностью). И даже если мы добавим к ключу поле "Количество", ограничение останется. Два клиента не смогут одновременно купить одинаковое количество одного и того же товара у одного поставщика. Обычно эта проблема решается введением сущности "заказ" и добавлением атрибута "номер заказа", который и становится (первичным) ключом. А пока ключей нет вообще.

melnikoff в сообщении #1287738 писал(а):

Тогда какая мотивация отделять от таблицы "Журнал поставок" таблицу "Поставки"?

Надо спрашивать у авторов статьи, я тут не могу ничего сказать. Вообще, при рассмотрении вопросов нормализации возможны два подхода:
1. Как в Википедии, книге Дейта и многих других местах, когда сначала дается одна большая таблица с данными. Вы определяете, где в этих данных атрибуты, кортежи и ключи, а потом последовательно приводите сначала к первой форме, потом первую ко второй и так далее.
2. Как в той статье. Вы делаете концептуальную модель по словесному описанию процесса. У вас нет никаких данных вообще, но на основании "общей бытовой" или бизнес-логики вы делаете предположения о том, какие данные могут быть, а какие не могут быть. Например, вряд ли человек, занесенный в базу как "клиент", станет товаром для продажи - рабство вроде как запретили уже, соответственно, вам не надо готовить вашу систему к такому повороту событий. А вот ситуация "два клиента хотят одновременно купить одинаковое количество одного и того же товара у одного поставщика" возможна, и вы должны это предусмотреть на этапе проектирования. Обычно, если вы все делаете правильно, на выходе с этапа концептуального проектирования у вас будет уже минимум 3НФ. Моделировать сначала полуготовую схему (в 2НФ), а потом доводить ее до ума с помощью ломика и какой-то матери, имхо, бессмысленно даже в учебных целях.

[melnikoff]

rockclimber в сообщении #1287814 писал(а):

Максимум в первой. Смотрите тут какая штука: если мы посмотрим на таблицу "Журнал поставок", то там первичный ключ - это (id поставщика, id товара, дата), что означает, что один поставщик может продать каждый товар только один раз за день - или это не первичный ключ.

Дело в том, что обычно поставщики поставляют товар в магазин довольно редко. Поэтому допустим, что один поставщик никогда не делает более одной поставки в одну дату. Тогда составной ключ (id поставщика, id товара, дата) функционально полно определяет поле Количество, что соответствует 2НФ. Ну и автоматически таблица находится в 3НФ. Правильно? В этом случае особого смысла выделять таблицу Поставки нет?

[Mental]

melnikoff в сообщении #1287828 писал(а):

Дело в том, что обычно поставщики поставляют товар в магазин довольно редко.

Если бизнес небольшой, а товар ходовой, то могут и два и три раза подвозить.

melnikoff в сообщении #1287531 писал(а):

Получается, что поле Количество должно зависеть от всех полей таблицы, а значит данная таблица уже находится в 2НФ. Где я ошибаюсь?

Она не находится во 2НФ. Если один и тот же поставщик привезёт один и тот же товар в один и тот же день, то данные просуммируются. Т.е. в таблице "Журнал поставок" будет утеряна информация об одной поставке.

А вот дальше у них с таблицей "Цены" ошибка: два поставщика в один и тот же день могут привести товар по различной цене, а это там не предусмотрено. Обычно в таких случаях вводят понятие "Средняя цена".

[rockclimber]

Mental в сообщении #1287872 писал(а):

Если один и тот же поставщик привезёт один и тот же товар в один и тот же день, то данные просуммируются.

Это в какой СУБД такой беспредел? В нормальной должно быть выброшено исключение из-за нарушения ограничения целостности.

Mental в сообщении #1287872 писал(а):

А вот дальше у них с таблицей "Цены" ошибка

Да там вся схема одна большая ошибка. Я пытаюсь придумать ТСу вменяемый ответ, открываю ту статью и у меня кровь из глаз идет.

melnikoff в сообщении #1287828 писал(а):

Тогда составной ключ (id поставщика, id товара, дата) функционально полно определяет поле Количество, что соответствует 2НФ. Ну и автоматически таблица находится в 3НФ. Правильно?

У них там написано

Цитата:

Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика).

прямо под схемой, где в таблице "Журнал поставок" есть поле "id поставщика". В каком месте они накосячили? Хотели сказать, зависит от поставщика? Или они хотели написать это про таблицу "Журнал покупок"? А "поле Поставщика" - это "id поставщика"? В общем, я не знаю, какие у них там формы. 2-я более-менее просматривается, и можно даже подобрать такую трактовку их "схемы", при которой там и третья будет.

[melnikoff]

rockclimber в сообщении #1287906 писал(а):

2-я более-менее просматривается, и можно даже подобрать такую трактовку их "схемы", при которой там и третья будет.

То есть, если трактовка такая: Заранее известно, что один поставщик никогда не делает более одной поставки в магазин в одну дату?
Тогда таблица "Журнал поставок" будет находиться в 2НФ и 3НФ?