Форум: "Базы";
Текущий архив: 2003.05.26;
Скачать: [xml.tar.bz2];
Вниз
Вопрос по проектированию БД Найти похожие ветки
← →
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 Спасибо, но пока что трудновато мне в это вникнуть...
← →
MsGuns (2003-05-06 15:28) [26]>MOA © (06.05.03 15:04)
И сколько же подобных справочников придется создать, чтобы описать всевозможные характеристики - 10, 100, 1000 ? А если завтра поступят комплектующие с принципиально новой характеристикой - добавлять новую таблицу ?
ИМХО, нормализация ради нормализации.
← →
MOA (2003-05-06 15:39) [27]>И сколько же подобных справочников придется создать
В предельном случае - ровно один + триггер для бизнес - ограничений. Человек же сказал, что справочники у него уже готовы. Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.
Удачи!
← →
vuk (2003-05-06 15:40) [28]А как такой вариант:
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
Можно для одного товара иметь сколько угодно характеристик одного типа. Заодно появляется возможность сравнивать разные товары по характеристикам.
← →
MsGuns (2003-05-06 15:54) [29]>MOA © (06.05.03 15:39)
>Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.
Согласен. Реплика MsGuns © (06.05.03 15:28)
, действительно, не по адресу.
← →
MsGuns (2003-05-06 15:59) [30]>vuk © (06.05.03 15:40)
>Можно для одного товара иметь сколько угодно характеристик одного типа
Неужели ? Т.е. один товар может иметь ДВЕ ОДНОТИПНЫЕ характеристики, например, форма корпуса ? TechPar этого явно не "вытянет".
Аааааааа..... Табла-то без ключа ! Теперь понятно.
← →
vuk (2003-05-06 16:10) [31]>Теперь понятно.
Ну дык. :o) Хотя, по большому счету суррогатный ключик там не помешает. Для обеспечения нормального редактирования каждой записи. То есть:
TechPar(Характеристики)
-----------------------
row_id int (PK)
g_id int (FK Goods.g_id)
tp_id int (FK TechParNames.tp_id)
tp_Value varchar
← →
NickBat (2003-05-06 17:50) [32]Если отталкиваться от характеристик, например хабов,
я бы сделал в справочнике характеристик три строки:
ID NAME
1 10
2 10/100
3 10/100/1000
Это проще и гораздо наглядней чем действовать в угоду нормализации.
Можете меня поругать. :))
← →
Соловьев (2003-05-06 17:56) [33]
> NickBat © (06.05.03 17:50)
если надо будет перевести с 100 на 101, например, то прийдется много чего делать...
← →
NickBat (2003-05-06 18:09) [34]Есть справочник характеристик, характеристика ни с того ни с сего меняться не может, как и справочник.
← →
Соловьев (2003-05-06 18:13) [35]
> Есть справочник характеристик, характеристика ни с того
> ни с сего меняться не может, как и справочник
та даже если надо поменять не стого-сего... Нормализацию и придумали чтобы избавиться от аномалий обновления...
← →
NickBat (2003-05-06 18:51) [36]Я не против нормализации! Я против бездумного ее применения. :)
Зачем городить огород из-за лишней строчки в справочнике?
А из вопросов автора ветки мне кажется дело обстоит именно так.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.05.26;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.008 c