WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 47 | 48 || 50 | 51 |   ...   | 54 |

[Гнатиенко, 1999г] Гнатиенко Г.Н., Олейник Г.И. Управление государственными корпоративными правами // Бизнес (бухгалтерия, право, налоги, консультации), 1999, №35, С.112-114.

[Ларичев, 1996] Ларичев О.И., Мошкович Е.М. Качественные методы принятия решений. М.Наука. Физматлит. 1996.

[Гнатиенко, 1999д] Гнатієнко Г.М. Деякі особливості дивідендної політики при управлінні державнимии корпоративними правами // ”Українська Інвестиційна Газета”, 1 червня 1999, №21, NB. Тематичний випуск.

Дивіденди. Нарахування та оподаткування, С.9-10.

[Гнатиенко, 1999е] Гнатієнко Г.М. Нарахування дивідендів при управлінні державним майном // Інформаційний бюлетень “Янус Нерухомість”, 1999, №14, С.12-13.

Информация об авторах Григорий Н. Гнатиенко – Киевский национальный университет им. Т. Шевченко, факультет кибернетики, докторант. Киев, Украина, e-mail: G.Gnatienko@veres.com.ua Николай М. Маляр – Ужгородский национальный университет, математический факультет, декан ИСПОЛЬЗОВАНИЕ МЕТОДОВ МАТЕМАТИЧЕСКОГО МОДЕЛИРОВАНИЯ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ Мария Е. Еремина Аннотация: В работе предлагается подход к описанию БД, позволяющий при работе с ней не учитывать особенности физического хранения реляционных данных и тип управляющей СУБД.

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

Ключевые слова: информационная система, база данных, метаданные, математическая модель, граф.

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

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

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

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

Разработка данного подхода ведется в рамках проекта создания CASE-средства METAS, позволяющего автоматизировать разработку ИС.

Технология METAS CASE-технология METAS (METAdata System) – это основа для создания систем, управляемых метаданными. Данная технология предназначена для снижения трудоемкости разработки корпоративных информационных систем и повышения их гибкости, масштабируемости и адаптируемости в процессе эксплуатации. Ключевым моментом технологии является использование взаимосвязанных метаданных, описывающих информационную систему предприятия (учреждения, организации – любой бизнессистемы) [7].

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

Применение метаданных дает возможность гибкой настройки приложения и его функциональности, а также реструктуризации информационных объектов, описанных метаданными. Это создает хорошие предпосылки для создания «интеллектуальной» системы, которая сможет настраиваться на потребности пользователя и меняющиеся условия эксплуатации «самостоятельно», в ходе работы с ней. Кроме того, при таком подходе проект обладает высокой степенью обратной связи, так как разработчик, меняя метаданные, сразу видит соответствующие изменения в создаваемой ИС. При обычном же подходе, Fourth International Conference I.TECH 2006 реализованном в большинстве других CASE-систем, разработчик сначала описывает систему, затем запускает генерацию, и только после этого может оценить результат внесенных изменений [7].

Все метаданные в системе разделены на модели (или уровни), каждая из которых описывает определенную часть, аспект ИС. Некоторые модели могут описывать одни и те же части ИС, но с различных точек зрения. Все модели взаимосвязанны, одна модель может основываться на другой, и представлять собой более высокоуровневое описание ИС [8].

Данная работа посвящена рассмотрению логическая модели метаданных (ЛМ). Она непосредственно опирается на физическую модель (ФМ), которая описывает все объекты базы данных ИС: таблицы и их поля, связи между таблицами, индексы и многое другое. Подробнее описание ФМ можно найти в [8].

Помимо названных, в системе существуют еще ряд моделей метаданных. Например, презентационная модель описывает визуальный интерфейс пользователя при работе с объектами ИС [6], модель бизнеспроцессов – бизнес-операции и бизнес-процессы, поддерживаемые ИС, модель репортинга описывает запросы, первичные документы и отчеты, формируемые системе, а модель защиты – метаданные, представляющие пользователей системы и их права на выполнение операций над объектами ИС или на доступ к моделям метаданных [8]. В данной работе все эти модели рассматриваться не будут.

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

Первая трудность возникает еще на этапе анализа предметной области и проектировании БД. Основные методы, используемые для этого – различные диаграммы типа «сущность-связь» (ERD – entity-relationship diagrams) или диаграммы классов в языках типа UML. Во всех этих подходах необходимо учитывать специфику реляционной модели данных. Человек, занимающийся анализом и проектированием, должен оперировать информацией на уровне физических таблиц и связей между ними, а также знать основные принципы нормализации реляционных БД. Вместе с тем, он должен достаточно глубоко разбираться в предметной области. Все это предъявляет достаточно серьезные требования к квалификации разработчика.

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

