Максимов Н.В., Голицына О.Л., Васина Е.Н. Управление данными

Подождите немного. Документ загружается.

121

обеспечивающими, в частности, необходимые для OLAP функции агре-

гирования данных. Таким образом, многомерные модели представляют

собой особую разновидность реляционной модели.

Многомерные модели – это “полноправные” модели данных. Так

же, как и другие модели, они используются для описания базы данных,

определяя тем самым соответствующее ее природе представление дан-

ных, и предоставляют средства манипулирования данными. И в этом

смысле они ничем не отличаются по своей функциональности от прочих

моделей данных. В сегодняшних массовых реляционных технологиях

многомерные модели ассоциируются с внешним уровнем архитектуры

систем баз данных. Именно этим определяется их направленность на ко-

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

условий для работы конечного пользователя было также основной це-

лью разработки модели универсального отношения.

Однако главная проблема в области массовых технологий заклю-

чается не столько в том, чтобы найти достойного преемника реляцион-

ной модели, сколько в том, что огромный балласт унаследованных сис-

тем (сегодня – уже реляционных) не дает возможности для резких тех-

нологических сдвигов и радикального обновления существующих тех-

нологий. Стремление избежать огромных кратковременных капитало-

вложений в случае перехода к принципиально новым технологиям при-

водит к необходимости лишь эволюционного пути развития. Отсюда

рождение таких гибридов, как объектно-реляционные базы данных “но-

вого поколения”.

Документальные системы и интеграция моделей. Приведенные

выше положения разрабатывались и действительно широко используют-

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

сегодня одной из важнейших проблем становится обеспечение интегра-

ции неоднородных информационных ресурсов, и в частности слабо-

структурированных данных. Необходимость ее решения связывается со

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

Web-технологий. При этом уже недостаточно простого обеспечения дос-

тупа к базе данных традиционным способом “из-под” HTML-форм.

Нужна интеграция на модельном уровне. И не просто синтаксическая

интеграция. В этом случае проблема семантической интероперабельно-

сти информационных ресурсов сводится к задаче разработки средств и

технологий, предусматривающих явную спецификацию метаданных для

ресурсов слабоструктурированных данных на основе традиционных

технологий моделирования из области баз данных. (Напомним, что в об-

ласти систем баз данных аналогичная ситуация была преодолена благо-

даря предложениям CODASYL о необходимости явной спецификации

схемы базы данных, независимой от приложений).

Именно на достижение этой цели направлены интенсивные разра-

ботки WWW-консорциумом языка XML и его инфраструктуры (факти-

чески, новой модели данных для этой среды), объектной модели доку-

122

ментов и других средств, которые, как можно ожидать, в близкое время

станут основой технологий управления информационными ресурсами.

Это направление связано с другой глобальной проблемой - организацией

распределенных неоднородных информационных систем на основе по-

строения репозиториев

метаданных, обеспечивающих возможность

семантического отождествления ресурсов и, таким образом, возмож-

ность их целенаправленного повторного использования.

5.2. Стадии проектирования и объекты моделирования

Не исключено, что у читателя создалось впечатление, будто мы

уже владеем современной методологией или, по крайней мере, близки к

этому, что, к сожалению, не так, и, может быть, мы никогда ничего по-

добного не добьемся. Всегда несложно охарактеризовать методологию

на концептуальном уровне, весьма трудно применить ее на практике.

Камень преткновения – сложность проникновения в существо предмет-

ной области (например, сложности понимания механизма деятельности

организации) и адаптации ее к новым, возможно лучшим, условиям

функционирования.

Аналогичные проблемы характерны и для СУБД в целом. Система

баз данных должна стать органическим элементом системы управления

организацией - вот залог ее успешного применения. Однако процесс ее

внедрения связан с определенными изменениями в самой организации и

в деятельности ее сотрудников, и мы всегда будем сталкиваться с есте-

ственной инертностью людей, когда речь идет о восприятии измене-

ний....

Весьма важно, чтобы средства СУБД были адекватны потребно-

стям пользователей. Поскольку разным пользователям могут понадо-

биться разные модели данных, языки данных и схемы, желательно, что-

бы СУБД поддерживала множество средств, а пользователь мог выби-

рать из них наиболее подходящие. ...

Можно, конечно, поставить под сомнение ценность таких иссле-

дований. Действительно, каким бы плохим ни был язык программирова-

ния, его, в конце концов, все-таки можно выучить. Точно также и сред-

