Концептуальное (инфологическое) проектирование

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

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

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

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

Существуют разные подходы к инфологическому проектированию.

1. Функциональный подход к проектированию БД.

Этот метод является наиболее распространённым. Он реализует принцип «от задач» и применяется в том случае, когда известны функции некоторой группы лиц или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

2. Предметный подход к проектированию БД.

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

3. Проектирование с использованием метода «сущность-связь».

Метод «сущность-связь» (Entity-Relation, ER-method) был разработан в 1976 г. П. Ченом (Chen P.P.). Он является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает предметную область на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов предметной области. Обычно она разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6−7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация).

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

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

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

Далее осуществляется спецификация связей: выявляются связи между сущностями внутри локального представления. Каждая связь именуется. Кроме спецификации связей типа «сущность — сущность», выполняется спецификация связей типа «сущность — атрибут» и «атрибут — атрибут» для отношений между атрибутами, которые относятся к одной и той же сущности или к одной и той же связи типа «сущность — сущность».

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

• · объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;
• · введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели;
• · образование классов и подклассов подобных объектов (например, класс «изделие» и подклассы типов изделий, производимых на предприятии).

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

• 1. Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение.
• 2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связьэкзаменмежду сущностямистудент, дисциплина, преподавательможет быть представлена агрегированной сущностьюэкзаменс атрибутамиНазвание дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.
• 3. Обобщение. Позволяет образовывать многоуровневую иерархию обобщений. Например, в объединяемых представлениях присутствуют следующие сущности:

Детали собственного производства Детали покупные Сборочные единицы покупные Сборочные единицы собственного производства Их можно объединить так, как показано на рисунке1.1. Это позволит упростить формализацию процессов обработки данных. Например, оформление заказа на покупные элементы изделий в данном примере может быть описано один раз (для второго уровня иерархии).

Рисунок 1.1 Использование обобщений при объединении На этапе объединения необходимо выявить и устранить все противоречия. Например, одинаковые названия семантически различных объектов или связей или несогласованные ограничения целостности на одни и те же атрибуты в разных приложениях. Устранение противоречий вызывает необходимость возврата к этапу моделирования локальных представлений с целью внесения в них соответствующих изменений.

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

На этапе анализа предметной области также решаются следующие задачи:

• 1. Определение правил (ограничений целостности), которым должны удовлетворять сущности предметной области, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных (возможности реализации ограничений целостности в схеме базы данных определяются моделью данных той СУБД, которая будет выбрана для реализации проекта). Остальные правила реализуются с помощью программного обеспечения.
• 2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.
• 3. Создание внешней спецификации тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т. д.
• 4. Семантическая объектная модель.

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

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

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