Третья нормальная форма

Таблица находится в третьей нормальной форме, если она удовлетворяет определению 2НФ и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля.

Требование третьей нормальной формы сводится к тому, чтобы все не ключевые поля зависели только от первичного ключа и не зависели друг от друга, т.е. в таблице нет полей, которые не зависят от ключа.

Пример: Таблица Заказы (Рис. 16) Рис. 16. Таблица "Заказы"

Эта таблица не находится в 3НФ, т.к. поле «Фамилия менеджера» зависит от другого неключевого поля «Код менеджера».

Для приведения к 3НФ необходимо вынести поле «Фамилия менеджера» в другую таблицу.

Получим две таблицы (Рис. 17): Рис. 17. Таблица "Заказы, таблица "Менеджеры"

На практике 3НФ схем отношений в большинстве случаев достаточна, и приведением к ней процесс проектирования реляционных БД обычно заканчивается.

Рассмотрим еще один пример:

Дана таблица ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов, Преподаватели)

Приведение к 1НФ

Так как атрибут Преподаватели подразумевает возможность наличия нескольких фамилий преподавателей в записи, относящейся к какому-то конкретному предмету, что соответствует участию нескольких преподавателей в ведении одной дисциплины.

ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Должность, Оклад, Адрес, Код предмета).

Полученные выражения соответствуют случаю, когда несколько преподавателей могут вести один предмет, но каждый преподаватель не может вести более одной дисциплины. А если учесть, что на самом деле один лектор может читать более одной дисциплины, так же как одну и ту же дисциплину могут читать несколько лекторов, необходимо отказаться от жесткой привязки препо­давателя к предмету в сущности ПРЕПОДАВАТЕЛЬ, создав дополнительную сущность ИЗУЧЕНИЕ, которая будет показывать, как связаны между собой преподаватели и предметы (Рис. 18):

ПРЕДМЕТ (Код предмета, Название, Цикл, Объем часов);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Должность, Оклад, Адрес);

ИЗУЧЕНИЕ (Код предмета, Код преподавателя).

Рис. 18. Приведение таблица к 1НФ

Приведение к 2НФ (Рис. 19):

Атрибут Цикл в таблице ПРЕДМЕТ, характеризующий принадлежность предмета к циклу гуманитарных, естественно-научных, общепро­фессиональных или специальных дисциплин, не полностью зави­сит от уникального идентификатора Код предмета, так как раз­ные предметы могут иметь одно и то же значение атрибута Цикл. Перенесем этот атрибут в новую сущность ЦИКЛ и получим че­тыре взаимосвязанных таблицы:

ПРЕДМЕТ (Код предмета, Название, Объем часов, Код цикла);

ЦИКЛ (Код цикла, Название цикла);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Должность, Оклад, Адрес);

ИЗУЧЕНИЕ (Код предмета, Код преподавателя).

Рис. 19. Приведение таблицы ко 2НФ

Приведение к 3НФ - в таблице нет полей, которые не зависят от ключа.

В данном случае неключевые атрибуты Должность и Оклад на­ходятся в транзитивной зависимости. Опасность такой зависимо­сти состоит в том, что несколько человек могут работать в одной и той же должности. При изменении должностного оклада в этом случае нужно будет менять данные в каждой записи, содержащей эту должность, следовательно, требуется создать новую сущность ДОЛЖНОСТЬ с находящимися в транзитивной зависимости ат­рибутами Название должности и Оклад и сделать ссылку от сущ­ности ПРЕПОДАВАТЕЛЬ на сущность ДОЛЖНОСТЬ (Рис. 20):

ПРЕДМЕТ (Код предмета, Название, Объем часов, Код цикла);

ЦИКЛ (Код цикла, Название цикла);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, ФИО, Код должности, Адрес);

ДОЛЖНОСТЬ (Код должности, Название должности, Оклад);

ИЗУЧЕНИЕ (Код предмета, Код преподавателя).

Рис. 20. Приведение таблицы ко 3НФ

Лекция 5. Системы управления базами данных (СУБД)

Общие сведения о СУБД

СУБД – программное обеспечение, осуществляющее создание баз данных, поддержание ее в рабочем состоянии и обеспечение эффективного доступа к данным базы для пользователей и для приложений. Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем " Базы данных " (БД).

Дадим определение СУБД:

СУБД – это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

Все современные СУБД можно разделить на три категории:

1. Программные продукты корпоративного направления — Oracle и MS SQL Server (должны быть надежными, что обеспечивается резервным копированием; безопасными — иметь защиту от несанкционированного доступа; работать с огромными объемами данных и обладать широкими функциональ­ными возможностями).

2. СУБД, предназначенные для работы с информационными массивами в небольших компаниях, — MS Access и Borland Interbase (должны обладать не только надежностью и функциональностью, но и работать без выделенного сервера).

3. СУБД для Web, реализующих создание web-сайтов с неболь­шими базами данных, — MySQL и Borland Interbase (им должна быть присуща высокая скорость обработки данных, нетребовательность к ресурсам и удобное удаленное администри­рование).

Каждая СУБД должна удовлетворять следующим требованиям:

1) Обеспечивать пользователю возможность создавать новые базы данных и определять их схему (логическую структуру данных) с помощью специального языка – языка определения данных; поддерживать разнообразные представления одних и тех же данных;

2) Позволять «запрашивать» данные (информацию из БД) и изменять их с помощью языка запросов или языка манипулирования данными; допускать интеграцию и совместное использование данных различными приложениями;

3) Поддерживать хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение длительного времени, защищая их от случайной порчи и неавторизированного использования, а также обеспечивать модификацию БД в случае необходимости и доступ к данным путем запросов, т.е. гарантировать безопасность и целостность данных;

4) Контролировать доступ к данным одновременно для многих пользователей; исключать влияние запроса одного пользователя на запрос другого и не допускать одновременный доступ, который может испортить данные, т.е. гарантировать управление параллельным доступом к данным.

Задачами СУБД являются:

· Хранение информации в структурированном виде;

· Обновление информации по мере необходимости;

· Поиск нужной информации по определенным критериям;

· Выдача информации пользователю в удобном для него виде;

· Устранение избыточности данных.

Классификация СУБД

· По степени универсальности: СУБД общего назначения (любая предметная область); специализированные СУБД;

· По технологии работы с БД (архитектура): централизованные и распределенные СУБД;

· По способу разработки приложений: непрограммируемые и программируемые СУБД.

Архитектура СУБД

Архитектура СУБД – это способ организации взаимодействия СУБД с БД через сеть. Выделяют следующие типы архитектур СУБД:

· СУБД с централизованной архитектурой;

· СУБД с архитектурой файл-сервер;

· СУБД с архитектурой клиент-сервер;

· СУБД с трёхуровневой архитектурой.

В системах с централизованной архитектурой (Рис. 1)СУБД и сама БД размещаются и функционируют на центральном компьютере, а пользователи получают доступ к БД при помощи терминалов (компьютер пользователя рассматривается как обыкновенное устройство ввода и отображения информации). Такая архитектура получила название "телеобработки". С терминалов посылались сообщения пользовательским приложениям, в свою очередь, приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. При такой архитектуре вся нагрузка возлагалась на центральный компьютер, который должен был выполнять не только действия прикладных программ и СУБД, но и значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов).

При Рис. 1. СУБД с централизованной архитектурой

В системах с архитектурой «файл-сервер» (Рис. 2)БД хранится на сервере, а копии СУБД устанавливаются на компьютерах пользователей. Файл БД, находящийся на сервере, совместно используется всеми пользователями одновременно при помощи сетевого ПО и ОС. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлам. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск. Пример: MS Access.

Рис. 2. СУБД с архитектурой "файл-сервер"

Как происходит обращение к БД: программа и драйвер находятся на РС, а БД на сервере. Пользователь передает запрос, но данные находятся удаленно; чтобы выполнить запрос вся нужная таблица (в случае Access вся БД, потому что в одном файле) выкачивается на компьютер пользователя, где драйвер обрабатывает данные.

Недостатки такой архитектуры:

· Большой объем сетевого трафика.

· На каждой рабочей станции должна находиться полная копия СУБД.

· Управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.

Клиент-серверные системы (Рис. 3). При данном подходе предполагается существование клиентского процесса, требующего определенных ресурсов, и серверного процесса, который эти ресурсы предоставляет. На компьютере пользователя хранится клиентская часть СУБД, которая обеспечивает интерактивное взаимодействие с пользователем и формирование запросов к БД (на языке SQL или др.). На сервере хранится сама БД и серверная часть СУБД, которая обеспечивает выполнение запросов.

Рис.3. СУБД с архитектурой "клиент-сервер"

Выделим выполняемые клиентом и сервером операции.

Клиент:

· Управляет пользовательским интерфейсом;

· Принимает и проверяет синтаксис введенного пользователем запроса;

· Выполняет приложение;

· Генерирует запрос к базе данных и передает его серверу;

· Отображает полученные данные пользователю.

Сервер:

· Принимает и обрабатывает запросы к базе данных со стороны клиентов;

· Проверяет полномочия пользователей;

· Гарантирует соблюдение ограничений целостности;

· Выполняет запросы/обновления и возвращает результаты клиенту;

· Поддерживает системный каталог;

· Обеспечивает параллельный доступ к базе данных;

· Обеспечивает управление восстановлением.

Этот тип архитектуры обладает следующими преимуществами.

· Обеспечивается более широкий доступ к существующим базам данных.

· Повышается общая производительность системы. Поскольку клиенты и сервер находятся на разных компьютерах, их процессоры способны выполнять приложения параллельно.

· Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения нужен только серверу - для хранения и управления базой данных.

· Сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных.

· Повышается уровень непротиворечивости данных. Сервер может самостоятельно управлять проверкой целостности данных, поскольку все ограничения определяются и проверяются только в одном месте.

· Эта архитектура хорошо согласуется с архитектурой открытых систем.

· Данная архитектура может быть использована для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети.

Большинство современных СУБД организованы по архитектуре «клиент-сервер»: Oracle, MS SQL Server, MySQL и др.

Дата добавления: 2015-07-07