09 Моделирование Базы данных

1. Моделирование базы данных

2. Цель моделирования данных

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

3. Процесс моделирования базы данных

Понятия и описания
ER-модель
Реляционная модель БД
18.11.2025
3

4. Этапы моделирования БД

Изучение понятий и описание информации,
подлежащей моделированию;
Отображение их в рамках ER-модели;
Преобразование ER-модели в реляционную
схему.
18.11.2025
4

5. ER – модель

Предложена Пин-Шэн Ченом в 1976 г. для логического
представления данных.
Получила дальнейшее развитие в работах Р.Баркера.
Основывается на семантической информации о
реальном мире и предназначена
для логического представления данных.
Определяет значения данных в контексте их
взаимосвязи с другими данными.
18.11.2025
5

6. Построение модели предметной области

Базируется на использовании графических
диаграмм, включающих небольшое число
разнородных компонентов.
Базовыми понятиями ER-модели являются
сущность, атрибут и связь.
При создании упрощённой ER-модели
базовыми понятиями являются сущность и
связь
18.11.2025
6

7. Сущность

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

8. Сущность

Например, сущность КНИГА
характеризуется такими атрибутами, как
автор, наименование, цена, издательство,
тираж, количество страниц.
18.11.2025
8

9. Сущность

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

10. Пример сущности

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

11. Пример сущности

Описываемую предметную область назовем
БАНК. В ней могут быть выделены четыре
сущности: филиал, менеджер, счет, клиент.
На ER-диаграмме сущность изображается
прямоугольником, в котором указывается ее
имя. Например:
МЕНЕДЖЕР
11

12. Каждая сущность должна

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

13. Связь

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

14. Связь

Связь между двумя сущностями называется
бинарной, а связь между более чем с
двумя сущностями – тернарной.
В рассматриваемой предметной области
БАНК можно выделить три связи.
1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ
2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – СЧЕТ
3. КЛИЕНТ – ИМЕЕТ – СЧЕТ
18.11.2025
14

15. Связь

На ER-диаграмме связь изображается
ромбом. Например,
Управляет
Важной характеристикой связи является тип
связи (кардинальность).
18.11.2025
15

16. Типы связей 1:1

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

17. Типы связей 1:М

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

18. Типы связей M:N

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

19. Класс принадлежности сущности

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

20. Класс принадлежности сущности

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

21. Класс принадлежности сущности

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

22. Класс принадлежности сущности

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

23. Класс принадлежности сущности

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

24. Класс принадлежности сущности

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

25. Атрибут сущности

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

26. Имена атрибутов

заносятся в прямоугольник, изображающий сущность,
под именем сущности
Студент
ФИО
Группа
Ключевой атрибут выделяется или подчеркивается.
18.11.2025
26

27. Словарь данных

Формируется словарь данных по атрибутам:
Имя атрибута
1.
2.
3.
4.
5.
6.
7.
8.
9.
тип и размерность значений или домен
Ключевое или не ключевое
Индексированное или нет
Значение по умолчанию (если такое имеется)
может ли принимать Null-значения
является ли атрибут составным, и если это так, то из каких
простых атрибутов он состоит
является ли атрибут расчетным, и если это так, то как
вычисляются его значения.
Обязательный или необязательный
Может иметь одинаковые значения или нет
27

28. ПРИМЕР

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

29. ПРИМЕР: Упрощённая ER-модель

ПРИМЕР: Упрощённая ERмодель
18.11.2025
29

30. ПРИМЕР: Набор атрибутов

Набор атрибутов для представленной
модели:
18.11.2025
30

31. ПРИМЕР: Словарь данных

