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

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

РО – рабочая область

МД - Внутренняя и внешняя модель данных

ПП – прикладная программа и пользователь

 

ПП1

PO 1

Внутренняя МД 1

ПП n

PO n

Внутренняя МД n

Внешняя МД

СУБД

ОС

БД

Буфер

 

Алгоритм:

На одном или нескольких ПК работают ПП. В определенный момент времени возникает потребности получить данные из общей БД. В этом случае ПП посылает запрос в определенной форме СУБД. СУБД этот запрос оптимизирует и на основе структуры внешней модели данных и соответствующей внутренней МД формирует запрос к БД в терминах и командах ОС. По этим командам требуемая информация извлекается из БД и размещается во временном хранилище «системный буфер» (данная информация может храниться некоторое время).

После поступления запроса и буфера, информация поступает в РО той или иной программы.

Представлены в единственном виде внешняя МД и несколько видов внутренней МД.

Наличие в структуре алгоритма ОС. Уменьшение объема программных средств СУБД.

 

Основные типы и структуры данных, применяемые в информационных системах.

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

1. Простые (элементарные). Используется в большинстве языков программирования.

2. Составные (структурные) тоже делятся:

a. Статические типы данных: во время исполнения программного кода они требуют выделения непрерывной области оперативной памяти (не всегда это можно найти). Они во время исполнения программного кода не могут изменять свой размер и структуру.

Массивы – набор однотипных данных. Доступ по номеру столбца, строки.

Запись похожа на одномерный массив. Ячейки – это поля. Обращение по имени поля. Все поля в ОП размещаются непосредственно друг за другом.

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

b. Динамические типы данных: не требуют непрерывной области ОП, изменяют и структуру и размер.

Наиболее известные:

Линейный список – структура, состоящая из записей различного формата, которые связаны между собой указателями или адресными ссылками. Может поддерживать несколько вариантов сортировки.

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

Таблица, в зависимости от того, как она забита, может быть динамической.

 

Методы доступа к данным.

Вопросы представления данных связаны с набором операций, с помощью которых эти данные обрабатываются. Четыре основных: выбор данных, изменение данных, добавление данных, удаление данных. В основе всех этих операций находится понятие «доступ к данным». Чтобы что-то с данными сделать, необходимо их найти.

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

 

Допустим, вся информация расположена в памяти в виде последовательного файла. Файл состоит из записей, которые расположены последовательно друг за другом. Каждая запись имеет ключ или индефикатор в начале записи. Вариант прямого перебора и упорядочивания не подходит. Решается просто: создание дополнительные внешние структуры данных – индексные файлы или индексы. Дополнительный файл с двумя полями: ключ и адрес. Информации меньше – легче перебирать. Можно использовать сортировку. Можно создавать несколько вариантов сортировки (несколько индексных файлов).

 

Есть две основные группы методов доступа к данным:

1. С помощью деревьев и графов.

2. Использование функции хеширования («разрезание»)

 

11.10.2011

Диаграмма сущность-связь

Это некоторое графическое представление модели сущность-связь, выполненное с определенными стандартами – нотациями.

Сущность – прямоугольник

Зависимая сущность – двойной прямоугольник

Каждая сущность определяется набором значений атрибутов – эллипс

Ключевые атрибуты – эллипс с подчеркиванием внутри

Связи – ромб

Кардинальность – 0 или 1

Степень – n:1, n:n, …

При построении диаграммы сущность-связь можно выделить несколько этапов:

1. Изучение предметной области

2. Индефикация основных сущностей и связей

3. Осуществляется индефикация семантических (предметных) наборов связей (о степенях связей)

4. Определение кардинальности связей

5. Задаются атрибуты для каждой сущности. При этом выполняется два действия: определяется состав атрибутов (название) и определяется домены этих атрибутов (области определения)

6. Формируется диаграмма сущность-связь

 

Определение предметной области:

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

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

Сотрудник

Отдел

Должность

Работает

№

ФИО

Название

Название

Оклад

Ставка

Сущности: Сотрудник (Табельный номер, ФИО, …), Отдел (название), Должность (название, зарплата)

Связи: Работает

Может возникнуть коллизии. Отделы могут быть пустыми, а должности?

 

После того, как разработчики договорились, создается окончательная диаграмма:

