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

Независимость данных может быть реализована на двух уровнях: физическом и логиче- ском [1.3], [1.4]. Однако сейчас нас интересует только физическая независимость. Поэтому неуточненный термин "независимость данных" мы пока будем понимать лишь как физиче- скую независимость данных, а логическую независимость данных рассмотрим позднее, в главах 2 и 3. Непосредственное отношение к этому вопросу имеет также глава 9.

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

Проще всего разобраться в понятии независимости данных на примере его про- тивоположности. Приложения, реализованные в старых системах ("дореляционные" или созданные даже до появления систем баз данных), в той или иной мере зависи- мы от данных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программ- ный код приложения.

■ Пример. Предположим, у нас есть приложение, обрабатывающее файл EMPLOYEE (см. рис. 1.4). Исходя из соображений эффективности примем, что этот файл про- индексирован по полю имени работника (NAME). В старых системах в этом прило- жении учитывалось бы, что такой индекс существует и что последовательность записей в файле определена данным индексом. На основе этих сведений была бы построена вся внутренняя структура приложения. В частности, избранный способ реализации процедур доступа и обработки исключительных ситуаций в значи- тельной степени зависел бы от особенностей интерфейса, предоставляемого про- граммами управления данными.

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

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

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

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

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

Таким образом, обеспечение независимости данных — важнейшая цель создания систем баз данных. Независимость данных можно определить как иммунитет при- ложений к изменениям в физическом представлении данных и в методах дос-

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

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

Хранимая база данных

N. ¹ У

^ Прочие хранимые файлы '

Файл PFILE, хранящий записи типа "деталь"

Два экземпляра хранимой записи типа "деталь"

_{I I 1 I}

Экземпляры хранимых полей

₁₁₁₁

Р2

Bolt

Green 17

Номер Название Цвет Вес детали детали детали детали

Рис. 1.6. Хранимые поля, записи и файлы

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

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

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

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

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

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

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

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

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

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

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

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

В некоторых ситуациях может понадобиться представлять данные в хранилище кодированными значениями. В частности, поле "цвет детали", которое представ- лено в приложении как символьная строка ("красный", "голубой", "зеленый"), может храниться в виде десятичной цифры в соответствии с некоторой таблицей перекодировки, например 1 = "красный", 2 = "голубой" и т.д.

Овеществление данных

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

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

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

Номер детали [ Цвет детали [ _и | Номер детали | Вес детали

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

| Номер детали | Цвет детали | Вес детали |

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

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

[ Номер детали | Цвет детали | Вес детали

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

Номер детали Цвет детали и Номер детали Вес детали

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

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

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

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

Теперь легко понять, что независимость данных — одна из причин разделения моде- ли данных и ее реализации, как уже указывалось в конце раздела 1.3. И очень важно от- метить, что чем больше будет такое разделение, тем большая независимость данных бу- дет обеспечена. Недостаточное разделение модели и ее реализации — широко распро- страненный недостаток, свойственный, в частности, современным системам, исполь- зующим язык SQL, что особенно огорчает.

Замечание. Последнее замечание (относительно использующих язык SQL совре- менных систем) вовсе не означает, что в подобных системах совершенно не обеспе- чена независимость от данных. Оно лишь указывает, что эти системы обеспечивают независимость данных в значительно меньшей степени, чем теоретически возможно

в реляционных системах. Иными словами, независимость данных — понятие отно- сительное. Различные системы обеспечивают ее в разной мере или не обеспечивают вообще. Системы, базирующиеся на языке SQL, более развиты в этом направлении, чем старые системы, однако, как мы увидим в последующих главах, все они еще да- леки от совершенства.'