Информационные системы / ИС_Тема05

Тема 6. Проектирование баз данных

6.1. Жизненный цикл баз данных

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

Часть реального мира, которая должна быть отображена в базе данных называется предметной областью.

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

Жизненный цикл базы данных определяется как период времени, который начинается с момента принятия решения о необходимости создания базы данных и заканчивается в момент его полного изъятия из эксплуатации.

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

Под моделью жизненного цикла базы данных понимается структура,

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

1.Формирование требований.

2.Проектирование.

3.Реализация.

4.Тестирование.

5.Ввод в действие.

6.Эксплуатация и сопровождение.

7.Снятие с эксплуатации.

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

6.2. Каноническая схема проектирования баз данных

6.2.1 Трех этапная схема разработки

Разработка базы данных делится на три этапа: концептуальное проектирование; логическое проектирование; физическое проектирование.

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

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

понятия предметной области. Эта модель связана с исследованием предметной области и пространством задачи, но не с ее решением.

Концептуальная модель может отображать следующее.

•Понятия

•Ассоциации между понятиями

1

•Атрибуты понятий Построение концептуальной модели включает следующие шаги:

1.Идентификация понятий.

2.Определение ассоциаций, отражающие связи между понятиями.

3.Определение атрибутов, необходимые для выполнения информационных требований.

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

Понятие — это представление идеи или некой реальности .

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

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

Ассоциация (association) — это связь между понятиями, отражающая некоторое значимое и полезное отношение между ними.

Обычно в концептуальную модель включаются следующие ассоциации.

•Ассоциации, знания о которых нужно сохранять в течение некоторого периода (важные ассоциации)

•Ассоциации, производные от содержащихся в списке стандартных ассоциаций

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

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

Рекомендации по поиску ассоциаций При поиске ассоциаций руководствуйтесь следующими рекомендациями.

•Сосредоточьтесь на тех ассоциациях, для которых данные о связи должны сохраняться в течение некоторого времени (важные ассоциации)

•Гораздо важнее идентифицировать понятия, чем ассоциации

•Слишком большое количество ассоциаций приводит к ошибкам в концептуальной модели, а не к ее упрощению. Изучение ассоциаций не должно отнимать слишком много времени и вместе с тем должно приносить максимальную пользу.

•Избегайте использования избыточных ассоциаций

Каждый конец ассоциации называется ролью (role). Роль дополнительно может иметь

следующие характеристики.

•Имя

•Кратность

•Направление связи (navigability)

Кратность (multiplicity) определяет, сколько экземпляров понятия А может быть

ассоциировано с одним экземпляром понятия В в определенный момент.

2

Например, один экземпляр объекта Store (Магазин) может быть ассоциирован с несколькими (ни с одним или с несколькими, что отображается символом *) экземплярами объекта Item (Элемент).

Имена ассоциаций базируются на формате ИмяПонятия—ГлагольнаяФраза— ИмяПонятия, где глагольная фраза представляет собой последовательность, которая читается и является значимой в контексте модели.

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

Между двумя типами может быть установлено несколько ассоциаций. И в этом нет ничего необычного. В предметной области системы управления полетами в качестве подобного примера можно привести отношение между объектами Flight (Полет) и Airport (Аэропорт). Ассоциации Flies-to (Летит в) и Flies-from (Летит из) являются принципиально различными и должны отображаться отдельно. Обратите внимание, что приземление в аэропорту гарантирует не каждый полет.

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

Атрибут (attribute) — это абстрактное свойство объекта.

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

Типы большинства простых атрибутов зачастую рассматриваются как примитивные типы данных. Обычно тип атрибута не должен быть сложным понятием предметной области, таким как Sale (Продажа) или Airport (Аэропорт). В концептуальной модели атрибуты должны быть простыми атрибутами (simple attributes) или простыми данными (pure data values).

