Реферат - Системи управління базами даних (СУБД)
11

Задання індивідуального значення кожному полю. З тим, щоб СУБД могла зв'язати дані з різних таблиць, наприклад дані про клієнта і його замовлення, кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають
основним ключем.
5. Визначення зв'язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв'язку даних у різних таблицях. Для цього потрібно визначити зв'язки між таблицями. Бажано вивчати зв'язки між таблицями в уже існуючій базі даних. Для перегляду зв'язків у вибраній базі даних відкриваємо її і вибираємо відповідні команди.
6. Відновлення структури бази даних.
Після проектування таблиць, полів і зв'язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки. Бажано це зробити на даному етапі, поки таблиці не заповнені даними. Для перевірки необхідно створити кілька таблиць, визначити зв'язки між ними та ввести кілька записів у кожну таблицю, потім подивитися, чи відповідає база даних поставленим вимогам. Рекомендується також створити чернеткові вихідні форми та звіти й перевірити, чи видають вони необхідну інформацію. Крім того, необхідно виключити з таблиць усі можливі повторення даних.
7. Додавання даних і створення інших об'єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.
8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft Access є два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв'язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.
Варіант 2. Розробка проекту бази даних
1. Розробка логічної моделі даних. Логічні моделі використовуються розробниками баз даних для формального представлення інформаційних потреб виробництва, економіки, бізнесу тощо. Найрозповсюдженішою формою відображення цієї моделі слугують ER-діаграми. Основними поняттями ER-моделі є сутність, зв'язок та атрибут. Кожна з частин такої діаграми повідомляє дещо про структуру даних або про те, як ці дані співвідносяться з іншими.
Як правило, розробка логічної моделі являє собою ітераційний процес, що складається з фаз аналізу, проектування та оцінювання. При цьому на кожній ітерації додаються нові правила. Добрі засоби проектування баз даних мають бути гнучкими, а організація роботи з ними — ефективною. ER-діаграми повинні доповнюватися детальнішою інформацією про бізнес, правила та обмеження посилання на цілісність, а також давати змогу керувати наочним поданням деталей моделі.
Під час створення логічної моделі потрібно насамперед провести важливу роботу з замовником. Найбільший обсяг робіт з базами даних пов'язаний із запитами. Тож потрібно якнайдокладніше дізнатися від замовника про можливі запити до бази даних. Досвід проектування свідчить про те, що замовники часто не уявляють, які можливості даватиме їм база даних, до вирішення яких нових задач вони зможуть долучитися. Через це під час проектування потрібно якнайраніше показати замовникам їхні можливі горизонти, щоб так само якнайраніше довелося б вносити зміни до логічної моделі.
2. Підготовка звіту про логічну модель. Для відстежування процесу проектування логічної моделі використовуються звіти.
3. Вони корисні також для узгодження вимог із замовниками. У звітах, як правило, перераховуються сутності, їх атрибути, правила та обмеження, що вміщують до бази даних. Добрі засоби підготовки звітів містять різні види інформації про логічну модель, сприяють гнучкому розміщенню та форматуванню, а також поданню звіту у файл або його експорту в інші додатки. При узгодженні вимог із замовниками варто результат оформляти окремим протоколом.
Перетворення логічної моделі у фізичну. У процесі розробки фізичної моделі сутності, атрибути та зв'язки складають фізичну модель, відображаються у таблиці та стовпчиках. До раніш заданих властивостей стовпчиків (типів даних, протяжностей і невизначених значень) додаються нові — первинні та зовнішні ключі, індекси, перевірочні обмеження та правила підтримки посилкової цілісності. Щоб правильно і добре виконати цей етап проектування, засоби моделювання даних повинні працювати з кількома популярними СУБД SQL-типу, графічно відображати фізичні характеристики, дозволяти призначати та модифікувати триггери1 за замовчування, створювати власні триггери, денормалізувати фізичну модель, не торкаючись при цьому логічної.
Підготовка звіту про фізичну модель. Як правило, для того, щоб переглянути якусь таблицю або всі таблиці одночасно, разом з деталями (стовпчики, їх характеристики, індекси, зовнішні ключі та триггери) застосовують звіт про фізичну модель. Добрі засоби підготовки таких звітів прості в користуванні, мають гнучкий інтерфейс для задання елементів, що включаються до звіту, організації звіту та його формування. Вони повинні надавати детальну інформацію про реалізацію обмежень, правил посилкової цілісності, включаючи призначення та зміст триг-герів.
Генерація схеми бази даних. Схема описує реалізацію бази даних з урахуванням специфіки конкретної СУБД. Схема може створюватися або мовою визначення даних (файли DDL), або при прямому зверненні до СУБД. Програмні продукти, які добре підтримують генерацію схеми, дають засоби контролю за генеруючими елементами схеми, що дає змогу зробити цей процес ітеративним. Варто шукати інструменти, які підключаються до нашої цільової СУБД і дають можливість переключатися між різними СУБД, мінімізуючи при цьому ручне редагування.
Супроводження розроблюваної моделі даних. Більшість баз даних протягом свого життєвого циклу еволюціонує. Для того, щоб спростити цей процес, рекомендується синхронно змінювати модель та базу даних. Варто звертати увагу на засоби синхронізації, утиліти керування версіями та захисту.

---

Сторінки: 1 2 3 4