Елемент інформаційної системи для контролю експлуатації автотранспорту

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

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

Міністерство освіти і науки, молоді та спорту України

Криворізький інститут

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

Кафедра технічної кібернетики

ДИПЛОМНА РОБОТА

зі спеціальності

Комп'ютеризовані та робототехнічні системи

ПОЯСНЮВАЛЬНА ЗАПИСКА

Елемент інформаційної системи для контролю експлуатації автотранспорту

Студента

Красівського Олександра Миколайовича

Кривий Ріг 2012

Анотація

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

Програмне забезпечення розроблено за допомогою середовища програмування Delphi з використанням пакету компонентів DevelopmentExpress та сервера баз даних під керуванням FireBird 2.1.

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

Зміст

інформаційна система програмне забезпечення

• ВСТУП
• 1. ПОСТАНОВКА ЗАВДАННЯ
• 1.1 Найменування та галузь застосування
• 1.2 Підстава для створення
• 1.3 Характеристика розробленого програмного забезпечення
• 1.4 Мета й призначення
• 1.5 Загальні вимоги до розробки
• 1.6 Джерела розробки
• 2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ВИКОРИСТАННЯ СУБД INTERBASE І FIREBIRD
• 2.1 Особливості застосування FireBird
• 2.2 Сторінки бази даних
• 2.3 Розмір сторінки бази даних
• 2.4 Діалект бази даних
• 2.5 Типи даних
• 2.6 Сервісні компоненти Delphi та їх особливості
• 2.7 Основні поняття і різновиди архітектур баз даних
• 2.8 Архітектура «файл-сервер» і локальні бази даних
• 2.9 Архітектура «клієнт-сервер»
• 2.10 Обґрунтування вибору архітектури стосовно проектованої системи
• 3. ОСОБЛИВОСТІ ВИКОРИСТАННЯ МОВИ SQL ПРИ РОЗРОБЦІ ІНФОРМАЦІЙНИХ СИСТЕМ
• 3.1 Історія розвитку і основні концепції мови SQL
• 3.2. Структура запитів до окремих таблиць
• 3.3.1 Оператор SELECT
• 3.3.2 Вибірка по умові
• 3.3.3 Агрегатні функції
• 3.3.4 Сортування записів
• 3.4. Багатотабличні запити
• 3.4.1 Об'єднання таблиць
• 3.4.2 Вкладені підзапити
• 3.4.3 Використання оператора EXISTS
• 3.4.4 Використання об'єднання UNION
• 4. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
• 4.1 Загальна характеристика та коло задач, що вирішує проектована система
• 4.2 Розробка логіко-функціональної схеми роботи користувача з системою
• 4.3 Опис моделі й структури таблиць бази даних
• 4.4 Опис інтерфейсу користувача системи
• 4.5 Опис програмної реалізації
• 5 ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ
• ПРОГРАМНОГО ПРОДУКТУ
• 6. ОХОРОНА ПРАЦІ
• 6.1 Аналіз шкідливих та небезпечних факторів
• 6.2 Заходи щодо нормалізації шкідливих і небезпечних факторів
• 6.3 Пожежна безпека
• ВИСНОВКИ
• СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

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

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

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

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

Для реалізації поставленого завдання також була використана СУБД FireBird 2.1., яка є клоном InterBase.

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

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

інформаційна система програмне забезпечення

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь застосування

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

1.2 Підстава для створення

Підставою для розробки є наказ № 55С-01 від 1 листопада 2011 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 03.11.11. Закінчення робіт: 03.05.12.

1.3 Характеристика розробленого програмного забезпечення

Проектоване програмне забезпечення розроблено за допомогою середовища програмування Delphi з використанням пакету компонентів DevelopmentExpress та сервера баз даних під керуванням FireBird 2.1.

Склад розробленої автоматизованої системи:

· AvtoServise.exe - виконавчий файл системи;

· base.fdb - файл бази даних;

· help.hlp - файл довідки;

· бібліотека GDS32.dll - забезпечує зв'язок з SQL сервером FireBird.

