Гнучка пошукова система обліку науково-дослідницької документації

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

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

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

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

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

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

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

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

«Гнучка пошукова система обліку науково-дослідницької документації»

Студента групи ГКС-06-з Короткого Юрія Ігоровича підпис_________

Керівник роботи ст. викл. Кислова Марія Алімовна підпис_________

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

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

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

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

Кривий Ріг, 2011

Анотація

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

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

Аннотация

Целью дипломной работы является создание системы, предназначенной для автоматизации учета научно-исследовательской документации в условиях Криворожского металлургического факультета НМетАУ. Разработанная система создана согласно заказу и внедрена в информационно-вычислительном центре этой организации.

В исследовательской части дипломной работы были рассмотрены особенности использования баз данных при проектировании информационных систем.

The summary

The purpose of the diploma work is development of the system intended for automation of the research documents account in the conditions of Kriviy Rih metallurgical faculty of NMetAU. The developed system is created in obedience to the order and inculcated in the information-computer center of this organization.

In research part of diploma work there were the considered features of databases using at planning of the information systems.

ЗМІСТ

• ВСТУП
• 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 Зовнішні ключі
• 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. ТЕОРЕТИЧНЕ ДОСЛІДЖЕННЯ ОБ'ЄКТНИХ МОДЕЛЕЙ ТА МЕТОДІВ СТВОРЕННЯ КОНТРОЛЕРІВ АВТОМАТИЗАЦІЇ MS OFFICE
• 4.1 Об'єктна модель MS Word
• 4.2 Загальні принципи створення контролерів автоматизації MS Office
• 4.3. Принципи створення контролерів автоматизації MS Word
• 4.3.1 Робота з об'єктом Word.Application
• 4.3.2 Створення таблиць і робота з ними
• 4.3.3 Настройка параметрів сторінки і друк документа
• 4.3.4 Елементи управління додатку MS Word
• 5. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
• 5.1 Функціональне призначення та технологічні особливості розробки
• 5.2 Розробка логіко-функціональної схеми роботи користувача з системою
• 5.3 Опис інтерфейсу користувача
• 5.4 Програмна реалізація системи
• 6 ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ
• 7. ОХОРОНА ПРАЦІ
• 7.1 Аналіз небезпечних й шкідливих виробничих факторів в видавничому центрі
• 7.2 Заходи щодо нормалізації небезпечних і шкідливих факторів
• 7.3 Пожежна безпека
• ВИСНОВКИ

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

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

Початок робіт: 01.11.10. Закінчення робіт: 25.05.11.

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

Гнучка пошукова система обліку науково-дослідницької документації була створена за допомогою інструментального засобу прискореної розробки програмного забезпечення Delphi та технології доступу до бази даних ADO з використанням бази даних в форматі Microsoft Access. В розробці були використані пакети альтернативних компонентів Development Express, Synactis та RXLib, за допомогою яких був реалізований інтерфейс системи. Використання пакету RXLib зумовлено вимогою замовника - можливістю застосування в системі редактору формул Microsoft Equation. Пакет компонентів Synactis призначений для відображення змісту файлів формату pdf.

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

· ADOServer.exe - серверна частина системи;

· NAUKA_client.exe - клієнтська частина;

· baza.mdb - файл бази даних формату Microsoft Access;

· path.ini - зберігає інформацію про повний шлях до файлу бази даних;

· p2iagent.exe - консольний конвертор фалів формату pdf в формат bmp;

· Шаблон_карт.dot - шаблон документу MS Word для створення картки обліку патентів, що містить графічне зображення та короткий опис винаходу (формулу);

· Шаблон_таблиця.dot - шаблон документу, що призначений для експорту в MS Word переліку патентів на основі вибірки;

· Шаблон_статті.dot - шаблон документу, що призначений для експорту в MS Word переліку наукових публікацій.

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

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

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

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

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

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

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

· Додаткове програмне забезпечення: установка пакету MS Office, Acrobat Reader (на клієнтських ЕОМ), IBProvider - ODBC- провайдера доступу до бази даних (на сервері);

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

· IBM-Сумісний комп'ютер, не нижче Pentium III, RAM-512Mb, SVGA-800*600*16bit, вільний простір на жорсткому диску на сервері не менш 300 Мб, на клієнтській машині - біля 5 Мб.

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

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

· технічне завдання на реалізацію проекту;

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

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

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

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

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

