1.5.Независимость данных

Приложения, реализованные на старых системах, в той или иной мере зависят от дан­ных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения; более того, сведения об органи­зации данных и способе доступа встроены в логику и код приложения.

• Пример. Предположим, у нас есть приложение, обрабатывающее файл EMPLOYEE; из соображений эффективности примем, что файл индексирован по определенному полю. В старых системах в этом приложении учитывалось бы, что такой индекс существует, и что последовательность записей в файле определена данным индексом; на этом была бы основана внутренняя структура приложения. В частности, конкретная реализация процедур доступа и обработки исключитель­ных ситуаций в большой степени зависела бы от особенностей интерфейса, обес­печиваемого программами управления данными.

Приложения, подобные описанному в примере, мы называем зависимыми от данных, так как невозможно изменить структуру хранения (т.е. способ физического хранения данных) или метод доступа (т.е. способ осуществления доступа к данным), не изменив самого приложения (возможно, радикально). Например, невозможно за­менить индексированный файл в нашем примере на хешированный файл без внесения значительных изменений в приложение. Более того, изменению в таком случае под­лежат те части приложения, которые взаимодействуют с программами управления данными, и трудности, возникающие при этом, не имеют никакого отношения к про­блеме, для решения которой было написано приложение; это трудности, вызванные структурой интерфейса управления данными.

Однако для системы баз данных крайне нежелательно, чтобы приложение зависе­ло от данных, и тому есть, по меньшей мере, две причины.

1. Для разных приложений требуются разные представления одних и тех же данных. Например, предположим, что до перехода к интегрированной базе данных предпри­ятие имеет два приложения, А и В. Каждое из них имеет свой файл, содержащий по­ле "баланс заказчика". Предположим также, что приложение А записывает значение этого поля в десятичном формате, а приложение В — в двоичном формате. Эти два файла все еще можно интегрировать, а существующую избыточность устранить, ес­ли в СУБД есть возможность выполнить все необходимые преобразования между форматом представления данных(формат представления может быть десятичным, двоичным или любым другим) и форматом, необходимым для приложения. Напри­мер, если принято решение сохранять значения поля в десятичном формате, то каж­дое обращение к приложению В потребует преобразования значений в двоичный формат или из двоичного формата.

Это довольно простой пример тех различий, которые могут существовать в системе баз данных между формой представления данных в приложении и формой их физиче­ского хранения. Многие другие возможные различия мы рассмотрим позднее.

2. Администратор базы данных должен иметь возможность при изменившихся тре­бованиях изменять структуру хранения или метод доступа к данным без измене­ния существующих приложений. Например, к базе данных могут быть добавлены новые виды данных; на предприятии могут быть приняты новые стандарты; могут быть изменены приоритеты приложений (а следовательно, и связанные с ними требования к производительности); могут появиться новые типы запоминающих устройств и т.д. Если приложения зависят от данных, то перечисленные измене­ния потребуют изменения программ и усилий программистов, которые можно бы­ло бы направить на создание новых приложений. До сих пор эта проблема не ред­кость; и сегодня случается, что 25% рабочего времени программистов (или даже больше) тратится на подобную работу, а это, конечно, бесполезная трата дефи­цитных и ценных ресурсов.

Таким образом, обеспечение независимости данных — основная цель систем баз данных. Независимость данных можно определить как иммунитет приложений к изменениям в структуре хранения данных и в методах доступа к данным, а это означает, что рассматриваемые приложения не зависят от любой конкретной струк­туры хранения и конкретных методов доступа. Далее в книге будет описана архитек­тура систем баз данных, обеспечивающая основу для достижения этой цели. Но пре­жде рассмотрим более детально некоторые примеры тех изменений, в выполнении которых может возникнуть необходимость у АБД и к которым, следовательно, долж­ны быть невосприимчивы приложения.

Начнем с определения трех новых терминов: хранимое поле, хранимая запись и хранимый файл (рис. 1.7).

• Хранимое поле — это наименьшая единица хранимых данных. Вообще, база дан­ных содержит много экземпляров каждого из нескольких типов хранимых полей. Например, база данных, содержащая информацию о деталях, может содер­жать тип хранимых полей с именем "номер детали", и для каждого вида детали (винт, шарнир, колпак и т.д.) предусмотрен один экземпляр этого хранимого поля.

•Хранимая запись — это набор связанных хранимых полей. И снова мы различа­ем тип и экземпляр. В данном случае экземпляр хранимой записи состоит из группы связанных экземпляров хранимых полей. Например, экземпляр хранимой записи в базе данных деталей состоит из экземпляров каждого из хранимых полей: номер детали, название детали, цвет детали и вес детали. Мы говорим, что база данных содержит множество экземпляров хранимой записи типа "'деталь" (один экземпляр для каждой определенной детали).

Заметим, что слова "тип" и "экземпляр" часто опускают, а что имеется в виду, следует выяснять по контексту. Хотя эта практика иногда может привести к недо­разумению, она удобна и мы по ходу изложения будем время от времени прибе­гать к ней.

• И, наконец, хранимый файл — это набор всех экземпляров хранимых записей одного типа.

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

В системах, отличных от баз данных, обычно логическая запись совпадает с соответ­ствующей хранимой записью. Как было показано выше, в базах данных это вовсе не обязательно, так как АБД может понадобиться внести изменения в структуру хранения данных (т.е. в хранимые поля, записи, файлы), в то время как логическая структура ос­танется неизменной. Например, упомянутое выше поле 'вес детали'' может быть сохранено в двоичном формате для экономии памяти, тогда как какое-либо приложение, на­писанное на языке COBOL, может рассматривать это поле как символьную строку. А позже может понадобиться изменить форму с двоичной на десятичную, позволяя при­ложению по-прежнему рассматривать поле в символьном формате.

