Створення АРМ заступника начальника виробництва фриз ТОВ «Вінісін»

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

Таким чином потенційні ключі мають таке саме фундаментальне значення для успішної роботи реляційної системи, як адресація основної пам'яті  для успішної роботи машини, на якій ця система встановлена.

Первинний ключ — атрибут, або набір атрибутів, що однозначно ідентифікує кортеж даного відношення. Первинний ключ обов'язково унікальний, він єдиний і найголовніший із унікальних ключів.

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

При виборі первинного ключа серед декількох потенційних слід враховувати:

• Використовувати потенційний ключ з мінімальним набором атрибутів.

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

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

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

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

Результати визначення первинних і альтернативних ключів для кожної із сутностей запишемо у вигляді таблиці 2.6.

Таблиця 2.6

Сутності та їхні первині та альтернативні ключі

Назва сутності	Первинний ключ	Альтернативний  ключ
1	2	3
Postachal'nyky syrovyny	Kod postachal'nyka	Juredychna nazva
Syrovyna	Kod syrovyny	Nazva
Vyrobnychyj zhurnal	Lichyl'nyk
Personal	Kod pracivnyka	Prizvyshhe
Sluzhby	Kod sluzhby	Nazva
Oblik robochogo chasu	Lichyl'nyk	Kod pracivnyka
Dop materialy	Kod dop materialu	Nazva

 

Продовження таблиці 2.6

1	2	3
Gotova produkcija na skladi	Lichyl'nyk	Kod pradukcii'
Dovidnyk gotovoi' produkcii'	Kod produkcii'	Nazva produkcii'
Zbut	Lichyl'nyk
Pokupci	Kod pokupcja	Juredychna nazva

Етап 1.6. Створення  діаграми “сутність-зв’язок”.

На цьому етапі створюємо  діаграма “сутність-зв’язок” (ER-діаграма), що містить концептуальне відображення представлення користувача про  предметну область додатку.

Ця ER-діаграма і підготовлена на етапі 1 документація (в сукупності) представляють собою локальну концептуальну модель даних для користувача АРМу.

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

Обговоривши створену локальну концептуальну модель бази даних із заступником начальника виробництва фриз ТОВ «Вінісін», приходимо до висновку, що запропонований проект вірно відображає представлення користувача АРМу про роботу підприємства.

2.2 Логічне  проектування бази даних (для  реляційної моделі)

2.2.1 Побудова  та перевірка створеної локальної  концептуальної моделі даних

Даний етап включає наступне:

• Етап 2.1. Перетворення локальної концептуальної моделі даних  в локальну логічну модель.
• Етап 2.2. Визначення набору відношень, виходячи із структури локальної логічної моделі даних.
• Етап 2.3. Перевірка моделі за допомогою правил нормалізації.
• Етап 2.4. Перевірка моделі у відношенні транзакцій користувачів.
• Етап 2.5. Створення остаточного варіанту діаграми “сутність-зв’язок”.
• Етап 2.6. Визначення вимог підтримки цілісності даних.
• Етап 2.7. Обговорення розробленої локальної логічної моделі даних з кінцевим користувачем.

Етап 2.1. Перетворення локальної концептуальної моделі даних  в локальну логічну модель

Перевіривши зв’язки  між сутностями, ми переконалися, що вони складені вірно. Усі таблиці бази даних з’єднані зв’язком один до багатьох. Зв’язків багато до багатьох не існує.

Оскільки, всі зв’язки  складено вірно, то локальна логічна  модель даних, під час її реалізації в середовищі Microsoft Office Access не викличе  ніяких ускладнень.

Етап 2.2. Визначення набору відношень, виходячи із структури локальної логічної моделі даних

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

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

Postachal'nyky syrovyny (Kod postachal'nyka, Juredychna nazva, Krai'na,Region , Adresa, Bankyvs'kyj rahunok).