ства СУБД можно освоить за определенный период времени. Но про-

блема состоит не в освоении средств, а в эффективности их использова-

ния!

Следует отметить, что положения цитаты из [20], текст которой

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

лее 20 лет назад. Действительно, средства проектирования непрерывно

развиваются, но и задачи, решение которых пользователь предполагает

автоматизировать с помощью систем баз данных, существенно услож-

нились.

Этому понятию в классических работах по проектированию баз данных соответствует понятие сло-

варь данных.

123

С точки зрения объектов моделирования необходимо различать

модели предметной области и модели базы данных. Эти модели взаимо-

связаны, поскольку представляют собой образы одного и того же ориги-

нала – некоторого множества предметов реального мира, информацию о

которых мы предполагаем хранить и обрабатывать с помощью проекти-

руемой БД.

Характер взаимосвязей (и, соответственно, отличий) проявляется и

в процессе проектирования системы баз данных. Модель предметной

области скорее ассоциируется с неформальным

уровнем семантическо-

го моделирования, а модель базы данных – с формализованным уровнем

системы (и в частности, СУБД). В идеале целью семантического моде-

лирования является формирование систематического основания для хо-

рошо формализованного процесса проектирования базы данных. Здесь

необходимо вспомнить следующие требования, предъявляемые к базам

данных, и, в частности, к способам описания данных:

1) описания должны быть понятны пользователю, не проектиро-

вавшему базу;

2) однажды принятые способы представления данных должны до-

пускать присоединение новых элементов данных без изменения сущест-

вующих схем данных и прикладных программ;

3) СУБД должны позволять эффективно обрабатывать произволь-

ные запросы к базе данных.

Эти требования отражают, с одной стороны, точку зрения пользо-

вателя, для которой характерны требования высокой степени общности

и широты представления (или, по крайней мере, не громоздкость де-

тальных описаний), позволяющих ему получить достаточно сведений

без затраты значительных временных или интеллектуальных ресурсов. С

другой стороны – точку зрения администратора, выполняющего проек-

тирование и оптимизацию системы баз данных, что предполагает высо-

кую степень детализации и формализации, обеспечивающих обоснован-

ность технических решений, а также возможность автоматизации проек-

тирования.

Забегая несколько вперед, рассмотрим взаимосвязь двух извест-

ных методов семантического моделирования инфологического уровня -

ER-диаграммы (Entity-Relation) и метод нормализации, воспринимаемых

зачастую как альтернативные. На самом деле нормализация с помощью

хорошо формализованных методов обеспечивает декомпозицию исход-

ных отношений (переменных) большой размерности к возможно боль-

шему набору отношений, но меньшей размерности. Эти методы не зави-

Правильнее было бы говорить о неформализованности, связанной с невозможностью обоснованно-

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

зуемых для моделирования (описания выделенных объектов).

124

сят от особенностей предметной области (семантики обрабатываемых

данных), но вследствие этого и не позволяют определить исходное от-

ношение. Для этого удобнее использовать методики, подобные ER-

диаграммам - для них свойственны подходы технологии нисходящего

проектирования, и которые дают представление «в целом», но именно

поэтому (из-за сравнительной простоты) не позволяют провести полно-

ценное проектирование базы. То есть, можно сказать, что метод норма-

лизации и ER-диаграммы по существу являются взаимодополняющими.

Кроме того, разнообразие моделей связано также и с различием

используемых парадигм моделирования, по существу определяющих

способ представления взаимосвязи объектов на уровне структур дан-

ных. С этой точки зрения, различаются реляционные, сетевые, иерархи-

ческие, объектные, объектно-реляционные, документальные и другие

виды моделей. Соответственно различаются и описываемые их средст-

вами схемы баз данных.

Рассмотрим основные стадии процесса

моделирования, пред-

ставленные на рис. 5.1.

Здесь не рассматриваются работы, относящиеся к другим этапам жизненного цикла баз данных,

такие как, определение процедур заполнения и сопровождения БД, разработка конкретных программ

обработки данных, развитие и улучшение структуры БД и т.д.

125

Рис. 5.1. Стадии и объекты процесса проектирования

Инфологическое проектирование

Системный анализ

парадигма информацион-

ной модели

Определение

- системы атрибутов;

- типовых запросов;

- типовых процедур обработки.

Инфологическая модель

Даталогическое проектирование

Разработка

- концептуальной схемы БД

