Oracle витрина что это

Обновлено: 28.06.2024

Размышления о разработке программного обеспечения и информационных систем

То, что действительно важно, но чему нигде не учат

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

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

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

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

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

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

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

А вот читать данные из витрины очень просто. В ней нет ничего лишнего. Только то, что необходимо при решении конкретной задачи. А потребуется другой отчёт - сделаем другую витрину!

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

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

Исходные данные поступают в нормализованную структуру в виде справочной и оперативной информации.

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

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

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

В заключение дам несколько ремарок.

Во-первых, я нарочно указал в справочниках в качестве значений идентификаторов объектов их коды. Часто объекты справочной информации классифицируются на основе некоторых общепризнанных классификаторов (международных, государственных, отраслевых, корпоративных и т.п.). Например, код региона может задаваться в соответствии с Общероссийским классификатором экономических регионов (ОКЭР). Пользователям удобнее работать с классификатором, чем запоминать длиннющие названия. Да и набирать на клавиатуре коды классификаторов проще.

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

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

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

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

В-пятых, всё сказанное выше хорошо укладывается в шаблон CQRS (Command/Query Responsibility Segregation - разделение ответственности команд и запросов). В рамках этого подхода в системе есть две модели: первая реализует команды и позволяет соблюдать бизнес-процессы, а вторая просто читает данные и передаёт их потребителям. Шаблон CQRS часто используется при предметно-ориентированном проектировании (Domain-Driven Design, DDD).

Читайте также: