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