Проектування бази даних прогнозування щоденної зайнятості робітників банка

Перед розробкою бази даних для прогнозування щоденної зайнятості робітника банка необхідно визначити сутності, про які будуть накопичуватися дані в базі даних. Так, дані про Робітники банка необхідно зберігати тому, що в кожної є свої щоденні плани. Відповідно є завдання, які відбуваються в певний проміжок часу. Перед прогнозуванням оцінка відбувається по психотипах, про яких також доцільно зберігати інформацію. Відповідно отриманих результатів надаються рекомендації, які формують Робочі плани, які зберігаються у вигляді файлів. Кожне прогнозування здійснюється за правилами, заданими розробником згідно психотипів.

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

Отже, основні сутності в базі даних програмного продукту для прогнозування щоденної зайнятості: Робітники банка, файли, завдання, рекомендації, Робочі плани, психотипи, правила.

1) рекомендації (формулювання рекомендації, правило для формування рекомендації, номер рекомендації)

2) робочі плани (рекомендація в звіті, дата формування робочого плану, час формування робочого плану, номер робочого плану)

3) психотипи (назва психотипу, номер психотипу, особливість психотипу)

4) правила (номер правила, назва правила, формулювання правила, відповідність психотипу)

5) завдання (назва завдання, дата завдання, час початку завдання, час завершення завдання, пріоритет завдання, номер завдання)

6) Робітники банка (унікальний номер користувача, ПІБ користувача, електронна адреса користувача, країна проживання користувача, місто проживання користувача, домашня адреса користувача, робочий телефон користувача, мобільний телефон користувача, файли користувача, логін користувача, пароль користувача).

Відповідно до вимог подання категорій бази даних опишемо сутності з атрибутами програмного продукту для прогнозування щоденної зайнятості:

Рекомендації (формулювання рекомендації, правило для формування рекомендації, номер рекомендації).

Робочі плани [Робітники банка] (рекомендація в звіті, дата формування робочого плану, час формування робочого плану, номер робочого плану).

Психотипи (назва психотипу, номер психотипу, особливість психотипу) {Правила}.

Правила [Завдання] (номер правила, назва правила, формулювання правила, відповідність психотипу) {Рекомендації}.

Завдання (назва завдання, дата завдання, час початку завдання, час завершення завдання, пріоритет завдання, номер завдання) {Робітники банка}.

Робітники банка (унікальний номер користувача, ПІБ користувача, електронна адреса користувача, країна проживання користувача, місто проживання користувача, домашня адреса користувача, робочий телефон користувача, мобільний телефон користувача, файли користувача, логін користувача, пароль користувача).

Вигляд універсального відношення для бази даних програмного продукту для прогнозування щоденної зайнятості:

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

Ступінь універсального відношення бази даних для реалізації програмного продукту для прогнозування щоденної зайнятості – 31.

ER-модель бази даних програмного продукту для прогнозування щоденної зайнятості представлена в таблиці 4.1.

Таблиця 4.1 – Фрагмент таблиці бази даних програмного продукту для прогнозування щоденної зайнятості

Відповідно до правил побудови концептуальних схем у вигляді ER-структур сутності зображують позначеними прямокутниками, асоціації – ромбами, а зв'язки між ними – ненаправленими ребрами. Зв’язки зображують у вигляді ліній – прямою обов’язковий зв’язок, пунктирною необов’язковий зв’язок.

Представлення ER-моделі для бази даних програмного продукту для прогнозування щоденної зайнятості на рисунку 2.4:

Рисунок 4.2 – Концептуальна схема бази даних програмного продукту для прогнозування щоденної зайнятості

Як видно з рисунку 4.2, зв’язки між сутностями «Робітники банка» - «Робочі плани», «Правила» - «Завдання» типу Б:Б, зв’язки між сутностями «Робітники банка» - «Завдання», «Рекомендації» - Правила», «Правила» - «Психотипи» – 1:Б, між сутностями «Робочі плани» - «Рекомендації» - 1:1. Зв’язки між сутностями «Робітники банка» - «Завдання», «Завдання» - «Правила», є необов’язковими, зв’язки між сутностями «Правила» - «Психотипи», «Правила» - «Рекомендації», «Рекомендації» - «Робочі плани», «Робочі плани» - «Робітники банка» - обов’язкові.

Проведемо нормалізацію даних бази даних програмного продукту для прогнозування щоденної зайнятості до 3 повної нормальної форми, для отримання такого проекту БД, у якому кожний атрибут з’являється лише в одному місці, тобто виключена надлишковість інформації [14].

Універсальне відношення даної предметної області знаходиться в 1НФ, оскільки таблиця має основний ключ: мінімальний набір колонок, які ідентифікують запис, таблиця задовольняє умову, у відповідності з якою у позиції на перетині кожного рядка і стовпця таблиці знаходиться єдине атомарне значення, а не множина таких значень, в таблиці немає кортежів, що повторюються: R: (формулювання рекомендації, правило для формування рекомендації, номер рекомендації, рекомендація в звіті, дата формування робочого плану, час формування робочого плану, номер робочого плану, назва психотипу, номер психотипу, особливість психотипу, номер правила, назва правила, формулювання правила, відповідність психотипу, назва завдання, дата завдання, час початку завдання, час завершення завдання, пріоритет завдання, номер завдання, унікальний номер користувача, ПІБ користувача, електронна адреса користувача, країна проживання користувача, місто проживання користувача, домашня адреса користувача, робочий телефон користувача, мобільний телефон користувача, файли користувача, логін користувача, пароль користувача).

