- •Реализация баз данных в msaccess
- •Содержание
- •Введение
- •Основные понятия бд. Запись, поле, атрибут, первичный ключ, кодирование.
- •Многотабличная база. Разбиение, типы связей.
- •Работа с реляционными базами. Нормализация.
- •IV.1. Первая нормальная форма (1нф)
- •IV.2. Вторая нормальная форма (2нф)
- •IV.3. Третья нормальная форма (3нф)
- •IV.4. Нормальная форма Бойса-Кодда (бкнф)
- •IV.5. Четвертая нормальная форма (4нф)
- •Стадии проектирования базы данных для реализации в сурбд ms access
- •Реализация. Структура главного окна ms access
- •Несколько баз данных одновременно открыть нельзя!
- •Связывание таблиц
- •Создание и удаление связей между открытыми таблицами не допускается.
- •Корректировка структуры таблицы
- •Режим заполнения таблицы. Ввод и редактирование записей
- •Первой заполняется главная таблица !
- •Не редактируются поля типа Счетчик, вычисляемые и блокированные поля.
- •Построение форм
- •Поиск и замена данных, установка фильтров, сортировка
- •XI .1. Поиск данных по одному полю
- •XI .2. Поиск и замена данных
- •XI .3. Поиск данных с помощью фильтра
- •XI .4. Сортировка
- •Создание запросов
- •XII.1 Создание простого запроса
- •Создание запросов по критериям
- •XIII.1. Запрос по критерию точного совпадения (точного несовпадения)
- •XIII.2. Запрос по нескольким критериям
- •XIII.3. Запрос с параметром
- •XIII.4. Вычисляемые поля в запросах
- •Результаты вычислений нельзя редактировать!
- •XIII.5. Выражения для даты и времени
- •XIII.6. Использование условий выбора при вычислениях
- •Итоговые запросы. Групповые операции
- •XIV.1. Вычисление суммы величин
- •XIV.2. Вычисление процентов
- •XIV.3. Вычисление максимального и минимального значений поля
- •Запросы действия (модифицирующие запросы)
- •XV.1. Запросы удаления
- •Создание архивной таблицы
- •XV.2. Запросы добавления
- •XV.3. Запросы обновления
- •Отчеты по запросам
- •Создание отчета по практике
- •Литература
IV.3. Третья нормальная форма (3нф)
Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит функционально от любого другого неключевого поля.
Можно произвести декомпозицию таблицы СОТРУДНИКИ-ОТДЕЛЫ в две таблицы СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР (r) СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
На практике третья нормальная форма схем отношений вполне достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.
IV.4. Нормальная форма Бойса-Кодда (бкнф)
Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей.
Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.
Предположим теперь, что в таблице
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН) включено поле СОТР_ИМЯ
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР (r) CОТР_ИМЯ
СОТР_НОМЕР (r) ПРО_НОМЕР
СОТР_ИМЯ (r) CОТР_НОМЕР
СОТР_ИМЯ (r) ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР (r) CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем (это не очень хорошее предположение, но вполне достаточное для примера).
В соответствии с определением 3НФ таблица СОТРУДНИКИ-ПРОЕКТЫ находится в 3НФ. Однако, например, для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все записи, включающие его номер.
Подобную аномалию можно обойти, если произвести декомпозицию таблицы СОТРУДНИКИ-ПРОЕКТЫ к таблицам СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи:
СОТР_НОМЕР
СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР (r) CОТР_ИМЯ или
СОТР_ИМЯ (r) СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые таблицы СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в БКНФ, и им не свойственны отмеченные аномалии.
IV.5. Четвертая нормальная форма (4нф)
Требование четвертой нормальной формы состоит в том, чтобы независимые объекты данных не хранились в одной и той же таблице, если между этими объектами существуют отношения «многие ко многим».
Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР,ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
Каждая запись таблицы связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта (предположим, что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). По причине сформулированных выше условий единственным возможным ключем таблицы является составной ключ ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и для нашей таблицы нет никаких других возможностей построения ключа. Следовательно, отношение ПРОЕКТЫ находится в БКНФ. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в таблицу ПРОЕКТЫ столько записей, сколько заданий в нем предусмотрено.
В нашем примере можно произвести декомпозицию таблицы ПРОЕКТЫ в две таблицы ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4НФ и свободны от отмеченных аномалий.
Для пятой нормальной формы требуется, чтобы исходная таблица могла быть воссоздана из новых таблиц, в которые она была преобразована или разбита. Применение 5НФ к результирующей таблице служит хорошей проверкой, не потеряны ли данные в результате проведенных преобразований.