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

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

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

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

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

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

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

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

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

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

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

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

· определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

· разработка средств защиты создаваемой системы.

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