Разработка системы государственных данных

1. Обзор

1.1 Сценарии применения

При анализе корпоративных данных вы часто сталкиваетесь с этой проблемой:

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

Эти проблемы можно решить, создав "систему Public Data" для группировки данных.

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

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

Системы государственных данных можно реализовать, когда они построены:

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

1.2 Ожидаемые результаты

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

Ниже приведен пример корпоративной системы открытых данных BI:

1.3 Идеи для реализации

2. Правила построения иерархий Public Data

(1) В BI для укладки Public Data следует придерживаться принципа удобного управления распределением данных, повышения производительности системы, простоты обслуживания и обновления данных, чтобы после укладки Public Data минимизировать иерархические ассоциации, контролировать уровень обновлений, проще назначать разрешения на данные.

(2) Поскольку каждая компания работает в разных отраслях, количество структур хранилищ, BI может быть основано на типе бизнеса компании, системе, используя отдел, ответственный за Public Data, чтобы построить систему Public Data. Справочный пример:

3) В целом, администраторы должны следовать принципам подотчетности Public Data при управлении ими:

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

(4) Четыре элемента именования открытых данных: ① бизнес/система/отдел использования + ② иерархия открытых данных + ③ информация о данных + ④ лицо, ответственное за открытые данные. Правила именования могут быть скорректированы в соответствии с фактической ситуацией на предприятии, не обязательно в строгом соответствии с определением спецификации именования, например, в некоторых клиентских приложениях, как правило, упрощается именование, непосредственно опускаются некоторые префиксы. Справочный пример:

Правила именования открытых данных
файл (бумажный)		метр (измеряющий что-л.)
иерархическая структура	соглашение об именовании	иерархическая структура	соглашение об именовании
Папка с исходными данными	* Необходимо включить бизнес-атрибуты и атрибуты уровня таблицы * Примеры именования: OA_Raw_Data, Public_Raw_Data	исходные данные	* Необходимо включить бизнес-атрибуты & атрибуты иерархии таблиц & атрибуты использования отделов & атрибуты ответственных лиц & атрибуты имен таблиц * Пример именования: отдел кадров_ОА исходные данные_процесс узел отдел размерность таблица_Чжан Сань
Папка с основными данными	* Необходимо включить бизнес-атрибуты и атрибуты уровня таблицы * Примеры именования: OA_Raw_Data, Public_Raw_Data	Основные данные	* Необходимо включить бизнес-атрибуты & атрибуты иерархии таблиц & атрибуты использования отделов & атрибуты ответственных лиц & атрибуты имен таблиц * Пример именования: Отдел кадров_Основные данные_Процесс узла, отнимающий много времени, большая широкая таблица_Чжан Сань
Папки для анализа данных	* Необходимо включить атрибуты бизнеса/отдела и атрибуты уровня таблицы * Пример именования: OA_Analytical Data, Marketing Department_Analytical Data	Анализ данных	* Необходимо включить бизнес-атрибуты & атрибуты иерархии таблиц & атрибуты использования отделов & атрибуты ответственных лиц & атрибуты имен таблиц * Пример именования: HR_OA Analytics Data_Reimbursement Process Expense Summary_Zhang San

(5) Помимо разделения папок по различным организациям, системам и бизнес-тематикам, для облегчения последующего назначения различным пользователям различных прав на использование данных и других разрешений, можно создать "публичную" папку, которая может использоваться для хранения таблиц данных для общего пользования несколькими отделами BI-системы, а также для настройки таблиц данных для BI-разрешений, чтобы избежать путаницы в разрешениях. В то же время администраторы регулярно обращают внимание на ключевые данные, полученные в результате Self-service бизнес-пользователей, на основании чего качество предоставляемых таблиц Public Data постоянно оптимизируется на плановой основе.

6) Эталонный пример для разработки системы Public Data:

3. правила набора данных

3.1 Правила именования наборов данных

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

Обратитесь к соглашению об именовании:

• Sector_DataSet_Content_Adders
• Анализ показателей_Использование в бизнесе_Дополнения
• Таблица Гранулярность_Влияние на бизнес_Библиотека источников

3.2 Управление данными

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

Принципы строительства:

(1) исходные данные, как правило, из ODS слой таблицы, в BI, как не будет непосредственно использоваться как нижняя таблица существует, для несущественного уровня, в основном для поддержания масштабируемости, когда объем данных большой, вызовет определенное количество данных избыточность, может быть выбрана в соответствии с реальной ситуацией.

2) В качестве базовых данных обычно используются таблицы из слоя DM с определенным бизнес-смыслом и охватом.

• Добавьте правило: высокая связность - низкая связность.
• Убедитесь, что таблица содержит поля, которые имеют непосредственное отношение к основной теме таблицы.

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

3.3 Идеи для управления общественными данными

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

Супер-администратор, а также все субадминистраторы (пользователи, имеющие доступ к управлению Public Data) должны знать следующее:

(1) Стандартизация процессов вверх и вниз: загрузка и выгрузка данных в Public Data должна соответствовать определенным спецификациям процесса и записывать необходимую информацию.

(2) Система ответственности за обслуживание таблицы данных: каждая таблица данных должна иметь четкое ответственное лицо, ответственное лицо отвечает за интерпретацию данных, ответы на вопросы, проверку ошибок и последующее обслуживание.

3) Улучшить описания Public Data: для наборов Public Data простые, но хорошо проработанные описания облегчают их использование другими людьми.

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

5) Public Data в идеале могут быть использованы со следующих точек зрения:

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