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

Концепция многоуровнего представления базы данных является основой современной технологии баз данных. Эти идеи впервые были сформулированы в отчете рабочей группы по базам данных Комитета по планированию стандартов Американского национального института стандартов (АЫЗГ/ХЗ/ЗРАЯС), опубликованном в 1975 г. В данном отчете была предложена обобщенная трехуровневая модель архитектуры базы данных, включающая концептуальный, внешний и внутренний уровни (рис. 1.36).

Рис. 1.36. Уровни представления данных (А1/Х3/5РА11С).

Концептуальный уровень архитектуры АК51/5РАЯС служит для поддержки единого взгляда на структуру базы данных, общей для всех приложений, использующих ее, и независимо от них. Концептуальный уровень представляет собой формализованную информационно-логическую модель базы данных.

Внутренний уровень архитектуры АЫ81/8РАКС определяет поддержку представления базы данных в среде хранения. На этом уровне она представляется в полностью «материализованном» виде.

Внешний уровень архитектуры АШ1/5РА11С предназначен для отражения поддержки базы данных на уровне отдельных групп пользователей. Описания таких представлений базы данных называются внешними схемами. При этом в системах управления базами данных поддерживается несколько внешних схем базы данных для различных групп пользователей или задач.

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

Рис. 1.37. Уровни представления моделей данных.

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

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

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

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

Учитывая эти особенности разработки баз данных, аналитический уровень представления модели данных содержит три основные модели, где данные являются ключевым элементом: модель потоков данных на основе реализуемых бизнес-процессов, схема документооборота, модель взаимосвязей объектов предметной области. Основную сложность при построении моделей данных на аналитическом уровне вызывает необходимость построения всех трех моделей одновременно, понимая, что сведения, отражаемые в одной из моделей, учитываются и (или) отражаются в другой модели, в соответствии с определенными правилами представления (нотация^[1]).

Рассматривая представление сведений о данных на аналитическом уровне, необходимо отталкиваться от терминологии, принятой при описании предметной области в бизнес-процессах и документах, а именно: объект, атрибут, функция/процесс/задача, связь, экземпляр объекта, классификатор и т. д. Используемая терминология позволяет, не переходя на уровень компьютерных систем, представить сведения о структурах данных и их характеристиках на языке, понятном функциональным специалистам^[2] и специалистам в области информационных технологий.

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

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

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

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

Здесь стоит учесть, что термин «Отношение» в нотации Питера Чена имеет несколько отличный смысл по сравнения с этим же термином в реляционной алгебре, где под отношением понималось любое представление данных. На уровне модели термин «Отношение» из реляционной алгебры уточняется путем выделения в отдельный терминологический элемент «Сущность» отношений, описывающих конкретный объект предметной области с фиксированным набором атрибутов, а термином «Отношение» называются представления, получаемые при взаимодействии связанных сущностей.

Таким образом, термин «Отношение» для модели Питера Чена (рис. 1.38) определяет именно особенности связи между сущностями, выражая ее глагольной формой, соответствующей деятельности в предметной области. Например, при связывании сущностей «Учащийся» и «Дисциплина» устанавливают отношение «Изучает», иллюстрируя предметную сущность взаимодействия между учащимися и дисциплинами, которые они изучают.

Рис. 1.38. Пример модели в нотации Питера Чена.

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

Представление модели в нотации Питера Чена является достаточно громоздким, что не очень удобно для последующего анализа и рассмотрения модели базы данных. Поэтому для логического и последующих уровней применяются более простые, с точки зрения визуализации, нотации, как, например, нотация Crow’s Foot^[3], применяемая в большинстве инструментальных средств^[4] моделирования базы данных Поскольку логическая модель базы данных является расширением концептуальной модели, то все элементы: сущности, атрибуты, связи, отношения и т. д., — также отображаются на диаграммах логической модели. Ориентация логической модели на уровень абстрактного представления базы данных и добавление в нее элементов уровня реализации: умолчание, ограничения и т. д., — относятся к специализированным моделям, с которыми в большинстве работают специалисты информационных технологий.

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

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

Переходя с логического на даталогический уровень, разработчик базы данных меняет используемую терминологию, а именно: от термина «Сущность» выполняется переход к термину «Таблица», от термина «Атрибут» — к термину «Поле» («Колонка») и т. д. Этот переход обусловлен необходимостью рассматривать модель в терминах СУБД, которая работает на физическом уровне.

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

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

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

• • таблицы и поля, обозначающие разделение данных на атомарные сведения и группирующие в неразрывные по функциональному признаку совокупности полей;
• • типы данных, которые определяют основные правила представления и обработки хранимых в полях данных, учитывая особенности работы СУБД;
• • ограничения на значения полей, представляемые в виде логических выражений и используемые в СУБД при определении возможности сохранения соответствующего значения в нужном поле таблицы;
• • умолчания, которые задаются, если командой добавления или изменения не предоставлено значение для сохранения в поле таблицы;
• • поле первичного ключа, соответствующее атрибутам первичных ключей логической модели базы данных, но накладывающее правила ограничений на физическом уровне по возможности внесения соответствующих значений в данное поле;
• • поле внешнего ключа, соответствующее атрибутам внешних ключей логической модели базы данных, но также, как для ноля первичного ключа, накладывающие особенные ограничения на хранение в нем соответствующих значений;
• • формулы вычисления значения, используемые для вычисляемых полей, где для математического или лингвистического вычисления применяются значения полей той же таблицы и записи, в которых используется данное поле;
• • правила ссылочной целостности^[5], определяющие возможные действия (Restrict, Cascade, Set NULL, Set default, No action и др.) при выполнении операций модификации данных (добавление, изменение, удаление).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [1] Термины «Нотация» и «Методология» рассматриваются в рамках теории проектирования информационных систем (см. соответствующую литературу).
• [2] Функциональным специалистом является владелец процессов в предметной области, выполняющий соответствующую деятельность в организации.
• [3] Отдельные нотации будут рассмотрены в гл. 2.
• [4] Под инструментальным средством понимается программное приложение, реализующее определенную решаемую задачу. Для моделирования базы данных инструментальное средство создает возможности графического представления схемы базы данных и реализацию дополнительных задач, связанных с обеспечением корректности представления моде
• [5] Особенности ограничений ссылочной целостности будут рассматриваться в гл. 5.