Проектирование БД на основе универсальной модели данных

Юрий Пергаменцев ("Вега-ЛТД")

Введение

В книге "Мифический человеко-месяц" Фредерик Брукс в главе "Серебряной пули нет…" предлагает: "использовать быстрое макетирование как часть запланированных итераций для установления технических требований к программному обеспечению". Универсальная модель данных (УМД) позволяет выполнить рекомендацию Брукса и обеспечить простое создание макета БД, дешевое проектирование открытой БД, эффективное развитие БД и надежную эксплуатацию БД. Неизменяемость структуры БД и программ, которые с ней взаимодействуют, позволяют не создавать торможение, дополнительное к традиционному сопротивлению изменениям.

1. Основная идея

Предметная область описывается элементарными единицами данных - элементами предметной области (ЭПО). Каждый ЭПО относится к некоторому понятию, перечень которых установлен. Основными являются понятия "объект" и "событие". Другие понятия уточняют, описывают и определяют основные. Перечень понятий определяет набор таблиц реляционной БД, который фиксирует модель данных. Заранее не ограниченное многообразие объектов распределяется по ограниченному набору понятий. Каждый элемент предметной области в БД имеет не менее 2-х записей: "запись описания" (метаданные) и "запись значения" (данные), что обеспечивает совместное хранение метаданных и данных. Это позволяет при любом расширении набора: объектов, характеристик объектов, событий, характеристик событий, связей между ЭПО; не добавлять в структуру данных строку, таблицу, поле или ключ, а просто добавлять в БД новую запись в существующую таблицу.

2. Назначение универсальной модели данных

УМД упрощает разработку БД и совершенствует использование в компании информационных систем (ИС). Наряду с операционными системами (ОС), обеспечивающими автоматическое распределение данных по оперативной памяти, и системами управления базами данных (СУБД), обеспечивающими автоматическое распределение групп данных по внешним устройствам, УМД обеспечивает автоматическое распределение описания предметной области и ее данных по таблицам, полям и ключам реляционной БД.

УМД позволяет не разрабатывать структуру БД, использовать готовые программы для формирования и просмотра данных и проектировать данные разных частей ИС раздельно. Вместо формирования структуры БД под каждый конкретный набор используемых данных (например, прямая разработка таблиц или при помощи CASE средств), используется единая структура БД для разных наборов фактографических данных. УМД включает формальное описание элементов предметной области (метаданные), которые хранятся в той же БД, что и все данные ИС. УМД обеспечивает инвариантность (неизменяемость) структуры реляционной БД по отношению к набору данных, не ухудшает эксплуатационные характеристики БД, повышает ее открытость, упрощает процесс проектирования и формирования данных. УМД позволяет применять объектное описание данных для математически выстроенных и повсеместно применяемых реляционных СУБД. Сейчас УМД реализована для СУБД "Oracle".

3. Проектирование БД

3.1. Данные

Деятельность компании и развитие информационных технологий постоянно формируют потребности в новых данных. УМД позволяет включать новые данные в БД по мере возникновения потребностей.

Используемое для формирования БД формальное описание строится легко, интуитивно понимается и позволяет при проектировании БД рассматривать только элементы предметной области. Элементы предметной области распределяются по нескольким определенным понятиям, которые значительно сокращают количество разных вариантов описаний и практически исключают из рассмотрения нежизнеспособные.

Включение в БД новых видов данных не требует проведения изменений в используемых, а готовые программы позволяют наращивать виды данных и формировать данные в общем эксплуатационном процессе. Это обеспечивает достаточное многообразие данных и их необходимый объем всегда. Простота и прозрачность описания, и раздельное рассмотрение разных частей проекта позволяет в 5-10 раз увеличить количество разнообразных элементов предметной области, содержащихся в БД.

3.2. Единая БД

УМД обеспечивает возможность формирования и использования одной БД для всей ИС компании. В единую БД включаются данные многих проблемных областей и разных частей ИС. Единая БД может создаваться как одновременно, так и поэтапно и включать данные вновь разрабатываемых приложений, данные приложений, которые разрабатывались ранее и независимо друг от друга, а также любые другие данные. Единая БД минимизирует затраты на системное сопровождение СУБД и обеспечивает функции хранилищ данных.

Согласование данных разных частей ИС обеспечивается структурой БД и средствами УМД, независящими от функций и набора данных ИС. Эти закономерности определены для понятий УМД. Согласование данных, которое определяется требованиями конкретной компании, обеспечивает специальный раздел. В этот раздел могут быть включены: общая для ИС терминология; словари синонимов; описания основных объектов компании; общетехнические, государственные и отраслевые нормативы и стандарты; географические атласы и карты; чертежи и схемы; классификация и специальные группировки, необходимые для разных разрезов общих аналитических отчетов. Единая БД имеет структуру данных, которая средствами СУБД "Oracle" может быть распределена по системе удаленных серверов и использована для интернет приложений.

