Фактографические информационные системы

Тема 9. Фактографические информационные системы

 

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

 

Файловые ИС

 

Исторически первым шагом создания фактографических АИС были файловые системы. С точки зрения прикладной программы файл – это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. По своему содержанию файл ИС является набором записей (records), которые содержат логически связанные данные.  Каждая запись содержит логически связанный набор из одного или нескольких полей (field). Значение поля дает некоторую характеристику моделируемого в ИС объекта.

Для манипулирования файловыми данными используется система управления файлами. Ее основные задачи:

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

 

Ограничения файловых информационных систем

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

Пример. Рассмотрим два отдела в некоторой организации – планово-договорный отдел и склад.

 

Файловая ИС ПДО:

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

Товары(Код товара, Наименование)

Контрагенты(Код контрагента, Наименование, Адрес, Телефон).

…

 

Файловая ИС склада:

Товары Код товара, Наименование)

Получатели(Код получателя, Наименование, Адрес, Телефон).

Отгрузка(Код получателя, Код товара, Количество)

…

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

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

 

Базы данных

 

Перечисленные недостатки являются следствием двух факторов:

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

 

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

 

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

 

Основные черты баз данных:

1. Единый информационный ресурс, обеспечивающий возможность совместного доступа к данным.
2. Все данные собраны вместе и хранятся с минимальной долей избыточности.
3. База данных хранит не только рабочие данные, но и метаданные («данные о данных»).

Определение. Метаданные (meta-data) – это информация, которая описывает информационное наполнение базы данных (сведения о структуре данных,  допустимых значениях, взаимосвязи с другими данными, физическом размещении и т.п.).

4. Независимость между программами и данными (program-data independence). Аналогия с принципом абстрагирования данных (известным из ООП): внутренняя реализация объектов остается закрытой для пользователя и может изменяться без видимых последствий до тех пор, пока не изменится внешнее описание этого объекта.
5. База данных представляет собой информационную модель предметной области.
6. Управление БД осуществляется с использованием специальных программных комплексов – систем управления базами данных (СУБД).

 

Системы управления базами данных

 

Определение. Система управления базами данных (Database management system, DBMS) – это комплекс программного обеспечения, с помощью которого пользователи могут определять, создавать и поддерживать базу данных, а также осуществлять к ней контролируемый доступ.

 

Основные возможности СУБД:

1. Позволяет определять базу данных (вносить метаданные) с использованием специального языка определения данных (ЯОД, DDL – Data Definition Language).
2. Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных путем взаимодействия с БД и прикладными программами пользователя. Для этих целей в СУБД обычно разрабатывается язык манипулирования (управления) данными (ЯМД, ЯУД, DML – Data Manipulation Language), который также называют языком запросов (Query Language).
3. Предоставляет контролируемый доступ к БД с использованием следующих средств:

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

4. Предоставляет администраторам БД доступ к системному каталогу с метаданными.

 

Более подробно все указанные возможности СУБД будут изучаться в курсе «Базы Данных».

 

Модели данных

 

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

 

Определение. Предметная область – это часть реального мира, которая представляется и отображается в ИС.

 

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

 

Мы рассмотрим трехуровневую систему описания БД.

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

 

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

На каждом из указанных уровней строится описание БД в виде модели данных.

Модель данных внешнего уровня – это описание предметной области (или представлений о предметной области) задачи.

К моделям данных концептуального уровня относятся объектные (object-based) модели и модели на основе записей (record-based).

К моделям данных внутреннего уровня относятся физические модели данных.

 

Объектные модели

 

В процессе создания объектной модели разработчик заменяет понятия о предметах, фактах и событиях реального мира на их информационные представления. На сегодняшний день существует свыше 30 разновидностей объектных моделей. Однако наиболее распространенным методом концептуального проектирования считается модель типа «сущность-связь» (ER-модель, Entity-Relationship model).

 

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

 

Дадим следующие определения:

 

Сущность (entity) – это отдельный элемент предметной области (человек, место, вещь или событие), который должен быть представлен в базе данных.

Набор сущностей (entity set) – это множество сущностей одного типа. Пример: люди, предприятия, праздники и т.д.

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

Ключ сущности – это один или несколько атрибутов, однозначно идентифицирующие сущность в наборе сущностей.

Связь (relationship) – некоторое это ассоциативное отношение между сущностями.

Пример: Отдел – Начальник отдела, Родитель-Потомок.

Связь, объединяющая два набора сущностей, называется бинарной связью.

 

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

 

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

 

• Связь один к одному (1 : 1). Сущности с одной ролью всегда соответствует не более одной сущности с другой ролью.

 

Пример: Отдел – Начальник отдела

• Связь один ко многим ( 1 : n ). Сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

 

Пример: Отдел-Сотрудник. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе.

 

• Связь многие ко многим ( m : n ). Каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пример. Для выполнения каждого проекта по контракту в организации создается рабочая группа исполнителей, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями «Сотрудник» и «Рабочая Группа» имеет степень m : n.

1

 

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной).

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