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

 

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

При виході реляційних баз даних на ринок корпоративних пропозицій, до їх продуктивності стали пред’являти підвищені вимоги. Користувачі хотіли бути впевнені в тому, що вибрана ними СКБД не почне “задихатися” при збільшенні вимог додатків. Це занепокоєння користувачів, яка доповнювалась також зацікавленістю виробниками СКБД призвела до “холодної війни” за показники продуктивності між виробниками. Одних цікавила максимальна абсолютна продуктивність СКБД, інших – співвідношення ціна/продуктивність і відповідна економія коштів. У всіх випадках компанії рекламували контрольні тести, які доказували перевагу їх продукту над іншими, і робилися спроби дискредитувати контрольні тести інших виробників.

Перш за все контрольні тести розроблялися самими виробниками. Однак виробники самі були зацікавлені в найкращих результатах цих тестів, що приводило до спотворення реально існуючої інформації про продуктивності роботи їх продуктів. Пізніше з’явились два незалежних теста “Дебет/кредит” та ТР1. Перший з них виконував прості бухгалтерські транзакції, а другий – вимірював продуктивність OLTP-систем. Однак ці тести були достатньо простими, і тому виробникам не складало великих труднощів маніпулювати результатами отриманих тестів, щоб представити свої продукти в найкращому світлі. Як правило маніпулювання даними тестами полягало у використанні більш продуктивніших та більш сучасних комп’ютерах, специфічно представлених даних, якими наповнювалися таблиці та інші.

Спроби зробити результати тестів більш-менш стабільними та достовірними закінчились об’єднанням декількох виробників і консультантів по базах даних в організацію Transaction Processing Council, яка зайнялась створенням стандартного тесту для реляційних баз даних. Ця організація розробила серію офіційних контрольних тестів для реляційних баз даних, відомих як ТРС-А, ТРС-В, ТРС-С. Ця організація взяла на себе функцію збору, зберігання та публікації результатів контрольних тестів для різних СКБД, а також роботу по верифікації результатів тестів, про які інформують виробники СКБД.

Однак, ці тести як правило втрачаються за горою рекламних кампаній нових продуктів, і кінцеві користувачі, як правило, не мають реальних даних про продуктивність тієї чи іншої СКБД в специфічних умовах (адже організація ТРС не може фізично протестувати всі можливі варіанти поєднання СКБД та різних видів програмного забезпечення). Тому в цій роботі ми спробуємо навести результати тестування певних функцій найбільш поширених СКБД при роботі з технологіями сервлетів та JSP. Ще однією причиною виконання роботи являється те, що компанія ТРС випустила тільки beta версію свого тесту ТРС-W, який орієнтований на оцінку продуктивності тестуючої СКБД у поєднанні з Internet-додатками, які працюють з базами даних через WWW [3].

 

Робота з графікою в Java

 

В Java аплети можуть малюватися на екрані, використовуючи метод paint(). Оскільки сам аплет явно ніколи не викликає метод repaint(), то це необхідно здійснювати програмісту вручну, або підключити аплет до слухача подій, який забезпечить перемалювання аплету при настанні визначеної події. У аплета є три різних способи, які можна використати для малювання:

1. repaint(перемалювання) викликається в будь-який час, коли аплет повинен заново вивести своє зображення на екран.

2. update (обновлення) викликається методом repaint(), указуючи, що настав момент для обновлення зображення; стандартний метод update () призводить очистку зображення і викликає метод paint().

3. paint(малювання) призводить вивід зображення аплета у відведеному місці на екрані; методу paint() в якості параметра передається об’єкт Graphics, який аплет може використовувати для малювання різних фігур і зображень.

Пакет AWT підтримує широкий вибір графічних методів. Всі графічні елементи пов’язані з вікнами. Це може бути головне або дочірнє вікно атлета чи окреме вікно додатку [4].

В Java використовується звичайна система координат (х, у), де х – кількість екранних точок від лівої границі екрану, у – кількість від верхньої границі екрану. Лівому верхньому куту відповідають координати (0,0). Така система координат використовується практично у всіх графічних системах. Координати задаються в пікселях. Вся інформація виводиться на екран з допомогою графічного контексту (graphics context), який інкапсульований в класі Graphics і отримується двома способами:

1. Передається в аплет під час виклику одного з багаточисельних методів таких як paint() або update().

2. Повертається методом getGraphics().

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

Клас Graphics забезпечує засіб для малювання наступних об’єктів:

1. Прямих.

2. Прямокутників і багатокутників.

3. Еліпсів і кругів.

4. Дуг.

5. Графічних зображень.

6. Тексту (різними шрифтами).