Соответствие  этапов моделирования данных и элементов  архитектуры ANSI-SPARC

 
Формулирование  и анализ требований

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

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

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

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

Определение требований к системе

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

Задачи  системы для приложения базы данных

Пользовательские представления

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

Любое пользовательское представление определяет требования к приложению базы данных в части хранимых в ней данных и транзакций, выполняемых над  данными (т.е. оно определяет, какие  действия и над какими данными  должен выполнять тот или иной пользователь). Требования пользовательского  представления могут относиться только к данному представлению  или частично совпадать с требованиями других представлений. На рисунке схематически изображена предметная область приложения базы данных с несколькими пользовательскими  представлениями (которые обозначены цифрами 1-6). Обратите внимание, что  требования некоторых пользовательских представлений (1—3, а также 5 и 6) частично перекрываются (это показано штриховкой), а требования пользовательского  представления 4 являются индивидуальными.

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

Сбор и анализ требований пользователей

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

• Описание применяемых или вырабатываемых данных.
• Подробные сведения о способах применения или выработки данных.
• Все дополнительные требования к создаваемому приложению базы данных.

Эта информация затем анализируется для определения  требований (или средств), которые  должны быть реализованы в разрабатываемом  приложении базы данных. Эти требования описываются в документах, известных  под общим названием спецификации требований к новому приложению базы данных.

Сбор  и анализ требований является предварительным  этапом концептуального проектирования базы данных, в ходе которого спецификации требований пользователей анализируются  с целью выяснения всех необходимых  сведений. Объем собранных данных зависит от сути проблемы и действующих  бизнес-правил предприятия. Слишком  тщательный анализ легко может привести к параличу сверханализа (paralysis by analysis), а слишком поверхностный —  к пустой трате времени и денежных средств на проведение работ по реализации решения, которое окажется ошибочным в результате неправильной формулировки проблемы.

Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления  пользователей, которые впоследствии потребуется преобразовать и  представить в виде более четко  сформулированных требований. Эта цель достигается с помощью методов  составления спецификаций требований, к числу которых относятся, например, технология структурного анализа и  проектирования (Structured Analysis and Design — SAD), диаграммы потоков данных (Data Flow Diagrams — DFD) и графики "вход-процесс-выход" (Hierarchical Input Process Output — HIPO), дополненные  соответствующей документацией. Как  будет показано ниже, для получения  гарантий того, что составленный набор  требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного  проектирования и создания программ.

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

 
Концептуальное  проектирование базы данных

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

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

Этапы концептуального  проектирования:

1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.

Охват предметной области  данного предприятия.

2. Определение типов сущностей.

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

3. Определение типов связей.

Определение важнейших типов  связей, существующих между сущностями, выделенными на предыдущем этапе.

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

Связывание  атрибутов с соответствующими типами сущностей  или связей.

5. Определение доменов атрибутов.

Определение доменов для всех атрибутов, присутствующих в локальной концептуальной модели данных.

6. Определение атрибутов, являющихся потенциальными и первичными ключами.

Определение всех потенциальных  ключей для каждого  типа сущности и, если таких ключей окажется несколько, выбор  среди них первичного ключа.

7. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

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

8. Проверка модели на отсутствие избыточности.

Проверка  на отсутствие какой-либо избыточности данных в модели.

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

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

10. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

 
Модель "сущность-связь"

 
Прежде, чем приступать к созданию системы автоматизированной обработки  информации, разработчик должен сформировать понятия о предметах, фактах и  событиях, которыми будет оперировать  данная система. Для того, чтобы привести эти понятия к той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).

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