Міністерство освіти і науки України
Національний технічний університет
«Дніпровська політехніка»
Інститут електроенергетики
Факультет інформаційних технологій
Кафедра програмного забезпечення комп’ютерних систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
курсової роботи
з дисципліни: Організація баз даних та знань
студента
Єршова Григорія Антоновича
академічної групи 121-17-1
спеціальності
121 Інженерія програмного забезпечення
на тему
База даних «Автоматизація роботи відділу кадрів»
для підприємства
Керівник
Оцінка за шкалою
Прізвище, ініціали
рейтинговою
роботи: ст. викл. Мєшков В.І.
ас. О.С.
Дніпро
2019
інституційною
Підпис
Варіант 6
Розробіть
підприємства.
базу
даних
для
автоматизації
роботи
відділу
кадрів
У режимі поточної обробки система повинна реалізовувати функції:
− обробку даних по руху кадрів: прийом, звільнення, переміщення;
− отримання статистичної звітної інформації по звільненим і працюючим в
різних відділах;
− отримання довідкової інформації за даними, що містяться в особистій
картотеці;
− ведення табельного обліку по відсутнім на місцях.
2
ВСТУП
Об'єктом дослідження є підприємство, яке відповідає за підбір кадрів і
оформленням їх на роботу.
Основна ціль системи обробки даних в курсовому проекті полягає у
підвищенні ефективності роботи підприємства, обробку даних по руху кадрів,
отримання статистичної звітної інформації по звільненим і працюючим в різних
відділах, отримання довідкової інформації за даними, що містяться в особистій
картотеці, ведення табельного обліку по відсутнім на місцях. Важливим
аспектом бази даних є надання змоги відбирати з великого об’єму даних
необхідну інформацію, яку, у свою чергу, можливо відобразити у формі різних
видів звітів, що дозволяє більш наглядно подивитися інформацію та оцінити
загальну роботу підприємства.
У процесі роботи проводилось дослідження предметної області з метою
виявлення найбільш значущих сутностей та їх атрибутів, розробка запитів,
формування форм та звітів.
В якості предметної області розроблюваної бази даних було вибрано
підприємство, яке зацікавлене в автоматизації своєї діяльності, тому база даних
має забезпечувати:
 вакантні посади;
 видача даних по звільненим і працюючим в різних відділах (назва
відділа, кількість звільнених, назва відкритої посади, їх обов’язки,
заробітна плата);
 довідкової інформації за даними, що містяться в особистій картотеці;
Керівники, та самі працівники отримують вхідну базу даних від
працівників відділу кадрів, які наповнюють її та обслуговують. Вони ж і мають
доступ до даних, робота з якими передбачена на їхньому конкретному робочому
місці, а сам керівник, щоб бачити, працівники яких посад уже є, а які терміново
потрібні.
3
Надане технічне завдання від замовника дає змогу зрозуміти коло задач і
вимоги, яких в курсовій роботі необхідно дотримуватися. Перш за все, був
наданий перелік вхідних даних, з якими працює замовник: інформації по
звільненим і працюючим в різних відділах. Перелік вихідних даних, потрібних
замовникові для управління структурою свого підприємства, включав до себе
ведення табельного обліку по відсутнім на місцях, отримання довідкової
інформації за даними, що містяться в особистій картотеці.
4
Обстеження предметної області, вибір засобів розробки
Областю застосування проектованої бази даних є відділ кадрів. Ця база
даних була вироблена за для облегшення роботи працівників відділу, ця база дає
можливість відстежувати: дійсні вакантні місця; працівників, які вже були раніш
звільнені; тих працівників, які були підвищені у посаді. Якщо ми оглянимо тип
зберігання інформації в таких місцях, то побачимо, що в відділі все зберігається
у паперовому виді, і якщо виникне потреба знайти перелік всіх працівників, які
колись працювали на підприємстві або на якійсь конкретній посаді. Це займе
купу часу, тим більш, якщо це якась крупна компанія. Завдяки цієї бази даних
швидкість підвищиться до декількох секунд, та пари кліков.
В якості вхідних даних потрібно знати:
 Особисті дані працівника
