Розробка гнучкої системи автоматизації обліку методичних матеріалів видавничого центру КМФ НМетАУ (ADO+Delphi)

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

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

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

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

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

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

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

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

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

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

видавничого центру КМФ НМетАУ»

Студента групи

ГКС-05-д Бурлінової Анни Василівни

Керівник роботи доц.,

к.т.н. Старіков Олексій Миколайович

Кривий Ріг 2010

Анотація

автоматизація пошук даний інтерфей

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

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

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

Аннотация

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

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

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

The summary

The purpose of the diploma work is development of the system intended for search and storage automation of methodical materials in the conditions of publishing center Kriviy Rih metallurgical faculty of NMetAU. The developed system is realized with the use of programming the system Delphi 2006 Explorer and technologies of databases access ADO.

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

Sections 6, circuits and figures 30, tables 6, bibliographic references 30, total amount - 100.

ЗМІСТ

ВСТУП

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

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

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

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

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

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

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

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

2.1 Призначення і область використання баз даних

2.2. Технології доступу до баз даних

2.2.1 Технологія BDE

2.2.2 Технологія ADO

2.3 Схема обміну даними при роботі з БД

2.4 Архітектури баз даних

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

2.6 Реляційна модель даних

2.6.1 Таблиці

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

2.6.3 Індекси

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

2.6.5 Реляційні відношення між таблицями

2.6.6 Контроль цілісності зв'язків

2.7 Методи і способи доступу до даних

3. СТАНДАРТ ODBC І ТЕХНОЛОГІЯ ДОСТУПУ ДО БАЗ ДАНИХ ADO

3.1 Загальні принципи організації низькорівневого інтерфейсу OLE DB

3.2 Основні конструкції OLE DB

3.3 Стандартні провайдери OLE DB

3.4. Високорівнева об'єктна надбудова ADO

3.4.1 Об'єктна модель ADO

3.4.2. Компонент TADOConnection

3.4.3 Механізм з'єднання зі сховищем даних ADO

3.4.4 Клас TCustomADODataSet

3.4.5 Компонент TADODataSet

3.4.6 Компонент TADOTable

3.4.7 Компонент TADOQuery

3.4.8 Компонент TADOStoredProc

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

4.1 Функціональне призначення та технологічні особливості розробки

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

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

4.4 Програмна реалізація системи

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

5.1 Організаційно-економічна частина

5.2 Економічне обґрунтування необхідності розробки

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

6.1 Аналіз небезпечних й шкідливих виробничих факторів в видавничому центрі

6.2 Заходи щодо норрисізації небезпечних і шкідливих факторів

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

ВИСНОВКИ

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

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Початок робіт: 01.11.09. Закінчення робіт: 25.05.10.

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

Гнучка система автоматизації обліку методичних матеріалів була реалізована за допомогою інструментального засобу прискореної розробки програм системи програмування Delphi 2006 Explorer, технології доступу до бази даних ADO та пакету альтернативних компонентів Development Express.

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

IVC.exe - виконуємий файл розробленої системи;

Met_baza.mdb - файл бази даних MS Access;

Шаблон.dot - шаблон документу для створення каталогу методичних матеріалів;

path.ini - ini-файл системи, що містить шлях до бази даних.

Додаткове програмне забезпечення: установка пакету MS Office.

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

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

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

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

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

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

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

Додаткове програмне забезпечення: установка пакету MS Office;

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

IBM-Сумісний комп'ютер, не нижче Pentium III, RAM-512Mb, SVGA-монітор 17 дюймів, вільний простір на жорсткому диску біля 3 Мб.

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

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

загальний опис технології процесу;

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

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

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

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

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

2.1 Призначення і область використання баз даних

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

2.2 Технології доступу до баз даних

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

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

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

На сьогодні існує безліч технологій доступу до даних, таких як BDE, OLE, ODBC, ADO, і дотепер розробляються нові, надійніші, зручніші в роботі і більш швидкодіючі технології.

