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

[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]

Есть таблички:
db_tables(id, name, description),
db_tables_fields(id, id_db_table, name, id_type, default_value, description)
types(id, name, description).

При вставке в db_tables должна создаваться таблица с именем name (триггер на insert)
Таблица types должна быть заполнена интересующими типами.
При вставке в db_tables_fields в таблицу по ссылке id_db_table должно вставляться поле, тип которого определяется по ссылке id_type.
Как-то так.

А если создавать для каждого типа свою таблицу, то как будет выглядеть логика? Например, в таблице int_values будут хранится ВСЕ целочисленные значения в БД? А как определить, к какой сущности они относятся? К какой конкретно записи? Как будут выглядеть запросы?

Раз уж проектируется универсальная структура ДБ, то ограничений должно быть как можно меньше. Нужно, чтобы было некое "ядро", через которое уже "раскручивается" нужная предметная область. Хотим, чтобы в ДБ были разные типы - значит их может быть сколько угодно. А ещё они могут быть ссылками. Применительно к конкретной предметной области "клиент" не должен видеть никакой кухни. Он говорит, допустим "хочу, чтобы в базе была такая-то сущность с такими-то сущностями" - "ядро" должно подготовить таблицу с нужными полями.
Думаю, полезно будет почитать, например, о том, как функционируют базы данных CMS.