Следует ли денормализовать базы данных OLAP для повышения производительности чтения?

Question

Следует ли денормализовать базы данных OLAP для повышения производительности чтения?

Я всегда думал, что базы данных должны быть денормализованы для производительности чтения, как это делается для проектирования баз данных OLAP, и не сильно преувеличивать 3NF для разработки OLTP.

PerformanceDBA на разных должностях, например, в Performance разных подходов к данным, основанным на времени, защищает парадигму, согласно которой база данных всегда должна быть хорошо спроектирована путем нормализации до 5NF и 6NF (нормальная форма).

Правильно ли я понял (и что я правильно понял)?

Что не так с традиционным подходом денормализации / парадигмы проектирования баз данных OLAP (ниже 3NF) и рекомендацией о том, что 3NF достаточно для большинства практических случаев использования баз данных OLTP?

Например:

"Простая правда... в том, что 6NF, правильно выполненная, является хранилищем данных" (PerformanceDBA)

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

На какие источники я могу ссылаться, пытаясь убедить мои заинтересованные стороны в том, что базы данных OLAP/ хранилища данных должны быть нормализованы?

Для улучшения видимости я скопировал сюда из комментариев:

"Было бы неплохо, если бы участники добавили (раскрыли), сколько реальных (без научных проектов) реализаций хранилища данных в 6NF они видели или в которых участвовали. Вид быстрого пула. Me = 0." - Дамир Сударевич

В статье Хранилища данных Википедии говорится:

"Нормализованный подход [против размерного подхода Ральфа Кимбалла], также называемый моделью 3NF (третья нормальная форма), чьи сторонники называются" инмонитами ", верят в подход Билла Инмона, в котором говорится, что хранилище данных должно быть смоделирован с использованием модели ER / нормализованной модели. "

Похоже, что нормализованный подход к хранилищу данных (Билл Инмон) воспринимается как не превышающий 3NF (?)

Я просто хочу понять, каково происхождение мифа (или повсеместного аксиоматического убеждения), что хранилище данных /OLAP является синонимом денормализации?

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

66

database database-design data-modeling data-warehouse olap

Источник

user200449 09 дек '10 в 01:59

9 ответов

Решение

Денормализация и агрегация - две основные стратегии, используемые для достижения производительности в хранилище данных. Просто глупо утверждать, что это не улучшает производительность чтения! Наверняка я что-то здесь неправильно понял?

Агрегация: рассмотрим таблицу с 1 миллиардом покупок. Сравните это с таблицей, содержащей один ряд с суммой покупок. Теперь, что быстрее? Выберите сумму (сумму) из таблицы в один миллиард строк или выберите сумму из таблицы из одной строки? Конечно, это глупый пример, но он достаточно четко иллюстрирует принцип агрегирования. Почему это быстрее? Потому что независимо от того, какую магическую модель / оборудование / программное обеспечение / религию мы используем, чтение 100 байтов быстрее, чем чтение 100 гигабайт. Просто как тот.

Денормализация. Типичное измерение продукта в розничном хранилище данных содержит множество столбцов. Некоторые столбцы - простые вещи, такие как "Имя" или "Цвет", но у них также есть некоторые сложные вещи, такие как иерархии. Несколько иерархий (ассортимент продукции (5 уровней), предполагаемый покупатель (3 уровня), сырье (8 уровней), способ производства (8 уровней), а также несколько вычисленных чисел, таких как среднее время выполнения заказа (с начала года)), вес / упаковка меры etcetera etcetera. Я поддерживал таблицу измерений продукта с 200+ столбцами, которая была построена из ~70 таблиц из 5 различных исходных систем. Просто глупо спорить, является ли запрос по нормализованной модели (ниже)

