Підтримка цілісності у разі виникнення перебоїв 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Підтримка цілісності у разі виникнення перебоїв



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

♦ періодичне створення резервної копії бази даних;

♦ ведення журналу всіх змін стану бази даних.

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

Розділ 4. Проектування баз даних

Тема 4.1. Методологія проектування бази даних

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

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

Фаза проектування поділяється на такі етапи:

♦ визначення стратегії;

♦ аналіз предметної області;

♦ концептуальне моделювання;

♦ логічне й фізичне проектування.

Фаза реалізації складається з таких пунктів:

♦ власне програмна реалізація;

♦ документування;

♦ дослідне впровадження;

♦ промислова експлуатація.

Методологія проектування баз даних — це сукупність принципів, методів, ін­струментів і засобів, що застосовуються для послідовного розроблення структури бази даних. Оскільки система баз даних складається з програм і даних, методоло­гія проектування баз даних розглядається як невід'ємна частина загальної мето­дології проектування програмних систем.

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

Методологія проектування баз даних визначає:

♦ процес проектування;

♦ методику виконання розрахунків і критеріїв оцінювання альтернативних рі­шень на кожному етапі проектування;

♦ інформаційні вимоги як вихідні дані для процесу проектування;

♦ засоби опису вихідних даних і відображення результатів кожного етапу про­ектування.

Процес проектування

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

З проектуванням тісно пов'язане експертне оцінювання проекту. Мета експер­тизи - знайти помилки й виправити їх на ранніх етапах проектування. Зазвичай експертиза виконується після завершення кожного з етапів.

Критерії оцінювання

Оцінювання необхідне для ухвалення рішень за наявності альтернатив. Труднощі у визначенні критеріїв і виборі альтернатив пов'язані з тим, що часто розробляє­ться кілька проектів структури бази даних і потрібно оцінити, який з них є кра­щим. Зробити це буває досить складно.

Критерії є кількісні (час обробки запитів, вартість операцій маніпулювання даними, витрати пам'яті тощо) та якісні (гнучкість, адаптивність, сприйнятли­вість та сумісність).

Інформаційні вимоги

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

Засоби опису

Це мовні засоби, призначені для опису результатів виконання кожного етапу про­ектування. А саме, йдеться про такі засоби.

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

♦ Стандартні форми, анкети та бланки. Використовуються переважно на етапі аналізу.

♦ Спеціальні формалізовані мови концептуального моделювання (семантичні мережі, числення предикатів та ER-мови). Використовуються переважно на етапі концептуального моделювання.

♦ Формалізовані мова означення даних (МОД) і мова маніпулювання дани­ми (ММД). Використовуються на етапі логічного проектування. Зазвичай з цією метою застосовують мову SQL.

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

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

Визначення стратеги

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

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

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

Результати. Основними результатами цього етапу мають бути:

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

♦ опис цілей і завдань автоматизації, витрат і можливого виграшу;

♦ узагальнена діаграма сутностей і зв'язків;

♦ узагальнена ієрархічна схема завдань (виробничих та управлінських);

♦ рекомендації щодо майбутньої реалізації та подолання можливих труднощів;

♦ визначення меж і окреслення сфери застосування системи баз даних;

♦ можлива архітектура системи;

♦ поетапний план проектування бази даних.

Такий підхід до моделювання предметної області передбачає її відображення 3 трьох різних точок зору:

♦ загальний напрям прикладної діяльності;

♦ прикладні завдання;

♦ інформаційні потреби.

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

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

Ключові чинники успіху. На першому етапі слід виділити насамперед такі чинники успіху:

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

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

♦ проведення плідних нарад із ретельним розглядом усіх питань.

Аналіз предметної області

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

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

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

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

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

♦ проведення бесід з користувачами;

♦ перегляд усіх документів та бланків, які обробляються і формуються органі­зацією;

♦ аналіз потоків документів;

♦ аналіз способів вирішення завдань організації;

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

Результати. До ключових результатів етапу аналізу належать:

♦ узгоджена діаграма сутностей і зв'язків;

♦ відомості про обсяги даних, частоту виконання завдань, очікуваний користу­вачем рівень продуктивності;

♦ деталізовані й узгоджені описи завдань;

♦ первинний варіант стратегії впровадження;

♦ опис заходів з ревізії і контролю даних, резервного копіювання й відновлення;

♦ загальний опис процедур, що не автоматизуються;

♦ критерії прийнятності, якості, гнучкості та продуктивності;

♦ попереднє оцінювання обсягів системи;

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

♦ уточнений план розроблення системи.

Ключові чинники успіху.

♦ активна участь користувачів;

♦ ретельна перевірка достовірності, повноти й несуперечності даних;

♦ виявлення всіх питань та припущень, що мають ключове значення для проек­тування і впровадження;

♦ встановлення точних характеристик ключових завдань і даних;

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



Поделиться:


Последнее изменение этой страницы: 2017-01-25; просмотров: 167; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.144.96.159 (0.03 с.)