Научная статья на тему 'Автоматизированное формирование объектного словаря реляционной базы данных'

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

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

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — А.А. Завалин, А.А. Зенькович

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

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

The article reviews the questions of practical implementation of the object dictionary creation methods for relational database. The automated method of filling and keeping the up-to-date state of object dictionary, the way of naming the objects and attributes and application that provides reference information for database object presentation form are offered.

Текст научной работы на тему «Автоматизированное формирование объектного словаря реляционной базы данных»

ПРОГРЕСИВН ШФОРМАЦШШ

ТЕХНОЛОГИ

ПРОГРЕССИВНЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

PROGRESSIVE INFORMATION TECHNOLOGIES

УДК 681.3.016:681.324

A.A. Завалин, A.A. Зенькович

АВТОМАТИЗИРОВАННОЕ ФОРМИРОВАНИЕ ОБЪЕКТНОГО СЛОВАРЯ

РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

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

ВВЕДЕНИЕ

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

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

еся для работы с РБД посредством объектного представления и описывающие соответствие между таблицами и объектами, предлагается разместить в объектном словаре данных (ОСД).

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

Перед использованием объектного представления ОСД должен быть инициализирован. Эта процедура выполняется однократно и может выполнена в несколько этапов.

ПОЛУЧЕНИЕ МЕТАДАННЫХ

РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

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

- «Таблица»: название таблицы;

- «Поле таблицы»: название поля; ссылка на таблицу, к которой относится данное поле; тип данных;

- «Связь двух таблиц Т1 и Т->: ссылка на таблицу Т; ссылка на поле - внешний ключ в таблице Т,; ссылка на таблицу Тр ссылка на поле - первичный ключ в таблице Ту.

В приложении метаданные РБД можно получить автоматически, используя:

- прямые запросы к системным каталогам системы управления базами данных (СУБД);

- запросы к виртуальным таблицам, представляющим системные каталоги СУБД, в системной схеме ШРОИМЛТЮ^СИБМЛ, описанной стандарте 80Ь92 [3];

- функции ^БС- или ОББС-драйверов [4].

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

Если применяемая СУБД не предоставляет средств для получения метаданных РБД, то их требуется ввести в ОСД вручную.

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

ФОРМИРОВАНИЕ ОБЪЕКТОВ

Каждый объект соответствует некоторой таблице в РБД. Все объекты подразделяются на два типа [2]: основные - находятся на верхнем уровне иерархии объектов и являются самостоятельными, и вспомогательные -являются составной частью других объектов. Объект включает в себя множество атрибутов, которые подразделяются на две группы: собственные атрибуты, ссылающиеся на поля в таблицах, связанных с объектами, и несобственные атрибуты. Множество несобственных атрибутов, в свою очередь, состоит из атри-бутов-подобъектов и атрибутов-указателей на объекты. Атрибут-подобъект связывает объект, которому он принадлежит, со вспомогательным объектом, включая все его атрибуты в состав объекта. Атрибут-указатель связывает объект, которому он принадлежит, с некоторым основным объектом, при этом поля связанного основного объекта не включаются в состав данного объекта.

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

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

Для описания атрибутов-подобъектов и атрибутов-указателей на объекты в ОСД вводится множество элементов, каждый из которых определяет соотношение между первым и вторым объектом в каждой паре связанных объектов. Алгоритм, который позволяет автоматически установить типы объектов и связи между ними, основан на анализе связей между таблицами и их последовательной «свертке», и изложен в [2].

Для описания объектов и соотношений между ними в ОСД могут быть использованы множества элементов со следующей структурой:

- «Объект»: название объекта; синонимы названия; ссылка на таблицу, соответствующую объекту; тип объекта (основной, вспомогательный); видимость объекта (видимый, скрытый);

- «Атрибут объекта»: название атрибута; синонимы названия; ссылка на объект, которому принадлежит атрибут; тип данных; видимость атрибута (видимый, скрытый);

- «Связь объектов О; и О-»: ссылка на объект О; ссылка на объект О; отношение объекта О 1 к объекту О-(подобъект, указатель на объект).

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

ИМЕНОВАНИЕ ОБЪЕКТОВ И АТРИБУТОВ.

СИНОНИМЫ НАЗВАНИЙ

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

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

128

1607-3274 "Радюелектрошка. 1нформатика. Управл1ння" № 2, 2004

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

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

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

- известно название элемента и его расположение в иерархии объектов;

- известно название элемента и факт его присутствия в объектном представлении, но не его точное расположение;

- точное название элемента, факт его присутствия и расположение в иерархии объектов неизвестны.

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

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

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

ВИДИМОСТЬ ОБЪЕКТОВ И АТРИБУТОВ

Практически в любой РБД в таблицах присутствуют поля, не несущие смысловой нагрузки для пользова-тел ей. К ним относятся: автоматически генерируемые уникальные идентификаторы записей в таблицах, используемые в качестве первичных ключей; ссылающиеся на них внешние ключи, обеспечивающие ссылочную целостность данных; поля, применяемые для отслеживания изменений в других полях и т. п. Атрибуты в объектном представлении, соответствующие таким полям, не предоставляют пользователю значимой информации. Для того, чтобы уменьшить общее количество полей в объектах и тем самым сконцентрировать внимание пользователя на существенных полях, в структуру элемента ОСД, описывающего атрибут объекта, вводится признак видимости, который может принимать значения «видимый» или «скрытый» и определяет, будет отображаться данный атрибут или нет.

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

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

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

ОБНОВЛЕНИЕ ОБЪЕКТНОГО СЛОВАРЯ

ДАННЫХ

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

Для приведения ОСД к актуальному состоянию возможна его повторная инициализация, однако, она приводит к потере данных, введенных администратором РБД (названия объектов, атрибутов, признаки их видимости, синонимы названий), и существенным затратам

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

Возможны следующие варианты практической реализации системы поддержки актуальности объектного представления РБД:

- периодическое сопоставление текущей структуры РБД с метаданными РБД в ОСД;

- отслеживание действий, приводящих к изменениям в структуре РБД.

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

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

Он может быть реализован путем отслеживания в реальном времени успешно выполненных SQL-запросов к РБД, изменяющих ее структуру. К ним относятся запросы на создание, изменение и удаление таблиц и представлений, и запросы, модифицирующие внешние ключи в таблицах: CREATE TABLE (VIEW), DROP TABLE (VIEW), ALTER TABLE. Определить факт выполнения такого запроса можно путем анализа журнала запросов, имеющегося практически во всех СУБД. В случае, если передача запросов на изменение структуры РБД выполняется только через ODBC-драйвер (например, при использовании универсальных приложений для администрирования РБД), то журналирование может быть включено в настройках источника данных, обеспечивающего подключение к модифицируемой РБД. Если в аналогичном случае используется только JDBC-драй-вер, то между приложением и JDBC-драйвером может быть подключен промежуточный драйвер, имеющий тот же программный интерфейс, и выполняющий журнали-рование и передачу запросов JDBC-драйверу.

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

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

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

ЗАКЛЮЧЕНИЕ

Предложенный подход позволяет в автоматизированном режиме сформировать объектный словарь РБД, выполнить процедуру именования объектов и атрибутов и обеспечить поддержку его соответствия текущему состоянию РБД. Он реализован в виде приложения, для разработки которого были выбраны следующие средства: операционная система Linux; СУБД PostgreSQL [5]; язык программирования Java; JDBC-драйвер для доступа к СУБД PostgreSQL из приложений на языке Java [6]. Такой выбор обеспечивает работоспособность приложений, использующих объектное представление РБД, на различных программных и аппаратных платформах и возможность использования других СУБД без необходимости внесения изменений в приложение. Кроме того, все использованные средства распространяются свободно. Приложение позволяет решать следующие задачи: инициализация ОСД; установка названий объектов, атрибутов и синонимов с необходимыми проверками на их уникальность; установка признаков видимости для объектов и атрибутов; визуализация иерархического объектного представления РБД с возможностью поиска нужных элементов по названию с указанием произвольного сочетания из следующих областей поиска: названия объектов, названия атрибутов, синонимы названий.

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

