— кожна таблиця повинна містити інформацію лише на одну тему. Дані на кожну тему опрацьовуються набагато легше, якщо вони утримуються в незалежних одна від іншої таблицях. Наприклад, адреси та замовлення клієнтів зберігаються в різних таблицях, щоб у разі вилучення замовлення інформація про клієнта залишилася в базі даних.
3. Визначення необхідних у таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці містить окремі дані по темі таблиці. Наприклад, у таблиці з даними про клієнта можуть бути поля з назвою компанії, адресою, містом, країною і номером телефону. Під час розробки полів для кожної таблиці необхідно пам’ятати:
— кожне поле має бути пов’язане з темою таблиці;
— не рекомендується включати до таблиці дані, що є результатом виразу;
— у таблиці має бути вся необхідна інформація;
— інформацію варто розбивати на найменші логічні одиниці (наприклад, поля «Ім’я» і «Прізвище», а не загальне поле «Ім’я»).
4. Задання індивідуального значення кожному полю. З тим, щоб СУБД могла зв’язати дані з різних таблиць, наприклад дані про клієнта і його замовлення, кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.
5. Визначення зв’язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв’язку даних у різних таблицях. Для цього потрібно визначити зв’язки між таблицями. Бажано вивчати зв’язки між таблицями в уже існуючій базі даних. Для перегляду зв’язків у вибраній базі даних відкриваємо її і вибираємо відповідні команди.
6. Відновлення структури бази даних.
Після проектування таблиць, полів і зв’язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки. Бажано це зробити на даному етапі, поки таблиці не заповнені даними. Для перевірки необхідно створити кілька таблиць, визначити зв’язки між ними та ввести кілька записів у кожну таблицю, потім подивитися, чи відповідає база даних поставленим вимогам. Рекомендується також створити чернеткові вихідні форми та звіти й перевірити, чи видають вони необхідну інформацію. Крім того, необхідно виключити з таблиць усі можливі повторення даних.
7. Додавання даних і створення інших об’єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.
8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft Access є два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв’язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.
Варіант 2. Розробка проекту бази даних
1. Розробка логічної моделі даних. Логічні моделі використовуються розробниками баз даних для формального представлення інформаційних потреб виробництва, економіки, бізнесу тощо. Найрозповсюдженішою формою відображення цієї моделі слугують ER-діаграми . Основними поняттями ER-моделі є сутність, зв’язок та атрибут. Кожна з частин такої діаграми повідомляє дещо про структуру даних або про те, як ці дані співвідносяться з іншими.
Як правило, розробка логічної моделі являє собою ітераційний процес, що складається з фаз аналізу, проектування та оцінювання. При цьому на кожній ітерації додаються нові правила. Добрі засоби проектування баз даних мають бути гнучкими, а організація роботи з ними — ефективною. ER-діаграми повинні доповнюватися детальнішою інформацією про бізнес, правила та обмеження посилання на цілісність, а також давати змогу керувати наочним поданням деталей моделі.
Під час створення логічної моделі потрібно насамперед провести важливу роботу з замовником. Найбільший обсяг робіт з базами даних пов’язаний із запитами. Тож потрібно якнайдокладніше дізнатися від замовника про можливі запити до бази даних. Досвід проектування свідчить про те, що замовники часто не уявляють, які можливості даватиме їм база даних, до вирішення яких нових задач вони зможуть долучитися. Через це під час проектування потрібно якнайраніше показати замовникам їхні можливі горизонти, щоб так само якнайраніше довелося б вносити зміни до логічної моделі.
2. Підготовка звіту про логічну модель. Для відстежування процесу проектування логічної моделі використовуються звіти.
Вони корисні також для узгодження вимог із замовниками. У звітах, як правило, перераховуються сутності, їх атрибути, правила та обмеження, що вміщують до бази даних. Добрі засоби підготовки звітів містять різні види інформації про логічну модель, сприяють гнучкому розміщенню та форматуванню, а також поданню звіту у файл або його експорту в інші додатки. При узгодженні вимог із замовниками варто результат оформляти окремим протоколом.
3. Перетворення логічної моделі у фізичну. У процесі розробки фізичної моделі сутності, атрибути та зв’язки складають фізичну модель, відображаються у таблиці та стовпчиках. До раніш заданих властивостей стовпчиків (типів даних, протяжностей і невизначених значень) додаються нові — первинні та зовнішні ключі, індекси, перевірочні обмеження та правила підтримки посилкової цілісності. Щоб правильно і добре виконати цей етап проектування, засоби моделювання даних повинні працювати з кількома популярними СУБД SQL-типу, графічно відображати фізичні характеристики, дозволяти призначати та модифікувати триггери за замовчування, створювати власні триггери, денормалізувати фізичну модель, не торкаючись при цьому логічної.
4. Підготовка звіту про фізичну модель. Як правило, для того, щоб переглянути якусь таблицю або всі таблиці одночасно, разом з деталями (стовпчики, їх характеристики, індекси, зовнішні ключі та триггери) застосовують звіт про фізичну модель. Добрі засоби підготовки таких звітів прості в користуванні, мають гнучкий інтерфейс для задання елементів, що включають-
ся до звіту, організації звіту та його формування. Вони повин-
ні надавати детальну інформацію про реалізацію обмежень, правил посилкової цілісності, включаючи призначення та зміст триггерів.
5. Генерація схеми бази даних. Схема описує реалізацію бази даних з урахуванням специфіки конкретної СУБД. Схема може створюватися або мовою визначення даних (файли DDL), або при прямому зверненні до СУБД. Програмні продукти, які добре підтримують генерацію схеми, дають засоби контролю за генеруючими елементами схеми, що дає змогу зробити цей процес ітеративним. Варто шукати інструменти, які підключаються до нашої цільової СУБД і дають можливість переключатися між різними СУБД, мінімізуючи при цьому ручне редагування.
6. Супроводження розроблюваної моделі даних. Більшість баз даних протягом свого життєвого циклу еволюціонує. Для того, щоб спростити цей процес, рекомендується синхронно змінювати модель та базу даних. Варто звертати увагу на засоби синхронізації, утиліти керування версіями та захисту. За допомогою найзручніших у роботі інструментів можна переносити зміни в обидва боки: з моделі в схему, і навпаки. Якщо раніше замовник після здачі СУБД в експлуатацію відмовлявся від супроводження, то тепер, як правило, проектувальники супроводжують експлуатацію СУБД. Це накладає на них додаткову відповідальність за якість проектування, бо всі негаразди доводиться ліквідовувати їм самим.
7. Звернене проектування, що виходить з існуючої бази даних. Відтворення схеми існуючої бази даних служить кільком цілям. Воно дає змогу побудувати модель цієї бази даних, перенести існуючу базу даних з однієї СУБД на іншу, а також досить просто модифікувати схему бази даних, що функціонує. Ключовими параметрами для виконання такого завдання є точність та гнучкість. Ми повинні мати можливість задати елементи схеми, з якими працюватиме програма, й очікується, що внаслідок генерації схеми бази даних за відновленою моделлю має з’явитися тотожна копія початкової схеми.
Як бачимо, другий варіант окреслює загальніший підхід до проектування баз даних та враховує відносини з замовником проекту. Розглянемо етапи проектування бази даних на основі засобів СУБД MS Access 97, але перед цим дамо характеристики цій реляційній СУБД.
44. Поняття про бази даних. Різновидності баз даних. Проектування баз даних (етапи створення баз даних). Задачі, що розв’язуються за допомогою СУБД ACCESS 2000.
База даних — це інтегроване сховище взаємопов'язаних даних конкретної предметної області.
Система управління базами даних (СУБД) — це комплекс програмних засобів, призначений для інтегрованого зберігання та обробки даних.
Етапи створення бази даних у середовищі Microsoft Access:
• визначення мети створення бази даних;
• визначення таблиць, які повинна містити база даних;
• визначення структури таблиць (полів та їх типів);
• призначення ключів таблиць та створення потрібних індексів;
• визначення зв'язків між таблицями;
• завантаження даних;
• створення інших об'єктів бази даних: запитів, форм, звітів, макросів та модулів;
« аналіз ефективності бази даних за допомогою майстра таблиць (меню СЕРВИОАНАЛИЗ>ТАБЛИЦА) та аналізатора швидкодії (меню СЕРВИОАНАЛИЗ>БЬІСТРОДЕЙСТВИЕ).
База даних – це сукупність даних, яким властива структурованість і взаємопов’язаність, а також належність від прикладних програм.
Принципи та етапи проектування
бази даних
Проектування бази даних відбувається на основі концептуальних вимог її кінцевих користувачів. Під час проектування бази даних враховується таке:
• база даних повинна задовольняти актуальним інформаційним потребам;
• дані перед включенням до бази даних повинні перевірятися на достовірність;
• доступ до даних повинні мати тільки особи з відповідними повноваженнями;
• база даних повинна легко розширятися під час реорганізації та збільшення обсягів предметної області.
Етапи проектування бази даних:
1. Визначення мети створення бази даних.
2. Проектування концептуальної моделі бази даних.
3. Проектування зовнішніх моделей даних.
4. Проектування внутрішньої моделі даних.
5. Оцінка внутрішньої моделі даних.
6. Реалізація бази даних.
7. Аналіз ефективності бази даних.
45. Поняття о таблицях, полях, записах, ключах, відношеннях та індексах в ACCESS 2000. Робота з базою даних: сортування, індексування, фільтрація та пошук даних у ACCESS 2000.
Таблиці і поля
Таблиця — об’єкт СУБД, де зберігається інформація. Здебільшого складається з рядків (записів) та стовпчиків (полів).
Имя поля — це ім’я, що присвоюється даному полю
Типи полів
Текстовый (Text)
MEМO (Memo
Числовой (Number)
Дата/Время
Денежный
Счетчик
Логический (Yes/No)
OLE Object
Гиперссылка
Мастер подстановок
Основний структурний елемент Access — таблиця, в якій зберігається інформація. Об’єкт «таблиця» — це лише одна частина Access-системи, в якій справді зберігається інформація. Всі інші об’єкти (такі, як запити, форми та звіти) ґрунтуються на даних таблиць.
Для більшості користувачів операції, що виконуються в ба-
зі даних, починаються зі створення однієї чи більше таблиць.
І хоча, з одного боку, таблиця — це колекція даних, з іншого — це дещо більше, ніж просто набір даних. Яка ж відмінність таблиці від сторінки тексту або чисел у структурі електронної таблиці? Структура перетворює дані в інформацію. Структуровану інформацію, організовану в таблицю, легше зрозуміти і читати.
По-перше, за рахунок класифікації по стовпчиках. Кожен стовпчик таблиці являє собою результат певної класифікації.
По-друге, тому, що рядки повторюють шаблон. Шаблон, установлений за допомогою стовпчиків, повторюється в кожному
рядку. Кожний рядок подає інформацію про певний існуючий об’єкт, наприклад, про легковий автомобіль, заводи-виготовлю-вачі або роки випуску.
Ці два чинники дозволяють легко читати інформацію таблиці, оскільки кожен рядок у таблиці передбачений.
Ця передбачена структура дає можливість комп’ютерній програмі виконати аналогічні операції набагато швидше і з вищою точністю, ніж це може зробити людина.
Стовпчики і рядки, поля та записи
Запис — скінченна сукупність даних, яка несе певний обсяг інформації про описуваний об’єкт.
Усі бази даних мають двовимірну структуру. Якщо структуру розуміти як таблицю, то, природно, використовуються терміни стовпчик і рядок. Загалом, поле є синонімом стовпчика, а запис — синонімом рядка.
Терміни рядок і стовпчик застосовуються, коли йдеться про фізичну структуру таблиці, що містить інформацію. Поле та запис слугують для вираження логічного зв’язку елементів даних, оскільки поля й записи не завжди постають у формі рядків і стовпчиків. Наприклад, усі поля форми належать одному запису, навіть коли у формі відсутні фізично рядок і стовпчик.
Поля визначають класифікаційну характеристику даних, за якою можна знайти кожен запис, такий, наприклад, як прізвище чи дата народження. Коли працюємо з полем, то можна маніпулювати даними, що належать одному чи кільком записам. Наприклад, за потреби відсортувати інформацію вибираємо одне або більше полів у ролі ключів сортування.
Запис містить інформацію про окрему особу, місце чи предмет.
Терміни рядок, стовпчик, поле та запис використовуються в різних частинах системи Access.
46. Основні об"єкти баз даних в ACCESS 2000 та робота з ними.
Усі дані бази даних зберігаються у таблицях. Таблиці створюються в два етапи. На першому етапі
створюється структура таблиці, а на другому — вводяться дані.
Створення таблиці. Вибрати вкладнику Таблицы, натиснути на кнопку Создать (рис. 10.114) та вибрати метод створення таблиці (рис. 10.116). Вважаючи, що структура таблиці, яка створена за допомогою майстра або в режимі таблиці, все одно підлягає редагуванню, розглянемо створення таблиці у режимі конструктора. Для цього треба у списку вибрати КОНСТРУКТОР і натиснути на кнопку Ok.
На екрані з'явиться вікно (рис. 10.117). У графу Имя поля треба ввести ім'я першого поля таблиці. Ім'я поля не повинно містити більше 64-х символів, включаючи пропуски, та не повинно містити символ «.».
У графі Тип данных треба задати тип поля. Для цього необхідно розкрити список (рис. 10.118) та вибрати потрібний тип даних. В Access застосовуються такі типи даних:
• Числовой (NUMBER) — застосовується для числових даних, які використовуються у формулах. Тип та розмір значень задаються у властивостях РАЗМЕР ПОЛЯ та ФОРМАТ ПОЛЯ;
• Текстовый (TEXT) — застосовується для тексту та чисел (наприклад, табельний номер), які не використовуються у формулах. Поле цього типу може містити до 255 символів, за замовчанням — 50. Для визначення розміру поля треба задати властивість Размер поля;
• Поле MEMO — використовується для уведення текстів або чисел довжиною до 64000 символів;
• Дата/время (DATE/TIME) — довжина поля 8 байтів;
• Денежный — використовується для попередження округлення під час обчислень. Розмір поля — 8 байтів;
• Счетчик (AUTONUMBER) — використовується для автоматичного додавання номера запису. Якщо властивість поля Новые значения має значення: Последовательные — виконується додавання числа, яке отримується збільшенням на одиницю номера попереднього запису; Случайные — для лічильника генерується випадкове число. Розмір поля — 4 байти;
• Логический (YES/NO) — застосовується до полів, що можуть містити тільки одне з двох значень, такі як ДА/НЕТ, Исти-на/Ложь, ВКЛ/ВЫКЛ. Розмір поля — 1 біт;
• Поле объекта OLE (OLE OBJECT) — використовується для зв'язування або впровадження об'єктів (документів MICROSOFT WORD, електронних таблиць (MICROSOFT EXCEL), рисунків, звуків тощо). Для зображення об'єктів у формах та звітах необхідно застосовувати елемент управління Присоединенная рамка объекта. Розмір поля — до 1 гігабайта;
Основні складові
Система управління базами даних Microsoft Access відноситься до реляційних баз даних. На відміну від СУБД Visual FoxPro база даних Access (фізична структура) міститься в одному файлі з розширенням MDB. Логічна структура СУБД Access складається з таких об’єктів: таблиць, запитів, форм, звітів, макросів та модулів. Доступ до цих об’єктів відбувається за допомогою відповідних вкладинок вікна Access — див. рис. 10.115.
Таблиці, запити, форми та звіти мають таке саме призначення, як і в СУБД Visual FoxPro (див. розд. 10.2.3, 10.2.10, 10.2.11, 10.2.13).
Макроси призначені для автоматизації задач та погодження роботи різних об’єктів. Макрос являє собою список команд, які повинні бути виконані Microsoft ACCESS без участі користувача. Макроси можна використовувати у формах, звітах, елементах управління, командах меню.
Модулі призначені для створення процедур та функцій мовою Access Basic.
Етапи створення бази даних у середовищі Microsoft Access:
• визначення мети створення бази даних;
• визначення таблиць, які повинна містити база даних;
• визначення структури таблиць (полів та їх типів);
• призначення ключів таблиць та створення потрібних індексів;
• визначення зв’язків між таблицями;
• завантаження даних;
• створення інших об’єктів бази даних: запитів, форм, звітів, макросів та модулів;
• аналіз ефективності бази даних за допомогою майстра таблиць (меню СЕРВИС>АНАЛИЗ>ТАБЛИЦА) та аналізатора швидкодії (меню СЕРВИС>АНАЛИЗ>БЫСТРОДЕЙСТВИЕ).
Завантаження MS Access можна виконати за допомогою меню ПУСК>ПРОГРАММЫ>MICROSOFT ACCESS або натиснути на кнопку в панелі Microsoft Office. На екрані з’явиться вікно (рис. 10.114), в якому треба задати потрібну операцію — створити або відкрити існуючу базу даних. Далі на екрані з’явиться вікно Microsoft Access
Рядок меню містить усі команди, які використовуються під час роботи з Access.
Панелі інструментів одразу після запуску за замовчанням містять лише панель інструментів БАЗА ДАНИХ. Додаткові панелі інструментів такі, як для роботи з таблицями, формами, звітами тощо виводяться у відповідному режимі роботи та можуть додаватися за допомогою меню ВИД>ПАНЕЛИ ИНСТРУМЕНТОВ.
Створення бази даних виконується за допомогою меню ФАЙЛ>СОЗДАТЬ БАЗУ ДАННЫХ > або відповідної піктограми на панелі інструментів.
Відкриття бази даних виконується за допомогою меню ФАЙЛ> ОТКРЫТЬ БАЗУ ДАННЫХ > або відповідної піктограми на панелі інструментів. Далі треба вибрати потрібний файл типу MDB. Відкриття бази даних автоматично закриває попередньо відкриту БД.
Закриття бази даних відбувається за допомогою меню ФАЙЛ> ЗАКРЫТЬ.
47. Проектування та створення структури бази даних у ACCESS 2000, правила запису найменувань полів та визначень полів в ACCESS 2000. Типи даних СУБД ACCESS 2000. Редагування структури бази даних у ACCESS 2000.
Проектування бази даних
Перед тим як створювати таблиці, форми та інші об’єкти, потрібно задати структуру бази даних. Добра структура бази даних є основою для створення адекватної вимогам, ефективної бази даних. Сам процес проектування бази даних являє собою складний процес проектування відображення опису предметної області у схему внутрішньої моделі даних. Перебіг цього процесу є послідовністю більш простих процесів проектування менш складних відображень. Ця послідовність у процесі проектування весь час уточнюється, вдосконалюється таким чином, щоб були визначені об’єкти, їх властивості та зв’язки, які будуть потрібні майбутнім користувачам системи.
