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


Содержание

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

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

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

1. Администрирование предметной области: поддержка представления БД на концептуальном уровне архитектуры СУБД (общем для всех приложений); адекватное отображение в БД изменений, происходящих в ПО. Последнее требование может подразумевать реструктуризацию (изменение схемы) БД и последующее приведение содержимого БД в соот-ветствие с новой схемой.

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

o изменения в структуре хранимых данных, например, выведение в отдельную таблицу редко используемых данных;

o изменения способов размещения данных в памяти, например:

§ разбиение таблицы на части для распределения её по различным фи-зическим носителям с целью распараллеливания доступа к ней;

§ построение кластеров (раздел 4.5);

§ изменение физических параметров среды хранения, например, размера блока данных в пространстве памяти.

o изменения используемых методов доступа к данным, например, построение индексов или введение хеширования (раздел 4.5).

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

4. Администрирование безопасности данных: предоставление пользователям прав на доступ к БД и настройка системных средств защиты от несанкцио-нированного доступа.

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

Словарь-справочник данных

Словарь-справочник данных (ССД) – это программная система, предназначенная для централизованного хранения и использования описания объектов БД (метаданных). Иногда ССД называют каталогом данных. Эта система содержит сведения:

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

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

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

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

Множества метаданных словаря и справочника в значительной мере пересекаются. Более того, они могут реализовываться совместно: во многих РСУБД словарь состоит из таблиц (table), содержащих описание объектов БД, а справочник реализуется с помощью представлений (view) над таблицами словаря.

Далее мы познакомимся с теми механизмами, с помощью которых в СУБД организуется хранение данных и доступ к ним.

«В действительности всё выглядит иначе, чем на самом деле».
Станислав Ежи Лец, польский поэт, участник Сопротивления

Язык SQL. Изучение одной из современных СУБД по выбору — Microsoft SQL Server

Введение в SQL

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

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

Появление теории реляционных БД дало толчок к разработке ряда языков запросов, которые можно отнести к двум классам:

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

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

В 1987 году SQL стал стандартом языков для профессиональных реляционных СУБД и начал внедряться во все распространенные системы. Это связано с рядом следующих моментов. Постоянный рост быстродействия, а также снижение энергопотребления, размеров и стоимости компьютеров привели к резкому расширению возможных рынков их сбыта, круга пользователей, разнообразия типов и цен. Естественно, что расширился спрос на разнообразное программное обеспечение. В борьбе за покупателя фирмы, производящие программное обеспечение, стали выпускать на рынок все более интеллектуальные, а значит, объемные программные комплексы. Приобретая их. многие организации и отдельные пользователи часто не могли разместить их на собственных ЭВМ. Для обмена информацией и ее распространения были созданы сети ЭВМ, где обобщающие программы и данные стали размещать на специальных файловых серверах.

СУБД, работающие с файловыми серверами, позволяют множеству пользователей разных ЭВМ, расположенных достаточно далеко друг от друга, получать доступ к одним и тем же БД. При этом упрощается разработка различных автоматизированных систем управления организациями, учебных комплексов, информационных и других систем, где множество сотрудников или учащихся должны использовать общие данные и обмениваться создаваемой в процессе работы информацией. Однако при таком подходе вся обработка запросов из программ или с терминалов пользовательских ЭВМ на них и выполняется, поэтому для реализации даже простого запроса необходимо считывать из файлового сервера или записывать на сервер целые файлы, а это ведет к конфликтным ситуациям и перегрузке сети, Для исключения указанных недостатков была предложена технология клиент/сервер, однако при этом нужен единый язык общения с сервером — и в его качестве был выбран SQL.

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

предложения определения данных — определение БД, а также определение и уничтожение таблиц и индексов;

запросы на выбор данных — предложение SELECT;

предложения модификации данных — добавление, удаление и изменение данных;

предложения управления данными — предоставление и отмена привилегий на доступ к данным, управление транзакциями и другие.

Кроме того. SQL предоставляет возможность выполнять в этих предложениях:

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

— упорядочение строк или столбцов при выводе содержимого таблиц на печать или экран дисплея;

— создание представлений, позволяющих пользователям интерпретировать данные без увеличения их объема в БД;

— сохранение выводимого по запросу содержимого таблицы, нескольких таблиц или представления в другой таблице;

— группирование данных и применение к этим группам таких операций, как среднее, сумма, максимум, минимум, число элементов и т.п.

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

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

Основные достоинства языка SQL заключается в следующем:

— стандартность языка SQL — как уже было сказано, его использование в программах стандартизировано международными организациями;

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

— возможность переноса с одной вычислительной системы я другую — СУБД может быть ориентирована на различны, вычислительные системы, однако приложения, созданные с помощью SQL, допускают использование как для локальных БД так и для крупных многопользовательских систем;

— реляционная основа языка — SQL является языком реляционных БД, поэтому он стал популярным тогда- когда популярной стала реляционная модель представления данных. Табличная структура реляционной БД хорошо понятна, поэтому язык SQL является простым и легким для изучения;

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

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

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

— поддержка архитектуры клиент/сервер — SQL одно из лучших средств для реализации приложений на платформе клиент/сервер. При этом SQL служит связующим звеном между клиентской системой, взаимодействующей с пользователем, и серверной системой, управляющей БД, позволяя каждой из них сосредоточиться на выполнении своих прямых функций

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

В SQL определены два подмножества языка:

· SQL-DDL (Data Definition Language) — язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.

· SQL-DML (Data Manipulation Language) — язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями

