Главная » SQL, Базы данных » НЕЗАВИСИМОСТЬ ОТДАННЫХ

0

Независимость от данных может быть реализована на двух уровнях: физическом и логическом [1.3], [1.4]. Однако на данном этапе нас интересует только физическая независимость. Поэтому неуточненный термин независимость от данных мы пока будем понимать лишь как физическую независимость от данных. (Необходимо отметить, что термин независимость от данных не совсем подходящий — он не отражает достаточно точно сущность происходящего. Но поскольку традиционно используется именно этот термин, последуем общему правилу.)

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

иной мере зависимы от данных. Это означает, что способ организации данных во вторичной

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

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

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

1.          Для разных приложений требуются разные представления одних и тех же данных.

Например, предположим, что до перехода к интегрированной базе данных пред приятие имело два приложения, А и В. Каждое из них работало с собственным файлом, содержащим поле "остаток средств на счете заказчика". Предположим

также, что приложение А записывает значение этого поля в десятичном формате,

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

значения этого поля в десятичном формате, то каждое обращение к приложению В

потребует прямого или обратного преобразования значений из десятичного фор мата в двоичный.

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

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

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

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

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

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

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

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

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

только одного типа. Это упрощение не окажет существенного влияния на последующие рассуждения.)

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

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

Как утверждалось ранее, такие различия (требующие преобразования типа данных некоторого поля при каждом обращении к нему) являются довольно незначительными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии