Решил что лучше новый топик организовать: а то Тенцер както не активно обсуждают
Пытаюсь создать схему данных для хранения данных по материалам и оборудованию. Параметры заранее неизвесны и описанию не поддаются
начал с модели Тенцера, но после двух дневных размышлений пришел к такой схеме данных (см. приложение)
Небольшое пояснение:
На основании изменений в таблицах OB_MAT и PARAMS тригеры модифицируют таблицы ZP_***. Т.е. при добавление новой записи в OB_MAT создаем записи в таблицах ZP_*** в зависимости от того в каком разделе вводиться такие и записи. При добавлении изменении удалении параметров в PARAMS производим соответствующие манипуляции в таблицах ZP_*** и т.д.

Вопросов вобщем то два:
1. Кто видит какие минусы в такой схеме
2. Как построить вьюшку чтобы объединить все параметры по объекту
собрать все NAME_P и VALUES из всех таблиц ZP_***

locky
например, если собрать все 3 (в данном случае) типа параметров в одну
таблицу - можно сэкономить на накладных расходах.
Такой вариант у меня был, но мне кажется в нем минусов еще больше
во первых в таблице будет много полей VALUE_STR, VALUE_NUM, VALUE_DAT и т.д. 3 это только пример - заполненым из которых будет всегда одно.
Сейчас я думаю над организзацией хранения типа BLOB в котором хранить описание в произвольном виде например сканированную страницу из журнала. А BLOB таблицу желательно хранить в другом табличном пространстве с большим размером блока. И кроме того проблема всеравно остается как представить такую таблицу с множеством полей в виде
КОД_ОБЪЕКТА ИМЯ_ПАРАМЕТРА ЗНАЧЕНИЕ_ПАРАМЕТРА
чтобы дать пользователю все параметры вместе в удобном виде.

locky
Аналогично, если оперировать не названием параметра (name_p) а кодом
параметра.

С этим согласен, но имя я думаю имя поля все равно оставить надо.

locky
А что за проблема - написать join? У Тенцера вроде как описано было?


Просьба с этого места поподробней, как из структуры см. вложение
получить
ID_OM VAL.NAME VALUE

В статье Тенцера такого примера не видел, и что-то не представляю как это реализовать.

Можно и поподробней:
Итак фирма занимается проектированием и строительством судов
при постройке судна как вы понимаете используются сотни тысяч видов материалов и оборудования. Начиная с болтов и листовой стали и кончая системами развлечений.
Все это оборудование и материалы проходит некоторые этапы утверждения, доставки установки, для этого его для начала необходимо описать, а так как описания параметров у болта, кабеля, телевизора, доски и т.д и т.п. разные то хочу организовать универсальный справочник где сам пользователь может описать набор параметров для определенной категории оборудования и ввести эти данные.
ModelR
1. Если Материал принадлежит не более одной Категории, то КатегорияМатериала тоже может рассматриваться как параметр.
Можно и так. категория может быть только одна, но я строю так потому что таблица категорий это расширенный справочник Быстрей всего ЕСКД или его иностранный аналог, пользователи уже привыкли им пользоваться и идти от раздела...

ModelR
2. Некоторые параметры могут иметь в качестве значения ссылку на справочник (например стандарты) или на Материал.
Точно, но я предпологаю что это просто числовой параметр, а откуда из какого справочника брать или просто значение вводить это не так важно.
ModelR
3. ZP_*** для параметра-ссылки на самом деле задает бинарную связь. Некотоые связи могут быть типа N:N, т.е. вполне симметричны.
Теоретически да но, я думаю это будет ненужно, хватит связи один ко многим
один материал-оборудование --> много параметров

ModelR
4.Категории не обязательно образуют дерево (лес), возможно множественное наследование.
Нет множественного наследования нет обычный "деревянный" классификатор

ModelR
Еще: непонятно, почему ZP_*** имеют внешний ключ на Материалы, но не имеют на Параметры.
Я пока предпологаю таблицу параметры использовать как хранилище шаблонов
параметров, при добавлении нового материала тригер берет необходимые параметры этого материала и добавляет в соответствующие таблицы ZP_***
Если нужно обработать какойто вид параметра то я и в запросе свяжу, а так пока невижу смысла.

