Лекция 3. Этапы проектирования БД. Концептуальная модель

Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

Основные задачи:

1. Обеспечение хранения в БД всей необходимой информации.

2. Обеспечение возможности получения данных по всем необходимым запросам.

3. Сокращение избыточности и дублирования данных.

4. Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Рисунок 3.1

Концептуальное (инфологическое) проектирование — построение семантической (смысловой) модели предметной области. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «модель базы данных», «модель предметной области», «концептуальная модель», «концептуальная модель базы данных», «концептуальная модель предметной области» и «инфологическая модель» являются синонимами.

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

Чаще всего концептуальная модель базы данных включает в себя:

· описание информационных объектов, или понятий предметной области и связей между ними;

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

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

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

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

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

Рисунок 3.2

Модель "сущность–связь"

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

Основные понятия ER-диаграммы – сущность, атрибут, связь.

Сущность – это некоторый объект реального мира, который может существовать независимо. Сущность имеет экземпляры, отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию. Атрибут – это свойство сущности. Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом "наименование". Атрибут, который уникальным образом идентифицирует экземпляры сущности, называется ключом. Может быть составной ключ, представляющий комбинацию нескольких атрибутов.

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

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

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

В рассматриваемой предметной области БАНК можно выделить три связи.

1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – СЧЕТ

3. КЛИЕНТ – ИМЕЕТ – СЧЕТ

На ER-диаграмме связь изображается ромбом. Например,

Важной характеристикой связи является тип связи (кардинальность). Рассмотрим типы связей 1–3.

Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1 имеет тип "один-к-одному" (1:1). На рисунке 3.3 представлена ER-диаграмма для связи типа 1:1.

Рисунок 3.3 – ER-диаграмма связи 1:1

Так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 2 имеет тип "один-ко-многим" (1:М). На рисунке 3.4 представлена ER-диаграмма для связи типа 1:М.

Рисунок 3.4 – ER-диаграмма связи 1:М

Так как счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ. В этом случае связь 3 имеет тип "многие-ко-многим" (М:N). На рисунке 3.5 представлена ER-диаграмма для связи типа М:N.

Рисунок 3.5 – ER-диаграмма связи M:N

Рассмотрим понятие класс принадлежности сущности.

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

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

В качестве примера на рисунке 3.6 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.

Рисунок 3.6 – ER-диаграммы связи М:N с учетом

класса принадлежности сущности

На ER-диаграмме 1 класс принадлежности обеих сущностей необязательный.

На ER-диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности СЧЕТ необязательный.

На ER-диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности СЧЕТ обязательный.

На ER-диаграмме 4 класс принадлежности обеих сущностей обязательный.

Предположим, что в рассматриваемой предметной области БАНК класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области БАНК будет иметь вид, представленный на рисунке 3.7.

Каждая из четырех сущностей приведенной ER-модели может быть описана своим набором атрибутов (рис. 3.8).

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

В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в автоматизированном проектирования реляционных баз данных.

Рисунок 3.7 – Пример ER–модели предметной области БАНК

МЕНЕДЖЕР		ФИЛИАЛ
Номер менеджера (НМ)		Номер филиала (НФ)
Стаж работы (СТАЖ)		Адрес филиала (АДР_Ф)
Специальность (СПЕЦ)
		КЛИЕНТ
СЧЕТ		Номер клиента (НК)
Номер счета (НС)		Ф.И.О. клиента (ФИО_К)
Тип счета (ТИП)		Социальное положение (СОЦ)
Остаток на счете (ОСТ)		Адрес клиента (АДР_К)

Рисунок 3.8 – Наборы атрибутов сущностей предметной области Банк

Примечание. Ключевые атрибуты выделены жирным шрифтом.

http://www.site-do.ru/db/db4.php - пример концептуальной модели

http://www.site-do.ru/db/db5.php - преобразование в реляционную (до процесса нормализации)

Дата добавления: 2014-01-03