2. Етапи проектування бази даних

Процес проектування бази даних складається із трьох основних етапів: концептуальне, логічне й фізичне проектування.

Концептуальне проектування бази даних

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

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

Логічне проектування бази даних

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

Другий етап проектування бази даних називається логічним проектуванням бази даних. Логічне проектування полягає у визначенні числа й структури таблиць, формування запитів до БД, визначенні типів звітних документів, розробці алгоритмів обробки інформації, створенні форм для уведення й редагування даних у базі й рішенні ряду інших задач. Його ціль складається в створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена на попередньому етапі, уточнюється й перетвориться в логічну модель даних. Логічна модель даних ураховує особливості обраної моделі організації даних у цільовий СУБД (наприклад, реляційна модель). Якщо концептуальна модель даних не залежить від будь-яких фізичних аспектів реалізації, то логічна модель даних створюється на основі обраної моделі організації даних цільовий СУБД. Інакше кажучи, на цьому етапі вже повинне бути відомо, яка СУБД буде використовуватися в якості цільовій - реляційна, мережна, ієрархічна або об’ектно-орієнтована. Однак на цьому етапі ігноруються всі інші характеристики обраної СУБД, наприклад, будь-які особливості фізичної організації її структур зберігання даних і побудова індексів.

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

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

Фізичне проектування бази даних.

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

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

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

• створення набору реляціних таблиць і обмежень для них на основі інформації, представленої в глобальній логічній моделі даних;

• визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність СУБД;

• розробка засобів захисту створюваної системи.

Етапи концептуального й логічного проектування великих систем варто відокремлювати від етапів фізичного проектування. На це є кілька причин.

• Вони пов'язані із зовсім різними аспектами системи, оскільки відповідають на запитання, що робити, а не як робити.

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

• Вони вимагають зовсім різних навичок і досвіду, тому вимагають залучення фахівців різного профілю.

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

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

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

Форми використовуються для уведення даних. Сьогодні форми по більшій частині пишуться на HTML. Приміром, у формі на сайті Web-магазину користувач уводить інформацію про рахунок і доставку. Користувач заповнює форму в браузері й натискає кнопку «Підтвердити». Після цього перед ним відкривається екран з підтвердженням замовлення.

Реляційна модель

Реляційна модель - це, можливо, найпростіша й зрозуміла модель бази даних, що коли-небудь, була придумана; тому вона так приваблива. Модель цілком заснована на таблицях з рядками й стовпцями. В математиці таблиці називаються «відношеннями», звідси й термін реляційна модель (від англ. relation).

Система керування базами даних (СУБД)

Система керування реляційними базами даних (СУБД) - це програмне забезпечення, встановлене на сервері бази даних. Воно дає можливість створювати й управляти базами даних. СУБД захищає дані як від неавторизованого доступу, так і від можливості ненавмисного ушкодження при авторизованому доступі. Мова команд, використовувана для спілкування із СУБД, - це мова структурованих запитів (SQL, Structured query language).

Ця мова команд має простий синтаксис і є досить компактною. Разом з тим вона досить потужна. Більшість СУБД також дозволяють використовувати для роботи графічний інтерфейс. Графічний інтерфейс часто називають запитом за зразком (QBE, query by example), хоча запити є лише частиною можливостей, надаваних інтерфейсом. Продукти для персонального комп'ютера, такі як Microsoft Access, використовують графічний інтерфейс, як найбільш простий у використанні. Професіонали воліють використовувати SQL.

Адміністратор бази даних (DBA)

Адміністратор бази даних (DBA, database administrator) - це людина, що працює із СУБД. Адміністратор створює бази даних і управляє ними, використовуючи СУБД. Адміністратор також може надавати користувачам доступ для створення й керування своїми власними базами даних, подібну базу даних ви можете створити для свого курсу в інституті. В однокористувальницькій системі кінцевий користувач, природно, є й адміністратором.