Здесь не дается строгое описание всех возможностей SQL-92. Во-первых, ни одна СУБД не поддерживает их в полной мере, а во-вторых, производители СУБД часто предлагают собственные расширения SQL, несовместимые друг с другом. Поэтому мы рассматриваем некое подмножество языка, которое дает общее представление о его специфике и возможностях. В то же время, этого подмножества достаточно, чтобы начать самостоятельную работу с любой СУБД. Более формальный (и более полный) обзор стандартов SQL сделан в статье С. Д. Кузнецова «Стандарты языка реляционных баз данных SQL: краткий обзор»,журнал СУБД N 2, 1996 г. Ознакомится с русским переводом стандарта SQL можно на сервере Центра информационных технологий, сравнительное описание различных версий языка (для СУБД Sybase SQL Server, Sybase SQL Anywhere, Microsoft SQL Server, Informix, Oracle Server) приводится в книге Дж.Боуман, С.Эмерсон, М.Дарновски «Практическое руководство по SQL», Киев, Диалектика, 1997.

Следует также отметить, что в отличие от «теретической» терминологии, используемой при описании реляционной модели (отношение, атрибут, кортеж), в литературе при описании SQL часто используется терминология «практическая» (соответственно — таблица, столбец, строка). Здесь мы следуем этой традиции.

Все примеры построены применительно к базе данных publications, содержащей сведения о публикациях (как печатных, так и электронных), относящихся к теме данного курса. Структуру этой базы данных можно посмотреть здесь, ее проектирование описано в разделе 5.4, доступ к ней для практических занятий можно получить через Internet посредством СУБД Leap (реляционная алгебра) или СУБД PostgreSQL. (язык SQL).

Администратор базы данных — это что за профессия?

Администратор базы данных – это специалист, который отвечает за разработку требований к различным базам данных организации. Он занимается проектированием, эффективным использованием, поддержанием целостности и сопровождением работы хранилища. Администратор управляет записями учетного типа и организует систему защиты от несанкционированного использования находящихся в базе сведений. Подробная характеристика этой специальности установлена в профстандарте «Администратор базы данных», утвержденном приказом Министерства по труду и социальной защите Российской Федерации № 647н от сентября 2014 года. Код специальности 40064.

Задачи администратора

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

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

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

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

Общие обязанности администратора

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

  1. Проведение постоянного копирования баз информации в резервном режиме. В случае постоянного сохранения данных при возникновении проблем с серверами или сетями все данные из информационной базы можно легко восстановить (или их бо́льшую часть).
  2. Регулярная работа по обновлению программного обеспечения. Информационные массивы часто обрабатываются не одной программой, а целым комплексом софта обслуживающего характера. Поэтому при постоянном обновлении программного обеспечения от администратора баз данных требуется наличие знаний об особенностях различных программных услуг, протоколов (сетевых), а также наличие навыков по программированию на разных компьютерных языках. Кроме того, каждый администратор должен уметь самостоятельно написать утилиту, которая требуется в его деятельности.

Группы специфических обязанностей

Работа администратором предполагает выполнение помимо общих обязанностей, одной из пяти групп специфических функций:

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

Работа по обеспечению функционирования БД (баз данных) включает следующие обязанности.

  1. Копирование информации из базы в резервном режиме.
  2. Восстановление информации из базы данных.
  3. Управление вариантами доступа к информационным базам.
  4. Установка, настройка программного обеспечения для управления базами данных.
  5. Анализ событий, которые возникают при работе баз данных.
  6. Протоколирование и фиксация событий, которые возникают в процессе обработки информации в базах.

Оптимизация работы информационных баз включает следующие обязанности:

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


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

  1. Разработка положений о копировании информационных баз в резервном режиме.
  2. Контроль за выполнением положений о резервном копировании.
  3. Разработка планов по резервному копированию информационных баз.
  4. Разработка процедур создания информационных копий данных в резервном автоматическом режиме.
  5. Осуществление процедур по восстановлению данных после «обвалов» информации.
  6. Анализ происходящих в системе сбоев, выявление причин нарушений.
  7. Разработка инструкций и методических рекомендаций по обслуживанию баз данных.
  8. Исследование функционирования программно-аппаратного сопровождения баз данных.
  9. Настройка функционирования и работоспособности информационных баз.
  10. Разработка предложений о модернизации поддерживающих программно-аппаратных средств.
  11. Оценка и анализ рисков возникновения сбоев в деятельности информационных баз.
  12. Разработка способов автоматического резервирования информационных баз.
  13. Разработка процедур по введению режимов горячих замен данных.
  14. Составление отчетов о работе баз данных.
  15. Проведение консультаций для пользователей при эксплуатации информационных баз.
  16. Выработка предложений в области повышения квалификации работников.

Снабжение баз данных различными мерами безопасности включает следующие обязанности:

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

Управление расширением и развитие информационных баз с данными включает следующие обязанности.

  1. Анализ проблем в системе по обработке информации в базах данных и разработка предложений по развитию перспектив в работе баз данных.
  2. Составление регламентов по обновлению программного системного обеспечения в базах данных, информационных баз в новые варианты программного обеспечения и их сочетание с новыми платформами.
  3. Изучение и внедрение на практике новых вариантов и способов работы с информационными базами.
  4. Отслеживание обновлений вариантов информационных баз.
  5. Отслеживание внедрения хранилищ информации и их сочетаемость с новыми платформами и новыми версиями программного обеспечения.
  6. Разработка и создание структуры подразделений, развитие кадрового резерва.

Проблемно ориентированный администратор

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

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

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

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

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

Алгоритм деятельности проблемно ориентированного сетевого управленца сводится к следующему:

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

Аналитик производительности

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

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

Администратор хранилища системных данных

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

Обязанности администратора хранилища данных заключаются в следующем:

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

Требования к администраторам

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

Помимо наличия соответствующего образования, важными требованиями являются следующие:

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

Результаты обучения

Несмотря на среднюю зарплату, к администратору баз данных при выпуске предъявляются серьезные требования. К ним относятся следующие:

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

Курсы по повышению квалификации

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

Специальности, по которым можно повысить квалификацию администратора базы данных это:

  • разработка моделей массивов информации;
  • архитектор информационных сетевых баз;
  • администратор в сфере базы данных по программе 1С по различным направлениям;
  • администрирование сетевого характера;
  • администратор в сфере базы данных по программе Microsoft SQL;
  • управление процессами хранения информации.

