OLTP-приложение для чтения данных Проектирование хранилища данных

Question

Мы только начинаем собирать хранилище данных, которое будет полезно для наших требований к отчетности, объединяя разнородные источники данных.

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Нужно ли вашим приложениям обновлять склад?Если это так, то вам нужно подумать о том, как это интегрируется с остальной частью процесса ETL.

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