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

Раздел 6. БАЗЫ ДАННЫХ
Дисциплина
Информатика
1
Тема 6.3. Разработка
инфологической модели
2
Этапы проектирования БД
АНАЛИЗ
ПРЕДМЕТНОЙ
ОБЛАСТИ
ИНФОРМАЦИОННОЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
ФИЗИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ
3
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
В результате должны быть сформулированы:
 описание входных документов, которые служат
основанием для заполнения данными базы
данных;
 подробное описание информации об объектах
предметной области и информационных
процессов;
 конкретные задачи, которые будут решаться
данной БД с кратким описанием алгоритма
решения;
 описание выходных документов, которые
должны генерироваться в системе.
4
Информационно-логическое
проектирование
Цель – обеспечение наиболее естественных для
человека способов представления той
информации, которую предполагается хранить в
создаваемой базе данных
Результат – построение независимой от СУБД
информационной структуры путем объединения
информационных требований пользователей.
Эта структура называется инфологическая
(семантическая) модель (ИЛМ)
5
Логическое проектирование
1. Выбор СУБД
2. Разработка СУБД-ориентированной схемы, которая
удовлетворяет всему диапазону требований
пользователей, начиная с требований целостности и
кончая показателями эффективности при ее
расширении и усложнении.
Физическое проектирование
1. Выбор способов размещения данных в среде хранения и
способов доступа к этим данным, которые
поддерживаются на физическом уровне
2. Окончательная отладка программных модулей
6
Инфологическая модель данных
«Сущность-связь»
Язык ER-диаграмм (Entity-Relationship, «сущность-связь»)
– средство графического изображения инфологических
моделей (Чен, 1976 г.)
Конструктивные элементы инфологических моделей:
СУЩНОСТИ
СВЯЗИ
АТРИБУТЫ
Сущность – любой различимый объект, информацию о
котором необходимо хранить в базе данных.
Информационный объект (ИнО) = Сущность
Атрибут – поименованная характеристика сущности.
Связь – зависимость одной сущности от другой
7
Графические обозначения
КНИГА
ИМЯ СУЩНОСТИ
# Шифр книги
ИМЯ КЛЮЧЕВОГО
АТРИБУТА (-ОВ)
Название книги
Объем книги
Стоимость книги
ИМЕНА ДРУГИХ
АТРИБУТОВ
Связь
ОТДЕЛ
СОТРУДНИК
# Таб_Номер
Фамилия
Имя
Отчество
Работает в
# Название
Кол_Сотр
Состоит из
8
Виды атрибутов
Обязательные и
необязательные
СОТРУДНИК
# Таб_Номер
Простой ключ
Ключевые и
неключевые
(описательные)
Составной ключ
ПОСТАВКА
# Код_Товара
# Дата_Пост
# Номер_Дог
*Фамилия
*Имя
*Отчество
*Дата_Рожд
*Кол_Детей
Сем_Полож
*Кол_Товара
*Стоимость
9
Виды связей
Один-к-Одному (1:1)
СУЩНОСТЬ1
1
1
СУЩНОСТЬ2
Одному экземпляру СУЩ1 соответствует ТОЛЬКО один
экземпляр СУЩ2. И наоборот, одному экземпляру СУЩ2
соответствует ТОЛЬКО один экземпляр СУЩ1.
ФАКУЛЬТЕТ
1
1
ДЕКАН
10
Виды связей
Один-ко-Многим (1:М)
СУЩНОСТЬ1
1
М
СУЩНОСТЬ2
Одному экземпляру СУЩ1 соответствует МНОГО
экземпляров СУЩ2. И наоборот, одному экземпляру
СУЩ2 соответствует ТОЛЬКО один экземпляр СУЩ1.
ГРУППА
1
М
СТУДЕНТ
11
Виды связей
Многие-ко-Многим (М:М)
СУЩНОСТЬ1
М
М
СУЩНОСТЬ2
Одному экземпляру СУЩ1 соответствует МНОГО
экземпляров СУЩ2. И наоборот, одному экземпляру
СУЩ2 соответствует МНОГО экземпляров СУЩ1.
КНИГА
М
М
АВТОР
12
Виды связей
Необязательная
Обязательная
СТУДЕНТ
ОЦЕНКА
1
Неключевая
М key
Ключевая
Ключевая связь :
 Может быть только с одной стороны бинарной
