ИПР: различия между версиями
FireWolf (обсуждение | вклад) |
FireWolf (обсуждение | вклад) |
||
Строка 1: | Строка 1: | ||
== G3 / Нормализация БД (1-3 нормальные формы) == | == G3 / Нормализация БД (1-3 нормальные формы) == | ||
Версия 14:08, 8 июля 2021
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».