36) Администрирование баз данных, функции администрирования.

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

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

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

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

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

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

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

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

37) Реляционная модель данных: таблицы, поля, записи, ключевые поля, связи, отношения целостности, схема данных.

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

• структуры данных в виде наборов таблиц;

• теоретико-множественные операции над таблицами: объединение, пересечение, разность и декартово произведение;

• специальные реляционные операции: отбор, проекция, соединение, группировка;

• специальные правила, обеспечивающие целостность данных.

К числу наибольших достоинств реляционного подхода можно отнести:

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

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

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

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

Модель реляционных баз данных использует следующие основные понятия:

• тип данных;

• показатель;

• таблица;

• поле;

• запись;

• первичный ключ;

• база данных;

• соединение таблиц;

• целостность;

• схема данных.

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

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

Структура таблицы (используется также термин «отношение») задается множеством полей. Поле (в некоторых источниках употребляются термины «атрибут» или «реквизит») можно описать парой <имя поля, имя показателя>. Хотя кажется, что достаточно задать только имя поля, но задание также имени показателя позволяет сравнивать столбцы разных таблиц.

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

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

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

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

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

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