5.4. Модели и технологии инфологического проектирования
реляционных БД

 

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

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

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

-         для многих приложений трудно моделировать предметную область на основе плоских таблиц;

-         хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не имеет средств представления (отражения семантики) этих зависимостей;

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

 

На практике семантическое моделирование обычно производится на первой стадии проектирования. Полученный результат - концептуальная схема базы данных (в терминах семантической модели) затем вручную или автоматически преобразуется к реляционной схеме.

 

5.4.1. Инфологическое проектирование и семантическая модель

 

Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью предметной области (объектом моделирования здесь является предметная область будущей системы!). Этой стадии соответствуют также ранее упомянутые термины “инфологическое проектирование” и “инфологическая модель”.

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

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

-         формализованность, обеспечивающую возможность автоматизированной обработки и, в том числе, например, автоматический контроль непротиворечивости;

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

 

К инфологическим моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к инфологическому уровню описания предметной области можно отнести следующие компоненты: 

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

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

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

 

 

К оглавлению

Назад к разделу "5.3. Системный анализ предметной области"

Вперед к разделу "5.4.2. Модель «Сущность-Связь»"



[1] Еще раз отметим, что они, в отличие от моделей данных, используемых в качестве инструмента моделирования конкретных баз данных, не обязательно поддерживаются механизмами используемой СУБД, хотя это и может иметь место на практике.