Презентация на тему: Проектирование базы данных

Проектирование базы данных
План
Требования к БД
Жизненный цикл БД
Проектирование базы данных
Этапы проектирования БД
Концептуальное проектирование БД
Базовые понятия ER -методики: сущность, связь, атрибут
Типы связей в ER -модели
Класс принадлежности в ER -модели
Возможные ER -диаграммы для связи М: N c учетом класса принадлежности сущности
Пример ER -модели предметной области ФИРМА
Концептуальная схема БД ФИРМА
Преобразование ER - модели в реляционную
Преобразование ER - модели в реляционную
Преобразование ER - модели в реляционную
CASE- средства моделирования данных
Характерные особенности CASE- средств
Проектирование базы данных
Главное окно ERwin
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Проектирование базы данных
Преимущества нормальных форм таблиц
Этапы проектирования БД
Концептуальное проектирование
Логическое проектирование
Физическое проектирование
Проектирование базы данных
1/36
Средняя оценка: 4.8/5 (всего оценок: 91)
Код скопирован в буфер обмена
Скачать (2000 Кб)
1

Первый слайд презентации: Проектирование базы данных

Дунько Элеонора Михайловна К.э.н., доцент кафедры информационных технологий е- mail: dunkoaly@mail.ru

Изображение слайда
2

Слайд 2: План

Требования к БД. Этапы жизненного цикла БД. Модель «сущность-связь». CASE- средства моделирования данных. Нормализация таблиц. Этапы проектирования БД и их процедуры

Изображение слайда
3

Слайд 3: Требования к БД

Независимость данных. Совместное использование данных многими пользователями. Безопасность данных. Стандартизация построения и эксплуатации БД. Адекватность отображения данных соответствующей предметной области. 3

Изображение слайда
4

Слайд 4: Жизненный цикл БД

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

Изображение слайда
5

Слайд 5

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

Изображение слайда
6

Слайд 6: Этапы проектирования БД

концептуальное проектирование; логическое проектирование; физическое проектирование. Предложено рабочей группой CODASYL в 1971 г.

Изображение слайда
7

Слайд 7: Концептуальное проектирование БД

Концептуальная модель – абстракция предметной области, которая базируется на графических диаграммах. Популярной методикой создания концептуальной модели является методика построения модели « Сущность–Связь », называемая ER -моделью ( Entity Relationship – сущность-связь), или моделью «Объект–Отношение». Эта методика была предложена Петером Пин-Шен Ченом в 1976г.

Изображение слайда
8

Слайд 8: Базовые понятия ER -методики: сущность, связь, атрибут

Сущность – объект, информация о котором представляет интерес или часть реального мира, информация о которой хранится в БД. Связь - представляет взаимодействие между сущностями. Атрибут – свойство, характеризу- ющее сущность, каждая из которых описана своим набором атрибутов. Менеджер Филиал Клиент Заказ Предметная область ФИРМА Управляет Менеджер Табельный номер Стаж Специальность

Изображение слайда
9

Слайд 9: Типы связей в ER -модели

Менеджер Филиал Управляет Филиал Заказ Обрабатывает Клиент Заказ Делает 1 1 M 1 M N

Изображение слайда
10

Слайд 10: Класс принадлежности в ER -модели

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

Изображение слайда
11

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

Изображение слайда
12

Слайд 12: Пример ER -модели предметной области ФИРМА

В рассматриваемой предметной области ФИРМА класс принадлежности всех четырех сущностей является обязательным. УПРАВЛЯЕТ 1 1 ОБРАБАТЫВАЕТ 1 1 ДЕЛАЕТ М N МЕНЕДЖЕР ФИЛИАЛ ЗАКАЗ КЛИЕНТ M

Изображение слайда
13

Слайд 13: Концептуальная схема БД ФИРМА

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

Изображение слайда
14

Слайд 14: Преобразование ER - модели в реляционную

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

Изображение слайда
15

Слайд 15: Преобразование ER - модели в реляционную

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

Изображение слайда
16

Слайд 16: Преобразование ER - модели в реляционную

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

Изображение слайда
17

Слайд 17: CASE- средства моделирования данных

