12 правил Кодда для определения концепции РМД

1.82M

Категория:

Базы данных

Похожие презентации:

Лекция 2

1. Базы данных: термины

Администратор БД (АБД) – это сотрудник
(группа лиц), выполняющих следующие
функции:
Координация проектирования,
реализации и ведения БД
Обслуживание пользователей БД
Определение структуры данных и
правила доступа
Оценка перспективы и формирование
требований, исходя из особенностей
ПрО

2. Базы данных: термины

Автоматизированная
информационная система (АИС) –
совокупность программноаппаратных средств,
предназначенных для автоматизации
деятельности, связанной с
хранением, передачей и обработкой
инфы.

3. Базы данных: термины

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

4. Компоненты сБД

Прикладное программное обеспечение
Система управления базами данных
База
данных

5. Этапы проектирования БД

6.

Предметная
область
Информационные
потребности
пользователей
Построение инфологической модели ПО
Этап
инфологического
проектирования
Выбор СУБД
Построение концептуальной модели
данных (ЛП)
Построение физической модели данных
(ФП)
Этап
датологического
проектирования

7. Этапы проектирования БД

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

8. Этапы проектирования БД

• На этапе инфологического проектирования
осуществляется построение семантической
модели, описывающей сведения из предметной
области которые могут заинтересовать
пользователей БД
Семантическая модель – представление
совокупности сведений о ПрО в виде графа, в
вершинах которого расположены понятия, а дуги
представляют отношения между понятиями
Подобные модели называются моделями
«сущность-связь» (ER-model: Entity-Relationship)

9. Этапы проектирования БД

• Реальные процессы и объекты предметной
области представлены в ER-моделях в виде
сущностей.
• Сущности: базовые и зависимые. Тип
сущности. Экземпляр сущности.
• Для каждого типа сущности необходимо
определить имя.

10. Этапы проектирования БД

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

11. Этапы проектирования БД

• Между сущностями ПрО могут существовать
связи, имеющие различный содержательный
смысл(семантику). Например, студент учится в
группе
СТУДЕНТ
УЧИТСЯ
ГРУППА
• Связи характеризуются следующими атрибутами:
• Кардинальность
• Степень связи

12. Этапы проектирования БД

• Кардинальность связи:
– Один к одному (1:1)
– Один ко многим (1:М), многие к одному (М:1)
– Многие ко многим (M:N)
ПРЕПОДАВАТЕЛЬ
M
СТУДЕНТ
ВЕДЕТ
M
N
ДИСЦИПЛИНА
N
УЧИТСЯ
1
ГРУППА
M
ИЗУЧАЕТ

13. Этапы проектирования БД

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

14. Этапы проектирования БД

• Датологическое проектирование
подразделяется на логическое и
физическое проектирование
Логическое проектирование–
преобразование требований к данным в
структуры данных (в форматах,
поддерживаемых выбранной СУБД).
Физическое проектирование –
определение особенностей хранения
данных, методов доступа и т. д.

15. Этапы проектирования БД

Различие уровней представления данных на каждом
этапе проектирования реляционной базы данных:
КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ — Представление
аналитика (используется модель «сущность-связь»)
термины: сущности, атрибуты, связи
ЛОГИЧЕСКИЙ УРОВЕНЬ — Представление
программиста
термины: записи, элементы данных,
связи между записями
ФИЗИЧЕСКИЙ УРОВЕНЬ — Представление
администраторов БД, СУБД, ...
термины: группирование данных, индексы,
методы доступа, распределенная БД, репликация,
15
производительность, надежность, кластеры…

16.

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

17. Модели данных

18. Модели данных

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

19. Типы структур

• Структурированная запись базируется
на использовании концепций
«агрегации» и «обобщения».
• Один из первых вариантов
структуризации данных был предложен
Ассоциацией по языкам обработки
данных (Conference of Data Systems
Languages, CODASYL)
Элемент
данных
Агрегат
данных
Запись
Набор
База
данных

20. Типы структур

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

21. Типы структур

• Агрегат данных – поименованная
совокупность элементов данных внутри
записи, которую можно рассматривать
как единое целое.
• Агрегат может быть простым (включает
только элементы данных) и составным
(включает элементы данных и другие
агрегаты)

22. Типы структур

• Агрегат данных
А(предприятие)
А(дата)
число
месяц
А(название)
год
название
А(адрес)
индекс
город
улица
и дом

23. Типы структур

