Моделирование хранилищ данных - общие понятия. Часть 2

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

Для хранения и управления оперативными или учетными данными у нас предназначены OLTP-системы (см. Толковый словарь DG). Отличительной особенностью таких систем является (в большинстве случаев) хранение данных в реляционных базах данных. 

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

Почему Реляционная? Потому что она хранит Отношения (relations) экземпляров сущностей и их свойств между собой, которые представлены в виде таблиц с записями (row) и полями (columns). Т.е. все данные в базе соотносятся друг с другом таким образом, что соблюдаются три основных принципа поведения данных:

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

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

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

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

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

Как проще объяснить нормализацию? Представьте, что мы в одну таблицу начнем складывать данные не только заказов,  но и бухгалтерские проводки по этим заказам, а также информацию по клиентам, которые у нас эти заказы оформляли. Получим полный хаос. Даже в электронных таблицах никто так уже не делает! Под каждую сущность мы открываем отдельный лист - Лист Заказы, Лист Клиенты, Лист Проводки. И на каждом отдельном листе, в отдельной таблице, ведём все записи по учёту наших операций. То есть, говоря простым языком, нормализация данных - это наведение в них порядка :)

Если компания может себе позволить информационную систему для учета операций, то она покупает себе OLTP-систему - 1С, Галактику или аналогичные им программные продукты. Все данные в этом случае хранятся в базе данных, которая "лежит под капотом" этой информационной системы.

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

Почему при проектировании хранилища нужна нормализация - это же OLAP-система? Дело в том, что в современных системах хранения данных ядром хранилища, как правило, является детальный слой хранения данных (DDS - см. Толковый словарь DG), который зачастую строится по схеме 3NF - третья нормальная форма. Вот мы и вернулись к вопросу моделирования данных в хранилище. 

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

Связи между сущностями в базе данных оформляются через ключи - первичный и внешний (PK & FK).

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