Прочие виды систем - автоматизация юридических библиотек и ВУЗов, консультационных пунктов, юридические экспертные системы и пр.

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

• в информационных языках для поиска в БД по законодательству необходим учет контекстных связей, возможность использования в запросе предлогов и частиц (И, ИЛИ, НЕ), регламентированных прилагательных (типа «обязательный», «произвольный» и пр.), что отличает их от обычных документальных ИПС;

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

В наше время практически все экономически развитые страны имеют АИСЗ. В США это "WRU", "LEXIS", "WESTLAW", "JURIS", "FLITE"; в Великобритании - "INFOLEX", "PRESTEL", "POLIS", "ENLEX"; в Бельгии - "Credos"; в Германии - Система Бундестага, "JURIS", "LEXinform", "NOMOS DATA POOL"; в Австрии - "RDB"; в Канаде - "DATUM"; в Финляндии - "Finlex"; во Франции - "IRETIV", "JURIDIAL", "JURISDATA", "SINDONI". В большинстве случаев эти системы носят негосударственный характер.

В 1992 г. образовалась НЛП "Гарант-Сервис". В этом же году была создана общероссийская сеть "КонсультантПлюс", которая охватила почти 200 городов России.

Функционирование информационной сети "КонсультантПлюс" в масштабах страны во многом определяет ее лидерство на рынке СПС.

Система "Гарант" занимает второе место в России по количеству пользователей.

На третьем месте находится достаточно популярный продукт — информационно-поисковая система (ИПС) "Кодекс", которая разработана малым государственным предприятием "Центр компьютерных разработок" (МГП "ЦКР") при мэрии Санкт-Петербурга в 1991 г.

На российском рынке АИСЗ представлены также следующие продукты, созданные государственными предприятиями для обеспечения потребностей в правовой информации государственных ведомств:

• «Эталон» (НЦПИ при Министерстве юстиции РФ);

• «Система» (НТЦ «Система» при ФАПСИ).

Кроме того, на российском рынке представлены такие системы, как:

• «ЮСИС» (фирма «Инталекс»);

• «Референт» (ЗАО «Референт-Сервис»);

• «Юридический мир» (издательство «Дело и право»);

• «Ваше право» и «Юрисконсульт» (фирма «Информационные системы и технологии»);

• «1C: Кодекс», «1C: Гарант», «1C: Эталон» (компания «1C»);

• «Законодательство России» (Ассоциация развития банковских технологий) и некоторые другие.

14. Администрирование базы данных.

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

Администрирование БД возлагается на администратора (или персонал администрирования, если система БД велика). В задачи администратора входит выполнение нескольких групп функций:

1. Администрирование предметной области: поддержка представления БД на концептуальном уровне архитектуры СУБД (общем для всех приложений); адекватное отображение в БД изменений, происходящих в ПО. Последнее требование может подразумевать реструктуризацию (изменение схемы) БД и последующее приведение содержимого БД в соответствие с новой схемой.

2. Администрирование БД: поддержка представления БД в среде хранения, эффективная и надежная эксплуатация системы БД. Если на этом уровне проводится реорганизация БД (с целью повышения эффективности работы), то она заключается в следующем:

• изменения в структуре хранимых данных, например, выведение в отдельную таблицу редко используемых данных;

• изменения способов размещения данных в пространстве памяти, например:

  • разбиение таблицы на части для распределения её по различным физическим носителям с целью распараллеливания доступа к ней;

  • построение кластеров;

  • изменение физических параметров среды хранения, например, размера блока.

• изменения используемых методов доступа к данным, например, построение индексов или введение хеширования.

3. Администрирование приложений: поддержка представлений БД для различных групп пользователей механизмами внешнего уровня СУБД. При изменении концептуальной схемы БД или схемы хранения может потребоваться внесение соответствующих изменений в приложения.

4. Администрирование безопасности данных: предоставление пользователям прав на доступ к БД и настройка системных средств защиты от несанкционированного доступа. Требования безопасности, надежности, конфиденциальности, целостности:

