Розробка бази даних

Дотепер за замовчуванням передбачалося, що дані в базі мають деяку структуру. Наприклад, на мал. 1.5 показані чотири таблиці: Property_for_Rent, Owner, Renter і Lease. Але як була отримана така структура? Відповідь на це питання досить проста: структура бази даних визначається під час її проектування. Однак сам процес проектування бази даних може виявитися надзвичайно складним. Для створення системи, що задовольняла б інформаційним потребам деякої організації, необхідно використовувати підхід, що зовсім відрізняється від методів розробки звичайних файлових систем, у яких уся робота полягає в розробці програм, що задовольняють потребам окремих підрозділів. Для успішної реалізації системи на основі бази даних необхідно подумати, насамперед про дані і лише потім про програми. Така зміна підходу цілком може розцінюватися як зміна парадигми.

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

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

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

1.4. Розподіл обов'язків у системах з базами даних

У цьому розділі ми розглянемо згаданий вище п'ятий компонент СКБД - їїкористувачів. Середних можна виділити чотири різні групи:

· адміністратори даних і баз даних;

· розроблювачі баз даних;

· прикладні програмісти;

· кінцеві користувачі.

1.4.1. Адміністратори даних і адміністратори баз даних

База даних і СКБД є корпоративними ресурсами, якими варто керувати так само, як і будь-якими іншими ресурсами. Звичайне керування даними і базою даних передбачає керування і контроль за СКБД і поміщеними в неї даними. Адміністратор даних, чи АД (Data Administrator - DA), відповідає за керування даними, включаючи планування бази даних, розробку і супровід стандартів, бізнес правил і ділових процедур, а також за концептуальне і логічне проектування бази даних. АД консультує і дає свої рекомендації керівництву вищої ланки, контролюючи відповідності загального напрямку розвитку бази даних установленим корпоративним цілям.

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

1.4.2. Розроблювачі баз даних

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

· Будь який співробітник не може відповідати одночасно більш ніж за десять об'єктів нерухомості що здаються в оренду чи продаються.

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

· Довірена особа не може виступати одночасно і як покупець, і як продавець нерухомості..

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

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

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

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

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

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

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

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

1.4.3.Прикладні програмісти

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

1.4.4. Користувачі

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

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

· Досвідчені користувачі. З іншого боку спектра знаходяться досвідчені кінцеві користувачі, що знайомі зі структурою бази даних і можливостями СКБД. Для виконання необхідних операцій вони можуть використовувати таку мову запитів високого рівня, як SQL. A деякі досвідчені користувачі можуть навіть створювати власні прикладні програми.

1.5. Історія розвитку СКБД

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

У результаті фахівці основного підрядчика - фірми North American Aviation (тепер ця фірма називається Rockwell International) - розробили програмне забезпечення за назвою GUAM (Generalized Update Access Method). Основна ідея GUAM була побудована на тім, що малі компоненти поєднуються разом як частини більш великих компонентів доти, поки не буде зібраний воєдино весь проект. Ця відповідна інвертованому дереву структура часто називається ієрархічною структурою (hierarchical structure). У середині 60-х років корпорація IBM приєдналася до фірми NAA для спільної роботи над GUAM, у результаті чого була створена система IMS (Information Management System). Причина, по якій корпорація IBM обмежила функціональні можливості IMS тільки керуванням ієрархіями записів, полягала в тім, що необхідно було забезпечити роботу з пристроями збереження з послідовним доступом, а саме з магнітними стрічками, що були основним типом носія в той час. Через деякий час це обмеження вдалося перебороти. Незважаючи на те, що IMS є найпершою з усіх комерційних СКБД, вона дотепер залишається основною ієрархічною СКБД, яка використовується на більшості великих мейнфреймів.

