Руководство по экономичному интеллектуальному анализу данных

В отличие от традиционного программирования приложений, где функции API меняются каждый день, программирование баз данных в основном остается прежним. Первая версия Microsoft Visual Studio .NET была выпущена в феврале 2002 г., а новая версия выпускается примерно каждые два года, не считая выпусков пакетов обновлений. Этот быстрый темп изменений вынуждает ИТ-персонал оценивать приложения своей корпорации каждые пару лет, оставляя функциональные возможности своих приложений нетронутыми, но с совершенно другим исходным кодом, чтобы оставаться в курсе новейших методов и технологий.

Этого нельзя сказать об исходном коде вашей базы данных. Стандартный запрос SELECT / FROM / WHERE / GROUP BY , написанный еще на заре SQL, работает и сегодня. Конечно, это не означает, что в программировании реляционных баз данных не было никаких достижений; были, и они были более логичными, чем техническими .

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

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

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

База данных транзакций

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

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

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

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

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

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

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

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

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

ETL (извлечение, преобразование, загрузка) и отчетность

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

Самый простой способ определить потребность бизнеса в процессах ETL или автоматической отчетности — выяснить, кто считывает данные из базы данных транзакций, а затем манипулирует данными с помощью электронной таблицы. Электронная таблица имеет ту же структуру, что и таблица базы данных. Оба содержат строки и столбцы. Если у вас есть конечные пользователи, которые манипулируют данными самостоятельно, вы должны спросить себя: «Почему этот процесс нельзя автоматизировать?»

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

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

Хорошо построенная система ETL также должна обеспечивать возможность возврата всех данных, загруженных в базу данных транзакций, обратно в исходный исходный файл. Это важная часть архитектуры базы данных. Если вы не знаете точную дату/время добавления каждой записи, а также имя источника (имя пользователя или имя файла), который добавил записи, то вы не готовы обрабатывать неверные данные, загруженные в вашу базу данных транзакций. Вы должны спросить себя: «Что, если кто-то пришлет нам плохой файл?» Сколько времени вам понадобится, чтобы идентифицировать записи, которые оттуда пришли?

Хранилище данных

Существует две теории проектирования хранилища данных. Разницу между теориями Инмона и Кимбалла можно резюмировать следующим образом:

Теория Инмона заключается в том, чтобы сначала разработать хранилище данных, а затем построить многомерные витрины данных для создания отчетов из хранилища данных. Теория Кимбалла заключается в том, чтобы сначала разработать многомерные витрины данных для отчетности, а затем объединить их вместе для создания хранилища данных.

Вы всегда хотите обеспечить клиентам максимально быструю окупаемость инвестиций. Создание витрин данных — простой процесс. Вы начинаете с того, что берете запросы, лежащие в основе ваших отчетов, и меняете их с возврата наборов результатов на сохранение наборов результатов в постоянных таблицах. Вы просто добавляете TRUNCATE TABLE tablename ; INSERT INTO имя таблицы перед исходным ключевым словом SELECT . Когда у вас есть несколько функциональных таблиц киосков данных, определение возможностей для объединения киосков данных должно встать на свои места; найдите запросы отчетов, которые используют тот же список таблиц, а затем объедините список полей. Это требует более сложного запроса, особенно когда список таблиц увеличивается. Однако пока вы тщательно тестируете запрос, каждое постепенное изменение может быть выполнено без нарушения обычных бизнес-процессов.

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

OLAP-куб

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

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

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

Как упоминалось ранее, создание куба OLAP может быть сложной задачей. Рекомендуется рассмотреть возможность использования гибридного куба OLAP. PowerPivot Microsoft Excel предоставляет простые в использовании инструменты интеллектуального анализа данных без сложности полноценного куба OLAP. Главный недостаток гибрида в том, что у него разное время отклика. Однако большим преимуществом является то, что с помощью Excel проще создавать отчеты интеллектуального анализа данных, чем с помощью MDX. При интеллектуальном анализе данных есть три полезных отчета. Мы можем посмотреть на некоторые примеры из реального мира и понять, как их интерпретировать.

Все эти отчеты взяты из автоматизированного приложения для дневной торговли, созданного автором.

Визуальная отчетность

Отчет о точечной диаграмме

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

Отчет «Коробка и усы»

В этом отчете суммируются значения x и y из отчета о точечной диаграмме. Значения оси x дискретизируются в набор сегментов.

Концы каждого уса (линии) представляют выбросы. Желтые и светло-синие полосы представляют верхний и нижний диапазоны одного стандартного отклонения.

Модель линейной регрессии

В этом отчете показана корреляция между значениями по осям x и y, а также сглаживание линии, которое может быть представлено математической формулой. Значение R в квадрате включено, чтобы показать, насколько надежна корреляция.

Заключение

По мере роста вашей компании обычно будет расти и ваша база данных.

Большинству организаций изначально не нужен специалист по базам данных или специализированная компания по обработке данных, которая занимается их потребностями. Вместо этого их ИТ-персонал выполняет несколько обязанностей или, как говорится, «носит много шляп». Это работает до определенного момента, но в конечном итоге вам нужно привлекать специалистов.

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