Вопрос по проектированию БД

← →
Jaxtor © (2003-05-06 14:00) [0]

Собственно вопрос по проектированию БД. Я создал таблицу с характеристиками товара и для каждой характеристики свою таблицу. Если товар имеет характеристики типа ИЛИ-ИЛИ-ИЛИ... проблем нет. А если И-И-И... возникают проблемы. В первом случае ИЛИ-ИЛИ-ИЛИ... устанавливается реляционная связь между главной и подчиненной таблицами. А во втором реляционная связь не получается. Для связи И-И-И... я собираюсь использовать компоненты типа TDBCheckBox, а для ИЛИ-ИЛИ-ИЛИ... - TDbLookUpComboBox. Как быть?

← →
MsGuns © (2003-05-06 14:04) [1]

Нескромный вопрос- а зачем на каждую характеристику отдельная таблица ? Типа таблица для ед.изм, таблица для признака тары, таблица для наименования, таблица для ставки НДС и т.д. ?

← →
Jaxtor © (2003-05-06 14:14) [2]

Сейчас занимаюсь вводом характеристик для концентраторов и коммутаторов. Да, для скорости UTP(может быть 10, 100, 1000) - одна таблица, для питания(встроенное или внешнее) - одна таблица.

← →
Соловьев © (2003-05-06 14:21) [3]

> . А во втором реляционная связь не получается.

что не получается? конкретнее...

← →
MsGuns © (2003-05-06 14:22) [4]

Т.е. сущность "Характеристика скорости" есть набор некоторых унифицированных представлений (справочник) ? А в карточке товара будет ссылка на ID соотв.представления спр-ка скоростей ?

← →
Jaxtor © (2003-05-06 14:26) [5]

>MsGuns
Да, вроде так.

← →
Соловьев © (2003-05-06 14:32) [6]

не могу догнать что за или-или-или и-и-и это ты обязательные поля? или про NULL?

← →
MOA © (2003-05-06 14:34) [7]

Это разве не связь многие-ко-многим? Вас выручит стандартный метод нормализации - "таблица связи" : ИД_Товара, ИДхарактеристики, Количество на каждый справочник.
Удачи!

← →
Jaxtor © (2003-05-06 14:43) [8]

>не могу догнать что за или-или-или и-и-и это ты обязательные >поля? или про NULL?

Поясняю, хаб может иметь питание или встроенное или внешнее.
Это - ИЛИ-ИЛИ.

А скорость UTP может быть и 10, и 100, и 100, или ,например,
10 и 100. Это - И-И.

← →
Jaxtor © (2003-05-06 14:47) [9]

>MOA Пока мне не ясна Ваша мысль.

← →
Соловьев © (2003-05-06 14:47) [10]

> А скорость UTP может быть и 10, и 100, и 100, или ,например,
>
> 10 и 100. Это - И-И.

дважды повторится id хаба в таблице связи.
id id_dsc 1 1 1 2
где 1 - хаб 1 -10, 2 -100

← →
Jaxtor © (2003-05-06 14:50) [11]

Ну вы согласны, что установить реляционную связь для И-И-И невозможно?

← →
Соловьев © (2003-05-06 14:54) [12]

> Ну вы согласны, что установить реляционную связь для И-И-И
> невозможно?

нет.

← →
Соловьев © (2003-05-06 14:54) [13]

> Ну вы согласны, что установить реляционную связь для И-И-И
> невозможно?

нет. не согласен.

← →
Jaxtor © (2003-05-06 14:55) [14]

>Соловьев Ну и как ее сделать?

← →
Соловьев © (2003-05-06 14:56) [15]

> Соловьев © (06.05.03 14:47)

не устраивает?

← →
Jaxtor © (2003-05-06 15:00) [16]

CheckBox1 - отмечен 1
CheckBox2 - неотмечен 0
CheckBox3 - отмечен 1

2^2*1+2^1*0+2^0*1=4+0+1=5?

5 находится в главной таблице.

← →
MsGuns © (2003-05-06 15:03) [17]

Слушай, а может ты просто перемудрил ? Почему бы не решить твое "многообразие" характеристик просто группировкой ? Но группы сделать в виде дерева. Т.е.
Ур.1 Сетевое оборудование
Ур.2 Хабы
Ур.3 Хабы UTP,100
Хабы UTP,10
Хабы BNC,10
Хабы BNC+UTP,10
Концентраторы
...

Хотя, конечно, если надо выбрать все с UTP или с 10.. 8(
Но, в конце концов наиболее типичные характеристики можно вывести в отдельную сущность.
Кстати, для хабов и им подобных кол-во портов, например, я бы вообще не выносил, а влепил бы в довесок к наименованию

← →
MOA © (2003-05-06 15:04) [18]

1. Есть таблица
Tovar: ID_Tovar, Name_Tovar PK(ID_Tovar)
1 Хаб 1
2 Хаб 2
2. Есть справочники
Sprav1: ID_Prop, NameProp PK(ID_Prop)
1 Скорость 10
2 Скорость 100

Sprav2: ID_Prop, NameProp PK(ID_Prop)
1 Питание внешнее
2 Питание внутреннее
Sprav3: ID_Prop, NameProp PK(ID_Prop)
1 Вес
3. Есть таблицы связей
Link1: ID_Tovar, ID_Prop PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop)
1 1
1 2
2 2