2.2.1 Технологія BDE

Borland Database Engine (BDE) є набором інтерфейсів для доступу до різних баз даних. З погляду користувачів - BDE це всього лише проста конфігураційна утиліта, в якій задаються драйвери і описуються інтерфейси для доступу до баз даних. Тим самим досягається незалежність табличних форматів.

Можливості BDE:

- підтримка багатьох форматів. У BDE вбудована підтримка багатьох форматів. До того ж BDE автоматично підтримує все ODBC-драйвера (Open Database Connectivity - ще один інтерфейс до баз даних), встановлені в операційній системі.

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

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

2.2.2 Технологія ADO

Технологія Microsoft ActiveX Data Objects забезпечує універсальний доступ до джерел даних із програм, які використовують БД. Таку можливість надають функції набору інтерфейсів, створені на основі загальної моделі об'єктів СОМ і описані в специфікації OLE DB.

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

За сервери БД турбуватися не варто, обробка запитів SQL -- це їх основний обов'язок. Але як бути з файловими послідовностями, електронними таблицями, файлами електронної пошти і т. д.? Тут на допомогу приходять механізми ADO і інтерфейси OLE DB.

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

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

Об'єкти OLE DB створюються і функціонують так само, як і інші об'єкти СОМ. Кожному об'єкту відповідає ідентифікатор класу CLSID, що зберігається в системному реєстрі. Для створення об'єкту використовується метод CoCreateinstance і відповідна фабрика класу. Об'єкту відповідає набір інтерфейсів, до методів яких можна звертатися після створення об'єкту.

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

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

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

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

Нижченаведений опис специфікації OLE DB представлений|уявлений| відповідно до офіційної термінології Microsoft для даної наочної|предметної| області.

Специфікація OLE DB розрізняє наступні|такі| типи об'єктів, які будуть розглянуті нижче.

Нумератор (Enumerator) виконує пошук джерел даних або інших нумераторів. Використовується для забезпечення функціонування провайдерів ADO.

Об'єкт-джерело даних (Data Source Object) представляє сховище даних.

Сесія (Session) об'єднує сукупність об'єктів, що звертаються до одного сховища даних.

Транзакція (Trasaction) інкапсулює механізм виконання транзакції.

Команда (Command) містить текст команди і забезпечує її виконання. Командою може бути запит SQL, звернення до таблиці БД і т.д.

Набір рядів (Rowset) є сукупністю рядків даних, що є результатом виконання команди ADO.

Об'єкт-помилка (Error) містить інформацію про виняткову ситуацію.

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

2.3 Схема обміну даними при роботі з БД

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

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

Цикл взаємодії користувача з БД за допомогою додатку можна розділити на такі основні етапи:

Користувач термінала в процесі діалогу з додатком формулює запит на деякі дані з БД.

Додаток на програмному рівні засобами мови маніпулювання даними формулює запит, з яким звертається до СКБД.

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

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

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

Результати вибору даних з бази додаток відображає на терміналі користувача.

У випадку роботи користувача в діалоговому режимі із СКБД (без додатку) цикл взаємодії користувача з БД спрощується.

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

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

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

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

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

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

Багатокористувальницькі СКБД часто використовуються на великих та середніх ЕОМ, але основним режимом використання ресурсів є колективний доступ.

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

Технологію одночасної роботи користувача з декількома програмами непогано реалізовано в Windows. При роботі у Windows СКБД не має необхідності підтримувати декілька сеансів роботи з користувачами.

2.4 Архітектури баз даних

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

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

Перевагою організації ІС за архітектурою клієнт-сервер допускає різні варіанти реалізації.

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

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

Для створення та керування персональними БД та додатків, які з ними працюють, використовуються СКБД, такі як Access, Visual FoxPro фірми Microsoft, Paradox фірми Borland.

Корпоративна БД створюється, підтримується та функціонує під керуванням сервера БД, наприклад Microsoft SQL Server, Oracle Server.

