Витрати на перетворення

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

Продуктивність

Збільшення інформаційного простору, який охоплює СКБД може в окремих випадках призводити до зменшення продуктивності окремих АРМ.

Більш серйозні наслідки при виході системи з ладу

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

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

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

Рис.1.4. Етапи життєвого циклу ІС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекція 2. Трьохрівнева архітектура БД за ANSI-SPARC.

Трьохрівнева архітектура ANSI-SPARC. Зовнішній рівень. Концептуальний рівень. Внутрішній рівень. Схеми, відображення й екземпляри. Незалежність від даних.

2.1.Трьохрівнева архітектура ANSI-SPARC.

Рис. 2.1. Трьохрівнева архітектура ANSI-SPARC

Історія методів доступу до даних протягом останніх декількох десятиліть пройшла шляхом від громіздких, фізично орієнтованих методів початкового періоду обробки файлів до різних видів обробки баз даних. Важливий етап цього розвитку реалізований в сьогоднішніх реляційних базах даних. Одним з найбільш важливих аспектів реляційної «революції» стала ідея відділення логічної структури і маніпуляції даними, як вони розуміються кінцевим користувачем, від фізичного представлення, необхідного комп'ютерним системам. На сьогодні ця важлива ідея втілена в філософії структури баз даних, представленої в моделі ANSI/SPARC.

Комітетом планування стандартів і норм SPARC (Standards Planning and Requirements Committee) Національного Інституту Стандартизації США (American National Standard Institute — ANSI), скорочено ANSI/SPARC в 1978р було визнано необхідність використання трьохрівневої архітектури БД, в якій опис елементів даних представляється за допомогою 3-х рівнів абстракції (зовнішній, концептуальний, внутрішній).

Причинами такого поділу стали:

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

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

- необхідність надання можливості адміністратору бази даних (АБД) змінювати структуру збереження даних у базі, не впливаючи на користувацькі уявлення;

- необхідність забезпечення незалежності внутрішньої структури бази даних від апаратних особливостей (або фізичних аспектів реалізації) системи;

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

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

2.2. Схеми, відображення й екземпляри

В рамках 3-х рівневої архітектури БД розрізняють два види схем:

-концептуальна схема;

-фізична схема.

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

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

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

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

2.3.Незалежність від даних

Р озрізняють логічну та фізичну незалежність.

Логічна незалежність відданих

Логічна незалежність від даних означає повну захищеність зовнішніх схем від змін, внесених у концептуальну схему.

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

Фізична незалежність від даних

Фізична незалежність від даних означає захищеність концептуальної схеми від змін, внесених у внутрішню схему.

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

Лекція 3. Функції та архітектура СУБД.

Функції СУБД. Багатокористувацькі СУБД. Архітектура клієнт \ серверних СУБД. Концепція відкритих систем. Відкритий зв’язок з БД. ODBC. Телеобробка. Файловий сервер.

1. Функції СУБД (3.11.01.02).

1.Безпосереднє управління даними в зовнішній пам'яті

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

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

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

2.Управління транзакциями

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

3.Журналізація

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

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

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

В усіх випадках дотримують стратегії «випереджувального» запису в журнал (так званого протоколу Write Ahead Log — WAL).

Найпростіша ситуація відновлення — індивідуальне відкочування транзакції.

4.Підтримка мов БД

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

5.Адміністрування БД.

2. Концепція відкритих систем. Відкритий зв’язок з БД ODBC (3.11.04.01).

Абрівіатура ODBC (англ. Open DataBase Connectivity) — це відкритий інтерфейс доступу до баз даних, розроблений консорціумом X/Open.

На початку 1990 років існувало декілька постачальників баз даних, кожен з яких мав власний інтерфейс. Якщо застосунку було необхідно підключатися до кількох джерел даних, для взаємодії з кожною з баз даних був необхідний нестандартний код. Для вирішення цієї проблеми Microsoft та ряд інших компаній створили стандартний інтерфейс для отримання і відправки даних БД різних типів. Цей інтерфейс отримав назву open database connectivity (відкритий зв'язок з базами даних).

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

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

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

3. Багатокористувацькі СУБД та їх архітектура.

Для локальної архітектури характерно, що програма, і база даних розташовані на одному комп'ютері.

Багато користувацькі СУБД включають в себе сервер БД і клієнтську частину і, як правило, можуть працювати в неоднорідному обчислювальному середовищі (з різними типами ЕОМ і операційними системами). До багатокористувацьких СУБД відносяться, Oracle i Informix

Дата добавления: 2014-10-15