• данные должны быть защищены от искажения, хищения, разрушения;

• данные должны быть восстанавливаемыми;

• данные должны быть контролируемыми;

• должна быть установлена процедура идентификации пользователей;

• должна быть организована система санкционированного доступа;

• должен быть установлен контроль за действиями пользователя с целью обнаружения ошибочных операций;

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

• разработка стандартов и графика резервного копирования

• разработка процедур восстановления для каждой базы данных

• проверка соответствия графика резервного копирования требованиям к восстановлению данных.

В состав СУБД обычно включаются вспомогательные средства (различные утилиты), упрощающие администрирование БД.

15. Реляционная модель данных. Понятие первой нормальной формы.

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

Говорят, что отношение находится в 1НФ, если его атрибуты содержат только скалярные (атомарные) значения.

Если таблица содержит составные атрибуты, то привести ее к 1NF можно, используя алгоритм нормализации, предложенный Э. Коддом:

1. начиная с исходной таблицы, берется ее первичный ключ и добавляется в каждую подчиненную таблицу (составной атрибут);

2. первичный ключ каждой расширенной таблицы состоит из первичного ключа подчиненной таблицы и добавленного родительского первичного ключа;

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

4. условие окончания алгоритма - атомарность всех атрибутов.

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

2. Сотрудники организации выполняют проекты.

3. Проекты состоят из нескольких заданий.

4. Каждый сотрудник может участвовать в одном или нескольких проектах, или временно не участвовать ни в каких проектах.

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

6. Над каждым заданием в проекте работает ровно один сотрудник.

7. Каждый сотрудник числится в одном отделе.

8. Каждый сотрудник имеет телефон, находящийся в отделе сотрудника.

В ходе дополнительного уточнения того, какие данные необходимо учитывать, выяснилось следующее:

1. Для каждого сотрудника необходимо хранить табельный номер. Табельный номер является уникальным для каждого сотрудника.

2. Каждый отдел имеет уникальный номер.

3. Каждый проект имеет номер. Номер проекта является уникальным.

4. Каждое задание из проекта имеет номер, уникальный в пределах проекта.

16. Реляционная модель данных. Понятие второй нормальной формы.

Определение. Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)

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

Представим схему отношения (вся информация в одной таблице):

СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ

(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первичный ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР -> СОТР_ЗАРП

СОТР_НОМЕР -> ОТД_НОМЕР

ОТД_НОМЕР -> СОТР_ЗАРП

СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН

Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.

Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)

Первичный ключ:

СОТР_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР -> СОТР_ЗАРП

СОТР_НОМЕР -> ОТД_НОМЕР

ОТД_НОМЕР -> СОТР_ЗАРП

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первичный ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН

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

Алгоритм приведения сущности ко второй нормальной форме.

1 выделить атрибуты, которые зависят от части первичного ключа;

2 создать новую сущность;

3 поместить атрибуты, зависящие от части первичного ключа в их собственную новую сущность;

4 установить связь от прежней сущности к новой. Часть первичного ключа прежней сущности мигрирует в новую сущность и станет ее первичным ключем.

2НФ позволяет избежать следующих аномалий при выполнении операций:

- Обновления. Имеет место дублирование данных о сотруднике, если он участвует в нескольких проектах.

- Вставки. Невозможно ввести данные о сотруднике, если он не участвует в проекте.

- Удаления. Если сотрудник прекращает работать над проектом, данные о нем теряются.

17. Реляционная модель данных. Понятие третьей нормальной формы.

Определение . Третья нормальная форма (определение дается в предположении существования единственного ключа.)

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.

Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР -> СОТР_ЗАРП является транзитивной; она является следствием функциональных зависимостей СОТР_НОМЕР -> ОТД_НОМЕР и ОТД_НОМЕР -> СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).

В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.

Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)

Первичный ключ:

СОТР_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР -> ОТД_НОМЕР

ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)

