Ім'я файлу: Курсовая ОБД Стуров (изменено).docx
Розширення: docx
Розмір: 512кб.
Дата: 12.06.2022
скачати
Пов'язані файли:
Пр№1-2. УБВ. Рудницький І.І. БТ-307Б.docx
vdoc.pub_categories.docx
Лекція 10 (1).doc
контрольна Логістика.doc

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

ІМЕНІ ОЛЕСЯ ГОНЧАРА

Кафедра електронних обчислювальних машин

КУРСОВА РОБОТА

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

С тудента 3 курсу групи КІ – 19 – 1

спеціальність «Комп’ютерна інженерія»

С
(прізвище та ініціали)
турова Ю.В.

К ерiвник: Герасимов В.В.

К ількість балів

Н аціональна шкала

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

А
(підпис)
хметшина.Л.Г.

Г
(підпис)
ерасимов В.В.


(підпис)
 Спиринцева О.В.

м. Дніпро

2021р.

РЕФЕРАТ


Курсова робота: с.35 , рис. 27, джерел 7, додатки 1.

Об’єктом дослідження є бази даних (БД), система управління базами даних (СУБД) Microsoft – SQL Server.

Предметом дослідження – розробка та нормалізація реляційної БД, створення запитів, подань та тригерів на мові SQL.

Мета роботи – розробити БД з предметної області.

Одержані висновки: розроблено і створено реляційну модель БД в НФБК.

Перелік ключових слів: СУБД, БД, РБД, НОРМАЛІЗАЦІЯ.

ЗМІСТ


РЕФЕРАТ 2

ВСТУП 3

ЗАВДАННЯ НА КУРСОВУ РОБОТУ 4

1.ТЕОРЕТИЧНА ЧАСТИНА 6

1.1Основні поняття 6

1.2 СКБД 6

1.3 Розробка БД 8

1.4 Нормалізація 9

1.5 Запити і подання 11

1.6 Обмеження цілісності даних 12

1.7 Тригери 12

2.ПРАКТИЧНА ЧАСТИНА 14

2.1 Створення БД 14

2.2 Створення таблиць 17

2.3Створення обмеженнь 19

2.4 Створення зв’язків 20

2.5 Створення запитів 22

2.6 Створення подань 25

2.5Створення тригерів 27

ВИСНОВКИ 30

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ 31

ДОДАТОК А 32

Лістинг 1 32



ВСТУП


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

SQL — це діалогова мова програмування для здійснення запиту і внесення змін до бази даних, а також управління базами даних. Багато баз даних підтримує SQL з розширеннями до стандартної мови. Ядро SQL формує командна мова, яка дозволяє здійснювати пошук, вставку, оновлення, і вилучення даних, використовуючи систему управління і адміністративні функції. SQL також включає CLI (Call Level Interface) для доступу і управління базами даних дистанційно.


ЗАВДАННЯ НА КУРСОВУ РОБОТУ


Варіант № 16: Транспортна компанія

Таблиці:

  1. Співробітники (Код, ПІБ, Дата народження, Стать, Адреса, Телефон, Паспорт).

  2. Посади (Код, Найменування, Оклад, Обов'язки, Вимоги).

  3. Види автомобілів (Код, Найменування, Опис).

  4. Марки автомобілів (Код, Найменування, Технічні характеристики, Опис)

  5. Види вантажів (Код, Найменування, Вид автомобіля для транспортування, Опис).

  6. Вантажі (Код, Найменування, Вид, Термін придатності, Особливості).

  7. Автомобілі (Код, Марка, Вид автомобіля, Реєстраційний номер, Номер кузова, Номер двигуна, Рік випуску, Водій, Дата останнього ТО,

  8. Механік).

  9. Рейси (Код, Автомобіль, Замовник, Звідки, Куди, Дата відправлення, Дата прибуття, Вантаж, Ціна, Оплата, Повернення, Експедитор).

  10. Клієнти та інші таблиці за необхідності.


Запити і подання:

1) Штат працівників компанії.