Заработная плата администратора

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

По данным анализа ситуации, в стране был выявлен средний уровень заработной платы специалистов в сфере администрирования информации.

По итогам 2020 года было установлено, что зарплата администратора баз данных выражается в следующих цифрах:

  • Москва – от ста десяти до ста шестидесяти тысяч рублей;
  • Санкт-Петербург – от семидесяти семи до ста тысяч рублей;
  • в регионах – от сорока до семидесяти пяти тысяч рублей.

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

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

Что учить администратору баз данных?

Гуглить по слову DBA и нужная база

Как человек в этом году неожиданно сменивший деятельность с senior php dev на DBA — хочу задать встречный вопрос:
а вы вообще видите вакансии на начинающего-студента-DBA? Целую одну или хотя бы даже две? Для увидевшего SQL вот только что студента и уже желающего быть DBA всего через пару месяцев? Человека, который даже не написал, какую именно СУБД ему интересно изучать до уровня DBA?

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

Илон Маск рекомендует:  Что такое код asp serverstate

Я не знаю как стать DBA с нуля. Похоже DBA становятся только имея за плечами заметный опыт администрирования или разработки.

Определитесь с конкретной СУБД и прочитайте полностью её мануал. Например мануал postgresql 10 в pdf занимает свыше 3 тысяч страниц A4. На пару месяцев этого уже хватит. А это только мануал. Только по непосредственно СУБД.
Плюс необходимо знать базовое администрирование той ОС под которой эта СУБД используется (например, я как postgresql dba даже близко не представляю что делать с windows — такая экзотика в жизни не встречается. А вот для MS SQL наверняка необязательно разбираться в linux).
Плюс теория: реляционная логика, обеспечение транзакционного, конкурентного доступа, восстановление после сбоев
Плюс практика — активность в профильных сообществах, форумах. Читаете, проверяете, запоминаете, вежливо переспрашиваете в комментариях если вам кажется что предыдущий отвечающий ошибся, отвечаете на вопросы.

Интересно? Вперёд. Но в DBA за 3 месяца из нулевого студента — не верю.


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

Читайте также:

  1. I. Краткое изложение данных истории болезни
  2. I. Краткое изложение данных истории болезни
  3. II. Основной файл исходных данных
  4. II. Основной файл исходных данных
  5. PDB-файлы (база данных по белкам)
  6. А.Чаще всего в качестве основания для оценки полученных в обследовании данных используется формальный критерий, связанный со статистическим подходом к пониманию нормы.
  7. Автоматизированные банки дорожных данных
  8. Администрирование
  9. Анализ данных в Excel
  10. Анализ исходных данных
  11. Анализ исходных данных для разработки технологического процесса

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

Это — администратор данных,или сокращенно АД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доминирующее положение в настоящее время занимают БД построенные на реляционной модели. Почти все продукты баз данных, созданные с конца 70-х годов, основаны на подходе, который называют реляционным (relational); более того, подавляющее большинство научных исследований в области баз данных в течение последних 25 лет проводилось в этом направлении. Что подразумевается под реляционной системой?

Реляционная система — это система, основанная на следующих принципах:

1) данные для пользователя передаются в виде таблиц (и никак иначе) ;

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

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

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

Основные термины, используемые при описании данных в реляционных системах.

ST_FAM
Сергей Иван и др.
S#
ST_NAME
AV_CNT
Домены
Первичный ключ
S# ST_FAM ST_NAME AV_CNT
S1 Степанов Руслан 4.1
S2 Иванов Иван 3.8
S3 Смирнов Сергей 4.18
S4 Губанов Владимир 3.7
S5 Толмачев Сергей 4.0
К а р д и ч н и а с л л ь о н о е
Отношение S
Кортежи
| |
Атрибуты

Отношение — Таблица;

Кортеж — строка таблицы,

атрибут — столбец;

Количество кортежей — кардинальное число;

Количество атрибутов — степень;

Первичный ключ — столбец или комбинация столбцов, такая, что в любой момент времени не существует двух строк, содержащих одинаковое значение в этом столбце или комбинации столбцов;

Домен —это общаясовокупность значений, из которой берутся настоящие значения для атрибутов определенного отношения.

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

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

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

На основании изложенного можно сделать вывод, что системы баз данных могут быть легко распределены по категориям в соответствии со структурами данных и операциями, которые они предоставляют пользователю. Прежде всего, старые (дореляционные) системы можно разделить на три большие категории: системы с инвертированными списками(inverted list), иерархические(hierarchic) и сетевые(network). <Примечание. Термин сетевая система в данном случае не имеет ничего общего с коммуникационной сетью.) Эти категории подробно рассматривать не будем , поскольку, их можно считать устаревшими.

Следует отметить, что сетевые системы иногда называют системами CODASYL или системами DBTG(Data Base Task Group) в честь предложившего их подразделения организации CODASYL (Conference on Data Systems Language). Пожалуй, наиболее известной из таких систем была IDMS корпорации Computer Associates International, Inc. Подобно иерархическим системам (но в отличие от реляционных), все подобные системы предоставляют пользователю доступ к указателям.

Первые реляционныепродукты начали появляться в конце 1970-х и начале 1980-х го-

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

DB2 (всевозможные версии) корпорации IBM;

Ingres II корпорации Computer Associates International, Inc.;

Informix Dynamic Server корпорации Informix Software, Inc.;

Microsoft SQL Server корпорации Microsoft;

Oracle 8i корпорации Oracle;

Sybase Adaptive Server компании Sybase, Inc.

В последнее время стали появляться объектно-ориентированныеи объектно-реляционныепродукты: первые объектные системы были выпущены в конце 1980-х и начале 1990-х годов, а объектно-реляционныесистемы были созданы в конце 1990-х годов. Большинство объектно-реляционных СУБД основываются на расширенных оригинальных реляционных продуктах, как в случае с DB2 или Informix. Существующие объектно-ориентированные системы иногда представляют собой попытки создать нечто совершенно отличное от других систем, как это имеет место в случае с системой GemStone корпорации GemStone Systems, Inc. и системой Versant ODBMS компании Versant Object Technology.

