Денормализация базы данных

Нормальные формы.

Правила нормализации, применяемые к таблице, уменьшают проблемные области, «поднимая» таблицы на более высокий уровень согласованности данных, особенно в процессе добавления, обновления и удаления записей. Первая нормальная форма (1NF) — является первым правилом, вторая — вторым и тд. Давайте рассмотрим эти правила подробнее.

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

Первая нормальная форма основана на атомарности значений полей в таблице. Имеется ввиду, что в поле должна храниться только какая-либо одна сущность. Например, в представленной ниже таблице к записи о сотруднике «привязано» несколько телефонных номеров. Это результат ошибок в проектировании.

Вместо этого, мы должны разместить данные в таблице следующим образом:

В результате мы получили много записей со значением NULL, более того, мы не можем добавить другой номер телефона. Лучше разделим эту таблицу на 2, так, как показано ниже.

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

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

В таблице выше, существуют следующие зависимости:

{SSN} → {EMPLOYEE_NAME}{SSN} → {PROJ_HOURS}

Также,

{PROJECT_NO} → {PROJECT_NAME}{PROJECT_NO} → {PROJECT_HOURS}

Это грубое нарушение 2NF, потому что значение полей PROJECT_HOURS и PROJECT_NAME в каждой записи функционально зависимы от PROJECT_NO. Кроме того, EMPLOYEE_NAME и PROJ_HOURS однозначно определяются значением поля SSN. Чтобы привести данные к 2NF в данном случае мы можем «разложить» таблицу EMPLOYEE_PROJECT на несколько таблиц:

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

Чтобы привести таблицу в третью нормальную форму (3NF), она должна находится во второй нормальной форме (2NF) и, самое главное, не должна содержать данные с транзитивными зависимостями. Транзитивная зависимость — это случай, когда X→Y, Y→Z, X→Z. Это значит, что любое не ключевое поле не должно быть зависимо от поля, которое не является первичным ключом таблицы. Например:

Здесь, существуют зависимости:

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}
{SSN} → {DEPT_NAME}
{SSN} → {DEPT_ADDRESS}

Однако, аномальной является следующая зависимость:

{DEPT_NAME} → {DEPT_ADDRESS}

потому что DEPT_NAME не является ключом. Мы можем устранить эту проблему, разделив таблицу на 2 таблицы.

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

В большинстве случаев, BCNF — это эквивалент 3NF. Правда эта форма строже, чем третья нормальная форма. Любая таблица, находящаяся в BCNF, находится в 3NF, но не наоборот.

BCNF — это нетривиальная функциональная зависимость X→Y в которой X, находящийся в ее левой части, является первичным ключом.

Давайте разберемся в этом на примере нескольких таблиц. Некоторые из них находятся одновременно и в 3NF и в BCNF, другие же находятся в3NF, но не в BCNF.

{SSN} → {EMPLOYEE_NAME}
{SSN} → {BIRTH_DATE}

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

{PROJECT_NO} → {PROJECT_NAME}
{PROJECT_NO} → {PROJECT_DURATION}

Таблица PROJECT также находится в BCNF.

{DEPT_NO, SSN} → {PROJECT_NO, DURATION}
{PROJECT_NO} → {DURATION, DEPT_NO}

Однако, PROJECT_INFO не находится в BCNF, потому что PROJECT_NO не является первичным ключом. Не может быть пары строк, представляющих 2 разных SSN, работающих в том же PROJECT_NO и DEPT_NO. Например:

Функциональная зависимость PROJECT_NO → DURATION нетривиальна. Таким образом, таблица не удовлетворяет определению BCNF. Мы можем устранить эту проблему, если перепроектируем эту таблицу таким образом, чтобы все полученные в результате таблицы приняли BCNF. Например:

1НФ — первая нормальная форма

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

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

