Функциональная модель базы данных

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

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

Обзор

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

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

Функциональная модель основана на многомерных массивах или « кубах » ячеек, которые, как и в электронной таблице, могут быть либо введены извне, либо рассчитаны на основе других ячеек. Такие кубы строятся с использованием измерений, которые соответствуют иерархически организованным наборам реальных объектов, таких как продукты, географические регионы, время и т. д. Куб можно рассматривать как функцию декартова произведения измерений. Т.е. он присваивает значение каждой ячейке, которая идентифицируется кортежем из n элементов измерения; отсюда и название «функциональный». Модель сохраняет гибкость и потенциал интерактивности электронных таблиц, а также многомерную иерархическую консолидацию реляционных инструментов OLAP. В то же время функциональная модель преодолевает ограничения как модели реляционной базы данных, так и классических электронных таблиц.

Продукты, в той или иной степени реализующие принципы функциональной модели, существуют уже некоторое время, включая такие продукты, как Essbase , TM1 , Jedox , Alea, Microsoft Analysis Services и др.

Аналитический контекст

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

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

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

Применение ИТ к древовидным компонентам контура управления со временем развивалось по мере разработки новых технологий. Запись операционных операций была одной из первых задач, которую необходимо было автоматизировать за счет использования перфокарт на 80 столбцов. По мере развития электроники записи переносились сначала на магнитную ленту, а затем на диск. Технологии программного обеспечения также развивались и привели к появлению систем управления базами данных, которые централизовали доступ к данным и контроль над ними.

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

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

Электронные таблицы и функциональная модель

Электронные таблицы имеют ключевой набор характеристик, которые облегчают моделирование и анализ. Данные из нескольких источников можно объединить на одном листе. Ячейки можно определять с помощью формул расчета на основе других ячеек, поэтому факты из разных источников можно логически связывать для расчета производных значений. Вычисляемые ячейки обновляются автоматически при каждом изменении любой из входных ячеек, от которых они зависят. Когда у пользователей возникает вопрос «что если», они просто меняют некоторые ячейки данных, и все зависимые ячейки автоматически обновляются. Кроме того, ячейки организованы в прямоугольные сетки и расположены рядом друг с другом, чтобы существенные различия можно было заметить с первого взгляда или с помощью связанных графических отображений. Сетки электронных таблиц обычно также содержат расчеты консолидации по строкам и/или столбцам. Это позволяет обнаруживать тенденции в совокупности, которые могут быть неочевидны на детальном уровне.

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

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

Компоненты функциональной модели

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

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

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

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

Пример

Пример кубов, связанных между собой формулами

Кубики и их размеры (в скобках) следующие:

• Прибыль и убыток — прибыли и убытки (регион, счет, валюта, время)
• Продажи - Продажи(Регион, Продукт, Время)
• Расчет заработной платы - Расчет заработной платы (Регион, Сотрудник, Время)
• Накладные расходы - Ovhd(Счет, Время)
• Валюта - Fx(Валюта, Время)

Кубы в модели связаны между собой формулами:

Куб P&L получает долларовые затраты из куба заработной платы по формуле вида: P&L( "Заработная плата", "Долларов") = Расчет заработной платы ("Все сотрудники")

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

P&L( xRegion, «Заработная плата», «Доллары», xTime) = Расчет заработной платы (xRegion, «Все сотрудники», xTime) , для всех выходов из xRegion в регионе и всех выходов из xTime во времени.

Аналогичным образом, P&L также получает доход от продаж из куба Sales через:

Прибыль и убыток( "Продажи", "Доллары") = Продажи("Все продукты")

Счета накладных расходов распределяются по регионам исходя из объема продаж:

P&L("Регион", "Долларов") = Ovhd() * Продажи("Регион") / Продажи("Все регионы")

Наконец, другие валюты рассчитываются на основе курса доллара:

P&L() = P&L("Доллары") * Fx()

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

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

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

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

Функциональные базы данных и перспективная аналитика

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

Функциональная база данных, такая как электронные таблицы, также позволяет пользователям изменять входные значения, пока все зависимые значения актуальны. Это облегчает экспериментирование «что, если», а также создание и сравнение нескольких сценариев. Затем пользователи смогут просмотреть сценарии рядом и выбрать наиболее подходящий. При планировании пользователи могут прийти к наиболее выгодному варианту действий, неоднократно перерабатывая и взаимодействуя с результатами. Полезные идеи возникают в результате тесного взаимодействия с данными, которое пользователи обычно делают с электронными таблицами.

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

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

Дальнейшее чтение

• «Основная теория множеств». Стэнфордская энциклопедия философии. http://plato.stanford.edu/entries/set-theory/primer.html
• Берд Р.С., Вадлер П.Л. Введение в функциональное программирование. Прентис Холл (1988).
• Бунеман П., Функциональные языки баз данных и функциональная модель данных. Документ с изложением позиции семинара FDM (июнь 1997 г.) http://www.cis.upenn.edu/~peter/fdm-position.html .
• Кодд, Э. Ф. Реляционная модель данных для больших общих банков данных. Комм. ACM 13, 6 (июнь 1970 г.)
• Хендерсон П. Применение и реализация функционального программирования. Прентис Холл (1980).
• Хрбачек К. и Джех Т. Введение в теорию множеств, третье издание, Marcel Dekker, Inc., Нью-Йорк, 1999.
• Ланг, Серж (1987), Линейная алгебра, Берлин, Нью-Йорк: Springer-Verlag, ISBN   978-0-387-96412-6
• CM Necco, JN Oliveira, L. Quintas. Функциональный подход к онлайн-аналитической обработке, 2006. WISBD, III семинар по разработке программного обеспечения и баз данных. CACIC'06, XII Аргентинский конгресс компьютерных наук, Национальный университет Сан-Луиса, Аргентина.
• Э. Ф. Кодд. Предоставление 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-е изд., Аддисон Уэсли, США, 1997 г., ISBN   978-0-201-96426-4
• Ральф Кимбалл и Марджи Росс, Набор инструментов для хранилищ данных: Полное руководство по многомерному моделированию (второе издание), стр. 393
• Карстен Олер Йохен Грюнес Кристофер Илаква, IBM Cognos TM1. Официальное руководство, McGraw Hill, 2012 г.
• Полная история TM1, Мэнни Перес, https://www.cubewise.com/about-cubewise/company/story-of-ibm-pa-tm1/
• За пределами электронной таблицы: история TM1. 2020. [фильм] Режиссер А. Вале да Консейсан. Сидней, Австралия. https://tm1.film
• Мэнни Перес; полное интервью Flatrock. 2020 [фильм] https://www.youtube.com/watch?v=yO_LUhkwIF4&list=PLCb8b-2N8MebWgyBhXdMDTmkH5Mx-ZMAs