- внешних схем;

- правил семантической целост-

ности.

Даталогическая модель

Физическое проектирование

Отображение даталогиче-

ской модели в модель данных вы-

бранной СУБД: проектирование

структур данных и связей.

Физическая модель БД

Определение парадигмы

информационной модели (струк-

турированность и динамичность

информации; способ представле-

ния и характер использования ин-

ф )

Объекты и связи

Предметной области

Прикладные

задачи

пользователей

Логика СУБД

(модель данных)

ЯОД и ЯМД

конкретной СУБД

Выбор парадигмы модели данных

(иерархическая / сетевая / реляци-

онная / объектная и т.п.).

Выбор методики (средств) моде-

лирования.

126

5.3. Системный анализ предметной области

Как отмечалось ранее, базы данных сами по себе представляют

относительную ценность. Базы данных это всегда важнейшая, но только

одна из составляющих некоторой информационной системы (ИС). И на-

до отметить, что любая информационная система, предназначенная, на-

пример, для оперативного управления предприятием или архивного хра-

нения и поиска документов – это не только программы, данные и ком-

муникации, но также и люди (заказчики, пользователи, аналитики, раз-

работчики), организационные структуры, а также цели, стимулы работы

предприятия или отдельных людей. И все эти компоненты должны быть

понятным как проектировщику, так и пользователю, а, кроме того, не-

противоречивым образом соединены в одну систему.

Главная идея процесса такого согласования состоит в том, что его

надо начинать с анализа самых главных характеристик предметной об-

ласти, рассматривая самые главные содержательные аспекты. И прово-

дить его не "мысленно" и не "на словах", а на явно изложенных описа-

ниях (моделях) объектов предметной области, позволяющих видеть все

существенные взаимосвязи. Но следует отметить, что попытки исполь-

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

ектных или каких либо других) на этом этапе приводят к более низкому

(более детальному и в тоже время ограниченному) уровню представле-

ния предметной области, чем это необходимо для общего понимания.

В общем случае существуют два подхода к определению состава и

структуры предметной области (рис. 5.2).

Функциональный подход предполагает, что проектирование начи-

нается с анализа задач и, соответственно, функций, обеспечивающих

реализацию информационных потребностей.

При объектном (предметном) подходе информационные потреб-

ности пользователей (задачи) жестко не фиксируются, а основное вни-

мание сосредотачивается на выделении существенных объектов – пред-

метов и связей, информация о которых может быть использована в при-

кладных задачах пользователя.

Условность такого деления достаточно очевидна, поэтому на

практике используются компромиссные варианты, предполагающие по

мере развития системы расширение как состава объектов, так и спектра

прикладных задач.

127

Рис. 5.2. Основные подходы к системному анализу предметной области

В [29] была предложена простая, но концептуально мощная схема,

показывающая различные уровни представления архитектуры ИС, раз-

личные виды ее "обеспечения", а также их основные взаимосвязи. На

рис. 5.3 показана таблица, представленная в [7], аналогичная схеме За-

хмана. Три столбца отражают три раздела обеспечения системы: инфор-

мационный (ДАННЫЕ), функциональный (ФУНКЦИИ) и коммуника-

ционный (СЕТЬ).

Строки таблицы отражают шесть уровней представления системы:

реальная среда приложений, концептуальная модель, логическая модель,

физическая модель, детальная реализация процедур, представления

пользователя.

Полезность такой схемы состоит в том, что она помогает рассмат-

ривать задачи проекта в полном объеме, упорядочивать состав и струк-

туру требований к системе, определять и фиксировать причинно-

следственные связи.

Рис. 5.3. Модель информационной системы Захмана

128

Позднее появилось развитие такой "плоской" модели. В [28] рас-

сматривалась схема, представленная на рис. 5.4, включающая три новых

столбца, в которых отражаются еще три раздела: побудительные причи-

ны действий системы, события и графики выполнения действий, а также

"действующие лица" - люди и организационные структуры.

Рис. 5.4. Развитие модели информационной системы Захмана

В результате появилось шесть разделов, которые содержат "ответы

на вопросы": почему выполняются действия, когда выполняются и кто

их выполняет, а также что делает система, как делает и где. При этом

уровни представления (строки таблицы) остались те же.

Такое расширение позволило рассматривать потребности в кон-

тексте информационных технологий, соединять предметы и действия с

человеческим фактором и операционной динамикой процессов.

Цель системного анализа предметной области как этапа проекти-

рования – выделить предметную область как систему объектов и их

взаимосвязей, определив при этом функционально-информационные

требования к их последующему представлению в виде системы взаимо-

связанных данных.

Главным результатом этапа системного анализа является опреде-

ление парадигмы информационной (инфологической) модели: тре-

бования к средствам представления системы определяются на основании

анализа уровня структурированности информации и характера воспри-

ятия ее семантики пользователем (точная/приблизительная, чет-

кая/неопределенная).

129

Например, выбор атрибутивной формы представления объектов

предметной области приведет, соответственно, к выбору парадигмы

фактографических баз данных, а вербальной - к необходимости выбора

документальных БД.

В дальнейшем изложении процесс и средства проектирования мы

будем рассматривать только для случая фактографических баз данных,

использующих реляционную модель.

5.4. Модели и технологии инфологического проектирования

реляционных БД

Как отмечалось ранее, представляется вполне очевидным начинать

создание базы данных с определения самих данных, выполняя проекти-

рование базы данных в терминах отношений на основе механизма нор-

мализации.

Однако, забегая вперед, отметим, что такой подход часто пред-

ставляет собой очень сложный и неудобный процесс для самого проек-

тировщика. При этом проявляется ограниченность реляционной модели

данных в следующих аспектах:

- реляционная модель не предоставляет достаточных средств для

фиксации смысла данных, т.е. семантика предметной области не фикси-

руется непосредственно в отношениях;

- для многих приложений трудно моделировать предметную об-

ласть на основе плоских таблиц;

- хотя весь процесс проектирования происходит на основе учета

зависимостей, реляционная модель не имеет средств представления (от-

ражения семантики) этих зависимостей;

- несмотря на то, что процесс проектирования начинается с выде-

ления некоторых существенных для приложения объектов предметной

области ("сущностей") и выявления связей между этими сущностями,

реляционная модель данных не предлагает какого-либо аппарата для

различения сущностей и связей в базе данных.

На практике семантическое моделирование обычно производится

на первой стадии проектирования. Полученный результат - концепту-

альная схема базы данных (в терминах семантической модели) затем

вручную или автоматически преобразуется к реляционной схеме.

5.4.1. Инфологическое проектирование и семантическая модель

Начальной стадией проектирования системы баз данных является

построение семантической модели предметной области, которая базиру-

ется на анализе свойств и природы объектов предметной области и ин-

формационных потребностей будущих пользователей разрабатываемой

130

системы. Эту стадию принято называть концептуальным проектирова-

нием системы, а ее результат – концептуальной моделью предметной

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

будущей системы!). Этой стадии соответствуют также ранее упомяну-

тые термины “инфологическое проектирование” и “инфологическая мо-

дель”.

Такие модели обобщенно представляют информационные потреб-

ности пользователей создаваемой системы в части использования хра-

нимых данных

и, по существу, являются средством коммуникации как

разработчиков, так и пользователей на разных стадиях жизненного цик-

ла базы данных.

Назначение инфологических моделей определяет и некоторые

специфические требования к средствам их представления. Помимо упо-

мянутой независимости от среды (оборудования) и требования адекват-

ности отражения предметной области отметим следующие:

- формализованность, обеспечивающую возможность автомати-

зированной обработки и, в том числе, например, автоматический кон-

троль непротиворечивости;

- дружественность, обеспечивающую возможность использования

наглядных графических средств отображения и обработки их пользова-

телем.

К инфологическим моделям относятся различные компоненты, по-

разному и разными средствами отражающие предметную область. По-

мимо наиболее известного описания объектов и связей между ними (мо-

дель «сущность-связь») к инфологическому уровню описания предмет-

ной области можно отнести следующие компоненты:

- систему атрибутов и средств описания предметной области. На-

пример, логические (алгоритмические) связи между показателями или

лингвистические свойства языка (синонимию, синтаксис и т.д.), исполь-

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

- ограничения целостности, определяющие допустимость значе-

ния отдельных полей и взаимосвязей как на уровне семантики содержи-

мого БД, так и ее физической структуры (отдельных файлов данных и

взаимосвязей между ними);

- описание информационных потребностей пользователей, на-

пример, в виде типовых запросов, отражающих процедурные особенно-

сти обращения к данным.

Еще раз отметим, что они, в отличие от моделей данных, используемых в качестве инструмента

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

СУБД, хотя это и может иметь место на практике.