Язык модели данных (ЯМД)
В сообществе разработчиков баз данных проблема создания формального языка, который позволял бы формировать данные и запросы с использованием естественного языка, рассматривается уже давно [2,3]. Предлагаемый язык модели данных (ЯМД) для БД с УМД решает эту проблему.
ЯМД – это внутренний непроцедурный язык описания и манипулирования данными, хранящимися в БД с УМД. Он состоит из двух частей: языка описания (определения) данных и языка управления (манипулирования) данными, хранящимися в БД с УМД.
ЯМД, как любой другой формализованный язык, имеет свой синтаксис и семантику (см. таблица 1).
Основным элементом языка является строка метаописания.
Структура строки метаописания:
{…} {…} … {…},
где информация, заключенная в фигурные скобки {…}
называется элементом строки метаописания.
Строка метаописания включает произвольное число элементов, которые определяют конкретные значения понятий УМД.
Набор понятий, относящихся к разделу, объекту, событию формируется между разделителями косая черта (/).
Последовательность разделителей косая черта (/) между операторами языка <Раздел>,
<КлассО>, <КлассПО>, <ЭкзО> определяет иерархию разделов, классов объектов, классов параметров объектов, экземпляров объектов соответственно.
Элемент предметной области описывается внутри зоны, ограниченной парой косых черт (/…/). Чередование синтаксических выражений языка внутри этой зоны – произвольное.
Знак равно (=) является оператором присвоения, который для указанного понятия определяет его значение, в конце которого ставится обязательный символ точка с запятой (;).
Фактически строки метаописания ЯМД это формализованные предложения естественного языка, которые описывают деятельность предприятия, его основные классификаторы и справочники, а также другие структурированные и неструктурированные документы и прочее.
ЯМД позволяет формализовать описание ПрО и сформировать модель предприятия (его метаданные и данные).
Примеры строки метаописания:
{<Раздел> = Конференция;/
<КлассО> = Компания;<ТипО> = ООО;<ТипО> = ЗАО;<ТипО> = ОАО; <ТипХО>[](строковая,любая,фактическая) = Юридический адрес; <ТипХО>[](строковая,любая,фактическая) = Телефон;/
<КлассО> = Специалист;<ТипО> = -; <ТипХО>[](строковая,любая,фактическая) = Гражданство; <ТипХО>[](строковая,любая,фактическая) = Телефон; <ТипХО>[](строковая,любая,фактическая) = Эл.адрес;/
<КлассО> = Материалы;<ТипО> = -;},
где <ТипХО> [ ] ( , , ) - тип характеристики экземпляра объекта ( <ТипХО> [единица измерения - только для объекта с численной характеристикой] (тип данных: логическая; строковая; численная; дата, признак нахождения данных в справочнике: справочная; любая, тип характеристики: паспортная; фактическая) ).
Данная строка метаописания определяет раздел «Конференция», классы объектов «Компания», «Специалист», «Материалы», их типы «ООО», «ЗАО», «ОАО», «-», иерархии подчиненности классов объектов (класс объектов «Материалы» подчинен классу объектов «Специалист», который в свою очередь подчинен классу объектов самого высшего уровня (без владельцев) - «Компания»), а также типы характеристик объектов «Юридический адрес», «Телефон», «Гражданство», «Эл.адрес» с соответствующими им атрибутами («строковая», «любая», «фактическая»). Исполнение данной строки с помощью приложения, имеющего доступ к БД с УМД, позволит записать все эти метаданные в базу.
{<Раздел> = Конференция; /
<КлассО> = Компания; <ТипО> = ООО ; <ЭкзО> = Dbcreator; <ТипХО>[](строковая,любая,фактическая) = Юридический адрес; <ЗначХО> = г.Харьков,пр.Правды,д.3к.7; <ТипХО>[](строковая,любая,фактическая) = Телефон;<ЗначХО> = (057)3331234;}
Данная строка метаописания определяет экземпляр объекта «Dbcreator» типа «ООО» и класса объектов «Компания», который (экземпляр) входит в состав раздела «Конференция». А также значения типов характеристик объекта «Юридический адрес» и «Телефон».
Исполнение данной строки с помощью приложения, имеющего доступ к БД с УМД, позволит записать все эти данные в базу.
С помощью ЯМД можно манипулировать данными реляционной БД подобно языку SQL-запросов, но в собственной терминологии, не привязанной к структуре данных (ЯМД не требует знания модели данных) и, не прибегая к контекстному поиску. При этом ЯМД прост в освоении и понятен не только программистам, но и специалистам предметной области.
Для получения списков классов объектов, событий, их экземпляров, типов, характеристик, значений и т.д. в синтаксисе языка предусмотрены некоторые специальные выражения, так называемые маски: «*.*»,«*.**», «*.*?», в операторе присваивания.
Операторы ЯМД используются также:
при реализации механизма распределения прав доступа к данным (вплоть до любого конкретного элемента данных);
при создании отчетных документов, которые могут формироваться, как с помощью OLAP-технологии, так и с помощью иных средств, и в некоторых других случаях.
Документальная и программная поддержка ЯМД включает:
описание синтаксиса языка;
интерпретатор языка для СУБД Oracle (реализован на языке PL/SQL);
описание интерфейса доступа к стандартным процедурам интерпретатора языка;
средства формирования строк метаописания элементов данных;
методику составления строк метаописания для записи новых данных или проведения конвертации данных из БД других информационных систем, построенных на различных платформах (таких как Oracle, PostgreSQL, Access, Lotus Notes), в БД с УМД;
программу конвертации данных.
Определения
Данные - информация, обработанная и представленная в формализованном виде для дальнейшей обработки.
Информация - сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком.
Информационная система - система, предназначенная для хранения, обработки, поиска, распространения, передачи и предоставления информации.
Класс - совокупность однородных элементов, обладающих каким-либо определенным качеством, свойством, отношением.
Модель - вспомогательный объект (или система), повторяющий свойства моделируемого объекта (прототипа), существенные для целей моделирования, и опускающий несущественные свойства, в которых он может отличаться от прототипа.
Модель данных – это набор понятий, которые могут быть использованы для описания множества данных, операций с данными, а также набора ограничений целостности данных. Модель данных - это средство абстракции.
Понятие – смысловое обобщение некоторой совокупности элементов, предметов, пр.
Предмет - все, что представляется ощущениям, обладает свойством и определяется именем, синоним «объект».
Предметная область - некоторая часть элементов реального мира, данные о которых используются информационной системой. Содержит данные, необходимые для формирования определенных знаний.
Событие - любой факт или действие, которое происходит с поименованным объектом в определенный интервал времени (идентифицируется объектом и временем).
Схема базы данных – это описание структуры базы данных, со всеми ее элементами, связями, с указанием необходимых ограничений поддержки целостности данных.
Универсальная модель данных (УМД) – это неизменная (стандартная) для разных предметных областей (ПрО) схема БД в реляционной СУБД. Для УМД определен перечень понятий, которые могут быть использованы для описания множества данных, операций с данными, а также набора ограничений целостности данных.
Программный инструментарий формирования модели предприятия
Программный инструментарий предназначен для формирования модели предприятия путем исполнения операторов (строк метаописаний) ЯМД.
Состав программного инструментария формирования модели предприятия:
программный интерфейс доступа к интерпретатору ЯМД;
специальные приложения, позволяющие осуществлять просмотр, модификацию, удаление имеющихся, а также запись новых данных в БД с УМД;
программа конвертации данных из БД других информационных систем, построенных на различных платформах (таких как Oracle, PostgreSQL, Access, Lotus Notes), в БД с УМД;
методики использования вышеперечисленных комплексов программ.
Программный инструментарий разработан в средах BorlandDelphi, Borland C.
Вид некоторых приложений приведен на рис.3,4,5,6,7.
Рис.3 Программа - просмотрщик
Рис.4 Программа конвертации данных
Рис.5 Программа работы с документами
Рис.6 Программа формирования данных
Рис.7 Программа персонализации доступа к данным и работы с данными
Этапы технологии проектирования модели предприятия
Выделение компонентов предприятия, значимых для управления и бизнеса.
Описание предметной области предприятия.
Формализация описанной предметной области предприятия средствами ЯМД.
Загрузка модели предприятия реальными данными путем исполнения строк метаописаний (операторов) ЯМД специальным программным инструментарием.
Просмотр специальной программой реальных данных, представленных в виде связанного иерархического дерева объектов и событий, и их сопоставление с существующими представлениями экспертов предприятия и проектировщиков модели предприятия.
Данные модели предприятия отображаются в виде иерархического дерева. Это дерево является простым и понятным представлением классов объектов и событий, их иерархий, наборов характеристик, имеющихся значений имен, характеристик и их значений и т.д. (рис.3). В технологии присутствует набор стандартных видов представлений, а также средства их расширения и модификации. По результатам таких представлений выявляются несоответствия между реальным предприятием и моделью предприятия. После чего проводятся изменения в модели. В результате нескольких итераций проектируется модель предприятия, адекватная целям предприятия и удовлетворяющая потребностям заказчика.
Проведение корректировок по перечисленным этапам.
Технология проектирования модели предприятия на основе универсальной модели данных
Понятие | Определение (семантика) | Чем определяется | Назначение (для чего используется) | Синтаксис языка | Значение | ||||||
Раздел | Некоторая выделенная и поименованная часть предметной области. | Именем | Описание раздела проекта или организационной структуры описываемой ПрО | <Раздел> | Имя* | ||||||
Владелец раздела | Раздел, которому принадлежит рассматриваемый | Связью с разделом | Описание иерархии разделов | <Раздел> | Имя* | ||||||
Класс объекта | Совокупность предметов (экземпляров объектов), выделенных по какому-либо принципу и идентифицируемая общим названием. | Именем | Описание совокупности объектов ПРО, которые описываются одинаковыми наборами признаков. | <КлассО> | Имя* | ||||||
Владелец класса объектов | Класс объектов, которому может принадлежать рассматриваемый класс. | Связью с классом объекта | Описание иерархии классов объектов | <КлассО> | Имя* | ||||||
Объект (экземпляр объекта) | Все, что представляется ощущениям, обладает свойством. (Идентифицируется именем, описывается именем существительным и принадлежит некоторому классу объектов.) | Именем | Описание конкретного объекта ПРО | <ЭкзО> <ЭкзДО> | Имя* | ||||||
Владелец объекта | Объект, которому принадлежит рассматриваемый объект. | Связью с объектом | Описание иерархии каждого объекта | <ЭкзО> | Имя* | ||||||
Тип объекта | Некоторая совокупность схожих по нескольким значительным качественным признакам экземпляров объектов. | Именем | Описание видов и типов оборудования, устройств и прочих средств ПРО | <ТипО> | Имя* | ||||||
Характеристика объекта (фактическая) | Один поименованный признак (качество) из всей совокупности признаков, описывающих экземпляр объекта определенного класса. | Именем | Описание характеризующего признака экземпляра объекта определенного класса | <ТипХО> | Имя* | ||||||
Значение характеристики объекта | Значение, присвоенное характеристике конкретного экземпляра объекта | Присвоенным значением | Присвоение конкретного значения характеристике объекта | <ЗначХО> | Значение* | ||||||
Паспортная характеристика объекта | Один поименованный признак (качество) из всей совокупности признаков описывающих названый тип объекта определенного класса | Именем | Описание характеризующего признака для однотипного оборудования, устройств и прочих средств ПРО | <ТипХО> | Имя* | ||||||
Значение паспортной характеристики объекта | Значение присвоенное паспортной характеристике объекта определенного типа | Присвоенным значением | Присвоение конкретного значения паспортной характеристике объекта | <ЗначХО> | Значение* | ||||||
Класс события | Совокупность событий (экземпляров событий), выделенных по какому-либо принципу, которые могут происходить с объектами определенного класса, и идентифицируемая общим названием. | Именем | Описание совокупности событий ПРО, которые описываются одинаковыми наборами признаков | <КлассС> | Имя* | ||||||
Владелец класса событий | Класс событий, которому может принадлежать рассматриваемый класс. | Связью с классом событий | Описание иерархии классов событий | <КлассС> <КлассСВл> | Имя* | ||||||
Событие (экземпляр события) | Любой факт или действие, которое происходит с поименованным объектом в определенный момент или интервал времени. (Идентифицируется временем и объектом, принадлежит некоторому классу событий.) С одним объектом в одно и тоже время может происходить только одно событие конкретного класса. | Объектом, временем (интервалом времени) | Описание события которое произошло с объектом и в конкретный момент (интервал) времени | <ВремяНС> <ВремяКС> | Значение* | ||||||
Владелец события (экземпляра события) | Событие, которому принадлежит рассматриваемое событие. | Связью с событием | Описание иерархии каждого события | <ВремяНС> <ВремяКС> | Значение* | ||||||
Характеристика события | Один поименованный признак из всей совокупности признаков описывающих событие определенного класса. | Именем | Описание характеризирующего признака события определенного класса | <ТипХС> | Имя* | ||||||
Значение характеристики события | Значение присвоенное характеристике события конкретного экземпляра события, которое произошло с конкретным экземпляром объекта. | Присвоенным значением | Присвоение конкретного значения характеристике события, которое произошло с определенным объектом | <ЗначХС> | Значение* | ||||||
Класс параметров объектов | Совокупность параметров, выделенных по какому-либо принципу и идентифицируемых общим названием. | Именем | Описание совокупности характеристик параметров оборудования, устройств и прочих средств ПРО. | <КлассПО> | Имя* | ||||||
Характеристика параметра объекта | Изменяемый во времени один поименованный признак (качество) из всей совокупности признаков, описывающих экземпляр объекта определенного класса. | Именем | Описание характеристики параметра оборудования, устройств и прочих средств ПРО | <ТипХПО> | Имя* | ||||||
Тип значения параметра объекта | Один поименованный признак (качество) из всей совокупности признаков, позволяющий различать некоторые одинаковые по названию, но разные по существу характеристики параметров объектов | Именем | Описание разновидности значения характеристики параметра оборудования, устройства, прочих средств (например, давление: внутреннее, внешнее) | <ТипЗнХПО> | Имя* | ||||||
Значение характеристики параметра объекта | Значение характеристики параметра и типа значения параметра для конкретного экземпляра объекта в заданное время | Присвоенным значением | Присвоение конкретного значения характеристике параметра объекта для заданного типа значения параметра объекта | <ЗначХПО> | Значение* | ||||||
Время параметра объекта | Значение времени, в которое произошло измерение установленного значения параметра объекта. | Значением момента времени | Определение моментов времени значений характеристик параметров объектов | <ВремяПО> | Значение* | ||||||
Единица измерения | Система измерения физической величины | Именем | Описание единицы измерения конкретного значения | [ ] | Имя* |
Имя* - любой идентификатор, не совпадающий по написанию с понятиями языка;
Значение* - любой допустимый идентификатор соответствующего типа данных (логический, строковый, дата, числовой).
Универсальная модель данных (УМД)
Существующие традиционные технологии проектирования ИС ориентированы на проектирование БД для одной конкретной предметной области. Такой подход не позволяет тиражировать модель данных на разные предметные области, не обеспечивает простое расширение состава информации в БД и не способствует использованию устоявшихся решений. Повышение надежности решений по проектированию БД и сокращению затрат на их создание и развитие возможно при стандартизации модели данных, что не раз обсуждалась на международных симпозиумах сообщества баз данных [1,2,3].
Предлагаемая универсальная модель данных представляет собой неизменную (стандартную) для разных наборов данных схему БД в реляционной СУБД. Универсальной модель данных названа потому, что ее структура не зависит от набора данных. Это позволяет БД с УМД использовать для разных проблемных областей (ПрО) с любыми составами данных.
УМД удовлетворяет основным требованиям, предъявляемым к моделям данных [4]:
структурная достоверность;
простота;
отсутствие избыточности;
способностью к совместному использованию;
расширяемость;
целостность;
представление в виде понятных обозначений.
Для УМД определен перечень понятий (таблица 1), на основе которых спроектирован набор таблиц реляционной БД. Заранее не ограниченное разнообразие элементов ПрО распределяется по перечисленным понятиям и формируется в фиксированном наборе таблиц [5]. Элемент ПрО относится к одному из понятий и определяется именем, местом в некоторой иерархии, величиной и/или временем. Используемыми понятиями можно описать любую совокупность компонентов предприятия с их качествами, возможными событиями и другими подробностями.
При расширении набора компонентов предприятия или их описаний, которые необходимо включить в БД предприятия, не требуются проводить изменения УМД, функционирующих приложениях и их нового тестирования. Что позволяет определять состав данных, включаемых в БД, по мере необходимости. Это очень важное преимущество по отношению к традиционному подходу, который при добавлении нового отношения (таблицы), или атрибута (столбца), требует пересмотра связей в схеме БД и изменения функционирующих приложений.
Отличительные особенности универсальной модели данных:
использование фиксированного набора таблиц (отношений);
описание предметной области иерархиями реальных объектов и событий, в отличие от традиционного описания ПрО моделью «сущность-связь»;
наличие связей между любыми классами, экземплярами и другими понятиями;
наличие данных об экземплярах компонентов, как они между собой связаны и что с ними произошло;
расширение набора данных БД добавляет только новые записи в существующие таблицы и не требует изменения состава таблиц и полей, как это предполагает традиционное проектирование БД.
Схема БД с УМД, реализованная в реляционных СУБД Oracle и PostgreSQL, представляет собой:
стандартный набор таблиц БД (основные из них приведены на рис.2);
триггеры;
серверные процедуры и функции;
иные технологические компоненты.
Система триггеров и серверных процедур УМД обеспечивает целостность:
иерархий классов объектов и событий;
иерархий экземпляров объектов и событий;
имен объектов и событий в классах;
имен характеристик объектов и событий;
связей;
типов объектов;
допустимых значений и значений по умолчанию и т.д.
Серверные процедуры и функции обеспечивают манипулирование данными и участвуют в распределении прав доступа к данным (вплоть до элемента данных).
УМД позволяет использовать одну модель БД для всего предприятия и помещать в нее информацию из разных ПрО и наследуемых приложений, что минимизирует ресурсы на системное сопровождение СУБД.
УМД обеспечивает семантическую и синтаксическую интеграцию разнообразной информации [5,6,7]. В этом случае БД с УМД можно использовать в качестве хранилища (витрины) данных, обеспечивая возможности по получению обобщенной информации, необходимой для стратегического планирования.
Рис. 2. Таблицы БД с УМД
в схеме реляционной базы данных
Цель технологии: построение модели предприятия в схеме реляционной базы данных с универсальной моделью данных, как основы информационной системы (ИС).
Основные решения, используемые в технологии:
универсальная модель данных (УМД);
язык модели данных (ЯМД);
программный инструментарий формирования модели предприятия.
Модель предприятия включает представления элементов предприятия, их взаимоотношения, связи, условия функционирования и т.д., описанные набором понятий УМД: «объект», «событие», «характеристика объекта», «характеристика события».
Модель предприятия строится на основе описаний предметных областей, выполненных сотрудниками предприятия, и их формализации специалистами информационных технологий на языке модели данных.
Модель предприятия формируется при помощи специального программного инструментария, осуществляющего ее загрузку в базу данных (БД), имеющую структуру универсальной модели данных.
Модель предприятия с необходимой для ИС степенью подробности фиксирует состав компонентов предприятия, определяет их иерархии и связи, формирует классификации и справочники, устанавливает агрегации и размерности для аналитической отчетности.
Модель предприятия позволяет:
интегрировать функционирующие на предприятии информационные системы и организовать их взаимодействия с вновь разрабатываемыми;
хранить значительные объемы данных и обеспечивает оперативный доступ к ним;
выполнять согласование, очистку данных и строить многомерную модель данных, необходимую для формирования аналитической отчетности, в том числе и с помощью OLAP-технологии.
Структура данных модели предприятия и служебные программы, которые обеспечивают ее функционирование, не зависят от предприятия. Что обеспечивает переносимость модели предприятия из проекта в проект, и не требует разработки каждый раз новой схемы БД и программ, которые взаимодействуют с этой БД.При этом содержимое модели предприятия открыто для расширения на любом этапе внедрения, развертывания, функционирования и развития.
Использование модели предприятия обеспечивает создание ИС в сжатые сроки и минимизирует ресурсы, необходимые на разработку, сопровождение и развитие.
Рис. 1. Проектирование модели предприятия
достаточно просто описать на специальном
Технология позволяет:
достаточно просто описать на специальном формальном языке, терминами понятными как руководителям различных звеньев управления (менеджерам), так и специалистам информационных технологий, модель предприятия;
легко адаптировать модель предприятия к требованиям конкретного предприятия;
хранить данные модели предприятия в объектно-событийном виде в реляционной СУБД;
манипулировать данными в терминах объектов и событий;
по мере необходимости добавлять в эксплуатируемую модель предприятия новые виды данных, в том числе новые иерархии и взаимодействия, без переформирования БД, изменения ее модели данных и программ доступа к данным;
разнести во времени и распределить между разработчиками проектирование БД и приложений пользователя. При этом вне зависимости от того, кто проектировал базу данных, пользователям предоставляется возможность самостоятельно расширять состав данных БД и разрабатывать собственные;
обеспечить хранение в единой БД связанных данных различных словарей, классификаторов, общетехнических нормативов, государственных и отраслевых стандартов, а также электронных карт, чертежей, схем оборудования и прочих мультимедийных документов;
использовать модель предприятия для интеграции наследуемых данных и приложений, для которых не следует изменять стереотипы пользователей.