Предположим, мы нарушили 1НФ и стали хранить фамилии, имена и отчества клиентов в одной колонке. Пока операторы вносили информацию, эта ошибка проектирования особенно не мешала, Однако, на следующем этапе понадобилась отчётность, в которой ФИО клиентов выводились бы в виде фамилии и инициалов. Оказалось, что некоторые записи вместо «Сидоров Петр Иванович» содержат «Петр Иванович Сидоров», в других отчества нет вовсе, в третьих фамилия двойная и не всегда записана через тире, в четвёртых после фамилий расставлены запятые… Эту проблему пришлось решать программированием совсем нетривиальной логики с элементами распознавания по словарю. Было потрачено много времени и средств, но в отчётности нет-нет да и проскакивали непонятные значения типа «Оглы П.Б.Б.».

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

Первая нормальная форма[править]

Определение:

Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда в отношении нет повторяющихся групп (атрибутов с одинаковым смыслом) все атрибуты атомарны у отношения есть ключ

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

Запрещенные конструкцииправить

Повторяющиеся группыправить

CourseId	Lecturer	Phone (1)	Phone (2)
1	Корнеев Г. А.		111-11-11
2	Киракозов А. Х.	222-22-22	333-33-33
3	Кудряшов Б. Д.	444-44-44	555-55-55
4	Сегаль А. С.	666-66-66

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

Неатомарные атрибутыправить

CourseId	Lecturer	Phones
1	Корнеев Г. А.	111-11-11
2	Киракозов А. Х.	222-22-22
333-33-33
3	Кудряшов Б. Д.	444-44-44
555-55-55
4	Сегаль А. С.	666-66-66

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

Отсутствие ключаправить

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

Приведение в 1НФправить

Для того, чтобы привести произвольное отношение в 1НФ, достаточно:

1. Рассмотреть все наборы атрибутов, имеющих одинаковый смысл
2. Для каждого фиксированного значения оставшихся атрибутов сделать по записи на каждое значение выбранных:
   • рассмотрим повторяющиеся атрибуты
   • рассмотрим оставшиеся атрибуты
   • построим такое отношение на атрибутах , что
3. Аналогичную процедуру повторить для всех неатомарных атрибутов

Отношение, использованое в примерах выше, после приведения в 1НФ будет выглядеть как

CourseId	Lecturer	Phone
1	Корнеев Г. А.	111-11-11
2	Киракозов А. Х.	222-22-22
2	Киракозов А. Х.	333-33-33
3	Кудряшов Б. Д.	444-44-44
3	Кудряшов Б. Д.	555-55-55
4	Сегаль А. С.	666-66-66

Аномалииправить

Определение:

Аномалия – эффект, возникающий при недостаточной нормализации БД или сложных зависимостях между данными, влекущий за собой проблемы возможной логической некорректности данных невозможности представления некоторых данных в данной форме технической/алгоритмической сложность внесения или изменения данных

Переход в 1НФ не уменьшает выразительную способность «разрешенных» отношений, но при этом исправляет только самые простые аномалии, поэтому в отношениях в 1НФ, не приведенных хотя бы во 2НФ, могут возникать аномалии более сложного вида.

Определение:

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

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

Определение:

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

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

Определение:

Аномалия изменения – ситуация, в которой частичное изменение данных нарушает целостность базы данных.

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

Плюсы

Нормализация не является обязательной, но приносит следующие преимущества:
— упрощается процесс выборки. Речь идет об упрощении работы по составлению запросов, то есть пользователь сможет получать нужную информацию относительно простыми запросами;
— обеспечивается целостность данных. Можно говорить о минимизации искажения информации и снижении вероятности потери данных;
— улучшается масштабируемость. При соблюдении правил нормализации формируются благоприятные предпосылки к росту БД;
— отсутствует избыточность (data redundancy). Избыточность — известная проблема непродуктивного использования свободного места на жестком диске, затрудняющая обслуживание БД. В отдельных случаях эту проблему усугубляет и то, что в случае необходимости изменения записей однотипных данных, хранимых в нескольких местах (таблицах), пользователю придется вносить требуемые изменения везде, что весьма трудоемкое занятие. Гораздо проще сделать так, чтобы, к примеру, данные о городах хранились только в таблице Cities и нигде больше. Если подытожить вышесказанное, избыточность предполагает дублирование данных, а это не только усложняет работу с БД, но и увеличивает ее размер;
— отсутствие несогласованных зависимостей. Несогласованные зависимости затрудняют доступ к данным, ведь путь к такой информации может быть неправилен и нелогичен. В той же таблице Cities логично искать города, количество жителей и т. п., но не адреса и имена жителей — для этой информации уже нужна другая таблица — Citizens.

Денормализация базы данных

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

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

• < Назад
• Вперёд >

Новые статьи:

• Объединение таблиц – UNION

• Соединение таблиц – операция JOIN и ее виды

• Тест на знание основ SQL

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы я мог развивать его дальше.

Цели

Основная цель первой нормальной формы, определенной Коддом в 1970 году, состояла в том, чтобы разрешить запрашивать данные и манипулировать ими с использованием «универсального подъязыка данных», основанного на логике первого порядка . ( SQL является примером такого подъязыка данных, хотя Кодд считал его серьезно несовершенным.)

Цели нормализации за пределами 1NF (первая нормальная форма) были сформулированы Коддом следующим образом:

Обновление аномалия . Сотрудник 519 показан как имеющий разные адреса в разных записях.

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

Удаления аномалия . Вся информация о докторе Гидденсе теряется, если он или она временно перестают участвовать в каких-либо курсах.

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

• Аномалия обновления. Одна и та же информация может быть представлена ​​в нескольких строках; поэтому обновления отношения могут привести к логическим несоответствиям. Например, каждая запись в отношении «Навыки сотрудников» может содержать идентификатор сотрудника, адрес сотрудника и квалификацию; таким образом, изменение адреса для конкретного сотрудника может потребоваться применить к нескольким записям (по одной для каждого навыка). Если обновление было успешным только частично — адрес сотрудника обновляется в некоторых записях, но не в других — тогда отношение остается в несогласованном состоянии. В частности, отношение дает противоречивые ответы на вопрос о том, каков адрес конкретного сотрудника. Это явление известно как аномалия обновления.
• Аномалия вставки. Есть обстоятельства, при которых некоторые факты вообще не могут быть зафиксированы. Например, каждая запись в отношении «Факультет и их курсы» может содержать идентификатор факультета, название факультета, дату найма преподавателя и код курса. Следовательно, сведения о любом преподавателе, который преподает хотя бы один курс, могут быть записаны, но только что нанятый преподаватель, которому еще не назначено преподавать какие-либо курсы, не может быть записан, кроме как путем установки кода курса равным нулю . Это явление известно как аномалия вставки.
• Аномалия удаления. При определенных обстоятельствах удаление данных, представляющих определенные факты, влечет за собой удаление данных, представляющих совершенно разные факты. Отношение «Преподаватели и их курсы», описанное в предыдущем примере, страдает от аномалии этого типа, поскольку, если преподаватель временно перестает быть назначенным на какие-либо курсы, последняя из записей, в которых появляется этот преподаватель, должна быть фактически удалена. также удаление преподавателя, если в поле Код курса не задано значение null. Это явление известно как аномалия удаления.

Минимизация редизайна при расширении структуры базы данных

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

Нормализованные отношения и отношения между одним нормализованным отношением и другим отражают концепции реального мира и их взаимосвязи.

Нормальная форма элементарного ключа (НФЭК)

НФЭК предложена Карло Занионо в 1982 году в качестве “компромисса” между 3НФ и НФБК.

Элементарная ФЗ

Функциональная зависимость \(f \in G\), \(f = X\to A\) называется элементарной, если она нетривиальна и замыкание \(G^+\) не содержит ФЗ \(X’\to A\) такого, что \(X’ \subset X\).

Элементарный ключ

Суперключ \(X\) отношения \(R\) называется элементарным ключом, если \(R\) удовлетворяет элементарной ФЗ \(X\to A\), где \(A\) – некий атрибут \(R\).

Отношение находится в НФЭК, если

• Оно находится в 3НФ
• Любая его элементарная ФЗ имеет в левой части суперключ или в правой части находится подмножество какого-либо элементарного ключа.

Иначе, отношение находится в НФЭК, если для любой его ФЗ \(X\to A\) выполняется хотя бы одно из условий:

