Проектирование базы данных

10

ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

1. Общие принципы проектирования баз данных

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

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

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области - т. е. создание частично формализованного описания объектов предметной области в терминах некоторой семантической модели.

3. Даталогическое проектирование БД, то есть описание БД в терминах выбранной СУБД, на конкретном диалекте языка SQL.

4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Структура процесса проектирования представлена на рисунке 2.1.

10

Рисунок 2.1 - Этапы проектирования

С точки зрения проектирования БД в рамках этапа анализа необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области[17].

В общем случае существует два подхода к выбору состава и структуры предметной области:

Функциональный подход -- реализует принцип «от задач» или, как его еще называют, “чего изволите” и применяется тогда, когда заранее известны функции будущих пользователей и задачи в целом. В этом случае можно четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

Предметный подход -- когда информационные потребности будущих пользователей БД до конца не определены. Они могут быть многоаспектными и изменчивыми. Нельзя точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении многих, заранее не определенных задач, что, может привести к сложной схеме БД, которая для конкретных задач будет неэффективной.

2. Модели данных

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

Данные - это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы. Примеры данных: ФИО, год рождения, адрес и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому основным понятием в области баз данных является понятие модели.

Модель данных - совокупность структур данных и операций их обработки. По способу установления связей между данными СУБД основывается на использовании трёх основных видов модели: иерархической, сетевой или реляционной; на комбинации этих моделей или на некотором их подмножестве. Однако различия между этими моделями постепенно стираются, что обусловлено, прежде всего, интенсивными работами в области баз знаний. Каждая из указанных моделей обладает характеристиками, делающими ее наиболее удобной для конкретных приложений. Одно из основных различий этих моделей состоит в том, что для иерархических и сетевых СУБД их структура часто не может быть изменена после ввода данных, тогда как для реляционных СУБД структура может изменяться в любое время.

2.1 Инфологическая модель данных

Проектирование базы данных состоит в построении комплекса взаимосвязанных моделей данных. Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели[2] предметной области, неориентированной на СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности приложение (задач и запросов). Информационно-логическая модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей. Инфологическая модель является исходной для построения даталогической модели БД и служит промежуточной моделью для специалистов предметной области (для которой создается БД) и администратора БД в процессе проектирования и разработки конкретной БД.

На практике сначала делается анализ, который должен дать подробное описание объектов предметной области, формулировку конкретных задач, которые будут решаться с использованием данной БД, с кратким описанием алгоритмов их решения, описание выходных документов, которые должны создаваться в системе, описание входных документов, которые служат источником данных для БД. Далее начинается этап собственно инфологического моделирования.

Одной из целей инфологического моделирования является достижение понимания того, что содержится в базе данных, всеми участниками проекта по созданию приложения, в основе которого лежит база данных. Иными словами, инфологическая модель призвана отражать реальный мир во множество понятных человеку концепций, независимых от особенностей реализации системы в конкретной СУБД. Для такого моделирования принято использовать совокупность диаграмм, предложенных Ченом, называемых “модель сущность-связь”. Другое название использует английскую аббревиатуру: ER-диаграмма (Entity-Relation). Впоследствии инфологическая модель должна быть отображена в даталогическую модель, понятную конкретной СУБД. Рассмотрим основные понятия инфологической модели:

Сущность - любой различимый объект, информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т.д.

Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

При построении инфологической модели следует учитывать следующее:

· четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);

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

· плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.

2.2 Модель данных «Сущность-связь»

Сущность описывает некоторый объект предметной области.

Набор сущностей - класс однотипных объектов или сущностей. Набор сущностей имеет атрибуты - характеристики, определяющие свойства объекта. Все сущности набора имеют одни и те же атрибуты. Совокупность атрибутов должна быть такой, чтобы отличить один объект от другого. Атрибуты, как правило, являются простыми значениями, такими как целые числа, числа с плавающей запятой, строки символов, даты и т. д. В диаграмме “сущность-связь” каждый набор сущностей изображается прямоугольником, который представлен на рисунке 2.2.

10

Рисунок 2.2 - Пример набора сущностей Преподаватели

Набор сущностей Сотрудники имеет как минимум 6 атрибутов (Табельный номер, Фамилия, Имя, Отчество, Адрес, Телефон …).

Связи между сущностями

Между наборами сущностей могут быть установлены связи. Связь соединяет два или больше наборов сущностей[2]. Она изображается линией, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Например, между двумя сущностям А и В возможны четыре типа связей. Сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю сущности А соответствует 1 или 0 представителей сущности В (рисунок 2.3).

10

Рисунок 2.3 - Связь ОДИН-К-ОДНОМУ

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В (рисунок 2.4).

10

Рисунок 2.4 - Связь ОДИН-КО-МНОГИМ