2) Автомобілі в рейсах.

3) Вантажі.

Тригери:

  1. Тригер видалення даних з таблиці.

  2. Тригер видалення таблиці.

  3. Тригер перевірки відповідності типу автомобіля та типу вантажа при внесенні даних в таблицю «Рейси».

Інші запити та подання для покриття потреб бізнесу.


  1. ТЕОРЕТИЧНА ЧАСТИНА

    1. Основні поняття

Під базою даних (БД) розуміють сховище структурованих даних, при цьому дані повинні бути несуперечливі, мінімально надлишкові і цілісні. Найбільш поширені – об’єктна та реляційна моделі даних.

Автором реляційної моделі вважається Е. Кодд, який першим запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різниця, декартово множення) і показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого виду, відомого в математиці як відношення.

Реляційні БД представляють пов'язану між собою сукупність таблиць-сутностей бази даних. Зв'язок між таблицями може знаходити своє відображення в структурі даних, а може тільки матися на увазі, тобто бути присутнім на неформалізованому рівні. Кожна таблиця БД представляється як сукупність рядків і стовпців, де рядки відповідають екземпляру об'єкта, конкретної події або явища, а стовпці - атрибутам (ознаками, характеристиками, параметрами) об'єкта, події, явища.

При практичній розробці БД таблиці-сутності звуться таблицями, рядка-екземпляри - записами, стовпці-атрибути - полями.

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

1.2 СКБД


Система керування базами даних (СКБД) - це сукупність мовних і програмних засобів, призначених для створення, ведення та спільного використання БД багатьма користувачами.

Основні характеристики СКБД:

  • Контроль за надлишковістю даних;

  • Несуперечливість даних;

  • Підтримка цілісності бази даних (коректність та несуперечливість);

  • Цілісність описується за допомогою обмежень;

  • Незалежність прикладних програм від даних;

  • Спільне використання даних;

  • Підвищений рівень безпеки.

Можливості СКБД:

  • Є можливість створювати БД (здійснюється за допомогою мови визначення даних DDL (Data Definition Language));

  • Є можливість додавання, оновлення, видалення та читання інформації з БД (за допомогою мови маніпулювання даними DML, яку часто називають мовою запитів);

  • Можна надавати контрольований доступ до БД за допомогою:

  1. Системи забезпечення захисту, яка запобігає несанкціонованому доступу до БД;

  2. Системи керування паралельною роботою прикладних програм, яка контролює процеси спільного доступу до БД;

  3. Система відновлення — дозволяє відновлювати БД до попереднього несуперечливого стану, що був порушений в результаті збою апаратного або програмного забезпечення.

Основні компоненти середовища СКБД:

  1. апаратне забезпечення;

  2. програмне забезпечення;

  3. дані;

  4. процедури — інструкції та правила, які повинні враховуватись при проектуванні та використанні БД;

  5. користувачі:

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

    • розробники БД;

    • прикладні програмісти;

    • кінцеві користувачі.

    1. Розробка БД

Розробка ефективної бази даних складається з декількох етапів.

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

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

      1. Створення логічної структури БД. Для цього визначають, як дані будуть згруповані логічно. Логічна модель БД зазвичай відображається у вигляді ER-діаграм. В цій моделі сутність визначається як дискретній об’єкт, для якого зберігаються елементи даних, а зв’язок описує відношення між двома об’єктами.

Етапи розробки ER-діаграми:

    • Ідентифікація сутностей, їх атрибутів, первинних і альтернативних ключів;

    • Ідентифікація відносин між сутностями і вказівка типів відносин;

    • Вирішення неспецифічних відносин типу M:N

Найбільш поширеними є бінарні зв’язки з показником кардинальності «один до одного» (1:1), «один до багатьох» (1:М) і «багато до багатьох» (M:N).

      1. Створення фізичної моделі БД (перетворення логічної структури) - елементи даних на цьому етапі отримують атрибути і визначаються як стовпці в таблицях обраної для реалізації БД СКБД з урахуванням аспектів продуктивності.

    1. Нормалізація

