1.2. Транзакции в бд

Часть А. Транзакция(Transaction)- это последовательность операторов манипулирования данными, выполняющаяся как единое целое (все или ничего) и переводящая базу данных из одного целостного состояния в другое целостное состояние.

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

Изолированность(Isolation)- Транзакции разных пользователей не должны мешать друг другу

Согласованность(Consensity)- Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.

Атомарность(Atomicity)- Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

Фиксация (commit)-подтверждение транзакции.

Откат (rollback) -отмена транзакции

Часть Б. Транзакция гарантирует логическую целостность данных. Позволяет объединять различные действия в логические блоки и обеспечить возможность принимать решения об успешности действий всего блока операций в целом.

Часть В. Транзакции реализуются путем ведения журнала всех изменений, вносимых в базу данных в ходе каждой транзакции. При откате СУБД сверяется с журналом и отменяет все проведенные инструкции, вложенные в откатываемую транзакцию. Журнал также позволяет легко восстановить согласованное состояние базы данных в случае непредвиденного сбоя.

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

1.3. Бд для oltp и olap

Часть А

OLTP-приложений (On-Line Transaction Processing (OLTP)- оперативная обработка транзакций, в режиме реального времени.

OLAP-приложения (On-Line Analitical Processing (OLAP) - оперативная аналитическая обработка данных.

Хранилище данных (Data Warehouse) - предметно - ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

Часть Б. OLTP-системы оптимизированы для небольших дискретных транзакций. OLTP, как правило, автоматизируют структурированные, повторяющиеся задачи обработки данных.

OLAP используется аналитиками для быстрой обработки сложных запросов к базе данных.

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

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

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

Примером OLAP-приложений может служит подготовка бизнес-отчетов по продажам, маркетингу, в целях управления

1.4. Таблицы реляционной БД

А) Реляционная база данных — база данных, основанная на реляционной модели данных.

Реляц. модель (Relational Model) – модель, которая лежит в основе подавляющего большинства совр. комммерческих СУБД ( так называемых реляц. СУБД – Relational DBMS).

Реляционная БД — это совокупность отношений, содержащих всю ин­формацию, которая должна храниться в БД.

Б) Информация в БД может быть организована по-разному. Чаще всего используется табличный способ.

БД с табличной формой организации называются реляционными БД. Главное достоинство таблиц — в их понятности.

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

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

Поля — это различные характеристики объекта. Значения полей в одной строчке относятся к одному объекту. Разные поля отличаются именами. Главным ключом в БД называют поле (или совокупность полей), значение которого не повторяется у разных записей.

Требования к проектированию реляционной БД в общем виде можно свести к нескольким правилам.

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

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

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

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

• Полное информационное содержание БД представляется в виде яв­ных значений самих данных, и такой метод представления является единствен­ным. Например, связь между таблицами осуществляется на основе хранимых в соответствующих столбцах данных, а не на основе каких-либо указателей, искусственно определяющих связи.

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

Г)

1.5. Типы полей таблиц БД

А) Поля — это различные характеристики (атрибуты) объекта. Значения полей в одной строчке относятся к одному объекту. Разные поля отличаются именами.

Б) Поля - это основные элементы структуры базы данных. Они обладают свойствами. От свойств полей зависит, какие типы данных можно вносить в поле, а какие нет, а также то, что можно делать с данными, содержащимися в поле.

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

В реляционных БД используются четыре основных типа полей: числовой; символьный; дата; логический.

Числовой тип имеют поля, значения которых могут быть только числами.

Символьный тип имеют поля, в которых будут храниться символьные последовательности (слова, тексты, коды и т.п.).

Тип «дата» имеют поля, содержащие календарные даты в форме «день/месяц/год» (в некоторых случаях используется американская форма: месяц/день/год).