Сущность «Менеджер»
Номер менеджера ( НМ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: счетчик, длинное целое
Ключевой
Индексированный
Значение по умолчанию: отсутствует
Не принимает Null-значение
Не составной атрибут
Увеличивается на 1 у каждого нового экземпляра
сущности.
Обязательный
Одинаковые значения недопустимы
31

32. ПРИМЕР: Словарь данных

Сущность «Менеджер»
Стаж работы ( СТАЖ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: числовой, положительное число с плавающей точкой
Не ключевой
Не индексированный
Значение по умолчанию: 0
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
32

33. ПРИМЕР: Словарь данных

Сущность «Менеджер»
Специальность ( СПЕЦ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 20 знаков
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
33

34. ПРИМЕР: Словарь данных

Сущность «Счет»
Номер счета ( НС )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Числовой, длинное целое
Ключевой
Индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения недопустимы
34

35. ПРИМЕР: Словарь данных

Сущность «Счет»
Тип счета ( ТП )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: определен на домене: «депозитный», «текущий», «до
востребования», «карт-счет».
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
35

36. ПРИМЕР: Словарь данных

Сущность «Счет»
Остаток на счете ( ОС )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Числовой, число с плавающей точкой, два знака
после запятой
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
36

37. ПРИМЕР: Словарь данных

Сущность «Отделение»
Номер Филиала ( НФ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: счетчик, длинное целое
Ключевой
Индексированный
Значение по умолчанию: отсутствует
Не принимает Null-значение
Не составной атрибут
Увеличивается на 1 у каждого нового экземпляра
сущности.
Обязательный
Одинаковые значения недопустимы
37

38. ПРИМЕР: Словарь данных

Сущность «Отделение»
Адрес филиала ( Адр_Ф )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 255 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения не допустимы
38

39. ПРИМЕР: Словарь данных

Сущность «Клиент»
Номер клиента ( НФ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: счетчик, длинное целое
Ключевой
Индексированный
Значение по умолчанию: отсутствует
Не принимает Null-значение
Не составной атрибут
Увеличивается на 1 у каждого нового экземпляра
сущности.
Обязательный
Одинаковые значения недопустимы
39

40. ПРИМЕР: Словарь данных

Сущность «Клиент»
ФИО клиента ( ФИО_К )
1.
2.
3.
4.
5.
6.
7.
8.
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Состоит из атрибутов: Фамилия клиента (Ф_К), Имя
клиента (Ф_Л), Отчество клиента (О_К)
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
40

41. ПРИМЕР: Словарь данных

Сущность «Клиент»
Фамилия клиента ( Ф_К ), Имя клиента ( И_К )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 20 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
41

42. ПРИМЕР: Словарь данных

Сущность «Клиент»
Фамилия клиента ( Ф_К )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 20 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
42

43. ПРИМЕР: Словарь данных

Сущность «Клиент»
Фамилия клиента ( Ф_К )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 20 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
43

44. ПРИМЕР: Словарь данных

Сущность «Клиент»
Социальное положение ( СОЦ )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 20 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
44

45. ПРИМЕР: Словарь данных

Сущность «Клиент»
Адрес клиента ( Адр_К )
1.
2.
3.
4.
5.
6.
7.
8.
9.
Тип: Текстовый, размер 255 символов
Не ключевой
Не индексированный
Значение по умолчанию отсутствует
Не принимает Null-значение
Не составной атрибут
Не расчетный атрибут
Обязательный
Одинаковые значения допустимы
45

46. ПРИМЕР

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

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

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

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

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

49. Примерные таблицы предметной области банк

18.11.2025
49

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

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

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

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

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

Согласно правилу 1 должна быть
сгенерирована одна таблица следующей
структуры:
Первичным ключом этой таблицы может
быть и первичный ключ сущности
МЕНЕДЖЕР – НМ.
18.11.2025
52

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

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

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

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

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

согласно правилу 2 должны быть
сгенерированы две таблицы следующей
структуры:
Сущность с необязательным классом
принадлежности (ФИЛИАЛ) именуется
родительской, а с обязательным
(МЕНЕДЖЕР) – дочерней.
18.11.2025
55

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

Первичный ключ родительской сущности (НФ),
помещаемый в таблицу, представляющую
дочернюю сущность, называется внешним
ключом родительской сущности. Связь между
указанными таблицами устанавливается путем
связи первичного и внешнего ключа и имеет вид
Примечание. Если внешний ключ представляет связь 1:1, то должны быть
запрещены его дублирующие значения.
18.11.2025
56

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

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

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

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

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

Согласно правилу 3 должны быть
сгенерированы три таблицы следующей
структуры:
18.11.2025
59

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

При этом осуществляется декомпозиция связи
1:1 на две связи 1:1 следующим образом:

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

Итак, для связи типа 1:1 существуют три отдельных
правила формирования предварительных таблиц из
ER-диаграмм.
Для связи типа 1:М существуют только два правила.
Выбор одного из них зависит от класса
принадлежности сущности на стороне M. Класс
принадлежности сущности на стороне 1 не влияет
на выбор.
18.11.2025
61

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

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

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

На ER-диаграмме связи 1:М, класс
принадлежности сущности СЧЕТ является
обязательным.
18.11.2025
63

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

Согласно правилу 4 должны быть
сгенерированы две таблицы следующей
структуры:
18.11.2025
64

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

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

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

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

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

Представим, что на ER-диаграмме связи 1:М,
класс принадлежности сущности СЧЕТ
является необязательным.
18.11.2025
67

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

Согласно правилу 5 должны быть
сгенерированы три таблицы следующей
структуры:
18.11.2025
68

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

При этом осуществляется декомпозиция связи
1:М на две связи – 1:М и 1:1 – следующим
образом:
Для связи типа М:N класс принадлежности сущности не имеет
значения.

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

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

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

На ER-диаграмме связи М:N имеются
18.11.2025
71

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

Согласно правилу 6 должны быть
сгенерированы три таблицы следующей
структуры:
18.11.2025
72

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

При этом осуществляется декомпозиция связи
М:N на две связи 1:М следующим образом:
В таблице КЛИЕНТ–СЧЕТ клиенту, имеющему, например, три счета
будут соответствовать три строки с одним и тем же номером
клиента.
А счет, у которого, например, два владельца, представляется двумя
строками с различными номерами клиентов, владеющими этим
счетом.

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

К ER-модели предметной
применимы правила 1, 4, 6.
области
БАНК,
74

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

Связь МЕНЕДЖЕР – ФИЛИАЛ представляется
(согласно правилу 1) одной таблицей
75

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

Связь ФИЛИАЛ – СЧЕТ
(согласно правилу 4) связью:
представляется
76

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

Связь КЛИЕНТ – СЧЕТ
(согласно правилу 6) связью:
представляется
77

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

Анализ состава атрибутов полученных таблиц
A, B, C, D, E, F показывает, что таблица В
является составной частью таблицы А,
таблица Е – составной частью таблицы С.
Поэтому таблицы В, Е можно исключить из
рассмотрения.
78

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

79

80. Нормализация таблиц

Реляционная
база
данных
считается
эффективной, если она обладает следующими
характеристиками:
1. Минимизация избыточности данных.
2. Минимальное
использование
отсутствующих значений (Null-значений).
3. Предотвращение потери информации.
80

81. 1. Минимизация избыточности данных.

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

82. 2. Минимальное использование отсутствующих значений.

В нашем примере неясно, означают ли Nullзначения атрибута "Преподаватель", что для
группы А2 не определен преподаватель или
его Ф.И.О. не введено.
Из-за неопределенности интерпретации Nullзначений их использование желательно свести
к минимуму.
82

83. 3. Предотвращение потери информации.

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

84. 3. Предотвращение потери информации.

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

85. Нормализация таблиц

Для того чтобы база данных соответствовала
указанным характеристикам, проводят ее
нормализацию как минимум по трем формам:
1. Первая нормальная форма
2. Вторая нормальная форма
3. Третья нормальная форма
85

86. Нормализация таблиц 1НФ

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

87. Нормализация таблиц 1НФ

Сотрудник
Контакт
Иванов И.И.
123-456-789, 987-654-321
Сергеев С.С.
Рабочий телефон 555-666-777,
Домашний телефон 777-888-999
John Smith
123-456-789
John Smith
123-456-789
18.11.2025
Сотрудник
Телефон
Тип телефона
Иванов И.И.
123-456-789
Иванов И.И.
987-654-321
Сергеев С.С.
555-666-777
Рабочий телефон
Сергеев С.С.
777-888-999
Домашний
телефон
John Smith
123-456-789
87

88. Нормализация таблиц 1НФ

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

89. Нормализация таблиц 2НФ

Вторая нормальная форма
1-НФ
Таблица должна иметь ключ
Все не ключевые столбцы таблицы должны
зависеть от полного ключа (в случае если
он составной)

90. Нормализация таблиц 2НФ

Как видно наша таблица с составным
ключом не удовлетворяет 3 правилу.
18.11.2025
90

91. Нормализация таблиц 2НФ

18.11.2025
91

92. Нормализация таблиц 3НФ

Третья нормальная форма
2-НФ
Не
должно быть зависимостей одних не
ключевых атрибутов от других. Все
атрибуты зависят только от ключевых
атрибутов
(отсутствие
транзитивных
зависимостей)

93. Этапы проектирования базы данных и их процедуры

Проектирование базы данных существляется
в три этапа:
1.
2.
3.
концептуальное проектирование
логическое проектирование
физическое проектирование

94. Концептуальное проектирование

Цель концептуального проектирования –
создание концептуальной модели данных
исходя из представлений пользователей о
предметной области.
Для концептуального проектирования
необходимо выполнить семь процедур.

95. КП. 1. Определение сущностей и их документирование.

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

96. КП. 2. Определение связей между сущностями и их документирование.

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

97. КП. 3. Создание ER-модели предметной области.

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

98. КП. 4. Определение атрибутов и их документирование.

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

99. КП. 4. Определение атрибутов и их документирование.

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

100. КП. 5. Определение значений атрибутов и их документирование.

Для каждого атрибута сущности, участвующей в
ER-модели, определяется набор допустимых
значений и ему присваивается имя.
Например, атрибут "Тип счета"
может иметь только значения "депозитный",
"текущий", "до востребования", "карт-счет".
Обновляются записи словаря данных,
относящиеся к атрибутам, – в них заносятся
имена наборов значений атрибутов.

101. КП. 6. Определение первичных ключей для сущностей и их документирование.

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

102. КП. 7. Обсуждение концептуальной модели данных с конечными пользователями.

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

103. КП. 7. Обсуждение концептуальной модели данных с конечными пользователями.

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

104. Логическое проектирование

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

105. ЛП. 1. Выбор модели данных.

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

106. ЛП. 2. Определение набора таблиц исходя из ER-модели и их документирование.

Для каждой сущности ER-модели создается
таблица.
Имя сущности – имя таблицы.
Осуществляется формирование структуры
таблиц.
Устанавливаются связи между таблицами
посредством механизма первичных и внешних
ключей.
Структуры таблиц и установленные связи между
ними документируются.

107. ЛП. 3. Нормализация таблиц.

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

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

Транзакция – это набор действий, выполняемых
отдельным пользователем или прикладной
программой с целью изменения содержимого
базы данных.

109. ЛП. 5. Определение требований поддержки целостности данных и их документирование.

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

110. ЛП. 5. Определение требований поддержки целостности данных и их документирование.

Должны быть рассмотрены следующие типы
ограничений:
- обязательные данные. Выясняется, есть ли
атрибуты, которые не могут иметь Null-значений;
· ограничения для значений атрибутов.
Определяются допустимые значения для
атрибутов;
· целостность сущностей. Она достигается, если
первичный ключ сущности не содержит Nullзначений;

111. ЛП. 5. Определение требований поддержки целостности данных и их документирование.

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

112. ЛП. 6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями.

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