Розробка гнучкої системи автоматизації обліку імунобіологічних препаратів

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

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

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

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

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

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

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

7.091402 “Гнучкі комп'ютеризовані системи та робототехніка“

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

”Розробка гнучкої системи автоматизації обліку

імунобіологічних препаратів”

Студента групи ГКС-03-з Горбенко Олени Олександрівни

Керівник роботи проф., к.т.н. Корнілов Георгій Іванович

Консультанти:

зі спеціальної частини доц. Вдовиченко І.Н.

з програмної частини проф., д.т.н. Мурашко А.Г.

з економічної частини доц., к.е.н. Тимко Є.В.

з охорони праці доц., к.т.н. Климович Г.Б.

нормоконтроль ст. викл. Супрунова Ю.А.

Завідувач кафедри ТК доц., к.т.н. Старіков О.М.

Кривий Ріг 2008

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

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

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

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

Спеціальність 7.091402 “Гнучкі комп'ютеризовані системи та робототехніка“

ЗАТВЕРДЖУЮ

Зав. кафедрою доц., к.т.н. Старіков О.М.

_______________________

" 31 " жовтня 2007 р.

ЗАВДАННЯ

на дипломну роботу студента

Горбенко Олени Олександрівни

(прізвище, ім'я, по-батькові)

1. Тема роботи: Розробка гнучкої системи автоматизації обліку імунобіологічних препаратів

затверджена наказом по інституту від " 29 " жовтня 2007 р. №65Са-01

2. Термін здачі студентом закінченої роботи 01.06.08.___________

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, вихідні масиви даних

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка задачі, Інформаційні системи як сукупність організаційних і технічних засобів для збереження та обробки інформації; Основи технології Activex Data Objects (ADO); Опис функціональних можливостей і програмної реалізації системи; Економічне обґрунтування доцільності розробки програмного продукту; Охорона праці.

5. Перелік графічного матеріалу (з точними вказівками обов'язкових креслень)

1. Логіко-функціональна схема роботи користувача з системою;______

2.Схема взаємозв'язку таблиць бази даних;________________________

3. Типи та призначення полів таблиць бази даних__________________

4. Приклади робочих вікон системи; __________________________

5. Ієрархія форм системи;_______________________________________

6. Схема архітектури ADO; ___________________________________

7. Схема взаємодії в ADO основних COM інтерфейсів ______________

8. Схема компонентів OLE DB__________________________________

6. Консультанти з роботи, з вказівками розділів роботи, що належать до них

Розділ	Консультант	Підпис, дата
		Завдання видав	Завдання прийняв
Спеціальна частина	Вдовиченко І.Н.
Програмна частина	Мурашко А.Г.
Економічна частина	Тимко Є.В.
Охорона праці	Климович Г.Б.

7. Дата видачі завдання 31.10.07 р.

Керівник ____________________

(підпис)

Завдання прийняв до виконання ____________________

(підпис)

КАЛЕНДАРНИЙ ПЛАН

№ п/п	Найменування етапів дипломної роботи	Термін виконання етапів роботи	Примітки
1.	Отримання завдання на дипломну роботу	31.10.07
2.	Огляд існуючих рішень	20.02.08
3.	Обґрунтування вибраного рішення	03.03.08
4.	Програмна частина (постановка задачі, створення програмного забезпечення, опис алгоритму рішення задачі, проектування та опис інтерфейсу користувача, опис програми)	30.04.08
5.	Оформлення пояснювальної записки	15.05.08
6.	Оформлення графічної документації	25.05.08
7.	Оформлення електронних додатків до диплому	27.05.08
8.	Представлення дипломної роботи до захисту	01.06.08

Студент-дипломник _________________

(підпис)

Керівник роботи _________________

(підпис)

АНОТАЦІЯ

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

Розділів 6, схем та малюнків 40, таблиць 7, бібліографічних посилань 28, загальний обсяг - 122.

Аннотация

Целью данной дипломной работы является разработка гибкой системы для автоматизации регистрации и учета движения иммунобиологических препаратов в пределах лечебно-профилактического учреждения. Система реализована в среде Delphi 6.0 с использованием технологии доступа к базам данных ADO.

Разделов 6, схем и рисунков 40, таблиц 7, библиографических ссылок 30, общий объем - 122.

The summary

The purpose of this diploma work is development of the flexible system for automation of registration and account of immunobiological preparations motion in the medical establishment. The system is realized in the environment of Delphi 6.0 with the use of access databases technology ADO.

Sections 6, circuits and figures 40, tables 7, bibliographic references 30, total amount - 122.

ЗМІСТ

ВСТУП

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

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

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

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

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

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

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

2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ ЯК СУКУПНОСТІ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ

2.1 Класифікація інформаційних систем

2.2 База даних як складова частина інформаційної системи

2.2.1 Моделі представлення даних

2.2.2 Реляційний спосіб доступу до даних

2.2.3 Таблиці

2.2.4 Ключові поля

2.2.5 Індекси

2.2.6 Зовнішні ключі

3. ОСНОВИ ТЕХНОЛОГІЇ ACTIVEX DATA OBJECTS (ADO)

3.1 Огляд технології ADO

3.2 Огляд технології OLE DB

3.2.1 OLE DB провайдери

3.2.2 ODBC провайдери

3.3 Архітектура технології ADO

3.3.1 Огляд компонентів ADO в середовищі Delphi

3.3.2 Інтерфейси архітектури ADO

3.3.3 Використання компонента TADOConnection

3.3.4 Використання параметрів запиту

3.3.5 Синхронізація даних клієнта і сервера

3.3.6 Робота з транзакціями

3.3.7 Атрибути доступу до даних

4. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ І ПРОГРАМНОЇ РЕАЛІЗАЦІЇ СИСТЕМИ

4.1 Предметна область і задачі, покладені на гнучку систему автоматизації

4.2 Апаратні вимоги, та вимоги до системного програмного забезпечення

4.3 Розробка логіко-функціональної схеми системи

4.4 Опис інтерфейсу користувача

5. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ

5.1 Визначення витрат на створення програмного продукту

5.2 Витрати, пов'язані з розробкою програми на ПК

5.3 Визначення планованої економії від упровадження програмного продукту

6. ОХОРОНА ПРАЦІ

6.1 Аналіз шкідливих і небезпечних факторів в Міська клінічна лікарня №2

6.2 Фізичні й психофізіологічні небезпечні та шкідливі виробничі фактори при роботі на комп'ютері й заходи по їх знищенню

6.2.1 Електромагнітне випромінювання

6.2.2 Рентгенівське випромінювання

6.2.3 Підвищений рівень шуму

6.2.4 Мікроклімат

6.2.5 Освітлення

6.2.6 Психофізіологічні шкідливі і небезпечні виробничі чинники

6.3 Організаційні і технічні заходи по зменшенню рівня шкідливих виробничих чинників

6.3.1 Захист від електромагнітних випромінювань

6.3.2 Захист від ураження електричним струмом

6.3.3 Захист від статичної електрики

6.3.4 Захист від шуму та вібрації

6.3.5 Оздоровлення повітряного середовища

6.3.6 Захист від рентгенівського випромінювання

6.3.7 Забезпечення раціонального освітлення

6.4 Пожежна безпека

6.4.1 Пожежна і вибухова безпека в робочій зоні технічного обслуговування в приміщеннях з ПЕОМ

ВИСНОВКИ

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

ДОДАТОК

ВСТУП

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

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

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

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

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

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

Традиційно Delphi відносять до так званих RAD-систем (Rapid Application Development, швидка розробка додатків). Проте ця система володіє також практично всіма можливостями сучасних СУБД, таких як, наприклад, Microsoft Access або Visual FoxPro. Вона дозволяє створювати додатки за допомогою широкого набору інструментальних програмних засобів, візуально готувати запити до баз даних, а також безпосередньо писати запити на мові SQL.

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

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

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

Найменування розробки: Гнучка система автоматизації обліку імунобіологічних препаратів. Система пройшла практичну апробацію і може бути впроваджена в КЗ «Міська клінічна лікарня №2».

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

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

Початок робіт: 31.10.07. Закінчення робіт: 01.06.08.

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

Гнучка система автоматизації була реалізована в середі Delphi 6.0. з використанням технології доступу до файлів баз даних ADO. Система може використовуватися як в локальному, так і в мереженому варіанті. Для функціонування системи потрібна інсталяція MS Office.

До складу системи входять:

· Ukr_vak.exe - виконавчий файл розробленої системи;

· baza.mdb - файл, що містить таблиці баз даних, і який може бути розташований на будь-якому комп'ютері, що підключений до локальної мережі; help.hlp - довідковий файл системи.

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

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

Система була реалізована з використанням технології доступу до баз даних АDО. Розробка пройшла практичну апробацію і може бути використана на прикладі КЗ «Міська клінічна лікарня №2».

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

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

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

· Відсутність додаткових вимог до розміщення здійснених файлів;

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

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

· ПК типу IBM PC або сумісний з ним, продуктивністю не менше 166 МГц;

· Оперативна пам'ять не менше 32 МГбайт;

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

· НЖМД не менше 4,3 Гбайт;

· НГМД 3,5 дюйми;

· Компакт-дисковий носій (CD);

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

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

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

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

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

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

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

2. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ ЯК СУКУПНОСТІ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ

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

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

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

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

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

2.1 Класифікація інформаційних систем

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

· за призначенням (фактографічні, документальні та змішані);

· за мовами (замкнуті системи, системи з базовою мовою та змішані);

· за локалізацією (локальні та розподілені);

· за схемою додаткової обробки (постобробка та попередня обробка);

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

Критерії за якими діляться АІС:

1) за призначенням.

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

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

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

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

Дескрипторні або документальні АІС (ДАІС) історично були першими. Спочатку їх мовою була нічим не обмежена природна мова. Перші ДАІС були призначені для пошуку книг та документів у бібліотеках і великих сховищах, тому їх і почали називати документографічними.

Основним елементом інформаційного простору ДАІС була анотація або реферат книги, документа, явища чи об'єкта. Реферат повинен відображувати ті риси, які цікавлять користувача (як правило - людини). В ньому виділяються слова чи словосполучення, які в сукупності майже однозначно (в ідеалі точно) відповідають повному опису об'єкта, крім того, таких слів повинно бути відносно небагато. Їх називають ключовими словами або дескрипторами. Запит для ДАІС можна сформулювати у вигляді переліку дескрипторів, який на думку користувача характеризує потрібний реферат, а значить, і відповідний об'єкт. Алгоритм формування відповіді послідовно порівнює запит з кожним рефератом і вибирає такі, що пройшли порівняння. В таких системах запит називають пошуковим розпорядженням, а реферат - пошуковим образом.

2) За мовами (замкнуті системи, системи з базовою мовою та змішані);

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

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