Нормалізація схеми бази даних — покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.

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

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

У створенні та розвитку теорії нормалізації брали участь багато вчених. Однак перші три нормальні форми і концепцію функціональної залежності запропонував Е. Кодд.

Перша нормальна форма (1NF)

Відношення знаходиться в першій нормальній формі (1НФ) тоді і тільки тоді, коли в будь-якому допустимому значенні відносин кожен його кортеж містить тільки одне значення для кожного з атрибутів.

У реляційної моделі відношення завжди знаходиться в першій нормальній формі за визначенням поняття відношення.

Друга нормальна форма (2NF)

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

    • знаходиться в першій нормальній формі;

    • кожний неключовий атрибут повністю визначається первинним ключем;

Третя нормальна форма (3NF)

Відношення знаходиться в третій нормальній формі тоді і тільки тоді, коли вона:

    • знаходиться в другій нормальній формі;

    • відсутні транзитивні функціональні залежності неключових атрибутів від ключових.

Нормальна форма Бойса - Кодда (BCNF)

Відношення знаходиться в нормальній формі Бойса - Кодда (інакше - в посиленою третій нормальній формі) тоді і тільки тоді, коли вона:

    • знаходиться в третій нормальній формі;

    • будь-який виконуваний для цього відношення нетривіальний і мінімальний функціональний зв'язок має як детермінант деякий можливий ключ даного відношення.

Четверта нормальна форма (4NF)

Відношення знаходиться в четвертій нормальній формі, якщо вона:

    • знаходиться в нормальній формі Бойса – Кодда;

    • не містить нетривіальних багатозначних залежностей.

П'ята нормальна форма (5NF)

Відношення знаходиться в п'ятій нормальній формі (інакше - в проекційно-сполучної нормальній формі) тоді і тільки тоді, коли:

    • знаходиться в четвертій нормальній формі;

    • кожна нетривіальна залежність з'єднання в ній визначається потенційним ключем (ключами) цього відносини.

    1. Запити і подання

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

З точки зору вирішення інформаційних завдань і форм результатів виконаних запитів їх можна розділити на 3 групи:

    • запити на вибірку даних;

    • запити на зміну даних;

    • керуючі запити.

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

    • Від користувача (і клієнтських додатків) ховається система таблиць в базі даних. В результаті якщо структура БД змінюється (в таблиці додані нові поля, таблиці розбиті на поточні і архівні тощо) досить виправити тільки визначення уявлення - немає необхідності правити кожне клієнтське додаток окремо;

    • Спрощується синтаксис запитів (особливо з великою кількістю join);

    • Спрощується система надання дозволів;

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

    • Уявлення можуть звертатися одночасно до кількох таблиць, розміщених на різних серверах - секціонування великих баз даних.

    1. Обмеження цілісності даних

Планування і створення таблиць вимагає задання допустимих значень для стовпців і визначення способів примусового збереження цілісності даних в них. SQL Server надає механізми для примусового збереження цілісності даних у стовпці:

  • Визначення значень за умовчанням (DEFAULT);

  • Дозвіл на зберігання значень (NULL);

  • Обмеження первинного ключа (PRIMARY KEY);

  • Обмеження зовнішнього ключа (FOREGIN KEY);

  • Обмеження на унікальність значень (UNIQUE);

  • Обмеження на умову (CHECK).

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

    1. Тригери

