ГЛАВА 1
Технологии администрирования баз данных
Технологии администрирования баз данных
1.1
Архитектура баз данных
Архитектура баз данных
В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного программного комплекса преобразований информации и (или) вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т. д.
Информационные системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующих данных. Их структура зачастую очень сложна, и, хотя структуры данных различны в разных информационных системах, между ними много общего.
Понятие согласованности данных является ключевым понятием баз данных. Если информационная система поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает БД. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее СУБД. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных.
Модели данных. Обобщенные структуры данных называют моделями данных, так как они отражают представление пользователя о данных реального мира.
Модели данных. Обобщенные структуры данных называют моделями данных, так как они отражают представление пользователя о данных реального мира.
Любая модель данных должна содержать три компонента:
1) структуру данных ― описывает точку зрения пользователя на представление данных;
2) набор допустимых операций, выполняемых на структуре данных. Модель данных предполагает, как минимум, наличие языка определения данных, описывающего структуру их хранения, и языка манипулирования данными, включающего в себя операции извлечения и модификации данных;
3) ограничения целостности ― механизм поддержания соответствия данных предметной области на основе формально описанных правил.
1) структуру данных ― описывает точку зрения пользователя на представление данных;
2) набор допустимых операций, выполняемых на структуре данных. Модель данных предполагает, как минимум, наличие языка определения данных, описывающего структуру их хранения, и языка манипулирования данными, включающего в себя операции извлечения и модификации данных;
3) ограничения целостности ― механизм поддержания соответствия данных предметной области на основе формально описанных правил.
В процессе исторического развития в СУБД использовались следующие модели данных: иерархическая, сетевая и реляционная.
Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних.
Иерархическая схема состоит из типов записей и типов «родитель—потомок».
Запись — это набор значений полей.
Записи одного типа группируются в типы записей.
Отношения «родитель—потомок» — это отношения вида 1 : M между двумя типами записей.
В сетевой модели у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями.
Основной элемент сетевой модели данных — набор, который состоит из типа «запись—владелец», имени набора и типа «запись—член».
Реляционная модель предложена сотрудником компании IBM Е. Ф. Коддом в 1970 г. Перевод статьи Кодда на русский язык с описанием этой модели опубликован в журнале «СУБД» № 1 за 1995 г. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
В упомянутой статье Е. Ф. Кодда утверждается, что реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т. е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (название «реляционная» происходит от англ. relation — отношение).
Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних.
Иерархическая схема состоит из типов записей и типов «родитель—потомок».
Запись — это набор значений полей.
Записи одного типа группируются в типы записей.
Отношения «родитель—потомок» — это отношения вида 1 : M между двумя типами записей.
В сетевой модели у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями.
Основной элемент сетевой модели данных — набор, который состоит из типа «запись—владелец», имени набора и типа «запись—член».
Реляционная модель предложена сотрудником компании IBM Е. Ф. Коддом в 1970 г. Перевод статьи Кодда на русский язык с описанием этой модели опубликован в журнале «СУБД» № 1 за 1995 г. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
В упомянутой статье Е. Ф. Кодда утверждается, что реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т. е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (название «реляционная» происходит от англ. relation — отношение).
Отношения удобно представлять в виде таблиц. На рис. 1.1 показана таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам. Каждая строка фактически представляет собой описание одного объекта предметной области (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели «сущность—связь». Реляционные отношения соответствуют сущностям, а кортежи — экземплярам сущностей. Поэтому, так же как и в модели «сущность—связь», столбцы в таблице, представляющей реляционное отношение, называют атрибутами.
Рис. 1.1 Основные элементы реляционной модели
Каждый атрибут определен на домене, поэтому домен можно рассматривать как множество допустимых значений данного атрибута.
Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на рис. 1.1, атрибуты «Оклад» и «Премия» определены на домене «Деньги». Поэтому понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Сравнение атрибутов «Табельный номер» и «Оклад» является семантически некорректным, хотя они и содержат данные одного типа.
Именованное множество пар «имя атрибута—имя домена» называется схемой отношения. Мощность этого множества называют степенью, или арностью отношения. Набор именованных схем отношений представляет собой схему базы данных.
Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). В приведенном примере ключом является атрибут «Табельный номер», поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ.
Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными или потенциальными ключами.
Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на рис. 1.1, атрибуты «Оклад» и «Премия» определены на домене «Деньги». Поэтому понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Сравнение атрибутов «Табельный номер» и «Оклад» является семантически некорректным, хотя они и содержат данные одного типа.
Именованное множество пар «имя атрибута—имя домена» называется схемой отношения. Мощность этого множества называют степенью, или арностью отношения. Набор именованных схем отношений представляет собой схему базы данных.
Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). В приведенном примере ключом является атрибут «Табельный номер», поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ.
Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными или потенциальными ключами.
На первом этапе проектирования БД необходимо собрать сведения о предметной области, в том числе о назначении, способах использования и структуре данных. По мере развития проекта осуществляется централизованное накопление информации о концептуальной, логической, внутренней и внешних моделях данных.
Рис. 1.2. Вид словаря данных
Одно из главных назначений словаря данных состоит в документировании данных. Так как БД обслуживает множество пользователей, необходимо, чтобы они правильно понимали, что представляют собой данные.
Второе важное назначение словаря данных — обеспечить эффективное взаимодействие между различными категориями разработчиков и пользователей.
Таким образом, два важнейших назначения словаря данных заключаются в централизованном ведении и управлении данными как ресурсом на всех этапах проектирования, реализации и эксплуатации системы, а также в обеспечении эффективного взаимодействия между всеми участниками проекта.
В случае распределенной БД вся БД или ее отдельные части могут размещаться на удаленных друг от друга вычислительных машинах, соединенных линиями связи. Одни рабочие станции в сети могут обращаться только к локальной БД, а другие — как к локальной, так и к внешним.
В этом случае в словарь данных может быть введена информация обо всех местах физического хранения данных, а также ограничения секретности, безопасности и доступа. С помощью этой информации словарь данных может «решить», каким образом удовлетворить запрос пользователя: обратиться к локальной БД или, если пользователь обладает соответствующими полномочиями, передать запрос в другой узел вычислительной системы.
Второе важное назначение словаря данных — обеспечить эффективное взаимодействие между различными категориями разработчиков и пользователей.
Таким образом, два важнейших назначения словаря данных заключаются в централизованном ведении и управлении данными как ресурсом на всех этапах проектирования, реализации и эксплуатации системы, а также в обеспечении эффективного взаимодействия между всеми участниками проекта.
В случае распределенной БД вся БД или ее отдельные части могут размещаться на удаленных друг от друга вычислительных машинах, соединенных линиями связи. Одни рабочие станции в сети могут обращаться только к локальной БД, а другие — как к локальной, так и к внешним.
В этом случае в словарь данных может быть введена информация обо всех местах физического хранения данных, а также ограничения секретности, безопасности и доступа. С помощью этой информации словарь данных может «решить», каким образом удовлетворить запрос пользователя: обратиться к локальной БД или, если пользователь обладает соответствующими полномочиями, передать запрос в другой узел вычислительной системы.
Для успешного применения словаря данных при разработке БД следует осуществлять накопление информации в этом едином источнике, из которого программисты смогут копировать описания структур данных и включать их в свои программы на всех этапах проектирования. В случае применения «ручного» или неинтегрированного словаря в нем время от времени может происходить нарушение непротиворечивости информации по отношению к фактическому состоянию системы.
Если словарь данных применяется для разграничения доступа к БД, то доступ к нему также нужно разграничить. Следует строго ограничить круг лиц, которым разрешено модифицировать словарь данных. В отношении хранимой в словаре информации должен быть реализован режим секретности.
Администрирование БД не возможно без учета основополагающих свойств отношений.
1. Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого кортежа первичного ключа. При определении первичного ключа должно соблюдаться требование «минимальности», т. е. в него не должны входить те атрибуты, которые можно отбросить без ущерба для основного свойства первичного ключа — однозначно определять кортеж.
2. Отсутствие упорядоченности кортежей. Свойство отсутствия упорядоченности кортежей отношения является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения упрощает задачи СУБД по хранению данных во внешней памяти и выполнение запросов к БД.
3. Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.
4. Атомарность значений атрибутов, т. е. среди значений домена не могут содержаться множества значений (отношения).
Схемы и объекты схемы данных используются в модели безопасности компонента Database Engine для упрощения взаимоотношений между пользователями и объектами, и, следовательно, схемы имеют очень большое влияние на взаимодействие пользователя с компонентом Database Engine.
Администрирование БД не возможно без учета основополагающих свойств отношений.
1. Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого кортежа первичного ключа. При определении первичного ключа должно соблюдаться требование «минимальности», т. е. в него не должны входить те атрибуты, которые можно отбросить без ущерба для основного свойства первичного ключа — однозначно определять кортеж.
2. Отсутствие упорядоченности кортежей. Свойство отсутствия упорядоченности кортежей отношения является следствием определения отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на множестве кортежей отношения упрощает задачи СУБД по хранению данных во внешней памяти и выполнение запросов к БД.
3. Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.
4. Атомарность значений атрибутов, т. е. среди значений домена не могут содержаться множества значений (отношения).
Схемы и объекты схемы данных используются в модели безопасности компонента Database Engine для упрощения взаимоотношений между пользователями и объектами, и, следовательно, схемы имеют очень большое влияние на взаимодействие пользователя с компонентом Database Engine.
