Механизм транзакций

Связь между таблицами

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

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

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

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

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

Рис. 2.Схема связи между таблицами базы данных Paradox

В главной таблице определен ключ, построенный по полю M_Code автоинкре­ментного типа. В подчиненной таблице определен ключ по полю D_Number также автоинкрементного типа и индекс, построенный по полю D_Code целочислен­ного типа. Связь между таблицами устанавливается по полям D_code и M_Сode. Индекс по полю D_Code является внешним ключом. В названия полей включе­ны префиксы, указывающие на принадлежность поля соответствующей таблице. Так, названия полей главной таблицы начинаются буквой М (Master), а названия полей подчиненной таблицы начинаются буквой D (Detail). Подобное именова­ние полей облегчает ориентацию в их названиях, особенно при большом коли­честве таблиц.

Замечание

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

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

• отношение "один-к-одному";

§ отношение "один-ко-многим";

§ отношение "много-к-одному";

§ отношение "много-ко-многим".

Отношение "один-к-одному" означает, что одной записи в главной таблице со­ответствует одна запись в подчиненной таблице. При этом возможны два ва­рианта:

§ для каждой записи главной таблицы есть запись в подчиненной таблице;

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

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

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

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

§ таблицу карточек читателей, содержащую такую информацию о читателе, как фамилия, имя, отчество, дата рождения и домашний адрес;

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

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

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

Отношение "много-к-одному" отличается от отношения "один-ко-многим" толь­ко направлением. Если на отношение "один-ко-многим" посмотреть со стороны подчиненной таблицы, а не главной, то оно превращается в отношение "много-к-одному".

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

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

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

Работа со связанными таблицами имеет следующие особенности.

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

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

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

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

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

§ организацию связи между таблицами;

§ установку значения поля связи подчиненной таблицы (это может также выполняться автоматически);

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

§ организацию (запрет) каскадного удаления записей.

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

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

Транзакция представляет собой выполнение последовательности операций. При этом возможны две ситуации.

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

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

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

§ при выполнении последовательности взаимосвязанных операций с БД;

§ при многопользовательском доступе к БД.

Транзакция может быть неявной или явной.

Неявная транзакция стартует авто­матически, а по завершении также автоматически подтверждается или отменяется.

Явной транзакцией управляет программист с использованием компонента Database и/или средств SQL.

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

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

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

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

Дата добавления: 2014-01-03