Тригер - це збережена процедура, що починає свою роботу у випадку виконання дії, на яку тригер настроєний. Тригери застосовуються для рішення завдань підтримки цілісності (коректності) даних, коли за якимись причинами неможливо (незручно) використовувати обмеження FOREIGN KEY (або обмеження на значення стовпців), і безпеки, коли, наприклад, неприпустимі які-небудь зміни в даних. Тригери бувають декількох типів: DML, DDL і LOGON.

  • DML тригери можуть спрацьовувати при виконанні (після виконання або замість виконання) команд INSERT, UPDATE і DELETE для таблиць або подань. Цей тип тригерів був присутній і в MS SQL Server 2000.

  • DDL тригери можуть спрацьовувати при виконанні, після виконання команд CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS і деяких системних процедур.

  • LOGON тригери спрацьовують після установки з'єднання з MS SQL Server. DDL і LOGON тригери можна використовувати тільки в MS SQL Server 2005, якщо рівень сумісності для БД установлений у значення 90.



  1. ПРАКТИЧНА ЧАСТИНА

    1. Створення БД

Розробка реляційної моделі БД здійснюється в середовищі Microsoft SQL Server Management.

    1. На вкладці Бази даних натиснути праву кнопку миші на вкладці і вибрати в спливаючому меню пункт Створити базу даних (рис. 2.1-2.2).



Рис. 2.1 Створення нової БД: сторінка Загальні



Рис. 2.2 Створення нової БД: сторінка Параметри

    1. Створимо ім’я для входу в систему (рис. 2.3 – 2.5).



Рис. 2.3 Створення імені для входу



Рис. 2.4 Створення імені для входу: ролі сервера


Рис. 2.5 Створення імені для входу: співставлення користувачів

    1. Створення таблиць

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

Для таблиць даної предметної області встановимо ряд обмежень:

    1. Мінімальний вік працівників – 18 років;

    2. Ім’я, прізвище та по батькові, дата народження, назва посади, , назва не можуть залишитися незаповненими.

Для створення таблиці потрібно натиснути ПКМ по вкладці Tables та натиснути New.


Рис. 2.6 Перелік створених таблиць

    1. Створення обмеженнь


Створення обмеження віку працівників не менше 18 років

  • ALTER TABLE employees

  • ADD CONSTRAINT EmployeeAge

  • CHECK (year(getdate()) - year(birthdate) >= 18);

Створимо ще одне обмеження на стать. Можливі лише m-для чоловічої та w-для жіночої. Спробуємо це зробити через вікно обмежень:



Рис. 2.7 Створення обмеження за допомогою вікна обмежень

    1. Створення зв’язків

Для зв'язування таблиць бази даних необхідно викликати контекстне меню на вузлі Діаграми баз даних і обрати пункт Створити діаграму бази даних.

Для таблиць створимо наступні зв’язки:



Рис 2.8 Зв’язки таблиць БД

  • Поля ‘id’ є первинними ключами для таблиць. Поля ‘model_id, ‘type_id’, ‘customer_id’, ‘car_id, ‘forwarder_id’, ‘position_id’ – зовнішні ключі для сутностей в таблицях.



Рис 2.9 Таблиця «auto_types»



Рис 2.10 Таблиця «car_models»



Рис. 2.11 Таблиця «cargo»



Рис. 2.12 Таблиця «cargo_types»



Рис. 2.13 Таблиця «cars»



Рис. 2.14 Таблиця «client»



Рис. 2.15 Таблиця «driver_to_car»

Скрипт заповнення бази даних наведений в Лістингу 1 в Додатку А.


Рис. 2.16 Таблиця «employees»



Рис. 2.17 Таблиця «position»



Рис. 2.18 Таблиця «trips»

2.5 Створення запитів

Згідно завдання, необхідно створити наступні запити і подання:

1) Штат працівників компанії.

2) Автомобілі в рейсах.

3) Вантажі.

Створення запиту «Штат працівників компанії»

SELECT em.id, em.last_name, em.first_name, em.patronymic, em.passport, em.gender, em.birthdate, em.phone, em.city, em.adress, p.name

FROM employees em, position p

WHERE p.id = em.position_id;



Рис. 2.19 Результати запиту «Штат працівників компанії»

Створення запиту «Штат працівників компанії за посадою»

SELECT em.id, em.last_name, em.first_name, em.patronymic, em.passport, em.gender, em.birthdate, em.phone, em.city, em.adress, p.name

FROM employees em, position p

