 |
  |
|||
 |
 |
 |
||
 |
|
 |
||
Издатель: Algorithm Online При поддержке ORACLE в России  Техническая поддержка  официальный дистрибутор ORACLE |
|
|
Несколько мыслей о том, чем занимаются Администраторы, АБД и Архитекторы Данных1 июня 2000 г. Some Thoughts on Data Administrators, DBAs, and Data Architects, by Tom Cox, ORACLE INTEGRATOR, vol.7, No.2, march/april 1996 Том Кокс
[От научного редактора “Мир Oracle” Анатолия Бачина. Эта статья имеет серьезное методологическое значение. Во-первых, вводятся в оборот довольно новые понятия “Администратор Данных” (Data Administrator), как профессиональная квалификация, и “владение данными” (Data Ownership). В связи с этим хочу обратить внимание на статью К.Люни “Роли системного уровня” (“Мир Oracle”, 3/95), где прописана роль APPLICATION OWNER (владелец приложения), исполнитель которой не имеет никаких привилегий (даже входа в базу!), но является владельцем и распределителем полномочий доступа ко всем объектам приложения в базе данных. Во-вторых, сведенное в таблицы распределение функций и задач администраторов различных этапов жизненного цикла базы данных может послужить ценным источником информации для всех специалистов, профессионально связанных с жизнедеятельностью базы данных, от аналитиков до прикладных программистов и конечных пользователей. Особенно хочу обратить внимание на эти таблицы менеджеров высшего уровня, отвечающих за интересы своих компаний в целом, поскольку по современным понятием (и Т.Кокс это отмечает) информация уже давно является капиталом. Где же взять столько системных администраторов?! (Я ведь еще не назвал системных программистов по ОС и ВС. Они совершенно необходимы!) Счастьем это не назовешь, но жизнь такова, что одни и те же лица вынуждены играть по несколько системных ролей. Хорошо хоть, в разное время и в близких предметных областях. Все более высокими становятся требования к их квалификации, а опыт и умение приходят с годами. И поскольку очевидно, что высокая квалификация сотрудников также является частью богатства и могущества организации, ее необходимо поощрять и поддерживать. В системном администрировании выгоднее брать не числом, а умением и постоянным стремлением к все новому знанию.] В сфере консалтинга Oracle существуют серьезные расхождения в понимании того, что же представляет собой АБД. Многие хотят нанять АБД Oracle, нет отбоя от рекламных объявлений, я еженедельно получаю просьбы от фирм по подбору кадров (headhunters), спрашивающих, не соглашусь ли я стать “АБД Oracle” для их клиентов. Но если спросить, что же они вменяют в обязанности АБД, то Вы получите в ответ ужасную путаницу задач, многие из которых полностью находятся вне сферы деятельности администрации базы данных. Существует три различных набора задач, выполняемых на базе данных: (1) задачи администрирования данными (Data Administration tasks); Довольно часто встречается ситуация, когда один человек выполняет задачи двух или даже всех трех разделов. АБД, например, может решать задачи архитектуры в период разработки, но эти области деятельности все же различны. Ясно одно, что эти различные задачи имеют место на различных стадиях жизненного цикла базы данных. В большинстве случаев новая база данных создается для поддержки нового или настолько существенно измененного приложения, что старая база данных уже не может быть использована. Для того, чтобы создать подходящую базу данных, некто должен проанализировать приложение и спроектировать соответствующие таблицы. Последнее совершается или посредством построения модели “сущность-связь”, на которой и проектируются таблицы, или непосредственным [эмпирическим образом] моделированием таблиц. Задача проектирования таблиц (Designing Tables) подпадает под начало архитектуры данных (Data Architect). Другие задачи архитектуры данных включают конкретный анализ (Impact Analysis – пристальный анализ), который имеет место, когда приложение требует изменения и должны быть определены необходимые изменения таблиц. Между тем, должна быть четко осознана ставшая насущной жизненная реальность, что информация - это сила [прим. редактора: я бы добавил, могущество и богатство]. Поэтому данные в базе данных должны кому-то принадлежать. И этой персоной является Администратор Данных (Data Administrator). Он устанавливает, кто владеет определенными элементами данных и кто что получает право создавать, изменять и уничтожать. Например, если в базе данных ведется копия основного ценника (master price list) продукции корпорации, то кто ответственен за поддержание этой копии в актуализированном состоянии? Если это возложено на владельца ценника, то кто тогда должен осуществлять изменения? Если эта ответственность возложена на владельца приложения, то кто тогда собирает и выполняет (polls and pulls) изменения? Обладают ли соответствующие исполнители полномочиями, чтобы прочитать какие следует данные? (Я не могу выполнить изменения в ценнике, если я не могу прочитать его.) Администратор Данных должен застолбить “владение данными” (Data Ownership) по элементам данных - задача, независимая от проектирования таблиц (Архитектура). Эта задача также независима от деталей размещения данных по конкретным дискам (АБД).
Каждый раз, когда приложение требует изменения, Администратор Данных должен выполнить функцию “управление изменениями” (Change Management), чтобы и далее гарантировать принадлежность данных соответствующим персонам, а эти люди должны быть уведомлены о факте произведенного действия. После того, как таблицы спроектированы, наступает время их создания (Table Creation). Это включает в себя планирование пространства, отработку параметров распределения памяти (на основе объемностных характеристик, предоставленных Архитектором на базе анализа приложения), и первую примерку распределения данных по дискам в целях сбалансированной их загрузки. АБД должен определить количество создаваемых табличных пространств, где и сколько надо построить файлов данных. Он также должен нести ответственность за создание плана процедур резервирования/восстановления (Backup and Recovery Planing). Если создание базы данных следует методике OFA (Optimal Flexible Architecture - Оптимальная гибкая архитектура), тогда АБД должен реализовать соглашения OFA относительно размещения файлов данных. Качественные различияНекоторые авторы единственно отмечают различия между Архитекторами и АБД, основываясь на том, что Архитекторы исключительно имеют дело с логическими конструкциями (сущности, связи, проекты таблиц), тогда как АБД исключительно имеют дело с физическими структурами (файлы данных, баланс дисковой загрузки, резервирование/восстановление). В такой постановке вопроса имеется изрядная доля истины, но таится и определенная опасность. Очень здраво звучит мысль, что персонам, исполняющим функции Архитектора, следует обладать определенными знаниями о том, как физически организована база данных, потому что конструкции, созданные грамотным в этой области специалистом, вероятно, будут легче для построения и управления. [Прим. редактора: от всей души и других внутренних органов горячо поддерживаю Т.Кокса, потому что в качестве АБД испытал на собственном опыте, насколько не просто разговаривать с аналитиками и проектировщиками; ну, вероятно, и им со мной бывает также не просто.] В автомобильной индустрии это известно под названием “промышленное проектирование” (“designing for manufacturability”). Представьте себе, что проектировщик выбирает между двумя возможностями, которые функционально эквивалентны, но так уж случается, что одна из них настолько просто реализуется, что не требует воплощения в виде программного кода. Если проектировщик не понимает производственных вопросов, тогда он не имеет необходимой информации для выбора более дешевой опции. Я достаточно удачлив в том, что несколько моих разработок благополучно прошли путь от начальной идеи до полного воплощения. Это многому меня научило в области промышленного проектирования. Ничто не заменит подобного опыта. Оборотной стороной этого вопроса является опасность погружения АБД в роль проектировщика. Я знаю несколько человек, которые пытались так перевоплотиться. Так вот они обычно конструировали объекты с единственным уклоном на легкость управления и недостаточно подчеркивали функциональные требования приложения. Такие проекты обычно не оправдывают надежд. Следующая ниже таблица классифицирует задачи жизненного цикла базы данных по областям задач. Коль скоро мы начали понимать качественные различия в этих задачах, возможно, надо выбирать и наиболее подходящих людей, которые в большей степени искусны к работам и задачам, требующим подобной квалификации. Результатом будет лучшее качество программного обеспечения, лучше работающие базы данных, более удачные проекты.
Об авторе: Томас Кокс (Thomas Cox) - автор книги “Oracle Workgroup Server Handbook”, директор в области технологии фирмы True North Consulting. Его можно разыскать по tcox@aol.com или по телефону (503) 220-1790. 
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Письмо в редакцию