Пропонуємо майбутнім користувачам систем управління базами даних два підходи, два варіанти проектування баз даних. Перший варіант широко відомий, бо він запропонований фірмою Microsoft. Другий варіант відображає практичний досвід проектування, і за основу взято варіант, надрукований у «ComputerWorld — Moscow» за 1996 рік.
Варіант 1. Етапи проектування бази даних
Нижче наведені основні етапи проектування бази даних:
1. Визначення мети створення бази даних.
2. Визначення таблиць, що їх повинна містити база даних.
3. Визначення необхідних у таблиці полів.
4. Завдання індивідуального значення кожному полю.
5. Визначення зв’язків між таблицями.
6. Відновлення структури бази даних.
7. Додавання даних і створення запитів, форм, звітів та інших об’єктів бази даних.
8. Використання засобів аналізу в СУБД.
Розглянемо ці етапи дещо детальніше.
1. Визначення мети створення бази даних. На першому етапі проектування бази даних необхідно визначити мету створення бази даних, основні її функції та інформацію, яку вона повинна містити. Тобто потрібно визначити основні теми таблиць бази даних та інформацію, що міститимуть поля таблиць.
База даних має відповідати вимогам тих, хто безпосередньо з нею працюватиме. Для цього потрібно визначити теми, які по-
винна покривати база даних, звіти, які вона має видавати, проаналізувати форми, що у даний момент використовуються для запису даних, порівняти створювану базу даних із добре спроектованою, подібною їй базою.
2. Визначення таблиць, які повинні містити база даних. Одним із найскладніших етапів у процесі проектування бази даних є розробка таблиць, тому що результати, які повинна видавати база даних (звіти, вихідні форми тощо), не завжди дають повне уявлення про структуру таблиці. У разі проектування таблиць зовсім не обов’язково використовувати СУБД. Спочатку краще розробити структуру на папері. Отже, у разі проектування таблиць слід керуватися такими основними принципами:
— інформація в таблиці не повинна дублюватися. Не повинно бути повторень і між таблицями. Коли певна інформація зберігається лише в одній таблиці, то і змінювати її доведеться лише в одному місці. Це робить роботу ефективнішою, а також виключає можливість розбіжності інформації в різних таблицях. Наприклад, в одній таблиці мають міститися адреси й телефони клієнтів;
— кожна таблиця повинна містити інформацію лише на одну тему. Дані на кожну тему опрацьовуються набагато легше, якщо вони утримуються в незалежних одна від іншої таблицях. Наприклад, адреси та замовлення клієнтів зберігаються в різних таблицях, щоб у разі вилучення замовлення інформація про клієнта залишилася в базі даних.
3. Визначення необхідних у таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці містить окремі дані по темі таблиці. Наприклад, у таблиці з даними про клієнта можуть бути поля з назвою компанії, адресою, містом, країною і номером телефону. Під час розробки полів для кожної таблиці необхідно пам’ятати:
— кожне поле має бути пов’язане з темою таблиці;
— не рекомендується включати до таблиці дані, що є результатом виразу;
— у таблиці має бути вся необхідна інформація;
— інформацію варто розбивати на найменші логічні одиниці (наприклад, поля «Ім’я» і «Прізвище», а не загальне поле «Ім’я»).
4. Задання індивідуального значення кожному полю. З тим, щоб СУБД могла зв’язати дані з різних таблиць, наприклад дані про клієнта і його замовлення, кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.
5. Визначення зв’язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв’язку даних у різних таблицях. Для цього потрібно визначити зв’язки між таблицями. Бажано вивчати зв’язки між таблицями в уже існуючій базі даних. Для перегляду зв’язків у вибраній базі даних відкриваємо її і вибираємо відповідні команди.
6. Відновлення структури бази даних.
Після проектування таблиць, полів і зв’язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки. Бажано це зробити на даному етапі, поки таблиці не заповнені даними. Для перевірки необхідно створити кілька таблиць, визначити зв’язки між ними та ввести кілька записів у кожну таблицю, потім подивитися, чи відповідає база даних поставленим вимогам. Рекомендується також створити чернеткові вихідні форми та звіти й перевірити, чи видають вони необхідну інформацію. Крім того, необхідно виключити з таблиць усі можливі повторення даних.
7. Додавання даних і створення інших об’єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.
8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft Access є два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв’язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.
Варіант 2. Розробка проекту бази даних
1. Розробка логічної моделі даних. Логічні моделі використовуються розробниками баз даних для формального представлення інформаційних потреб виробництва, економіки, бізнесу тощо. Найрозповсюдженішою формою відображення цієї моделі слугують ER-діаграми . Основними поняттями ER-моделі є сутність, зв’язок та атрибут. Кожна з частин такої діаграми повідомляє дещо про структуру даних або про те, як ці дані співвідносяться з іншими.
Як правило, розробка логічної моделі являє собою ітераційний процес, що складається з фаз аналізу, проектування та оцінювання. При цьому на кожній ітерації додаються нові правила. Добрі засоби проектування баз даних мають бути гнучкими, а організація роботи з ними — ефективною. ER-діаграми повинні доповнюватися детальнішою інформацією про бізнес, правила та обмеження посилання на цілісність, а також давати змогу керувати наочним поданням деталей моделі.
Під час створення логічної моделі потрібно насамперед провести важливу роботу з замовником. Найбільший обсяг робіт з базами даних пов’язаний із запитами. Тож потрібно якнайдокладніше дізнатися від замовника про можливі запити до бази даних. Досвід проектування свідчить про те, що замовники часто не уявляють, які можливості даватиме їм база даних, до вирішення яких нових задач вони зможуть долучитися. Через це під час проектування потрібно якнайраніше показати замовникам їхні можливі горизонти, щоб так само якнайраніше довелося б вносити зміни до логічної моделі.
2. Підготовка звіту про логічну модель. Для відстежування процесу проектування логічної моделі використовуються звіти Вони корисні також для узгодження вимог із замовниками. У звітах, як правило, перераховуються сутності, їх атрибути, правила та обмеження, що вміщують до бази даних. Добрі засоби підготовки звітів містять різні види інформації про логічну модель, сприяють гнучкому розміщенню та форматуванню, а також поданню звіту у файл або його експорту в інші додатки. При узгодженні вимог із замовниками варто результат оформляти окремим протоколом.
3. Перетворення логічної моделі у фізичну. У процесі розробки фізичної моделі сутності, атрибути та зв’язки складають фізичну модель, відображаються у таблиці та стовпчиках. До раніш заданих властивостей стовпчиків (типів даних, протяжностей і невизначених значень) додаються нові — первинні та зовнішні ключі, індекси, перевірочні обмеження та правила підтримки посилкової цілісності. Щоб правильно і добре виконати цей етап проектування, засоби моделювання даних повинні працювати з кількома популярними СУБД SQL-типу, графічно відображати фізичні характеристики, дозволяти призначати та модифікувати триггери за замовчування, створювати власні триггери, денормалізувати фізичну модель, не торкаючись при цьому логічної.
4. Підготовка звіту про фізичну модель. Як правило, для того, щоб переглянути якусь таблицю або всі таблиці одночасно, разом з деталями (стовпчики, їх характеристики, індекси, зовнішні ключі та триггери) застосовують звіт про фізичну модель. Добрі засоби підготовки таких звітів прості в користуванні, мають гнучкий інтерфейс для задання елементів, що включають-
ся до звіту, організації звіту та його формування. Вони повин-
ні надавати детальну інформацію про реалізацію обмежень, правил посилкової цілісності, включаючи призначення та зміст триггерів.
5. Генерація схеми бази даних. Схема описує реалізацію бази даних з урахуванням специфіки конкретної СУБД. Схема може створюватися або мовою визначення даних (файли DDL), або при прямому зверненні до СУБД. Програмні продукти, які добре підтримують генерацію схеми, дають засоби контролю за генеруючими елементами схеми, що дає змогу зробити цей процес ітеративним. Варто шукати інструменти, які підключаються до нашої цільової СУБД і дають можливість переключатися між різними СУБД, мінімізуючи при цьому ручне редагування.
6. Супроводження розроблюваної моделі даних. Більшість баз даних протягом свого життєвого циклу еволюціонує. Для того, щоб спростити цей процес, рекомендується синхронно змінювати модель та базу даних. Варто звертати увагу на засоби синхронізації, утиліти керування версіями та захисту. За допомогою найзручніших у роботі інструментів можна переносити зміни в обидва боки: з моделі в схему, і навпаки. Якщо раніше замовник після здачі СУБД в експлуатацію відмовлявся від супроводження, то тепер, як правило, проектувальники супроводжують експлуатацію СУБД. Це накладає на них додаткову відповідальність за якість проектування, бо всі негаразди доводиться ліквідовувати їм самим.
7. Звернене проектування, що виходить з існуючої бази даних. Відтворення схеми існуючої бази даних служить кільком цілям. Воно дає змогу побудувати модель цієї бази даних, перенести існуючу базу даних з однієї СУБД на іншу, а також досить просто модифікувати схему бази даних, що функціонує. Ключовими параметрами для виконання такого завдання є точність та гнучкість. Ми повинні мати можливість задати елементи схеми, з якими працюватиме програма, й очікується, що внаслідок генерації схеми бази даних за відновленою моделлю має з’явитися тотожна копія початкової схеми.
Як бачимо, другий варіант окреслює загальніший підхід до проектування баз даних та враховує відносини з замовником проекту. Розглянемо етапи проектування бази даних на основі засобів СУБД MS Access 97, але перед цим дамо характеристики цій реляційній СУБД.
48. Області звіту, їх призначення. Створення заголовка та шапки документа у звіті. Порядок заповнення звіту і підрахунок результатів по строкам та графам. Створення звіту і знаходження сум, середнього, мінімума, максимума.
Створення звітів
Звіт є кінцевим наслідком багатьох задач управління базами даних. Можна створювати різні звіти з різними рівнями деталювання.
Звіти можна створювати вручну, за допомогою засобу Автоотчет або за допомогою майстра звітів.
Автоматичне створення звіту
Якщо у нас є вибрана таблиця чи запит, відкриваємо меню кнопки Новый объект панелі інструментів і вибираємо команду Автоотчет. Буде створено звіт у стовпчик.
Створення звітів
за допомогою майстра звітів
Майстри звітів використовуються для створення звітів у стовпчик, стрічкових звітів з групами та без, поштових наклейок та підсумкових звітів. Для створення звіту за допомогою майстра звітів:
1. У вікні бази даних відкриваємо вкладку Отчет і натискаємо кнопку Создать — з’явиться діалогове вікно Новый отчет.
2. Вибираємо у списку праворуч пункт Мастер отчетов.
У списку внизу виберемо таблицю (чи запит), дані якої будуть використані у звіті.
3. Натискаємо кнопку ОК — з’явиться діалогове вікно Создание отчетов. Виконавши певні дії в цьому вікні і натиснувши кнопку Далее, переходимо до наступного діалогового вікна і т. д.
4. Після виходу з шостого діалогового вікна звіт потрібно надрукувати. Наприклад, Файл/Печать.
Звіти: використовуються для більш зручного представлення даних при друці, створюються на базі значень таблиці і запитів. Створення: в основному вікні БД відкриваємо вкладку Отчеты – Мастер Отчета. Потім у вікні списку таблиці Запроси вибирають таблицю або запит на базі яких створюємо звіт, з»являється
вікно «Доступні поля», вибираємо кнопку > , далі вибираємо поле, по якому відбувається групування даних, активізуємо поле і >. В цьому вікні можна визначити критерії для групування значень. В наст. вікні визначають які підсумки будуть розраховуватися. В наст. вікні – критерії сортування значень. В наст.вікнах вибираємо вид та стиль звіту, в останньому – назву, кнопка”Готово”. Для роботи зі звітами використ.такі графічні елементи: кн.”Надпісь” для створ.текстових полів, кнопка “Поле“ для створ.розрахункових полів. Для створ.текстового поля активіз.кнопку”Надпісь” вказівник стає + і малюємо поле. Для створ.розрахункового поля актив.кнопку”Поле”,з'являється 2 поля: для назви і визначення значень, активізуємо поле і свойства.
Типи звітів:
- рядкові
- звіти в стовпчик
- звіти для розсилок
- поштові наклейки
1. Вибрати вкладнику Отчеты, натиснути на кнопку Создать, вибрати Мастер отчетов та натиснути на кнопку Ok.
2. Вибрати потрібну таблицю або запит та поля
3. Задати рівні групування, а саме поля, для яких у звіті будуть виводитися проміжні підсумки (Наприклад, НАЗВА МІСЯЦЯ). Натиснути на кнопку Далее (рис. 10.151).
4. Визначити порядок сортування записів у звіті та, натиснувши на кнопку Итоги, задати підсумкові операції (рис. 10.152). Натиснути на кнопку Далее.
5. Вибрати макет для звіту (рис. 10.153). Натиснути на кнопку Далее.
6. Вибрати стиль звіту. Натиснути на кнопку Далее.
7. Увести назву звіту і натиснути на кнопку Готово.
8. Переглянути звіт, вибравши його у вікні бази даних та натиснувши на кнопку Просмотр.
Розрахунок заг.функцій в звітах. Звіт відкривають у режимі конструктора кнопкою Поле, створюють поле в частині Прімєчаніє Отчьота. Після створення із меню правою мишею команда Свойства – Данние – Данние, з'являється вікно Построітель вираженій, ліворуч - перелік функцій Встроєнниє Функції, в третій частині вибираємо функції, середня частина містить категорії функцій, кнопка Вставити. З'являється у вікні назва функції AVG (Expr), треба виділити те, що в дужках, замість нього: активізувати “Звіт по” або відповідний об”єкт і шукаємо потрібне і кнопка ОК.
49. Види запиту (режими представлення запиту). Технологія друку запиту на мові SQL. Які існують способи модифікації запитів?
СУБД ACCESS дозволяє створювати запити за допомогою майстрів та у режимі конструктора. У СУБД ACCESS під час виконання запиту створюється набір записів, що виглядає як таблиця, але він не є таблицею. Фактично запит — це уявлення користувача про потрібні дані з різних таблиць або інших запитів. У процесі відкриття запиту в режимі таблиці або використання його у формах та звітах, створюється новий набір записів з поточного змісту бази даних. Дані в запитах можна редагувати. Всі зміни фіксуються у таблицях, дані з котрих використовуються у запиті.
Запит - один з найбільш потужних об(єктів MS Access, який дозволяє ефективно представити інформацію, що містять таблиці, з певними властивостями. В деякому розумінні запит подібний до фільтрів, коли з таблиць будується виборка за певною умовою. Але на відміну від фільтру запит дозволяє отримати більш змістовний результат. Перш за все, це пояснюється тим, що фільтр дає інформацію для перегляду (друку), але, на відміну від запиту автоматично не зберігається, як окремий об(єкт бази даних. Запити, маючи таку властивість, дозволяють динамічно поновлювати інформацію у своїх таблицях, якщо у таблицях бази даних виникла зміна інформації. Крім цього, запит має і зворотню дію: якщо змінювати інформацію у його таблицях, то таблиці бази даних, на базі яких побудований запит, будуть адекватно змінювати свою інформацію.
СУБД ACCESS дозволяє створювати запити за допомогою майстрів та у режимі конструктора. У СУБД ACCESS під час виконання запиту створюється набір записів, що виглядає як таблиця, але він не є таблицею. Фактично запит — це уявлення користувача про потрібні дані з різних таблиць або інших запитів. У процесі відкриття запиту в режимі таблиці або використання його у формах та звітах, створюється новий набір записів з поточного змісту бази даних. Дані в запитах можна редагувати. Всі зміни фіксуються у таблицях, дані з котрих використовуються у запиті.
- Майстер ПРОСТОЙ ЗАПРОС на основі кількох пов'язаних таблиць або запитів дозволяє створювати запити двох типів: ПОДРОБНЫЙ та ИТОГОВЫЙ.
- Майстер ПЕРЕКРЕСТНЫЙ ЗАПРОС створює запит із статистичними розрахунками (суми, середні значення, кількість записів тощо). Такий запит дуже схожий на зведену таблицю EXCEL.
1. запит на вибірку
2. запит на модифікацію
а. запит на поновлення
б. запит на додавання
в. запит на знищення
У запиті можна створювати поля, значення яких розраховуються за допомогою заданого виразу. Під час запису виразу треба дотримуватися певних правил:
« імена таблиць, запитів, звітів, полів та елементів управління повинні братися у квадратні дужки (наприклад, [назва матеріалу]). Якщо ім'я не містить пропусків та спеціальних символів, тоді дужки є необов'язковими;
• ім'я поля відокремлюється від імені таблиці (запита) крапкою;
• текст береться у лапки (наприклад, "мідь");
;. • дата/час супроводжуються символом # (наприклад, #12.12.00#).
Приклад
Створити розрахункове поле «Нова вартість доставки», що буде більша від попередньої на 20%.
Запросы → Конструктор → (прав. кн. мишки на пустому полі) → Построить
Вводимо наступне
Нова вартість доставки:[Закази]![Вартість доставки]*1,2
Поставити галочку напроти «Вывод на экран».
СУБД ACCESS дозволяє створювати запити за допомогою майстрів та у режимі конструктора. У СУБД ACCESS під час виконання запиту створюється набір записів, що виглядає як таблиця, але він не є таблицею. Фактично запит — це уявлення користувача про потрібні дані з різних таблиць або інших запитів. У процесі відкриття запиту в режимі таблиці або використання його у формах та звітах, створюється новий набір записів з поточного змісту бази даних. Дані в запитах можна редагувати. Всі зміни фіксуються у таблицях, дані з котрих використовуються у запиті.
Запит на зміну – дозволяє створювати нові таблиці або робити зміни в існуючих таблицях (знищувати, поновлювати, додавати записи)
Щоб створити запит на модифікацію, потрібно:
1. створити запит на вибірку
2. переглянути відібрані записи
3. Запрос → Удаление (Обновление, Добавление
50. Основні принципи пошуку даних у базах даних. Пошук одного запису, кількох записів. Як відбувається пошук групи записів?
Пошук даних за допомогою команд та фільтрів
Як зазначалося раніше, будь-яка команда, що пов’язана з обробкою даних, дозволяє обмежити область даних. Це дозволяють зробити параметри «діапазон» (SCOPE), «FOR» та «WHILE», які повинні задаватися у кожній команді. У VFP існує команда, яка дозволяє задати фільтр відбирання записів:
