Предисловие

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

Эта серия статей будет включать в себя большое количество кода SQL, кода анализа и обработки данных, а также использование вспомогательных продуктов для промежуточного хранения данных и хранилищ данных. Если еще нет относительно зрелого изучения продуктов, рекомендуется использовать зрелые продукты Alibaba DataWorks. и Макскомпьют.

Процесс построения хранилища данных

1. Бизнес-исследования

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

Адекватные бизнес-исследования и анализ спроса являются краеугольными камнями построения хранилища данных и напрямую определяют, может ли хранилище данных быть успешно построено. Пользователей можно разделить на отделы анализа данных, эксплуатации и обслуживания. У каждого отдела свои потребности в хранилище данных. Нам необходимо провести отдельные исследования в разных отделах, чтобы разобраться в общей структуре бизнес-данных. Мы по-прежнему берем тендерный бизнес в качестве примера для анализа и рисуем блок-схему тендерного бизнеса посредством интервью и наблюдений. Включая объявление о торгах, прием заявок, оценку заявок, определение ставок, подписание контракта и другие основные ссылки:

ключевые шаги：

• Публикация объявления о тендере: понимание каналов выпуска, содержания и частоты.
• Управление предложениями: документируйте процесс получения, классификации и управления предложениями.
• Процесс оценки заявок: узнайте больше о критериях, процессе и участниках оценки заявок.
• Решение о победе в тендере: запишите основу и процесс принятия решения о победе в тендере.
• Управление контрактами: понимание процесса подписания контрактов и управления ими.

Данные требуют исследования

Определить потребности в данных：

• Определите ключевые элементы данных в каждом бизнес-процессе, такие как тендерные проекты, тендерные компании, эксперты по оценке заявок, стандарты оценки и т. д.
• Определите необработанные данные, которые необходимо собрать, и необходимые исторические данные.

поле данных：

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

Идентификация источника данных

Определить источники данных：

• Определите исходную систему данных, например систему ERP, систему CRM, систему электронной почты, систему хранения файлов и т. д.

сбор данных：

• Определите, как извлечь данные из этих источников данных, требуется ли разработка интерфейса, импорт данных и т. д.

Определение ключевого показателя эффективности

Определить ключевые показатели эффективности：

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

Общие ключевые показатели эффективности：

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

2. Анализ спроса

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

Существует два способа проведения анализа потребностей:

• Понимание потребностей на основе общения с аналитиками и персоналом бизнес-операций.
• Проводить исследования и анализ существующих отчетов в системе отчетности.

Напишите документ с требованиями：

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

Содержание документа：

• Бизнес-история и цели
• Бизнес-процесс описывать
• Требования к данным и источники данных
• ключевые показатели эффективности
• Анализ существующих систем и источников данных
• Болевые точки бизнеса и потребности в улучшении

Например, требованиями к тендерному бизнесу могут быть:

• Оценка рынка и анализ возможностей поставщиков.
• Анализ эффективности бренда тендерных проектов.
• Управление уровнями поставщиков и финансовыми расчетами.
• Мониторинг и оптимизация тендерных процессов.

3. Анализируйте бизнес-процессы

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

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

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

4. Разделите области данных

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

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

Разделите хранилище данных на различные домены данных на основе бизнес-функций и ключевых объектов данных. Каждая область данных может содержать несколько связанных таблиц данных с тесными деловыми связями между этими таблицами.

Поле данных управления тендерами

• объект данных：Тендерный проект, объявление о тендере
• описывать：Управляйте всеми данными, связанными с тендерным процессом,Включает определение проекта, бюджет, расписание. и объявления размещены.
• Пример таблицы：
  • Таблица проекта торгов (Проект)
  • Форма объявления о проведении тендера (Объявление)

Поле данных управления ставками

• объект данных：нежный、Тендерная документация
• описывать：Управлять всемнежныйданные, связанные с процессом,включать Тендерная документацияприем、Запишите и классифицируйте.
• Пример таблицы：
  • Форма заявки (Заявка)
  • Таблица файлов ставок (Bid_File)

