Нормализация для работника службы поддержки по телефону

Я создаю базу данных sql, которая регистрирует звонки от компаний (или отдельных отделов внутри компании) с контрактами на обслуживание (1).

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

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

Нормализация

Если бы кто-нибудь из вас, ребята, мог бы мне помочь, я был бы фантастическим

* UPDATE OK, я еще раз попытался его нормализовать, и вот оно: (звездочка = внешний ключ. двойная звездочка = первичный ключ)

**Call id**
Date and time of call
Method of call
*First line Support Analyst ID
*Problem Analyst  ID
*Specialist Analysts  ID
*Service contract number
Name of caller
landline
mobile 
Email address
Brief textual description of problem
Initial severity level

**Action id** 
*Call id 
Date and time of action
Textual description of action
Current status
Current severity level

**Specialist Analysts  ID**
Name of specialist analyst
Expertise

**First line Support Analyst ID**
Name of first line support analyst

**Problem Analyst ID**
Name of problem analyst

**Service contract number**
Company
Department
Software product
Software version
Operating system

ПРИМЕЧАНИЯ

(1) Контракт на обслуживание относится либо к компании в целом, либо к отделу, т. е. два отдела в одной компании будут иметь отдельные контракты на обслуживание. Контракт на обслуживание охватывает отдельную комбинацию программного обеспечения и ОС, поэтому SQL Developer под Windows 7 иметь отдельный контракт на обслуживание с SQL Developer под Windows XP (или Windows Vista или MacOS Lion)


database-design database-normalization normalization
person user667430    schedule 14.11.2011    source источник
comment
Как вы понимаете свою цель при переходе от 2NF к 3NF?   -  person Mike Sherrill 'Cat Recall'    schedule 14.11.2011
comment
Я добавил обновленную версию нормализации. это выглядит правильно для 3NF?   -  person user667430    schedule 16.11.2011

Ответы (1)


arrow_upward
1
arrow_downward

Не зная ваших требований, трудно быть точным, но вот несколько замечаний:

Я бы создал таблицу «аналитик» с Analyt_Type, а не отдельные таблицы для каждого типа аналитика.

Я бы установил отношения «никто ко многим» между аналитиками и областями знаний.

Я бы создал явную концепцию «call_status», а не зависел бы от того, какой аналитик в настоящее время владеет мячом.

Я бы подумал о том, чтобы call_status, action и current_analyst были в отдельной таблице с флагами date_time, чтобы вы могли отслеживать историю — когда она была назначена аналитику 2-й линии? Как долго они звонили? Что они сделали?

person Neville Kuyt    schedule 16.11.2011
comment
Привет, спасибо за ответ. Я сделал большую часть того, что вы сказали. Что касается call_status, это может быть i) ожидание назначения, ii) работа над ним, iii) ожидание ответа, iv) закрыто. Это проводится в «Текущий статус». Было бы более уместно хранить это в таблице «Вызов»? Вот ссылка на обновленную нормализацию. - person user667430; 16.11.2011
comment
Я думаю, что между аналитиками и экспертами существует связь «многие ко многим». Я думаю, что analyticID должен быть в таблице действий, а не в таблице вызовов. - person Neville Kuyt; 16.11.2011
comment
Обновлено Теперь все выглядит нормально? Спасибо за вашу помощь. - person user667430; 16.11.2011
comment
Вам по-прежнему необходимо соотношение «многие ко многим» между аналитиками и экспертами — обычно для этого требуется таблица соединений с аналитиками_идентификатором и знанием_идентификатора в качестве внешних ключей. - person Neville Kuyt; 16.11.2011