Залежність від даних

Як уже згадувалося вище, фізична структура і спосіб збереження записів файлів даних жорстко зафіксовані в коді програм. Це значить, що змінити існуючу структуру даних досить складно. Наприклад, збільшення у файлі “Власність_В_Оренду” довжини поля адреси з 40 до 41 символу здається зовсім незначною зміною його структури, але для втіленні цієї зміни буде потрібно, як мінімум, створити одноразову програму спеціального призначення (тобто програму, що виконується тільки один раз), що перетворить вже існуючий файл “Власність_В_Оренду” у новий формат. Вона повинна виконувати наступні дії:

• відкрити вихідний файл “Власність_В_Оренду” для читання;

• відкрити тимчасовий файл із новою структурою запису;

• читати запис з вихідного файлу, перетворити дані в новий формат і записати їх у тимчасовий файл. Ці дії варто виконати для всіх записів вихідного файлу;

• видалити вихідний файл “Власність_В_Оренду”;

• привласнити тимчасовому файлу ім'я “Власність_В_Оренду”.

Крім цього, всі програми, що звертаються до файлу “Власність_В_Оренду” повинні бути змінені з метою відповідності новій структурі файлу. Причому таких програм може бути дуже багато. Отже, програміст повинний колись виявити всі такі програми, а потім перевірити ще раз і змінити їх. Зверніть увагу, що багато програми можуть звертатися до файлу “Власність_В_Оренду” і при цьому взагалі не використовувати поле адреси. Ясно, що виконання всіх цих дій вимагає великих витрат часу і може з'явитися причиною появи помилок. Дана особливість файлових систем називається залежністю від програм і даних (program-data dependence).

Несумісність форматів файлів

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

Фіксовані запити/швидке збільшення кількості програм

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

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