Общий обзор методологии физического проектирования реляционных баз данных

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

✍	денормализация усложняет реализацию БД,
✍	денормализация снижает гибкость системы,

 

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

Иногда денормализацию называют оптимизацией исполнения.

 

В начало

 

УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ.

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

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

Имеются определенные требования к выполнению транзакций. Эти требования, известные как требования ACID (Atomicity, Consistency, Isolation и Durability), описывают то, как должны обра­батываться данные и в каком состоянии они должны находиться после завер­шения транзакции:

•

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

•

Согласованность (Consistency). После того, как транзакция будет успешно завершена, данные должны удовлетворять всем ограничениям целостности, определенным в базе данных. Кроме того, все связанные с измененными данными индексы должны находиться в корректном состоянии. Каждая команда производит изменение данных в таблице. В ходе этих изменений могут быть нарушены правила и огра­ничения целостности, наложенные на данные. SQL Server 2012 позволяет контролировать целостность данных двумя способами: целостность данных может проверяться после выполнения каждой команды или только при её фиксировании.

 

•

Изолированность (Isolation). Изменения данных, выполняемые различными транзакциями, должны быть независимыми друг от друга, т. е. быть изоли­рованными. Если транзакция выбирает строки по определенному логическому условию, то никакая другая транзакция не должна изменять, добавлять или удалять строки, которые соответствуют указанному логическому условию. Такое поведение из­вестно как "сериализуемость".

•

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

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

Чтобы обеспечить требования изолированности транзакций используются блокировки (locks). По возможности следует включать в транзакцию как можно меньше команд, чтобы блокировать ресурсы минималь­ное количество времени.

Основы блокировок

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

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

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

•

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

•

Проблема "грязного" чтения (The uncommitted dependency problem). Эта про­блема возникает, когда транзакция пытается считать данные, обрабатывае­мые другой транзакцией, и находящиеся на стадии обработки. При этом дан­ные могут нарушать ограничения целостности и правила, тем самым нарушая общую целостность данных.

 

•

Проблема неповторяемого чтения (The inconsistent analysis problem). Эта про­блема связана с многократным чтением транзакцией одних и тех же данных. Между операциями чтения некоторая транзакция может изменить данные, так что при следующем сканировании первая транзакция будет оперировать уже другими данными.

•

Проблема чтения фантомов (The phantom read problem). Эта проблема возни­кает, когда во время выполнения транзакции в таблицу вставляются новые строки, которые могут быть обработаны транзакцией. Предположим, что транзакция осуществляет несколько раз выборку данных из таблицы на ос­нове одного и того же логического условия. Перед началом очередной вы­борки в таблицу добавляются (или удаляются) строки, удовлетворяющие ло­гическому условию. В результате при сканировании будет обработан иной набор данных, чем при предыдущих сканированиях.

Стандарт, определяющий уровни блокировки:

•	Level 0 — No trashing of data (запрещение "загрязнения" данных). На этом уровне решается проблема последнего изменения, т. е. обеспечивается изо­лированность изменений данных транзакциями. Одни и те же данные в каж­дый момент времени может изменять только одна транзакция. Если какая-то другая транзакция пытается изменить эти же данные, то она должна ожидать завершения работы первой транзакции.
•	Level 1 — No dirty read (запрещение "грязного" чтения). Когда транзакция начинает изменение дан­ных, СУБД должна блокировать ресурсы, чтобы ни одна другая транзакция не смогла прочитать изменяемые данные до тех пор, пока транзакция не бу­дет зафиксирована или отменена. Транзак­ции, подавшие запрос на чтение данных, должны будут ожидать разблокиро­вания ресурсов.

 

•

Level 2 — No nonrepeatable read (запрещение неповторяемого чтения). Когда транзакция обра­щается к каким-то данным, СУБД организовывает блокировку таким образом, чтобы ни одна другая транзакция не могла изменить эти данные. Если транзакция только читает данные, то достаточно запре­тить только изменение данных. Если же транзакция изменяет данные, то не­обходимо полностью блокировать ресурсы, запретив также чтение данных.

•

Level 3 — No phantom (запрещение фантомов). Если транзакция производит выборку данных по логическому условию, то никакая другая транзакция не должна вставлять в таблицу или удалять из нее строки, удовлетворяющие этому логическому условию.

Mi­crosoft SQL Server 2000 поддерживает все уровни блокирования.

Использование транзакций

Начало транзакции:

BEGIN TRAN[SACTION] [ tran_name | @tran_var

[ WITH MARK [ 'description' ] ] ]

•	tran_name – имя транзакции;
•	@tran_ variable – переменная типа char, varchar, nchar, nvarchar;

 

•	WITH MARK [ 'description' ] – метка, используемая при описаниях в transact log.

При создании транзакций изменяется значение системной переменной @@TRANCOUNT, которая содержит номер активной транзакции для текущего соединения.

Для распределенных транзакций:

BEGIN DISTIBUTED TRAN[SACTION] [ tran_name | @tran_var]

Создание точек сохранения:

SAVE TRAN[SACTION] { save_point | @save_var}

ROLLBACK TRAN. С помощью данной команды выполняется откат транзакции. Данные, которые изменялись в ходе выполнения транзакции, восстанавли­ваются в состояние, в котором они были до начала транзакции. Кроме того, с помощью этой команды можно выполнить восстановление точки сохране­ния.

ROLLBACK [ TRAN [ SACTION ]

[ tran_name | @tran_var| save_point | @savet_var ] ]

или

ROLLBACK [ WORK ]

Команда ROLLBACK WORK – отменяет последнюю начатую транзакцию.

SQL Server 2000 контролирует работу транзакций на низком уровне, проверяя лишь соответствие данных наложенным ограничениям целостности и прави­лам. При нарушении целостности система автомати­чески выполняет откат транзакции.

COMMIT TRAN. Эта команда выполняет фиксирование транзакции.

COMMIT [TRAN[SACTION] [tran_name | @tran_var] ]

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