WHERE p.id = em.position_id and p.name = 'Водитель';



Рис. 2.20 Результати запиту «Штат працівників компанії за посадою»
Створення запиту «Автомобілі в рейсах»

SELECT c.id, c.reg_number, cm.name as model, tr.parture_date, em.last_name as driver

FROM cars c, car_models cm, trips tr, employees em

WHERE c.id = tr.car_id and cm.id = c.model_id and em.id =c.driver_id and tr.arrival_date IS NULL

ORDER BY tr.departure_date ASC;



Рис. 2.21 Результат запиту «Автомобілі в рейсах»

Створення запиту «Вантажі»

SELECT name, type_id, peculiarities FROM cargo



Рис. 2.22 Результат запиту «Вантажі»

2.6 Створення подань



Рис. 2.23 Збереженні подання

Створення подання «STAFF»

CREATE VIEW STAFF AS

SELECT em.id, em.last_name, em.first_name, em.patronymic, em.passport, em.gender, em.birthdate, em.phone, em.city, em.adress, p.name

FROM employees em, position p

WHERE p.id = em.position_id;

Створення подання «CARSONTRIP»

CREATE VIEW CARSONTRIP AS

SELECT c.id, c.reg_number, cm.name as model, tr.parture_date, em.last_name as driver

FROM cars c, car_models cm, trips tr, employees em

WHERE c.id = tr.car_id and cm.id = c.model_id and em.id =c.driver_id and tr.arrival_date IS NULL

ORDER BY tr.departure_date ASC;
Створення подання «CARGOVIEW»

CREATE VIEW CARGOVIEW AS

SELECT name, type_id, peculiarities FROM cargo
Виводи подань майже нічим не відрізняються від запитів тому вважаю доречним їх пропустити.


    1. Створення тригерів

Створимо тригер, який заборонятиме видалення будь-яких даних з таблиці trips:

CREATE TRIGGER TripsDelete

ON trips

AFTER DELETE

AS ROLLBACK;
.

Рис. 2.24 Створення тригеру TripsDelete



Рис. 2.25 Тестування роботи тригеру TripsDelete

Створимо тригер, який заборонятиме видалення таблиці з БД.

CREATE TRIGGER DropTable

ON DATABASE

FOR DROP_TABLE

AS ROLLBACK;


Рис. 2.26 Тестування роботи тригеру DropTable
Створимо тригер, який після занесення даних в таблицю trips перевірятиме чи відповідає тип обраного автомобіля типу автомобіля, котрий використовується для перевезення типу обраного вантажа:

CREATE TRIGGER WrongCar ON trips

AFTER INSERT, UPDATE AS

DECLARE

@first int,

@second int

SELECT @first = ct.auto_type,

@second = c.type_id

FROM cars as c, cargo_types as ct

WHERE c.id = (SELECT car_id FROM INSERTED) and ct.id = (SELECT type_id FROM cargo WHERE id = (SELECT cargo_id FROM INSERTED))

IF @first != second

BEGIN

RAISERROR ('Несоответствие типа машины, типу груза', 16, 1)

ROLLBACK TRANSACTION

END



Рис. 2.27 Тестування роботи тригеру WrongCar

ВИСНОВКИ


В ході курсової роботі було розроблено реляційну модель БД «Транспортна компанія» та реалізовано її в середовищі Microsoft SQL Server Management. Розроблена реляційна модель з урахуванням ключів та обмежень, яка може бути використана для потреб ведіння бізнесу транспортної компанії.

В ході роботи було створено 9 таблиць:

      1. auto_types

      2. car_models

      3. cargo

      4. cargo_types

      5. cars

      6. clients

      7. employees

      8. position

      9. trips


На основі таблиць була побудована діаграма зв’язків, для перегляду даних було створено 4 запити, 3 подання та 3 тригери.

