|
2 adisk
Почитайте еще раз топик с начала - ссылки есть, люди делились. И ресурсы по теме в нете есть. Можно "теорию" почитать в "СУБД" и "Открытые системы".
Я сейчас как раз "перерыванием" доступных ресурсов занимаюсь. Сам ок. 6 лет "размышлял" над необходимостью подобной ОО-надстройки над РСУБД. Просто не было возможности (у меня) её реального применения. Теперь вроде-бы появилась - по работе. То, что сам раньше "надумал" сильно перекликается с тем, о чем в этом (и других) топике писали. Пока есть время надо по максимуму ознакомится с тем что уже есть, чтобы потом не наступать на грабли, которые кто-то уже нашел как обходить :)
Может получится использовать у нас чью-то готовую разработку - неважно свободную или коммерческую?! Пока ищу, знакомлюсь с тем, что есть.
P.S. Кроме "Каше" была еще такая "Жасмин" от СА, а "всяк сверчок хвалит свой шесток" (пока ему там тесно не станет :)
2 guest_20040621
>Пожалуйста, очертите круг задач этой информационной системы.
Эта информационная система должна будет как минимум реализовать единое информационное пространство для всех подразделений и компаний а в идеале обеспечить в организации все требования и управленческого учета и финансового и остальных... :)
Можно много писать о конкретике и "воде", но чтобы мне здесь круг задач очерчивать конкретно, то ни места ни времени не хватит. Могу только несколько примеров привести:
Надо чтобы и у коммерсантов и у финансистов данные в ИХ отчетах о (напр.)реализации продукции были одинаковые;
Надо чтобы справочник оргструктуры у кадровиков был такой-же как и у тех-же коммерсантов и у финансистов;
Надо чтобы менеджер (не важно какого уровня), пожелавший ежедневно с утра получать отчетность нового вида, смог начать ее получать не через месяц-два, а уже через день;
Надо чтобы внедрение в систему новой функциональности занимало не 3-6 месяцев а 1-2 недели;
>Если Вас не затруднит, пожалуйста, сформулируйте требования к "объектности" такой системы
"объектность" такой системы плавно вытекла из логичной необходимости иметь не в Visio или Rose, а в БД модель всей организации и ее БП. Сделать это можно и "традиционным реляционным" подходом, забив все необходимые данные в кучу справочников и обеспечив их "динамичность", но поддерживать и развивать такую систему и на уровне БД и на уровне прикладного софта будет очень проблематично даже для небольшой компании.
Выходом здесь на мой взгляд(и не только на мой) может послужить внесение в БД дополнительного "низкоуровневого", "объектного" слоя (или "объектной надстройки" - наверно не важно как это называть) в которой можно будет описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их связей, атрибутов и методов.
Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка имеет более широкий смысл.
Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет обсуждения по вопросу, который я выше в теме обозначил номером 6.
Логично было-бы в объектном слое описать для необходимых бизнес-объектов и их пользовательский интерфейс - тоже в виде логических объектов. Тогда можно было-бы все возможные клиентские модули системы ограничить единым универсальным модулем - генератором user-интерфейса (очень тонкий клиент).
При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и, возможно, написанию/генерации некоторых специфических ХП.
"Традиционную реляционную"структуру БД, при необходимости, можно будет получить из объектного слоя автоматически в виде представлений, временных или постоянных таблиц и др. и хранить данные системы в них. НО! Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой системы в таких таблицах. Поэтому на мой взгляд, имея объектный слой в БД, эффективнее было-бы и для хранения данных системы пользоваться только объектным слоем, а постоянные/временные таблицы или представления использовать только в "крайних" случаях - автоматически генерировать для сложных отчетов, пересчетов данных, и т.п.
В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать ни одну таблицу объектного слоя.
Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу - в ней тоже есть таблицы с полями, индексы, связи, ХП, запросы, представления... Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма нормализации модели данных :)
Минусами при этом будут - нетрадиционный подход к проектированию и структуре БД, возможно меньшая производительность (что спорно и сильно зависит от реализации), и больший объем БД.
Плюсов и выгод на мой взгляд гораздо больше чем минусов и о них тоже можно будет поговорить.
Возможно Вам не нравится сам термин "объектная" (надстройка или слой в БД) но этот термин на мой взгляд наиболее точно отражает суть предлагаемых изменений в подходе к проектированию в СУБД :)
|
