guest_20040621
Остается надеяться, что Ваша работа оплачивается достойно. ;)


платить они достойно стали бы специалисту :) Я же довольна, что
получила возможность на реальном примере поучиться.Только вот сложнее получается, чем я себе представляла.

guest_20040621

К сожалению, для практического применения Ваша схема малопригодна:
- на Вашей схеме атрибуты каждого объекта уникальны; на самом деле это не так;
- непонятен смысл декомпозиции атрибутов; если вдруг появится новый тип, Вы для него новую таблицу заведете?
- нет возможности использовать перечисляемые значения (на автомобиль А1 может быть установлен только двигатель Д1 или Д2, а не двигатель вообще).

Это то, что на поверхности. ;)


Спасибо огромное за критику!

1) У меня уникальны ЗНАЧЕНИЯ аттрибутов(каждый аттрибут же имеет свои Attr_Id), т.е., например, у меня часто будут повторяться такие значения аттрибутов, как, "Rigidity" (для каждой скорости каждой коробки передач будет такое значение встречаться), так вот что бы мне не дублировать эту текстовую строку по 100 раз, я перед вставкой нового аттрибута- сначала проверю, а нет ли у меня уже такого значения, и если есть - то выберу Value_Id этого аттрибута и помещу к нововведённому Attr_Id.

2) Типы аттрибутов заранее известны: аттрибуты могут быть только указанных типов: Integer, Double, Varchar. И соответственно для хранения значений этих типов будут соответствующие таблицы.

Таблица же "Type" имеет вид:
----------------
Id | Name
-----------------
1 | Integer
2 | Double
3 | Varchar

Идея та же - что бы для каждого типа не дублировать текстовую строку, а только лишь Integer(Id), за это прийдётся, конечно, лишний join "заплатить". Стоит ли Type в отдельную таблицу выводить, или лучше сразу прописать название типа аттрибута в таблиcу Attributes?

3) Я тоже долго пыталась разобраться в этом. Данные составляющих зап.частей мне нужно будет перекачать с уже имеющейся базы данных. Как мне обьяснили, у каждой зап.части/автомобиля есть свой однозначно характеризующий её номер. Т.е. автомобиля с конкретмным номером может быть только 1 мотор, только 1 коробка передач. Объясняющий мне, правда, не очень уверенно обьяснял, поэтому я надеюсь получить доступ к этой их базе с зап.частями и проверить это сама, но доступ получить у них тут-это долгий процесс. Вот что бы время не терять я решила положиться на обьясняющего и сделать модель на случай, что информация деиствительно достоверна.

guest_20040621> У меня уникальны ЗНАЧЕНИЯ аттрибутов (каждый аттрибут же имеет свои Attr_Id)

Я не очень понимаю, что Вы хотели сказать этой фразой. Постарайтесь решить такую задачу: выбрать любой объект (в Вашей терминологии) с перечнем (не значениями!) его характеристик (включая те, значения которых не определены). Плюс к этому было бы правильно описать единицы измерения характеристик (а совсем хорошо было бы еще и использовать разные системы измерений).


SELECT A.Attr_Id, A.Value_Id, Ti.Name, Ty.Name, A.Line_Number,
FROM Object O, Object_Attributes OA, Attributes A, Title Ti, Type Ty
WHERE O.Object_Id=OA.Object_Id
AND OA.Attr_Id=A.Attr_Id
AND A.Title_Id=Ti.Title_Id
AND A.Type_Id=Ty.Type_Id
AND O.Name=’коробка предач А’;

в итоге таблица результатов будет выглядеть как в прикреплённом рисунке. Дальше я буду проходить по каждой строчке результатов и для каждого Аттр_Ид делать запрос:

SELECT Value from Ty.Name
WHERE Ty.NameValue_Id=Value_Id;

в итоге получу значения аттрибутов. Зачем мне хранить аттрибуты, значения которых не определены? Это необходимо?

таблицу забыла

nnovКакой ужас!!!
И это только выборка одного объекта с атрибутами
А теперь как у Вас получиться выбрать Все объекты у которых
Атрибут1 = Х или Атрибут2 = Y или Атрибут3 = Z
Отсортировав по атрибуту4

Естественно только возможностями SQL тут не обойтись, такои запрос прийдеотся программным путеом "дорабатывать". Никто и не утверждал, что всё должно быть легко, требования не позволяют такой роскоши.

я о том, что при такой схеме, как у меня ты не сделаешь в одном SQL запросе такую выборку, которую описал nnov, и вряд ли ORDER BY применишь.