В предыдущей статье этой серии была демонтирована система хранилища бизнес-данных электронной коммерции, а также демонтирован и стратифицирован весь бизнес с помощью концепции стратификации хранилища данных. В этой главе будет использована концепция хранилища данных из предыдущей статьи для сегментирования бизнеса электронной коммерции. , специально для создания хранилища данных для бизнеса электронной коммерции, мы построим относительно полное хранилище данных в соответствии с признанными в отрасли стандартными процессами.
В этой серии статей будет рассмотрено большое количество кода SQL, кода анализа и обработки данных, а также использование вспомогательных продуктов для промежуточного хранения данных и хранилищ данных. Если еще нет относительно зрелого изучения продуктов, рекомендуется использовать зрелые продукты Alibaba DataWorks. и Макскомпьют.
Прежде чем строить хранилище данных, сначала необходимо определить цели и требования к построению хранилища данных и провести комплексное исследование бизнеса. Вам необходимо понять, каковы реальные потребности бизнеса, и определить, какие проблемы может решить вся бизнес-система.
Адекватные бизнес-исследования и анализ спроса являются краеугольными камнями построения хранилища данных и напрямую определяют, может ли хранилище данных быть успешно построено. Пользователей можно разделить на отделы анализа данных, эксплуатации и обслуживания. У каждого отдела свои потребности в хранилище данных. Нам необходимо провести отдельные исследования в разных отделах, чтобы разобраться в общей структуре бизнес-данных. Мы по-прежнему берем тендерный бизнес в качестве примера для анализа и рисуем блок-схему тендерного бизнеса посредством интервью и наблюдений. Включая объявление о торгах, прием заявок, оценку заявок, определение ставок, подписание контракта и другие основные ссылки:
ключевые шаги:
Определить потребности в данных:
поля данных:
Определить источники данных:
сбор данных:
Определить ключевые показатели эффективности:
Общие ключевые показатели эффективности:
Хранилища данных, построенные исключительно на основе бизнес-исследований, плохо удобны в использовании. После завершения бизнес-исследования необходимо дополнительно собрать потребности пользователей данных, а затем провести углубленное размышление и анализ потребностей.
Существует два способа проведения анализа потребностей:
Напишите документ с требованиями:
Содержание документа:
Например, требованиями к тендерному бизнесу могут быть:
Тендерный бизнес | поставщик | Тендерный проект | Информация о ставках | Управление закупками |
---|---|---|---|---|
потребности бизнеса | Оценка рынка и анализ возможностей поставщиков. | Анализ эффективности бренда тендерных проектов | Управление уровнями поставщиков и финансовыми расчетами | Мониторинг и оптимизация тендерных процессов |
основные данные | Информация о поставщиках, анализ поставщиков (отрасль, квалификация, рейтинги) | Бюджет проекта, время выпуска, дедлайн | Сумма предложения, время торгов, результаты оценки предложений | Сумма контракта, время подписания |
источник данных | информационная система поставщика | Система управления закупками | система управления проектами | финансовая система |
Сценарии применения данных | Анализируйте квалификацию поставщиков, исторические показатели и показатели успешных торгов. Оцените возможности поставок и потенциал партнерства поставщиков. | Анализируйте эффективность бренда и реакцию рынка на тендерные проекты. Контролировать ход тендерных проектов и исполнение бюджета. | Обеспечьте иерархическое управление поставщиками, классифицируя их на основе исторических показателей и рейтингов. Управляйте финансовыми расчетами с поставщиками и отслеживайте исполнение контрактов. | Мониторинг ключевых аспектов тендерного процесса для выявления узких мест и возможностей улучшения. Повысить прозрачность и справедливость процесса оценки заявок и оптимизировать стандарты и процессы оценки заявок. |
Бизнес-процесс может представлять собой отдельное бизнес-событие, например, оплата транзакции, возврат средств и т. д., он также может быть статусом определенного события, например, баланса текущего счета, или это может быть бизнес-процесс, состоящий из серии; сопутствующие деловые мероприятия. Это зависит от того, анализируете ли вы прошлые события, текущий статус или эффективность потока событий.
Построение диаграммы бизнес-процессов помогает четко понять конкретные шаги и поток данных каждого звена, включая все этапы тендерного проекта, от публикации объявления о торгах до подписания контракта и реализации проекта.
После уточнения бизнес-процесса пользователя предметную область можно разделить по бизнесу, требующему анализа и принятия решений.
Обычно вам необходимо прочитать проектную документацию, словарь данных и проектную документацию модели данных каждой исходной системы, а также изучить полученную обратно физическую модель данных. Кроме того, можно выполнить объединение предметных доменов между источниками для сортировки доменов данных всего предприятия по источникам.
Под предметной областью данных понимается коллекция, которая абстрагирует бизнес-процессы или измерения для бизнес-анализа. Чтобы обеспечить жизнеспособность всей системы, предметную область данных необходимо абстрагировать, уточнять, поддерживать и обновлять в течение длительного времени. При разделении домена данных оно может не только охватить все текущие потребности бизнеса, но также позволить включать новые услуги в существующий домен данных или расширять новые домены данных при их появлении. Разделение предметных областей может быть осуществлено после бизнес-исследований, при этом необходимо проанализировать бизнес-деятельность в каждом бизнес-модуле.
Разделите хранилище данных на различные домены данных на основе бизнес-функций и ключевых объектов данных. Каждая область данных может содержать несколько связанных таблиц данных с тесными деловыми связями между этими таблицами.
Как упоминалось выше, для каждой области данных необходимо разработать подробную модель данных, включая таблицы фактов и таблицы измерений.
Поле данных управления тендерами:
Определите взаимосвязь между каждой областью данных и спроектируйте соответствующие ограничения внешнего ключа. Это помогает обеспечить согласованность и целостность данных. Например, таблицу ставок (Bid) в поле данных «Управление ставками» необходимо связать с таблицей проекта торгов (Project) в поле данных «Управление ставками»:
CREATE TABLE bid(
bid_id INT PRIMARY KEY,
project_ID INT,
supplier_ID INT,
bid_amount DECIMAL(10,2),
bid_data DATE,
FOREING KEY (project_ID) REFERENCES Project(project_ID),
FOREING KEY (supplier_ID) REFERENCES Supplier(supplier_ID)
);
Определение измерений и построение матрицы шины — очень важные этапы проектирования хранилища данных, особенно для обеспечения согласованности и унификации в нескольких доменах данных.
Измерения — это информация, которая описывает контекст бизнес-процессов и помогает нам понимать и анализировать фактические данные. Мы можем сначала построить общие измерения, а затем построить измерения с подробным определением.
Во-первых, определите общие измерения во всех предметных областях, которые будут повторно использоваться в разных предметных областях. Например, в тендерном бизнесе возможные общие параметры включают в себя:
Определите подробные атрибуты для каждого измерения и создайте соответствующую таблицу измерений. Например, мы можем спроектировать таблицу измерений времени как:
Таблица измерения времени (Dim_Time):
CREATE TABLE Dim_Time(
Time_ID INT PRIMARY KEY,
Year INT,
Quarter INT,
Month INT,
Day INT,
Weekday VARCHAR(10)
)
Размерность проекта (Dim_Project):
CREATE TABLE Dim_Project(
Project_ID INT PRIMARY KEY,
Project_Name VARCHAR(100),
Budget DECIMAL(10,2),
Start_Date DATE,
End_Date DATE
);
Матрица шины — это двумерная таблица, в которой перечислены все таблицы фактов и таблицы общих измерений в хранилище данных. Это помогает обеспечить согласованность и единообразие в различных областях данных и бизнес-процессах.
Сначала перечислите все поля данных в таблице фактов. В тендерном бизнесе возможные таблицы фактов включают в себя:
Перечислите измерения, общие для всех полей данных, например:
Создайте таблицу, которая сопоставит таблицу фактов с таблицей измерений. Пример матрицы шины следующий:
таблица фактов/измерение | Dim_Time | Dim_Project | Dim_Supplier | Dim_Location | Dim_Expert |
---|---|---|---|---|---|
Fact_Bid | Yes | Yes | Yes | No | No |
Fact_Evaluation | Yes | No | No | No | Yes |
Fact_Contract | Yes | Yes | Yes | No | No |
Fact_Project_Progress | Yes | Yes | No | Yes | No |
Fact_Settlement | Yes | Yes | Yes | No | No |
Пример таблицы фактов ставок (Fact_Bid):
CREATE TABLE Fact_Bid (
Bid_ID INT PRIMARY KEY,
Project_ID INT,
Supplier_ID INT,
Bid_Amount DECIMAL(10, 2),
Bid_Date INT,
Evaluation_Result VARCHAR(50),
FOREIGN KEY (Project_ID) REFERENCES Dim_Project(Project_ID),
FOREIGN KEY (Supplier_ID) REFERENCES Dim_Supplier(Supplier_ID),
FOREIGN KEY (Bid_Date) REFERENCES Dim_Time(Time_ID)
);
Таблица фактов оценки ставок (Fact_Evaluation):
CREATE TABLE Fact_Evaluation (
Evaluation_ID INT PRIMARY KEY,
Bid_ID INT,
Expert_ID INT,
Score DECIMAL(5, 2),
Evaluation_Date INT,
FOREIGN KEY (Bid_ID) REFERENCES Fact_Bid(Bid_ID),
FOREIGN KEY (Expert_ID) REFERENCES Dim_Expert(Expert_ID),
FOREIGN KEY (Evaluation_Date) REFERENCES Dim_Time(Time_ID)
);
Атомарные индикаторы имеют четкий статистический калибр и логику расчета: Атомный показатель = бизнес-процесс + измерение
。Производные показатели – это общие статистические показатели.:Производный индикатор = период времени + модификатор + атомарный индикатор
。Атомарные индикаторы можно создавать только после определения бизнес-процесса.。Создание производных показателей обычно необходимо осуществлять после понимания конкретных требований к отчетности.,Прежде чем создавать производный индикатор, необходимо создать атомарный индикатор. Следует отметить следующее:
На основе предыдущего анализа мы подтвердили, что бизнес-процесс: подтверждение поступления (успешная сделка), а измерение – сумма реализации товара. Таким образом, в соответствии с потребностями бизнеса мы можем определить атомарный показатель: сумму успешной транзакции с товаром.
Производными показателями являются:
Отсортируйте общий объем продаж каждого продукта в категории кухонных принадлежностей в провинции в порядке убывания за последний день, а затем выберите 10 наименований, которые наиболее продаются, чтобы получить 10 наименований продуктов с наибольшими продажами в этой категории. Затем в следующей главе мы начнем комбинировать инструменты моделирования данных для детального проектирования следующей подробной модели и, в частности, использовать интуитивно понятные инструменты моделирования данных для построения DWD, DIM и DWS.