Іншим помітним досягненням середини 60-х років була поява системи IDS (Integrated Data Store) фірми General Electric. Роботу над нею очолював один з піонерів досліджень в області систем керування базами даних - Чарльз Бачман (Charles Bachmann). Розвиток цієї системи привів до створення нового типу систем керування базами даних - мережних (network) СКБД, - що вплинуло на інформаційні системи того покоління. Мережна СКБД створювалася для представлення більш складних взаємозв'язків між даними, чим ті, котрі можна було моделювати за допомогою ієрархічних структур, а також для формування стандарту баз даних. Для створення таких стандартів у 1965 році на конференції організації CODASYL (Conference on Data Systems Languages), що проходила при участі представників уряду США і бізнесменів, була сформована робоча група List Processing Task Force, перейменована в 1967 році в групу Data Base Task Group (DBTG). У компетенцію групи DBTG входило визначення специфікацій середовища, що допускала би розробку баз даних і керування даними. Попередній варіант звіту цієї групи був опублікований у 1969 році, а перший повний варіант — у 1971 році. Пропозиції групи DBTG містили три компоненти.

· Мережна схема - це логічна організація всієї бази даних у цілимо (з погляду АДБ), що включає визначення імені бази даних, типу кожного запису і компонентів записів кожного типу.

· Підсхема — це частина бази даних, як вона бачиться користувачам чи програмам.

· Мова керування даними - інструмент для визначення характеристик і структури даних, а також для керування ними.

· Група DBTG також запропонувала стандартизувати три різні мови,

· Мова визначення даних (Data Definition Language — DDL) для схеми, що дозволить АБД описати її.

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

· Мова маніпулювання даними (Data Manipulation Language — DML), призначений для керування даними.

Незважаючи на те, що цей звіт офіційно не був схвалений Національним Інститутом Стандартизації США (American National Standards Institute — ANSI), велика кількість систем було розроблено в повній відповідності з цими пропозиціями групи DBTG. Тепер вони називаються CODASYL-системами, чи DBTG-системами. CODASYL-системи і системи на основі ієрархічних підходів являють собою СКБД першого покоління.

Більш докладно вони розглядаються в додатках В, "Мережна модель даних", і Г, "Ієрархічна модель даних", відповідно. Однак ці дві моделі мають наведені нижче недоліки:

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

· Незалежність від даних існує лише в мінімальній ступені.

· Відсутність загальновизнаних теоретичних основ.

У 1970 році Э.Ф.Кодд (Е. Р. Codd), що працював у дослідницькій лабораторії корпорації IBM, опублікував дуже важливу і дуже своєчасну статтю про реляційну модель даних, що дозволяла усунути недоліки колишніх моделей. Слідом за цим з'явилася безліч експериментальних реляційних СКБД, а перші комерційні продукти з'явилися наприкінці 70-х - початку 80-х років. Особливо слід зазначити проект System R, розроблений у дослідницькій лабораторії корпорації IBM, розташованої в місті Хосе, штат Каліфорнія, створений наприкінці 70-х років (Astrahan et al., 1976). Цей проект був задуманий з метою довести практичність реляційної моделі, що досягалося за допомогою реалізації передбачених нею структур даних і необхідних функціональних можливостей. На основі цього проекту були отримані найважливіші результати:

· Була розроблена структурована мова запитів SQL, що з тих пір стала стандартною мовою будь-яких реляційних СКБД.

· У 80-х роках були створені різні комерційні реляційні СКБД - наприклад, DB2 чи SQL/DS корпорації IBM чи Oracle корпорації Oracle Corporation.

В даний час існує кілька сотень різних реляційних СКБД для мейнфреймів і мікрокомп'ютерів, хоча для багатьох зних визначення реляційної моделі носить трохи перебільшений характер. Як, приклад СКБД для багатьох користувачів може служити система CA-OpenIngres фірми Computer Associates і систему Informix фірми Informix Software, Inc. Прикладом реляційних СКБД для персональних комп'ютерів є Access і FoxPro фірми Microsoft, Paradox і Visual dBase фірми Borland, а також R:Base фірми Microrim. Реляційні СКБД відносяться до СКБД другого покоління. Більш докладно реляційна модель даних розглядається далі.