Змішані системи передбачають наявність обох можливостей двох попередніх підходів і є найбільш поширеними на сьогодні.

3) за локалізацією (локальні та розподілені);

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

4) за схемою додаткової обробки (постобробка та попередня обробка);

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

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

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

2.2 База даних як складова частина інформаційної системи

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

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

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

- для пошуку та модифікації даних використовуються спільні механізми;

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

Прокоментуємо додатково підкреслені слова та вирази у вищенаведеному описі, порівнюючи в основному з близьким попередником БД - файловими системами (ФС).

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

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

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

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

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

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

За критерієм виразової потужності інструментальні засоби специфікації умов цілісності можна підрозділити на такі групи:

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

· порівняння поля запису з полем або кількома полями інших записів;

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

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

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

· оперативно одержувати інформацію про місце знаходження комп'ютера;

· вести облік пристроїв які підключені або входять до складу комп'ютера;

· організувати процеси перемішання комп'ютерів їх частин або пристроїв;

· вести облік програм які установлені на цьому комп'ютері;

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

2.2.1 Моделі представлення даних

У залежності від виду організації даних розрізняють наступні основні моделі представлення даних у БД:

· ієрархічну;

· мережну;

· реляційну;

· об'єктно-орієнтовану.

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

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

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

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

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

2.2.2 Реляційний спосіб доступу до даних