Как установлено ранее, разница, подобная этой, требующая преобразования дан­ных определенного поля при каждом обращении к ним, сравнительно незначительна; однако в принципе разница между тем, что "видит" приложение и что сохраняется на самом деле, может быть довольно значительна. Развивая это замечание, перечислим аспекты структуры хранения баз данных, которые можно подвергнуть изменениям. Читателю предлагается подумать над тем, что должна сделать СУБД для защиты приложения от таких изменений (и всегда ли такую защиту можно обеспечить).

• Представление числовых данных.

Числовое поле может храниться во внутренней арифметической форме (например, в упакованном десятичном формате) или в виде символьной строки. В каждом случае АБД должен определить подходящее основание системы счисления (например, он может выбрать двоичную или десятичную систему счисления), масштаб (число с фиксированной или плавающей запятой), тип (действительное число или комплексное) и точность (количество цифр). Каждый из этих парамет­ров может быть изменен для повышения производительности, при введении ново­го стандарта или по другим причинам.

• Представление символьных данных.

Поле в форме символьной строки может сохраняться с помощью нескольких раз­ных наборов кодирования символов (например, таких как ASCII, EBCDIC).

• Единицы для числовых данных.

Единицы числовых полей могут быть изменены, например, с дюймов на санти­метры, если приложение связано с процессами измерения.

• Кодирование данных.

В некоторых ситуациях может понадобиться представлять данные кодированными значениями. Например, поле "цвет детали", которое представлено в приложении как символьная строка ("Красный", "Голубой", "Зеленый"), может храниться в виде де­сятичной цифры в соответствии с таблицей перекодировки: 1 = "Красный", 2 = "Голубой" и т.д.

• Материализация данных.

Обычно логическое поле, используемое приложением, соответствует некоторому оп­ределенному хранимому полю (хотя, как мы видели ранее, могут существовать разли­чия в типе данных, единицах и т.д.). В этом случае процесс материализации, т.е. по­строение экземпляра логического поля из соответствующего экземпляра хранимого поля и передача его приложению, можно назвать прямым. Однако иногда логическое поле может не иметь соответствующего эквивалентного хранимого поля, а его значе­ние "материализуется" с помощью некоторых вычислений, выполняемых над набором из нескольких экземпляров хранимых полей. Например, значения логического поля "общее количество" можно определить путем суммирования нескольких хранимых значений поля "количество". "Общее количество" — это пример виртуального поля, процесс определения его значения называют непрямым. Однако обратите внимание, что пользователь может отличить реальное поле от виртуального, так как экземпляр виртуального поля нельзя вставить или изменить (напрямую).

• Структура хранимых записей.

Два существующих типа хранимых записей можно объединить в один. Например, типы хранимых записей

Номер детали

Цвет детали

и

Номер детали

Вес детали

можно представить в форме

номер детали

Цвет детали

вес детали

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

И наоборот, один тип хранимых записей можно разделить на два. Воспользуемся записями из предыдущего примера: тип хранимых записей

номер детали

Цвет детали

вес детали

можно разбить на два

Номер детали

цвет детали

Номер детали

вес детали

Такое разделение позволяет редко используемые части исходной записи помес­тить, например, на более медленное устройство. При этом неявно предполагается, что логическая запись приложения может содержать поля из нескольких отдель­ных хранимых записей, т.е. логическая запись является расширением любой из этих хранимых записей.

• Структура хранимых файлов.

Хранимый файл может физически храниться в памяти разными способами. На­пример, его можно разместить на одном томе памяти (например, на одном диске) или распределить на нескольких томах разных типов устройств; он может быть физически упорядочен в соответствии со значениями некоторого хранимого поля; он может быть упорядочен какими-либо другими способами, например с помо­щью одного или нескольких индексов или встроенных цепочек указателей; к нему может быть обеспечен доступ методом хеш-адресации; хранимые записи могут быть физически объединены в блоки (несколько в одной физической записи). Но ни один из этих факторов не должен влиять каким-либо образом на приложение (за исключением, конечно, эффективности приложения).

Этим ограничиваются аспекты структуры хранения, которые можно подвергнуть изменениям. Здесь среди прочего предполагается, что база данных может развиваться, не оказывая влияния на приложения. В действительности возможность развития базы данных без логического ущерба для существующих приложений является единствен­ным наиболее важным мотивом обеспечения независимости данных. Например, можно было бы расширить существующий тип хранимой записи добавлением новых хранимых полей, представляющих обычно дополнительную информацию о некоторых сущест­вующих типах объектов (например, поле "цена" можно добавить к хранимой записи "деталь"). Такие новые поля будут "невидимы" для существующих приложений. Точно так же можно добавить новые типы хранимых записей (а, следовательно, новые храни­мые файлы), не изменяя существующих приложений; такие записи обычно представля­ют собой новые типы объектов (например, тип записи "поставщик" можно добавить к базе данных "детали"). Такие добавления также будут незаметны для приложений.

В заключение заметим, что независимость данных — понятие относительное, раз­личные системы обеспечивают ее в разной мере или не обеспечивают вообще. В це­лом современные системы более развиты в этом направлении, чем старые, однако, как будет показано в последующих главах, и они имеют свои недостатки.