1. Паспорт
2. Банківська картка
 Можливі посади
 Можливі види наказа
 Дата проведення наказа
В якості вихідних даних:
 Готовий наказ
5
Концептуальне проектування
В даному розділі розглядається й формується перелік атрибутів, що
описують, ідентифікують або моделюють властивості сутностей виділяються
атрибути і атрибути-ознаки для заданої предметної області. Після закінчення
даного етапу отримуємо концептуальну модель, інваріантну до структури бази
даних.
Відповідно до предметної області були створені такі сутності:
«Наказ» - зберігається повна інформація про наказ.
«Працівники» - зберігається інформація про працівников, які вже
працюють, працювали або ще тільки подали свої документи аби їй взяли на
роботу;
«Види посад» - зберігається інформація про існуючі посади на
предприємстві.
«Види наказу» - зберігається інформація про існуючі накази.
«Банківська картка» - зберігається інформація про платіжну картку
працівника.
«Паспорт» - зберігається особиста інформація про людину.
«Прописка» - зберігається інформація про місто проживання людини.
Для кожного суб'єкта визначаються атрибути і виділяються з них, ті, які
братимуть участь у забезпеченні зв'язків, зазначених на діаграмі «сутністьзв'язок».
В результаті дослідження предметної області були отримані наступні
атрибути:
1. Таблиця «Наказ» містить:
- Код наказа – унікальний код наказа;
- Код виду наказа – зовнішній ключ таблиці «Вид наказа»;
- Код працівника - зовнішній ключ таблиці «Працівники»;
- Код посади - зовнішній ключ таблиці «Посада»;
- Дата;
2. Таблиця «Посада» містить:
- Код посади - унікальний код посади;
- Назва посади;
6
3. Таблиця «Вид наказа» містить:
- Код виду наказа – унікальний код виду наказа;
- Назва наказу;
4. Таблиця «Працівники» містить:
- Код працівника – унікальний код працівника;
- Ім’я
- По батькове
- Фамілія
- Код карти банка – зовнішній ключ таблиці «Карти»;
- Код паспорта – зовнішній ключ таблиці «Паспорт»;
- Контактний телефон;
- Эл. Пошта;
5. Таблиця «Карти» містить:
- Код карти – унікальний код карти;
- Номер карти
- Банк
6. Таблиця «Паспорт» містить:
- Код паспорта – унікальний код паспорта;
- Серія паспорта;
- № паспорта;
- Дата народження;
- Місто народження;
- Пол;
- Місто видачи паспорта;
- Дата видачи паспорта;
- Код прописки – зовнішній ключ таблиці «Прописка»;
7. Таблиця «Прописка» містить:
- Код прописки – унікальний код прописки;
- Назва району;
- Назва вулиці;
- Номер будинку;
- Номер корпусу;
- Номер квартири.
Первинний ключ - це атрибут, який однозначно ідентифікує екземпляр
сутності.
Первинними ключами є: Код наказа, Код посади, Код виду наказа, Код
працівника, Код карти, Код паспорта, Код прописки.
Зовнішнім ключем називають посилання полів однієї таблиці на однотипні
поля іншої таблиці. Так, наприклад, для сутності «Наказ» зовнішнім ключем
буде: Код виду наказа, Код працівника, Код посади.
7
Зв'язок - асоціювання двох або більше сутностей. Якби призначенням бази
даних було тільки збереження окремих, не пов'язаних між собою даних, то її
структура могла б бути дуже простою. Проте одна з основних вимог до
організації бази даних - це забезпечення можливості відшукання одних
сутностей за значеннями інших, для чого необхідно встановити між ними певні
зв'язки.
Зв'язок між об'єктом і його властивістю може бути різною. Об'єкт може
мати тільки одним значенням якогось властивості. Наприклад, паспорт видається
лише одній конкретній людині. Для інших властивостей можливе існування
одночасно кількох значень у одного об'єкта. Так, наприклад, один й той самий
працівник може працювати одночасно на двох посадах.
Визначаються зв'язки та їх типи між суб'єктами технологічного процесу.
Створюється діаграма «сутність - зв'язок» і діаграма зв'язків між відносинами в
БД.
Паспортні
данні
Вид наказу
Карти
Працівники
Обов’язки
Оформлення
Дата
виконання
Наказ
Рисунок 1: Схема сутність зв’язок
8
Код
Логічне проектування
Логічне проектування – перетворення вимог до даних в структури даних.
На виході отримуємо СУБД-орієнтовану структуру бази даних і специфікації
прикладних програм. Логічне проектування бази даних - це процес створення
моделі використовуваної на підприємстві інформації на основі обраної моделі
організації даних, але без урахування типу цільової СУБД і інших фізичних
аспектів реалізації.
Другий
етап
проектування
бази
даних
називається
логічним
проектуванням бази даних. Його мета полягає в створенні логічної моделі даних
для досліджуваної частини підприємства. Концептуальна модель даних,
створена на попередньому етапі, уточнюється і перетворюється в логічну модель
даних. Логічна модель даних враховує особливості обраної моделі організації
даних в цільової СУБД (в даній роботі - реляційна модель).
Якщо концептуальна модель даних не залежить від будь-яких фізичних
аспектів реалізації, то логічна модель даних створюється на основі обраної
моделі організації даних цільової СУБД. На цьому етапі ігноруються всі інші
характеристики обраної СУБД, наприклад, будь-які особливості фізичної
організації її структур зберігання даних і побудови індексів.
Створена логічна модель даних є джерелом інформації для етапу фізичного
проектування і забезпечує розробника фізичної бази даних засобами пошуку
компромісів, необхідних для досягнення поставлених цілей, що дуже важливо
для ефективного проектування. Логічна модель даних відіграє також важливу
роль на етапі експлуатації і супроводу вже готової системи. При правильно
організованому супроводі підтримувана в актуальному стані модель даних
дозволяє точно і наочно уявити будь-які вносяться в базу даних зміни, а також
оцінити їх вплив на прикладні програми та використання даних, вже наявних в
базі.
Проектування реляційної бази даних проходить в тому ж порядку, що і
проектування БД інших моделей даних, але має свої особливості.
9
Проектування схеми БД має вирішувати завдання мінімізації дублювання
даних і спрощення процедур їх обробки та оновлення. При неправильно
спроектованої схемою БД можуть виникнути аномалії модифікації даних, які
обумовлені відсутністю коштів явного уявлення типів множинних зв'язків між
об'єктами ПО і нерозвиненістю засобів опису обмежень цілісності на рівні
моделі даних.
Для вирішення подібних проблем проводиться нормалізація відносин.
Нормалізація схеми відносини виконується шляхом декомпозиції схеми, яка
задана в таблиці 1.
10
Посада
Наказ
№
п.п.
1.
2.
3.
4.
5.
Атрибуты
Код
Код наказа
Код працівника
Код посади
З якої дати
№
п.п.
Ключ
Перв.
6.
Внеш.
7.
Атрибути
Код
Назва посади
Внеш.
Вид наказа
Працівники
1.
2.
1.
2.
3.
4.
5.
6.
7.
8.
Атрибути
Код
Ім’я
По батькове
Фамілія
Код карти банка
Код паспорта
Контактний
телефон
Эл. пошта
Перв.
1.
Код
2.
Серія паспорта
3.
№ паспорта
4.
Дата народження
5.
Місто народження
6.
Пол
7.
Місто видачи
паспорта
Дата видачи
паспорта
Код прописки
8.
9.
Код
Назва наказу
Ключ
Перв.
Карта
№
п.п.
Внеш.
1.
Внеш.
2.
3.
Атрибути
Код
Номер карти
Банк
Ключ
Перв.
Прописка
№
п.п.
Атрибути
Атрибути
Ключ
Паспорт
№
п.п.
Перв.
Внеш.
№
п.п.
№
п.п.
Ключ
1.
Ключ
2.
Перв.
3.
4.
5.
6.
Внеш.
Таблиця 1: Зв’язків
11
Атрибути
Код
Назва району
Назва вулиці
Номер будинку
Номер корпусу
Номер квартири
Ключ
Перв.
Класифікація зв’язків
Наступний етап проектування – виділення зв’язків між сутностями:
 Видання – Наказ. У рамках одного працівника, якого керівник може
