Головна

Проектування бази даних

  1.  A) Перший ряд бази даних містить неповторювані імена полів.
  2.  I. Комп'ютерна симуляція експериментальних даних
  3.  I. Статистична обробка даних вимірювання росту
  4.  I. Статистична обробка даних вимірювання росту.
  5.  I. Файлові структури, використовувані для зберігання даних в БД
  6.  Ii. Моделі сторінкової організації даних в сучасних БД
  7.  II. Провести статистичний аналіз для наступних сукупностей даних

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

Розробка технічного завдання.Технічне завдання на проектування бази даних повинен надати замовник. Однак для цього він повинен володіти відповідною термінологією і знати, хоча б у загальних рисах, технічні можливості основних систем управління базами даних. На жаль, на практиці такий стан зустрічається не завжди. Тому зазвичай використовують такі підходи:

• демонструють замовнику роботу аналогічної бази даних, після чого погоджують

специфікацію відмінностей;

• якщо аналога немає, з'ясовують коло завдань і потреб замовника, після чого допомагають йому

підготувати технічне завдання.

При підготовці технічного завдання складають:

• список вихідних даних, з якими працює замовник;

в список вихідних даних, які необхідні замовнику для управління структурою свого

підприємства;

• список вихідних даних, які не є необхідними для замовника, але які він

повинен надавати в інші організації (до вищих структур, до органів статистичного

обліку, інші адміністративні та контролюючі організації).

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

Розробка структури бази даних.З'ясувавши основну частину даних, які замовник споживає або поставляє, можна приступати до створення структури бази, тобто структури її основних таблиць.

1. Робота починається зі складання генерального списку полів - він може налічувати десятки і

навіть сотні позицій.

2. Відповідно до типу даних, що розміщуються в кожному полі, визначають найбільш

відповідний тип для кожного поля.

3. Далі розподіляють поля генерального списку по базових таблиць. На першому етапі

розподіл виробляють за функціональною ознакою. Мета - забезпечити, щоб введення даних в одну таблицю вироблявся, по можливості, в рамках одного підрозділу, а ще краще - на одному робочому місці.

Наметове стільки таблиць, скільки підрозділів охоплює база даних, приступають до

подальшого поділу таблиць. Критерієм необхідності ділення є факт множинного

повтору даних в сусідніх записах. На рис. 13.7 показана таблиця, у якій в поле Адреса

спостерігається повтор даних. Це явне свідчення того, що таблицю треба поділити на дві

взаємопов'язані таблиці.

Мал. 13.7. Якщо дані в полі починають повторюватися

, Це ознака того, що таблицю варто поділити

4.. У кожній з таблиць намічають ключове поле. У цій іпостасі вибирають поле, дані в

якому повторюватися не можуть. Наприклад, для таблиці даних про студентів таким полем може

служити індивідуальний шифр студента. Для таблиці, в якій містяться розкладу занять,

такого поля можна і не знайти, але його можна створити штучним комбінуванням полів

«Час заняття» і «Номер аудиторії». Ця комбінація неповторна, так як в одній аудиторії в

один і той же час не прийнято проводити два різних заняття.

Якщо в таблиці взагалі немає ніяких полів, які можна було б використовувати як ключові,

завжди можна ввести додаткове поле типу Лічильник - воно не може містити

повторюваних даних за визначенням.

5. За допомогою олівця і паперу розкреслюють зв'язку між таблицями. На рис. 13.8 показаний

приклад взаємозв'язку між групою таблиць, складових одну базу даних. такий креслення

називається схемою даних.

Існує кілька типів можливих зв'язків між таблицями. найбільш поширеними

є зв'язку «один до багатьох» і «один до одного». Зв'язок між таблицями організовується на

основі загального поля, причому в одній з таблиць воно обов'язково повинно бути ключовим, тобто на

стороні «один»

Мал. 13.8. Схема зв'язків між таблицями

має виступати ключове поле, що містить унікальні, неповторювані значення. значення

на стороні «багато» можуть повторюватися.

Розглянемо таблицю Клієнти (рис. 13.8). Тут поле Код клієнта є ключовим. це

зрозуміло, оскільки у кожного клієнта повинен бути свій унікальний код, що ідентифікує його

однозначно. Якщо ми розглянемо таблицю Замовлення, то побачимо, що в ній код клієнта не може бути

унікальним, оскільки кожен клієнт міг зробити як завгодно багато замовлень. На схемі даних

ці поля з'єднані лінією зв'язку. З одного боку ця лінія маркована знаком «1», з іншого

боку - значком «нескінченність». Це графічний метод зображення зв'язку «один до

багатьом ».

Ключовим полем в таблиці замовлень є Код замовлення - він однозначно ідентифікує, хто,

коли, що замовив і на яку суму. Тут же можна дізнатися, який співробітник прийняв замовлення до

виконанню. Оскільки один співробітник може прийняти безліч замовлень, поле Код співробітника в

таблиці замовлень не є ні унікальним, ні ключовим, зате в таблиці Співробітники це поле

унікально.

Про подібні таблиці говорять, що вони пов'язані реляційними відносинами. відповідно,

системи управління, здатні працювати зі зв'язаними таблицями, називають системами

керування базами даних, а схему даних в технічній літературі можуть

називати схемою реляційних відносин.

6. Розробкою схеми даних закінчується «паперовий» етап роботи над технічним

пропозицією. Цю схему можна узгодити з замовником, після чого приступати до

безпосереднього створення бази даних.

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

Протиріччя виконавця з замовником завжди свідчать про недостатню кваліфікацію виконавця. Саме тому етап попереднього проектування бази даних слід вважати основним. Від його успіху залежить, наскільки база даних стане зручною і чи будуть з нею працювати користувачі. Якщо відзначається, що користувачі бази «саботують» її експлуатацію і вважають за краще працювати традиційними методами, це говорить не про низьку кваліфікацію користувачів, а про недостатню кваліфікацію розробника бази.

На цьому етапі завершується попереднє проектування бази даних, і на наступному етапі починається її безпосередня розробка. З цього моменту слід почати роботу з системою управління базами даних. У нашому прикладі ми розглянемо СУБД Microsoft Access 2000.




 Вправа 12.5. Аналіз даних з використанням методу найменших квадратів |  Вправа 12.6. Застосування таблиць підстановки |  Вправа 12.7. Рішення рівнянь засобами програми Excel |  Вправа 12.8. Рішення задач оптимізації |  Бази даних та системи управління базами даних |  Структура найпростішої бази даних |  Властивості полів бази даних |  типи даних |  Безпека баз даних |  Режими роботи з базами даних |

© um.co.ua - учбові матеріали та реферати