Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
ИНФОРМАЦИОННАЯ СИСТЕМА
Информационная система – это совокупность, содержащаяся в базе данных информации и обеспечивающих её обработку информационных технологий и технических средств.
Автоматизированными называют информационные системы, которые включают технические средства.
Информационные системы можно классифицировать по области применения (промышленность, образование и т.д.) и по целевой функции ( управляющие, информационно справочные и поддержки принятия решений, банк данных – разновидность информационной. Системы, в которой реализованы функции централизованного хранения и накопления обрабатываемой информации, организованной в одну или несколько баз данных).
База данных – это интегрированная компьютерная структура совместного доступа, в которой хранится совокупность специальным образом организованных данных, отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.
Логическую структуру хранимых в БД данных называют моделью представления данных(иерархическая, сетевая, реляционная и т.д.).
Система управления базами данных(СУБД) – это комплекс языковых и программных средств, с помощью которых осуществляется управление структурой базы данных и контроль доступа к данным, хранящимся в ней.
Словарь данных – это хранилище мета-данных(данных о данных), которые описывают свойства о данных и совокупность отношений, которыми связаны данные, хранящиеся в базе данных.
Модели баз данных можно разделить на 2 категории:
1. Концептуальные модели – нацелены на логическую природу представления данных, таким образом в ней основное внимание уделяется тому, ЧТО представлено в базе данных, а не тому КАК это представлено.
К концептуальным моделям относится модель сущность-связь( ER-модель ) и объектно-ориентированная модель
2. Модели реализации – в этих моделях основное внимание уделяется способу представления данных, т.е. тому, как реализовать структуры данных, чтобы получить представление о том, что проектируется.
К моделям реализации относится иерархическая модель, сетевая модель, реляционная модель и ОО-модель.
ИСПОЛЬЗОВАНИЕ КОНЦЕПТУАЛЬНЫХ МОДЕЛЕЙ, ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ
Проектирование информационных систем состоит из трех этапов:
1. Концептуальное(инфологическое) проектирование
Это построение формализованной модели предметной области, целью инфологического моделирования является формализация объектов реального мира предметной области и методов обработки информации, в соответствии с поставленными задачами обработки и требованиями представления данных естественными для человека способами сбора и представления информации.
Инфологическая модель строится без ориентации на какую-либо конкретную СУБД.
Основными элементами модели являются:
1. Описание объектов предметной области и связи между ними
2. Описание информационных потребностей пользователей
3. Описание алгоритмических зависимостей между данными
4. Описание ограничений целостности, т.е. требования допустимых значений данных и связей между ними.
При инфологическом проектировании рассматриваемая предметная область может быть представленная двумя видами моделей:
1. Функциональная модель рассматривает предметную область как набор функций, преобразующих входной поток информации в выходной поток. В функциональной модели функции(методы) обработки данных четко отделяются от самих данных.
Наиболее распространенная модель – IDEF0, так же широко известна DFD-диаграммы(диаграммы потоков данных)
Главным недостатком функциональных моделей является то, что процесс существует отдельно от данных и структура данных уходит на второй план, поэтому для инфологического проектирования часто используются ОО-модели. При этом подходе в рассматриваемой предметной области выделяют классы объектов, для которых определяются методы обработки, что в конечном счете обеспечивает лучшую реализацию динамического поведения информационных систем.
При ОО-подходе используют графический метод моделирования предметной области. Например , с помощью языка UML. Классическим подходом является проектирование информационных систем является проектирование информационных систем с помощью диаграмм сущность-связь (ER-диаграммы). При разработке как функционально ориентированных, так и объектно-ориентированных моделей часто исп. CASE-средства.
В ER-диаграмме используется графическое представление моделей компонентов базы данных. Основу ER-модели составляют следующие компоненты:
1. Сущность – логический объект, персона, местоположение или предмет, сведения о которых подлежат сбору и хранению. На ER-диаграмме сущность представляется в виде прямоугольника, название сущности ( имя существительное ) записывается в центре прямоугольника как правило заглавными буквами и предпочтительно в единственном числе на русском языке. Обычно если ER-диаграмма связана с реляционной моделью сущность отображается на реляционную таблицу. Каждая строка реляционной таблицы соответствует экземпляру сущности. Сущность описывается набором атрибутов. Каждый атрибут описывает отдельное свойство сущности.
2. Связь – описывает соединение между данными, большинство связей описывает соединение между двумя сущностями. Для обозначения типа связей используется термин «связность». В концептуальной модели используется 3 типа связей для описания отношений между данными:
- один ко многим – 1 : М (пример: художник – картины)
- многие ко многим – М : М или М : N (пример: студент – предмет)
- один к одному – 1 : 1 (пример: сотрудник – магазин в сети)
ER-диаграммы, представленные выше, основаны на модели Чена, в которой связи обозначаются ромбами, а сущности прямоугольниками. Другой широко известный способ называется «птичья лапка».
2. Даталогическое проектирование – это отображение инфологической модели на модель данных, используемой в конкретной СУБД. Для реляционной СУБД даталогическая модель – это набор таблиц, обычно с указанием ключевых полей и связей между таблицами.
3. Физическое проектирование – это реализация логической модели средствами конкретной СУБД, а так же выбор решений, связанных с физической средой хранения данных(выбор типов и размеров данных, определение индексов и т.д.)
РЕЛЯЦИОННАЯ МОДЕЛЬ (наиболее широко применяемая и стандартизированная)
Реляционная модель данных была предложена сотрудником IBM Эдгаром Коддом и основывается на понятии «отношения» (Relation). Реляционная модель данных представляется набором связанных таблиц, в которых хранятся данные, и состоит из трех частей: структурной части, целостной части, манипуляционной части.
Структурная часть описывает, какие объекты рассматриваются в реляционной модели. Постулируется, что единственной структурой данных, используемых в реляционной модели, являются нормализованные n-арные отношения. Отношения в реляционной модели представляются в виде таблиц (Эдгар Кодд использовал слово»отношение» как синоним слова «таблица») под таблицей понимается двумерная структура, состоящая из строк и столбцов, которая содержит группу связанных сущностей, т.е. набор сущностей.
Отношения характеризуются следующими параметрами:
STUDENT (ТАБЛИЦА 1)
|
SNUM |
LNAME |
FNAME |
PASP |
DOB |
SGR |
PHONE |
AVM |
SHOST |
|
20236 |
Иванов |
Петр |
1109 222333 |
4.11.1995 |
413 |
1234567 |
4.5 |
no |
|
20237 |
Петров |
Сидор |
4110 333222 |
7.01.1996 |
414 |
+79213334445 |
4.6 |
yes |
|
20238 |
Сидоров |
Иван |
4111 123456 |
1.05.1995 |
415 |
9876543 |
4.7 |
no |
Таблица представляет собой двумерную структуру, состоящую из строк и столбцов.
Роль ключа основана на концепции определяемости.
В контексте таблиц баз данных, выражение А определяет В, означает, что зная значение атрибута А можно найти значение атрибута В.
Принцип определяемости используется при формулировании центральной концепции реляционных баз данных – функциональной зависимости.
Атрибут В функционально зависит от атрибута А, если все строки в таблице, совпадающие по значению атрибута А, так же совпадают по значению атрибута В. Для определения функциональной зависимости может потребоваться более чем один атрибут, т.е. ключ может состоять больше чем из одного атрибута. Такие ключи называют составными.
Любой атрибут, который является частью составного ключа, называют ключевым атрибутом.
Типы ключей:
Пример(суперключ): Из ТАБЛИЦА 1
SNUM
SNUM,LNAME
SNUM, LNAME,FNAME
Пример(потенциальный ключ):
SNUM
PASP
LNAME,FNAME
Пример(первичный ключ):
PASP
Пример(альтернативный ключ):
SNUM
Ключи используют для:
Использование пустого значения связано с практической потребностью хранить в базе данных не только достоверную и полностью определенную информацию, но и такую, которая частично неточна или неопределенна.
Приведем 3 характерных примера:
Эти три примера иллюстрируют три наиболее распространенных случае неполноты информации, их соответственно называют случаями неизвестности, неприменимости и возможности. Поэтому обычно в реляционных СУБД выделяют одно специальное значение NULL, которое считается автоматически входящим в любой встроенный тип данных и любой определенный пользователем домен. Что имеется ввиду под неопределенным значением в каждом конкретном случае определяется семантикой предметной области.
В языке запросов фиксируется лишь следующее, если при вычислении арифметического выражения хотя бы одно из использованных значений есть NULL, то и значение всего арифметического выражения есть NULL, соответственно в операциях сравнения, значения левого или правого операнда или и того и другого есть нулл, то результатом операции сравнения является «неизвестно». Тем самым в языке запросов используется не двузначная, а трехзначная логика. Таблицы истинности основных операций расширяются следующим образом:
Таким образом наличие выделенного неопределенного значения null в некоторой степени решает проблему представления неполной информации, во вторых трехзначная логика позволяет в ряде случаев не заботится о наличии неопределенных значений при формулировке запросов.
Как принято говорить неопределенное значение и трехзначная логика позволяют повысить выразительную мощность языка запросов.
В реляционных СУБД для указания связи таблиц производят операцию их связывания. Преимущества, обеспечивающиеся связыванием таблице, заключаются:
Между таблицами могут устанавливаться бинарные, тернарные и в общем случае n-арные связи.
Рассмотрим бинарные связи. Суть связи состоит в установлении соответствия полей связи между двумя таблицами, т.е. связь создается, когда две таблицы совместно используют один атрибут с общим значением, т.е. когда первичный ключ одной таблицы появляется в качестве внешнего ключа связанной таблицы.
Связь вида 1:1 является частным случаем связи 1:M и образуется, когда все поля связи одной и другой таблицы являются первичными ключами. Поскольку значения в первичных ключах обеих таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей этих таблиц. На практике связи вида 1:1 используются сравнительно редко, т.к. хранимую в двух таблицах информацию в этом случае можно объединить в одну таблицу, однако в некоторых случаях для ускорения обработки информации, повышения удобства работы нескольких пользователей с общей информацией, обеспечение более высокой степени защиты информации, действительно может оказаться удобней иметь две и более таблиц.
Связь 1:М имеет место в случае, когда одной записи первой(главной) таблицы соответствует несколько записей второй(подчиненной, дочерней) таблицы.
Самый общий вид связи М:М возникает в случаях, когда нескольким записям одной таблицы соответствует несколько записей другой таблицы. При этом каждая сторона отношения выглядит как отношение 1:М. Однако если рассматривать взаимосвязь таблиц с двух сторон становится очевидно, что ни одна из таблиц не может быть главной и для их связывания необходима третья таблица. Связующая таблица представляет собой промежуточную таблицу, которая служит «мостом» между двумя таблицами в отношении М:М, её ключ состоит из ключевых полей этих таблиц, с каждой из которых она связана отношением «многие к одному», помимо ключевых полей связующая таблица может содержать дополнительные поля, которых нет в связываемых таблица, но которые могут иметь значение для каждой из них. Связанные поля не обязательно должны иметь одинаковые имена, однако они должны иметь одинаковые типы данных. Существует возможность создавать связь между текстовыми полями разной длины, однако это может вызвать сложности при создании запросов.
Неидентифицирующая связь имеет место, когда в связь вступают две самостоятельные сущности. Неидентифицирующая связь обозначается прерывистой линией. Идентифицирующая связь является особым случаем обязательной связи.
Если сущность А связана с сущностью В идентифицирующей связью, то существование экземпляра В невозможно и не имеет смысла без существования экземпляра А. Сущность В в этом случае называют зависимой или слабой сущностью. Экземпляр сильной или независимой сущности существует сам по себе независимо от всех других сущностей.
На диаграммах слабые сущности обозначают прямоугольниками с закругленными углами. Прямоугольник, изображающий сильные сущности, имеет прямые углы.
Согласованность базы данных есть формальное свойство БД. База данных «не понимает» смысла хранимых данных. Смыслом данных для СУБД является весь набор ограничений целостности. Если все ограничения выполнены, то СУБД считает, что данные корректны.
Ограничения целостности – это некоторые утверждения, которые могут быть истинными или ложными в зависимости от состояния БД. Примерами ограничений целостности могут служить следующие утверждения:
Некоторые из ограничений целостности являются ограничениями реляционной модели данных, они должны выполняться для любых отношений, в любых реляционных базах данных.
Пример 1 представляет ограничение, реализующее целостность на уровне сущности, которое говорит о том, что в пределах таблицы первичный ключ должен быть уникален, чтобы однозначно идентифицировать каждую строку. Для обеспечения целостности на уровне сущности в первичном ключе недопустимы пустые значения. Пример 2 представляет ограничение, реализующее ссылочную целостность(целостность на уровне ссылки). Контроль целостности связи обычно означает анализ содержимого двух таблиц на соблюдение следующих правил:
Таким образом, ссылочная целостность проявляется, если внешний ключ содержит значения, совпадающие с первичным ключом в таблице на стороне «1» или пустые значения.
Другие ограничения являются достаточно произвольными утверждениями.
Любое ограничение целостности является семантическим понятием, т.е. проявляется как следствие определенных свойств объектов предметной области и(или) их взаимосвязи. Если какая-то СУБД не может отобразить все необходимые ограничения предметной области, то такая БД хотя и будет находится в целостном состоянии, с точки зрения СУБД, но это состояние может не быть правильным с точки зрения пользователя.
Вместе с понятием целостности БД возникает понятие реакции системы на попытку нарушения целостности.
Попытка выполнить операцию по удалению/добавлению или модификации данных
Пользователь или приложение
Проверка ограничений
Операция отвергается
Сообщение пользователю СУБД
Ограничения не нарушают
Операция выполняется
Ограничение нарушений
Операция выполняется, дополнительно выполняется компенсирующая операция
Файл
Классификация файлов и файловых структур, использующихся для хранения информации в БД.
Прямого доступа
Однонаправленные цепочки
Двунаправленные цепочки
Индексно прямые(Плотный индекс)
Неплотный индекс(Индексно последовательные)
В - деревья
Взаимосвязанные файлы
Последовательного доступа
Инвертированные списки
Индексные
Соответственно в реляционной СУБД возникают следующие разновидности объектов во внешней памяти:
Существует два принципиальных подхода для физического хранения отношений, наиболее распространенным способом является покартежное хранение отношений, т.е. картеж является единицей физического хранения. Этот способ обеспечивает быстрый доступ к целому картежу, но при этом во внешней памяти дублируются общие значения разных картежей одного отношения, и вообще говоря, могут потребоваться лишние обмены с внешней памятью, если нужна часть картежей. К основным характеристикам этой организации можно отнести следующее:
Второй способ – хранение отношений по столбцам.
Менее распространенным подходом является хранение отношений по столбцам, т.е. единицей хранения является столбец с исключенными дубликатами.
При таком способе организации в среднем тратится меньше внешней памяти, и за один обмен с внешней памятью в общем случае считывается больше полезной информации. Дополнительным преимуществом является возможность использования значений столбца отношения для оптимизации выполнения соединений. Однако, для каждого картежа отношений необходимо хранить картеж той же степени, состоящий из ссылок на места расположений соответствующих значений столбцов. Таким образом, для сборки целого картежа требуется несколько больше ресурсов, чем в случае покартежного хранения.
Индекс – это системная таблица, построенная по значениям заданного столбца заданной таблицы для ускорения поиска данных и других операций, использующих поиск. В нидексы размещается перечень уникальных значений указанного столбца таблицы со ссылками на те ее строки, где встречаются эти значения. Таким образом, индекс выполняет роль, аналогичную предметному указателю книги. Обращение к индексу предшествует обращению к записи таблицы, для которой построен этот индекс, такую таблицу называют индексированной. В некоторых СУБД индексы могут храниться в отдельных файлах. Основное назначение индексов состоит в обеспечении эффективного прямого доступа к картежу отношения по ключу.
Обычно индекс выделяется для одного отношения и ключом является значение атрибута, возможно составного. Если ключом индекса является потенциальный ключ отношения, то индекс должен обладать свойством уникальности. На практике ситуация обычно выглядит противоположно. При объявлении первичного ключа отношения автоматически создается уникальный индекс. Единственным способом объявления потенциального ключа отличного от первичного, является создание уникального индекса, это связано с тем, что для проверки свойства уникальности, так или иначе, требуется индексная поддержка.
Поскольку при выполнении многих операций требуется сортировка отношений, в соответствии со значениями некоторых атрибутов. Полезным свойством индекса является обеспечение последовательного просмотра картежей отношений в диапазоне значений ключа в порядке возрастания или убывания значений. Одним из способов организации выполнения соединений отношений является организация мультииндексов для связок отношений.
Общей идеей любой организации индекса, поддерживающего прямой доступ по ключу и последовательный просмотр в порядке возрастания или убывания значений ключа, является хранение упорядоченного списка значений ключа с привязкой к каждому значению ключа списка идентификаторов картежей. Одна организация индекса отличается от другой главным образом в способе поиска ключа с заданным значением.
Одним из самых распространенных подходов к организации индексов в СУБД является использование техники В-деревьев. С точки зрения внешнего логического представления В-дерево это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к каждому его листу одна и та же. Ветвистость дерева – это свойство каждого узла дерева ссылаться на большое число узлов потомков. С точки зрения физической организации В-дерево представляется как мультисписочная структура страниц внешней памяти, т.е. каждому узлу дерева соответствует блок(страница) внешней памяти. Внутренние и листовые страницы обычно имеют разную структуру. В общем случае структура внутренней страницы выглядит следующим образом:
Ключ n
Nn
………..
N2
Ключ1
N1
При этом выдерживаются следующие свойства:
ключ 1 <= ключ 2 …. <=ключ n
Ni – является идентификатором страницы внешней памяти, в роли идентификатора в общем случае выступает адрес страницы. В странице дерева Ni находятся ключи k со значениями:
ключ(i-1)<=k<=ключ i
Листовые страницы связаны одно- или двунаправленным списком.
Поиск в В-дереве – это проходение от корня к листу в соответствии с заданным значением ключа. Т.к. деревья сильно ветвисты и сбалансированы, то для выполнения поиска по любому значению ключа потребуется одно и то же и обычно небольшое число обменов с внешней памятью. Более точно если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной lognm. Если m достаточно велико, то глубина дерева невелика и выполняется быстрый поиск.
Основной «изюминкой» В-дерева является автоматическое поддержание свойства сбалансированности. Рассмотрим, как это выполняется при занесении новой записи:
Проблемой является то, что при выполнении операции модификации слишком часто могут возникать расщепления и слияния. Чтобы добиться эффективного использования внешней памяти с минимизацией числа расщеплений и слияний, применяют более сложные приемы:
В поле ключа индексного файла можно хранить значения ключевых полей индексированной таблицы, либо свертку ключа, так называемый хэш-код, свертка получается результате применения к значению ключа некоторой функции свертки(хэш-функции), вырабатывающей значения меньшего размера и определенной всегда постоянной длины. Свертка значений ключа затем используется для доступа к записи. Хеширование является часто распространенным подходом, применяемым при организации индексов.
Преимущество хранения хеш кода состоит в том, что длина свертки независимо от длины исходного значения ключевого поля всегда имеет постоянную и достаточно малую величину, что существенно снижает время выполнения поисковых операций.
Недостатки хеширования – необходимость выполнения самой операции свертки, борьба с возникновений коллизий. Свертка различных значений может дать одинаковый хеш код.
В самом простом классическом случае свертка ключа используется как адрес в таблице, содержащий ключи и записи. Основным требованием хеш функции является равномерное распределение значений свертки. При возникновении коллизии индексируемое поле образуются цепочки переполнения.
Главным ограничением этого метода является фиксированный размер таблицы. Если таблица заполнена слишком сильно или переполнена, возникает слишком много цепочек переполнения, и главное преимущество хеширования, доступ к записи почти всегда за одно обращение к таблице, будет утрачено. Расширение таблицы требует ее полной переделки на основе новой хеш функции (со значением свертки большего размера).
В случае баз данных такие действия являются абсолютно неприемлемыми. Поэтому вводятся промежуточные таблицы справочники, содержащие значения ключей и адреса записей, а сами записи хранятся отдельно, тогда при переполнении справочника требуется только его переделка, на что суммарно требуется меньше ресурсов.
Чтобы избежать потребности в полной переделки справочника, при их организации часто используют технику В-деревьев с технологией их расщепления и слияния, хеш функция при этом меняется динамически в зависимости от глубины В-дерева. Путем дополнительных технических ухищрений удается добиться сохранения порядка записей в соответствии со значениями ключа. В целом методы В-деревьев и хеширования все более сближаются.
Рассмотрим организацию индексирования таблиц двумя схемами: одноуровневой и двухуровневой.
При одноуровневой схеме в индексном файле хранятся короткие записи, имеющие два поля: поле содержимого старшего ключа (хеш кода ключа) адресуемого блока и поле адреса начала этого блока. В каждом блоке записи располагаются в порядке возрастания значения ключа или свертки. Схема1
Старшим ключом каждого блока является ключ его последней записи. Если в индексном файле хранятся хеш коды ключевых полей индексированной таблицы, то алгоритм поиска нужной записи в таблице включает в себя 3 этапа:
Основным недостатком одноуровневой схемы является то, что ключи (свертки) записи хранятся вместе с записями, что приводит к увеличению длины поиска. Из-за большой длины просмотра. Поэтому двухуровневая схема индексации в ряде случаев оказывается более рациональной, в ней ключи (свертки) записи отделены от содержимого записи, таким образом, индекс основной таблицы распределен по совокупности файлов: одному файлу главного индекса и множеству файлов с блоками ключей.
На практике для создания индексов пользователь указывает поле некоторой таблицы базы данных, которая требует индексации. … во многих СУБД индексируется автоматически, такие индексы обычно называются первичными индексами. Индексы, создаваемые пользователем не для ключевых полей, называют вторичными пользовательскими индексами. Создание таких индексов не изменяет физического расположения записей таблицы, но влияет на последовательность просмотра записей. Связь вторичного индекса с элементами данных может быть установлена различными способами. Один из них - использование вторичного индекса для получения первичного ключа, по которому затем с использованием первичного индекса производится поиск необходимых записей.
Пользовательский индекс К (сторонний)
Пользовательский индекс I (вторичный)
Автоматический индекс (первичный)
Таблица БД
В некоторых СУБД деление индексов на первичные и вторичные не производится. В этом случае используются автоматически создаваемые индексы и индексы, определяемые пользователем по любому из неключевых полей.
Главная причина повышения скорости выполнения различных операций в индексированных таблицах состоит в том, что основная часть работы производится с небольшими индексными файлами, а не с самими таблицами. Наибольший эффект повышения производительности при, работе с индексированными таблицами, достигается для значительных по объему таблиц. Индексирование требует небольшого дополнительного места на диске и некоторого дополнительного использования ресурсов системы на изменение индексов в процессе работы. В больших таблицах более 1000 строк поиск индексированных значений выполняется на порядок быстрее, чем неиндексированных, а в очень больших таблицах 10000 и более строк, на 2-3 порядка.
Только один из индексов может быть определен как кластерный. В кластерном индексе строки таблицы сортируются и сохраняются в памяти в физически упорядоченном состоянии, т.е. логическое расположение строк соответствуют их физическому расположению в памяти. Таким образом, при создании кластерного индекса происходит переупорядочение записей таблицы на диске с тем, чтобы их порядок расположения соответствовал их порядку в кластерном индексе. Таким образом, кластерный индекс может быть только один, т.к. данные можно расположить только в одном физическом порядке. Использование кластерного индекса при его правильном определении может существенно повысить скорость поиска данных даже в сравнении с некластерными индексами.
Индекс часто определяется для столбцов, на которые содержатся ссылки в операторах выборки строк по определенным критериям.
Язык запросов SQL намеренно не включает в своих конструкциях ссылки на индексы. Решение о том, использовать или не использовать какой-либо индекс при обработке некоторого запроса принимается не пользователем, а оптимизатором СУБД, который учитывает множество факторов: размер таблиц, тип данных, статическое распределение данных в таблицах и индексах и т.д.. Однако, чтобы оптимизатор смог использовать индекс, его нужно сначала создать.
Если база данных не должна модифицироваться или подвергается незначительным модификациям, создание большого количества индексов для таблицы может положительно повлиять на быстродействие, однако, при активных операциях, связанных с модификацией базы данных, необходимо будет перестраивать индексы каждый раз в случае удаления или добавления записи в индексированной таблице, а так же при изменении значения индексированного столбца. В этом случае время потраченное на модификацию индексов может превысить время сэкономленное в результате поиска по индексированной таблице, поэтому если планируется модификация множества строк сильно индексированной таблицы, то целесообразно сначала уничтожить индексы ее столбцов, провести необходимые операции модификации данных, а затем создать индексы заново.
х единиц товара
Транзакция – это логическая единица работы с базой данных, которая должна быть или полностью выполнена или отменена.
Начальное состояние (устойчивое состояние)
х=х-10 Транзакция А (Модернизация БД)
Х-10
Конечное состояние (устойчивое состояние)
Транзакция А, которая изменяет содержимое базы данных переводит БД из одного устойчивого состояния в другое устойчивое состояние.
Устойчивым состоянием БД считается состояние, при котором выполняются все условия ограничения целостности.
После завершения транзакции, все используемые в ней данные освобождаются, чтобы к ним можно было получить доступ из других транзакций. Соответственно при выполнении транзакций, данные должны блокироваться, чтобы гарантировать, что ни одна другая транзакция не сможет получить к ним доступа.
По своей природе однопользовательская БД автоматически гарантирует изолированность и серилизуемость, поскольку в данный момент времени выполняется только одна транзакция. Свойства атомарности и долговечности должны обеспечиваться даже в однопользовательской СУБД.
Поддержка транзакции обеспечивается двумя SQL операторами:
Стандарты ANSI требуют, чтобы после инициализации транзакции пользователем или прикладной программой, она выполнялась последовательностью SQL операторов, пока не произойдет одно из следующих четырех событий:
Транзакция начинает выполняться явно, как только встретится первый SQL оператор. В некоторых версиях SQL для начала выполнения транзакции используется специальный оператор, например: BEGIN TRANSACTION.
Для отслеживания всех транзакций, выполняющихся в БД, используется журнал транзакций. Информация, которая содержится в этом журнале, может быть применена для восстановления БД в случае неожиданного прерывания выполнения программы или системного сбоя или в случае отмены транзакции с помощью оператора ROLLBACK.
В журнале транзакции хранится следующая информация:
Использование журнала транзакций увеличивает непроизводительные издержки при работе СУБД, однако возможность восстановления поврежденной СУБД стоит того.
Пример журнала транзакции:
|
TRL ID |
TRX NUM |
пред PTR |
след PTR |
Операции |
Объект БД |
Идентификатор столбца |
Атрибут «до» |
|
341 |
101 |
null |
352 |
START |
начало транзакции |
||
|
342 |
101 |
341 |
363 |
UPDATE |
TOVAR |
QUANT |
40 |
|
363 |
101 |
352 |
365 |
UPDATE |
SKLAD |
CQUANT |
960 |
|
365 |
101 |
363 |
null |
COMMIT |
конец транзакции |
Журнал транзакций сам по себе представляет БД, управляемую с помощью СУБД, как и любая БД.
Поскольку в журнале транзакций содержится весьма важная информация, то обычно СУБД поддерживают размещение журналов на нескольких дисках или других устройствах хранения данных для уменьшения риска потери информации при сбое системы.
Управление параллельным выполнением транзакций – это координирование их одновременного выполнения в многопользовательских БД. Контроль параллельного выполнения очень важен, т.к. параллельное выполнение транзакций может стать причиной проблем с целостностью и непротиворечивостью данных.
Тремя основными проблемами можно считать:
Потеря изменений возникает в случае, когда две транзакции T1 и T2 выполняются параллельно, и вторая транзакция T2 начинает выполняться, когда первая транзакция Т1 еще не завершила свою работу и получает доступ к данным, с которыми оперирует транзакция Т1.
Несвязанность данных возникает в случае, когда две транзакции Т1 и Т2 выполняются параллельно и первая транзакция Т1 отменяется после того, как вторая транзакция Т2 уже получила доступ к несвязным данным.
Неоднозначность поиска возникает, когда транзакции Т1 и Т2 выполняются параллельно и в транзакции Т1 выполняется агрегатная функция на множеством данных, в то время как другая транзакция Т2 обновляет эти данные. Проблема состоит в том, что транзакция Т1 может считывать некоторые данные перед их изменением, а другие данные после их изменения.
Планировщик транзакций устанавливает порядок, в котором выполняются операции параллельных транзакций, чтобы избежать их конфликта. Планировщик может чередовать выполнение операций различных транзакций и обеспечивать их правильную последовательность. Эта последовательность определяется специальными алгоритмами параллельного выполнения, такими как блокировки или метки времени. Если невозможно спланировать выполнение транзакции, то все транзакции будут выполняться по принципу FIFO, что может привести к увеличению времени отклика в многопользовательских СУБД. Поэтому необходимо применение специальных методов, которые позволили бы увеличить общую производительность системы, выполняя транзакции параллельно. Так например, можно было бы позволить транзакциям Т1 и Т2 оперировать одними и теми же данными в случае отсутствия конфликтов.
Рассмотрим возможные конфликты между транзакциями с помощью матрицы конфликтов:
|
Т1 |
Т2 |
|
R |
R |
|
R |
W |
|
W |
R |
|
W |
W |
R-read, W - write
На основе матрицы конфликтов можно сделать вывод, что две транзакции будут конфликтовать, если хотя бы в одной из них есть операция записи.
Рассмотрим методы устранения конфликтующих ситуаций параллельных транзакций:
Блокировка(lock) гарантирует эксклюзивное использование данных только в одной транзакции, другими транзакция Т2 не сможет получить доступа к данным, которые в настоящий момент используются транзакцией Т1. Чтобы это гарантировать транзакция Т1 должна перед своим выполнением сначала блокировать доступ данных, а после своего выполнения снять эту блокировку.
Большинство многопользовательских СУБД автоматически инициируют и выполняют процедуру блокировки. Вся информации о блокировках обрабатывается частью СУБД, которая называется менеджером блокировок и отвечает за установку и контроль блокировок в транзакциях.
Степень детализации блокировок показывает уровень объектов, на которых используется блокировка. Степени: