1. Смысл нормализации схем баз данных

1. Смысл нормализации схем баз данных

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

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

Каждой нормальной форме соответствует определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером может служить ограничение первой нормальной формы – значения всех атрибутов отношения атомарны.

В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:

1) первая нормальная форма (1 NF);

2) вторая нормальная форма (2 NF);

3) третья нормальная форма (3 NF);

4) нормальная форма Бойса – Кодда (BCNF);

5) четвертая нормальная форма (4 NF);

6) пятая нормальная форма, или нормальная форма проекции-соединения (5 NF или PJ/NF).

(В данный курс лекций включается подробное рассмотрение первых четырех нормальных форм базовых отношений, поэтому мы не будем подробно разбирать четвертую и пятую нормальные формы.)

Основные свойства нормальных форм состоят в следующем:

1) каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;

2) при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

В основе процесса проектирования лежит метод нормализации, т. е. декомпозиции отношения, находящегося в предыдущей нормальной форме, на два или более отношений, которые удовлетворяют требованиям следующей нормальной формы (с этим мы столкнемся, когда нам самим придется по мере прохождения материала проводить нормализацию того или иного базового отношения).

Как уже упоминалось в разделе, посвященном созданию базовых отношений, заданные множества функциональных зависимостей, накладывают соответствующие ограничения на схемы базовых отношений. Эти ограничения в общем случае реализуются двумя методами:

1) декларативно, т. е. с помощью объявления в базовом отношении различного вида первичных, кандидатных и внешних ключей (это метод, получивший наибольшее распространение);

2) процедурно, т. е. написанием программного кода (использованием упомянутых выше так называемых триггеров).

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

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

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

Итак, вариант 1 схемы базы данных.

Сессия (№ зачетной книжки, Фамилия, Имя, Отчество, Предмет, Оценка)

В этом отношении, как видно из изображения схемы базового отношения, задан составной первичный ключ:

Primary key (№ зачетной книжки, Предмет);

Также в этом отношении задана система функциональных зависимостей:

{№ зачетной книжки} ? {Фамилия, Имя, Отчество};

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

Здесь для поддержания целостности данных по состоянию, т. е. для выполнения ограничения системы функциональной зависимости {№ зачетной книжки} ? {Фамилия, Имя, Отчество} при изменении, например, фамилии необходимо просматривать все кортежи этого базового отношения и последовательно вводить необходимые изменения. Однако так как это довольно громоздкий и трудоемкий процесс (особенно если мы имеем дело с базой данных большого учебного заведения), разработчики систем управления базами данных пришли к выводу, что этот процесс необходимо автоматизировать, т. е. сделать автоматическим. Теперь контроль выполнения этой (и любой другой) функциональной зависимости можно организовывать автоматически при помощи правильного объявления в базовом отношении различных ключей и так называемой декомпозиции (т. е. разбиения чего-либо на несколько самостоятельных частей) этого отношения.

Итак, нашу имеющуюся схему отношения «Сессия» разобьем на две схемы: схему «Студенты», содержащую только информацию о студентах данного учебного заведения, и схему «Сессия», содержащую информацию о последней прошедшей сессии. А затем объявим ключи таким образом, чтобы можно было без труда получить любую необходимую информацию.

Покажем, как будут выглядеть эти новые схемы отношений со своими ключами.

Вариант 2 схемы базы данных.

Студенты (№ зачетной книжки, Фамилия, Имя, Отчество),

Primary key (№ зачетной книжки).

Сессия (№ зачетной книжки, Предмет, Оценка),

Primary key (№ зачетной книжки, Предмет),

Foreign key (№ зачетной книжки) references Студенты (№ номер зачетной книжки).

Что мы имеем теперь? В отношении «Студенты» первичный ключ «№ зачетной книжки» функционально определяет остальные три атрибута: «Фамилия», «Имя» и «Отчество». А в отношении «Сессия» составной первичный ключ «№ зачетной книжки, Предмет» также однозначно, т. е. буквально функционально определяет последний атрибут этой схемы отношения – «Оценка». И связь между этими двумя отношениями налажена: она осуществляется посредством внешнего ключа отношения «Сессия» «№ зачетной книжки», который ссылается на одноименный атрибут отношения «Студенты» и при соответствующем запросе представляет всю необходимую информацию.

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

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Смысл жизни – 2

Из книги автора

Смысл жизни – 2 Вам случалось когда-нибудь в теплую летнюю ночь лежать, глядя на звезды, и думать, почему вы живете на свете? Каково ваше место в жизни и как следует жить дальше?Да, вот и мне не случалось.Тем не менее я выработал собственную теорию жизни, Вселенной и всего на


2.1. Слова, предложения и смысл

Из книги автора

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


Анализ транзисторных схем

Из книги автора

Анализ транзисторных схем Следующая предварительная схема представляет собой усилитель на биполярном транзисторе (BJT) с типовой схемой смещения на двух резисторах. Эта схема представлена на рис. 0.10. PSpice допускает использование встроенных моделей для биполярных


Использование Spice для исследования схем

Из книги автора

Использование Spice для исследования схем Вход в PSpice начинается с команд File, New, Text File. Анализ схемы можно провести с помощью представленного ниже входного файла:Spice Analysis of Series CircuitVs 1 0 50VR1 1 2 100 R2 2 3 50R3 3 0 150.OP.ENDНапомним, что после того как набрана последняя команда (.END), Enter лучше


Анализ схем для других конфигураций

Из книги автора

Анализ схем для других конфигураций Когда транзисторные схемы не упрощаются до базовых моделей (рис. 3.7, 3.10 и 3.12), необходимо соблюдать осторожность при размещении элементов между узлами, например, для резистора, включенного между коллектором и базой в схеме с ОК (рис.


Использование z-параметров для расчета схем

Из книги автора

Использование z-параметров для расчета схем Рис. 12.15. Схема с источником и нагрузкойТипичная схема имеет неидеальный источник с полным внутренним сопротивлением на входе и полное сопротивление нагрузки, подключенное к выходу (рис. 12.15). Можно показать, что Некоторые из


4-й час Процесс нормализации

Из книги автора

4-й час Процесс нормализации На этом уроке вы ознакомитесь с процессом разделения сырой базы данных на логические единицы, называемые таблицами. Этот процесс называют процессом нормализации.Мы обсудим преимущества и недостатки нормализованных баз данных, в частности,


Урок 1 Черчение схем

Из книги автора

Урок 1 Черчение схем Изучив материал этого урока, вы научитесь чертить электросхемы с помощью редактора проектирования схем SCHEMATICS: находить нужные элементы в соответствующих программных библиотеках, размещать их на рабочем листе и редактировать полученные


Глава 12 Моделирование и изменение схем

Из книги автора

Глава 12 Моделирование и изменение схем Эта глава посвящена анализу схемы МОП-транзисторного усилителя. Особое внимание уделено тому, насколько похожи результаты измерения и моделирования схемы и чем обусловлены различия. В табл. 12.1 приведены наиболее важные результаты


R.8.2 Смысл описателей

Из книги автора

R.8.2 Смысл описателей Список описателей следует после (возможно пустого) списка спецификаций-описания (§R.7.1). Каждый описатель содержит в точности одно имя-из-описателя, которое задает описываемый идентификатор. Если не считать описаний некоторых специальных функций


Лекция № 11. Проектирование схем баз данных

Из книги автора

Лекция № 11. Проектирование схем баз данных Наиболее распространенным средством абстрактного представления схем баз данных при проектировании на логическом уровне является так называемая модель «сущность – связь». Ее еще иногда называют ER-модель, где ER – аббревиатура


6.2.2 Предопределенный Смысл Операций

Из книги автора

6.2.2 Предопределенный Смысл Операций Относительно смысла операций, определяемых пользоватлем, не делается никаких предположений. В частности, посколку не предполагается, что перегруженное = реализует присваивание ее первому операнду, не делается никакой провеки, чтобы


8.4 Смысл описателей

Из книги автора

8.4 Смысл описателей Каждый описатель считается утверждением того, что если в выражении возникает конструкция, имеющаяя ту же форму, что и описатель, то она дает объект указанного типа и класса памти. Каждый описатель содержит ровно одно оп_имя; оно опредляет описываемый


Глава 5 Создание схем и иллюстраций

Из книги автора

Глава 5 Создание схем и иллюстраций Сложно представить себе курсовую или дипломную работу без схем или иллюстраций. Схемы позволяют гораздо лучше сформулировать основные идеи работы, а иллюстрации используют для более наглядного и понятного сообщения о предмете


Смысл наследования

Из книги автора

Смысл наследования Мы уже рассмотрели основные способы наследования. Многое еще предстоит изучить, в частности, множественное наследование и детали того, что происходит с утверждениями в контексте наследования (понятие субконтрактов).Но вначале следует поразмышлять


АНАЛИЗЫ: Здравый смысл vs. законодательство

Из книги автора

АНАЛИЗЫ: Здравый смысл vs. законодательство Не секрет, что представления наших с вами соотечественников о праве очень часто далеки от реальности — даже для таких «обыденных», казалось бы, отраслей, как уголовное или гражданское. Ну а «копирайт» демонизировать, как