Створення реляційної бази даних
Опис предметної області та середовища розробки бази даних. Модель реальної системи - ієрархія діаграм DFD. Складання таблиці списку подій. Переробка ERD в реляційне відношення клієнтів, постачальників та автомобілів. Створення ключових полів таблиць БД.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | украинский |
Дата добавления | 04.02.2013 |
Размер файла | 606,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Вступ
Для початку нам необхідно розібратися, що таке «база даних» та для чого вона потрібна. У загальному розумінні, база даних - це сукупність відомостей про конкретні об'єкти реального світу в будь-якій предметній області, чи розділі предметної області. Кожна база даних - це сукупність таблиць, запросів, форм, звітів, макросів та модулей, яка зберігається в якомусь конкретному файлі з довільним ім'ям. Необхідно також знати, що база даних - це сукупність даних, які організовані чітко згідно конкретним правилам, які передбачають загальні принципи опису, зберігання та маніпулювання даними.
Також необхідно відповісти на питання «для чого потрібна база даних?», адже якщо не знати навіщо ми це робимо - то й робити непотрібно..
Вважають, що використання концепції бази даних дозволяє:
1. Збільшити надійність цілісності та збереження даних;
2. Зберегти витрати інтелектуальної роботи;
3. Забезпечити легкість та простоту використання даних;
4. Забезпечити незалежність прикладних програм від даних (зміни їх описів та засобів
зберігання);
5. Забезпечити достовірність даних;
6. Забезпечити необхідну швидкість доступу до даних;
7. Стандартизувати дані у межах однієї предметної області;
8. Автоматизувати реорганізацію даних;
9. Забезпечити захист від ушкодження та знищення даних;
10. Скоротити дублювання інформації за рахунок структуювання даних;
11. Забезпечити обробку незапланованих запросів до зберігаємої інформації.
1. Теоретична частина
1.1 Опис предметної області
Фабрика отримує запит на виготовлення автомобілів від клієнтів. Запити розглядаються адміністрацією фабрики, використовуючи інформацію про запчастини для авто. та самі автомобілі(марка авто.). Перевіряються і обновляються списки про кількість запчастин для авто. на фабриці. Адміністрація перевіряє, щоб кількість запчастин відповідала необхідній кількості для виконання замовлення і збірки автомобіля(вибраної марки). Робота фабрики відбувається наступним чином: клієнт робить замовлення на виготовлення автомобіля(деякої марки), адміністрація фабрики перевіряє свої списки і видає клієнту інформацію про можливість виконання замовлення. На фабриці зберігається інформація про запчастини: назва,країна виробник,рівень якості, тип, період експлуатації ,ціна;про автомобілі(різних марок):,малюнок, колір, гама, технічні характеристики, ціна. Фабрика отримує від постачальників необхідні запчастини і при отриманні обновляє списки доступних запчастин.
1.2 Опис середовища розробки курсової роботи
OraDeveloper Studio спрощує роботу з Oracle, автоматизує рутинні завдання з розробки і полегшує управління великими проектами. OraDeveloper Studio - окремий додаток, призначений для професійних розробників PL/SQL і користувачів Oracle, які шукають більш гнучке середовище розробки баз даних. Основні переваги OraDeveloper Studio:
- Зручна навігація по базі даних
- Об'єкти на сервері представлені в спеціальному вікні Провідника в ієрархічному виді, зручні для роботи.
- Будь-який об'єкт бази даних можна знайти, проаналізувавши і змінивши за декілька секунд.
- Провідник відображає залежності між об'єктами БД і зберігає історію навігації, яка дозволяє легко повернутися до відвідуваних об'єктам і папкам.
- Властивості будь-якого об'єкта БД можна побачити за один щиглик.
- Можна швидко отримати дані з таблиць або уявлень, вибравши їх в Провіднику.
- OraDeveloper Studio також дозволяє шукати об'єкти БД будь-якого типу на сервері за його ім'ям.
- PL/SQL об'єкти можна шукати за фрагментом коду. Можна також шукати дані в таблицях, і матеріалізованих уявленнях.
- Полегшене створення та зміна об'єктів БД.
З OraDeveloper Studio не потребує багато часу на зміну структури БД. OraDeveloper Studio автоматизує всі часто використовувані операції.
Для забезпечення дружнього користувацького інтерфейсу при роботі з об'єктами БД створені спеціалізовані візуальні редактори об'єктів.
OraDeveloper Studio дозволяє проглядати всі об'єкти БД як вирази DDL, створювати і редагувати DDL-скрипти для багатьох об'єктів БД.
- Можна легко створювати копії об'єктів БД.
- Налагодження PL/SQL об'єктів и SQL скриптів.
Вбудований наладчик дозволяє налагоджувати всі види PL/SQL об'єктів і SQL скриптів.
OraDeveloper Studio дозволяє встановлювати крапки зупинки на будь-якому рядку коду.
В вікні Стек Викликів можна продивлятися поточний стек PL/SQL програм. Можна також продивлятися і модифікувати змінні в вікні Змінні.
- Прямий доступ до сервера
OraDeveloper Studio може працювати з сервером Oracle навіть без встановленого Oracle Client Software.
2. Практична частина
Модель реальної системи визначається як ієрархія діаграм DFD, які описують асинхронний процес перетворення інформації від її входу в систему до видачі користувачам. Діаграми верхніх рівнів ієрархії (контекстні діаграми) виділяють основні процеси або підсистеми з зовнішніми виходами і входами. Вони деталізуються до тих пір,доки не буде досягнутий такий рівень декомпонізації,на якому процес стає елементарним і надалі його деталізувати неможливо.
Особливістю складної системи є велика кількість сутностей(більше 10),розподілена природа системи.
2.1 Концептуальна модель
Рис. 1- DFD діаграма 0-го рівня
2.2 Складання таблиці ELM
Список подій (ELM) - матриця, яка описує дії зовнішніх сутностей і реакцію системи на них.
Таблиця 1. ELM - матриця
П/н |
Опис події |
Тип |
Реакція системи |
|
1 |
Клієнт звертається на фабрику |
ND |
Реєстрація клієнта |
|
2 |
Зміна даних клієнта |
ND |
Реєстрація нових даних для клієнта |
|
3 |
Надходження нових запчастин від постачальника |
ND |
Додавання даних про запчастини |
|
4 |
Подача замовлення постачальнику на нові запчастини |
ND |
Формування списку потрібних запчастин, відправка постачальнику |
|
5 |
Керівництво запитує звіт |
ND |
Формування звіту,відправка керівництву |
|
6 |
Поява нового постачальника |
ND |
Реєстрація постачальника |
|
7 |
Зміна даних постачальника |
ND |
Реєстрація нових даних |
Реакція системи - вихідний потік. Один абстрактний потік може бути розділений на декілька конкретних потоків.
Таблиця 2. Потоки подій на DFD 0-го рівня
Абстрактний потік |
Конкретний потік |
|
Інформація від клієнта |
Реєстраційні дані Запит о запчастинах і їх вартості Замовлення запчастин |
|
Інформація для клієнта |
Відповідь на запит про запчастини і їх вартість |
|
Інформація від постачальника |
Реєстраційні дані Дані по запиту на постачання запчастин |
|
Інформація для постачальника |
Запит на постачання запчастин |
|
Інформація від керівництва |
Запити звітів про клієнтів, постачальників, автомобілів(різних марок) і запчастин |
|
Інформація для керівництва |
Звіти про клієнтів ,постачальників ,автомобілів(різних марок) і запчастин для них |
2.3 Побудова DFD- діаграми 1-го рівня
Рис.2 DFD- діаграма 1-го рівня
3. ERD - Діаграма
Реляційна БД має як структурну, так і семантичну інформацію. Структура БД визначається числом і видом включених у неї відношень, і зв'язками типу «один до багатьох», існуючими між кортежами цих відношень.
3.1 Побудова ERD
Якщо клієнт подає замовлення на фабрику, то може замовити не тільки одне авто ,а декілька одночасно,різні клієнти можуть замовляти точно те ж саме авто, тому зв'язок між сутностями Клієнт і Автомобіль має ступінь N:N. Таке відношення реалізувати не можливо, тому проводиться нормалізація. Додаємо нову сутність - замовлення автомобіля.
Один клієнт може робити декілька замовлень, тому зв'язок між сутностями Клієнт і Запчастини буде 1: N.
В одне замовлення може бути включено декілька автомобілів, тому зв'язок між сутностями Замовлення автомобілів і Автомобіль буде 1: N.
Оскільки при збірці автомобіля деякі запчастини можуть підходити не тільки для одного, а для декількох типів автомобілів одночасно, і одні і ті ж самі запчастини можуть входити у різні автомобілі, тому зв'язок між сутностями Автомобіль і Запчастини має ступінь N:N. Таке відношення реалізувати не можливо, тому проводиться нормалізація. Додаємо нову сутність - склад Автомобіля(тобто враховуємо усі запчастини які взяті з інших марок автомобіля).
Один автомобіль може складатися з декількох видів запчастин, тому зв'язок між сутностями Склад автомобіля і Автомобіль буде 1:N.
Одна запчастина може входити до різних складів автомобіля, тому зв'язок між сутностями Склад автомобіля і Запчастина буде 1:N.
Один постачальник може поставляти декілька видів запчастин, і один і той самий вид запчастин може постачатися різними постачальниками, тому зв'язок між сутностями N:N. Таке відношення реалізувати не можливо, тому проводиться нормалізація. Додаємо нову сутність - замовлення запчастин.
Декілька різних постачальників можуть постачати запчастини для одного замовлення, тому зв'язок між сутностями Замовленням запчастин і Постачальниками 1:N. база дані таблиця реляційний
Одне замовлення може складатися з декількох видів запчастин, тому зв'язок між сутностями Замовлення запчастин і Запчастина 1:N.
Рис.3 ERD - діаграма
3.2 Переробка ERD в реляційне відношення
Клієнт(#ID клієнта, Назва, Адреса, Телефон, Факс, E-mail, Кількість звернень, Розрахунковий рахунок);
Постачальник(#ID постачальника, Назва, Адреса, Телефон, Факс, E-mail, Дата реєстрації, Розрахунковий рахунок);
Автомобіль(#ID автомобіля, #ID складу, Назва,Марка, Технічні характеристики, Колір, Гама, Розмір, Ціна);
Запчастини(#ID запчастини, Назва, Країна виробник, Рівень якості,Період експлуатації, Тип, Ціна);
Замовлення Автомобіля(#ID клієнта, #ID автомобіля, Назва, Марка, Кількість , Дата замовлення, Дата кінця замовлення);
Склад Автомобіля(#ID Автосалону, #ID запчастин);
Замовлення запчастин(#ID замовлення, #ID постачальника, #ID запчастини, Назва, Кількість);
4. Практична частина
4.1 Створення таблиць баз даних
Створюємо необхідні для бази даних таблиці:
Створюємо таблицю Клієнт:
Create table A_Avto_Klients
(ID_Клієнта NUMBER(4),
Назва Varchar2(20),
Адреса Varchar2(20),
Телефон NUMBER(8),
Факс NUMBER(15),
Mail Varchar2(20),
Кількість_звернень NUMBER(4),
Розрахунковий_рахунок VARCHAR2(20));
Створюємо таблицю Постачальник:
Create table A_Avto_Postavshik
(
P_ID_постачальника number(2),
P_Назва varchar2(20),
P_Адреса varchar2(20),
P_Телефон number(8),
P_Факс Number (8),
P_Mail varchar2(20),
P_Дата_реєстрації DATE,
P_Розрахунковий_рахунок varchar2(20)
);
Створюємо таблицю Автомобіль:
Create table Avto
(K_ID_автомобіля Number(2),
K_ID_автосалону Number(2),
K_Назва Varchar2(20),
K_Малюнок Varchar2(20),
K_Колір Varchar2(20),
K_Гама Varchar2(20),
K_Технічні_характеристики Varchar2(20),
K_Ціна Number(5)
);
Створюємо таблицю Запчастини:
Create table A_Avto_Zapchasti
(
N_ID_запчастини Number(2),
N_Назва varchar2(20),
N_Країна_виробник varchar2(20),
N_Рівень_якості Number(2),
N_Тип varchar2(20),
N_Період_експлуатації varchar2(20) ,
N_Ціна Number(5),
N_В яких_марках_використовується varchar2(30)
);
Створюємо таблицю Замовлення автомобіля:
Create table A_Avto_Zakaz_avto
(Z_ID_замовлення number(2),
Z_ID_клієнта number(2),
Z_ID_автомобіля number(2),
Z_Назва Varchar2(20),
Z_Кількість number(5),
Z_Дата_замовлення DATE,
Z_Дата_кінця_замовлення DATE
);
Створюємо таблицю Склад автомобіля:
Create tableA_Avto_Sostav_avto
(S_ID_складу number(2),
S_ID_запчастини number(2),
Кількість number(4));
Створюємо таблицю Замовлення запчастини:
Create table A_Avto_Zamovlenua_zapchastey
(
AD_ID_замовлення number(2),
AD_ID_постачальника number(2) ,
AD_ID_запчастини number(2),
AD_Назва varchar2(20),
AD_Кількість number(10)
);
4.2 Створення ключових полів таблиць БД
У чотирьох таблицях необхідно задати ключові поля:
Для таблиці Автомобіль - це поле K_ID_АВТОМОБІЛЯ:
ALTER TABLE Avto
ADD (CONSTRAINT Avto_pkey PRIMARY KEY(K_ID_АВТОМОБІЛЯ));
Для таблиці Запчастина - це поле N_ID_ЗАПЧАСТИНИ:
ALTER TABLE A_Avto_Zapchasti
ADD (CONSTRAINT A_Avto_Zapchasti_pkey PRIMARY KEY(N_ID_ЗАПЧАСТИНИ));
Для таблиці Постачальник - це поле P_ID_ПОСТАЧАЛЬНИКА:
ALTER TABLE A_Avto_postavshik
ADD (CONSTRAINT A_Avto_postavshik_pkey PRIMARY KEY(P_ID_ПОСТАЧ));
Для таблиці Клієнт - це поле ID_КЛІЄНТА:
ALTER TABLE A_Avto_KLIENTS
ADD (CONSTRAINT A_Avto_KLIENTS_pkey PRIMARY KEY(ID_КЛІЄНТА));
4.3 Заповнення таблиць баз даних
Заповнюємо таблицю Клієнти:
INSERT INTO A_Avto_KLIENTS
(ID_КЛІЄНТА,НАЗВА,АДРЕСА,ТЕЛЕФОН,ФАКС,MAIL,КІЛ_ЗВЕР,РОЗРАХ_РАХУНОК)
VALUES
(8,'Пул В.С.', 'Тітова 12',7445632,87657665,'Avto@mail.ru',4,'as13565456h');
Вигляд заповненої таблиці:
Заповнюємо таблицю Автомобіль:
INSERT INTO AVTO
(K_ID_АВТОМОБІЛЯ,K_ID_АВТОСАЛОНУ,K_НАЗВА,K_МАЛЮНОК,K_КОЛІР,K_ГАМА,K_ТЕХНІЧНІ_ХАР,K_ЦІНА)
VALUES (1,1,'ВаЗ','нет','Синій','Синьовата','70hp',100);
Вигляд заповненої таблиці:
Заповнюємо таблицю Запчастини:
INSERT INTO A_Avto_ZAPCHASTI
(N_ID_ЗАПЧАСТИНИ,N_НАЗВА,N_КРАЇНА_ВИР,N_РІВЕНЬ_ЯКОСТІ,N_ТИП,N_ПЕРІОД_ЕКСП, N_ЦІНА)
VALUES (4,'Тормоза','Китай',10,'Дискові','4 роки',200);
Вигляд заповненої таблиці:
Заповнюємо таблицю Постачальник:
INSERT INTO A_Avto_POSTAVSHIK
(P_ID_ПОСТАЧ,P_НАЗВА,P_АДРЕСА,P_ТЕЛЕФОН,P_ФАКС,P_MAIL,P_ДАТА_РЕЄСТР,P_РОЗ_РАХ)
VALUES
(17,'Сурич В.В.','Кірова 10',674581,57587687,'Su@mail.ru','12/10/07','re172467868131u');
Вигляд заповненої таблиці:
Заповнюємо таблицю Склад автомобілів:
INSERT INTO A_Avto_SOSTAV_AVTO
(S_ID_СКЛАДУ,S_ID_ЗАПЧАСТИНИ, КІЛЬКІСТЬ)
VALUES (1,1,3);
Вигляд заповненої таблиці:
Заповнюємо таблицю Замовлення автомобіля:
INSERT INTO A_Avto_ZAKAZ_AVTO
(Z_ID_ЗАМОВЛЕННЯ,Z_ID_КЛІЄНТА,Z_ID_АВТОМОБІЛЯ,Z_НАЗВА, Z_КІЛЬКІСТЬ,Z_ДАТА_ЗАМ,Z_ДАТА_КІН_ЗАМ)
VALUES (12,1,1,'Рудь Б.В.',1,'3/10/08','10/11/08');
Вигляд заповненої таблиці:
Заповнюємо таблицю Замовлення запчастини:
INSERT INTO A_Avto_ZAMOVLENUA_ZAPCHASTEY
(AD_ID_замовл, AD_ID_постач, AD_ID_запча, AD_Назва,AD_Кількість)
VALUES (1,12,20,'Двигун',5);
Вигляд заповненої таблиці:
4.4 Створення запитів
1.Вивести всі активні замовлення за період починаючи з(наприклад '7/11/08'):
select distinct Z_ID_ЗАМОВЛЕННЯ from A_Avto_Zakaz_Avto where (Z_ДАТА_КІН_ЗАМ >'7/11/08')
Приклад роботи:
2.Вивести всі виконані закази за даний період:
select distinct Z_ID_ЗАМОВЛЕННЯ from A_Avto_Zakaz_Avto where (Z_ДАТА_КІН_ЗАМ >'7/11/08')
and ('18/11/08'>Z_ДАТА_КІН_ЗАМ)
Приклад роботи:
3. Вивести усіх клієнтів, які зверталися на фабрику більше 4-х разів:
select ID_КЛІЄНТА,НАЗВА,АДРЕСА from KLIENTS where КІЛ_ЗВЕР>=4
Приклад роботи:
Висновок
В ході виконання цієї роботи була виконана головна задача, а саме - створення реляційної бази даних. Вміння створювати та працювати з реляційною базою даних є дуже важливим, оскільки реляційні бази даних дозволяють складними та цікавими способами маніпулювати даними таким чином, що можна буде обирати усі записи, які відповідають конкретному критерію, посилатися з одних таблиць на інші та редагувати усі записи одночасно. Вагомою перевагою реляційної бази даних є висока швидкість пошуку, яка наглядно була застосована в практичних завданнях , де відбувалася обробка великої кількості даних.
Для розробки свого курсового проекту я обрала середовище OraDeveloper Studio. Бо, як на мене, вона має досить вагомі переваги перед іншими середовищами розробками бази даних, а саме: легка маніпуляція даними (що буває дуже корисним при великих обсягах даних), можливість масштабованості бази даних (дуже корисна можливість - замість створення нової бази даних, можна розширити вже існуючу, що буде гарантувати збереження старих даних та економію часу), велика продуктивність , зручна навігація, швидкий доступ до даних таблиць - все це набагато спрощує роботу з базою даних. А також з'явилася можливість користуватися OraDeveloper Studio з сервером Oracle без встановленого Oracle Client Software.
Список використаної літератури:
1. Курс лабораторных работ по РСУБД Oracle.
2. К.Бегг «Основи баз даних».
3. Грофф «Енциклопедія SQL».
4. http://www.oracle.com/global/ru/pdfs/tech/techguide_rdb.pdf
5. http://www.sdteam.com/?tid=1858
6. «За рулем» 2005г,
7. www.oracle.com/technology/smb
Размещено на Allbest.ru
Подобные документы
Основні відомості про реляційні бази даних, система управління ними. Основні директиви для роботи в середовищі MySQ. Визначення та опис предметної області. Створення таблиць та запитів бази даних автоматизованої бази даних реєстратури в поліклініці.
курсовая работа [2,9 M], добавлен 06.11.2011Проектування бази даних, що реалізує звіти про графік робіт на об’єктах впродовж місяця. Графічне зображення нагромаджувачів даних. Побудова діаграм потоків даних і переходів станів, таблиць у вигляді двовимірного масиву, запитів. Створення бази даних.
курсовая работа [1,2 M], добавлен 29.02.2012Створення баз даних і введення даних. Створення бази даних за допомогою майстра. Створення таблиць. Створення таблиці в режимі конструктора. Створення запитів за допомогою майстра. Додавання полів у бланк запиту. Зміна порядку полів.
реферат [17,1 K], добавлен 07.10.2004Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.
курсовая работа [147,2 K], добавлен 02.06.2019Визначення мети створення бази даних магазину та таблиць, які вона повинна містити. Розгляд видів полів та ключів таблиць. Створення запитів, форм, звітів, макросів та модулів. Вибір системи управління базами даних. Реалізація моделі у Microsoft Access.
курсовая работа [3,8 M], добавлен 20.07.2014Створення інформаційних таблиць бази даних. Створення екранних форм як засобу організації інтерфейсу користувача. Створення запитів для вибору, сортування і обчислення з використанням даних однієї таблиці. Оформлення звітів за допомогою команд MS Access.
лабораторная работа [397,7 K], добавлен 09.09.2010Загальний склад, структура таблиць та бази даних, опис інформаційних полів структури таблиць, головних процедур. Розробка інструкцій: адміністратору, менеджеру, користувачу, гостю. Собівартість, ціна розробки бази даних реалізації косметичної продукції.
курсовая работа [4,6 M], добавлен 14.10.2014Поняття та переваги реляційної бази, автоматизація аналізу даних. Опис основних компонентів сховища даних AS/400. Процес перетворення оперативних даних в інформаційні. Багатовимірні бази даних (MDD). Опис даних і створення файлів в інтеграційних базах.
реферат [36,8 K], добавлен 14.01.2012Виявлення основних сутностей предметної області. Побудова схеми реляційної бази даних. Вбудовані процедури і тригери. Опис архітектури програмної системи і концептуальної моделі бази даних, програмної реалізації та інтерфейсу користувача додатку.
курсовая работа [4,3 M], добавлен 05.12.2012Систематизація знань як основна функція бази даних. Логічне та фізичне проектування бази даних. Створення таблиць у базі даних, визначення основних зв'язків. Інструментальні засоби проектування та створення програмного забезпечення для обробки даних.
курсовая работа [1,4 M], добавлен 29.04.2010