CASE -средства ( Compute r Aided System Engineering ) предназначены для автоматизированного проектирования реляционных БД. Широко распространены CASE -системы, позволяющие выполнять ER -диаграммы в соответствии со стандартом IDEF 1 X : Erwin ; Design / IDEF ; Power Designer.

Изображение слайда
18

Слайд 18: Характерные особенности CASE- средств

единый графический язык; использование репозитария; поддержка коллективной разработки и управления проектом; макетирование; генерация документации; верификация проекта; поддержка всех этапов ЖЦ БД.

Изображение слайда
19

Слайд 19

Проектирование модели данных в ERwin : Логический уровень - абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД.

Изображение слайда
20

Слайд 20: Главное окно ERwin

Изображение слайда
21

Слайд 21

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

Изображение слайда
22

Слайд 22

Первой нормальной формой называется реляционная таблица, в которой все значения полей являются атомарными, т.е. любая реляционная база данных находится в первой нормальной форме. Все заказы клиентов сведены в одну таблицу ЗаказИнфо Ном ер заказ а Код клиента Город Улица Вес з аказа Дата з аказа Код валюты Наименование валюты 1021 АА Минск Правды 11 100 01.02.0 6 100 Бел рубль 1022 АА Минск Правды 11 150 01.02.0 6 100 Бел рубль 1023 АС Пуховичи Широкая 1 300 10.03.0 6 101 Росс рубль 1024 АС Пуховичи Широкая 1 400 1 1.03.0 6 101 Росс рубль 1025 АС Пуховичи Широкая 1 700 1 2.03.0 6 103 Евро 1026 АС Пуховичи Широкая 1 230 10.03.0 6 101 Росс рубль 1027 АС Пуховичи Широкая 1 120 15.04.0 6 101 Росс рубль 1028 АС Пуховичи Широкая 1 100 15.04.0 6 102 Доллар США 1029 АС Пуховичи Широкая 1 300 15.04.0 6 101 Росс рубль 1030 АВ Мюнхен Лейбниц а 8 500 20.04.0 6 103 Евро 1031 АВ Мюнхен Лейбниц а 8 500 20.04.0 6 103 Евро 1032 АД Минск Захарова 20 300 08.05.0 6 102 Доллар 1033 АС Пуховичи Широкая 1 200 15.05.0 6 101 Росс рубль 1034 АС Пуховичи Широкая 1 300 15.05.0 6 101 Росс рубль

Изображение слайда
23

Слайд 23

Таблицы в первой нормальной форме являются, как правило, избыточными, например сведения о клиенте (Код клиента, Адрес) повторяется в записи о каждом заказанном продукте. Проблемы такой таблицы: Узнаем адрес клиента, только в том случае если он что- то заказал При удалении записи о продукте одновременно удаляются все сведения о самом заказе и о клиенте Если сменил адрес, например, то его надо менять в каждой записи Вывод: Данные в таблице необходимо нормализовать путем разбиения исходной таблицы на несколько таблиц, связанных первичными и внешними ключами. Ном ер заказ а Код клиента Город Улица Вес з аказа Дата з аказа Код валюты Наименование валюты 1021 АА Минск Правды 11 100 01.02.0 6 100 Бел рубль 1022 АА Минск Правды 11 150 01.02.0 6 100 Бел рубль 1023 АС Пуховичи Широкая 1 300 10.03.0 6 101 Росс рубль 1024 АС Пуховичи Широкая 1 400 1 1.03.0 6 101 Росс рубль 1025 АС Пуховичи Широкая 1 700 1 2.03.0 6 103 Евро 1026 АС Пуховичи Широкая 1 230 10.03.0 6 101 Росс рубль 1027 АС Пуховичи Широкая 1 120 15.04.0 6 101 Росс рубль 1028 АС Пуховичи Широкая 1 100 15.04.0 6 102 Доллар США … ... … … … … … … 1034 АС Пуховичи Широкая 1 300 15.05.0 6 101 Росс рубль

Изображение слайда
24

Слайд 24

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

Изображение слайда
25

Слайд 25

