ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / нормализация продукт-параметр-значение
7 сообщений из 7, страница 1 из 1
нормализация продукт-параметр-значение
    #33049544
баззззлайтер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
баззззлайтер
Гость
вопрос теоретический:

Склад товаров, каждой группе продукции сопоставлены параметры. У каждой номенклатурной единицы указаны все параметры её группы.

группы:
сапоги
бугорчатая тара для яиц

параметры:
у группы сапоги:
размер (перечисление)
инвентарный номер (строка)
у группы бугорчатая тара для яиц
упаковка (перечисление)
масса единицы (целое число)

склад:
сапоги р-р 45, ИН12345
сапоги р-р 43, ИН54321
бугорчатая тара для яиц 1 палета, 100 кг.

на уровне таблиц бд, склад описывается двумя таблицами:
table Product(idProduct, idGroup, ...)
table ProductParam(idProduct,idParam,Num_Val,String_Val,Bool_Val...)
-- значение параметра пишется в поле, соответвующее типу параметра
-- строковый в String_Val, целочисленный в Num_Val

ВОПРОС:если завести сущность "значение парамета" и в ProductParam прописывать ссылку на это значене - приблизит ли это структуру бд к какой-нибудь нормальной форме?

т.е.
table Product(idProduct, idGroup, ...)
table ProductParam(idProduct,idValue)
table ParamValue(idValue,idGroup,idParam,Num_Val,String_Val,Bool_Val..)
является ли более нормализованной структурой по сравнению с предыдущей?
является ли менее нормализованной структурой по сравнению с предыдущей?

Определённо, такое схлопывание данных приведёт к уменьшению размера бд, т.к. количество перечислимых параметров с малым числом возможных значений превышает число строковых параметров, которые придётся хранить каждую под своим idValue. В полтора раза примерно. Впрочем, в теории нормальных форм понятие "объём данных" вообще отсутствует, сколько я помню.

IMHO, RTFM href=, "а вот у нас был случай" - с благодарностью принимаются.
...
Рейтинг: 0 / 0
05.05.2005, 09:19
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33050501
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Давайте сначала уточним логику. Фактически вы используете шаблон со словарем параметров.

Собственно словарь, минимально :
Код: plaintext
1.
2.
Параметр (парИД, имя, типЗначения,...) 
ТипПродукции (типПрИД, имя, ...)
ПараметрТипа (парИД, типПрИД)  - параметр определен для типа продукции

Данные, базовый вариант :
Код: plaintext
1.
Продукция (продИД,...)
ЗначениеПараметраПрод(продИД, парИД,  значениеСтр, значениеЧисло, ...)
Если так то вопрос касается изменения структуры ЗначениеПараметраПрод на, вариант 1 :
Код: plaintext
1.
ЗначениеПараметраПрод(продИД, парИД,  значениеИД)
ЗначениеПараметра(значениеИД, значениеСтр, значениеЧисло, ...)
или, вариант 2:
Код: plaintext
1.
2.
3.
ЗначениеПараметраПрод(продИД, парИД,  значениеСтрИД, значениеЧислоИД,...)
ЗначениеПараметраСтр(значениеИД, значение)
ЗначениеПараметраЧисло(значениеИД, значение)
...
или комбинация этих вариантов, например вариант 2 для строковых, длинных параметров и базовый вариант для остальных.

С точки зрения РМД вы по-моему вы правы - по уровню нормализации все три варианта одинаковы и соответствуют одинаковому набору критериев нормализации. С практической конечно все зависит от задачи.

Не совсем понял, для чего в вашем примере в
table ParamValue(idValue,idGroup,idParam,Num_Val,String_Val,Bool_Val..)
служат idGroup,idParam.
...
Рейтинг: 0 / 0
05.05.2005, 13:51
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33051391
баззззлайтер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
баззззлайтер
Гость
2 ModelR :
- вариант 1. Всмысле, то, что параметр может быть разного типа - поддерживается всё равно одной таблицей. Разные типы параметров по разным таблицам растаскивать в голову не приходило. Давайте считать это отдельным вопросом, как ещё-более-продвинутое-уплотнение данных, которое можно применять уже после того как решится - хранить данные в ЗначениеПараметраПрод или отдельным справочником.
- (ParamValue.idGroup,ParamValue.idParam) - внешний ключ на таблицу Param.
В которой эта пара полей является первичным ключом. (idParam уникален только внутри группы, параметры разных групп никак между собой не связаны)
...
Рейтинг: 0 / 0
05.05.2005, 18:23
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33052047
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
баззззлайтер2 ModelR :
- (ParamValue.idGroup,ParamValue.idParam) - внешний ключ на таблицу Param.
В которой эта пара полей является первичным ключом. (idParam уникален только внутри группы, параметры разных групп никак между собой не связаны) Ясно. По опыту если idParam - суррогатный ключ (не несущий бизнес смысла), то для программной реализации удобнее иметь его глобально уникальным по базе а не возиться с отдельной нумерацией в пределах каждой группы.

Не забудьте еще такой момент, не могут ли у вас некоторые параметры быть ссылками на объекты базы данных, например параметр "Страна происхождения" - ссылка на справочник стран.
...
Рейтинг: 0 / 0
06.05.2005, 10:18
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33052105
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Ну если порыть и глубже, то можно вспомнить и про значения по умолчанию, которые и могут быть этими объектами, а потом Вам еще и захочется сделать наследование, чтобы не описывать каждую позицию по 10 раз (например, шуруп->Шуруп оцинкованный для бетона->и далее по ветви наследования) Кстати, это классическая "велосипедная" тема: настраиваемый справочник номенклатурных позиций.
...
Рейтинг: 0 / 0
06.05.2005, 10:40
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33052120
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Кстати,как сделаете ссылки, начнется пляска с бубнами по поводу ссылочной целостности и пойдет тема "база данных в базе данных" -0);
...
Рейтинг: 0 / 0
06.05.2005, 10:44
| Ответить | Цитировать | Написать  
нормализация продукт-параметр-значение
    #33053533
баззззлайтер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
баззззлайтер
Гость
Спасибо ответившим!

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

- типы данных, которые могут хранить параметры - да, это головняк, но опять же, к теме обсуждения отношения он не имеет.

Позволю повториться:
выбор между схемами:

Таблица(id_продукт, id_параметр, значение_параметра)
и
Таблица(id_продукт, id_значения_параметра)
ТаблицаЗначений(id_значения_параметра,id_параметр,значение_параметра)

в обоих случаях "значение_параметра" это некий набор полей.

? регламентируется ли теорией нормальных форм или ещё какой теорией?
? чреват ли граблями (с перекосом планов запроса хп, например)?

простите, а что такое классическая "велосипедная" тема ?
...
Рейтинг: 0 / 0
06.05.2005, 18:25
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / нормализация продукт-параметр-значение
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]