В дополнение к различным уже упоминавшимся выше подходам, в течение нескольких лет проводились исследования множества альтернативных схем, включая многомерный(multi-dimensional) подход и логический(logic-based) подход, называемый еще дедуктивным или экспертным. Кроме того, в связи с наблюдающимся в последнее время стремительным ростом World Wide Web и расширением области применения языка XML, проявляется значительный интерес к направлению научной деятельности, которое получило (не совсем удачное) название полуструктурированный подход.

Рассмотрим основные подсистемы реляционной СУБД (RDBMS);

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

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

На рисунке показаны основные подсистемы ядра СУБД.

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

Управление хранением данных во внешней памяти

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

Транзакция — это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

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

С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций.

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

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

Oпределение ACID и стоящие за ним свойства.

  • Atomicity — транзакции атомарны, то есть либо все изменения транзакции фиксируются (commit), либо все откатываются (rollback);
  • Consistency — транзакции не нарушают согласованность данных, то есть они переводят базу данных из одного корректного состояния в другое. Тут можно упомянуть допустимые значения полей, внешние ключи и более сложные ограничения целостности;
  • Isolation — работающие одновременно транзакции не влияют друг на друга, то есть многопоточная обработка транзакций производится таким образом, чтобы результат их параллельного исполнения соответствовал результату их последовательного исполнения;
  • Durability — если транзакция была успешно завершена, никакое внешнее событие не должно привести к потере совершенных ей изменений.

Каждое из этих требований выглядит более чем рациональным, особенно если оно затрагивает такие важные сферы, как банковские операции и другие операции с валютой: согласитесь, будет очень неприятно, если с вашего счета деньги спишутся, а на счет магазина они не придут (нарушение «atomicity»), или в результате сбоя будет потеряна информация о том, что вам на счет зачислили зарплату (нарушение «durability»).

Если начать рассуждать о том, как же работают СУБД, поддерживающие ACID транзакции, больше всего вопросов вызовет свойство Isolation: современные СУБД поддерживают сотни и тысячи одновременных транзакций, и все они обращаются к одним и тем же таблицам. Как же сделать так, чтобы они друг другу не мешали? Здесь на помощь приходит MVCC (MultiVersion Concurrency Control), то есть контроль конкурентного доступа к данным через создание множества “версий” изменяемых данных. В упрощенном виде этот механизм можно представить следующим образом: все операции с данными можно условно разделить на чтение (select), вставку (insert), удаление (delete), обновление (update). Вот что происходит при этих операциях:

  • Select — считываются валидные записи таблицы. Запись считается валидной, если она создана транзакцией, которая была зафиксирована (commit) до начала текущей транзакции;
  • Insert — новая запись просто добавляется в свободное место таблицы;
  • Delete — запись в таблице помечается как не валидная, при этом сама запись не удаляется;
  • Update — комбинация delete и insert. Сначала старая версия записи помечается как не валидная, затем добавляется новая запись с обновленными данными.

В целом, указанный подход можно реализовать при помощи всего одного дополнительного бита с флагом is_val >

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

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

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

Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log — WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

  1. Дайте определение базы данных.
  2. Что является компонентами базы данных.
  3. Перечислите основные понятия реляционной модели данных.
  4. Назовите основные подсистемы реляционной СУБД.

Дата добавления: 2015-06-25 ; Просмотров: 2242 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

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

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

Среди моих работ есть доклад, называющийся «Роль администратора БД», который я иногда читаю, если ко мне обращаются с просьбой провести презентацию тематического характера. Мне кажется, что предлагаемый материал может оказаться довольно полезным для членов сообщества Oracle Professional . Статья дает общее представление о том, чем занимается администратор БД, его обязанностях и специализации относительно реляционных БД Oracle. По окончании доклада многие слушатели подходят ко мне со словами: «Как жаль что здесь нет моего начальника, чтобы он мог это услышать». Так вот теперь он сможет это прочитать!


Должностная инструкция

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

Илон Маск рекомендует:  Предопределённые константы ldap

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

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

Стереотип администратора

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

История администрирования БД Oracle

Платформа Oracle не всегда была такой “ навороченной ” . Во времена Oracle V4 администратор БД зачастую оставался лишь разработчиком. Едиственным способом резервирования данных было «холодное» резервирование, то есть копирование всего программного обеспечения БД Oracle и файлов данных только при «выключенной» БД. Выход Oracle V5 и появление SQL*net ознаменовали собой развитие нового подхода клиент-сервер. Кроме того, в Oracle V5 были включены дополнительные средства настойки, такие как explain plan , средства аудита и тому подобное. В помощь администратору БД предоставлялся ряд дополнительных функций, призванных облегчить его работу. Начиная с Oracle V6 стало происходить разделение администраторов по специализациям. Корпорация Oracle выпустила целый пакет приложений; внедрила параллельный сервер; размеры баз данных можно было уже смело охарактеризовать, как очень большие; по этим причинам системой становилось все труднее управлять, что еще более усугубялось наличием ошибок и разрушением данных. Кроме того, в Oracle V6 впервые были введены триггеры и язык PL/SQL, а заинтересованной общественности представлен механизм репликации. Сложность же пакета Oracle V7 достигла небывалых до той поры высот, воплотив понятие целостности ссылочных данных или отношения первичный/внешний ключ на уровне БД. Это позволило упростить написание приложений , однако добавило лишней головной боли администраторам БД. Oracle V8, в свою очередь, познакомил всех с разбиением таблиц и индексов, и массой новых средств индексации. Oracle8i поднял планку еще выше благодаря поддержке файловой системы Интернет, Java-триггеров и т . д.

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

Обязанности администратора

Что касается обязанностей администратора БД, то у него их множество. Среди наиболее важных — резервное копирование и воостановление информации. Механизм резервирования и восстановления данных обязан учитывать зависимость бизнеса от информации. Другими словами, если в Вашей прикладной системе приема заказов через Интернет любая потеря информации является абсолютно недопустимой, то использование схемы «холодного» резервирования, т.е. подразумевающую полную остановку и отключение БД, в данном случае, совершенно неприемлемо. Для того, чтобы найти наилучшее решение, соответсвующее запросам предприятия, администратор должен хорошо разбираться в многообразии методов резервирования и восстановления, знать плюсы и минусы каждого из них.

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

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

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

Если возникла проблема, желательно как можно быстрее добраться до ее первопричины, чтобы ее вовремя нейтрализовать.

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

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

Роль администратора в управлении БД Oracle

Существует множество спецализаций, связанных с Oracle-приложениями, начиная, в первую очередь, непосредственно с самих конечных пользователей. Вот кто настоящие клиенты администратора. Если Вы имеете дело с Интернет-системой, то иногда прямая связь с пользователями просто невозможна. Предполагается, что все люди, о которых идет речь в этой статье, работают в одной компании. Так вот, пользователям необходим доступ к отдельным объектам базы данных, составляющим их приложение. Обязанность администратора обеспечить им необходимые права для выполнения соответствующих операций. Кроме того, администратор может взаимодействовать с пользователями по вопросам, касающимся функционирования БД и уж тем более когда он выполняет мероприятия по настройке системы.

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

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

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

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

Системный АБД больше заботится о программной среде Oracle в целом, нежели об ее отдельных элементах. В его обязанности входит поддержка аппаратно-программной вычислительной среды в оптимальном состоянии, обеспечивающем максимальную производительность для приложений, использующих среду в своих нуждах. Кроме того, к ним относится выработка соответствующих рекомендаций и принятие решений относительно резервирования/восстановления файлов. Системный администратор БД занимается всем, что касается вопросов производительности и проблем, способных оказать влияние на среду СУРБД Oracle. Он также ответственен за реализацию любых репликаций (replication) и параллельного функционирования, если эти механизмы задействованы в его системе . Обслуживание SQL*Net и Net8 тоже возлагается на системного АБД. В добавок ко всему вышеперечисленному, системный АБД отвечает за любой Web-сервер, с которого осуществляется доступ к базе данных, особенно если этот сервер на платформе Oracle.

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

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

Обеспечение информационных систем (ИС)

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

Потребности ИС в программном обеспечение проявляются по-разному, но в первую очередь они проявляются в наличие самих бизнес-приложений как таковых. При этом могут понадобится и дополнительные средства, как-то утилиты резервного копирования и восстановления данных, слежения, диагностики и настройки SQL. Все они относятся больше к области вспомогательного ПО, однако могут оказаться незаменимыми для поддержания продуктивности и оперативности обслуживающего персонала базы данных.

Классификация АБД

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

  1. Оперативные (operational) АБД:
    • манипулируют дисковым пространством
    • наблюдают за текущей производительностью системы
    • реагируют на возникающие неисправности БД
    • обновляют системное ПО и ПО базы данных
    • контролируют структурные изменения БД
    • запускают процедуры резервного копирования данных
    • выполняют восстановление данных
    • создают и управляют тестовыми конфигурациями БД
  2. Тактические (tactical) АБД:
    • реализуют схемы размещения информации
    • утверждают процедуры резервного копирования и восстановления данных
    • разрабатывают и внедряют структурные элементы БД: таблицы, столбцы, размеры объектов, индексацию и т.п.; сценарии(scripts) изменения схемы БД; конфигурационные параметры БД
    • утверждают план действий в случае аварийной ситуации
  3. Стратегические (strategic) АБД:
    • выбирают поставщика БД
    • устанавливают корпоративные стандарты данных
    • внедряют методы обмена данных в рамках предприятия
    • определяют корпоративную стратегию резервирования и восстановления данных
    • устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных
  4. Старшие (senior) АБД:
    • досконально знают свой персонал
    • пользуются высоким спросом
    • могут написать скрипт, который освободит их из запертого сундука, брошенного в океан, и чрезвычайно гордятся своими произведениями
    • тратят уйму времени на подготовку младших АБД
    • очень ценятся руководством и получают бешеные деньги
  5. Младшие (junior) АБД:
    • мечтают стать старшим АБД
    • не слишком сильны в написании скриптов
    • имеют большую склонность к использованию средств управления БД
    • тоже неплохо получают
  6. Прикладные (application) АБД:
    • в курсе информационных нужд компании
    • помогают в разработке прикладных задач
    • отвечают за разработку схемы и ее изменения
    • вместе с системным АБД обеспечивают должный уровень резервирования/ восстановления данных
    • занимаются построением тестовых БД
  7. Системные (system) АБД:
    • отвечают за все необходимое для резервирования и восстановления данных
    • контролируют производительность системы в целом
    • осуществляют поиск и устранение неисправностей
    • в курсе нынешних и будущих потребностей БД в плане емкости
    • в курсе текущего состояния и нужд БД
  8. Наемныю (contract) АБД :
    • приглашаются под конкретную задачу или в качестве консультантов
    • передают персоналу необходимые знания
    • фиксируют свои действия!
    • должны прекрасно разбираться в соответствующей области
    • хороши в качестве временного персонала, для оценки проекта или системы
  9. Администраторы-руководители :
    • проводят еженедельные совещания
    • определяют перечень первоочередных задач
    • устанавливают и оглашают официальный курс и стратегию
    • утверждают и корректируют должностные инструкции и список обязанностей
    • следят за наличием соответствующей документации

Виды окружений ИС Oracle

