Проектирование БД

1. Проектирование БД

1

2.

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

3.

ЭТАПЫ РАЗРАБОТКИ РЕЛЯЦИОННОЙ
БАЗЫ ДАННЫХ.
Понятие предметной области и модели
предметной области.
Критерии оценки качества логической
модели
данных
3

4. ЭТАПЫ РАЗРАБОТКИ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

При разработке базы данных можно
выделить следующие уровни:
1. Сама предметная область.
2. Модель предметной области.
3. Инфологическая модель данных.
4. Даталогическая модель данных.
5. Собственно база данных и приложения.
4

5.

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

6.

• Модель предметной области - это
наши знания о предметной области.
Модель предметной области описывает
процессы, происходящие в предметной
области и данные, используемые этими
процессами.
6

7.

В качестве средств описания модели могут
выступать:
• текстовые описания предметной области,
• наборы должностных инструкций,
• правила ведения дел в компании и т.п.
7

8.

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

9.

Имеется большое количество методик
описания
предметной
области.
Из
наиболее
известных
можно
назвать
диаграммы потоков данных, методику
объектно-ориентированного
анализа
UML, и др.
9

10.

• Информационнологическая (инфологическая)
предметной области
модель
Модель описывает
1. понятия предметной области,
2. взаимосвязь понятий предметной области,
3. ограничения на данные, налагаемые
предметной областью.
10

11.

Примеры понятий - "сотрудник", "отдел",
"проект", "зарплата".
Примеры взаимосвязей между понятиями
- "сотрудник числится ровно в одном
отделе", "сотрудник может выполнять
несколько проектов", "над одним проектом
может работать несколько сотрудников".
Примеры ограничений - "возраст
сотрудника не менее 18 и не более 60 лет".
11

12.

Инфологическая модель данных является
начальным прототипом будущей базы
данных.
Эта модель строится без привязки к
конкретной СУБД.
Основным
средством
разработки
логической модели данных являются
различные варианты ER-диаграмм (EntityRelationship, диаграммы сущность-связь).
12

13.

Одну и ту же ER-модель можно
преобразовать как в реляционную
модель данных, так и в модель данных
для иерархических и сетевых СУБД,
или в постреляционную модель
данных.
13

14.

Даталогическая модель данных.
Даталогическая
модель
данных
описывает
данные
средствами
конкретной СУБД.
14

15.

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

16.

Ограничения, имеющиеся в логической
модели данных, реализуются различными
средствами СУБД, например, при помощи
индексов, декларативных ограничений
целостности,
триггеров,
хранимых
процедур.
16

17.

• Собственно база данных и
приложения.
17

18.

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

19. Критерии оценки качества логической модели данных

19

20.

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

21.

Для того чтобы база данных удовлетворяла
критерию адекватности предметной области,
должны выполняться следующие условия:
• Состояние базы данных в каждый момент
времени должно соответствовать состоянию
предметной области.
• Ограничения предметной области, отраженные в
модели предметной области, должны отражаться
и учитываться в базе данных.
Для того чтобы база данных удовлетворяла этим
критериям, она должна быть приведена к
третьей нормальной форме.
21

22.

Основой логического проектирования базы данных
является системный анализ предметной области,
в результате которого определяются:
1.
цели разработки БД,
2.
описание объектов предметной области и связей
между объектами,
3.
на данном этапе должны быть выяснены вопросы
о том, какие пользователи будут работать с базой
данных, какие задачи они будут решать.
22

23.

Этапы работы над
моделью данных.
23

24.

I этап. Подготовка Технического задания
(постановка задачи).
Выполняется следующий комплекс работ:
• определение экономической целесообразности
и технической возможности создания базы данных;
• выявление
состава,
содержания
и
характеристик хранимой информации на основе
результатов обследования предметной области;
24

25.

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

26.

выбор СУБД.
По результатам выполнения этого этапа
создается техническое задание (ТЗ).
26

27.

II этап. Технический проект. На данном этапе
выполняются следующие работы:
уточнение инфологической модели;
создание датологической модели;
проектирование программного обеспечения.
27

28.

III этап. Рабочий проект..
Выполняется следующий комплекс
работ:
• создание программных средств и
сервисных программ;
• подготовка контрольного примера;
• разработка должностных инструкций
для пользователей.
28

29.

IV этап. Внедрение проекта
Осуществляется заполнение БД реальной
информацией.
Выполнятся
проверка
проектных решений и их доводка, при
необходимости дорабатывается технология
работы с базой данных, пользователями.
29

30.

Логическое проектирование данных
30

31.

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

32.

32

33.

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

34.

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

35.

Основные проблемы, имеющие место
при определении структуры данных в
отношениях реляционной модели:
избыточное
данных
и
редактирования.
дублирование
аномалии
35

36.

Следует различать избыточное и
неизбыточное
дублирование
данных.
36

37.

Пример неизбыточного дублирования
37

38.

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

39. Пример избыточного дублирования:

Так как три последних сотрудника находятся в одной и той же комнате, их номера
телефона можно узнать из кортежа, относящегося к первому из сотрудников,
находящемуся в комнате 101, а остальные номера- избыточны.
39

40.

Сотрудник__телефон__комната
40

41.

Способ устранения избыточности в данном отношении неудачен по
следующим причинам:
• при программировании потребуются дополнительные усилия на
создание механизмов поиска информации для прочерков таблицы;
• память под поля с прочерками все равно выделяется;
• при исключении из списка первого сотрудника, для которого указан
№ телефона, будет уничтожена информация о номере телефона в
данной комнате.
Возможный выход из данной ситуации: исходное отношение
разбивается на два отношения, т.е. выполняется декомпозиция
отношений.
41

42.

42

43. Нормальные формы

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

44.

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

45.

