Общая характеристика реляционной модели данных

Схемой реляционной  базы данных называется набор заголовков отношений, входящих в базу данных.

Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения.

6 нормальных форм БД

Официальное определение  же гласит, что:

“Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).”

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

Основные критерии:

• Все строки должны быть различными.
• Все элементы внутри ячеек должны быть атомарными (не списками). Другими словами, элемент является атомарным, если его нельзя разделить на части, которые могут использовать в таблице независимо друг от друга.

Пример не 1NF таблицы:

Категория	Товары
Книги	Война и Мир, Азбука
Игрушки	Юла

В этом примере в одной  из ячеек содержится список из двух элементов: Война и Мир, Азбука, т.е. он является не атомарным.

Исправить можно так:

Категория	Товары
Книги	Война и Мир
Книги	Азбука
Игрушки	Юла

Вот, теперь это таблица  в первой нормальной форме.

Методы приведения к 1NF:

• Устраните повторяющиеся группы в отдельных таблицах (одинаковые строки).
• Создайте отдельную таблицу для каждого набора связанных данных.
• Идентифицируйте каждый набор связанных данных с помощью первичного ключа (добавить уникальный id для каждой строки)

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

Основные критерии:

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

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

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

Например. Эта таблица  находится в первой нормальной форме, но не во второй.

Категория	Дата	Скидка	Товар
Книги	10.10.2008	10%	PHP for dummies
Ноутбуки	11.10.2008	20%	Acer
Книги	10.10.2008	10%	Windows XP

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

Исправляется это разделением  этой таблицы на две другие:

Категория	Дата	Скидка
Книги	10.10.2008	10%
Ноутбуки	11.10.2008	20%
Книги	10.10.2008	10%

Категория	Товар
Книги	PHP for dummies
Ноутбуки	Acer
Книги	Windows XP

Вот и все. Теперь эти таблицы  находятся во второй нормальной форме.

Методы приведения к 2NF:

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

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

Основные критерии:

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

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

Имя шпиона	Государство
Джеймс Бонд	Великобритания
Ким Филби	СССР
Штирлиц	СССР

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

ID	Государство
1	Великобритания
2	СССР

Имя шпиона	Государство
Джеймс Бонд	1
Ким Филби	2
Штирлиц	2

Благодаря этому правилу, при удалении какого-то государства, имена шпионов не будут утеряны 

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

Методы приведения к 3NF

• Удаление полей не зависящих от ключа

Нормальная форма  Бойса-Кодда (BCNF)

Эта форма почти то же самое, что и третья. С одним  небольшим дополнительным условием.

Основные критерии:

• Таблица находится в третьей нормальной форме
• В таблице должен быть только один потенциальный первичный ключ

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

Методы приведения к BCNF

• Вынести в отдельную таблицу потенциальные первичные ключи

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

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

Пятая нормальная форма (5NF)

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

В самом начале статьи я  показал, какие проблемы могут возникнуть при работе с не нормальными таблицами. В научной терминологии эти проблемы называют аномалиями. И, собственно, вся иерархия нормальных форм, построена таким образом, что каждая последующая ограничивает список возможных аномалий предыдущей формы. Этот процесс сопутствует процессу уменьшения энтропии базы данных, то есть наличия лишней информации. Мы добрались до 5ой нормальной формы, но этот список, в принципе никто не думал прекращать. Вот и в 1981 году Фагин (R. Fagin) опубликовал статью, в которой ввел понятие доменно-ключевой нормальной формы (ДКНФ).

Доменно-ключевая нормальная форма (ДКНФ)

В своей статье Фагин показал, отношение в ДКНФ не имеет аномалий модификации. Другими словами, что бы Вы там не меняли – ничего не потеряется, eсли соблюдены все ограничения относительно ключей и доменов.

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

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

Технологии и этапы разработки базы данных

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

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

Основные этапы  разработки базы данных

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

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

2. Утверждение плана разработки, подписание договора

После согласования плана  разработки мы подготавливаем договор  и счет, после оплаты(50% или 70%) которого начинаем подготовку технического задания.

3. Подготовка технического задания на разработку базы данных

На данном этапе мы подготавливаем подробное описание вашей базы данных.

4. Выбор технологии разработки

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

5. Разработка и описание структуры таблиц данных

6. Проектирование интерфейсов работы с базой данных

7. Разработка системных запросов к таблицам базы данных

8. Разработка форм ввода/данных

9. Программирование базы данных

10. Тестирование приложения

11. Внедрение приложения

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