ModelRРечь о другом. Если в факте

Материал ="Двигатель 1", параметр ="Тип топлива", значение = "АИ 92"

признать "АИ 92" ссылкой на материал, то этот факт можно рассматривать как экземпляр связи со схемой

РазрешенноеТопливо (
ГдеПрименяется: Материал категория Двигатель
ЧтоПрименяется: Материал категория Топливо)
UNIQUE (ГдеПрименяется, ЧтоПрименяется)

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

ModelR
Еще вспомнил:
5.Исполнения. Каждое исполнение - это самостоятельный материал?
А вот тут непонял, исполнения - это технология обработки - если да то я хочу разносить в отдельные таблицы так легче разграничивать права между конструкторами и технологами, если нет то поподробней.

Да и еще а по второму вопросу

2. Как построить вьюшку чтобы объединить все параметры по объекту
собрать все NAME_P и VALUES из всех таблиц ZP_***

Никто незнает или так нельзя...

ModelRИсполнения - это группа сильно похожих материалов, отличающихся значениями немногих параметров.
Скажем дверь - одна конструкция, варьируемые независимо параметры:
цвет (4 варианта), размер (5 вариантов).
Сколько материалов - один плюс двадцать исполнений или 20 отдельных материалов? Добавили еще один цвет - плюс пять материалов нужно сгегенрировать автоматом?
Нет таких проблем не будет, конструктор сам прорабатывает варианты и дает конкретное решение, дверь такая указывая ее параметры. А любое изделие имеет граничное количество параметров и описывается именно ими эти параметры вводятся один раз для всех дверей, кабелей, лестниц и т.д. в проекте. А цвет это значение параметра, его значение задается для каждой двери.
ModelR
Я к тому, что таких вопросов всплывет много. Прежде чем преобразовывать строки в столбцы или наборот неплохо бы все это продумать.
Это понятно, чем и занимаюсь. Просто я привык так: продумываю схему данных. Вроде подходит, в нее укладываются все данные которые необходимо хранить и обрабатывать. Затем продумываю как предоставить эти данные пользователю, примерные формы, запросы, процедуры обработки.
Если все склеилось то начинаем ваять.
В данном случае схема данных вроде подходит, но работать с ней неудобно, надо или менять схему или придумать способ обработки. Вот и думаю и спрашиваю советы.

locky
хотя, как показывает практика... у меня еще ни разу не встретилась
необходимость заджойнить ВСЕ параметры... джойнятся самы ходовые (чаще
всего наименование, цена, единица измерения и т.д.).
Или в каждом конкретном случае свой небольшой набор параметров.

Во первых спасибо за запрос, но это немного не то что я спрашивал. Здесь надо каждый раз писать свой запрос для каждого типа изделий. Я пытаюсь получить запрос который бы выдавал не так:

КОД РАЗМЕР ЦВЕТ ВЕС
________________________
1111 123х123 черн 1000
2222 234х234 белы 2000

а вот так

код поле значение
___________________
1111 размер 123Х123
1111 цвет черн
1111 вес 1000
2222 размер 234х234
2222 цвет белы
2222 вес 2000

Тогда этот запрос получится универсальным будет всегда выдавать все параметры, а если надо в табличном виде можно сделать перекрестный запрос
и развернуть. И показать все материалы со всеми параметрами в группе.

locky
Понял, но и в этом случае проблем нет. Вы ораклист? Вам в оракловский
форум :-).
Я занимался Oracle теперь, сменил работу сижу на Firebird, но дело не в субд
SQL он хоть и различается немного в разных СУБД но принципиально возможности одинаковые.
locky тут конечно кака- в завимости от типа параметра надо брать либо
"Строка", либо "Число", либо "дата".
Но кака небольшая.

Нет это все не то, я уже сделал и выглядит это так - кому интересно

И даже развернул предварительно сделав вьюшку


теперь думаю как сделать универсальную разворачивалку чтобы было как
в Access