Пример: создается БД, содержащая
сведения о преподавателях и их
нагрузке.
Проектирование БД начинается с
определения всех объектов, сведения о
которых будут включены в базу и
определения их атрибутов. Затем
атрибуты сводятся в одну таблицу.
45

46.

Исходное отношение имеет следующие атрибуты:
Преподаватель_Занятия(ФИО, Должность,
Оклад, Стаж, Надбавка за стаж, Кафедра,
Предмет, Группа, Вид_занятий, Часы).
46

47.

Преподаватель_Занятия
47

48.

Исходное отношение содержит избыточное
дублирование данных. Эта избыточность
может быть явной и неявной.
Явная избыточность заключается в том, что
сведения о преподавателях, проводящих
занятия в нескольких группах, по
нескольким
предметам
повторяются
соответствующее число раз.
48

49.

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

50.

Основные цели нормализации БД:
• исключение избыточного дублирования
данных;
• обеспечение быстрого доступа к данным;
• обеспечение ссылочной целостности данных т.о,
чтобы
при
изменении
одних
объектов
автоматически происходило изменение всех
связанных с ними объектов.
50

51.

Метод нормализации отношений основан
на
фундаментальном
в
теории
реляционных БД понятии зависимости
между атрибутами отношений.
51

52.

13. Зависимости между
атрибутами
отношений
(функциональные,
многозначные,
транзитивные)
52

53. ЗАВИСИМОСТИ МЕЖДУ АТРИБУТАМИ ОТНОШЕНИЙ

Основные виды зависимостей между
атрибутами отношений:
• функциональные,
• многозначные,
• транзитивные.
53

54.

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

55. Определение функциональной зависимости:

Атрибут В функционально зависит от
атрибута А, если каждому значению А
соответствует в точности одно значение В.
Aтрибут А функционально определяет
атрибут B (A является детерминантом
(определителем) для B, а B является
зависимым от A)
55

56.

А->В
А и В могут быть составными, то
есть состоять из двух и более
атрибутов.
56

57.

57

58.

Примеры функциональных зависимостей в
отношении Преподаватель_Занятия
ФИО -> ДОЛЖНОСТЬ,
ДОЛЖНОСТЬ -> ОКЛАД,
ФИО, Предмет, Группа, Вид_занятий -> Часы
58

59.

В отношении Преподаватель_Занятия
первичный ключ является составным и
состоит из атрибутов ФИО, Предмет,
Группа, Вид_занятий.
59

60.

Атрибут Предмет входит в первичный ключ, т.к.
преподаватель может вести разные предметы, атрибут
Вид занятий входит в первичный ключ, т.к.
преподаватель может проводить и лекционные и
лабораторные занятия по одному и тому же предмету,
атрибут Группа входит в первичный ключ т.к.
преподаватель может проводить один и тот же вид
занятий по одному и тому же предмету в разных группах.
Значения атрибута Часы находятся в зависимости от
комбинации
атрибутов
ФИО,
Предмет,
Группа,
Вид_занятий.
60

61.

Частичной функциональной зависимостью называют
зависимость неключевого атрибута от части составного
ключа.
ФИО, Предмет, Группа, Вид_занятий -> Часы
ФИО -> ДОЛЖНОСТЬ
В рассматриваемом отношении атрибут Должность
находится в функциональной зависимости от атрибута
ФИО, являющегося частью составного ключа. Тем
самым атрибут должность находится в частичной
зависимости от ключа отношения.
61

62.

ФИО, Предмет, Группа, Вид_занятий -> Часы
62

63.

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

64. Определение транзитивной зависимости:

Атрибут С зависит от атрибута А
транзитивно, если для атрибутов А,В,С
выполняется А->В и В->С, но обратная
зависимость отсутствует.
Пример транзитивной зависимости
ФИО->Должность->Оклад.
64

65.

Между
атрибутами
может
многозначная зависимость.
быть
В отношении R атрибут В многозначно
зависит от атрибута А, если каждому
значению А соответствует множество
значений В, не связанных с другими
атрибутами из R.
65

66.

Многозначные зависимости могут быть.
«один-ко-многим»(1:М),
многие
к
одному(М:1) или многие ко многим(М:М).
Например,
если
преподаватели
ведут
несколько предметов, а каждый предмет
может вестись несколькими преподавателями,
то имеет место зависимость(М:М) между
атрибутами ФИО и Предмет.
66

67.

67

68. Выявим функциональные зависимости между атрибутами отношения Преподаватель_Занятия

• ФИО -> Оклад
• ФИО -> Должность
• ФИО -> Стаж
• ФИО -> Надб
• ФИО -> Каф
• Стаж -> Надбавка
• Должн -> Оклад
• ФИО.Предмет.Группа. Вид_зан -> Часы
68

69.

После того, как выделены все функциональные
зависимости,
следует
проверить
их
согласованность с данными исходного
отношения. Например, Должность “доцент” и
Оклад “20000” должны соответствовать друг
другу во всех кортежах, так как имеет место
функциональная зависимость
Должн->Оклад.
Так же следует проверить и остальные данные.
69

70.

70

71. Нормальные формы

Первая нормальная форма. Таблица в первой
нормальной форме должна удовлетворять
следующему требованию:
Все атрибуты отношения являются простыми
(имеют единственное значение).
Исходное отношение строится таким образом,
чтобы его атрибуты были простыми.
71

72.

72

73.

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

74.

Исходное отношение Преподаватель_Занятия имеет
составной ключ ФИО, Предмет, Группа, Вид_занятий
и находится 1НФ.
Преподаватель_Занятия(ФИО, Должность,
Оклад, Стаж, Надбавка за стаж, Кафедра,
Предмет, Группа, Вид_занятий, Часы).
В этом отношении можно выделить частичную зависимость
атрибутов Стаж, Надбавка, Должность, Оклад, Кафедра от
первичного ключа - указанные атрибуты находятся в
функциональной
зависимости
от
атрибута
ФИО,
являющегося частью составного ключа.
74

