Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Подходы к организации баз данных
Содержание
- 1. Подходы к организации баз данных
- 2. Рис. 2 Схема сетевой моделиПодходы к организации баз данныхСетевые базы данных
- 3. Рис. 3 Соотношение основных понятий реляционного подход
- 4. Рис. 4 Ненормализованное отношение ОТДЕЛЫ-СЛУЖАЩИЕВведение в реляционную
- 5. Рис. 5 Отношение СЛУЖАЩИЕ: нормализованный вариант отношения
- 6. Трехзначная логика (3VL)Таблица 1. Таблица истинности AND
- 7. Имеется несколько парадоксальных следствий применения трехзначной логики.
- 8. Таблица 4. Отношение "Сотрудники"Таблица 5.Потенциальные ключи
- 9. Таблица 6. Отношение "Поставщики и поставляемые детали"Внешние ключи
- 10. Таблица 7. Отношение "Поставщики"Таблица 8. Отношение "Детали"Таблица 9. Отношение "Поставки"Внешние ключи
- 11. Стратегии поддержания ссылочной целостностиОсновные:RESTRICT (ОГРАНИЧИТЬ)CASCADE (КАСКАДИРОВАТЬ)Дополнительные: SET
- 12. Технологии проектирования реляционных БД Этапы разработки базы
- 13. Технологии проектирования реляционных БДКритерии оценки качества логической
- 14. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 15. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 16. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 17. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 18. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 19. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 20. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 21. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 22. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 23. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 24. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 25. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 26. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 27. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 28. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 29. Технологии проектирования реляционных БДПроектирование реляционных баз данных на основе принципов нормализации Рис. 13. Значения переменных отношений
- 30. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 31. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 32. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 33. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 34. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 35. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 36. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 37. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 38. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 39. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 40. Возможная декомпозицияРис. 18. Диаграммы FD и значения переменных отношений СЛУЖ_НОМ_ИМЯ и СЛУЖ_НОМ_ПРО_ЗАДАН
- 41. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 42. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 43. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 44. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 45. Технологии проектирования реляционных БДПроектирование реляционных баз данных
- 46. Классический подход к проектированию реляционных баз данных
- 47. Классический подход к проектированию реляционных баз данных
- 48. Классический подход к проектированию реляционных баз данных
- 49. Классический подход к проектированию реляционных баз данных
- 50. Концептуальные модели и схемы баз данных Ограниченность
- 51. Концептуальные модели и схемы баз данных Семантическая
- 52. Основные понятия модели Entity-Relationship (Сущность-Связи) Сущность -
- 53. Концептуальные модели и схемы баз данных Рис.
- 54. Концептуальные модели и схемы баз данных Определение:
- 55. Рис. 29. Пример рекурсивного типа связи
- 56. Концептуальные модели и схемы баз данных Определение:
- 57. Концептуальные модели и схемы баз данных
- 58. Концептуальные модели и схемы баз данных Рис.
- 59. ER-диаграмма должна подчиняться следующим правилам: каждая сущность,
- 60. Нормальные формы ER-схем В первой нормальной форме
- 61. Концептуальные модели и схемы баз данных Рис. 35. Пример приведения ER-диаграммы к первой нормальной форме
- 62. имеются следующие FD: {номер рейса, дата-время вылета}
- 63. Концептуальные модели и схемы баз данных Рис. 36. Пример приведения ER-диаграммы ко второй нормальной форме
- 64. Концептуальные модели и схемы баз данных между
- 65. Концептуальные модели и схемы баз данных Рис. 37. Пример приведения ER-диаграммы к третьей нормальной форме
- 66. Рис. 38. Супертипы и подтипы сущности
- 67. Рис. 39. Пример ER-диаграммы со взаимно исключающими связями
- 68. Получение реляционной схемы из ER-схемы Шаг 1.
- 69. Получение реляционной схемы из ER-схемы Шаг 4.
- 70. Представление в реляционной схеме супертипов и подтипов
- 71. Достоинства (а)) можно отнести следующее:соответствие логике супертипов
- 72. Достоинства метода (b) состоят в следующем:действуют более
- 73. Представление в реляционной схеме взаимно исключающих связейСуществуют
- 74. Рис. 40. Возможные модификации ER-диаграмм, позволяющие избежать взаимно исключающих связей
- 75. Вариант ER-модели в нотации Баркера каждая
- 76. Вариант ER-модели в нотации Баркера Концептуальные
- 77. Вариант ER-модели в нотации Баркера Связь
- 78. Вариант ER-модели в нотации Баркера Концептуальные
- 79. Вариант ER-модели в нотации Баркера Концептуальные
- 80. Вариант ER-модели в нотации Баркера Атрибут
- 81. Вариант ER-модели в нотации Баркера Концептуальные
- 82. Вариант ER-модели в нотации Баркера Концептуальные
- 83. Вариант ER-модели в нотации Баркера Концептуальные
- 84. Вариант ER-модели в методологии IDEF1X Сущность
- 85. Вариант ER-модели в методологии IDEF1X Связь
- 86. Вариант ER-модели в методологии IDEF1X Если
- 87. Вариант ER-модели в методологии IDEF1X Концептуальные модели и схемы баз данных Рис. Неидентифицирующая связь
- 88. Вариант ER-модели в методологии IDEF1X Атрибуты
- 89. Вариант ER-модели в методологии IDEF1X Сущности
- 90. Вариант ER-модели в методологии IDEF1X Внешние
- 91. Вариант ER-модели в методологии IDEF1X Роль
- 92. Вариант ER-модели в методологии IDEF1X Концептуальные
- 93. Вариант ER-модели в методологии IDEF1X Потенциальные
- 94. Вариант ER-модели в методологии IDEF1X Инверсный
- 95. Вариант ER-модели в методологии IDEF1X Концептуальные модели и схемы баз данных Рис. Пример модели
- 96. Вариант ER-модели в методологии IDEF1X Концептуальные модели и схемы баз данных Рис. Пример модели
- 97. Скачать презентанцию
Рис. 2 Схема сетевой моделиПодходы к организации баз данныхСетевые базы данных
Слайды и текст этой презентации
Слайд 1
Рис. 1 Схема иерархической модели данных
Подходы к организации баз данных
Иерархические
базы данных
Слайд 3
Рис. 3 Соотношение основных понятий реляционного подход
Введение в реляционную
модель данных
Основные понятия реляционной модели данных
Слайд 4
Рис. 4 Ненормализованное отношение ОТДЕЛЫ-СЛУЖАЩИЕ
Введение в реляционную модель данных
Основные понятия
реляционной модели данных
Атомарность значений атрибутов, первая нормальная форма отношения
Слайд 5
Рис. 5 Отношение СЛУЖАЩИЕ: нормализованный вариант отношения ОТДЕЛЫ-СЛУЖАЩИЕ
Введение в
реляционную модель данных
Основные понятия реляционной модели данных
Атомарность значений атрибутов,
первая нормальная форма отношения
Слайд 6Трехзначная логика (3VL)
Таблица 1. Таблица истинности AND
Таблица 2. Таблица
истинности OR
Таблица 3. Таблица истинности NOT
Трехзначная логика (3VL)
Слайд 7Имеется несколько парадоксальных следствий применения трехзначной логики.
Парадокс 1.
Null-значение
не равно самому себе.
Действительно, выражение
null = null
дает значение не ИСТИНА, а НЕИЗВЕСТНО.Парадокс 2.
Неверно также, что null-значение не равно самому себе! Действительно, выражение null <> null также принимает значение не ИСТИНА, а НЕИЗВЕСТНО!
Парадокс 3.
a or (not(a)) не обязательно ИСТИНА.
И т.п.
Трехзначная логика (3VL)
Слайд 10Таблица 7. Отношение "Поставщики"
Таблица 8. Отношение "Детали"
Таблица 9. Отношение "Поставки"
Внешние
ключи
Слайд 11Стратегии поддержания ссылочной целостности
Основные:
RESTRICT (ОГРАНИЧИТЬ)
CASCADE (КАСКАДИРОВАТЬ)
Дополнительные:
SET NULL (УСТАНОВИТЬ В
NULL)
SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ)
IGNORE (ИГНОРИРОВАТЬ)
Слайд 12Технологии проектирования реляционных БД
Этапы разработки базы данных
Уровни моделирования:
Сама предметная область
Модель предметной области
Логическая модель
данных Физическая модель данных
Собственно база данных и приложения
Слайд 13Технологии проектирования реляционных БД
Критерии оценки качества логической модели данных
Адекватность
базы данных предметной области
Легкость разработки и сопровождения базы
данных Скорость выполнения операций обновления данных
(вставка, обновление, удаление кортежей)
Скорость выполнения операций выборки данных
Слайд 14Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
При проектировании базы данных решаются две основные проблемы:
Каким образом
отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было, по возможности, лучшим (эффективным, удобным и т. д.)?(Проблема логического проектирования баз данных).
Как обеспечить эффективность выполнения запросов к базе данных, т. е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создания каких дополнительных структур (например, индексов) потребовать и т. д.?
(Проблема физического проектирования баз данных).
Слайд 15Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных
форм:первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса-Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).
Основные свойства нормальных форм состоят в следующем:
каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;
при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.
Слайд 16Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Декомпозиция без потерь и функциональные зависимости
Определение: Функциональная зависимость
В
отношении r атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y:r.X -> r.Y.
Определение: Минимальная (полная) функциональная зависимость
Функциональная зависимость r.X -> r.Y называется минимальной (или полной), если атрибут Y не зависит функционально от любого точного подмножества X.
Слайд 17Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Декомпозиция без потерь и функциональные зависимости
Определение: Транзитивная функциональная зависимость
Функциональная зависимость r.X -> r.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости
r.X -> r.Z и r.Z -> r.Y
и отсутствует функциональная зависимость r.Z -> r.X.
(При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)
Слайд 18Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Декомпозиция без потерь и функциональные зависимости
Определение: Неключевой атрибут
Неключевым
атрибутом называется любой атрибут отношения, не входящий в состав ключа (в частности, первичного). Определение: Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Слайд 19Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Декомпозиция без потерь и функциональные зависимости
Декомпозиция отношения – разбиение
путем проецированияПравило:
Считаются правильными такие декомпозиции отношения, которые обратимы, т. е. имеется возможность собрать исходное отношение из декомпозированных отношений без потери информации. Такие декомпозиции называются декомпозициями без потерь.
Слайд 20Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Корректные и некорректные декомпозиции отношений. Теорема Хеза.
Рис. 6. Две
возможные декомпозиции отношения СЛУЖАЩИЕ_ПРОЕКТЫ
Слайд 21Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Корректные и некорректные декомпозиции отношений. Теорема Хеза.
Рис. 7. Результат
естественного соединения отношений СЛУЖ и ЗАРП_ПРО
Слайд 22Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Корректные и некорректные декомпозиции отношений. Теорема Хеза.
Теорема Хеза.
Пусть задано
отношение r {A, B, C} (A, B и C, в общем случае, являются составными атрибутами) и выполняется FD A -> BТогда:
r = (r PROJECT {A, B}) NATURAL JOIN (r PROJECT {A, C}).
Слайд 23Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Корректные и некорректные декомпозиции отношений. Теорема Хеза.
Рис. 8. Декомпозиция без
потерь по теореме Хеза
Слайд 24Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Первая нормальная форма
Определение: Первая нормальная форма
Переменная отношения находится в
первой нормальной форме, если обладает следующими свойствами: в отношении нет одинаковых кортежей.
кортежи не упорядочены.
атрибуты не упорядочены.
все значения атрибутов атомарны
Слайд 25Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Рис. 11. Возможное значение переменной отношения СЛУЖАЩИЕ_ПРОЕКТЫ_ЗАДАНИЯ
Слайд 26Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Рис. 10. Диаграмма множества FD отношения СЛУЖАЩИЕ_ПРОЕКТЫ_ЗАДАНИЯ
Слайд 27Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Аномалии обновления, возникающие из-за наличия неминимальных функциональных зависимостей
(на
примере отношения СЛУЖАЩИЕ_ПРОЕКТЫ_ЗАДАНИЯ)Добавление кортежей. Мы не можем дополнить отношение СЛУЖАЩИЕ_ПРОЕКТЫ_ЗАДАНИЯ данными о служащем, который в данное время еще не участвует ни в одном проекте (ПРО_НОМ является частью первичного ключа и не может содержать неопределенных значений).
Удаление кортежей. Мы не можем сохранить в отношении СЛУЖАЩИЕ_ПРОЕКТЫ_ЗАДАНИЯ данные о служащем, завершившем участие в своем последнем проекте (по той причине, что значение атрибута ПРО_НОМ для этого служащего становится неопределенным).
Модификация кортежей. Чтобы изменить разряд служащего, мы будем вынуждены модифицировать все кортежи с соответствующим значением атрибута СЛУ_НОМ.
Слайд 28Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Возможная декомпозиция
Рис. 12 Диаграммы FD в переменных отношений СЛУЖ
и СЛУЖ_ПРО_ЗАДАН
Слайд 29Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Рис. 13. Значения переменных отношений
Слайд 30Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Вторая нормальная форма
Определение: Вторая нормальная форма
Переменная отношения находится во
второй нормальной форме (2NF)тогда и только тогда:
когда она находится в первой нормальной форме, и
каждый неключевой атрибут минимально функционально зависит от первичного ключа.
Слайд 31Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Аномалии обновлений, возникающие из-за наличия транзитивных функциональных зависимостей (
на примере отношения СЛУЖ)Добавление кортежей. Невозможно сохранить данные о новом разряде (и соответствующем ему размере зарплаты), пока не появится служащий с новым разрядом. (Первичный ключ не может содержать неопределенные значения.)
Удаление кортежей. При увольнении последнего служащего с данным разрядом мы утратим информацию о наличии такого разряда и соответствующем размере зарплаты.
Модификация кортежей. При изменении размера зарплаты, соответствующей некоторому разряду, мы будем вынуждены изменить значение атрибута СЛУ_ЗАРП в кортежах всех служащих, которым назначен этот разряд (иначе не будет выполняться FD СЛУ_УРОВ ->СЛУ_ЗАРП ).
Слайд 32Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Возможная декомпозиция
Рис. 14 Диаграммы FD в отношениях СЛУЖ1 и
УРОВ
Слайд 33Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Третья нормальная форма
Определение: Третья нормальная форма
Переменная отношения находится в
третьей нормальной форме (3NF) в том и только в том случае, когда онанаходится во второй нормальной форме, и
каждый неключевой атрибут нетранзитивно функционально зависит от первичного ключа.
Слайд 34Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Независимые проекции отношений. Теорема Риссанена
Рис. Варианты проекций отношения
Слайд 35Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Независимые проекции отношений. Теорема Риссанена
Теорема Риссанена
Проекции r1 и r2
отношения r являются независимыми тогда и только тогда, когда: каждая FD в отношении r логически следует из FD в r1 и r2;
общие атрибуты r1 и r2 образуют возможный ключ хотя бы для одного из этих отношений.
Слайд 36Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Определение
Атомарным отношением называется отношение, которое невозможно декомпозировать на независимые
проекции. Например,
отношение СЛУЖ2 {СЛУ_НОМ, СЛУ_ЗАРП, ПРО_НОМ} с множеством FD {СЛУ_НОМСЛУ_ЗАРП, СЛУ_НОМПРО_НОМ} не является атомарным, т.к.
возможна декомпозиция на независимые проекции:
СЛУЖ3 {СЛУ_НОМ, СЛУ_ЗАРП} и СЛУЖ4 {СЛУ_НОМ, ПРО_НОМ}.
Слайд 37Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Аномалии обновлений, связанные с наличием перекрывающихся возможных ключей
Рис. 16 Диаграмма
FD отношения СЛУЖ_ПРО_ЗАДАН1
Слайд 38Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Аномалии обновлений, связанные с наличием перекрывающихся возможных ключей
Рис. 17. Возможное
значение переменной отношения СЛУЖ_ПРО_ЗАДАН1
Слайд 39Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Третья нормальная форма
Определение: Нормальная форма Бойса-Кодда
Переменная отношения находится в
нормальной форме Бойса-Кодда (BCNF) в том и только в том случае,Когда любая выполняемая для этой переменной отношения нетривиальная и минимальная FD имеет в качестве детерминанта некоторый возможный ключ данного отношения.
Слайд 40 Возможная декомпозиция
Рис. 18. Диаграммы FD и значения переменных отношений
СЛУЖ_НОМ_ИМЯ и СЛУЖ_НОМ_ПРО_ЗАДАН
Слайд 41Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Многозначные зависимости и чествертая нормальная форма
Рис. 22. Возможное значение
переменной отношения СЛУЖ_ПРО_ЗАДАН 
Слайд 42
Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Аномалии обновлений:
Добавление кортежа. Если уже участвующий в проектах сотрудник присоединяется
к новому проекту, то к телу значения переменной отношения СЛУЖ_ПРО_ЗАДАН требуется добавить столько кортежей, сколько заданий выполняет этот сотрудник.Удаление кортежей. Если сотрудник прекращает участие в проектах, то отсутствует возможность сохранить данные о заданиях, которые он может выполнять.
Модификация кортежей. При изменении одного из заданий сотрудника необходимо изменить значение атрибута СЛУ_ЗАДАН в стольких кортежах, в скольких проектах участвует сотрудник.
Слайд 43Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Многозначные зависимости и четвертая нормальная форма
Рис. 23. Значения переменных
отношений СЛУЖ_ПРО_НОМ и СЛУЖ_ЗАДАНИЕ
Слайд 44Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Многозначные зависимости и четвертая нормальная форма
Определение: Четвертая нормальная форма
Переменная
отношения r находится в четвертой нормальной форме (4NF) в том и только в том случае, когда она находится в BCNF, и все MVD r являются FD с детерминантами – возможными ключами отношения r.Вариант:
Отношение r находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A -->> B все остальные атрибуты r функционально зависят от A.
Слайд 45Технологии проектирования реляционных БД
Проектирование реляционных баз данных на основе принципов
нормализации
Заключение по разделу:
Процесс проектирования реляционной базы на основе метода нормализации
преследует две основных цели:избежать избыточности хранения данных;
устранить аномалии обновления отношений.
Слайд 46Классический подход к проектированию реляционных баз данных
Анализ критериев для нормализованных
и ненормализованных моделей данных
Сравнение нормализованных и ненормализованных моделей
Слайд 47Классический подход к проектированию реляционных баз данных
Анализ критериев для нормализованных
и ненормализованных моделей данных
OLTP и OLAP-системы
OLTP-приложения (On-Line Transaction Processing (OLTP)-
оперативная обработка транзакций). Основополагающий признак: скорость и надежность выполнения коротких операций обновления данных.
Примеры: системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п.
Слайд 48Классический подход к проектированию реляционных баз данных
Анализ критериев для нормализованных
и ненормализованных моделей данных
OLTP и OLAP-системы
OLAP-приложения (On-Line Analitical Processing (OLAP)
- оперативная аналитическая обработка данных). OLAP-приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми их электронных таблиц или из других источников данных.
Разновидности OLAP-приложений:
систем поддержки принятия решений (Decision Support System - DSS)
хранилищ данных (Data Warehouse)
систем интеллектуального анализа данных (Data Mining)
Слайд 49Классический подход к проектированию реляционных баз данных
Анализ критериев для нормализованных
и ненормализованных моделей данных
OLTP и OLAP-системы
Признаки OLAP-приложений:
Добавление в систему новых
данных происходит относительно редко крупными блокамиДанные, добавленные в систему, обычно никогда не удаляются.
Перед загрузкой данные проходят различные процедуры "очистки", связанные с тем, что в одну систему могут поступать данные из многих источников
Запросы к системе являются нерегламентированными и, как правило, достаточно сложными.
Скорость выполнения запросов важна, но не критична
Слайд 50Концептуальные модели и схемы баз данных
Ограниченность реляционной модели:
Модель не
предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной
области должна независимым от модели способом представляться в голове проектировщика.Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей. Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Слайд 51Концептуальные модели и схемы баз данных
Семантическая модель данных –
средство моделирование предметной области, обеспечение возможности выражения семантики данных.
Состав семантической
моделиструктурная часть
манипуляционная часть
представление целостности
Одна из наиболее популярных семантических моделей данных –
модель «Сущность-Связи» (кратко ER-модель).
Модель была предложена Ченом (Chen) в 1976 г.
Слайд 52 Основные понятия модели Entity-Relationship (Сущность-Связи)
Сущность - это реальный или
представляемый объект, информация о котором должна сохраняться и быть доступна.
Связь - это графически изображаемая ассоциация, устанавливаемая между сущностями.
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.
Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.
Концептуальные модели и схемы баз данных
Слайд 53
Концептуальные модели и схемы баз данных
Рис. 27. Пример типа
сущности
Определение: Сущность
Сущность – это реальный или представляемый объект, информация о
котором должна сохраняться и быть доступной. 
Слайд 54
Концептуальные модели и схемы баз данных
Определение: Связь
Связь – это
графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей.
Рис. 28.
Пример типа связи
Слайд 55Рис. 29. Пример рекурсивного типа связи
каждый МУЖЧИНА является
сыном одного и только одного МУЖЧИНЫ;
каждый МУЖЧИНА
может являться отцом одного или более МУЖЧИН. Концептуальные модели и схемы баз данных
Слайд 56Концептуальные модели и схемы баз данных
Определение: Атрибут
Атрибутом сущности является
любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики
или выражения состояния сущности.Рис. 30. Пример типа сущности с атрибутами
Слайд 57Концептуальные модели и схемы баз данных
Уникальные идентификаторы типов сущности
Рис.
31. Тип сущности, экземпляры которого идентифицируются атрибутами
Слайд 58Концептуальные модели и схемы баз данных
Рис. 32. Тип сущности,
экземпляры которого идентифицируются связью
Рис. 33. Тип сущности, экземпляры которого идентифицируются
комбинацией связей
Слайд 59ER-диаграмма должна подчиняться следующим правилам:
каждая сущность, каждый атрибут и
каждая связь должны иметь имя (связь супертипа или ассоциативная связь
может не иметь имени);имя сущности должно быть уникально в рамках модели данных;
имя атрибута должно быть уникально в рамках сущности;
имя связи должно быть уникально, если для нее генерируется таблица БД;
каждый атрибут должен иметь определение типа данных;
Концептуальные модели и схемы баз данных
Слайд 60Нормальные формы ER-схем
В первой нормальной форме ER-схемы устраняются повторяющиеся
атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных"
под атрибуты.Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
Концептуальные модели и схемы баз данных
Слайд 61Концептуальные модели и схемы баз данных
Рис. 35. Пример приведения
ER-диаграммы к первой нормальной форме
Слайд 62имеются следующие FD:
{номер рейса, дата-время вылета} -> бортовой номер
самолета;
номер рейса аэропорт -> вылета;
номер рейса -> аэропорт
назначения;бортовой номер самолета -> тип самолета.
Концептуальные модели и схемы баз данных
Слайд 63Концептуальные модели и схемы баз данных
Рис. 36. Пример приведения
ER-диаграммы ко второй нормальной форме
Слайд 64Концептуальные модели и схемы баз данных
между уникальным идентификатором
и другими атрибутами типа сущности ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие функциональные
зависимости:{КОГДА, НА ЧЕМ, дата-время вылета} -> бортовой номер самолета
{КОГДА, НА ЧЕМ, дата-время вылета} -> тип самолета
бортовой номер самолета -> тип самолета
Слайд 65Концептуальные модели и схемы баз данных
Рис. 37. Пример приведения
ER-диаграммы к третьей нормальной форме
Слайд 68Получение реляционной схемы из ER-схемы
Шаг 1. Каждая простая сущность
превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом
и не имеющая подтипов. Имя сущности становится именем таблицы.Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Концептуальные модели и схемы баз данных
Слайд 69Получение реляционной схемы из ER-схемы
Шаг 4. Связи многие-к-одному (и
один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с
конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
все подтипы в одной таблице (а)
для каждого подтипа - отдельная таблица (б)
Концептуальные модели и схемы баз данных
Слайд 70Представление в реляционной схеме супертипов и подтипов сущности
Если в концептуальной
схеме (ER-диаграмме) присутствуют подтипы, то возможны два способа их представления
в реляционной схеме:(a) собрать все подтипы в одной таблице;
(б) для каждого подтипа образовать отдельную таблицу.
Слайд 71Достоинства (а)) можно отнести следующее:
соответствие логике супертипов и подтипов;
обеспечение
простого доступа к экземплярам супертипа и не слишком сложный доступ
к экземплярам подтипов;возможность обойтись небольшим числом таблиц.
Недостатки метода (a):
прикладная программа, имеющая дело с одной таблицей супертипа, должна включать дополнительную логику работы с разными наборами столбцов (в зависимости от значения столбца ТИП) и разными ограничениями целостности (в зависимости от особенностей связей, определенных для подтипа);
общая для всех подтипов таблица потенциально может стать узким местом при многопользовательском доступе по причине возможности блокировки таблицы целиком;
для индивидуальных столбцов подтипов должна допускаться возможность содержать неопределенные значения; таким образом, потенциально в общей таблице будет содержаться много неопределенных значений, что при использовании некоторых РСУБД может потребовать значительного объема внешней памяти.
Слайд 72Достоинства метода (b) состоят в следующем:
действуют более понятные правила работы
с подтипами (каждому подтипу соответствует одноименная таблица);
упрощается логика приложений; каждая
программа работает только с нужной таблицей.Недостатки метода (b):
в общем случае требуется слишком много отдельных таблиц;
работа с экземплярами супертипа на основе представления, объединяющего таблицы супертипов, может оказаться недостаточно эффективной;
поскольку множество экземпляров супертипа является объединением множеств экземпляров подтипов, не все РСУБД могут обеспечить выполнение операций модификации экземпляров супертипа.
Слайд 73Представление в реляционной схеме взаимно исключающих связей
Существуют два способа формирования
схемы реляционной БД при наличии взаимно исключающих связей (имеются в
виду связи «один ко многим», причем конец связи «многие» находится на стороне сущности, для которой связи являются взаимно исключающими):(а) общее хранение внешних ключей;
(b) раздельное хранение внешних ключей.
Слайд 75 Вариант ER-модели в нотации Баркера
каждая сущность должна иметь
уникальное имя, и к одному и тому же имени должна
всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;
каждая сущность может обладать любым количеством связей с другими сущностями модели.
Концептуальные модели и схемы баз данных
Рис. Графическое изображение сущности
Слайд 76 Вариант ER-модели в нотации Баркера
Концептуальные модели и
схемы баз данных
Рис. Графическое отображение связей
Слайд 77 Вариант ER-модели в нотации Баркера
Связь - это ассоциация
между сущностями, при которой, как правило, каждый экземпляр одной сущности,
называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи.
Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными.
Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.
Концептуальные модели и схемы баз данных
Слайд 78 Вариант ER-модели в нотации Баркера
Концептуальные модели и схемы
баз данных
Рис. Виды связей по степени и обязательности
Рис.
Пример отображения связей 
Слайд 79 Вариант ER-модели в нотации Баркера
Концептуальные модели и схемы
баз данных
Рис. Графическое отображение атрибутов на диаграмме
Слайд 80 Вариант ER-модели в нотации Баркера
Атрибут может быть либо
обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать
неопределенных значений (null values).Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа).
Уникальный идентификатор - это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя.
Концептуальные модели и схемы баз данных
Слайд 81 Вариант ER-модели в нотации Баркера
Концептуальные модели и схемы
баз данных
Рис. Пример отображения атрибутов на диаграмме
Слайд 82 Вариант ER-модели в нотации Баркера
Концептуальные модели и схемы
баз данных
Рис. Подтипы и супертипы
Рис. Взаимно исключающие связи
Слайд 83 Вариант ER-модели в нотации Баркера
Концептуальные модели и схемы
баз данных
Рис. Рекурсивная связь (сущность может быть связана сама
с собой) Рис. Неперемещаемая связь (экземпляр сущности не может быть перенесен из одного экземпляра связи в другой)
Слайд 84 Вариант ER-модели в методологии IDEF1X
Сущность в методологии IDEF1X
является независимой от идентификаторов или просто независимой, если каждый экземпляр
сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности
Концептуальные модели и схемы баз данных
Рис. Графическое изображение сущности
Слайд 85 Вариант ER-модели в методологии IDEF1X
Связь изображается линией, проводимой
между сущностью-родителем и сущностью-потомком с точкой на конце линии у
сущности-потомка.N - каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка (по умолчанию);
P- каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
Z - каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Концептуальные модели и схемы баз данных
Рис. Мощность связи (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).
Слайд 86 Вариант ER-модели в методологии IDEF1X
Если экземпляр сущности-потомка однозначно
определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в
противном случае – неидентифицирующей.Концептуальные модели и схемы баз данных
Рис. Идентифицирующая связь
Слайд 87 Вариант ER-модели в методологии IDEF1X
Концептуальные модели и схемы
баз данных
Рис. Неидентифицирующая связь
Слайд 88 Вариант ER-модели в методологии IDEF1X
Атрибуты изображаются в виде
списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются
наверху списка и отделяются от других атрибутов горизонтальной чертойКонцептуальные модели и схемы баз данных
Рис. Атрибуты и первичные ключи
Слайд 89 Вариант ER-модели в методологии IDEF1X
Сущности могут иметь также
внешние ключи (Foreign Key), которые могут использоваться в качестве части
или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.Концептуальные модели и схемы баз данных
Рис. Примеры внешних ключей
Слайд 90 Вариант ER-модели в методологии IDEF1X
Внешние ключи определяются как
атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их
связь. Передаваемые атрибуты называются мигрирующими.Концептуальные модели и схемы баз данных
Рис. Объект с мигрировавшим внешним ключом (FK).
Слайд 91 Вариант ER-модели в методологии IDEF1X
Роль (Rolename)
Когда внешние ключи
мигрируют от родительской сущности через связь к дочерней сущности, они
служат в модели двойную службу. Для понимания обеих ролей, иногда является полезным переименовать передаваемый ключ, для того, чтобы показать, какую он играет роль в дочерней сущности. Имя, назначаемое этому атрибуту, называется ролью.Примечание: Имена Ролей также используются для совместимости модели с наследуемыми моделями данных, где внешний и первичный ключи имели разные названия.
Концептуальные модели и схемы баз данных
Слайд 92 Вариант ER-модели в методологии IDEF1X
Концептуальные модели и схемы
баз данных
Рис. Модель Пункта обмена валюты
Слайд 93 Вариант ER-модели в методологии IDEF1X
Потенциальные ключи, не использующиеся
в качестве первичных ключей, могут быть назначены в качестве альтернативных
ключей и записаны под этим именем в модели. Символ (AKn), где n – это номер, ставится после атрибутов, составляющих альтернативный ключ.Альтернативные ключи часто используются для отображения различных индексов, используемых при доступе к данным.
Концептуальные модели и схемы баз данных
Слайд 94 Вариант ER-модели в методологии IDEF1X
Инверсный вход – это
атрибут или группа атрибутов, которые используются для доступа к сущности
(так, как если бы они были первичными ключами), однако не обязательно находят только один экземпляр.Концептуальные модели и схемы баз данных
Слайд 95 Вариант ER-модели в методологии IDEF1X
Концептуальные модели и схемы
баз данных
Рис. Пример модели
Слайд 96 Вариант ER-модели в методологии IDEF1X
Концептуальные модели и схемы
баз данных
Рис. Пример модели