• \(A\subset X\)
• \(X\) является суперключом.
• A входит в состав элементарного ключа

Декомпозиция без потерь

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

Декомпозиция

Составление проекций \(S\), \(T\) исходного отношения \(R\), таких, что объединение заголовков \(S\) и \(T\) совпадает с заголовком \(R\).

Однако, не всякая декомпозиция допустима.

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

Декомпозиция без потерь

Такая декомпозиция \(R\) в \((S,T)\), что \(R = S\bowtie T\).

Декомпозиция без потерь (lossless-join) позволяет восстановить исходное отношение при помощи операции соединения.

Как выбрать декомпозиции без потерь из всех возможных? Ответ на этот вопрос дает теорема Хита.

Теорема Хита

Пусть дано отношение \(R(A,B,C)\). Если \(R\) удовлетворяет функциональной зависимости \(A\to B\) , то \(R = \pi_{A,B} R \bowtie \pi_{A,C} R\).

Декомпозиция без потерь, однако, может не сохранять функциональные зависимости.

Например, пусть дано отношение \(R(A,B,C)\), удовлетворяющее ФЗ \(F_R=\{(A,B)\to C,C\to A\}\). По теореме Хита, \(C\to A \Rightarrow R=S(B,C)\bowtie T(C,A)\). Тогда ФЗ отношения \(S\) \(F_S=\{B\to B, C\to C\}^+\), и ФЗ отношения \(T\) \(F_T=\{C\to A\}^+\). Но \(((A,B)→C)\notin (F_S\cup F_T)^+\), и в результате оказывается потеряна.

Всегда существует декомпозиция без потерь до НФБК.

Декомпозиция, сохраняющая зависимости

Такая декомпозиция \(R\) в \((S,T)\), что замыкание множества ФЗ отношения \(R\) совпадает с замыканием объединения ФЗ отношений \(S\) и \(T\).

Декомпозиция, сохраняющая зависимости (dependency-preserving) сохраняет неизменным замыкание ФЗ всех отношений БД.

Всегда существует декомпозиция до НФЭК, сохраняющая зависимости. Однако, не всегда возможна декомпозиция, сохраняющая зависимости, до НФБК.

Демормализация в базе данных: «звезда» и «снежинка»

Как можно понять из вышеприведённых примеров, основными целями нормализации являются:

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

Но список заявленных целей касается приложений транзакционных.

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

Инфологическое проектирование

Инфологическое проектирование

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

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

Один из популярных способов построения инфологической модели – построение ER-диаграмм.

ER-диаграммы

В отличие от диаграмм атрибутов, ER-диаграммы, кроме непосредственно атрибутов, включают так же в явном виде “сущности” и “связи” между ними, откуда, собственно, и происходит название: entity-relationship diagram, или диаграмма сущности-связи.

И сущности, и связи могут обладать набором атрибутов. Сущности без атрибутов – явление достаточно бессмысленное, как Кантовская “вещь в себе”. Связи без атрибутов – явление, напротив, весьмя распространенное.

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

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

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

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

Атрибуты, входящие в первичный ключ на ER-диаграмме подчеркиваются.

Рассмотрим ER-диаграмму для примера с теннисными кортами.

Нейронные сети

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

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

большой вход убивает обратный градиент потока

3. Резюме

Стандартизация выгодна во многих случаях. Это улучшает числовую стабильность модели и часто сокращает время обучения. Однако стандартизация не всегда хороша

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

Ссылка:

: Шенкер М, Ху М.Ю., Хунг М.С.,Влияние стандартизации данных на обучение нейронной сети,https://www.sciencedirect.com/science/article/pii/0305048396000102

2НФ — вторая нормальная форма

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

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

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

Аномалия в данном случае приведёт только к избыточности хранения в виде размера идентификатора, помноженного на число строк таблицы (без учёта индексов). Но если в той же таблице обнаружится ещё и колонка «Контактный телефон», присущая атрибутике покупателя, то последствия окажутся более серьёзными. Кроме избыточности хранения при ошибке ввода придётся исправлять номер телефона во всех записях о продажах данному покупателю.

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

