Инфологическое моделирование - Банки и базы данных. Системы управления базами данных

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

Основными свойствами, которым должна удовлетворять инфологическая модель БД, являются прежде всего следующие:

    1. Предметная область должна быть описана адекватно и непротиворечиво. 2. Все возможные пользователи должны трактовать эту модель однозначно и легко ее воспринимать. 3. При необходимости инфологическая модель должна иметь возможность легко модифицироваться, подвержена композиции и декомпозиции.

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

Первым шагом при разработке инфологической модели БД является описание объектов предметной области и связей между ними. Инфологическое моделирование направлено на отображение семантики (то есть смысла) предметной области на модель БД. На ранних этапах развития теории БД было предложено несколько семантических моделей. Все эти модели имели свои преимущества и недостатки и к настоящему моменту времени в подавляющем большинстве случаев используется так называемая модель "сущность-связь". Эта модель называется также методом ER-диаграмм или ER-моделей (Essence - сущность, Relation - связь). Рассмотрим этот метод более подробно.

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

Зависимость между атрибутами сущностей определяет связь между ними. Связи делятся на три типа по степени связи сущностей: один-к-одному (1:1), один-ко-многим (или многие-к-одному) (1:М, М:1), многие-ко-многим (М:М). В общем случае между двумя сущностями может быть задано произвольное количество связей с различными смысловыми нагрузками. Класс принадлежности сущности может быть обязательным (О), когда в связи должен участвовать каждый экземпляр сущности, и необязательным (Н), когда не все экземпляры сущности должны участвовать в связи. Связь может быть обязательной со стороны одной сущности и необязательной со стороны другой. На практике степень связи и класс ее принадлежности всегда определяются исходя из анализа предметной области.

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

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

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

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

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

Объекты могут быть реальными или абстрактными. Объекты объединяются в классы объектов - совокупность объектов, имеющих одинаковый набор свойств. При этом ER-модель строится не для отдельных экземпляров объектов, а именно для классов объектов. В ER-модели каждому классу присваивается уникальное имя - существительное в единственном числе, дополненное при необходимости прилагательным или предлогом (ПРЕДМЕТ, ПРЕДМЕТ_ИЗУЧАЕМЫЙ). Уникальное имя объекта называется его идентификатором.

Каждый объект обладает набором свойств. В совокупности эти свойства описывают все возможные состояния объекта. Экземпляры объекта различаются как раз тем, что конкретные значения их свойств отличаются (объект СТУДЕНТ, свойства ФИО, Группа).

Если каждый объект может обладать только одним значением данного свойства в каждый момент времени (свойство Дата_Рождения), то такие свойства называются единичными. Если же одновременно у объекта имеется несколько значений свойства (свойство Изучаемый_Предмет у объекта СТУДЕНТ), то такие свойства называются множественными.

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

Есть такие свойства, которые могут одновременно присутствовать не у всех объектов данного класса (например, свойство Ученая_Степень у объекта ПРЕПОДАВАТЕЛЬ). Такие свойства называются условными.

Иногда вводится понятие составного свойства. Например, свойство Адрес может состоять из составных частей Город, Улица, Дом и т. д.

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

Составной объект используется для отображения "целое-часть" (ГРУППА-СТУДЕНТ).

Обобщенный объект используется для отображения связи "род-вид" между разными объектами предметной области. Например, для некоторого предприятия обобщенный объект СОТРУДНИК (родовой объект) составляют объекты ДИРЕКТОР, БУХГАЛТЕР. МЕНЕДЖЕР и т. д., (видовые объекты) которые называются категориями обобщенного объекта). Здесь впервые встречается понятие наследования свойств, поскольку все видовые объекты должны обладать всеми свойствами родового объекта (наследуют его свойства), а также индивидуальными, присущими только данному видовому объекту свойствами.

Агрегированными называются такие объекты, которым соответствует некий процесс. Примером такого объекта может быть объект СЕССИЯ, который объединяет в себе такие объекты, как ДАТА_ЭКЗАМЕНА, ОЦЕНКА, ПРЕДМЕТ, СТУДЕНТ.

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

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

    1 случай. Связь 1:1, класс принадлежности обеих сущностей обязательный. В этом случае для обеих сущностей формируется одно реляционное отношение. В этом отношении в качестве первичного ключа выбирается ключ любой из сущностей, а атрибуты сущностей становятся атрибутами этого отношения. Сформированное таким образом отношение содержит в себе полную информацию об обеих сущностях. 2 случай. Связь 1:1, класс принадлежности одной сущности обязательный, а другой - необязательный. Для каждой сущности формируется реляционное отношение с соответствующим набором атрибутов, первичным ключом каждого из этих отношений является ключ соответствующей сущности. После этого для установления связи между отношениями к отношению, соответствующему сущности с обязательным классом принадлежности, добавляется атрибут, являющийся ключом сущности с необязательным классом принадлежности. 3 случай. Связь 1:1, классы принадлежности обеих сущностей необязательные. В таком случае создается три отношения. Первые два отношения соответствуют каждой из сущностей, их первичными ключами являются ключи этих сущностей. Третье отношение используется для связи между первыми двумя и его атрибутами являются первичные ключи этих двух отношений. 4 случай. Связь 1:М (М:1), класс принадлежности М-связной сущности обязательный. Достаточно сформировать два отношения для каждой из сущностей так же как и в случае 2. После этого ключ 1 - связной сущности добавляется в качестве атрибута в отношение, соответствующее М - связной сущности, в качестве внешнего ключа. 5 случай. Связь 1:М (М:1), класс принадлежности М - связной сущности необязательный. Здесь по тому же принципу, как и в случае 3, необходимо сформировать три отношения.

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

6 случай. Связь М:М. Вне зависимости от классов принадлежности каждой из сущностей формируется три отношения таким же образом как и в случаях 3 и 5.

В настоящее время существует целый ряд автоматизированных средств проектирования ER-моделей, называемых CASE-средствами. Среди них следует отметить Design/IDEF, Power Designer (S-Designor), Oracle, ERWin. Использование этих средств дает ряд преимуществ, к которым относятся: снижаются требования к знанию языков описания данных и конкретных СУБД; автоматически контролируются целостность и согласованность схемы описания БД; сокращается в целом время проектирования; появляется возможность автоматического тестирования проекта на разных стадиях его проектирования.

Подводя итоги, сформулируем основные этапы проектирования БД в рамках инфологического моделирования.

    1. Определение сущностей и выявление связей между ними. 2. Построение ER-диаграммы с учетом всех сущностей и связей между ними. 3. Формирование набора предварительных отношений с указанием предполагаемых первичных и внешних ключей. 4. Добавление неключевых атрибутов в отношения. 5. Нормализация предварительных отношений, приведение их по возможности к нормальной форме Бойса-Кодда. На этом этапа как правило и происходит пересмотр принятых решение и происходит возврат к предыдущим этапам проектирования, включающий пересмотр ER-диаграмм и повторное выполнение следующих этапов.

Похожие статьи




Инфологическое моделирование - Банки и базы данных. Системы управления базами данных

Предыдущая | Следующая