- •1. Пояснення до тексту пояснювальної записки
- •1. Постановка задачі до курсової роботи
- •2. Теоретична частина (короткий опис візуальних та програмних засобів PostfreSql)
- •1.2. Поради щодо складання тексту пояснювальної записки
- •2. Варіанти задач курсової роботи
- •Варіант 2 Реалізація продукції хлібозаводу
- •Варіант 3 Нафтогазоносні родовища України
- •Варіант 4 Розміри газонафтоносних родовищ України
- •Варіант 5 Газосховища України
- •Варіант 6 Нафтобази України
- •Варіант 7 Транспортування газу по території України
- •Варіант 8 Забезпеченість України паливно-мастильними матеріалами
- •Варіант 9 Видобування нафти на Україні
- •Варіант 10 Запаси нафти на родовищах України
- •Варіант 11 Зміни запасів нафти в родовищах України
- •Варіант 12 Гiдрохiмiчний стан поверхневих вод
- •Варіант 13 Реалізація продукції хлібозаводу
- •Варіант 14 Облік відвідування занять студентами вузу
- •Варіант 15 Газосховища України
- •Варіант 16 Вміст нафтопродуктів у нафтобазах України
- •Варіант 17 Забезпеченість паливно-мастильними матеріалами
- •Варіант 18 Добовий видобуток нафти на Україні
- •Варіант 19 Кадровий облік працівників фірми
- •Варіант 20 Дані про туристичну фірму (даний варіант розглянути в прикладі)
- •Варіант 21 Продажа товарів торгівельною фірмою
- •Варіант 22 Продажа фірмою виробів із сої
- •Варіант 23 Виготовлення продукції підприємствами виробничого об’єднання
- •Варіант 24 Малий бізнес
- •Варіант 25 Книжковий магазин
- •Варіант 26 Заклади освіти
- •Варіант 27 Науково-технічна література бібліотеки
- •Напрям: код напряму, напрям;
- •Варіант 28 Транспортні підприємства
- •Варіант 29 Автомобілі
- •Варіант 30 Підприємства-банкрути
- •Завдання
- •Дата видачі завдання 02.09.2013 р.
- •Календарний план
- •1. Вступ
- •2 Коротка історія postgresql
- •2.1 Проект postgres його заснування та розробка
- •3 Основні концепції роботи з postgresql
- •3.1 Створення таблиць
- •3.1.1 Типи даних
- •3.2 Внесення даних у таблицю
- •Insert into ім’я_таблиці [(список_імен_полів)] values (значення1, значення2, …, значення n);
- •3.3 Редагування таблиць
- •Alter table ім’я_таблиці owner то новий_власник
- •3.4 Обмеження
- •Immediate – всі або конкретне обмеження перевіряються наприкінці кожної команди.
- •3.5 Послідовності
- •Drop sequence перелік_послідовностей
- •3.6 Запити
- •3.7 Об'єднання таблиць (Join)
- •3.8 Агрегатні функції
- •3.9 Курсори sql
- •4 Основні елементи мови plpgsql
- •4.1 Структура мови, функції користувача
- •4.2 Розгалуження, цикли, масиви
- •4.3 Курсори
- •5. Практична частина Завдання в-20
- •5.1 Завдання 1
- •Результати виконання:
- •5.2 Завдання 2
- •Розв'язок задачі
- •Задача 8.
- •Розв'язок задачі
- •Результати запиту:
- •5.4 Завдання 4
- •Розв'язок задачі
- •Результат задачі
- •Задача 6,9
- •Розв’язок задачі
- •Результат задачі:
- •6. Висновки
- •7. Список використаної літератури
- •Рекомендована література
3.7 Об'єднання таблиць (Join)
Ми бачимо, що наші запити використовують в тільки одну таблицю. Але запити можуть одночасно звертатися до декількох таблиць або до в один і той же час до тієї ж таблиці але з іншим способом обробки довільних записів. Запит, який звертається до кількох записів однієї таблиці або до декількох таблиць одночасно, називається join запитом (об'єднанням). Як приклад, скажімо ви хочете подивитися всі записи про погоду разом з тими містами, до яких вони належать. Щоб це зробити, нам потрібно порівняти поле city кожного запису про погоду в таблиці погоди weather з ім'ям поля всіх записів в таблиці міст cities, і вибрати пари записів, де ці значення збігаються.
Примітка: Це тільки концептуальна модель. Фактично, об'єднання може бути виконано більш ефективно, але це буде не видно користувачеві.
Таким чином, потрібна нам дію буде виконано наступним запитом:
SELECT * FROM weather, cities WHERE city = name;
city | temp_lo | temp_hi | prcp | date | name | location
---------------------------------------------------------------------------------------------------
San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | (-194,53)
San Francisco | 43 | 57 | 0 | 1994-11-29 | San Francisco | (-194,53)
Після виконання якого ми отримаємо два рядки:
Тут немає запису для міста Hayward, тому що для цього міста немає відповідного запису в таблиці cities, і таким чином, об'єднання ігнорує незбіжні записи в таблиці weather.
В отриманому результаті є два поля, що містять ім'я міста. Це правильно, тому що відбувається злиття списку полів таблиць weather і cities. На практиці це небажано, і тому треба явно вказати ті поля, які потрібно, замість використання :
SELECT city, temp_lo, temp_hi, prcp, date, location
FROM weather, citiesWHERE city = name;
Оскільки всі поля мають різні імена, аналізатор автоматично знаходить яке ім'я відповідає якій таблиці, але хорошим стилем у запитах об'єднання є вказівка повного імені поля:
SELECT weather.city, weather.temp_lo, weather.temp_hi,
weather.prcp, weather.date, cities.location
FROM weather, cities
WHERE cities.name = weather.city;
Запити об'єднання такого виду, можуть бути також записані в альтернативній формі, яку значно доцільніше використовувати, ніж попередню:
SELECT * FROM weather INNER JOIN cities ON
(weather.city = cities.name);
Тепер розглянемо як можна отримати записи для міста Hayward. Для цього потрібен такий запит, який би виконав сканування таблиці weather і для кожного запису в ній, знайшов відповідний запис у таблиці cities. Якщо відповідний запис не знайдено, ми хочемо підставити деякі "порожні значення" на місце полів таблиці cities. Такий вид запитів називається outer join (зовнішнє об'єднання). (Яке як ми бачимо відрізняється від inner join (внутрішнього об'єднання)). Ось як буде виглядати запит:
SELECT * FROM weather LEFT OUTER JOIN cities
ON (weather.city = cities.name);
city | temp_lo | temp_hi | prcp | date | name | location
------------------------------------------------------------------------------------------------
Hayward | 37 | 54 | | 1994-11-29 | |
San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | (-194,53)
San Francisco | 43 | 57 | 0 | 1994-11-29 | San Francisco | (-194,53)
Даний запит називається left outer join, тому що для таблиці згадується в лівій частині оператора об'єднання join в отриманому результаті буде видано всі записи принаймні один раз, у той час як для таблиці праворуч в результат потраплять тільки ті записи, які відповідають записам у таблиці ліворуч. Коли буде проводиться висновок записи з таблиці ліворуч, для якої немає відповідного запису в таблиці праворуч, в поля, відповідні таблиці праворуч будуть підставлені порожні (null) значення.
Ми також можемо об'єднувати таблицю з собою ж. Такий вид запитів називається self join. Припустимо, що ми хочемо знайти всі записи про погоду, які знаходяться в певному діапазоні температур. Для цього нам необхідно порівняти значення полів temp_lo і temp_hi для кожного запису про погоду weather з значеннями полів temp_lo і temp_hi для всіх інших записів про погоду weather. Ми можемо зробити це за допомогою наступного запиту:
SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high,
W2.city, W2.temp_lo AS low, W2.temp_hi AS high
FROM weather W1, weather W2
WHERE W1.temp_lo < W2.temp_lo
AND W1.temp_hi > W2.temp_hi;
city | low | high | city | low | high
------------------------------------------------------------------
San Francisco | 43 | 57 | San Francisco | 46 | 50
Hayward | 37 | 54 | San Francisco | 46 | 50
У цьому запиті переназвано таблицю weather іменами W1 і W2 щоб розрізняти ліву і праву частини оператора об'єднання join. Також можна використовувати такі види псевдонімів в інших запитах, щоб зробити запис запиту коротшим, тобто:
SELECT * FROM weather w, cities c WHERE w.city = c.name;
Такий стиль абревіатур зустрічається часто.
