Тема 4. Целостность данных. (1 час)
Принципы поддержки целостности данных в реляционной модели данных.
Общие понятия и виды ограничений целостности.
Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 аспекта.
Во-первых, это поддержка структурной целостности, которая трактуется как то, что реляционная СУБД должна допускать работу только с однородными структурами данных типа «реляционное отношение». При этом понятие «реляционного отношения» должно удовлетворять всем ограничениям, накладываемым на него в классической теории реляционной БД (отсутствие дубликатов кортежей, соответственно обязательное наличие первичного ключа, отсутствие понятия упорядоченности кортежей).
В дополнение к структурной целостности необходимо рассмотреть проблему неопределенных Null значений. Как уже указывалось раньше, неопределенное значение интерпретируется в реляционной модели как значение, неизвестное на данный момент времени. Это значение при появлении дополнительной информации в любой момент времени может быть заменено на некоторое конкретное значение. При сравнении неопределенных значений не действуют стандартные правила сравнения: одно неопределенное значение никогда не считается равным другому неопределенному значению. Для выявления равенства значения некоторого атрибута неопределенному применяют специальные стандартные предикаты:
<�имя атрибута>IS NULL и <�имя атрибута> IS NOT NULL.
Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL — FALSE (Ложь), в противном случае предикат IS NULL принимает значение FALSE, а предикат IS NOT NULL принимает значение TRUE.
Ведение Null значений вызвало необходимость модификации классической двузначной логики и превращения ее в трехзначную. Все логические операции, производимые с неопределенными значениями, подчиняются этой логике в соответствии с заданной таблицей истинности.
Таблица истинности для логических операций с неопределенными значениями
А
|
В
|
Not A
|
A&B
|
A V В
|
TRUE
|
TRUE
|
FALSE
|
TRUE
|
TRUE
|
TRUE
|
FALSE
|
FALSE
|
FALSE
|
TRUE
|
TRUE
|
Null
|
FALSE
|
Null
|
TRUE
|
FALSE
|
TRUE
|
TRUE
|
FALSE
|
TRUE
|
FALSE
|
FALSE
|
TRUE
|
FALSE
|
FALSE
|
FALSE
|
Null
|
TRUE
|
FALSE
|
Null
|
Null
|
TRUE
|
Null
|
Null
|
TRUE
|
Null
|
FALSE
|
Null
|
FALSE
|
Null
|
Null
|
Null
|
Null
|
Null
|
Null
|
В стандарте SQL2 появилась возможность сравнивать не только конкретные значения атрибутов с неопределенным значением, но и результаты логических выражений сравнивать с неопределенным значением, для этого введена специальная логическая константа UNKNOWN. В этом случае операция сравнения выглядит как:
Логическое выражение> IS {TRUE | FALSE | UNKNOWN}
Во-вторых, это поддержка языковой целостности, которая состоит в том, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту.
Именно поэтому доступ к информации, хранимой в базе данных, и любые изменения этой информации могут быть выполнены только с использованием операторов языка SQL.
В-третьих, это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:
кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ними.
кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ними, при этом на месте ключа родительского отношения ставится неопределенное Null значение.
Ссылочная целостность обеспечивает поддержку непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления или удаления.
Кроме указанных ограничений целостности, которые в общем виде не определяют семантику БД, вводится понятие семантической поддержки целостности.
Структурная, языковая и ссылочная целостность определяют правила работы СУБД с реляционными структурами данных. Требования поддержки этих трех видов целостности говорят о том, что каждая СУБД должна уметь это делать, а разработчики должны это учитывать при построении баз данных с использованием реляционной модели. И эти требования поддержки целостности достаточно абстрактны, они определяют допустимую форму представления и обработки информации в реляционных базах данных. Но с другой стороны, эти аспекты никак не касаются содержания базы данных. Для определения некоторых ограничений, которые связаны с содержанием базы данных, требуются другие методы. Именно эти методы и сведены в поддержку семантической целостности.
Принципы семантической поддержки целостности как раз и позволяют обеспечить автоматическое выполнение тех условий, которые перечислены ранее.
Семантическая поддержка может быть обеспечена двумя путями: декларативным и процедурным путем. Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего «бизнес-правилами» (Business Rules) или декларативными ограничениями целостности.
Выделяются следующие виды декларативных ограничений целостности:
Ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов.
Задание значения по умолчанию означает, что каждый раз при вводе новой строки в отношение, при отсутствии данных в указанном столбце этому атрибуту присваивается именно значение по умолчанию. Например, при вводе новых книг разумно в качестве значения по умолчанию для года издания задать значение текущего года. Например, для MS Access 200Х это выражение будет иметь вид:
YEAR(NOW())
Здесь NOW() — функция, возвращающая значение текущей даты, YEAR(data) — функция, возвращающая значение года указанной в качестве параметра даты.
В качестве условия на значение для года издания надо задать выражение, которое будет истинным только тогда, когда год издания будет лежать в пределах от 1960 года до текущего года. В конкретных СУБД это значение будет формироваться с использованием специальных встроенных функций СУБД.
Для MS Access 200Х это выражение будет выглядеть следующим образом:
Between 1960 AND YEAR(NOW())
В СУБД MS SQL Server значение по умолчанию записывается в качестве «бизнес-правила». В этом случае будет использоваться выражение, в котором явным образом должно быть указано имя соответствующего столбца, например:
YEAR_PUBL >= 1960 AND YEAR_PUBL <- YEAR(GETDATE())
Здесь GETDATE() — функция MS SQL Server7.0, возвращающая значение текущей даты, YEAR_PUBL — имя столбца, соответствующего году издания.
Ограничения целостности, задаваемые на уровне доменов, при поддержке доменной структуры. Эти ограничения удобны, если в базе данных присутствуют несколько столбцов разных отношений, которые принимают значения из одного и того же множества допустимых значений. Некоторые СУБД поддерживают подобную доменную структуру, то есть разрешают определять отдельно домены, задавать тип данных для каждого домена и задавать соответственно ограничения в виде бизнес-правил для доменов. А для атрибутов задается не примитивный первичный тип данных, а их принадлежность тому или другому домену. Иногда доменная структура выражена неявно и в ряде СУБД применяется специальная терминология для этого. Так, например, в MS SQL Server вместо понятия домена вводится понятие типа данных, определенных пользователем, но смысл этого типа данных фактически эквивалентен смыслу домена. В этом случае действительно удобно задать ограничение на значение прямо на уровне домена, тогда оно автоматически будет выполняться для всех атрибутов, которые принимают значения из этого домена.
Ограничения целостности, задаваемые на уровне отношения. Некоторые семантические правила невозможно преобразовать в выражения, которые будут применимы только к одному столбцу.
Ограничения целостности, задаваемые на уровне связи между отношениями: задание обязательности связи, принципов каскадного удаления и каскадного изменения данных, задание поддержки ограничений по мощности связи. Эти виды ограничений могут быть выражены заданием обязательности или необязательности значений внешних ключей во взаимосвязанных отношениях.
Декларативные ограничения целостности относятся к ограничениям, которые являются немедленно проверяемыми. Есть ограничения целостности, которые являются откладываемыми. Эти ограничения целостности поддерживаются механизмом транзакций и триггеров.
Раздел 3 Гипертекстовые и мультимедийные БД. XML-серверы
Гипертекстовые технологии
Способы организации гипертекстовых и мультимедийных баз данных
Гипертекст (нелинейный текст) - это организация текстовой информации, при которой текст представляет собой множество фрагментов с явно указанными ассоциативными связями между этими фрагментами.
Основная идея гипертекстовых технологий состоит в том, что поиск документальной информации происходит с учетом множества взаимосвязей, имеющихся между документами, а значит, более эффективно, чем при традиционных методах поиска.
Формально гипертекст можно представить в виде сети или графа, где узлами являются фрагменты текста, а дуги отображают отношения, связывающие эти фрагменты. Доступ к информации осуществляется не путем последовательного просмотра текста, как в обычных информационно-поисковых системах, а путем движения от одного фрагмента к другому.
В самом общем виде взаимодействие пользователя с гипертекстовой системой заключается в следующем. Пользователь читает на экране компьютера некоторый текст и имеет возможность выполнять ряд определенных в системе действий в зависимости от того, какие у него возникают ассоциации от чтения текста на экране.
Считают, что первым идею гипертекста, не используя самого термина "гипертекст", выдвинул в 1945 г. Венневер Буш, советник президента Рузвельта по науке. Им был предложен проект технической системы нового типа (или лучше сказать — технической среды), названный им "Metex". Основное преимущество этой системы состояло в возможности соединения и совместного просмотра отдельно существующих, но ассоциативно связанных единиц информации (статей, текстовых документов, фотографий, чертежей). Система "Metex" представлялась в виде своеобразной библиотеки с простым доступом к любому документу и возможностью переходить от любого документа к смежным, связанным с ним по смыслу. Пользователь должен был иметь возможность самостоятельно устанавливать нужные ему связи между документами, вводить собственные документы, связывать их с существующим содержимым библиотеки. Таким образом, основная идея предложенного проекта состояла в возможности фиксации смысловых связей между элементами информации и доступа к этой информации по системе связей. Принципы системы "Metex" полностью соответствуют современным представлениям о сути гипертекста.
Первая компьютерная система, реализующая идею гипертекста, была создана в 1968 г. Она носила чисто научно-исследовательский характер и обеспечивала возможность пользователям, в соответствии со своими представлениями, формулировать, наращивать систему связей между элементами информации и просматривать информацию как систему связей.
Термин "гипертекст" ввел Т. Нельсон. Он определил гипертекст как "соединение текста на естественном языке с создаваемой компьютером возможностью интерактивного создания внутри него новых ветвей или динамичной организации нелинейного текста, который уже не может быть напечатан обычным образом на обычной странице".
Т. Нельсон был разработчиком гипертекстовой системы, которая использовалась для ведения документации по проекту космического корабля "Апполон".
В 1987 г. фирма Apple выпустила первую гипертекстовую систему для персональных машин - пакет HyperCard для компьютеров Macintosh. С этого времени гипертекстовая технология приобретает массовый коммерческий характер.
Гипертекст можно рассматривать как своеобразную базу данных, которая организуется в виде открытой, свободно наращиваемой и изменяемой сети, узлы которой (линейные тексты) соединяются самим пользователем. От обычной базы данных гипертекст отличается прежде всего тем, что в нем отсутствуют априорно заданные ограничения на характер связей (как, например, в иерархических структурах).
Элементы гипертекста (текстовые фрагменты) называются узлами. Узлы, между которыми возможен переход, считаются смежными, а сама возможность перехода называется "связь". Совокупность смежных узлов образует "окрестность" данного узла.
Последовательно соединенные связями узлы образует "цепь". Расстояние между узлами, что соответствует "близости" или "неблизости" их содержания, равно минимальному количеству промежуточных узлов.
В общем случае в качестве узла могут выступать: слово; словосочетание; предложение; абзац; параграф; документ; собрание документов, относящихся к одной теме; отдельные сообщения и т. п.
Характер связей между узлами может быть различным. Переход может осуществляться между: текстом и комментарием к нему, между разными редакциями текста, между текстом и его возможными продолжениями, между текстами, отвечающими или возражающими друг другу, между текстами пересекающимися по содержанию и т. д.
Создание гипертекста состоит, прежде всего, в формировании системы переходов от узла к узлу (системы ссылок). В зависимости от типа гипертекстовой системы такая система может задаваться как разработчиками, так и пользователем в процессе работы с гипертекстом.
Движение в гипертекстовой сети, совершаемое в процессе чтения гипертекста, называется "навигацией".
Если гиперсеть имеет сложную, разветвленную структуру, возникает проблема ориентации пользователя, т. е. определения в каком месте сети в данный момент он находится. Проблема ориентации присутствует и при работе с традиционным линейным текстом большого объема, но в этом случае пользователь имеет только два направления поиска - "выше" или "ниже". Гипертекст предлагает больше возможностей в выборе направлений движения, поэтому в этом смысле работать с гипертекстом сложнее. Многие гипертекстовые системы облегчают проблему ориентации в гипертексте, предоставляя наглядное изображение структуры связей.
В некоторых современных гипертекстовых системах существует возможность запоминания направлений поиска пользователя в процессе навигации. Такую информацию можно рассматривать как альтернативу обработки информации по правилам логического вывода (экспертные системы). Примером использования такого подхода могут служить системы, базирующиеся на технологии CBR (Case Based Reasoning — вывод, основанный на прецедентах).
Гипертекстовая технология реализуется в конкретной гипертекстовой системе, которая состоит из двух частей: гипертекста (базы данных) и гипертекстовой оболочки.
Гипертекстовая оболочка осуществляет следующие основные функции:
поддержка ссылочных связей;
создание, редактирование и наращивание гипертекста;
прямой доступ;
просмотр (browsing — браузинг);
выделение виртуальных структур.
Поддержка ссылочных связей позволяет поддерживать ранее зафиксированные связи между узлами сети.
Функция создания, редактирования и наращивания гипертекста принципиально отличает технологию гипертекста от технологии баз данных, в которых концептуальная схема данных заранее задана. Она позволяет вводить новые узлы, редактировать содержание узлов, устанавливать связи между узлами.
Прямой доступ позволяет осуществлять прямой доступ к узлам сети по их именам.
Просмотр (браузинг) - операция, характерная только для гипертекста. Означает поиск информации посредством просмотра гипертекстовой сети, при этом возможно запоминание пути следования, с тем, чтобы при последующем аналогичном запросе поиск происходил по зафиксированному пути следования.
Реальные гипертекстовые системы в зависимости от специализации могут обладать различным набором вышеперечисленных функций.
Гипертекстовые технологии широко используются в различных прикладных системах:
в настольных издательских системах - для создания документов большого объема со свойствами гипертекста (т. е. с системой ссылок);
в системах управления документами (СУД) - например, для сведения в один итоговый документ информации, содержащейся в разнородных документах;
в системах подготовки электронных документов, позволяющих составлять гипертекстовые документы с возможностью осуществления навигации.
Наиболее известным инструментом создания гипертекста остается система HyperCard, входящая в набор базовых программных средств для машины Макинтош.
Одним из перспективных направлений развития гипертекстовых систем является технология гипермедиа - соединение технологии гипертекста и технологии мультимедиа (интеграция текста, графики, звука, видео). Для разработки гипермедийных приложений фирма Apple разработала среду программирования АМТ (Apple Media Tool), в которой основным объектом разработки является не "карта", как в HyperCard, а "экран". С помощью этих средств создаются различные электронные издания - справочники, энциклопедии; разрабатываются обучающие программы.
Гипертекстовые технологии нашли широкое применение и при организации хранения и представления информации в сети Интернет, например в сервисе World Wide-Web (WWW).
Сервис Web построен на основе архитектуры "клиент-сервер". В состав Web-системы входят следующие составляющие:
язык гипертекстовой разметки документов HTML (Hyper Text Markup Language),
универсальный способ адресации ресурсов в сети URL (Universal Resource Locator);
протокол обмена данными (гипертекстовой информацией) HTTP (Hyper Text Transfer Protocol),
средства просмотра Web-страниц (браузеры).
Язык HTML - это средство для формирования гипертекстовых документов. Гипертекстовые ссылки встроены в текст документа и хранятся как его часть. Благодаря этому языку можно не только формировать гипертекстовые документы, но и осуществлять связь текста и изображения с документами, расположенными на другом сервере Web.
Универсальный способ адресации применяется для организации гипертекстовых ссылок и обеспечивает доступ к распределенным ресурсам сети. Адрес URL состоит из трех элементов: используемого протокола доступа, логического имени сервера, имени файла. Например, сервер Государственной публичной научно-технической библиотеки России имеет адрес: http://gpntb.ippi.ras.ru/ Протокол обмена данными служит для установления связи с документами формата HTML независимо от его местонахождения.
В настоящее время гипертекстовые технологии развиваются в нескольких направлениях.
Одно из них концентрируется на представлении в узлах гипертекста разнородной, но семантически связанной информации — текста, рисунков, графики, фотографий, видео, звука.
Важным направлением развития гипертекстовых технологий является аналитическая обработка информации. Например, смысловое упорядочивание документов, обеспечивающих решение многоэтапной задачи или разработку сложных проектов.
Интернет представляет собой огромное хранилище распределенной документальной информации, различных форматов и видов:
Web-страницы,
онлайновые электронные библиотеки,
виртуальные музеи,
каталоги по продуктам и услугам,
открытая правительственная информация,
научно-исследовательские публикации,
документы различных сервисов Интернет: Gopher, FTP, Usenet и электронной почты,
коммерческая и финансовая информация.
Раздел 4 Распределенные базы данных (2 часа)
Распределенная обработка данных
Модели построения распределенных систем. Достоинства и недостатки.
При размещении БД на персональном компьютере, который не находится в сети, БД всегда используется в монопольном режиме. Даже если БД используют несколько пользователей, они могут работать с ней только последовательно, и поэтому вопросов о поддержании корректной модификации БД в этом случае здесь не стоит, они решаются организационными мерами - то есть определением требуемой последовательности работы конкретных пользователей с соответствующей БД. Однако даже в некоторых настольных БД требуется учитывать последовательность изменения данных при обработке, чтобы получить корректный результат: так, например, при запуске программы балансного бухгалтерского отчета все бухгалтерские проводки - финансовые операции должны быть решены заранее до запуска конечного приложения.
Однако работа на изолированном компьютере с небольшой базой данных в настоящий момент становится уже нехарактерной для большинства приложений. БД отражает информационную модель реальной предметной области, она растет по объему и резко увеличивается количество задач, решаемых с ее использованием, и в соответствии с этим увеличивается количество приложений, работающих с единой базой данных. Компьютеры объединяются в локальные сети, и необходимость распределения приложений, работающих с единой базой данных по сети, является несомненной.
Параллельный доступ к одной БД нескольких пользователей, в том случае если БД расположена на одной машине, соответствует режиму распределенного доступа к централизованной БД. (Такие системы называются системами распределенной обработки данных.)
Если же БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен параллельный доступ нескольких пользователей, то мы имеем дело с параллельным доступом к распределенной БД. Подобные системы называются системами распределенных баз данных. В общем случае режимы использования БД можно представить в следующем виде (см. рис. 7).
Рисунок 7 - Режимы работы с базой данных
Определим терминологию, которая нам потребуется для дальнейшей работы. Часть терминов нам уже известна, но повторим здесь их дополнительно.
Системы распределенной обработки данных в основном связаны с первым поколением БД, которые строились на мультипрограммных операционных системах и использовали централизованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный многопользовательский режим доступа к ней. При этом пользовательские терминалы не имели собственных ресурсов - то есть процессоров и памяти, которые могли бы использоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R, разработанная фирмой IBM, именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных, которые до сих пор являются базисными практически во всех коммерческих СУБД.
Общая тенденция движения от отдельных mainframe-систем к открытым распределенным системам, объединяющим компьютеры среднего класса, получила название DownSizing. Этот процесс оказал огромное влияние на развитие архитектур СУБД и поставил перед их разработчиками ряд сложных задач. Главная проблема состояла в технологической сложности перехода от централизованного управления данными на одном компьютере и СУБД, использовавшей собственные модели, форматы представления данных и языки доступа к данным и т. д., к распределенной обработке данных в неоднородной вычислительной среде, состоящей из соединенных в глобальную сеть компьютеров различных моделей и производителей.
В то же время происходил встречный процесс - UpSizing. Бурное развитие персональных компьютеров, появление локальных сетей также оказали серьезное влияние на эволюцию СУБД. Высокие темпы роста производительности и функциональных возможностей PC привлекли внимание разработчиков профессиональных СУБД, что привело к их активному распространению на платформе настольных систем.
Сегодня возобладала тенденция создания информационных систем на такой платформе, которая точно соответствовала бы ее масштабам и задачам. Она получила название RightSizing (помещение ровно в тот размер, который необходим).
Однако и в настоящее время большие ЭВМ сохраняются и сосуществуют с современными открытыми системами. Причина этого проста - в свое время в аппаратное и программное обеспечение больших ЭВМ были вложены огромные средства: в результате многие продолжают их использовать, несмотря на морально устаревшую архитектуру. В то же время перенос данных и программ с больших ЭВМ на компьютеры нового поколения сам по себе представляет сложную техническую проблему и требует значительных затрат.
Модели «клиент-сервер» в технологии баз данных.
Вычислительная модель «клиент-сервер» исходно связана с парадигмой открытых систем, которая появилась в 90-х годах и быстро эволюционировала. Сам термин «клиент-сервер» исходно применялся к архитектуре программного обеспечения, которое описывало распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели назывался «клиентом», а другой - «сервером». Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов.
Ранее приложение (пользовательская программа) не разделялась на части, оно выполнялось некоторым монолитным блоком. Но возникла идея более рационального использования ресурсов сети. Действительно, при монолитном исполнении используются ресурсы только одного компьютера, а остальные компьютеры в сети рассматриваются как терминалы. Но теперь, в отличие от эпохи main-фреймов, все компьютеры в сети обладают собственными ресурсами, и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы.
И как в промышленности, здесь возникает древняя как мир идея распределения обязанностей, разделения труда. Конвейеры Форда сделали в свое время прорыв в автомобильной промышленности, показав наивысшую производительность труда именно из-за того, что весь процесс сборки был разбит на мелкие и максимально простые операции и каждый рабочий специализировался на выполнении только одной операции, но эту операцию он выполнял максимально быстро и качественно.
Основной принцип технологии «клиент-сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу:
функции ввода и отображения данных (Presentation Logic);
прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
функции обработки данных внутри приложения (Database Logic),
функции управления информационными ресурсами (Database Manager System);
служебные функции, играющие роль связок между функциями первых четырех групп.
Структура типового приложения, работающего с базой данных приведена на рис. 8.
Рисунок 8 - Структура типового интерактивного приложения, работающего с базой данных
Презентационная логика (Presentation Logic) как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения, к этой же части относится все то, что выводится пользователю на экран как результаты решения некоторых промежуточных задач либо как справочная информация. Поэтому основными задачами презентационной логики являются:
формирование экранных изображений;
чтение и запись в экранные формы информации;
управление экраном;
обработка движений мыши и нажатие клавиш клавиатуры.
Некоторые возможности для организации презентационной логики приложений предоставляет знако-ориентированный пользовательский интерфейс, задаваемый моделями CICS (Customer Control Information System ) и IMS/DC фирмы IBM и моделью TSO (Time Sharing Option) для централизованной main-фреймовой архитектуры. Модель GUI - графического пользовательского интерфейса, поддерживается в операционных средах Microsoft's Windows, Windows NT, в OS/2 Presentation Manager, X-Windows и OSF/Motif.
Бизнес-логика, или логика собственно приложений (Business processing Logic), - это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Cobol, SmallTalk, Visual-Basic.
Логика обработки данных (Data manipulation Logic) - это часть кода приложения, которая связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используются язык запросов и средства манипулирования данными стандартного языка SQL
Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения.
Процессор управления данными (Database Manager System Processing) - это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.
В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.
В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределения можно выделить следующие модели распределений (см. рис. 9):
распределенная презентация (Distribution presentation, DP);
удаленная презентация (Remote Presentation, RP);
распределенная бизнес-логика (Remote business logic, RBL);
распределенное управление данными (Distributed data management, DDM);
удаленное управление данными (Remote data management, RDA).
Рисунок 9 - Распределение функций приложения в моделях «клиент—сервер»
Эта условная классификация показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Действительно, считается, что она не может быть удалена сама по себе полностью. Считается, что она может быть распределена между разными процессами, которые в общем-то могут выполняться на разных платформах, но должны корректно кооперироваться (взаимодействовать) друг с другом.
Двухуровневые модели
Двухуровневая модель фактически является результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели.
Модель удаленного управления данными. Модель файлового сервера.
Модель удаленного управления данными также называется моделью файлового сервера (File Server, FS). В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиенте.
Распределение функций в этой модели представлено на рис. 10.
В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база мета-данных, находится на клиенте.
Рисунок 10 - Модель файлового сервера
Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте.
Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации и т. д.
Перекачка информации с сервера на клиент производится до тех пор, пока не будет получен ответ на запрос клиента.
Недостатки:
высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;
узкий спектр операций манипулирования с данными, который определяется только файловыми командами;
отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).
Модель удаленного доступа к данным
В модели удаленного доступа (Remote Data Access, RDA) база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 11.
Рисунок 11 - Модель удаленного доступа (RDA)
Преимущества данной модели:
перенос компонента представления и прикладного компонента на клиентский компьютер существенно разгрузил сервер БД, сводя к минимуму общее число процессов в операционной системе;
сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций. (Это становится возможным, если отказаться от терминалов, не располагающих ресурсами, и заменить их компьютерами, выполняющими роль клиентских станций, которые обладают собственными локальными вычислительными ресурсами);
резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на SQL, и их объем существенно меньше. В ответ на запросы клиент получает только данные, релевантные запросу, а не блоки файлов, как в FS-модели.
Основное достоинство RDA-модели - унификация интерфейса «клиент-сервер», стандартом при общении приложения-клиента и сервера становится язык SQL.
Недостатки:
все-таки запросы на языке SQL при интенсивной работе клиентских приложений могут существенно загрузить сеть;
так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения. Это вызывает излишнее дублирование кода приложений;
сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте. Действительно, например, если нам необходимо выполнять контроль страховых запасов товаров на складе, то каждое приложение, которое связано с изменением состояния склада, после выполнения операций модификации данных, имитирующих продажу или удаление товара со склада, должно выполнять проверку на объем остатка, и в случае, если он меньше страхового запаса, формировать соответствующую заявку на поставку требуемого товара. Это усложняет клиентское приложение, с одной стороны, а с другой — может вызвать необоснованный заказ дополнительных товаров несколькими приложениями.
Модель сервера баз данных
Для того чтобы избавиться от недостатков модели удаленного доступа, должны быть соблюдены следующие условия:
Необходимо, чтобы БД в каждый момент отражала текущее состояние предметной области, которое определяется не только собственно данными, но и связями между объектами данных. То есть данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми.
БД должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules). Например, завод может нормально работать только в том случае, если на складе имеется некоторый достаточный запас (страховой запас) деталей определенной номенклатуры, деталь может быть запущена в производство только в том случае, если на складе имеется в наличии достаточно материала для ее изготовления, и т. д.
Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них: например, при достижении некоторым измеряемым параметром критического значения должно произойти отключение определенной аппаратуры, при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара.
Необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход выполнения прикладной задачи.
Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно-допустимые типы данных, то есть такие, которые определены в DDL (data definition language) - языке описания данных, который является частью SQL. Однако в реальных предметных областях у нас действуют данные, которые несут в себе еще и семантическую составляющую, например, это координаты объектов или единицы различных метрик, например рабочая неделя в отличие от реальной имеет сразу после пятницы понедельник.
Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры. Модель сервера баз данных представлена на рис. 12.
Рисунок 12 - Модель активного сервера БД
В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте. Трафик обмена информацией между клиентом и сервером резко уменьшается.
Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.
Термин «триггер» взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры.
Механизм использования триггеров предполагает, что при срабатывании одного триггера могут возникнуть события, которые вызовут срабатывание других триггеров. Этот мощный инструмент требует тонкого и согласованного применения, чтобы не получился бесконечный цикл срабатывания триггеров.
В данной модели сервер является активным, потому что не только клиент, но и сам сервер, используя механизм триггеров, может быть инициатором обработки данных в БД.
И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что. существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях.
Для написания хранимых процедур и триггеров используется расширение стандартного языка SQL, так называемый встроенный SQL. Встроенный SQL мы рассмотрим в главе 12.
Недостатком данной модели является очень большая загрузка сервера. Действительно, сервер обслуживает множество клиентов и выполняет следующие функции:
осуществляет мониторинг событий, связанных с описанными триггерами;
обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;
обеспечивает исполнение внутренней программы каждого триггера;
запускает хранимые процедуры по запросам пользователей;
запускает хранимые процедуры из триггеров;
возвращает требуемые данные клиенту;
обеспечивает все функции СУБД: доступ к данным, контроль и поддержку целостности данных в БД, контроль доступа, обеспечение корректной параллельной работы всех пользователей с единой БД.
Если мы переложили на сервер большую часть бизнес-логики приложений, то требования к клиентам в этой модели резко уменьшаются. Иногда такую модель называют моделью с «тонким клиентом», в отличие от предыдущих моделей, где на клиента возлагались гораздо более серьезные задачи. Эти модели называются моделями с «толстым клиентом».
Для разгрузки сервера была предложена трехуровневая модель.
Модель сервера приложений
Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 13. Этот промежуточный уровень содержит один или несколько серверов приложений.
Рисунок 13 - Модель сервера приложений
В этой модели компоненты приложения делятся между тремя исполнителями:
Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД, расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front-end части приложения, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером может включать в себя управление распределенными транзакциями, что соответствует тем случаям, когда клиент также является клиентом менеджера распределенных транзакций.
Серверы приложений составляют новый промежуточный уровень архитектуры. Они спроектированы как исполнения общих не загружаемых функций для клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях.
Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).
Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing.) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как С, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость.
Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки ХА-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД.
Раздел 5 Технология оперативной обработки транзакции (ОLТР–технология). Информационные хранилища. ОLАР-технология. (4 часа)
|
