Функциональная модель базы данных используются для поддержки аналитических приложений , таких как финансовое планирование и управление производительностью . Функциональная модель базы данных, или для краткости функциональная модель, отличается от реляционной модели, но дополняет ее . Функциональная модель также отличается от других концепций с аналогичным названием, включая модель функциональной базы данных DAPLEX [1] и базы данных на функциональном языке.
Функциональная модель является частью категории онлайн-аналитической обработки (OLAP), поскольку она включает многомерную иерархическую консолидацию. Но он выходит за рамки OLAP, требуя ориентации ячеек, как в электронной таблице , где ячейки могут вводиться или вычисляться как функции других ячеек. Также, как и в электронных таблицах, он поддерживает интерактивные вычисления, при которых значения всех зависимых ячеек автоматически обновляются при каждом изменении значения ячейки.
Обзор
Аналитика, особенно ориентированная на будущее или перспективная аналитика, требует интерактивного моделирования, «что, если» и экспериментов, подобных тем, которые большинство бизнес-аналитиков проводят с электронными таблицами. Это взаимодействие с данными обеспечивается ориентацией ячеек электронной таблицы и ее способностью позволять пользователям определять ячейки, рассчитываемые как функцию других ячеек.
Модель реляционной базы данных не имеет таких концепций и, таким образом, очень ограничена в моделировании эффективности бизнеса и интерактивности, которую она может поддерживать. Соответственно, реляционная аналитика почти исключительно ограничена историческими данными, которые являются статическими. При этом упускается большая часть стратегических преимуществ аналитики, связанных с интерактивным построением взглядов на будущее.
Функциональная модель основана на многомерных массивах или « кубах » ячеек, которые, как в электронной таблице, могут вводиться извне или вычисляться с точки зрения других ячеек. Такие кубы строятся с использованием измерений, которые соответствуют иерархически организованным наборам реальных объектов, таких как продукты, география, время и т. Д. Куб можно рассматривать как функцию над декартовым произведением измерений. То есть, он присваивает значение каждой ячейке, которая идентифицируется кортежем из n элементов измерения; отсюда и название «функциональный». Модель сохраняет гибкость и потенциал для интерактивности электронных таблиц, а также многомерные иерархические консолидации реляционных инструментов OLAP. В то же время функциональная модель преодолевает ограничения как модели реляционной базы данных, так и классических электронных таблиц.
Продукты, которые реализуют принципы функциональной модели в той или иной степени, существуют уже некоторое время, включая такие продукты, как Essbase , TM1 , Alea, Microsoft Analysis Services и т. Д. [2] [3] [4] [5] [6 ]
Контекст аналитики
Система управления предприятием обычно состоит из ряда взаимосвязанных контуров управления. Каждый цикл начинается с разработки плана, затем план выполняется, а результаты проверяются и сравниваются с планом. На основе этих результатов и новой оценки того, что ждет в будущем, разрабатывается новый план, и процесс повторяется. Три компонента цикла управления - планирование, выполнение и оценка - имеют разные временные перспективы. Планирование смотрит в будущее, исполнение смотрит в настоящее, а обзор смотрит в прошлое.
Информационные технологии (ИТ) сейчас играют центральную роль в повышении эффективности и действенности контуров управленческого контроля. Операционные компьютерные системы связаны с исполнением, в то время как аналитические компьютерные системы или просто аналитика используются для улучшения планирования и оценки. Информационные потребности каждого компонента различны. Операционные системы обычно связаны с записью транзакций и отслеживанием текущего состояния бизнеса - запасов, незавершенного производства и т. Д. Аналитика состоит из двух основных компонентов: прогнозная или перспективная аналитика, которая применяется к планированию, и ретроспективная аналитика. , что относится к оценке.
В ретроспективной аналитике транзакции, возникающие в результате операций, сводятся и накапливаются в массивы ячеек. Эти ячейки идентифицируются по многим параметрам, имеющим отношение к бизнесу: время, продукт, клиент, счет, регион и т. Д. Ячейки обычно группируются в кубы, которые формируют основу для ретроспективного анализа, такого как сравнение фактической производительности с планом. Это основная сфера систем OLAP. Перспективная аналитика создает аналогичные кубы данных, но для будущих периодов времени. Разработка предполагаемых данных обычно является результатом человеческого ввода или математических моделей, которые управляются и контролируются посредством взаимодействия с пользователем.
Применение ИТ к древовидным компонентам контура управления и контроля со временем развивалось по мере развития новых технологий. Запись операционных транзакций была одной из первых, которую нужно было автоматизировать за счет использования перфокарт на 80 столбцов. По мере развития электроники записи перемещались сначала на магнитную ленту, а затем на диск. Программные технологии также прогрессировали и привели к появлению систем управления базами данных, которые централизовали доступ к данным и контроль над ними.
Базы данных позволили разработать языки, которые упростили создание отчетов для ретроспективной аналитики. Примерно в то же время были разработаны языки и системы для обработки многомерных данных и автоматизации математических методов прогнозирования и оптимизации в рамках перспективной аналитики. К сожалению, эта технология требовала высокого уровня знаний и была непонятна большинству конечных пользователей. Таким образом, его признание пользователями было ограниченным, равно как и выгоды, полученные от него.
До появления электронной таблицы не было широко используемых инструментов для перспективной аналитики. Впервые у конечных пользователей появился инструмент, который они могли понять и контролировать, а также использовать его для моделирования своего бизнеса в том виде, в котором они его понимали. Они могли взаимодействовать, экспериментировать, приспосабливаться к меняющимся ситуациям и очень быстро получать идеи и ценить. В результате электронные таблицы получили широкое распространение и в конечном итоге стали повсеместными. По сей день электронные таблицы остаются незаменимым инструментом для всех, кто занимается планированием.
Таблицы и функциональная модель
Электронные таблицы имеют ключевой набор характеристик, облегчающих моделирование и анализ. Данные из нескольких источников можно собрать на одном листе. Ячейки могут быть определены с помощью формул расчета в терминах других ячеек, поэтому факты из разных источников могут быть логически связаны между собой для вычисления производных значений. Вычисляемые ячейки обновляются автоматически при изменении любой из входных ячеек, от которых они зависят. Когда у пользователей возникает вопрос «что, если», они просто меняют некоторые ячейки данных, и автоматически обновляются все зависимые ячейки. Кроме того, ячейки организованы в прямоугольную сетку и сопоставлены друг с другом, так что существенные различия могут быть обнаружены с первого взгляда или с помощью связанных графических дисплеев. Сетки электронных таблиц обычно также содержат вычисления консолидации по строкам и / или столбцам. Это позволяет выявлять тенденции в совокупности, которые могут быть не очевидны на детальном уровне.
Но электронные таблицы страдают рядом недостатков . Ячейки идентифицируются по положению строки и столбца, а не по бизнес-концепциям, которые они представляют. Таблицы являются двухмерными, а несколько страниц создают подобие трех измерений, но бизнес-данные часто имеют больше измерений. Если пользователи хотят выполнить другой анализ того же набора данных, данные необходимо продублировать. Иногда можно использовать ссылки на электронные таблицы, но чаще всего это непрактично. Совокупный эффект этих ограничений состоит в том, что существует предел сложности электронных таблиц, которые можно создавать и которыми можно управлять. Функциональная модель сохраняет ключевые особенности электронной таблицы, но также преодолевает ее основные ограничения. В функциональной модели данные располагаются в виде сетки ячеек, но ячейки идентифицируются по бизнес-концепции, а не просто по строке или столбцу. Объектами функциональной модели являются не рабочие листы, а размеры и кубы. Вместо двух или трех измерений: строки, столбца и листа функциональная модель поддерживает столько измерений, сколько необходимо.
Еще одним преимуществом функциональной модели является то, что это база данных с такими функциями, как независимость данных, одновременный многопользовательский доступ, целостность, масштабируемость, безопасность, контрольный журнал, резервное копирование / восстановление и интеграция данных. Независимость данных особенно важна для аналитики. Данные больше не должны храниться в таблицах. Вместо этого функциональная база данных действует как центральный информационный ресурс. Электронная таблица действует как пользовательский интерфейс для базы данных, поэтому одни и те же данные могут использоваться несколькими таблицами и несколькими пользователями. Обновления, отправленные несколькими пользователями, доступны всем пользователям в соответствии с правилами безопасности. Соответственно, всегда существует единственная согласованная совместно используемая версия данных.
Компоненты функциональной модели
Функциональная база данных состоит из набора измерений, которые используются для построения набора кубов. Измерение - это конечный набор элементов или членов, которые идентифицируют бизнес-данные, например, периоды времени, продукты, области или регионы, позиции и т. Д. Кубы строятся с использованием любого количества измерений. Куб - это набор ячеек, каждая из которых идентифицируется набором элементов, по одному из каждого измерения куба. Каждая ячейка куба содержит значение. Куб фактически представляет собой функцию, которая присваивает значение каждому кортежу из n декартова произведения измерений.
Значение ячейки может быть присвоено извне (ввод) или результат вычисления, в котором используются другие ячейки в том же кубе или других кубах. Определение куба включает формулы, которые определяют вычисление таких ячеек. Ячейки также могут быть пустыми и считаться имеющими нулевое значение для целей консолидации.
Как и в случае с электронными таблицами, пользователям не нужно беспокоиться о выполнении пересчета. Когда значение ячейки запрашивается, возвращаемое значение является актуальным по отношению к значениям всех ячеек, которые участвуют в его вычислении, то есть ячеек, от которых оно зависит.
Измерения обычно содержат иерархии консолидации, в которых некоторые элементы определены как родительские элементы для других элементов, а родительский элемент интерпретируется как сумма своих дочерних элементов. Ячейки, которые идентифицируются консолидированным элементом в одном или нескольких измерениях, автоматически вычисляются функциональной моделью как суммы ячеек, имеющих дочерние элементы в этих измерениях. Когда запрашивается значение объединенной ячейки, возвращаемое значение всегда актуально по отношению к значениям всех объединяемых ячеек.
Пример
Кубики и их размеры (в скобках) следующие:
- Прибыль и убыток - прибыль и убыток (регион, счет, валюта, время)
- Продажи - Продажи (регион, продукт, время)
- Расчет заработной платы - Расчет заработной платы (регион, сотрудник, время)
- Накладные расходы - Ovhd (счет, время)
- Иностранная валюта - Fx (валюта, время)
Кубики в модели связаны между собой формулами:
Куб прибылей и убытков берет долларовые затраты из куба расчета заработной платы по формуле вида: P&L («Расчет заработной платы», «Доллары») = Расчет заработной платы («Все сотрудники»).
Примечание. Синтаксис выражения используется для иллюстрации и может не отражать синтаксис, используемый в формальной модели или в конкретных продуктах, реализующих функциональную модель. Предполагается, что размеры, которые не указаны в выражении, охватывают все конечные элементы этих измерений. Таким образом, это выражение эквивалентно:
P&L (xRegion, «Payroll», «Dollars», xTime) = Payroll (xRegion, «All Employees», xTime) , для всех покидает xRegion в регионе и все покидает xTime во времени.
Аналогичным образом, P&L также получает выручку от продаж из куба продаж за счет:
P&L («Продажи», «Доллары») = Продажи («Все продукты»)
Накладные расходы распределяются по регионам исходя из продаж:
Прибыль и убыток («Регион», «Доллары») = Ovhd () * Продажи («Регион») / Продажи («Все регионы»)
Наконец, другие валюты выводятся из обменного курса доллара:
P&L () = P&L («Доллары») * Fx ()
Историческая часть кубов также заполняется из хранилища данных. В этом упрощенном примере только что обсужденные вычисления могут выполняться в хранилище данных для исторической части кубов, но в целом функциональная модель поддерживает вычисление других функций, таких как отношения и проценты.
Хотя история статична, будущая часть обычно динамична и разрабатывается в интерактивном режиме бизнес-аналитиками из различных организаций и с разным опытом. Прогнозы продаж должны составлять специалисты из каждого региона. Они могут использовать модели и параметры прогнозирования, в которых учитываются их знания и опыт в этом регионе, или они могут просто вводить их через электронную таблицу. В каждом регионе можно использовать разные методы с разными допущениями. Прогноз заработной платы может быть разработан специалистами по персоналу в каждом регионе. Куб накладных расходов будет заполнен людьми из финансового отдела штаб-квартиры, как и прогнозы обменного курса. Прогнозы, разработанные региональными экспертами, сначала проверяются и повторно используются в регионе, а затем рассматриваются и повторно используются в штаб-квартире.
Модель можно расширить, включив в нее измерение «Версия», которое варьируется, например, в зависимости от различных сценариев экономического климата. С течением времени каждый цикл планирования может сохраняться в отдельной версии, и эти версии сравнивать с фактическими и друг с другом.
В любое время данные во всех кубах, с учетом ограничений безопасности, доступны всем заинтересованным сторонам. Пользователи могут динамически переносить фрагменты кубов в электронные таблицы для дальнейшего анализа, но с гарантией того, что данные будут такими же, как и другие пользователи.
Функциональные базы данных и перспективная аналитика
Функциональная база данных объединяет данные из нескольких разрозненных источников и связывает разрозненные наборы данных в согласованные расходные модели. Это также позволяет контролировать данные, разбросанные по нескольким таблицам. Это позволяет пользователям видеть сводную картину, которая объединяет несколько компонентов, например, чтобы автоматически преобразовать планирование рабочей силы в полную финансовую картину. Это дает им единую точку входа для разработки глобального понимания на основе различных источников.
Функциональная база данных, такая как электронные таблицы, также позволяет пользователям изменять входные значения, пока все зависимые значения обновлены. Это облегчает экспериментирование «что, если», а также создание и сравнение нескольких сценариев. Затем пользователи могут просматривать сценарии рядом и выбирать наиболее подходящий. При планировании пользователи могут прийти к наиболее выгодному курсу действий, неоднократно повторяя и взаимодействуя с результатами. Практические идеи приходят из этого тесного взаимодействия с данными, которое пользователи обычно делают с электронными таблицами.
Функциональная база данных не только предоставляет общее интерактивное хранилище данных. Он также объединяет модели, разработанные аналитиками со знанием конкретной области бизнеса, которые могут использоваться всеми пользователями. Чтобы облегчить это, функциональная база данных сохраняет возможность интерактивного моделирования электронной таблицы на основе ячеек. Это позволяет создавать модели, которые более точно отражают сложности деловой реальности.
Возможно, самый крупный вклад функциональной базы данных в аналитику - это содействие сотрудничеству. Это позволяет нескольким людям и организациям не только делиться единой версией правды, но и истиной, которая динамична и постоянно меняется. Его автоматические вычисления быстро объединяют и согласовывают входные данные из нескольких источников. Это способствует взаимодействию различных отделов, способствует множеству итераций мыслительных процессов и позволяет сближать и согласовывать различные точки зрения. Кроме того, поскольку каждая часть модели разрабатывается людьми, которые являются экспертами в своей конкретной области, она может использовать опыт и идеи, существующие в организации.
Рекомендации
- ^ Шипман Д.В. Функциональная модель данных и язык данных DAPLEX. Транзакции ACM в системах баз данных 6 (1), март 1981 г., стр. 140-173.
- ^ Джордж Споффорд, Сивакумар Харинат, Крис Уэбб, Дилан Хай Хуанг, Франческо Чиварди: MDX-решения: с помощью Microsoft SQL Server Analysis Services 2005 и Hyperion Essbase. Wiley, 2006, ISBN 0-471-74808-0
- ^ IBM Planning Analytics на базе TM1 https://www.ibm.com/products/planning-analytics.html
- ^ Jedox OLAP http://www.jedox.com/en/products/jedox-olap.html
- ^ Сервер Infor PM OLAP http://www.infor.com/content/brochures/infor-pm-olap.pdf/
- ^ Apliqo FPM https://apliqo.com/apliqo-fpm-suite/
дальнейшее чтение
- «Основная теория множеств». Стэнфордская энциклопедия философии. http://plato.stanford.edu/entries/set-theory/primer.html
- Берд Р.С., Вадлер П.Л. Введение в функциональное программирование. Прентис Холл (1988).
- Бунеман П. Функциональные языки баз данных и функциональная модель данных. Документ с изложением позиции для семинара FDM (июнь 1997 г.) http://www.cis.upenn.edu/~peter/fdm-position.html .
- Кодд, Э. Ф. Реляционная модель данных для больших общих банков данных. Comm. ACM 13, 6 (июнь 1970 г.)
- Хендерсон П. Применение и реализация функционального программирования. Прентис Холл (1980).
- Hrbacek, K и Jech, T. Введение в теорию множеств, третье издание, Marcel Dekker, Inc., Нью-Йорк, 1999.
- Ланг, Серж (1987), Линейная алгебра, Берлин, Нью-Йорк: Springer-Verlag, ISBN 978-0-387-96412-6
- CM Necco, JN Oliveira, L. Quintas. Функциональный подход для оперативной аналитической обработки, 2006. WISBD, III Workshop de I ngeniería de Software y Bases de Datos. CACIC'06, XII Argentino de Ciencias de la Computación, Национальный университет Сан-Луиса, Аргентина.
- EF Codd. Предоставление OLAP пользователям-аналитикам: ИТ-мандат, апрель 1993 г. Технический отчет, EF Codd and Associates.
- П. Триндер, функциональная база данных, докторская диссертация, Оксфордский университет, 1989.
- Г. Коллиат, Реляционные и многомерные системы баз данных Olap, SIGMOD Record, 25 (3), (1996)
- Т. Б. Педерсен, К. С. Йенсен, Технология многомерных баз данных, IEEE Computer 34 (12), 40-46, (2001)
- CJ Date с Хью Дарвеном: Руководство по стандарту SQL: руководство пользователя по стандартному языку баз данных SQL, 4-е изд., Addison Wesley, USA 1997, ISBN 978-0-201-96426-4
- Ральф Кимбалл и Марджи Росс, Инструментарий хранилища данных: полное руководство по пространственному моделированию (второе издание), стр. 393
- Карстен Олер, Йохен Грунес, Кристофер Илаква, официальное руководство IBM Cognos TM1, McGraw Hill 2012
- Полная история TM1, Мэнни Перес, https://cubewise.com/history/
- За пределами таблицы: история TM1. 2020. [фильм] Режиссер А. Вале да Консейсау. Сидней, Австралия. https://tm1.film