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

ФАКТОГРАФИЧЕСКИЕ  ИНФОРМАЦИОННЫЕ СИСТЕМЫ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                   

 

 

 

 

 

 

 

ОСРОБЕННОСТИ  ПРЕДМЕТНОЙ ОБЛАСТИ, ХОРОШО МОДЕЛИРУЕМОЙ ФАКТОГРАФИЧЕСКОЙ ИНФОРМАЦИЕЙ

 

 

 

При информационном моделировании  на ЭВМ предметная область достаточно просто отображается в компьютерные данные следующим образом:

 

     Предметная область                                  Компьютерная модель

 

1. Параметр (свойство, характеристика)       1. Данное

 

2. Значение параметра                                     2. Значение данного

 

3. Перечень возможных  значений                  3. Классификатор значений параметра  для объектов                          (словарь)

 одного типа

 

4. Группа параметров, описывающих             4. Схема файла

однотипные объекты

с определенной стороны

 

1. Описание множества однотипных          4.1. Файл базы данных

  объектов по этой  группе параметров                

  

4.2 Описание одного объекта по  этой            4.2. Одна либо несколько

группе параметров (значения параметров           записей файла

объекта)                                                                  

    

5. Описание однотипных  объектов                 5. Система файлов предметной области  с различных сторон                (база   данных)

 

6. Описание предметной области в целом       6. Система баз данных

    (все множество  типов объектов)                                                                                                                           

                   

Предметная  область                                  Компьютерная модель

 

                                         

    

Посмотреть на соответствие объектам РМД

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

 В реляционной модели  данных им соответствуют ДОМЕНЫ

 

Система актуализации БД включает две подсистемы:

1. отображения структуры предметной области (ПО) в структуру БД;

· отображения состояния объектов ПО в состояние БД.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                   

 

 

 

 

 1. Отображение структуры предметной области в структуру БД может трактоваться как проектирование БД.

 

 

Процесс проектирования можно представить  в виде трех основных этапов:

 

· формирование концептуальной информационной модели предметной области (КИМПО);

 

· выбор СУБД;

 

· отображение КИМПО в логическую и физическую структуру БД выбранной СУБД.

 

Построение концептуальной  модели самый сложный и трудно формализуемый процесс.  Отсутствуют конструктивные  методики, процесс структуризации по существу является искусством, опирающимся на опыт проектировщика и участие профессионала – работника моделируемой предметной области.  Важнейшая причина такого положения -   недостаточное развитие теории структуризации данных.  Вот уже в течение нескольких десятилетий теория базируется  на понятии: «сущность    - связь»,  формальных базовых отношениях между элементами 1 :1, 1:М, N : M, через которые определяют более сложные линейные,  иерархические и сетевые структуры. В рамках этих формализмов строится концептуальная модель.

 

 

 

Реляционная модель данных (РМД) рассматривает  сложные структуры данных только на концептуальном уровне.  Элементами структуры БД в реляционных СУБД являются простые (нормализованные) таблицы. Поэтому, когда говорят о проектировании БД в РМД то прежде всего имеют ввиду нормализацию отношений, а уже потом установление связей между ними.

Как в иерархической, сетевой, так  и РМД отсутствуют конструктивные методики проектирования концептуальной модели (логической структуры) данных.

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

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

 Такой  подход  назовем ИНТЕГРАЦИОННЫМ, т.к. концептуальная модель строится в результате интеграции анализируемых потребностей.

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

 

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

 

 

 

 

 

 

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

 

 

 

 

 

 

 

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

 

 

Одним из наиболее распространенных подходов к разработке КИМПО является подход, предложенный одним из руководителей корпорации ORACLE  Ричардом Баркером, отвечающим за направления, связанные с развитием CASE-метода, с автоматизированным проектированием систем и с разработкой прикладных программ с помощью СУБД ORACLE . Суть подхода достаточно подробно изложена в работе Фирмы Oracle «CASE Method – Entity Relationship Modelling by Richard Barker», !990 г. Подход основывается на системном анализе предметной области, реализуемым преимущественно посредством интервьюирования  специалистов предметной области и направлен на построение ER-модели (Ehtety-Relantion).

 

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

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 2. Отображение состояния объектов предметной области в состояние БД осуществляется, как правило, в два этапа:

· фиксации значений параметров объектов предметной  области;

· корректировки значений соответствующих данных в БД.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                   

 

 

 

 

 

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

 

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

 

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

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

 

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

 

 

Контроль уровня данного:

· на соответствие типу данного (не цифра в числовом данном, ограничение на число дней и месяцев в данном типа дата, недопустимый код в логическом данном и т.п.);

· на размер значения данного;

· на обязательность наличия значения ( Not Null);

· на допустимый диапазон, в котором должно быть значение (значение данного д.б. больше А и меньше В);

· на наличие в словаре ( в списке), например, оценка м.б. отлично, хорошо, удовлетворительно, не удовлетворительно ;

· использование контрольного разряда.

 

 

 

 

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

 

 

 

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

 

 

 

 

В России используется деление по модулю 11.

Например, имеем весовые коэффициенты .  Тогда числовой код 255 имеет контрольный разряд равный 3 ( 5 ´ 3 + 5 ´ 7  + 2 ´ 4 = 58 остаток от деления на 11 равен 3), т.е. верный код 2553 .

Если при вводе допущено искажение кода, например, 2523, то в  результате расчета получаем контрольный  разряд равный 5 (2 ´ 3 + 5 ´ 7 + 2 ´ 4 = 49, остаток от деления на 11 равен 5), что не совпадает с введенным контрольным разрядом 3.

 

 

 

Естественно ошибка (особенно двойная) может быть такой, что контрольный  разряд ошибочного кода совпадает с  расчетным. Поэтому мы вначале отметили, что при ошибке рассчитанный контрольный  разряд «вероятнее всего не совпадает с введенным контрольным разрядом». Вероятность обнаружения ошибки тем выше, чем выше модуль на который делится сумма произведений разрядов кода на весовые коэффициенты (поэтому в России выбран модуль 11) и чем дальше отстоят друг от друга значения коэффициентов соседних разрядов.

 

 

 

 

 

 

Контроль уровня записи:

· на размер записи;

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

 

Контроль на уровне групп записей:

· контроль по итоговой строке таблицы;

· контроль  на обязательность заполнения строк таблицы.

Межзаписный контроль (уровень БД):

· арифметико-логические выражения (типичны для контроля множества бухгалтерских документов);

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

 

 

 

 

Далее о системе актуализации БД

Типовые процедуры  корректировки БД:

· замена значений данных в некоторых записях;

· удаление записей;

· вставка новых записей.

 

 

Для осуществления замены или удаления

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

 

 

 

 

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