Однак реляційна модель також має деякі недоліки - зокрема, обмеженими можливостями моделювання. Для рішення цієї проблеми був виконаний великий обсяг дослідницької роботи. У 1976 році Чен запропонувавмодель " сутність-зв'язок " (Entity-Relationship model - ER-модель), що у даний час стала самою розповсюдженою технологією проектування баз даних і є основою методології концептуального проектування баз даних і логічного проектування реляційних баз даних. У 1979 році Кодд зробив спробу усунути недоліки власної основної роботи й опублікував розширену версію реляційної моделі - RM/T (1979), потім ще одну версію — RM/V2 (1990). Спроби створення моделі даних, що дозволяє більш точно описувати реальний світ, нестрого називають семантичним моделюванням даних (semantic data modeling).

У відповідь на все зростаючу складність програм баз даних з'явилися дві нові системи: об ' єктно-орієнтовані СКБД, чи ОО СКБД (Object-Oriented DBMS - OODBMS), і об 'є ктно-реляційні СКБД, чи ОР СКБД (Object-Relational DBMS -ORDBMS). Однак, на відміну від попередніх моделей, дійсна структура цих моделей не зовсім ясна. Спроби реалізації подібних моделей являють собою СКБД третього покоління, що більш докладно будуть розглянуті далі.

1.6. Переваги і недоліки СКБД

СКБД володіють як багатообіцяючими потенційними перевагами, так і недоліками, які ми коротко розглянемо в цьому розділі.

Переваги:

· Контроль за надмірністю даних.

· Несуперечність даних.

· Більше корисної інформації при тім же обсязі збережених даних.

· Спільне використання даних.

· Підтримка цілісності даних.

· Підвищена безпека.

· Застосування стандартів.

· Підвищення ефективності з ростом масштабів системи.

· Можливість перебування компромісу при суперечливих вимогах.

· Підвищення приступності даних і їхньої готовності до роботи.

· Поліпшення показників продуктивності.

· Спрощення супроводу системи за рахунок незалежності від даних.

· Поліпшене керування паралельністю.

· Розвиті служби резервного копіювання і відновлення.

Контроль за надмірністю даних

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

Несуперечність даних

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

Більше корисної інформації при одному обсязі збережених даних

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

Спільне використання даних

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

Підтримка цілісності даних

Цілісність бази даних означає коректність і несуперечність збережених у ній даних. Цілісність звичайно описується за допомогою обмежень, тобто правил підтримки несуперечності, що не повинні порушуватися в базі даних. Обмеження можна застосовувати до елементів даних усередині одного запису чи до зв'язків між записами. Наприклад, обмеження цілісності може говорити, що зарплата співробітника повинна перевищувати 40 000 фунтів стерлінгів на рік чи, що в записі з даними про співробітника номер відділення, у якому він працює, повинний відповідати реально існуючому відділенню компанії. Таким чином, інтеграція даних дозволяє АБД задавати вимоги по підтримці цілісності даних, а СКБД застосовувати їх.

Підвищена безпека

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

Застосування стандартів

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

Підвищення ефективності з ростом масштабів системи

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

Можливість знаходження компромісу для суперечливих вимог

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

Підвищення приступності даних і їхньої готовності до роботи

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

SELECT *

FROM property_for_rent

WHERE type = 'Flat' AND rent>400;

Поліпшення показників продуктивності

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

Спрощення супроводу системи за рахунок незалежності від даних

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

Поліпшене керування паралельністю

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

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

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

Недоліки

· Складність.

· Розмір.

· Вартість СКБД.

· Додаткові витрати на апаратне забезпечення.

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

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

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

Складність

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

Розмір

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

Вартість СКБД

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

Додаткові витрати на апаратне забезпечення

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

Дата добавления: 2014-01-07