select product_id
  from table1
  join table2 on(keys)
  join (select average(..)
          from one_billion_row_table 
         where lastyear = ...) on(keys)
  join ...table70
 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
   and exists(select ... from )
   and not exists(select ...)
   and table20.version_id = (select max(v_id from product_ver where ...)
   and average_price between 10 and 20
   and product_range = 'High-Profile'

... быстрее, чем эквивалентный запрос в денормализованной модели:

select product_id
  from product_denormalized
 where average_price between 10 and 20
   and product_range = 'High-Profile';

Зачем? Частично по той же причине, что и агрегированный сценарий. Но еще и потому, что запросы просто "сложные". Они настолько отвратительно сложны, что оптимизатор (а теперь я расскажу об особенностях Oracle) запутается и испортит планы выполнения. Субоптимальные планы выполнения могут быть не такими уж сложными, если запрос касается небольших объемов данных. Но как только мы начинаем присоединяться к Большим таблицам, очень важно, чтобы база данных правильно разработала план выполнения. После денормализации данных в одной таблице с помощью одного синтаксического ключа (черт, почему я не добавляю больше топлива для этого продолжающегося пожара), фильтры становятся простыми фильтрами диапазона / равенства на предварительно приготовленных столбцах. Дублирование данных в новые столбцы позволяет нам собирать статистику по столбцам, что поможет оптимизатору оценить избирательность и, таким образом, предоставить нам надлежащий план выполнения (ну,...).

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

Итак, следует ли денормализовать вашу базу данных для достижения производительности чтения? Конечно нет! Это добавляет так много сложностей в вашу систему, что нет предела тому, сколько способов это перевернет, прежде чем вы доставите. Стоит ли оно того? Да, иногда вам нужно сделать это, чтобы удовлетворить конкретное требование к производительности.

Обновление 1

PerformanceDBA: 1 строка будет обновляться миллиард раз в день

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

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

Сравните это с потребностями водителей этого грузовика (тех, кто выжил). Они не могут ждать 5 часов в некотором транзитном пункте только потому, что какой-то глупый процесс агрегирования должен закончиться. Наличие двух отдельных копий данных решает обе задачи.

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

10

Источник

user472226 09 дек '10 в 23:06

Под "OLAP" я понимаю, что вы подразумеваете предметно-ориентированную реляционную базу данных / базу данных SQL, используемую для поддержки принятия решений - AKA a Data Warehouse.

Нормальная форма (обычно 5/ 6 нормальная форма), как правило, является лучшей моделью для хранилища данных. Причины нормализации хранилища данных точно такие же, как и в любой другой базе данных: это уменьшает избыточность и позволяет избежать потенциальных аномалий обновления; он избегает встроенного смещения и, следовательно, является самым простым способом поддержки изменения схемы и новых требований. Использование обычной формы в хранилище данных также помогает сделать процесс загрузки данных простым и последовательным.

Не существует "традиционного" подхода к денормализации. Хорошие хранилища данных всегда были нормализованы.

6

Источник

user191708 09 дек '10 в 08:26

Не следует ли денормализовать базу данных для повышения производительности чтения?

Хорошо, здесь идет общий ответ "Ваш пробег может меняться", "Он зависит", "Используйте подходящий инструмент для каждой работы", "Один размер не подходит всем", с небольшим количеством "Не исправляйте, если это Не сломан "

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

Это следует учитывать только тогда, когда вы сталкиваетесь с проблемой производительности (потому что вы даете преимущества нормализации и вносите сложность).

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

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

5

Источник

user14955 09 дек '10 в 02:12

Сначала моё мнение, потом немного анализа

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

Строго говоря, это неверно, см. Этот вопрос / ответ. Денормализация в строгом смысле означает отрыв любой из нормальных форм от 1NF-6NF, другие зависимости вставки, обновления и удаления рассматриваются в Принципе ортогонального проектирования.

Так что получается, что люди берут принцип компромисса " пространство-время" и запоминают термин "избыточность" (связанный с денормализацией, но не равный ему) и приходят к выводу, что вы должны иметь преимущества. Это неверное следствие, но ложное значение не позволяет вам сделать обратное.

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

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

Анализ

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

1) Взлом 1НФ

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

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

account_balances(month, report)

который будет содержать структурированные балансы XML для каждой учетной записи. Это нарушает 1NF (см. Примечания позже), но позволяет выполнить один конкретный запрос с минимальным вводом / выводом.

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

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

Это позволяет вам сказать, что домен отчета об атрибутах представляет собой набор всех возможных отчетов и что из всех них есть ровно одно значение и утверждается, что 1NF не нарушен (аналогично аргументу, что сохранение слов не нарушает 1NF, даже если Ты можешь иметь letters отношение где-то в вашей модели).

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

В любом случае это объясняет, почему люди утверждают, что нарушение NF может улучшить производительность.

2) Ломка 3НФ

Предполагая таблицы в 3NF

