4.1 Логічне проектування

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

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

· Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім'я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.

· Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім'я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.

· Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

Рис. Концептуальна ER-модель проходження практики студентами

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

· Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

· Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

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

Таблиця 1. Відношення сутності НАВЧАЛЬНИЙ ПЛАН EDU_PLAN

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
EPID	ціле число	10	Унікальний ID	Первинний ключ
Num	строка	8	Номер навч. плану	Унікальний, обов'язковий
Ass_date	дата		Дата затвердження	Обов'язковий
Prs	строка	40	Особа, що затвердила	Обов'язковий
SPID	ціле число	10	Зв'язок зі спеціальністю	Зовнішній ключ, що посилається на первинний ключ відношення SPECIALITY. Обов'язковий

Таблиця 2. Відношення сутності ЗАПЛАНОВАНА ПРАКТИКА PLAN_PRACTICE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
PPID	ціле число	10	Унікальний ID	Первинний ключ
Dur_type	строка	1	Одиниці виміру терміну проходження практики. Приймає значення „Д”-дні, „Т”-тижні	Обов'язковий
Duration	ціле число	3	Термін проходження практики	Обов'язковий
QLID	ціле число	10	Зв'язок з кваліфікаційним рівнем	Зовнішній ключ, що посилається на первинний ключ відношення QUALI_LEVEL. Обов'язковий
CUID	ціле число	10	Зв'язок з курсом	Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов'язковий
PTID	ціле число	10	Зв'язок з видом практики	Зовнішній ключ, що посилається на первинний ключ відношення PRAC_TYPE. Обов'язковий
EPID	ціле число	10	Зв'язок з навчальним планом	Зовнішній ключ, що посилається на первинний ключ відношення EDU_PLAN. Обов'язковий
Обмеження цілісності таблиці	Сукупність стовпців (CUID, EPID) має обмеження унікальності та обов'язковості.