Первичный ключ:

ОТД_НОМЕР

Функциональные зависимости:

ОТД_НОМЕР -> СОТР_ЗАРП

Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.

Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:

Определение *

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF, и каждый не ключевой атрибут не является транзитивно зависимым от какого-либо ключа R.

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

Алгоритм приведения отношения к третьей нормальной форме

1 создать новое отношение и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

2 использовать атрибут(ы), определяющий эту зависимость, в качестве первичного ключа нового отношения;

3 установить связь от нового отношения к старому.

3НФ позволяет избежать следующих аномалий при выполнении операций:

- Обновления. Имеет место дублирование данных об окладе, если должность занимают несколько сотрудников.

- Вставки. Невозможно ввести данные об окладе, если нет сотрудника, занимающего эту должность.

- Удаления. В случае удаления из таблицы сотрудника, занимающего уникальную должность данные об окладе теряются

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

18. Распределенные информационные системы. Технология сервера базы данных (dbs).

DBS-модель (модель сервера БД) – реализована в реляционных СУБД Informix, Oracle, Ingres. Основой модели является механизм хранимых процедур – средство программирования SQL-сервера. Процедуры хранятся в словаре БД, разделяются между несколькими клиентами и выполняются на компьютере, где функционирует SQL-сервер (рис. 1).

вызов

процедур

данные

Клиент Сервер

Рисунок 1 Модель сервера баз данных

Технология: компонент представления выполняется на компьютере-клиенте, а прикладной компонент и ядро СУБД на компьютере-сервере БД. Процедуры хранятся в словаре БД на SQL- сервере и являются средством программирования SQL-сервера. Процедуры разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры, является процедурным расширением языка SQL и уникальным для каждой CУБД (например, PL/SQL для Oracle). В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД, там же находится и компонент доступа к данным, т е ядро СУБД.

Концепция активного сервера опирается на четыре «столпа»:

1. процедуры БД;

2. правила (триггеры);

3. события в БД;

4. типы данных, определяемые пользователем прикладных программ.

Хранимые (stored, присоединяемые, разделяемые) процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных. Выполняемый или интерпретируемый код хранимой процедуры сохраняется в базе данных, а сама она может быть вызвана из любой прикладной программы авторизованного пользователя (того, кто получил привилегию на выполнение этой процедуры) с указанием фактических параметров (рис.2). Хранимые процедуры обычно пишутся либо на специальном процедурном расширении языка SQL (например, PL/SQL для ORACLE или Transact-SQL для MS SQL Server), или на некотором универсальном языке программирования, например, C++, с включением в код операторов SQL в соответствии со специальными правилами такого включения. Основное назначение хранимых процедур - реализация бизнес-процессов предметной области. Использование процедур БД преследует четыре цели:

1. обеспечение независимого уровня централизованного контроля доступа к данным, осуществляемого администратором БД;

2. одна процедура может быть использована несколькими прикладными программами;

3. значительное снижение трафика сети с архитектурой «клиент-сервер» за счет вызова процедур, а не пересылки запросов.

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

Пример 7.7 Разработать процедуру, которая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность:

CREATE PROCEDURE Назначение (Номер_сотр integer not null) AS

BEGIN

INSERT INTO Резерв SELECT * FROM Сотрудник WHERE номер= Номер_сотр;

DELETE FROM Сотрудник WHERE номер= Номер_сотр;

END

Вызов процедуры осуществляется с помощью команды EXECUTE …,например:

EXECUTE PROCEDURE Назначение (115)

Рисунок. 2. Подготовка и использование хранимой процедуры

Триггеры - это хранимые процедуры без параметров, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров - автоматическая поддержка целостности базы данных. Кроме поддержки целостности БД, триггеры позволяют решать следующие задачи:

• расчет промежуточных результатов и других вычисляемых значений;

• создание записей аудита для обеспечения безопасности или просто отслеживания операций, выполняемых над таблицей;