К стандартным типам простых атрибутов относятся Boolean, Date, Number, String(Text), Time. Другими стандартными типами являются следующие: Address (адрес), Color (цвет), Geometries (Point, Rectangle) (геометрические фигуры: точка, прямоугольник), Phone Number (номер телефона), Social Security Number (номер страхового полиса), Universal Product Code (UPC) (универсальный код товара), ZIP или Postal Code (почтовый индекс).

Атрибуты не должны использоваться для связи понятий концептуальной модели. Наиболее распространенным нарушением этого принципа является добавление некоторой разновидности атрибута внешнего ключа (foreign key attribute), что обычно происходит при разработке реляционных баз данных. Не лишним будет повторить еще раз: связывайте типы с помощью ассоциаций, а не атрибутов.

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

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

•Клиент — человек, который хочет застраховать свое имущество.

•Агент — сотрудник фирмы, оказывающей страховые услуги.

•Имущество — квартира, мебель, дорогостоящая техника.

•Страхование — процесс предоставления страховых услуг Клиенту

•Страховые услуги.

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

Ассоциации: Клиент владеет имуществом. Страховой полис включает информацию о страховых услугах и льготах.

3

Рис. 6.1. Концептуальная модель

Основные требования:

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

•Агент оказывает содействие Клиенту при заключение договора, который завершается выдачей страхового полиса.

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

6.2.2 Двух этапная разработка баз данных

Разработка базы данных делится на два этапа: инфо-логическое проектирование; физическое проектирование.

На стадии формулировки требований и стадии проектирования строится

информационно-логическую или инфо-логическая модель (ИЛМ) предметной области.

ИЛМ определяет совокупность информационных объектов, их атрибутов, их структурных связей.

Информационный объект — это именованная совокупность идентифицированных объектов, обладающих одинаковым состоянием и поведением.

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

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

При решении задачи, связанной с автоматизацией деятельности страховой фирмы, на сформированы три информационных объекта. Информационный объект КЛИЕНТ построен на основе двух понятий концептуальной модели Клиент и Имущество. Информационный объект АГЕНТ получен на основе понятия Агент концептуальной модели. Информационный объект ДОГОВОР сформирован на основе понятий Страхования, Страховые услуги, Страховые льготы. Ниже представлены атрибуты информационных объектов и их идентификаторов (идентификатор представлен как первый атрибут):

•КЛИЕНТ (Код клиента, Фамилия, Имя, Отчество, Пол, и т.д.); 4

•АГЕНТ (Код агента, Фамилия, Имя, Отчество, Пол, Дата рождения и т.д);

•ДОГОВОР (Номер, Дата, Код агента, Код клиента, и т.д).

Связи между информационными объектами отображаются реальными отношениями.

Определены следующие типы реальных отношений:

1)1:1 (Один к одному), при которых одному экземпляру первого информационного объекта соответствует один экземпляр второго информационного объекта.

2)1:М (Один ко многим), при которых одному экземпляру первого объекта соответствует множество экземпляров второго объекта, а каждому экземпляру второго объекта соответствует один экземпляр первого объекта.

3)М:N (Многие ко многим), при которых каждому экземпляру первого объекта соответствует множество экземпляров второго объекта, и каждому экземпляру второго объекта соответствует множество экземпляров первого объекта.

Примером отношения служит связь между информационными объектами поставленной здесь задачи КЛИЕНТ — ДОГОВОР.

Примером отношений М:N могла бы служить связь АГЕНТ — КЛИЕНТ.

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

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

системы управления базами данных (СУБД, DBMS - Data Base Management Systems).

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

5

6.3. Индустриальный подход к проектированию баз данных

Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information Engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу AS IS. Основным преимуществом IDEF1X, по сравнению с другими многочисленными методологиями разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком ER.

В соответствии с методологией IDEF1X создаются логическая и физическая модели данных. На стадии формулировки требований и проектирования создаются три уровня логической модели:

•Entity Relation Diagram (Диаграмма сущность-связь)

•Key-Based model (Модель данных, основанная на ключах)

•Полная атрибутивная модель.

На стадии реализации создаются физическая модель. Существует два уровня физических моделей:

