Размещено на http://www.allbest.ru/

Міністерство освіти та науки України

Державний університет «Одеська політехніка»

МЕТОДИЧНІ ВКАЗІВКИ ДО ЛАБОРАТОРНИХ РОБІТ

з дисципліни БАЗИ ДАНИХ

для студентів спеціальності 121 - Інженерія програмного забезпечення

ОДЕСА 2021

Зміст

реляційний база дані інформаційний

• Вступ
• Варіанти
• Лабораторна робота №1 Дослідження предметної області
• Лабораторна робота №2 Побудова концептуальної моделі даних
• Лабораторна робота №3 Визначення запитів до інформаційної системи та розробка структури реляційної БД
• Лабораторна робота №4 Реалізація запитів за допомогою реляційної алгебри
• Лабораторна робота №5 Створення таблиць та модифікація даних за допомогою SQL
• Лабораторна робота №6 Виведення даних за допомогою запитів SQL
• Лабораторна робота №7 Створення тригерів та збережених процедур
• Література
• Вступ
• Метою лабораторних занять є одержання навичок по проектуванню інформаційної системи, в основі якої перебуває база даних.
• У процесі виконання робіт студент повинен вивчити запропоновану предметну область, сформувати вимоги до розроблювальної інформаційної системи, розробити структуру реляційної БД, реалізувати запити з використанням мови SQL, запрограмувати елементарні тригери й збережені процедури.
• Всі лабораторні роботи виконуються студентом по єдиному власному варіанту. Варіант вибирається за номером в списку групи й погоджується з викладачем, що проводить лабораторні заняття.
• Варіанти
• 1) Поліклініка
• Види діяльності: ведення розкладу лікарів; розподіл адрес, лікарів і пацієнтів по ділянках; прийом пацієнтів; постановка діагнозів; призначення лікування; облік призначення й результатів аналізів й обстежень різних видів; видача лікарняних листів.
• 2) Виробнича фірма
• Види діяльності: замовлення на виготовлення продукції; облік випуску продукції; облік поставок і витрат сировини; розподіл роботи між співробітниками; облік оплати замовлень клієнтами; облік виплати зарплати.
• 3) Лікарня
• Види діяльності: облік прийому пацієнтів; постановка діагнозів; приміщення пацієнтів у палати різних типів різних відділень; облік поставок і витрат медикаментів; облік призначень і результатів різних видів обстежень (УЗД, аналізи, кардіограма й т.д.)
• 4) Готель
• Види діяльності: облік зайнятості номерів, зроблених послуг клієнтам; бронювання номерів; облік робочого часу співробітників й оплати їхньої роботи; облік закупівель різного встаткування (меблів, сантехніки, побутової техніки й т.д.) і розміщення (переміщення) у номерах.
• 5) Фитнесклуб
• Види діяльності: облік проведених у групах й індивідуально занять; видача абонементів; облік знижок різних видів; облік роботи співробітників; закупівля й списання встаткування; ведення розкладу в різних залах.
• 6) Тепличне господарство
• Види діяльності: посадка рослин різних видів на різних площах; облік зібраного врожаю й реалізація вирощеної продукції по договорах і на ринку; закупівля й витрата добрив й інших допоміжних матеріалів; облік роботи співробітників; оплата постачальникам, співробітникам, за реалізовану продукцію.
• 7) Інтернет-магазин
• Види діяльності: каталог продукції по категоріях; прийом замовлень, відправлення продукції; оплата замовлень; ведення цін у декількох видах валюти; облік постійних клієнтів; проведення акцій зі знижками; закупівля продукції.
• 8) Банк
• Види діяльності: ведення рахунків різних видів по різних видах валюти; прийом платежів різного виду; видача кредитів й облік їхньої оплати; облік роботи відділень й їхніх співробітників.
• 9) Туристична компанія
• Види діяльності: організація маршрутів; кошторис витрат по маршрутах; формування груп й індивідуальні поїздки; облік роботи співробітників (в офісі й по супроводу туристів); бронювання готелів; каталог місць проживання, екскурсій і т.д.
• 10) Інтернет-провайдер
• Види діяльності: проведення Інтернету індивідуально й у багатоквартирні будинки; облік ремонтних робіт; каталог тарифів; облік трафіка клієнтів; облік оплати послуг (основних і додаткових).
• 11) Продовольчий магазин
• Види діяльності: облік закупівель і продажу товарів; списання товару після закінчення строку реалізації; облік часу роботи співробітників; ведення довгострокових і короткострокових договорів на поставку продукції; облік устаткування (закупівля, ремонт, переоцінка).
• 12) Вантажні перевезення
• Види діяльності: прийом замовлень на перевезення; розподіл вантажу по машинах; формування маршрутів; оплата клієнтами виконаних замовлень (з авансом); облік закупівель і витрати палива; оплата праці співробітників.
• 13) Будівельна компанія
• Види діяльності: підтримка договорів на проведення будівельних робіт; складання кошторису витрат для договорів; облік закупівель і витрати матеріалів; облік проведених робіт; розподіл робіт між співробітниками; облік поетапної оплати по договорах.
• 14) Деканат
• Види діяльності: ведення розкладу занять; ведення особистих справ студентів; облік успішності студентів; ведення навчального плану по курсах, спеціальностях, дисциплінах і видах занять.
• 15) Мережа промтоварних складів
• Види діяльності: закупівля товарів різних видів; розподіл товарів по складах; відвантаження товару зі складів відповідно накладним; списання товару; облік поетапної оплати постачальникам і з боку клієнтів; облік роботи співробітників.
• 16) Друкарня
• Види діяльності: ведення договорів на виготовлення продукції; закупівля й витрати сировини; розподіл робіт між співробітниками; відвантаження готової продукції; оплата замовлень і роботи співробітників; облік устаткування (закупівля, переоцінка, переміщення, списання).
• 17) Ресторан
• Види діяльності: закупівля й витрата продуктів (штучних і вагових); облік замовлень по блюдах і штучних продуктах; оплата постачальникам; облік роботи співробітників по змінах і посадам; ведення рецептури блюд і нормативів витрати продуктів.
• 18) Аптека
• Види діяльності: закупівля продукції різних виробників й у різних постачальників; продаж лікарських препаратів; списання після закінчення строку придатності; можливо, поетапна оплата постачальникам; опис лікарських препаратів (компоненти, показання, протипоказання, дозування прийому, упакування).
• 19) Автовокзал
• Види діяльності: ведення розкладу руху автобусів; ведення маршрутів руху; продаж і бронювання квитків; облік роботи водіїв; ремонт й обслуговування транспорту; закупівля й витрата палива.
• 20) Мережа бензоколонок
• Види діяльності: облік закупівель і продажу палива різних видів і супутніх товарів; облік робочого часу співробітників; оплата постачальникам і співробітникам; ведення довгострокових договорів по закупівлі з різними постачальниками; продаж палива по талонах відповідно до договорів з організаціями.
• 21) Лабораторія
• Види діяльності: закупівля й витрата реактивів; облік устаткування; нормативи витрати реактивів; проведення різного виду аналізів; нормативи результатів; облік роботи співробітників; облік оплати аналізів і поставок реактивів.
• 22) Швейний цех
• Види діяльності: прийом замовлень на виготовлення виробів різного виду; кошторис по витратах на вироби; облік закупівлі й витрати матеріалу й фурнітури; розподіл робіт між співробітниками; оплата постачальникам, співробітникам, клієнтами; виготовлення стандартних виробів й облік їхньої реалізації; облік устаткування.

Лабораторна робота №1 Дослідження предметної області

Ціль роботи: одержати навички аналізу предметної області й виявлення її об'єктів; навчитися на основі зібраної інформації про предметну область формувати вимоги до цієї системи.

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

Проект розробки інформаційної системи (ІС) - від становлення ідеї до першої версії, переданої замовникам, - складається із трьох етапів: аналізу, проектування й реалізації, у результаті ітеративного виконання яких відбувається покрокове "нарощування" системи.

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

При проектуванні інформаційної системи необхідно провести аналіз цілей цієї системи й виявити вимоги до неї окремих користувачів (співробітників організації). Збір даних починається з вивчення сутностей організації й процесів, які використають ці сутності. Сутності групуються по «подібності» (частоті їхнього використання для виконання тих або інших дій) і по кількості асоціативних зв'язків між ними (літак - пасажир, викладач - дисципліна, студент - сесія й т.д.).

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

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

- опис застосовуваних або вироблюваних даних;

- докладні відомості про способи застосування або виробітки даних;

- всі додаткові вимоги до створюваної програми бази даних.

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

До традиційних методів виявлення вимог належать використання інтерв'ю й анкет, спостереження й вивчення ділових документів

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

Існують два основних типи інтерв'ю: структуроване (формальне) і неструктуроване (неформальне). Структуроване інтерв'ю готується заздалегідь, відрізняється ясністю постановки питань, а багато питань можуть бути задані заздалегідь.

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

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

Анкета (або запитальник) повинна бути розроблена таким чином, щоб, по можливості, полегшити відповіді на питання.

Спостереження може виступати у двох формах;

- пасивне спостереження, у ході якого бізнес-аналітик спостерігає за різними видами ділової діяльності без втручання або прямої участі в них;

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

Щоб результати спостережень були представницькими, спостереження необхідно проводити протягом тривалого періоду часу, у різні часові інтервали й при різному робочому навантаженні (вибіркові періоди).

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

Вимоги, які формулюються у вигляді прецедентів, проявляються за допомогою вивчення існуючих організаційних документів і системних форм і звітів.

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

Системні форми й звіти, які підлягають вивченню, включають: копії екранів, звіти разом з відповідною документацією - системні допомога з експлуатації, користувальницька документація, технічна документація, системні моделі аналізу й проектування й т.д.

Вимоги, засновані на знанні проблемної області, з'ясовуються за допомогою вивчення журналів і підручників, які належать до даної сфери.

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

До сучасних методів виявлення вимог належить використання програмних прототипів, а також такі методи, як JAD (Joіnt Applіcatіon Development - спільна розробка програм) і RAD (Rapіd Applіcatіon Development - швидка розробка програм).

Прототипування - це найбільше часто використовуваний сучасний метод виявлення вимог. Програмні прототипи конструюються для візуалізації системи або її частини для замовників з метою одержання їхніх відгуків.

Прототип являє собою демонстраційну систему - «нашвидку й грубо» зроблену робочу модель рішення, що представляє користувальницький GUІ-интерфейс і моделює поводження системи при ініціюванні користувачем різних подій. Інформаційне наповнення екранів частіше жорстко запрограмовано в програмі прототипу, ніж вибрано автоматично з бази даних.

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

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

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

На самому базовому рівні вимоги можна розділити на робочі цілі, властивості об'єктів, правила й переваги.

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

Приклад. Є наступна вимога до системи, створюваної для лікувальної профілактичної установи: вести облік своєчасності проходження співробітниками атестації по своїй спеціальності.

Ця вимога виражає кілька робочих цілей системи, які стосуються інформаційних потреб:

- Надати користувачам дані, які їм необхідні для виконання своєї роботи, через відповідний комп'ютерний інтерфейс до БД.

- Надати відомості про лікарів у вигляді їхнього прізвища, імені, по батькові, посади й місця роботи.

- Надати відомості про атестації, які проходив співробітник.

- Надати відомості про всіх співробітників, які проходили атестацію в заданий період.

- Надати відомості про співробітників, у яких підходить час чергової атестації.

- Надати відомості про співробітників, у яких атестація вже прострочена.

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

Наприклад, ключовий об'єкт в інформаційних вимогах - це атестація. Можна назвати деякі базові властивості цього об'єкта:

- Період проходження;

- Місце проходження;

- Спеціальність;

- Номер наказу, що зафіксував результат атестації;

- Категорія, яку має співробітник у результаті проходження атестації;

- Категорія привласнена, продовжена або підтверджена.

Правила - це умовні вимоги до властивостей об'єктів. Так, наприклад, співробітник повинен проходити атестацію кожні п'ять років.

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

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

Можна також використати початкові значення або значення за замовчуванням - значення, які привласнюють системою, якщо іншого не визначено - для представлення переваг.

Звичайно переваги мають форму «наскільки можливо» або «оптимально» або щось подібне. Необхідно розуміти різницю між правилами й перевагами. Правило говорить «повинен» або «буде», або «потрібно». Це розходження між необхідністю й бажанням.

Завдання

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

Лабораторна робота №2 Побудова концептуальної моделі даних

Ціль роботи: одержати навички побудови концептуальної моделі даних ER

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

Перший етап - аналіз даних, що дозволяють зібрати інформацію про атрибути і їхні взаємозв'язки.

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

1) ЛІКАР

2) СПЕЦІАЛЬНІСТЬ

3) ПАЦІЄНТ

4) ПРЕПАРАТ

5) КАТЕГОРІЯ ПРЕПАРАТІВ

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

На четвертому етапі задаються первинні та альтернативні ключі, визначаються атрибути сутностей.

Отримана інформаційна модель виглядає так.

Завдання

Сформувати модель ER для заданої предметної області. Модель повинна містити не менш 8 об'єктів. Указати види взаємозв'язків (обов'язкова присутність зв'язків "один до багатьох" й "багато до багатьох ") і обов'язковість зв'язків з кожного боку.

Лабораторна робота №3 Визначення запитів до інформаційної системи та розробка структури реляційної БД

Ціль роботи: навчитися створювати реляційні таблиці на основі моделі предметної області. Одержати навички виявлення функціональних вимог до інформаційної системи; навчитися формувати вимоги до інформаційної системи у вигляді запитів на добування даних із БД.

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

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

Об'єкт із атрибутами перетвориться в таблицю.

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

Відношення перетвориться одним із трьох способів залежно від його типу.

1:1

Нехай кожен клієнт банку може мати тільки один поточний рахунок. Тоді між об'єктами Клієнт і Рахунок існує зв'язок 1:1. Нехай ключами є НомерКлієнта й НомерРахунку. Одержимо дві реляційні таблиці:

Клієнт (НомерКлієнта,...)

Рахунок (НомерРахунку,...)

Щоб показати зв'язок між цими таблицями, потрібно включити НомерРахунку в таблицю Клієнт АБО НомерКлієнта в таблицю Рахунок. Який варіант обрати, можна вирішити з наступних міркувань. Очевидно, що якщо в клієнта немає зараз поточного рахунку, то НомерРахунку в таблиці Клієнт у цьому випадку буде порожнім. Але рахунок без клієнта-власника не може існувати, тому НомерКлієнта в таблиці Рахунок завжди буде заповнений. Тому краще обрати другий варіант. Таким чином, відношення 1:1 перетвориться шляхом приміщення одного з об'єктів як атрибут у таблицю другого об'єкта.

1:М

Нехай у клієнта може бути кілька поточних рахунків, але кожен рахунок належить тільки одному клієнту.

У будь-якому відношенні 1:М у таблицю, що описує об'єкт, потужність із боку якого дорівнює «багато», включається стовпець, що є зовнішнім ключем, що вказує на інший об'єкт.

Виходить наступна структура таблиць:

Клієнт (НомерКлієнта,...)

Рахунок (НомерРахунку, НомерКлієнта,...)

М:N

Нехай кожен клієнт може мати кілька поточних рахунків. Але й кожним поточним рахунком можуть користуватися кілька клієнтів. Для перетворення відношення М:N створюється таблиця перетинання. Таблиця перетинання - це таблиця, що представляє елементи двох інших таблиць, що перебувають у відношенні М:N. Тобто створюються три таблиці:

Клієнт (НомерКлієнта,...)

Рахунок (НомерРахунку,...)

КлієнтРахунок (НомерКлієнта, НомерРахунку,...)

У таблиці КлієнтРахунок атрибути НомерРахунку й НомерКлієнта є зовнішніми ключами.

Нехай є складений об'єкт.

Оскільки відношення має потужність «багато до багатьох», створюються три таблиці

Лікар (Ід лікаря,...)

Пацієнт (Ід пацієнта)

Прийом (Ід лікаря, Ід пацієнта, Дата, Скарги)

У таблицю Прийом поміщені атрибути Дата та Скарги, тому що він відноситься до складеного об'єкта.

Після всіх перетворень потрібно переглянути реляційну схему на предмет усунення надмірності.

Залежно від змісту вхідної інформації, покладеної в основу проектування, розрізняють підходи «від предметної області» й «від запиту».

Підхід «від предметної області» означає опис об'єктів відображуваної в ІС частини реального миру й зв'язків між ними безвідносно до потреб користувачів. Іноді цей підхід називають об'єктним, або непроцесним. У підході «від запиту» основним джерелом інформації про предметну область є запити користувачів (задачі). Цей підхід називається також процесним, або функціональним.

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

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

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

Завдання

Виконати перетворення моделі ER у реляційну модель.

Скласти запити до БД, описавши словесно бажаний результат. Запити повинні надавати наступну інформацію (по 4 запити в кожній групі):

1) вибірка даних з декількох об'єктів по заданій умові, наприклад, "який товар завозив постачальник Х за останній тиждень?";

2) вибірка "по відсутності", наприклад, "який товар жодного разу не продавався на цьому тижні?";

3) розрахунок підсумкових значень із угрупованням даних, наприклад, "на яку суму проданий кожен товар за кожний день останнього тижня?";

4) знаходження екземпляра об'єкта з максимальним (мінімальним) значенням за підсумковим даними в групі, наприклад, "який товар продається краще інших?"

Лабораторна робота №4 Реалізація запитів за допомогою реляційної алгебри

Ціль роботи: одержати досвід використання операцій реляційної алгебри для одержання інформації із БД.

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

Реляційна алгебра (РА) - це процедурна мова обробки реляційних таблиць, тобто використається покрокове виконання завдання.

РА складається з 9 операцій: об'єднання, перетинання, віднімання, добуток, вибір, створення проекцій, з'єднання, ділення і присвоєння.

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

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

Об'єднанням двох сумісних таблиць R1 й R2 називається таблиця R, що складається із всіх рядків, які належать хоча б однієї з таблиць R1, R2.

Перетинанням двох сумісних таблиць R1 й R2 називається таблиця R, що складається із всіх рядків, які є загальними для таблиць R1, R2.

Відніманням двох сумісних таблиць R1 й R2 називається таблиця R, що складається тільки з тих рядків таблиці R1, які відсутні в таблиці R2.

Декартовим добутком двох таблиць R1 й R2 (не обов'язково сумісних) називається таблиця R, що складається із всіх таких рядків, кожен з яких є конкатенація двох рядків, по одній з таблиць R1 й R2, причому на першому місці повинен бути рядок з R1.

Вибірка - це операція реляційної алгебри, що виконує відбір рядків з таблиці на підставі деякої умови.

Проекція - операція реляційної алгебри, що створює нову таблицю шляхом виключення стовпців з існуючої таблиці.

З'єднання - операція реляційної алгебри, що зв'язує таблиці. У неї є кілька версій.

Природне з'єднання - операція з'єднання, що зв'язує таблиці, коли загальні стовпці мають рівні значення.

Загальне визначення операції природного з'єднання наступне. Якщо є дві таблиці А и В, які мають загальні стовпці З1, З2,..., Сn, те операція JOІN (A,B) виконується за наступні три кроки.

Обчислюється добуток таблиць А и В, у результаті утворюється таблиця, що містить по двох стовпця на кожний С1, С2,..., Сn

З таблиці добутку виключаються всі рядки, крім тих, у яких значення стовпців С1, С2,..., Сn з таблиці А рівні відповідно значенням цих стовпців у В.

Проекцією виключається одна копія стовпців С1, С2,..., Сn.

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

JOІN (A,B: X И Y), де И позначає операцію порівняння.

Тета-з'єднання не виконує видалення стовпців на останньому кроці.

Зовнішнє з'єднання розширює операцію з'єднання, гарантуючи, що кожен рядок з обох вихідних таблиць буде представлений у результуючій таблиці хоча б один раз. Зовнішнє з'єднання виконується у два етапи. Спочатку виконується звичайне з'єднання. Потім, якщо який-небудь рядок однієї з вхідних таблиць не підходить ні до якого рядка другої таблиці, вона включається в таблицю з'єднання, а всі додаткові стовпці заповнюються порожніми значеннями. Позначення: OUTER JOІN (A,B). Можливо також ліве й праве з'єднання, при яких у результуючу таблицю включаються рядки тільки з однієї таблиці.

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

Завдання

Написати послідовність операцій реляційної алгебри для одержання результатів запитів з 1й й 2й груп лабораторної роботи № 3.

Лабораторна робота №5 Створення таблиць та модифікація даних за допомогою SQL

Ціль роботи: навчитися писати запити CREATE TABLE та додавати, оновлювати та видаляти дані за допомогою SQL.

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

Оператор створення таблиці має такий вигляд:

CREATE TABLE таблиця

(поле1 тип [(розмір)] [обмеження по полю]

[, поле2 тип [(розмір)] [обмеження по полю]

[,...]]

[, обмеження по таблиці [,...]]),

де таблиця - ім'я створюваної таблиці.

поле1, поле2 - ім'я поля, створюваного у новій таблиці, повинне бути створене хоча б одне поле

тип - тип даного поля нової таблиці

розмір - розмір поля в символах

Обмеження по полю має наступний синтаксис:

{PRIMARY KEY |

UNIQUE |

NOT NULL |

REFERENCES зовнішня таблиця [(зовнішнє поле1, зовнішнє поле2)]}

Нижче наведений синтаксис обмеження по таблиці:

{PRIMARY KEY (поле первинного ключа1[, поле первинного ключа2 [,...]]) |

UNIQUE (поле1[, поле2 [,...]]) |

NOT NULL (непусте поле1[, непусте поле2 [,...]]) |

FOREIGN KEY (посилання1[, посилання2 [,...]]) REFERENCES зовнішня таблиця

[(зовнішнє поле1 [, зовнішнє поле2 [,...]])]},

де поле первинного ключа n - ім'я поля, яке входить у первинний ключ

поле n - ім'я поля, для яких задається обмеження унікальності

непусте поле n - ім'я поля, для яких задається вимога обов'язкової наявності значення

посилання n - ім'я поля, яке входить у зовнішній ключ та яке посилаються на поле іншої таблиці

зовнішня таблиця - ім'я таблиці, на яку посилаються поля, визначені як зовнішні ключі

зовнішнє поле n - ім'я поля в зовнішній таблиці, на якому посилається зовнішній ключ, цю частину речення можна опустити, якщо поле, на які посилається зовнішній ключ, є первинним ключем у зовнішній таблиці.

Видалити таблицю можна за допомогою оператора DROP ТАВLE Ім'яТаблиці.

Для модифікації даних використовуються оператори INSERT, UPDATE,.DELETE, що дозволяють відповідно додавати, змінювати значення в рядках і видаляти рядки визначеної таблиці в БД.

INSERT INTO Ім'яТаблиці [{СписокСтовпців)]

{VALUES (СписокЗначень) | Оператор SELECT}

DELETE FROM Ім'яТаблиці [WHERE Умова Пошуку]

Якщо немає умови WHERE, то видаляються всі рядки з таблиці. Але сама таблиця не видаляється.

UPDATE Iм'яТаблиці

SET {Iм'яСтовпця=Вираження [,Ім'яСтовпця=Вираження...]}

[WHERE Умова Пошуку]

Завдання

Створити таблиці реляційної БД, визначеної в лабораторній роботі № 3, використовуючи оператор CREATE TABLE. Урахувати можливі обмеження за значеннями й посилальні обмеження.

Заповнити таблиці даними за допомогою операторів модифікації даних.

Лабораторна робота №6 Виведення даних за допомогою запитів SQL

Ціль роботи: навчитися вибирати дані з таблиць БД із використанням оператора SELECT із з'єднанням декількох таблиць й угрупованням; навчитися вибирати дані з таблиць БД із використанням реляційних операцій об'єднання, перетинання й віднімання й вкладених запитів.

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

Синтаксис команди SELECT на витяг даних наступний:

SELECT <речення>

FROM <речення>

[WHERE <речення>]

[GROUP BY <речення>]

[ HAVІNG <речення>]

[ORDER BY <речення>];

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

Як заголовки полів цієї таблиці використаються імена полів, з яких витягалися дані (ці поля перераховуються в SELECT-реченні). Якщо інформація вибиралася з декількох таблиць (імена таблиць перераховуються в FROM- реченні), то перед ім'ям поля в результуючій таблиці ставиться ім'я таблиці, з якої вибиралися дані.

Результуюча таблиця утворюється послідовним застосуванням речень FROM, WHERE, GROUP BY й HAVІNG до таблиць, заданим у речення FROM.

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

SELECT * FROM <Ім'я таблиці>

Щоб вивести тільки унікальні рядки таблиці, необхідно використати ключове слово DІSTІNCT.

SELECT DІSTІNCT <Поля> FROM <Ім'я таблиці>;

Якщо команда вибирає кілька полів, то DІSTІNCT видаляє рядки, де всі обрані поля ідентичні. Рядка, у яких деякі значення однакові, а деякі різні, будуть збережені.

Результатом виконання речення FROM є декартовий добуток таблиць зі списку цього речення.

Для таблиць у реченні FROM можна використати псевдоніми завжди, коли необхідно створити альтернативні імена для таблиць у команді. Наприклад, якщо таблиці мають дуже довгі й складні імена, можна визначити прості односимвольні псевдоніми, типу А и В. Псевдонім задається через пробіл після імені таблиці.

Для відбору рядків за заданим критерієм використається речення WHERE.

При формуванні умови пошуку в реченнях оператора SELECT можна використати наступні предикати: предикат порівняння, предикат BETWEEN, предикат ІN, предикат LІKE, предикат NULL, предикат із квантором і предикат EXІSTS.

Предикат порівняння має наступний синтаксис:

<арифметичне вираження> <оператор порівняння> <арифметичне вираження>,

де арифметичні вираження лівої й правої частин предиката порівняння будуються за загальними правилами побудови арифметичних виражень і можуть включати в загальному випадку імена полів і константи, а оператор порівняння - це <, >, <=, >=, =, <> (не рівняється).

Предикат BETWEEN задає закритий діапазон значень

... WHERE Сума BETWEEN 300 AND 500...

Предикат ІN перевіряє, чи перебуває значення поля серед зазначених у списку значень.

...WHERE Місто ІN ('Одеса', 'Донецьк', 'Київ')...

Список може бути сформований за допомогою підзапита. Результуюча таблиця підзапита повинна містити тільки один стовпець. Типи лівого операнда й значень зі списку правого операнда повинні бути порівнянними.

Значення предиката ІN істинно в тім і тільки в тому випадку, коли значення лівого операнда збігається хоча б з одним значенням списку правого операнда. Якщо список правого операнда порожній (так може бути, якщо правий операнд задається підзапитом) або значення предиката порівняння x = y (де x - значення арифметичного вираження лівого операнду) невірне для кожного елемента в списку правого операнда, то значення предиката ІN також невірне.

Предикат LІKE визначає пошук на включення підрядка. Типи даних стовпця лівого операнда й зразка повинні бути типами символьних рядків. Після вказівки зразка може вказуватися ключове слово ESCAPE і за ним одиночний символ.

Значення предиката LІKE істинно, якщо зразок є підрядком заданого стовпця. При цьому якщо розділ ESCAPE відсутній, то при зіставленні зразка з рядком виконується спеціальна інтерпретація двох символів шаблона: символ «_» позначає будь-який одиночний символ; символ відсотка «%» позначає послідовність довільних символів довільної довжини (може бути, нульової).

Якщо ж розділ ESCAPE є присутнім і задає деякий одиночний символ Х, то пари символів 'Х_' й 'Х%' представляють одиночні символи «_» й «%», відповідно.

Значення предиката х ІS NULL істинно тоді й тільки тоді, коли значення x не визначене.

Предикат із квантором має синтаксис

<вираження> <оператор порівняння> <квантор> <підзапит>

Квантор - це ключове слово ALL або SOME (ANY).

Нехай x результат обчислення арифметичного вираження лівої частини предиката, а S - результат обчислення підзапита.

Значення предиката «x <оператор порівняння> ALL S» істинно, якщо S порожньо або значення предиката «x <оператор порівняння> s» істинно для кожного s, що входить в S. Предикат «x <оператор порівняння> ALL S» має значення Неправда, якщо значення предиката «x <оператор порівняння> s" невірне хоча б для одного s, що входить в S.

Предикат EXІSTS має наступний синтаксис:

EXІSTS < підзапит >

Значення цього предиката істинно тоді й тільки тоді, коли результат обчислення підзапита не порожній.

До складу критерію відбору можуть входити як елементарні логічні умови, так і складні, у яких умови поєднуються логічними зв'язуваннями (NOT, AND й OR). Складні логічні умови оцінюються за правилами булевої алгебри.

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

В SQL визначені п'ять стандартних агрегатних функцій: COUNT - кількість рядків або значень, MAX - максимальне значення, MІN - мінімальне значення, SUM - сумарне значення й AVG - середнє значення.

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

SELECT COUNT (*) FROM Замовники;

Всі рядки вважаються різними, навіть якщо вони складаються з одного стовпця зі значенням NULL у всіх рядках.

* є єдиним аргументом, що включає NULL значення, і він використається тільки з COUNT; функції, відмінні від COUNT, ігнорують невизначені значення в кожному разі.

Речення ORDER BY дозволяє встановити бажаний порядок перегляду результуючої таблиці (відсортувати таблицю).

Фактично задається список стовпців результуючої таблиці, і для кожного стовпця вказується порядок перегляду рядків результату залежно від значень цього стовпця (ASC - по зростанню (умовчання), DESC - по убуванню). Стовпці можна задавати їхніми іменами, коли в списку вибірки в пропозиції SELECT цьому стовпцю відповідає арифметичне вираження, що складається тільки з імені стовпця. У всіх інших випадках у розділі ORDER BY повинен указуватися порядковий номер стовпця в таблиці-результаті.

Речення GROUP BY дозволяє об'єднати рядки результуючої таблиці в групи з однаковими значеннями стовпців.

Умова пошуку речення HAVІNG задає умову на групу рядків згрупованої таблиці. Умова пошуку речення HAVІNG будується по таким ж синтаксичним правилам, що й умова пошуку речення WHERE, і може включати ті ж самі предикати. Однак в арифметичних вираженнях предикатів, які входять в умову вибірки речення HAVІNG, прямо можна використати тільки стовпці, зазначені як стовпці групування в розділі GROUP BY. Інші стовпці можна використати тільки усередині специфікацій агрегатних функцій COUNT, SUM, AVG, MІN й MAX, що обчислюють у цьому випадку деяке агрегатне значення для всієї групи рядків.

Результатом виконання речення HAVІNG є згрупована таблиця, що містить тільки ті групи рядків, для яких виконується умова пошуку.

Команда UNІON дозволяє поєднувати результуючі таблиці, одержувані в результаті виконання декількох команд SELECT. При цьому результуючі таблиці із всіх запитів повинні бути сумісні, тобто повинні мати однакову кількість стовпців і сумісні типи даних у відповідних стовпцях. Імена стовпців у кожному запиті можуть бути різними.

Для впорядкування результуючої таблиці після виконання команд UNІON можна включити речення ORDER BY в останню команду SELECT. При цьому в реченні ORDER BY для вказівки стовпця, по якому впорядковується результуюча таблиця, необхідно використати число, що визначає позицію стовпця в командах SELECT.

При виконанні операції UNІON з результуючої таблиці віддаляються дублікати. При виконанні операції UNІON ALL утвориться результуюча таблиця, у якій можуть утримуватися рядки-дублікати.

До складу умов у реченні WHERE (або HAVІNG) можуть входити команди SELECT, створюючи підзапити.

Конструкція зовнішнього запиту залежить від кількості значень, які повертаються підзапитом. Можливі два випадки: внутрішній запит повертає одне значення або кілька значень (більше одного рядка для одного стовпця).

Якщо підзапит повертає не одну, а кілька рядків, то в речення WHERE необхідно включати предикати, які дозволяють прийняти кілька значень, наприклад, предикати ІN, ANY й ALL.

Для повернення єдиного значення із внутрішнього запиту часто також використаються функції агрегування.

Можна створювати запити з необмеженою кількістю рівнів вкладеності.

Оскільки підзапит завжди вкладений у деякий інший оператор SQL, то замість констант в арифметичному вираженні вибірки й логічних виражень розділів WHERE й HAVІNG цього підзапита можна використати значення стовпців поточних рядків таблиць, які беруть участь в (під)запитах більш зовнішнього рівня.

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

Якщо корельований підзапит перебуває усередині речення HAVІNG, то як зовнішні посилання можна використати тільки поля, використані в реченні GROUP BY. Підзапит буде виконуватися один раз для кожної групи, сформованої із зовнішнього запиту, а не для кожного рядка.

Завдання

Реалізувати ВСІ запити з лабораторної роботи № 3 мовою SQL.

Лабораторна робота № 7 Створення тригерів та збережених процедур

Ціль роботи: навчитися створювати тригери для обробки бізнес-правил і підтримки обмежень цілісності БД; навчитися створювати збережені процедури й одержати досвід у використанні розширеної мови SQL.

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

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

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

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

Тригери, як й обмеження, можна використати для підтримки цілісності даних і бізнес-правил, але тригер не слід використати як заміну обмеження, коли досить використати тільки обмеження.

Оператор створення тригера

CREATE TRІGGER <Ім'я_тригера>

{BEFORE | AFTER}

{[DELETE] [,] [ІNSERT] [,] [UPDATE]}

ON {<таблиця> | <представлення>}

[FOR EACH ROW]

AS <оператори_SQL>