Создание БД с данными для согласования на начальном этапе проектирования позволяет вести разработку разных частей ИС разным подрядчикам. Проектирование БД может выполняться независимо от разработки приложений. Это позволяет вести работы по разработке конкретного приложения наиболее подготовленному в соответствующей предметной области подрядчику, который может привлечь наиболее квалифицированных специалистов.

Взаимодействие обеспечивает однозначно понимаемые формальные данные единой БД. Для взаимодействия разработаны средства отображения данных, которые предоставляют разработчикам: формальное описание элементов предметной области; реальные данные компании; согласующие данные; данные, формируемые реализованными функциями. Единая БД обеспечивает распределение прав доступа между разными разработчиками и позволяет им постоянно через локальную сеть, интранет, либо интернет иметь все актуальные данные, необходимые для проектирования, вне зависимости от места своего расположения. При этом обеспечивается целостность всех данных крупной компании, которая необходима для качественного функционирования ИС.

3.3. Особенности проектирования

Значительное сокращение стоимости внедрения, сопровождения и развития БД.

Поэтапное выполнение работ, которое соответствует текущим потребностям и/или финансовым возможностям компании.

Объединение разных данных в единую БД и согласование объединяемых данных средствами УМД.

Сохранение существующих разрозненно эксплуатируемых в компании приложений и включение их данных в единую корпоративную БД.

Равномерное развитие и наращивание БД компании.

Независимая работа разных подрядчиков на основе формализованного взаимодействия с общей БД при обеспечении преемственности разрабатываемых приложений данных.

При построении аналитических отчетов согласование данных различных проблемных областей средствами УМД в единой БД.

Включение новых видов реальных данных без проектирования новой структуры БД.

Расширение состава БД администратором БД без привлечения разработчиков.

3.4. Использование

На основе УМД следующие работы по проектированию ИС могут выполняться независимо:

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

4. История создания

ИТ иногда позволяют получать неожиданно простые и весьма эффективные решения. К таким решениям относится УМД, которая была создана не на основе научной программы, а в результате реализации конкретных проектов.

Для описания газотранспортной системы и ее оборудования, учета основных фондов и объектов строительства, регистрации объектов имущества и расчетов за газ было необходимо включить в одну БД большое количество разнообразных данных, объединенных единым технологическим процессом. Существующее финансирование не позволяло выполнить эту работу традиционными методами, а желание участвовать в проекте требовало быстрого и качественного выполнения работ. Это вынудило применить решения, которые позволили формировать состав отраслевой БД по мере реализации проекта. Осмысление полученных результатов и работы в других проблемных областях (энергетические системы, противовоздушная оборона, книжная торговля, другие) привели к созданию УМД.

Авторам не известны другие реализованные варианты универсальной или стандартной модели данных. При создании описываемой УМД и проектировании к ней интерфейсов были использованы работы, которые фиксируют потребность в УМД (стандартной модели данных) и формируют к ней требования.

Смотри: Сергей Кузнецов "Будущие направления исследований в области баз данных: десять лет спустя"; Евгений Григорьев "Модель "объект - качество"; Мартин Фаулер "Новые методологии программирования".

Реализованные решения представлены:

Пергаменцев Ю.А. Информационные, функциональные модели и техническое задание на сегмент ОБД "Основные фонды" в Материалах Научно-технического совета ОАО "Газпром" по проекту "Отраслевой банк данных (ОБД)", Санкт-Петербург, ноябрь 2000г., стр.66, Москва 2001.
Решение фирмы "Вега" "Программно-аналитический комплекс ГТП" в Каталоге решений партнеров Oracle в СНГ, стр.34, Москва 1998;

Контакты:

www.dbcreator.com

perg@dbcreator.com

www.vega.kharkov.ua

Пергаменцев Юрий Арнольдович

Приложение

Раздел проекта "Конференция", Пример БД, построенной на основе УМД

Концептуальное описание предметной области понятиями УМД

Обозначения: классы объектов; классы событий; классы связей

Компания организует конференцию.
В конференции специалист участвует.
На конференции компания или специалист выступает.
В выступлении материалы докладываются.
Сайт принадлежит компании.
Сайт выполняет публикацию.
Материалы считаются опубликованными, если на сайте есть их публикация.
Материалы связаны классификацией с подразделом рубрики.
Подраздел рубрики входит в раздел рубрики.
Раздел рубрики входит в рубрику.
Рубрика принадлежит сайту.
Материалами может владеть компания или специалист.
Материалы связаны авторством с компанией или специалистом.
Специалист может состоять в компании.
На конференции компания проводит: открытие, перерыв, кофе, обед, закрытие.