• вызов внешних действий, например, процедуры для посылки почтового сообщения при срабатывании триггера;

• реализация сложной защиты целостности данных.

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

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

Укажем основные цели механизма правил:

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

Пример 7.9 Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше 1000. Это требование описывается правилом:

CREATE RULE Проверить_деталь

AFTER UPDATE (количество) OF Деталь WHERE деталь.количество<1000

EXECUTE PROCEDURE Заказать_деталь (Ном_дет=Деталь.ном, остаток=Деталь.количество);

2. обеспечение целостности БД, особенно целостности по ссылкам

Механизм событий в БД позволяет прикладным программам и серверу БД уведомлять другие программы о наступлении в БД определенного события и тем самым синхронизировать их работу. Операторы языка SQL, которые обеспечивают уведомление, называются сигнализаторами событий в БД database event alerters). Функции управления событиями целиком ложатся на сервер БД. Различные прикладные программы и процедуры вызывают события, а сервер оповещает монитор прикладных программ об их наступлении. Реакция монитора на событие заключается в выполнении действий, которые предусмотрел разработчик.

Механизм событий используется следующим образом:

1. вначале в БД для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT – создать событие);

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

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

4. каждая зарегистрированная программа может получить информацию о событии, для чего должна запросить очередное сообщение из очереди событий оператором GET DBEVENT (получить событие).

Типы данных, определяемые пользователем. Проблемы с типами данных решаются за счет интеграции в сервер новых типов данных. Например, СУБД Ingres предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для этого надо написать и откомпилировать функции на языке С. Введение новых типов данных является по сути изменением ядра СУБД. В Ingres типы данных, определяемые пользователем могут быть параметризированы. Определение нового типа данных сводится к указанию его нового имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют стандартные операции (сравнение, преобразование в различные форматы и т.д.) программист должен их разработать самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип определен, то все операции выполняются над ним как над данными стандартного типа. Разрешение пользователю создавать свои типы данных – это один из шагов развития реляционных СУБД в направлении объектно-реляционных систем.

Достоинства модели:

• возможность централизованного администрирования прикладных функций;

• снижение трафика, т. к. по сети отправляются вызовы хранимых процедур вместо SQL-запросов;

• возможность разделения процедур между несколькими приложениями;

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

Недостатки: ограниченность языковых средств, используемых для написания хранимых процедур. Процедурные расширения SQL не выдерживают никакого сравнения с функциональными возможностями языков программирования высокого уровня и сфера их использования ограничена конкретной СУБД.

На практике чаще используется разумный синтез RDA и DBS-моделей

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

19. Распределенные информационные системы. Технология удаленного доступа к данным (rda).

RDA-модель (модель удаленного доступа). Коды компонента представления и прикладного совмещены и выполняются на компьютере-клиенте, а доступ к информационным ресурсам обеспечивается операторами языка запросов SQL (рис. 7.2).

SQL-запросы

Данные

Клиент Сервер

Рисунок 7.2 Модель доступа к удаленным данным

Технология: клиентский запрос направляется на сервер, где ядро СУБД обрабатывает запрос и возвращает результат (набор данных) клиенту. Ядро СУБД играет пассивную роль, так как инициатором манипуляций с данными являются программы на компьютере-клиенте.

Традиционной и наиболее популярной является модель доступа к удаленным данным (RDA-модель). Имеется компьютер-клиент, на котором запускаются программы переднего плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции). Этот компьютер, называемый локальным узлом (local node) соединен в сети с компьютером, на котором выполняется сервер БД, и находится сама БД (обычно его называют удаленным узлом – remote node). Все проблемы, возникающие при взаимодействии клиента и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net).

Достоинства: уменьшается загрузка сети, так как по сети передаются запросы языке SQL; унифицирован интерфейс «клиент-сервер» в виде языка SQL, который используется в качестве стандарта общения клиента и сервера.

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

20. Распределенные информационные системы. Технология сервера приложений (as).

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