CREATE TABLE `t` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `member_id` int(10) unsigned NOT NULL,
  `status` tinyint(3) unsigned NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  `opening` decimal(10,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `member_id` (`member_id`),
  CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB

CREATE TABLE `m` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

с выборочными данными (1 млн строк в т, 100 тыс в м)

Примите общий запрос, который вы хотите улучшить

mysql> select sql_no_cache m.name, count(*) 
       from t join m on t.member_id = m.id 
       where t.id between 100000 and 500000 group by m.name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (1.08 sec)

Вы могли бы найти предложения, чтобы переместить атрибут name в таблицу m, которая разбивает 3NF (она имеет FD: member_id -> name и member_id не является ключом t)

после

alter table t add column varchar(255);
update t inner join m on t.member_id = t.id set t.name = m.name;

Бег

mysql> select sql_no_cache name, count(*) 
       from t where id 
       between 100000 and 500000 
       group by name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (0.41 sec)

примечания: указанное выше время выполнения запроса сокращается вдвое, но

таблица не была в 5NF/6NF для начала
тест был выполнен с no_sql_cache, поэтому большинство механизмов кеширования были исключены (и в реальных ситуациях они играют роль в производительности системы)
Потребление места увеличивается примерно в 9 раз по сравнению с именем столбца и 100 000 строк.
на t должны быть триггеры, чтобы сохранить целостность данных, что значительно замедлило бы все обновления имени и добавило бы дополнительные проверки, через которые вставки в t должны были бы пройти
вероятно, лучших результатов можно было бы достичь, отбросив суррогатные ключи и переключившись на естественные ключи, и / или индексировав, или изменив дизайн на более высокие NF.

Нормализация - это правильный путь в долгосрочной перспективе. Но у вас не всегда есть возможность перепроектировать ERP компании (которая, например, в основном уже 3NF) - иногда вы должны выполнить определенную задачу в рамках данных ресурсов. Конечно, это только краткосрочное "решение".

Нижняя линия

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

в строгом смысле, за нарушение НФ
свободно, для введения любых зависимостей вставки, обновления и удаления (оригинальные цитаты Кодда комментируют нормализацию, говоря: " нежелательные (!) зависимости вставки, обновления и удаления", см. некоторые детали здесь)

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

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

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

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

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

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

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

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

3

Источник

user207036 10 дек '10 в 11:53

Проблема со словом "денормализованный" заключается в том, что в нем не указано, в каком направлении идти. Это все равно, что пытаться добраться до Сан-Франциско из Чикаго, уезжая из Нью-Йорка.

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

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

2

Источник

user19937 23 дек '10 в 22:32

Две самые популярные методологии построения хранилища данных (БД) - это Билл Инмон и Ральф Кимбалл.

Методология Инмона использует нормализованный подход, в то время как Кимбалл использует многомерное моделирование - ненормализованную звездную схему.

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

Я не могу комментировать ни подход 6NF, ни моделирование якоря, потому что я никогда не видел и не участвовал в проекте DW с использованием этой методологии. Когда дело доходит до реализации, мне нравится путешествовать по хорошо проверенным путям - но это только я.

Итак, подведем итог: должен ли DW быть нормализован или не нормализован? Зависит от выбранной вами методологии - просто выберите один и придерживайтесь его, по крайней мере, до конца проекта.

РЕДАКТИРОВАТЬ - Пример

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

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

Дело в том, что для запуска сценария Python и SQL требовалось восемь часов (да, восемь часов) для запуска каждый день. Излишне говорить, что база данных и приложение создавались годами несколькими партиями разработчиков, так что это не совсем ваш 5NF.

Пришло время воссоздать устаревшую вещь из DW. Хорошо, для краткости это сделано, и на его создание уходит 3 минуты (три минуты), шесть секунд на подотчет. И я спешил доставить, поэтому даже не оптимизировал все запросы. Это в 8 * 60 / 3 = 160 раз быстрее, не говоря уже о преимуществах удаления восьмичасовой работы с рабочего сервера. Я думаю, что я все еще могу побриться минутку или около того, но сейчас никого это не волнует.

Для интереса я использовал метод Кимбалла (пространственное моделирование) для DW, и все, что использовалось в этой истории, имеет открытый исходный код.

Это то, о чем все это (хранилище данных) должно быть, я думаю. Имеет ли значение, какая методология (нормализованная или ненормализованная) использовалась?

РЕДАКТИРОВАТЬ 2

Для интереса у Билла Инмона есть хорошо написанная статья на его веб-сайте - "Повесть о двух архитектурах".

2

Источник

user196713 09 дек '10 в 15:32

Короткий ответ: не исправляйте проблемы с производительностью, которых у вас нет!

Что касается временных таблиц, общепринятая парадигма - иметь в каждой строке даты valid_from и valid_to. Это по-прежнему в основном 3NF, так как он только меняет семантику с "это единственная версия этой сущности" на "это единственная версия этой сущности на данный момент "

1

Источник

user38207 09 дек '10 в 02:12

Упрощение:

База данных OLTP должна быть нормализована (насколько это имеет смысл).

Хранилище данных OLAP должно быть денормализовано в таблицы фактов и измерений (чтобы минимизировать объединения).

1

Источник

user16076 09 дек '10 в 02:39

Другие вопросы по тегам database database-design data-modeling data-warehouse olap

user484814 19 янв '11 в 04:14 2011-01-19 04:14 · Accepted Answer · 2011-01-19 04:14

мифология

Я всегда думал, что базы данных должны быть денормализованы для чтения, как это делается для проектирования баз данных OLAP, и не сильно преувеличивать 3NF для разработки OLTP.

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

Нормализация против ненормализованных

("Денормализация" - это мошеннический термин, от которого я отказываюсь.)

Это научная индустрия (по крайней мере, та, которая поставляет программное обеспечение, которое не ломается; это ставит людей на Луну; оно управляет банковскими системами и т. Д.). Это регулируется законами физики, а не магии. Компьютеры и программное обеспечение - это конечные, материальные, физические объекты, подчиняющиеся законам физики. По среднему и высшему образованию я получил:

более крупный, более толстый, менее организованный объект не может работать лучше, чем меньший, более тонкий и более организованный объект.
Нормализация дает больше таблиц, да, но каждая таблица намного меньше. И хотя таблиц больше, на самом деле (а) меньше соединений и (б) соединения быстрее, потому что наборы меньше. В целом требуется меньше индексов, поскольку для каждой таблицы меньшего размера требуется меньше индексов. Нормализованные таблицы также дают значительно более короткие размеры строк.
для любого заданного набора ресурсов нормализованные таблицы:
- поместите больше строк в один и тот же размер страницы
- поэтому поместите больше строк в одно и то же пространство кеша, поэтому общая пропускная способность увеличится)
- поэтому поместите больше строк в одно и то же дисковое пространство, поэтому число операций ввода-вывода уменьшается; и когда требуется ввод / вывод, каждый ввод / вывод более эффективен.
  ,