• Запись – поименованная совокупность
элементов и агрегатов данных.
• Запись – это агрегат, не входящий в
состав других агрегатов
• Различают понятия тип записи (ее
структура) и экземпляр записи (т.е.
запись с конкретными значениями
элементов данных)
• Одна запись описывает свойства одной
сущности ПО

24. Типы структур

• Запись.
№
А
Дата
Паспорт Пол
пропуска (ФИО) рождения
Должность
индекс
фамилия
имя
отчество
Оклад
А
(адрес)
город
улица
и дом

25. Типы структур

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

26. Типы структур

• Набор (групповое отношение) (кратко
ГО) – поименованная совокупность
записей, образующих двухуровневую
структуру.
• Каждый тип набора представляет собой
связь между двумя или несколькими
типами записей.
• Для каждого типа набора один тип
записи объявляется владельцем
набора, остальные – членами набора.

27. Типы структур

• ГО удобно изображать с помощью диаграммы
Бахмана.
• Диаграмма Бахмана представляет собой
ориентированный граф: вершины – типы записей,
дуги – наборы (групповые отношения)
Поликлиники
Организации
работают
диспансеризация
Жители
проживают
Квартиры
Ремонтно-эксплуат.
управления
обслуживают

28. Операции над данными

• МД определяет множество действий,
которые допустимо производить над
некоторой реализацией БД для ее
перевода из одного состояния в другое.
• Это множество соотносят с языком
манипулирования данными (Data
Manipulation Language, DML)
• Любая операция над данными включает в
себя селекцию данных (select)
• Условие селекции – это некий критерий
отбора данных

29. Операции над данными

По типу производимых действий различают
следующие операции:
• Идентификация данных и нахождение их
позиции в БД
• Выборка (чтение) данных из БД
• Включение (запись) данных в БД
• Удаление данных из БД
• Модификация данных БД

30. Операции над данными

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

31. Ограничение целостности

• Это правила, которым должны удовлетворять
значения элементов данных.
• Ограничения целостности (integrity constraint)
делятся на внутренние и явные.
Определение
• Ограничения, обусловленные возможностями
конкретной СУБД, называют «внутренними
ограничениями целостности»
Определение
• Ограничения, обусловленные особенностями
хранимых данных о конкретной ПО, называют
«явными ограничениями целостности»

32. Ограничение целостности

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

33. Модели данных

• Модели первого поколения
– Иерархическая
– Сетевая
• Модели второго поколения
– Реляционная
• Модели третьего поколения
– Объектно-ориентированная
– Объектно-реляционная

34. Иерархическая модель данных (ИМД)

ИЕРАРХИЧЕСКАЯ МОДЕЛЬ
ДАННЫХ (ИМД)

35. Иерархическая модель данных

• Организация данных в СУБД
иерархического типа определяется в
терминах: элемент, агрегат, запись
(группа), групповое отношение, база
данных.
• Иерархическая модель реализуется
древовидной структурой, объекты
которой представлены узлами дерева

36. Иерархическая модель данных

1. Свойства иерархической модели
1. Существует корень
2. Узел содержит атрибуты
3. Исходный и зависимый узлы находятся в отношении
«непосредственный предок и потомок»
4. Потомок соединен единственной связью с предком
5. Предок может иметь несколько потомков
6. Доступ к данным производится через предка
7. Может существовать множество экземпляров узла
8. При удалении узла удаляется все его поддерево

37. Иерархическая модель данных

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

38.

А
ОТДЕЛ
ЗАКАЗЧИК
Наименование
Наименование
Число работников
Адрес
B
СОТРУДНИК
СОТРУДНИК
КОНТРАКТ
КОНТРАКТ
Фамилия
Фамилия
Номер
Номер
Должность
Должность
Дата
Дата
Оклад
Оклад
Сумма
Сумма
ИСПОЛНИТЕЛЬ
ИСПОЛНИТЕЛЬ
ИСПОЛНИТЕЛЬ
Фамилия
Фамилия
Фамилия
Должность
Должность
Должность
Наименов_отдела
Наименов_отдела
Наименов_отдела
КОНТРАКТ
КОНТРАКТ
Номер
Номер
Дата
Дата
Сумма
Сумма
C

39. Иерархическая модель данных

2. Операции над данными:
– ДОБАВИТЬ в БД новую запись.
– ИЗМЕНИТЬ значение данных выбранной
записи.
– УДАЛИТЬ некоторую запись и все
подчиненные ей записи
– ИЗВЛЕЧЬ
• Корневую запись по ключу
• Следующую запись (в порядке
левостороннего обхода дерева)

40. Иерархическая модель данных

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

