ИПР

Материал из Home Wiki
Перейти к навигации Перейти к поиску

G3 / Нормализация БД (1-3 нормальные формы)

https://info-comp.ru/database-normalization

https://info-comp.ru/first-normal-form

Требование первой нормальной формы (1NF) очень простое и оно заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы.

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

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

https://info-comp.ru/second-normal-form

Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:

   Таблица должна находиться в первой нормальной форме
   Таблица должна иметь ключ
   Все неключевые столбцы таблицы должны зависеть от полного ключа (в случае если он составной) 
     {
        Если какой-то атрибут (столбец) зависит только от одного столбца в ключе, значит, база данных не находится во второй нормальной форме.
        Иными словами, в таблице не должно быть данных, которые можно получить, зная только половину ключа, т.е. только один столбец из составного ключа.
     }


https://info-comp.ru/third-normal-form

Требование третьей нормальной формы (3NF) заключается в том, чтобы в таблицах отсутствовала транзитивная зависимость.

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

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

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

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

Главное правило третьей нормальной форме (3NF) звучит следующим образом:

   Таблица должна содержать правильные неключевые столбцы

G3 / Шардирование Репликация

G3 / Типы данных в Redis

Ключи

Redis — хранилище данных в формате «ключ-значение». Факты о ключах:

   Ключи в Redis — бинарно-безопасные (binary safe) строки.
   Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением.
   Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».


Типы данных Redis

   Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб.
   Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2^32 — 1.
   Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2^32 — 1.
   Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2^32 — 1.
   Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».