Выбор СУБД и других инструментальных программных средств.
На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, выбор типа и конфигурации ЭВМ, типа и версии операционной системы.
Выбор зависит от таких следующих показателей:
примерный объём данных в БД;
динамика роста объёма данных;
характер запросов к данным (извлечение и обновление отдельных записей, групп записей, обработка отдельных отношений или соединение отношений);
интенсивность запросов к данным по типам запросов;
требования к времени отклика системы по типам запросов.
Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализации информационной системы.
Теоретически при осуществлении этого выбора нужно принимать во внимание десятки факторов. Но на практике разработчики руководствуются лишь собственной интуицией и несколькими наиболее важными критериями, к которым, в частности, относятся:
тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой ПО;
характеристики производительности СУБД;
запас функциональных возможностей для дальнейшего развития информационной системы;
степень оснащенности СУБД инструментарием для персонала администрирования данными;
удобство и надежность СУБД в эксплуатации;
стоимость СУБД и дополнительного программного обеспечения.
Даталогическое или логическое проектирование БД, т.е. описание БД в терминах принятой даталогической модели данных (например, реляционной). Задачей логического этапа проектирования является организация данных., выделенных на предыдущем этапе, в такую форму, которая принята в выбранной конкретной СУБД, используя ее типы и модели данных. Даются рекомендации по выбору методов доступа к данным.
Физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения. Задачей физического этапа проектирования является выбор рациональной структуры хранения данных. и методов доступа к ним, исходя из того арсенала средств и методов, который предоставляет разработчику конкретная СУБД.
При проектировании базы данных решаются две основных проблемы:
Каким образом отобразить объекты предметной области в абстрактные объекты модели данных? Эту проблему называют проблемой логического проектирования баз данных.
Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.
В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Поэтому мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.
Более того, мы не будем касаться очень важного аспекта проектирования - определения ограничений целостности (за исключением ограничения первичного ключа). Дело в том, что при использовании СУБД с развитыми механизмами ограничений целостности (например, SQL-ориентированных систем) трудно предложить какой-либо общий подход к определению ограничений целостности. Эти ограничения могут иметь очень общий вид, и их формулировка пока относится скорее к области искусства, чем инженерного мастерства. Самое большее, что предлагается по этому поводу в литературе, это автоматическая проверка непротиворечивости набора ограничений целостности.
Так что будем считать, что проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том,
из каких отношений должна состоять БД и
какие атрибуты должны быть у этих отношений
Можно выделить три основных подхода к проектированию реляционных БД:
сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая ее декомпозиция на несколько взаимосвязанных таблиц на основе процедур нормализации (классический метод);
переход от семантической (инфологической) модели второго этапа с помощью CASE-средств к готовой схеме БД или даже готовой прикладной информационной системе (ИС);
структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности практических правил и рекомендаций.
Применение семантических моделей при проектировании
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.
При этом проявляется ограниченность реляционной модели данных в следующих аспектах:
Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика.
Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.
Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области («сущностей») и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Моделирование структуры базы данных при помощи алгоритма нормализации, описанного в п.5.1, имеет серьезные недостатки:
Первоначальное размещение всех атрибутов в одном отношении является очень неестественной операцией. Интуитивно разработчик сразу проектирует несколько отношений в соответствии с обнаруженными сущностями.
Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку называть разными именами одни и те же вещи или, наоборот, называть одними именами разные вещи.
Для проведения процедуры нормализации необходимо выделить зависимости атрибутов, что тоже очень нелегко, т.к. необходимо явно выписать все зависимости, даже те, которые являются очевидными
В реальном проектировании структуры базы данных применяются другой метод - так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:
на основе явного представления концептуальной схемы как исходной информации для компилятора;
построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.
3. Работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта:
обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной схемы базы данных в реляционную схему)
прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).
11. Распределенные информационные системы (рис), основные понятия.
Под распределенной БД (Distributed DataBase - DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово «распределенная» отражает способ организации базы данных, но не внешнюю ее характеристику («распределенность» базы данных невидима извне). Примерами СУБД, обеспечивающих распределенную обработку данных являются: R-Star, Distributed Ingres, Oracle 7, Ingres/Star, CA-OpenIngres, Sybase, Informix-OnLine Dynamic Server.
Распределенная БД предполагает хранение и выполнение функций управления данными в нескольких узлах и передачу данных между этими узлами в процессе выполнения запросов.
При построении систем распределенных обработки данных применяются две технологии:
1. Технология распределенной БД (Технология STAR), при которой фрагменты данных расположены на разных узлах сети. Все изменения должны синхронно передаваться во все узлы. Такая схема предъявляет жесткие требования к производительности и надежности каналов связи.
2. Технология тиражирования, при которой в каждом узле дублируются данные всех других узлов, а передаются только операции изменения данных, а не сами данные как в технологии STAR. Передача может быть асинхронной (неодновременной для разных узлов).
Аспекты сетевого взаимодействия
Традиционной и наиболее популярной является модель доступа к удаленным данным (RDA-модель). Рассмотрим ее более подробно. Имеется компьютер-клиент, на котором запускаются программы переднего плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции). Этот компьютер, называемый локальным узлом (local node) соединен в сети с компьютером, на котором выполняется сервер БД, и находится сама БД (обычно его называют удаленным узлом – remote node). Все проблемы, возникающие при взаимодействии клиента и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net).
В основу взаимодействия клиентов и сервера БД положены 12 принципов, сформулированных К. Дейтом и определяющих функциональные возможности современных СУБД и требования к ним при сетевом взаимодействии и распределенной обработки данных:
Локальная автономия (local autonomy). Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. БД, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная база данных; управление ею выполняется локально и независимо от других узлов системы
Независимость узлов (no reliance on central site). В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. БД на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа
3. Непрерывные операции (continuous operation). Это качество можно трактовать как возможность непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а операции над ними выполняются непрерывно».
4 Прозрачность расположения (location independence). Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.
5. Прозрачная фрагментация (fragmentation independence). Это свойство трактуется как возможность распределенного (то есть на различных узлах) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам.
6. Прозрачное тиражирование (replication independence). Тиражирование данных - это асинхронный (в общем случае) процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном контексте прозрачность тиражирования означает возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.
7. Обработка распределенных запросов (distributed query processing). Это свойство DDB трактуется как возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных.
Пример 7.2 SELECT customer.name, customer.address, order.number, order.date FROM customer@london, order@paris WHERE customer.cust_number = order.cust_number
8. Обработка распределенных транзакций (distributed transaction processing). Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной БД (INSERT, UPDATE, DELETE), не разрушающих целостность и согласованность данных. Эта цель достигается применением двухфазового или двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.
9. Независимость от оборудования (hardware independence). Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до ПК.
10. Независимость от операционных систем (operationg system independence). Это качество вытекает из предыдущего и означает многообразие операционных систем, управляющих узлами распределенной системы.
Прозрачность сети (network independence). Доступ к любым БД может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Данное качество формулируется максимально широко - в распределенной системе возможны любые сетевые протоколы.
12. Независимость от СУБД (DBMS independence). Это качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. Исходя из определения Дэйта, можно рассматривать DDB как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами - это потоки тиражируемых данных. Топология DDB варьируется в широком диапазоне - возможны варианты иерархии, структур типа "звезда" и т.д. В целом топология DDB определяется географией информационной системы и направленностью потоков тиражирования данных. Посмотрим, во что выливается некоторые наиболее важные свойства DDB, если рассматривать их практически
В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB - достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.
Прозрачность расположения в реальных продуктах должна поддерживаться соответствующими механизмами. Разработчики СУБД придерживаются различных подходов.
Пример 7.3 Рассмотрим пример из Oracle. Допустим, что DDB включает локальную базу данных, которая размещена на узле в Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем (london_unix), транслируемым в IP-адрес узла в Лондоне.
CREATE PUBLIC DATABASE LINK london.com CONNECT TO london_unix USING oracle_user_ID;
Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в операторе SELECT таблицу, хранящуюся в этой базе:
SELECT customer.cust_name, order.order_date FROM customer@london.com, order WHERE customer.cust_number = order.cust_number;
Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных, поскольку явно использовали в нем ссылку. Определим customer и customer@london.com как синонимы:
CREATE SYNONYM customer FOR customer@london.com;
и в результате можем написать полностью независимый от расположения базы данных запрос:
SELECT customer.cust_name, order.order_date FROM customer, order WHERE customer.cust_number = order.cust_number
Задача решается с помощью оператора SQL CREATE SYNONYM, который позволяет создавать новые имена для существующих таблиц. При этом оказывается возможным обращаться к другим базам данных и к другим компьютерам.. Во многих СУБД задача управления именами объектов DDB решается путем использования глобального словаря данных, хранящего информацию о DDB: расположение данных, возможности других СУБД (если используются шлюзы), сведения о скорости передачи по сети с различной топологией и т.д.
Обработка распределенных запросов (Distributed Query -DQ) - задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента - оптимизатора DQ.
Пример 7.4 Обратимся к базе данных, распределенной по двум узлам сети. Таблица Деталь хранится на одном узле, таблица Поставщик - на другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:
SELECT Деталь _имя, Поставщик _имя, Поставщик _адрес
FROM Деталь, Поставщик
WHERE Деталь. Поставщик _номер = Поставщик. Поставщик _номер;
Результирующая таблица представляет собой соединение таблиц Деталь и Поставщик, выполненное по столбцу Деталь.Поставщик.номер (внешний ключ) и Поставщик. Поставщик.номер (первичный ключ). Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица Поставщик. Следовательно, оптимизатор DQ запросов должен учитывать:
размер таблиц;
статистику распределения данных по узлам;
объем данных, передаваемых между узлами;
скорость коммуникационных линий;
структуры хранения данных;
соотношение производительности процессоров на разных узлах и т.д.
От интеллекта оптимизатора DQ впрямую зависит скорость выполнения распределенных запросов.
Важным качеством для DDB является межоперабельность, означающая две вещи. Во-первых, - это качество, позволяющее обмениваться данными между БД различных поставщиков. Как, например, тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных. Во-вторых, это возможность некоторого унифицированного доступа к данным в DDB из приложения. Возможны как универсальные решения (стандарт ODBC), так и специализированные подходы. Очевидный недостаток ODBC - недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения не поддерживаются. Специальные подходы - это, например, использование шлюзов, позволяющее приложениям оперировать над базами данных в «чужом» формате так, как будто это собственные базы данных. Вообще, цель шлюза - организация доступа к унаследованным (legacy) БД и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так, если компания долгое время работала на СУБД IMS и затем решила перейти на Oracle, то ей очевидно потребуется шлюз в IMS. Следовательно, шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе.
Технология распределенной БД (технология STAR)
Системы распределенных БД состоят из набора узлов, связанных вместе коммуникационной сетью, в которой:
каждый узел обладает собственной системой БД;
узлы работают согласованно, поэтому пользователь может получить доступ к данным на любом узле сети, как будто все данные находятся на его собственном узле.
Пример 7.5 Пусть БД «Склад» расположена на узле «узел_1», а БД «Предприятие» на узле «узел_2». В первой содержится таблицы Деталь, а во второй Поставщик. Пусть БД «Номенклатура» должна включать таблицы Деталь и Поставщик, физически принадлежащие различным БД. Логически она будет рассматриваться как нераспределенная БД. Следующие операторы SQL устанавливают ссылки на таблицы локальных БД. Они включены в в описание распределенной БД и передаются серверу БД.
REGISTER TABLE Деталь AS LINK WITH NODE=узел_1, DATABASE=Склад;
REGISTER TABLE Поставщик AS LINK WITH NODE=узел_2, DATABASE=Предприятие;
Таким образом, при описании распределенной БД «Номенклатура» явно задаются ссылки на конкретные таблицы реально существующих БД, однако при работе с такой БД это физическое распределение прозрачно для пользователя.
Наибольшую сложность при организации работы распределенной БД вызывает решение следующих задач:
управление именами в распределенной среде;
оптимизация распределенных запросов;
управления распределенными транзакциями.
Задачи рассмотрены выше . Решение этих трех задач возложено на специальный компонент СУБД – сервер распределенных баз данных (Distributed Database Server). Возможны следующие варианты организации работы распределенной БД:
Если БД расположена на одном узле и прикладная программа выполняется там же, то не требуется ни коммуникационный сервер, ни сервер распределенных БД.
Когда же прикладная программа выполняется на локальном узле, БД находится на удаленном узле и там же выполняется сервер БД, то на удаленном узле необходим коммуникационный сервер, а на локальном – сервисная коммуникационная программа.
Если же распределенная БД состоит из таблиц локальных БД, которые находятся на одном узле, и там же функционирует сервер распределенной БД, и выполняется прикладная программа, то коммуникационный сервер не нужен, так как нет взаимодействия по сети.
Если же локальные БД расположены на нескольких узлах, то для доступа к распределенной БД необходим и сервер распределенной БД, и коммуникационный сервер
Главное требование технологии STAR - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в DDB. Уязвимым местом этой технологии являются - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
Технология тиражирования данных
Принципиальная характеристика тиражирования (репликации) данных (Data Replication - DR) заключается в отказе от физического распределения данных. Суть DR состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально. DR – это набор технологий, который позволяет поддерживать несколько копий одних и тех же данных на нескольких узлах. Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к Oracle7 DBMS опцию Replication Option. Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR - использование «моментальных снимков» (snapshot).
Пример 7.6 Рассмотрим пример из Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE ('DD-MON-YY HH23:MI:55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = "N";
«Моментальный снимок» в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторяться каждые 7 дней. Каждый раз будут выбираться только завершенные заказы. Реальные схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для тиражирования выступает транзакция к базе данных. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей базы на определенный момент времени. Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависят от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит качество 6 в определении Дэйта. Технология распределенных БД и DR-технология - в определенном смысле антиподы. DR-технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы. Преимуществами технологии тиражирования данных являются:
данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается;
передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик;
со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом;
никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
DR-технология данных не лишена недостатков. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. При проектировании распределенной среды с использованием DR-технологии необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения. Необходимо отметить, что при этой технологии предъявляются высокие требования к аппаратным ресурсам узлов.
Технология тиражирования нашла применение там, где предъявляются повышенные требования к надежности - в сфере банковских информационных систем.
12. Понятие транзакции. Проблемы обновления таблиц-отношений.
Транзакция - это неделимая, с точки зрения воздействия на СУБД, последовательность операций манипулирования данными. Для пользователя транзакция выполняется по принципу «все или ничего», т.е. либо транзакция выполняется целиком и переводит базу данных из одного целостного состояния в другое целостное состояние, либо, если по каким-либо причинам, одно из действий транзакции невыполнимо, или произошло какое-либо нарушение работы системы, БД возвращается в исходное состояние, которое было до начала транзакции (происходит откат транзакции). С этой точки зрения, транзакции важны как в многопользовательских, так и в однопользовательских системах. В однопользовательских системах транзакции - это логические единицы работы, после выполнения которых БД остается в целостном состоянии. Транзакции также являются единицами восстановления данных после сбоев - восстанавливаясь, система ликвидирует следы транзакций, не успевших успешно завершиться в результате программного или аппаратного сбоя. Эти два свойства транзакций определяют атомарность (неделимость) транзакции. В многопользовательских системах, кроме того, транзакции служат для обеспечения изолированной работы отдельных пользователей - пользователям, одновременно работающим с одной базой данных, кажется, что они работают как бы в однопользовательской системе и не мешают друг другу.
Транзакция или логическая единица работы БД, - это в общем случае последовательность ряда таких операций, которые преобразуют некоторое непротиворечивое состояние базы данных в другое непротиворечивое состояние, но не гарантируют сохранения непротиворечивости во все промежуточные моменты времени.
Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:
(А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.
(С) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.
(И) Изоляция. Транзакции разных пользователей не должны мешать друг другу (например, как если бы они выполнялись строго по очереди).
(Д) Долговечность. Если транзакция выполнена, то результаты ее работы должны сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.
Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:
подана команда COMMIT (зафиксировать транзакцию);
подана команда ROLLBACK (откатить транзакцию);
произошло отсоединение пользователя от СУБД;
произошел сбой системы.
Свойства АСИД транзакций не всегда выполняются в полном объеме. Особенно это относится к свойству И (изоляция). В идеале, транзакции разных пользователей не должны мешать друг другу, т.е. они должны выполняться так, чтобы у пользователя создавалась иллюзия, что он в системе один. Простейший способ обеспечить абсолютную изолированность состоит в том, чтобы выстроить транзакции в очередь и выполнять их строго одну за другой. Очевидно, при этом теряется эффективность работы системы. Поэтому реально одновременно выполняется несколько транзакций (смесь транзакций). Различается несколько уровней изоляции транзакций. На низшем уровне изоляции транзакции могут реально мешать друг другу, на высшем - они полностью изолированы. За большую изоляцию транзакций приходится платить большими накладными расходами системы и замедлением работы. Пользователи или администратор системы могут по своему усмотрению задавать различные уровни изоляции всех или отдельных транзакций. Более подробно изоляция транзакций рассматривается в п. 4.6.3.
Свойство Д (долговечность) также не является абсолютными свойством, т.к. некоторые системы допускают вложенные транзакции. Если транзакция Б запущена внутри транзакции А, и для транзакции Б подана команда COMMIT, то фиксация данных транзакции Б является условной, т.к. внешняя транзакция А может откатиться. Результаты работы внутренней транзакции Б будут окончательно зафиксированы только, если будет зафиксирована внешняя транзакция А.
Свойство (С) - согласованность транзакций определяется наличием понятия согласованности базы данных. База данных находится в согласованном (целостном) состоянии, если выполнены (удовлетворены) все ограничения целостности, определенные для базы данных.
Ограничение целостности (бизнес-правило) - это некоторое утверждение, которое может быть истинным или ложным в зависимости от состояния базы данных.
Примерами ограничений целостности могут служить следующие утверждения:
Пример 1. У каждого заказчика только один продавец.
Пример 2. Каждый сотрудник имеет уникальный табельный номер.
Пример 3 Сотрудник обязан числиться в только одном отделе.
Пример 4. Сумма денег накладной обязана равняться сумме произведений цен товаров на количество товаров для всех товаров, входящих в накладную.
Как видно из этих примеров, некоторые из ограничений целостности являются ограничениями реляционной модели данных. Пример 2 представляет ограничение, реализующее целостность сущности. Примеры 1, 3 представляют ограничения, реализующие ссылочную целостность. Другие ограничения являются достаточно произвольными утверждениями, связанными с правилами в конкретной предметной области (пример 4). Любое ограничение целостности является семантическим понятием, т.е. появляется как следствие определенных свойств объектов предметной области и/или их взаимосвязей.
Вместе с понятием целостности базы данных возникает понятие реакции системы на попытку нарушения целостности. Система должна не только проверять, не нарушаются ли ограничения в ходе выполнения различных операций, но и должным образом реагировать, если операция приводит к нарушению целостности. Имеется два типа реакции на попытку нарушения целостности:
Отказ выполнить "незаконную" операцию.
Выполнение компенсирующих действий.
Работа системы по проверке ограничений изображена на рисунке 1.
Каждая система обладает своими средствами поддержки ограничений целостности. Ограничения целостности классифицируются несколькими способами:
по способам реализации;
по времени проверки;
по области действия.
По способам реализации различают:
декларативную поддержку ограничений целостности - средствами языка определения данных (DDL);
процедурную поддержку ограничений целостности - посредством триггеров и хранимых процедур.
Рисунок.1 Работа системы по проверке ограничений
По времени проверки ограничения делятся на:
немедленно проверяемые ограничения;
ограничения с отложенной проверкой.
По области действия ограничения делятся на:
ограничения домена;
ограничения атрибута;
ограничения кортежа;
ограничения отношения;
ограничения базы данных.
Стандарт языка SQL поддерживает только декларативные ограничения целостности, реализуемые как:
ограничения домена;
ограничения, входящие в определение таблицы;
ограничения, хранящиеся в базе данных в виде независимых утверждений (assertion).
Проверка ограничений допускается как после выполнения каждого оператора, могущего нарушить ограничение, так и в конце транзакции. Во время выполнения транзакции можно изменить режим проверки ограничения.
Стандарт SQL не предусматривает процедурных ограничений целостности, реализуемых при помощи триггеров и хранимых процедур. В стандарте SQL 92 отсутствует понятие «триггер», хотя триггеры имеются во всех промышленных СУБД SQL-типа. Таким образом, реализация ограничений средствами конкретной СУБД обладает большей гибкостью, нежели с использованием исключительно стандартных средств SQL.
Проблемы параллельной работы транзакций
Современные многопользовательские системы допускают одновременную работу большого числа пользователей. При этом, если не предпринимать специальных мер, транзакции будут мешать друг другу. Этот эффект известен как проблемы параллелизма.
Имеются три основных следствия проблемы параллелизма:
проблема потери результатов обновления;
проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание);
проблема несовместимого анализа.
Решение проблем параллелизма состоит в нахождении такой стратегии запуска транзакций, чтобы обеспечить сериальность графика запуска и не слишком уменьшить степень параллельности.
Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой план, который приводит к сериализации транзакций. График запуска набора транзакций называется последовательным, если транзакции выполняются строго по очереди. Если график запуска набора транзакций содержит чередующиеся элементарные операции транзакций, то такой график называется чередующимся. Два графика называются эквивалентными, если при их выполнении будет получен один и тот же результат, независимо от начального состояния базы данных. График запуска транзакции называется верным (сериализуемым), если он эквивалентен какому-либо последовательному графику.
Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Одним из методов обеспечения сериальности графика запуска является протокол доступа к данным при помощи блокировок. В простейшем случае различают S-блокировки (Shared locks разделяемые) и X-блокировки (eXclusive locks монопольные). Протокол доступа к данным имеет вид:
Прежде, чем прочитать объект, транзакция должна наложить на этот объект S-блокировку.
Прежде, чем обновить объект, транзакция должна наложить на этот объект X-блокировку. Если транзакция уже заблокировала объект S-блокировкой (для чтения), то перед обновлением объекта S-блокировка должна быть заменена X-блокировкой.
Если блокировка объекта транзакцией B отвергается оттого, что объект уже заблокирован транзакцией A, то транзакция B переходит в состояние ожидания. Транзакция B будет находиться в состоянии ожидания до тех пор, пока транзакция A не снимет блокировку объекта.
X-блокировки, наложенные транзакцией A, сохраняются до конца транзакции A.
Если все транзакции в смеси подчиняются протоколу доступа к данным, то проблемы параллелизма решаются (почти все, кроме «фантомов»), но появляются тупики. Состояние тупика (dead locks) характеризуется тем, что две или более транзакции пытаются заблокировать одни и те же объекты, и бесконечно долго ожидают друг друга.
Для разрушения тупиков система периодически или постоянно поддерживает граф ожидания транзакций. Наличие циклов в графе ожидания свидетельствует о возникновении тупика. Для разрушения тупика одна из транзакций (наиболее дешевая с точки зрения системы) выбирается в качестве жертвы и откатывается.
Для решения проблемы «фантомов», а также для уменьшения накладных расходов, вызываемых большим количеством блокировок, применяются более сложные методы. Одним из таких методов являются преднамеренные блокировки, блокирующие объекты разной величины - строки, страницы, таблицы, файлы и др.
13. Документальные информационные системы
Информационные системы делят на фактографические (ориентированные на работу со структурированными данными - фактами) и документальные (ориентированные на работу со слабо структурированными или неструктурированными данными – текстами).
Первые системы автоматизированного информационного поиска документов появились еще в 60-х годах, развитые коммерческие информационно-поисковые системы, ориентированные на накопление и обработку текстовых документов, получили распространение лишь в конце 80-х – начале 90-х годов.
В фактографических ИС единичным элементом данных, имеющих отдельное смысловое значение, является запись, образуемая конечной совокупностью полей-атрибутов. В документальных ИС единичным элементом данных является неструктурированный на более мелкие элементы документ.
Основной задачей документальных ИС является накопление и предоставление пользователю документов, содержание, тематика, реквизиты и т.п. которых адекватны его информационным потребностям. Поэтому документальную ИС определяют как единое хранилище документов с инструментарием поиска и отбора необходимых документов. Поисковый характер документальных ИС исторически определил еще одно их название – информационно-поисковые системы (ИПС).
СПЕЦИФИКА ДОКУМЕНТАЛЬНЫХ ИПС
Поиск информации (данных) осуществляется и в фактографических ИС. Специфика документальных ИПС заключается в том, что они удовлетворяют информационные запросы пользователя, предоставляя ему документы, в которых содержится интересующая пользователя информация.
В зависимости от особенностей реализации хранилища документов и механизма поиска документальные ИПС можно разделить на две группы:
системы на основе индексирования;
семантически-навигационные системы.
СЕМАНТИЧЕСКИ-НАВИГАЦИОННЫЕ СИСТЕМЫ
В семантически-навигационных системах документы, помещаемые в хранилище, оснащаются специальными навигационными конструкциями, соответствующими смысловым связям (ссылкам) между различными документами или отдельными фрагментами одного документа. Такие конструкции реализуют некоторую семантическую (смысловую) сеть в базе документов. Способ и механизм выражения информационных потребностей в подобных системах заключаются в явной навигации (перенаправлении) пользователя по смысловым отсылкам между документами. Такой подход реализуется в гипертекстовых ИПС.
СИСТЕМЫ НА ОСНОВЕ ИНДЕКСИРОВАНИЯ
Процесс отображения документа в поисковое пространство называется индексированием.
В системах на основе индексирования исходные документы помещаются в базу без какого-либо дополнительного преобразования, но при этом смысловое содержание каждого документа отображается в некоторое поисковое пространство.
Иначе говоря, каждый документ описывается набором ключевых слов (словосочетаний) – дескрипторов. Этот набор дескрипторов называется поисковым образом документа (ПОД). Для поиска документа пользователь формирует свой набор дескрипторов, формируя поисковый образ запроса (ПОЗ) к базе документов.
Документальная ИС на основе определенных критериев и способов ищет документы, для которых ПОД совпадают или близки ПОЗ, и выдает соответствующие документы (или их адреса – ссылки на них). Соответствие найденных документов запросу пользователя называется релевантностью.
Рисунок 1. Общий принцип функционирования документальных ИПС на основе индексирования
ИНФОРМАЦИОННОЕ ОПОВЕЩЕНИЕ В ДОКУМЕНТАЛЬНЫХ ИС
Еше одна функция документальных ИС – задачи информационного оповещения по всем новым поступающим в систему документам, соответствующим заранее определенным информационным потребностям пользователя. Эти потребности отражаются в поисковое пространство в виде так называемых поисковых профилей пользователей. Информационно-поисковая система по мере поступления и индексирования новых документов сравнивает ПОД с поисковыми профилями пользователей и принимает решение о соответствующем оповещении.
ИНФОРМАЦИОННО-ПОИСКОВЫЕ ЯЗЫКИ
Поиск информации предполагает сравнение смыслового содержания запроса со смысловым содержанием документов. Такая операция возможна только в том случае, когда существует некоторый язык представления информации, позволяющий однозначно описывать смысловое содержание документов и запросов.
Естественный язык для этой цели не подходит в силу своей многозначности и высокой сложности. Таким образом, поисковое пространство, отображающее поисковые образы документов и реализующее механизмы информационного поиска документов так же, как и в СУБД фактографических систем, строится на основе языков документальных баз данных, называемых информационно-поисковыми языками (ИПЯ).
Информационно-поисковый язык представляет собой некоторую формализованную семантическую систему, предназначенную для выражения содержания документа и запросов по поиску необходимых документов. По аналогии с языками баз данных фактографических систем ИПЯ можно разделить на структурную и манипуляционную составляющие.
Поисковое пространство, отображающее ПОД и реализующее механизмы информационного поиска документов, так же, как и в СУБД фактографических систем, строится на основе языков документальных баз данных, называемых информационно-поисковыми языками (ИПЯ). По аналогии с языками баз данных фактографических систем в ИПЯ выделяют структурную и манипуляционную составляющие (в СУБД – языки описания данных и языки манипулирования данными).
КЛАССИФИКАЦИЯ ИПЯ
Структурная составляющая
в семантически-навигационных ИПС – гипертекстовые технологии;
в ИПС на основе индексирования – индексные указатели:
информационно-поисковые каталоги;
тезаурус;
генеральный указатель.
Поисковая (манипуляционная составляющая)
Дескрипторные языки
Семантические языки
предикатные
реляционные
СТРУКТУРНАЯ СОСТАВЛЯЮЩАЯ ИПЯ
Структурная составляющая ИПЯ семантически-навигационных систем реализуется в виде техники смысловых отсылок в текстах документов и специальном навигационном интерфейсе по ним и в настоящее время представлена гипертекстовыми технологиями.
Структурная составляющая ИПЯ документальных ИПС на основе индексирования реализуется индексными указателями в форме информационно-поисковых каталогов, тезаурусов и генеральных указателей.
ИНФОРМАЦИОННО-ПОИСКОВЫЕ КАТАЛОГИ
Информационно-поисковые каталоги представляют собой классификационную систему знаний по определенной предметной области. Смысловое содержание документа в информационно-поисковых каталогах отражается тем или иным классом каталога, а индексирование документов заключается в присвоении каждому документу специального кода (индекса) соответствующего по содержанию класса (классов) каталога и создания на этой основе специального индексного указателя (пример – УДК (универсальная десятичная классификация)).
ТЕЗАУРУС
Тезаурус представляет собой специальным образом организованную совокупность основных лексических единиц (понятий) предметной области и описание семантических отношений между лексическими единицами, не зависящими от контекста. Независимость от контекста обозначает обобщенность (абстрагированность) смысловых отношений, например, отношения «род-вид», «предмет-целое», «субъект-объект-средство-место-время_действия». Так же, как и в информационно-поисковых каталогах, в информационно-поисковое пространство отражается не весь текст документа, а только выраженное средствами тезауруса смысловое содержание документа.
ГЕНЕРАЛЬНЫЙ УКАЗАТЕЛЬ
Генеральный указатель (глобальный словарь-индекс) – представляет собой перечисление всех слов (словоформ), имеющихся в документах хранилища, с указанием (отсылками) координатного местонахождения каждого слова (№ документа - № абзаца - № предложения - № слова). Индексирование нового документа производится через дополнение координатных отсылок тех словоформ генерального указателя, которые присутствуют в новом документе. Так как поисковое пространство в таких системах отражает полностью весь текст документа, то такие системы получили название полнотекстовых ИПС.
ДЕСКРИПТОРНЫЕ ИНФОРМАЦИОННО-ПОИСКОВЫЕ ЯЗЫКИ
Поисковая (манипуляционная) составляющая ИПЯ реализуется дескрипторными и семантическими языками запросов.
В дескрипторных языках документы и запросы представляются наборами некоторых лексических единиц (слов, словосочетаний, терминов) – дескрипторов, не имеющих между собой связей (не имеющих грамматики). Таким образом, каждый документ или запрос представлен некоторым набором дескрипторов (ПОД или ПОЗ). Поиск осуществляется через сопоставление этих наборов.
СЕМАНТИЧЕСКИЕ ИНФОРМАЦИОННО-ПОИСКОВЫЕ ЯЗЫКИ
Семантические языки содержат грамматические и семантические конструкции для описания смыслового содержания документов и запросов.
Семантические языки делятся на две большие группы:
предикатные языки
реляционные языки
ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ ФУНКЦИОНИРОВАНИЯ ДОКУМЕНТАЛЬНЫХ ИПС
Полнота информационного поиска (R).
R=A/C, где А – число найденных документов, соответствующих информационным потребностям пользователя; С – общее число документов в системе, соответствующих информационным потребностям пользователя.
Точность информационного поиска (Р).
P=A/L, где А – число найденных документов, соответствующих информационным потребностям пользователя, L – общее число документов, выданных в ответ на запрос пользователя.
Информационный шум системы.
K= (L-A)/L , где K – коэффициент информационного шума, определяется отношением числа нерелевантных документов (L-A), выданных в ответе пользователю, к общему числу документов L.
В идеале полнота информационного поиска и точность информационного поиска должны приближаться к единице, хотя на практике их значения колеблются в пределах от 60 до 90%.
Конец формы
Понятие пертинентность отражает смысловое соответствие документа информационным потребностям пользователя.
Релевантность — соответствие содержания документа информационному запросу в том виде, как он сформулирован.
Структура ДИПС
В ДИПС входят 4 подсистемы:
Ввод и регистрация;
Обработка;
Хранение;
Поиск.
Подсистема ввода решает следующие вопросы:
создание электронных копий (сканирование, распознавание, ввод с клавиатуры);
подключение к каналам доставки электронных документов (электронная почта и т.д.);
преобразование форматов электронных документов;
присваивание электронным документам уникальных идентификаторов;
синхронизация имен.
Подсистема обработки формирует для каждого документа поисковый образ, который необходим для дальнейшего поиска. Образец хранится в индексе (индекс-таблице). Индекс- это таблица, в строках которой стоят IDдокумента, а в столбцах — информационные признаки, на основе которых строится данный образ документа. Данные, как правило, бинарные. Поскольку таблицы сильно разряжены, то для их хранения обычно используют свертку. Запрос пользователя в системе преобразуется в поисковое предписание (ПП) и передается в систему поиска.
Подсистема хранения содержит исходные документы без изменения. При этом для хранения используют средства сжатия документов и быстрого поиска. Обычно используют доступ по индексу, системы архивации. В подсистему хранения подаются идентификаторы релевантных документов, и она осуществляет их выдачу.
Подсистема поиска осуществляет поиск в индексе тех документов, ПОД которых удовлетворяют ПП, с точки зрения КСС.
АВТОМАТИЗИРОВАННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ ПО ЗАКОНОДАТЕЛЬСТВУ
Автоматизированная информационная система по законодательству (АИСЗ) — это программный комплекс, включающий в себя массив правовой информации и инструменты для работы с ним. Эти инструменты могут позволять производить поиск документов, формировать подборки документов, выводить документы или их фрагменты на печать. Преимущества АИСЗ — доступность информации, и удобство работы с нею. Проблема, присущая таким системам, — недостаточная оперативность — может быть решена с помощью глобальной сети Интернет.
АИСЗ являются частью следующих типов информационных систем:
Справочно-информационные системы общего назначения, ориентированные на доступ пользователей любой профессиональной ориентации к нормативно-правовым актам. К этим системам относятся АИСЗ JURIUS, Консультант, Гарант, Кодекс и др. (Российская Федерация).
Глобальные информационные службы (хост-системы), предоставляющие доступ удаленным пользователям к библиографической, полнотекстовой или другой информации. Крупнейшей в мире коммерческой службой, обеспечивающей доступ к юридической информации, является система LEXIS (США). Начало ее разработки относится к 1967 г., когда было заключено соответствующее соглашение между коллегией адвокатов шт. Огайо и фирмой Mead Data Corp.
Известны другие системы данного типа:
JURIS GmbH (Саарбрюккен, ФРГ), которая предоставляет интерактивный доступ к правовой информации, включающей научную литературу, тексты законов, отчеты о судебной практике, а также пресс-релизы Федерального конституционного суда и других высших федеральных судов;
ITALGIURE/FIND (Италия), WESTLAW (США), и пр.
Системы информационной поддержки деятельности правотворческих органов (законодательные и "конституционные собрания, конгресс, Госдума, сенат и пр.). Спецификой таких систем является необходимость хранения и поиска многих версий и редакций нормативно-правовых документов, с учетом вносимых поправок и изменений.
Системы автоматизации делопроизводства судов, полиции, и других правоприменительных или правоохранительных органов. Необходимо заметить, что в странах с прецендентным правом (США) судопроизводство также может рассматриваться как деятельность во многом правотворческого характера, в связи с чем данные системы интегрируются с приведенными выше (п.З).