Базовые понятия реляционных БД

Базовые понятия реляционных БД

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

Тип данных

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

Домен

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

Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Кортеж - это набор именованных значений заданного типа. Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий: Отношение – Таблица (иногда Файл), Кортеж – Строка (иногда Запись), Атрибут – Столбец, Поле. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения".

Объектные СУБД

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

 

Многомерные БД

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

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

Модель	Месяц	Объем
"Жигули"	Июнь
"Жигули"	Июль
"Жигули"	Август
"Москвич"	Июнь
"Москвич"	Июль
"Волга"	Июль

Двухмерное представление данных конечному пользователю: многомерная модель (те же данные):

Модель	Июнь	Июль	Август
«Жигули»
«Москвич»			No
«Волга»	No		No

Многомерное представление при описании структур данных

Измерение – это множество однотипных данных, образующих одну из граней гиперкуба. Например – Дни, Месяцы, Кварталы, Годы

Переменная – значения таких показателей один раз вводятся из какого-либо внешнего источника или формируются программно и затем в явном виде хранятся в многомерной базе данных (МБД)

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

Реляционная алгебра

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

Особенности теоретико-множественных операций реляционной алгебры

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

Начнем с операции объединения (все, что будет говориться по поводу объединения, переносится на операции пересечения и взятия разности). совместимость отношений по объединению: два отношения совместимы по объединению в том и только в том случае, когда обладают одинаковыми заголовками. Более точно, это означает, что в заголовках обоих отношений содержится один и тот же набор имен атрибутов, и одноименные атрибуты определены на одном и том же домене. Можно сделать полностью совместимыми по объединению путем применения операции переименования. Все операции, кроме взятия разности, являются коммутативными, т.е. A OP B = B OP A. Операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы.

 

Основные функции СУБД

функции СУБД: управление данными во внешней памяти; управление буферами оперативной памяти; управление транзакциями; журнализация и восстановление БД после сбоев; поддержание языков БД.

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

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

Цикл жизни БД

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

Во время технического проектирования базы данных проектировщик должен проделать следующую работу: 1. Обследовать предметную область автоматизации. 2. Определить объекты и перечень их атрибутов, для каждого объекта выделить первичные ключи и провести нормализацию. 3. Установить все структурные, иерархические связи между объектами и все запросные связи, обеспечивающие обработку всех запросов пользователей и баз данных. Начертить схему проекта со всеми объектами и связями. 4. Выработать технологию обслуживания базы данных, т. е. определить порядок сбора, хранения данных в базе данных, частоту и форматы ввода - вывода данных, правила работы всех групп пользователей. Проект должен обеспечивать простоту и удобство будущей эксплуатации банка данных, защиту данных от некорректных обновлений пользователями и от разрушений при сбоях компьютера.

5. Выбрать конкретную СУБД для реализации. 6. Проверить корректность проекта. Проект должен адекватно, на требуемом уровне детальности, отображать предметную область. 7. Определить сроки реализации базы данных.

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

1. Описать средствами СУБД и ввести в ЭВМ схемы всех отношений.

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

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

 

Администратор БД

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

Функции администратора:

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

- решать вопросы, связанные с расширением БД в связи с изменением границ ПО;

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

- выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность;

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

Роль пользователей БД

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

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

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

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

Роль системных программистов

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

Роль прямых конечных пользователей

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

Роль косвенных конечных пользователей

Косвенные конечные пользователи не обращаются с ЭВМ непосредственно.

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

Языки описания данных

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

Методика проектирования БД

Организационный аспект

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

Концептуальное проектирование

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

Существует три подхода к концептуальному проектированию: объектное представление; моделирование сущностей; семантическое моделирование данных.

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

Логическое проектирование

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

Проектирование физической реализации

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

Проектирование формата хранимой записи

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

Кластеризация хранимых данных

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

Проектирование метода доступа

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

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

Вопросы целостности и безопасности данных

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

Проектирование программ

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

Логическое проектирование

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

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

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

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

 

Физическое проектирование

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

 

Модели хранения данных

Иерархическая и сетевая модели хранения данных стали применяться в системах управления базами данных в начале 70-х годов. В начале 80-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Реляционное исчисление

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

Реляционное исчисление доменов

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

Распределенные базы данных

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

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

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

Первое из них состоит в том, что не все таблицы глобального логического представления доступны конкретному пользователю. В данном примере таблица СЫРЬЕ не содержится в приведенном представлении пользователя, означая тем самым, что пользовательский уровень представления может содержать не все таблицы глобального логического уровня представления. Второе замечание состоит в том, что дальнейшее совершенствование пользовательского представления может быть достигнуто путем использования лишь некоторого подмножества столбцов таблиц. Столбец ТАРИФ из таблицы СЛУЖАЩИЕ не включен в приведенное пользовательское представление. И, наконец, пользовательское представление может включать только подмножество строк таблицы. В приведенном примере в таблице СЛУЖАЩИЕ пользовательского представления содержатся лишь строки, соответствующие заводу, номер которого равен 3. Существование третьего и четвертого уровней представления объясняется распределенной природой базы данных и решением использовать управляемую избыточность. Третий уровень представления - фрагментное представление. Используя это представление, АБД определяет несвязанные подмножества базы данных, называемые логическими фрагментами, каждый из которых является подмножеством строк в таблице.

На рисунке показаны логические фрагменты базы данных. В рассмотренном примере таблица ЗАВОД разделена на три логических фрагмента согласно конкретным значениям номеров заводов.

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

 

Сегментация баз данных

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

 

Целостность данных

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

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

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

 

Обработка транзакций