Логический тип соответствует полю, которое может принимать всего два значения: «да» — «нет» или «истина» — «ложь». Если двоичную матрицу представить в виде реляционной БД (табл. 6.4, 6.5), то ее полям, принимающим значения «О» или «1», удобно поставить в соответствие логический тип. При этом «1» заменится на значение «истина», «О» — на значение «ложь».

От типа величины зависят те действия, которые можно с ней производить.

Например, с числовыми величинами можно выполнять арифметические операции, а с символьными и логическими — нельзя.

Г) Числовой тип: в БД «Погода» три поля числового типа: ТЕМПЕРАТУРА, ДАВЛЕНИЕ, ВЛАЖНОСТЬ.

Символьный тип: поля АВТОР и НАЗВАНИЕ в БД «Домашняя библиотека»; поле ТЕЛЕФОН в БД «Школы».

Тип «дата»: поле ДЕНЬ в БД «Погода».

Логический тип: Есть задолженность либо нет.

1.6. Виртуальные таблицы

1.Virtual cabies –виртуально существующие таблицы которые строят СУБД на основе базовых таблицу представляет приложению возможность работать с ними как с реальными таблицами . SQL запрос из реальных таблиц СУБД строит вид таблицу в памяти временной в ответ на запрос приложений

Remote View –удаленная виртуальная таблицу построенная на основе чужих таблиц .

В отличии от классических View в material view данные сохраняются на диске после создания подобных запросов(первая придумавшая фирма oracle)

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

2.Материализованные представления позволяют многократно ускорить выполнение запросов, обращающихся к большому количеству (сотням тысяч или миллионам) записей, позволяя за секунды (и даже доли секунд) выполнять запросы к терабайтам данных.

3.1. SQL запрос из реальных таблиц СУБД строит таблицу в временной памяти в ответ на запрос приложений

2. Это достигается за счет прозрачного использования заранее вычисленных итоговых данных и результатов соединений таблиц. Предварительно вычисленные итоговые данные обычно имеют очень небольшой объем по сравнению с исходными данными.

4. Пусть вам нужна информация о служащих и выполняемых проектах, тогда можно создать следующую виртуальную таблицу:

CREATE VIEW PERSPROJ

AS SELECT

ENAME,

JOB,

PNAME

FROM EMPLOYEE, PROJECT

WHERE EMPLOYEE.PROJNO=PROJECT.PROJNO;

Выполняя команду

SELECT *

FROM PERSPROJ;

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

1.7. Хран. процедуры и триггеры

1.Процедура обработки которая хранятся на сервере (stored procedure)

Триггеры –особый ряд хранимой процедуры, автоматически запускаемой при выполнении в БД определенных событиях

1)Каждый триггер связан с 1ой таблицей

2) Событие (event),которые обрабатывают триггеры : вставка, изменение , удаление строки в таблицы

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

4) База для создания активных БД (active BD)

2.1. Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности данных.

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

Кроме собственно выполнения запроса, хранимые процедуры позволяют также производить вычисления и манипуляцию данными — изменение, удаление

2.Триггеры решают проблему обеспечения целостности данных и реализации сложной бизнес-логики.

3.1 Один-единственный оператор позволяет вызвать сложный сценарий, который содержится в хранимой процедуре, что позволяет избежать пересылки через сеть сотен команд и, в особенности, необходимости передачи больших объёмов данных с клиента на сервер.

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

2.Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера. Соответственно, в случае обнаружения ошибки или нарушения целостности данных может произойти откат этой транзакции.

Момент запуска триггера определяется с помощью ключевых слов BEFORE (триггер запускается до выполнения связанного с ним события; например, до добавления записи) или AFTER (после события). В случае, если триггер вызывается до события, он может внести изменения в модифицируемую событием запись (конечно, при условии, что событие — не удаление записи).

4 триггер

допустим у нас есть таблица «Sotrydnik» БД “Ludi”. Необходимо запретить вставлять запись о сотруднике оклад которого, менее 20000 рублей.