Відношення знаходиться в другій нормальній формі (2НФ), якщо воно знаходиться в 1НФ і кожний неключовий атрибут функціонально повно залежить від складеного ключа [15]. Якщо проаналізувати такі умови – то можна зробити висновок, про те, що не всі атрибути функціонально повно залежать від ключа – наприклад, атрибут «мобільний телефон користувача» залежить лише від атрибута «унікальний номер користувача», але зовсім не залежить від таких складових як «формулювання рекомендації», «правило для формування рекомендації», «номер рекомендації», «рекомендація в звіті», «дата формування робочого плану», «час формування робочого плану», «номер робочого плану», «назва психотипу», «номер психотипу», «особливість психотипу», «номер правила», «назва правила», «формулювання правила», «відповідність психотипу», «назва завдання», «дата завдання», «час початку завдання», «час завершення завдання», «пріоритет завдання», «номер завдання», «ПІБ користувача», «електронна адреса користувача», «країна проживання користувача», «місто проживання користувача», «домашня адреса користувача», «робочий телефон користувача», «файли користувача», «логін користувача», «пароль користувача».

Друга нормальна форма вимагає, щоб відношення знаходилось у 1НФ, а також, щоб кожен не ключовий атрибут функціонально повно залежав тільки від первинного ключа. Визначимо функціональні залежності, що присутні в універсальному відношенні.

Унікальний номер користувача → ПІБ користувача, електронна адреса користувача, країна проживання користувача, місто проживання користувача, домашня адреса користувача, робочий телефон користувача, мобільний телефон користувача, файли користувача, логін користувача, пароль користувача.

Номер рекомендації → формулювання рекомендації, правило для формування рекомендації.

Номер робочого плану → рекомендація в звіті, дата формування робочого плану, час формування робочого плану.

Номер психотипу → назва правила, формулювання правила, відповідність психотипу.

Номер правила → назва правила, формулювання правила, відповідність психотипу.

Номер завдання → назва завдання, дата завдання, час початку завдання, час завершення завдання, пріоритет завдання.

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

Рекомендації (формулювання рекомендації, правило для формування рекомендації, номер рекомендації, ключ – номер рекомендації).

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

Психотипи (назва психотипу, номер психотипу, особливість психотипу, ключ – номер психотипу).

Правила (номер правила, назва правила, формулювання правила, відповідність психотипу, ключ – номер правила).

Завдання (назва завдання, дата завдання, час початку завдання, час завершення завдання, пріоритет завдання, номер завдання ключ – номер завдання).

Перевіримо, чи знаходяться дані відношення у 2НФ.

У відношенні «Рекомендації» ключовим атрибутом є «номер рекомендації». Неключові атрибути: «формулювання рекомендації», «правило для формування рекомендації» функціонально повно залежить від ключа.

У відношенні «Робочі плани» ключовим атрибутом є «номер робочого плану». Неключові атрибути: «рекомендація в звіті», «дата формування робочого плану», «час формування робочого плану» функціонально повно залежить від ключа.

У відношенні «Психотипи» ключовим атрибутом є «номер психотипу». Неключові атрибути: «назва психотипу», «особливість психотипу» функціонально повно залежить від ключа.

У відношенні «Правила» ключовим атрибутом є «номер правила». Неключові атрибути: «назва правила», «формулювання правила», «відповідність психотипу» функціонально повно залежить від ключа.

У відношенні «Завдання» ключовим атрибутом є «номер завдання». Неключові атрибути: «назва завдання», «дата завдання», «час початку завдання», «час завершення завдання», «пріоритет завдання» функціонально повно залежить від ключа.

У відношенні «Робітники банка» ключовим атрибутом є «унікальний номер користувача». Неключові атрибути: «ПІБ користувача», «електронна адреса користувача», «країна проживання користувача», «місто проживання користувача», «домашня адреса користувача», «робочий телефон користувача», «мобільний телефон користувача», «файли користувача», «логін користувача», «пароль користувача» функціонально повно залежить від ключа.

Тепер отримані відношення знаходяться у другій нормальній формі.

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

У відношенні «Рекомендації» ключовим атрибутом є «номер рекомендації». Неключові атрибути: «формулювання рекомендації», «правило для формування рекомендації» транзитивно не залежать від ключа.

У відношенні «Робочі плани» ключовим атрибутом є «номер робочого плану». Неключові атрибути: «рекомендація в звіті», «дата формування робочого плану», «час формування робочого плану» транзитивно не залежать від ключа.

У відношенні «Психотипи» ключовим атрибутом є «номер психотипу». Неключові атрибути: «назва психотипу», «особливість психотипу» транзитивно не залежать від ключа.

У відношенні «Правила» ключовим атрибутом є «номер правила». Неключові атрибути: «назва правила», «формулювання правила», «відповідність психотипу» транзитивно не залежать від ключа.

У відношенні «Завдання» ключовим атрибутом є «номер завдання». Неключові атрибути: «назва завдання», «дата завдання», «час початку завдання», «час завершення завдання», «пріоритет завдання» транзитивно не залежать від ключа.

У відношенні «Робітники банка» ключовим атрибутом є «унікальний номер користувача». Неключові атрибути: «ПІБ користувача», «електронна адреса користувача», «країна проживання користувача», «місто проживання користувача», «домашня адреса користувача», «робочий телефон користувача», «мобільний телефон користувача», «файли користувача», «логін користувача», «пароль користувача» транзитивно не залежать від ключа.

Оскільки ні один не ключовий атрибут не залежить транзитивно від ключа відношення, то можна стверджувати, що відношення знаходяться у третій нормальній формі. Введемо додаткові відношення, які будуть відображати зв’язки типу Б:Б: 1) «Робітники банка_Робочі плани», де полями є «унікальний номер користувача», «номер робочого плану»; 2) «Правила_Завдання», де полями є «номер правила», «номер завдання».

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: