Администратор базы данных - кто он?

Е.З. Зиндер

Корпорация LVS, тел.(095)330-15-37,Российская Ассоциация пользователей ORACLE, ez@lvs.msk.su

5.1. Три варианта политики автоматизации
5.2. АБД в варианте "САМООБЕСПЕЧЕНИЕ"
5.3. АБД в варианте "ЗАКАЗЫ"
5.4. АБД в варианте "СМЕШАННЫЙ"

6.1. Функции Группы АБД "полного" вида
6.2. Функции Группы АБД "локального" вида
6.3. Функции Группы АБД "растущего" вида

Кто такой Администратор Баз Данных - администратор в обычном понимании? Технический эксперт, почти не выходящий из своего кабинета, говорящий с другими работниками предприятия редко, неохотно и на непонятном языке? Главный хозяин всех данных в компьютерах предприятия? Может быть, это "просто" системный программист специфического профиля, находящийся под началом руководителя группы системных программистов отдела эксплуатации ВЦ предприятия? Очень плохо, если на вашем предприятии сложился один из таких вариантов. Это значило бы, что одна из краеугольных функций информационного обеспечения предприятия практически отсутствует или искажена до состояния, в котором неизбежно будет приносить вред. Вместе с тем вопрос это важный, часто - жизненно важный для предприятия. Ответ на него есть, хотя и не в виде единственного шаблона, применимого во всех случаях.

1. Введение

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

В качестве базовой технологии предполагается проектирование и использование интегрированных баз данных (БД), т.е. таких БД, которые накапливаются и поддерживаются в интересах многих пользователей и задач.

Кроме достоверности данных, интегрированные БД дают много других полезных эффектов. В организационном аспекте они являются одной из основ согласованного функционирования отделов и групп своего предприятия или отделения.

Основным механизмом при этом служат современные полномасштабные многопользовательские промышленные СУБД вне зависимости от их технических особенностей - ADABAS, IDMS, INGRES, ORACLE, UniVerse или др. (приведено в алфавитном порядке).

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

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

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

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

Общий план изложения таков:

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

2. Кто такой Администратор Базы Данных?

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

В СССР в начале 70-х годов к таким предприятиям относились, например, ЦЖБ МПС с его службой резервирования железнодорожных билетов на базе системы "Экспресс", или завод Автоваз с его системой учета и планирования производства.

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

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

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

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

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

Как и для каждого общего ресурса значительной важности, БД стала требовать отдельного управления, причем:

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

Функция управления БД получила название "администрирование базы данных".

Естественно, лицо, ответственное за администрирование БД, получило название "Администратор базы данных", или АБД.

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

3. АБД: классические подходы и практические коллизии

Классические подходы к наполнению содержанием понятия "АБД" стали формироваться после издания рабочего отчета группы по базам данных Американского Национального Института Стандартов ANSI/X3/SPARC в 1975 г. В этом отчете была описана трехуровневая архитектура СУБД, в которой выделялся уровень внешних схем данных, уровень концептуальной схемы данных и уровень схемы физического хранения данных. В соответствии с этой архитектурой определялись три роли АБД: администратор концептуальной схемы, администратор внешних схем и администратор хранения данных. Эти роли в случае очень маленькой системы мог играть один человек, в большой системе для выполнения каждой роли могла назначаться группа людей. Каждой роли соответствовал набор функций, а все эти функции вместе составляли функции АБД.

В 1980 - 1981 г. в американской литературе стало принятым включать в функции АБД:

• организационное и техническое планирование БД,
• проектирование БД,
• обеспечение поддержки разработок прикладных программ,
• управление эксплуатацией БД.

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

Ниже приведены три рисунка, показывающие рекомендуемый тогда состав Группы АБД, начиная с простых вариантов, характерных для начальной стадии работы АБД (рис. 1 и 2), вплоть до функционально структурированной, "зрелой" Группы АБД (рис. 3).

(Рисунки взяты из кн. Дж.-Л. Уэлдона "Администрирование баз данных", Москва, "Финансы и статистика", 1984; перевод издания 1981 г., Plenum Press, New York.)

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

Практически в те же годы эти описания организационных и технических аспектов работы АБД стали широко доступны отечественным руководителям и специалистам.

Но появление АБД на наших предприятиях часто сопровождалось большими трудностями:

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

Может быть, и по этим причинам, но первое определение АБД в ГОСТ-ах задало слишком узкий состав функций АБД:

• подготовка вычислительного комплекса к установке СУБД, участие в установке и приемке СУБД и самой БД с комплексом прикладных программ,
• управление эксплуатацией БД,
• подготовка словарей и другой НСИ - нормативно-справочной информации - к моменту начала испытания БД.

(Потенциально была возможна поддержка последующих разработок новых прикладных программ.)

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

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

4. Современные условия работы АБД

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

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

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

Часто сквозным инструментом предполагается инструментальный комплекс класса CASE (Computer Aided System/Software Engeneering - автоматизированная разработка систем и программ), интегрирующий инструменты разработки для всех стадий проекта.

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

• стратегическое планирование развития АС,
• детальный анализ функциональных и информационных потребностей,
• проектирование таблиц БД, прототипов экранных форм, печатных отчетов и др.

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

Основу состава такой группы составляют аналитики: так называемые прикладные аналитики (business analysts) и системные аналитики (system analysts), описание деятельности которых не входит в задачу данной статьи.

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

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

Обеспечение надежной и эффективной работы пользователей и программ с БД, поддержка разработчиков в их доступе к БД и средствам разработки реализует группа АБД.

В достаточно полный набор функций АБД входит:

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

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

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

г) организация работы с БД, находящейся на удаленном компьютере, работы с распределенной БД, т.е. размещенной на нескольких компьютерных центрах (узлах, "нодах"),

д) сбор статистики о работе СУБД, ее настройка и настройка АС в целом для эффективной обработки данных и обслуживания пользователей,

е) участие в планировании развития аппаратных и системных программных средств предприятия в связи с качественным и количественным ростом требований к АС,

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

з) подключение новых разработчиков и пользователей, приписывание им паролей, привилегий доступа к конкретным данным и др.,

и) участие в анализе попыток несанкционированного доступа к БД.

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

Из приведенного перечня ясно, что АБД:

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

Надежность и достоверность - ключевые понятия в деятельности АБД. Он должен уметь (лучше - и любить!) вести тщательное документирование всех действий по управлению базой данных.

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

5. Виды и роли АБД в зависимости от политики автоматизации предприятия. Место в оргструктуре предприятия

5.1. Три варианта политики автоматизации

АБД не всегда выполняет все функции, указанные выше - с а) до и). Их состав зависит от политики автоматизации, проводимой на предприятии. Рассмотрим три варианта политики:

в1) "САМООБЕСПЕЧЕНИЕ": предприятие полностью самостоятельно ведет разработку АС поддержки своей деятельности (за исключением поставки таких программных систем, как операционные системы, СУБД, системы программирования и другие средства разработчиков, а также их техническое сопровождение);

в2) "ЗАКАЗЫ": предприятие закупает полностью готовый проект АС и его дальнейшую адаптацию для себя, включая проект БД, процедуры ее сопровождения и дальнейшего развития;

в3) "СМЕШАННЫЙ", при котором начальная версия системы с ее настройкой на предприятие закупается, а дальнейшее, относительно небольшое развитие и приспособление делается на предприятии при поддержке разработчиков.

5.2. АБД в варианте "САМООБЕСПЕЧЕНИЕ"

Для варианта "САМООБЕСПЕЧЕНИЕ" АБД выполняет наибольший набор функций, причем в стартовый момент они могут быть практически такими же, как и впоследствии (хотя возможен рост набора функций в связи с развитием самой АС).

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

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

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

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

Можно отметить такой факт: уже после того, как статья была практически готова, автор обнаружил, что приведенная структура и последующие описания функций для "полного" варианта АБД, изложенные с учетом современных технологий, практически соответствуют методике организации и выполнения работ по созданию БД, разработанной автором и группой его коллег по заказу МПС в 1979 году. (Там в число групп проектирования АС входили две отдельные группы: аналитиков-конструкторов и прикладных программистов. Практикуются и другие варианты организации разработчиков, но этот вопрос не входит в предмет статьи.) Эта, достаточно полная методика (объем - 240 стр.) составила РТМ-10/79 МПС по разработке банков данных для всех категорий персонала, шагов разработки и сопровождения БД. В 1980 году она была запрошена в ряд других отраслей и предприятий, выпущена как их отраслевые материалы.

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

5.3. АБД в варианте "ЗАКАЗЫ"

Для варианта "ЗАКАЗЫ" АБД выполняет наименьший набор функций, причем впоследствии они могут остаться такими же, как и в стартовый момент. В этом варианте часто требуется всего два-три специалиста в Группе АБД, особенно в сравнительно небольших, компактных по числу пользователей и территорий АС.

Практически никогда не применяется дальнейшее внутреннее деление Группы.

АБД такого "локального" вида обычно играет менее активную роль на предприятии. По существу это неверно, так как решения должны приниматься во многом по тем же вопросам, что и в случае "САМООБЕСПЕЧЕНИЯ", хотя их реализация в меньшей мере выполняется силами предприятия. Поэтому и в варианте "ЗАКАЗЫ" АБД должен играть важную роль эксперта вплоть до участия в совещаниях самого высокого уровня.

Вместе с тем в этом случае в оргструктуре предприятия АБД часто находится на уровень ниже, непосредственно подчиняясь руководителю, отвечающему за эксплуатацию АС предприятия. Обозначим его РЭАС - "Руководитель, Эксплуатация АС" - и используем это обозначение в последующем. Обычно РЭАС - это начальник ВЦ предприятия, поскольку часто именно так называется и организуется подразделение, главным результатом которого является эксплуатация автоматизированных систем и компьютеров.

