- •Содержание
- •Введение
- •1. Основные понятия
- •1.1 Терминология, базовые принципы
- •1.1.1 Понятие базы данных, субд и информационной системы
- •1.1.2 База данных и субд
- •1.1.3 Принципы построения информационных систем
- •1.2.2 Архитектура «файл-сервер»
- •1.2 Архитектуры информационных систем
- •1.2.1 Понятие архитектуры информационной системы
- •1.2.3. Архитектура «клиент-сервер»
- •1.2.4 Многозвенные архитектуры
- •1.2.5. Информационные системы на основе web-архитектуры
- •1.2.6 Информационные системы, функционирующие в терминальном режиме
- •1.3 Модели данных
- •1.3.1 Сравнительная характеристика моделей данных
- •1. Иерархическая модель данных
- •2. Сетевая модель данных
- •3. Реляционная модель данных
- •4. Постреляционная модель данных
- •5. Объектно-ориентированная модель данных
- •1.3.2 Неформальное введение в реляционную модель
- •1. Таблицы и связи
- •2. Первичные, альтернативные и внешние ключи
- •3. Null-значения
- •4. Метаданные. Схема базы данных
- •5. Правила ссылочной целостности
- •2. Реляционная модель
- •2.1 Реляционная модель. Структурная и целостная части
- •2.1.1 Структурная часть
- •2.1.2 Атрибуты и домены. Схема отношения
- •2.1.3 Кортежи. Отношение
- •2.1.4 Потенциальные ключи. Первичный ключ
- •2.1.5 Внешние ключи
- •2.1.6 Целостная часть реляционной модели
- •2.2 Манипуляционная часть реляционной модели
- •2.2.1 Реляционная алгебра
- •2.2.2 Реляционное исчисление
- •3. Проектирование базы данных
- •3.1 Семантический анализ предметной области
- •3.1.1 Трехуровневая модель ansi/sparc
- •3.1.2 Диаграммы «сущность - связь»
- •3.1.3 Case-технологии и case-системы
- •3.1.4 Методология idef1
- •3.2 Нормализация базы данных
- •3.2.1 Определение функциональной зависимости
- •3.2.2 Математические свойства фз, теоремы
- •3.2.3 Процедура нормализации. Декомпозиция отношений
- •3.2.4 Нормальные формы
- •3.3 Денормализация. Хранилища данных
- •3.3.1 Недостатки нормализованной базы данных
- •3.3.2 Oltp и olap-системы. Data Mining
- •3.3.3 Хранилища данных
- •4. Язык sql
- •4.1 Язык ddl. Основные объекты базы данных
- •4.1.1 Общий вид команд ddl
- •4.1.2 Основные объекты бд
- •4.2 Команды ddl для работы с таблицами
- •4.2.1 Создание таблицы
- •Типы даты и времени
- •4.2.2 Удаление таблиц и изменение их структуры
- •4.2.3 Пример создания базы данных
- •4.2.4 Создание таблиц на основе других таблиц
- •4.3 Команды манипулирования данными
- •4.3.1 Команда insert
- •Insert into имя_таблицы [(список_имен_столбцов)]
- •Values (список значений)
- •Insert into имя таблицы [(список столбцов)]
- •4.3.2 Команда delete
- •4.3.3 Команда update
- •4.4 Команда выборки данных (select)
- •4.4.1 Запросы на выборку по одной таблице
- •4.4.2 Соединение таблиц в запросах
- •Декартово произведение
- •Внутреннее (естественное) соединение таблиц
- •4. Самосоединения
- •4.4.3 Вложенные запросы
- •4.4.4 Комбинированные запросы
- •4.5 Представления (view)
- •4.5.1 Понятие представления
- •4.5.2 Создание и удаление представлений
- •4.5.3 Обновление представлений
- •4.5.4 Стандартные представления словаря данных Oracle
- •4.6 Хранимый код. Триггеры
- •4.6.1 Процедурные расширения языка sql
- •1. Оператор присваивания
- •2. Условный оператор
- •3. Операторы цикла
- •4.6.2 Использование команд sql в хранимом коде
- •4.6.3 Хранимые процедуры и функции
- •4.6.4 Триггеры
- •1. Триггер на вставку нового студента
- •2. Триггеры на удаление студента
- •3. Триггер на изменение оценки
- •5. Управление доступом к данным
- •5.1 Система безопасности субд
- •Разграничение доступа пользователей.
- •5.1.1 Разграничение доступа пользователей
- •Identified by пароль
- •5.1.2 Привилегии и роли
- •5.1.3 Аудит действий пользователей
- •5.2 Поддержка транзакций
- •5.2.1 Свойства транзакции
- •5.2.2 Поддержка транзакций в языке sql
- •5.2.3 Механизмы субд для поддержки транзакций
- •5.3 Настройка производительности. Индексы
- •5.3.1 Понятие индекса
- •5.3.2 Обзор индексов Oracle
- •Заключение
- •Библиографический список
3.2 Нормализация базы данных
Диаграммы «сущность – связь» являются самым общим способом описания данных предметной области, который базируется только на семантическом анализе информации и не учитывает особенностей реляционной модели данных.
Современные методологии, такие как IDEF1X, уже используют терминологию реляционных баз данных (например, понятия внешнего ключа, ассоциированной сущности и т.д.) и позволяют проектировать модель «сущность – связь», которая затем автоматически преобразуется в схему реляционной базы данных. Однако процесс выделения сущностей и анализа связей по-прежнему остается не формализованным, а результаты существенно зависят от опыта и аналитических способностей проектировщика.
В процессе разработки основ реляционной теории был предложен формальный математический аппарат, позволяющий проектировать реляционные базы данных с минимальной избыточностью, который получил название нормализации базы данных. В настоящее время нормализация не рассматривается как основной аппарат проектирования БД, но является прекрасным средством анализа имеющейся схемы БД (например, полученной с помощью методологии IDEF1X) с целью обнаружения и устранения избыточности данных.
Нормализация основана на анализе функциональных зависимостей (ФЗ) между атрибутами отношений. Начнем с формального определения ФЗ и их математических свойств.
3.2.1 Определение функциональной зависимости
Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y.
Функциональная зависимость обозначается X Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы (подмножества), составленные из нескольких атрибутов одного отношения.
Подмножество атрибутов X называют детерминантом функциональной зависимости.
Можно сказать, что функциональные зависимости представляют собой связи типа "один ко многим", существующие внутри отношения.
Например, в отношении Сотрудники (код, ФИО, пол, дата_рождения) можно выделить довольно много ФЗ. Вот некоторые из них:
код ФИО
код пол
код дата_рождения
код (ФИО, дата_рождения),
поскольку каждому значению кода соответствует ровно одно значение атрибутов ФИО, пол и дата_рождения и любых их сочетаний. Однако нельзя с уверенностью сказать, что каждому значению ФИО соответствует ровно одно значение кода (могут оказаться полные однофамильцы), поэтому нельзя говорить о наличии ФЗ ФИО код. Тем более, не может быть, например, ФЗ дата_рождения ФИО.
Атрибуты ФИО и дата_рождения являются взаимно независимыми, поскольку в общем случае ни один из них не зависит от другого. Заметим, что если текущее состояние базы данных таково, что все ФИО различны, все равно нельзя говорить о наличии ФЗ ФИО дата_рождения, поскольку уникальность и/или неизменность столбца ФИО явно не декларирована и значения-дубликаты могут появиться в любой момент.
Стоит обратить внимания на возможность существования ФЗ ФИО пол. Создание программного кода, которое может автоматически безошибочно вычислять пол по заданному значению ФИО, весьма проблематично при существующем разнообразии способов формирования ФИО и национальных особенностях. Поэтому в существующих БД принято пол хранить явно и считать, что такой ФЗ в отношении нет.