Реляційний спосіб доступу до даних ґрунтується на операціях із групами записів. Для завдання операцій використовуються засоби мови структурованих запитів - SQL (Structured Query Language), тому реляційний спосіб доступу називають також SQL-орієнтованим. Для його реалізації в програмних продуктах Delphi як набір даних повинні застосовуватися такі компоненти, як Query чи storedProc, що дозволяють виконати SQL-запит.

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

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

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

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

· здійснювати пошук даних по частковому збігу зі значеннями полів.

Основи мови SQL

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

Мова SQL звичайно інтегрується в інші засоби (оболонку), використовуючись в інтерактивному режимі. Так, у системі керування базами даних, що має інтерактивний інтерфейс, користувач може працювати, нічого не знаючи про мову SQL, незалежно від того, яка БД використовується: віддалена чи локальна. Такі СУБД, як Microsoft Access, Visual FoxPro чи Paradox, самі виконують дії, зв'язані з програмуванням запитів на SQL, пропонуючи користувачу засоби візуальної побудови запитів, наприклад, Query By Example (QBE) - запит за зразком.

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

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

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

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

Мова SQL має кілька стандартів, з яких найбільш розповсюдженими серед виробників програмних продуктів є стандарти SQL-89 і SQL-92. Стандарт SQL92, підтриманий Американським національним інститутом стандартів (ANSI - American National Standards Institute) і Міжнародною організацією по стандартизації (ISO - International Standard Organization), також називають стандартом ANSI чи ANSI/ISO. Наявність декількох стандартів і різна їхня інтерпретація породили безліч діалектів мови SQL, що у більшому чи меншому ступені відрізняються друг від друга.