75.

75

76.

Эта частичная зависимость приводит к следующему:
в отношении присутствует явное избыточное
дублирование данных, например:
повторение
данных о стаже, должности и окладе преподавателей,
проводящих занятия в нескольких группах и/или по
разным предметам;
Следствием избыточного дублирования данных
является проблема их редактирования. Например,
изменение должности у преподавателя Иванова
потребует просмотра всех кортежей отношения и
внесения изменений в те из них, которые содержат
сведения о данном преподавателе.
Часть избыточности устраняется при переводе отношения
в 2НФ.
76

77. Определение 2 НФ.

Отношение находится во 2-й нормальной
форме, если оно находится в первой
нормальной форме и каждый неключевой
атрибут функционально полно зависит от
первичного ключа (составного).
Функционально полная зависимость неключевых
полей заключается в том, что каждый неключевой
атрибут функционально зависит от ключа, но не
находится в функциональной зависимости ни от какой
части ключа.
77

78.

Преподаватель_Занятия(ФИО,
Должность, Оклад, Стаж, Надбавка за
стаж, Кафедра, Предмет, Группа,
Вид_занятий, Часы).
78

79.

Для устранения частичной зависимости и
перевода отношения в 2НФ необходимо,
используя операцию проекции, разложить
его на несколько отношений следующим
образом:
• построить отношение без атрибутов,
находящихся в частичной функциональной
зависимости от первичного ключа;
• построить отношения, включающие
части составного первичного ключа и
атрибуты, зависящие от этих частей.
В результате получим два отношения,
находящиеся во 2НФ
79

80.

80

81.

Перевод отношения во вторую нормальную
форму
позволил
исключить
явную
избыточность
данных
в
таблице
Преподаватель_Занятия – повторение строк
со сведениями о преподавателях.
В отношении Преподаватели по-прежнему
имеет место неявное дублирование данных:
повторение окладов для преподавателей,
занимающих одинаковую должность и
надбавок - для преподавателей, имеющих
одинаковый стаж. Необходимо преобразовать
это отношение в 3НФ.
81

82. Третья нормальная форма

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

83.

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

84.

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

85. ФИО -> Должность -> Оклад ФИО -> Стаж -> Надб

ФИО -> Должность -> Оклад
ФИО -> Стаж -> Надб

86.

Преобразуем отношение Преподаватели
так, чтобы исключить транзитивные
зависимости.
В результате получим из него отношения
Преподаватели1 (ФИО, должность, стаж,
кафедра)
Должностные_ оклады (Должность, Оклад)
Надбавки(Стаж, надбавка)
86

87.

87

88.

Первоначальное определение, данное Коддом
для ЗНФ не во всех случаях оказывается
удовлетворительным.
В
частности,
оно
неадекватно если отношение имеет два (или
больше) потенциальных ключа, таких, что эти
потенциальные ключи являются составными.
Поэтому впоследствии исходное определение
ЗНФ
было
заменено
более
строгим
определением Бойса—Кодда.
88

89.

Отношение находится в нормальной
форме Бойса-Кодда (НФБК) тогда и только
тогда,
когда
детерминанты
всех
функциональных зависимостей являются
потенциальными ключами.
89

90.

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

91.

Дано отношение:
Результаты_сессии(Номер_зачетки,
ID_Студента, Дисциплина, Дата, Оценка).
91

92.

Отношение содержит зависимости:
Номер_зачетки, Дисциплина, Дата -> Оценка;
ID_Студента, Дисциплина, Дата ->Оценка;
Номер_зачетки->ID_Студента;
ID_Студента ->Номер_зачетки.
92

93.

В последних двух зависимостях детерминанты не
являются возможными ключами отношения. Поэтому
разбиваем отношение Результаты_сессии на два
отношения:
Итоги_сессии(Номер_зачетки, Дисциплина, Дата, Оценка)
Сведения о студентах(Номер_зачетки, ID_Студента).
Все отношения находятся в НФБК.
93

94.

Четвертая нормальная форма
Рассмотрим пример следующей схемы
отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР,
ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера
проектов, для каждого проекта - список
сотрудников, которые могут выполнять проект,
и
список
заданий,
предусматриваемых
проектом. Сотрудники могут участвовать в
нескольких проектах, и разные проекты могут
включать одинаковые задания.
94

95.

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

96.

Единственным возможным ключом отношения
является составной атрибут ПРО_НОМЕР,
ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других
детерминантов.
Следовательно,
отношение
ПРОЕКТЫ
находится в БКНФ. Но при этом оно обладает
недостатками: если, например, некоторый
сотрудник присоединяется к данному проекту,
необходимо вставить в отношение ПРОЕКТЫ
столько кортежей, сколько заданий в нем
предусмотрено.
96

97.

В отношении ПРОЕКТЫ существуют
следующие две многозначные зависимости:
ПРО_НОМЕР ->-> ПРО_СОТР
ПРО_НОМЕР ->-> ПРО_ЗАДАН
ПРО_НОМЕР ->-> ПРО_СОТР|ПРО_ЗАДАН
97

98.

Дальнейшая нормализация отношений, подобных
отношению ПРОЕКТЫ, основывается на
следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без
потерь в отношения
R1 (A, B) и R2 (A, C) в том и только в том случае,
когда существует многозначная зависимость A ->->
B | C.
Под проецированием без потерь понимается такой
способ декомпозиции отношения, при котором
исходное
отношение
полностью
и
без
избыточности
восстанавливается
путем
естественного соединения полученных отношений.
98

99.

Четвертая нормальная форма. Отношение R
находится в четвертой нормальной форме (4NF) в том и
только в том случае, если в случае существования
многозначной зависимости A >->B все остальные
атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию
отношения ПРОЕКТЫ в два отношения ПРОЕКТЫСОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН).
Оба эти отношения находятся в 4NF.
99

