Проектируя довольно крупный программный продукт с 1997 года, последние 2-3 года много думал :) об объектном представлении.

Цель - минимизация затрат по построению интерфейса пользователя. Речь не идет о полной автоматизации проекта, хотя два стандартных представления свойств объекта (в виде ObjectInspector или Диалоговая форма с авторазмещением контролов) могут сэкономить время. Для пользователя не всегда это является самым удобным вариантом представления. А если на тот же диалог, пользователь просит "прикрутить" еще и кипу аналитики, то тут чисто стандартный подход буксует (обычно это частная реализация).

В конце концов пришел к тому пути, по которому пошли многие - ведение второго словаря метаданных.

Принципы построения словаря метаданных:
Словарь метаданных ( METADATA DICTIONARY - MD ) ведутся по данным, MD служит не для проектирования новых объектов. а для отражения View Point на существующие объекты.

Классом называется общий перечень описаний свойств, методов и событий, присущий объектам одного вида, классы могут наследоваться (на уровне свойств, методов и события - конкретная реализация может отличаться от исходного класса (другая таблица, другие методы)).

Каждый объект имеет запись в Object List (каждый объект имеет уникальный внутренний идентификатор UII ), наличие ссылок на объект - косвенное подтверждение его "объектности".

Субобъект - аналогичен объекту, единственная разница - не имеет записи (уникального идентификатора) в Object List (как следствие не тратися значения уникального внутреннего идендификатора), тем не менее при работе с ним можно оперировать всеми понятиями (свойства, методы, события - о событиях чуть ниже)

в MD для каждого объекта задается связь с другим объектом (каскадное удаление например)

Для каждого объекта существует флаг состояния (например READ_ONLY). Субобъекты не имеют такого флаг, они используют соотв. флаг родительского объекта.

Реализация объектов:

Объект (свойства объекта) хранятся в таблицах

Методы объекта реализованы в процедурах

События объектов реализуются через свойства типа "событие", которому может быть присвоен метод (процедура), вызыаемая триггером на таблице свойств объекта, при их изменении(Insert,Update,Delete) триггера.
Эти же триггера проверяют возможность выполнения изменения объекта (субобъекта), например - удаления объекта.

Все проектирование ведется в CASE - средстве, в базе данных самостоятельного проектирования структуры не существует.
Единственное что может автоматом генерироваться в самой базе данных - создание VIEW для реализации полиморфизма доступа к свойствам обектов определенного унаследованного класса.

Немного частностей:
Так как планирую я эт оприменить на Sybase ASE,
для события планируется такая реализация

авторТриггер оперирует таблицами inserted и deleted
чтобы они были доступны в процедуре, триггер создает соотв. временные таблицы
select * into #object_class_name_old from deleted
select * into #object_class_name_new from inserted

и после этого дергает соотв. прцедуру.

execute @event_proc_name

процедура может откатить транзакцию, выдать сообщение об ощибке.
Таким образом триггера можно формировать единожды по шаблону, а логику менять впоследствии в текстах процедур. Все это вести в модели Sybase Power Designer

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

guest_20040621В общем и целом подход понятен.

Предположим, есть такая задача: несколько сущностей (неважно, какие; вполне себе реальная ситуация), которые могут быть связаны с любыми другими сущностями отношением n:m. Вопрос: как бы Вы организовали такую связь? Дополнительное условие: количество таблиц базы данных достаточно велико, так что связь с помощью третьей таблицы не рассматривается.

Т.е. если я правильно понял, Вы имеете в виду многомерные отношения ?

Любое сочетание объектов - есть объект (в моей терминологии, если класс объекта не является справочником, то - эот объект является субобъектом)

В ответ на вопрос: заведем третий объект(субобъект) и будем хранить в нем ссылки на имеющиеся.
Насчет третьей таблицы не понял? Если я неправильно понял вопрос просьба пояснить на примере.

guest_20040621
Пусть сущность, к которой есть кросс-линки (т. е. ссылки от любой сущности, описанной в бд), - одна. Пусть в бд описаны единицы сотен сущностей. Получим, что кросс-таблиц - те же единицы сотен. Т. е., физический предел допустимого количества таблиц в бд - вот он.

Ок, пусть будет объект "коллекция",
состав коллекции определяет объект "тип коллекции",
ссылки на конкретные экземпляры данной коллекции пусть хранятся в субобъекте "спецификация коллекции".

Теперь три таблицы должны полностью описать все возможные сочетания объектов. и дополнительных таблиц не потребуется.

Как вы думаете ?

На практике число сочетаний должно быть конечно.
Матрица не безгранична :)

2 guest_20040621