Тип и размер центра сильно зависит от величины и возможностей компании. Маленькие центры, такие как dot-coms (.com — организации, имеющие только сайт в Интернете — прим.ред .) , небольшие производственные фирмы, или даже крупные отделы, только-только переходящие на Oracle, вполне могут обойтись одним АБД, выполняющим весь спектр задач. С одной стороны это хорошо: ясно к кому обращаться, кто за все отвечает. С другой стороны не все так однозначно. АБД в одних вопросах более копметентны нежели в других в зависимости от подготовки, поэтому иногда нелегко найти специалиста, который бы одновременно хорошо разбирался в администрировании приложений и был на “ ты ” с «железом» и средствами резервирования\восстановления данных Oracle. Кроме того, возлагая всю ответственность на одного человека, следует учитывать его склонности к обучению, сверхурочной работе и т.п.

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

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

В чем нуждается администратор БД?

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

  1. Профилактический монитор:
    • избавляет администратора от экстренных мер
    • разгружает администратора по вечерам и выходным
    • ускоряет приобретение опыта
  2. Средства диагностики:
    • превращают младшего АБД в старшего, позволяя последнему сконцентрироваться на других задачах
  3. Средства анализа:
    • помогают при планировании роста БД и будущих затрат
  4. Средства технического обслуживания:
    • помогают при резервном копировании и восстановлении данных, сокращая время операции и уменьшая число ошибок
    • помогают при реорганизациях, экономя время, уменьшая количество ошибок и длительность профилактических окон (maintenance window)
    • способствуют высокой доступности данных, создавая “ незаметные ” с точки зрения системы профилактические окна и помогая при резервировании / восстановлении системы.

Сколько нужно администраторов БД?

У каждой компании свои потребности, основанные на характере используемых приложений. Не существует двух контор с абсолютно одинаковыми запросами, тем не менее Gartner предлагает по этому поводу несколько рекомендаций:

  • оцените сложность и изменчивость БД по пятибальной шкале
  • добавьте по два очка за каждую дополнительную БД
  • учтите доходность системы
  • расставьте приоритеты на основе следующей таблицы:

Как удержать администратора БД?

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

Резюме

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

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

администратор банка данных — Человек, ответственный за состояние, развитие и использование баз данных организации либо предприятия. Администратор обеспечивает: работоспособность баз данных; полноту, правильность и целостность данных; необходимую защиту данных; взаимодействие … Справочник технического переводчика

Администратор — У этого термина существуют и другие значения, см. Администратор (значения). Об администраторах в Википедии смотрите страницу Википедия:Администраторы. Администратор (лат. administrator управитель) распорядитель в учреждении, коллективе, а также… … Википедия

Администратор (значения) — Об администраторах в Википедии смотрите страницу Википедия:Администраторы. Администратор человек, выполняющий какие либо административные (управляющие) действия или наделённый соответствующими полномочиями. Администратор в Римско католической… … Википедия

Администратор защиты — (Security administrator) это субъект доступа, ответственный за защиту автоматизированной системы от несанкционированного доступа к информации (по руководящему документу «Защита от несанкционированного доступа к информации: Термины и определения») … Википедия

Системный администратор — (англ. system administrator), ИТ администратор сотрудник, должностные обязанности которого подразумевают обеспечение штатной работы парка компьютерной техники, сети и программного обеспечения, а также обеспечение информационной… … Википедия

банк данных — БнД Автоматизированная ИПС, состоящая из одной или нескольких баз данных и системы хранения, обработки и поиска информации в них. [ГОСТ 7.73 96] банк данных Совокупность массивов информации длительного хранения данных в автоматизированной системе … Справочник технического переводчика

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

Сертификаты Oracle — Корпорация Oracle проводит международную сертификацию специалистов в различных областях, связанных с технологиями Oracle. Сертификация специалистов Oracle обновляет сертификационные экзамены при появлении новых версий программных продуктов. Для… … Википедия

OS/2 — Warp Разработчик IBM, Microsoft Семейство ОС … Википедия

Warp4 — OS/2 Warp Разработчик Microsoft Семейство ОС OS/2 Исходный код Закрытый исходный код Последняя версия 4.52 декабрь 2001 Тип ядра модульное Интерфейс графический Л … Википедия

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

Управление данными в базах данных

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

СУБД представляет собой специальный пакет программ, с помощью которого, как уже было отмечено, реализуется централизованное управление БД и обеспечивается доступ к данным. В каждой СУБД прежде всего имеются компиляторы (трансляторы) либо интерпретаторы с языка описания данных (ЯОД) и языка манипулирования данными (ЯМД). При создании интегрированных БнД содержащих несколько разнотипных СУБД каждая из которых используется в отдельном локальном БнД и характеризуется наличием своего ЯОД и ЯМД, разрабатывают единые для всего интегрированного банка ЯОД и ЯМД, обеспечивающие работу с данными. И кстати Любого локального банка, входящего в состав интегрированного.

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

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

Журнал — это так называемая особенная часть БД, недоступная для пользователя СУБД и поддерживаемая особо тщательно базой защиты (кстати можно поддерживать две копии журнала, располагаемые на разных физических дисках), в первую копию которую поступают записи обо всех изменениях основной части БД. А также во многих СУБД изменения баз данных журнализируются на разных уровнях: иногда запись в журнале имеет соответствие многих логических операции изменения БД (например, операции удаления строки из таблицы реляционной базы данных), а в некоторых случаях запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В большинстве личных системах баз одновременно используются оба подхода. А также во всех случаях и при любых обстоятельствах придерживаются стратегии «предупреждающие » записи в журнале (так бы называемого протокола Write Ahead Log — WAL). Говоря своими словами, эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части базы данных. Так, как нам известно, что если в СУБД правильно соблюдается протокол WAL, то при помощи журнала можно решить даже очень сложные проблемы восстановления баз данных даже после глобального сбоя. К стати самая простая операция восстановления это провести индивидуальный откат изменений в базе данных. Проще говоря, для этого даже не понадобится общесистемный журнал изменений БД, для этого достаточно просто для каждой обработки данных поддерживать локальный журнал изменения операций базы данных, выполненных в этой транзакции, и производить откат транзакции, выполнением обратных данных операций, следуя от конца локального журнала. А в определенных СУБД так и делают, но хочу подметить, что в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для того все записи от одной транзакции и связывают обратным списком (от конца к началу). А также при произошедшим мягком сбое во внешней памяти основной части БД, могут находиться объекты измененные транзакции не закончившимися к моменту сбоя системы базы и могут отсутствовать объекты измененные транзакциями которые к этому моменту сбоя успешно завершились по причине использования буферов оперативной памяти. А содержимое которых при мягком сбое просто пропадает. При соблюдении протокола WAL во внешней памяти журнала всегда должны гарантированно находить записи, относящиеся к операциям изменения обоих видов объектов. Для восстановления баз данных после жесткого сбоя используют журналы, а также архивную копию БД. Говоря своими словами, архивная копия баз данных — это полная копия БД к моменту начала работы заполнения журнала (имеется много вариантов более легкого и гибкого объяснения смысла архивной копии). Конечно, для нормальной операции по восстановлению БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже пояснялось, к сохранности журнала во внешней памяти в СУБД требуются особо повышенные требования. И так операция по восстановлению БД состоит в том, что исходя из архивной копии по журналу, воспроизводится работа всех транзакций обработки данных, которые закончились к моменту сбоя. А также в принципе можно даже и воспроизвести работу незавершенных транзакций и продолжить их работу после восстановления базы данных. Однако во многих реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