прийняти на роботу, підвищити або зовсім звільнити, але як мінімум щось
одне з цього. Тому тип зв’язку – 1:М. Зв'язок ідентифікуюча, тому що
працівник без наказу керівника існувати не може.
 Працівник – складові. До складу одного працівника може включатися
багато різних складових; один й той же тип комплектуючого може
включатися до складу різних працівників. Тому тип зв’язку – 1:М.
 Складові - Ім’я, По батькове, Фамілія, Карта банка, Паспорта, Контактний
телефон, Эл. пошта. Тип зв’язку – 1:М.
 Види наказів. Тип зв’язку 1:М.
 Види посад. Тип зв’язку 1:М.
Реляційна модель БД
Рисунок 2: Реляційна модель БД
12
Вибір ключів
В мене:
 Атрибут «Код наказа, Код працівника, Код посади» - це зовнішні, а
«Код» - це первісний ключ таблички «Наказ»;
 Атрибут «Код» - це первісний ключ таблички «Посада»;
 Атрибут «Код» - це первісний ключ таблички «Вид наказа»;
 Атрибут «Код карти банка, Код паспорта» - це зовнішні, а «Код» це первісний ключ таблички «Працівники»;
 Атрибут «Код» - це первісний ключ таблички «Карти»;
 Атрибут «Код прописки» - це зовнішні, а «Код» - це первісний ключ
