- •Реляционная модель данных. Общая характеристика. Целостность реляционных данных.
- •Технологии проектирования реляционных бд. Этапы разработки базы данных. Критерии оценки качества логической модели данных.
- •Проектирование реляционных баз данных на основе принципов нормализации. Понятие метода нормализации отношений. Декомпозиция без потерь и функциональные зависимости. 1-я форма.
- •Минимальные функциональные зависимости и вторая нормальная форма.
- •Нетранзитивные функциональные зависимости и третья нормальная форма.
- •Перекрывающиеся возможные ключи и нормальная форма Бойса-Кодда.
- •Проектирование реляционных баз данных с использованием семантических моделей. Семантическая модель Entity-Relationship. Основные понятия er-модели. Уникальные идентификаторы типов сущности.
- •Нормальные формы er-диаграмм.
- •Получение реляционной схемы из er-диаграммы. Базовые приемы. Представление в реляционной схеме супертипов и подтипов сущности. Представление в реляционной схеме взаимно исключающих связей.
- •Методология idef1x.
- •Основные понятия диаграмм классов uml. Получение схемы рбд из диаграммы классов uml.
- •15.Case-системы проектирования информационных систем. Назначение и разновидности case-систем.
- •16.Классификация архитектур построения приложений баз данных.
- •17.Базовая архитектура сервера баз данных.
- •18.Технология хранилищ данных. Концепция хранилищ данных. Отличия хранилищ данных от систем oltp.
- •Отличия хранилищ данных от систем oltp
- •19.Системы оперативной аналитическая обработка (olap). Связь olap и хд. Структура информационно-аналитической системы и место olap в ней.
- •Связь olap и хд
- •Структура информационно-аналитической системы и место olap в ней
- •Логическая многомерная модель
- •Архитектуры olap
- •О преимуществах и недостатках различных архитектур Реляционное хранилище
- •24.Основы sql. Формат оператора select. Использование предложения where для задания условия отбора и внутреннего соединения таблиц.
- •25.Основы sql. Формат оператора select. Использование псевдонимов таблиц. Определение сортировки. Устранение повторяющихся значений. Расчет значений вычисляемых столбцов.
- •26.Основы sql. Формат оператора select. Агрегатные функции. Группировка записей. Наложение ограничений на группировку записей.
- •27.Основы sql. Формат оператора select. Вложение подзапросов.
- •28.Основы sql. Формат оператора select. Внешние соединения
- •29.Основы sql. Формат оператора select. Объединение запросов – union. Использование is null. Использование операции сцепления строк.
- •30.Основы sql. Формат оператора insert. Явное указание списка значений. Формирование значений при помощи оператора select.
- •1.1.2.1.Явное указание списка значений
- •1.1.2.2.Формирование значений при помощи оператора select
- •31. Основы sql. Формат операторов update и delete.
- •1.1.4.Оператор delete Формат оператора удаления записей
- •32. Основы sql. Работа с просмотрами (view).
- •1.1.5.Работа с просмотрами (view) Понятие просмотра как виртуальной таблицы
- •1.1.5.1.Способы формирования просмотра
- •1.1.5.2.Обновляемые и не обновляемые просмотры
- •1.1.5.3.Дополнительные параметры просмотра
- •Основы sql. Понятие хранимой процедуры. Алгоритмический язык хранимых процедур. Создание хп.
- •Основы sql. Понятие хранимой процедуры. Алгоритмический язык хранимых процедур. Создание хп, параметры и переменные в хп.
- •1.1.6.Создание хранимой процедуры Хранимая процедура создается оператором:
- •1.1.7.Алгоритмический язык хранимых процедур Формат объявления локальных переменных:
- •Операторные скобки :Используются для указания границ составного оператора begin ... End ;
- •Основы sql. Понятие хранимой процедуры. Алгоритмический язык хранимых процедур. Формат оператора select в хп.
- •Оператор for select … do
- •1.1.8.Изменение хп
- •36. Основы sql. Понятие хранимой процедуры. Алгоритмический язык хранимых процедур. Операторы if, while, exit, suspend. Оператор вызова хп.
- •Оператор execute procedure Оператор вызова другой хранимой процедуры:
- •37. Понятие и особенности триггера. Использование триггеров для реализации каскадных воздействий.
- •1.1.9.Создание триггеров
- •38. Понятие и особенности триггера. Использование триггеров для реализации бизнес-правил.Использование генераторов.
- •1.1.10.Изменение существующего триггера:
- •39. Основы sql. Понятие транзакции. Уровни изоляции транзакций.
- •1.2.1.Уровни изоляции транзакций
- •40. Физическое проектировании бд. Способы повышения производительности работы с бд. Определение структуры индексов. Денормализация. Оптимизация запросов.
- •1.3.1.Денормализация для оптимизации
- •Целесообразность создания индексов. Их необходимо создавать в случае, когда по столбцу или группе столбцов:
- •Уменьшение общего количества индексов.
- •41. Реализация доступа к базам данных на примере Borland Delphi. Понятие набора данных. Механизмы доступа.
- •Компоненты для доступа к данным, реализующие:
- •Визуальные компоненты, реализующие интерфейс пользователя;
- •42. Реализация доступа к базам данных на примере Borland Delphi. Применение многозвенных архитектур.
39. Основы sql. Понятие транзакции. Уровни изоляции транзакций.
Существует несколько способов внесения изменений в таблицы БД. Для локальных (не серверных) БД характерен подход немедленного отображения изменений. Все изменения, внесенные операторами изменения данных в БД немедленно физически запоминаются в таблицах БД и становятся доступны для всех пользователей БД. Отказаться от изменений в этом случае невозможно. Необходимость отката изменений обуславливается тем, что БД всегда должна находиться в целостном состоянии. Существуют механизмы отката изменений в БД в случае невыполнения условия успешного завершения всех операций в составе группы. Один из таких механизмов носит название обработка транзакций. Обычно обработка транзакций реализуется серверами БД.
Транзакция – это единичное или чаще групповое изменение БД, которое или выполняется полностью, или не выполняется вообще. Результаты выполнения транзакции записываются в БД только в том случае, если вся транзакция завершилась успешно. Таким образом, транзакция переводит БД из одного целостного состояния в другое.
Начало транзакции инициируется оператором : SET TRANSACTION [имя транзакции]
Подтверждение транзакции, т.е. санкционировать физическое запоминание сделанных изменений в БД выполняется оператором COMMIT: COMMIT WORK [TRANSACTION name]
Отказаться от физического запоминания сделанных изменений («откатить изменения») можно с помощью оператора. ROLLBACK WORK [TRANSACTION name]
Описанные выше операторы представлены в упрощенном формате. Полный формат содержит дополнительные параметры управления транзакциями.
1.2.1.Уровни изоляции транзакций
При одновременной работе нескольких клиентов с одной и той же БД возникают проблемы одновременного изменения данных. Пусть пользователь A получил данные из таблицы RASHOD и впоследствии изменил их. В это же время с той же записью в таблице RASHOD работает пользователь B. Он также изменил записи в той же записи, что и A, и пытается подтвердить их. Пользователь C работает с таблицей RASHOD в режиме «только для чтения». Сразу же возникает группа вопросов:
Позволять или не позволять B изменять запись, если A еще не подтвердил ее изменение?
Позволять ли C видеть изменения, внесенные A и B?
Может ли A видеть изменения, внесенные B, и наоборот?
Для разрешения указанных проблем на стороне клиента определены три уровня изоляции транзакций.
При уровне изоляции транзакций Dirty Read («грязное чтение») конкурирующие транзакции видят изменения, внесенные, но не подтвержденные текущей транзакцией. Если текущая транзакция откатит сделанные изменения, другие транзакции будут обладать недостоверными данными. Этот уровень изоляции может привести к серьезным ошибкам и применяется крайне редко – фактически он не изолирует конкурирующие транзакции.
При уровне Read Committed («подтвержденное чтение») конкурирующие транзакции работают с данными, какими они были на момент старта транзакции A. однако, если транзакция A внесла изменения в запись и подтвердила их, а незавершенная транзакция вновь прочитала эти данные, она увидит изменения.
Уровень изоляции Repetable Read («повторяющееся чтение») заставляет конкурирующие транзакции оперировать с собственными (локальными) версиями одной и той же записи. Если транзакция A читает какую-то запись, она, как и при уровне ReadCommited, получит последнюю подтвержденную ее версию. Однако, если другая транзакция изменит эту запись, а транзакция A вновь прочитает ее, она не увидит внесенных изменений, т.е. A видит всегда одну и ту же версию записи. Изменения, которые вносят конкурирующие транзакции в одну и ту же запись, могут конфликтовать. В этом случае фактически изменит данные первая завершенная транзакция, а попытки подтвердить свои изменения второй и всеми другими незавершенными транзакциями, изменившими те же записи, будут отвергнуты.
Разные серверы БД различным образом интерпретируют уровни изоляции транзакций.
Для InterBase с учетом управляющих параметров формат оператора начала транзакции выглядит следующим образом:SET TRANSACTION [ имя транзакции ]
[READ WRITE | READ ONLY]
[WAIT | NO WAIT]
[[ISOLATION LEVEL] {SNAPSHOT [TABLE STABILITY]
| 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 – читается последняя подтвержденная версия записи.