МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
Кафедра інформаційних систем
«РОЗРОБКА БАЗИ ДАНИХ ДІЯЛЬНОСТІ МАГАЗИНУ АВТОЗАПЧАСТИН»
Пояснювальна записка до курсового проекту
з дисципліни «Організація баз даних і знань»
Спеціальність
«7.080401 інформаційні управляючі системи татехнології»
Студент
Чуркін О.П
Керівник
к.т.н., професор
Степанов В.П
Харків, 2009р.
ВСТУП
Метоюстворення цього курсового проекту є закріплення теоретичних та практичних знаньщодо проектування, розробки та введення в експлуатацію бази даних. Для цьогоспроектуємо базу даних для віртуального магазину «MotorUA», яке займається продажом тасервісним обслуговування автомобілів. База даних необхідна для обліку тасистематизації інформації про робітників даного підприємства, їхніх замовників,створених проектів та проектів що знаходяться у стадії розробки. Також базаданих буде потрібна для автоматизації різноманітних бізнес процесів, отримання різноманітнихстатистичних даних та запитів на отримання необхідної інформації.
Розробленабаза даних повинна допомагати в управлінні підприємством шляхом отриманнямиттєвих відповідей на відіслані запити. Запити можуть стосуватися діяльностіяк робітників (їх завантаження, тощо), так й різноманітні дані про замовниківта їх проекти. Економічний ефект від впровадження бази даних є очевидним, боавтоматизується сам процес отримання різноманітної інформації на ряду зістаровинним збором з паперових архівів.
Длябази даних розробник пред’являє такі вимоги:
- інформативністьбази даних;
- можливістьмати резервну копію даних;
- забезпечуватиодержання загальних або деталізованих звітів за підсумками роботи;
- дозволятилегко визначати тенденції зміни найважливіших показників;
- забезпечуватиодержання інформації, без істотних затримок;
- виконуватиточний і повний аналіз даних;
- захистінформації від несанкціонованого доступу.
Правакористувачів бази даних, їх права на різноманітні дії над інформацією будерозглянуте у пункті 7 «Розробка механізмів захисту даних від несанкціонованогодоступу».
СучасніСУБД в основному є додатками Wіndows, тому що дане середовище дозволяє більшповно використовувати можливості персональної ЕОМ, ніж середовище DOS. Зниженнявартості високопродуктивних ПК обумовив не тільки широкий перехід до середовищаWіndows, де розроблювач програмного забезпечення може в менше ступеніпіклуватися про розподіл ресурсів, але також зробив програмне забезпечення ПК уцілому й СУБД зокрема менш критичними до апаратних ресурсів ЕОМ.
Середнайбільш яскравих представників систем керування базами даних можна відзначити:Mіcrosoft Access, MySQL, MіcrosoftSQL Server та Oracle. Саме на останній ми й зупинимось, як на одному знайкращих варіантів, побудованій за технологією «клієнт-сервер», бо на ряду зСУБД, сучасний підхід до керування базами даних має на увазі широкевикористання технології «клієнт-сервер».
Насьогоднішній день розроблювач не зв'язаний рамками якого-небудь конкретногопакета, а залежно від поставленого завдання може використовувати самі різнідодатки.
РОЗДІЛ 1 ВИБІРАВТОМАТИЗУЄМИХ ФУНКЦІЙ ТА ІНФОРМАЦІЙНОГО ЗАБЕСПЕЧЕННЯ
Даний розділприсвячений вибору функції що автоматизуються та інформаційного забезпечення,які виступають за основу для подальшого проектування структури бази даних. Врозділі дається короткий опис предметної області; проводиться вибір та описфункції; що автоматизуються виконується опис інформаційного забезпечення.
1.1 Короткий опис предметної області
Вданому підрозділі дається кроткий опис предметної області, у якому функціонуєінформаційна система «Розробка бази даних діяльностіпідприємства». Описується середовищефункціонування, об’єкт і суб’єкт управління, цілі і задачі управління.
1.1.1 Середовищефункціонування
Середоюфункціонування системи «Розробка бази даних діяльності підприємства»є підприємства «MotorUA».
1.1.2 Об’єктуправління
Об’єктомуправління виступає процес обліку та систематизації інформації про робітниківданого підприємства, їхніх замовників, створених проектів та проектів щознаходяться у стадії розробки.
1.1.3 Суб’єктуправління (управляюча система)
Суб’єктомуправління виступає віртуального підприємства «MotorUA», яке займається прокладкою комп'ютернихмереж і розробкою програмних комплексів.
1.1.4 Цілі ізадачі управління
Цель управления состоит вобслуживании запросов наибольшего числа пассажиров.
Для достижения этой целив процессе управления решаются следующие задачи:
Впроцесі керування можуть бути виконані такі завдання:
1. веденняобліку працівників;
2. веденняобліку поставок;
3. зберіганнявідомостей щодо замовників;
4. введенняобліку завантаження працівників;
1.2 Вибір та опис функцій, що автоматизуються
В даному розділідається короткий опис чотирьох функцій управляючої системи, які необхідноавтоматизувати з використанням інформаційної системи, яка розробляється.Дається перелік об’єктів предметної області, які беруть участь в реалізаціїфункцій, що автоматизуються.
1.2.1 Перелік функцій,що автоматизуються
В рамках даногопроекту для автоматизації були вибрані наступні функції:
1) Облік клієнтів
2) Облікпрацівників
3) Облікпоставок
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
ВИМОГИДО ТЕХНИЧНОГО ЗАБЕЗПЕЧЕННЯ
Передбачається,що база даних буде працювати у режимі клієнт-серверного додатку. Це передбачає,що сама база даних буде знаходитися на сервері, а доступ до її ресурсів буденадходити з клієнтських комп’ютерів користувачів. В такому випадку, слідзазначити, що на сервері повинне бути досить потужне технічне забезпечення, бойому буде потрібно оброблювати запити, а саме – проводити вибірку інформації зприсутньої на необхідну до відповідності з отриманого запиту. Відповідно,вимоги до комп’ютерів користувачів бази даних менш вимогливі. Рекомендованіхарактеристики ПК наведені нижче:
- AMD2,0 GHz Athlon;
- 256 Мбайта ОЗП;
- 2,0 Гбайта зайвого місця на НЖМД;
- мережнакарта Ethernet10/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 став основноюмовою для реляционных баз даних.
Упроцесі аналізу вищевикладеної інформації виявлені наступні недолікирозглянутої моделі баз даних:
–тому що всі поля однієї таблиці повинні міститипостійне число полів заздалегідь певних типів, доводиться створювати додатковітаблиці, що враховують індивідуальні особливості елементів, за допомогоюзовнішніх ключів. Такий підхід сильно ускладнює створення скільки-небудьскладних взаємозв'язків у базі даних;
–висока трудомісткість маніпулювання інформацією й зміни зв'язків.
СПИСОК ВИКОРИСТАНОЇЛІТЕРАТУРИ
1. Конноли Томас.Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-еизд.: Пер. с англ.: Уч. пос. – М.: Издательский дом «Вильямс», 2004. – 1120 с.
2. К. Дж. Дейт.Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.:Издательский дом «Вильямс», 2003. – 848 с.
3. Саймон А.Р.Стратегические технологи баз данных: менеджмент на 2005 год. Перевод с англ./ Под ред. и с предисл. М.Р.Когаловского. – М.:
4. ДСТУ 2874-05. Бази даних. Терміни та визначення.— Київ: Держстандарт України, 2004. — 32 с.
5. ДСТУ 2940-94.Системи оброблення інформації. Керування процесами оброблення даних. Терміни тавизначення. — Київ: Держстандарт України, 2005. — 20с.
ДОДАТОКА
Файли-скріпти
--del.sql
--скриптдля видалення таблиць
promptPL/SQL Developer import file
promptCreated on вторник 22 Мая 2009 г. by alan
setfeedback off
setdefine off
promptУдаление таблицы Postavshiki….
droptable Postavshiki;
promptУдаление таблицы Detali...
droptable Detali;
promptУдаление таблицы Zakazchik...
droptable Zakazchik;
promptУдаление таблицы Postavshiki….
droptable Postavshiki;
promptУдаление таблицы Detali...
droptable Detali;
promptУдаление таблицы Zakazchik...
droptable Zakazchik;
promptУдаление таблицы Postavshiki….
droptable Postavshiki;
promptУдаление таблицы Detali...
droptable Detali;
promptУдаление таблицы Zakazchik...
droptable Zakazchik;
--кінець
--my_project.sql
--скриптдля створення таблиць
promptPL/SQL Developer import file
promptCreated on вторник 22 Мая 2009 г. by alan
setfeedback off
setdefine off
promptСоздаётся таблица Detali...
CREATETABLE Detali (
kod_detali NUMBER(3)NOT NULL PRIMARY KEY,
nazvanieVARCHAR(60),
articulVARCHAR(20),
primechanie VARCHAR(30),
promptСоздаётся таблица Postavshiki...
CREATETABLE Postavshiki (
kod_postavshika NUMBER(3) NOT NULL PRIMARY KEY,
nazvanieVARCHAR(60),
adress VARCHAR(20),
telefon NUMBER(15),
promptСоздаётся таблица Zakazchik...
CREATETABLE Zakazchik (
proj_zakazchika NUMBER(3) NOT NULL PRIMARY KEY,
trade_mark VARCHAR(30),
dejatelnost VARCHAR(50),
raspologenie VARCHAR(33),
--кінець
-add.sql
--скриптдля додавання даних
promptPL/SQL Developer import file
promptCreated on вторник 22 Мая 2009 г. by alan
setfeedback off
setdefine off
promptЗаполнение таблиц данными...
insertinto Detali values (01, Двигун','Імпортований', 'Присутній на складі' );
insertinto Postavshiki values (11, 'ХарківАвто','Пушкінська 91', '312-41-21' );
insertinto Zakazchik values (10, 'Helenvagen', 'Німеченна' );
--кінець