Система управління взаємовідносинами з клієнтами CRM

власники транспорту (паспортні дані, Ф. І. ПБ., телефон) ;

система взаємовідносин з клієнтами яка повинна містити в собі клієнтів, спосіб звернення, робітника який обслуговував, тему за якою звертаються, суть проблеми, дії по зверненню, дата виконання та оцінку на скільки задоволений клієнт.

Вивід інформації у вигляді звітів.

На основі швидкого аналізу, для наглядного представлення компонентів БД була розроблена концептуальна модель (рис. 3. 3) На концептуальному рівні здійснюється інтегрований опис предметної області, для якої розглядається БД, незалежно від її сприйняття окремими користувачами та способів реалізації в комп’ютерній системі.

 

Рисунок 3.3 ― Концептуальна модель

 

Концептуальна модель бази даних ― це високорівнева об’єктно-орієнтована модель предметної області, що представляє об’єктну область у вигляді набору об’єктів, що володіють певними властивостями і знаходяться в деяких відносинах [44]. Основна мета розробки високорівневої моделі даних полягає у створенні моделі користувацького сприйняття даних та узгодження великої кількості технічних аспектів, пов’язаних з проектуванням бази даних. Концептуальна модель даних не прив’язана до конкретної фізичної реалізації баз даних і не залежить від конкретної СКБД. Концептуальна модель створюється на основі уявлень про предметну область кожного типу користувачів, що представляють собою набір даних, необхідних користувачеві для вирішення своїх завдань. Основні концепції моделі включають такі поняття як сутність (об’єкт), відношення (зв’язок), типи сутностей, типи зв’язків та атрибути.

При проектуванні БД слід дотримуватися правил нормалізації таблиць [45]:

Кожне поле будь-якої таблиці повинне бути унікальним.

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

Для кожного значення первинного ключа повинно бути одне і тільки одне значення кожного з стовпців даних, і це значення повинно ставитися до об’єкта таблиці.

Повинна бути можливість змінювати значення будь-якого поля (не входить в первинний ключ), і це не повинно спричинити за собою зміну іншого поля [].

З описання предметної області виведемо всі типи сутностей:

Власники;

Транспорт;

Дефекти;

Робітники;

Замовлення;

Види робіт;

Категорія дефектів;

Спосіб звернення;

Задоволеність клієнта.

Тепер для кожного об’єкту встановимо потенційний ключ, після чого здійснимо вибір первинного ключа. При виборі первинного ключа будемо керуватися правилами:

Будемо використовувати ключ з мінімальним набором атрибутів.

Використовувати слід той ключ, ймовірність зміни значень якого мінімальна.

Значення ключа повинно мати мінімальну довжину.

З обраним ключем користувачеві буде зручніше працювати.

Фізичне проектування

На етапі фізичного проектування створюються таблиці. Нижче представлені рисунки таблиць, та відповідними типами даних полів (рис. 3. 4 – 3. 16).

 

 

Рисунок 3. 4 – Структура таблиці «Власники»

 

 

Рисунок 3. 5 – Структура таблиці «Робітники»

 

 

Рисунок 3. 6 – Структура таблиці «Транспорт»

 

 

Рисунок 3. 7 – Структура таблиці «Замовлення»

 

 

Рисунок 3. 8 – Структура таблиці «Дефект»

 

 

Рисунок 3. 9 – Структура таблиці «Види робіт»

 

 

Рисунок 3. 10 – Структура таблиці «Категорія дефектів»

 

 

Рисунок 3. 11 – Структура таблиці «Спосіб звернення»

 

 

Рисунок 3. 12 – Структура таблиці «Задоволеність клієнта»

 

 

Рисунок 3. 13 – Структура таблиці «Дефект транспорту»

 

 

Рисунок 3. 14 – Структура таблиці «Власники транспорту»

 

 

Рисунок 3. 15 – Структура таблиці «Послуги замовлення»

 

 

Рисунок 3. 16 – Структура таблиці «Взаємодії з клієнтом»

 

Структура БД

Структура БД – це визначення таблиць і атрибутів (полів) з їх типами, властивостями, умовами на значення.

Існують 3 типи структур даних [46]:

Деревовидна (ієрархічна) – її зручно використовувати при опису даних про родовід від одного предка.

Мережева – використовується для задання даних про родовід від двох предків.

Реляційні структури – дані організовуються в двовимірних таблицях.

В сучасних СКБД використовується реляційна структура. Ця конструкція була запропонована в 1970 році Коддом. Він показав що представлення даних з допомогою ієрархічної чи мережевої структури може бути зведена до реляційної структури.

Реляційні модель на сьогоднішній день набули великої популярності і практично всі сучасні СБД орієнтовані на таке представлення даних. У реляційних моделях таблиця розглядається як безпосереднє сховище даних. Традиційно в реляційних системах таблицю називають відношенням. Рядок таблиці називають кортежем, а стовпчик атрибутом, при цьому атрибути мають унікальні (в межах відношення) імена. Кількість кортежів в таблиці називають кардинальним числом, а кількість атрибутів степенем.

У відношень є такі основні властивості:

в загальному випадку в відношеннях не буває двох однакових кортежів;

кортежі не впорядковані з верху в низ, тому що в відношеннях відсутнє поняття позиційного номеру;

атрибути не впорядковані з ліва на право.

значення атрибутів складаються з логічно неділимих одиниць.

Після того, як були обрані первинні ключі, наступним кроком є подання зв’язків