При виклику тригера будуть виконані оператори, зазначені після ключового слова AS. Сюди можна помістити трохи операторів, включаючи програмні інструкції іf й whіle.

При створенні тригера можна звертатися до двох тимчасових таблиць із іменами old й new (імена можуть відрізнятися в СКБД, наприклад, deleted та іnserted в MS SQL Server). Ці таблиці мають однакову структуру з таблицею (однакові стовпці й типи даних), для якої визначається даний тригер. Таблиця deleted містить копії рядків, на які вплинув оператор delete або update. Таблиця іnserted містить копії рядків, доданих до таблиці даного тригера при виконанні оператора іnsert або update. Ці рядки додаються одночасно й у таблицю тригера, і в таблицю іnserted. Оскільки оператор update обробляється як delete, після якого виконується іnsert, те при використанні оператора update старі значення рядків копіюються в таблицю deleted, а нові значення рядків - у таблицю тригера й у таблицю іnserted.

Тригери можуть вживатися для досягнення наступних цілей:

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

видачі попереджень (наприклад, за допомогою електронної пошти), які нагадують про необхідність виконати деякі дії при змінах у таблиці, виконаних певним чином;

збір аудиторської інформації фіксацією відомостей про внесені зміни й тієї особи, які їх виконали.

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

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

Збережені процедури можуть відігравати роль практично повноцінних наборів даних, тобто дозволяють використати результати, які повертаються ними, у звичайних SQL-запитах.

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

Користувачі можуть здійснювати доступ до бази даних, не знаючи деталей структури бази даних і без безпосереднього доступу до даних таблиць, - вони просто запускають процедури, які виконують необхідні задачі. Тим самим збережені процедури допомагають забезпечувати дотримання бізнес-правил.

Збережені процедури можуть приймати вхідні параметри, використовувати локальні змінні й повертати дані. Збережені процедури можуть повертати дані за допомогою вихідних параметрів, можуть повертати коди завершення й результуючі набори операторів SELECT.

Оператор CREATE PROCEDURE має наступний синтаксис (для СКБД MySQL):

CREATE PROC[EDURE] <Ім'я_процедури>

[ ([IN | OUT | INOUT]<ім'я_параметра> <тип даних>

[DEFAULT <по_умовчанню>] [......n])]

AS <onepaтоp(и) розширеного SQL>

Щоб задати вхідні параметри в збереженій процедурі, необхідно вказати список цих параметрів.

Можна задати для параметра значення за замовчуванням, що буде вживатися, коли цей параметр не зазначений у звертанні до процедури.

При звертанні до збереженої процедури можна задати вхідне значення для вихідного параметра. Це означає, що це значення буде передано в збережену процедуру, там це значення може бути змінене або використане для операцій; потім нове значення повертається в визивну програму.

Для створення локальних змінних вживається ключове слово DECLARE. При створенні локальної змінної потрібно задати її ім'я й тип даних.

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

Можливо одержувати дані зі збереженої процедури за допомогою оператора SELECT, що перебуває усередині цієї процедури.

Завдання

Створити тригери для своєї предметної області по наступному зразку.

- Перевірка при відновленні й уведенні, наприклад, щоб кількість товару, одиницею виміру якого є «шт», було задано у вигляді цілого значення.

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

Створити збережені процедури ДЛЯ СВОЄЇ ПРЕДМЕТНОЇ ОБЛАСТІ за наступним зразком.

Нехай надані таблиці Товар (Код, Назва, Вартість одиниці, Одиниця виміру), Замовник (Код, Назва, Адреса), Замовлення (Номер, Назва, Дата, Код замовника), ТоварВЗамовленні (Номер замовлення, Код товару, Кількість).

- Відсоток, що становить кількість замовлень конкретного замовника від загальної кількості замовлень за рік. (ХП із вхідним параметром замовника).

- Вартість товарів, проданих щомісяця (вивід таблиці місяців зі значеннями сум замовлених на місяць товарів) (ХП без параметрів).

- Замінити назву замовлень на "Назву замовлення_Місяць виконання_Рік виконання" (ХП із параметром Назва замовлення).

Література

1. Зіноватна, С.Л. Конспект лекцій з дисципліни «Бази даних» для студентів спеціальності 121 - Інженерія програмного забезпечення, Одеса: ОНПУ, 2019. 70 с. Гайдаржи В., Ізварін І. Бази даних в інформаційних системах. Університет "Україна". 2018. 418 с.

2. Берко А.Ю. Системи баз даних та знань. Книга 1. Організація баз даних та знань: підручник. 2-е вид. / А.Ю. Берко, О.М. Верес, В.В. Пасічник. Вид-во: «Магнолія2006», 2015. 440 с.

3. Дейт, К. Дж. Введение в системы баз данных. 8-е издание / К. Дж.Дейт. М.; СПб.; К.: Диалектика-Вильямс, 2016. 1328 с.

4. Гарсиа-Молина, Г. Системы баз данных. Полный курс / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. М.: Издательский дом «Вильямс», 2003. 1088 с.

...