Проектирование БД

← →
Vlad2 (2002-08-01 06:46) [0]

Помогите, пожалуйста, разобраться.
В БД "транспорт" существуют таблицы:
- ремонты S1(idState, ...);
- заявки S2(idState, ...);
- постоянные работы S3(idState, ...);
- состояние автомашин (а/м) S0(idCar, idSate, idType, ...);
По условиям производства, каждая а/м должна находиться в каком л.б. состоянии из S1, S2, S3. Это состояние нужно хранить в S0. Т.е. S0.idState может принимать значения:
либо S1.idSate, либо S2.idState, либо S3.idState; это определяется значением S0.idType.

Назовем такую модель M. Говорят, что она плоха и предлагают:

модель M1:
объединить S1, S2, S3 в одну таблицу (супертип) ST(idType, idState, ...), где PK is {idType, idState}. Проблем нет,
но S1, S2, S3 - существенно разные, => в ST множество пустых значений.

модель M2:
разделить S0 на таблицы S01, S02, S03 соответственно для состояний ремонтов, заявок и пост. работ. Однако, такое разделение повлечет такие же разделения в следующих структурах, а в них используются уже другие подтипы и процесс станет неуправляемым.

Вопрос: Чем плоха модель M ? Мне кажется, только тем, что ссылочная целостность поддерживается логикой манипулирования данными. Я гарантирую ссылочная целостность легальными операциями, хотя другие операции могут ее нарушить.
Или я не прав ?

← →
ЮЮ (2002-08-01 08:19) [1]

Можно уточнить?
- ремонты S1(idState, ...);
- заявки S2(idState, ...);
- постоянные работы S3(idState, ...);
Какое отношение между S1-S0,S2-S0,S3-S0 ?
Имеют они отношение к конкретмому состоянию
S0(idCar, idSate, idType, ...) , т.е. дополняют информацию для каждого состояния каждой машины (отношение 0..1-1), или являются как бы справочниками и повторяются для разных состояний разных машин (отношение 1-N), ?

← →
Vlad2 (2002-08-01 08:59) [2]

S1, S2, S3 - справочники.
В модели M поле S0.idState может хранить значение ID ремонта,
ID заявки, ID постоянной работы, как альтернативные значения.
При этом, значение поля S0.idType выполняет роль дискриминатора, или определителя по какому справочнику интерпретировать значение
S0.idState.
Меня, конечно, смущает такая схема, но и привлекает. А как умные люди делают ?

← →
Vlad2 (2002-08-01 09:08) [3]

Вдогонку
>ЮЮ
"Какое отношение между S1-S0,S2-S0,S3-S0 ?"
Вы сразу схватили суть: декларировать эти связи в модели M нельзя.

← →
ЮЮ (2002-08-01 09:27) [4]

Не знаю, как умные, но я применял оба варианта:

модель M1:
объединить S1, S2, S3 в одну таблицу (только это вряд ли можно назвать супертипом) ST(idType, idState, ...), но PK только по idType. Соответственно, в ST нет idState. To, что S1, S2, S3 - существенно разные и в ST множество пустых значений не столь важно, ведь это справочники и в них не так много записей. А редакторы справочников для разных idState могут быть разные.

модель M1*:
Имеем S0(idType,...) (суперкласс, где ... - общие для всех наследников). В моем случае общего ничего не было, и там был один ID :-). Наследники Sn(idState, ...) представлены отдельными таблицами. ID имеет сквозную нумерацию.
idState уже нет нигде. Но в этой правильнай с точки OOП модели трудно посредством SQL-запроса выявить с каким наследником мы имеем дело. Поэтому, на всякий случай добавили в S0(idType, idState, ...),хотя и не дело суперклассу знать, кто от него наследуется :-)

← →
Dem (2002-08-01 09:28) [5]

да изначальная модель в принципе неплоха)))
только в s0 надо перетащить максимально общую информацию из всех остальных таблиц...как вариант - возможно трактовка одного поля п-разному в зависимости от типа idtype - главное чтобы типы данных в столбцах совпадали...в принципе на уровне логики это нетрудно сделать..

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

реально обычно работа идет с основной базой(всякие просмотры, перевод из состояния в состояние..и прочее - а информация из справочных - требуется как "дополнительная" по специальному запросу.

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

← →
Vlad2 (2002-08-01 10:17) [6]

Спасибо, ребята !
1. to Dem
"только в s0 надо перетащить максимально общую информацию из всех остальных"
Верно, в S0 перетащены общие поля.
2. "объединить S1, S2, S3 в одну таблицу" (из ЮЮ) нежелательно,
потому, что таблица "заявки" пополняется каждый день (хотя БДанных безразлично, справочник это или оперативные данные).
А самое главное, S1, S2, S3, - разные сущности, поэтому где-то
все равно придется определять имя таблицы, - что-то вроде "динамической" связи, да простит меня Codd.
Итак, я понял так, что:
1. Существенных возражений против использования модели M нет.
2. Только хотелось бы услышать мнение про ссылочную целостность, ведь в S0 можно установить отсутствующие состояния, которых нет ни в S1, ни в S2, ни в S3.

← →
Sergey13 (2002-08-01 11:07) [7]

2Vlad2 (01.08.02 10:17)
У меня была такая же проблема. Работал по схеме М. Из-за необъявленой ссылочной целостности рано или поздно нарвешься на нарушение этой самой целостности. Я решил проблему "в лоб" - может и не лучший способ, но о проблемах с данными в задаче я забыл. Суть - добавил поля в S0(в твоем случае) S1_IdState, S2_IdState, S3_IdState(на них повесил те самые форин кеи) и оставил IdState которое заполняется тригером неNULLовым Sx_IdState. Т.е. заменил IdType на три поля. Нормализованной эту таблицу не назовешь, но ... "и волки целы, и овцы сыты" 8-) Такая схема, к тому же, упростила(частично) и работу с ней.

← →
Vlad2 (2002-08-01 11:19) [8]

to Sergey13
Да, это решение, тем более, что таблиц типа S[n] всего 4
(в реальной БД), и по-жизни их и не будет более 5-ти, 6-ти.
А потенциальна опасность не даст покоя.
Мне только непонятна роль SxIdState: если я правильно понял, он дублирует одно из значений S1_IdState, S2_IdState, S3_IdState ?

← →
Sergey13 (2002-08-01 11:58) [9]

2Vlad2 (01.08.02 11:19)
Да. В принципе можно обойтись и без него, но оно здорово облегчает жизнь.

← →
Vlad2 (2002-08-01 12:09) [10]

Спасибо Всем !

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