Початкова сторінка

Микола Жарких (Київ)

Персональний сайт

?

Зберігання графічної інформації
в Access 2.0

М.І.Жарких

В повідомленні розглянуто різні способи зберігання графічної інформації в СУБД Access 2.0. Визначено орієнтовні витрати дискової пам'яті для різних методів зберігання. Запропоновано новий – найраціональніший з точки зору використання дискової пам'яті – метод зберігання.

Експеримент

Жодна з книг по СУБД Access не містить ніяких рекомендацій щодо методів зберігання зображень в базах даних (БД) [Бёмер С. MS Access 2.0. – Спб.-М. : BHV, 1995. – 445 с.; Вейскас Д. Работа в Access 2.0. – Спб. : Питер, 1995. – 846 с.; Палмер С. Access 2.0 для чайников.- К. : Диалектика, 1995. – 250 с.; Крамм Р. Программирование в Access 2.0 для чайников. – К. : Диалектика, 1995. – 300 с.]; зокрема, нема рекомендацій щодо оптимізації використання дискової пам'яті для цієї мети. Щоб заповнити цю прогалину, я вдався до експерименту.

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

Вставка, спосіб перший : з меню Access “Редагування” (Edit) вибрати команду “Вставити об'єкт” (Insert object), в ній – можливість “Створити з файлу” (Create from file), потім вказати потрібний файл і виконати операцію.

Вставка, спосіб другий : відкрити потрібний файл в графічному редакторі (я використовував Corel Photo-paint), скопіювати образ, переключитись на Access і вставити образ в поле БД командою “Вставка” (Edit/Paste).

Зв'язування, спосіб перший : діяти як при першому способі вставки, але у вікні діалогу “Вставити об'єкт” треба увімкнути вимикач “Зв'язати” (Link), який по умовчанню вимкнуто.

Зв'язування, спосіб другий : скопіювати образ в графічному редакторі, переключитись на Access і вставити за допомогою команди “Спеціальна вставка” (Edit/Paste special), в якій треба вказати режим “Вставити посилання” (Paste link). Цей спосіб гірший від першого через те, що спроба редагувати зображення у програмі-сервері викликає помилку.

Для експерименту я заготував 11 растрових зображень : штрихових чорно-білих з глибиною кольору 1 біт і 256-кольорових з глибиною кольору 8 біт. Зображення у вигляді BMP-файлів мали розмір від 9 до 273 Кб, загальний їх обсяг – 912 Кб. Ці ж зображення були перетворені у GIF-файли розміром від 5 до 133 Кб; в такому вигляді вони займали 360 Кб (тобто 40 % від обсягу BMP-файлів).

Далі була створена нова БД Access, яка містила одну таблицю :

таблиця Зображення

Ід : лічильник;

Зображ : OLE об'єкт;

кінець таблиці {Зображення}

Для заповнення таблиці було створено формуляр з одним полем зображення, яке мало тип “зв'язана рамка об'єкту” (bound object frame). З цим-то полем формуляру і можна виконувати всі описані вище операції вставки та зв'язування зображень.

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

Зростання бази даних по мірі…

Малюнок 1. Зростання бази даних по мірі накопичення графічної інформації.

Виявилось, що для зберігання 360 Кб зображень методом вставки потрібно 5.2 Мб, а методом зв'язування – 3.2 Мб дискової пам'яті. Це означає, що при методі вставки потрібна дискова пам'ять в кількості 1450 % від розміру зображень, а в методі зв'язування – в кількості 890 % (+ 100 % висхідних файлів, отже, разом 990 %).

Access, як відомо, може оперувати файлами розміром в 1000 Кб. При встановлених темпах росту файлу ми зможемо зберегти в БД 112 Мб графічної інформації (у вигляді економних GIF-файлів), тобто десь 11 000 креслень (розміром в 10 Кб кожне) або 1 100 фотографій (розміром в 100 Кб кожна). Збільшення загального обсягу диску нічим не допоможе, оскільки обмежуючим фактором виступає розмір файлу бази даних.

Теорія

Розглянемо результати експерименту трохи детальніше. Головне, що кидається у вічі – це те, що при методі вставки розмір БД ніяк не залежить від формату висхідного файлу (BMP чи GIF). Це означає, що Access перетворює кожен графічний образ у свій внутрішній формат, який не залежить від формату файлу-джерела. Тому зекономити дискову пам'ять на економному графічному форматі (GIF чи JPEG) не вдається.

Для більш надійного прогнозування розміру файлу БД треба відкладати приріст розміру файлу БД як функцію розміру графічного файлу (малюнок 2). Найбільш прозорими є результати для BMP-файлів. З малюнка видно, що вся множина значень чітко розпадається на дві підмножини : перші три зображення і решта зображень. Позначивши приріст файлу БД через Y, а розмір графічного файлу через X, можна побудувати лінійну регресію виду

Y = A + BX

і обчислити параметри регресії, які наведено в таблиці 1.

Таблиця 1. Параметри регресії для даних малюнка 2 (вставка зображень).

A, Кб B Квадрат коефіцієнта кореляції
Перші три зображення 137 35.9 0.995
Решта зображень 14.5 3.33 0.9967
Разом 289 1.945 0.226

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