•трансформационная модель (Transformation Model)

•модель СУБД.

6.3.1. Формулировка требований

На стадии формулировки требований выполняется анализ предметной области на основе информационных потребностей будущих пользователей разрабатываемой базы данных. Эту стадию также иногда называют концептуальным проектированием базы данных. Результатом концептуального проектирования является разработка модели «Сущность-связь» и выпуск технического задания.

Диаграмма сущность-связь определяет сущности и их отношения. Диаграмма сущность-связь (ERD — Entity Relationship Diagram) является самым высоким уровнем в модели данных и определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации.

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

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

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

Сущность необходимо именовать существительным в единственном лице и записывать заглавными буквами.

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. Примером сущности IDEF1X может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности.

6

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

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

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

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

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

Фактор риска <снижает риск> Страхования Отдел <состоит из> нескольких Сотрудников Самолет <перевозит> нескольких Пассажиров. Сотрудник <пишет> разные Отчеты.

Рис. 6.2

Вприведенных примерах глаголы заключены в угловые скобки. Связи отображаются

ввиде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. На рис. 6.2 приводится диаграмма связи между сущностями СТРАХОВАНИЕ и ФАКТОР РИСКА.

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

ВERwin связи представлены пятью основными элементами информации:

•тип связи;

•имя связи;

•мощность связи;

•допустимость пустых (null) значений;

•требования по обеспечению ссылочной целостности.

7

Тип связи

ERwin поддерживает следующие основные типы связей:

•идентифицирующая/неидентифицирующая,

•полная категория, неполная категория,

•многие-ко-многим.

Идентифицирующая и неидентифицирующая связи

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

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

Идентифицирующая связь изображается сплошной линией; неидентифицирующая - пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

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

Характеристическая-зависимая дочерняя сущность — это сущность, связанная только с одной родительской и хранящая информацию о характеристиках родительской сущности. Например, связь Агент – Телефон.

Ассоциативная сущность — это сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является СТРАХОВОЙ ДОГОВОР.

Именующая сущность — это частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Категориальная сущность — это дочерняя сущность в иерархии наследования. Иерархия наследования (или иерархия категорий) представляет собой особый тип

объединения сущностей, которые разделяют общие характеристики.

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

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

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

8

Рис. 6.3. Иерархия наследования: полная категория

Иерархии категорий делятся на 2 типа: полные и неполные. В полной категории одному экземпляру родового предка (сущность Сотрудник, см. рис. 6.3) обязательно соответствует экземпляр в каком-либо потомке, т е. в примере служащий обязательно является либо Администратором, либо Агентом.

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

Рис.6.4

Для создания категориальной связи следует:

•установить курсор на кнопке «Категория» в палитре инструментов и нажать левую кнопку мыши;

•щелкнуть сначала по родовому предку, а затем по потомку;

•для установления второй связи в иерархии категории следует сначала щелкнуть по символу категории, затем по второму потомку.

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу

категории и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге

9

Subtype Relationship можно указать атрибут-дискриминатор категории (список Discriminator Attribute Choice) и тип категории - полная/неполная (радио-кнопки Complete/Incomplete).

Связи типа «один-ко-одному», «один-ко-многим», «многие ко-многим»

Связи между сущностями могут быть типа

•один-ко-одному;

•один-ко-многим;

•многие ко-многим.

Связь один-ко-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности и, наоборот, один экземпляр второй сущности связан с одним экземпляром первой сущности. Обычно такая связь возникает, когда одна сущность искусственно делится на две сущности.

Связь один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности и один экземпляр второй сущности связан с одним экземпляром первой сущности. Причем первая сущность называется главной, а вторая - подчиненной.

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

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

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями.

Для связи "один ко многим" достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child).

Для связи "многие ко многим" следует указывать имя как Parent-to-Child, так и Child- to-Parent.

Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают 4 типа мощности (рис. 6.5) :

•общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;

•символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

•символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

•цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

10