Syrovyna (Kod syrovyny, Kod postachal'nyka, Poroda derevyny, Nazva, Dovzhyna, ShyrynaTovshhyna, Sort, Odynyci vymir, Cina za odynycju).

Vyrobnychyj zhurnal (Lichyl'nyk, Pochatok zminy, Kinec' zminy,Kod syrovyny, Kod pracivnyka, Kod produkcii'Kil'kist' syrovyny, Odynyci vymir, Kil'kist' produkcii', Odynyci vymir(prod))

Personal (Kod pracivnyka, Prizvyshhe, Im'ja,Pobat'kovi, Stat', Profesija abo posadaRozrjad, Kod sluzhby)

Sluzhby (Kod sluzhby, Nazva, Funkcii')

Oblik robochogo chasu (Kod pracivnyka, Sichen', Ljutyj ,Berezen', Kviten', Traven'Cherven', Lypen', Serpen', Veresen'Zhovten', Lystopad, Gruden', Zagal'na kil'kist')

Dop materialy(Kod dop materialu, Nazva, Odynyci vymir,Cina za odynycju, Kod  postachal'nyka)

Gotova produkcija na skladi (Lichyl'nyk, Kod pradukcii', Kil'kist',Zagal'na vartist')

Dovidnyk gotovoi' produkcii'(Kod produkcii', Kolekcija, Nazva produkcii',Typ dyzajnu, Kil'kist' polos, DovzhynaShyryna, Tovshhyna, Fazka, Dodatkove zahysne pokryttjaVariacija kol'oru pid dijei' UF-promeniv, Zmina vidtinku pid dijei' UF-promeniv, Tverdist' dereveny, Koeficijent tverdosti, Cina, grn/m2)

Zbut (Lichyl'nyk, Kod produkcii', Kod pokupcja,Kil'kist', Vartist', PDVData realizacii')

Pokupci (Kod pokupcja, Juredychna nazva, Krai'na,Region , Adresa)

Етап 2.3. Перевірка  моделі за допомогою правил нормалізації

Нормалізація схеми  бази даних - покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.

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

Атомарність: кожен атрибут  повинен мати лише одне значення, а  не множину значень.

Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа. При цьому схема бази даних повинна відповідати вимогам першої нормальної форми. Дані, що повторно з'являються в декількох колонках виносяться в окремі таблиці.

Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці  залежали винятково від основного  ключа:

При цьому схема бази даних повинна відповідати всім вимогам другої нормальної форми.

Будь-яке поле, що залежить від основного ключа та від  будь-якого іншого поля, має виноситись в окрему таблицю.

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

Четверта нормальна  форма (4НФ, 4NF) вимагає, аби в схемі  баз даних не було нетривіальних  багатозначних залежностей множин атрибутів від будь чого, окрім  надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді, і тільки тоді, коли вона знаходиться в НФБК, та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних — багатозначні залежності.

П'ята нормальна форма (5НФ, 5NF, PJ/NF) вимагає, аби не було не тривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця знаходиться в п'ятій нормальній формі тоді і тільки тоді, коли вона знаходиться в 4НФ та кожна залежність об'єднання зумовлена її ключами-кандидатами.

Проаналізувавши функціональні  залежності між цими відношенням  ми переконалися, що кожне з них  знаходиться як мінімум в нормальній формі Бойса-Кодда.

Етап 2.4. Перевірка  моделі у відношенні транзакцій користувачів

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

Етап 2.5. Створення  остаточного варіанту діаграми «сутність-зв’язок»

Створюємо остаточний варіант діаграми «сутність-зв’язок» (див. Додаток Б1)

Етап 2.6. Визначення вимог підтримки цілісності даних

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

1. Атрибут первинного ключа не може мати пустого значення;
2. Зв’язки між сутностями моделюються шляхом розміщення у дочірнє відношення копії первинного ключа батьківського відношення;
3. Вимоги даного підприємства визначаються певними обмеженнями, встановленими у відношенні виконання різноманітних операцій.

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

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

2.2.2 Створення та перевірка глобальної логічної моделі даних

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

2.3 Фізичне  проектування бази даних (із використанням реляційної СУБД

2.3.1 Перенесення  глобальної логічної моделі даних  в середовище цільової СУБД

На основі створеної  глобальної логічної моделі даних будуємо  базову функціональну схему реляційної бази даних (див. Додаток Б2) та здійснюємо проектування таблиць бази даних в середовищі Microsoft Office Access. Підготовлений проект набору таблиць бази даних описаний у додатку Б3.

2.3.2 Проектування  фізичного представлення бази  даних

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

Етап 5.1. Аналіз транзакцій.

Етап 5.2. Вибір файлової структури.

Етап 5.3. Визначення вимог  до дискової пам’яті.

Етап 5.1. Аналіз транзакцій

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

• Очікувана частота транзакцій.
• Відношення та атрибути, до яких потрібно мати доступ при виконанні транзакції, а також тип цього доступу (вибірка, вставка, обновлення та видалення).
• Атрибути, що використовуються хоча б в одному з предикатів.
• Атрибути, які при виконанні запитів будуть використовуватись для з’єднання двох або більше відношень.
• Обмеження, що встановлюються на час виконання транзакцій.

Проаналізувавши транзакції, які будуть виконуватися у базі даних, робимо висновок, що більшість транзакцій потребують одержання доступу до таблиці Personal, Dovidnyk gotovoi' produkcii'.