2.6. Отображения

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

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

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

Замечание. Очевидно, что как отображение концептуальный-внутренний является ключом к физической независимости данных, так и отображения внешний-концептуальный являются ключом к логической независимости данных. Как было показано в главе 1, система обеспечивает физическую независимость данных [2.3], если пользователи и пользовательские программы обладают иммунитетом к изменениям в физической структуре хранимой базы данных. Аналогично система обеспечивает логическую независимость данных [1.4], если пользователи и пользовательские программы обладают иммунитетом к изменениям в логической структуре базы данных (подразумеваются изменения на концептуальном или общем логическом уровне). Этот важный вопрос будет обсуждаться в главах 3 и 9.

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

2.7. Ад11инистратор базы данных

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

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

Определение концептуальной схемы

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

Замечание. На практике редко все происходит точно по описанной выше схеме. Иногда сам АД создает концептуальную схему, а иногда АБД занимается логическим проектированием.

Определение внутренней схемы

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

Взаимодействие с пользователями

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

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

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

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

Определение требований защиты и обеспечения целостности данных

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

Определение процедур резервного копирования и восстановления

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

Помимо всего прочего, требование быстрого восстановления поврежденных данных является одной из тех причин, по которым желательно организовать хранение данных не в каком-либо одном месте, а распределить их в нескольких отдельных базах данных. Каждая из таких баз данных будет представлять собой оптимальный объект выгрузки или перезагрузки. В этой связи отметим, что терабайтные системы (т.е., грубо говоря, коммерческие системы, хранящие более триллиона байтов данных) уже существуют, а в будущем системы будут еще больше. Понятно, что такие системы очень больших баз данных (VLDB - very large database) требуют тщательного и продуманного администрирования, в особенности если необходимо обеспечить для пользователей постоянный доступ к базе данных (а часто именно так и бывает). Однако для простоты рассуждений будем по-прежнему подразумевать, что мы имеем дело с единственной базой данных.

Управление производительностью и реагирование на изменяющиеся требования

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

1024 байт = 1 Кбайт (килобайт); 1024 Кбайт = 1 Мбайт (мегабайт); 1024 Мбайт = 1 Гбайт (гигабайт); 1024 Гбайт = 1 Тбайт (терабайт); 1024 Тбайт = 1 Пбайт (петабайт); 1024 Пбайт = 1 Ебайт (эксабайт). Отметим, что, поскольку гигабайт равен приблизительно миллиарду (billion) байтов, вместо сокращения Мбайт иногда используют сокращение Ббайт . Кстати, вопреки распространенному мнению, английское слово gigabyte произносится с мягким начальным g ( jigabyte ).