В залежності від розмірів організації та особливостей розв'язуваних задач ІС може мати одну з наступних конфігурацій:

Комп'ютер-сервер, який містить корпоративну та персональні БД.

Комп'ютер-сервер та персональні комп'ютери з ПБД.

Декілька комп'ютерів -серверів та персональних комп'ютерів з ПБД.

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

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

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

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

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

Для розгляду методів організації БД визначимо такі поняття.

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

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

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

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

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

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

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

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

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

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

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

ієрархічну;

мережну;

реляційну;

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

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

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

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

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

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

2.6 Реляційна модель даних

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

Щоб таблицю можна було вважати відношенням, вона повинна задовольняти певним вимогам:

Значення в комірках повинні бути одиночними.

Всі записи в стовпці повинні бути одного типа.

Кожен стовпець повинен мати унікальне ім'я.

У відношенні не може бути двох однакових рядків.

Порядок рядків не має значення.

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

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

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

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

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

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

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

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

2.6.1 Таблиці

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.3 Індекси

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

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

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

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

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

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

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

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

2.6.5 Реляційні відношення між таблицями

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

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

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

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

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

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

відношення «один-до-одного» або 1:1;

відношення «один-до-багатьох» або 1:М;

відношення «багатьох-до-одного» або М:1;

відношення «багатьох-до-багатьох» або М:М.

Таблиця 2.1

Характеристика видів зв'язку таблиць

Характеристика полів зв'язку за видами	1:1	1:М	М:1	М:М
Поле зв'язку основної таблиці	являються ключем	являються ключем	не являються ключем	не являються ключем
Поле зв'язку додаткової таблиці	являються ключем	не являються ключем	являються ключем	не являються ключем

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

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

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

Зв'язок М:1 має місце у випадку, коли одній чи декільком записам основної таблиці ставиться у відповідності один запис додаткової таблиці.

Загальний вигляд зв'язку М:М виникає у випадках, коли декільком записам основної таблиці відповідає декілька записів додаткової таблиці.

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

2.6.6 Контроль цілісності зв'язків

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

Контроль цілісності зв'язків звичайно означає аналіз вмісту таблиць на дотримання таких правил:

кожному запису основної таблиці відповідає нуль або більше записів допоміжної таблиці;

в допоміжній таблиці немає записів, в яких немає батьківських записів в основній таблиці;

кожний запис допоміжної таблиці має тільки один батьківський запис основної таблиці;

Опишемо дію контролю цілісності при маніпулюванні даними в таблицях. Розглянемо три основних операції над даними двох таблиць:

введення нових записів;

модифікацію записів;

видалення записів.

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

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

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

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

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

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

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

Видалення записів основної таблиці логічно підчинити одному з наступних правил:

видаляти можна запис, який не має підлеглих записів;

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

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

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

При знищенні записи у головній таблиці обов'язково необхідно видалити усі зв'язані записи.

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

2.7 Методи і способи доступу до даних

Методи доступу до даних таблиці підрозділяються на:

послідовні;

прямі;

індексно-послідовні.

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

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

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

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

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

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

навігаційний;

реляційний.

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

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

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

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

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

3. СТАНДАРТ ODBC І ТЕХНОЛОГІЯ ДОСТУПУ ДО БАЗ ДАНИХ ADO

3.1 Загальні принципи організації низькорівневого інтерфейсу OLE DB

OLE DB являє собою низькорівневий інтерфейс, що забезпечує доступ до різних джерел даних - реляційним і не реляційним, що містять текст, графічні й географічні дані, до файлів електронної пошти, вмісту файлових систем і створюваного користувачами бізнес-об'єктам. OLE DB визначає набір інтерфейсів компонентної об'єктної моделі (Component model object, COM), що включають у себе служби різних систем керування базами даних для забезпечення універсального доступу до даних. За допомогою цих інтерфейсів програмісти можуть створювати додаткові сервіси баз даних.

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