Смекни!
smekni.com

Системи управління базами даних 2 (стр. 2 из 2)

Розглянемо ці етапи дещо детальніше.

1. Визначення мети створення бази даних. На першому ета­пі проектування бази даних необхідно визначити мету створення бази даних, основні її функції та інформацію, яку вона повинна містити. Тобто потрібно визначити основні теми таблиць бази даних та інформацію, що міститимуть поля таблиць.

База даних має відповідати вимогам тих, хто безпосередньо з нею працюватиме. Для цього потрібно визначити теми, які по­винна покривати база даних, звіти, які вона має видавати, про­аналізувати форми, що у даний момент використовуються для запису даних, порівняти створювану базу даних із добре спроек­тованою, подібною їй базою.

2.Визначення таблиць, які повинні містити база даних.

Одним із найскладніших етапів у процесі проектування бази да­них є розробка таблиць, тому що результати, які повинна видава­ти база даних (звіти, вихідні форми тощо), не завжди дають по­вне уявлення про структуру таблиці. У разі проектування таблиць зовсім не обов'язково використовувати СУБД. Спочатку краще розробити структуру на папері. Отже, у разі проектування таб­лиць слід керуватися такими основними принципами:

—інформація в таблиці не повинна дублюватися. Не повинно бути повторень і між таблицями. Коли певна інформація зберіга­ється лише в одній таблиці, то і змінювати її доведеться лише в одному місці. Це робить роботу ефективнішою, а також виклю­чає можливість розбіжності інформації в різних таблицях. На­приклад, в одній таблиці мають міститися адреси й телефони клі­єнтів;

кожна таблиця повинна містити інформацію лише на однутему. Дані на кожну тему опрацьовуються набагато легше, якщо вони утримуються в незалежних одна від іншої таблицях. Наприклад, адреси та замовлення клієнтів зберігаються в різних табли­цях, щоб у разі вилучення замовлення інформація про клієнта за­лишилася в базі даних.

3. Визначення необхідних у таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці міс­тить окремі дані по темі таблиці. Наприклад, у таблиці з даними про клієнта можуть бути поля з назвою компанії, адресою, міс­том, країною і номером телефону. Під час розробки полів для кожної таблиці необхідно пам'ятати:

—кожне поле має бути пов'язане з темою таблиці;

—не рекомендується включати до таблиці дані, що є резуль­татом виразу;

—у таблиці має бути вся необхідна інформація;

—інформацію варто розбивати на найменші логічні одиниці (наприклад, поля «Ім'я» і «Прізвище», а не загальне поле «Ім'я»).

4. Задання індивідуального значення кожному полю. З тим, щоб СУБД могла зв'язати дані з різних таблиць, наприклад дані про клієнта і його замовлення, кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають

основним ключем.

5. Визначення зв'язків між таблицями. Після розподілу да­них по таблицях і визначення ключових полів необхідно вибрати схему для зв'язку даних у різних таблицях. Для цього потрібно визначити зв'язки між таблицями. Бажано вивчати зв'язки між таблицями в уже існуючій базі даних. Для перегляду зв'язків у вибраній базі даних відкриваємо її і вибираємо відповідні команди.

6. Відновлення структури бази даних.

Після проектування таблиць, полів і зв'язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки. Бажано це зробити на даному етапі, поки таблиці не заповнені даними. Для перевірки необхідно створити кілька таблиць, ви­значити зв'язки між ними та ввести кілька записів у кожну таб­лицю, потім подивитися, чи відповідає база даних поставленим вимогам. Рекомендується також створити чернеткові вихідні фо­рми та звіти й перевірити, чи видають вони необхідну інформа­цію. Крім того, необхідно виключити з таблиць усі можливі по­вторення даних.

7. Додавання даних і створення інших об'єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запи­ти, форми, звіти, макроси та модулі.

8. Використання засобів аналізу в СУБД. Наприклад, у СУБД MicrosoftAccessє два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таб­лицю, в разі потреби пропонує нову її структуру та зв'язки, а та­кож переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.

Варіант 2. Розробка проекту бази даних

1. Розробка логічної моделі даних. Логічні моделі ви­користовуються розробниками баз даних для формального пред­ставлення інформаційних потреб виробництва, економіки, бізне­су тощо. Найрозповсюдженішою формою відображення цієї мо­делі слугують ER-діаграми. Основними поняттями ER-моделі є сутність, зв'язок та атрибут. Кожна з частин такої діаграми по­відомляє дещо про структуру даних або про те, як ці дані спів­відносяться з іншими.