Таблиця 3. Відношення сутності ВИД ПРАКТИКИ PRAC_TYPE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
PTID	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва практики	Унікальний, обов'язковий. Приймає значення: схемотехнічна; комп'ютерна; технологічна; експлуатаційна (для спеціалістів науково-дослідна (для магістрів).
Descr	строка	255	Змістовний опис	Факультативний

Таблиця 4. Відношення сутності КВАЛІФІКАЦІЙНИЙ РІВЕНЬ QUALI_LEVEL

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
QLID	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва кваліфікаційного рівня	Унікальний, обов'язковий. Приймає значення: бакалавр; спеціаліст; магістр.
Descr	строка	255	Змістовний опис	Факультативний
CUID	ціле число	10	Зв'язок з курсом	Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов'язковий

Таблиця 5. Відношення сутності СПЕЦІАЛЬНІСТЬ SPECIALITY

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
SPID	ціле число	10	Унікальний ID	Первинний ключ
Num	строка	20	Номер спеціальності	Унікальний, обов'язковий.
Name	строка	100	Назва спеціальності	Обов'язковий

Таблиця 6. Відношення сутності КУРС COURSE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
CUID	ціле число	10	Унікальний ID	Первинний ключ
Num	ціле число	1	Номер курсу	Унікальний, обов'язковий. Приймає значення: 1-6.
Descr	строка	255	Змістовний опис	Факультативний

Таблиця 7. Відношення сутності ВУЗ UNIVERSITY

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
UNID	ціле число	10	Унікальний ID	Первинний ключ
Short_Name	строка	10	Скорочена назва ВУЗу	Факультативний.
Long_Name	строка	50	Повна назва ВУЗу	Обов'язковий, унікальний
Address	строка	50	Адреса ВУЗу	Факультативний
Rector	строка	30	ПІБ ректора	Обов'язковий, унікальний

Таблиця 8. Відношення сутності ІНСТИТУТ INSTITUTE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
INID	ціле число	10	Унікальний ID	Первинний ключ
Short_Name	строка	10	Скорочена назва	Факультативний.
Long_Name	строка	50	Повна назва	Обов'язковий, унікальний
Director	строка	30	ПІБ директора	Обов'язковий, унікальний
UNID	ціле число	10	Зв'язок з ВУЗом	Зовнішній ключ, що посилається на первинний ключ відношення UNIVERSITY. Обов'язковий

Таблиця 9. Відношення сутності ФАКУЛЬТЕТ FACULTY

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
FAID	ціле число	10	Унікальний ID	Первинний ключ
Short_Name	строка	10	Скорочена назва	Факультативний.
Long_Name	строка	50	Повна назва	Обов'язковий, унікальний
Dean	строка	30	ПІБ декана	Обов'язковий, унікальний
UNID	ціле число	10	Зв'язок з ВУЗом	Зовнішній ключ, що посилається на первинний ключ відношення UNIVERSITY. Факультативний
INID	ціле число	10	Зв'язок з інститутом	Зовнішній ключ, що посилається на первинний ключ відношення INSTITUTE,. Факультативний
FKType	строка		Признак, кому належить факультет, ВУЗу або інституту	Приймає значення: „У”, якщо факультет належить UNIVERSITY, або “І”, якщо факультет належить INSTITUTE

Таблиця 10. Відношення сутності КАФЕДРА DEPARTMENT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
DEID	ціле число	10	Унікальний ID	Первинний ключ
Short_Name	строка	10	Скорочена назва	Факультативний.
Long_Name	строка	50	Повна назва	Обов'язковий, унікальний
Head	строка	30	ПІБ завідувача	Обов'язковий, факультативний
FAID	ціле число	10	Зв'язок з факультетом	Зовнішній ключ, що посилається на первинний ключ відношення FACILTY. Обов'язковий

Таблиця 11. Відношення сутності ГРУПА STGROUP

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
GRID	ціле число	10	Унікальний ID	Первинний ключ
Num	строка	5	Номер групи	Обов'язковий, унікальний у межах факультету
Descr	строка	255	Змістовний опис групи	Факультативний
DEID	ціле число	10	Зв'язок з кафедрою	Зовнішній ключ, що посилається на первинний ключ відношення DEPARTMENT. Обов'язковий
CUID	ціле число	10	Зв'язок з курсом	Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов'язковий

Таблиця 12. Відношення сутності СТУДЕНТ STUDENT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
STID	ціле число	10	Унікальний ID	Первинний ключ
Last_name	строка	30	Прізвище	Обов'язковий
Name	строка	20	Ім'я	Обов'язковий
Patro_name	строка	20	По батькові	Обов'язковий
Num	строка	10	Номер студентського квитка	Обов'язковий, унікальний
Birthday	дата		Дата народження	Обов'язковий
Year	ціле число	4	Рік вступу у ВУЗ	Обов'язковий
Country	строка	20	Країна мешкання	Обов'язковий
Contract	строка	1	Навчання за контрактом	Обов'язковий. „T” - навчання за контрактом, „H” - ні
External	строка	1	Навчання екстерном	Обов'язковий. „T” - навчання екстерном, „H” - ні
GRID	ціле число	10	Зв'язок з групою	Зовнішній ключ, що посилається на первинний ключ відношення STGROUP. Обов'язковий

Таблиця 13. Відношення сутності БАЗА ПРАКТИКИ COMPANY

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
COID	ціле число	10	Унікальний ID	Первинний ключ
Num	строка	10	Реєстровий номер	Обов'язковий, унікальний
Name	строка	40	Назва	Обов'язковий
Head	строка	20	ПІБ керівника	Обов'язковий
Post	строка	20	Посада керівника	Обов'язковий
Address	строка	50	Адреса	Факультативний

Таблиця 14. Відношення сутності ДОГОВІР AGREEMENT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
AGID	ціле число	10	Унікальний ID	Первинний ключ
Num	строка	10	Номер договору	Обов'язковий, унікальний
AssDate	дата		Дата підписання	Обов'язковий
St_num	ціле число	2	Кількість студентів	Обов'язковий
From_date	дата		Дата початку практики	Обов'язковий
To_date	дата		Дата закінчення практики	Обов'язковий
COID	ціле число	10	Зв'язок з базою практики	Зовнішній ключ, що посилається на первинний ключ відношення COMPANY. Обов'язковий
FAID	ціле число	10	Зв'язок з кафедрою	Зовнішній ключ, що посилається на первинний ключ відношення FACULTY. Обов'язковий

Таблиця 15. Відношення сутності КЕРІВНИК TUTOR

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
TUID	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	30	ПІБ керівника	Обов'язковий
Post	строка	20	Посада	Факультативний
Address	строка	30	Адреса	Факультативний
Pas_ser	строка	2	Серія паспорту	Обов'язковий
Pas_ num	строка	6	Номер паспорту	Обов'язковий
Обмеження цілісності таблиці	Сукупність стовпців (PasSer, PasNum) має обмеження унікальності.

Таблиця 16. Відношення сутності ПРАКТИКА СТУДЕНТА STUD_PRACTICE

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
SPID	ціле число	10	Унікальний ID	Первинний ключ
Duration	ціле число	2	Термін проходження практики у днях	Обов'язковий
In_date	дата		Дата початку практики	Обов'язковий
Out_date	дата		Дата закінчен. практики	Обов'язковий
Mark	ціле число	1	Оцінка	Факультативний, Приймає значення у інтервалі 1 -- 5
STID	ціле число	10	Зв'язок з студентом	Зовнішній ключ, що посилається на первинний ключ відношення STUDENT. Обов'язковий
TUFID	ціле число	10	Зв'язок з керівником від факультету	Зовнішній ключ, що посилається на первинний ключ відношення TUTOR. Обов'язковий
TUCID	ціле число	10	Зв'язок з керівником від бази практики	Зовнішній ключ, що посилається на первинний ключ відношення TUTOR. Обов'язковий
AGID	ціле число	10	Зв'язок з договором, згідно з яким проходила практика	Зовнішній ключ, що посилається на первинний ключ відношення AGREEMENT. Факультативний
PPID	ціле число	10	Зв'язок з запланованою практикою	Зовнішній ключ, що посилається на первинний ключ відношення PLAN_PRACTICE. Обов'язковий
Обмеження цілісності таблиці	Сукупність стовпців (STID, PPID) має обмеження унікальності та обов'язковості.

Таблиця 17. Відношення сутності ЗВІТ REPORT

Ім'я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
REID	ціле число	10	Унікальний ID	Первинний ключ
Text	строка	30КБ	Текст звіту	Обов'язковий
SPID	ціле число	10	Зв'язок з практикою студента	Зовнішній ключ, що посилається на первинний ключ відношення STUD_PRACTICE. Обов'язковий та унікальний

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

База даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об'єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних. Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.

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

Скрипти створення бази даних

Наведемо скрипт мови SQL Oracle, який створює таблиці БД.

- Створення таблиці SPECIALITY

CREATE TABLE SPECIALITY (

SPID integer CONSTRAINT spe_prk PRIMARY KEY,

Num char(20) CONSTRAINT spe_num_unq UNIQUE NOT NULL,

Name varchar(100) NOT NULL);

- Створення таблиці EDU_PLAN

CREATE TABLE EDU_PLAN (

EPID integer CONSTRAINT edp_prk PRIMARY KEY,

Num char(8) CONSTRAINT edp_num_unq UNIQUE NOT NULL,

Ass_date date NOT NULL,

Prs varchar(40) NOT NULL,

SPID integer CONSTRAINT edp_spc_frk REFERENCES SPECIALITY(SPID) NOT NULL);

- Створення таблиці COURSE

CREATE TABLE COURSE (

CUID integer CONSTRAINT crs_prk PRIMARY KEY,

Num number(1) CONSTRAINT crs_num_unq UNIQUE NOT NULL

CONSTRAINT crs_num_chk CHECK (Num IN (1,2,3,4,5,6)),

Descr varchar(255));

- Створення таблиці QUALI_LEVEL

CREATE TABLE QUALI_LEVEL (

QLID integer CONSTRAINT qlv_prk PRIMARY KEY,

Name varchar(15) CONSTRAINT qvl_nam_unq UNIQUE NOT NULL

CONSTRAINT qvl_nam_chk CHECK

(Name IN ('бакалавр', 'спеціаліст', 'магістр')),

Descr varchar(255),

CUID integer CONSTRAINT qvl_crs_frk REFERENCES COURSE(CUID) NOT NULL);

- Створення таблиці PRAC_TYPE

CREATE TABLE PRAC_TYPE (

PTID integer CONSTRAINT prt_prk PRIMARY KEY,

Name varchar(15) CONSTRAINT prt_nam_unq UNIQUE NOT NULL

CONSTRAINT prt_nam_chk CHECK

(Name IN ('схемотехнічна', 'комп''ютерна',

'технологічна', 'експлуатаційна', 'науково-дослідна')),

Descr varchar(255));

- Створення таблиці PLAN_PRACTICE

CREATE TABLE PLAN_PRACTICE (

PPID integer CONSTRAINT ppr_prk PRIMARY KEY,

Dur_type char(1) CONSTRAINT ppr_dtp_chk CHECK (Dur_type IN ('Д','Т'))

NOT NULL,

Duration NUMBER(3) NOT NULL,

QLID integer CONSTRAINT ppr_qvl_frk REFERENCES QUALI_LEVEL(QLID) NOT NULL,

CUID integer CONSTRAINT ppr_crs_frk REFERENCES COURSE(CUID) NOT NULL,

PTID integer CONSTRAINT ppr_prt_frk REFERENCES PRAC_TYPE(PTID) NOT NULL,

EPID integer CONSTRAINT ppr_edp_frk REFERENCES EDU_PLAN (EPID) NOT NULL,

CONSTRAINT ppr_crs_edp_unq UNIQUE (CUID, EPID);

- Створення таблиці UNIVERSITY

CREATE TABLE UNIVERSITY (

UNID integer CONSTRAINT uni_prk PRIMARY KEY,

Short_name varchar(10),

Long_name varchar(50) CONSTRAINT uni_nam_unq UNIQUE NOT NULL,

Address varchar(50),

Rector varchar(30) CONSTRAINT uni_rec_unq UNIQUE NOT NULL);

- Створення таблиці INSTITUTE

CREATE TABLE INSTITUTE (

INID integer CONSTRAINT ins_prk PRIMARY KEY,

Short_name varchar(10),

Long_name varchar(50) CONSTRAINT ins_nam_unq UNIQUE NOT NULL,

Director varchar(30) CONSTRAINT ins_rec_unq UNIQUE NOT NULL,

UNID integer CONSTRAINT ins_uni_frk REFERENCES UNIVERSITY(UNID));

- Створення таблиці FACULTY

CREATE TABLE FACULTY (

FAID integer CONSTRAINT fac_prk PRIMARY KEY,

Short_name varchar(10),

Long_name varchar(50) CONSTRAINT fac_nam_unq UNIQUE NOT NULL,

Dean varchar(30) CONSTRAINT fac_rec_unq UNIQUE NOT NULL,

UNID integer CONSTRAINT fac_uni_frk REFERENCES UNIVERSITY(UNID),

INID integer CONSTRAINT fac_ins_frk REFERENCES INSTITUTE(INID),

FKType char(1) CONSTRAINT fac_fkt_chk CHECK (FKType IN ('У', 'І')));

- Створення таблиці DEPARTMENT

CREATE TABLE DEPARTMENT (

DEID integer CONSTRAINT dep_prk PRIMARY KEY,

Short_name varchar(10),

Long_name varchar(50) CONSTRAINT dep_nam_unq UNIQUE NOT NULL,

Head varchar(30) CONSTRAINT dep_hed_unq UNIQUE NOT NULL,

FAID integer CONSTRAINT dep_fac_frk REFERENCES FACULTY(FAID) NOT NULL);

- Створення таблиці STGROUP

CREATE TABLE STGROUP (

GRID integer CONSTRAINT grp_prk PRIMARY KEY,

Num char(5) NOT NULL,

Descr varchar(255),

DEID integer CONSTRAINT grp_dep_frk REFERENCES DEPARTMENT(DEID) NOT NULL,

CUID integer CONSTRAINT grp_crs_frk REFERENCES COURSE(CUID) NOT NULL);

- Створення таблиці STUDENT

CREATE TABLE STUDENT (

STID integer CONSTRAINT std_prk PRIMARY KEY,

Last_name varchar(30) NOT NULL,

Name varchar(20) NOT NULL,

Patro_name varchar(20) NOT NULL,

Num char(10) CONSTRAINT std_num_unq UNIQUE NOT NULL,

Birthday date NOT NULL,

Year number(4) NOT NULL,

Country varchar(20) NOT NULL,

Contract char(1) CONSTRAINT prs_con_chk CHECK (Contract IN ( 'Т', 'Н')),

External char(1) CONSTRAINT prs_ext_chk CHECK (External IN ( 'Т', 'Н')),

GRID integer CONSTRAINT prs_grp_frk

REFERENCES STGROUP(GRID) NOT NULL);

- Створення таблиці COMPANY

CREATE TABLE COMPANY (

COID integer CONSTRAINT com_prk PRIMARY KEY,

Num char(10) CONSTRAINT com_num_unq UNIQUE NOT NULL,

Name varchar(40) NOT NULL,

Head varchar(20) NOT NULL,

Post varchar(20) NOT NULL,

Address varchar(50));

- Створення таблиці AGREEMENT

CREATE TABLE AGREEMENT (

AGID integer CONSTRAINT agr_prk PRIMARY KEY,

Num char(10) CONSTRAINT agr_num_unq UNIQUE NOT NULL,

Ass_date date NOT NULL,

St_num NUMBER(2) NOT NULL,

From_date date NOT NULL,

To_date date NOT NULL,

COID integer CONSTRAINT agr_crs_frk REFERENCES COMPANY(COID) NOT NULL,

FAID integer CONSTRAINT agr_fac_frk REFERENCES FACULTY(FAID) NOT NULL);

- Створення таблиці TUTOR

CREATE TABLE TUTOR (

TUID integer CONSTRAINT tut_prk PRIMARY KEY,

Name varchar(30) NOT NULL,

Post varchar(20),

Address varchar(30),

Pas_ser char(2) NOT NULL,

Pas_num char(6) NOT NULL,

CONSTRAINT tut_ser_nmm_unk UNIQUE (Pas_ser, Pas_num));

- Створення таблиці STUD_PRACTICE

CREATE TABLE STUD_PRACTICE (

SPID integer CONSTRAINT stp_prk PRIMARY KEY,

Duration number(2) NOT NULL,

In_date date NOT NULL,

Out_date date NOT NULL,

Mark number(1) CONSTRAINT stp_mrk_chk CHECK (Mark BETWEEN 1 AND 5),

STID integer CONSTRAINT stp_std_frk REFERENCES STUDENT(STID) NOT NULL,

TUFID integer CONSTRAINT stp_tuf_frk REFERENCES TUTOR(TUID) NOT NULL,

TUCID integer CONSTRAINT stp_tuc_frk REFERENCES TUTOR(TUID) NOT NULL,

AGID integer CONSTRAINT stp_agr_frk REFERENCES AGREEMENT(AGID),

PPID integer CONSTRAINT stp_prp_frk REFERENCES PLAN_PRACTICE(PPID) NOT NULL,

CONSTRAINT stp_std_prp_unk UNIQUE (STID, PPID));

- Створення таблиці REPORT

CREATE TABLE REPORT (

REID integer CONSTRAINT rep_prk PRIMARY KEY,

Text CLOB (30K) NOT NULL,

SPID integer CONSTRAINT rep_stp_frk REFERENCES STUD_PRACTICE(SPID)

CONSTRAINT rep_stp_unq UNIQUE NOT NULL);

Інформаційно-пошукові запити

Наведемо приклади інформаційно пошукових запитів відносно тих задач, які були окреслені в підрозділі «2.4. Інформаційно-довідкові задачі». Приклади наведемо у мові SQL Oracle з використанням бази даних, визначеної у попередньому підрозділі.

Інформаційні запити, що пов'язані з проходженням практики

Запит 1. Вивести перелік назв видів практик, які повинні проходити студенти, на якому курсі, у відповідності до кваліфікаційних рівнів. Відсортувати перелік по кваліфікаційним рівням та курсам.

SELECT q.Name, c.Num, t.Name, FROM PLAN_PRACTICE p, COURSE c, QUALI_LEVEL q, PRAC_TYPE t WHERE p.CUID = c.CUID AND p.QLID = q.QLID AND p.PTID = t.PTID ORDER BY q.Name, c.Num;

Запит 2. Вивести назви баз практик, які є на факультеті комп'ютерних наук.

SELECT c.Name AS ”Бази практики факультету комп'ютерних наук” FROM FACULTY f, COMPANY c, AGREEMENT a WHERE f.FAID = a.FAID AND c.COID = a.COID AND UPPER(f.ShortName) = 'CS';

Запит 3. Вивести роки проходження практик і оцінки студента Іванова

SELECT TO_CHAR(p.In_date,'YYYY') AS ”Рік проходження практики”, p.Mark AS ”Оцінка” FROM STUDENT s, STUD_PRACTICE p

WHERE p.STID = s.STID AND UPPER(s.Last_name) = 'ІВАНОВ';

TO_CHAR(p.In_date,'YYYY' = '2003';

Інформація організаційного характеру

Запит 1. Скільки договорів було підписано на факультеті інформатики по рокам.

SELECT TO_CHAR(a.Ass_date,'YYYY') AS ”Рік підписання договору”,

COUNT(*) AS ”Кількість підписаних договорів” FROM FACULTY f, COMPANY c, AGREEMENT a WHERE f.FAID = a.FAID AND c.COID = a.COID AND UPPER(f.ShortName) = 'CS' GROUP BY TO_CHAR(a.Ass_date,'YYYY') ORDER BY q.Name, c.Num;

Запит 2. Хто є керівником підприємства, з яким підписано договір від 03.07.2003.

SELECT TO_CHAR(a.Ass_date,'YYYY') AS ”Рік підписання договору”, COUNT(*) AS ”Кількість підписаних договорів” FROM COMPANY c, AGREEMENT a WHERE c.COID = a.COID AND a.Ass_date = TO_DATE('03/07/2003', 'DD/MM/YYYY');

Запит 3. Скільки студентів на 3 курсі факультету комп'ютерних наук SELECT COUNT(*) AS ”Кількість студентів 3 курсу на факультеті CS” FROM FACULTY f, DEPARTMENT a, STGROUP g, COURSE c, STUDENT s WHERE f.FAID = d.FAID AND d.DEID = g.DEID AND g.CUID = c.CUID AND g.GRID = s.GRID AND (f.ShortName) = 'CS' AND c.Num = 3;

Інформація про керівників практики

Запит 1. Хто був керівником від факультету практики студента Іванова з групи 401 у 2003 році.

SELECT tf.Name AS ”Керівник Іванова з групи 401 у 2003”

FROM STUDENT s, GROUP g, STUD_PRACTICE p, TUTOR tf
WHERE s.GRID = g.GRID AND s.STID = p.STID AND p.TUFID = tf.TUID AND UPPER(s.Last_name) = 'ІВАНОВ' AND g.Num =401 AND TO_CHAR(p.In_date,'YYYY') = '2003';

Запит 2. Хто був керівниками (від кафедри і від бази практики) практики студентів групи 505 у 2002 році

SELECT tf.Name AS ”Керівник від факультету”,

tc.Name AS ”Керівник від бази практики”, FROM STUDENT s, GROUP g, STUD_PRACTICE p, TUTOR tf, TUTOR tc WHERE s.GRID = g.GRID AND s.STID = p.STID AND p.TUFID = tf.TUID AND p.TUCID = tc.TUID AND g.Num =505 AND TO_CHAR(p.In_date,'YYYY' = '2002';

Запит 3. Вивести тих викладачів, які були керівниками студентів одночасно від факультету і бази практики.

SELECT tf.Name AS ”Вони одночасно керували практикою від факультету і БП”

FROM STUD_PRACTICE p, TUTOR tf, TUTOR tc
WHERE p.TUFID = tf.TUID AND p.TUCID = tc.TUID AND p.TUFID = p.TUCID;

Висновки

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

Ціллю курсової роботи було проектування бази даних проходження практики студентами на прикладі факультету комп'ютерних наук НАУ.

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

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

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

Логічне та фізичне проектування БД складалося з конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази даних. Після цього реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

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

Размещено на Allbest.ru

...