Ном ер заказ а Код клиента Город Улица Вес з аказа Дата з аказа Код валюты Наименование валюты 1021 АА Минск Правды 11 100 01.02.0 6 100 Бел рубль 1022 АС Пуховичи Широкая 1 300 10.03.0 6 101 Росс рубль 1024 АВ Мюнхен Лейбниц 8 500 20.04.0 6 103 Евро 1025 АД Минск Захарова 20 300 08.05.0 6 102 Доллар 1-й шаг нормализации: Для связывания в дальнейшем таблиц, получаемых из Таблицы ЗаказИнфо определим первичный ключ. Такое поле рекомендуется выбирать из тех полей, записи в которых являются избыточными: определим поле Код клиента в качестве первичного ключа. По определению ссылочной целостности первичный ключ не должен содержать повторяющихся записей, поэтому первая промежуточная таблица, назовем ее ЗаказИнфо1, будет содержать только неповторяющееся записи Кода клиента. В исходной таблице поле Код клиента определяется как внешний ключ В исходной таблице поле Код клиента определяется как внешний ключ

Изображение слайда
26

Слайд 26

2-й шаг нормализации: В исходной таблице определяем поля, которые зависят только от первичного ключа, т.е. их значения не меняются при одинаковом значении записи первичного ключа: поля Город и Улица. Только эти поля остаются в таблице ЗаказИнфо1, остальные поля удаляются. Таблицу ЗаказИнфо1 переименуем в таблицу Клиенты. Из исходной таблицы ЗаказИнфо эти же поля удаляются и исходную таблицу ЗаказИнфо переименовываем в таблицу ЗаказИнфо2.

Изображение слайда
27

Слайд 27

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

Изображение слайда
28

Слайд 28

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

Изображение слайда
29

Слайд 29

2-й шаг нормализации В таблице ЗаказИнфо2, находящейся во второй нормальной форме, определим поле Код валюты в качестве первичного ключа. Полностью от этого поля зависит только поле Наименование валюты. Из таблицы ЗаказИнфо2 выбираются только уникальные (неповторяющиеся) записи Код Валюты, и из полей Код Валюты и Наименование получается третья таблица Банк. Из таблицы ЗаказИнфо2 удаляется поле Наименование валюты и таблица ЗаказИнфо2 переименовывается в таблицу Заказы 1-й шаг нормализации 3-й шаг нормализации Объединяются Таблицы Клиенты, Заказы и Банк с помощью первичных и внешних ключей

Изображение слайда
30

Слайд 30

Код валюты Наименование валюты 100 Бел рубль 101 Росс рубль 102 Доллар США 103 Евро Банк Банк Код клиента Ном ер заказ а Вес з аказа Дата з аказа Код валюты АА 1021 100 01.02.0 6 100 АА 1022 150 01.02.0 6 100 АС 1023 300 10.03.0 6 101 АС 1024 400 1 1.03.0 6 101 АС 1025 700 1 2.03.0 6 103 АС 1026 230 10.03.0 6 101 АС 1027 120 15.04.0 6 101 АС 1028 100 15.04.0 6 102 АС 1029 300 15.04.0 6 101 АВ 1030 500 20.04.0 6 103 АВ 1031 500 20.04.0 6 103 АД 1032 300 08.05.0 6 102 АС 1033 200 15.05.0 6 101 АС 1034 300 15.05.0 6 101 Заказы Структура базы данных в третьей нормальной форме:

Изображение слайда
31

Слайд 31: Преимущества нормальных форм таблиц

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

Изображение слайда
32

Слайд 32: Этапы проектирования БД

концептуальное проектирование; логическое проектирование; физическое проектирование. Предложено рабочей группой CODASYL в 1971 г.

Изображение слайда
33

Слайд 33: Концептуальное проектирование

Цель этапа концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Этапы: Определение сущностей. Определение связей между сущностями. Создание ER -модели предметной области. Определение атрибутов. Определение значений атрибутов. Определение первичных ключей для сущностей. Обсуждение концептуальной модели данных с конечными пользователями. Обязательное документирование каждого этапа!

Изображение слайда
34

Слайд 34: Логическое проектирование

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

Изображение слайда
35

Слайд 35: Физическое проектирование

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

Изображение слайда
36

Последний слайд презентации: Проектирование базы данных

Спасибо за внимание!

Изображение слайда