В результаті були отримані навички роботи з Microsoft SQL Server Management, зокрема у створенні SQL-запитів, а також проектуванні структури БД.

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ


  1. Матеріали інформаційного сайта Вікіпедія [Електронний ресурс]. – Режим доступу: https://ru.wikipedia.org/wiki/Нормальная_форма

  2. Матеріали інформаційного сайта Язики програмування [Електронний ресурс]. – Режим доступу: https://life-prog.ru/ukr/view_infosystem.php?id=3

  3. Матеріали інформаційного сайта Вікі ЦДПУ [Електронний ресурс]. – Режим доступу: https://wiki.cuspu.edu.ua/index.php/Поняття_та_функції_СКБД._Компоненти_СКБД.#.D0.9C.D0.BE.D0.B6.D0.BB.D0.B8.D0.B2.D0.BE.D1.81.D1.82.D1.96_.D0.A1.D0.9A.D0.91.D0.94

  4. Матеріали інформаційного сайта AskIt[Електронний ресурс]. – Режим доступу: http://www.askit.ru/custom/db_basics/m8/08_01_basics.htm

  5. Матеріали інформаційного сайта Портал знань [Електронний ресурс]. – Режим доступу: http://www.znannya.org/?view=PHP_SUBD_main

  6. Матеріали інформаційного сайта Informatic [Електронний ресурс]. – Режим доступу: http://informatic.ugatu.ac.ru/lib/office/Proekt.htm

  7. Матеріали інформаційного сайта Справочник [Електронний ресурс]. – Режим доступу: https://spravochnick.ru/bazy_dannyh/zaprosy_v_relyacionnye_bd/

ДОДАТОК А

Лістинг 1

INSERT INTO position

(name,salary,duty,requirements)

VALUES

('Водитель',12000 ,'Перевозка грузов','Умение управлять грузовыми автомобилями всех типов, наличие прав соответствующей категории'),

('Менеджер',15000, 'Контроль за соблюдением водителями правил технической эксплуатации автотранспортных средств и оказанием им необходимой технической помощи на линии',''),

('Механик',13000,'Обеспечеине исправного состояния автотранспортных средств, выпуск на линию в соответствии с графиком и определение неисправностей при приеме с линии по окончании работы.','Наличие полного среднего технического образования'),

('Оператор',12000,'Приём заказов от клиентов, занесение их в базу данных','Комуникабельность, ответственность, отсутствие дефектов речи')

(Экспедитор, 15000, ' ', ' ')
INSERT INTO employees

(first_name,last_name,patronymic,birthdate,gender,city,adress,phone,passport,position_id)

VALUES

('Юрий','Стуров','Владимирович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',2),

('Братко','Микола','Вадимович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',1),

('Бубенко','Максим','Олександрович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',3),

('Гайдара','Володимир','Кирилович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',1),

('Духно','Ксенія','Олександрівна','2002/01/29','w','Днепр','ул. Победителей, 23','0635821895','112568752',4),

('Ждан','Іван','Віталійович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',5),

('Коляда','Ярослав','Олегович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',1),

('Кузнєцов','Анатолій','Русланович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',5),

('Лещенко','Анастасія','Олександрівна','2002/01/29','w','Днепр','ул. Победителей, 23','0635821895','112568752',4),

('Матіщак','Юрій','Юрійович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',1),

('Нагорний','Олександр','Андрійович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',5),

('Назаренко','Єгор','Артемович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',5),

('Нікіфоряк','Богдан','Станіславович','2002/01/29','m','Днепр','ул. Победителей, 23','0635821895','112568752',3)
INSERT INTO cars

(model_id,type_id,reg_number,vin,engine_number,issue_year,driver_id,last_maintenance_date,mechanic_id)

VALUES

(3,1,'XC000712','wdb4633461x191868','WMAT35ZZZYM295438',2010,2,'2021-06-30',13),

(3,1,'KA8250EM','XTA210740CY037931','WAUSGAFC7CN023789',2018,2,'2001-08-08',3),

(4,2,'OP3467FR','zfa22300005568796','ZFA25000002946042',2015,2,'2021-01-12',3),