2.1 Концепція баз даних - закономірний результат розвитку автоматизованих інформаційних систем

Широке використання ЕОМ призвело до автоматизації обробки і використання величезної кількості інформації у різних галузях діяльності людини. Ще в початковий період розвитку автоматизованих інформаційних систем (АІС) на основі ЕОМ першого і другого поколінь (кінець 50-х - початок 60-х років) різні організації почали накопичувати і зберігати дані про цікаві для них предметні області. Дані або були «зашиті» безпосередньо в програми, або програми мали змогу вибирати ці дані тільки з жорстко фіксованих (визначених усередині програми) пристроїв (носіїв інформації).

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

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

Користувачі АІС поступово усвідомлювали необхідність централізації управління даними і програмн ими додатками. Розуміння цієї необхідності приходило різними шляхами.

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

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

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

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

Усвідомлення значимості, даних, необхідності централізованого управління ними і прагнення розв'язати наведені вище проблеми розвитку АІС призвели до виникнення нової концепції спільного використання даних -- концепції баз даних.

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

Насамперед проголосимо основні ідеї, що лежать в основі концепції бази даних:

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

2. Усунути надмірне дублювання даних.

3. Централізувати управління даними.

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

Тобто всі дані розміщуються в єдиному сховищі. Користувачі АІС мають можливість звертатися до будь-яких даних, що їх цікавлять.

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

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

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

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

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

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

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

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

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

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

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

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

Основними вимогами до баз даних та систем управління ними є:

1. Можливість представлення адекватних реальній предметній області структур даних (побудова адекватної інформаційної моделі предметної області).

2. Простота та малі витрати ресурсів на розвиток системи (швидка і дешева модифікація старих та розробка нових програмних додатків у рамках автоматизованої інформаційної системи).

3. Простота та оперативність доступу до даних, можливість пошуку інформації різними методами.

4. Можливість одночасного ефективного обслуговування великої кількості користувачів.

5. Можливість використання у розподілених обчислювальних мережах ЕОМ.

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

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

8. Забезпечення необхідної продуктивності розв'язування задач при обмежених витратах ресурсів ЕОМ.

9. Забезпечення захисту інформації у БД від збоїв і відмов у роботі технічних засобів та помилок користувачів.

Основними перевагами застосування БД та СУБД під час реалізації на їхній основі АІС є:

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

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

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

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

5. Спрощується підтримка цілісності (адекватності та узгодженості) даних.

6. Забезпечується можливість швидкого на дання даних на нестандартні (заздалегідь непередбачені) запити користувачів без додаткової розробки прикладних програм.

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

8. У разі централізованого управління базою даних спрощується стандартизація та уніфікація представлення даних у АІС.

Основними недоліками, з якими можуть зустрітися користувачі та розробники програмного забезпечення під час застосування БД та СУБД, є:

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

2. Додаткові витрати на встановлення і підтримку СУБД у робочому стані.

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

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

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

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

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

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

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

· мережну;

· реляційну;

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

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

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

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

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

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

2.2.1 Таблиці

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

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

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

Ім'я таблиці - Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах 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.2 Ключові поля

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

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

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

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

На перший погляд, первинним ключем таблиці 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.3 Індекси

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

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

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

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

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

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

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

Зовнішні ключі є невід'ємною частиною реляційної моделі, оскільки реалізують відносини між таблицями бази даних. До нещастя, підтримка зовнішніх ключів була відсутня в перших реляційних СУБД. Вона була введена в системі DB2 Version 2 і тепер мається у всіх комерційних СУБД.

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

Доступ до даних є найважливішою вимогою при розробці сучасних бізнес-додатків. Технологія ODBC забезпечує доступ до реляційних баз даних і це перший крок на шляху вирішення цієї проблеми. Однак, коли розроблювачі хочуть включити у свої проекти не реляційні джерела даних або працювати в середовищах, подібних Інтернет, вони стикаються з дилемою - або розробляти власні парадигми доступу до даних, або працювати на рівні API, що несумісне з новими середовищами. ActiveX об'єкти доступу до даних (ActiveX Data Object) вирішують цю дилему і забезпечують єдину модель, що працює з усіма джерелами даних у різних середовищах. У такий спосіб ADO забезпечує послідовний, високопродуктивний доступ до даних, із якими можливо створювати клієнтські програми для роботи з БД або бізнес-об'єкти середнього рівня, що використовують додатки, інструментарій, мова або, навіть, Інтернет-переглядач (Internet Explorer). ADO - це єдиний інтерфейс доступу до даних, що необхідний для створення одне- і багаторівневих додатків архітектури клієнт/сервер і Web-орієнтованих інформаційних систем.

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

