Конспект Лекций БД. Конспект лекций_БД. Конспект лекций по курсу Информационное обеспечение, базы данных

• Название: Конспект лекций по курсу Информационное обеспечение, базы данных
• Анкор: Конспект Лекций БД
• Дата: 16.11.2021
• Размер: 0.89 Mb.
• Имя файла: Конспект лекций_БД.docx
• Тип: Конспект лекций; #273214
• страница: 9 из 11

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

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

Тип данных

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

Домен

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

Схема отношения, схема базы данных

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений.

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

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.

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

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

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

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

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

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

В
Пользовательский интерфейс


СУБД



БД


Словарь данных


Администрирование БД (АБД)










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

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

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

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

Работа с пользователями.

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

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

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

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

Установление стандартов и процедур

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

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

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

3. Тестирование. При оценке всех новых процедур, ПО и оборудования проводится проверка их рабочих характеристик. Контроль структуры и непротиворечивости БД проводится регулярно.

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

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

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

7. Контроль целостности. Составляется план проверки целостности данных, хранящихся в БД.

Задачи АБД

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

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

Целостность

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

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

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

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

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

Например, необходимо оплатить счет, т.е. “изъять” часть суммы из одной таблице и “перевести” ее в другую. Предположим, что вторая операция не выполняется, тогда баланс счетов не будет сходиться. Если операции выполняются независимо, то БД имеет вид:
Общий счет Расчет

. . . . . . . . . . . Баланс . . . . . . . . Баланс

2000 1000

Общий счет Расчет

. . . . . . . . . . . Баланс Отказ . . . . . . . . Баланс

1000 системы 1000

Если действия выполняются в неделимом режиме, и одно из них приводит к отказу, то никакие изменения в БД не вносятся. Такие транзакции называются прерванными.

Общий счет Расчет

. . . . . . . . . . . Баланс . . . . . . . . Баланс

2000 1000

Общий счет Расчет

. . . . . . . . . . . Баланс Отказ . . . . . . . . Баланс

2000 системы 1000

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

Контроль параллельной обработки.

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

Например, два разных пользователей одновременно оплачивают разные счета. Пусть баланс равен 2000, одному нужно оплатить 1000, а другому 500. Баланс позволяет оплатить оба счета. Предположим, первый запрос поступает на долю секунды раньше. Баланс перемещается в рабочую область компьютера. Но прежде чем транзакция завершается и запись баланса обновляется, вторая транзакция создает копию в рабочей области той же записи, т.е. баланс равен 2000. После завершения работы первой транзакции запись баланса переписывается 2000-1000 = 1000, а после завершения работы второй транзакции запись опять будет переписана 2000-500 = 1500. В итоге размер истинный размер баланса равен 500, а запись в системе показывает 1500.

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

Требует блокировки А Требует блокировки Б

Запись А заблокирована Запись Б заблокирована

Требует блокировки Б Требует блокировки А

Режим бесконечного ожидания Режим бесконечного ожидания

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

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

Пользователь  Пользователь 

Ожидает Ожидает

Запись БД А Б

Используется Используется

Другая опция контроля параллельной обработки – двухфазная блокировка. Транзакция следует протоколу двухфазной блокировки, если все операции блокировки, предшествуют первой операции разблокирования в транзакции.

Защита БД.

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

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