В CASE-системе METAS для преодоления этих трудностей был использован следующий подход. На этапе проектирования по-прежнему строится диаграмма, состоящая из сущностей и связей между ними. Однако здесь сущности уже соответствует не одна, а несколько связанных между собой таблиц БД. Это приближает понятие сущности (как объекта реального мира) к тому, которое мы используем в жизни, что позволяет проектировать в терминах реальной предметной области.

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

Information Systems Для практической реализации изложенного выше подхода был создан компонент «Логическая модель» (ЛМ), который опирается на метаданные логического уровня. Используя этот компонент, все остальные компоненты системы имеют возможность работы с БД не напрямую, а в терминах логического уровня, что значительно облегчает их написание. При этом существует достаточно простая возможность добавления в ЛМ новой функциональности, например, возможность генерации новых видов запросов.

В данной статье мы рассмотрим только основные принципы и понятия, используемые при построении ЛМ.

Более подробное ее описание можно найти, например, в статьях [3,4].

Основные понятия логической модели В ЛМ реально существующие объекты представляются набором характеристик (атрибутов). Эти атрибуты физически могут храниться в разных таблицах ФМ. Поэтому введем некоторую обобщающую логическую конструкцию – сущность – представляющую собой совокупность этих атрибутов.

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

Физический уровень Логический уровень Таблица Таблица “Тип школы” “Школа” Идентификатор Идентификатор Идентификатор типа 1 школы M Номер школы Название типа Номер школы Тип школы Идентификатор типа школы На логическом уровне для данного фрагмента можно выделить сущность «Школа» с атрибутами «Номер» и «Тип школы». При этом «Тип школы» становится таким же атрибутом, как и остальные, с тем только отличием, что для него устанавливается пометка, что его значения выбираются из справочника. Далее сущность сама обеспечивает всю работу с этим справочником прозрачно для пользователя. Таким образом, на физическом уровне каждой сущность соответствует набор таблиц. Одна таблица является главной, остальные связаны с ней соотношением «1:М», то есть являются справочниками для нее.

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

Иногда возникают ситуации, когда необходимо в достаточно сжатом виде представить основную информацию о конкретном реальном объекте некоторой сущности. Например, ситуация, когда две сущности связаны связью «1:М». При этом сущность со стороны М имеет атрибут, представляющий Fourth International Conference I.TECH 2006 родительскую сущность (внешний атрибут). Пусть в сущности «Ученик» есть внешний атрибут «Школа». В нем необходимо представить не всю информацию о школе, где он учится, а только какую-то основную, достаточную для ее идентификации пользователем, например ее номер. Что именно для данной сущности является такой «основной информацией» и определяется ее презентационным выражением.

Для школы это может быть город и номер, для ученика – ФИО и т.д.

Презентационное выражение представляет собой SQL-подобное выражение, в котором могут присутствовать любые атрибуты представляемой сущности. В нем допускается использование стандартных операций и функций, содержащихся в языке SQL. Все встречающиеся атрибуты должны быть записаны в квадратных скобках. Например, для ученика допустимо такое презентационное выражение: [familia]+[imia]+[otchestvo].

Как уже было сказано выше, каждая сущность представляет собой совокупность атрибутов. Атрибуты у сущности бывают нескольких видов.

• Собственный атрибут сущности. Это любой атрибут из главной таблицы.

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

• Внешний атрибут. Если данная сущность связана с другой отношением «М:1», то у нее появится дополнительный атрибут, содержащий информацию об этой связи. Например, в сущности «Ученик» есть внешний атрибут, представляющий родительскую сущность «Школа». Работа с внешними атрибутами аналогична работе с атрибутами справочника, но его значения можно только выбирать, а не изменять или добавлять.

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

Это понятие вводится исключительно для удобства работы.

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

Введем понятие связи между сущностями. Оно является аналогией связей между таблицами, только на логическом уровне, то есть в терминологии предметной области. Например, сущность «Школа» может быть связана с сущностью «Город» связью М:1, определяющей ее местонахождение.

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

• 1:М. В этом случае связь соответствует физической связи «1:М» между главными таблицами сущностей.

• М:М. Данная связь соответствует физической связи «М:М», которая в реляционных СУБД реализуется с помощью промежуточной таблицы.

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

Например, в типе «1:М» возможны следующие подтипы: «1 : 2..3», «0..1 : 0..1», «0..1 : 1» и т.д.

Pages:     | 1 |   ...   | 47 | 48 || 50 | 51 |   ...   | 54 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.