100.

•Предположим, что рестораны производят разные виды пиццы, а
службы доставки ресторанов работают только в определенных
районах города. Составной ключ таблицы такого отношения включает
три поля:
{Ресторан, Вид пиццы, Район доставки}.
Такая таблица не соответствует 4NF, так как существует
многозначная зависимость:
{Ресторан} >> {Вид пиццы}
{Ресторан} >> {Район доставки}
100

101.

То есть, например, при добавлении нового вида
пиццы придется внести по одной новой записи
для каждого района доставки. Возможна
логическая
аномалия,
при
которой
определенному
виду
пиццы
будут
соответствовать лишь некоторые районы
доставки из обслуживаемых рестораном
районов.
Для предотвращения аномалии нужно разбить
многозначную зависимость — разместить
независимые факты в разных таблицах. В
данном примере
- {Ресторан, Вид пиццы} и {Ресторан, Район
доставки}.
101

102.

Моделирование структуры базы данных при помощи
алгоритма нормализации имеет серьёзные
недостатки:
• Первоначальное размещение всех атрибутов в одном
отношении
является
очень
неестественной
операцией.
Интуитивно
разработчик
сразу
проектирует несколько отношений в соответствии с
обнаруженными сущностями.
• Невозможно сразу определить полный список
атрибутов.
• Хотя весь процесс проектирования происходит на
основе учёта зависимостей, реляционная модель не
предоставляет каких-либо средств для представления
этих зависимостей.
102

103.

15. Семантическое
моделирование БД. Модель
сущность-связь. Понятия
сущности, экземпляра сущности
атрибута, связи. Модальность
связи.
103

104. Семантическое моделирование БД

104

105.

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

106.

Чаще всего на практике семантическое
моделирование используется на первой
стадии проектирования базы данных. При
этом в терминах семантической модели
создаётся концептуальная схема базы
данных,
которая
затем
вручную
преобразуется к реляционной (или какойлибо другой) схеме.
Этот процесс выполняется под управлением
методик, в которых достаточно чётко
оговорены все этапы преобразования.
106

107.

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

108.

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

109.

В
качестве
инструмента
семантического
моделирования
используются различные варианты
диаграмм сущность-связь
(ER - Entity-Relationship).
109

110.

Оба термина relation и relationship могут быть переведены
на русский язык как отношение. Поэтому в русскоязычной
литературе ER-модель иногда называют моделью
сущность-отношение.
110

111.

Первый вариант модели сущность-связь
был предложен в 1976 г. Питером Пин-Шэн
Ченом. В дальнейшем многими авторами
были
разработаны
свои
варианты
подобных моделей (нотация Мартина,
нотация IDEF1X, нотация Баркера и др.).
Все варианты диаграмм сущность-связь исходят из одной идеи рисунок всегда нагляднее текстового описания. Все такие
диаграммы используют графическое изображение сущностей
предметной области, их свойств (атрибутов), и взаимосвязей
между сущностями.
111

112.

Простота и наглядность представления
концептуальных схем баз данных в ERмодели
привели
к
ее
широкому
распространению
в
CASE-системах,
поддерживающих
автоматизированное
проектирование баз данных.
Среди множества разновидностей ERмоделей одна из наиболее популярных и
развитых применялась в CASE-системе
компании Oracle.
112

113. Основные понятия ER-моделирования

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

114.

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

115.

Экземпляр
сущности
это
конкретный представитель данной
сущности.
Например,
представителем
сущности
"Сотрудник" может быть "Сотрудник Иванов".
Экземпляры
сущностей
должны
быть
различимы, т.е. сущности должны иметь
некоторые свойства, уникальные для каждого
экземпляра этой сущности.
115

116.

Атрибут
сущности
это
именованная
характеристика,
являющаяся некоторым свойством
сущности.
Примерами
атрибутов
сущности
"Сотрудник" могут быть такие атрибуты как
"Табельный номер", "Фамилия", "Имя",
"Отчество", "Должность", "Зарплата" и т.п.
116

117.

117

118.

Возможно указание примеров значений атрибутов для
облегчения выбора типа данных
118

119.

Связь - это некоторая ассоциация
между двумя сущностями.
Связи позволяют по одной сущности находить
другие сущности, связанные с нею.
Связи между сущностями могут выражаться
следующими фразами - "СОТРУДНИК может
иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК
обязан числиться ровно в одном ОТДЕЛЕ".
119

120.

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

121.

Графически
связь
изображается
соединяющей две сущности:
линией,
121

122.

Каждая связь имеет два конца и одно или
два наименования. Наименование обычно
выражается в неопределённой глагольной
форме: "иметь", "принадлежать" и т.п.
Каждое из наименований относится к
своему концу связи. Иногда наименования
не пишутся ввиду их очевидности.
122

123.

Каждая связь может иметь один из следующих
типов связи: 1:1, 1:M, M:M.
• Связь типа один-к-одному означает, что один
экземпляр первой сущности связан с одним
экземпляром второй сущности. Связь один-кодному чаще всего свидетельствует о том, что
на самом деле мы имеем всего одну сущность,
неправильно разделённую на две.
123

124.

• Связь
типа
один-ко-многим
означает, что один экземпляр
первой
сущности
связан
с
несколькими экземплярами второй
сущности. Это наиболее часто
используемый тип связи.
Сущность
со
стороны
"один"
называется родительской, со стороны
"много" - дочерней.
124

125.

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

126.

Каждая связь может иметь одну из двух
модальностей :
-
126

127.

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

128.

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

129.

Каждая связь может быть прочитана как слева направо, так и
справа налево.
Связь на рисунке читается так:
Слева направо: "каждый сотрудник может иметь несколько детей".
Справа налево: "Каждый ребенок обязан принадлежать ровно
одному сотруднику".
129

