Федеральна державна бюджетна

1 2

Ім'я файлу: БД курсовая.docx
Розширення: docx
Розмір: 912кб.
Дата: 07.05.2022
скачати
Пов'язані файли:
КПС 4+Т150 к.doc
1й розд.docx
Реферат.docx
Цивільне право України. Реферат.doc
Реферат Стаматова Олена 13М.docx
лабораторн101.docx
Chumak.docx
Тисячник_ІТ-02_Курсова.docx
vseosvita_1681109443.docx
Арт терапія стосунків.docx
диплом_Слабченко.docx

Міністерство освіти і науки Російської Федерації

ФЕДЕРАЛЬНА ДЕРЖАВНА БЮДЖЕТНА

ОСВІТНИЙ ЗАКЛАД ВИЩОЇ ОСВІТИ

«ОРЕНБУРСЬКИЙ ДЕРЖАВНИЙ УНІВЕРСИТЕТ»
Факультет математики інформаційних технологій
Кафедра програмного забезпечення та обчислювальної техніки автоматизованих систем
КУРСОВА РОБОТА
з баз даних

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

Пояснювальна записка

ОДУ 09.03.04 ПЗ

Керівник

доцент каф. ПОВТАС

канд. техн . наук

	Д.В.Горбачов
підпис

«____» __________ 20___р.

Студент групи З-19ПІнж(б) РПіС

	М.А.Анненков
підпис

«____» __________ 20___р.

Оренбург 2022

Анотація
Ця робота присвячена темі «розробка та створення бази даних предметної галузі».

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

Описують діаграми IDEF0, IDEF3, DFD, основні принципи проектування бази даних, а також програми Windows Forms .

У роботі наводяться результати роботи програми, наведені вище за діаграму.

Робота містить 37 аркушів, 19 малюнків, 1 додаток, 13 таблиць.

Зміст
Введение……………………...…………………………………… ….... ………………….4

1. Аналіз інформаційних потоків предметної області……………………………...5

1.1. Розробка моделі IDEF0 досліджуваного процесу…………………………… ……. 5

1.2. Розробка моделі DFD автоматизації досліджуваного процесу…………… ……. .8

2. Вибір та обґрунтування технології проектування бази даних…………………...11

3. Технічне проектування…………………………………………………… ……. 13

3.1. Опис об'єктів бази даних та їх взаємозв'язків ……...………………………15

3.2. Інфологічна модель данных……………………………………………… ……. 16

3.3. Обґрунтування СУБД. Даталогічна модель данных………………… ……. ….….18

3.4. Фізична модель данных…………………………………………………… ……. 21

3.5. Розробка запитів на вибірку, зміну, оновлення та видалення даних. 25

3.6. Розробка процедур забезпечення цілісності БД……………… ……. .…………26

4. Інтерфейси взаємодії з БД……………………………………… ……. ……....29

Заключение………………………………………………………………………… ……. .31

Список використаних джерел……………………………………………………32

Додаток А……………………………………………………………………… ……. 33

Додаток Б……………………………………………………………………… ……. .37

Вступ

База даних - представлена в об'єктивній формі сукупність самостійних матеріалів (статей, розрахунків, нормативних актів, судових рішень та інших подібних матеріалів), систематизованих таким чином, щоб ці матеріали могли бути знайдені та оброблені за допомогою електронної обчислювальної машини (ЕОМ).

Microsoft SQL Server – система управління реляційними базами даних (РСУБД), розроблена корпорацією Microsoft . Основна мова запитів - Transact -SQL, створений спільно Microsoft і Sybase . Transact -SQL є реалізацією стандарту ANSI/ISO із структурованої мови запитів (SQL) з розширеннями. Використовується до роботи з базами даних розміром від персональних до великих баз даних масштабу підприємства; конкурує з іншими СУБД у цьому сегменті ринку.

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

1 Вивчення предметної галузі з метою аналізу інформаційних потоків.

2 Побудова діаграм IDEF0, IDEF3, DFD з метою систематизації даних, отриманих у процесі аналізу предметної області.

3 Проектування бази даних засобами SQL Server .

4 Створення графічної програми засобами MS Visual Studio та встановлення зв'язків з базою даних для забезпечення комфортної роботи.
1 Аналіз інформаційних потоків даних

Розробка моделі IDEF 0 досліджуваного процесу.

