Запити та запитувальні зв’язки
Наступним етапом є виділення запитів до БД і їх словесний опис. Запити потрiбно описувати на природнiй мовi таким чином, щоб можна було видiлити послiдовнiсть переходу вiд одного об'єкта до iншого при виконаннi запиту.
Запит 1.
Виведення даних про книги, взятих окремим користувачем.
Форма вихідного повідомлення буде подана в Додатку 3.
Запит 2.
Виведення даних про користувачів які не повернули книги.
Форма вихідного повідомлення буде подана в Додатку 3.
Запит 3.
Виведення даних про вартість книг з певної категорії.
Форма вихідного повідомлення буде подана в Додатку 3.
2.3 Структурні зв’язки та їх представлення на графі ілм
Сформулювавши усі структурні зв’язки, виконаємо побудову інфологічної моделі за допомогою СASE-засобу ERwin.
Рисунок 1. Представлення моделі в ERwin.
Між усіма об’єктами ми маємо відношення 1:Б. В CASE-засобі ERWin ці зв’язки відображаються обов’язковими неідентифікуючими зв’язками. Це значить, що наші об’єкти (таблиці) є незалежними один від одного та значення вторинних ключів у дочірніх доблицях не можуть приймати нульові значення.
Таблиця Нормативні показники не звязана з іншими таблицями, оскільки створюється за допомогою запитів.
2.4 Автоматизація проектування інфологічної моделі
Таблиця 3
Назва поля |
Тип даних |
Розмір поля |
1 |
2 |
3 |
«Користувач» |
||
Код користувача |
Текстовий |
10 |
Ім’я користувача |
Текстовий |
50 |
Номер телефону |
Текстовий |
13 |
«Видані книги» |
||
Код виданої книги |
Текстовий |
10 |
Код книги |
Текстовий |
10 |
Код користувача |
Текстовий |
10 |
Дата видачі |
Дата |
8 |
Дата повернення |
Дата |
8 |
«Книги» |
||
Код книги |
Текстовий |
10 |
Код категорії |
Текстовий |
10 |
Код видавництва |
Текстовий |
10 |
Назва книги |
Текстовий |
50 |
Рік видання |
Текстовий |
4 |
Кількість |
Чистовий |
1000 |
Ціна |
Числовий |
5 |
«Категорії» |
||
Код категорії |
Текстовий |
10 |
Назва категорії |
Текстовий |
20 |
«Автори» |
||
Код автора |
Текстовий |
10 |
Ім’я автора |
Текстовий |
50 |
«Видавництва» |
||
Код видавництва |
Текстовий |
10 |
Назва видавництва |
Текстовий |
30 |
3. Розробка даталогiчної моделi
3.1 Обґрунтування та вибір скбд
Наступним кроком в створенні програмного продукту (БД) є даталогічне проектування. На відміну від проектування на інфологічному рівні, на яке не впливають особливості конкретної СКБД, даталогічне проектування спирається на середовище певної СКБД. Тобто цей вид програмування враховує особливості та обмеження тієї СКБД на базі якій створюється продукт.
Для даталогічного проектування даної бази даних мною була обрана СКБД Microsoft Access 2010.
Microsoft Access об'єднує відомості з різних джерел в одній реляційній базі даних. Створювані форми, запити і звіти дозволяють швидко й ефективно поновлювати дані, одержувати відповіді на питання, здійснювати пошук потрібних даних, аналізувати дані, друкувати звіти, діаграми і т.д.
В Access усі відомості, що стосуються певної предметної області представляються у вигляді сукупності пов'язаних між собою таблиць і на фізичному рівні зберігаються в одному файлі. В цьому ж файлі крім таблиць зберігаються всі інструментальні засоби для роботи з ними (запити, форми, звіти, макроси, модулі).
Запити створюються для пошуку і відбору даних, що задовольняють визначені умови. Запити дозволяють також обновити або видалити одночасно декілька записів, виконати вбудовані або спеціальні обчислення.
Для перегляду, введення або зміни даних прямо в таблиці застосовуються форми. Форма дозволяє відібрати дані з однієї або декількох таблиць і вивести їх на екран, використовуючи стандартний або створений користувачем макет.
Для аналізу даних або друку їх певним чином використовується звіт. Наприклад, можна створити і надрукувати звіт, що групує дані і вираховує результати.
Що стосується продуктивності, то в Microsoft Access додані деякі засоби для значного підвищення продуктивності. Наприклад, Microsoft Access без необхідності не робить завантаження програм, таких як процедури Visual Basic для додатків і об'єктів доступу до даних, без яких деякі бази даних можуть обійтися. Це скорочує час завантаження бази даних і підвищує повну продуктивність. Відкриття декількох форм і звітів відбувається набагато швидше через відсутність модулів у формах і звітах, що не містять процедури обробки подій.
Для оптимізації запитів на відновлення значних обсягів даних із джерел даних ODBC достатньо послати на сервер запит, що обробляє весь відповідний запис одночасно, замість послідовного перебору.
До моменту виконання програми Visual Basic із модуля, у тому числі з модуля форми, Microsoft Access не виконує його завантаження. Це підвищує продуктивність.
Можлива підтримка відкомпільованого стану бази даних користувача навіть при її зміні. Перекомпілюються тільки змінені програми і всі програми, що залежать від змінених.
У Microsoft Access збільшена продуктивність вбудованих елементів Active, полів із списком.
Для того, щоб створити у формі або звіті незв'язані малюнки, варто використовувати елемент керування - малюнок. У цьому елементі керування малюнки виводяться значно швидше, ніж у вільній рамці об'єкта.
Майстер-аналізатор швидкодії аналізує об'єкти бази даних користувача і пропонує засоби максимального збільшення їхньої швидкості.
Перегляд звітів істотно прискорений, оскільки події генеруються при першому переміщенні по сторінках звіту.
У Microsoft Access входить такий новий засіб роботи, як помічник, він дає довідку по Microsoft Office. Після натискання кнопки будуть автоматично підібрані розділи довідки, що відносяться до поточних дій.