[Розмір БД] = 2270 Кб + 3.33×[Сумарний розмір BMP-файлів] (1)

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

Значно гіршою є якість прогнозу для вставки GIF-файлів :

[Розмір БД] = 2270 Кб + 4.17×[Сумарний розмір GIF-файлів] (2)

але квадрат коефіцієнта кореляції для нього становить десь 0.37. Таке зменшення кореляції пов'язане з великою дисперсією ступеня компресії в GIF-файлі.

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

Таблиця 2. Параметри регресії для зв'язування зображень.

A, Кб B Квадрат коефіцієнта кореляції
Перші три зображення 65 46.8 0.9997
Решта зображень 7.4 2.02 0.9959
Разом 226 1.53 0.075

Підсумкові рівняння для прогнозу розміру БД при методі зв'язування мають вигляд :

[Розмір БД] = 1480 Кб + 2.02×[Сумарний розмір BMP-файлів] (3)

[Розмір БД] = 1148 Кб + 2.53×[Сумарний розмір GIF-файлів] (4)

Аналіз приросту розміру БД під час…

Малюнок 2. Аналіз приросту розміру БД під час вставки зображень.

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

Таблиця 3. Параметри регресії для прогнозу витрат дискової пам'яті.

A, Кб B (BMP-файли) B (GIF-файли) Максимальний обсяг BMP-файлів в одній БД, Мб
Вставка 2270 3.33 4.17 300
Зв'язування без висхідних файлів 1480 2.02 2.53 500
Зв'язування з висхідними файлами 1480 3.02 3.53 500

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

Практика

Який з проаналізованих методів зберігання зображення можна рекомендувати для використання ? Якщо в БД треба зберігати незначну кількість графічних образів (прикладом такої БД є NWIND.MDB – учбова БД, що постачається разом з Access), то треба вживати вставку. Незначна економія дискової пам'яті не виправдовує необхідності тягати за собою висхідні файли зображень для зв'язування.

Якщо ж завданням БД є масове зберігання графічної інформації (саме таке завдання стоїть перед БД “Пам'ятки України”), то не можна рекомендувати жодного з цих методів. Надзвичайно високі накладні витрати стають неприпустимими, коли число зображень досягає 10 000 (з наведених вище розрахунків видно, що обсяг БД наближається до гранично допустимого при зберіганні 30 000 креслень або 3 000 фотографій; звичайно, цього дуже мало). Програмісти Access явно були незнайомі з творами маршала Л.І.Брежнєва, і тому до них не дійшов полум'яний заклик до економіки – бути економною [натомість програмісти Word з цим закликом знайомі : зв'язування будь-якої кількості зображень практично не впливає на розмір документу].

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

таблиця ВказНаЗображення

Ід : лічильник;

ШляхДоФайлу : текст[100];

кінець таблиці {ВказНаЗображення}

і заповнити цю таблицю повними іменами потрібних графічних файлів (скажімо, застосувавши стандартний діалог “Відкрити файл”). Для перегляду зображень треба створити формуляр, базований на таблиці “ВказНаЗображення”, в який треба помістити один елемент управління – незв'язану рамку об'єкта (unbound object frame). Його ім'я по умовчанню буде Embedded0. Далі треба написати обробник події “Від запису до запису”. У максимально спрощеному вигляді він має бути таким :

Sub Form_Current ()

If (Not IsNull(Me ![ШляхДоФайлу])) Then

'встановлюємо нове джерело інформації :

Me ![Embedded0].SourceDoc = Me ![ШляхДоФайлу]

'встановлюємо зв'язок, щоб перемалювати зображення :

Me ![Embedded0].Action = OLE_CREATE_LINK

End If

End Sub

[Якщо ви хочете цим методом промальовувати об'єкти, отримані від різних серверів (наприклад, не тільки Corel Photo-paint, але й Corel Draw), то треба перевизначати також інші властивості для рамки об'єкту]

Експеримент по викладеній вище програмі показав, що зберігання 11 зображень не впливають на розмір файлу БД (360 Кб). Отже, в ході розвитку технології об'єктного зв'язування ми відкотились на висхідні позиції – зберігати в базі даних тільки шлях до файлу. Перевагою даного способу є можливість зберігати необмежену кількість посилань на файли (мільйони посилань). Недоліками є :

– під час закриття формуляру вам пропонують зберегти зміни в проекті формуляру (від цієї пропозиції треба відмовлятись);

– перехід від запису до запису є дуже повільним [на 486DX2-66 ця операція займає 55..60 секунд, в той час як перемальовка вставленого чи зв'язаного зображення – 1..2 сек].

Страшенно довгий час виконання команди створення нового зв'язку пояснює нам, що програмісти Access вирішили піти на додаткові витрати дискової пам'яті заради прискорення перемальовки зображень. Я думаю, що і в запропонованому вище раціональному способі можна прискорити перемальовку, але для цього треба звернутись до творів М.С.Горбачова і його вчення про прискорення. Це – тема іншої роботи.

Надійшла до редакції 28.03.1997 р.

Джерело : Археометрія та охорона історико-культурної спадщини, 1998 р., вип. 2, с. 53 – 56.