Архитектура БД. Модели данных, используемые на различных этапах проектирования БД.

Архитектура БД

Основной целью любой СУБД является возможность предложить обычному пользователю базы данных абстрактное представление данных, скрыв от пользователя особенности хранения и управления ими. Поскольку база данных, как правило, разрабатывается как общий ресурс для большого количества пользователей, то каждому пользователю может потребоваться своё, отличное от других пользователей представление о данных, хранимых в БД. Это вызвано следующими причинами:
— каждый пользователь иметь право обращаться к общим данным, используя своё представление о них;
— взаимодействие пользователя с БД не должно зависеть от особенностей её физической организации;
— администратор базы данных (АБД) должен иметь возможность изменять структуру и формат данных, не оказывая влияния на пользовательские представления;
— внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;
— АБД должен иметь возможность изменять концептуальную или глобальную структуру данных без какого—либо влияния на всех пользователей.
Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД, существующих на рынке программного обеспечения, в той или иной мере, строится на базе так называемой архитектуры ANSI—SPARC. Название произошло по названию комитета планирования стандартов и норм (Standards Planning and Requirements Committee SPARC) национального института стандартизации (American National Standard Institute— ANSI) США. Комитет признал необходимость использования трехуровневого подхода к организации БД. Этот подход отделяет пользовательские представления базы данных от её физического представления посредством создания независимого уровня, изолирующего программы от особенностей представления данных на низком уровне.
Архитектура БД представлена на рисунке 1.
Внешний уровень – это индивидуальное представление БД с точки зрения отдельного пользователей. Пользователи могут быть разные, с разным уровнем подготовки. Каждый пользователь представляет данные в соответствии с формами различных документов, присущих данной предметной области. При этом одни и те же данные могут иметь различную форму представления — формат (тип), длину. Например, сведения о зарплате – их можно увидеть в виде итоговой суммы в записи ведомости, либо в виде перечня составляющих – различных начислений и удержаний.

ПП1 – представление 1—го пользователя, ППк – представление к—того пользователя

Рисунок 1 — Трехуровневая архитектура БД

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

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

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

Различают логическую и физическую независимость данных.

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

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

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

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

В современной трактовке термин «модель данных» обозначает инструмент моделирования. Модель базы данных (схема данных) или модель предметной области являются результатами моделирования.

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

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

Исходя из трехуровневой архитектуры БД, различают три, связанных между собой, модели данных, получаемых в результате проектирования и отображающие результаты проектирования.
1. Внешняя модель данных, отображает обобщенное представление всех пользователей. Эту модель называют описанием предметной области, формируемым на естественном языке. Представить внешнюю модель можно как в формализованном (схемы, рисунки, таблицы), так и в неформализованном (словесное описание на языке проектировщиков) виде.
2. Концептуальная модель. Она может быть выражена в виде диаграммы, схемы, рисунка, отображающего обобщенное логическое представление информации предметной области (концептуальная информационно логическая модель предметной области) или в виде рисунка, схемы, отображающего обобщенное логическое представление данных (концептуальная логическая модель данных), не зависимое от выбранной СУБД.
3. Внутренняя модель. Является результатом отображения концептуальной модели средствами языка определения данных выбранной СУБД.

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

Модели данных, как инструменты, делятся на 3 основные категории:

1. Объектные модели данных. В этих моделях используются такие понятия как: классы объектов (типы сущностей), объекты (экземпляры сущностей), свойства классов объектов (атрибуты сущностей), связи между классами объектов. В скобках приведена исторически ранняя терминология, используемая в теории баз данных.
Среди объектных моделей выделяют наиболее общие типы:
— семантические модели. Их назначение – обеспечение возможности выражения семантики (смыла) предметной области. Это, например, модели типа "сущность—связь" (ER—модели — Entity Relationship model), отображающие семантику предметной области в виде ER—диаграмм;
— функциональные модели, дающие представление о функциях автоматизируемого предприятия, о распределении ответственности за их выполнение. Результаты использования функциональных моделей могут быть представлены в виде диаграмм бизнес—функций, диаграмм потоков данных;
—объектно—ориентированные модели. Эти модели расширяет определение класса объектов (сущности) предметной области с целью включения в определение не только свойств, описывающих состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. Это, например, модели, основанные на использовании языка UML (Unified Modeling Language — унифицированного языка моделирования). Описание предметной области получают в виде различных диаграмм — диаграмм вариантов использования, диаграмм деятельности, диаграмм классов.
В настоящее время для проектирования БД, получения концептуальной инфологической модели предметной области, широко используются семантические модели «сущность—связь».
2. Модели на основе физических записей. Такие модели позволяют описывать логическую структуру БД в виде записей, фиксированного формата. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа логических моделей данных на основе записей:
— иерархическая (hierarchical data model);
— сетевая (network data model);
— реляционная (relational data model).
3. Физические модели данных. Модель содержит всю информацию, необходимую для реализации конкретной БД в среде выбранной (целевой) СУБД. В физической модели в виде описания содержится информация обо всех объектах БД. В описании объектов БД определяется физический формат данных, реализуются ограничения предметной области, бизнес—логика автоматизируемого предприятия, уровни доступа пользователей. Описание создается на языке определения данных (ЯОД) выбранной (целевой) СУБД. В состав ЯОД входят операторы, позволяющие создать или удалить объект БД, модифицировать его структуру. Физическая модель данных не затрагивает вопросы физического размещения данных на машинных носителях, в настоящее время это максимально реализуется средствами СУБД.
Модели первых двух групп используются для формирования концептуального уровня архитектуры БД, третьей – для описания БД на внутреннем уровне.
Модель данных, полученная в результате проектирования, должна представлять автоматизируемое предприятие в таком виде, который позволит проектировщикам и пользователям БД обмениваться конкретными недвусмысленными мнениями.

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

В таблице 1 представлены модель, которые будем использовать при проектировании базы данных

Таблица 1 — Модели данных

Уровень архитектуры БД	Модель данных, как инструмент, используемый для формирования схемы БД	Результат проектирования
Внешний уровень	Функциональные модели, модели на основе языка UML.	Диаграмма иерархии функций, диаграмма потоков данных и др.
Концептуальный уровень	1. Семантические модели («сущность—связь») 2. Модели на основе физических записей	1. ER—диаграмма предметной области – концептуальная информационно—логическая (инфологическая) модель (ИЛМ) предметной области 2. Логическая структура БД – концептуальная даталогическая модель (ДЛМ) БД.
Внутренний уровень	ЯОД СУБД	1. Техническое описание объектов БД. 2. SQL—скрипты объектов БД.