Лабораторна робота № 2

Тема: Проектування логічної й фізичної моделей БД. Створення

табличного простору та таблиць БД.
Мета:
1. Прищепити студентам практичні навички у створенні основних моделей
даних.
2. Підготувати студентів до самостійного виконання обов’язків адміністратора
БД.
Завдання на лабораторну роботу:
Всі дії та результати виконання цих дій повинні бути
продемонстровані за допомогою скриншотів (образ екрану) та
прокоментовані.
1. Вивчити порядок приведення таблиць БД до 3-ої нормальної форми.
2. Придумати та створити (в Word або в Excel) таблицю, в якій буде хоча б 10
стовбців та хоча б 10 рядків. В таблиці повинно бути хоча б по 3 поля кожного з
основних типів даних (тобто текстові данні, цілі числа, дробові числа, дата або час).
З даних в таблиці повинно бути зрозуміло, що це саме ваша таблиця.
3. Проаналізувати характеристики вмісту таблиці:
 виділити її основні об'єкти;
 їх зв'язки;
 атрибути, в тому числі ключові;
 характеристики атрибутів.
4. Спроектувати набір таблиць, на які повинна ділитися таблиця, що
створюється, відповідно до 3-ї нормальної форми. Розрахувати кількісні
характеристики отриманих таблиць, в тому числі індексних, з урахуванням набору
можливих запитів до бази даних з розрахунку на максимальну її продуктивність.
Також необхідно вказати типи полів таблиць та зв’язки між таблицями. Результат
представити у вигляді схеми в Word (або у вигляді чіткого рисунку).
5. Засобами БД Oracle створити табличний простір.
6. У створеному табличному просторі створити спроектовані таблиці. Таблиці
зв'язати між собою та заповнити даними (хоча б по 10 рядків).
7. Засобами БД Oracle довести, що ваші таблиці знаходяться в вашому
табличному просторі і що між таблицями є спроектовані в п. 4 зв'язки.
8. Переглянути спроектовану загальну таблицю (придуману в п. 2 завдання),
яка є результатом об’єднання пов’язаних між собою таблиць.
 9. Оформити звіт по лабораторній роботі. Звіт повинен містити інформацію
про виконання кожного пункту завдання на лабораторну роботу.
10.Створити відео-файл з демонстрацією результатів виконання всіх пунктів
завдання (поясненням етапів виконання завдань та результатів).
Зміст звіту:
1. Титульна сторінка.
2. Завдання на лабораторну роботу.
3. Виконання кожного пункту завдання та опис всіх необхідних дій і
результату.

Теоретичні відомості

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

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

Рис 2.2. Всі данні розміщено в одній таблиці – приклад невдалого дизайну.

Рис 2.3. Зменшення числа повторень за рахунок використання неатомної структури – все ще не
ідеально.
На рис. 2.1 показано кілька елементів даних. По-перше, зверніть увагу на те,
що вам не обов'язково зберігати стовпець Value, оскільки його можна обчислити за
існуючими даними.
Як правило, все, що можна обчислити, зберігати не обов'язково. База даних
має в своєму розпорядженні інструменти, які виконають для вас всі розрахунки,
тому вам зовсім не обов'язково займати місце цією інформацією.
Якщо ви спробуєте ввести дані в запропоновану таблицю, то швидко виявите
ряд проблем – в основному це надмірна кількість повторів. Для кожної з трьох
замовлених речей вам доведеться не тільки повторно вводити всі дані замовлення,
але і всі дані про клієнта. А постійний повтор одних і тих же даних це бездумне
витрачання місця. Однак є й інші проблеми. Що станеться, якщо клієнт (Замовник)
155 відмінить своє замовлення і ви вилучили два рядки таблиці? Ви втратите всю
інформацію про клієнта! Інше питання: що ви можете сказати про продукт 1577?
Він ще не замовлений, тому для зберігання зазначених даних немає місця, отже, ви
не знаєте нічого. Вивчаючи запропоновану таблицю, ви можете знайти й інші
проблеми подібного роду. Як виправити дизайн таблиці та уникнути цих проблем?
Гарантувати, що всі таблиці відповідають трьом правилам нормалізації (або трьом
нормальним формам)! Дані правила нормалізації застосовуються послідовно,
починаючи з першої нормальної форми.

Перша нормальна форма