Управление безопасностью в СУБД

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

Илон Маск рекомендует:  Всплывающие подсказки на CSS3 без javascript

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

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

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

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

операционные ограничения (за счет прав доступа операторов выборки, вставки, удаления и обновления, применяемые ко всем или отдельным столбцам таблицы);

ограничения по значениям (за счет механизма представлений);

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

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

И так рассмотрим, операцию управление доступом. Этот этап базируется на реализации следующего минимального набора действий: произвольное управление доступом; обеспечение безопасности повторного использования объектов; использование меток безопасности; принудительное управление доступом. А также произвольное управление доступом — это метод ограничения доступа к объектам, основанный на учете личности субъекта или групп, в которую субъект входит. Группа — это именованная совокупность пользователей; объединение субъектов в группы облегчает процесс администрирования баз данных, и строится на основе формальной структуры организации. Эта технология обеспечивает владельцу объекта (представления, сервера базы данных, процедуры, таблицы) передачу по своему усмотрению привилегий другому лицу. Таким лицом в данной ситуации может выступать субъект-пользователь, группа пользователей и такой возможный носитель привилегий как роль. Дальше привилегии можно распределить в зависимости от статуса пользователей (администратор сервера базы данных и база данных, прочие пользователи). А также следует отметить, что особенно важным следует считать поддержание уровня защиты привилегий, администратора сервера базы данных, так как. Хищения его пароля может привести к серьезным проблемам для всей хранящейся информации. Считается что главным достоинство применения произвольного управления доступом — это гибкость в управление защитой, однако такие сопутствующие характеристики как рассредоточенность управления и сложность централизованного контроля создают немало проблем для обеспечения безопасности данных. В качестве дополнения к средствам управления доступа можно отнести безопасность повторного использования объектов, которая должна гарантироваться для областей оперативной памяти, в частности, для буферов с образами экрана, расшифрованными паролем, для магнитных носителей. Следует также обратить внимание и на обеспечение безопасности повторного использования субъектов. Это означает лишение прав для входа в информационную систему всех пользователей, покинувших организацию. Специалисты по управлению безопасностью информации считают достаточным для большинства коммерческих приложений использование средств, произвольного управления доступом. И, тем не менее, остается нерешенной одна немало важная проблема слежение за передачей информации базы данных. Кстати, средства произвольного управления доступом не могут помешать авторизованному пользователю, законным путем получить конфиденциальную информацию и сделать ее доступной для других пользователей. И таким образом это происходит по той причине, что при произвольном управлении доступом привилегии существуют изолированно от данных. Для решения этой проблемы применяют подход, позволяющий осуществить разделение данных по уровням секретности и категориям доступа, называемый метками безопасности. Метка безопасности состоит из двух частей: уровня секретности и списка категорий. Первая составляющая зависит от приложения и в стандартном варианте может выглядеть как спектр значений от «совершенно секретно» до «несекретно». Вторая составляющая метки позволяет описать предметную область, разделяя информацию «по отсекам», что способствует лучшей защищенности. Метки безопасности строк таблиц добавляются к каждой строке реляционного отношения. Каждый пользователь также получает и собственную метку безопасности, которая определяет степень его благонадежности. Пользователь получает доступ к данным, если степень его благонадежности соответствует требованиям соответствующей метки безопасности, а именно: уровень секретности пользователя должен быть не ниже уровня секретности данных; набор категорий, заданных в метке безопасности данных, должен целиком находиться в метке безопасности пользователя.

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

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

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

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

Профессия администратор баз данных

Кто такой специалист по информационным системам

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

Что делает администратор базы данных?

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

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

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

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

Некоторые обязанности администратора базы данных включают в себя:

  • Определение потребностей пользователей в создании и администрировании баз данных
  • Обеспечение эффективной и бесперебойной работы базы данных
  • Внесение и тестирование изменений в структуру базы данных при необходимости
  • Ведение базы данных и обновление разрешений
  • Объединение старых баз данных в новые
  • Резервное копирование и восстановление данных для предотвращения их потери

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

Две общие специальности заключаются в следующем:

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

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

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

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

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

Пользователями БД могут быть:

1. прикладные программы;

2. программные комплексы;

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

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

Администратор БД обеспечивает:

1. работоспособность БД,

2. контролирует и поддерживает полноту, достоверность, непротиворечивость и целостность данных,

3. реализует необходимый уровень защиты.

Защита базы данных.

В современных многопользовательских СУБД защитные механизмы реализуются следующими способами:

1. установка пароля для открытия БД. После установки пароля при каждом открытии БД будет появляться диалоговое окно, в которое требуется ввести пароль. Только те пользователи, которые введут правильный пароль, смогут открыть БД. Этот способ достаточно надежен, но он действует только при открытии БД.

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

