Технологія створення і ведення БД презентация

І ВЕДЕННЯ БД

ОПЕРАЦІЯ ВІДНОВЛЕННЯ БАЗИ ДАНИХ

4. РЕОРГАНІЗАЦІЯ І РЕСТРУКТУРИЗАЦІЯ БАЗИ ДАНИХ

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

Цю операцію виконують для файлів, які вміщують умовно-постійну та оперативну інформацію

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

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

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

Access – це таблиці). Сучасні СУБД надають зручні засоби створення структур файлів. Тому при створенні структур доцільно використовувати стандартні засоби СУБД.
Що стосується операції завантажування (насичення таблиць інформацією), то використання стандартних засобів, які надаються для цього сучасними СУБД, не завжди доцільне. Це пов'язано з кількома причинами:

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

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

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

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

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

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

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

в інший. Цю операцію можна виконувати в кількох випадках:

1) якщо є лінійні файлові структури, котрі необхідно реорганізувати в базу даних, що буде перебувати під управлінням СУБД;

2) при імпорті/експорті файлів бази даних з однієї СУБД в іншу. Багато СУБД мають стандартні засоби конвертації та приєднання й роботи з базами даних, сформованими іншими системами. Наприклад, Microsoft Access, має засоби імпорту та експорту з такими СУБД, як FoxPro, Paradox версії: 3.x чи 4.x, dBASE III чи dBASE IY, Btrieve (зі словниковим файлом Xtrieve) та Microsoft SQL Server. Крім того, ця СУБД може імпортувати та експортувати дані різного роду текстових редакторів та електронних таблиць, таких як Microsoft Excel чи Lotus 1-2-3.

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

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

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

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

Семантична цілісність даних – це захист цілісності окремих даних, файлів і зв'язків між ними, яка залежить від специфіки предметної області.

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

реляційних таблиць (файлів), а також зв’язків між ними.

Обмеження цілісності, які повинні накладатися на окремі атрибути.

1. Контроль поля за шаблоном.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

перевірку на недопустимість циклів. Характерним прикладом файлу для такої перевірки є «Склад виробу», при створенні якого необхідно виконувати перевірку того, щоб вузол не входив сам у себе.

Є обмеження, які накладаються на зв'язки між файлами, і ці обмеження стосуються кількох зв'язаних між собою файлів.

Обмеження, які можуть накладатися на зв'язки та на зв'язані між собою відношення.

1. Обмеження посилкової цілісності.

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

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

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

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

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

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

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

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

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

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

її часткового пошкодження чи повного знищення. Технологію ведення бази даних належить спроектувати так, щоб можна було відновити базу даних у таких випадках.
Деякі СУБД мають змогу відновлювати інформацію в деяких випадках її пошкодження. Зокрема, Microsoft Access має спеціальну команду відновлення бази даних, коли її пошкодження сталося в результаті незапланованої зупинки Access (наприклад, «зависання» системи).
Однією з основних вимог до СУБД є забезпечення надійності зберігання даних. Ця вимога передбачає можливість відновлення узгодженого стану бази даних після будь-яких апаратних чи програмних збоїв.

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

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

виконується як єдине ціле (все або нічого) і що переводить базу даних з одного цілісного стану в інший цілісний стан.

Трансакція володіє чотирма важливими властивостями:

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

продовжується до тих пір, поки не відбудеться одна з наступних подій:

Подана команда COMMIT WORK (зафіксувати трансакцію).
Подана команда ROLLBACK WORK (відкотити трансакцію).
Відбулося від'єднання користувача від СУБД.
Відбувся збій системи.

Команда COMMIT WORK завершує поточну трансакцію і автоматично починає нову трансакцію. При цьому гарантується, що результати роботи завершеної трансакції фіксуються, тобто зберігаються в базі даних.
Зауваження. Деякі системи (наприклад, Visual FoxPro), вимагають подати явну команду BEGIN TRANSACTION для того, щоб почати нову трансакцію.

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

При від'єднанні користувача від СУБД відбувається автоматична фіксація трансакцій.

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

Ті трансакції, для яких була подана команда COMMIT WORK, але результати роботи яких не були занесені в базу даних виконуються знову (накочуються).

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

Далі буде докладніше.

об'ємі. Особливо це відноситься до властивості І (ізоляція). У ідеалі, трансакції різних користувачів не повинні заважати один одному, тобто вони повинні виконуватися так, щоб у користувача створювалася ілюзія, що він в системі один.

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

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

допускають вкладені трансакції. Якщо трансакція Б запущена усередині трансакції А, і для трансакції Б подана команда COMMIT WORK, то фіксація даних трансакції Б є умовною, оскільки зовнішня трансакція А може відкотитися. Результати роботи внутрішньої трансакції Б будуть остаточно зафіксовані тільки якщо буде зафіксована зовнішня трансакція А.

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

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

Жорсткий збій.

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

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

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

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

висуваються високі вимоги до безпеки та захищеності даних.

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

внесених змін передбачає виконання таких дій:

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

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

3. Якщо було частково зруйновано файли бази даних і на них виконували якісь розрахунки, то їх необхідно повторити на відновленій базі даних.

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

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

бази даних, інтенсивності та характеристики модифікацій, інтенсивності звертання до файлів бази даних та ін.

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

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

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

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

До операцій актуалізації належать операції: дозаписування, заміни та вилучення.

У ході виконання цих операцій потрібно дотримуватися таких вимог:

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

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

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

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

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

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

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

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