Ситуация которой вы меня озадачили в общем то уже имеет место, только вместо объектов, приходится иметь дело с древовиднымпредставлением конечных сущностей. Зато их сочетания как раз и реализуются описанным выше способом. Тема эта касается классификации информациив рамках рекомендаций по улучшению конечных продаж, что-то типа электронного консультанта.

Программный продукт носит название мифологического героя и обслуживает сеть распределенных складов, с которых осуществляется розничная торговля.
Количественный учет естественно при продаже ("интеллектуальные кассы").

И в настоящее время он реализован классически, без использования объектности в том смысле , в каком понимая это я и изложил выше.
Целью ветки было и показать ии услышать критические замечания по будущей архитектуре.

Решений достаточно много, это было одно из них.

ChaХотя некоторые отличия от предложенной Вами модели есть, в целом наблюдается схожесть. Собственно к тому, что эти идеи уже давно "витают в воздухе", в независимости от того, хороши они или плохи, опять же по разным соображениям.
Собственно модель предложена не мной, но я бы хотел ее использовать. Рад что все больше узнаю об практической реализации самой идеи.

Вот странная вещь, я планировал использовать две базы данных (оперативную и архивную), сегодня наткнулся на документ на сайте Sybase - "Динамический архив" (июнь 2004г). Идея аналогичная:
1)определяем данные, которые не требуются для оперативной деятельности
2)переносим их в другую БД (возможно настраиваем механизм переноса)
3)настраиваем VIEW и STORED PROC (UNION) для использования данных из обоих баз данных для отчетов - прозрачно для пользователей, без перекомпиляции приложения и отчетов.

Все это как я понял - на уровне рекомендаций, т.е. консалтинг. Думаю эта идея приходила в голову и не раз и не одному человеку, однако массовой озвучки так и не было до сих пор. Теперь эта идея озвучена Sybase :)

guest_20040621>> только вместо объектов, приходится иметь дело с древовиднымпредставлением
> конечных сущностей.

А вот с этого момента поподробнее, пожалуйста. Imho необходимо не просто древовидное представление, а полноценная схема.


Ничего нового, каталог товаров, набор групп(иерархическая классификация со множеством входов), вхождение товаров в группы. Вот и заводятся под определенным корнем, коллекции, в которых собраны сочетания групп и товаров.

guest_20040621
> Программный продукт носит название мифологического героя и обслуживает
> сеть распределенных складов, с которых осуществляется розничная торговля.

;) К сожалению, слабо знаком с системами такого рода, поэтому название мифологического героя ни о чем не сказало.
Имя программы не принципиально, она не имеет коммерческого хождения, написана под заказ и используется для автоматизации бизнеса в области продаж товаров для здоровья (медикаменты, косметика, памперсы и т.д.).

guest_20040621Понятно. Надеюсь, бизнес доволен. ;)

Настолько доволен, что о развитии самой платформы пекусь только я , заказчики только спускают тех. задания на новую функциональность. А хотелось бы и снизить затраты и стандартизировать многие вещи за счет использования "объектного ядра".

guest_20040621
Клиентские места в аптеках/магазинах? Или это исключительно внутренний анализ/учет? Есть импорт данных из внешних источников?

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

А анализ. Не нужен он на конечных местах. Его экономически выгодно централизовывать (консолидировать данные в одну аналитическую БД).
Типа Sybase IQ.

guest_20040621Т. е., если я правильно понимаю, система не монопольная? Т. е. присутствует несколько поставщиков?

Поставщики - внешние юридические лица. По согласованию с нами они доработали свои системы и состыковалсь с нами по электронному документообороту.

guest_20040621
Возможно, анализом просто некому пользоваться. ;) А вообще в розничной точке - очень даже нужен. Тем более если (в случае даже очень маленькой аптеки) ассортимент > 2 тыс. наименований.

На самом деле иногда даже > 6 тыс. позиций. Но когда аптека работает в составе аптечной сети, анализ нужен не индивидуальный, а обобщенный.

guest_20040621Кстати спросить, раз уж перешли на детали, внешние ключи к базам типа "Клифар" как строятся? Серии препаратов регистрируются?

Серии регистрируются, все программы для работы с медикаментами, должны обеспечивать отслеживание сроков годности. Отсюда отчасти и требование партионности в учете.

Насчет Клифара, нет такой связи.

2 stepa405

ответил по эл. почте

2 dr_dendroid

Схема от Тенцера понятная, но там много завязано и на клиенсткую (Middle Layer) реализацию.

Принципиальной схемы нет, собственно статья, упоминавшаяся в теме как раз содержит основные принципы.

Пока это только проект.