Технологія ADO була вперше застосована в Microsoft Internet Information Server як інтерфейс доступу до БД. Використання ADO дозволяє мінімізувати мережний трафік у ключових Internet-сценаріях і зменшити кількість проміжних рівнів між клієнтським додатком і джерелом даних. ADO легко використовувати, тому що він (або вони (об'єкти) або вона (технологія)) застосовує звичну систему викликів - інтерфейс Автоматизації OLE, доступний сьогодні в більшості засобів розробки додатків. Через легкість застосування й вивчення популярність ADO буде рости й у підсумку ADO витисне технології RDO і DAO, що у даний час застосовуються дуже широко. Технологія ADO багато в чому подібна до RDO і DAO, наприклад, вона використовує ті ж угоди мови. ADO також підтримує аналогічну семантику і тому може бути легко освоєна розроблювачами ПЗ.

ADO є інтерфейсом програмного рівня до OLE DB, новітній і наймогутнішої парадигмі доступу до даних від MS. OLE DB забезпечує високопродуктивний доступ до багатьох джерел даних. ADO і OLE DB разом являють собою основу стратегію універсального доступу до даних (Universal Data Access). OLE DB дає можливість універсального доступу до багатьох даних і представляє розроблювачам можливість зробити це досить легко. Тому що ADO знаходиться на вершині OLE DB, те застосування ADO має всі привілеї універсального доступу до даних, що забезпечує OLE DB.

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

OLE DB - це відкрита специфікація, розроблена на основі успіху специфікації ODBC і забезпечує відкритий стандарт доступу до усіх видів даним у системах масштабу підприємства. OLE DB - це ядро технології підтримуючий універсальний доступ до даних. На відміну від технології ODBC, що була створена для доступу до реляційних БД, технологія OLE DB розроблена для реляційних і не реляційних джерел даних, таких як сховища пошти (mail stores), текстів і графіки для Web, служби каталогів (directory services), IMS і VSAM сховищ даних на мейнфреймах.

Компоненти OLE DB складаються з провайдерів даних (data providers), що представляють свої дані, споживачів даних (data consumers), що використовують дані, і сервісних компонентів (service components), що обробляють і транспортують дані (наприклад, процесор запитів і механізм курсорів). OLE DB містить у собі міст із ODBC, щоб дати можливість розроблювачам використовувати ODBC-драйвера реляційних БД, широко розповсюджені в даний час.

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

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

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

Microsoft OLE DB SDK version 1.1 поставляє два OLE DB провайдери: ODBC провайдер і провайдер текстів. Провайдер текстів є прикладом, що демонструє докладну реалізацію OLE DB провайдеру. ODBC провайдер - це OLE DB провайдер для ODBC драйверів. Цей провайдер надає механізм для споживачів, щоб використовувати існуючі ODBC драйвери без необхідності термінової заміни існуючих ODBC драйверів на нові OLE DB провайдери.

пошукова система delphi аccess

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

ODBC провайдер встановлює відповідність між OLE DB інтерфейсами і ODBC API. З ODBC провайдером OLE DB споживачі можуть зв'язуватися із сервером БД через існуючі ODBC драйвери. Споживач викликає OLE DB інтерфейс через ODBC провайдеру. ODBC провайдер викликає відповідні ODBC API інтерфейси і посилає запити до ODBC драйвера. Метою розробки ODBC провайдеру є здійснення усієї функціональності менеджера ODBC драйвера. Тому тепер немає необхідності в менеджері ODBC драйвера. Однак при використанні ODBC провайдером версії 1.1 менеджер ODBC драйвера усе ще потрібно для підтримки зв'язку з ODBC додатками.

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

ADO засновано на технології COM (Component Object Model) - компонентній об'єктній моделі. Всі об'єкти й інтерфейси ADO є інтерфейсами й об'єктами COM.

Рис. 3.1 Архітектура ADO

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

Для роботи з ADO на вкладці компонентів ADO є шість компонентів: TADOConnection, TADOCommand, TADODataSet, TADOTable, TADOQuery, TADOStoredProc.

Рис. 3.2 Палітра компонентів ADO

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

TADOTable - таблиця доступна через ADO.

TADOQuery - запит до бази даних. Це може бути як запит, у результаті якого повертаються дані і бази (наприклад, SELECT), так і запит не повертає даних (наприклад, INSERT).

TADOStoredProc - виклик збереженої процедури. На відміну від BDE і InterBase збережені процедури в ADO можуть повертати набір даних, по цьому компонент даного типу є нащадком від TDataSet і може виступати джерелом даних у компонентах типу TDataSource.

TADOCommand і TADODataSet є найбільше загальними компонентами для роботи з ADO, але і найбільш складними в роботі. Обидва компоненти дозволяють виконувати команди мовою провайдера даних (так у ADO називається драйвер бази даних).

Різниця між ними в тім, що команда, що виконується через TADODataSet, повинна повертати набір даних і цей компонент дозволяє працювати з ними засобами Delphi (наприклад, прив'язати компонент типу TDataSource). А компонент TADOCommand дозволяє виконувати команди не повертають набір даних, але не має штатних засобів Delphi для наступного використання повернутого набору даних.

Очевидно, що усі компоненти повинні зв'язуватися з базою даних. Робиться це двома способами або через компонент TADOConnection або прямим указівкою бази даних в інших компонентах. До TADOConnection інші компоненти прив'язуються за допомогою властивості Connection, до бази даних прямо через властивість ConnectionString.

База даних може бути зазначена двома способами через файл лінка до даних (файл у форматі Microsoft Data Link, розширення UDL), або прямим завданням параметрів з'єднання.

Значення властивості всіх ConnectionString цих компонентів можуть бути введені прямо в текстовій формі, але куди простіше викликати редактор властивості натиснувши на кнопку «…» наприкінці отримавши введення. Вікно завдання цієї властивості виглядає так:

Рис. 3.3 Вікно завдання властивостей ConnectionString

При виборі «Use data link file» і натисканні на кнопку «Browse...» з'являється стандартний діалог вибору файлу. Цей файл можна створити в будь-якому вікні explorer-а (у цьому вікні відкриття файлу, у самому explorer, на desktop і т.д.) викликавши контекстне меню і вибравши пункт «New/Microsoft Data Link». Потім викличте локальне меню для створеного файлу і виберіть у ньому пункт «Open». Після цього з'явиться property sheet описаний трохи нижче. Ці ж вкладки містить і property sheet, викликуваний через пункт «Property» локального меню UDL файлу, але в ньому ще є вкладки стосовні до самого файлу.

Використання файлів Microsoft Data Link спрощує підтримку додатків, тому що можливо використовувати засобу Windows для настроювання додатка.

При виборі в редакторі властивості «Use connection string» і натисканні на кнопку «Build...» з'являється такою же property sheet, як і при виборі «Open» для Microsoft Data Link файлу.

У цьому вікні вибирається тип бази даних, місце розташування бази і параметри з'єднання.

На першій сторінці вибирається тип бази даних або Provider, у термінах ADO.

Рис. 3.4 Вибір типу бази даних (провайдера)

Бази MS Access доступні як через «Microsoft Jet OLE DB Provider», так і через «Microsoft OLE DB Provider for ODBC».

Наступна сторінка залежить від обраного типу бази, однак для всіх типів є кнопка «Test connection» що дозволяє перевірити правильність і повноту параметрів.

Для «Microsoft Jet OLE DB Provider» вона виглядає наступним чином (рис.3.5).

Checkbox «Blank password» придушує діалог введення ідентифікатора і пароля користувача при встановленні з'єднання, якщо поле пароля порожнє.

Checkbox «Allow saving password» зберігає пароль у рядку параметрів з'єднання. Якщо він не відзначений, то введений пароль буде використовуватися тільки при виконанні тестового з'єднання.

Рис. 3.5 Вибір джерела бази даних

Для «Microsoft OLE DB Provider for ODBC» ця сторінка виглядає так:

Рис. 3.6 Вибір джерела бази даних

Радіокнопка «Use data source name» дозволяє ввести аліас ODBC, а через «Use connection string» уводиться як аліаси так і тип ODBC драйвера і параметри з'єднання. Параметри ідентифікації користувача аналогічні вище описаним.

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

Рис. 3.7 Встановлення додаткових параметрів

На сторінці «All» можна відредагувати всі параметри з попередніх сторінок і параметри залежні від провайдера, але не ввійшли на сторінку «Connection». Редагування здійснюється у виді параметр - значення, причому в текстовій формі, ніяких діалогів немає. Допомоги те ж ні, ці параметри описані тільки в документації на провайдер. Її можна знайти в MSDN Data Access Services/Microsoft Data Access Components (MDAC) SDK/Microsoft Active Data Objects (ADO)/Microsoft ADO Programmer's Reference/Using Providers with ADO.

Рис. 3.8 Сторінка з усіма доступними параметрами відкриття

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

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

Інтерфейс Connection

Об'єкти цього типу виконують наступні функції:

· зв'язок із сервером;

· керування трансакціями;

· одержання інформації про помилки, що відбулися, (властивість Errors);

· одержання інформації про схему даних (таблиці, поля і т.д.).

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

Інтерфейси Recordset і Field

Інтерфейс Recordset (на нижньому рівні ADO це IRowset) є аналогом TDataSet у Delphi.

Підтримує поточне положення і переміщення курсору, закладки (bookmarks), читання, зміна і видалення записів і так далі. Значення полів і їхніх типів доступні за допомогою властивості Fields.

Інтерфейс Field дозволяє одержувати значення полючи, його тип довжину і так далі.

Інтерфейси Command і Parameter

Ці два типи дозволяють працювати з командами джерела даних. Синтаксис команд для кожного з джерел свій.

Інтерфейс Property

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

Бібліотека досить заплутана, багато функцій дубльовані в різних об'єктах. Наприклад, Recordset можна створювати прямо, методом Open, (причому попередньо створювати Connection не обов'язково), можна одержати як результат виконання методу Command.Execute, або після Connection.Execute задавши команду без параметрів.

Особливості інтерфейсу Command та RecordSet

Інтерфейс Command інкапсульований в усі компоненти за винятком TADOConnection. Це зроблено тому, що в ADO немає можливості одержати дані не виконавши команду.

Інтерфейс Recordset інкапсульований у компоненти похідні від TCustomADODataSet. Це компоненти TADODataSet, TADOTable, TADOQuery, TADOStoredProc. Одержувати дані з них можливо штатними засобами Delphi.

Можливе одержання даних і при виконанні компонента TADOCommand. Метод цього компонента Execute повертає тип _Recordset. Після чого його можна, наприклад, зв'язати з компонентом TADODataSet у такий спосіб

ADODataSet1.RecordSet := ADOCommand1.Execute;

Компоненти TADOTable, TADOQuery і TADOStoredProc є окремими випадками команди, відповідно для таблиці, SQL запиту і збереженої процедури.

Тип Connection інкапсулюється в компонент TADOConnection.

Коли ви виконуєте команду попередньо не відкриваючи з'єднання, воно все рівно створюється. Одержати до нього доступ можливо через властивість Recordset. Прив'язати компонент TADOConnection до уже відкритого з'єднання можливо через властивість ConnectionObject.

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

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

У цьому прикладі розглядається робота з компонентом TADOConnection, SQL запитами з параметрами і трансакціями.

Створимо додаток з наступних компонентів (рис. 3.10):

· Connect типу TADOConnection

· MasterSQL і DetailSQL типу TADODataSet

· MasterDS і DetailDS типу TDataSource

· MasterGrid і DetailGrid типу TDBGrid

Зв'язуємо MasterGrid, MasterDS, MasterSQL і DetailGrid, DetailDS, DetailSQL аналогічно попередньому прикладові, за винятком того, що замість типу TADOTable використовується тип TADODataSet.

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

Для введення SQL запитів необхідно відредагувати властивість CommandText компонентах MasterSQL і DetailSQL. Після натискання на кнопку "SQLString" з'явиться редактор компонентів, що виглядає в такий спосіб (рис.3.11).



Рис. 3.10 Master-detail форма на етапі проектування

Рис. 3.11 Редактор SQL-запиту

Кнопка «Add Table to SQL» додає в текст SQL запиту таблицю, обрану в списку «Tables», а «Add Field to SQL» поле таблиці, обране в списку «Fields».

Запит для MasterSQL:

select VendorNo, VendorName, Country, City, State, Preferred from vendors

Запит у DetailSQL повинний вибирати тільки ті деталі, постачальник яких є поточним у MasterSQL. Для цього установимо властивість DataSource компонента DetailSQL у значення MasterDS.