130.

130

131.

Пример рекурсивной связи, связывающая сущность МУЖЧИНА
с ней же самой. Конец связи с именем " сын "
определяет тот факт, что несколько людей могут
быть сыновьями одного отца. Конец связи с именем " отец "
означает, что не у каждого мужчины должны быть сыновья.
каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;
каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.
131

132.

132

133. Курсовые работы

133

134.

134

135. Студенты-Специальности

135

136.

136

137.

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

138.

138

139.

139

140.

140

141.

Как и в реляционных схемах БД, так и в ERсхемах вводится понятие нормальных форм,
причем их смысл очень близко соответствует
смыслу реляционных нормальных форм.
В первой нормальной форме ER-диаграммы
устраняются атрибуты сущностей, содержащие
множественные значения.
Во 2 НФ устраняются атрибуты, зависящие
только от части уникального идентификатора.
Эта часть уникального идентификатора
определяет отдельную сущность.
В 3 НФ устраняются атрибуты, зависящие от
атрибутов, не входящих в уникальный
идентификатор. Они являются основой
отдельной сущности.
141

142.

142

143.

143

144.

Ни в одном типе сущности больше нет атрибутов, определяемых
частью уникального идентификатора. Свойства второй
нормальной формы удовлетворяются.
144

145.

145

146.

146

147.

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

148. Курсовые работы

148

149.

В
ER-модели
допускается
категоризации сущностей.
принцип
Это значит, что, вводится понятие подтипа
сущности.
Все
подтипы
сущностей
рассматриваются как взаимоисключающие.
Сущность, на основе которой строятся
подтипы, называется супертипом.
Как в языках объектно-ориентированного
программирования, вводится возможность
наследования типа сущности, исходя из
одного или нескольких супертипов;
149

150.

150

151.

Пример супертипа
ЛЕТАТЕЛЬНЫЙ АППАРАТ и его
подтипов АЭРОПЛАН, ВЕРТОЛЕТ, ПТИЦЕЛЕТ и ПРОЧИЕ.
У подтипа АЭРОПЛАН имеются два собственных подтипа
– ПЛАНЕР и МОТОРНЫЙ САМОЛЕТ.
Для супертипа сущности
ЛЕТАТЕЛЬНЫЙ АППАРАТ
определен атрибут максимальная дальность полета и
необязательная связь "многие ко многим" с типом
сущности ПИЛОТ.
Эти атрибут и связь наследуется всеми подтипами этого
супертипа сущности. У подтипа сущности
АЭРОПЛАН
определяется один дополнительный атрибут, так что в
совокупности у данного типа сущности имеются два
атрибута максимальная дальность полета и размах
крыльев и одна унаследованная связь с типом
сущности ПИЛОТ.
151

152. Пример создания инфологической модели (Библиотека)

152

153.

Описание предметной области
Объекты предметной области:
1. Книги, характеризующиеся следующими
параметрами:
уникальный
шифр,
название, фамилии авторов, место
издания, издательство, год издания,
количество страниц, цена, количество
экземпляров в библиотеке.
2. Читатели с характеристиками: ФИО, дата
рождения, телефон, домашний адрес.
153

154.

3. Каждая книга в библиотеке может
присутствовать в нескольких экземплярах.
Каждый экземпляр может иметь следующие
характеристики:
уникальный
инвентарный
номер, место размещения в библиотеке.
4. Для выдачи книг существует вкладыш, в
котором записываются сведения: номер билета
читателя, который взял книгу, дата выдачи
книги, дата возврата книги.
154

155.

Необходимо предусмотреть ограничения на
информацию в системе:
1. Книга может не иметь ни одного автора.
2. В библиотеке должны быть записаны
читатели не моложе 17 лет.
…
155

156.

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

157.

При работе с системой библиотекарь должен
иметь возможность решать следующие задачи:
1. Принимать новые книги и регистрировать их в
библиотеке.
2. Проводить дополнительную каталогизацию, для
вновь поступивших книг, экземпляры которых
уже имеются в библиотеке.
3. Проводить списание старых книг. Списывать
можно только те книги, ни один из экземпляров
которой не находится у читателей.
4. Вести учет книг, выдаваемых читателям, в
режимах выдачи и приема возвращаемых книг.
5. Проводить списание утерянных читателем книг.
• …
157

158.

Читатель должен иметь возможность решать
следующие задачи:
1. Просматривать систематический каталог, то есть
перечень всех областей знаний, по которым есть
книги в библиотеке.
2. По выбранной области знаний получить полный
перечень книг, которые числятся в библиотеке.
3. Для выбранной книги получить инвентарный
номер свободного экземпляра или сообщение о
том, что свободных экземпляров нет. В случае
отсутствия свободного экземпляра читатель
должен иметь возможность узнать дату
ближайшего предполагаемого возврата данной
книги.
4. …
158

159. Сущность Книги

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

160.

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

161.

161

162.

Между сущностями Книги и Экземпляры
существует связь 1:М, обязательная с двух
сторон. Связь обязательна с двух сторон,
т.к. если в библиотеке нет ни одного
экземпляра книги, то нет смысла хранить ее
описание. С другой стороны если имеется
описание, книги, то, по крайней мере, один
экземпляр есть в библиотеке.
162

163. Сущность Читатели

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

164.

Существует ограничение на возраст читателя,
поэтому необходимо ввести атрибут Дата
рождения. Каждый читатель может держать на
руках несколько экземпляров книг. Для
отражения этой ситуации необходимо провести
связь между сущностями Читатели и Экземпляры
Между сущностями Читатели и Экземпляры
установлена связь 1:М, не обязательная с 2-х
сторон, т.к. читатель может в данный момент не
иметь ни одной книги на руках, а с другой
стороны, данный экземпляр книги может не
находиться на руках ни у одного читателя, а стоять
на полке.
164