невозможно, чтобы объект, который сильно дублирован, работал лучше, чем объект, который хранится как единая версия истины. Например. когда я удалил 5-кратное дублирование на уровне таблицы и столбца, все транзакции были уменьшены в размере; блокировка уменьшена; Аномалии обновления исчезли. Это существенно уменьшило конкуренцию и, следовательно, увеличило одновременное использование.

Таким образом, общий результат был намного выше.

По моему опыту, который доставляет и OLTP, и OLAP из одной и той же базы данных, никогда не было необходимости "нормализовать" мои нормализованные структуры, чтобы получить более высокую скорость для запросов только для чтения (OLAP). Это тоже миф.

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

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

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

Почему миф превалирует?

Ну, во-первых, это не распространено среди научных типов, которые не ищут пути преодоления законов физики.

Исходя из моего опыта, я определил три основные причины распространенности:

Для тех людей, которые не могут нормализовать свои данные, это удобное оправдание для того, чтобы этого не делать. Они могут ссылаться на магическую книгу и без каких-либо доказательств магии, они могут благоговейно сказать: "Видите, известный писатель подтверждает то, что я сделал". Не сделано, наиболее точно.
Многие кодеры SQL могут писать только простой одноуровневый SQL. Нормализованные структуры требуют немного возможностей SQL. Если у них нет этого; если они не могут производить SELECT без использования временных таблиц; если они не могут писать подзапросы, они будут психологически приклеены к бедру к плоским файлам (что и есть "ненормализованные" структуры), которые они могут обработать.
Люди любят читать книги и обсуждать теории. Без опыта. Особенно повторная магия. Это тоник, заменитель реального опыта. Любой, кто действительно нормализовал базу данных правильно, никогда не заявлял, что "нормализация происходит быстрее, чем нормализация". Для любого, кто произносит мантру, я просто говорю "покажи мне доказательства", а они никогда не приводили никаких доказательств. Таким образом, реальность такова, что люди повторяют мифологию по этим причинам без какого-либо опыта нормализации. Мы стадные животные, а неизвестность - это один из наших самых больших страхов.
Вот почему я всегда включаю "продвинутый" SQL и наставничество в любой проект.

Мой ответ

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

Позвольте мне представить вам науку в управляемых сегментах. Типичные "базы данных" первого поколения
Типичная модель из шести крупномасштабных полномасштабных заданий.

Это были закрытые "базы данных", обычно встречающиеся в небольших фирмах, а организации были крупными банками.
отлично подходит для первого поколения, настроенного на работу с приложениями, но полный провал с точки зрения производительности, целостности и качества
они были разработаны для каждого приложения, отдельно
отчетность была невозможна, они могли сообщать только через каждое приложение
поскольку "ненормализованный" миф, точное техническое определение состоит в том, что они не были нормализованы
- Чтобы "отменить нормализацию", нужно сначала нормализовать; затем немного меняйте процесс в каждом случае, когда люди показывали мне свои "ненормализованные" модели данных, простой факт: они вообще не нормализовались; таким образом, "нормализация" была невозможна; это было просто ненормализовано
поскольку у них не было много реляционных технологий или структур и управления базами данных, но они выдавались за "базы данных", я поместил эти слова в кавычки
как с научной точки зрения гарантировано для ненормализованных структур, они претерпели множество версий истины (дублирование данных) и, следовательно, высокий уровень конкуренции и низкий параллелизм, в каждой из них
у них была дополнительная проблема дублирования данных в "базах данных"
организация пыталась синхронизировать все эти дубликаты, поэтому они внедрили репликацию; что, конечно, означало дополнительный сервер; ETL и синхронизирующие сценарии, которые будут разработаны; и поддерживается; так далее
Излишне говорить, что синхронизации никогда не было достаточно, и они всегда меняли ее
При всем этом конфликте и низкой пропускной способности, не было никаких проблем с оправданием отдельного сервера для каждой "базы данных". Это не сильно помогло.

Итак, мы рассмотрели законы физики и применили немного науки. Корпоративная база данных 5NF
Мы внедрили стандартную концепцию, согласно которой данные принадлежат корпорации (а не отделам), и корпорация хотела иметь одну версию правды. База данных была чисто реляционной, нормализованной до 5NF. Чистая открытая архитектура, так что любое приложение или инструмент отчета может получить к ней доступ. Все транзакции в хранимых процессах (в отличие от неконтролируемых строк SQL по всей сети). Те же разработчики для каждого приложения кодировали новые приложения после нашего "продвинутого" обучения.

Видимо наука работала. Ну, это была не моя личная наука или магия, это была обычная инженерия и законы физики. Все это работало на одной платформе сервера баз данных; две пары (производство и DR) серверов были выведены из эксплуатации и переданы другому отделу. 5 "баз данных" общим объемом 720 ГБ были нормализованы в одну базу данных общим объемом 450 ГБ. Около 700 таблиц (много дубликатов и дублированных столбцов) были нормализованы в 500 не дублированных таблиц. Он работал намного быстрее, как в 10 раз быстрее в целом, и более чем в 100 раз быстрее в некоторых функциях. Это не удивило меня, потому что это было моим намерением, и наука предсказывала это, но это удивляло людей мантрой.

Больше нормализации

Что ж, имея успехи с нормализацией в каждом проекте и уверенность в соответствующей науке, это было естественным шагом к нормализациибольше, а не меньше. В старые времена 3NF был достаточно хорош, а более поздние NF еще не были идентифицированы. За последние 20 лет я поставлял только базы данных с нулевыми аномалиями обновления, так что, судя по сегодняшним определениям NF, я всегда поставлял 5NF.

Аналогично, 5NF - это здорово, но у него есть свои ограничения. Например. Поворот больших таблиц (не маленьких наборов результатов в соответствии с расширением MS PIVOT) был медленным. Поэтому я (и другие) разработал способ предоставления нормализованных таблиц, чтобы Pivoting был (а) легким и (б) очень быстрым. Оказывается, теперь, когда определено 6NF, эти таблицы являются 6NF.

Поскольку я предоставляю OLAP и OLTP из одной и той же базы данных, я обнаружил, что в соответствии с наукой, чем более нормализованы структуры:

чем быстрее они выполняют
и они могут быть использованы другими способами (например, Pivots)

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

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

