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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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