Универсальная архитектура хранилища данных для CRM систем

Актуальность исследования

На сегодняшний день 91% компаний со штатом из более 11 сотрудников используют CRM-cистему. Компании, которые используют CRM-систему, замечают увеличение своих продаж на величину вплоть до 29% [1]. Многие компании используют уже готовые технологические решения, функционал которых предоставляется из «коробки». То есть функционал, заложенный разработчиками данного решения, на этапе конструирования системы. Данный функционал, во многих случаях, отвечает требованиям компаний малого бизнеса, но среднему и большому бизнесу необходимы свои собственные технологические решения, отвечающие их специфическим требованиям. Актуальность исследования обусловлена необходимостью создания универсальной платформы, позволяющей создавать гибко настраиваемые и масштабируемые технологические решения в области CRM систем в короткий срок и без изменения программного кода.

Цель исследования

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

Практическая часть

Любая CRM система представляет из себя целый комплекс различного программного обеспечения (далее ПО). Комплекс может включать в себя различные программные решения. Как минимум в системе должна присутствовать клиентская и серверная часть, с учетом того, что почти все современное ПО использует исключительно клиент-серверную архитектуру [3, с. 56]. В данной статье будет рассматриваться только ядро всего комплекса, а именно хранилище данных и его архитектура.

CRM-система – это способ управления взаимоотношениями с клиентами и оптимизации бизнес-процессов [2, с. 5]. Из данного утверждения следует, что необходимо где-то хранить как минимум информацию о клиентах. Также для более эффективной работы предприятия необходимо хранить информацию о сотрудниках предприятия и услугах или товарах, которые оказывает или предоставляет соответственно предприятие. Немаловажно также хранить данные об уже оказанных услугах или проданных товарах. Для удобства можно представить CRM-систему для сервисного центра по ремонту электронной техники. Простейшая база данных в классическом исполнении для такого сервисного центра представлена ниже (рис. 1).

Рис. 1. Классическая архитектура хранилища

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

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

Для получения большой масштабируемости и адаптации под большое множество бизнес-логик, необходимо кардинально пересмотреть подход к архитектуре хранения данных. В классической архитектуре каждая таблица представляет собой сущность. У таблицы есть столбцы, которые являются свойствами сущности. Чтобы добиться универсальности работы для большого количества бизнес-логик и масштабируемости, необходимо создать возможность добавлять новые сущности(таблицы) и свойства сущностей(столбцы) без изменения общей структуры данных. Это можно сделать путем добавления трех таблиц: «Сущности», «Свойства», «Сущность-свойство». В таблице «Сущности» будет только название сущности, например «Сотрудники», «Услуги» и т. д. В таблице «Свойства» будет столбец с названием свойства, например «Имя», «Номер телефона», а также столбец с типом данных. Тип данных необходим для того, чтобы серверная и клиентская части понимали в какой формат конвертировать данные из базы. Таблица «Сущность-свойство» необходима для привязки определенной сущности к свойствам. Для добавления самих данных в таблицу необходимо создать две таблицы: «Объекты» и «Данные». Таблица «Объекты» будет хранить идентификаторы всех объектов сущностей. Эти объекты можно назвать строками из таблиц в классической архитектуре. Для хранения самих данных по каждому объекту сущности необходимо создать таблицу «Данные». В ней будет столбец, содержащий идентификатор объекта, идентификатор связки сущность-свойство, а также самое значение, в зависимости от типа свойства. Универсальная архитектура для хранения данных представлена ниже (рис. 2).

Рис. 2. Универсальная архитектура базы данных

Данный тип архитектуры хранилища позволяет добавлять новые сущности и свойства к ним, без добавления новых таблиц и столбцов в базу данных. Единственным «зашитым» функционалом в данном подходе, является обработка типов данных. В таблице «Данные» поле «Значение» является условным. Вместо одного столбца «Значение», должно быть несколько столбцов, которые имеют поддерживаемые языком SQL типы данных, например int, character varying, bool и др. Данные столбцы необходимы для хранения значения, в зависимости от типа данных самого свойства сущности. Например, если тип свойства представляет из себя строку, то его значение будет храниться в столбце с типом данных character varying. При добавлении нового типа данных в таблице «Свойства» необходимо добавлять в программный код новый функционал по обработке нового типа данных. Эта необходимость обусловлена тем, что серверной части ПО необходимо знать из какого столбца таблицы «Данные» брать значение для передачи в клиентскую часть. А клиентская часть, получая тип данных, должна понимать какой клиентский интерфейс нужно создать на стороне клиента, например, при числовом типе, необходимо сделать маску, ограничивающую пользователя во вводе строки в поле.

Выводы

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