1.4 Мета й призначення

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

В дослідницькій частині дипломної роботи були розглянуті теоретичні аспекти використання СУБД INTERBASE і FIREBIRD та особливості використання мови SQL при розробці інформаційних систем.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows;

· Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

· персональний комп'ютер на базі Intel процесору з частотою не менше 2,4 ГГц;

· оперативна пам'ять не менше 1024 Мб;

· монітор із SVGA адаптером;

· НЖМД не менше 250 Гбайт;

· монітор, клавіатура, маніпулятор типу "миша";

Додаткове програмне забезпечення: установка сервера FireBird на комп'ютері де буде встановлена програма.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ВИКОРИСТАННЯ СУБД INTERBASE І FIREBIRD

Промисловий сервер баз даних InterBase призначений для рішення широкого кола завдань. Він містить у собі високу надійність і простоту установки. Сьома версія сервера забезпечує підтримку паралельної роботи на багатопроцесорном устаткуванні. З Delphi поставляється ряд компонентів InterBase eXpress (IBX), що дозволяють без особливих труднощів працювати із цим сервером. Із самим сервером, крім потужних консольних утиліт, поставляється деяка кількість допоміжних інструментів. Однієї з таких утиліт є InterBase Guardian.

Дана утиліта запускається як сервіс і робить безперервний моніторинг роботи сервера. У випадку відмови Guardian перезапускає сервер. На рис. 2.1 показана схема взаємодії додатків із сервером InterBase.

Як видно зі схеми, на основі InterBase можна розробляти двох і трьохланкові програми баз даних. При розробці трьохланкової програми необхідно в якості проміжної ланки використовувати сервер. Взаємодія із сервером може здійснюватися прямо з використанням API-Сервера, за допомогою компонентів InterBase eXpress або через BDE або dbExpress. Слід зазначити, що існує декілька паралельно розвиваючихся Open Source - проектів, таких як FireBird і Yaffil. До певної версії вони є повністю сумісними з InterBase.

Для реалізації поставленого завдання також була використана СУБД FireBird 2.1., яка є клоном InterBase.

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



Рис. 2.1 Схема взаємодії з InterBase

2.1 Особливості застосування FireBird

FireBird - це СУБД, заснована на ядрі Borland InterBase. Вона являє собою повнофункціональний SQL-Сервер. Відмітні якості:

1. Висока продуктивність і надійність при мінімальних вимогах до технічних засобів.

2. Висока масштабованість.

3. Можливості використання Firebird:

· у якості основний СУБД web-сайту;

· у якості настільного, однокористувальницького додатка БД;

· як потужний сервер масштабу підприємства для роботи десятків і сотень користувачів.

4. Розширена підтримка стандарту ANSI SQL-92

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

6. Кросплатформенність. Підтримуються всі версії Windows, починаючи з Windows 98 до Windows7, Linux і UNIX-платформи.

7. Безкоштовність. Нам не треба платити за ліцензію, як у випадку з InterBase, MS SQL або Oracle.

8. Виправлено багато обмежень InterBase.

Широке використання клонів InterBase (InterBase 5.x, 6.x, 7.x, Firebird 1.x, 1.5, Yaffil) говорить багато про що. Наведемо такий, що навіть не претендує на повноту список областей застосування:

· у тисячах ділових додатків у країнах СНД і по усьому світі.

· в одній з моделей танка «Абрамс».

· у телефонних станціях «Motorola».

· у пристроях, що зчитують, на німецьких залізницях.

СУБД Firebird може бути встановлена як на виділений сервер, так і на робочу станцію.

2.2 Сторінки бази даних

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

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



Рис. 2.2 Сторінкова організація зберігання даних

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

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

2.3 Розмір сторінки бази даних

Файл бази даних розбивається на сторінки фіксованого розміру. Сервер FireBird посторінково зчитує й записує зміни в базу даних. Таким чином, щоб зробити абияку операцію із записом, він зчитує всю сторінку. Але при цьому рекомендується встановлювати розмір сторінки не менш 4096 байт.

