Розробка проекту баз даних

НАЦІОНАЛЬНИЙ  АВІАЦІЙНИЙ УНІВЕРСИТЕТ

Факультет комп’ютерних наук

Кафедра  комп’ютерних інформаційних  технологій

 

 

 

 

 

 

 

КУРСОВИЙ ПРОЕКТ

(ПОЯСНЮВАЛЬНА ЗАПИСКА)

з дисципліни "Організація  баз даних і знань"

Тема: «Розробка  проекту баз даних»

 

 

 

Виконав:

студент групи  ФКН 302

Новосельський Андрій

Керівник:

Харченко О.Г.

 

 

 

 

 

 

 

 

Київ 2012

НАЦІОНАЛЬНИЙ  АВІАЦІЙНИЙ УНІВЕРСИТЕТ

Кафедра комп'ютерних  інформаційних технологій

 

ЗАВДАННЯ

на  виконання курсового проекту

студента ФКН-302

Новосельського Андрія Олександровича

Тема  курсового проекту: Розробка проекту баз даних.

1. Термін виконання проекту: з __________р. до __________р.

2. Вихідні дані  до проекту:

 

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

 

3. Завдання:

1. Вибрати сутності та встановити зв'язки між ними.
2. Побудувати E-R діаграму. Перевірити сутності та зв'язки на нормальність. При необхідності провести нормалізацію та спрощення зв'язків.
3. Визначити первинні та зовнішні ключі для реалізації зв'язків.
4. Перетворити E-R діаграму в реляційну модель.
5. Нормалізувати побудовані відношення до III нормальної форми.
6. Визначити типи даних та обмеження цілісності й написати командні скрипти на мові SQL для створення бази даних в середовищі СУБД.
7. Написати запити на мові SQL для заповнення таблиць, а також запити для перегляду, видалення, та заміни даних в таблицях БД.

 

4. Завдання видав  ___________________________ ( _________________________________ )

(підпис керівника)   (П.І.Б. керівника)

 

" _____ " _______________ 2012 р.

 

Завдання прийняв  до виконання ________________________________________________

(підпис студента)

 

Курсовий  проект захищений з оцінкою_________________________________________

 

Голова комісії: ________________________________________________________.2012 р.

 

Члени комісії: _________________________________________________________________

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Зміст

Вступ 5

1. Основні теоретичні відомості 6

2. Побудова концептуальної (логічної) моделі даних 7

2.1 Визначення сутностей. 7

2.2 Дослідження зв’язків 7

2.3 Визначення атрибутів. 8

2.4 Побудова E-R діаграми. 9

2.5 Визначення ключів таблиці. 9

2.6 Нормалізація моделі даних. 10

3. Реалізація моделі даних засобами мови SQL. 12

3.1 Створення таблиць СКБД 14

4. Отримані таблиці 15

4.1. project 15

4.2. subdivision 15

4.3. work_project 16

4.4. work 16

4.5. staff_project 16

4.6. staff 16

5. Створення запитів 17

5.1. Оператор SELECT 17

5.2. Використання специфікатора WHERE 17

5.3. Контекстний пошук 18

5.4. Використання функцій 18

5.5. Використання підзапитів 18

5.6. Оператор видалення DELETE 18

5.7. Вставка рядків INSERT 18

5.8. Зміна рядка даних. Оператор UPDATE 19

5.9. Представлення ( VIEW ) 19

5.10. Використання складних під запитів 19

Висновок 20

Список використаної літератури 21

 

 

Вступ

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

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

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

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

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

 

 

1. Основні теоретичні  відомості

Основними інформаційними об'єктами E-R моделі даних є сутності, а їх характеристиками – зв'язки й атрибути.

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

Сутності мають  задовольняти таким вимогам:

• сутність повинна бути значущою;
• сутність повинна бути загальною;
• сутність повинна бути фундаментальною;
• сутність повинна бути неподільною.

Зв’язаність належить до числа властивостей сутностей і описує кратність входження примірників деякої сутності в зв'язок.

Існує три типи зв’язаності:

• один до одного (1:1);
• один до багатьох (1:n);
• багато до багатьох (m:n).

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

Виділені атрибути повинні мати такі властивості:

• значущість;
• прямі (тобто такі, що не виводяться з інших);
• неподільність;
• повинні містити дані одного типу.