41. Сетевая модель данных (СМД)

СЕТЕВАЯ МОДЕЛЬ ДАННЫХ
(СМД)

42. Сетевая модель данных

Сетевая модель данных определена в тех же
терминах, что и иерархическая модель данных
1. Отличия сетевой и иерархической моделей:
– Запись может быть членом более чем одного ГО
– Каждое ГО именуется
– Тип ГО определяет свойства общие для всех
экземпляров данного типа
– Экземпляр ГО представляется записьювладельцем и множеством (возможно пустым)
подчиненных записей
– Экземпляр записи не может быть членом двух
экземпляров ГО одного типа

43.

ОТДЕЛ
ЗАКАЗЧИК
Наименование
Наименование
Число работников
Адрес
СОТРУДНИК
СОТРУДНИК
КОНТРАКТ
КОНТРАКТ
Фамилия
Фамилия
Номер
Номер
Должность
Должность
Дата
Дата
Оклад
Оклад
Сумма
Сумма
СОТРУДНИК_КОНТРАКТ
СОТРУДНИК_КОНТРАКТ
СОТРУДНИК_КОНТРАКТ
СОТРУДНИК_КОНТРАКТ

44. Сетевая модель данных

2. Операции над данными:
– ДОБАВИТЬ в БД новую запись в зависимости
от режима включения, либо включить ее в ГО,
где она объявлена подчиненного, либо не
включать ни в какое ГО.
– ВКЛЮЧИТЬ В ГО связать существующую
подчиненную запись с записью-владельцем
– ПЕРЕКЛЮЧИТЬ связать существующую
подчиненную запись с другой записьювладельцем в том же ГО.
– ОБНОВИТЬ изменить значение элементов
предварительно извлеченной записи

45. Сетевая модель данных

• Операции над данными:
– ИЗВЛЕЧЬ записи последовательно по
значению ключа, а также использую ГО –
от владельца перейти к записям-членам, а
от подчиненной записи к владельцу
набора.
– УДАЛИТЬ убрать из БД запись.
– ИСКЛЮЧИТЬ ИЗ ГО разорвать связь
между записью-владельцем и записью–
членом.

46. Сетевая модель данных

3. Ограничения целостности
• Поддерживается только целостность
связей между владельцами и членами
ГО.

47. Реляционная модель данных (РМД)

РЕЛЯЦИОННАЯ МОДЕЛЬ
ДАННЫХ (РМД)

48. Реляционная модель данных

1. Основные понятия
• Предложена сотрудником компании IBM Е.Ф.
Коддом в 1970 г.
• Кодд предложил использовать для обработки баз
данных аппарат теории множеств и теории
отношений.
• В реляционной модели данных достигается
гораздо более высокий уровень абстракции
данных, чем в иерархической или сетевой.

49. Реляционная модель данных

• В основу реляционной модели Кодд
положил три принципа (стремления):
– Независимость данных на логическом и
физическом уровнях – стремление к
независимости
– Создание структурно-простой модели –
стремление к коммуникабельности
– Использование концепции языков высокого
уровня для описания операций над порциями
информации – стремление к обработке
множеств.

50. Реляционная модель данных

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

51. Реляционная модель данных

• Структурная часть модели состоит из
следующих компонент:
– Домен
– Отношение
– Атрибут
– Кортеж
– Потенциальный ключ
– Первичный ключ

52. Реляционная модель данных

Определение:
• Домен D – это совокупность (множество)
однотипных значений данных
Пример:
• Домен Возраст – [0..100]
• Домен Пол – [‘м’, ‘ж’]
• Домен Номер – [‘00001’..’99999’]
• и т.д.

53. Реляционная модель данных

Определение:
• Декартово произведение множеств
D1 D2 … Dn – это новое множество,
состоящее из всех возможных комбинаций
элементов исходных множеств
Пример:
Даны множества: D1 = {1,2} , D2 = {5,6,7}
D1 D2 = {(1,5), (1,6), (1,7), (2,5), (2,6), (2,7)}

54. Реляционная модель данных

Определение:
• Отношением R, определенным на множествах
(доменах) D1, D2, …, Dn называется
подмножество декартово произведения
D1 D2 … Dn
Пример: Даны множества: D1 = {1,2} , D2 = {5,6,7}
D1 D2 ={(1,5), (1,6), (1,7), (2,5), (2,6), (2,7)}
R D1 D2 = {(1,5), (1,7), (2,6)}

55. Реляционная модель данных