Прогресс на эту тему. Я всегда был специалистом по базам данных, а не специалистом по хранилищу данных, поэтому мои первые несколько проектов со складами были не полноценными реализациями, а скорее существенными заданиями по настройке производительности. Они были в моей сфере, на продуктах, на которых я специализировался. Типичное хранилище данных
Давайте не будем беспокоиться о точном уровне нормализации и т. Д., Потому что мы смотрим на типичный случай. Мы можем принять это как данность, учитывая, что база данных OLTP была достаточно нормализована, но не поддерживала OLAP, и организация приобрела совершенно отдельную платформу OLAP, аппаратное обеспечение; инвестировал в разработку и поддержку массы кода ETL; и т.д. И после внедрения потратил половину своей жизни на управление созданными ими дубликатами. Здесь нужно обвинять авторов книг и поставщиков за огромную трату аппаратного обеспечения иотдельных лицензий на программное обеспечение платформ, которые они заставляют организации покупать.

Если вы еще этого не заметили, я бы попросил вас обратить внимание на сходство между"базой данных" Typical First Generation и хранилищем данных Typical.

Тем временем, возвращаясь на ферму (базы данных 5NF выше), мы просто продолжали добавлять все больше и больше функций OLAP. Конечно, функциональность приложения выросла, но это было мало, бизнес не изменился. Они попросили бы больше 6NF, и это было легко обеспечить (5NF к 6NF - маленький шаг; 0NF к чему-либо, не говоря уже о 5NF, - большой шаг; организованную архитектуру легко расширить).

Одно из основных отличий между OLTP и OLAP, которое является основным обоснованием дляотдельного программного обеспечения платформы OLAP, заключается в том, что OLTP ориентирован на строки, ему нужны строки с транзакционной безопасностью и быстротой; и OLAP не заботится о транзакционных проблемах, ему нужны столбцы и быстро. По этой причине все платформы высокого класса BI или OLAP ориентированы на столбцы, и именно поэтому модели OLAP (Star Schema, Dimension-Fact) ориентированы на столбцы.

Но с таблицами 6NF:

нет строк, только столбцы; мы обслуживаем строки и столбцы с одинаковой скоростью
Таблицы (т. е. представление 5NF структур 6NF)уже организованы в Факты измерений. На самом деле они организованы в большее количество измерений, чем когда-либо идентифицирует любая модель OLAP, потому чтовсе они являются измерениями.
Поворот целых таблиц с агрегацией на лету (в отличие от PIVOT небольшого числа производных столбцов) - это (а) простой и простой код и (б) очень быстрый

По определению мы поставляем в течение многих лет реляционные базы данных с минимальной 5NF для использования OLTP и 6NF для требований OLAP.

Обратите внимание, что это та же самая наука, которую мы использовали с самого начала; перейти оттиповых ненормализованных "баз данных" ккорпоративной базе данных 5NF. Мы просто применяем больше проверенной науки и получаем более высокие заказы функциональности и производительности.
Обратите внимание на сходство междукорпоративной базой данных5NF и корпоративной базойданных 6NF
Вся стоимость отдельного оборудования OLAP, программного обеспечения платформы, ETL, администрирования, обслуживания - все это исключено.
Существует только одна версия данных, нет аномалий обновления или их обслуживания; одни и те же данные обслуживаются для OLTP в виде строк и для OLAP в качестве столбцов

Единственное, что мы не сделали, - это начать с нового проекта и объявить чистый 6NF с самого начала. Вот что я выстроил рядом.

Что такое шестая нормальная форма?

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

Пятая нормальная форма: все функциональные зависимости разрешены в базе данных
- в дополнение к 4NF/BCNF
- каждый не PK столбец равен 1::1 со своим PK
- и никакому другому ПК
- Нет обновлений аномалий
  ,
Шестая нормальная форма: это неприводимая NF, точка, в которой данные не могут быть дополнительно уменьшены или нормализованы (не будет 7NF)
- в дополнение к 5NF
- строка состоит из первичного ключа и не более одного неключевого столбца
- устраняет нулевую проблему

Как выглядит 6NF?

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

Этот предназначен для сбора данных мониторинга сервера (сервер базы данных корпоративного класса и ОС) для любого количества клиентов за любой период. Мы используем это для удаленного анализа проблем с производительностью и проверки любых настроек производительности, которые мы делаем. Структура не изменилась за более чем десять лет (добавлено, без изменений к существующим структурам), это типично для специализированного 5NF, который много лет спустя был идентифицирован как 6NF. Позволяет полный поворот; любой график или график, которые нужно нарисовать, в любом измерении (предусмотрено 22 точки, но это не предел); ломтик и кости; смешивать и сочетать. Обратите внимание, что они все измерения.

Данные мониторинга, метрики или векторы могут изменяться (изменяется версия сервера; мы хотим поднять что-то большее), не влияя на модель (вы можете вспомнить в другом посте, который я заявил, что EAV - ублюдок 6NF; ну, это полный 6NF, неразбавленный отец, и, следовательно, обеспечивает все функции EAV, не жертвуя какими-либо стандартами, целостностью или властью в отношениях); Вы просто добавляете строки.

▶ Модель статистических данных мониторинга ◀. (слишком большой для встроенного; некоторые браузеры не могут загрузить встроенный; нажмите на ссылку)

Это позволяет мне создавать эти ▶ диаграммы, подобные этим, шесть нажатий клавиш после получения необработанного файла статистики мониторинга от клиента. Обратите внимание на сочетание и совпадение; ОС и сервер на одном графике; множество пивотов. (Используется с разрешения.)

Читатели, которые не знакомы со Стандартом моделирования реляционных баз данных, могут найти ▶IDEF1X Notation◀ полезным.

6NF Хранилище Данных

Это было недавно подтверждено Anchor Modeling, поскольку теперь они представляют 6NF в качестве модели OLAP"следующего поколения" для хранилищ данных. (Они не предоставляют OLTP и OLAP из единой версии данных, то есть только для нас).

Хранилище данных (только) Опыт

Мой опыт работы только с хранилищами данных (не с вышеперечисленными базами данных 6NF OLTP-OLAP) позволил мне выполнить несколько важных задач, в отличие от проектов полной реализации. Результаты оказались неудивительными:

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

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

Обоснованное обоснование хранилища данных

Вот почему я указал в других статьях, единственное действительное обоснование для отдельной платформы хранилища данных, аппаратного обеспечения, ETL, обслуживания и т. Д., Когда существует множество баз данных или "баз данных", все из которых объединяются в центральное хранилище для отчетности и OLAP.

Кимбалл

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

Конечно, чтобы получить какую-либо производительность, он должен был еще больше "нормализовать", создать дополнительные дубликаты и оправдать все это.
- Таким образом, верно, что шизофреническим способом "денормализация" ненормализованных структур путем создания более специализированных копий "улучшает производительность чтения". Это не правда, когда целое принимает во внимание; это правда только внутри этого маленького убежища, а не снаружи.
- Точно так же, это сумасшедший путь, когда все "столы" являются монстрами, эти "соединения дорогие" и чего-то, чего следует избегать. У них никогда не было опыта объединения меньших таблиц и наборов, поэтому они не могут поверить научному факту, что большие меньшие таблицы быстрее.
- у них есть опыт, что создание дублирующих "таблиц" происходит быстрее, поэтому они не могут поверить, что удаление дубликатов происходит даже быстрее.
его размеры добавляются к ненормализованным данным. Ну, данные не нормализованы, поэтому никакие размеры не выставляются. Принимая во внимание, что в нормализованной модели измерения уже представлены, как неотъемлемая часть данных, добавление не требуется.
этот хорошо проложенный путь Кимбалла ведет к утесу, где больше леммингов падает быстрее. Лемминги являются стадными животными, пока они идут по пути вместе и умирают вместе, они умирают счастливыми. Лемминги не ищут других путей.

Все просто истории, части одной мифологии, которые тусуются вместе и поддерживают друг друга.

Ваша миссия

Если вы решите принять это. Я прошу вас думать самим и перестать развлекать любые мысли, которые противоречат науке и законам физики. Неважно, насколько они распространены, мистические или мифологические. Ищите доказательства чего-либо, прежде чем доверять этому. Будьте научны, проверяйте новые убеждения для себя. Повторение мантры "Денормализовано для производительности" не сделает вашу базу данных быстрее, это только заставит вас чувствовать себя лучше. Как толстый ребенок, сидящий в стороне, говорящий себе, что он может бежать быстрее, чем все дети в гонке.

Исходя из этого, даже концепция "нормализовать для OLTP", но сделать наоборот, "нормализовать для OLAP" является противоречием. Как законы физики могут работать так, как указано на одном компьютере, а на другом - наоборот? Разум поражает. Это просто невозможно, работать одинаково на каждом компьютере.

Вопросы?