Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Зміст

1. Вступ

2. Методи й засоби проектування баз даних

2.1 Опис основних етапів проектування баз даних

2.2 Опис методології проектування

2.3 Короткий опис мови моделювання, що використовується

3. Стратегія автоматизації

3.1 Короткий опис предметної області із зазначенням поточних цілей і задач

3.2. Цілі та задачі автоматизації

3.3 Декларація вимог до проектованої системи баз даних (вимоги до інформаційного, математичного, програмного, технічного, організаційного забезпечення)

4. Системний аналіз предметної області

4.1 Опис інформаційного забезпечення (сутності, зв'язки, атрибути, домени, обмеження цілісності)

4.2. Опис зв'язків між даними та задачами (матриця задачі/дані)

4.3 Опис необхідності захисту даних та рівня цього захисту

4.4 Опис заходів, необхідних для контролю даних у базі даних, їх резервного копіювання та відновлення

5. Концептуальне моделювання предметної області

5.1 ERD предметної області, що автоматизується

5.2 Змістовний опис обмежень цілісності

6. Логічний проект бази даних

6.1 Опис таблиць бази даних з обмеженнями цілісності

6.2 Опис запитів по вибору даних, що реалізують описані задачі

Висновки

1. Вступ

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

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

Зараз найбільш поширеною є реляційна модель баз даних. Широке поширення ця модель отримала відносно недавно. У той час, як основні теоретичні результати в цій області були отримані ще в 70-х (співробітником інституту фірми ІБМ в Сан-Хосе Е.Ф. Коддом), і тоді ж з'явилися перші прототипи реляційних СУБД, довгий час вважалося неможливим досягти ефективної реалізації таких систем. Однак поступове накопичення методів і алгоритмів організації реляційних баз даних і управління ними призвели до того, що вже в середині 80-х років реляційні системи практично витіснили зі світового ринку ранні СУБД ієрархічного і мережевого типу. В реляційній базі даних дані зберігаються не все разом, а в окремих таблицях, завдяки чому досягається виграш у швидкості та гнучкості. Таблиці зв'язуються між собою за допомогою відносин, завдяки чому забезпечується можливість поєднувати при виконанні запиту дані з декількох таблиць. Реляційна модель описує, які дані можуть зберігатися в реляційних базах даних, а також способи маніпулювання такими даними. У спрощеному вигляді основна ідея реляційної моделі полягає в тому, що дані повинні зберігатися в таблицях і тільки в таблицях. В даний момент існуємо багато різних систем обробки даних, що оперують поняттям "таблиця", наприклад, всім відомі, електронні таблиці, таблиці текстового редактора MS Word, і т.п. Осередки електронної таблиці можуть зберігати різнотипні дані, наприклад, числа, рядки тексту, формули, що посилаються на інші клітинки. Власне, на одному аркуші електронної таблиці можна розмістити кілька абсолютно незалежних таблиць, якщо під таблицею розуміти прямокутну область, розкреслену на клітинки та заповнену даними. Таблиці текстових редакторів взагалі можуть мати абсолютно довільну структуру. У даній роботі виконується проектування та розробка бази даних реєстру повітряних суден.

2. Методи й засоби проектування баз даних

2.1 Опис основних етапів проектування баз даних

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

Як і в будь-якій іншій системі, життєвий цикл баз даних складається з двох основних фаз: проектування та реалізація.

Фаза проектування:

- Розробка стратегії;

- Системний аналіз;

- Концептуальне моделювання;

- Логічне і фізичне проектування.

Фаза реалізації:

- Реалізація;

- Документування;

- Дослідне впровадження;

- Промислова експлуатація.

2.2 Опис методології проектування

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

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

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

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

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

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

2.3 Короткий опис мови моделювання, що використовується

В наш час у реальному проектуванні структури бази даних широко застосовується семантичне моделювання. Семантичне моделювання являє собою моделюванням структури даних, що спирається на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм «сутність-зв'язок» (ERD - Entity-Relationship Diagram). Всі варіанти діаграм «сутність-зв'язок» використовують графічне зображення сутностей предметної області, їх властивостей (атрибутів), і взаємозв'язків між сутностями.

Основні поняття ERD

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

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

Атрибут сутності - це іменована характеристика, що є деякою властивістю сутності.

Найменування атрибута має бути виражене іменником в однині. Атрибути зображуються в межах прямокутника, що визначає сутність.

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

Сутність може мати кілька різних ключів. Ключові атрибути зображуються на діаграмі символом «#»

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

Кожен зв'язок може мати один з типів зв'язку: один-до-одного () , один-до-багатьох () и багато-до-багатьох ().

Один-до-одного	Один екземпляр першої сутності (лівої) пов'язаний з одним екземпляром другої сутності (правої). Зв'язок один-до-одного частіше за все свідчить про те, що насправді ми маємо всього одну сутність, помилково розділену на дві
Один-до-багатьох	Один екземпляр першої сутності (лівої) пов'язаний з декількома екземплярами другої сутності (правої). Це найбільш часто використовуваний тип зв'язку. Ліва сутність (з боку "один") називається батьківського, права (з боку "багато") - дочірньою
Багато-до-багатьох	Зв'язок типу означає, що кожен екземпляр першої сутності може бути пов'язаний з декількома екземплярами другої, і кожен екземпляр другої сутності може бути пов'язаний з декількома екземплярами першої. Тип зв'язку багато-до-багатьох є тимчасовим типом зв'язку, допустимим на ранніх етапах розробки моделі. Надалі цей тип зв'язку повинен бути замінений двома зв'язками типу один-до-багатьох шляхом створення проміжної сутності

Кожен зв'язок може мати одну з двох модальностей зв'язку: «може» () і «повинен» ().

Може	Екземпляр однієї сутності може бути пов'язаний з одним або кількома екземплярами іншої сутності, а може бути і не пов'язаний ні з одним екземпляром
Повинен	Екземпляр однієї сутності зобов'язаний бути пов'язаний не менш ніж з одним екземпляром іншої сутності

Описаний графічний синтаксис дозволяє однозначно читати діаграми, користуючись наступною схемою побудови фраз: <Кожен екземпляр СУТНОСТІ 1> <МОДАЛЬНІСТЬ ЗВ'ЯЗКУ> <НАЙМЕНУВАННЯ ЗВ'ЯЗКУ> <ТИП ЗВ'ЯЗКУ> <екземпляр СУТНОСТІ 2>.

3. Стратегія автоматизації

3.1 Короткий опис предметної області із зазначенням поточних цілей і задач

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

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

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

база система програмний копіювання

3.2 Цілі та задачі автоматизації

Розробка бази даних реєстру повітряних суден спрощує роботу з доступом інформації.

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

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

Головна мета створення бази даних:

- Автоматизація роботи персоналу авіакомпаній;

- Підвищення продуктивності праці.

База даних реєстрації повітряних суден вирішує наступні завдання:

- Додавання нових повітряних суден до державного реєстру України;

- Швидкий доступ до реєстру повітряних суден;

- Отримання різноманітної інформації про повітряне судно, що знаходиться в реєстрі.

3.3 Декларація вимог до проектованої системи баз даних (вимоги до інформаційного, математичного, програмного, технічного, організаційного забезпечення)

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

В якості програмного ресурсу будемо використовувати СУБД ORACLE, оскільки він володіє високою продуктивністю, надійною системою безпеки, зручністю в роботі.

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

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

Дана система повинна мати зручний користувальницький інтерфейс.

4. Системний аналіз предметної області

4.1 Опис інформаційного забезпечення (сутності, зв'язки, атрибути, домени, обмеження цілісності)

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

- Повітряне судно

- Реєстраційний орган

- Реєстрація

- Авіакомпанія

- Тип повітряного судна

- Служба

- Обслуговування

Наведемо для всіх перерахованих вище сутностей набори необхідних атрибутів

Повітряне судно
#	Бортовий номер	Цілочисельний
Реєстраційний орган
#	Назва	Строковий
Реєстрація
#	Код реєстрації	Цілочисельний
*	Дата	Дата
*	Місце	Строковий
*	Власник	Строковий
*	Ознака повторної реєстрації	Строковий
Авіакомпанія
#	Назва	Строковий
Тип повітряного судна
#	Назва	Строковий
*	Кількість місць	Цілочисельний
*	Вантажопідйомність	Цілочисельний
Служба
#	Назва	Строковий
Обслуговування
#	Дата	Дата
*	Результат	Строковий

4.2 Опис зв'язків між даними та задачами (матриця задачі/дані)

	Повітряне судно	Реєстраційний орган	Реєстрація	Авіакомпанія	Тип повітряного судна	Служба	Обслуговування
Повітряне судно							1:М
Реєстраційний орган			1:М
Реєстрація	1:М
Авіакомпанія	1:М
Тип повітряного судна	1:М
Служба							1:М
Обслуговування

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

Виділено наступні завдання:

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

2. Видати всі результати обслуговування повітряного судна (бортовий номер, результати) за період з 1.01.2011 по 1.01.2012

3. Видати перелік авіакомпаній, судна яких зареєстровані

4. Видати список зареєстрованих повітряних суден (бортові номери, назви типів) з кількістю місць менше 200

5. Вивести список служб, які виконали обслуговування певного рейсу;

6. Видати повітряні судна заданої авіакомпанії, що пройшли повторну реєстрацію.

7. Видати кількість літаків певного типу, що належать заданій авіакомпанії.

4.3 Опис необхідності захисту даних та рівня цього захисту

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

4.4 Опис заходів, необхідних для контролю даних у базі даних, їх резервного копіювання та відновлення

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

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

5. Концептуальне моделювання предметної області

5.1 ERD предметної області, що автоматизується

5.2 Змістовний опис обмежень цілісності

Назва таблиці	Назва стовпця	Обмеження цілісності
Повітряне судно	# Бортовий номер	Первинний ключ
	*Тип повітряного судна	Зовнішній ключ, не дорівнює нулю
	*Код реєстрації	Зовнішній ключ, не дорівнює нулю
	*Назва авіакомпанії-власника	Зовнішній ключ, не дорівнює нулю

Реєстраційний орган	#Назва	Первинний ключ

Реєстрація	# Код реєстрації	Первинний ключ
	*Дата	Не дорівнює нулю
	*Місце	Не дорівнює нулю
	*Власник	Не дорівнює нулю
	*Ознака повторної реєстрації	Не дорівнює нулю. Може приймати одне зі значень: «Так» чи «Ні»
	*Назва реєстраційного органу	Зовнішній ключ, не дорівнює нулю

Авіакомпанія	# Назва	Первинний ключ

Тип повітряного судна	# Назва	Первинний ключ
	*Кількість місць	Не дорівнює нулю
	*Вантажопідйомність	Не дорівнює нулю

Служба	#Назва	Первинний ключ

Обслуговування	#Дата	Первинний ключ
	*Результат	Не дорівнює нулю
	*Бортовий номер обслуговуваного судна	Зовнішній ключ
	*Назва служби, що обслуговує	Зовнішній ключ

Для всіх зв'язків встановлено каскадне видалення (після видалення сутності повинні видаляти всі пов'язані з ним об'єкти).

6. Логічний проект бази даних

6.1 Опис таблиць бази даних з обмеженнями цілісності

CREATE TABLE aircrafttype (

Name VARCHAR(50) CONSTRAINT c1 PRIMARY KEY,

PlaceCount INTEGER CONSTRAINT c2 NOT NULL,

CarCapacity INTEGER CONSTRAINT c3 NOT NULL

);

CREATE TABLE aricompany (

Name VARCHAR(100) CONSTRAINT c4 PRIMARY KEY

);

CREATE TABLE reg_organ (

Name VARCHAR(100) CONSTRAINT c5 PRIMARY KEY

);

CREATE TABLE registration (

ID INTEGER CONSTRAINT c6 PRIMARY KEY,

RegDate DATE CONSTRAINT c7 NOT NULL,

Place VARCHAR(50) CONSTRAINT c8 NOT NULL

Owner VARCHAR(70) CONSTRAINT c19 NOT NULL

Ag_sign VARCHAR(10) CONSTRAINT c9 CHECK (Ag_sign in (`Yes', `No')),

OrganName VARCHAR(100) CONSTRAINT c10 REFERENCES reg_organ(Name) ON DELETE CASCADE

);

CREATE TABLE aircraft (

Hull_No INTEGER CONSTRAINT c11 PRIMARY KEY

ac_type VARCHAR(50) CONSTRAINT c12 REFERENCES aircrafttype (Name) ON DELETE CASCADE

compnyname VARCHAR(100) CONSTRAINT c13 REFERENCES aircompany(Name) ON DELETE CASCADE

RegID INTEGER CONSTRAINT c14 REFERENCES registration (ID) ON DELETE CASCADE

);

CREATE TABLE service ( //служба

Name VARCHAR(50) CONSTRAINT c15 PRIMARY KEY

);

CREATE TABLE serv ( //обслуживание

srvDate DATE CONSTRAING c16 PRIMARY KEY

result VARCHAR(20) CONSTRAINT NOT NULL

servName VARCHAR(50) CONSTRAINT c17 REFERENCES service(Name) ON DELETE CASCADE

Hull_No INTEGER CONSTRAINT c18 REFERENCES aircraft(Hull_No) ON DELETE CASCADE

);

6.2 Опис запитів по вибору даних, що реалізують описані задачі

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

SELECT aircraft.Null_No, registration.Owner, reg_organ.Name

FROM aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name;

2. Видати всі результати обслуговування повітряного судна (бортовий номер, результати) за період з 1.01.2011 по 1.01.2012

SELECT aircraft.hull_No, serv.result

FROM serv, service, aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name and service.Name = serv.servName and serv.Null_No=aircraft.Null_No and serv.srvDate BETWEEN TO_DATE(`1.01.2011', `DD.MM.YYYY) AND TO_DATE(`1.01.2012','DD.MM.YYYY');

3. Видати перелік авіакомпаній, судна яких зареєстровані

SELECT aircompany.Name

FROM aircompany, aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name and aircraft.companyname = aircompany.Name

4. Видати список зареєстрованих повітряних суден (бортові номери, назви типів) з кількістю місць менше 250

SELECT aircraft.Hull_NO, aircrafttype.Name

FROM aircrafttype, aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name and aircrafttype.Name = aircraft.ac_type and aircrafttype.placecount<250;

5. Вивести список служб, які обслуговували певний рейс

SELECT serv.ServName

FROM serv, aircraft,

WHERE serv.Hull_No=aircraft.Hull_No and Aircraft.id=148;

6. Видати повітряні судна заданої авіакомпанії (бортові номери), що пройшли повторну реєстрацію

SELECT aircraft.Hull_NO

FROM aircompany, aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name and aircraft.companyname = `Авиакомпания#1';

7. Видати кількість літаків певного типу, що належать заданій авіакомпанії

SELECT COUNT(*)

FROM aircraft, registration, reg_organ

WHERE aircraft. RegID = registration.ID and registration.OrganName = reg_organ.name and aircraft.tp_Name='АН-140' and aircraft.companyname='Авиакомпания#2';

8. Вибрати ті судна (бортові номери) АН-140, які не проходили обслуговування в періодс 1.01.2011 до 01.01.2012

SELECT aircraft.hull_No

FROM aircraft, aircrafttype

WHERE aircraft.ac_type = aircrafttype.Name AND aircraft.ac_type='АН-140' AND aircraft.Hull_No NOT IN (

SELECT aircraft.Hull_No

FROM aircraft, serv

WHERE serv.Hull_No = aircraft.hull_No AND serv.srvDate not BETWEEN TO_DATE(`1.01.2011', `DD.MM.YYYY) AND TO_DATE(`1.01.2012','DD.MM.YYYY');

);

Висновки

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

Ціллю даної курсової роботи було створення бази даних реєстрації повітряних суден України.

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

Після цього був проведений аналіз ПО в результаті якого був отриманий змістовний опис ПО. Для аналізу ПО використовувалися наявні документи, а саме: журнали реєстрацій суден; правила та загальні пункти реєстрації.

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

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

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

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