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

Системный подход к построению модели данных эволюционных баз данных Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
201
61
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Системный подход к построению модели данных эволюционных баз данных»

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

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

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

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

В ИАС ОГУ реализован обмен информационными ресурсами с внешними организациями. В 2004 году ОГУ наряду с другими 14 вузами России принял участие в апробации Единой системы конкурсного приема. Ежегодно на основе БД ИАС формируются данные для Национального аккредитацион-ного агентства в сфере образования о дипломах, выданных вузом.

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

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

Процессы, сопутствующие развитию регионального университетского комплекса «Оренбургский государственный университет» требуют интеграции информационных ресурсов структурных единиц, входящих в состав ОГУ, и, соответственно, возникает необходимость внедрения ряда подсистем ИАС в филиалах и колледжах университета, разобщенных территориально. Для реализации внедрения рассматриваются разные технологии. Первоначально реализован вариант внедрения подсистем ИАС на основе распределенных БД. Для каждого филиала создан сервера БД Oracle, программное обеспечение ИАС выделено в отдельный блок.

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

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

СИСТЕМНЫЙ ПОДХОД К ПОСТРОЕНИЮ МОДЕЛИ ДАННЫХ ЭВОЛЮЦИОННЫХ БАЗ ДАННЫХ

В.В. Дрождин, к.т.н. (Пенза)

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

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

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

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

Использование СЛ8Е-средств на этапе проектирования, стандартизации интерфейса между подсистемами, многоплатформенной реализации, вычислительных средств большой мощности и компьютерных сетей, а также поэтапной разработки и внедрения систем позволяют создавать более сложные АИС, но не дают возможности принципиально решить проблемы создания и функционирования больших АИС с распределенными БД.

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

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

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

Основные принципы организации ЭБД:

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

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

Модель данных - это совокупность допустимых структур данных и операций над ними.

Структура данных - это взаимосвязанная совокупность элементов данных.

Построение модели данных будем осуществлять на основе общей теории систем, разработанной Ю.А. Урманцевым (см. работы: Ю.А. Урманцев. Эволюционика. Пущино. 1988, а также «Система, симметрия, гармония». М. 1988).

Объект-система (OS) - это композиция, или единство элементов m с MOS, построенная по отношениям (взаимодействиям) г с ROS и ограничивающим их условиям или законам композиции z с ZOS. Поэтому в общем виде OS представляется тройкой: S=<m,г,z>.

Система объектов одного и того же i рода (К-система, или RS) - это закономерное множество OS одного и того же качества (рода означающая, что каждая OS построена:

- из всех или части элементов т с М1, выделенных из универсума и (М1 с и) по основаниям а с А1;

- в соответствии со всеми или частью отношений гсК1;

- в соответствии со всеми законами композиции (или их частью) zсZ1.

Поэтому RS представляется четверкой вида:

к^ид^к1,^.

Любой объект есть OS и каждая OS принадлежит хотя бы одной RS.

Далее будем считать, что каждая OS разрабатываемой модели строится на основе всех отношений К1, удовлетворяет всем законам композиции Z1 и принадлежит строго одной RS. Поэтому модель OS будет иметь вид: S=<m,R1,Z1>, а в случае известной RS: S=<m>.

Введем обозначения, более привычные в программировании и теории БД: Т=и,уа1=т, F1=R1, Р^1, УАЬ1=<Т,А1>=М1, где Т - множество допустимых типов данных; F - зависимости между данными (ассоциации, отображения, классификации, многозначные, функциональные и др.), причем наиболее сильными (логическими) являются функциональные и многозначные зависимости, а наиболее слабыми - ассоциации, позволяющие ассоциировать между собой произвольные данные; Р - предикат, задающий ограничения целостности на данные; УАЬ1 - множество элементов, составляющих RS.

Тогда модели OS и RS будут иметь вид: S1=<va11, F1, Р1> или S1=<va11>, R1=<VAL1,F1,P1>.

Будем считать R-системой 0-го рода любой абстрактный тип данных (см.: М. Нагао, Т. Катая-ма, С. Уэмура. Структуры и базы данных. М. 1986) с атомарными значениями данных, представленный в виде: Т={^}, @ё), где g - имя типа; -

множество атомарных элементов данных типа g;

©g - множество операций, выполняемых над элементами данных типа g.

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

Тогда OS и RS 0-го рода, реализующие тип данных g, будут иметь вид: S0=<val0>, R0= =<VAL0>, где A0=g; VAL0=Dg; val0eVAL0; F°=0; P0=0.

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

Для эффективного представления, обработки и организации взаимодействия OS введем абстрактный элемент id следующим образом: id=val.

Элемент id будем называть идентификатором и считать, что он не зависит от типа и структуры val и принадлежит некоторому универсальному числовому типу.

Тогда модели OS и RS примут вид: S=<id,vali, Fi,Pi> или S=<id,vali>, R=<ID,VALi,Fi,Pi>.