Для побудови функціональної моделі зазвичай використовується методологія IDEF 0. Дана методологія призначена для представлення функцій системи та вимог аналізу до систем. У IDEF 0 реалізовані ідеї системного аналізу, під якими розуміють дослідження, що беруть початок із загального огляду системи, а потім відбувається її деталізація у вигляді ієрархічної структури з фіксованим числом рівнів. Результатом деталізації є функціональні складові, кожної складової дається повний опис, досліджуються інформаційні потоки і формується структура даних. Ця методологія дозволяє отримати наочне уявлення бізнес-процесів та виявити недоліки системи. У нотації IDEF0 основними елементами діаграм є функціональні блоки та дуги, які представляють відповідно прямокутники та стрілки. Всі дуги та функціональні блоки мають бути названі. Дуги являють собою інформацію, якої блоки потребують або її виробляють. Кожен блок має свій номер, який розміщується зазвичай у нижньому правому куті. У методології IDEF0 функціональний блок, який на верхньому рівні ієрархії представляє систему як єдиний блок (контекстна діаграма), деталізується на іншій діаграмі за допомогою декількох блоків, з'єднаних між собою інтерфейсними дугами. Ці блоки є основними підфункціями єдиного вихідного модуля. Кожен із цих підмодулів може бути декомпозований подібним чином для більш детальної вистави. Кількість рівнів ієрархії не обмежується, процес декомпозиції блоків закінчується тоді, коли кожен із модулів найнижчого рівня декомпозиції може бути реалізований у проектованій системі одним програмним модулем.

Результат застосування методології IDEF0 – функціональна модель, що складається з діаграм, фрагментів тексту та глосарію, що мають посилання один на одного.

Малюнок 1 – Контекстна діаграма методології IDEF 0.

Рисунок 2 – IDEF0 – діаграма першого рівня декомпозиції

Розробка моделі DFD авт оматизації досліджуваного процесу

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

Рисунок 4 – діаграма потоків даних

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

- підприємство (Код, Назва, Коротка назва Адреса, Контактні телефони, електронна адреса);

- Назва вакансії (посада);

- вимоги до претендента: підлога, вік (Верхня межа, Нижня межа), освіта (вища, середня, не має значення тощо), знання певних видів діяльності (вибір з переліку - знання електронного документообігу, певних прикладних програм тощо) .п.), комунікабельність (так, ні);

- обов'язки (вибір із переліку – укладання договорів, розповсюдження агітаційного матеріалу, робота з клієнтами тощо);

- передбачувана оплата (Нижня межа, Верхня межа), одиниці виміру оплати - рублі;

- Оформлення трудової книжки (так, ні);

- Наявність соціального пакета (так, ні);

- Термін початку відкриття вакансії;

- Термін закриття вакансії (вакансія зайнята).

Вибір та обґрунтування технології проектування бази даних

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

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

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

Для проектування складних БД переважно застосовується низхідний підхід. При такому підході робота починається з підготовки моделей даних, що містять кілька високорівневих сутностей та зв'язків. Після цього виробляються низхідні уточнення низькорівневих сутностей, зв'язків та атрибутів, що належать до них.
Східний підхід використовують у концепції методу проектування «сутність-зв'язок». В основі методу лежать три елементи: сутність, атрибут, зв'язок. Робота починається з виявлення сутностей та зв'язків між ними.

Процес побудови баз даних методом «сутність-зв'язок» включає три етапи: концептуальне, логічне і фізичне проектування [1].

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

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