У мові SQL можна виділити наступні основні підмножини операторів:

· визначення даних;

· обробки даних;

· керування привілеями (доступом до даних); керування транзакціями.

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

У додатках Delphi для виконання операторів SQL можна використовувати набір даних Query. Нагадаємо, що текст SQL-запиту є значенням властивості sql компонента Query і формується при розробці додатка, чи під час його виконання. Компонент Query забезпечує виконання SQL-запиту й одержання відповідного набору даних. Формування набору даних виконується при активізації компонента Query шляхом виклику методу Оpen чи установкою властивості Active значення True. Іноді при відпрацьовуванні SQL-запиту немає необхідності одержувати набір даних, наприклад, при видаленні, чи вставці модифікації записів. У цьому випадку більш переважно виконувати запит викликом методу ExecSQL. При роботі в мережі виклик цього методу робить необхідну модифікацію набору даних, не передаючи в визиваючу програму (комп'ютер) запис набору даних, що істотно знижує навантаження на мережу.

Крім того, набрати і виконати в інтерактивному режимі текст SQL-запиту дозволяють інструментальні програми, що поставляються разом з Delphi 5, наприклад такі, як Database Desktop, SQL Explorer і SQL Builder. Відзначимо, що перші дві програми викликаються за допомогою однойменних команд меню Tools і Database, відповідно, а візуальний будівник запитів SQL Builder викликається через контекстне меню компонента Query.

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

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

Зарезервовані слова мови SQL пишемо рядковими, а імена - прописними буквами. Регістр букв не впливає на інтерпретацію операторів мови. Крапка з комою наприкінці SQL-операторів необов'язкова. Елементи в списках, наприклад, імена полів і таблиць, повинні бути розділені комами.

Імена таблиць і полів (стовпців) полягають в одиночні чи подвійні апострофи, наприклад, "First Name". Якщо ім'я не містить пробілів і інших спеціальних символів, то апострофи можна не вказувати.

У SQL-запиті допускаються коментарі, що пояснюють текст програми. Коментар обмежується символами /* і */.

Функції мови SQL

Мова SQL, як і інші мови, надає для використання ряд функцій, з яких найбільш уживані наступні:

Агрегатні чи статистичні функції:

AVG () - середнє значення;

МАХ () - максимальне значення;

MIN () - мінімальне значення;

SUM () - сума;

COUNT () - кількість значень;

COUNT(*) - кількість ненульових значень.

Функції роботи з рядками:

UPPER(Str) - перетворення символів рядка Str до верхнього регістра;

LOWER(Str) - перетворення символів рядка Str до нижнього регістра;

TRIM(Str) - видалення пробілів на початку і наприкінці рядка Str;

SUBSTRING (Str FROM n1 to n2) - виділення з рядка str підрядка, що містить у собі символи, починаючи з номера (позиції) n1 і закінчуючи номером n2;

CAST (<Expression> AS <Type>) - приведення виразу Expression до типу Type;

|| - конкатенація (зчеплення) двох рядків.

Функції декодування дати і часу:

EXTRACT (<Елемент> FROM <вираз>) - з вираження, що містить значення чи дати часу, витягається значення, що відповідає зазначеному елементу. Як елемент дати чи часу можна вказувати значення: YEAR, MONTH, DAY, HOUR, MINUTE чи SECOND.

Відбір даних з таблиць

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

Оператор SELECT - найважливіший оператор мови SQL. Він використовується для добору записів, що задовольняють складним критеріям пошуку, і має наступний формат:

SELECT [DISTINCT] {* I <Список полів>)

FROM <Список таблиць>

[WHERE <Умови добору >]

[ORDER BY <Список полів для сортування >]

[GROUP BY <Список полів для групування >]

[HAVING <Умови групування>]

[UNION <Вкладений оператор SELECT>]

Результат виконання SQL-запиту, заданого оператором SELECT, являє собою вибірку записів, що відповідають заданим у ньому умовам. При розгляді оператора SELECT будемо припускати, що SQL-запит набраний і виконаний за допомогою компонента Query. У цьому випадку результатом виконання запиту є відповідний цьому компонент набору даних.

У такому результуючому наборі даних можуть бути дозволені чи заборонені повторювані записи (тобто однакові значення, що мають, усіх полів). Цим режимом керує DISTINCT. Якщо він відсутній, то в наборі даних дозволяються повторювання записів.

В оператор SELECT обов'язково включається список полів і операнд FROM. інші операнди можуть бути відсутніми. У списку операнда FROM перелічуються імена таблиць, для яких відбираються записи. Список повинний містити як мінімум одну таблицю.

Список полів визначає склад полів результуючого набору даних, ці поля можуть належати різним таблицям. У списку повинне бути задане хоча б одне поле. Якщо в набір даних потрібно уключити всі поля таблиці (таблиць), то замість перерахування імен полів можна вказати символ "*". Якщо список містить поля декількох таблиць, то для вказівки приналежності полів до тієї чи іншої таблиці використовують складене ім'я, що включає в себе ім'я таблиці й ім'я полючи, розділені крапкою: <Ім'я таблиці>.<Ім'я поля>

Операнд WHERE задає умови (критерії) добору, яким повинні задовольняти запису в результуючому наборі даних. Вираження, що описує умови добору, є логічним. Його елементами можуть бути імена полів, операції порівняння, арифметичні і логічні операції, дужки, спеціальні функції LIKE, NULL, IN і інші.

Операнд GROUP BY дозволяє виділяти групи записів у результуючому наборі даних. Групою є записи з однаковими значеннями в полях, перерахованих за операндом GROUP BY. Виділення груп потрібно для виконання групових операцій над записами, наприклад, для визначення кількості якого-небудь товару на складі.

Операнд HAVING діє разом з операндом GROUP BY і використовується для добору записів усередині груп. Правила запису умов групування аналогічні правилам формування умов вибору в WHERE. Операнд ORDER BY містить список полів, що визначають порядок сортування записів результуючого набору даних. За замовчуванням сортування по кожному полю виконується в порядку зростання значень; якщо необхідно задати для полів сортування по зменшенню, то після імені цього поля вказується описувач DESC.

Оператори SELECT можуть мати складну структуру і бути вкладеними друг у друга. Для об'єднання операторів використовується операнд UNION, у якому розташовується вкладений оператор SELECT, названий також підзапитом. Результуючий набір даних представляють записи, відібрані в результаті виконання умов добору, заданих операндами WHERE обох операторів.

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

Статичний і динамічний запити

Як уже відзначалося, у залежності від способу формування SQL-запит може бути:

· статичним;

· динамічним.

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

Динамічний SQL-запит формується чи змінюється при виконанні додатка.

2.2.3 Таблиці

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

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

Структура таблиці включає наступну інформацію:

Ім'я таблиці - Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах SQL.

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

Кожен вертикальний стовпець таблиці STUDENTS представляє один елемент даних для кожного зі студентів. Наприклад, у стовпці GROUP містяться номери груп, у яких розташовані студенти. У стовпці DATE містяться дати народження кожного студента.

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

На перетинанні кожного рядка з кожним стовпцем таблиці міститься одне значення даних. Наприклад, у другому рядку в стовпці FAMILY міститься значення "ІВАНОВ". У стовпці PODGRP того ж рядка міститься значення 1, що є номером підгрупи, у якій знаходиться даний студент.

Усі значення, що містяться в тому самому стовпці, є даними одного типу. Наприклад, у стовпці FAMILY містяться тільки слова, у стовпці DATE містяться дати, а в стовпці NUMBER містяться цілі числа, що представляють ідентифікатори студентів. Безліч значень, що можуть міститися в стовпці, називається доменом цього стовпця. Доменом стовпця FAMILY є безліч прізвищ студентів. Доменом стовпця DATE є будь-як дата.

У кожного стовпця в таблиці є своє ім'я, що звичайно служить заголовком стовпця. Усі стовпці в одній таблиці повинні мати унікальні імена, однак дозволяється привласнювати однакові імена стовпцям, розташованим у різних таблицях. На практиці такі імена стовпців, як NUMBER, FAMILY, NAME, GROUP, DATE, PODGRP, часто зустрічаються в різних таблицях однієї бази даних.

Стовпці таблиці упорядковані ліворуч праворуч, і їхній порядок визначається при створенні таблиці. У будь-якій таблиці завжди є як мінімум один стовпець. У стандарті ANSI/ISO не вказується максимально припустиме число стовпців у таблиці, однак майже у всіх комерційних СУБД ця межа існує і звичайно складає приблизно 255 стовпців.

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

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

2.2.4 Ключові поля

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

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

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

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

На перший погляд, первинним ключем таблиці STUDENTS можуть служити і стовпець FAMILY. Однак у житті досить часто зустрічаються однофамільці, отже, стовпець FAMILY більш не може виконувати роль ключа. На практиці як первинні ключі таблиць звичайно варто вибирати ідентифікатори, такі як ідентифікатор студента NUMBER у таблиці STUDENTS.

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

Він застосовується у випадках, коли неможливо гарантувати унікальність значень кожного окремого поля. Стовпець NSTUD містить ідентифікатори студентів, перерахованих у таблиці, а стовпець NORDER містить номера, наказам. Може показатися, що стовпець NORDER міг би й один виконувати роль первинного ключа, однак ніщо не заважає одному студенту кілька разів потрапити під відрахування і потім відновитися на факультеті. Таким чином, як первинний ключ таблиці ORDERS необхідно використовувати комбінацію стовпців NSTUD і NORDER. Для кожного зі студентів, що містяться в таблиці, комбінація значень у цих стовпцях буде унікальною.

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

Хоча первинні ключі є важливою частиною реляційної моделі даних, у перших реляційних СУБД (System/R, DB2, Oracle і інших) не була забезпечена явно їхня підтримка. Як правило, проектувальники бази даних самі стежили за тим, щоб у всіх таблиць були первинні ключі, однак у самих СУБД не було можливості визначити для таблиці первинний ключ. І тільки в СУБД DB2 Version 2, що з'явилася в квітні 1988 року, компанія IBM реалізувала підтримку первинних ключів. Після цього подібна підтримка була додана в стандарт ANSI/ISO.

2.2.5 Індекси

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

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

Створити індекси, як і ключі, можна по одному чи декільком полям. Складені індекси дозволяють при доборі даних групувати записи, у яких перші поля можуть мати однакові значення. Індексувати поля потрібно для виконання частих пошуків, сортувань чи об'єднань з полями з інших таблиць у запитах. Ключові поля таблиці індексуються автоматично. Не можна індексувати поля з типом даних поле МЕМО, чи об'єкту OLE. Для інших полів індексування використовується, якщо поле має текстовий, числовий, грошовий тип чи тип дати/часу і потрібно здійснювати пошук і сортування значень у полі. Якщо передбачається, що буде часто виконуватися сортування чи пошук одночасно по двох і більш полях, можна створити складений індекс. Наприклад, якщо для того самого запиту часто встановлюється критерій для полів Ім'я і Прізвище, то для цих двох полів має сенс створити складений індекс. При сортуванні таблиці по складеному індексі спочатку здійснюється сортування по першому полю, визначеному для даного індексу. Якщо в першому полі містяться записи з повторюваними значеннями, то сортування здійснюється по другому полю і т.д.

2.2.6 Зовнішні ключі

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

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

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