Назовем R-системой 1-го рода упорядоченное множество атомарных элементов val и эквивалентных им идентификаторов id: S1=<id, val1>, R1=<ID, VAL1, P1>, где A1 = gR - имя системы объектов R0, объекты S0 которой преобразуются в val1; VAL1cVAL0; val1eVAL1; F1=0; P1= ={ Ppi I в1 e <ограничения на атомарные данные^ - ограничения, определяющие допустимое разнообразие объектов S1 в системе объектов R1.

Примерами R-систем 1-го рода являются домены реляционной модели данных: списки фамилий, имен, отчеств, дат рождения.

На i уровне решаются задачи эффективного представления, хранения и доступа к объектам S1 в системе объектов R1.

Следующие, более высокие уровни организации систем будут содержать сложные элементы val, структура которых будет задаваться набором отношений (устойчивых связей, взаимосвязей) F между компонентами val'е val и ограничениями целостности P. При этом уровень системы будет определяться мощностью взаимосвязей (обязательностью участия в них компонентов val' , допустимой степенью нарушений - количеством исключений, частотой совместного использования и обработки компонентов val') и допустимой степенью разнообразия val. Уровень системы будет тем ниже, чем выше мощность связей между компонентами val' и ниже степень разнообразия val.

Будем называть R-системой 2-го рода упорядоченное множество объектов S2, существующих во времени T, в каждом из которых компоненты val' е val2 жестко взаимодействуют между собой: S2=<id,val2,t„,tK>, R2=<ID,VAL2, F2,P2,T>, где A2=[gR1,gR2,...,gRn] - последовательность имен систем объектов R1, из объектов S1 которых фор-

мируется элемент val2; VAL2c VAL1^ х xVAL1, х-х VAL1,, ; val2e VAL2; F2={f 21 a2e

gR2 gRn 1 a2 '

<зависимости между элементами данных во всех val2>} - отношения (взаимосвязи) между данными типа функциональных и многозначных зависимостей, определяющие необходимое подобие всех объектов S2 в системе объектов R2; P2 = {Pp21 в2е <ограничения на сложные данные>} -

ограничения, определяющие допустимое разнообразие объектов S2 в системе объектов R2; T={t} -физическое время; t^t^T - начальный и конечный моменты времени, задающие интервал времени существования объекта S2.

Примерами R-систем 2-го рода являются отношения реляционной БД: человек (фамилия, имя, отчество, дата рождения, номер паспорта, адрес), предприятие (название, адрес, руководитель, телефон руководителя).

На 2 уровне решаются задачи эффективного выявления и поддержки отношений между данными, представления и обработки исключений, поддержки схемы данных в оптимальной форме, а также ведение динамической информационной модели предметной области с предысторией. При этом для темпоральных данных целесообразно создавать подсистемы R2' вида: S2'=<id,val2',t>, R2'=<ID,VAL2',T>, где val2'eVAL2' - значение компоненты в некоторый момент времени; teT -начальный момент времени существования компонента val2' в S2.

Будем называть R-системой 3-го рода упорядоченное множество объектов S3, каждый из которых представляет собой совокупность объектов S2 и S3', в подавляющем случае обрабатываемых и используемых совместно: S^^djval3,^,^, R3=<ID,VAL3,F3,P3,T>, где A3=[gRbgR2,...,gRn] -последовательность имен систем объектов R2 и R3', из объектов S2 и S3' которых формируется элемент val3; VAL3c VAL^ xVALgR2 х- ••xVALgR;

val3e VAL3; S3' - это объект уже существующей R3', который включается в val3 в качестве компонента; F3={f 31 а3е<взаимосвязи компонентов

i a3 1

val и val во всех val >} - отношения, определяющие совместную обработку (возможные конфигурации) объектов S2 и S3' и задающие необходимое подобие всех объектов S3 в системе объектов R ; P ={ Pp3 | ве <ограничения на совместную обработку объектов>} - ограничения на отсутствие и форму объектов S2 и S3', определяющие допустимое разнообразие объектов S3 в системе объектов R3; T={t} - физическое время; t^eT -начальный и конечный моменты времени, задающие интервал времени существования объекта S3.

Примерами R-систем 3-го рода являются, например, ФИО и адрес в отношении человек или

сотрудник и студент, являющиеся наследниками человека.

Таким образом, R-система 3-го рода позволяет, с одной стороны, декомпозировать существующие системы объектов 2 и 3 рода на более мелкие системы, но с более сильно связанными элементами, а с другой - формировать из существующих систем 2 и 3 рода более крупные при усилении связей между элементами этих систем.

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

Будем называть R-системой 4-го рода единственный объект S4, представляющий собой взаимосвязанную совокупность объектов S2 и S3 и существующий автономно: S4=<val4,tH,tK>, R3= =<VAL4,F4,P4,T>, где A4=[gRi,gR2,...,gRn] - последовательность имен систем объектов R2 и R3, из объектов S2 и S3 которых формируется элемент val4; VAL4c VALgRi xVALjL x-xVALgj val4eVAL4;

F4={ f 4 | а4е<взаимосвязи компонентов val2 и

а 4

val3 в val4>} - отношения, определяющие автономную совокупность объектов S2 и S3 и формирующие целостный объект S4, являющийся единственным представителем системы объектов R4;

Р4={Рр4 | р4е <ограничения на автономность

объекта>} - ограничения на необходимость, объем и интенсивность обработки объектов S2 и S3, определяющие существование объекта S4, представляющего систему объектов R4; Т=М - физическое время; 1;н,1;кеТ - начальный и конечный моменты времени, задающие интервал времени существования объекта S4.

Примерами R-систем 4-го рода являются автономные подсистемы больших систем, или самостоятельные автоматизированные системы.

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

На 4 уровне решаются задачи эффективного выявления и поддержки отношений автономности объекта и предоставления эффективного интерфейса взаимодействия с внешней средой.

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

ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

О.В. Петриева (Санкт-Петербург)

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

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

Предварительное проектирование включает три типа деятельности: структурирование системы, моделирование управления, декомпозиция подсистем на модули.

Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульного соединения.

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

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

Требования

Архитектура

программ и _

Предварительное 1 данные Детальное

' проектирование * проектирование

Структуры данных и алгоритмы

■ программ ♦

Интерфейсное проектирование (создание GUI)

Характеристики, формы человеко-машинного интерфейса

Рис. 1. Информационные связи процесса _проектирования_

i Надоели баннеры? Вы всегда можете отключить рекламу.