CREATE TRIGGER primer1 ON sotrydnik AFTER INSERT AS BEGIN SET NOCOUNT ON; if (select oklad from inserted)<'20000' rollback print'Вы не можете вставлять запись о сотруднике с окладом менее 20 000 рублей' END

Хранимая процедура

пример очень простой хранимой процедуры, которая принимает на входе два числа, складывает их и возвращает полученный результат: CREATE PROCEDURE SP_Add(first_arg DOUBLE PRECISION,  second_arg DOUBLE PRECISION)  RETURNS (Result DOUBLE PRECISION)  AS BEGIN Result=first_arg+second_arg; SUSPEND;  END

1.9А. Целостность базы данных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам.

Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).

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

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

Г. Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.

Связи в ER-моделях

А. Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных.

СУЩНОСТЬ – это объект предметной области, элемент информационной системы. В ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности и ее атрибуты.

АТРИБУТ СУЩНОСТИ – простейший элемент информационной системы, формирующийся вручную или посредством классификаторов из элементов первичной однородной фактографической информации, разделенной по назначению.

Линии, связывающие сущности в ER-моделях, определяют взаимосвязи между объектами предметной области.

СВЯЗЬ – это ассоциация между сущностями, где, как правило, каждый экземпляр одной сущности (родительская сущность) ассоциируется с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя. Связи в ER-моделях могут определяться как между двумя разными сущностями, так и между сущностью и ей же самой, такая связь называется рекурсивной связью. Связи в ER-диаграммах могут быть типа один к одному (1:1), один ко многим (1:М), многие ко многим (М:М).

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

В. Как и любая другая модель, модель «сущность-связь» имеет несколько базовых понятий, на основании которых стоятся уже более сложные объекты по заранее определенным правилам.

ER-модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент является без сомнений основной при разработке крупных информационных систем.

Г. «один к одному» (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

«один ко многим» (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

«многие к одному» (М:1)

«многие ко многим» (М: М)

2.4. 4- и 5НФ

А. Четвертая нормальная форма (4НФ) — это НФБК, в которой отсутствуют нетривиальные многозначные за­висимости

Многозначная зависимость (Multi-Valued Dependency) - означает, что если присутствуют экземпляры сущности, имеющие значения (a, b₁ с_1,) и (a, b₂ с₂), то должны присутствовать и экзем­пляры (a, b₁ с₂) и (a, b₂ с₁). Многозначная зависимость яв­ляется обобщением понятия функциональной зависимо­сти.

Пятая нормальная форма (5НФ) — это 4НФ, в ко­торой отсутствуют так называемые зависимости соеди­нения (нетривиальные).

Зависимость соединения (или «по соединению») (Join Dependency) — это такое ограничение целостности, при котором сущность может быть декомпозирована без потери инфор­мации на п сущностей, где п — 2 для тривиального слу­чая и п > 2 для нетривиального.

Б. Главное, чего мы добьемся, проведя нормализацию базы данных – это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.

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

Г. Пример 4 НФ. Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной ключ таблицы такого отношения включает три поля: {Ресторан, Вид пиццы, Район доставки}. Такая таблица не соответствует 4NF, так как существует многозначная зависимость:

{Ресторан} →→ {Вид пиццы}

{Ресторан} →→ {Район доставки}

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

Пример 5 НФ. Предположим, что продавец может торговать продукцией нескольких фирм, ассортимент у фирм различен, причем продавец может предлагать только часть товаров конкретной фирмы. Отношение {Продавец, Фирма, Вид товара} соответствует 4NF, однако не отражает ограничения, связанного с ассортиментом продукции фирм. Может возникнуть кортеж, в котором фирме будет соответствовать вид товара, который она не выпускает.

В данном случае (для приведения к 5NF) отношение должно быть разбито на три: {Продавец, Фирма}, {Фирма, Вид товара}, {Продавец, Вид товара}.