Обновление: Я не ищу кого-то
придумать схему для меня. Похоже
Я ищу информацию о том, некоторые ли
нормализованный дизайн БД будет работать, когда
Я не могу четко определить все
отношения сущностей я
работать, или если что-то еще
вдоль линии хранилища данных
было бы то, что я хотел бы посмотреть на
дальше (понимая здесь, я знаю достаточно
о хранилищах данных быть опасными
- и это все.)
Мне было поручено "оптимизировать" процесс отчетности для небольшого колл-центра. Большая часть моего опыта связана с веб-приложениями, и я считаю себя средним PHPer (самоучка, нет колледжа - я потрачу минутку молчания, чтобы коллективный вздох утих). Так что это было немного, если проект отличается от моей нормы - хотя все еще должен быть веб-интерфейс, так что он, по крайней мере, немного похож на домашний.
Процесс отчетности в том виде, в котором он существует, включает получение печатных отчетов из системы ACD, которые необходимо вводить вручную в Crystal Reports. Кроме того, Crystal используется для запуска отчетов из системы тикетов, чтобы найти такие вещи, как скорость разрешения для принятых вызовов и т. Д. Мне было поручено разрешить загрузку электронных CSV-файлов, которые следует анализировать, а затем загружать в базу данных. , После загрузки в указанную базу данных отчеты можно создавать и отправлять по электронной почте, просто щелкнув ссылку на веб-сайте (в основном).
Обычно я начинаю проекты, просматривая имеющиеся у меня данные и создавая базу данных для моделирования этих данных. Я не DB Rockstar, поэтому базы данных, как правило, довольно просты, но я стараюсь нормализовать, как минимум 3NF. Однако с этим проектом я быстро понял, что будет трудно определить отношения надежно - поскольку сценарии, которые я не контролирую, определяют, как связаны эти данные, и отчеты, которые я получаю, не способствуют выявлению этих отношений. , Поэтому я начал искать в Интернете. Я измотал Google. Я прочитал кучу вопросов и ответов на SO; во многих из них больше акронимов, чем я хочу посмотреть.
Так что я прихожу к вам, ТАК, за помощью. Предполагая, что я предоставил достаточно информации, может кто-нибудь сказать мне, будет ли то, что я смотрю, лучше всего послужить мне, если я сбегу и узнаю больше о хранилище данных (а также, если да, где, кто, что я должен читать / делать), или, скорее всего, будет работать довольно денормализованная база данных SQL?
Имейте в виду, что самое большее будет вводиться от 300 до 400 строк данных в день - и большинство из этих данных - простые INT. Это очень маленькая база данных.
Бизнес просто хочет сократить количество рабочей силы, используемой для создания отчетов. Они не пытаются изменить отчеты.
Я надеюсь, что предоставил достаточно информации, если нет, я приложу все усилия, чтобы быть более конкретным, основываясь на комментариях / вопросах, которые я получаю обратно.
Я начал делать схему 3NF и получил несколько таблиц. Один для агентов (идентификатор, имя, адрес электронной почты, добавочный номер), групп агентов (идентификатор, имя группы) и приложений (идентификатор, имя приложения).
Это немного сломалось, когда я понял, что когда приложение получает вызов, оно может перейти к любому количеству групп на основе любого количества критериев, и у меня нет возможности получить эту информацию (я не уверен, что кто-то делает). Поэтому я начал думать, что не было никакой необходимости связывать эти три вещи вместе.
Учитывая это, будет еще 4 таблицы, AgentProfiles, AgentEvaluations, AgentGroupSummary и ApplicationSummary. Каждая из этих таблиц будет иметь столбец, который соответствует данным в отчете, который я получаю. Кроме того, существует FK, который указывает на приложение, агент или группу агентов, связанную с этой «строкой» данных.
Я думаю, что в этот момент я начал паниковать, и мне кажется, что я ищу информацию от людей, которые находятся за пределами болота этого проекта, о том, как действовать. Я не хочу денормализовать до такой степени, что будущее обслуживание становится кошмаром - я, кажется, застрял; боюсь, что я переоцениваю / теряю дизайн, и в конечном итоге сам себя накручиваю.
Edit:
Я сопротивлялся желанию слишком углубиться в данные, с которыми работал, из-за страха создать гигантскую стену текста. Я объясню данные, которые буду получать, но файлы CSV настолько искажены, что я не могу привести пример отчетов, которые я получу. Я могу (и сделаю чуть дальше) привести пример данных, которые будут поступать в БД.
По сути, отчеты, которые я получаю, являются измерениями статистики аналитика вызовов. Сколько звонков они совершают за час, за день, сколько времени им требуется, чтобы ответить на звонок, продолжительность разговора и т. Д. В отчетах каждый аналитик называется агентом. Каждый агент принадлежит к группе агентов, а каждая группа агентов связана с приложением.
После того, как я перенесу данные в БД, мне нужно будет делать красивые отчеты, которые можно ежедневно экспортировать руководству, а также агентам.
Существуют 2 отчета, которые имеют непосредственное отношение к агентам: отчет о профиле агента и отчет об оценке агента. Я приведу примеры одного из докладов. Остальные отчеты не очень удобны для того, чтобы их можно было перевести в текст без 40 минут ввода.
AGNTNAME,07:18:56,03:29:36,26,265,74,0,339,11
- Отчет об оценке агента
- Имя агента
- Время (ЧЧ: ММ: СС), в которое агент входил на свой телефон
- Время (ЧЧ: ММ: СС), в течение которого агент был готов принимать вызовы
- Сколько звонков они приняли (INT)
- Тогда есть несколько рассчитанных средних значений, которые рассчитываются на основе того, что генерирует отчеты. Если не указано иное, это целые числа, выражающие общее время в секундах (например, 180 против 00:03:00).
- время разговора (время начала разговора, пока оператор не отключится)
- рабочее время (время, проведенное недоступно после принятия вызова, пока не будет доступно, чтобы принимать вызовы снова)
- время удержания (время, когда вызывающий абонент удерживал определенного агента)
- время обработки (время разговора + время работы)
- звонков в час (это мнимый #, что означает, что он экстраполируется на основе количества звонков, которые агент берет против количества времени, когда они вошли в систему. Я не уверен, какая формула используется для получения это число)
Отчет о профиле оператора разбивает день агентов на отдельные входы в систему по периодам. Каждый раз, когда агент становится недоступным, генерируется новый период входа в систему, а также новая строка данных, структурированная аналогично отчету об оценке агента, но с большим количеством полей, которые измеряют все больше аналитических точек. Большинство из них представляют собой средние значения или произведенные средние значения (то есть они не являются истинными средними значениями фактических чисел, а являются средними значениями вычисленных чисел, основанных на некотором критерии секретного соуса).
Агенты также группируются в логические подмножества на основе навыков, которые называются группами агентов. Каждая группа агентов принадлежит одному или нескольким приложениям. Приложение можно рассматривать как очередь вызовов («Нажмите 1 для сброса пароля», «Нажмите 2 для справки Microsoft Office» и т. Д.). Однако каждое приложение имеет сценарий, который определяет, как вызов перенаправляется до 10 групп операторов, связанных с приложением.
Именно здесь определение отношений становится проблематичным, потому что в отчетах нет ничего, что говорило бы мне о том, что «вызов X был перенаправлен в группу операторов Y по критериям Z». Таким образом, я получаю 3 объекта, которые трудно надежно связать друг с другом.
- Агенты
- Группы агентов
- Приложения
Агент принадлежит 1 или более групп агентов.
Агент принадлежит 0 приложениям (напрямую - они связываются через группы агентов).
Группа агентов может иметь 1 или более агентов.Группа агентов принадлежит одному или нескольким приложениям.
Приложение имеет от 1 до 10 групп агентов.Приложение имеет 0 агентов (опять же, напрямую).
Поскольку мне потребуется хранить исторические данные, мне потребуется способ отсеять статистику для агентов, которых больше не существует, поэтому я неотправка статистики по несуществующим адресам электронной почты.
Надеюсь, что дополнительная информация поможет.