3. защита на уровне пользователей:

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

o защита конфиденциальных сведений в базе данных.

При запуске СУБД от пользователя требуется идентифицировать себя и ввёсти пароль. Пользователи идентифицируются как члены группы. СУБД по умолчанию создает две группы: администраторы (группа «Admins») и пользователи (группа «Users»). Допускается также определение других групп.

Группам и пользователям предоставляются разрешения на доступ.

Восстановление базы данных.

Важными средствами восстановления БД являются регулярное и частое резервное копирование БД и ведение журнала транзакций.

Резервная копия БД— это копия всех файлов, составляющих БД. Если повреждается или теряется файл, являющийся частью БД, то из резервной копии можно извлечь копию этого файла и восстановить его в базе.

Журнал транзакций — это группа файлов, в которые записываются изменения, внесенные завершенными транзакциями. Эта информация достаточна для повторного выполнения, если надо восстановить БД.

Сжатие базы данных.

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

СУБД

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

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

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

Классификация СУБД

Классификация СУБД по организации данных

ЛокальныеСУБД

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

Распределенные СУБД

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

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

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

Работу с распределенной БД обеспечивают распределенные СУБД.

Распределенная СУБД (РаСУБД)— это программная система, которая обеспечивает управление распределенной БД и прозрачность ее распределенности для пользователей.

Требования к РаБД:

o локальная автономность;

o никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел;

o непрерывность функционирования;

o независимость от местоположения, от фрагментации, от тиражирования;

o распределенная обработка запросов;

o управление распределенными транзакциями;

o независимость от оборудования, от операционных систем, от сети, от СУБД.

РаБД могут быть однородными и неоднородными. Однородные РаБД имеют в своей основе одну СУБД, обычно с единственным языком баз данных; неоднородные РаБД — две или более существенно различающиеся СУБД.

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

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

Репликаты — это множество различных физических копий некоторого объекта БД (обычно таблицы), для которых в соответствии с определенными в БД правилами поддерживается синхронизация (идентичность) с некоторой «главной» копией.

Последнее изменение этой страницы: 2020-06-26; Нарушение авторского права страницы

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

Родственные профессии

Инженер по поддержке оборудования, системный администратор, специалист по системной интеграции, веб-мастер

Сфера профессиональной деятельности

  • Информационные технологии
  • Безопасность
  • Промышленность

Классификация профессии

  • Может быть отнесена к типам профессии:
  1. «Человек – Знак» (связана с работой со знаковой информацией: текстами, цифрами, формулами и таблицами, расчетами).
  2. «Человек — Техника» (ориентирована на эксплуатацию технических устройств).
  • Класс профессии: эвристический (творческий). Работа связана с анализом, исследованиями и испытаниями, контролем и планированием. Она требует высокой эрудиции, оригинальности мышления, стремления к развитию и постоянному обучению.
  • Тип профессии по условиям труда: микроклимат бытового типа (работа в помещениях).

Описание профессии

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

  • проектирование базы данных;
  • оптимизация производительности базы данных;
  • обеспечение и контроль доступа к базе данных;
  • обеспечение безопасности в базе данных;
  • резервирование и восстановление базы данных;
  • обеспечение целостности баз данных.

В основные обязанности администратора баз данных входит:

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

Требования к индивидуальным особенностям специалиста

Профессионально важные качества администратора баз данных:

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

Администратор баз данных должен обладать следующими личностными качествами:

  • усидчивость;
  • терпеливость;
  • настойчивость;
  • обязательность;
  • «педантизм» в работе;
  • ответственность;
  • аккуратность.

Медицинские противопоказания

  • Заболевания центральной нервной системы различной этиологии с двигательными и чувствительными нарушениями, расстройствами координации, когнитивными и интеллектуальными нарушениями.
  • Нарколепсия и катаплексия.
  • Заболевания, сопровождающиеся расстройствами сознания: эпилепсия и эпилептические синдромы различной этиологии и др.
  • Психические заболевания с тяжелыми, стойкими или часто обостряющимися болезненными проявлениями.
  • Алкоголизм, токсикомания, наркомания.
  • Активные формы туберкулеза любой локализации.
  • Хронические гепатиты, циррозы печени и другие заболевания печени.
  • Миопия высокой степени или осложненная близорукость.
  • Катаракта осложненная.
  • Дегенеративно-дистрофические заболевания сетчатки глаз, глаукома любой стадии при нестабилизированном течении.
  • Болезни эндокринной системы прогрессирующего течения с признаками поражения других органов и систем и нарушением их функции 3-4 степени.
  • Злокачественные новообразования любой локализации.
  • Заболевания крови и кроветворных органов с прогрессирующим и рецидивирующим.
  • Гипертоническая болезнь III стадии, 3 степени.
  • Хронические болезни сердца и перикарда с недостаточностью кровообращения ФК III, и более степени; ишемическая болезнь сердца;
  • Ревматизм: активная фаза, частые рецидивы с поражением сердца и других органов и систем.
  • Осложненное течение язвенной болезни желудка, двенадцатиперстной кишки.
  • Хронические болезни почек и мочевыводящих путей с явлениями хронической почечной недостаточности 2 — 3 степени.
  • Хронические, рецидивирующие формы инфекционных и паразитарных заболеваний.

Приказ Министерства здравоохранения и социального развития РФ от 12 апреля 2011 г. N 302н

Требования к профессиональной подготовке

Администратор баз данных должен знать:

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

Администратор баз данных должен уметь:

  • выполнять регламентные процедуры по резервному копированию, архивированию и восстановлению баз данных;
    управлять учетными записями пользователей;
    устанавливать и настраивать прикладное программное обеспечение для администрирования систем управления базами данных;
    протоколировать работу систем управления базами данных;
    подготавливать отчеты о функционировании систем управления базами данных;
    вести эксплуатационную и технологическую документацию;
    устанавливать и настраивать серверное программное обеспечение систем управления базами данных.
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL