Лекция 3

Раздел 2. Проектирование баз данных

Жизненный цикл информационной системы

Типичная автоматизированная информационная система (ИС) включает следующие компоненты:

• База данных.

• Программное обеспечение базы данных.

• Прикладное программное обеспечение.

• Аппаратное обеспечение, в том числе устройства хранения.

• Персонал, использующий и разрабатывающий систему.

Жизненный цикл любой ИС, основанной на базе данных, обычно состоит из нескольких этапов:

1. планирование;

2. сбор и анализ требований к системе;

3. проектирование системы (в том числе проектирование базы данных);

4. создание прототипа;

5. реализация;

6. тестирование;

7. преобразование;

8. сопровождение.

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

Рис. 6. Жизненный цикл информационной системы

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

Планирование разработки базы данных .Планирование самого эффективного способа реализации этапов жизненного цикла системы.

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

Сбор и анализ требований пользователей. На этом этапе производится сбор и анализ требований пользователей из всех возможных областей применения БД.

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

Выбор целевой СУБД. Выполняется подбор наиболее подходящей СУБД для приложения базы данных.

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

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

Реализация. Создание внешнего, концептуального и внутреннего определений базы данных и прикладных программ.

Конвертирование и загрузка данных (первичное наполнение). Преобразование и загрузка данных (и прикладных программ) из старой системы в новую.

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

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

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

Этапы проектирования баз данных

Основная цель проектирования БД – это сокращение избыточности хранимых данных.

При проектировании базы данных решаются две основных проблемы:

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

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

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

Рис. 7. Этапы проектирования базы данных

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

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

Затем компонуется концептуальная инфологическая модель, основное значение при этом имеют потребности пользователей. Описывается информация, требуемая каждому конкретному пользователю, т.е. описываются запросы к БД. Каждый запрос соотносится с определенным фрагментом предметной области. Формируются описания внешних инфологических моделей, их взаимная увязка с концептуальной инфологической моделью. Полученные описания инфологических моделей отражают составляющие (сущности) предметной области, связи между ними, но эти описания не должны зависеть от методов представления данных в конкретной СУБД. Концептуальная инфологическая модель призвана обеспечить прочную и долговременную работу всей системы, выдерживать замену одной используемой СУБД на другую.

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

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

Инфологическое проектирование базы данных

Модель «сущность-связь» в проектировании БД.

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

Основное назначение неформальной модели «сущность-связь» – семантическое описание предметной области и пред­ставление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе.

Модель «сущность-связь» (Entity-Relationship model, ER-модель) разработана Питером Пин-Шен Ченом (Peter Pin-Shen Chen, американский профессор компьютерных наук) в 1976 году с целью упрощения концептуального проектирования БД.

ER-диаграмма – графическое представление ER-модели, определяющее данные и отношения между ними.

Основными элементами ER-модели являются:

• сущности;

• атрибуты;

• связи.

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

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

Атрибут – это поименованная характеристика сущности, которая принимает значения из некоторого множества значений. Например, для описа­ния свойств сущности «Книга» можно использовать атрибуты «На­звание», «Фамилия Автора», «Год Издания». Основное назначение атрибута – описание свойства сущнос­ти, а также идентификация экземпляров сущностей. На ER-диаграммах атрибут представляется овалом (эллипсом), соединенным с соответствующей сущностью линией.

Домен – множество значений, которые может принимать атрибут.

Атрибуты делятся на:

• простые;

• составные;

• однозначные;

• многозначные;

• производные.

Простой атрибут состоит из одного компонента с независимым существованием.

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

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

Многозначный атрибут может содержать несколько значений для одного экземпляра сущности.

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

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

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

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

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

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

Пример ER-диаграммы с обозначениями сущностей, их атрибутов и связей представлен на рис. 10.

Рис. 10. Пример ER-диаграммы

Степень связи – количество сущностей, которые охвачены данной связью. Если связь определена между двумя сущностями, то ее степень – 2 (бинарная связь). Связь между тремя сущностями называется тернарной, четырьмя сущностями – кватернарной и т.д. В общем случае связь между п сущностями называется n-арной. Примеры различных связей представлены на рис. 11 – рис. 14.

Рис. 11. Пример бинарной связи (между двумя сущностями)

Рис. 12. Пример тернарной связи (между тремя сущностями)

Рис. 13. Пример кватернарной связи (между четырьмя сущностями)

Рис. 14. Пример унарной (рекурсивной) связи

Рекурсивная связь – связь, в которой одни и те же сущности участвуют несколько раз в разных ролях. Рекурсивную связь часто называют унарной. В приведенном примере (рис. 14) каждый студент из сущности СТУДЕНТ может исполнять обязанности дежурного по отношению к другим студентам той же сущности.

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

Класси­фикация бинарных связей.

Отображение 1:1 (связь «один к одному»). С помощью ото­бражения 1:1 (рис. 15, а) определяют такой тип связи между ти­пами сущностей А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и, на­оборот, каждому экземпляру сущности В соответствует один и только один экземпляр сущности А. Это означает, что один эк­земпляр сущности, от которого направлена связь, например, А, идентифицирует один и только один экземпляр другой сущнос­ти В (к которому направлена связь), и наоборот. Идентификация экземпляров сущностей уникальна в обоих направлениях для отображений 1:1.

Рис. 15. Схемы бинарных связей двух типов сущностей прямого и об­ратного отображения: а – связь «один к одному»; б – связь «один ко многим»; в – связь «многие к одному»; г – связь «многие ко многим».

Отображение 1: М (связь «один ко многим»). С помощью отображения 1: М (рис. 15, б) определяется тип связи между ти­пами сущностей А и В, когда одному экземпляру сущности А может соответствовать 0, 1 или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А. Это означает, что с одним экземп­ляром сущности А может быть связано либо несколько экземпля­ров сущности В, либо один, либо ни одного. Но при этом каж­дый экземпляр сущности В связан только с одним экземпляром сущности А, т. е. идентификация экземпляров при отображении 1: М уникальна только в направлении от В к А.

Отображение М : 1 (связь «многие к одному»). Это отобра­жение является обратным отображению 1: М (рис. 15, в).

Отображение M : N (связь «многие ко многим»). С помо­щью отображения М: N (рис. 15, г) определяется тип связи между типами сущностей А и В, при котором каждому экземпляру сущ­ности А может соответствовать 0, 1 или несколько экземпляров сущности В и наоборот. С одним экземпляром сущности А мо­жет быть связано либо несколько экземпляров сущности В, либо один, либо ни одного. И наоборот, с одним экземпляром сущно­сти В также может быть связано либо несколько экземпляров сущности А, либо один, либо ни одного, т.е. идентификация эк­земпляров сущностей не уникальна в обоих направлениях.

Различают простую и многозначную связь.

При простой (рис. 16) однонаправленной связи от сущно­сти А к сущности В одному и тому же экземпляру сущности А со­ответствует один и тот же экземпляр сущности В. При этом об­ратная связь не определена. Идентификация экземпляров сущно­сти В экземплярами сущности А – уникальна (однозначна).

При многозначной (рис. 17) однонаправленной связи от сущности А к сущности В одному и тому же экземпляру сущ­ности А соответствует 0, 1 или несколько экземпляров сущно­сти В. При этом обратная связь не определена. Идентифика­ция экземпляров сущности В экземплярами сущности А не уникальна.

Рис. 16. Простая однонаправленная связь: а – общий вид; б – пример связи

Рис. 17. Пример графической диаграммы сущностей и связей

в отделе управления

Примеры связей:

Рис. 18. Связь один к одному (1:1)

Рис. 19. Связь один ко многим (1:M)

Рис. 20. Связь многие ко многим (M:M)

Рис. 21. Пример множества связей между сущностями

ПРЕПОДАВАТЕЛЬ и СТУДЕНТ