165.

165

166. Систематический каталог

Систематический каталог содержит перечень
всех областей знаний, сведения по которым
содержатся в библиотечных книгах. Название
области знаний может быть длинным и
состоять из нескольких слов. Поэтому
сущность Систематический каталог будет
состоять из двух атрибутов: Код области
знаний и Название области знаний.
Атрибут Код области знаний будет ключевым.
166

167.

Из описание предметной области известно,
что каждая книга может содержать
сведения из нескольких областей знаний, а
с другой стороны, из практики известно, что
в библиотеке может присутствовать
множество книг, относящихся к одной и той
же области знаний, поэтому между
сущностями Систематический каталог и
Книги имеет тип М:М, обязательную с двух
сторон.
167

168.

168

169.

169

170.

16.
Преобразование
модели
«сущность
–
связь»
в
реляционную
модель.
Учет
модальности
связи
при
переходе к реляционной модели
170

171. ПОЛУЧЕНИЕ РЕЛЯЦИОННОЙ СХЕМЫ ИЗ ER-МОДЕЛИ

ПОЛУЧЕНИЕ РЕЛЯЦИОННОЙ СХЕМЫ ИЗ ERМОДЕЛИ
1.Каждая простая сущность превращается
в отношение. Имена отношений могут
отличаться от имен сущностей, т. к могут
быть
ограничены
требованиями
конкретной СУБД;
1.Каждый атрибут становится возможным
столбцом с тем же именем, для каждого
атрибута задается допустимый тип
данных
и
обязательность
или
необязательность
этого
атрибута;
171

172.

3. Компоненты
уникального
идентификатора
сущности превращаются в первичный ключ
отношения;
4. В
каждое
отношение,
соответствующее
подчинённой сущности, добавляется набор
атрибутов основной сущности, являющейся
первичным ключом основной сущности. В
отношении, соответствующем подчинённой
сущности этот набор атрибутов становится
внешним ключом. Необязательные связи
соответствуют
столбцам,
допускающим
неопределённые значения; обязательные связи столбцам, не допускающим неопределённые
значения.
172

173.

5. Для связи М:М используется специальный механизм
преобразований,
который
позволяет
отразить
множественные
связи,
неспецифичные для реляционной модели.
Это делается введением дополнительного
связующего отношения, которое связано с
каждым исходным связью 1:М., атрибутами
этого связующего отношения являются
первичные ключи связываемых отношений.
173

174.

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

175.

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

176.

Согласно
правилу
4
перехода
к
реляционной модели (в каждое отношение,
соответствующее подчиненной сущности,
добавляется набор атрибутов основной
сущности, являющейся ее первичным
ключом).
Поэтому необходимо внести в подчиненное
отношение Экземпляры ключи отношений
Книги и Читатели.
176

177.

Для связи М:М между сущностями Книги и
Системный каталог вводится дополнительное
связующее отношение, которое связано с каждым
исходным связью 1:М.
Атрибутами этого связующего отношения будут
первичные ключи связываемых отношений, то есть
введем отношение с атрибутами ISBN и KOD. При
этом каждый из атрибутов нового отношения
является внешним ключом, а вместе они образуют
первичный ключ новой связующей сущности.
177

178.

178

179.

Учет модальности связи при
переходе к реляционной
модели
179

180.

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

181.

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

182.

Менеджер
Клиент
Номер менеджера
Код клиента
Стаж
ФИО
Специальность
Адрес клиента
управляет за
имеет
принадлежит
Счет
Филиал
обрабатывает
Номер счета
Номер филиала
Тип счета
Адрес филиала
Остаток
182

183.

Клиент
Филиал
Код клиента
Номер филиала
ФИО
Номер менеджера
Адрес клиента
Стаж менеджера
Специальность
Адрес филиала
Клиент-счет
Код клиента
Номер счета
Счет
⦁
Номер счета
Тип счета
Остаток
Номер филиала
183

184.

Менеджер
Клиент
Номер менеджера
Код клиента
Стаж
ФИО
Специальность
Адрес клиента
управляет
имеет
принадлежит
Счет
Филиал
обрабатывает
Номер счета
Номер филиала
Тип счета
Адрес филиала
Остаток
184

185.

Менеджер
Номер менеджера
Стаж менеджера
Клиент
Код клиента
ФИО
Адрес клиента
Специальность
Клиент-счет
Код клиента
Номер счета
Филиал
Номер филиала
⦁
Счет
Специальность
Адрес филиала
Номер счета
Номер менеджера
Тип счета
Остаток
Номер филиала
185

186.

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

187.

187

188.

188

189.

Проверка транзакций!
189

190.

190

191.

Если в концептуальной схеме (ERдиаграмме) присутствуют подтипы,
то возможны два способа их
представления
в
реляционной
схеме:
(a) собрать все подтипы в одной
таблице;
(b) для каждого подтипа образовать
отдельную таблицу.
191

192.

192

193.

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

194.

В таблицу добавляется столбец, содержащий
код ТИПА; он становится частью первичного
ключа. Для каждой строки таблицы значение
этого столбца определяет тип сущности,
экземпляру которой соответствует строка.
Столбцы, которые соответствуют атрибутам,
отсутствующим в данном типе сущности,
должны
содержать
неопределённые
значения. Т.е. для ряда экземпляров ряд
атрибутов не будет иметь смысла.
194

195.

195

196.

Таблица3
код типа
борт
номер
дальность
размах
крыльев
ап
в
мощность диаметр
мотора
винта
1
2000
10
300
3
3000
-
-
-
200
196

197.

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

198.

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

199.

199

200.

200

201.

17.
Пример
логического
проектирования базы данных с
использованием модели «сущностьсвязь».
201

