Инфологическое проектирование бд. Основные компоненты концептуальной модели. Преимущества использования er-моделирования. Краткая характеристика er-модели.
Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.
Основными компонентами концептуальной модели являются:
• описание объектов ПО и связей между ними;
• описание информационных потребностей пользователей;
• описание существующей информационной системы (документы, документооборот, при наличии автоматизированной информационной системы - ее описание);
• описание алгоритмических зависимостей показателей;
• описание ограничений целостности;
• описание функциональной структуры системы, для которой создается АИС;
• требования к ИС и существующие ограничения;
• лингвистические отношения.
ER-модель представляет собой графическое описание предметной области в терминах «объект – свойство – связь». ER-модель является одним из элементов концептуальной модели. Использование ER-моделирования (особенно в сочетании с автоматизированными средствами проектирования - CASE-средствами) дает много преимуществ:
· предписывая определенную методологию моделирования, делает анализ предметной области более целенаправленным и конкретным;
· является удобным средством документирования проекта;
· позволяет вести проектирование АИС без привязки к конкретной целевой СУБД и осуществлять выбор последней в любой момент времени (чем ближе к концу проектирования это будет сделано, тем точнее может быть выбор).
При использовании ER-моделирования в составе CASE-средств появляются дополнительные преимущества:
· снижаются требования к знанию деталей языков описания данных (DDL - Data Definition Language) и диалектов SQL конкретных СУБД;
· при смене используемой СУБД не нужно проводить проектирование заново; следует только осуществить шаг по переводу ER-модели в целевую (если выбранная вами целевая СУБД поддерживается данным CASE-средством, то такой переход вообще будет выполнен автоматически);
· наличие в CASE-средстве возможности «обратного проектирования» (т.е. получения ER-диаграммы по имеющимся описаниям данных) позволяет использовать существовавшие ранее наработки для «реверс-инжиниринга» системы;
· указание связи объектов в ER-модели и соответствующая миграция ключа при преобразовании этой модели в целевую не только позволяют задавать контроль целостности связи при ведении БД, но и автоматически обеспечивают согласованное описание схемы (внешний ключ мигрирует в связанное отношение; при этом имя, тип и длина соответствующего атрибута повторяются в зависимой сущности);
Описание базовой ER-модели предметной области. Понятия «объект» и «класс объектов». Разновидности объектов. Изображение простого объекта. Описание свойств объекта. Разновидности свойств. Связи между объектами. Рекомендации по построению базовой ER-модели.
Описание базовой ER-модели.
Моделирование предметной области (проектирование БД) строится на различных графических схемах, поэтому существует понятие технологии построения диаграмм. ER-модель (Entity – сущность, Relationship – отношение, связь)- модель "Сущность-Связь" или "Объект-Отношение”. Наиболее известна – ERD диаграмма ER-модели, предложенная Питером Ченом в 1976г. Семантическую основу ER – модели составляют следующие предположения:
та часть реального мира, которая должна быть помещена в БД и представить собой совокупность сущностей.
Каждая сущность обладает своими характерными атрибутами (свойствами)
Сущность можно классифицировать по типам, т.е. каждая сущность может быть отнесена к определенному классу (типу). Рассматривается зависимость 1 сущности от другой.
Взаимосвязи объектов могут быть представлены различными связями.
Понятия «объект» и «класс объектов».
Объект – это некая совокупность данных и способов работы с ними, т.е. объект обладает собственными свойствами и имеет свое поведение. Все объекты, имеющие однотипное поведение составляют один класс. Класс - это описание совокупности однотипных объектов. Объект представляет собой экземпляр определенного класса и имеет те же свойства, что и сам класс. Понятие объекта – понятие множеств. Сходные между собой объекты объединяются в классы. В разные моменты времени одному и тому же классу могут соответствовать разные множества объектов. Необходимо заметить, что понятие класс имеет тесную связь с понятием сущность. Если рассматривать материальный объект(студент, товар), то в таблице он рассматривается как сущность, которая имеет свои атрибуты(поля) и кортежи.
Разновидности объектов.
1) простые (рассматриваются в исследовании как неделимые)
2) сложные (объединение других объектов ИС)
Также есть 3 разновидности сложных объектов:
1) составной (соответствует отображению отношения «целое-часть». Пример: «класс-ученики».)
2) обобщенный (отражает наличие связи «род-вид» между объектами. Пример: видовые объекты «студент», «школьник», «аспирант» образуют обобщенный родовой объект «учащийся». Видовые объекты наследуют свойства родовых объектов и обладают собственными.)
3) агрегированный (соответствует какому-либо процессу, в который оказываются вовлечены другие объекты. Пример: агрегированный объект «поставка» объединяет в себе объекты «поставщик», «потребитель», «продукция».)
Изображение простого объекта.
Базовая модель состоит из следующих компонентов:
1)сущности(объект), представленной в виде прямоугольника
2) Свойства: 1)Атрибут сущности (свойство, характеризующее объект) - овал 2) Ключевой атрибут –овал
3) связи –ромб, между сущностями, свойствами и связями используются линии:
Тип связей: 1) (:1), 2) (:М), 3) (:0 или 1), 4) (0 или более). Пример: СтудентОценкаПредмет
Описание свойств объекта. Разновидности свойств.
Свойство – это отдельная характеристика объекта или класса. Свойства. Свойство может быть множественным или единичным. Множественность свойства зависит от его состава(несколько значений или одно). Свойство может быть простым, т.е. не подлежащим делению и составным. Значения свойств могут быть статическими и динамическими. Свойство может быть неопределенным, если оно является динамическим, но его текущее состояние не задано.
Связи между объектами.
Связи между объектами могут быть 3-х типов:
Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.
Один – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.
Многие – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот. Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета.
Кроме связи между объектами и их свойствами инфологическая модель отражает связи между объектами разных классов(сущностями). Наблюдается связь между сущностью и ей самой(рекурсивная). Сущности, объединяемые связью, называются участниками. Если каждый экземпляр сущности учавствует, по крайней мере, в 1 экземпляре связи, то такое участие называется полным или обязательным. В противном случае неполным или необязательным.
В
схеме ERD в отношении 1:М не позволяется
использовать отношение (:0 или 1), а в
отношении 1:1 вполне возможна связь 
Рекомендации по построению базовой ER-модели.
1) Непротиворечивость(Всякое имя на ER - диаграмме должно быть уникальным.), неизбыточность (Всякий атрибут может быть отнесен только к одной сущности или одной связи.)
2) Следует иметь в виду, что одна и та же сущность может участвовать в нескольких связях и между двумя сущностями может быть определено несколько связей.
3) Неоднозначность выражения(Определения конструктивных элементов не отличаются особой конкретностью. Поэтому два разработчика, моделируя одну и ту же предметную область, могут получить различные ER - диаграммы.)
4) Если имеется несколько вариантов ER - диаграммы, то предпочтение рекомендуется отдавать тому, который является более гибким с точки зрения обновления и обработки данных.
Даталогическое проектирование БД. Исходные данные для даталогического проектирования. Критерии оценки БД. Особенности даталогических моделей (внутризаписная, межзаписная). Проектирование логической структуры реляционной БД. Создание физической модели с использованием CASE-средств.
Подходы к проектированию логической структуры БД существенно зависят от типа модели данных. Рассмотрим вопросы даталогического проектирования применительно к структурированным моделям данных.
В разд. 1.5 было дано понятие даталогического проектирования и определен состав работ на этой стадии (см. рис. 1.23). Рассмотрим эту схему подробнее.
Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также разрешает использование определенных правил композиции логических структур более высокого уровня из составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру базы данных. Поэтому, прежде чем приступить к построению даталогической модели, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, возможности и целесообразности их использования.
Хотя даталогическое проектирование соотносится с логической структурой базы данных, на него оказывают влияние возможности физической организации данных, предоставляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными база данных являются отображением реальной предметной области. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика отображаемой предметной области, отраженная в инфологической модели.
Все шаги проектирования даталогической модели выполняются итеративно. Причем вероятны итерации не только внутри стадии даталогического проектирования, но и с «захватом» других стадий проектирования БД.
Перечислим основные критерии, используемые при оценке БД.
1. Адекватность - соответствие базы данных реальной предметной области. Естественно, что БД не должна искажать предметную область. Это является важнейшим требованием к БД, без соблюдения которого бессмысленно соблюдение всех остальных требований. Оценка адекватности является не только очень важной, но и очень трудной задачей, поскольку некоторые несоответствия трудно выявить. Адекватность должна быть обеспечена как на уровне структуры БД, так и при задании ограничений целостности. Так, например, если в предметной области могут быть однофамильцы, а вы зададите ФИО как ключ, то запись, касающаяся однофамильца, не сможет быть введена в базу данных.
2. Полнота - возможность удовлетворения существующих и новых потребностей пользователей. Использование подхода «от предметной области» к проектированию баз данных и сама идеология банков данных как интегрированного взаимоувязанного хранилища данных способствуют обеспечению этого критерия. Хранение в БД детализированных показателей также повышает возможности удовлетворения разнообразных (в том числе и нерегламентированных) потребностей пользователей. Полнота является одним из проявлений адекватности БД.
3. Адаптируемость.
3.1. Адаптируемость к изменениям в предметной области.
3.1.1. Устойчивость схемы базы данных - отсутствие необходимости в изменении структуры БД при изменении предметной области. В теории БнД широко используется понятие независимости программ от данных и данных от программ. Не менее, а даже более значимой является проблема обеспечения независимости логической модели БД от изменений, происходящих в предметной области. Устойчивость модели является лучшим проявлением свойства адаптируемости системы. Обеспечение устойчивости модели базы данных к изменениям предметной области фактически снимает проблему независимости программ от данных, так как в этом случае структуры данных меняться не будут.
3.1.2. Простота и эффективность внесения изменений. Речь может идти как об изменении структуры базы данных в случае возникновения такой необходимости, так и об обычной корректировке значений данных в базе данных.
3.1.2.1. Простота корректировки структуры БД данных. Например, некоторые типы полей трудно преобразовать в другие. Особенно внимательными нужно быть при определении полей связей, так как их изменение повлечет за собой целую цепочку изменений.
3.1.2.2. Простота и трудоемкость корректировки значений данных. Прежде всего следует обратить внимание на аномалии, возникающие при корректировке ненормализованных структур.
3.2. Адаптация к изменениям информационных потребностей пользователей, возможность удовлетворения нерегламентированных запросов.Например, если хранить в БД детальные данные, то любые производные данные можно получить при возникновении необходимости в них; если же хранить только какие-либо сводные данные, но не хранить исходные, то получить информацию, отличную от хранимой, в большинстве случаев нельзя.
3.3. Адаптация к изменениям используемых программных и технических средств. Основным способом обеспечения этого требования является соблюдение стандартов, а также, по возможности, использование при выборе проектного решения таких средств, которые являются широко распространенными, а не специфическими для конкретной системы. Так, например, использование экзотических типов полей скорее всего приведет к проблемам при переносе системы в другую среду или при обработке информации в гетерогенной среде.
4. Универсальность. Может быть обеспечена разными способами, например реализацией возможности настройки системы на особенности предметной области, определенными приемами при проектировании структуры БД и программного обеспечения. Особое значение приобретает при создании отчуждаемых проектов, ориентированных на конечных пользователей, не являющихся специалистами по машинной обработке данных.
5. Сложность структуры БД. Речь может идти как о сложности самой поддерживаемой в данной СУБД модели данных, так и о сложности логической структуры конкретной спроектированной БД.
6. Степень дублирования данных в БД. Различают необходимое, контролируемое и неконтролируемое дублирование. Но какими бы причинами ни было вызвано дублирование данных, оно всегда ведет к необходимости поддержки идентичности всех копий дублируемых значений, росту требуемого объема памяти, повышению трудоемкости корректировки, увеличению числа полей в БД, что повышает ее сложность.
7. Сложность последующей обработки. Оценить этот показатель достаточно трудно, поскольку его значение зависит как от предполагаемой обработки, так и от возможностей языка манипулирования данными конкретной СУБД
8. Объем требуемой памяти. В связи со значительным ростом технических характеристик накопителей и снижением стоимости хранения единицы информации значимость данного фактора постоянно снижается. Исходными данными для определения требуемого объема памяти являются: число объектов отображаемой предметной области, особенности выбранной логической и физической структуры БД, особенности носителя данных. Некоторые CASE-средства включают в себя блоки оценки объемов памяти.
9. Скорость (время) обработки информации (время реакции на запрос). Значение данного критерия трудно достаточно точно оценить на стадии проектирования, поскольку на величину этого показателя влияет значительное число взаимосвязанных и взаимозависимых факторов. Если для определения требуемого объема памяти обычно используются аналитические методы, то для определения времени обработки это проблематично. Чаще всего скоростные характеристики определяются путем проведения специальным образом подобранных тестов. Однако факторы, влияющие на скорость обработки, известны, и их следует иметь в виду при проектировании структуры БД.
Особенности даталогических моделей (внутризаписная, межзаписная).
В базах данных со структурированными моделями следует различать внутризаписную и межзаписную структуры. Внутризаписная структура может быть либо линейной, либо иерархической. При линейной структуре запись состоит из простых элементов (часто называемых полями), которые следуют в записи один за другим, т. е. структура записи является нормализованной. В случае иерархической в состав записи могут входить не только простые, но и составные компоненты. Это могут быть векторы (когда повторяются однотипные элементы), повторяющиеся группы (когда в записи может присутствовать несколько экземпляров составных единиц информации, включающих в себя несколько разнотипных элементов), а также неповторяющиеся составные единицы информации внутри записи. Межзаписная структура. Традиционное деление СУБД по типу модели данных основывается на характере связей между записями. При всей разнице в терминологии можно считать, что основными компонентами любой из этих моделей являются файлы, которые состоят из записей.
Проектирование логической структуры реляционной БД.
Существуют разные способы проектирования логической структуры реляционных баз данных. Среди них есть и строгие математические методы. Для реляционной базы данных проектирование логической структуры заключается в том, чтобы разбить всю информацию по файлам (или в терминах реляционной модели — по отношениям), а также определить состав полей (в терминах реляционной теории — атрибутов) для каждого из этих файлов.
В реляционных моделях структура записи должна быть линейной. Логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так. называемые функциональные зависимости между атрибутами БД.
Создание физической модели с использованием CASE-средств
CASE – средства – средства автоматизации разработки ИС. Помогают: 1) наглядно моделировать предметную область, 2) выполнять анализ моделей и вариантов структуры БД, 3) разрабатывать приложения.
1.Нулевая функция
2.
Физическая организация данных. Технологии хранения данных в СУБД. Доступ к базе данных. Файловые структуры, используемые для хранения и организации доступа к БД: файлы с последовательным, прямым, индексным доступом, инвертированные списки, цепочки.
Физическая организация данных.
Физическая модель БД определяет способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживается на физическом уровне. Первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ). СУБД создавала над этими файловыми моделями свою надстройку, которая позволяла организовать всю совокупность файлов таким образом, чтобы она работала как единое целое и получала централизованное управление от СУБД. Однако механизмы буферизации и управления файловыми структурами не приспособлены для решения задач собственно СУБД, эти механизмы разрабатывались просто для традиционной обработки файлов, и с ростом объемов хранимых данных они стали неэффективными для использования СУБД. Технологии хранения данных в СУБД.
Механизмы среды хранения БД служат для управления двумя группами ресурсов – ресурсами хранимых данных и ресурсами пространства памяти. В большинстве случаев в качестве единицы хранения принимается хранимая запись.
Механизмы среды хранения выполняют следующие операции:
1. При запоминании нового объекта: 1)определение места размещения "физической" БД в пространстве памяти; 2)выделение необходимого ресурса памяти; 3)запоминание этого объекта; 4)формирование связей с другими объектами.
2. При поиске объекта: 1)поиск места размещения объекта в пространстве памяти по заданным атрибутам или "адресу"; 2)выборка объектов для обработки.
3. При удалении объекта: 1)удаление с освобождением памяти (физическое удаление) или без освобождения (логическое удаление); 2)разрушение связей с другими объектами.
Доступ к базе данных.
1)Последовательная обработка области БД. Областью БД может быть файл или другое множество страниц. Последовательная обработка предполагает, что система последовательно просматривает страницы, пропускает пустые участки и выдаёт записи в физической последовательности их хранения. 2)Доступ по ключу базы данных (КБД). КБД определяет местоположение записи в памяти ЭВМ. Зная его, система может извлечь нужную запись за одно обращение к памяти. 3)Доступ по структуре. Эта разновидность доступа применяется для групповых отношений и позволяет перейти к предыдущему или следующему экземпляру группового отношения, к экземпляру-владельцу группового отношения или к списку подчинённых экземпляров. 4)Доступ по первичному ключу. Первичный ключ идентифицирует записи внутри типа. Если система обеспечивает доступ по первичному ключу, то он (ключ) используется также при запоминании записи и, более того, его значение в этом случае обычно используется при размещении записи в памяти. Наиболее распространённые механизмы доступа по первичному ключу – индексирование и хеширование.
Файловые структуры, используемые для хранения информации в базах данных
В каждой СУБД по-разному организованы хранение и доступ к данным, однако существуют некоторые файловые структуры, которые имеют общепринятые способы организации и широко применяются практически во всех СУБД.
В системах баз данных файлы и файловые структуры, которые используются для хранения информации во внешней памяти, можно классифицировать следующим образом
Файл – это поименованная линейная последовательность записей, расположенных на внешних носителях, поэтому в файле всегда можно определить текущую запись, предшествующую ей и следующую за ней. случаях мы знаем значение ключа, но не знаем номера записи, который соответствует этому ключу.
Суть методов хеширования состоит в том, что мы берем значения ключа ( или некоторые его характеристики) и используем его для начала поиска, то есть мы вычисляем некоторую хэш-функцию h(k) и полученное значение берем в качестве адреса начала поиска. То есть мы не требуем полного взаимно-однозначного соответствия, но, с другой стороны, для повышения скорости мы ограничиваем время этого поиска (количество дополнительных шагов) для окончательного получения адреса. Таким образом, мы допускаем, что нескольким разным ключам может соответствовать одно значение хэш-функции (то есть один адрес). Подобные ситуации называются коллизиями. Значения ключей, которые имеют одно и то же значение хэш-функции, называются синонимами.
Поэтому при использовании хэширования как метода доступа необходимо принять два независимых решения:
выбрать хэш-функцию;
выбрать метод разрешения коллизий.
Структурированный язык запросов SQL. Общая характеристика языка. Операторы языка группы DDL: CREATE, ALTER, DROP. Примеры использования операторов. Оператор языка группы DQL SELECT. Примеры запросов.
Общая характеристика языка.
SQL(Structured Query Language) представляет собой непроцедурный язык, который используется для управления данными в СУБД. Существует 3 уровня соответствия стандарту языкаSQL.1)начальный, 2) промежуточный, 3)полный.
SQL является примером языка преобразования данных, или же языка, предназначенного для работы с таблицами с целью преобразования входных данных к требуемому выходному виду. Язык SQL, который определен стандартом ISO, имеет два основных компонента:
1)язык DDL (Data Definition Language), предназначенный для определения структур базы данных и управления доступом к данным; 2)язык DML (Data Manipulation Language), предназначенный для выборки и обновления данных. символьный литерал ' Smith , то эта запись не будет найдена.
Операторы CREATE, ALTER, DROP. Обработка различных компонентов БД (таблицы, индексы, схемы данных, представления, домены).
Это
операторы языка определения данных
DDL(Data Definition Language), который предоставляет
пользователям средства указания типа
данных и их структуры, а также средства
задания ограничений для информации,
хранимой в БД. Они позволяют создать,
удалить и модифицировать компоненты
БД(CREATE, DROP, ALTER соответственно).
Поскольку язык SQL имеет свободный
формат, отдельные операто
ры SQL и
их последовательности будут иметь более
удобный для чтения вид при использовании
отступов и выравнивания.
C
REATE DATABASE [IF NOT EXISTS] db_name – создает БД с указанным именем. Если база данных уже существует и не указан ключевой параметр IF NOT EXISTS, то возникает ошибка выполнения команды. Базы данных в MySQL реализуются как директории, содержащие файлы, которые соответствуют таблицам в базе данных.
DROP DATABASE [IF EXISTS] db_name - удаляет все таблицы в указанной базе данных и саму базу.
ALTER TABLE имя_табл – модифицировать таблицу; Оператор ALTER TABLE обеспечивает возможность изменять структуру существующей таблицы. Например, можно добавлять или удалять столбцы, создавать или уничтожать индексы или переименовывать столбцы либо саму таблицу. Можно также изменять комментарий для таблицы и ее тип
Примеры использования операторов.
1). создать таблицу STUDENT с полями: номер,фамилия, имя, группа, дата рождения, плата.
CREATE TABLE STUDENT
(Nomer INTEGER PRIMARY KEY,
Fam VARCHAR (30),
Imya VARCHAR (20),
Gruppa VARCHAR (6),
Data_rog DATE,
Plata NUMERIC(10));
2). Описать ограничения для предыдущего примера. Для полей Nomer и E-mail не должно быть повторяющихся значений.
CREATE TABLE STUDENT
(… …,
Plata NUMERIC(10,
Email VARCHAR(20),
CONSTRAINT ogranich
UNIQUE (Nomer,Email));
Модели организации доступа к БД. Классификация фактографических баз данных по способу доступа. Локальные, сетевые и распределенные базы данных. Архитектура «файл-сервер», «клиент/сервер», модели сервера баз данных. Типы параллелизма при обработке запросов. Модель сервера приложений.
Организация доступа к данным на основе инвертированных таблиц используется практически во всех современных реляционных СУБД, но в этих системах пользователи не имеют непосредственного доступа к инвертированным таблицам (индексам). Кстати, когда мы будем рассматривать внутренние интерфейсы реляционных СУБД, можно будет увидеть, что они очень близки к пользовательским интерфейсам систем, основанных на инвертированных таблицах.
По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с сетевым доступом.
В зависимости от общего назначения или принадлежности: - служебная БД - База данных, предназначенная для решения внутрисистемных функциональных задач персонала автоматизированной системы: ” пользовательская БД - База данных, предназначенная для решения задач пользователей автоматизированной системы; - персональная (личная) БД - База данных, обслуживающая одного пользователя и содержащая его личную информацию: - частная (закрытая) БД - База данных, доступная для использования только ее владельцу (пользователю): - БД общего пользования - База данных, доступная всем пользователям автоматизированной, вычислительной системы или сети;
Транзакция и целостность БД. Понятие транзакции и её краткая характеристика. Понятие целостности базы данных. Условия целостности. Модели транзакции (автоматическое и управляемое выполнение транзакций). Обработка транзакций. Модель ANSI/ISO. Откат и восстановление. Параллельное выполнение транзакций. Захваты и блокировки.
Для обеспечения целостности данных в БД используется понятие транзакции.
Транзакция – это логическая программная единица, которая обладает возможностью восстановления данных. Существует 2 исхода транзакции: удачное завершение и неудачное завершение.
В языке SQL существует 3 команды:
BEGIN TRANSACTION – описание начала транзакции.
COMMIT- удачное завершение транзакции.
ROLLBACK – неудачное завершение транзакции.
Существует 2 модели транзакции:
1). Модель автоматического выполнения транзакции
2). модель управляемого выполнения транзакции
Первый вариант транзакции автоматически начинается с выполнения пользователем или программой первой конструкции языка SQL- BEGIN TRANSACTION. Далее происходит последовательное выполнение команд до тех пор, пока транзакция не завершится одним из 2 способов. В первой модели участвуют 3 команды языка SQL.
Вторая модель транзакции в основном используется в СУБД SyBase. Она включает в себя 4 команды: BEGIN TRANSACTION, COMMIT, SAVE TRANSACTION. Последняя команда позволяет создавать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения.
Журнал транзакции. Возможность восстановления состояния БД после сбоя обеспечивается с помощью журнала транзакции. Журнализация изменений (сохранение во внешней памяти) тесно связана с управлением транзакциями. Очень важно, чтобы запись об изменении объекта БД попала во внешнюю память журнала раньше, чем измененный объект окажется в этой памяти.
Иногда для восстановления последнего актуального состояния БД после сбоя, журнала изменений бывает недостаточно. Основой восстановления являются журнал и архивная копия БД.
Восстановление начинается с обратного копирования БД из архивной копии. Затем для всех закончившихся транзакций повторно выполняются все операции. Точнее по журналу в прямом направлении, а для неудачных транзакций осуществляется откат.
Существуют общие требования к системе восстановления данных в составе СУБД:
Пользователь не должен осуществлять рестарт транзакции или повторный ввод данных. Восстановление должно происходить на базе транзакции с помощью отмены или изменения отдельных транзакций.
Быстрое восстановление данных обеспечивается генерацией данных.
При выполнении процедур автоматизированного восстановления пользователь не должен анализировать состав данных и выбирать процедуры.
Для восстановления БД существуют следующие сервисные средства:
программы ведения системного журнала
программы архивации
программы восстановления
программы отката
программы записи контрольных точек и повторного исполнения
Параллельное выполнение транзакции.
Различают четыре ситуации, когда 2 параллельные транзакции пересекаясь (во времени) вызывают ошибки следующих видов:
пропавшее обновление
чтение «грязных» данных
чтение несогласованных данных
«строки-призраки»
Пропавшее обновление. Рассмотрим пример, в котором протекают две транзакции. Допустим, 1-я транзакция меняет фамилию Петрова на фамилию Сидорова, а 2-я транзакция для «бывшей» Петровой оформляет материальную помощь. 1500р. Если 2-я транзакция завершится позже, чем 1-я (или 1-я транзакция успеет завершиться быстрее, чем 2-я сделает обновление), то совместное завершение транзакции закончится неудачно для пользователя, т.к. Петровой никогда не будет назначена мат. помощь.
Чтение «грязных» данных. В данной ситуации также прослеживается несогласованная работа двух параллельных транзакций. Допустим работают два диспетчера. Второй диспетчер(Д2) запрашивает данные о нагрузке преподавателя в то время, как первый диспетчер(Д1) вводит различные изменения в нагрузку. Изменения Д1 зафиксированы, а транзакция №2 ещё не закончилась. Запрос Д2 возвращает значение 400, и Д2 вынужден отменить свои действия, т.к. данное число является слишком большим для подобной нагрузки. Между тем Д1 вынужден вернуться к первоначальному состоянию, т.к. запрос Д2 не соответствует изменению Д1.
Чтение несогласованных данных. По прежнему, Д1 выполняет операцию по заполнению учебного плана, а Д2 делает запрос, чтобы просмотреть нагрузку преподов. Начиная работу практически одновременно с Д1, Д2 получает следующие требования: нагрузка 1-го препода составляет 350 человек, а нагрузка 2-го 370 человек. Далее Д2 принимает решение в пользу 1-го препода, но повторный запрос нагрузки возвращает значение 400, т.к Д1 успел изменить данному преподу значение 350 на 400. Возможно, что Д1 увидев, что 400 часов – это слишком много, вновь исправит максимальную нагрузку на меньшее количество часов.
«Строки-призраки». Пример: Д1 запускает транзакцию 1, которая выполняет выборку согласно условию (например, формирование списка студентов, сдавших дисциплину N с оценкой X). Для завершения транзакции 1 транзакция 2 вставляет в таблицу ВЕДОМОСТЬ новую строку, которая тоже удовлетворяет необходимому условию транзакции 1 и успешно завершается. Транзакция 1 вновь делает запрос по тому же критерию и в результате оказывается, что появляется новая строка, которая до этого не существовала.
Сериализация транзакций.
Метод сериализации транзакций – это механизм их выполнения по такому плану, когда результат совместного выполнения транзакций эквивалентен результату некоторого последовательного выполнения этих же транзакций.
Основная проблема метода состоит в обеспечении такого выполнения транзакций, при котором не слишком ограничивалась бы их параллельность.
«Захват» и «освобождение» объекта.
Для обеспечения сериализации транзакций применяются методы «захвата» и «освобождения» объектов, которые проводятся по инициативе самой транзакции. Транзакция «захватывает» объект, что приводит к его блокировке для других транзакций и «освобождает» его при завершении. При этом «захваты» объектов несколькими транзакциями на чтение совместимы.