MinMaxScaler: приведение к диапазону [0,1]

MinMaxScaler в PySpark применяется для шкалирования в диапазоне . Рассчитывается как

X_std = (X - X.min(axis=0)) / (X.max(axis=0) - X.min(axis=0))
X_scaled = X_std * (max - min) + min
# при min=0, max=1 => X_std = X_scaled

где min и max задаются как минимальное и максимальное допустимое значение, по умолчанию min=0, max=1. Вот так выглядит Python-код для такого вида нормализации:

from pyspark.ml.feature import MinMaxScaler


scaler = MinMaxScaler(inputCol="features", outputCol="scaledFeatures")
scalerModel = scaler.fit(dataFrame)
scaledData = scalerModel.transform(dataFrame)
print("Features scaled to range: " % (scaler.getMin(), scaler.getMax()))
scaledData.select("features", "scaledFeatures").show(truncate=False)

Результат нормализации данных в PySpark:

Features scaled to range: 
+--------------+-----------------------------------------------------------+
|features      |scaledFeatures                                             |
+--------------+-----------------------------------------------------------+
||                                              |
| ||
||                                              |
+--------------+-----------------------------------------------------------+

Зачем нормализовать датасет для Data Mining и Machine Learning

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

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

После нормализации все числовые значения входных признаков будут приведены к одинаковой области их изменения – некоторому узкому диапазону. Это позволит свести их вместе в одной модели Machine Learning и обеспечит корректную работу вычислительных алгоритмов [1.

Нормализованные данные в диапазоне

Практическим приемам Feature Transformation посвящена наша следующая статья, где мы рассказываем, как именно выполняется нормализация данных: формулы, методы и средства. Все эти и другие вопросы Data Preparation рассматриваются в нашем новом курсе обучения для аналитиков Big Data: подготовка данных для Data Mining. Оставайтесь с нами!

Смотреть расписание
Записаться на курс

Источники

1. https://wiki.loginom.ru/articles/normalization.html
2. http://molbiol.ru/forums/lofiversion/index.php/t460759.html
3. https://btimes.ru/dictionary/normirovanie
4. https://neuronus.com/theory/nn/925-sposoby-normalizatsii-peremennykh.html
5. https://habr.com/ru/company/ods/blog/325422

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

Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.

Рассмотрим таблицы сотрудников и телефонных линий.

Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:

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

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

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

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

Алгоритмы, основанные на расстоянии

Стандартизация на основе дистанционных кластерных алгоритмов, таких как K-mean и K-NN, очень вероятно Алгоритм кластеризации должен рассчитывать расстояния между записями. Наиболее распространенное расстояние — это евклидово расстояние:

расстояние между i и j

Очевидно, что функция масштабирования изменит числовые расстояния между узлами.

Эксперимент:

Создайте набор данных, используя следующий код:

def random_2D_data(x,y,size):    x = (np.random.randn(size)/3.5)+x    y = (np.random.randn(size)*3.5)+y    return x,yx1,y1 = random_2D_data(2,20,50)x2,y2 = random_2D_data(2,-20,50)x3,y3 = random_2D_data(-2,20,50)x4,y4 = random_2D_data(-2,-20,50)x = np.concatenate((x1,x2,x3,x4))y = np.concatenate((y1,y2,y3,y4))

Кластеризация данных с использованием K-mean:

кластеризация без какого-либо масштабирования

Однако одно и то же для стандартизированных данных дает совершенно другой результат:

пострадавший результат

Отлично, у нас результаты противоречат друг другу. Какой результат мне выбрать?

Стандартизация дает «равные» соображения для каждой функции.

Например, X имеет две функции x1 и x2

Если вычислить евклидово расстояние напрямую, узлы 1 и 2 будут дальше друг от друга, чем узлы 1 и 3. Однако узел 3 полностью отличается от 1, тогда как узлы 2 и 1 отличаются только по признаку 1 (6%), и доля та же самая особенность 2. Это потому, что особенность 1 — особенность ‘VIP’, доминирующая над результатом с его большим численным значением.

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