Уровни моделирования ИС

     При выполнении основных функций СУБД должна использовать различные описания данных. Рассмотрим порядок создания этих описаний.

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

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

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

     На рис. 7 приведен фрагмент концептуальной модели предметной области "Предприятие".

Рисунок 7 - Концептуальная модель ИС "Предприятие"     

     Из наиболее известных методик исследования предметных областей и построения концептуальных моделей можно назвать системный анализ. Также существует целый ряд методик, учитывающих принципы системного анализа, - методика структурного анализа SADT и основанная на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методика объектно-ориентированного анализа UML, и др. Концептуальная модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

     Модель данных - инструментарий для отображения предметной области, определяется:

     - допустимой организацией данных;

     - ограничениями целостности (семантикой);

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

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

     Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

     Можно выделить три основные виде логических моделей:

     - иерархическую модель;

     - сетевую модель;     

     - реляционную модель.

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

Рисунок 8 - Пример логической модели данных

     Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Предварительным средством разработки логической модели данных в настоящий момент являются различные варианты инфологических (информационно-логических) моделей - ER-диаграмма (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.

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

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

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

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

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

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

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