Треугольник паскаля его свойства и приложения

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

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

     АБД имеет код специальности по общероссийскому  классификатору профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР) — 40064 и код 2139 по Общероссийскому  классификатору занятий (ОКЗ). Код 2139 ОКЗ  расшифровывается следующим образом: 2 - СПЕЦИАЛИСТЫ ВЫСШЕГО УРОВНЯ КВАЛИФИКАЦИИ, 21 - Специалисты в области естественных* и инженерных наук, 213 - Специалисты по компьютерам, 2139 - Специалисты по компьютерам, не вошедшие в другие группы.

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

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

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

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

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

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

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

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

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

БД требует  управления для обеспечения ее повседневной эксплуатации,

БД развивается, отвечая изменениям в потребностях предприятия, и требуется управление ее развитием,

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

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

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

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

Основные  задачи администратора базы данных

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

• Проектирование базы данных.
• Оптимизация производительности базы данных.
• Обеспечение и контроль доступа к базе данных.
• Обеспечение безопасности в базе данных.
• Резервирование и восстановление базы данных.
• Обеспечение целостности баз данных.
• Обеспечение перехода на новую версию СУБД.

Основные  типы администраторов  БД

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

• Системный администратор.
• Архитектор БД.
• Аналитик БД.
• Разработчик моделей данных.
• Администратор приложении.
• Проблемно-ориентированный администратор БД.
• Аналитик производительности.
• Администратор хранилища данных.

 
 
 
 

Глава 2. Примеры проектирования и администратирования баз данных.

§2.1.Урок 1: Классические подходы в АБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§2.2. Урок 2: Современные условия работы АБД

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

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

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

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

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

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