Розробка бази данних діяльності магазину "Автозапчастин"
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
Кафедра інформаційних систем
«РОЗРОБКА БАЗИ ДАНИХ ДІЯЛЬНОСТІ МАГАЗИНУ АВТОЗАПЧАСТИН»
Пояснювальна записка до курсового проекту
з дисципліни «Організація баз даних і знань»
Спеціальність
«7.080401 інформаційні управляючі системи та технології»
Студент
Чуркін О.П
Керівник
к.т.н., професор
Степанов В.П
Харків, 2009р.
ВСТУП
Метою створення цього курсового проекту є закріплення теоретичних та практичних знань щодо проектування, розробки та введення в експлуатацію бази даних. Для цього спроектуємо базу даних для віртуального магазину «MotorUA», яке займається продажом та сервісним обслуговування автомобілів. База даних необхідна для обліку та систематизації інформації про робітників даного підприємства, їхніх замовників, створених проектів та проектів що знаходяться у стадії розробки. Також база даних буде потрібна для автоматизації різноманітних бізнес процесів, отримання різноманітних статистичних даних та запитів на отримання необхідної інформації.
Розроблена база даних повинна допомагати в управлінні підприємством шляхом отримання миттєвих відповідей на відіслані запити. Запити можуть стосуватися діяльності як робітників (їх завантаження, тощо), так й різноманітні дані про замовників та їх проекти. Економічний ефект від впровадження бази даних є очевидним, бо автоматизується сам процес отримання різноманітної інформації на ряду зі старовинним збором з паперових архівів.
Для бази даних розробник пред’являє такі вимоги:
інформативність бази даних;
можливість мати резервну копію даних;
забезпечувати одержання загальних або деталізованих звітів за підсумками роботи;
дозволяти легко визначати тенденції зміни найважливіших показників;
забезпечувати одержання інформації, без істотних затримок;
виконувати точний і повний аналіз даних;
захист інформації від несанкціонованого доступу.
Права користувачів бази даних, їх права на різноманітні дії над інформацією буде розглянуте у пункті 7 «Розробка механізмів захисту даних від несанкціонованого доступу».
Сучасні СУБД в основному є додатками Wіndows, тому що дане середовище дозволяє більш повно використовувати можливості персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК обумовив не тільки широкий перехід до середовища Wіndows, де розроблювач програмного забезпечення може в менше ступені піклуватися про розподіл ресурсів, але також зробив програмне забезпечення ПК у цілому й СУБД зокрема менш критичними до апаратних ресурсів ЕОМ.
Серед найбільш яскравих представників систем керування базами даних можна відзначити: Mіcrosoft Access, MySQL, Mіcrosoft SQL Server та Oracle. Саме на останній ми й зупинимось, як на одному з найкращих варіантів, побудованій за технологією «клієнт-сервер», бо на ряду з СУБД, сучасний підхід до керування базами даних має на увазі широке використання технології «клієнт-сервер».
На сьогоднішній день розроблювач не зв'язаний рамками якого-небудь конкретного пакета, а залежно від поставленого завдання може використовувати самі різні додатки.
РОЗДІЛ 1 ВИБІР АВТОМАТИЗУЄМИХ ФУНКЦІЙ ТА ІНФОРМАЦІЙНОГО ЗАБЕСПЕЧЕННЯ
Даний розділ присвячений вибору функції що автоматизуються та інформаційного забезпечення, які виступають за основу для подальшого проектування структури бази даних. В розділі дається короткий опис предметної області; проводиться вибір та опис функції; що автоматизуються виконується опис інформаційного забезпечення.
Короткий опис предметної області
В даному підрозділі дається кроткий опис предметної області, у якому функціонує інформаційна система "Розробка бази даних діяльності підприємства". Описується середовище функціонування, об’єкт і суб’єкт управління, цілі і задачі управління.
1.1.1 Середовище функціонування
Середою функціонування системи "Розробка бази даних діяльності підприємства" є підприємства «MotorUA».
1.1.2 Об’єкт управління
Об’єктом управління виступає процес обліку та систематизації інформації про робітників даного підприємства, їхніх замовників, створених проектів та проектів що знаходяться у стадії розробки.
1.1.3 Суб’єкт управління (управляюча система)
Суб’єктом управління виступає віртуального підприємства «MotorUA», яке займається прокладкою комп'ютерних мереж і розробкою програмних комплексів.
1.1.4 Цілі і задачі управління
Цель управления состоит в обслуживании запросов наибольшего числа пассажиров.
Для достижения этой цели в процессе управления решаются следующие задачи:
В процесі керування можуть бути виконані такі завдання:
ведення обліку працівників;
ведення обліку поставок;
зберігання відомостей щодо замовників;
введення обліку завантаження працівників;
Вибір та опис функцій, що автоматизуються
В даному розділі дається короткий опис чотирьох функцій управляючої системи, які необхідно автоматизувати з використанням інформаційної системи, яка розробляється. Дається перелік об’єктів предметної області, які беруть участь в реалізації функцій, що автоматизуються.
1.2.1 Перелік функцій, що автоматизуються
В рамках даного проекту для автоматизації були вибрані наступні функції:
1) Облік клієнтів
Облік працівників
Облік поставок
1.2.2 Функція 1 – «Облік працівників»
Дана функція необхідна для реалізації отримання інформації про співробітника, його особову інформацію: , ПІП, домашня адреса, досвіт роботи, рік народження, освіта, примітки, фото. В реалізації даної функції приймають учать наступні об’єкти предметної області: співробітник.
Автоматизація даної функції дозволить отримувати повну інформацію про кожного співробітника.
1.2.3 Функція 2 – «Облік клієнтів»
Дана функція необхідна для реалізації обліку клієнтів, та їх особисту інформацію: назва підприємства замовника, телефон, банк, номер рахунку в банку, код ЄДРОПУ, адреса, відповідальний за замовлення, телефон відповідального.
Автоматизація даної функції надасть можливість фіксувати данні про клієнтів фірми.
1.2.4 Функція 3 – «Облік поставок»
Дана функція необхідна для реалізації обліку проектів котрі ведуться магазині автозапчастин.
Автоматизація даної функції дозволить керівництву спостерігати за розвитком проектів проектів.
1.2.6 Перелік об’єктів, які приймають участь в реалізації функцій
Об’єкти предметної області, які беруть участь у реалізації автоматизованих функцій приведені в табл. 1.1.
Таблиця 1.1 Перелік об’єктів, які приймають участь в реалізації функцій
|
№ з/п |
Назва об’єкту |
Опис об’єкту |
Функції |
|||
|
1 |
2 |
3 |
||||
|
1 |
Робітник фірми |
Фізична особа, яке працює у фірмі |
+ |
|||
|
2 |
Замовник |
Фізична або юридична особа, яке дає заказ на розробку проекту |
+ |
+ |
||
|
3 |
Поставка |
Показує дату початку та кінця поставки замовленої запчастини |
+ |
1.3 Первісний опис інформаційного забезпечення
В даному підрозділі подається первісний опис інформаційного забезпечення функцій, які обрані для автоматизації. Інформаційне забезпечення кожної функції у вигляді сукупності атрибутів, необхідних для її здійснення, з вказівкою об’єктів предметної області, яким належать атрибути, зображено в табл. 1.3.
Таблиця 1.3.1 Інформаційне забезпечення функції 1 Облік працівників
|
Об’єкт |
Атрибут |
Опис атрибута |
|
Робітник фірми |
1.1 Прізвище робітника |
|
|
1.2 Ім’я робітника |
||
|
1.3 По батькові робітника |
||
|
1.4 Рік народження |
Освіта(вища, технічна ) Стаж праці робітника Місце проживання робітника |
|
|
1.5 Освіта |
||
|
1.6 Фото |
||
|
1.7 Стаж роботи |
||
|
1.8 Адреса |
Таблиця 1.3.2 Інформаційне забезпечення функції 2 Облік клієнтів
|
Об’єкт |
Атрибут |
Опис атрибута |
|
Замовник |
1.1 назва підприємства |
назва підприємства замовника |
|
1.2 телефон |
Телефон підприємства |
|
|
1.3 банк |
Банк замовника |
|
|
1.4 номер рахунку в банку |
Рахунок у банку Ареса підприємства |
|
|
1.5 код ЄДРОПУ |
||
|
1.6 адреса |
Таблиця 1.3.2 Інформаційне забезпечення функції 2 Облік проектів
|
Об’єкт |
Атрибут |
Опис атрибута |
|
1. Замовник |
1.1 назва підприємства |
назва підприємства замовника |
|
1.2 телефон |
Телефон підприємства |
|
|
1.3 банк |
Банк замовника |
|
|
1.4 номер рахунку в банку |
Рахунок у банку Ареса підприємства |
|
|
1.5 код ЄДРОПУ |
||
|
1.6 адреса |
||
|
2. Поставка |
2.1 Початок поставки |
|
|
2.1 Кінец поставки |
||
|
2.3 Вартість |
Вартість поставки |
|
|
2.3 Керівник |
Керівник продажу |
|
|
2.4 Премія |
Премія, %, при достроковому виконанні |
|
|
2.5 Назва поставки |
Назва поставки Початок участі працівника в поставки |
|
|
3. Розробник |
3.1Початок |
|
|
3.2 Кінець |
1.4 Висновок
В результаті аналізу функціонування автоматизованої системи Розробка бази даних діяльності магазину автозапчастин" було обрано 3 функції, які охвачують дану предметну область.
РОЗДІЛ 2 ПРОЕКТУВАННЯ ЛОКАЛЬНОЇ ER-МОДЕЛІ
Даний розділ присвячено проектуванню локальних ER-МОДЕЛЕЙ, які відповідають окремим функціям що автоматизуються. У розділ проводиться нормалізація локальних ER-моделей, розробляються специфікація обмежень і правил підтримки цілісності для локальных ER-моделей.
2.1 Складання локальної ER-моделі
У даному підрозділі на основі описових моделей даних, отриманих на попередніх етапах проектування, для кожної функції, що автоматизується, будуються початкові концептуальні моделі Entity-relationship (ER-моделі) в графічній формі.
2.2 Нормалізація локальних ER-моделей
У даному підрозділі на основі аналізу та перетворення вихідних ER-моделей для кожної функції що автоматизується будуються нормалізовані ER-моделі, які не містять "прихованих" сутностей.
2.2.1 Функция 1 Облік працівників
Нормалізовану ER-модель для цієї функції, отримана на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.1. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 3.3, присвяченому обмеженням та правилам підтримки цілісності.
2.2.2 Функція 2 “ Облік кліентів ”
Нормалізовану ER-модель для цієї функції, отримано на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.2. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 2.3, присвяченому обмеженням і правилам підтримки цілосності 2.2.2 - нормалізована ER-модель для функції 2 "Надання інформації про діяльність кафедри".
2.2.2 Функція 3 “ Облік поставок ”
Нормалізовану ER-модель для цієї функції, отримано на основі опису, наведеного в попередніх розділах, представлена на малюнку 2.2.3. Відомості про обмеження цілісності, наведені на цьому малюнку, пояснюються нижче в підрозділі 2.3, присвяченому обмеженням і правилам підтримки цілосності 2.2.3 - нормалізована ER-модель для функції 2 " Облік поставок ".
2.3 Висновок
В результаті проектування локальних ER-моделей, відповідних окремим автоматизованим функціям, отримані нормалізовані локальні ER-моделі, що містять сутності в третій нормальній формі. Розроблені специфікації обмежень та правила підтримки цілісності, що містять усі обмеження та правила, отримані на попередньому етапі та трансформовані для локальних ER-моделей.
магазин база дані модель
РОЗДІЛ 3 ПРОЕКТУВАННЯ ГЛОБАЛЬНОЇ ER-МОДЕЛІ
Даний розділ присвячено проектуванню глобальної ER-моделі. В розділ виконується виявлення еквівалентних сутностей і їх злиття. Будується графічне уявлення глобальної моделі.
3.1 Виявлення та відхилення еквівалентних сутностей
В даному підрозділі були виявлені і усунені еквівалентні сутності.
3.2 Графічне уявлення глобальної ER-моделі
В даному підрозділі, в результаті виявленні еквівалентних сутностей та їх злиття, виявлення категорій і синтезу узагальнюючих сутностей, виявлення та усунення дублювання атрибутів, була розроблена глобальна ER модель.
Рис. 3.1 Логічна схема зв’язків
Рис. 3.1 Фізична схема зв’язків
3.3 Класифікація зв'язків
Для побудови інфологічної моделі даних визначимо сутності їхнього зв'язку й атрибути.
Визначимо сутності:
1. поставщіки, які займаються постачанням;
2. замовники, котрі замовляють деталі;
3. деталі, які будуть продані замовнику;
Опишемо атрибути сутностей для кожної окремо:
ПОСТАВЩІКИ (код постачальника, назва, адреса, телефон);
ДЕТАЛІ (код деталі, назва, артикул примітка);
- ЗАМОВНИК (код замовника, торгова марка, діяльність, місце знаходження).
РОЗДІЛ 4 ПРОЕКТУВАННЯ РЕЛЯЦІЙНОЇ SQL-МОДЕЛІ
Даний розділ присвячений проектуванню реляційної SQL-модели. Тут виконується переклад глобальної ER-моделі в реляційну форму, специфікуються обмеження і правила підтримки цілісності на реляційному рівні, записується SQL-код для створення реляційної моделі.
4.1 Функціональні залежності між атрибутами
Наша база даних складається з трьох таблиць. Первинними серед них є DETALI. Вона заповнюються першими. У таблиці – DETALI – зберігаються данні про деталі. У другій – ZAKAZCHIK – зберігається інформація про замовників підприємства.У таблиці POSTAVSHIKI йдеться про причасність робітників магазину до продаваємих деталій. Ця таблиця залежить і від таблиці DETALI.
Установимо функціональні залежності між атрибутами.
ідентифікатор працівника → (ПІП, домашня адреса, досвіт роботи, рік народження, освіта, примітки, фото);
ідентифікатор замовника → (назва підприємства замовника, телефон, банк, номер рахунку в банку, код ЄДРОПУ, адреса, відповідальний за замовлення, телефон відповідального);
ідентифікатор замовника → ідентифікатор проекту (назва проекту, дата початку та кінця проекту, керівник, замовник проекту, вартість розробки та премія за дострокове виконання).
4.2 Вибір ключів
Постачальники (*ідентифікатор постачальника, домашня адреса, досвіт роботи, рік народження, освіта, примітки, фото); Поставка (*ідентифікатор поставки, назва поставки, дата початку та кінця поставки керівник, замовник поставки, вартість поставки); Деталі (*ідентифікатор деталі, назва деталі, артикул, вартість деталі, опис деталі).
4.3 Нормалізація відносин
Ті самі дані можуть групуватися в таблиці (відносини) різними способами, тобто можлива організація різних наборів відносин взаємозалежних інформаційних об'єктів. Угруповання атрибутів у відносинах повинна бути раціональної, тобто зменшуючи дублювання даних і процедури, що спрощує, їхньої обробки й відновлення.
Певний набір відносин має кращі властивості при включенні, модифікації, видаленні даних, чим всі інші можливі набори відносин, якщо він відповідає вимогам нормалізації відносин.
Нормалізація відносин - формальний апарат обмежень на формування відносин (таблиць), що дозволяє усунути дублювання, забезпечує несуперечність збережених у базі даних, зменшує трудозатрати на ведення (уведення, коректування) бази даних.
Поняття третьої нормальної форми ґрунтується на понятті нетранзитивної залежності. Транзитивна залежність спостерігається в тому випадку, якщо один із двох описових реквізитів залежить від ключа, а інший описовий реквізит залежить від першого описового реквізиту.
Відношення буде перебувати в третій нормальній формі, якщо воно перебуває в другій нормальній формі, і кожний не ключовий атрибут нетранзитивно залежить від первинного ключа.
Для усунення транзитивної залежності описових реквізитів необхідно провести "розщеплення" вихідного інформаційного об'єкта. У результаті розщеплення частина реквізитів віддаляється з вихідного інформаційного об'єкта й включається до складу інших (можливо, знову створених) інформаційних об'єктів.
РОЗДІЛ 5 ДАТОЛОГІЧНЕ ПРОЕКТУВАННЯ БД
5.1 Склад таблиць БД
Таблиця 5.1 Атрибути до бази даних
-
№
Найменування атрибутів
Тип
Розмір
Допустимість невизначених значень
1
cust_id
Числовий
3
NOT NULL
2
cust_name
Текстовий
60
3
phone
Текстовий
60
4
bank
Текстовий
60
5
account
Текстовий
20
6
INN
Числовий
8
7
cust_address
Текстовий
60
8
worker_name
Текстовий
60
9
worker_phone
Текстовий
10
10
emp_id
Числовий
3
NOT NULL
11
emp_name
Текстовий
60
12
emp_address
Текстовий
60
13
expeience
Числовий
2
14
date_both
Дата
Авто
15
language
Текстовий
15
16
base
Текстовий
15
17
about
Текстовий
60
18
salary
Грошовий
Авто
19
proj_id
Числовий
3
NOT NULL
20
proj_start
Дата
Авто
21
proj_stop
Дата
Авто
22
chief
Текстовий
60
23
cost
Грошовий
Авто
24
bonus_all
Числовий
Авто
№
Найменування атрибутів
Тип
Розмір
Допустимість невизначених значень
25
proj_name
Текстовий
60
26
num
Числовий
Авто
NOT NULL (Рахівник)
27
emp_stop
Дата
Авто
28
emp_start
Дата
Авто
5.2 Засоби підтримки цілісності
У даному підрозділі для значень атрибутів виявляються обмеження й правила на рівні атрибутів, обраних у попередньому розділі. У першу чергу шляхом аналізу окремих атрибутів визначаються характеристики доменів, з яких атрибути об'єктів, що беруть участь у виконанні автоматизуємих функцій, беруть свої значення. Далі аналізуються можливі змінення значень атрибутів з метою виявлення динамічних обмежень і операційних правил, що ставляться до окремих атрибутів.
Взагалі, у цілісній частині реляційної моделі даних фіксуються дві базових вимоги цілісності, які повинні підтримуватися в будь-який реляційної СУБД. Перша вимога називається вимогою цілісності сутностей. Об'єкту або сутності реального миру в реляційних БД відповідають кортежі відносин. Конкретна вимога полягає в тому, що будь-який кортеж будь-якого відношення відрізнимо від будь-якого іншого кортежу цього відношення, тобто інакше кажучи, будь-яке відношення повинне мати первинний ключ.
Друга вимога називається вимогою цілісності по посиланнях і є трохи більше складним. Очевидно, що при дотриманні нормалізованісті відносин складні сутності реального миру представляються в реляційної БД у вигляді декількох кортежів декількох відносин.
Так, первинним ключем у нас у таблиці «Postavshiki» є атрибут «cod_postavshika», ця таблиця є батьківською для дочірній таблиці «detali» з її первинним ключем «cod_detali»; зв’язуються вони через зовнішній ключ «cod_detali». У таблиці «zakazchiki» первинним ключем є атрибут «cod_zakazchika», звьяхується з таблицєю «Postavshiki» з її первинним ключем «cod_postavshika»; зв’язуються вони через зовнішній ключ. При заповненні полів бази даних існують такі правила.
1) Поля з назвами, заповнюються українськими або англійськими буквами. Перша буква прописна, інші – рядкові); можливі подвійні назви, розділені дефісом; багатослівні назви, розділені пробілами.
2) Адреса записується в такому форматі: країна, індекс, місто, вулиця, номер будинку, номер корпусу, номер квартири.
3) Ідентифікатори розпочинаються з числа 01 та збільшуються на одиницю.
4) Можливі роздільники – пробіли .
5) Дата записується у форматі: д/м/р.
6) Номера телефонів: +(код країни – код міста) номер телефону.
7) Якщо поле розпочинається з букви, то у випадку ім’я власного – перша літера прописна, в іншому – строкова.
РОЗДІЛ 6 ЗАПИТИ ДО БД
В даному пункті відпрацюємо деякі запити, які можуть бути розроблені користувачами бази даних. Складемо такі SQL-запити:
1) Проста вибірка.
2) Вибірка з умовою.
3) Вибірка даних зі зв'язаних таблиць.
4) Вибірка з використанням оператора (природного) з'єднання.
5) Вибірка з використанням шаблона.
1.1) Вивести список робітників, відсортированих за розміром з/п.
1.2) Вивести список замовників підприємства
2.1) Вивести данні по проектам, за дострокове виконання яких замовник сплатить бонусний відсоток.
2.2) Вивести данні працівників, якім не більше 25 років.
3.1) Вивести список компаній, проекти яких знаходяться в розробці.
3.2) Вивести список працівників, які отримують з/п, вищу за середню.
4.1) Вивести розміри річних окладів працівників.
4.2) Вивести данні найстаршого працівника.
5.1) Вивести список замовників, офіс яких розміщується в Харкові.
5.2) Вивести список працівників, у котрих базовою мовою програмування не є PHP.
РОЗДІЛ 7
РОЗРОБКА МЕХАНИЗМІВ ЗАХИСТУ ДАНИХ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ
Захист даних від несанкціонованого доступу припускає введення засобів, що перешкоджають витягу й відновленню даних деякими користувачами. Основний засіб забезпечення цього різновиду захисту даних полягає в тому, що користувачеві надається доступ не до всієї БД, а лише до деяким, певним адміністратором БД, частини даних. При цьому звертання до будь-яких інших даних для зазначеного користувача стає неможливим.
У деяких СУБД утримується додатковий засіб, що складається у визначенні для даних або груп даних замків керування доступом. Тоді звернутися до них зможуть лише ті користувачі, які знають ключі таємності, "відкриваючі" ці замки. Найпростіший варіант замка керування доступом - пароль.
Ще одна можливість захисту даних від несанкціонованого доступу пов'язана з кодуванням даних при відновленні й декодуванні при витягах. При цьому процедури декодування повинні бути доступні не всім користувачам. Перераховані засоби захисту від несанкціонованого доступу звичайно сполучаються: наприклад, на звертання до процедури декодування накладає замок керування доступом.
Крім цього, гарна продумана інформаційна політика безпеки разом з належним навчанням і тренуваннями поліпшать розуміння працівників про належну роботу з корпоративною бізнесом-інформацією. Політика класифікації даних допоможе здійснити належний контроль за розкриттям інформації. Без політики класифікації даних вся внутрішня інформація повинна розглядатися як конфіденційна, якщо не визначено інакше.
Так чином, під час необмеженого допуску до бази даних можливі такі дії над нею:
читання існуючої інформації;
змінення існуючох данних;
добавка нових записів;
видалення полів із записами.
Для захисту інформації від несанкціонованого доступу слід по-перше встановити політику компанії щодо захисту інформації з обмеженим доступом, провести з особовим складом компанії роз’яснювальну роботу щодо збереження даних для автонтифікації користувачів. Також слід розробити ранги доступу, при якому найвищі права надаються адміністратору БД та, наприклад, президенту компанії. Нижче – менеджерам, які вже будуть позбавлені деяких повноважень, ще нижче – рядові службовці, які можуть мати найнижчі права, а саме – перегляд деяких таблиць. Також, можливо примусово позбавити конкретного користувача деяких прав, або навпаки, надати їх.
РОЗДІЛ 8
ВИМОГИ ДО ТЕХНИЧНОГО ЗАБЕЗПЕЧЕННЯ
Передбачається, що база даних буде працювати у режимі клієнт-серверного додатку. Це передбачає, що сама база даних буде знаходитися на сервері, а доступ до її ресурсів буде надходити з клієнтських комп’ютерів користувачів. В такому випадку, слід зазначити, що на сервері повинне бути досить потужне технічне забезпечення, бо йому буде потрібно оброблювати запити, а саме – проводити вибірку інформації з присутньої на необхідну до відповідності з отриманого запиту. Відповідно, вимоги до комп’ютерів користувачів бази даних менш вимогливі. Рекомендовані характеристики ПК наведені нижче:
AMD 2,0 GHz Athlon;
256 Мбайта ОЗП;
2,0 Гбайта зайвого місця на НЖМД;
мережна карта Ethernet 10/100.
РОЗДІЛ 9 ІНСТРУКЦІЯ З ВИКОРИСТАННЯ БД
9.1 Виклик програми
Розроблена база даних зберігається на сервері. Для того щоб користувач міг працювати з базою даних він повинен на своєму персональному ПК запустити утиліту SQLPLUSW.exe, яка входить до програмного комплексу Oracle. Після цього з’явиться вікно для вводу персональних даних
Рис. 9.1 Вікно для входу до бази даних
Після цього треба ввести ім’я, власний пароль та шлях до бази даних, які повинні бути видані адміністратором бази даних.
9.2 Екранні форми
В попередньому пункті було надано вікно для входу в систему. Після того, як користувач введе необхідні данні, вікно може мати такий вигляд
Рис. 9.2. Вікно для входу до бази даних після вводу даних
Після цього, за умови правильно введеного паролю та шляху зв’язку до бази даних, з’являється основне вікно утиліти SQLPLUSW.exe, в якому користувач може вводити SQL-запити, які, при наявності відповідних прав у користувача, можуть бути оброблені. Основне вікно програми наведено нижче.
Рис. 9.3 Основне вікно програми
9.3 Опис звітів
Після написання в вікні програми запит на мові SQL можна отримати у разі правильного набору операторів звіт, який відповідає запиту. Набраний оператором ПК запит буде відправне до серверу. Сервер в свою чергу відпрацює запит та, у відповідності з останнім, відішле на комп’ютер користувача вибірку з бази даних у відповідності з запитом. Вибірка буде представлена у вигляді звіту та відобразиться у робочому вікні утиліти. Отриманий запит може бути отриманий оперативним шляхом, для того щоб переглянути якісь данні, а у разі потреби – збережені у виді текстового файлу. Сам запит та результат його роботи приведені нижче.
Рис. 9.4 Основне вікно програми з запитом та звітом
ВИСНОВОК
На сьогоднішній день реляционные бази даних залишаються найпоширенішими, завдяки своїй простоті й наочності як у процесі створення так і на користувальницькому рівні.
Основним достоїнством реляционных баз даних сумісність із самою популярною мовою запитів SQL. За допомогою єдиного запиту на цій мові можна з'єднати кілька таблиць у тимчасову таблицю й вирізати з її необхідні рядки й стовпці (селекція й проекція). Тому що таблична структура реляционной бази даних інтуїтивно зрозуміла користувачам, те й мова SQL є простим і легенею для вивчення. Реляционная модель має солідний теоретичний фундамент, на якому були засновані еволюція й реалізація реляционных баз даних. На хвилі популярності, викликаної успіхом реляционной моделі, SQL став основною мовою для реляционных баз даних.
У процесі аналізу вищевикладеної інформації виявлені наступні недоліки розглянутої моделі баз даних:
– тому що всі поля однієї таблиці повинні містити постійне число полів заздалегідь певних типів, доводиться створювати додаткові таблиці, що враховують індивідуальні особливості елементів, за допомогою зовнішніх ключів. Такий підхід сильно ускладнює створення скільки-небудь складних взаємозв'язків у базі даних;
– висока трудомісткість маніпулювання інформацією й зміни зв'язків.
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
Конноли Томас. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ.: Уч. пос. – М.: Издательский дом "Вильямс", 2004. – 1120 с.
К. Дж. Дейт. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом "Вильямс", 2003. – 848 с.
Саймон А.Р. Стратегические технологи баз данных: менеджмент на 2005 год. Перевод с англ./ Под ред. и с предисл. М.Р. Когаловского. – М.:
ДСТУ 2874-05. Бази даних. Терміни та визначення. — Київ: Держстандарт України, 2004. - 32 с.
ДСТУ 2940-94. Системи оброблення інформації. Керування процесами оброблення даних. Терміни та визначення. — Київ: Держстандарт України, 2005. - 20 с.
ДОДАТОК А
Файли-скріпти
--del.sql
--скрипт для видалення таблиць
prompt PL/SQL Developer import file
prompt Created on вторник 22 Мая 2009 г. by alan
set feedback off
set define off
prompt Удаление таблицы Postavshiki….
drop table Postavshiki;
prompt Удаление таблицы Detali...
drop table Detali;
prompt Удаление таблицы Zakazchik...
drop table Zakazchik;
prompt Удаление таблицы Postavshiki….
drop table Postavshiki;
prompt Удаление таблицы Detali...
drop table Detali;
prompt Удаление таблицы Zakazchik...
drop table Zakazchik;
prompt Удаление таблицы Postavshiki….
drop table Postavshiki;
prompt Удаление таблицы Detali...
drop table Detali;
prompt Удаление таблицы Zakazchik...
drop table Zakazchik;
--кінець
--my_project.sql
--скрипт для створення таблиць
prompt PL/SQL Developer import file
prompt Created on вторник 22 Мая 2009 г. by alan
set feedback off
set define off
prompt Создаётся таблица Detali...
CREATE TABLE Detali (
kod_detali NUMBER(3) NOT NULL PRIMARY KEY,
nazvanie VARCHAR(60),
articul VARCHAR(20),
primechanie VARCHAR(30),
prompt Создаётся таблица Postavshiki...
CREATE TABLE Postavshiki (
kod_postavshika NUMBER(3) NOT NULL PRIMARY KEY,
nazvanie VARCHAR(60),
adress VARCHAR(20),
telefon NUMBER(15),
prompt Создаётся таблица Zakazchik...
CREATE TABLE Zakazchik (
proj_zakazchika NUMBER(3) NOT NULL PRIMARY KEY,
trade_mark VARCHAR(30),
dejatelnost VARCHAR(50),
raspologenie VARCHAR(33),
--кінець
-add.sql
--скрипт для додавання даних
prompt PL/SQL Developer import file
prompt Created on вторник 22 Мая 2009 г. by alan
set feedback off
set define off
prompt Заполнение таблиц данными...
insert into Detali values (01, Двигун', 'Імпортований', 'Присутній на складі' );
insert into Postavshiki values (11, 'ХарківАвто', 'Пушкінська 91', '312-41-21' );
insert into Zakazchik values (10, 'Helenvagen', 'Німеченна' );
--кінець