связи;
 Должна быть обязательной;
 Только со стороны “М”.
13
НОРМАЛИЗАЦИЯ ДАННЫХ
14
УНИВЕРСАЛЬНОЕ ОТНОШЕНИЕ
А1
А2
А3
…
Аn
15
Каждый факт в одном месте
Основная цель проектирования БД – это
сокращение избыточности хранимых данных
СЛЕДОВАТЕЛЬНО
• экономия объема используемой памяти;
• уменьшение затрат на многократные операции
обновления избыточных копий;
• устранение возможных противоречий из-за
хранения в разных местах сведений об одном и
том же объекте.
16
Пример нереляционной таблицы
Дисциплина
Преподаватель
Информатика
Гришин,
Титова,
Богословская
Соловьев,
Голубев
Математика
Рекомендуемая
литература
Книга1, Книга2,
Книга3, Книга4
Книга5, Книга 6,
Книга7
Нарушено свойство реляционных таблиц каждый элемент таблицы - один элемент данных;
17
Первая нормальная форма (1НФ)
Каждый атрибут для каждого экземпляра сущности имеет
ТОЛЬКО ОДНО значение.
Дисциплина
Преподаватель
Информатика
Гришин
Рекомендуемая
литература
Книга1
Информатика
Информатика
Информатика
Информатика
Гришин
Гришин
Гришин
Титова
Книга2
Книга3
Книга4
Книга1
…
…
…
18
Приведение к 1НФ
Операция ВСТАВКИ
В таблицу включаются дополнительные строки,
так, чтобы в каждой строке каждый атрибут
принимал единственное значение
3препод*4книги+2препод*3книги=18 строк
РЕЗУЛЬТАТ – появление избыточности данных,
множественных атрибутов.
СЛЕДСТВИЕ – наличие АНОМАЛИЙ
• Добавления
• Удаления
• Обновления
19
Первая нормальная форма (1НФ)
ИСКЛЮЧЕНИЕ МНОЖЕСТВЕННЫХ АТРИБУТОВ
СТУДЕНТ
СТУДЕНТ
1
# Фамилия
# Имя
# Отчество
ДатаРожд
Пол
Предмет
Оценка
М
ОЦЕНКА
# Предмет
Оценка
20
Вторая нормальная форма (2НФ)
1. Сущность находится в 1НФ
2. Все неключевые атрибуты функционально
полно зависят от ключа.
Функциональная зависимость является полной, если
значению ключевого атрибута соответствует ТОЛЬКО
ОДНО значение описательного атрибута.
"СТУДЕНТ" ( №
книжки, Фамилия, Имя,
№ зач.
зач.книжки,
Отчество, ДатаРожд, ДомАдрес, Пол, …)
"УСПЕВАЕМОСТЬ" (№
книжки, ФамСтуд,
№зач.
зач.книжки,
ИмяСтуд, ОтчСтуд, название
названиедисциплины,
дисциплины,
дата, Оценка, ФамПреп)
21
Примеры
функциональной
зависимости
СТУДЕНТ
# № Зач.кн
*№ группы
*Фамилия
*Имя
*Отчество
*Дата рожд.
*Адрес
*Пол
ПОСТАВКА
# Код_Товара
# Дата_Пост
# Номер_Дог
*Кол_Товара
*Стоимость
УСПЕВ-ТЬ
# № Зач.кн
# Назв.дисц
# Дата
*ФИО студ
*Оценка
*ФИО преп
22
Приведение к 2НФ
СТУДЕНТ
# Фамилия
# Имя
# Отчество
# Номер гр
* Факультет
* Курс
СТУДЕНТ
ГРУППА
# Фамилия
# Имя
# Отчество
# Номер гр
М key
1
* Факультет
* Курс
23
Третья нормальная форма (3НФ)
1. Атрибуты находятся в 1НФ и 2НФ
2. Каждый неключевой атрибут нетранзитивно
зависит от ключа.
ПОНЯТИЕ ТРАНЗИТИВНОЙ ЗАВИСИМОСТИ
Если неключевой атрибут А функционально зависит от
ключа К, а неключевой атрибут В функционально зависит
неключевого атрибута А, то, говорят, что атрибут В
транзитивно зависит от ключа К.
К—›А, А—›В, то К—›В (транзитивно)
24
Приведение к 3НФ
ИСКЛЮЧЕНИЕ ТРАНЗИТИВНЫХ ЗАВИСИМОСТЕЙ
СОТРУДНИК
СОТРУДНИК
# Таб_Номер
# Таб_Номер
*Фамилия
*Имя
*Отчество
*Должность
*Оклад
Надбавка
М
*Фамилия
*Имя
*Отчество
Надбавка
ДОЛЖНОСТЬ
1
# Название
*Оклад
25
Устранение связей типа
«МНОГИЕ-ко-МНОГИМ»
В инфологической модели не должно быть связей типа М:М
ПРЕПОД-ЛЬ
ДИСЦИПЛИНА
М
М
1
1
ПРЕП-ДИСЦ
М key
М key
26
ПРИМЕРЫ
ИНФОРМАЦИОННО-ЛОГИЧЕСКОГО
ПРОЕКТИРОВАНИЯ
27
Требования нормализации данных
1. Каждая сущность имеет уникальный
идентификатор – ключ;
2. Реквизиты, входящие в составной ключ
взаимонезависимы;
3. Любой описательный атрибут
функционально полно зависит от ключа
(зависимость описательных реквизитов
от части составного ключа не
допускается);
4. Все описательные (неключевые)
атрибуты взаимонезависимы, т.е. между
ними нет функциональных связей;
28
Каждый факт в одном месте
Одно из практических правил,
применяемых при проектировании
БД – постараться устранить из
таблиц, так называемые
множественные атрибуты – поля, у
которых значения повторяются в
разных строках таблицы.
29
Этапы проектирования
(не последовательные, а взаимосвязанные)
1. Определить объекты, подлежащие
описанию в БД.
2. Выделить атрибуты, подлежащие
описанию в БД.
3. Скомпоновать атрибуты в отдельные
таблицы. Определить ключ в каждой
таблице.
4. Установить связи между таблицами.
30
Задание ключа в таблице
1. Лучше простой ключ, чем
составной.
2. Составной ключ из
минимального числа атрибутов.
3. Лучше числовой ключ, чем
текстовый (как правило,
создается поле – КодЧегото типа
Счетчик).
4. Ключ – обязательное поле.
31
Пример 1. Поставка материалов
Цель:
Обеспечить учет поставки
материалов на предприятие
32
Выявление сущностей и атрибутов
на основе анализа входных документов
Приходный ордер №
Поставщик
(код)
(наименование)
(адрес, расч. счет)
Дата
№
п/п
1.
2.
3.
Код
матер
Наименование Цена
Ед.изм. Кол-во
Стоим-ть
ИТОГО:
33
Установлено
один поставщик осуществляет поставку различных
материалов;
один и тот же материал поставляется несколькими
поставщиками;
за определенную дату может быть осуществлена
только одна поставка отдельным поставщиком и по
одному документу;
номера документов не повторяются;
документ содержит перечень поставляемых
материалов;
цена материала не изменяется при поставке его
различными поставщиками в разное время;
справочные реквизиты поставщика не меняются
(название, адрес, расч.счет).
34
Состав атрибутов
Дата поставки
(ДП)
Приходный
ордер №
Дата
(код)
ПриходныйПоставщик
ордер № (ПрО)
(наименование)
Код поставщика (КП)
ПОСТАВЩИК
(адрес,
расч. счет)
Наименование поставщика (НП)
Адрес
(АП)
№
Код поставщика
Наименование
Цена Ед.изм. Кол-во Стоим-ть
Расчетный счет (РС)
п/п матер
МАТЕРИАЛ
1.
Код материала (КМ)
2.
Название материала (НМ)
3.
Цена материала (ЦМ)
ПОСТАВКА
ИТОГО:
Единица измерения (ЕИ)
Количество поставки (КолП)
Стоимость поставки (СП)
35
ER-диаграмма
(связи между сущностями)
МАТЕРИАЛ
ПОСТАВЩИК
# Код матер
# Код пост
1
1
ПОСТАВКА
М
key
# Дата поставки
#Код поставщика
# Код материала
М key
36
Табличное описание
выделенных сущностей
Сущность
Атрибуты
ПОСТАВЩИК
# Код поставщика (КП)
* Наименование поставщика (НП)
* Адрес поставщика (АП)
* Расчетный счет (РС)
# Код материала (КМ)
* Наименование материала (НМ)
* Цена материала (ЦМ)
* Единица измерения (ЕИ)
# Дата поставки (ДП)
# Код поставщика (КП)
# Код материала (КМ)
* Приходный ордер № (ПрО)
* Количество поставки (КолП)
* Стоимость поставки (СП)
МАТЕРИАЛ
ПОСТАВКА
Семантика
(смысловое
содержание)
Организации,
поставляющие
материалы
Номенклатура
поставляемых
материалов
Процесс
поставки
материалов
37
Схема данных
38
Пример 2. ПОЛИКЛИНИКА
Цель:
Обеспечить учет приема пациентов
врачами поликлиники
Документы:
• Расписание приема врачей
• Медкарта пациента
• Статистический талон посещения
39
Выявление сущностей и атрибутов
Ф пациента
И пациента
О пациента
Дата рожд
Медполис
Ф врача
И врача
О врача
Специализация
Дата приема
Жалобы
Диагноз
Назначения
Документ нетрудосп.
ПАЦИЕНТЫ
ВРАЧИ
СПЕЦИАЛИЗ
ПРИЕМ
ЗАБОЛЕВАНИЕ
40
ER-диаграмма
# КодСпец
НазвСпец
СПЕЦИАЛИЗ
1
М key
ПАЦИЕНТЫ
# КодПац
ВРАЧИ
1
1
М key
ПРИЕМ
М
1
Справочник
# КодВр
КодСпец
М key
# ДатаПр
# КодПац
# КодВр
ЗАБОЛЕВАНИЕ
# КодЗаб
НазвЗаб
41
Пример 3. БИБЛИОТЕКА
Цели:
1. Учет книг хранящихся в библиотеке
(каталожная карточка)
2. Учет читателей (читательский билет)
3. Учет выданных книг (читательский
билет)
42
Книга
Шифр книги (ШК)
Инв
Инв номер
номер
Авторы
Авторы
ЭКЗЕМПЛЯР
АВТОР
Название
Тематика
Издательство
ТЕМА
ИЗДАТЕЛЬСТВО
Год
43
Приведение к 1, 2, 3 НФ
1
ИЗДАТЕЛЬСТВО
М
# КодИзд
М
1
КНИГА
ЭКЗЕМПЛЯР
# КодА, ФИО
М
М
# ШК,
НазвК, Год,
Стоим,
М key
Стр
АВТОР
М
ТЕМА
# КодТ,
Описание
# ИнвНом
44
Устранение связей М:М
М key
М
key
АВТОР
1
КНИГИ
КНИГА
1
АВТОР
# КодА…
# ШК
# КодА
1
# ШК
М key
ТЕМА
КНИГИ
# ШК
# КодТ
1
М key
ТЕМА
# КодТ
45
Читатель
Множественные
атрибуты
Читательский билет (№)
Фамилия читателя
Имя читателя
Отчество читателя
Адрес читателя
Телефон читателя
Категория читателя
Экземпляр книги1
Дата выдачи1
Дата возврата1
Экземпляр книги2
Дата выдачи2
Дата возврата2
…
ЧИТАТЕЛЬ
ЗАПИСЬ В
БИЛЕТЕ
46
Связи между сущностями
КНИГА
1
# ШК, НазвК, Год,
Стоим, Стр
М key
ЭКЗЕМПЛЯР
КНИГИ
1
# ИнвНом
ЧИТАТЕЛЬ
1
# ЧБ, ФИО, ТелЧ…
М key
ЗАПИСЬ В
БИЛЕТЕ
М key
# ДатаВыд, # ИнвНом,
ДатаВоз
47
Логическое проектирование БД
ИЗДАТЕЛЬСТВО
Ключевое
поле
Ключ
Имя поля
Код_изд
Название_изд
Адрес
Телефон
Тип
данных
Счетчик
Текстовый
Текстовый
Текстовый
Примечание
20, Обязательное
50
Маска с кодом города
48
Логическое проектирование БД
КНИГА
Ключевое Имя поля
поле
Ключ
Шифр книги
Название_кн
Код_изд
Кол-во
страниц
Стоимость
Тип
данных
Текстовый
Текстовый
Мастер
подстановок
Числовой
Примечание
15, (Инд, Обяз)
50, Обязательное
Из таблицы
Издательство поле
Название_изд
Целое
Денежный
49
Логическое проектирование БД
АВТОР КНИГИ
Ключевое
поле
Ключ
Имя поля
Тип данных
Примечание
Шифр книги
Ключ
Код_автора
Мастер
подстановок
Мастер
подстановок
Из таблицы Книга
поле Название_кн
Из таблицы Автор
поля Фамилия, Имя,
Отчество
После подстановки ключевых полей из других таблиц им
присваивается тип соответственно Текстовый (такой же
как и в главной таблице) и Числовой (не Счетчик).
Поэтому важно для этих полей вручную установить
свойства Обязательное и Индексированное.
50
Логическое проектирование БД
ЗАПИСЬ В БИЛЕТЕ
Ключевое
поле
Имя поля
Ключ
Ном записи
Дата выдачи
Ключ
Инв номер
Ключ
Чит_билет
Дата возврата
Тип данных
Примечание
Счетчик
Дата/Время
Краткий формат даты
Значение по умолчанию –
Date( )
Мастер
Из таблицы Экземпляр
подстановок книги поля Шифр_книги
Мастер
Из таблицы Читатель
подстановок три поля Фамилия, Имя,
Отчество
Дата/Время Краткий формат даты
51
Схема данных
52
Пример 4. ДЕКАНАТ
Процесс обучения
студентов в вузе
Приобретение
знаний
Контроль усвоения
знаний
Студенты изучают
дисциплины.
Преподаватели ведут
дисциплины.
Студенты получают
оценки по дисциплинам.
Преподаватели ставят
оценки по дисциплинам.
53
Ограничения предметной области
Срок обучения в институте по всем специальностям
одинаковый – 5 лет (10 семестров)
Год поступления в вуз конкретного студента
отождествляется с годом образования новой группы
Год окончания вуза студентов приравнивается к году
выпуска всей группы
Один студент учится только в одной группе
54
Сущности и Связи
ПРЕПОДАВАТЕЛЬ
ДИСЦИПЛИНА
1
1
М
ПРЕПОДАВАТЕЛЬ-
М
ДИСЦИПЛИНА
ГРУППА
1
1
М
СТУДЕНТ
М
1
М
ОЦЕНКА
55
Описание таблиц
Сущность
Преподаватель
Атрибут
Код преподавателя
Фамилия
Имя
Отчество
Пол
Фотография
Дата рождения
Дата приема
Примечание
Ключевое поле
56
Описание таблиц
Сущность
Группа
Студент
Атрибут
Код группы
Обозначение
Год образования
Год окончания
Код студента
Фамилия
Имя
Отчество
Пол
Дата рождения
Код группы
Паспорт-серия
Паспорт-номер
Фотография
Атрибуты адреса
Примечание
Ключевое поле
Ключевое поле
Связь с таблицей Группа
Несколько полей
57
Сущность
Дисциплина
ПреподавательДисциплина
Атрибут
Код дисциплины
Название
Код ПД
Код преподавателя
Код дисциплины
Оценка
Код записи
Код студента
Дата
Семестр
Код ПД
Вид контроля
Оценка
Примечание
Ключевое поле
Ключевое поле
Связь с сущностью
Преподаватель
Связь с сущностью
Дисциплина
Ключевое поле
Связь с сущностью
Студент
Связь с сущностью
Преп-Дисциплина
58