Третий тип - связь МНОГИЕ-К-ОДНОМУ (М:1): представителям сущности А соответствует 1 или 0 представителей сущности В (рисунок 2.5).

10

Рисунок 2.5 - Связь МНОГИЕ-К-ОДНОМУ

Четвертый тип - связь МНОГИЕ-КО-МНОГИМ (М:N): многим представителям сущности А соответствует несколько представителей сущности В (рисунок 2.6).

10

Рисунок 2.6 - Связь МНОГИЕ-КО-МНОГИМ

В качестве примера рассмотрим связь между сущностями такими как Студенты и Преподаватели (рисунок 2.7) и определим какие между ними могут существовать связи.

10

Рисунок 2.7 - Пример модели «сущность-связь»

Эта диаграмма означает, что объект набора сущностей Преподаватели связан с объектом набора сущностей Студенты (Читает лекции). Связь двунаправлена: преподаватель читает лекции студентам, студент слушает лекции преподавателей.

Вторая связь (руководит дипломным проектом) устанавливает связь объекта набора сущностей Преподаватели с объектом набора сущностей Студенты по иному признаку, а именно, устанавливается связь между преподавателями-руководителями дипломных проектов и студентами-дипломниками.

Связи могут быть охарактеризованы мощностью или кардинальностью. Например, связь руководит дипломным проектом на левом конце имеет так называемую «лапу», а на правом конце единственную линию. Это отражает тот факт, что один преподаватель может руководить несколькими дипломными проектами. В этом случае говорят, что имеет место связь “один ко многим”. Кроме мощности, характер изображения связи говорит о ее обязательности. В частности, связь руководит дипломным проектом обязательна со стороны сущности Преподаватели (не бывает дипломного проекта без руководителя). Это отражено черточкой, перпендикулярной линии связи вблизи набора сущностей Преподаватели.

Однако не каждый преподаватель руководит дипломным проектом хотя бы одного студента. Поэтому связь может и не соединять конкретного преподавателя со студентами, т. е. является “необязательной”. Это выражается наличием кружка со стороны набора сущностей Студенты.

Вторая связь, Читает лекции, является необязательной с обеих сторон. Это значит, что конкретный преподаватель может и не читать ни одной лекции в текущем семестре. А также, что конкретный студент может не слушать ни одного курса (например, быть в академическом отпуске). Кроме того, эта связь имеет “лапы” с обеих сторон и поэтому называется “многие ко многим”. В самом деле, конкретный преподаватель может читать лекции многим студентам, а конкретный студент может слушать лекции многих преподавателей.

Рекурсивная связь и Роль

Порой одна сущность используется на обоих концах связи. Чтобы лучше понимать суть взаимоотношений разных сущностей, концы связи можно наделить именами, которые соответствуют ролям сущностей в этой связи. Вообще же такая связь называется рекурсивной. На рисунке 2.8 представлен пример такой связи[17]. Его следует понимать как совокупность следующих утверждений:

· у сотрудника может быть начальник (но не более одного), а может и не быть (например, у директора начальника нет);

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

10

Рисунок 2.8 - Рекурсивная связь с ролями

Множественные связи

До сих пор были рассмотрены только ER-диаграммы, в которых встречались двухсторонние связи. Однако модель “сущность-связь” способна представить и связи с большим числом сторон. Такие связи иногда стоит ввести ввиду того, что они позволяют отразить существо взаимоотношений между понятиями моделируемой предметной области. Значение связи можно воспринимать в виде множества кортежей, атрибутами которых являются сущности (ссылки на них) из наборов сущностей, соединяемых этой связью. Любая многосторонняя связь может быть преобразована в некоторую совокупность двухсторонних связей типа “многие к одному”. С этой целью следует ввести новый набор сущностей, состоящий из кортежей, представляющих многостороннюю связь. После того, как был введен новый, связующий набор сущностей, становится удобным ввести в него дополнительные атрибуты, характеризующие собственно договор, такие как дата заключения договора, срок исполнения, сумма по договору и т. д.

Слабые наборы сущностей

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

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

2.3 Даталогическая модель данных

Под даталогической понимается модель[2], отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели.

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

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

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

При разработке даталогической модели, кроме требований предъявляемых для построения инфологической модели, предъявляются дополнительные требования:

· загруженные в базу данных корректные данные должны оставаться корректными;

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

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

· разрешение проблем, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами) ;

· способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа.

Проектирование схемы БД может быть выполнено двумя путями:

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

2. Путем синтеза, то есть путем компоновки из заданных.

2.4 Физическая модель данных

Физическая модель данных - модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы.

