Введение в системы БД (542480), страница 11
Текст из файла (страница 11)
Однако есть еще одно преимушество, которое необходимо добавить к этому списку и которое не столь очевидно (хотя косвенно и охватывает несколько преимушеств). Речь идет об обеспечении независимости данных. (Строго говоря, это, скорее, цель создания систем баз данных, а не обязательное их преимушество.) Концепция независимости настолько важна, что ей посвящен целый раздел, представленный ниже.
1.5. Независимость данных Независимость данных может быть реализована на двух уровнях: физическом и логическом [1.3), [1.4[. Однако сейчас нас интересует только физическая независимость. Поэтому неуточненный термин "независимость данных" мы пока будем понимать лишь как физическую независимость данных, а логическую независимость данных рассмотрим позднее, в главах 2 и 3. Непосредственное отношение к этому вопросу имеет также глава 9. Замечание. Пожалуй, необходимо отметить, что термин "независимость данных" не совсем подходящий (он не отражает достаточно точно сущность происходящего).
Но поскольку именно этот термин традиционно используется, мы последуем общему правилу. Проще всего разобраться в понятии независимости данных на примере его противоположности. Приложения, реализованные в старых системах ("дореляционные" или созданные даже до появления систем баз данных), в той или иной мере зависимы от данных.
Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программный код приложения. ° Пример. Предположим, у нас есть приложение, обрабатывающее файл ЕИРЬОХЕЕ (см. рис. 1.4). Исходя из соображений эффективности примем, что этот файл проиндексирован по полю имени работника (ИЛИЕ). В старых системах в этом приложении учитывалось бы, что такой индекс существует и что последовательность записей в файле определена данным индексом.
На основе этих сведений была бы построена вся внутренняя структура приложения. В частности, избранный способ реализации процедур доступа и обработки исключительных ситуаций в значительной степени зависел бы от особенностей интерфейса, предоставляемого программами управления данными. 50 Часть 1 Основные понятия Приложения, подобные описанному в этом примере, мы называем зависимыми от данных, так как невозможно изменить физическое представление (т.е, способ физического размещения данных во вторичной памяти) или метод доступа (т.е.
конкретный способ доступа к данным), не изменив самого приложения (возможно, радикально). Например, невозможно заменить индексированный файл в нашем примере хешированным файлом, не внеся в приложение значительных изменений. Более того, изменению в подобных случаях подлежат те части приложения, которые взаимодействуют с программами управления данными. Трудности, возникающие при этом, не имеют никакого отношения к проблеме, для решения которой было написано данное приложение; это трудности, внесенные используемой структурой интерфейса управления данными.
Однако для системы баз данных крайне нежелательно, чтобы приложение зависело от данных, и на то есть по меньшей мере две причины. Е Для разных приложений требуются разные представления одних и тех же данных. Например, предположим, что до перехода к интегрированной базе данных предприятие имело два приложения, А и В.
Каждое из них работало с собственным файлом, содержащим поле "баланс заказчика". Предположим также, что приложение А записывает значение этого поля в десятичном формате, а приложение  — в лвоичном. Эти два файла все еще можно интегрировать, а существующую избыточность устранить, если в СУБД есть возможность выполнить все необходимые преобразования между форматом представления данных (формат представления может быть десятичным, двоичным или любым другим) и форматом, необходимым для приложения. Например, если принято решение сохранять значения поля в десятичном формате, каждое обращение к приложению В потребует преобраювания значений в двоичный формат или из двоичного формата. Это довольно простой пример различий, которые могут существовать в системе баз данных между формой представления данных в приложении и формой их физического хранения.
Многие другие возможные различия будут рассмотрены ниже. 2. Администратор базы данных должен иметь неограниченные возможности изменять физическое представление или метод доступа к данным в случае изменения требований, причем без необходимости модифицировать существующие приложения. Например, к базе данных могут быть добавлены новые виды данных, на предприятии могут быть приняты новые стандарты, могут быть изменены приоритеты приложений (а следовательно, и связанные с ними требования к производительности), могут появиться новые типы запоминающих устройств и т.д. Если приложения зависят от данных, то перечисленные изменения потребуют внесения изменений в программы, а значит, дополнительных усилий программистов, которые можно было бы направить на создание новых приложений. До сих пор подобные проблемы не являются исключением.
И сегодня случается, что значительная часть рабочего времени программистов (вспомните хотя бы проблему 2000-го года!) тратится на подобную работу„а это, конечно, бесполезная трата дефицитных и ценных ресурсов. Таким образом, обеспечение независимости данных — важнейшая цель создания систем баз данных. Независимость данных можно определить как иммунитет приложений к изменениям в физическом представлении данных и в методах дос- Глава 1. Базы Данных и управление ими 51 тупа к ним, а это означает, что рассматриваемые приложения не зависят от любых конкретных способов физического представления информации или выбранных методов доступа к ним.
В главе 2 будет описана архитектура систем баз данных, обеспечивающая основу для достижения этой цели. Однако прежде давайте более детально рассмотрим некоторые примеры тех видов изменений, в выполнении которых у АБД может возникнуть необходимость и к которым, следовательно, должны быть невосприимчивы приложения.
Начнем с определения трех новых терминов: хранимое поле, хранимая запись и хранимый файл (рис. 1.6). Рис. 1.6. Хранимые паля, записи и файлы ° Хранимое поле — это наименьшая единица хранимых данных. Типичная база данных содержит множество экземпляров (оссцгепсе или 1пз1апсе) каждого из нескольких описанных в ней типов или хранимых полей. Например, база данных, содержащая информацию о деталях, может включать тип хранимого поля с именем "номер детали" и лля каждого описанного в базе данных вида детали (винта, шарнира, колпака и т.д.) будет существовать отдельный экземпляр этого хранимого поля.
Часть 1 Основные понятия ю:«., Замечание. На практике часто опускают квалификаторы "тип" и "экземпляр", полагая, что точный смысл ясен по контексту. Хотя и существует небольшая вероятность путаницы, это удобная практика, и мы будем ей время от времени следовать. (Это замечание также относится к хранимым записям, речь о которых пойдет в следующем абзаце.) ° Хранимая запись — это набор связанных хранимых полей. И снова мы различаем для них тип и экземпляр. В данном случае экземпляр хранимой записи состоит из группы связанных экземпляров хранимых полей. Например, экземпляр хранимой записи в базе данных деталей состоит из экземпляров каждого из следующих хранимых полей: "номер детали", "название детали", "цвет детали" и "вес детали".
Мы говорим, что база данных содержит множество экземпляров хранимой записи типа "деталь" (опять же, один экземпляр для каждой конкретной детали). ° И наконец, хранимый файл — это набор всех существующих в настоящий момент экземпляров хранимых записей одного и того же типа. Замечание. Для упрощения предполагается, что любой заданный хранимый файл может содержать хранимые записи только одного типа. Это упрощение не окажет существенного влияния на последующие рассуждения. В современных системах, отличных от баз данных, логическая запись (с точки зрения приложения) обычно совпадает с соответствующей хранимой записью.
Как было показано выше, в базах данных это вовсе не обязательно, поскольку АБД в любой момент может потребоваться внести изменения в структуру хранения данных (т.е. в хранимые поля, записи, файлы), в то время как структура данных с точки зрения приложения должна остаться неизменной. Например, поле йЕРАЕТМЕМТ в файле ЕМРЬОТЕЕ для экономии памяти может быть сохранено в двоичном формате, тогда как приложение, написанное на языке СОВОГО, может рассматривать это поле в качестве символьной строки. А позже может понадобиться изменить двоичную форму представления этого поля на десятичную, сохранив для приложения возможность обрабатывать поле в символьном формате. Как утверждалось ранее, такие различия потребуют преобразования типа данных подобного поля при каждом обращении к нему, хотя в целом эти различия можно считать сравнительно незначительными.
Однако, в принципе, разница между тем, что видит приложение, и тем, что сохраняется на самом деле, может быть довольно значительна. Развивая это замечание, перечислим те аспекты структур хранения данных в базах, которые могут подвергаться изменениям. Читателю предлагается самостоятельно подумать над тем, что должна сделать СУБД для зашиты приложения от таких изменений (и всегда ли такую защиту можно обеспечить). ° Представление числовых данных Числовое поле может храниться во внутренней арифметической форме (например, в упакованном десятичном формате) или в виде символьной строки.
В каждом случае АБД должен определить подходящее основание системы счисления (например, двоичную или десятичную систему), масштаб (число с фиксированной или плавающей запятой), тип (действительное число или комплексное) и точность (количество цифр). Каждый из этих параметров может быть изменен с целью повышения производительности, при введении нового стандарта или по некоторым другим причинам. Глава 1. Базы данньгх и управление ими ° Представление символьных данных Поле в формате символьной строки может сохраняться с использованием любого из существующих наборов кодировки символов (например, АСС!1, ЕВСР!С, (1и!соде).
° Единицы измерения для числовых данных Единицы измерения числовых полей могут быть изменены, например дюймы могут быть' изменены на сантиметры, если приложение связано с процессами измерения. ° Кодирование данных В некоторых ситуациях может понадобиться представлять данные в хранилище кодированными значениями. В частности, поле "цвет детали", которое представлено в приложении как символьная строка (" красный", "голубой", "зеленый" ), может храниться в виде десятичной цифры в соответствии с некоторой таблицей перекодировки, например ! = "красный", 2 = "голубой" и т.д. ° Овеществление данных Используемое приложением логическое поле обычно действительно соответствует некоторому определенному хранимому полю (хотя, как мы видели ранее, могут существовать различия в типе данных, единицах и т.д.).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
