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

5.1. Життєвий цикл додатку бази даних 2

Планування розробки баз даних 3

Визначення вимог до системи 4

Збір і аналіз вимог користувачів 4

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

Вибір цільової СУБД 8

Розробка додатків 8

Створення прототипів 9

Реалізація 9

Конвертування і завантаження даних 10

Тестування 10

Експлуатація і супровід 11

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

Моделювання даних 11

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

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

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

5.3. Вибір СУБД 15

5.4. Адміністрування даних і адміністрування баз даних 15

5.5. Захист баз даних 17

Безпека даних 17

Реєстрація користувачів 20

Керування правами доступу 20

Обов’язкові методи захисту 21

Ведення журналів доступу 21

Обхід системи захисту 22

Контрольні запитання 22

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

5.1. Життєвий цикл додатку бази даних

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

Рис. 9. Життєвий цикл додатка бази даних

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

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

Збір і аналіз вимог користувачів. На цьому етапі виконується збір та аналіз вимог користувачів із усіх можливих галузей застосування.

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

Вибір цільовою СУБД (необов'язково). На цьому етапі виконується вибір СУБД, яка найбільше підходить для додатка бази даних.

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

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

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

Конвертування і завантаження даних. На цьому етапі виконується перетворення і завантаження даних (і прикладних програм) із старої системи в нову.

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

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

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

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

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

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

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

• оцінка можливостей використання інформаційних технологій для досягнення конкурентноздатної переваги.

Для підтримки планування розробки баз даних може бути створена корпоративна модель даних, яка відображає найбільш важливі дані й зв’язки між ними, а також їх відношення до різних функціональних сфер організації. Завдяки цьому можна зрозуміти в яких випадках потрібно організувати спільний доступ до даних з різних функціональних підрозділів.

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

Визначення вимог до системи

Визначення вимог до системи – це визначення діапазону дії та меж додатку бази даних, складу його користувачів і областей застосування.

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

Збір і аналіз вимог користувачів

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

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

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

• з допомогою спостережень за роботою підприємства;

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

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

• за рахунок використання досвіду проектування інших подібних систем.

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

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

Зібрана на цьому етапі інформація може бути погано структурована і включати деякі неформальні заяви користувачів, які потім потрібно буде перетворити і представити у вигляді чітко сформульованих вимог. Цієї мети можна досягнути з допомогою методів складання специфікацій вимог, до яких відносяться, наприклад, технологія структурного аналізу і проектування (Structured Analysis and Design - SAD), діаграми потоків даних (Data Flow Diagrams - DFD) і графіки „вхід-процес-вихід” (Hierarchical Input Process Output - HIPO), доповнені існуючою документацією. Для отримання гарантій того, що складений набір вимог є повним і однозначним, можуть використовуватися CASE-інструменти, призначені для автоматизованого проектування і створення програм. [ 7]

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

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

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

Основними цілями проектування баз даних є:

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

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

• розробка попереднього варіанту проекту, структура якого дозволяє задовольнити всі основні вимоги, які ставляться до продуктивності системи – наприклад, до часу реакції системи.

Існує два основних підходи до проектування баз даних: низхідне, висхідне. При висхідному підході робота починається з найнижчого рівня – рівня визначення атрибутів, які на основі аналізу існуючих між ними зв’язків групуються у відношення, які представляють типи сутностей і зв’язки між ними.

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

Кращою стратегією проектування складних баз даних є використання низхідного підходу. Починається цей підхід з розробки моделей даних, які містять декілька високорівневих сутностей і зв’язків, потім робота продовжується у вигляді серії низхідних уточнень низькорівневих сутностей, зв’язків і атрибутів. Низхідний підхід демонструється в концепції моделі „сутність-зв’язок”. [7] У цьому випадку робота починається з ідентифікації сутностей і зв’язків між ними, що найбільше цікавлять дану організацію.

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

Вибір цільової СУБД

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

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

Розробка додатків

Розробка додатків – це проектування інтерфейсу користувача і прикладних програм, призначених для роботи з базою даних.

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

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

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

Створення прототипів

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

Створення прототипу – це створення робочої моделі додатку бази даних.

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

Рис. 10. Етапи розробки прототипів

Реалізація

Реалізація – це фізична реалізація бази даних і розроблених додатків.

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

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

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

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

Конвертування і завантаження даних

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

Тестування

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

Експлуатація і супровід

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

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

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