Технология: В этой модели компоненты приложения делятся между тремя исполнителями:

• на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем; этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения;

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

• серверы БД обеспечивают функции создания и ведения БД, поддерживают целостность БД и выполняют другие функции СУБД.

Достоинства: эта модель обладает большей гибкостью, чем двухзвенные модели. Большая часть бизнес-логики клиента в этой модели изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования. Это повышает переносимость и масштабируемость системы.

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

запуск

процедур

данные SQL

Клиент Сервер приложений Сервер БД

Рисунок 7.4 Модель сервера приложений

С ростом сложности распределенных вычислительных систем возникают проблемы эффективного использования их ресурсов. Для решения этих проблем в состав распределенных OLTP-систем вводят дополнительный компонент – монитор транзакций (TPM – Transaction Processing Monitor). Мониторы транзакций выполняют две основные функции:

• динамическое распределение запросов в системе (выравнивание нагрузки);

• оптимизация числа выполняемых серверных приложений.

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

• запрос клиентского приложения поступает монитору транзакций, который определяет получателя этого запроса. Для этого он обращается к динамической маршрутной таблице, по которой определяет систему, предоставляющую соответствующий сервис;

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

• результат выполнения запроса через монитор транзакций перенаправляется приложению, пославшему запрос.

21. Понятие полноты и точности информационного поиска.

Информационный поиск: Действия, методы и процедуры, позволяющие осуществлять отбор определенной информации из массива данных

Пертинентность; пертинентный: Соответствие полученной информации информационной потребности

Показатели эффективности информационно-поисковых систем:

Полнота информационного поиска R определяется отношением числа найденных пертинентных документов А к общему числу пертинентных документов С, имеющихся в системе или в исследуемой совокупности документов:

Точность информационного поиска Р определяется отношением числа найденных пертинентных документов А к общему числу документов L, выданных на запрос пользователя:

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

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

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

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

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

В документальных ИПС объекты хранения и выдачи – документы и тексты целиком.

При фактографическом поиске объекты хранения и выдачи – это представленные в специальной форме сведения (факты) об определенном объекте.

Например, на запрос “какова скорость света” в документальных ИПС будут выданы статьи и книги, в которых говорится о скорости света, и возможно, содержится ответ на поставленный вопрос. В фактографической же системе в той или иной форме будет выдано сообщение о том, какова скорость света.

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

Соответственно, следует различать два типа запросов: документальные (тематические – найти, документы в которых говорится о скорости света) и фактографические (найти, какова скорость света).

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

Нередко ИПС представляют собой смешанные системы, в которых фактографическая информация используется как дополнительное средство документального поиска, и наоборот.

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

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

Поэтому можно дать следующее определение документальной ИС - единое хранилище документов с инструментарием поиска и отбора необходимых документов.

Поисковый характер документальных информационных систем исторически определил еще одно их название — информационно-поисковые системы (ИПС), хотя этот термин не совсем полно отражает специфику документальных ИС.

Информационная потребность: Характеристики предметной области, значения которых необходимо установить для выполнения поставленной задачи в практической деятельности

Соответствие найденных документов информационным потребностям пользователя называется пертинентностъю.

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

Система на основе определенных критериев и способов ищет документы, поисковые образы которых соответствуют или близки поисковым образам запроса пользователя, и выдает соответствующие документы.

Информационный запрос: Текст, выражающий информационную потребность

Соответствие найденных документов запросу пользователя называется релевантностью. Схематично общий принцип устройства и функционирования документальных ИПС на основе индексирования иллюстрируется на Рисунок 1.

Рисунок 2. Общий принцип функционирования документальных ИПС на основе индексирования

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

Релевантность; релевантный: Соответствие полученной информации информационному запросу

• Релевантность - степень соответствия содержания документа, найденного в результате информационного поиска, содержанию информационного запроса.

