більший спектр методів контролю цілісності введеної інформації, створювати певні зручності при її введенні, не потребуючи при цьому складної підготовки користувача.
До програмних засобів завантажування файлів БД висуваються такі вимоги:
програми завантажування повинні бути діалоговими і орієнтованими на користувача-непрофесіонала в сфері обчислювальної техніки та програмування;
програмні засоби завантажування мають бути захищеними, тобто не дозволяти некоректного та несанкціонованого введення інформації. Деякі файли бази даних взагалі можуть бути закритими для введення в них даних і доступними лише для перегляду. Наприклад, файл даних, що зберігає результати інвентаризації на складі, повинен після його створення бути захищеним від внесення в нього будь-яких змін;
окрім візуального контролю та контролю за типом і форматом даних програми завантажування повинні вміщувати широкий спектр арифметичних і семантичних методів контролю;
при завантажуванні даних необхідно виконувати повний обсяг робіт, пов'язаних з контролем забезпечення цілісності та узгодженості даних у файлах БД;
програма повинна імітувати звичний для користувача процес заповнення первинного документа (відображуючи його формуляр-шаблон на екрані) і паралельно з ним завантажувати відповідні файли бази даних, а в разі потреби видавати цей документ на принтер;
виконувати паралельно зі створенням файла БД автоматизацію процедур кодування окремих позицій номенклатур на базі використання файлів нормативно-довідкової інформації;
виконувати обробку та діагностику всіх типових помилок при введенні даних з клавіатури;
надавати користувачеві максимум сервісних функцій у вигляді підказок і коментарів (бажано в двох режимах: для користувача-початківця і досвідченого користувача).
Створюючи файли бази даних, необхідно дотримуватися принципу одноразового введення інформації. Нову інформацію потрібно вводити в базу даних лише тоді, коли її не можна отримати якимось іншим способом. Сучасні СУБД надають великі можливості по зв'язуванню файлів з перенесенням даних з одного файла в інший, з однієї системи — в іншу. Операція імпорту (експорту) файлів з однієї системи в іншу дає змогу виключити повторне ручне введення даних, зменшує час на виконання такої досить непродуктивної роботи та кількість помилок. При імпорті (експорті) даних виконують операцію конвертації.
Конвертація — це процедура перетворення файла бази даних з одного формату в інший. Цю операцію можна виконувати в кількох випадках:
1) якщо є якісь лінійні файлові структури, котрі необхідно реорганізувати в базу даних, що буде перебувати під управлінням СУБД. Найчастіше цю операцію виконують при переході від пакетної обробки на машинах типу ЄС ЕОМ до обробки на персональній обчислювальній техніці;
2) при імпорті/експорті файлів бази даних з однієї СУБД в іншу. Багато СУБД мають стандартні засоби конвертації та приєднання й роботи з базами даних, сформованими іншими системами. Наприклад. Microsoft Access має засоби імпорту та експорту з такими СУБД, як FoxPro, Paradox версії З.х чи 4.х, dBASE III чи dBASE IY, Btrieve (зі словниковим файлом Xtrieve) та Microsoft SQL Server. Крім того, ця СУБД може імпортувати та експортувати дані різного роду текстових редакторів та електронних таблиць, таких як Microsoft Exel чи Lotus1-2-3.
Якщо ж СУБД не має стандартних засобів для конвертації, для виконання цієї операції необхідно записувати спеціальні програми конвертації.
5.3. ОПЕРАЦІЯ ВІДНОВЛЕННЯ БД
Операцію відновлення бази даних виконують в разі її часткового пошкодження чи повного знищення. Технологію ведення бази даних треба спроектувати так, щоб можна було відновити базу даних у таких випадках. Деякі СУБД мають змогу відновлювати інформацію в деяких випадках її пошкодження. Так, Microsoft Access має спеціальну команду відновлення бази даних, коли її пошкодження сталося в результаті незапланованої зупинки Access (наприклад, «зависання» системи).
Однією з основних вимог до СУБД є забезпечення надійності зберігання даних. Ця вимога передбачає можливість відновлення узгодженого стану бази даних після будь-яких апаратних чи програмних збоїв.
Розглянемо можливі ситуації пошкодження БД.
Індивідуальний відкіт транзакції. Ця ситуація може виникнути, коли відкіт ініціюється оператором чи системою, наприклад, транзакцію було вибрано для виходу з тупика; при виникненні виняткової ситуації в прикладній програмі (наприклад, ділення на нуль) та при інших помилках програмного забезпечення. В разі індивідуального відкоту транзакції для відновлення бази даних необхідно усунути наслідки дій операторів модифікації бази даних, які виконувалися в цій транзакції.
М'який збій. Така ситуація може виникнути після аварійного вимкнення електроенергії в мережі, при збої процесора з невстановлених причин і т.п. У цьому разі втрачається та частина бази даних, яка в момент збою розміщувалася в буферах оперативної пам'яті.
Жорсткий збій. Ця ситуація пов'язана з поломкою зовнішнього пристрою, на якому розміщена база даних. Ця ситуація за досить високої надійності пристроїв зовнішньої пам'яті може виникати дуже рідко, але все одно такий варіант пошкодження БД потрібно передбачати і мати засоби відновлення БД.
Очевидно, що для відновлення бази даних необхідна деяка додаткова інформація. У сучасних розподілених СУБД, які мають механізм підтримки транзакцій, така додаткова інформація підтримується у вигляді журналів реєстрації змін бази даних.
Але е багато СУБД, які не мають спеціальних засобів відновлення бази даних, тому необхідно