Штатная единица – соединение информации должность и конкретная единица ставки

Штатная единица

Отдел

Сотрудник

Должность

Занимает

Соответствует

№

ФИО

Название

Оклад

Наименование

Ставка

Относится

0\0

0\0

0\0

1\1\0

Диаграмма усложнилась, но нет связей многие-ко-многим, и больше не будет коллизий.

 

26.10.2011

Нотация Чена

Многозначный атрибут - наличие нескольких значений. Не может быть на конечных этапах проектирования.

Сущности

Многозначный атрибут

Первичный ключ атрибут

Внешний ключ атрибут

Атрибут

Связь

Зависимая сущность

Независимая сущность

 

 

Связи

 

Степень связи, координальность

 

Нотация Мартина

 

Сущности

Имя сущности Атр1 Атр2 Атр3 ….

 

 

1-1

Обозначение степени и типа связи

1/0

1-ко многим

 

 

Нотация Баркера

 

Использует обозначения сущностей, как в предыдущем варианте. Вместо подчеркивания у атрибутов – спецсимволы (#, @, …). Связи, как и в предыдущем случаи, одной или множественной линиями. Кардинальность по-другому: Сплошная линия – обязательная, пунктирная – необязательная.

 

Итог: вся группа разработчиков одинаково и правильно понимает всю структуру БД. Есть некоторая общность представления Предметной области, понимание семантики (то есть, как функционирует предметная области). Приступим к проектированию.

 

 

Проектирование структуры БД

В настоящее время существует два основных подхода к проектированию БД (реляционные):

1. Предметно-ориентированный подход основан на использовании реальной структуры объектов конкретной предметной области.

Положительные характеристики:

ü весьма невысокие затраты на проектирование и реализацию.

ü БД не является очень большой, достаточно компактные небольшие БД.

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

Недостаток: практически невозможно адаптировать на другие предметные области.

2. Прикладной подход или универсальный подход основан на решении определенных типовых задач, которые встречаются при работе с данными:

a. Оцениваются наиболее возможные пути доступа к данным

b. Способы выборки данных

c. Реализуются общие механизмы для представления данных на логическом уровне

d. Делается попытка реализовать все предвидимые задачи, которые может решать данная система. В нужный момент она должна представить нужные инструменты для решения

Получается универсальная система, в которой предусмотрены все типовые ситуации.

Положительные моменты:

ü Прикладной подход позволяет создавать БД, которая подходят практически для любой предметной области

Недостатки:

ü Громоздкая и требует много вычислительных средств

ü На разработку требуется достаточно большое количество средств разработчиков

 

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

Типичный пример: 1С Предприятие

Основная цель проектирования – это создание системы, которая в полной мере будет обладать свойствами целостности БД. ТО есть, сокращается избыточность или вообще исключается.

Основная цель проектирования – получение «чистого» проекта БД. Он предполагает, что каждая порция информации встречается только один раз и только в одном месте.

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

 

Реляционная модель данных

Является наиболее распространенной. Почему?

1. Представление данных в виде таблиц является наиболее удобным форматом для пользователя.

2. Существует некоторый математический аппарат, который позволяет задавать и описывать процедуры манипулирования данными.

В теории множеств существует понятие отношений:

Если заданное множество Д1, Д2,..,Дn, то отношением R является декартовым произведением исходных множеств (оно состоит из кортежей, при чем каждый элемент является элементом соответствующего множества). При этом исходные множества называются доменами. n – степень соответствующего отношения.

 

Строки таблицы – кортежи. Столбцы – атрибуты Ai. Количество атрибутом равно количеству исходных множеств. Атрибуты – подмножество Д.

 

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

С другой стороны каждый атрибут Ai можно рассматривать как проекцию на соответствующую i-ую координату.

Записывается так R1(A1, A2)

Можно дать новое определение:

Реляционная БД представляет собой набор взаимосвязанных отношений или таблиц. Обычная база данных может насчитывать несколько сотен или тысяч отношений и миллионы кортежей.

В РМД предполагается, что все отношения являются нормализованными (все атрибуты являются атомарными). Операции над отношениями осуществляются в РМД двумя способами: методы реляционного исчисления и методы реляционной алгебры.

МРИ базируются на теоретических основах исчисления предикатов. Использование РИ имеет следующее преимущество:

1. Появляется возможность манипулирования данных на уровне выходного документа.

2. РИ позволяет создавать языки манипулирования данными не процедурного типа (типа SQL).

3. Пользователю дается возможность создавать и описывать данные независимо от процедур поиска и доступа к данным.

p(x1, x2,…,xn)=0|1

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

В РИ принято связывать с каждым отношением вида R(A1, A2,…,An) некоторый предикат p(x1, x2,…,xn). При этом значение атрибутов и значение аргументов предиката имеют одну и ту же область определения. Тогда, если такая связь создана, если предикат p с конкретными значениями атрибутов (a1, a2, …, an) принимает истинное значение, то соответствующий кортеж <a1,an> входит в состав отношения R. Если значение ложь, кортеж не принадлежит исходному отношению.

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

R1={(12,1),(10,4),(8,6),(7,3)}

Соответствующий предикат p1(x1,x2). Область определения первого 12, 10,8,7. Второго 1,4,6,3.

Можно на основе существующего предиката задать новое выражение. p2(x1)=

Создаем новое отношение R2(A1)={10,8,7}

Недостаток: отсутствие процедурности, то есть пользователь никаким образом не может влиять на реализацию процедур поиска и доступа к данным.

 

МРА

Любой алгебраический процесс предполагает наличие двух составляющих: операнды и операции. В РМД операнды – таблицы или отношения, возможные операции – операция над абстрактными множествами.

1. Операция объединения отношений. Если заданы два отношения А = {1,2,=,//} В= {8,10,+,-}. Результирующее отношение С состоит из элементов или отношения А, или отношения В. С= {1,2,=,//,8,10,+,-}.

2. Операция пересечения. Результат операции – это отношение С, состоящее из кортежей, который принадлежат и А, и В. В нашем примере отношение С пустое.

3. Операция вычитания. Результат вычитания В из А – это отношение С, состоящее из кортежей принадлежащих А, но не принадлежащих В.

4. Операция декартово произведения отношений. Результат – создание отношение С, полученное соединением каждого кортежа из отношения А с каждым кортежем из отношения В. Студенты*дисциплины = студент и какие дисциплины он изучает.

5. Операция проекция. Два операнда, но первый операнд – это отношение, а второй – это список атрибутов. A = {1,2,4,=,//,+} B={a1,a3}. С = {1,4,=,+}. Скрытие данных от отдельных видов пользователей.

6. Операция ограничения. Имеет два операнда: отношение и логическое выражение, задающее какое-то условие. Результирующее отношение – только те кортежи, которые соответствуют заданному логическому выражению. На этом основан Фильтр.

7. Операция соединения позволяет создать новое отношение из исходных А и В путем соединения однопорядковых строк из каждого отношения.

 

НОРМАЛИЗАЦИЯ.

 

Любая реляционная база данных включает в себя структурнуи и семантическую информацию.

Структура БД определяется множеством таблиц(отношений) и множеством связей.

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

Если даны два атрибута А и В, то можно сказать что между атрибутами существует функциональная зависимость, если в любой момент времени каждому значению атрибута А соответствует только одно значение атрибута В. В функц. зависит от А.

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

 

Функциональная зависимость соответствует отношению 1 к 1 или 1 ко многим внутри таблицы.

 

Избыточная функциональная зависимость. Эта такая функц. зависимость, которая может быть получена на основе других зависимостей, находящихся в таблице. Схема БД - множество таблиц, связ. между собой. Корректной считается такая схема БД, в которой полностью отсутствует изб. функц. зависимость.(иначе декомпозиция таблиц - одна или неск. таблиц разбиваются на доп. отношений. новое мн-во таблиц является проекцией исходных отношений).

 

Нормализация - обратимый пошаговый процесс замены одной группы отношений другой группой отношений. При этом устраняются избыт. функц. зависимости.

 

Условия обратимости:

1. в новых таблицах не должны появляться ранее отсутствовашие кортежи.

2. на схеме(на таблицах) новой схемы должно выполняться исходное множество функциональных зависимостей.

 

Если была функц. связь, то в результате декомпозиции она превратится в связь между таблицами.

Предполагается, что существует несколько состояний исходного проекта, которые называются нормальными формами. Каждая н.ф. определяется определенными требованиями, которые должны выполняться на каждом этапе проектирования.(1, 2, 3 нф. фбк. 4...нф).

 

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

 

Нормальные формы:

1 нормальная форма. Простой атрибут - только одно значение в каждый момент времени. Составной - несколько. Отношение находится в 1 н.ф. если все его атрибуты являются простыми(атомарными).

пример: в бд содердится инфомрмация о сотрудниках предприятия. состав этой информации помимо информации о сотруднике включает информацию о детях,о всей истории работы и доходах.

сотр(фио, адрес, дети, ист. работы)

дети(имя, дата)

ист. раб.(дата приема на должность, должность, история зп)

ист. зп.(дата начисления, сумма)

В конечных отношениях все атрибуты - атомарные.

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

 

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

БД поставок товаров. Поставщики могут один и тот же товар, но существуют ограничения, что один и тот же товар поставляется всегда по одной и той же цене.

поставки(поставщик, товар, цена товара)

поставщик, товар -> цена

товар -> цена

тогда:

(поставщик, товар)

(товар, цена)

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

 

Третья нормальная форма

Для определения ТНФ вводится понятие транзитивной функциональной зависимости.

Допустим, атрибуты А, Б, С принадлежат одной и той же таблице и отношению. При этом в таблице есть отношение АкБ и БкС, обратной нет. В этом случае С транзитивно зависит от атрибута А. А, как правило, первичный ключ.

 

Пример:

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

1. каждая организация использует только одно складское помещение;

2. одно и то же складское помещение может разделяться между несколькими организациями.

Таблица Хранение_товаров (Организация, Склад, Объем склада)

Организация – первичный ключ. Недостатки или аномалии: Дублирование информации о складе и об объеме складского помещения.

Зависимости: Организация -> склад; склад->объем. Следовательно, орг->объем

Разбиваем на две таблицы: Хранение_товаров (Организация, склад) и Характеристики_склада (Склад, объем).

Недостатки исчезают.

 

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

 

Четвертая нормальная форма

Основана на многозначных зависимостях.

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

Пример:

Таблица содержит информацию о преподавателях, информацию о дисциплинах, которые преподают, и информацию об учебных пособиях, которые рекомендуются.

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

Преподаватель	Дисциплина	Методички
	математика	Уч1
	математика	Уч2
	математика	Уч1
	математика	Уч3

Недостатки: все аномалии, какие возможны

Функциональные зависимости: препод->>дисциплина, препод->>методичка

(->> множественная зависимость)

Первичный ключ – все три поля

Разбиваем на две таблицы Преподаватель-Дисциплина и Преподаватель-Учебник.

Обязательно вводить Код!

 

Отношение находится в четвертой нормальной форме, если соответствует ТНФ или НФБиК и при этом отсутствуют многозначные функциональные зависимости в количестве больше, чем единица.

В реальном проекте достаточно довести до ЧНФ, далее программная реализация. Но возникают случаи, когда все требования соблюдены, но при анализе таблиц возникают аномалии. В этом случае нужна пятая нормальная форма. Вообще это отдельная дисциплина.

Проводится анализ каждой таблицы и осуществляется дальнейшая декомпозиция. Как правило, декомпозиция осуществляется на три или более проекции – зависимость по соединению. При этом обеспечивается сохранение полезных ФЗ, полученные таблицы имеют первичный ключ и не менее одного неключевого атрибута (но последнее рекомендация).

Отношение соответствует ПНФ, если выполняются требования всех предыдущих форм и любая зависимость по соединению определяется только возможными ключами.

 

Целостность сущности

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

Может обеспечиваться СУБД и разработчиком.

Для обеспечения данного требования:

1. При добавлении записей или кортежей в таблицу проверяется уникальность первичного ключа.

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

 

Модель сервера БД

Компонент представления

Компонент доступа к ресурсам

Клиент

Сервер

Вызовы

Информация для отображения

СУБД

Компонент доступа

На локальных компьютерах размещается единственная компонента представления, она носит универсальный характер, поэтому ПС изменяются достаточно редко. В серверной части сосредоточены и прикладной компонент, и Компонент доступа. В данном случае прикладной компонент, как правило, реализуется на специальном диалекте SQL (позволяют создавать вызываемые процедуры).

В обратном направлении перемещается только информация для отображения пользователю.

Достоинства:

· На локальных компьютерах размещается только компонент представления, который редко изменяется. Прикладной компонент реализуется стандартными средствами и размещается в единственном месте, то есть на сервере. Это позволяется осуществлять эффективное администрирование БД сокращает потребление ресурс ВС в целом.

· Низкий трафик по локальной сети, вызовы процедур достаточно короткие сообщения. Информация отображения занимает тоже мало места.

Недостатки:

· Поскольку прикладной компонент реализуется на языках типа SQL, достаточно сложно отразить всю специфику задач предметной области;

· Как правило, отсутствует средства для отладки хранимых или переносимых процедур.

 

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

Пример: Microsoft Access – язык программирования хороший. В качестве компонента доступа используется Microsoft SQL Server.

Модель сервера приложений

Компонент представления

Прикладной компонент   AS

Компонент доступа

API

SQL

Данные для отображения

Данные

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

API – низко уровневые функции.

SQL – стандартные запросы.

Достоинства:

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

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

 

Эволюция серверов БД

Централизованная архитектура сервера БД

ПП Сервер

ПП Сервер

ПП Сервер

БД

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

Функции управления данными на следующем этапе выделяются в отдельное приложение. Появляется следующая стуктура:

Сервер

БД

Сервер

Сервер

ПП

ПП

ПП

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

Сервер

БД

Сервер

Сервер

ПП

ПП

ПП

Дальше все серверные части сведены в единственное приложение, которые исполняется на отдельном компьютере и каждая прикладная программа связана с сервера отдельным потоком (нитью).

БД

Сервер

ПП

ПП

ПП

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

Дальнейшее развитие – замена выделенного сервера на специальный диспетчер (виртуальный сервер).

БД

диспетчер

ПП

ПП

ПП

серв

серв

серв

серв

Диспетчер теряет право распоряжаться данными и выполняет функции распределения запросов между СП.

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

Многопользовательская многопотоковая мультисерверная архитектура.

БД

ПП

ПП

ПП

ПП

Сервер

Сервер

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

Самая современная и сама используемая.

 

Концепция активного сервера в составе современных информационных систем.

Основное требование для ИС:

1. Вся информация в их составе должна быть актуальной и обеспечение принципов целостности БД. Вся информация должна в любой момент времени соответствовать действительности.

2. БД должна отражать не только информацию структуру, но и функционал (правила и законы, по которым функционирует предметная область).

3. Постоянный контроль за состоянием информации в БД. Реакция со стороны контролирующих систем при изменениях.

4. Необходимо, чтобы при возникновении некоторой ситуации была определенная обработка этой ситуации.

5. Одной из проблем является преобразование и отслеживание типов данных.

 

Правила в составе БД

Механизм правил или триггеров позволяет тем или иным образом программировать обработку определенных ситуаций, который возникают в БД.

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

На всю таблицу: в этом случае правила программируются на определение ситуации в случае изменения информации в таблицы (добавление новой строчки, удаление и так далее).

К отдельным элементам: с помощью правил определяется реакция на изменение значения определенного реквизита таблицы.

 

Примеры: стандартная ситуация – разработка БД для производственного предприятия. В реальном производстве может возникнуть ситуация: в БД храниться кол-во элементов на складе. Если реальное количество превышает минимального запаса – то всё нормально. А если стало меньше или нуль – при изменении значения срабатывает правило – предупреждение или самостоятельный заказ.

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

 

Правила разрабатываются и программируются на том же диалекте SQL, что и переносимые процедуры.

Исторически первые появились.

 

Понятие «событие» в БД

Механизм событий в БД позволяет прикладным программам и серверу БД уведомлять другие программы о наступлении некоторого события. Данный механизм позволяет синхронизировать работы БД и прикладных программ. Механизм событий предполагает использование двух элементов: во-первых, определение (описание) возможного события – заданно, как и в ПП, так и в процедуре сервера; во-вторых, каждое событие регистрируется для определенных прикладных программ.

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

 

Механизм событий совместно с правилами и переносимыми процедурами обеспечивают главное качество БД – это целостность информации.

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

РО – рабочая область

МД - Внутренняя и внешняя модель данных

ПП – прикладная программа и пользователь