• Пертинентность - степень соответствия содержания документа, найденного в результате информационного поиска, информационной потребности пользователя, сформулированной в виде информационного запроса.

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

• Формальная релевантность – наличие в документе контекстных ситуаций, затребованных пользовательским запросом

• Содержательная релевантность – соответствие содержания документа информационной потребности пользователя

• Индивидуально-прагматическая релевантность или пертинентность (англ. pertinent)

23. Способы описания предметной области. Er модели.

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

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

Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:

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

2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:

• на основе явного представления концептуальной схемы как исходной информации для компилятора;

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

И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.

3. Работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта:

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

• прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).

Основные понятия модели Entity-Relationship

Опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании основных идей.

Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная».

Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.5.1).

Рисунок 5.1 Пример сущности

Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».

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

Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.

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

Рисунок 5.2 Пример сущности с указанием атрибутов

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

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на диаграмме подчеркиванием (рис.5.3).

Рисунок 5.3 Пример сущности с указанием ключа

Определение 5. Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

Связи позволяют по одной сущности находить другие сущности, связанные с нею.

Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».

Графически связь изображается линией, соединяющей две сущности (рис.5.4).

Рисунок 5.4 Пример связи двух сущностей

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

Каждая связь может иметь один из следующих типов связи (рис.5.5.:

Рисунок 5.5 Графическое изображение типов связей

Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на рис.5.4.

Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.

Каждая связь может иметь одну из двух модальностей связи (рис.5.6).

Рисунок 5.6 Графическое изображение модальностей связи

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

Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов (как на рис. 5.4).

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 5.4 читается так:

Слева направо: «каждый сотрудник может иметь несколько детей».

Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».

Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Приведем только очень краткие и неформальные определения трех первых нормальных форм.

В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, «замаскированных» под атрибуты.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности

Пример разработки простой ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

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

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

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

• Хранить информацию о покупателях.

• Печатать накладные на отпущенные товары.

• Следить за наличием товаров на складе.

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

• Покупатель - явный кандидат на сущность.

• Накладная - явный кандидат на сущность.

• Товар - явный кандидат на сущность

• (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

• (?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями – «покупатели могут покупать много товаров» и «товары могут продаваться многим покупателям». Первый вариант диаграммы выглядит так (рис.5.7).

Рисунок 5.7 Первый вариант диаграммы

Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада. Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Как связаны эти сущности между собой и с сущностями «Покупатель» и «Товар»? Пока известно, что:

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

• Каждый покупатель может получить несколько накладных.

• Каждая накладная обязана выписываться на одного покупателя.

• Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных).

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

• Каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных.

Таким образом, после уточнения, диаграмма будет выглядеть следующим образом (рис.5.8).

Рисунок 5.8 Второй вариант диаграммы

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

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

• Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

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

• Каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

• юридическое лицо - термин ненужный, т.к.фирма не работает с физическими лицами. Не обращаем внимания;

• наименование покупателя - явная характеристика покупателя;

• адрес - явная характеристика покупателя;

• банковские реквизиты - явная характеристика покупателя;

• наименование товара - явная характеристика товара;

• (?)цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

• единица измерения - явная характеристика товара;

• номер накладной - явная уникальная характеристика накладной;

• дата накладной - явная характеристика накладной;

• (?)список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;

• (?)количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной»;

• (?)цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

• сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;

• наименование склада - явная характеристика склада.

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

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

• каждая накладная обязана иметь несколько записей из списка товаров в накладной;

• каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;

• каждый товар может включаться в несколько записей из списка товаров в накладной;

• каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.

Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности «Список товаров в накладной».

Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму «Оптовая фирма» (рис. 5.9).

Замечание. Утверждения, которые были сформулированы в ходе бесед с сотрудниками фирмы, например: «Каждый покупатель может получить несколько накладных», являются бизнес-правилами. Бизнес-правила описывают правила работы данной организации и для БД это, по сути, ограничения целостности.

Рисунок 5.9 Диаграмма «Оптовая фирма»

61