Припустимо, що запис має кілька десятків полів, кожне з яких займає кілька десятків байт. Такий запис при малому обсязі сторінки буде займати кілька сторінок. Отже, для того щоб здійснити з нею яку-небудь операцію, сервер буде змушений звернутися до диска кілька разів, що саме по собі негативно позначиться на продуктивності. Як було відзначено раніше, розмір сторінки в InterBase 7 може приймати значення 1024, 2048, 4096 і 8192 байт. Якщо база даних розташовується на диску з файловою системою NTFS, розмір сторінки варто встановлювати 4096 байт (рівним розміру кластера), якщо файловою системою є FAT32, то краще під сторінку відводити 8192 байтів.

2.4 Діалект бази даних

У ході еволюції InterBase (ці відомості використовуються й до FireBird) у різних версіях змінювалися типи даних і використовуваних операторів мови SQL. Цей процес породив необхідність створення діалектів - форматів типів даних. На даний момент існує три діалекти - 1, 2 і 3. Перший діалект підтримують сервери InterBase версії 4 і 5, а третій діалект підтримується серверами, починаючи із шостої версії. У третьому діалекті виділені поля дати й часу. Також уведені типи даних для роботи з більшими цілими числами. Третій діалект не підтримує неявне приведення типів, на відміну від першого діалекту.

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

2.5 Типи даних

InterBase і FireBird підтримує більшість типів даних SQL 92, враховуючи типу BLOB і масиви. Будь-який тип даних має набір операцій, які можна виконувати зі значеннями цього типу, тому необхідно правильно вибрати тип на етапі розробки бази даних. У версії сервера визначено 13 типів даних:

· BLOB - тип даних з динамічно змінюваним розміром, призначений для зберігання даних великого розміру. У цих полях зберігаються графічні дані, великі масиви текстів, музика й багато чого іншого. Дані зберігаються в сегментах розміром по 64 Кбайт.

· Boolean - логічне поле. Може приймати значення True, False і Unknown. Має розмір два байти.

· CHAR(n) - символьне поле фіксованої довжини. Розмір поля визначається на етапі проектування й вказується як параметр n. Поле може займати до 32 767 байт.

· DATE - поле дати. Може приймати значення від 1 січня 100 року до 29 лютого 32768 року. Поле займає чотири байти.

· DECIMAL - числовий тип даних з фіксованою точкою. Тип даних приймає як аргументи розрядність і точність збережених чисел. Розрядність визначає загальне число цифр, а точність - число цифр після коми. Розрядність може бути визначена в межах від 1 до 18 знаків, а точність - досягати певної перед цим розрядності. Поле може займати розмір 16, 32 або 64 біта.

· DOUBLE PRECISION - речовинний тип даних підвищеної точності. Число може перебувати в діапазоні від 2,25* 10-308 до 1,797*10308 і мати розмір до 15 знаків. Поле займає вісім байтів.

· FLOAT - речовинний тип даних. Число може перебувати в діапазоні від 1,175* 10-38 доз,4002х1038 і мати розмір до 15 знаків. Поле займає чотири байти.

· INTEGER - знаковий цілочислений тип даних. Може приймати значення в діапазоні від -2 147 483 648 до 2 147 483 647. Поле займає чотири байти.

· NUMERIC - еквівалентний типу DECIMAL.

· SMALLINT - знаковий цілочислений тип даних. Може приймати значення в діапазоні від -32 768 до 32 767. Поле займає два байти.

· TIME - зберігає дані про час із точністю до десятитисячної частки секунди. Може приймати значення в діапазоні від 00:00 до 23:59.9999.

· TIMESTAMP - тип даних, що зберігає інформацію про дату й час. Фактично, являє собою комбінацію типів DATE і TIME.

· VARCHAR(n) - символьне поле змінної довжини. Розмір поля визначається на етапі проектування й вказується як параметр n. Поле може займати до 32 767 байт.

2.6 Сервісні компоненти Delphi та їх особливості

