Разработка словаря данных (с визуальным дизайнером)
Постановка на компонент Дельфи, обеспечивающий создание, изменение, хранение структур таблиц БД.
Концепция.
1. В жизни нет таблиц и полей. Есть сущности, и их атрибуты.
2. Количество функциональных разновидностей сущностей перечислимо (классификация будет дана).
3. Атрибуты сущностей делятся на два типа:
3.1. Собственные;
3.2. Зависимые от равноправного взаимодействия с другими сущностями.
4. Таблицы, предназначенные для хранения значений атрибутов экземпляров сущностей, разделяются на два типа:
4.1. Значения собственных атрибутов сущностей хранятся в Таблицах Основных Записей.
4.2. Значения атрибутов, зависимых от равноправного (многие-ко-многим) взаимодействия с другими сущностями, хранятся в Таблицах-Ракурсах.
5. Все возможные атрибуты любых сущностей классифицируемы по своему смыслу и могут быть отнесены к перечислимому количеству функциональных классов. Ориентация не на тип атрибутов, а на их назначение!
6. Каждая сущность имеют текстовые описания длиной: 20, 40 и 60 символов, зависящих от языка;
Требования.
1. Компонент не использует никаких компонент VCL, предназначенных для работы с базами данных, за исключением TDataBase.
2. Иерархия типов атрибутов оригинальна (никаких TFieldDefs!), будет дана.
3. Визуальный редактор сущностей и их свойств, работоспособный как в Design-time, так и в Run-time. Ориентированность редактора на древовидный интерфейс. Заданная иерархия классов таблиц и атрибутов (см. выше).
4. Компонент должен быть способным самостоятельно осуществлять (посредством языка SQL и компоненты TDataBase) инсталляцию, изменение и удаление структур данных, в следующих типах СУБД:
4.1. MS SQL;
4.2. Oracle;
4.3. InterBase.
5. Возможность сохранения структуры как в DFM-файле, так и в базе данных (временно можно использовать TTable для сохранения-выборки из БД самих структур данных – но с прицелом на то, что потом будет использоваться другой компонент).
6. Не надо вопросов «А чем тебя не устраивает TDataSet/TTable/TField/TDataProvider/и т.д. и т.п.». Считайте, что это мой каприз.
Желательно еще разработать достаточно сложный алгоритм, который можно было бы назвать анализатором зависимостей (далее – анализатор).
Это необязательное условие, но если сделаете - доплата 4.000 рублей.
Предположим, есть несколько сущностей, со своими атрибутами (буква – сущность, Буква.Цифра – ее атрибут), а также пара ракурсов.
1. A
1.1. A.1 (ключ)
1.2. A.2
1.3. A.3
2. B
2.1. B.1 (ключ)
2.2. С.1 (ключевая ссылка на сущность C)
2.3. B.2
2.4. B.3
3. X (ракурс A+B)
3.1. A.1 (ключ)
3.2. B.1 (ключ)
3.3. X.1
3.4. X.2
3.5. X.3
4. C
4.1. C.1 (ключ)
4.2. C.2
5. D
5.1. A.1 (ссылка на сущность A)
5.2. D.1
5.3. D.2
6. Y (ракурс C+D)
6.1. C.1 (ссылка на сущность C).
6.2. D.1 (ссылка на сущность D)
6.3. Y.1
6.4. Y.2
У меня есть технология, позволяющая представлять эти структуры в виде иерархического дерева, с возможностью произвольно переставлять уровни местами, убирать или добавлять уровни, показывать только отдельные атрибуты сущностей.
Например, как в виде
C.1 - B.2 - A.3 - D.2 ,
так и, например, в виде
A.1 – B.1 – C.1 .
Но необходимо разработать алгоритм для расчетов зависимостей при операциях с данными, в зависимости от текущего представления иерархии.
При этом у уровней-атрибутов можно поменять значения (и необходимо определить массив объектов, у которых необходимо изменить значения одинаковым образом), а у уровней-идентификаторов сущностей, при создании новых сущностей автоматом заполняются поля (необходимо определять, какие поля и какими значениями) и создаются присвоения.
Пример. Мы показали пользователю структуры в виде дерева
B.2
A.1
B.1
Пользователь хочет создать новое значение на уровне B.1 (т.е., создать новый экземпляр сущности B).
Анализатор должен определить, что при создании данного экземпляра, автоматом заполняется значением поле B.2 (в силу того, что оно уже указано в дереве на более высоком уровне), плюс автоматом создается пересечение с объектом A (в силу того, что это тоже уже определено деревом).
Или, более сложные зависимости.
C.1
D.2
B.2
A.1
На уровне B.2: при изменении значения атрибута, значение этого атрибута меняются у всех экземпляров сущности B, которые:
Принадлежат к C.1;
И
Имеют пересечения с А, которым принадлежат объекты D, имеющие пересечение с C.1 и имеющие значение D.2.
D.2
C.1
B.2
A.1
На уровне A.1:
При создании экземпляра A.1:
Ему автоматом присваиваются объекты D с атрибутом D.2, имеющие пересечение с C.1;
Создаются пересечения нового объекта A.1 с тем объектами B, которые имеют значение B.2 и подчиняются к C.1.
Более подробная информация – победителю конкурса.
Сроки.
2 недели - первая часть.
2 недели - опциональная часть.
Бюджет.
5+4 т.рублей