Модели данных Модель данных [ 1 ] - это средство, позволяющее реализовать интерпретацию данных в соответствии с указанными требованиями и увидеть их информационное содержание ( семантику ). Традиционно выделяют три, отличающиеся способами представ- ления взаимосвязей между объектами, модели: реляционную, сетевую и иерархическую. Для описания объектов данных в предметной области исполь- зуются бинарные и инфологические модели, семантические сети, модель "сущность - связь" и др. В настоящее время наиболее широкое распространение получили идеи реляционного подхода, который сочетает прозрачность и ес- тественность представления данных ( в виде плоских таблиц ) с разработанным математическим формализмом, являясь по сути разви- тием теории отношений [ 2 ]. Этот аппарат легко реализуется на ЭВМ и позволяет создавать достаточно простые и удобные программ- ные и языковые средства поддержки реляционной модели данных ( РМД ). Основными понятиями РМД являются: домен - множество значений, которые принимает некоторый атрибут ( столбец ), отно- шение - некоторое подмножество декартова произведения одного или более доменов, кортеж - элемент ( строка ) отношения. Этапы проектирования систем реляционных баз данных. Разработка систем реляционных баз данных включает два ос- новных этапа: - концептуальное проектирование; - логическое проектирование. На этапе концептуального проектирования БД определяются ин- формационные потребности и локальные представления предметной области. Выявляется роль, назначение и взаимосвязь различных классов данных, проводится их глобальная спецификация. В резуль- тате формируются объекты данных и их взаимосвязи. Они представ- ляются без указания способов физического хранения и максимально приближаются к понятийной модели предметной области. Структура данных на концептуальном уровне называется концептуальной схе- мой. Она проблемно - ориентирована и независима от конкретной СУБД. Согласно представлениям ANSI/X3/SPARC [ 3 ] концептуаль- ная схема определяется наборами СУЩНОСТЕЙ, СВЯЗЕЙ и АТРИБУТОВ. Рассмотрим две важнейшие стадии этапа концептуального про- ектирования БД. 1. Анализ данных. Здесь производится сбор информации о данных, на основе ко- торого получается полное и точное представление о данных пред- метной области. Анализ данных может проводится с помощью анкети- рования пользователей или работы с экспертами ( специалистами предметной области ). Оба эти пути трудоемки и требуют значи- тельных временнных затрат, однако эта работа необходима для построения достаточно полной и работоспособной системы. В анкет- ный опрос могут быть включены следующие пункты: - имя объекта данных; - имя элемента данных, источник, атрибуты; - используемость, ограничения, показатель важности; - взаимосвязи; - продолжительность хранения и др. 2. Организация хранения данных. На этой стадии обычно разрабатывается графическая схема объектов и элементов данных: - исходные данные; - формирующие их подразделения или виды деятельности; - результирующие данные; - использующие их подразделения. Параллельно с этим уточняется степень важности отдельных данных для конечного пользователя , т.е. сопоставляются выдвига- емые пользователем требования к объектам и элементам с реально существующими объектами и элементами. Кроме того, обсуждаются выявленные связи между данными, их источники и требования поль- зователей. Выше описанные действия выполняются администратором базы данных, который работает с конечным пользователем. На основе составленного описания предметной области разрабатывается кон- цептуальная модель данных. Она служит основой для создания логи- ческой модели, которая может быть реализована средствами реляци- онной, иерархической или сетевой СУБД. На этапе логического проектирования осуществляется отобра- жение концептуальной схемы на выбранную модель данных. В процес- се проектирования возникает вопрос о том, какая модель данных наиболее подходит для этого. Отображение концептуальной модели данных на реляционную модель происходит относительно просто по сравнению с отображением первой на сетевую или иерархическую мо- дели данных. Каждая структурная единица графического изображения схемы ( например прямоугольник ) отображается в одно отношение. Это отношение отражает представление пользователя в удобном для него табличном формате. При отображении на реляционную модель данных необходимо оп- ределить отношения и их атрибуты, а некоторые атрибуты выделить в качестве первичных ключей соответствующих отношений. На основе процесса выделения отношений мы получаем пользовательское предс- тавление о логической модели базы данных, которая выделена из концептуальной модели. Ряд представлений пользователя, к сожале- нию, могут характеризоваться ,например, наличием избыточных клю- чевых атрибутов, т.е. один атрибут может быть ключом в несколь- ких отношениях. Эта избыточность может быть устранена при физической реализации. Таким образом, логическая модель детализирует концептуаль- ную схему и определяет атрибутивные свойства объектов и связей. Соответствующая ей структура называется логической схемой. Опи- сание атрибутов, выделение ключей и типов логических связей за- вершается процесом структурной нормализации данных [ 11 ]. Основная задача процесса нормализации - это получение тако- го набора отношений, который обладает лучшими свойствами, чем другие наборы. Как правило схема базы данных содержит два вида информации: структурная информация и семантическая. Первый вид информации связан с объявлением отношений. Второй - выражается множеством функциональных зависимостей между атрибутами отношений в схеме. Корректной считается такая схема, в которой отсутствуют нежела- тельные функциональные зависимости. В противном случае рекомен- дуется проводить процесс декомпозиции, когда исходное множество отношений заменяется другим множеством отношений ( при этом чис- ло их возрастает), которые являются проекциями первых. Целью де- композиции является устранение нежелетельных функциональных за- висимостей, что и сотавляет суть процесса нормализации. Другими словами, нормализация - это пошаговый обратимый процесс замены данной схемы ( или совокупности отношений) другой схемой, в ко- торой отношения имеют более простую и регулярную структуру. Уровень нормализации зависит от семантики отношения и не может быть однозначно определен из данных, содержащихся в теку- щий момент в базе данных. Семантика отношения должна быть задана с помощью функциональных зависисмостей. Существуют различные нор- мальные формы, которые ограничивают типы допустимых функциональ- ных зависимостей отношения. Однако не следует чрезмерно увле- каться процессом нормализации, так как это обычно приводит к значительному ухудшению прозрачности схемы базы данных. Поэтому, как правило переходят от первой ко второй и третьей нормальным формам. В результате формируется логическая модель, на основе кото- рой осуществляется выбор СУБД или разработка средств реализации базы данных. Известно, что семантическая мощность БД возрастает с увели- чением количества дополнительных характеристик, таких как конт- роль полномочий, достоверность поступающих данных, ограничения целостности и др. Однако, далеко не всегда этим вопросам уделя- ется должное внимание. Развитые СУБД, обычно, обеспечивают язы- ковую поддержку дополнительных характеристик. При проектировании систем баз данных необходимо ее использовать: формулировать и реализовывать в виде ограничений целостности правила задания, модификации и удаления жанных, защищать данные от несанкциониро- ванного доступа, предусмотреть возможность их восставновления в случае сбоя. Литература 1. Цикритзис Д., Лоховский Ф. Модели данных / Пер. с англ. -М.: Финансы и статистика, 1985. -344 с. 2. Мейер Д. Теория реляционных баз данных / Пер. с англ. -М.: Мир, 1987. -608 с. 3. Tsichritzis D.S. and Klug A. The ANSI/X3/SPARC DBMS framework report of the study group on database management systems. Inf. Syst., 3, p. 173-191.