Определение:
• Атрибут A – атомарное данное, определяющее
один из столбцов (полей) отношения.
• Атрибут есть подмножество некоторого домена,
на котором определено отношение
Пример:
№
1
Атрибуты
Дата рождения
Домены
Дата
2
3
Непрерывный стаж работы
Общий стаж работы
Стаж
Стаж

56. Реляционная модель данных

Определение:
• Кортеж – строка (элемент) отношения,
представляет собой некоторый элемент
декартово произведения.
Пример: Отношение R = {(1,5), (1,7), (2,6)}
Кортежи: (1,5)
(1,7)
(2,6)

57. Реляционная модель данных

Определение:
• Степень отношения – количество атрибутов
отношения (унарные, бинарные, …, n-арные).
• Мощность отношения – количество кортежей
отношения.
Пример: Отношение R = {(1,5), (1,7), (2,6)}
Степень R = 2
Мощность R = 3

58. Реляционная модель данных

Определения:
• Ключевой атрибут (ключ) – атрибут
(набор атрибутов), значение которого
однозначно идентифицирует кортежи.
• Значения первичного ключа изменить
нельзя.

59. Реляционная модель данных

Определения:
• Схема отношения – именованное
множество пар «имя атрибута – имя
домена».
• Схема БД – набор именованных схем
отношений.

60. Реляционная модель данных

Целое
Строка Строка
Целое
Номер
Имя
Деньги
Табельный
Имя
номер
Должность
Должность Оклад
Премия
2934
Иванов Инженер
1120
400
2935
Петров Вед.
инженер
1440
500
2936
Климов Бухгалтер
920
350
Ключ
ОТНОШЕНИЕ
Типы
данных
Домены
Атрибуты
Кортежи

61. Реляционная модель данных

• Объектом реляционной модели могут быть
только нормализованные отношения.
• Отношение нормализовано, если каждый
его атрибут атомарен (т.е. не заменим
другим отношением).

62.

Реляционная модель данных
• В отличие от иерархической и сетевой
моделей данных в реляционной
отсутствует понятие ГО.
• Для отражения ассоциаций между
кортежами разных отношений
используется дублирование их ключей.

63.

64.

65.

ОТДЕЛ
СОТРУДНИК
Номер_отдела
Табельный_номер
Наименование
Номер_отдела
ИСПОЛНИТЕЛИ
Фамилия
Табельный_номер
Должность
Номер_контракта
Оклад
ЗАКАЗЧИК
КОНТРАКТ
Номер_заказчика
Номер_контракта
Наименование
Номер_заказчика
Адрес
Дата
Сумма
Реляционная
модель
данных

66. Реляционная модель данных

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

67. Реляционная модель данных

2. Операции над данными:
• Обрабатывающая часть модели
определяется операциями реляционной
алгебры:
– Выборка
– Проекция
– Объединение
– Пересечение
– Соединение
– и др.

68. Реляционная модель данных

3. Ограничения целостности
Существуют два ограничения, которые должны
выполняться в любой реляционной базе данных.
Это:
Целостность сущностей.
Целостность внешних ключей.
Прежде, чем говорить о целостности сущностей,
опишем использование null-значений в
реляционных базах данных.

69.

Целостность сущностей
Т.к. потенциальные ключи фактически служат
идентификаторами объектов предметной
области (т.е. предназначены для различения
объектов), то значения этих идентификаторов
не могут содержать неизвестные значения.
правило целостности сущностей:
Атрибуты, входящие в состав некоторого
потенциального ключа не могут
принимать null-значений.

70.

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

71.

Номер
товара
Товар
Кол-во
Номер
пост-ка
Поставщик
1
«Герцогиня»
100
1
ООО «Премьер-Видео»
2
«Герой»
200
2
ООО «Ди Ви Ди Клуб»
2
«Герой»
130
3
ООО «Диск ПРО»
3
«Белый плен»
150
1
ООО «Премьер-Видео»
4
«Турист»
200
3
ООО «Диск ПРО»
Потенциальный ключ – (Номер товара, Номер поставщика).
Проблемы:
1. При изменении наименования поставщика – необходимо
внести изменение во все строки таблицы
2. При удалении информации о поставках, удаляется и
информация о поставщике.
3. Нельзя представить товар, не поставляемый никем.
Причина: смешана разнородная информация

72.

