Проектирование баз данных

Технологии баз данных и знаний

Лекция 04

 

 

ПРОЕКТИРОВАНИЕ  БАЗ ДАННЫХ Ч.1

 

 

4.1 Требования, предъявляемые к базе данных. 

Этапы жизненного цикла базы данных

 

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

Эти требования следующие.

1. Целостность базы данных. (Требование полноты и непротиворечивости данных).
2. Многократное использование данных.
3. Быстрый поиск и получение информации по запросам пользователей.
4. Простота обновления данных.
5. Уменьшение излишней избыточности данных.
6. Защита данных от несанкционированного доступа, от искажения и уничтожения.

 

Жизненный цикл базы данных (ЖЦБД) –  это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из следующих семи этапов:

1. предварительное планирование;
2. проверка осуществимости;
3. определение требований;
4. концептуальное проектирование;
5. логическое проектирование;
6. физическое проектирование;
7. оценка работы и поддержка базы данных.

Опишем главные задачи каждого этапа.

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

2. Проверка осуществимости. Она предполагает подготовку отчетов по трем вопросам:

1. есть ли технология – необходимое оборудование и программное  обеспечение – для реализации запланированной базы данных? (технологическая осуществимость);
2. имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных? (операционная осуществимость);
3. окупится ли запланированная база данных? (экономическая эффективность).

3. Определение требований. На этом этапе определяются:

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

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

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

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

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

 

4.2 Модель «сущность–связь»

 

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

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

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

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

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

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

 

 

 

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

В рассматриваемой предметной области ФИРМА можно выделить три связи:

 

1. МЕНЕДЖЕР  – УПРАВЛЯЕТ – ФИЛИАЛ
2. ФИЛИАЛ  – ОБРАБАТЫВАЕТ – ЗАКАЗ
3. КЛИЕНТ  – ДЕЛАЕТ – ЗАКАЗ

 

 

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

Например,

 

 

 

 

 

 

Важной характеристикой связи является тип связи (кардинальность).

Рассмотрим типы выше указанных связей 1–3.

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

    

 

 

 

 

 

 

 

 

 

Так как филиал обрабатывает несколько заказов, а заказ обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности ЗАКАЗ, а каждый экземпляр сущности ЗАКАЗ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. 

В этом случае связь 2 имеет тип «один-ко-многим» (1:М). На рис. 4.2 представлена ER-диаграмма для связи типа 1:М.

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

 

 

 

 

 

 

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

Предположим, что в  рассматриваемой предметной области ФИРМА класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области ФИРМА будет иметь вид, представленный на рис. 4.5.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

набором атрибутов (рис. 4.6).

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

 

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

 

Рис. 4.6. Наборы атрибутов сущностей предметной области ФИРМА

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

 

 

 

4.2 Преобразование ER- модели в реляционную

 

 

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

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности.

 

Правило 1

 

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

 

На ER-диаграмме связи 1:1, представленной на рис. 4.1, класс принадлежности сущностей МЕНЕДЖЕР,  ФИЛИАЛ является обязательным. Тогда согласно правилу 1 должна быть сгенерирована одна таблица следующей структуры:

 

 

 

МЕНЕДЖЕР–ФИЛИАЛ

 

НМ

СТАЖ

СПЕЦ

НФ

АДР_Ф