(5,2,'BE6712IO','F1SJGL85FG197234',' WDB2020801F829003',2012,2,'2021-02-09',13),

(6,3,'MK6547IK','WAUZZZF25KN025960','WAUB8GFF9G1036860',2011,2,'2021-03-19',3),

(6,3,'XO8945KI','JF1BC5DL0EG064512','ZAR93200000229932',2009,2,'2021-11-02',13),

(7,3,'CO7214OI','XLER4X20005248087','XTA210740CY037931',2016,2,'2021-11-16',3),

(7,3,'AE7833IO','WDF44781313487714','XLER4X20005248087',2017,2,'2021-11-02',3),

(1,1,'AH3735HM','XTA210610S3353158','2B3HD46R2WH109392',2018,2,'2021-05-11',13),

(8,4,'AM6571OK','JHMFA362X7S014311','XTA210610S3353158',2016,2,'2021-06-23',13)
INSERT INTO clients

(first_name,last_name,phone)

VALUES

('Ева', 'Воробьева','0984575865'),

('Виктория','Егорова','0664532875'),

('Игорь','Чернов','0985621477'),

('Михаил','Шаров','0987896547'),

('Маргарита','Макарова','0661145477'),

('Юрий', 'Герасимов','0567485555'),

('Степан','Лебедев','0735898754'),

('Вероника','Касаткина','0735624711'),

('Тимофей','Рябов','0682586545'),

('Иван','Семенов','0998745811'),

('Александр', 'Калмыков','0965556125'),

('Мария','Петрова','098814587'),

('Милана','Суханова','0664886955'),

('Тимофей','Наумов','0664112547'),

('Владислав','Васильев','0994558896');
INSERT INTO auto_types

(name, description)

VALUES

('Малой грузоподъемности','0,5-2 тонны'),

('Средней грузоподъемности',' от 2 до 5 тонн ' ),

('Большой грузоподъемности', '5-16 тонн'),

('Особой большой','от 16 тонн')
INSERT INTO car_models

(name, specifications, description)

VALUES

('DAF XF 95' , '(430 к.с. / 316 кВт) • Дизель',null ),

('Hyundai HD78' , '3.9 л • Дизель', null ),

('МАЗ 4371' , '4.8 л • Дизель',null ),

('Mercedes-Benz Atego' , '354л.с. Дизель 6x2',null),

('MERCEDES-BENZ Actros 2535' , '354л.с. Дизель 6x2',null),

('ИВЕКО 10 тонн' , '190 л.с. 5 л Дизель',null),

('SCANIA P-340' , '340 л.с 11л дизель',null)
INSERT INTO cargo

(name, type_id, expiration_date, peculiarities)

VALUES

('Доски сосновые',1,NULL,NULL),

('Окна металлопластиковые','2',NULL,'хрупкое'),

('Лампочки',2,NULL,'хрупкое'),

('Диваны',3,NULL,NULL),

('Бензин',7,NULL,'огнеопасное'),

('Турецкие конфеты',4,'2022-11-01','тает при высокой температуре'),

('Трубы стальные',5,NULL,NULL),

('Арматура',5,NULL,NULL),

('Вино в бутылках',2,'2025-09-01','хрупкое'),

('Пиво в кегах',7,'2022-03-01',NULL),

('Носки',9,NULL,'')
INSERT INTO cargo_types

(name, auto_type, description)

VALUES

('Дерево',4 ,'Требует автомобиля с большой грузоподъёмностью'),

('Стекло',1 ,'Требует бережной упаковки и перевозки'),

('Мебель', 2,'Не требует особых условий'),

('Кондитерка',3 ,'Не требует особых условий'),

('Металл', 4,'Требует автомобиля с большой грузоподъёмностью'),

('Личные вещи',1 ,'Не требует большого объёма но требует бережной перевозки'),

('Жидкости', 3,'Не требует особых условий'),

('Выпечка', 1,'Требует особых санитарных условий'),

('Ткань',2 ,'Не требует особых условий')
скачати

© Усі права захищені
написати до нас