Поле данных управления оценкой ставок

• объект данных：оценка предложения、Критерии оценки、Эксперт по оценке тендеров
• описывать：Управлять всемоценка предложенияданные, связанные с процессом,включать Критерии оценки、Протоколы оценки заявок и экспертная информация.
• Пример таблицы：
  • Форма оценки (Оценка)
  • Стандартная таблица оценок (Scoring_Standard)
  • Форма эксперта по оценке заявок (Эксперт)

Поле данных управления контрактами

• объект данных：договор、Условия контракта
• описывать：Управлять всемдоговор Подписание и управление соответствующими данными,включать Условия контрактаи подписываем записи。
• Пример таблицы：
  • Договор
  • Условия контракта (Contract_Term)

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

Поле данных управления тендерами：

• Таблица проекта торгов (Проект)：
  • Project_ID (первичный ключ)
  • Project_Name
  • Budget
  • Start_Date
  • End_Date
• Форма объявления о проведении тендера (Объявление)：
  • Announcement_ID (первичный ключ)
  • Project_ID (внешний ключ)
  • Announcement_Content
  • Publish_Date

5. Связь между предметными областями

Определите взаимосвязь между каждой областью данных и спроектируйте соответствующие ограничения внешнего ключа. Это помогает обеспечить согласованность и целостность данных. Например, таблица ставок (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)
);

6. Определите размеры и постройте матрицу шин.

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

1. Определите размеры

Измерения — это информация, которая описывает контекст бизнес-процессов и помогает нам понимать и анализировать фактические данные. Мы можем сначала построить общие измерения, а затем построить измерения с подробными определениями.

1.1 Определение общих размеров

Во-первых, определите общие измерения во всех предметных областях, которые будут повторно использоваться в разных предметных областях. Например, в тендерном бизнесе возможные общие параметры включают в себя:

• Измерение времени (Время)
• Измерение проекта (Проект)
• Параметр Поставщик (Поставщик)
• Географическое измерение (Местоположение)

1.2 Подробное определение таблицы измерений

Определите подробные атрибуты для каждого измерения и создайте соответствующую таблицу измерений. Например, мы можем спроектировать таблицу измерений времени как:

Таблица измерения времени (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
);

2. Построить матрицу шин (Bus Matrix)

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

2.1 Перечислите все таблицы фактов

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

• Таблица фактов ставок (Fact_Bid)
• Таблица фактов оценки ставок (Fact_Evaluation)
• Таблица фактов контракта (Fact_Contract)
• Таблица фактов о ходе проекта (Fact_Project_Progress)
• Таблица фактов расчетов (Fact_Settlement)

2.2. Перечислите все общие параметры

Перечислите измерения, общие для всех полей данных, например:

• Измерение времени (Dim_Time)
• Измерение проекта (Dim_Project)
• Параметр «Поставщик» (Dim_Supplier)
• Географическое измерение (Dim_Location)

2.3 Заполните матрицу шин

Создайте таблицу, которая сопоставит таблицу фактов с таблицей измерений. Пример матрицы шины следующий:

Пример таблицы фактов ставок (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)
);

3. Проверка и оптимизация

3.1 Уточнение статистических показателей

Атомарные индикаторы имеют четкий статистический калибр и логику расчета: Атомный показатель = бизнес-процесс + измерение。Производные показатели – это общие статистические показатели.：Производный индикатор = период времени + модификатор + атомарный индикатор。Атомарные индикаторы можно создавать только после определения бизнес-процесса.。Создание производных показателей обычно необходимо осуществлять после понимания конкретных требований к отчетности.,Прежде чем создавать производный индикатор, необходимо создать атомарный индикатор. Следует отметить следующее:

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

На основе предыдущего анализа мы подтвердили, что бизнес-процесс: подтверждение поступления (успешная сделка), а измерение – сумма реализации товара. Таким образом, в соответствии с потребностями бизнеса мы можем определить атомарный показатель: сумму успешной транзакции с товаром.

Производными показателями являются:

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

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