202.

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

203.

В ходе беседы с менеджером по продажам,
выяснилось,
что
он
считает,
что
проектируемая система должна выполнять
следующие действия:
• Хранить информацию о покупателях;
• Печатать накладные на отпущенные
товары;
• Следить за наличием товаров на складе.
203

204.

Выделим все существительные в этих
предложениях – это будут потенциальные
кандидаты на сущности и атрибуты, и
проанализируем их.
204

205.

• Покупатель – явный кандидат на
сущность, т.к. покупатели – множество
объектов предметной области , с которыми
взаимодействует фирма;
• Товар – явный кандидат на сущность, т.к.
товары – множество объектов предметной
области,
которые
фирма
продает
покупателям;
205

206.

• Накладная – явный кандидат на сущность,
т.к. накладные – множество документов, в
которых фиксируется факт продажи товара;
• (?) Склад – сколько складов имеет фирма?
Если несколько, то это будет кандидатом на
новую сущность;
• (?)Наличие товара – это, скорее всего,
атрибут, но атрибут какой сущности?
206

207.

Сразу возникает очевидная связь между
сущностями – Покупатели могут покупать
много
Товаров
и
Товары
могут
продаваться многим покупателям.
207

208.

208

209.

Задав
дополнительные
вопросы
менеджеру, выясняем, что фирма имеет
несколько складов. Причём, каждый
товар может храниться на нескольких
складах и быть проданным с любого
склада.
209

210.

НАКЛАДНЫЕ
Покупатели покупают Товары, получая при этом Накладные, в которые внесены
данные о количестве и цене купленного Товара.
Каждый Покупатель может получить несколько Накладных.
Каждая Накладная должна выписываться на одного Покупателя.
Каждая Накладная может содержать несколько Товаров, и должна содержать
хотя бы один Товар – не бывает пустых накладных.
Каждый Товар, в свою очередь, может быть продан нескольким покупателям и
зафиксирован в нескольких Накладных.
Кроме того, каждая Накладная должна быть выписана с определённого Склада,
и с любого Склада может быть выписано много Накладных.
210

211.

211

212.

После выделения и уточнения сущностей можно
определить атрибуты сущностей.
• Каждый покупатель имеет наименование, адрес,
банковские реквизиты.
• Каждый товар имеет наименование, цену, а также
характеризуется единицами измерения.
• Каждая накладная имеет уникальный номер, дату
выписки, список товаров с количествами и
?ценами, а также общую сумму накладной.
Накладная выписывается с определённого склада и
на определённого покупателя.
• Каждый склад имеет свое наименование.
212

213.

В ходе дополнительной беседы проясняются
различные понятия цен. Оказалось, что
каждый товар имеет некоторую текущую цену.
Эта цена, по которой товар продаётся в
данный момент. Естественно, что эта цена
может меняться со временем. Цена одного и
того же товара в разных накладных,
выписанных в разное время, может быть
различной.
Таким образом, имеется две цены – цена
товара в накладной и текущая цена товара.
213

214.

214

215.

Сущности Накладная и Товар связаны друг с
другом отношением М:М. Такая связь должна
быть разделена на две связи типа один-комногим. Для этого требуется дополнительная
сущность. Этой сущностью будет сущность
Запись списка в накладной.
215

216.

216

217.

Связь новой сущности с сущностями «Накладная» и «Товар»
характеризуется следующим:
• Каждая накладная обязана иметь несколько записей из
списка товаров в накладной;
• Каждая запись из списка товаров в накладной обязана
включаться ровно в одну накладную;
• Каждый товар может включаться в несколько записей из
списка товаров в накладной;
• Каждая запись из списка товаров в накладной обязана
быть связана ровно с одним товаром.
217

218.

Атрибуты Количество товара в накладной и
Цена товара в накладной являются
атрибутами сущности «Список товаров в
накладной»
218

219.

Точно
также
поступим
со
связью,
соединяющей сущности «Склад» и «Товар».
Введём дополнительную сущность «Товар на
складе». Атрибутом этой сущности будет
«Количество товара на складе». Таким
образом, товар будет числиться на любом
складе и количество его на каждом складе
будет свое.
219

220.

220

221.

221

222.

222

223.

18.
CASE-средства
для
логического
проектирования
БД.
Зависимые и независимые
сущности. Типы зависимых
сущностей
и
иерархия
наследования.
Прямое
и
обратное проектирование.
223

224.

СASE-системы для проектирования
баз
данных
(Computer
Aided
Software
Engineering)
История систем автоматизации проектирования
баз данных началась с автоматизации процесса
рисования диаграмм, проверки их формальной
корректности, обеспечения средств хранения
диаграмм и другой проектной документации.
Наличие
электронного
архива
проектной
документации помогает при эксплуатации,
администрировании и сопровождении базы
данных.
224

225.

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

226.

В разряд CASE-средств попадают как
относительно дешевые системы для
персональных компьютеров с весьма
ограниченными возможностями, так и
дорогостоящие
системы
для
неоднородных
вычислительных
платформ и операционных сред.
Современный
рынок
программных
средств
насчитывает
около
300
различных CASE-средств.
226

227.

Под термином CASE-средства понимаются
программные
средства,
поддерживающие
процессы создания и сопровождения ИС,
включая
• анализ и формулировку требований,
• проектирование прикладного ПО и баз
данных,
• генерацию кода,
• тестирование,
• документирование,
•управление проектом, а также другие
процессы.
227

228.

Как
правило,
CASE-средства,
автоматизирующие
преобразование
концептуальной схемы БД в реляционную,
производят реляционную схему базы
данных в третьей нормальной форме.
Нормализация более высокого уровня
усложняет программную реализацию и
редко требуется на практике.
228

229.