Link2: ID_Tovar, ID_Prop PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop), UNIQUE INDEX CONSTRAINT ID_Tovar
1 1
2 1

Link3: ID_Tovar, ID_Prop, Kolvo PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop), UNIQUE INDEX CONSTRAINT ID_Tovar
1 1 10
2 1 0.5

Всё ограничения обеспечиваются. Конечно, возможны вариации (ну, напрмер, хранить все св-ва в одном или немногих справочниках). Важно тут именно наличе таблиц связи и для "исключительно или" - наличие уникального ограничения на ID_Tovar. Выгода архитектуры - Вам будет достаточно легко добавить свойство. Конечно, неотьемлимые атрибуты лучше хранить прямо в справочнике товара.
Удачи!

← →
Соловьев © (2003-05-06 15:04) [19]

что-то не догоню...
что 5? 5 раз в таблице связи повторится id? ну и что?

← →
Jaxtor © (2003-05-06 15:07) [20]

id id_dsc 1 1 1 2
Да, вроде начинаю понимать...
>id_dsc
dsc - что это?

← →
Jaxtor © (2003-05-06 15:10) [21]

Ладно буду думать... Через некоторое время дельта t сообщу, что
придумал.

← →
Соловьев © (2003-05-06 15:11) [22]

> dsc - что это?

description - характеристика

← →
Jaxtor © (2003-05-06 15:13) [23]

Соловьев> id-это PK, а у тебя он имеет 2 значения-"1".

← →
Соловьев © (2003-05-06 15:17) [24]

> id-это PK, а у тебя он имеет 2 значения-"1".

нет не PK. Я же сказал - это таблица связи... И кто тебе сказал,что id - это число обязателько? его можно генерить из имени устройства+код:
hub100
hub101
lan156
...

← →
Jaxtor © (2003-05-06 15:19) [25]

>MOA Спасибо, но пока что трудновато мне в это вникнуть...

>MOA © (06.05.03 15:04)

И сколько же подобных справочников придется создать, чтобы описать всевозможные характеристики - 10, 100, 1000 ? А если завтра поступят комплектующие с принципиально новой характеристикой - добавлять новую таблицу ?

ИМХО, нормализация ради нормализации.

>И сколько же подобных справочников придется создать
В предельном случае - ровно один + триггер для бизнес - ограничений. Человек же сказал, что справочники у него уже готовы. Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.
Удачи!

А как такой вариант:

Goods(Товары)
------------
g_id int (PK)
g_Name varchar

TechParNames(Наименования характеристик)
----------------------------------------
tp_id int (PK)
tp_Name varchar

TechPar(Характеристики)
-----------------------
g_id int (FK Goods.g_id)
tp_id int (FK TechParNames.tp_id)
tp_Value varchar

Можно для одного товара иметь сколько угодно характеристик одного типа. Заодно появляется возможность сравнивать разные товары по характеристикам.

>MOA © (06.05.03 15:39)
>Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.

Согласен. Реплика MsGuns © (06.05.03 15:28)
, действительно, не по адресу.

>vuk © (06.05.03 15:40)
>Можно для одного товара иметь сколько угодно характеристик одного типа

Неужели ? Т.е. один товар может иметь ДВЕ ОДНОТИПНЫЕ характеристики, например, форма корпуса ? TechPar этого явно не "вытянет".

Аааааааа..... Табла-то без ключа ! Теперь понятно.

>Теперь понятно.
Ну дык. :o) Хотя, по большому счету суррогатный ключик там не помешает. Для обеспечения нормального редактирования каждой записи. То есть:

TechPar(Характеристики)
-----------------------
row_id int (PK)
g_id int (FK Goods.g_id)
tp_id int (FK TechParNames.tp_id)
tp_Value varchar

Если отталкиваться от характеристик, например хабов,
я бы сделал в справочнике характеристик три строки:

ID NAME
1 10
2 10/100
3 10/100/1000

Это проще и гораздо наглядней чем действовать в угоду нормализации.
Можете меня поругать. :))

Есть справочник характеристик, характеристика ни с того ни с сего меняться не может, как и справочник.

> Есть справочник характеристик, характеристика ни с того
> ни с сего меняться не может, как и справочник

та даже если надо поменять не стого-сего... Нормализацию и придумали чтобы избавиться от аномалий обновления...

Я не против нормализации! Я против бездумного ее применения. :)
Зачем городить огород из-за лишней строчки в справочнике?
А из вопросов автора ветки мне кажется дело обстоит именно так.

Вопрос по проектированию БД Найти похожие ветки