ОБЩИЙ ОБЗОР МЕТОДОЛОГИИ ФИЗИЧЕСКОГО ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам "физической" БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (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 (запрещение фантомов). Если транзакция производит выборку данных по логическому условию, то никакая другая транзакция не должна вставлять в таблицу или удалять из нее строки, удовлетворяющие этому логическому условию. |
Microsoft 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 выполняется без указания имени транзакции, то происходит фиксирование последней транзакции. Если транзакции создаются друг из друга, то происходит образование вложенных транзакций. Пользователь может производить поочередно фиксирование каждой транзакции либо выполнить фиксирование транзакции высокого уровня с указанием имени транзакции.