Моделирование данных

в этой главе:

Типы .моделей

/ 10 тапое модел11} оваи11е данных?

Диаграммы eijuHocnib-oiHHouieiiue

Контроль качества концептуальной т1формациои11ой модели

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

lljioeKvuipoeaune, управляемое даппымп, и метамоделп

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

В главе 1 мы уже описывали, что представляет собой этап анализа в целом. Здесь же рассказывается о том, какие результаты мы можем получить на этом этапе и что они означают. Мы введем понятие семантических моделей данных и диаграмм сущность-отношение . Будут определены такие термины, как сущности, атрибуты, ключи, отнощения, супертипы, подтипы и нормализация. Особое внимание мы уделим непонятным и сложным структурам данных, которые нельзя непосредственно реализовать в реляционной базе данных без участия проектировщика. Мы также рассмотрим, какой смысл могут привнести в результаты анализа диаграммы жизненных циклов сущностей и диаграммы потока данных.

Вы, возможно, спросите, почему в книге о проектировании мы посвяща- \ ем целую главу методам моделирования данных - методам, которые часто считаются частью анализа? Ответ состоит в том, что проектировщикам крайне необходимо полностью уяснить концепции, лежащие в основе модели данных, и конструкции, которые эту модель образуют. Еще важнее тот факт, что мы редко оставляем модель в том виде, который она имела в начале проектирования. Нам необходимо уметь определить, какие конструкции вызовут проблемы, если мы реализуем их как есть, и понять последствия изменения этих конструкций. Это нужно сделать на первых стадиях этапа проектирования, чтобы к концу проектирования мы могли создать физическую модель данных. Для этого достаточно лищь взять концепцию и превратить ее в практишую и работоспособную физическую базу данных.

Типы моделей

Нам необходимо рассмотреть два типа моделей. Этап анализа дает нам информационную модель, а этап проектирования - модель данных. Как мы увидим, в модели данных должны учитываться технические характеристики СУБД Oracle?, тогда как информационная модель не должна ничего предполагать о технологии, которая будет использована для реализации приложения. Задача информационной модели - уточнить реальную ситуацию, которую должно моделировать приложение. Другими словами, хорошую информационную модель можно использовать как входные данные для проектирования, независимо от того, о какой среде идет речь - сетевой, иерархической, объектно-ориентированной или реляционной. Вот перечень элементов, которые вы встретите в модели:

диаграммы сущность-отношение (ДСС);

диаграммы потока данных (ДПД);

жизненные циклы сущностей (ЖЦС) или диаграммы изменения состояний (ДИС);

определения сущностей;

уникальные идентификаторы сущностей (УИД);

определения атрибутов;

отношения между сущностями.

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

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

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

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

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

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

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

Сущности%1

Ключ 1 атрибут 1

ТАБЛИЦА 1

-о<

Сущность 2

Ключ 2 атрибут 2

ПЁРВИЧНЫЙ КЛЮЧ 1 СТ0ЛБЕЦ 1

ТАБЛИЦА!

ПЕРВИЧНЫЙ КЛЮЧ 2 ВНЕШНИЙ КЛЮЧ 2 СТ0ПБЕЦ 2

Рис 3.1. Упрощенная схема процесса проектирования данных

Что такое моделирование данных?

Цель этого раздела - дать самое общее представление о семантических моделях данных. Мы введем такие понятия, как сущности, атрибуты, первичные ключи, отношения, супертипы и подтипы. (Не беспокойтесь, если эти термины вам ничего не говорят, - мы все объясним.) Если вы уже знакомы с этими понятиями, то можете пропустить или только бегло просмотреть данный раздел. (Правда, мы все же рекомендуем прочесть его, так как вы, возможно, не знакомы с обозначениями, которыми мы пользуемся.) Отметим, что этот раздел большей частью является теоретическим и специфику Oracle не отражает.