К числу Сase-средства проектирования баз данных
относятся ERwin (CA ERwin Data Modeler r8 ), SDesignеr (SDP) и DataBase Designer.
Средства проектирования баз данных имеются
также в составе CASE-средств Vantage Team
Builder, Designer/2000, Silverrun, PRO-IV.
229

230.

ERwin
средство
концептуального
моделирования БД, использующее методологию
IDEF1X.
ERwin реализует проектирование схемы БД,
генерацию ее описания на языке целевой СУБД
(ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft
SQL Server, Progress и др.)
Сетевая
версия
Erwin
обеспечивает
согласованное проектирование БД и приложений
в рамках рабочей группы.
230

231.

ERWin может на основе диаграммы базы
данных
сгенерировать
SQL-код
этой
структуры. Или наоборот, по SQL-коду
сгенерировать ER-диаграмму базы данных.
231

232.

232

233.

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

234.

234

235.

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

236.

Ситуации в которых сущность зависит от
существования другой сущности.
Пример: Накладная и Запись списка.
Запись списка зависит от существования
Накладной.
.
236

237.

237

238.

238

239.

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

240.

240

241.

241

242.

Объекты, не зависящие при идентификации
от других объектов в модели, называются
независимыми объектами
В IDEF1X независимые объекты представлены
в виде прямоугольников.
242

243.

Идентификация связей
В
IDEF1X
концепция
зависимых
и
независимых сущностей усиливается типом
взаимосвязей между двумя сущностями.
Идентифицирующие связи обозначаются
сплошной линией между сущностями.
Идентифицирующая связь устанавливается
между независимой (родительский конец
связи) и зависимой (дочерний конец связи)
сущностями.
243

244.

Когда рисуется идентифицирующая связь,
ERwin
автоматически
преобразует
подчинённую
сущность в зависимую, а
атрибуты первичного ключа родительской
сущности автоматически переносятся в состав
первичного ключа дочерней сущности
244

245.

Не идентифицирующие связи отображаются
пунктирной линией между объектами.
Если связать объекты посредством не
идентифицирующей
связи,
они
рассматриваются как независимые сущности.
245

246.

Неидентифицирующая
связь
помечается
прозрачным ромбом со стороны родительской
сущности.
246

247.

247

248.

Связь может дополнительно определяться с
помощью указания степени или мощности
(количества экземпляров сущности-потомка,
которое может существовать для каждого
экземпляра сущности-родителя).
248

249.

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

250.

250

251.

Типы зависимых сущностей и иерархия
наследования
Различают несколько типов зависимых
сущностей.
• Характеристическая - зависимая сущность,
которая
связана
только
с
одной
родительской.
251

252.

252

253.

• Ассоциативная - сущность, связанная с
несколькими родительскими сущностями.
Такая сущность содержит информацию о
связях сущностей.
Пример ассоциативной сущности:
253

254.

• Именующая - частный случай
ассоциативной сущности, не имеющей
собственных атрибутов (только атрибуты
родительских сущностей, мигрировавших в
качестве внешнего ключа).
254

255.

255

256.

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

257.

257

258.

Из общих свойств формируется обобщённая
сущность (родовой предок, супертип)
Сотрудник, чтобы представить информацию,
общую для всех типов служащих.
Специфическая
для
каждого
типа
информация может быть расположена в
категориальных
сущностях
(потомках,
подтипах)
Постоянный
сотрудник,
Совместитель, Консультант.
258

259.

259

260.

Прямое и обратное проектирование (Forward
Engineering, Reverse Engineering)
ERwin имеет два уровня представления
модели - логический и физический.
Физическая модель данных зависит от
конкретной СУБД, фактически являясь
отображением системного каталога.
260

261.

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

262.

Системный каталог или словарь данных является
хранилищем информации, описывающей данные в
базе данных (метаданные).
Обычно в системном каталоге хранятся следующие
сведения:
• - имена, типы и размеры элементов
данных;
• - имена связей;
• - накладываемые на данные ограничения
поддержки целостности;
• - имена санкционированных
пользователей;
262

263.

После описания логической модели,
проектировщик
может
выбрать
необходимую
СУБД
и
ERwin
автоматически создаст соответствующую
физическую модель.
На основе физической модели ERwin
может сгенерировать соответствующий
SQL-скрипт.
Этот процесс называется прямым
проектированием
(Forward
Engineering).
263

264.

С другой стороны, ERwin способен по SQLскрипту
воссоздать
физическую
и
логическую модель данных (Reverse
Engineering).
На основе полученной логической модели
данных можно сгенерировать физическую
модель для другой СУБД и затем сгенерировать
ее SQL-скрипт.
Следовательно, ERwin позволяет решить задачу
по переносу структуры данных с одного
сервера на другой.
264

265.

Кроме режима прямого и обратного
проектирования ERwin поддерживает
синхронизацию
между
логической
моделью и системным каталогом СУБД
на протяжении всего жизненного цикла
создания ИС.
265

266.

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

267.

Для создания моделей данных в ERwin
можно использовать две нотации: IDEF1X и IE
(Information Engineering).
Методология IDEF1X была разработана для
армии США и широко используется в
государственных
учреждениях
США,
финансовых и промышленных корпорациях.
Методология IE, разработанная Мартином и
другими
авторами,
используется
преимущественно в промышленности.
267

268.

Объектно-ориентированные CASE-средства
(Rational Rose)
Rational Rose - CASE-средство фирмы Rational Software
Corporation (США) - предназначено для автоматизации
проектирования программного обеспечения c помощью
языка UML, а также для генерации кодов на различных
языках и выпуска проектной документации.
Но, помимо прочего, язык UML применяется для
проектирования
реляционных
БД.
Для
этого
используется небольшая часть языка (диаграммы
классов).
С точки зрения проектирования реляционных БД
модельные возможности не слишком отличаются от
возможностей ER-диаграмм
268

269.

269