Детализация понятий: объекты, события, связи

Объект компания определяется именем; характеризуется: видом деятельности, временем основания, адресом в интернет, ИНН, количеством участников, факсом, телефоном, физическим адресом, юридическим адресом.

Объект сайт определяется адресом в интернет; характеризуется: именем, временем создания, количеством посещений в неделю.

Объект материалы определяется названием; характеризуются: датой издания, местом издания, объемом; указывает на документ, где материалы содержатся.

Объект специалист определяется ФИО; может принадлежать компании; характеризуется: именем, отчеством, адресом, годом рождения, гражданством, E-mail, телефоном.

Объект рубрика определяются наименованием.

Объект раздел рубрики определяются наименованием; принадлежит рубрике.

Объект подраздел рубрики определяются наименованием; принадлежит разделу рубрики.

Событие конференция происходит с объектами компания; определяется временем проведения; характеризуется: именем, местом проведения; указывает на документ "схема проезда".

События открытие, перерыв, кофе, обед, закрытие организует объект компания; в составе события конференция; определяются временем проведения.

Событие выступление происходит с объектами компания или специалист; входит в событие конференция; определяется планируемым временем (по программе); характеризуется: фактическим временем.

Событие доклад происходит с объектами материалы; входит в событие выступление компании или выступление специалиста; определяется планируемым временем (по программе); характеризуется: фактическим временем.

Событие участвует происходит с объектами специалист; входит в событие конференция компании; определяется временем регистрации; характеризуется: временем оплаты, суммой оплаты, фактическим временем; бронирование гостиницы; категория, форма оплаты.

Событие публикация происходит с объектом сайт определяется временем публикации; характеризуется адресом

Событие опубликован материал; входит в событие опубликован на сайте, определяется временем публикации.

Связь автор для материала определяет специалиста или компанию, которые разработали материалы.

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

Пример формального описания предметной области (XML)

Классы объектов:
<ObjClass
	Name="Материалы"
	SName="Материалы"
	IsPoint="N"
	IsInterval="N"
	>
		<ObjType
			Name="Программное обеспечение"
			SName="ПО"
		/>
		<PropType
			UnitSName="стр."
			Name="Объём"
			SName="Объём"
			ValType="N"
			IsObjBound="Y"
			IsObjTypeBound="N"
		/>
		<EvType
			Name="доклад"
			SName="доклад"
		/>
		<EvType
			Name="публикация"
			SName="публикация"
		/>
	</ObjClass>
Подчиненность классов объектов:
	<Ownership
		ChildSName="Специалист"
		ParentSName="Компания"
		MaxChildren=""
	/>
	<Ownership
		ChildSName="Материалы"
		ParentSName="Компания"
		MaxChildren=""
	/>
Событий:
<EvOwnership
 	Notion="OBJECTS"
 ClassSName="Компания"
 EvTypeSName="Конференция"
 MaxChildren=""
>
	<EvOwnership
	 Notion="OBJECTS"
	 ClassSName="Специалист"
	 EvTypeSName="выступление"
	 MaxChildren=""
	>
		<EvOwnership
		 Notion="OBJECTS"
		 ClassSName="Материалы"
		 EvTypeSName="доклад"
		 MaxChildren="1"
		/>
	</EvOwnership>
</EvOwnership>
Связи:
<RelType
	Name="авторство"
	FromNotion="OBJECTS"
	FromClassSName="Материалы"
	FromAllowChildren="N"
	FromMaxVals="1"
	ToNotion="OBJECTS"
	ToClassSName="Специалист"
	ToAllowChildren="N"
	ToMaxChildren=""
	RevName="разработал"
/>

Пример реализации в БД

Пример отображения данных

Пример пакетной загрузки данных

Пример скрипта для закачки материалов:
declare
 cl_1 number(12);
 id1 number(12);
 cl_2 number(12);
 id2 number(12);
 rel_id number(12);
 ok char(1);
 error_text varchar2(255);
 begin
  select obj_class_id into cl_1 from obj_classes where obj_class_name='Материал';
  select obj_class_id into cl_2 from obj_classes where obj_class_name='Специалист';
  select rel_type_id into rel_id from relation_types where rel_type_name='авторство'
  and class_id2=cl_2;
  for w in (select * from spisok) 
   loop
  select object_id into id1 from objects where obj_sname=w.doklad and obj_class_id=cl_1;
  select object_id into id2 from objects where obj_sname=w.avtor and obj_class_id=cl_2;
    relation_p(action => 'I',
             rel_type_id_p => rel_id,
             id1_p => id1,
             id2_p => id2,
             ok => ok,
             error_text => error_text);
   if error_text is not null then
    dbms_output.put_line('err= '||error_text||',id='||id);
   end if;
 end loop;
 end;
/