Независимость прикладных программ и данных
[3]. Конечные пользователи СБД получают доступ к хранимым данным через посредство прикладных программ (ПП), работающих с общим полем данных во внешней памяти (см. рис. 1.3). Этого требует принцип интег-
 |
Рис. 1.3 ПП вокруг данных
рированного хранения. При этом ПП могут использовать только общие для всех форматы хранимых файлов, определенные проектировщиком БД. Игнорирование этого требования недопустимо.
В самом деле, предположим, что прикладные программы создают файлы собственных форматов. Тогда возможны показанные на рис. 1.4 варианты соответствия ПП и данных.
| Вариант 1 |
| Вариант 2 | |
 |  | ||
| Каждая ПП использует только собственные файлы со всеми нужными данными. | ПП создает собственные файлы, если нет подходящих файлов других ПП. |
Рис. 1.4 Данные вокруг ПП
В первом варианте неизбежна неконтролируемая избыточность. Данным нельзя доверять и ими невозможно управлять как общим ресурсом предприятия.
Во втором варианте избыточности нет, но возникает ряд проблем проектирования и развития системы. Главная из них состоит в том, что если прикладной программист изменит структуры файлов своей ПП, скажем, с целью повышения эффективности программы, то придется переписать все ПП, использующие эти файлы. Прикладные программы оказываются взаимно зависимыми в этом смысле.
Вариант «ПП вокруг данных» (рис. 1.3) лишен этих недостатков. Здесь нет ни неконтролируемой избыточности, ни взаимной зависимости ПП. Однако, если ПП получают доступ к данным непосредственно от ОС, то возникает проблема зависимости ПП от данных. Подробное обсуждение этой проблемы можно найти в [1]. Здесь излагается только ее суть. Начнем с определения терминов.
Данные, хранящиеся во внешней памяти, будем называть хранимыми. Наименьшая (логическая) единица хранимых данных называется хранимым полем. Обычно во внешней памяти размещается много экземпляров
хранимых полей, т.е. значений поля.
Поле имеет имя и тип. Хранимые поля объединяются в хранимые записи. Хранимая запись – это набор связанных хранимых полей.
Например
|
номер детали |
наименование |
вес |
– тип хранимой записи |
|
‘P12’ |
‘шайба’ |
0,1 |
– экземпляр записи |
Вариант «ПП вокруг данных» предполагает, что все нужные типы хранимых записей и все их связи определены проектировщиком БД в виде схемы хранения данных. Прикладной программе известна часть схемы, содержащая необходимые ее пользователю данные. Тело программы содержит ссылки на доступные ей хранимые записи и поля. Если схема хранения изменится, то придется переписать все ПП, ориентированные на измененную часть схемы.
Необходимость внесения изменений в схему хранения возникает отнюдь не в исключительных случаях.
· В связи с изменениями требований пользователей могут быть добавлены/удалены хранимые поля или типы записей.
· В связи с изменением программно-технической платформы системы может измениться, например, способ упорядочения записей или способ доступа к записям и т.п.
· Для повышения эффективности обработки запросов к данным может потребоваться изменение структуры хранимых записей. Например, два существующих типа хранимых записей используются в запросах, как правило, вместе. Разумно объединить их в один. Это приведет к уменьшению числа обращений к внешней памяти. Или наоборот, часть длинной записи редко используется и может быть размещена на более медленном устройстве. Разумно расщепить запись на две.
· Для удовлетворения новым стандартам или требованиям защиты, или с целью экономии внешней памяти и т.д. может понадобиться: изменить представление числовых данных – форму, основание системы счисления, масштаб, тип, точность и т.д.; изменить кодировку символов (ASCII – EBCDIC); ввести кодирование данных.
Требование независимости ПП и данных состоит в том, что все эти изменения не должны быть видны
прикладным программам.
