- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Таблица A
- •Таблица A
- •Таблица A
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Элементы языка SQL
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Физическое проектирование БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •Технологии построения информационных систем – приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
- •: Проектирование приложений БД
Элементы языка SQL
Исключения
Пример определение исключения:
CREATE EXCEPTION UNKNOWN_EMP_ID «Неизвестный идентификатор”
Пример вызова исключения:
EXCEPTION UNKNOWN_EMP_ID
Пример удаления исключения:
DROP EXCEPTION UNKNOWN_EMP_ID
Элементы языка SQL
Использование генераторов в InterBase
Основные понятия
В InterBase отсутствует аппарат автоинкрементных столбцов. Вместо этого для установки уникальных значений столбцов используются генераторы.
Генератор – хранимый на сервере БД механизм, возвращающий уникальные значения , никогда не совпадающие со значениями, выданными тем же самым генератором в прошлом.
Для создания генератора используется оператор:
CREATE GENERATOR ИмяГенератора ;
Установка стартового значения генератора:
SET GENERATOR ИмяГенератора TO СтартовоеЗначение;
Обращение к генератору (получение уникального значения):
GEN_ID( ИмяГенератора , Шаг )
Элементы языка SQL
Использование генераторов в InterBase
Основные понятия
Пример:
CREATE GENERATOR RASHOD_N_RASH;
SET GENERATOR RASHOD_N_RASH TO 20 ;
CREATE TRIGGER BI_RASHOD FOR RASHOD ACTIVE
BEFORE INSERT AS
BEGIN
NEW.N_RASH = GEN_ID(RASHOD_N_RASH, 1); END
Физическое проектирование БД
Транзакции
Назначение трaнзакции:
Откат изменений и целостность БД Понятие транзакции
Транзакция – это единичное или чаще групповое изменение БД, которое или выполняется полностью, или не выполняется вообще.
Результаты выполнения транзакции записываются в БД только в том случае, если вся транзакция завершилась успешно. Таким образом, транзакция переводит БД из одного целостного состояния в другое.
Начало транзакции инициируется оператором :
SET TRANSACTION [имя транзакции]
Подтверждение транзакции, т.е. санкционирование физического запоминания сделанных изменений в БД выполняется оператором COMMIT
COMMIT WORK [TRANSACTION name]
Отказаться от физического запоминания сделанных изменений («откатить изменения») можно с помощью оператора.
ROLLBACK WORK [TRANSACTION name]
Замечание. Описанные выше операторы представлены в упрощенном формате. Полный формат содержит дополнительные параметры управления транзакциями.
Физическое проектирование БД
Транзакции
Уровни изоляции транзакций
При одновременной работе нескольких клиентов с одной и той же БД возникают проблемы одновременного изменения данных.
Пусть пользователь A получил данные из таблицы RASHOD и впоследствии изменил их. В это же время с той же записью в таблице RASHOD работает пользователь B. Он также изменил записи в той же записи, что и A, и пытается подтвердить их. Пользователь C работает с таблицей RASHOD в режиме «только для чтения». Сразу же возникает группа вопросов:
•Позволять или не позволять B изменять запись, если A еще не подтвердил ее изменение?
•Позволять ли C видеть изменения, внесенные A и B?
•Может ли A видеть изменения, внесенные B, и наоборот?
•Для разрешения указанных проблем на стороне клиента определены три уровня изоляции (разграничения) транзакций.
Для разрешения указанных проблем на стороне клиента определены три уровня изоляции (разграничения) транзакций.
Физическое проектирование БД
Транзакции
Уровни изоляции транзакций
1.При уровне изоляции транзакций Dirty Read («грязное чтение») конкурирующие транзакции видят изменения, внесенные, но не подтвержденные текущей транзакцией. Если текущая транзакция откатит сделанные изменения, другие транзакции будут обладать недостоверными данными. Этот уровень изоляции может привести к серьезным ошибкам и применяется крайне редко – фактически он не изолирует конкурирующие транзакции.
2.При уровне Read Committed («подтвержденное чтение») конкурирующие транзакции работают с данными, какими они были на момент старта транзакции A. однако, если транзакция A внесла изменения в запись и подтвердила их, а незавершенная транзакция вновь прочитала эти данные, она увидит изменения.
3.Уровень изоляции Repetable Read («повторяющееся чтение») заставляет конкурирующие транзакции оперировать с собственными (локальными) версиями одной и той же записи. Если транзакция A читает какую-то запись, она, как и при уровне ReadCommited, получит последнюю подтвержденную ее версию. Однако, если другая транзакция изменит эту запись, а транзакция A вновь прочитает ее, она не увидит внесенных изменений, т.е. A видит всегда одну и ту же версию записи. Изменения, которые вносят конкурирующие транзакции в одну и ту же запись, могут конфликтовать. В этом случае фактически изменит данные первая завершенная транзакция, а попытки подтвердить свои изменения второй и всеми другими незавершенными транзакциями, изменившими те же записи, будут отвергнуты.
Физическое проектирование БД
Транзакции
Уровни изоляции транзакций
Разные серверы БД различным образом интерпретируют уровни изоляции транзакций
Сервер БД |
Уровень изоляции |
Интерпретируется как |
Oracle |
Dirty Read |
Read Committed |
|
Read Committed |
Read Committed |
|
Repetable Read |
Repetable Read |
MS SQL Server, Sybase |
Dirty Read |
Read Committed |
|
Read Committed |
Read Committed |
|
Repetable Read |
Не поддерживается |
DB2 |
Dirty Read |
Dirty Read |
|
Read Committed |
Read Committed |
|
Repetable Read |
Repetable Read |
Informix |
Dirty Read |
Dirty Read |
|
Read Committed |
Read Committed |
|
Repetable Read |
Repetable Read |
InterBase |
Dirty Read |
Read Committed |
|
Read Committed |
Read Committed |
|
Repetable Read |
Repetable Read |
Несерверные СУБД |
Dirty Read |
Dirty Read |
|
Read Committed |
Не поддерживается |
|
Repetable Read |
Не поддерживается |
Физическое проектирование БД
Транзакции
Уровни изоляции транзакций
В InterBase с учетом управляющих параметров формат оператора начала транзакции выглядит следующим образом:
SET TRANSACTION [ имя транзакции ] [ READ WRITE | READ ONLY ] [ WAIT | NO WAIT ]
[[ ISOLATION LEVEL ] {SNAPSHOT | READ COMMITTED [ [ NO ] RECORD_VERSION]}]
------------------------------
READ WRITE | READ ONLY WAIT – устанавливает уровень доступа к данным (по умолчанию READ WRITE )
WAIT | NO WAIT – определяет поведение при возникновении конфликта при обновлении записи данной транзакции с другой транзакцией, ранее сделавшей изменение в той же записи: WAIT (по умолчанию) побуждает данную транзакцию ожидать завершения конкурирующей транзакции; NO WAIT определяет аварийное завершение данной транзакции.
ISOLATION LEVEL – определяет уровни изоляции транзакций на сервере (по умолчанию SNAPSHOT, что соответствует уровню REPETABLE READ.
READ COMMITTED разрешает стартующей транзакции читать только подтвержденные записи:
NO RECORD_VERSION (по умолчанию) – читается последняя версия записи, даже если она не подтверждена другой транзакцией; при этом если указан параметр WAIT, стартующая транзакция будет ожидать подтверждения последней версии; RECORD VERSION – читается последняя подтвержденная версия записи.
Пример.
SET TRANSACTION WAIT
ISOLATION LEVEL READ COMMITTED
Физическое проектирование БД
Учет особенностей используемого сервера БД
Основная часть проблем физического проектирования баз данных в большой степени зависит от особенностей используемого сервера баз данных. В частности, это относится к планированию размещения в дисковой памяти различных частей базы данных: таблиц, индексов, BLOB'ов, журналов и т.д. Соответствующие рекомендации обычно содержатся в руководстве администратора используемой системы. Но можно, тем не менее, выделить некоторые общие соображения, которые осмысленны вне зависимости от деталей реализации сервера. Прежде всего это касается индексов.
Понятно, что чем больше индексов существует над таблицами базы данных, тем более вероятным будет выполнение запросов по выборке данных и тем медленнее будут выполняться операции модификации базы данных.
Физическое проектирование БД
Учет особенностей используемого сервера БД
В большинстве систем индекс создается автоматически для каждого определенного в таблице первичного, возможного и внешнего ключа. Здесь никуда не денешься: потребность в определении ключей следует из семантики предметной области, а для поддержания и использования ключей СУБД нуждается в соответствующих индексах. Но вот что касается дополнительных индексов, вводимых для целей более эффективного выполнения запросов, то с ними нужно быть очень аккуратным. Требуется тщательный предварительный анализ наиболее важного набора запросов (к сожалению далеко не всегда это возможно). Нужно также отдавать себе отчет в том, что создание нового индекса для большой заполненной таблицы - это серьезная дорогостоящая операция (как правило, СУБД выполняет сортировку строк таблицы в соответствии со значением ключевого атрибута).
Хотя в языке SQL и в большинстве его реализаций допускается динамическое изменение реляционной схемы базы данных, не все такие изменения выполняются дешево и безопасно. Дешево и безопасно можно создать новую таблицу с набором индексов и добавить столбец к существующей заполненной таблице. Дорого и опасно уничтожается большая заполненная таблица или ее отдельный столбец. (Опасно в том смысле, что, как правило, соответствующие операции не журнализуются.)