- •История развития баз данных.
- •Файлы и файловые системы.
- •Распределенные бд.
- •Архитектура бд. Физическая и логическая независимость.
- •Процесс прохождения пользовательского запроса.
- •Пользователи банков данных.
- •4. Первоначальная загрузка и ведение бд:
- •5. Защита данных:
- •Классификация моделей данных.
- •Иерархическая модель данных.
- •Сетевая модель данных.
- •Реляционная модель данных основные понятия.
- •Реляционная алгебра операции над отношениями.
- •История развития sql .
- •Структура языка sql.
- •Типы данных sql.
- •Системный анализ предметной области.
- •Инфологическая модель данных. "Сущность-связь". Основные понятия.
- •Характеристика связей и язык инфологического моделирования.
- •Классификация сущностей.
- •Элементы расширенного языка er-диаграмм.
- •Даталогическое проектирование.
- •Нормализация данных.
- •Нормальные формы.
- •Архитектура "клиент-сервер" в технологии баз данных.
- •Модели серверов баз данных.
- •Модели транзакций. Свойства транзакций.
- •Журнал транзакций.
- •Журнализация и буферизация транзакций.
- •Параллельное выполнение транзакций.
- •Хранимые процедуры.
- •Встроенный sql.
Даталогическое проектирование.
В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД.
В общем случае в результате выполнения этого этапа должны быть получены следующие результирующие документы:
Описание концептуальной схемы БД в терминах выбранной СУБД.
Описание внешних моделей в терминах выбранной СУБД.
Описание декларативных правил поддержки целостности базы данных.
Разработка процедур поддержки семантической целостности базы данных.
Проектирование схемы БД может быть выполнено двумя путями:
путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;
путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Нормализация данных.
Нормализация таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый - сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации. Но это, как говорится, подразумевается по умолчанию:).
Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал.
Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.