Everything_is_bad, просто я с трудом тогда понимаю суть логической структуры
Таблица МАРКА или МАРКА_В_КОЛЛЕКЦИИ
Тут что, тоже получается все обходится одним лишь уникальным ключом?
Но зачем тогда родительские ключи (FK) в зоне ключевых атрибутов у потомка, если потомок итак имеет свой уникальный ключ?
Everything_is_bad, о том и вопрос.
Где и как тогда должен применяться составной ключ?
В каких именно случаях в промежуточную таблицу добавляется её собственный ключ, помимо ключей родителей?
Опять же, если это взаимозаменяемые понятия, тогда не ясна суть миграции родительских ключей в составной ключ потомка.
Сергей П, это требует отдельного внимания.
Но что все таки с нормализацией (3NF) и такими типами данных как дата/время?
Может я в самой сути нормализации чего-то не понял (зависимость одного неключевого столбца от другого)?
Но очевидно что по дате/времени можно вообще информацию из любого другого неключевого столбца получить. Или я ошибаюсь?
Примерно схожая проблема с 1NF и типом данных SET/ENUM.
Сергей П, я видимо не в состоянии вам точно ответить.
Скажу тогда немного иначе - хранить нужно дату/время обновления количествя товаров.
Т.е. произошло событие при котором какое-то количество какого-то товара изменилось и появилась новая запись с датой и временем.
Потом мы в теории можем запросить эти данные (т.е. количество конкретного товара на конкретную дату) и использовать это для анализа динамики.
Сергей П, так пример то мой личный, а не взятый из учебника. И тот факт, что я пришел с вопросом о нормализации БД - этого всего мало для ответа?
Очевидно же, что если бы не было вопроса в голове - его и тут бы не было.
Задача тут проста:
нарушается ли нормализация таким образом, если мы через дату/время можем извлечь конкретное количество и наоборот?
Т.е. вопрос про нормализацию, а не про проектирование в целом.
А дата/время нужны для анализа данных по необходимости.
Однако тут и смущает момент (на мой взгляд), что через дату/время тогда вообще много чего конкретного можно получить и при других полях и другой предметной области. Это все о 3НФ.
alexalexes, да оно как бы понятно, но когда речь идет об учебных примерах, у нас зачастую никакая функциональность не описывается, даже более того - её и не рекомендуют рассматривать в таком контексте
но будем считать, что аналитика предполагается по-умолчанию, чтобы понимать КОГДА и ИЗ ЧЕГО состоял наш складской запас, а также как он менялся с ходом времени
а что, такой простой вариант БД может быть настолько неоднозначно интерпретирован относительно нормализации данных, что без посторонних рассуждений/взглядов не обойтись?
это же учебный вариант, а не какой-то сложный реальный проект
Дмитрий Энтелис, товар поставляется со склада в магазин или наоборот (смотря что происходит), но магазин и склад имеют свой отдельный запас товаров. Только склад хранит, поставляет и забирает, а магазин хранит и продает.
Так нет никакого конкретного места, оно еще неизвестно, как неизвестно даже само наличие товара.
Это же просто абстрактные конструкции, а не конкретные данные.
Тогда уж правильнее:
"место, где может находиться экземпляр товар", верно?
Тогда это можно рассматривать как неключевой атрибут товара с типом enum или вроде того. Но это ладно.
Вопрос то как раз в том, по какой именно причине надо объединять склад с магазином? Я такого в даже очень крупных проектах еще не встречал.
Да, и тот и другой могут хранить товар. Но каждый из них может еще совершать множество других операций и далеко не только над товаром, но и какие-то свои собственные, свойственные только им самим.
Т.е. суть в том, что различий больше, чем одно. А вот общее там только одно.
Исходя из чего именно тогда предпочтение отдается именно единственному схожему признаку? И не было бы даже в таком случае целесообразнее вывести этот признак в отдельную таблицу и добавить её как внешний ключ в две предыдущие?
Akina, имеется ввиду, что склад - это независимая сущность, аналогично и магазин.
И возникает потребность что-то поменять в такой сущности.
Т.е. мы никак товар, как квант, вообще не трогаем. Может даже склад будет совершенно пустой, там нет никаких товаров, но тем не менее, склад, как физический объект, и без всяких товаров обладает своими параметрами.
Я честно говоря, не особо понимаю, что тогда по вашему должен представлять тот же склад относительно товара? Это как выглядит? Склад стал атрибутом товара, т.к. именно товар - это квант?
Или тут просто какая-то путаница между сущностью и экземпляром сущности? Само собой, конкретный экземпляр товара может храниться только на конкретном экземпляре склада, однако это не уровень сущности, на уровне сущностей обязана быть комбинация товара со складом, что и отображено схематически в виде логической структуры.
Akina, а если учитывать, что магазин и склад - это совершенно разные физические объекты с совершенно разными задачи, где общее только то, что кокнретный товар только хранится? Тут всё общее заканчивается.
К тому же у нас есть:
1. Множество магазинов
2. Множество складов
3. Множество товаров
И, соответственно, куча комбинаций экземпляров одной сущности с двумя другими.
То, что "Товар в магазине" и "Товар на складе" - это промежуточные варианты, я изначально указал, тут проблемы нет.
А пересечение как раз в связи между, например, "Товар в магазине" и "Зона поставок".
Зоны разные территориально, в каждой свои магазины и склады.
Условия такие:
1. Множество магазинов
2. Множество складов
3. Разные магазины и разные склады находятся в разных зонах территориально
4. Множество товаров
Т.е. имеем массу комбинаций трех сущностей.
Далее, конкретный магазин и конкретный склад могут быть в одной зоне поставок, а могут и не быть, но минимум 1:1, т.е. магазина без склада нет, как и склада без магазина.
Если проще, то представьте карту России. В разных местах разные магазины и разные склады. Один и тот же магазин может снабжаться разными складами, если они все в одной зоне поставок. Как-то так.
Также отмечу, что у промежуточных таблиц всегда составной PK, т.к. это нотация IDEF1X, и она вынуждает PK писать отдельно, а FK включаются в него как-бы по умолчанию, если они в зоне ключевых атрибутов. Тут ничего прям особенного, только выглядит криво, но суть все равно в составном PK.
Shavadrius, это же учебные цели, а не живой проект.
Именно поэтому интересует теоретической вопрос на тему пересечения между собой двух потомков одного родителя.
А для киоска видимо придется отдельную таблицу заводить, особенно если киоск будет не один, а тоже некоторое множество и каждый со своим ассортиментом.
к тому же неизвестно, попадут ли в лог запросы из графического интерфейса