РМД была придумана и разработана Э.Кодд в 1970г. Его последователь Дейт.
В основе РМД лежит понятие теоретико-множественного отношения .
Отношение представляет собой двумерную таблицу, содержащую некоторые данные.
Сущность - это объект любой природы, данные о котором хранятся в БД.
Атрибут – это свойство характеризующее сущность.
Пусть дано D 1 ,D 2 ,…,D n –n-множеств,
Тогда отношение R-это
множество упорядоченных кортежей
Пример:
Сотрудник
Арностью отношений (степенью) является общее количество атрибутов в отношении.
Кардинальным числом (мощностью отношений) называют число всех различных кортежей в образующих отношенияR.
Отношением называется некоторое подмножество декартового произведения, включающего один или несколько доменов.
Пр: имеется множество
D 1* D 2* D 3 ={(A,B,3),(A,B,4),(A,B,5),(A,C,3),(A,C,4),(A,C,5),(2,B,3),(2,B,4),(2,B,5),(2,C,3),(2,C,4),
Схемой отношений называется конечное множество имен атрибутов отношения.
Домен – множество всех возможных значений какого-либо атрибута отношения.
Отношение может меть несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношений. Такие комбинации называют возможными ключами отношений (потенциальными ключами).
Подмножество атрибутов Р отношения R называется потенциальным ключом (возможным ключом), если выполняются следующие два условия:
в отношении R не может быть двух различных кортежей с одинаковым значениям (это называется свойством уникальности).
никакое подмножество Р не обладает свойством уникальности.
Потенциальные ключи служат единственным средством адресации на уровнях кортежей в отношении. Первичным ключом называется атрибут (или совокупность атрибутов) отношения, однозначно идентифицирующие каждый из кортежей данного отношения.
Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Это гарантируется тем фактом, что отношение – это множество, которое не содержит одинаковых кортежей.
Ключи обычно используются для следующих целей:
исключение дублирования значений ключевых атрибутов.
упорядочивание кортежей.
ускорение работы с кортежами отношений.
организация связывания таблиц.
Пусть в отношении R1 имеется неключевой атрибутA, значение которого является значением ключевого атрибутаBдругого отношенияR2, тогда говорят что атрибутAотношенияR1 являетсявнешним ключом .
Любое отношение может быть представлено в виде таблицы, но не всякая таблица является отношением. Для того чтобы произвольная таблица являлясь отношением, необходимо выполнения четырех условий:
все записи должны иметь одинаковую структуру.
каждая запись в таблице должна быть уникальна.
значение элементов одного столбца должны принадлежать одному и тому же домену.
имена столбцов должны быть уникальными.
ADD – данная операция сообщает об ошибках в следующих случаях:
Добавляемый кортеж не соответствует схеме отношения.
Некоторое значение кортежа не принадлежит соответствующему домену.
Кортеж совпадает по ключу с кортежем, уже имеющемся в отношении.
DEL – дляудаления достаточноуказать значение ключаудаленного кортежа. Ошибка возникает только в том случае, если удаляемый кортеж в отношении отсутствует.
CH – дляданной операции все ошибки добавления и удаления имеют место.
ПРОГРАММИРОВАНИЕ В СРЕДЕ DELPHI 6
Базы данных. Создание отчета с помощью Word.
Утверждено Редакционно-издательским советом
университета в качестве лабораторного практикума
Воронеж 2004
УДК 681.3
Воробьёв Э.И., Короткевич Д.Э.. Программирование в среде Delphi 6: Лабораторный практикум: Ч. 2: Базы данных. Создание отчета с помощью Word. Потоки. Воронеж: Воронеж. гос. техн. ун-т, 2004. 107 с.
Во второй части лабораторного практикума рассматриваются теоретические и практические сведения для написания программ в среде Delphi 6 на тему: «Проектирование баз данных, создание отчетов в программе Word и использование потоков при создании высокопроизводительных приложений».
Издание соответствует требованиям Государственного образовательного стандарта высшего профессионального образования по направлению 230100 «Информатика и вычислительная техника», специальности 230104 «Системы автоматизированного проектирования», дисциплине «Программирование на языках высокого уровня».
Табл. 3. Ил. 19. Библиогр.: 7 назв.
Научный редактор: д-р техн. наук, проф. Я.Е. Львович
Рецензенты: кафедра вычислительной техники Воронеж- ской лесотехнической академии (зав. кафедрой д-р техн. наук, проф. В.Е. Межов);
д-р техн. наук, проф. О.Ю.Макаров
© Воробьёв Э.И., Короткевич Д.Э., 2004
© Оформление. Воронежский государственный
технический университет, 2004
Введение
Концепция баз данных
Базы данных считаются основным преимуществом Delphi. Даже специализированные языки для работы с базами данных (такие, как MS Visual FoxPro) явно уступают по простоте и мощи программирования этого типа приложений. Delphi скрывает все сложности и в то же время даёт величайшую мощь. Ещё не было такой задачи, которую не смогли бы реализовать на Delphi за короткий промежуток времени. А главное, что всё это реализовано очень удобно и легко для понимания. В Delphi можно создавать простые приложения, даже со сложными базами, без единой строчки кода. В данном учебном пособии рассмотрены лабораторные задания для освоения приемов работы с локальными базами данных.
Теория реляционных баз данных
Ещё десять лет назад программирование баз данных было очень сложным занятием. Сейчас уже такое трудно себе представить, потому что благодаря Delphi процесс написания программ упростился, а количество разновидностей баз данных уже исчисляется десятками.
Базы данных делятся на локальные (установленные на компьютере клиента, там же где и работает программа) и удалённые (установленные на сервере, удалённом компьютере). Серверные базы данных располагаются на удалённом компьютере и работают под управлением серверного программного обеспечения. К их главным преимуществам можно отнести возможность работы с одной базой данных одновременно несколькими пользователями, и при этом осуществляется минимальная нагрузка на сеть. Есть ещё сетевые базы данных, которые создают слишком большую нагрузку на сеть и неудобны в работе как для программиста, так и для конечного пользователя. Когда программа присоединяется к сетевой базе данных, то она выкачивает с сервера практически полную его копию. Если Вы внесли изменения, то Ваша копия полностью закачивается обратно. Это очень неудобно, потому что создаётся большая нагрузка на сеть из-за излишней перекачки данных. При клиент-серверной технологии программа клиент посылает простой текстовый запрос на сервер на получение каких-либо данных. Сервер обрабатывает его и возвращает только необходимую порцию данных. Когда нужно изменить какие-то данные опять посылается запрос к серверу на их изменение, и сервер изменяет данные в своей базе. Таким образом, по сети происходит перекачка в основном только текстовых запросов, которые в основном занимают меньше килобайта. Все данные обрабатывает сервер, а значит, машина клиента загружается намного меньше и не так сильно требовательна к ресурсам. Сервер отсылает клиенту только самые необходимые данные, а значит, отсутствует излишняя перекачка копии всей базы. Благодаря всему этому сетевые базы данных уже устарели и практически не используются. Их практически полностью вытесняет технология клиент-сервер. А вот локальные базы данных будут жить всегда. Может измениться формат их хранения или добавиться какие-то новые функции, но сами базы данных будут существовать. Для дальнейшего рассмотрения нам надо определить новое понятие – таблица . Пока что говорились только общие принципы, поэтому использовалось общее понятие баз данных . Таблица базы данных – это как двухмерный массив, в котором в столбец выстроены данные (яркий пример таблицы – Excel). База данных – грубо говоря, это всего лишь файл, в котором может храниться от одной до нескольких таблиц. Большинство локальных баз данных могут хранить только одну таблицу (dBase, Paradox, XML). Но есть представители локальных баз, где в одном файле заключено несколько таблиц (например Access).
Локальные базы данных
Из локальных баз данных рассмотрим реляционные как самые распространённые. Что такое реляционная база данных? Это таблица, в которой в качестве столбцов выступают имена хранимых в ней данных, а каждая строка хранит сами данные. Таблица базы данных похожа на электронную таблицу Excel (если быть точнее, то Excel хранит свои данные в виде собственного формата, построенного на основе технологии баз данных). Локальные таблицы баз данных могут храниться на локальном жёстком диске или централизовано сохраняться на сетевой диск файлового сервера. Эти файлы можно копировать с помощью стандартных средств как любой другой файл, потому что сами таблицы базы данных не привязаны к определённому месту расположения. Главное, чтобы программа могла найти таблицу. В каждой таблице должно быть одно уникальное поле, которое однозначно будет идентифицировать строку. Это поле называется ключевым. Эти поля очень часто используются для связывания нескольких таблиц между собой. Но даже если таблица не связана, ключевое поле всё равно обязательно. В качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше если он будет типа "autoincrement" (автоматически увеличивающееся/уменьшающееся число или счётчик). Имена столбцов в таблице базе данных также должны быть уникальными, но в этом случае не обязательно числовыми. Их можно называть как угодно, лишь бы было уникально и понятно. Каждый столбец (поле базы данных) обязательно должен иметь определённый тип. Количество типов и их разновидности зависят от типа базы данных, например формат dBASE (файлы с расширением DBF) поддерживает только 6 типов, а Paradox уже до 15. База данных может храниться в одном файле (Access) или в нескольких (Paradox, dBase). Точнее сказать, данные таблицы всегда хранятся в одном файле, а вот дополнительная информация может располагаться в отдельных файлах. В качестве дополнительной информации могут быть индексы, ограничения или список значений по умолчанию для конкретных полей. Если хотя бы один из файлов запортится или будет удалён, то данные могут стать недоступными для редактирования.
Что такое индексы ? Очень часто данные из таблиц подвергаются каким-то изменениям, поэтому прежде чем произвести редактирование над какой-либо строкой, необходимо её найти. Даже статические таблицы, использующиеся в качестве справочников, тоже подвергаются операциям поиска перед выводом запрашиваемых данных. Поиск достаточно трудоёмкая операция, особенно если таблица содержит очень много строк. Индексы направлены на ускорение этой процедуры, а так же могут использоваться в качестве отправной точки при сортировке. На данном этапе достаточно знать, что не проиндексированное поле невозможно упорядочить.
Если надо, чтобы какая-то таблица была упорядочена по полю «Фамилия », то это поле надо сначала проиндексировать. Затем нужно только указать, что таблица должна работать сейчас с таким-то индексом, и она сортируется автоматически.
В хорошо спроектированной базе данных избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется. Таким образом, создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий проектирования, реализации и эксплуатации.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с базой данных, является стадия проектирования. От того, насколько тщательно продумана структура базы, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Требования к базам данных
Итак, хорошо спроектированная база данных:
1. Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
2. Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
3. Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
4. Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности
начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
1. Определить информационные потребности базы данных.
2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.
3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.
6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
7. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.
Похожая информация.
Реляционная алгебра базируется на теории множеств и является основой логики работы баз данных.
Когда я только изучал устройство баз данных и SQL, предварительное ознакомление с реляционной алгеброй очень помогло дальнейшим знаниям правильно уложиться в голове, и я постараюсь что бы эта статья произвела подобный эффект.
Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.
Для начала введем понятие реляцинной базы данных, в которой будем выполнять все действия.
Реляционной базой данных называется совокупность отношений, содержащих всю информацию, которая должна хранится в базе. В данном определении нам интересен термин отношение, но пока оставим его без строго определения.
Лучше представим себе таблицу продуктов.
Таблица PRODUCTS
| ID | NAME | COMPANY | PRICE |
| 123 | Печеньки | ООО ”Темная сторона” | 190 |
| 156 | Чай | ООО ”Темная сторона” | 60 |
| 235 | Ананасы | ОАО ”Фрукты” | 100 |
| 623 | Томаты | ООО ”Овощи” | 130 |
Таблица состоит из 4х строк, строка в таблице является кортежем в реляционной теории. Множество упорядоченных кортежей называется отношением.
Перед тем как дать определение отношения, введем еще один термин - домен. Домены применительно к таблице это столбцы.
Для ясности, теперь введем строгое определение отношения.
Пусть даны N множеств D1,D2, …. Dn (домены), отношением R над этими множествами называется множество упорядоченных N-кортежей вида
Каждый элемент кортежа представляет собой значение одного из атрибутов, соответствующего одному из доменов.
Таблица DRIVERS
Видно, что в организации может быть несколько водителей, и чтобы однозначно идентифицировать водителя необходимо и значение из столбца “Название организации” и из “Имя водителя”. Такой ключ называется составным.
В реляционной БД таблицы взаимосвязаны и соотносятся друг с другом как главные и подчиненные. Связь главной и подчиненнной таблицы осуществляется через первичный ключ (primary key) главной таблицы и внешний ключ (foreign key) подчиненной таблицы.
Внешний ключ это атрибут или набор атрибутов, который в главной таблице является первичным ключем.
Этой подготовительной теории будет достаточно для знакомства с основными операциями реляционной алгебры.
Для понимания важно запомнить, что результатом любой операции алгебры над отношениями является еще одно отношение, которое можно потом так же использовать в других операциях.
Создадим еще одну таблицу, которая нам пригодится в примерах.
Таблица SELLERS
| ID | SELLER |
| 123 | OOO “Дарт” |
| 156 | ОАО ”Ведро” |
| 235 | ЗАО “Овоще База” |
| 623 | ОАО ”Фирма” |
Для начала рассмотрим самую простую операцию - имя отношения. Её результатом будет такое же отношение, то есть выполнив операцию PRODUCTS, мы получим копию отношения PRODUCTS.
Синтаксис операции:
π
(ID, PRICE) PRODUCTS
В условии выборки мы можем использовать любое логическое выражение. Сделаем еще одну выборку с ценой больше 90 и ID товара меньше 300:
σ (PRICE>90 ^ ID<300) PRODUCTS
Получим декартово произведения таблиц PRODUCTS и SELLERS.
Синтаксис операции:
PRODUCTS × SELLERS
Можно заметить, что у двух этих таблиц есть одинаковый домен ID. В подобной ситуации домены с одинаковыми названиями получают префикс в виде названия соответствующего отношения, как показано ниже.
Для краткости перемножим не полные отношения, а выборки с условием ID<235
(цветом выделены одни и те же кортежи)
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 156 | ОАО ”Ведро” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 123 | OOO “Дарт” |
Для примера использования этой операции представим себе необходимость выбрать продавцов с ценами меньше 90. Без произведения необходимо было бы сначала получить ID продуктов из первой таблицы, потом по этим ID из второй таблицы получить нужные имена SELLER, а с использованием произведения будет такой запрос:
π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS
В результате этой операции получим отношение:
| SELLER |
| ОАО ”Ведро” |
Также для понятности можно представить соеднинение как результат двух операций. Сначала берется произведение исходных таблиц, а потом из полученного отношения мы делаем выборку с условием равенства атрибутов из одинаковых доменов. В данном случае условием явлется равенство PRODUCTS.ID и SELLERS.ID.
Попробуем соединить отношения PRODUCTS и SELLERS и получим отношение.
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLERS.ID | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | 123 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | 156 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | 235 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | 623 | ОАО ”Фирма” |
Натуральное соединение получает схожее отношение, но в случае, если у нас корректно настроена схема в базе (в данном случае первичный ключ таблицы PRODUCTS ID связан с внешним ключем таблицы SELLERS ID), то в результирующем отношении остается один домен ID.
Синтаксис операции:
PRODUCTS ⋈ SELLERS;
Получится такое отношение:
| PRODUCTS.ID | NAME | COMPANY | PRICE | SELLER |
| 123 | Печеньки | ООО ”Темная сторона” | 190 | OOO “Дарт” |
| 156 | Чай | ООО ”Темная сторона” | 60 | ОАО ”Ведро” |
| 235 | Ананасы | ОАО ”Фрукты” | 100 | ЗАО “Овоще База” |
| 623 | Томаты | ООО ”Овощи” | 130 | ОАО ”Фирма” |
Буду благодарен за аргументированные замечания
возможными ключами, поскольку любое из них можно выбрать в качестве составного ключа.Например, пусть имеется отношение
R(Город, Адрес, Почтовый_индекс).
Очевидно, что атрибуты Город Адрес Почтовый_индекс. В то же время Почтовый_индекс Город (хотя и не адрес). Оба множества могут быть возможными ключами.
Шаг 2. Переместить любую селекцию в дереве как можно ниже - законы I.4, IY.1, IY.3, IY.5.
Шаг 3. Переместить любую проекцию в низ дерева - законы I.2, IY.5, IY.6.
Шаг 4. Скомбинировать любой каскад селекций (проекций) в одиночную селекцию (проекцию) I.1, I.2, I.5 или селекцию с последующей проекцией.
Шаг 5. Разбить внутренние узлы дерева на группы: объединить двухместные операции с предшествующими или последующим узлу унарными операциями S и P.
Шаг 6. Перейти к более высокому уровню иерархии.
Пример оптимизации. Пусть дана база данных Библиотека:
ИЗД[АТЕЛИ](Название_издательства, Место, Адрес_издательства),
ЧИТ[АТЕЛИ](Фамилия, Адрес, Город, N_форм[уляра]),
ВЫД[АЧИ](N_форм[уляра], N_бк, Дата), где бк - библиотечный каталог, а для обозначения таблиц и полей используем сокращения (без букв в квадратных скобках).
Запрос: найти, у кого находятся книги, выданные до 01.01.1997.Д
Ему соответствует на языке АЛЬФА запрос (рис. 4.8, а)
p НАЗВАНИЕ s ДАТА J 1.1.1997 p S (S F (ВЫД, ЧИТ, КН)),
где F = ЧИТ.N_форм = ВЫД.N_формКН.N_бк = ВЫД.N_бк,
На рис. 4.8, а в условии F разделяют две селекции и перемещают как можно ниже в дереве. Селекция
s ДАТА≤1.1.1997 (4.2)
ниже проекции и двух селекций по законам I.1, I.5.
Селекция (4.2) применяется к произведению (ВЫД×ЧИТ)×КН. Дата - единственный атрибут отношения ВЫД потому
s ДАТА≤1.1.1997 ((ВЫД×ЧИТ)×КН)
(s ДАТА≤1.1.1997 (ВЫД×ЧИТ))×КН
((s ДАТА≤1.1.1997 (ВЫД))×ЧИТ)×КН.
Селекцию можно переместить вниз по дереву. Селекция с условием КН.N_бк = ВЫД.N_бк не может быть перемещена ниже любого декартова произведения, поскольку имеет атрибуты как отношения КН, так и других отношений.
s ЧИТ.N_ФОРМ = s ВЫД.N_ФОРМ может быть перемещена ниже и применена к произведению
s ДАТА≤1.1.1997 ((ВЫД)×ЧИТ).
ВЫД.N_форм есть имя атрибута отношения, полученного в s ДАТА≤1.1.1997 (ВЫД), ибо это атрибут отношения ВЫД.
По закону I.2 две проекции комбинируются в одну pНАЗВАНИЕ и результат отражается в рис. 4.8, б.
По закону I.4 p НАЗВАНИЕ и s кн.N_бк=выд.N_бк заменим на каскад
p НАЗВАНИЕ,
s кн.N_бк=выд.N_бк,
p название кн.N_бк, выд.N_бк. (4.3)
По закону IY.6 выражение (4.3) заменяется на p название кн.N_бк, примененное к отношению КН, и
p выд.N_бк, (4.4)
примененное к левому оператору декартова произведения более высокого уровня (рис. 4.8, б).
Последняя проекция (4.4) взаимодействует с нижней селекцией по закону I.4 и получается каскад:
p выд.N_бк,
s чит.N_форм=выд.N_форм,
p выд.N_бк, чит.N_форм, выд.N_форм. (4.5)
Проекция (4.5) «просеивается» через декартово произведение по закону IY.6 и частично - через s ДАТА≤1.1.1997
(ВЫД) по закону I.4. Кроме того, проекция p выд.N_бк, выд.N_форм, дата
- излишняя (это - все атрибуты ВЫД) и исключается. Тогда окончательный результат принимает вид рис. 4.9,
на котором группы операторов обведены пунктирными линиями. Любое из декартовых произведений является фактически эквисоединением, если его скомбинировать с селекцией, находящейся в дереве выше. Иными словами, селекция для ВЫД и проекция для ЧИТ могут быть скомбинированы в группы I и II, при этом сначала выполняются операции группы I, а затем - группы II.
Полученный результат может оказаться неоптимальным, поскольку критерий оптимизации как таковой отсутствует.
Если принять в качестве критерия минимум соединений и декартовых произведений [ c. 204], то для класса так называемых конъюнктивных запросов возможно провести однозначную оптимизацию.
Синхронизация процессов доступа
Синхронизация имеет место как при однопользовательском, так и при многопользовательском режимах.
Здесь возникают понятия «достоверность», «логический элемент работы или транзакция», «объект (запись, столбец, таблица, файл)», «управление параллелелизмом», «восстановление БД».
Первоначально поговорим об однопользовательском режиме.
Под транзакцией понимается:
1) входное сообщение, передаваемое в систему и отражающее некоторое реальное событие в компьютере (БД);
2) процесс изменения в БД, вызванный передачей одного входного сообщения.
К транзакции преддъявляются следующие основные требования:
1) она выполняется полностью или не выполняется совсем;
2) транзакция должна иметь возможность возврата, при этом независим возврат в начальное состояние до момента изменения состояния всех объектов;
3) транзакция должна быть воспроизводима: при воспроизводстве блокировку необходимо осуществлять до момента просмотра всех объектов.
Возможна двухфазная и трехфазная схема транзакции. Последняя болеe сложная и применяется в ограниченном объеме (например, в системе управления распределенной БД SDD-1) и будет рассмотрена позднее. Сейчас же поговорим о широко применяемой двухфазной схеме транзакции.
Возврат (восстановление) может быть оперативным, промежуточным, длительным. Для двух первых устанавливается предыдущее состояние (точки фиксации), для последнего - контрольные точки. Контрольные точки предназначены для процедуры восстановления БД после серьезного сбоя и устанавливаются периодически (например, с интервалом 2 - 3 с). Интервал определяется при настройке БД или компьютера.
Перейдем к многопользовательскому режиму (рис. 4.11).
Здесь задача синхронизации процессов усложняется за счет взаимодействия нескольких пользователей.
Для любой транзакции ТР возможны две группы действий:
1) изменение состояния (запись) - R;
2) считывание (чтение) состояния - W.
Для двух взаимодействующих транзакций ТР 1 и ТР 2 возможны следующие случаи.
Одновременное изменение ТР 1 и ТР 2 , при этом возможны наложение данных (потеря обновления) или ошибка в первой транзакции (взаимозависимость восстановления).
Изменение R 1 и считывание W 2 с двумя возможными последствиями:
а) изменение с помощью ТР 1 значения, считываемого ТР 2 (воспроизводимость считывания);
б) откат перед окончанием работы ТР 1 (поскольку нет изменений в ТР 2) и возврат ТР 1 в прежнее состояние.
Чтение ТР 1 и изменение ТР 2 (нет гарантии воспроизводимости).
Для устранения этих нежелательных явлений возможны такие способы управления.
Блокировка монопольная или согласованная.
Отложенные изменения.
Привязка по меткам времени работы компьютера (временная привязка) и трехфазная схема транзакции.
Второй способ используется редко. Третий способ рассмотрим при изучении распределенных баз данных, а здесь остановимся на первом способе.
Блокировка выполняется только для одной транзакции и одного объекта.
При последовательном (во времени) выполнении транзакций нарушений целостности нет, но такое выполнение требует много времени. В связи с этим используют так называемый параллельный режим (параллелизм). Вводится понятие «правильно оформленная транзакция» .
Перед обработкой объекта должна быть выполнена его блокировка.
После обработки объект должен быть разблокирован.
Перед разблокировкой не должна выполняться повторная блокировка.
Неблокированный объект не должен освобождаться.
Для параллельного выполнения
Для выхода из тупиков при монопольной блокировке возможны следующие выходы:
При использовании согласованных блокировок возможно:
1) предупреждение о блокировке для всей области;
2) блокировка части области, связанной с данной транзакцией.
Жизненный цикл информационных систем
Анализ ситуации (сложность разработки ИС, не эффективное использование ИС), проведенный учеными, показал, что такое положение было вызвано тем, что при разработке программного обеспечения не соблюдались очень важными требования:
· Отсутствие полной спецификации всех требований;
· Отсутствие приемлемой методологии (системы методов) разработки ИС;
· Отсутствие разделения общего глобального проекта на отдельные компоненты, поддающиеся эффективному контролю и управлению.
Жизненный цикл (ЖЦ) информационных систем – это структурный подход к разработке программного обеспечения.
(некая схема) за 26.09.12
1. Планирование разработки ИС. Подготовительные действия, позволяющие с максимальной эффективностью реализовывать этапы ЖЦ ИС. Три основных компонента: оценка объема работ; оценка необходимых ресурсов; оценка общей стоимости проекта.
2. Определение требований к системе. Определение диапазона действий и границ приложения базы данных, функций, состава его пользователей и областей применения.
3. Сбор и анализ требований пользователей. Сбор и анализ информации о той части организации, работа которой будет поддерживаться с помощью создаваемой ИС, определение требований пользователей к системе. Источники: опрос и анкетирование; наблюдение; изучение документов; предыдущий опыт.
4. Проектирование базы данных. Создание проекта базы данных. Два основных подхода к проектированию систем баз данных: «нисходящий » и «восходящий ».
5. Выбор целевой СУБД. Выбор СУБД подходящего типа, предназначенной для поддержки создаваемого приложения базы данных.
6. Разработка приложений. Проектирование интерфейса пользователя и прикладных программ, предназначенных для работы с базой данных.
7. Создание прототипа. Создание рабочей модели приложения баз данных.
8. Реализация. Физическая реализация базы данных и разработанных приложений.
9. Конвертирование и загрузка данных. Перенос существующих данных в новую базу данных, загрузка и модификация существующих приложений с целью организации совместной работы с новой БД.
10. Тестирование. Процесс выполнения прикладных программ с целью поиска ошибок. Стратегии тестирования: нисходящее тестирование; восходящее тестирование; тестирование потоков; интенсивное тестирование.
11. Эксплуатация и сопровождение. Наблюдение за системой и поддержка её нормального функционирования: контроль производительности; сопровождение и модернизация приложений.
Реляционная теория баз данных
Терминология
В 1970 г. Реляционная модель впервые была предложена Э.Ф. Коддом.
В реляционной СУБД предполагается, что пользователь воспринимает БД как набор таблиц (и не как иначе).
Математические отношения.
Теория реляционных БД основана на математической теории отношений.
Пусть D1, D2, … Dn некоторые множества.
Декартовым произведение D1 D2 … Dn = {(X1,X2,…,Xn) | X1 D1, X2 D2, … Xn Dn}
Отношение – подмножество R D1*D2*…*Dn
Например, n=2, D1={2,4} и D2={1,3,5}, D1 * D2 = {(2,1),(2,3),(2,5),(4,1),(4,3),(4,5)}, R={(2,1),(4,1)}
Подмножество м. б. задано условием, например:
R={(x1,x2) |x1 D1, x2 D2, X2=1}, A1, A2, … An – имена атрибутов с доменами D1, D2, … Втб тогда отношение будем записывать в виде:
R(A1:D1,A2:D2,…An:Dn)
Свойства отношений:
· Отношение имеет уникальное имя;
· Каждый атрибут имеет уникальное имя (в отношении);
· Каждая ячейка отношения содержит только атомарное значение и нет повторяющихся групп (отношение нормализовано);
D1 – студенты
D2 – дисциплины: Математика, Информатика
· Порядок следования атрибутов не имеет никакого значения;
· Порядок следования кортежей произвольный;
· Каждый кортеж является уникальным.
Реляционные ключи
Реляционные ключи служат для уникальной идентификации кортежа описания связей между отношениями.
Реляционная целостность.
Реляционная алгебра
Результат операции, может использоваться в качестве операнда для другой операции, что позволяет создавать вложенные выражения (замкнутость РА).
Реляционная алгебра является языком, в котором все кортежи обрабатываются одной командой.
Пять основных операций:
· Выборка,
· Проекция,
· Декартово произведение,
· Объединение,
· Разность.
На основе этих операций могут быть получены другие:
· Соединения,
· Пересечения,
· Деления.
В предикате могут использоваться знаки логических операций ^(And), v(Or), ~(not).
Пример. Получить список всех сотрудником с окладом свыше 300.
Проекция.
Определяет отношение, атрибутами которого являются атр1, …, атрn и содержит только уникальные кортежи.
Декартово произведение
Декартово произведение используется редко, к результату применяют выборку.
Объединение
Разность
Операции соединения.
Тета-соединение
Естественное соединение
Внешнее соединение
То при левом внешнем соединении сохраняется вся исходная информация из отношения R. Аналогично также можно определить правое внешнее соединение.
Полусоединение
Операцию полусоединения можно определить с помощью операторов проекции и соединения.
Пересечение
Представления
Назначение представлений:
· Предоставляет гибкий механизм защиты БД за счет сокрытия некоторой её части от определенных пользователей;
· Позволяет организовать доступ пользователей к данным наиболее удобным для них способом;
· Позволяет упрощать сложные операции с базовыми отношениями.
Правила, которые должны удовлетворить
реляционные СУБД
Для определения того, является ли СУБО реляционной Кодд (1985 г.) предложил 13 правил, которым они должны удовлетворять.
| № | Правило | |
| Фундаментальное правило. Реляционная СУБД должна быть способна управлять базами данных исключительно с помощь её реляционных функций | ||
| Представление информации. Вся информация в реляционной БД представляется в явном виде на логическом уровне только одним способом – в виде значений в таблицах. В том числе, метаданные. | ||
| Гарантированный доступ. Для каждого элемента данных реляционной БД должен быть гарантирован логический доступ на основе комбинации имени таблицы, значения первичного ключа и имени столбца. | ||
| Поддержка неопределенных значений. СУБД поддерживает неопределенные значения (Null). | ||
| Реляционный системный каталог. Описание БД должно представляться на логическом уровне таким образом, как и обычные данные, что позволяет пользователям использовать для обращения к ним тот же реляционный язык. | ||
| Исчерпывающий подъязык данных. реляционная СУБД может поддерживать несколько языков. Однако должен существовать по крайней мерее один язык, операторы которого позволяли бы выполнить следующие функции: 1. Определение данных; 2. Определение представлений; 3. Команды манипулирования данными; 4. Ограничения целостности; 5. Авторизации пользователей; 6. Организации транзакций | ||
| Высокоуровневые операции извлечения, вставки, удаления, обновления. Способность СУБД выполнять операции извлечения данных команд вставки, удаления и обновления как единой операции. | ||
| Физическая независимость от данных. От способа хранения | ||
| Логическая независимость от данных. Независимость приложений от изменения базовых таблиц. | ||
| Независимость ограничений целостности. Ограничения целостности должны определяться на подъязыке реляционных данных и храниться в системном каталоге, а не в прикладных программах. | ||
| Независимость от распределения данных. | ||
| Правило запрета обходных путей. Если СУБД имеет низкоуровневый язык (с последовательной построчной обработкой), он не должен позволять обходить правила и ограничения целостности, описанных на реляционном языке высокого уровня. |
Моделирование данных на основе процесса нормализации
Цель нормализации.
Процесс нормализации был предложен в 1972 году Э. Ф. Коддом – три нормальные формы (НФ): первая (1НФ), вторая (2НФ) и третья (3НФ).
Более строгое определение третьей НФ (Р. Бойс и Э. Ф. Кодд, 1974) – нормальная форма Бойса-Кодда (НФБК).
Избыточность данных и аномалии обработки.
Отсутствие нормализации приводит:
· Избыточность данных
· Аномалии вставки (невозможно добавлять записи)
· Аномалии удаления (при удалении информации теряется другая информация)
· Аномалии обновления (требуется обновление многих записей)
· Свойства сохранения без потерь и сохранения зависимости.
Функциональные зависимости
