Проектирование универсальной структуры БД Опции

[Litkevich Yuriy]

Задался вопросом как бы так запроектировать структуру БД, чтобы её для всех задач использовать.
За основу взял такую задачу - справочник по радиоэлектронным компонентам.
Суть его такова, есть типы компонентов (конденсаторы, резисторы, ...). У каждого типа есть обязательный набор характеристик (для конденсаторв: Напряжение и ёмкость, для резисторов: сопротивление и мощьность). Также у каждого типа есть специфические характеристики, но необязательные (для конденсаторов: ТКЕ-температурный коэфициент ёмкости, для резисторов: ТКС - температурный коэфициент сопротивления).
Плюс к этому у каждого компонента может быть уникальная, важная характеристика.
Разумеется у каждого элемента есть марка (наименование)

Дерево элементов можно представить так:

|
|-конденсаторы
|    |- К50-35 16В  100мкФ ±20% (ёмкость-100мкФ, напряжение-16В, допуск по ёмкости ±20%)
|    |- К50-35 35В  2200мкФ ±20% (ёмкость-2200мкФ, напряжение-35В, допуск по ёмкости ±20%)
|-Резисторы
|    |- С2-32-1 100 ±5% (сопротивление-100 Ом, мощьность 1Вт, допуск по сопротивлению ±5%)
|    |- С2-29-0,5 1к ±0,5% (сопротивление-1 кОм, мощьность 0,5Вт, допуск по сопротивлению ±0,5%)

В интернете встречал такие термины - "сущьности" и "свойства сущьностей", вроде как такими терминами оперируют при проектировании БД.
Видимо это какой-то подход, на манер шаблонов проектирования программ.

Где-то так должен выглядеть процесс настройки заготовки БД:


вот с типами и элементами вроде реализация сравнительно простая, а со свойствами не совсем понятно, т.к. тип данных может быть разный.
И ещё, хотелось бы для каждого свойства задавать, некое связанное свойство, например, для "напряжения" - еденицу измерения - "Вольты" (тип: "строка")

Может кто-нибудь подсказать, где про такие вещи почитать?

[Elfinit]

может хватит велик изобретать, а стоит посмотреть системные таблицы MS SQL....

Практика показала, что их недостаточно) Да, есть там, например [dbo].[sysobjects] (вроде). Ну и? Там вперемешку таблицы, процедуры, функции?
А как программную логику сделать для создаваемых таблиц? Точнее, чтобы она АВТОМАТИЧЕСКИ генерировалась? Как установить довольно сложные взаимодействия между сущностями? Писать триггеры к системным таблицам? Там получится куча условий и вообще тёмный лес....
В общем, аргумент такой: работа с системными таблицами не универсальна и не гибка.

Для меня является проблемой "Сущность и её свойства" где-то сзади чешется, что свойства тоже являются сущностью, тогда где их держать?

Первое, что пишло на ум - это аналогия reference-type и value-type. Т.е. свойство может быть ссылкой на сущность. А может и has is к сущности.

Вообще, советую почитать про ER-модели, это первое, с чего начинают проектирование БД. В UML можно заглянуть. После этого многое понятно станет. Очевидно, что раз хочется универсальную БД, то надо абстрагироваться от предметной области.

в FireBird

З.Ы. Firebird - реляционная, или объектно-реляционная СУБД? Леньгуглить)