Как добиться оптимальной структуры БД? Ведь в КИС есть несколько составляющих, которые используют как свои данные, так и данные составляющих. Как избавится от избыточности, как добиться наилучшей синхронизации?
Вид для печати
Как добиться оптимальной структуры БД? Ведь в КИС есть несколько составляющих, которые используют как свои данные, так и данные составляющих. Как избавится от избыточности, как добиться наилучшей синхронизации?
А надо ли избавлятся от избыточности?Цитата:
Как избавится от избыточности, как добиться наилучшей синхронизации?
Кстати, с синхронизацией вопрос давно решен....
Простой пример…
Бухгалтерский учет оперирует информацией о контрагентах, CRM тоже. Пересечений между этими составляющими не особо много. Держать все данные этих составляющих вместе не всегда выгодно, вот и получается избыточность информации о контрагентах и вопрос о синхронизации этих данных. Легко может получится, что либо в бух учете не хватает каких либо данных которые знает CRM или, что данные разняться!
Ну вот, опят возвращаемся к лоскутной автоматизации.Цитата:
Простой пример…
Не может быть таких проблем, если система одна.
Общая БД панацея?
_______________________________________
Как вариант для решения данной проблемы я пытался реализовать следующее:
Рассматриваем БД как множества… N множеств имеют какие-то пересечения, находим простейшие, не дробимые, и считаем их основой. Из получившегося набора множеств путем объединения получаем любое из больших.
Любое из простейших множеств считаем самостоятельной БД со своей структурой и методами обработки данных, методами ссылочной целостности и т.д.
И при этом подходе мы не получаем лоскутной системы! Мы получаем гибко настраиваемые рабочие места, более легкое сопровождение. Все эти простейшие БД объединяются и работают как одно целое!
При таком подходе требуется сначала дать определение базе данных.Цитата:
Рассматриваем БД как множества…
Информационная область – совокупность конфигурации и БД, логически завершенная база данных. Любая ИО может быть полностью или частично использована в другой ИО. Дочерняя ИО т.е. ИО объекты (конфигурации) которой использованы в «материнской» ИО могут быть изменены только из самой «дочерней» ИО. Материнская ИО может только использовать эти объекты в собственной конфигурации. Работа с данными же происходит вне зависимости от принадлежности ИО т.е. данные дочерней ИО могут быть изменены как из дочерней так и материнской ИО.
Информационная область состоит из:
1. Конфигурации (структура данных, интерфейсные модули, методы работы с данными)
2. Движок БД (алгоритмы получения/записи данных)
3. Модули доступа к данным
a. MS SQL Server Engine
b. Oracle Engine
c. …
_____________
Извиняюсь за сумбур :) ... Просто однажды Писал ТЗ "Комплес разработки бизнес приложений"
Это что то новое... ;)Цитата:
Информационная область
Я не случайно спросил по определение базы данных. Существуещее совсем не подходит к обсуждению поднимаемых здесь вопросов.
"База данных - набор данных и правил их обработки."
Слишком общее не правда ли?
Информационная область - это то, чего мне жутко не хватает... Ничего подобного реализованного я не видел... Поэтому в свое время и стал разрабатывать "Комплес разработки бизнес приложений". Но уперся в то, что затраты и риск огромные...
Максим, давайте проработаем теоретичеускую часть и кто-нибудь (может и я) реализует.Цитата:
Информационная область - это то, чего мне жутко не хватает...
Почему бы и нет... Правда наработки, которые у меня были сделаны в этом направлении частично утеряны... Прикрепляю файлик в котором частично описано, что я хотел сделать... Образно понять можно хоть там и недоработано... Совместными усилиями можно доработать до ума...
;(
Маловато ....
Ладно, буду думать.
К TOT: если что получиться интересное оформим в виде статьи?
Остальное это объектная модель с комментариями, но разрабатывал ее не я, и публиковать не имею права, так как она была частично взята для реализации одного коммерческого проекта.
Андрей,конешно.Цитата:
К TOT: если что получиться интересное оформим в виде статьи?
Господа.
Позвольте встрянуть.
Если Вы полагаете объектно-ориентированное решение, то надо понимать, что SQL не подразумевает подобный подход. Делить задачу на маленькие объектные составляющие с методами доступа к таблицам - примитивизация SQL и, по сути, решение которое игнорирует всю мощь SQL. (Хотя конечно можно классы наследовать :)) Использовать SQL базы как простой менеджер записей - не очень продуктивно.
Если же вы полагаете строить некую динамическую интерпретационную систему с динамическими таблицами, описателями, встроенными языками и генераторами SQL запросов, то IMHO при более-менее сложной структуре, управление таким механизмом становится задачей чрезвычайно сложной, и все равно все упрется в необходимость писать SQL запросы, отвечающие требованиям данного момента, с учетом всех тонкостей текущей организации информационного поля. Да и медленно все это.
Ну вроде бы Postgress это позволяет? Или я не прав?Цитата:
то надо понимать, что SQL не подразумевает подобный подход
Не факт, замедляет конечно, но кто сказал, что объектный подход должен быть реализован на SQL? Тут как раз и приходит необходимость 3-х звенной архитектуры.Цитата:
Да и медленно все это
Кстати, самая медленная система из всех мне известных - 1С, однако её популярность обусловлена не скоростью, а простотой разработки (маркетинговые фокусы отложим в сторону).
> Ну вроде бы Postgress это позволяет? Или я не прав?
Ну разве наследование структуры таблиц это уже ООП?
> Тут как раз и приходит необходимость 3-х звенной архитектуры.
Я не говорю о забвении принципов ООП в решении задачи. Я говорю, что объектная декомпозиция на уровне создания простых "базных" частей и обертка их объектами и последующее использование полученных оберток в процессе создания более сложных классов уничтожает мощь SQL.
Хм, не хочу спорить, но ведь и ООП и SQL это просто инструмент?Цитата:
уничтожает мощь SQL
Можно копать ломом, можно лопатой, но пользуются почему и тем и другим. Зачем противоставлять одно другому?
Такое ощущение что мы путаем мягкое с теплым. :)
Никто никому ничего не противопоставляет. Ну а по существу вопроса я высказывался выше. Я говорил только о высказываниях Flattera о информационном поле и о таблично-объектной декомпозиции задачи. См. мои сообщения выше.
Я говорил немного не о том...
Полная универсальность это абсурд для пользователя, можно работать и в Access очень универсально. Но пользователь без адресного внедрения работать в нем не будет да и затраты для этого адресного внедрения со стороны программера слишком велики.
На самом деле основа любого бизнес приложения это справочники которые и составляют БД. В связи с этим нам нужно просто классифицировать требования прилагаемые бизнес приложениями к БД, и исходя из этого описать объектную модель нашей разработки. А не объектную модель БД!!! Объектная БД это конечно хорошо, но требуется ли она? Нам нужно то всего лишь быстрые выборки и апдейты данных, проработанная структура и контроль ссылочной целостности.
С этим трудно спорить. :)
В этом направлении и нужно работать :)
Надо подумать сперва.
Есть еще интересные вопросы касающиеся «информационного поля» с одной стороны это делается для уменьшения избыточности данных, но свести избыточность к 0 значит замедлить систему и сильно завысить требования к железу. Необходимо найти оптимальное соотношение допустимой избыточности данных к производительности системы.
Например:
ИО№1: Данные о контрагентах организаций.
Справочник «Контрагенты»
ИО№2: CMR (работа с клиентами)
Справочник «Контрагенты» (ИО№1)
Справочник «Контактные лица» (подчинен справочнику «Контрагенты»)
Есть несколько путей реализации:
1) минимальная избыточность
В ИО№2: хранятся только уникальные идентификаторы элементов (ИО№1) используемых в ИО№2 т.е. те у которых есть подчиненные. А все выборки для просмотра списков запросами к БД ИО№1
2) Использование всех данных ИО№1 и их синхронизация в определенные моменты в ИО№2
3) Производные от первых 2.
Теоретики, типа Детй, говорят о другом.Цитата:
свести избыточность к 0 значит замедлить систему
Зависит от конкретной реализации... Зачастую оптимизация по скорости сводится к увеличению избыточности!