Для того щоб таблиця відповідала першій нормальній формі, вона повинна
мати тільки атомні елементи. Атомний означає, що значення не можна розділити на
більш дрібні складові. Іншими словами, кожна клітинка таблиці містить прості
елементи даних, які не можуть повторюватися або мати вкладені значення. Технічно
всі комірки на рис. 2.2 є атомними. Однак тут ми зробили не можливе. У реальному
житті номер ItemId повторюється для кожного запису OrderId, що явно видно по
формі замовлення, наведеної на рис. 2.1.
Таблиця, запропонована на рис. 1.3, не знаходиться в першій нормальній
формі. Це можна виправити за допомогою повтору даних і приведення таблиці до
виду, представленому на рис. 2.2, однак таке поліпшення не видається доцільним.
Замість цього розумно розбити отриману таблицю на дві нові. На ті ж дві таблиці
можна розбити і версію, представлену на рис. 2.2, керуючись, однак, іншими
причинами. По суті, ви отримуєте дані, що знаходяться в повторюваному блоці
вихідної таблиці, і ставите їх в нову таблицю. Тим не менше в нову таблицю вам
потрібно включити стовпець OrderId, оскільки з його допомогою отримані таблиці
будуть пов'язані між собою.
Результат змін зображений на рис. 2.4.
Друга нормальна форма
Таблиця знаходиться в другій нормальній формі, якщо всі стовпці, що не
відносяться до ключа, залежать від усього ключа. Крім того, вона повинна бути в
першій нормальній формі.

Рис. 2.4. Виділення блоку даних, що повторюються.

Таблиця, наведена на рисунку 2.4, не знаходиться в другій нормальній формі,
оскільки опис і ціна залежать тільки від Itemid, але не від OrderlD. З іншого боку,
замовлену кількість речей залежить і від OrderlD, і від Itemid, оскільки воно
повідомляє нам, скільки одиниць кожного товару необхідно надати конкретному
покупцеві.
Щоб виправити таблицю, яка зараз перебуває не у другій нормальній формі,
вам треба розщепити її ще раз. Помістіть стовпці, що залежать тільки від часткового
ключа, в окрему таблицю (рис. 2.5). Тепер таблиці Orderltems і Items знаходяться в
другій нормальній формі. У дійсності запропонована таблиця order-customer також
знаходиться в другій нормальній формі, оскільки її первинний ключ складається з
одного стовпця.