Заметим, что по многим оценкам включение в штат ВЦ разработчиков АС побуждает их к большей консервативности, а через какое-то время становится тормозом в использовании новых подходов и внедрении новых систем. (Это важно для общей картины, так как в случае варианта "ЗАКАЗЫ" предприятие не имеет или практически не имеет своих разработчиков.)

Надо сказать, что подчинение АБД Руководителю эксплуатации АС может приводить к негативным последствиям, которые описаны выше, для включения разработчиков в ВЦ, основной функцией которого является эксплуатация АС. И здесь многое зависит от личных качеств РИО, РЭАС и АБД, а так же от традиций предприятия.

5.4. АБД в варианте "СМЕШАННЫЙ"

Для варианта "СМЕШАННЫЙ" АБД выполняет тот же набор функций, что и для "САМООБЕСПЕЧЕНИЯ", но их состав дорастает до такого состояния постепенно. В стартовый момент они практически такие же, как и в варианте "ЗАКАЗЫ", хотя функции поддержки разработчиков, настройки СУБД и др. должны планироваться сразу, а, значит, должно сразу планироваться и обучение АБД в специализированных учебных центрах поставщика СУБД или разработчика АС.

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

АБД такого "растущего" вида также должен играть активную роль на предприятии вплоть до участия в совещаниях самого высокого уровня.

В оргструктуре предприятия АБД з непосредственно подчинен РИО - "Руководителю информационного обеспечения". Для иллюстрации может использоваться рис. 4.

6. Функции Группы АБД в зависимости от осуществляемой политики автоматизации, возможный состав Группы

6.1. Функции Группы АБД "полного" вида

Вариант "САМООБЕСПЕЧЕНИЕ": предприятие самостоятельно ведет разработку АС, что требует выполнения всех функций, указанных выше в разделе 4: с а) до и).

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

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

От особенностей предприятия, АС и степени владения специалистами группы АБД теми или иными вопросами зависит - правда, в небольшой части - приписывание некоторых функций конкретной группе в составе АБД. В наибольшей степени это относится к двум видам функций: участие в логическом и физическом проектировании БД может быть приписано либо группе Установки и экспертирования СУБД, либо группе Управления доступом; консультирование разработчиков и пользователей особенностям версии СУБД и программных инструментов может быть поручено этим же группам или распределено между всеми тремя.

Обязательное требование - активное и доброжелательное консультирование, которое выполняли бы все специалисты Группы АБД.

6.2. Функции Группы АБД "локального" вида

Вариант "ЗАКАЗЫ": предприятие закупает готовый проект АС и его дальнейшую адаптацию, включая проект БД, процедуры ее сопровождения и дальнейшего развития.

В этом случае АБД как минимум выполняет следующие функции:

д) сбор статистики о работе СУБД, ее настройка и настройка АС в целом для эффективной обработки данных и обслуживания пользователей,

е) участие в планировании развития аппаратных и системных программных средств предприятия в связи с качественным и количественным ростом требований к АС,

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

и) участие в анализе попыток несанкционированного доступа к БД (если эта функция предусматривается в системе).

Кроме того, АБД принимает участие в приемке готовой АС и в рамках этой работы, в объеме, соответствующем приемке, выполняет функции:

б) установка СУБД, программных инструментов разработки АС и инструментов пользователей для прямой работы с БД,

в) планирование использования запоминающих устройств компьютера (дисков, основной памяти, лент),

г) организация работы с БД, находящейся на удаленном компьютере, работы с распределенной БД,

ж) составление процедур для начальной загрузки данных, копирования и восстановления БД и т.п.; передача этих процедур эксплуатационному персоналу,

Как говорилось ранее, в этом случае Группа АБД может далее не структурироваться. Вариант устройства АБД такого "локального" вида показан на рис. 7, причем не самый маленький вариант такой группы (как говорилось ранее, многое зависит от размеров и напряженности работы АС).

6.3. Функции Группы АБД "растущего" вида

Вариант "СМЕШАННЫЙ", при котором начальная версия системы с ее настройкой на предприятие закупается, а дальнейшее, относительно небольшое развитие и приспособление делается на предприятии при поддержке разработчиков.

В соответствии с описанием такого варианта, изложенным выше, а так же в соответствии с реальными объемами доработок, сложностью АС и т.п., Группа АБД и ее функции занимают промежуточное состояние между Группами "локального" и "полного" видов, показанных на рис. 6 и рис, 7 соответственно. Обычно, с течением времени происходит рост использования АС, процессы ее развития и эксплуатации усложняются, а сама Группа АБД развивается вплоть до зрелой Группы "полного" вида.

7. Другие виды администрирования, связанные с базами данных

Существуют и другие виды администрирования, которые чаще всего рассматриваются отдельно от АБД, хотя и тесно с ним связаны. К таким функциям можно отнести:

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

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

8. Заключение

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

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

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

Численный состав Группы АБД зависит в большей степени от компактности Автоматизированной Системы предприятия и способности специалистов Группы совмещать различные функции.

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

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