Логическая оптимизация - Функционалы
Функционал (functional) — функция, обычно определённая на множестве функций со значениями обычно в вещественных числах.
Одним из важнейших шагов при проектировании базы данных является выбор функционалов (вычисленных функций от наборов данных), необходимых для эффективного анализа данных. Вы думаете, что набор функционалов нужен только для ускорения выборки данных? Конечно, нет! Кроме повышения эффективности анализа данных следует помнить о качестве анализа. Вспомним идеи OLAP - набора методик оперативного анализа данных в любой момент на любом уровне детализации. Одной из ошибок OLAP-подхода, погубившей все направление была неверная трактовка технологии. Одно только название "многомерный анализ данных" побудило сломать горы копий и создать множество нежизнеспособных информационных систем. А правильно было бы использовать термин "многоуровневый анализ". Знаете, что такое фрактальное изображение? Это изображение, которое повторяет себя на разных уровнях детализации. Например, если посмотреть на береговую линию побережья и небольшой его участок участок они окажутся подобны. В то же время размер (мера) сравниваемых элементов совершенно разный! И хотя мы точно знаем, что сравниваем (очень простой пример), никакой многомерности в помине нет, хотя ясно видна взаимосвязь. В реальности же для сложных данных назвать меру измерения в произвольном случае невозможно, можно лишь определить уровни детализации, интересующие нас. А классический подход к OLAP-технике побуждал строить универсальные системы и потом пытаться "пропихнуть" в них реальные данные. Как водится, практики пренебрегли теорией и вышло то, что и следовало ожидать. Чтобы избежать названной ошибки, следует заранее определить уровни анализа наборов данных и построить наборы функционалов для каждого уровня. Такой подход гарантирует возможность многоуровневого анализа в реальном времени.
Под термином "мера" мы понимаем некоторую измеримую (measuring) величину (в данном случае вещественное число). Ключевое слово "измеримая", это нам потребуется для сравнения мер между собой. Например, Если Иванов выполнил работу "неплохо", а Петров "так себе" мы никакого анализа не проведем. Разве что выгоним обоих и аналитика заодно. А вот если Иванов набрал 8 баллов, а Петров 5, все становится понятно и легко анализируется автоматически. Притом понятие балл может включать в себя все, что угодно, главное, что количество баллов измеримо. Таким образом, следует определить набор функционалов и в работающей системе анализ сведется к прямому сравнению количественных показателей, что не представляет принципиальной сложности. Прикладные программисты и пользователи могут даже представления не иметь о применяемых критериях оценки, зато архитектор ИС данных должен отлично себе их представлять. Да, проектировщик БД должен быть экспертом в предметной области, а не только в программировании и администрировании PostgreSQL (или Oracle, MySQL, MSSQL, ...). А Вы кому хотели бы свои данные доверить? Что бы Вы сказали, если хирург будет классным специалистом по использованию скальпеля, но понятия не имеет об анатомии человека и болезням? Глупый пример, не правда ли - а вот ситуация, когда проектировщик корпоративной информационной системы специалист лишь в программировании и понятия не имеет об особенностях бизнеса, встречается сплошь и рядом.
Итак, суммируя вышеизложенное, приходим к выводу, что нам нужно определить набор функций, которые потребуются для каждого уровня детализации анализа. Желательно еще и полный набор, чтобы весь анализ мог проводиться исключительно по построенным функционалам. Если при этом удастся обеспечить выполнение анализа на определенном уровне детализации только по функционалам соответствующего уровня, то получится сделать и real-time анализ.
Одним из важнейших шагов при проектировании базы данных является выбор функционалов (вычисленных функций от наборов данных), необходимых для эффективного анализа данных. Вы думаете, что набор функционалов нужен только для ускорения выборки данных? Конечно, нет! Кроме повышения эффективности анализа данных следует помнить о качестве анализа. Вспомним идеи OLAP - набора методик оперативного анализа данных в любой момент на любом уровне детализации. Одной из ошибок OLAP-подхода, погубившей все направление была неверная трактовка технологии. Одно только название "многомерный анализ данных" побудило сломать горы копий и создать множество нежизнеспособных информационных систем. А правильно было бы использовать термин "многоуровневый анализ". Знаете, что такое фрактальное изображение? Это изображение, которое повторяет себя на разных уровнях детализации. Например, если посмотреть на береговую линию побережья и небольшой его участок участок они окажутся подобны. В то же время размер (мера) сравниваемых элементов совершенно разный! И хотя мы точно знаем, что сравниваем (очень простой пример), никакой многомерности в помине нет, хотя ясно видна взаимосвязь. В реальности же для сложных данных назвать меру измерения в произвольном случае невозможно, можно лишь определить уровни детализации, интересующие нас. А классический подход к OLAP-технике побуждал строить универсальные системы и потом пытаться "пропихнуть" в них реальные данные. Как водится, практики пренебрегли теорией и вышло то, что и следовало ожидать. Чтобы избежать названной ошибки, следует заранее определить уровни анализа наборов данных и построить наборы функционалов для каждого уровня. Такой подход гарантирует возможность многоуровневого анализа в реальном времени.
Под термином "мера" мы понимаем некоторую измеримую (measuring) величину (в данном случае вещественное число). Ключевое слово "измеримая", это нам потребуется для сравнения мер между собой. Например, Если Иванов выполнил работу "неплохо", а Петров "так себе" мы никакого анализа не проведем. Разве что выгоним обоих и аналитика заодно. А вот если Иванов набрал 8 баллов, а Петров 5, все становится понятно и легко анализируется автоматически. Притом понятие балл может включать в себя все, что угодно, главное, что количество баллов измеримо. Таким образом, следует определить набор функционалов и в работающей системе анализ сведется к прямому сравнению количественных показателей, что не представляет принципиальной сложности. Прикладные программисты и пользователи могут даже представления не иметь о применяемых критериях оценки, зато архитектор ИС данных должен отлично себе их представлять. Да, проектировщик БД должен быть экспертом в предметной области, а не только в программировании и администрировании PostgreSQL (или Oracle, MySQL, MSSQL, ...). А Вы кому хотели бы свои данные доверить? Что бы Вы сказали, если хирург будет классным специалистом по использованию скальпеля, но понятия не имеет об анатомии человека и болезням? Глупый пример, не правда ли - а вот ситуация, когда проектировщик корпоративной информационной системы специалист лишь в программировании и понятия не имеет об особенностях бизнеса, встречается сплошь и рядом.
Итак, суммируя вышеизложенное, приходим к выводу, что нам нужно определить набор функций, которые потребуются для каждого уровня детализации анализа. Желательно еще и полный набор, чтобы весь анализ мог проводиться исключительно по построенным функционалам. Если при этом удастся обеспечить выполнение анализа на определенном уровне детализации только по функционалам соответствующего уровня, то получится сделать и real-time анализ.
Comments