Рис 2.5. Виділення стовпців, які залежать тільки від значення ItemID.
Третя нормальна форма
У таблиці замовлень клієнтів (див. рис. 2.5) все ще є проблеми. Якщо ми
повернемося до вихідної таблиці, наведеної на рис. 2.2, то побачимо ці проблеми ще
чіткіше. Для кожного замовлення в таблиці як і раніше повторюється одна і та ж
інформація про клієнта. У первинному варіанті інформація про клієнта
повторювалася для кожної замовленої речі. Проблема полягає в тому, що дані про
клієнта (ім'я, адреса тощо) Залежать тільки від атрибута CustomerlD, але абсолютно
не залежать від OrderlD. Якщо ви знаєте значення атрибуту CustomerlD, то знаєте
все про даний клієнта і вам зовсім не потрібен атрибут OrderlD.
Таблиця знаходиться в третій нормальній формі, коли будь-який стовпець,
що не належить до ключа, залежить тільки від ключа. Крім того, вона повинна
перебувати в другій нормальній формі. У цьому прикладі дані про клієнта залежать
від атрибута CustomerlD, який не є частиною первинного ключа, тому таблиця не
знаходиться в третій нормальній формі. Як і раніше, для вирішення цієї проблеми
таблицю необхідно розщепити на дві. Вам слід винести стовпці, що залежать тільки
від атрибута CustomerlD, і помістити їх у власну таблицю.
Отримані в результаті таблиці показані на рис. 2.6. Ви можете вивчити їх і
переконатися, що вони знаходяться в третій нормальній формі. Головне, пам'ятайте,
що таблиця знаходиться в третій нормальній формі тоді й тільки тоді, коли кожна
клітинка містить атомні дані, а будь-який стовпець, що не входить в ключ, залежить
від усього ключа і тільки від ключа.

Рис 2.6. Виділення стовпців, залежаних тільки від атрибута CustomerID.

Таблиці в третій нормальній формі мають порівняно мало проблем. Кожна
таблиця представляє окрему концепцію, а дублювання даних мінімально. Ви можете
додавати в таблицю рядки і видаляти їх, не втрачаючи важливі дані в інших
таблицях. Якщо, наприклад, ви вилучили замовлення, у вас як і раніше залишаться
контактні дані клієнта.
ТИПИ ДАНИХ В ORACLE
Таблиця 2.1. Вбудовані типи даних ORACLE.
Вбудований тип даних Oracle Опис
VARCHAR2 (розмір) [BYTE | CHAR] Символьне поле змінної довжини з
максимальною довжиною до 4000 байт,
мінімальна довжина 1 байт. Модифікатор
CHAR означає, що для визначення
довжини строки використовується так
звана символьна семантика; BYTE
означає, що для цієї мети
використовується байтова семантика.
NVARCHAR2 (розмір) Поле змінної довжини з максимальним
розміром 4000 байт.
NUMBER (p, s) Числовий стовпець з заданою
розрядністю (p) і масштабом (s).
Розрядність може змінюватись в
діапазоні від 1 до 38, а масштаб – від 84
до 127.
 LONG
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP (точність_секунд)
TIMESTAMP (точність_секунд)
WITH TIME ZONE
TIMESTAMP (точність_секунд)
WITH LOCAL TIME ZONE
INTERVAL YEAR (розрядність_роки)
TO MONTH
INTERVAL DAY (розрядність_днів)
TO SECOND (точність_секунд)
Поле даних змінної довжини, розмір поля
до 2Гбайт (2^31-1).
Значення дат, починається з 1 січня
4712р. до н.е. і закінчується 31 грудня
9999р.
32-бітове число з плаваючою точкою.
64-бітове число з плаваючою точкою.
Представляє дату і час (рік, місяць, число,
години, хвилини, секунди і долі секунди).
Значення точності секунд може
змінюватись від 0 до 9; іншими словами,
забезпечується точність до одної
міліарної долі секунди. Значення за
замовчуванням рівно 6 (одна мільйонна
доля секунди).
Вміщує значення TIMESTAMP, до якого
добавлено зміщення, зв’язене з часовим
поясом. Часовий пояс може
відраховуватись від UTC (всесвітній час),
наприклад «-6:00» або вказуватись назва
регіону, наприклад «US/Central».
Цей тип даних похожий на TIMESTAMP
WITH TIMEZONE за виключенням того,
що: (1) при збереженні в бізі даних дати
приводиться до часового поясу бази
даних і (2) при виборці даних користувач
буде бачити ці дані в перерахунку на
часовий пояс сеансу.
Зберігає значення інтервалу часу,
виражене в роках і місяцях. Значення
розрядність_року визначає число цифр в
полі YEAR дати.
Зберігає значення інтервалу часу
виражене в днях, часах, хвилинах,
секундах і долях секунд. Значення
розрядність_днів знаходиться в інтервалі
від 0 до 9. Значення за замовчуванням
дорівнює 2. Значення точність_секунд
аналогічно значенню точність_секунд
 для типу даних TIMESTAMP. Воно
також лежить в інтервалі від 0 до 9, а
значення за замовчуванням дорівнює 6.
RAW (розмір) Поле змінної довжини (до 2000 байт).
LONG RAW Поле змінної довжини (до 2 Гбайт),
використовуване для збереження
двійкових даних.
ROWID Представлення (в кодуванні base-64), у
вигляді строки унікальної адреси строки
відповідної таблиці. Цей адрес повинен
бути унікальним для всієї бази даних.
UROWID [(розмір)] Строка (в кодуванні base-64), яка
представляє логічну адресу троки індекс-
таблиці; довжина до 4000 байт.
CHAR (розмір) [BYTE | CHAR] Символьне поле фіксованої довжини,
визначеної значенням розмір. Мінімальне
значення довжини рівно 1 байт, а
максимальне – 2000 байт. Параметри
BYTE та CHAR вказують на
використання байтової чи символьної
семантики, як в VARCHAR2.
NCAHR (размер) Поле для розміщення символів
фіксованої довжини (складених з
декількох байт). Максимальний розмір
поля – 2000 байт. Значення за
замовчуванням – 1 байт.
CLOB Символьний великий об’єкт який містить
однобайтові або багатобайтові символи;
підтримує як одно байтові так і
багатобайтові набори символів.
Максимальний розмір об’єкту дорівнює
(4 Гбайт - 1)*DB_BLOCK_SIZE.
NCLOB Аналгічний CLOB за виключенням, що в
базу даних замість символів з наборів
символів фіксованої або змінної довжини
записуються символи Unicode.
Максимальний розмір об’єкту дорівнює
(4 Гбайт - 1)*DB_BLOCK_SIZE.
BLOB Двійковий великий об’єкт.
 Максимальний розмір об’єкту дорівнює
(4 Гбайт - 1)*DB_BLOCK_SIZE.
BFILE Вказівник на великий двійковий файл,
який зберігається поза базою даних.
Двійкові файли повинні бути доступні з
сервера, на якому виконується екземпляр
Oracle. Максимальний розмір об’єкту
дорівнює 4 Гбайт.

Крім того, Oracle підтримує типи даних, порівнянні з типами даних ANSI.
АРХІТЕКТУРА ТАБЛИЧНОГО ПРОСТОРУ
Табличний простір (tablespace) - винахід фахівців компанії Oracle. Це логічний
набір елементів бази даних. Як адміністратор ви можете помістити в табличний простір
різні об'єкти (у тому числі користувачів). Ви можете створити як завгодно багато
табличних просторів і вирішувати, що ви будете зберігати в них.
Можливо, ви віддасте перевагу зберігати всі таблиці і інші об'єкти однієї бізнес-
системи в одному табличному просторі, а дані, відповідні іншим системам, - в інших
табличних просторах. Можна також піти далі і зберігати в одному табличному просторі
тільки таблиці однієї бізнес-системи, а всі індекси даної системи - в інших табличних
просторах. Можна поступити і по-іншому, а саме: розмістити всі об'єкти в один великий
табличний простір. У чому відмінність цих підходів і як прийняти правильне рішення?
На рис. 2.7 показані основні терміни, що стосуються зберігання даних у системі
Oracle. Табличний простір - це логічний набір даних.

З ним

Рис. 1,7. Табличні простори і файли даних

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

База даних

Табличний Табличний Табличний

простір простір простір Сегмент
SYSTEM USERS SYSAUX

Екстент 1

Табличний простір
Екстент 2
Сегмент 1 Сегмент 2

Сегмент 3 Сегмент 4

Сегмент 5 Сегмент 6 Блоки

Рис 1.8. Логічна структура пам’яті.

Необхідною попередньою умовою повного створення всіх табличних просторів

для бази даних є розуміння різних типів табличних просторів і того, як вони
використовуються Oracle.
Основними типами табличних просторів в базах даних Oracle є постійні і
тимчасові табличні простори, а також табличні простори відкату. У постійних
табличних просторах містяться сегменти, існування яких не обмежено поточним
сеансом або транзакцією (тобто вони існували до і будуть, можливо, існувати після
цього сеансу або транзакції).
Двома прикладами постійних табличних просторів є табличні простори SYSTEM
і SYSAUX. Будь-який сегмент, який повинен бути збережений у пам'яті користувачем
або додатком поза межами сеансу розміщується постійному табличному просторі.
Сегменти користувачів ніколи і ні в якому разі не повинні зберігатися в
табличному просторі SYSTEM. Починаючи з Oracle 10g, з'явилася можливість
оголошувати за замовчуванням постійні табличні простори, а не тільки тимчасові, як це
мало місце в Огасle9g.
Відповідно до загального емпіричного правила бажано розносити сегменти по
різним табличним просторам на підставі їх типу, розміру та частоти обертання до них.
Кожне з цих табличних просторів виграє від того, що воно виявиться у своїй дисковій
групі або на своєму диску, але, на практиці в більшості організацій не вистачає ресурсів,
щоб зберігати кожен табличний простір на власному пристрої.
Наведений нижче маркірований список ілюструє умови, які можна
використовувати для визначення, як сегменти повинні бути розділені між табличними
просторами.
 Великі і малі сегменти повинні потрапляти в різні табличні простори.
 Сегменти таблиці та відповідні їм індексні сегменти повинні потрапляти в
різні табличні простори.
 Для кожного додатку повинен використовуватися окремий табличний
простір.
 Рідко використовувані сегменти повинні бути відокремлені від часто
використовуваних.
 Статичні (рідко змінювані) сегменти повинні бути відокремлені від
сегментів з високою інтенсивністю операцій DML.
 Табличні простори тільки для читання повинні перебувати у власних
табличних просторах.
 Проміжні таблиці для сховища даних повинні перебувати у власному
табличному просторі.
 Табличні простори повинні створюватися з відповідним розміром блоку, в
залежності від того, звертаються до сегментів рядок за рядком, або
здійснюється повне сканування таблиці.
 Матеріалізовані подання і базова таблиця повинні зберігатися в різних
 табличних просторах.
 Кожен розділ секціонованих таблиць та індексів повинен зберігатися у
власному табличному просторі.
РОЗГЛЯНЕМО ПОРЯДОК ПРИВЕДЕННЯ ТАБЛИЦЬ БД ДО 3-ОЇ
НОРМАЛЬНОЇ ФОРМИ НА ПРИКЛАДІ
Почнемо з аналізу характеристик бізнес процесу, що підлягає моделюванню:
 виділимо його основні об'єкти;
 їх зв'язки;
 атрибути, в тому числі ключові;
 характеристики атрибутів.
Головна мета використання бази даних це збір і ефективне збереження
необхідної інформації, щоб її можна було швидко оновлювати і витягувати.
Дослідження баз даних показали, що найефективнішим способом збереження
і вилучення більшої частини інформації є реляційні бази даних. Щоб добитися такої
ефективності, до розробки бази даних необхідно підходити дуже відповідально.
Фундаментальним компонентом реляційної бази даних є таблиця.
Таблиця складається з рядків і стовпців і містить дані, що представляють
один об'єкт в бізнес-моделі. Її стовпці називаються атрибутами, а рядки
представляють окремі екземпляри даних.
Існує кілька основних правил розробки таблиць, які будуть ефективно і точно
працювати в реляційній системі баз даних. Однак для розуміння цих правил
спочатку необхідно ознайомитися з декількома визначеннями.
Реляційна база даних це набір зв'язаних таблиць. Таблиця це набір рядків і
стовпців (атрибутів), що описують об'єкт. Атрибут це характеристика об'єкта. Рядок
містить дані для одного екземпляра об'єкту.
Кожна таблиця повинна мати первинний ключ - значення, яке єдиним чином
визначає кожен рядок і розташоване у певному стовпці або наборі стовпців. Для
кількох об'єктів ви створите власний стовпець первинних ключів і дозволите системі
управління реляційної базою даних автоматично заповнити стовпці унікальними
значеннями.
 Нам дана накладна (таблиця), в якій міститься інформація про назву товарів,
кількість одиниць в замовленні, ціна за одиницю у валюті, сума за всі одиниці
товару у валюті і в гривнях, ПДВ (20% від суми в гривнях), та сума всього (сума за
товар в гривнях + ПДВ). Розіб’ємо дану таблицю на 2 таблиці. В першу помістимо
назву товару, одиниці, ціну і порядковий номер товару, назвемо її «PRODUCTS»
(жовтий колів). В іншу таблицю помістимо кількість замовлених товарів та їх код(id),
назвемо її «ORDERS» (зелений колір). Поля таблиці сума вал., сума грн., ПДВ та всього
нам зберігати не потрібно. Їх можна обрахувати (червоний колір). В такому випадку
таблиця «PRODUCTS» буде складатись з атомарних елементів, а всі стовпці крім
ключового (порядкового номеру) будуть залежати від ключа і тільки від ключа. (3
нормальна форма). В таблиці «ORDERS» ключовим полем буде порядковий номер
замовлення, а всі інші стовпці будуть залежні тільки від ключового поля (3 нормальна
форма). При цьому кожному товару з таблиці «ORDERS» буде відповідати аналогічний
товар з таблиці «PRODUCTS». А оскільки стовпці сума вал., сума грн., ПДВ та всього
динамічно обраховуються ми можемо створити додаток, який буде генерувати нам
накладні по заданому списку і кількості товарів.

Ціна
№ Од. Кіл-ть Сума вал Сума грн ПДВ Всього
Назва вал
1 лампа Б40Вт E-27 шт. 100,000 3,17 317,50 317,50 63,500 381,000
2 Лампа рефл. R 63 60W Е27 шт. 50,000 7,65 382,92 382,92 76,584 459,504
3 Лампа ЛОН 300 Вт Е-27 шт. 15,000 10,82 162,25 162,25 32,450 194,700
4 лампа F18W/54-765 G13 люм шт. 50,000 7,18 358,75 358,75 71,750 430,500
5 Стартер 4-22WFS22 шт. 50,000 2,98 149,17 149,17 29,834 179,004
6 лампа гал . 300W /240V шт. 7,000 20,70 144,90 144,90 28,980 173,880
7 Лампа ен зб 9W-840 T14 шт. 20,000 31,66 633,33 633,33 126,666 759,996
8 Вимикач авт.LR 1 10A тип С шт. 2,000 35,69 71,38 71,38 14,276 85,656
9 Вимикач авт.LR 1 16A тип С шт. 2,000 35,69 71,38 71,38 14,276 85,656
10 Вимикач авт.LR 1 20A тип С шт. 2,000 35,69 71,38 71,38 14,276 85,656
11 Вимикач авт.LR 1 25A тип С шт. 2,000 35,69 71,38 71,38 14,276 85,656
12 Вимикач авт.LR 3 25A тип С шт. 1,000 128,16 128,16 128,16 25,632 153,792
13 Вимикач авт.LR 3325A тип С шт. 1,000 135,51 135,51 135,51 27,102 162,612
14 Механізм вимикача 2 кл шт. 2,000 39,68 79,35 79,35 15,870 95,220
15 Механізм вимикача універсальн шт. 2,000 25,68 51,37 51,37 10,274 61,644
16 Розетка Z,біла 16А\230В шт. 5,000 24,38 121,88 121,88 24,376 146,256
17 Клавіша для 2-х клавиш.вимикач шт. 2,000 10,14 20,28 20,28 4,056 24,336
біла
18 Вимикач 2 кл- білий шт. 2,000 63,92 127,83 127,83 25,566 153,396
19 Вимикач універс. білий шт. 2,000 52,90 105,80 105,80 21,160 126,960
20 Клавіша для 1 клавішн. вимикач шт. 2,000 6,95 13,90 13,90 2,780 16,680
біла
21 баласт F40 B2 шт. 6,000 25,88 155,30 155,30 31,060 186,360
22 Светильник ЛПО 11У-18-212 шт. 13,000 155,88 2026,38 2026,38 405,276 2431,656
проз
23 Лампа ен зб R63 13W 2700K T27 шт. 11,000 33,72 370,88 370,88 74,176 445,056
Всього: 5770,98 5770,98 1154,20 6925,18

В результаті ми отримуємо 3 об’єкти в нашій БД. Осталось визначити лише

більш детально атрибути, але це буде зроблено в ході створення таблиць.
Тепер розпишемо кожен крок створення нашого додатку від створення першої
таблиці до редагування зовнішнього вигляду самого додатку.
Перш ніж створювати таблиці створимо нашого нового користувача і табличний
простір для створення наших таблиць.
Для створення табличного простору можна використати запит CREATE
DATABASE або CREATE TABLESPACE. При створенні, табличного простору, слід
зробити вибір, який тип файлів буде використовуватися, великий чи маленький, який
тип управління екстент буде використовуватися, локальний або словником даних, і як
буде проводитися управління простором сегментів - автоматично або вручну.
Додатково, вирішується, чи буде це табличний простір спеціалізованим - табличний
простір для тимчасових сегментів або сегментів відкоту.
Нове в Oracle 18c, це табличні простори з великими файлами (bigfile). Такі
табличні простори побудовані на одному файлі даних або тимчасовому файлі. Може
містити до 2 ^ 32 блоків даних. Такий табличний простір використовуючи блоки даних
по 8K, може бути розміром до 32TB.
Такі табличні простори використовуються для дуже великих баз даних. Великі
бази даних містять сотні файлів даних для читання або запису, та операції які повинні
змінювати заголовки файлів даних, наприклад установка контрольних точок, займають
досить тривалий час. Якщо ви зменшите кількість файлів, то операції будуть
виконуватися швидше.
Табличний простір smallfile - це нова назва старих табличних просторів. У таких
табличних просторах, може бути декілька файлів даних. Кожен файл даних може бути з
2 ^ 22 блоків даних. Табличний простір може містити до 1022 файлів даних. Табличні
простори SYSTEM і SYSAUX завжди створюються з маленькими файлами.
Для створення табличного простору у користувача мають бути відповідні права.
Якщо цих прав нема, тоді треба або їх надати (краще), або створити нового користувача.

Створюємо табличний простір розміром 100Мбайт.

Для цього в консолі PowerShell переходимо в редактор SQL (Ми
використовуємо PowerShell, так як встановлення APEX проводилось через цю ж
консоль), як в 1 лабораторній і вводимо команду CREATE TABLESPACE lab_2_
DATAFILE `D:/Temp/ora/oradata/xe/lab_2_.dbf` SIZE 100M;

Перевірити перелік табличних просторів, що є, можна наступним чином:

Далі можна або зразу створювати таблиці в створеному табличному просторі, або
спочатку створити їх в просторі за замовченням (скоріш за все в USERS), а потім
перенести їх в потрібний табличний простір. Але в цьому випадку принциповим є в
якому порядку переносити таблиці. Розглянемо, наприклад, другий варіант.
Крок 1. Створюємо таблицю «PRODUCTS». Для цього заходимо в «Object
Browser» на головній сторінці ORACLE APEX

В контекстному меню «Create» вибираємо пункт «Table».

 Тут даємо назву таблиці «PRODUCTS». Нам потрібно створити чотири
стовпці. Перший «id_product» - тип данних стовпця «NUMBER». Це в нас буде поле
первинного ключа, тому тип «NUMBER» нам підходить найкраще. Наступний
стовпець «product_name», тип даних стовпцы – «VARCHAR2» - текстове поле.
Довжина поля «4000». Третій стовпець – «unit», числовий тип (NUMBER). І
останній стовпець «price», теж числового типу.

В цьому пункті задаємо ключове поле. В списку «Primary Key» вибираємо

стовпець «id_product».

Наша таблиця готова.

Натиснувши на стрілку поряд з написом «SQL» можна переглянути SQL який
відповідає за всі наші попередні дії при створенні таблиці.

CREATE table "PRODUCTS" (

"ID_PRODUCT" NUMBER,
"PRODUCT_NAME" VARCHAR2(4000),
"UNIT" NUMBER,
"PRICE" NUMBER,
constraint "PRODUCTS_PK" primary key ("ID_PRODUCT")
)
Крок 2. Створюємо таблицю «ORDERS». Список необхідних дій для створення нової
таблиці ми розглянули на прикладі попередньої таблиці. Тому тут лише проаналізуємо
які нам необхідні стовпці. Задамо ключове поле «ID_ORDER» з типом даних
«NUMBER». Стовпець «ID_PRODUCT» буде зв'язувати цю таблицю з попередньою, а
«QUANTITY» відповідатиме за кількість товару у замовленні.
Тепер задамо первинний ключ в насупному пункті. Для цього просто оберемо
«ID_ORDER» в розділі «Primary Key».

Тепер задамо віддалений ключ. Для цього в пункті «Select Key Column(s)» виберемо
стовпець «ID_PRODUCT». В пункті «Reference Table» оберемо таблицю «PRODUCTS».
Після цього з’явиться ще оди список стовпців «Select Reference Column(s)», це стовпці
відданої таблиці. Зі списку виберемо «ID_PRODUCT». Далі потрібно натиснути кнопку
«Add».
Наша таблиця готова.

Крок 3. Додаємо дані в нашу БД. Заповнюємо таблиці. Можливі варіанти заповнення
таблиць ми вже розглядали в лабораторній роботі №1.
Ми заповняли таблиці вручну, додаючи кожен запис в «Data->Insert Row».
Заповнена таблиця.
Переглянемо спроектовану загальну таблицю, яка є результатом об’єднання
пов’язаних між собою таблиць. Для цього переходимо в «SQL Workshop, Utilities»
потім в «Query Builder». Зліва оберемо обидві таблиці. Галочкою відмітимо
необхідні нам в запиті поля. Натиснемо кнопку «Run». Результат нашого запиту.
Тобто таблиці створені і заповнені.
Перевірити зв’язки між таблицями можна наступним чином:
 Усі таблиці були створені поза табличним простором користувача lab_2. Тепер
перенесемо вже створені таблиці в табличний простір lab_2. Зробити це можна
використовуючи консоль в режимі SQL

Для створення таблиць в табличному просторі не за замовчуванням, перед назвою

створюваної таблиці потрібно додавати ім’я потрібного табличного простору.