
- •1.1. Архитектура бд
- •2. Тема 2. Системы управления бд (субд). Выбор систем управления бд. Функции субд.
- •3.1. Жизненный цикл бд. Этапы жц бд.
- •3.1.1. Оценка работы и поддержка б.Д. Производится оценка с точки зрения выполнения требований пользователей. В случае необходимости в систему вносятся изменения.
- •3.1.1.1. Документальные системы
- •3.1.1.2.Обобщенная функциональная структура дипс.
- •3.1.1.3. Коммерческие б.Д.
- •3.1.1.4. Коммерческие базы данных.
- •3.1.1.5. Распределенная обработка данных. Распределенные базы данных
- •3.2. Литература
- •4.1. Уровни.
- •4.2. Этапы проектирования.
- •4.3.Трехуровневая архитектура организации бд
- •4.4. Этапы проектирования: исследование проблемы, этап анализа, проектирование, реализация, внедрение, сопровождение.
- •4.5. Проектирование бд.
- •4.5.1. Этапы проектирования.
- •Тема 5. Средства и методы проектирования бд. Методика диаграмм взаимосвязей между объектами erd-диаграммы. Использование case-технологий при проектировании бд.
- •5.1. Базовые понятия.
- •5.2. Case - приложение eRwin
- •5.2.1. Объекты в eRwin
- •5.2.2. Связь в Erwin
- •6.1. Правила отношений между сущностями. Определение ключей
- •6.2. Нормализация бд. Денормализация бд.
- •Тема 7. Реляционная модель бд. Таблицы. Ограничения целостности данных. Реляционная алгебра. Реляционное исчисление.
- •Тема 8. Организация процессов обработки данных в бд. Обработка транзакций
- •Понятие транзакции.
- •9.1.1. Операторы определения данных ddl
- •9.1.2. Операторы манипулирования данными Data Manipulation Language dml
- •9.1.3. Язык запросов Data Query language (dql)
- •9.1.4. Средства администрирования данных
- •9.1.5. Программный sql
- •9.2. Оператор выборки данных select, использование условий поиска, сортировка результатов запроса. Синтаксис оператора select.
- •C.10. Тема 10. Простые запросы и правила их выполнения. Особенности многотабличных запросов. Объединение таблиц. Использование вложенных запросов
- •10.1. Простые запросы и правила их выполнения
- •10.2. Особенности многотабличных запросов
- •10.3. Объединение таблиц
- •10.4. Использование вложенных запросов
- •Тема 11. Внесение изменений в бд. Добавление информации в бд, удаление данных, изменение существующих данных.
- •C.11.1.Внесение изменений в базу данных
- •Удаление данных
- •11.2. Изменение существующих данных
- •12.1. Специальные аспекты работы с бд. Процедура индексирования.
- •12.2. Триггеры
- •12.2.1. Ключевые слова и параметры
- •12.2.2. Компоненты триггера
- •12.2.3.Типы триггеров.
- •12.2.4.Включение и выключение триггеров.
- •C.12.2.5. Удаление триггера
- •C.12.2.6. Корреляционные имена
- •12.3. Процедуры и функции
- •12.4. Функция
- •12.5.Курсоры.
- •Тема 13. Физическая организация бд на примере Oracle9i. Организация табличных пространств, журналов транзакций. Серверные процессы. Структуры памяти и взаимодействие между процессами.
- •13.1. Архитектура бд.
- •14.1. Системы обработки транзакций oltp и olap - технологий
- •14.2. Хранилища данных. Многомерные хранилища данных
- •14.3. Методы аналитической обработки (olap)
- •14.3.1. Хранилища данных
- •14.3.2. Причины внедрения информационных систем на основе хранилищ данных
- •Литература
- •14.5. Olap в России
- •Тема 15. Основы фракталов. Фрактальная математика. Фрактальные методы в архивации. Управления складами данных
- •15.1. Понятие "фрактал"
- •15.2. Классификация фракталов
- •15.2.1. Геометрические фракталы
- •15.2.2. Алгебраические фракталы
- •C.15.2.3. Стохастические фракталы
- •C.15.3. Системы итерируемых функций
- •15.4. Фрактальное сжатие
- •15.5. История фрактального сжатия
- •15.6. Идея фрактальной архивации
- •15.7. Сравнение с jpeg
- •15.8. Литература
- •Темы рефератов
6.2. Нормализация бд. Денормализация бд.
Нормализация представляет собой процесс дальнейшего совершенствования реляционной модели. Главная цель нормализации избавить реляционную таблицу от зависимостей не связанных с первичными ключами. Проведение процесса нормализации обеспечивает:
- Целостность данных (данные сохраняют корректность и достоверность, поскольку в результате нормализации они будут сохраняться только в одном месте).
- Нормализация приводит к исключению избыточности данных (нормализация опирается на данные, а не на процессы их обработки. На практике это означает, что структура БД остается неизменной даже при изменении процессов обработки).
- Снижение требований к объему памяти (Следствием этого является повышение скорости поиска данных).
Полная нормализация приводит к исключению избыточности данных. Избыточность данных всегда связана с дополнительными объемами памяти. Чем больше массив данных, тем продолжительнее поиск и ниже производительность системы.
Область |
Код |
Население |
Город |
Кол-во пред-щее |
Кол-во текущее |
Относит. прирост |
Носибирская область |
НО |
10млн. |
Новосибирск |
1100 |
1200 |
9% |
Куйбышев |
500 |
550 |
10% |
|||
Барабинск |
300 |
270 |
-9% |
|||
Омская область |
ОО |
4млн. |
Омск |
400 |
420 |
5% |
Калачинск |
200 |
210 |
5% |
|||
Алтайс.край |
АК |
5млн. |
Барнаул |
800 |
860 |
8% |
Эта таблица не нормализована, т.к. ряд атрибутов не определен к какой области относится.
1НФ. Сущность находиться в 1НФ, если значения всех её атрибутов однозначно определены. Все повторяющиеся группы должны быть удалены в новую связанную сущность. Все неопределенные группы должны быть доопределены.
Область |
Код |
Насел-ие |
Город |
Кол-тво пред-ее |
Кол-тво текущее |
Относит. прирост |
Носиб. Обл. |
НО |
10млн. |
Новосибирск |
1100 |
1200 |
9% |
Носиб. Обл. |
НО |
10млн. |
Куйбышев |
500 |
550 |
10% |
Носиб. Обл. |
НО |
10млн. |
Барабинск |
300 |
270 |
-9% |
Омская обл. |
ОО |
4млн. |
Омск |
400 |
420 |
5% |
Омская обл. |
ОО |
4млн. |
Калачинск |
200 |
210 |
5% |
Алтайс.край |
АК |
5млн. |
Барнаул |
800 |
860 |
8% |
2НФ. Сущность находиться во 2НФ, если она находится в 1НФ, а каждый её неключевой атрибут функционально полно зависит от ключа, т.е. 2НФ требует, чтобы не было неключевых атрибутов, которые зависят от части первичного ключа. 2НФ это отсутствие частичной зависимости. Для нормализации 2НФ потребуется неключевой столбец (это столбец, который не входит в состав ни одного потенциального ключа). Столбец Город можно выделить отдельно, т.е. он является не ключевым столбцом.
Область |
Код |
Население |
|
|
Город |
Колво предее |
Кол-тво текущее |
Относ. прирост |
Носиб. Обл. |
НО |
10млн. |
|
|
Новосиб-ск |
1100 |
1200 |
9% |
Омская обл. |
ОО |
4млн. |
|
|
Куйбышев |
500 |
550 |
10% |
Алтайс.край |
АК |
5млн. |
|
|
Барабинск |
300 |
270 |
9% |
|
|
|
|
|
Омск |
400 |
420 |
5% |
|
|
|
|
|
Калачинск |
200 |
210 |
5% |
|
|
|
|
|
Барнаул |
800 |
860 |
8% |
3НФ. Сущность находиться в 3НФ, если она находится во 2НФ и все её не ключевые атрибуты зависят только от первичного ключа. 3НФ это отсутствие транзистивной зависимости: ни один неключевой столбец не должен зависеть от другого неключевого столбца, т.е. все неключевые атрибуты зависят от первичного ключа.
После 3НФ идет НФ Бойса Кодда. Это отсутствие инверсионной частичной зависимости. В ней ни первичный ключ, ни какая-либо его часть не должны зависеть от неключевого атрибута. После НФБК идет 4НФ и 5НФ, они используются редко для разработки сложных больших БД.
Денормализация. Означает понижение уровня нормализации таблиц в условиях увеличения производительности таблиц. Нужно стараться не прибегать к денормализации без всяких причин, может не хватить дискового пространства. Кроме, денормализации существуют и др. пути повышения производительности. Например, индексы и модульная структура программы. Различают 2 типа денормализации: нисходящую и восходящую.
Нисходящая предполагает перенос атрибутов из родительской сущности в дочернюю.
До нормализации |
|
После нормализации |
Клиент |
|
Клиент |
Идентификатор |
|
Идентификатор |
Адрес |
|
Адрес |
|
|
Имя ┘ |
|
|
|
Заказ |
|
Заказ |
╧заказа |
|
╧заказа |
дата заказа |
|
дата заказа |
дата изготовл. |
|
дата изготовл. |
|
|
имя клиента |
т.е. мы переместили имя клиент из сущности Клиент в сущность Заказ. Единственный выигрыш в том, что избежим операции соединения, если захотим вместе с заказом увидеть фамилию клиента. Такое устранение соединений посредством нисходящей денормализации редко оправдывает затраты на введение денормализованного столбца в табл. Заказ.
Восходящая - это перенос атрибута из дочерней сущности в родительскую.
-
До нормализации
После норм-ии
Заказ
Заказ
╧заказа
╧заказа
дата заказа
дата заказа
дата изгот-я ┘
дата изгот-я
цена заказа
Статья
заказа
Статья заказа
╧заказа
╧заказа
╧статьи
╧статьи
цена статьи
цена статьи
В случае, если в дочерней таблице статья заказа будет добавлена новая строка, то в таблице Заказ цена заказа увеличится на величину цену статьи.