Компоненти InterBase eXpress (IBX) призначені для роботи із сервером InterBase, використовуючи InterBase API. Використовуючи дані компоненти, можна одержувати дані, вносити в них зміни, управляти транзакціями, одержувати відомості про базу даних, відслідковувати стан процесів виконання запитів і здійснювати інші дії. Основою коду IBX є Open Source - бібліотека FreeIBComponents, розроблена Грегорі Ділтцом в 1998 році.

На вкладці InterBase Admin розташовані компоненти, призначені для керування сервером і одержання різної інформації про режими його роботи. Компоненти, фактично, являють собою “обгортку” для методів InterBase Services API. Перелік можливостей цих методів досить широкий:

· архівування й відновлення баз даних, відключення й перезавантаження сервера, складання “сміття”, сканування таблиць для пошуку помилок;

· створення, модифікація й видалення облікових записів;

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

· одержання інформації про конфігурацію сервера й баз даних.

За виконання перерахованих вище завдань відповідає об'єкт Services Manager, що одержує виклики від клієнтських додатків за допомогою Services API. На рис. 2.3 показана схема, що відбиває зміст сказаного. Сімейство функцій Services API складається із чотирьох функцій:

· Функція isc_service_attach здійснює встановлення з'єднання з об'єктом Services Manager.

· Функція isc_service_start здійснює виклик потрібного методу об'єкта Services Manager.

· Функція isc_service_query повертає запитану інформацію або результат виконання викликаного раніше методу.

· Функція isc_service_detach розриває з'єднання з об'єктом Services Manager.

Для визначення додаткових параметрів з'єднання, створюваного методом isc_service_attach, варто скористатися спеціальним буфером Services Parameter Buffer (SPB), адреса якого передається методу в якості одного з параметрів. Буфер параметрів являє собою масив типу Char і може бути використаний для передачі ім'я користувача й пароля.

Клас TIBCustomService є загальним предком для всіх компонентів IBService. У його властивості ServerName вказується ім'я сервера, на якому будуть використовуватися сервіси. Для того щоб визначити параметри з'єднання, варто використовувати властивість ServiceParamBySPB, що дозволяє звернутися до параметра буфера по його індексі. Наприклад, вираження ServiceParamBySPB [isc_SPB_user_name] дозволяє одержати або встановити ім'я користувача.

isc_service_query ()

isc_service_start()

Рис. 2.3 Взаємодія з InterBase Services

На рис. 2.4 представлена ієрархія компонентів IBX Services. Основою всіх компонентів є клас TIBCustomService.

Метод Attach здійснює з'єднання з базою даних. У момент з'єднання з базою даних ініціюється подія OnAttach.

Для активації сервісу варто привласнити властивості Active значення True, відповідно, для деактиваціі варто привласнити властивості значення False.

Для доступу до параметрів бази даних варто використовувати властивість Params, а для вибору мережного протоколу, по якому буде вироблятися з'єднання із сервером, використовується властивість Protocol.

Рис. 2.4 Ієрархія компонентів IBX Services

2.7 Основні поняття і різновиди архітектур баз даних

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

Ядро БД відповідає за управління даними в зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журналізацією. Відповідно, можна виділити такі компоненти ядра (принаймні, логічно, хоча в деяких системах ці компоненти виділяються явно), як менеджер даних, менеджер буферів, менеджер транзакцій. Ядро БД володіє власним інтерфейсом, не доступним користувачам безпосередньо і використовуваним в програмах, що створені компілятором SQL і утилітах БД. Ядро БД є основною резидентною частиною СУБД. При використанні архітектури "клієнт-сервер" ядро є основною складовою серверної частини системи. Основною функцією компілятора мови БД є компіляція операторів мови БД в деяку виконувану програму. В окремі утиліти БД звичайно виділяють такі процедури, які дуже невигідно виконувати з використанням мови БД, наприклад, завантаження і вивантаження БД, збір статистики, глобальна перевірка цілісності БД і т.д. Утиліти програмуються з використанням інтерфейсу ядра БД, а іноді навіть з проникненням всередину ядра. Загальний склад засобів, необхідних для роботи готового додатку з БД, показаний на рис. 2.5.

Рис. 2.5 Загальний склад засобів для роботи системи з БД

Згідно цій загальній схемі, ми маємо ланцюжок:

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

Місцеположення Ядра БД і баз даних залежить від використовуваної архітектури. Є чотири різновиди архітектури баз даних:

· локальні бази даних;

· архітектура "файл-сервер";

· архітектура "клієнт-сервер";

· багатоланкова (триланкова N-tier або multi-tier) архітектура.

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

2.8 Архітектура «файл-сервер» і локальні бази даних

Локальні бази даних і архітектура "файл-сервер".

Рис. 2.6 Архітектура системи при роботі з локальними БД

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

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

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

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

2.9 Архітектура «клієнт-сервер»

Архітектура "файл-сервер" неефективна, принаймні, в двох відносинах. При виконанні запиту до бази даних, розташованої на файловому сервері, насправді відбувається запит до локальної копії даних на комп'ютері користувача. Тому перед виконанням запиту дані в локальній копії оновлюються з реальної БД. Дані оновлюються в повному об'ємі. Так, якщо таблиця БД складається з 1000 записів, а для виконання запиту (наприклад, видати суму премій за жовтень у відділі Y) реально потрібно 10 записів, все одно перегоняться всі 1000 записів. Таким чином, не потрібно мати дуже багато користувачів і запитів від них, щоб серйозно завантажити мережу, що, звичайно ж, не може не позначитися на її швидкодії.

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

Рис. 2.7 Архітектура „клієнт-сервер”

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

Архітектура "клієнт-сервер" розділяє функції програми користувача (званого клієнтом) і сервера.

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

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

· посилка до сервера запитів;

· інтерпретація результатів запитів, одержаних від сервера, і представлення їх користувачу в необхідній формі;

· реалізація інтерфейсу користувача.

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

· прийом запитів від програм-клієнтів, інтерпретація запитів, виконання запитів в БД, відправка результату виконання запиту програмі-клієнту;

· управління цілісністю БД, забезпечення системи безпеки, блокування невірних дій програм-клієнтів;

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

· забезпечення одночасно безпечної і відмовостійкої, розрахованої на багато користувачів роботи з одними і тими ж даними.

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

До розрядку промислових СУБД належать: Oracle, Gupta, Informix, Sybase, MS SQL Server DB2, InterBase і ряд інших.

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

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

2.10 Обґрунтування вибору архітектури стосовно проектованої системи

Використання архітектури „клієнт-сервер”:

· різко зменшує мережевий трафік;

· знижує складність програм-клієнтів (оскільки тим вже немає необхідності забезпечувати цілісність і безпеку БД і стежити за параметрами розрахованої на багато користувачів роботи з БД);

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

· підвищує надійність БД, її цілісність, безпеку і секретність.

3. ОСОБЛИВОСТІ ВИКОРИСТАННЯ МОВИ SQL ПРИ РОЗРОБЦІ ІНФОРМАЦІЙНИХ СИСТЕМ

3.1 Історія розвитку і основні концепції мови SQL

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

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

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

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

Поява теорії реляційних баз даних і запропонованої Коддом мови запитів "alpha", заснованої на реляційному численні, ініціювало розробку ряду мов запитів, які можна віднести до двох класів:

