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

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

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

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

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

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

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

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

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

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

Единицы измерения для числовых данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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