На даному етапі має бути визначена цільова СУБД (реляційна, мережева, ієрархічна або об'єктно-орієнтована), оскільки побудова логічної моделі відбувається з урахуванням обраної моделі організації даних. З допомогою методу нормалізації відбувається перевірка правильності моделі. Нормалізація виключає надмірність даних, яка може призвести до різних аномалій у процесі оновлення даних. Підтримка всіх транзакцій, які необхідні користувачам, також має забезпечуватися логічною моделлю.

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

У цьому роботі застосовується низхідний підхід.

3 Технічне проектування

База даних призначена для підприємства, що займається працевлаштуванням.

Основним завданням бази даних є відстеження фінансової сторони роботи з працевлаштування.

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

У основі фіксується як угода, а й зберігається інформація з відкритих вакансій. Крім того, для автоматичного пошуку варіантів слід вести довідник «Види діяльності».

За змістом завдання до бази даних можливі такі запити:

Яку вакансію отримав здобувач із заданим прізвищем;

Який вид діяльності пропонує роботодавець;

Яку кваліфікацію має претендент;

Які посади включають відкриті вакансії;

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

 Роботодавці;

 Здобувачі;

 Угоди;

 Відкриті вакансії;

 Вид діяльності;

Об'єкт Шукачі пов'язаний з об'єктом Угоди співвідношенням один до багатьох, об'єкт Угоди пов'язаний з об'єктом Відкриті вакансії співвідношенням один до одного, об'єкт Відкриті вакансії пов'язаний з об'єктом Роботодавці співвідношенням багато до одного, об'єкт роботодавці пов'язаний з об'єктом Вид діяльності співвідношенням багато до одного.

Рисунок 5 – Схема БД «З працевлаштування»

3.1 Опис об'єктів БД

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

До неї входять такі об'єкти:

 Види діяльності;

 Відкриті вакансії;

 Роботодавці;

 Угоди;

 Здобувачі.

CREATE TABLE Тип діяльності (

Код вигляд діяльності INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Тип діяльності VARCHAR (20) NOT NULL ,( Код вид діяльності)

); TABLE Шукачі (

Код здобувача INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Код вигляд діяльності INTEGER UNSIGNED NOT NULL,

Прізвище VARCHAR (20) NULL,

Ім'я VARCHAR (20) NULL,

батькові VARCHAR (20) NULL,

Кваліфікація VARCHAR (45) NULL,

Інші дані VARCHAR (255) NULL,

Передбачуваний розмір заробітної плати NUMERIC NULL, KEY (Код здобувача ),Здобувачі _FKIndex1(Код вид діяльності),KEY(Код вид діяльності)Вид діяльності(Код вид діяльності)

ON DELETE NO ACTIONUPDATE NO ACTION

); TABLE Роботодавці (

Код роботодавця INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Код вигляд діяльності INTEGER UNSIGNED NOT NULL,

Назва VARCHAR (45) NULL,

Адреса VARCHAR (45) NULL,

Телефон VARCHAR (20) NULL , KEY (Код роботодавця), Роботодавці_ FKIndex 1(Код вид діяльності),KEY(Код вид діяльності)Вид діяльності(Код вид діяльності)

ON DELETE NO ACTIONUPDATE NO ACTION

); TABLE Відкриті вакансії (

Код вакансії INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Код роботодавця INTEGER UNSIGNED NOT NULL,

Посада VARCHAR (20) NULL , KEY (Код вакансій), Відкриті вакансії_ FKIndex 1(Код роботодавця),

FOREIGN KEY (Код роботодавця)

REFERENCES Роботодавці (Код роботодавця)

ON DELETE NO ACTIONUPDATE NO ACTION

); TABLE Угоди (

Код угоди INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Код вакансії INTEGER UNSIGNED NOT NULL,

Код здобувача INTEGER UNSIGNED NOT NULL,

Комісійні NUMERIC NULL , KEY (Код угоди), Угоди_ FKIndex 1(Код претендента),

INDEX Угоди_ FKIndex 2(Код вакансій),

FOREIGN KEY (Код претендента)

REFERENCES Здобувачі (Код претендента)

ON DELETE NO ACTIONUPDATE NO ACTION, KEY ( Код вакансій ) _ вакансії ( Код вакансії ) DELETE NO ACTIONUPDATE NO ACTION);

3.2 Інфологічна модель БД
Інформаційно-логічна модель предметної області відбиває предметну область як сукупності інформаційних об'єктів та його структурних зв'язків. У цьому проекті інфологічна модель відбиває сукупність об'єктів центру служби зайнятості та його структурних зв'язків.

Рисунок 5 – інфологічна модель БД.
3.3 Обґрунтування СУБД. Даталогічна модель БД
СУБД є комплекс інструментальних засобів, програмних та мовних, що реалізують централізоване управління БД і забезпечують доступ до даних (зміни, додавання, видалення, резервного копіювання тощо), роль яких як єдиного засобу зберігання, обробки та доступу до великих обсягів інформації постійно зростає. Швидкий розвиток потреб застосування БД висуває нові вимоги до СУБД: природні та ефективні уявлення в БД різноманітних відносин між об'єктами предметних областей (наприклад, просторово-часових із забезпеченням візуалізації даних).

В даному курсовому проекті для розробки СУБД застосовується MS SQL Server . Характеристика цієї СУБД представлена таблиці 13.

Таблиця 13 – порівняння СУБД

В даному курсовому проекті для розробки СУБД застосовується MS SQL Server . Характеристика цієї СУБД представлена таблиці 14.

Таблиця 14 - характеристика СУБД

Параметри	СУБД
Назва, версія, фірма виробник	MS SQL Server 2014, Microsoft та Sybase
Підтримувані ОС	UNIX , OS/2 , Windows
Вимоги до апаратного забезпечення	6 Гб вільного простору, Пам'ять: 1 ГБ, швидкодія процесора 1,4 ГГц, процесор x64: AMD Opteron , AMD Athlon 64, Intel Xeon з підтримкою Intel EM64T, Intel Pentium IV з підтримкою EM64T
Напрямок розробки	Проектування БД
Модель, що підтримується	Реляційна
Оптимальний розмір БД	Не важливий
Реалізація прав доступу	Так
Наявність вбудованих засобів створення резервної копії БД та відновлення БД	Є в наявності
Наявність засобів формування звітів із БД	Є в наявності
Можливість створення локальної БД	Так
Технологія створення БД та об'єктів БД	За допомогою засобів програми або програмним способом
Підтримка сервера БД	Так
Підтримка мовних середовищ	Так
Засоби підтримки обмеження цілісності БД	Так
Зручність розробки та адміністрування	У цій СУБД зручно працювати, вона зрозуміла і вимагає від користувача поглиблених навичок.
Підтримка багатопроцесорності	Так
Підтримка експорту та імпорту даних інших форматів	Підтримується
Підтримка роботи у кластері	так
Складність чи простота роботи з СУБД	Простота роботи

Даталогічна модель даних - це опис, створюваний проектувальником за інфологічною моделлю даних мовою опису даних конкретної СУБД.

Рисунок 6 – датологічна модель даних.

3.4 Фізична модель даних.

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

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

Таблиця 1 - Реляційна таблиця Адреса

Ім'я поля	Ключ	Фізичні характеристики	Логічні операції	Обов'язкове поле	Приклад даних
Номер_адреси	PK	integer	Check( Номер >0)	Notnull	1,2,3…
Номер_НП	FK	integer		Notnull	201
Номер_вулиці	FK	integer		Notnull	2101
хата		Integer		Notnull	63
корпус		Integer		null	2
офіс		integer		Notnull	18

Таблиця 2 – Реляційна таблиця Організація

Ім'я поля	Ключ	Фіз. Характеристики	Лог операції	Обов'язкові поля	Приклад
Код_організації	PK	int	Check( Номер >0)	Notnull	303
Назва організації		Char(10 0 )		Notnull	ТОВ « Евалар »
Скорочена назва		Char(100)		null	ТОВ_Е
Телефон		int		notnull	225-336
Електронна адреса		Char(100)		null	evalar@mail.ru
Номер_адреси	FK	int	Check( Номер >0)	Notnull	9009
Код_документа	FK	int	Check( Номер >0)	Notnull	6818

Таблиця 3 – Реляційна таблиця Освіта

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Код_ освіти	PK	int	Check( Номер >0)	Notnull	1111
Назва_ освіти		Char (100)		Notnull	Вища

Таблиця 4 – Реляційна таблиця Абітурієнт

Ім'я поля	Ключ	Фіз. Характеристики	Лог. операції	Обов'язкові поля	Приклад
Номер_абітурієнта	PK	int	Check( Номер >0)	Notnull	818
Прізвище		Char(100)		Notnull	Петров
Ім'я по батькові		Char(100)		Notnull	Петро Петрович
Підлога		Char(10)		Notnull	м
Вік		int		Notnull	25
Номер_ освіти	FK	int	Check( Номер >0)	Notnull	11111
Номер_ адреси	FK	int	Check( Номер >0)	Notnull	14234

Таблиця 5 – Реляційна таблиця Список курсів абітурієнтів

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_списку	PK	int	Check( Номер >0)	Notnull	1,3
Номер_курсу	FK	int	Check( Номер >0)	Notnull	1,3
Номер_абітурієнта	FK	int	Check( Номер >0)	Notnull	1,3
Код_організації	FK	int	Check( Номер >0)	Notnull	1,3
Код_освіти	FK	int	Check( Номер >0)	Notnull	1,3
Код_термін_навчання	FK	int	Check( Номер >0)	Notnull	1,3

Таблиця 6 - Реляційна таблиця Курси

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_курсу	PK	int	Check( Номер >0)	Notnull	331
Назва_курсу		Char(10 0 )			Адміністратор БД
Номер_організації	FK	int	Check( Номер >0)	Notnull	102
Номер_освіти	FK	Char(10)	Check( Номер >0)	Notnull	220
Номер _ теми	FK	int	Check( Номер >0)	Notnull	895
Номер_контролю	FK	int	Check( Номер >0)	Notnull	823
Ціна_курсу		int	Check( Номер >0)	Notnull	120000,00

Таблиця 7 - Реляційна таблиця Документ

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Код_документа	PK	int	Check( Номер >0)	Notnull	1,3
Тип документу		Char(10 0 )	Check( Номер >0)	Notnull	Акредитація
Серія документу		int	Check( Номер >0)	Notnull	1,3
Номер документа		int	Check( Номер >0)	Notnull	1,3
Дата видачі		int	Check( Номер >0)	Notnull	20.12.18
Дата_закінчення_дії		int	Check( Номер >0)	null	20.12.18

Таблиця 8 – Реляційна таблиця Контроль

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_контролю	PK	int	Check( Номер >0)	Notnull	331
Тип_контролю		Char(10 0 )	Check( Номер >0)	Notnull	залік
Назва_контролю		Char(10 0 )			Випускна кваліфікаційна робота
Коротка_назва					ВКР
Дата проведення		int	Check( Номер >0)	Notnull	20.18.19
Код_документа	FK	int	Check( Номер >0)	Notnull	102

Таблиця 9 – Реляційна таблиця Теми

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_теми	PK	Int	Check( Номер >0)	Notnull	02
Назва теми		Char(100)		Notnull	Економічний розвиток
Методичний_матеріал		Char(100)		Notnull	Кітчев ” Економіка ”
Кількість годин		Int		Notnull	45
Номер_контролю	FK	Int		Notnull	05

Таблиця 10 - Реляційна таблиця тип_НП

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_типу_НП	PK	Int	Check( Номер >0)	Notnull	02
Назва_типу_НП		Char(100)		Notnull	Село

Таблиця 11 - Реляційна таблиця тип_вулиці

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_ типу_ вулиці	PK	Int	Check( Номер >0)	Notnull	002
Назва_ типу_вулиці		Char(100)		Notnull	Бульвар

Таблиця 12 - Реляційна таблиця вулиця

Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_ вулиці	PK	int	Check( Номер >0)	Notnull	110
Номер_типу _ вулиці	FK	Int	Check( Номер >0)	Notnull	002
Назва_ вулиці		Char(100)		Notnull	Вул.Міра

Таблиця 13 – Реляційна таблиця НП

Продолжение таблицы 8. Ім'я поля	Ключ	Фіз. Характеристики	Логічні операції	Обов'язкові поля	Приклад
Номер_НП	PK	int	Check( Номер >0)	Notnull	2002
Номер_типу_НП	FK	Int	Check( Номер >0)	Notnull	02
Назва_НП		Char(100)		Notnull	Орськ

3.5 Розробка запитів

У цьому проекті було реалізовано такі запити:

на задану дату список підприємств, що мають вакансії на посаду

Рисунок 8 – SQL запит на виведення вакансій.

Рисунок 9 – результат виконання запиту

назва посади, яку за заданий період було запропоновано максимальну кількість вакансій;

Малюнок 10 – SQL запит на посаду

Рисунок 11 – результат виконання запиту

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

Рисунок 12 – SQL запит на виведення вакансій без освіти.

Рисунок 13 – результат виконання запиту

3.6 Розробка процедур захисту даних (забезпечення цілісності БД)

Цілісність бази даних ( database integrity ) - відповідність наявної в базі даних інформації її внутрішньої логіки, структури та всіх явно заданих правил. Кожне правило, яке накладає певне обмеження на можливий стан бази даних, називається обмеженням цілісності ( integrity constraint ).

Головний засіб забезпечення доменної цілісності в SQL Server – це обмеження CHECK. Воно може бути визначено під час створення таблиці або додано пізніше за допомогою команди ALTER TABLE.

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

Роль являє собою іменований набір прав та привілеїв на об'єкт БД, в системі є два типи ролей: Адміністратор БД та Користувач, налаштування ролей представлені на рисунках 14 та 15 відповідно.

Рисунок 14 - Роль Адміністратор БД

Рисунок 15 - Роль

4 Інтерфейси взаємодії з БД

Для взаємодії з БД було розроблено програму в середовищі MS Visual studio 2017. У програмі можна переглядати таблиці БД, а також продавати запити, описані вище.

Малюнок 16 – Головна форма

Рисунок 17 – вибір таблиці для перегляду

Рисунок 18 – Перегляд вибраної таблиці.

Для реалізації запитів необхідно натиснути кнопку «Запити», розташовану на цій же формі. Внаслідок цього з'явиться нове вікно з полями для умов відбору.

Малюнок 19 – форма «Запити»

Результат виконання запитів наведено вище. Код програми див. Додаток А.

1 2

скачати

© Усі права захищені
написати до нас