Связи: «Поставщики выполняют Поставки»
– (1:M)
«Товары поставляются через Поставки» – (1:M)
Эти две взаимосвязи косвенно определяют новую
взаимосвязь между "Поставщиками" и «Товаром":
«Товары поставляются Поставщиками» – (M:N)
Взаимосвязи типа "многие-ко-многим" реализуются в
РБД использованием нескольких взаимосвязей типа "одинко-многим".
Отношение, входящее в связь со стороны "один"
("Поставщики"), называют родительским отношением.
Отношение, входящее в связь со стороны "много"
("Поставки"), называется дочернем отношением.

73.

Номер
поставщика
Поставщик
Номер
товара
1
ООО «Премьер-Видео»
1
«Герцогиня»
2
ООО «Ди Ви Ди Клуб»
2
«Герой»
3
ООО «Диск ПРО»
3
«Белый плен»
4
«Турист»
Отношение «Поставщики»
Товар
Отношение «Товары»
Номер
поставщика
(FK)
Номер
товара (FK)
Кол-во
1
1
100
2
2
200
3
2
130
1
3
150
3
4
200
Отношение «Поставки»

74.

Определение .
Пусть дано отношение R. Подмножество
атрибутов FK отношения R будем называть
внешним ключом, если:
1) Существует отношение S (R и S не
обязательно различны) с потенциальным
ключом K.
2) Каждое значение FK в отношении R всегда
совпадает со значением K для некоторого
кортежа из S, либо является null-значением.
Отношение S – родительское отношение
Отношение R – дочернее отношение.

75.

Замечание. Внешний ключ, как правило, не
обладает свойством уникальности. Это,
собственно, и дает тип отношения 1:N.
Замечание. Хотя каждое значение внешнего
ключа обязано совпадать со значениями
потенциального ключа в некотором кортеже
родительского отношения, то обратное, вообще
говоря, неверно. Например, могут существовать
поставщики, не поставляющие никаких деталей.
Замечание. Для внешнего ключа не требуется,
чтобы он был компонентом некоторого
потенциального ключа.

76.

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

77.

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

78.

Нарушение целостности для
родительского отношения
Вставка кортежа в родительском отношении.
• При вставке кортежа в родительское отношение
возникает новое значение потенциального ключа.
• Т.к. допустимо существование кортежей в
родительском отношении, на которые нет ссылок из
дочернего отношения, то вставка кортежей в
родительское отношение не нарушает ссылочной
целостности.
78

79.

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

80.

Нарушение целостности для
родительского отношения
Удаление кортежа в родительском
отношении.
• При удалении кортежа в родительском
отношении удаляется значение потенциального
ключа.
• Если есть кортежи в дочернем отношении,
ссылающиеся на удаляемый кортеж, то значения
их внешних ключей станут некорректными.
• Удаление кортежей в родительском отношении
может привести к нарушению ссылочной
80
целостности.

81.

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

82.

Нарушение целостности отношений
Таким образом, ссылочная целостность в
принципе может быть нарушена при выполнении
одной из четырех операций:
• Обновление кортежа в родительском
отношении.
• Удаление кортежа в родительском отношении.
• Вставка кортежа в дочернее отношение.
• Обновление кортежа в дочернем отношении.
82

83. 12 правил Кодда для определения концепции РМД

1.Явное представление данных.
2.Гарантированный доступ к данным. К
каждому элементу данных должен быть
гарантирован доступ с помощью
комбинации имени таблицы, первичного
ключа строки и имени столбца.

84.

3. Обработка неизвестных значений.
Неизвестные значения NULL, отличные от
любого известного значения, должны
поддерживаться для всех типов данных при
выполнении любых операций. Например,
для числовых данных неизвестные значения
не должны рассматриваться как нули, а для
символьных данных – как пустые строки.
4. Динамический каталог данных. Каталог
(или словарь-справочник) данных должен
сохраняться в форме реляционных таблиц,
и РСУБД должна поддерживать доступ к
ним.

85.

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

86.

8. Физическая независимость данных.
Приложения не должны зависеть от
используемых способов хранения данных на
носителях, от аппаратного обеспечения
компьютера, на котором находится БД.
9. Логическая независимость данных. Это
свойство позволяет сконструировать
несколько различных логических взглядов
(представлений) на одни и те же данные для
разных групп пользователей.

87.

10. Независимость контроля целостности.
Язык для работы с данными должен
выполнять проверку входных данных и
автоматически поддерживать целостность
данных.
11. Независимость от распределённости.
БД может быть распределённой (может
находиться на нескольких компьютерах), и это
не должно оказывать влияние на приложения.
12. Согласование языковых уровней. Не
должно быть иного средства доступа к
данным, отличного от стандартного языка для
работы с данными.

English Русский Правила