Дальнейшее развитие предложенного подхода возможно в направлении разработки средств автоматизированного формирования объектного представления для распределенных ИС.

ПЕРЕЧЕНЬ ССЫЛОК

1. Завалин A.A., Кунгурцев А.Б., Блажко A.A. Использование словаря данных в информационных системах с логической формой представления данных // Тр. Одес. по-литехн. ун-та. - Одесса, 2002. - Вып. 2 (18).

2. Кунгурцев А.Б., Завалин A.A. Методика формирования объектного представления реляционной базы данных // Тр. Одес. политехн. ун-та. - Одесса, 2004. - Вып. 1 (21).

3. Kreigel A, Trukhnov B. SQL Bible. - Chichester, England: Wiley, 2003. - 858 с.

4. Дунаев С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. - М.: Диалог-МИФИ, 2000. - 416 с.

130

ISSN 1607-3274 "Радюелектрошка. 1нформатика. Управл1ння" № 2, 2004

A.A. Каргин, A. В. Григоръев: НЕЧЕТКИЙ МЕТОД К ИДЕНТИФИКАЦИИ ЧЕЛОВЕКА ПО ФОТОПОРТРЕТУ

5. Гешвинде Э., Шениг Г.-Ю. PostgreSQL. Руководство разработчика и администратора. - СПб.: ООО "ДиаСофт-ЮП", 2002. - 608 с.

6. Хорстманн К., Корнелл Г. Java 2. Библиотека профессионала. Том 2. Тонкости программирования. - М.: Изд. дом "Вильямс", 2002. - 1120 с.

Надшшла 11.1.2003 Шсля доробки 02.04.2004

В cmammi розгля-Hymi питания практичноi реал1зацп методики формування об'ектного словника рeляцiйно'i бази даних. Запропоновано автоматизований cпоciб заповнення та тдтримки aкmyaльноcmi об'ектного словника, mdxid до

iMenyeanHn oô'eêmie ma ampuôymie, a maêox npoipaMa, wo do3eoëne ompuMyeamu doeidiuKoey iHÔopMau,irn no oô'eêm-H0My npedcmaeëeHHrn 6açu damux.

The article reviews the questions of practical implementation of the object dictionary creation methods for relational database. The automated method of filling and keeping the up-to-date state of object dictionary, the way of naming the objects and attributes and application that provides reference information for database object presentation form are offered.

УДК 681.327.12.001.362

A.A. Каргин, A.B. Григорьев

НЕЧЕТКИЙ МЕТОД К ИДЕНТИФИКАЦИИ ЧЕЛОВЕКА

ПО ФОТОПОРТРЕТУ

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

ВВЕДЕНИЕ

Одной из важнейших задач, возникающих в ходе оперативно-розыскной деятельности правоохранительных органов, является быстрая идентификация неизвестных лиц, являющихся организаторами, участниками или свидетелями преступлений; лиц пропавших без вести, а также неопознанных трупов. Из систем криминалистического учета, функционирующих на территории стран СНГ, можно выделить российскую АДИС «Папи-лон» [1] и отечественную систему информационной поддержки ОВД Украины [2]. В рамках данных систем работают соответственно подсистемы «Словесное описание» («Папилон»), «Шзнання» и «1БД», позволяющие проводить поиск неизвестного лица в БД по словесному описанию, и поддерживающие регистрацию в БД фотоизображений, однако, ни в какой из приведенных систем не реализован модуль поиска по фотографии. В данной статье предложено два метода нечеткого автоматизированного поиска неопознанного лица в БД по фотопортрету.

ПОСТАНОВКА ЗАДАЧИ

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

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

МОДЕЛЬ НЕЧЕТКОГО ПРЕДСТАВЛЕНИЯ ФОТОИЗОБРАЖЕНИЯ ЧЕЛОВЕЧЕСКОГО

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

ЛИЦА

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

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

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