Мови, алгебри, що дозволяють виражати запити засобами спеціалізованих операторів, вживаних до відносин (JOIN - з'єднати, INTERSECT - перетнути, SUBTRACT - відняти і т.д.).

Мови числення предикатів є набором правил для запису виразу, що визначає нове відношення із заданої сукупності існуючих відносин. Іншими словами числення предикатів є метод визначення того відношення, яке нам бажано одержати (як відповідь на запит) з відносин, вже наявних в базі даних. Розробка, в основному, йшла у відділеннях фірми IBM (мови ISBL, SQL, QBE) і університетах США (PIQUE, QUEL). Останній створювався для СУБД INGRES (Interactive Graphics and Retrieval System), яка була розроблена на початку 70-х років в Університеті шт. Каліфорнія і сьогодні входить в п'ятірку кращих професійних СУБД. Сьогодні зі всіх цих мов повністю збереглися і розвиваються QBE (Query-By-Example - запит за зразком) і SQL, а з інших узяті в розширення внутрішніх мов СУБД тільки найцікавіші конструкції.

На початку 80-х років SQL "переміг" інші мови запитів і став фактичним стандартом таких мов для професійних реляційних СУБД. У 1987 році він став міжнародним стандартом мови баз даних і почав упроваджуватися у всі поширені СУБД персональних комп'ютерів. Чому ж це відбулося?

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

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

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

Для виключення вказаних і деяких інших недоліків була запропонована технологія клієнт-сервер, по якій запити призначених для користувача ЕОМ (Клієнт) обробляються на спеціальних серверах баз даних (Сервер), а на ЕОМ повертаються лише результати обробки запиту. При цьому, природно, потрібна єдина мова спілкування з Сервером і як така мова вибрана SQL. Тому всі сучасні версії професійних реляційних СУБД (DB2, Oracle, Ingres, Informix, Sybase, Progress, Rdb) і навіть нереляційних СУБД (наприклад, Adabas) використовують технологію клієнт-сервер і мову SQL.

Існує думка: Оскільки велика частина запитів формулюється на SQL, практично байдуже, що це за СУБД - був би SQL.

Реалізація в SQL концепції операцій, орієнтованих на табличне представлення даних, дозволило створити компактну мову з невеликим (менше 30) набором операторів. Мова SQL може використовуватися як інтерактивна (для виконання запитів) і як вбудована (для побудови прикладних програм).

На рис. 3.1 показана схема, що відображає принцип використання SQL. Користувач передає запит інтерпретатору, який, у свою чергу, повертає уявлення, таблицю або курсор. Ці об'єкти знаходяться на так званому віртуальному рівні і формуються тільки за запитом. Але вони взаємодіють з реальним рівнем, тобто з таблицями баз даних, на основі яких відбувається формування віртуальних об'єктів. Звичайно, дане розділення є умовним, але воно добре відображає ідеологію SQL.

3.2 Структура запитів до окремих таблиць

Достатньо поширеним є завдання отримання даних з однієї або декількох таблиць і формування на їх основі яких-небудь звітів. У даному розділі будуть викладені базові поняття SQL і способи створення відповідних запитів.

3.2.1 Оператор SELECT

Оператор SELECT є виразом, що ініціює виконання запиту. В даному випадку запит є командою на отримання даних. Вираз SELECT має строго певний формат:

SELECT [[ALL] | DISTINCT]{ * | елемент_SELECT [.елемент _SELECT] ...}

FROM{ базова_таблиця | уявлення} [псевдонім]

[.{ базова_таблиця | уявлення} [псевдонім]]

[WHERE умова]

[GROUP BY назва поля (полів) [HAVING фраза]]:

Рис. 3.1 Схема взаємодії з базою даних за допомогою SQL

3.2.2 Вибірка по умові

Вибірку по умові реалізує оператор WHERE. Оператор є частиною виразу SELECT і служить для завдання умов відбору записів в результуючий набір. В ході виконання запиту відбувається перевірка всіх записів на відповідність умові відбору. Як приклад можна привести досить простий запит:

SELECT State,City,Company FROM Customer

WHERE State = 'CA'

При обробці запиту був похідний відбір всіх записів, поле State яких має значення СА.

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

SELECT Company,Phone,Fax FROM Customer

WHERE Phone = Fax

Виключення значень, що повторюються

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

SELECT DISTINCT Country FROM Customer

Обчислювані поля

Автоматичне обчислення значень полів досить часто застосовується в найрізноманітніших запитах. Приклад відповідного запиту виглядає досить просто:

SELECT OnHand,OnOrder,(OnHand*OnOrder) AS

Твір, (OnHand+OnOrder) AS Сума FROM Parts

У даному прикладі проводиться перемножування і підсумовування значень полів OnHand і OnOrder.

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

Запит SELECT може також включати числові і текстові константи. Як приклад можна привести наступний запит:

SELECT OnHand,OnOrder,'MUL',(OnHand + 1) AS Плюс,'SUB',(OnHand - 1) AS Мінус FROM Parts

У лапках вказані текстові константи, які будуть включені в результуючу таблицю як значення відповідних полів.

Оператори порівняння і логічні оператори

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

Логічні оператори дозволяють задати в запиті логічні умови. Оператор AND реалізує логічне “І”. Оператор OR реалізує логічне “АБО”. Вираз з його використанням, вважатиметься істинним, якщо хоч би одна з умов теж є істиною. Оператор NOT означає логічне заперечення. Його дія зводиться до того, що він інвертує логічну умову, перед якою його розташовують.

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

SELECT LastName, FirstName, Salary FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000

В результаті виконання запиту повертаються імена співробітників із заробітною платнею від 25 до 30 тисяч включно. В даному випадку оператор AND використовується для завдання діапазону вибираних значень.

Тепер можна змінити даний запит. Можна відшукати всіх співробітників, для яких окрім приведених вище умов поле PhoneExt яких має значення 22:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000 and PhoneExt = '22'

Якщо ж потрібно буде відшукати співробітників, поле PhoneExt яких має значення, не рівне 22, запит буде трохи змінений:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000 and not PhoneExt = '22'

Як видно з тексту запиту, логічна умова NOT дозволила виключити непотрібні номери.

Тепер можна розглянути приклад запиту з використанням оператора OR. Припустимо, менеджеру знадобилося одержати списки всіх співробітників по прізвищу Johnson. Або тих співробітників, які одержують заробітну платню більше 45 000. Скласти запит буде неважко:

SELECT LastName, FirstName, Salary FROM Employee

WHERE LastName = 'Johnson' or Salary > 45000

Варто звернути увагу на дію оператора 0R. У набір даних були включені записи, значення поля Salary яких перевищувало 40 000, і ті записи, в яких поле LastName мало значення Johnson.

Використання оператора IN

Оператор IN визначає масив значень, в який може входити або не входити значення поля даного запису. Наприклад, необхідно вибрати співробітників із заробітною платнею 40 000, 55 500 і 25 000. Запит потрібно буде переробити:

SELECT LastName, FirstName, Salary FROM Employee

where Salary = 40000 or Salary = 55500 or Salary = 25000

Проте цей же запит можна написати в коротшій і красивішій формі за допомогою оператора IN:

SELECT LastName, FirstName, Salary FROM Employee

where Salary IN (40000, 55500, 25000)

Як аргументи оператору IN були передані значення полів, по яких проводився відбір записів.

Оператор IN може використовуватися і для пошуку символьних значень. Припустимо, нам необхідно з'ясувати назви компаній, що знаходяться в містах Christiansted, Grand Cayman і St. Thomas. Ці дані міститися в таблиці Customer. Запит знову знадобиться трохи змінити:

SELECT Company, City FROM Customer

WHERE City IN (`Christiansted','Grand Cayman','St.Thomas')

Використання оператора BETWEEN

Оператор BETWEEN використовується для вказівки діапазону значень, які використовуються для установки умови відбору записів. Цей оператор чутливий до порядку переліку параметрів, що визначають межі діапазону. Як приклад можна привести простий запит:

SELECT CustomerID, EmployeeID, ShipName FROM Orders

WHERE EmployeeID BETWEEN 3 AND 5

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

Наступний приклад показує, як можна вибрати номери замовлень, зроблених за певний проміжок часу від 04.07.1996 до 08.07.1996:

SELECT OrderlD, OrderDate, ShipName FROM Orders

WHERE OrderDate BETWEEN '07.04.1996' AND '07.08.1996'

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

SELECT OrderID, OrderDate, ShipName, Freight FROM Orders

WHERE OrderDate NOT BETWEEN '07.04.1996' AND '07.08.1996' AND Freight > 100

Використання оператора LIKE

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

Припустимо, необхідно вибрати компанію, в назві якої не вистачає декількох букв. В цьому випадку назву можна позначити як S?mons?bistro. Відповідний запит використовуватиме вказаний оператор LIKE:

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE 'S_rnons_bistro'

Можна скласти запит, в якому проводитиметься пошук якогось підрядка, що входить в запис. Припустимо, що необхідно знайти всі компанії, в назвах яких зустрічається послідовність символів “ric”.

Задачу вирішує нескладний запит

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%Ric%'

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

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%R c%'

3.2.3 Агрегатні функції

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

· Оператор COUNT повертає кількість записів, що задовольняють умові запиту.

· Оператор SUM підсумовує значення записів поля.

· Оператор AVG обчислює середнє значення записів поля.

· Оператор МАХ повертає найбільше значення даного поля.

· Оператор MIN повертає найменше значення даного нуля.

Агрегатні функції використовуються подібно до імен полів в запиті, а справжні імена полів передаються їм як аргументи. З операторами SUM і AVG можуть використовуватися тільки числові поля. З операторами COUNT, MAX і MIN можуть використовуватися числові і символьні поля. У разі застосування функцій МАХ і MIN до символьних полів їх значення будуть трансльовані в ASCII-код. Мінімальному значенню функції відповідатиме символ алфавіту, що знаходиться ближче до його початку, максимального, -- що знаходиться ближче до кінця.

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

SELECT AVG(Freight) AS Середнє, MIN(Freight) AS Мін, MAX(Freight) AS Макс, SUM(Freight) AS Сумарне, COUNT(Freight) AS Кількість FROM Orders

WHERE Freight >300

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

SELECT COUNT(DISTINCT City) AS Кількість_міст FROM Customers

В ході виконання запиту з оператором DISTINCT було зафіксовано 69 записів. Без використання оператора -- 91. Для виключення повторів при використанні функцій AVG і SUM теж може бути використаний цей оператор.

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

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

SELECT City, COUNT(*) AS Кількість, MAX(PostalCode) AS Почтовий_індекс FROM Customers GROUP BY City

Легко відмітити, що поле City не входить в агрегатну функцію як параметр, тому його було оголошено з використанням оператора GROUP BY. В ході виконання запиту були вибрані міста, і для кожного міста була підрахована кількість входжень.

Цей приклад можна ускладнити. Можна створити запит, який одержує тільки ті міста, які повторюються в таблиці більше двох разів, і при цьому в кінцевий результат не повинне включатися місто Buenos Aires. Оператор WHERE в даному випадку використовувати не вийде, оскільки він працює тільки з окремими записами, а не з масивами. Доведеться використовувати оператора HAVING, який є аналогом оператора WHERE, але може працювати з агрегатними функціями. Сам запит буде досить сильно змінений:

SELECT City, COUNT(*) AS Кількість, MAX(PostaTCode) AS

Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

3.2.4 Сортування записів

Оператор ORDER BY використовується для впорядковування записів результуючого набору даних. Записи сортуються відповідно до порядку проходження полів і їх значень. Якщо сортування проводитиметься за збільшенням, то слід використовувати параметр ASC. Для сортування по убуванню використовується параметр DESC. Як приклад можна привести нескладний SQL- запит

SELECT CompanyName,ContactName,City FROM Customers

ORDER BY City

Сортування записів проводиться по полю City.

До створеного запиту можна додати сортування по кількості міст у порядку убування записів:

SELECT City, COUNT(*) AS Кількість, MAX(PostalCode) AS Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

ORDER BY Кількість DESC, City ASC

Потрібно звернути увагу на те, що як аргумент параметра ORDER BY була використана назва поля, оскільки його значення є результатом агрегатної функції COUNT. Для включення сортування по убуванню був вказаний параметр DESC, розташований після назви поля.

3.3 Багатотабличні запити

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

3.3.1 Об'єднання таблиць

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