Правила проектирования таблиц.

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

#Таблицы #ПроектированиеТаблиц

Правила уникальности и применения ключей.

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

Первичный ключ следует выбирать таким образом, чтобы он удовлетворял следующим требованиям:
▪️Минимальность. Первичный ключ должен содержать как можно меньше столбцов.
▪️Стабильность. Первичный ключ должен изменяться как можно реже.
▪️Простота. Первичный ключ должен быть понятным и привычным для пользователей.

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

#Ключи #ПроектированиеТаблиц

Нормализация и нормальные формы.

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

#Нормализация #НормальныеФормы

Первая нормальная форма.

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

#НормальныеФормы #ПерваяНормальнаяФорма

Вторая нормальная форма. Декомпозиция.

Во второй нормальной форме все не ключевые столбцы должны полностью зависеть от первичного ключа. Иными словами, в каждой таблице должны храниться данные только об одной сущности. Рассмотрим таблицу, она включает в себя информацию о заказах (OrderID, ClientID и OrderDate), а также о том, какие товары заказаны каждым клиентом (Item и Quantity). Чтобы привести эту таблицу ко второй нормальной форме, необходимо разбить ее на две таблицы: таблицу заказов и таблицу сведений о заказе.

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

#НормальныеФормы #ВтораяНормальнаяФорма #Декомпозиция

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

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

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

#НормальныеФормы #ТретьяНормальнаяФорма

Денормализация – умышленное нарушение правил.

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

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

#НормальныеФормы #Денормализация

Правила целостности.

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

#ПравилаЦелостности #ОбщиеПравилаЦелостности #ПравилаЦелостностиБазы

​​Общие правила целостности.

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

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

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

#ОбщиеПравилаЦелостности #СсылочнаяЦелостность #СущностнаяЦелостность

Правила целостности, относящиеся к конкретной базе данных.

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

#ПравилаЦелостности #ПравилаЦелостностиБазы