Сутності на E-R діаграмі зображуються прямокутниками, а зв'язки – лініями, що з'єднують їх. Для зображення невизначеності зв'язку використовується коло, для  зображення того, що зв'язок тільки з одним примірником – риска, а для зображення зв'язку з багатьма примірниками – трикутник. Діаграма читається ліворуч-праворуч, а потім праворуч-ліворуч.

Стовпці таблиці мають ключовий стовпчик або дескриптор. Ключ повинен бути таким, щоб однозначно ідентифікувати рядки. Основними типами ключів є первинний (PRIMARY) і зовнішній (FOREIGN). Первинний ключ таблиці – це стовпець, значення якого різні в кожному рядку. Якщо такого стовпця не існує, то первинний ключ складають зі значень двох або більше стовпців, так, щоб складені значення були різні в різних рядках.

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

2. Побудова концептуальної (логічної) моделі даних

2.1 Визначення сутностей.

Для своєї моделі я визначила  такі сутності:

• проект;
• підрозділи;
• види робіт;
• співробітники.

Діаграма сутностей має  такий вигляд: 

	Проект		Підрозділи		Види робіт		Співробітники

 

 

2.2 Дослідження зв’язків

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

 

 

 

 

	project	subdivision	work	staff
project	none	1 1 - n	1 – n 1 - n	1 - n 1 - n
subdivision	-	none	none	1 1 - n
work	-	-	none	1 1 - n
staff	-	-	-	none

 

Одразу ж зазначимо  відсутність зв’язків між однойменними сутностями (none).

Також зв’язки відсутні між сутностями проект – підрозділ (none), підрозділ – види робіт (none).

На проекті може бути задіяно багато видів робіт (зв’язок 1:n) і кожен вид робіт може бути задіяний на декількох проектах (зв’язок 1:n) .  На кожному проекті задіяно багато працівників (зв’язок 1:n),  і кожен працівник задіяних хоча б на одному проекті (зв’язок 1:n). В кожному підрозділі працює багато працівників (зв’язок 1:n) , але кожен працівник працює лише в одному підрозділі (зв’язок 1:1).  Кожен вид робіт виконує декілька працівників (зв’язок 1:n), але кожен працівник задіяний лише на 1 виді робіт (зв’язок 1:1)

2.3 Визначення атрибутів.

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

project		subdivision		work		staff
proj_name contract begin_date end_date price		sub_name work_kind staff_number		work_name beg_work end_work price_work percent		id qualification subdivis project_numb

2.4 Побудова E-R діаграми.

Побудуємо E-R діаграму організації, що виконує проекти, використовуючи діаграму сутностей, матрицю зв`язків і список атрибутів. Вона буде мати такий вигляд:

2.5 Визначення ключів таблиці.

Після того, як ми проаналізували атрибути таблиць і вибрали ключі -   отримаємо таку таблицю:

project		subdivision		work		staff
proj_name contract PK begin_date end_date price		sub_name PK contract FK work_kind staff_number		work_name PK contract FK id FK1 beg_work end_work price_work percent		id PK contract FK sub_name FK1 qualification subdivis project_numb

    

Для таблиці Project первинним ключем був обраний ключ Contract, для таблиці Subdivision - обраний ключ Sub_name, для таблиці Work -  Work_name, для таблиці Stuff - Id. Для з`єднання таблиці Project з іншими таблицями був взятий зовнішній ключ  Contract.

Після визначення ключів та спрощення зв’язків, наша модель даних  буде мати такий вигляд:

Випишишемо атрибути  кожної із сутностей:

Project  (proj_name, contract, begin_date, end_date, price)

Subdivision (sub_name, contract , work_kind, staff_number)

Work (id, work_name, contract, beg_work, end_work, price_work,  percent)

Staff (id, contract, qualification, subdivis, project_numb, sub_name)

2.6 Нормалізація моделі даних.

Перша нормальна форма

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

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

Друга нормальна форма

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

     Проаналізуємо залежність атрибутів кожної сутності від первинного ключа:

Project: 

contract  PK

contract → proj_name

contract → begin_date

contract → end_date

contract → price

 

Subdivision :

sub_name PK

sub_name  → contract 

sub_name  → work_kind

sub_name  → staff_number

 

Work:

work_name PK

work_name → contract

work_name →id

work_name → beg_work,

work_name → end_work

work_name → price_work 

work_name → percent

 

Staff :

id PK

id → contract

id → sub_name

id → qualification

id → subdivis

id → project_numb

 

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