Як правило, розробка логічної моделі являє собою ітераційний процес, що складається з фаз аналізу, проектування та оцінюван­ня. При цьому на кожній ітерації додаються нові правила. Добрі засоби проектування баз даних мають бути гнучкими, а організа­ція роботи з ними — ефективною. ER-діаграми повинні допов­нюватися детальнішою інформацією про бізнес, правила та об­меження посилання на цілісність, а також давати змогу керувати наочним поданням деталей моделі.

Під час створення логічної моделі потрібно насамперед прове­сти важливу роботу з замовником. Найбільший обсяг робіт з ба­зами даних пов'язаний із запитами. Тож потрібно якнайдокладніше дізнатися від замовника про можливі запити до бази даних. Досвід проектування свідчить про те, що замовники часто не уявляють, які можливості даватиме їм база даних, до вирішення яких нових задач вони зможуть долучитися. Через це під час про­ектування потрібно якнайраніше показати замовникам їхні мож­ливі горизонти, щоб так само якнайраніше довелося б вносити зміни до логічної моделі.

2.Підготовка звіту про логічну модель. Для відстежування процесу проектування логічної моделі використовуються звіти.

3. Вони корисні також для узгодження вимог із замовниками. У зві­тах, як правило, перераховуються сутності, їх атрибути, правила та обмеження, що вміщують до бази даних. Добрі засоби підго­товки звітів містять різні види інформації про логічну модель, сприяють гнучкому розміщенню та форматуванню, а також по­данню звіту у файл або його експорту в інші додатки. При узго­дженні вимог із замовниками варто результат оформляти окре­мим протоколом.

3.Перетворення логічної моделі у фізичну. У процесі роз­робки фізичної моделі сутності, атрибути та зв'язки складають фізичну модель, відображаються у таблиці та стовпчиках. До ра­ніш заданих властивостей стовпчиків (типів даних, протяжностей і невизначених значень) додаються нові — первинні та зовнішні ключі, індекси, перевірочні обмеження та правила підтримки по­силкової цілісності. Щоб правильно і добре виконати цей етап проектування, засоби моделювання даних повинні працювати з кількома популярними СУБД SQL-типу, графічно відображати фізичні характеристики, дозволяти призначати та модифікувати триггери1 за замовчування, створювати власні триггери, денормалізувати фізичну модель, не торкаючись при цьому логічної.

4.Підготовка звіту про фізичну модель. Як правило, для то­го, щоб переглянути якусь таблицю або всі таблиці одночасно, разом з деталями (стовпчики, їх характеристики, індекси, зовні­шні ключі та триггери) застосовують звіт про фізичну модель. Добрі засоби підготовки таких звітів прості в користуванні, ма­ють гнучкий інтерфейс для задання елементів, що включають­ся до звіту, організації звіту та його формування. Вони повин­ні надавати детальну інформацію про реалізацію обмежень, пра­вил посилкової цілісності, включаючи призначення та зміст триг-герів.

Генерація схеми бази даних. Схема описує реалізацію бази даних з урахуванням специфіки конкретної СУБД. Схема може створюватися або мовою визначення даних (файли DDL), або при прямому зверненні до СУБД. Програмні продукти, які добре під­тримують генерацію схеми, дають засоби контролю за генерую­чими елементами схеми, що дає змогу зробити цей процес ітера­тивним. Варто шукати інструменти, які підключаються до нашої цільової СУБД і дають можливість переключатися між різними СУБД, мінімізуючи при цьому ручне редагування.

6.Супроводження розроблюваної моделі даних. Більшість баз даних протягом свого життєвого циклу еволюціонує. Для того, щоб спростити цей процес, рекомендується синхронно змінювати модель та базу даних. Варто звертати увагу на засоби синхроніза­ції, утиліти керування версіями та захисту. За допомогою найзруч­ніших у роботі інструментів можна переносити зміни в обидва бо­ки: з моделі в схему, і навпаки. Якщо раніше замовник після здачі СУБД в експлуатацію відмовлявся від супроводження, то тепер, як правило, проектувальники супроводжують експлуатацію СУБД. Це накладає на них додаткову відповідальність за якість проекту­вання, бо всі негаразди доводиться ліквідовувати їм самим.

7.Звернене проектування, що виходить з існуючої бази да­них. Відтворення схеми існуючої бази даних служить кільком ці­лям. Воно дає змогу побудувати модель цієї бази даних, перенес­ти існуючу базу даних з однієї СУБД на іншу, а також досить просто модифікувати схему бази даних, що функціонує. Ключо­ вими параметрами для виконання такого завдання є точність та гнучкість. Ми повинні мати можливість задати елементи схеми, з якими працюватиме програма, й очікується, що внаслідок гене­рації схеми бази даних за відновленою моделлю має з'явитися тотожна копія початкової схеми.

Як бачимо, другий варіант окреслює загальніший підхід до проектування баз даних та враховує відносини з замовником про­екту.