Физическая организация баз данных[2] определяет способы размещения данных в среде хранения и способы физического доступа к этим данным. Исторически первыми системами хранения и доступа были файлы, являвшиеся частью операционной системы. СУБД создавала над этими файлами надстройку, которая позволяла организовать их так, чтобы они работала как единое целое - база данных. Доступ осуществлялся на уровне файловых операций. По мере роста объема данных и требований, предъявляемых к СУБД, механизмы буферизации и управления файлами оказались неэффективны. Тогда произошел переход от файлов к непосредственному управлению размещением данных на носителях, осуществляемому самой СУБД. При этом пространство внешней памяти предоставляется СУБД полностью для управления, а операционная система не получает доступа к этому пространству.

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

Физическая модель данных соответствует описанию данных в БД конкретной СУБД [17], то есть схеме данных, и с ней хорошо знакомы уже все разработчики без исключения. Она непосредственно учитывает такие аспекты, как архитектуру, безопасность, эффективность доступа и другие. Можно еще заметить, что понятие «физическая модель» относительно, так как имеет тенденцию к изменению во времени, и то, что когда-то относилось к логической модели, сегодня могут приписывать физической.

3. Переход от ER-модели к реляционной

Переход от инфологической модели “сущность-связь” к реляционной - это сравнительно простая задача, поскольку в терминологии и принципах ER-модели и реляционного подхода имеется взаимно однозначное соответствие[17]. Существует ряд хорошо зарекомендовавших себя правил, с помощью которых из ER-диаграмм откроются реляционные таблицы:

Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

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

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

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

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

Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

а) все подтипы в одной таблице (таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется, по крайней мере, один столбец, содержащий код ТИПА, он становится частью первичного ключа);

б) для каждого подтипа - отдельная таблица (для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).

Имеется два способа работы при наличии исключающих связей:

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

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

3.1 Этапы проектирования базы данных

В общем случае можно выделить следующие этапы проектирования:

1. Системный анализ и словесное описание информационных объектов предметной области и выявление требований конечных пользователей и решаемых задач.

2. Проектирование инфологической модели предметной области - т.е. создание частично формализованного описания объектов предметной области в терминах некоторой семантической модели.

3. Даталогическое проектирование БД, то есть описание БД в терминах выбранной СУБД, на конкретном диалекте языка SQL.

4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

При проектировании базы данных «Терминал» была использована реляционная модель данных.

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

Реляционная модель данных - модель данных, хранящаяся в базе, описывающая взаимосвязи элементов данных в виде отношения (таблицы).

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

Реляционная модель данных отличается простотой структуры данных, удобным для пользователя табличным пред-ставлением и возможностью применения формального аппарата алгебры отношений и реляционного исчисления для обработки данных[17].

Датой рождения реляционной теории баз данных принято считать 6 июня 1970 года, когда сотрудник фирмы IBM, доктор Э. Кодд, опубликовал статью «Реляционная модель данных для больших коллективных банков». Именно в этой статье впервые встретился термин «реляционная модель данных». Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение - relation (англ.). Теоретической основой реляционной модели является теория отношений, основу которой заложили американец Ч. С. Пирс и немец Э. Шредер в конце 19 века. В их работах было показано, что множество отношений замкнуто относительно некоторых специальных операций, т.е. образует с этими операциями абстрактную алгебру. Этот факт и послужил основой для разработки языка манипулирования данными в реляционной модели.

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

3.2 Нормализация отношений

К проектированию БД можно подойти и более формально, превратив процесс проектирования в математическую процедуру[17]. Цель этой процедуры одна - спроектировать оптимальную в некотором смысле структуру данных. Выбор той или иной структуры таблиц может привести к несовершенствам или наоборот обеспечить удобство использования данных.

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

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

Проблемы, возникающие из-за неудачной структуры данных:

1. Аномалия изменения (избыточность и потенциальная противоречивость). Информация во многих столбцах многократно повторяется. Чем больше данных в отношении, тем больше дублируется информации и тем больше непроизводительных затрат. Из-за наличия многих дублей одних и тех же данных возможна ситуация, когда одна часть избыточных копий будет изменена, а другая - нет.

2. Аномалия добавления. В отношение нельзя включить поставщика, если он не осуществил ни одной поставки. Однако зачастую требуется учесть поставщика, данные о котором потенциально могут понадобиться.

3. Аномалия удаления. При удалении факта поступления товара от поставщика может потеряться и информация об этом поставщике, хотя она может пригодиться в дальнейшем.

Нормализация - разбиение таблицы на две или более, обладающие лучшими свойствами при добавлении, изменении и удалении данных.

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

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

первая нормальная форма: таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто;

вторая нормальная форма: таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом;

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

нормальная форма Бойса--Кодда: таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа;

пятая нормальная форма или форма проекции-соединения: таблица находится в пятой нормальной форме (5НФ) тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в 5НФ;

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

Основные свойства нормальных форм:

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

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

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