таблички «Паспорт»;
 Атрибут «Код» - це первісний ключ таблички «Прописк»;
Також:
 Зовнішні ключі таблички «Наказ»:
1. «Код наказа» - залежить від первісного ключа таблички
«Наказ»;
2. «Код працівника» - залежить від первісного ключа таблички
«Працівник»;
3. «Код посади» - залежить від первісного ключа таблички
«Посада»;
 Зовнішні ключі таблички «Працівник»:
1. «Код карти» - залежить від первісного ключа таблички
«Карти»;
2. «Код паспорту» - залежить від первісного ключа таблички
«Паспорт»;
 Зовнішній ключ «Код прописки» таблички «Паспорт» - залежить від
первісного ключа таблички «Прописка».
13
Розробка фізичної моделі БД
У цьому розділі наводиться склад таблиць БД. Фізичне проектування бази
даних – процес підготовки опису реалізації бази даних на вторинних
запам'ятовуючих пристроях; на цьому етапі розглядаються основні відносини,
організація файлів і індексів, призначених для забезпечення ефективного
доступу до даних, а також всі пов'язані з цим обмеження цілісності і засоби
захисту.
Фізичне проектування є третім і останнім етапом створення проекту бази
даних, коли приймаються рішення про способи реалізації розроблюваної бази
даних. Під час попереднього етапу проектування була визначена логічна
структура бази даних (яка описує відносини і обмеження в даній прикладній
області). Хоча ця структура не залежить від конкретної цільової СУБД, вона
створюється з урахуванням обраної моделі зберігання даних, наприклад
реляційної, мережевої або ієрархічної (в цій роботі – реляційної). Між логічним
і фізичним проектуванням існує постійний зворотний зв'язок, так як рішення, що
приймаються
на
етапі
фізичного
проектування
з
метою
підвищення
продуктивності системи, здатні вплинути на структуру логічної моделі даних.
Як правило, основною метою фізичного проектування бази даних є опис
способу фізичної реалізації логічного проекту бази даних.
У разі реляційної моделі даних під цим мається на увазі наступне:
-
створення набору реляційних таблиць і обмежень для них на основі
інформації, представленої в глобальній логічної моделі даних;
-
визначення конкретних структур зберігання даних і методів доступу
до них, що забезпечують оптимальну продуктивність СУБД;
-
розробка засобів захисту створюваної системи.
Фізичне проектування баз даних складається з декількох етапів.
Концептуальне та логічне проектування охоплює перші з них, а фізичне
проектування – інші. Етап, наступний відразу після логічного проектування,
стадії фізичного проектування включає розробку основних відносин і реалізацію
обмежень предметної області з використанням доступних функціональних
14
коштів цільової СУБД. На цьому етапі має бути також прийнято рішення щодо
вибору способів отримання похідних даних, які включені в модель даних.
Наступний етап включає вибір файлової організації та індексів для
основних відносин. Як правило, СУБД для персональних комп'ютерів мають
фіксовану структуру зовнішньої пам'яті, а інші СУБД надають кілька
альтернативних варіантів файлової організації для зберігання даних. З точки зору
користувача організація внутрішньої структури зберігання відносин повинна
бути абсолютно прозорою - користувач повинен мати можливість отримувати
доступ до будь-якого відношенню і до окремих його рядках без урахування
способу зберігання даних. Це означає, що СУБД повинна забезпечувати повну
незалежність фізичного зберігання даних від їх логічної організації. Тільки в
цьому випадку внесення змін до фізичну організацію бази даних не матиме
ніякого впливу на роботу користувачів. Відповідність між логічною моделлю
даних і фізичною моделлю даних визначається внутрішньою схемою бази даних.
На наступному кроці необхідно прийняти рішення про те, як має бути
реалізовано кожне призначене для користувача подання. Далі здійснюється
проектування засобів захисту, необхідних для запобігання несанкціонованого
доступу до даних, включаючи управління доступом до основних відносин.
На наступному етапі аналізується також необхідність зниження рівня
вимог нормалізації даних в логічної моделі, що може сприяти підвищенню
загальної продуктивності системи. Однак ці дії слід робити тільки в разі реальної
необхідності, оскільки введення в базу даних надмірності неминуче викличе
появу проблем з підтриманням цілісності даних.
Специфікація таблиці Order (Наказ):
№ Озаглавлення
Ім’я поля
Тип
Довжина
1. Код
Code
integer
2. Код наказа
OrderCod
integer
3. Код працівника
EmployeeCod
integer
4. Код посади
PostCod
integer
5. З якої дати
Date
date
15
Ключ
P
F
F
F
Специфікація таблиці Post (Посада):
Ім’я поля
Тип
Довжина
Code
integer
NameOfPost
char
30
Ключ
P
Специфікація таблиці TypeOfOrder (Вид наказа):
№ Озаглавлення
Ім’я поля
Тип
Довжина
1. Код
Code
integer
2. Назва наказу
NameOfOrder
char
30
Ключ
P
№ Озаглавлення
1. Код
2. Назва посади
8.
Специфікація таблиці Employees (Працівники):
Озаглавлення
Ім’я поля
Тип
Довжина
Код
Code
integer
Ім’я
Name
char
30
По батькове
Patronymic
char
30
Фамілія
FamyliName
char
30
Код карти банка
CardCode
integer
Код паспорта
PassportCode
integer
Контактний
TelephoneNumber char
телефон
Эл. пошта
Email
char
30
№
1.
2.
3.
Озаглавлення
Код
Номер карти
Банк
Специфікація таблиці Card (Карти):
Ім’я поля
Тип
Довжина
Code
integer
CardNomber
integer
Bank
char
30
№
1.
2.
3.
4.
5.
6.
7.
8.
9.
Специфікація таблиці PassportData (Паспорт):
Озаглавлення
Ім’я поля
Тип
Довжина Ключ
Код
Code
integer
P
Серія паспорта
Series
char
2
№ паспорта
Number
integer
Дата народження
Birthday
date
Місто народження
BirthPlace
char
30
Пол
Sex
Enum(M,Ж)
Місто видачи паспорта IssuePlace
char
100
Дата видачи паспорта IssueDate
date
Код прописки
NoteCode
integer
F
№
1.
2.
3.
4.
5.
6.
7.
16
Ключ
P
F
F
Ключ
P
№
1.
2.
3.
4.
5.
6.
Специфікація таблиці Note (Прописка):
Озаглавлення
Ім’я поля
Тип
Довжина
Код
Code
integer
Назва району
NameOfDistrict
char
30
Назва вулиці
NameOfStreet
char
30
Номер будинку
NomberOfHouse integer
Номер корпусу
NomberOfCorpus integer
Номер квартири
NomberOfFlat
integer
17
Ключ
P
Розробка механізмів захисту даних від несанкціонованого доступу
Засоби захисту БД в різних СУБД дещо відрізняються один від одного. На
основі аналізу сучасних СУБД Borland і Microsoft можна стверджувати, що
засоби захисту БД умовно діляться на дві групи, основні і додаткові.
До основних засобів захисту інформації можна віднести наступні засоби:
-
парольний захист;
-
шифрування даних і програм;
-
встановлення прав доступу до об’єкта БД;
-
захист прав і запис таблиць БД;
Парольний захист представляє простий і ефективний спосіб захисту БД від
несанкціонованого доступу. Паролі встановлюються кінцевими користувачами
або адміністратором БД. Облік і зберігання паролів проводиться самою СУБД.
Зазвичай паролі зберігаються в певних системних файлах СУБД. Парольний
захист є досить слабким засобом, особливо якщо пароль не шифрується.
Шифрування - це перетворення тексту, що читається в нечитаний текст, за
допомогою деякого алгоритму; застосовується для захисту вразливих даних.
Процес дешифрування відновлює дані в початковий стан. З метою контролю
використання основних ресурсів СУБД в багатьох системах є засоби
встановлення прав доступу до об'єктів БД. Права доступу визначають можливі
дії над об'єктами.
По відношенню до таблиць можуть передбачатися такі права доступу:
-
перегляд (читання) даних;
-
зміна (редагування) даних;
-
додавання нових записів;
-
додавання і видалення даних;
-
зміна структури таблиці.
Захист даних в полях таблиць передбачає такі рівні прав доступу:
-
повна заборона доступу;
-
тільки читання;
18
-
дозвіл всіх операцій (перегляд, введення нових значень, видалення і
зміна).
По відношенню до форм можуть передбачатися дві основні операції:
-
виклик для роботи і проектування (режим Конструктора). Заборона
виклику Конструктора.
-
захист окремих елементів. Наприклад, деякі поля вихідної таблиці
взагалі можуть бути відсутніми або приховані від користувача, а деякі поля доступні для перегляду.
До додаткових засобів захисту БД можна віднести такі, які не можна прямо
віднести до засобів захисту, але які безпосередньо впливають на безпеку даних.
Їх складають такі кошти:
-
вбудовані засоби контролю значень даних відповідно до типів;
-
підвищення достовірності даних, що вводяться;
-
забезпечення цілісності зв'язків таблиць.
Рішення прикладної задачі, як правило, вимагає вибору інформації з
декількох таблиць. Таблиці в базі даних можуть буди пов’язані. Функції
підтримки логічної цілісності пов’язаних таблиць бере на себе СУБД. Якщо
СУБД не реалізує ці функції, то відповідальність за конкретність зв’язків
покладається на дотаток.
Співробітники приймальної комісії мають такі права доступу:
-
перегляд даних;
-
редагування даних;
-
додавання нових записів.
Співробітники, які не мають пароля або користувачі, які не являються
співробітниками приймальної комісії, не мають доступу до бази даних.
Приклад облікового запису працівника приймальної комісії:
19
Рисунок 3
20
Вимоги до технічного забезпечення
Технічне забезпечення системи повинно максимально і найбільш
ефективним чином використовувати існуючі технічні засоби.
До складу комплексу повинні входити такі технічні засоби:
-
сервер БД;
-
персональні комп'ютери (ПК) користувачів.
Мінімальні
вимоги
до
характеристик
компонентів
забезпечення, при яких значення часових параметрів системи:
для сервера БД:
-
процесор - 2 х IntelXeon3 ГГц;
-
обсяг оперативної пам'яті - 16 Гб;
-
дискова підсистема - 4 х 146 Гб;
-
пристрій читання компакт-дисків (DVD-ROM);
-
мережевий адаптер - 100 Мбіт / с.
для ПК користувача:
-
процесор - IntelPentium1.5 ГГц;
-
обсяг оперативної пам'яті - 256 Мб;
-
дискова пам'ять - 40 Гб;
-
мережевий адаптер - 100 Мбіт / с.
Програмне забезпечення:
-
операційна система WINDOWS 2000 / XР і вище;
-
платформа Nеt Framеwork 2.0 і вище;
-
My SQL Workbench 8.0;
-
Microsoft SQL Server.
21
технічного
Інструкція з використання БД
Для установки програмного продукту не потрібно особливих зусиль. Для
цього потрібно скопіювати проект на жорсткий диск, після чого відкрити його в
середовищі - My SQL Workbench 8.0 і відкрити файл. Для початку роботи з базою
даних потрібно ввести ім’я користувача і пароль, після чого можна уде почати
роботу з базою даних в залежності від прав доступу.
Рисунок 4
Рисунок 5
22
У кожному діалоговому вікні, наданому для модифікації БД, є кнопки
навігації, додавання, збереження видалення для виконання однойменних дій.
Інтерфейс доброзичливий і простий.
23
Висновок
Метою створення будь-якої БД є спрощення використання великих
масивів інформації. БД дозволяють збирати, зберігати, оновлювати і виводити
інформацію в зрозумілій користувачеві формі.
В ході роботи даної курсової роботи була розроблена база даних для
приймальної комісії ВНЗ, яка значно спрощує роботу з даними і багато в чому
економить час співробітників. Створена БД може бути вдосконалена і доповнена
новими даними, в неї можуть бути введені додаткові кошти формування даних.
Наприклад, можуть значно допомогти кошти VBA і мови SQL.
Таким чином, можна говорити про можливість створення більш потужної
системи, заснованої на використанні засобів самодіагностики, які будуть в
автоматичному режимі прибирати надмірність даних і виробляти операції
пов'язані з формуванням правильної структури даних.
24
Додаток
Створення БД:
-- MySQL Workbench Synchronization
-- Generated: 2019-05-23 13:04
-- Model: New Model
-- Version: 1.0
-- Project: Name of the project
-- Author: User
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS,
UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO
_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGIN
E_SUBSTITUTION';
ALTER TABLE `mydb`.`PassportData`
DROP FOREIGN KEY `Note`;
ALTER TABLE `mydb`.`Employees`
DROP FOREIGN KEY `Card`,
DROP FOREIGN KEY `Passport`;
ALTER TABLE `mydb`.`Order`
DROP FOREIGN KEY `Employee`,
DROP FOREIGN KEY `Post`;
ALTER TABLE `mydb`.`Note`
25
CHANGE COLUMN `NameOfDistrict` `NameOfDistrict` CHAR(30)
CHARACTER SET 'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ,
CHANGE COLUMN `NameOfStreet` `NameOfStreet` CHAR(30) CHARACTER
SET 'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`PassportData`
CHANGE COLUMN `Birthday` `Birthday` DATE NOT NULL ,
CHANGE COLUMN `BirthPlace` `BirthPlace` CHAR(30) CHARACTER SET
'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ,
CHANGE COLUMN `Sex` `Sex` ENUM('М', 'Ж') CHARACTER SET 'cp1251'
COLLATE 'cp1251_general_ci' NOT NULL ,
CHANGE COLUMN `IssuePlace` `IssuePlace` CHAR(100) CHARACTER SET
'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`Card`
CHANGE COLUMN `CardNomber` `CardNomber` INT(11) NOT NULL ,
CHANGE COLUMN `Bank` `Bank` CHAR(30) CHARACTER SET 'cp1251'
COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`Employees`
CHANGE COLUMN `Code` `Code` INT(11) NOT NULL AUTO_INCREMENT ,
CHANGE COLUMN `Name` `Name` CHAR(30) CHARACTER SET 'cp1251'
COLLATE 'cp1251_general_ci' NOT NULL ,
CHANGE COLUMN `Patronymic` `Patronymic` CHAR(30) CHARACTER SET
'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ,
CHANGE COLUMN `FamyliName` `FamyliName` CHAR(30) CHARACTER SET
'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`TypeOfOrder`
26
CHANGE COLUMN `NameOfOrder` `NameOfOrder` CHAR(30) CHARACTER
SET 'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`Post`
CHANGE COLUMN `NameOfPost` `NameOfPost` CHAR(30) CHARACTER SET
'cp1251' COLLATE 'cp1251_general_ci' NOT NULL ;
ALTER TABLE `mydb`.`PassportData`
ADD CONSTRAINT `Note`
FOREIGN KEY (`NoteCode`)
REFERENCES `mydb`.`Note` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `mydb`.`Employees`
ADD CONSTRAINT `Card`
FOREIGN KEY (`CardCode`)
REFERENCES `mydb`.`Card` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
ADD CONSTRAINT `Passport`
FOREIGN KEY (`PassportCode`)
REFERENCES `mydb`.`PassportData` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `mydb`.`Order`
DROP FOREIGN KEY `TypeOfOrder`;
ALTER TABLE `mydb`.`Order` ADD CONSTRAINT `TypeOfOrder`
27
FOREIGN KEY (`OrderCod`)
REFERENCES `mydb`.`TypeOfOrder` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
ADD CONSTRAINT `Employee`
FOREIGN KEY (`EmployeeCod`)
REFERENCES `mydb`.`Employees` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
ADD CONSTRAINT `Post`
FOREIGN KEY (`PostCod`)
REFERENCES `mydb`.`Post` (`Code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
28
ERR Diagramm:
Вивід заповнених табличок:
SELECT * FROM mydb.post;
SELECT * FROM mydb.note;
SELECT * FROM mydb.card;
29
SELECT * FROM mydb.typeoforder;
SELECT * FROM mydb.passportdata;
SELECT * FROM mydb.employees;
30
SELECT * FROM mydb.`order`;
Простіші запити до бази даних:
SELECT * FROM mydb.passportdata where BirthPlace = "Днепр";
SELECT * FROM mydb.passportdata where BirthPlace = "Днепр" and IssueDate > "201702-1" and IssueDate < "2017-02-28";
SELECT * FROM mydb.note where NameOfStreet = "Тополь 2";
SELECT * FROM mydb.note where NameOfStreet = "Тополь 2" and NomberOfFlat = 44;
SELECT * FROM mydb.passportdata where Sex = "М";
31
SELECT * FROM mydb.passportdata where Sex = "М" and Birthday > "2000-08-1";
Програмне забезпечення до БД:
Переглянемо таблицю «Прописка»:
Додомо до цієї таблиці інформацію:
32
Видалимо цю же інформацію:
Отже все працює.
33