CC BY
8
ности. Один из возможных форматов представления такой классификации - MuSCoW. Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.
6. Выводы
В работе выделены основные проблемы, возникающие на стадии подготовки макетов в редакционно-
издательской деятельности. Рассмотрены существующие системы управления допечатной подготовкой многостраничных изданий, определены их достоинства и недостатки.
Для типового проектирования подобной системы для конкретного предприятия проведен анализ деятельности предприятия, указаны необходимые требования для проектируемого макета системы управления совместной работой над издательскими проектами и установлен перечень планируемых функций системы, проведена их классификация по степени важности.
Литература
1. Раттан К. Кроссмедийные системы в полиграфии и издательском деле. Выбор стратегии [Текст] / Кевин Раттан. - М.: МГУП,
2007г. - 198с.
2. Фрэнк Романо, Ф. Современные технологии в издательско-поли-графической отрасли [Текст] / пер. с англ. М. Бредис, В. Во-
бленко, Н. Друзьева; под ред. Б.А. Кузьмина. - М.: Принт-Медиа центр, 2006. - 456 с.
3. Гехман Ч. Рабочий поток. Практическое руководство [Текст] / Чак Гехман. - М.: МГУП, 2004 г. - 256 стр.
4. Грекул В.И. Проектирование информационных систем: курс лекций: учеб пособ. для вузов [Текст] / В. И. Грекул, Г. Н. Дени-
шенко, Н. Л. Коровкина. - М.: Интернет-Ун-т Информтехнологий, 2005. - 304 с.
Розглянуто необхдтсть пошуку тформацп у базах даних, та як це виконуеть-ся у класичному випадку реляцшних баз даних. Наведено гiдностi й недолши кла-сичного тдходу. Запропоновано алгоритм пошуку тформацп на основi семантичног тформацп
Ключовi слова: система пошуку тформацп, база даних, запит
□-□
Рассмотрена необходимость поиска информации в базах данных, и то как это осуществляется в случае классической реля -ционной базы данных. Приведены достоинства и недостатки классического подхода. Предложен алгоритм поиска информации на основе семантических данных
Ключевые слова: система поиска информации, база данных, запрос
□-□
The necessity of the information retrieval from the databases and how it is implemented in case of relational databases is reviewed in the article. The value and limitations of the classical approach are given. The algorithm of the information retrieval that is based on the sema-tic data is proposed
Keywords: information retrieval, database, query
УДК 004.652
ПОШУК ШФОРМАЦП У СЕМАНТИЧН1Й БАЗ1 ДАННИХ ДОКУМЕНТ1В З Р1ЗНОМАН1ТНИМ РЕКВ1ЗИТНИМ ЗМ1СТОМ
С.С. Забара
Доктор техычних наук, професор, завщувач кафедри Контактний тел.: 096-990-89-38 E-mail: symanyshyn_lesja@mail.ru
I. В. I з в а р i н
Астрант*
*Кафедра шформацшних технолопй та
програмування
1нститут комп'ютерних технолопй Вщкритого мiжнародного ушверситету розвитку людини
«УкраТна»
вул. Львiвська, 23, м. КиТв, 03115
Головна мета будь-яко1 бази даних, та СУБД в рамках яко1 така база даних icHye, це зберпання тформацп, та надання ü за вимогами користувача [1,4]. Вимоги
користувача щодо надання потрiбноi тформацп дуже важко характеризувати, та формалiзyвати. Розгляне-мо такий гшотетичний приклад вимог користувача:
«Знайти Bei документi, що мають шформащю про банк «Банк Кшру», який а) знаходиться у MiCTi Кшв, та б) операцii з банком проводилися у 2010 рощ. Вся знайдена шформащя повинна також мати перелж товарiв та послуг яю були наданi згiдно операцiй з банком, та назви й адреси компанш, як цi послуги надали.»
Очевидно, що наданий опис не може бути напряму передано до СУБД, щоб виконати пошук потрiбноi iнформацii. Цей опис потрiбно обробити та збудувати вщповщний SQL запит.
Побудова SQL запиту потребуе знання структури бази даних, та значення вах полiв yсiх таблиць в базi даних, тобто вiдповiдностi термжв у сформульова-ному вище гшотетичному прикладi назвам полiв та-блиць БД.
В будь-якому випадку, щоб виконати пошук по-трiбноi iнформацii необхiдно трансформувати опис у вщповщну мову цiльовоi системи. Якщо цiльова система - СУБД, то опис потрiбно перекласти у речення SQL. У випадку запиту до текстового сховища, як, на-приклад, через пошуковий сервiс Google, виконуеться аналiз запиту, та побудова семантичних навантажених критерпв для подальшого пошуку у текстових даних за допомогою вiдповiдних алгоритмiв [5,6].
Такий класичний тдхщ до пошуку шформацп мае своi гiдностi, та недолжи.
Гiдностi класичного пiдходy:
1. Класичний тдхщ базуеться на теорii реляцiйноi алгебри [1].
2. Класичний пiдхiд використовуе стандартизова-ну мову запитiв SQL.
3. Запити SQL оптимiзyються цiльовою СУБД, що дозволяе дуже швидко виконувати пошук потрiбноi iнформацii.
Недолiки класичного тдходу:
1. Змiна структури бази даних, наприклад у випад-ку додавання до бази даних нового типу документу для збертння, може привести до повноi переробки запипв пошуку iнформацii.
2. Новi запити кiнцевого користувача, яю не мають вiдповiдноi реалiзацii, повинш бути проаналiзованi, та реалiзованi у термшах мови SQL, для чого потребу-ються вiдповiднi фахiвцi. Тобто, кшцевий користувач, який не мае знань структури бази даних, та не вмiе ви-користовувати мову SQL не може отримати вщповщь на свш запит.
3. Аналiз вимог та формування SQL запиту потребуе значного часу, тому що потрiбно проаналiзyвати до деюлькох сотень реквiзитiв (полiв таблиць БД) [2], та побудувати складний запит i налагодити його.
Запропонована у роботах [3,4] семантична база даних докуменпв з рiзноманiтним ре^зитним змктом дозволяе уникнути тих недолiкiв як було наведено вище. Наявнiсть двох рiвнiв семантичноi iнформацii дае змогу уникнути детального аналiзy опису проблеми та пошуку ввдповвдних полiв потрiбноi iнформацii, а також захистить ввд змiн реалiзованого програмного забезпе-чення у випадку додавання нових титв докуменпв.
Наявнiсть семантичних даних також дае можливкть спростити формування запиту для пошуку шформацп.
Розглянемо як семантична шформащя допоможе кшцевому користувачу отримати ввдповвдь на приклад наведений на початку:
1. Осюльки сховище iнформацii зберiгаe даш для всiх типiв документiв, у результат ми отримаемо документи рiзних типiв у яких зустрiчается дана назва банку.
2. Якщо користувач мае додатковi вимоги (що не наведеш у приклад^ щодо потрiбних йому типiв доку-ментiв вш може перелiчити iх на початку формування запиту.
3. Перший рiвень семантичноi iнформацii - гло-бальнi блоки - дозволить нам скоротити юльюсть реквiзитiв серед яких ми повинш вибрати потрiбнi.
4. Вибранi ре^зити дозволять нам ще звузити результата пошуку, якщо ми задамо конкретш умови для кожного з реквiзитiв.
5. Шсля формування запиту, та його виконання користувач матиме змогу вибрати потрiбнi йому для ввдображення додатковi реквiзити, якi не приймали участ у пошуку шформацп.
Тепер ми маемо змогу створити алгоритм пошуку шформацп у семантичнш базi даних. Алгоритм пошуку складаеться з трьох частин: формування умов пошуку, вибiр тдмножини докуменив, тдготовка та формування звiту.
Розглянемо першу частину алгоритму, блок-схема якого зображена на рис. 1.
г----------------------------------1
Формування умов пошуку I
Рис. 1. Блок-схема алгоритму формування умов пошуку
Восточно-Европейский журнал передовым технологий
На першому крощ виконуеться зчитування шформацп з семантичного ядра щодо вах типiв документiв, якi iснують у базi даних. Зчитана iнформацiя виво-диться на iнтерфейс i користувачу надаеться можли-вiсть вибрати потрiбнi типи документiв для пошуку (крок 2). Початково вважаеться, що пошук буде вико-нуватися по вах типах документiв.
Третiй крок алгоритму виконуе зчитування семан-тично1 шформацп першого рiвня, тобто перелiк в«х глобальнiх блокiв для вибраних титв документiв, та вiдображення 1х на штерфейсь Користувачу надаеться можливiсть вибрати потрiбнi йому глобальнi блоки для подальшого уточнення умов пошуку.
На наступному крощ виконуеться зчитування гло-бальних реквiзитiв вiдповiдно до вибраних глобаль-них блокiв та виведення 1х на iнтерфейс користувача.
На п'ятому крощ користувач вибирае потрiбний йому глобальний ре^зит, та формуе булевий вираз умов пошуку. У випадку нашого гшотетичного запи-ту умова для ре^зиту «Банк» повинна мати вигляд: «Банк = 'Банк Кшру'», а для ре^зиту «Дата операцп»: «Дата операцii = 2010».
Сформований булевий вираз додаеться до повноi умови пошуку за допомогою операторiв «ТА» («AND») та «АБО» («ОЯ»).
Перша частина а лгоритму завершуеться форму-ванням повних умов пошуку шформацп.
На рис. 2 зображено блок-схему другоi частини алгоритму пошуку.
Виб1р тдмножини документов
3. Формування нового , виразу пошуку на основ1 отримано! тдмножини ] заголовюв документов
4. Зчитування потр1бно1 тдмножини документов з таблиц заголовюв
5. Виведення отримано! тдмножини докуменпв на 1нгерфейс користувача у вигляд1 таблит
На основi перелiку значень реквiзитiв в умовi пошуку алгоритм витягуе шформащю зi сховища. Ця шформащя вiдповiдае всiм елементарним умовам пошуку («Банк = 'Банк Кшру'») i мае також референцп на заголовки докуменпв до яких ця шформащя вщ-носиться.
Другий крок алгоритму вибору тдмножини до-кументiв отримуе вщповщну пiдмножину заголовкiв документiв i на наступному кроцi формуе новий вираз для пошуку, тому що потрiбно вибрати всю шформащю, яка мае вiдношення до даного документу.
Вся вибрана шформащя виводиться на штерфейс користувача для подальшого вибору потрiбноi до-датковоi шформацп. У нашому приклад^ це та шформащя яка не була присутня в умовах пошуку, а саме: перелж товарiв та послуг, назва та адреса компанп.
Третя частина алгоритму пошуку вщповщае за формування результуючого звггу, i надае можливкть вибрати потрiбнi iнформацiйнi ре^зити вибраних до-кументiв. Блок-схема алгоритму зображена на рис. 3.
Шдготовка до формування звту
Рис. 2. Блок-схема вибору тдмножини докуменлв
Рис. 3. Блок-схема тдготовки формування зв^у
Важливо ввдмиити наступш вiдмiнностi у запро-понованому пiдходi до пошуку шформацп за допомогою семантичноi складовоi бази даних вiд класичного тдходу:
1. Якщо до бази даних буде додано новий тип докуменпв, то вш вщразу з'явиться на ш-терфейсi користувача i буде приймати участь у формуван-ш умов пошуку (згiдно до пер-шого кроку формування умов пошуку, дивiться рис. 1).
2. Уа новi глобальнi блоки та глобальш реквiзити нових документiв також з'являться на штерфейи кiнцевого ко-ристувача i будуть приймати участь у формуванш умов пошуку. Шяких додаткових про-грамних засобiв для цього не потрiбно.
3. Завдяки присутностi се-мантичних даних першого рiв-ня, тобто глобальних блоюв, зменшуеться кiлькiсть рек-вiзитiв, якi будуть приймати участь у пошуку, що спрощуе вiдбiр потрiбних для пошуку реквiзитiв, та зменшуе час по-трiбний для формування умов пошуку.
4. Формування умов пошуку вщбуваеться у термшах яю вiдомi й зрозумiлi користува-чу (давайте знову звернемося до прикладу наведеного на початку стати), а не у термшах SQL мови.
5. Зменьшення юлькоси реквiзитiв, якi приймають участь у формуванш умов пошуку, та яю вибирае користу-вач, приводить до спрощення взаемодп кшцевого користу-вача з програмним засобом для пошуку.
Реалiзацiя наведеного ал-
3 Проект: Поисковая система
4 Автор: Изварин
5 Описание : Возвращает перечень блоков по внутреннему имени системы
6 Версия: 1.00
7 История : 17 июня 2009 -- создан
8
9 Входные параметры: SystemId - И системы
10
11 */
13 IF EXISTS (SELECT name FROM sysobjects WHERE name = 'GetBlocks' AND TYPE = 'P')
14 DROP PROCEDURE [dbo].[GetBlocks]
15
16 GO
18 CREATE PROCEDURE GetBlocks
19 @SystemId INT
20 AS
21
22 SELECT
23 f_id,
24 f_name
25 FROM
26 [dbo].[Blocks]
27 WHERE
28 f_id IN (SELECT f_fkBlockId FROM [dbo].[DocumentBlocks] WHERE f_fkDocId = @SystemId)
29 ORDER BY
30 f_name
Рис. 4. Процедура зчитування перелiку глобальних блокiв для даного типу документу
горитму складаеться з двох
частин: шару SQL процедур на бощ СУБД, та ^iemcb-кого прикладного програмного засобу для штерфейсу кшцевого користувача.
SQL процедури мають простий вигляд. У якоси приклада на рис. 4 наведено код процедури, яка реаль зуе крок 2 алгоритму формування умов пошуку.
Для того, щоб було можливо виконувати пошук у базах даних, як було створено на основi СУБД що не тдтримують ушверсальний тип даних SQL_VARIA-NT (Microsoft SQL Server), або ANYDATA (Oracle) було створено прошарок представлень (VIEW), щоб ство-рити единий програмний штерфейс для процедур, що виконують зчитування даних зi сховища.
Замiрювана швидкiсть формування умов пошуку не перевищувала 10-15 хвилин. Цей час складаеться з часу для зчитування даних з бази даних, формування штерфейсу кшцевого користувача, та штерактивно! роботи користувача по аналiзу потрiбних глобальних блоюв та реквiзитiв, та формування додаткових умов для кожного ре^зиту. Час пошуку потрiбноi шфор-мацп не перевищував 5-ти хвилин у СУБД Microsoft SQL Server 2005 Enterprise Edition, яка працюе тд операцшною системою Windows Server 2008 Enterprise Edition. Час тдготовки та формування звггу також не перевищував 5-ти хвилин значна частина з яких також ввдноситься до роботи з iнтерфейсом [2].
Лиература
1. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
2. Забара С. С., Изварин И. В. Семантические базы данных документов с различным реквизитным содержанием // Комп'ютер-но-штегроваш технологи: осв™, наука, виробництво: Науковий журнал / Пщ редакщею доктора техшчних наук В. Д. Рудь. - Луцьк: Видавництво Луцького нацюнального техшчного ушверситету, 2011, № 5. — С. 87-92.
3. Изварин И.В. Жизненный цикл информационного потока // Интеллектуальные сисьемы принятия решений и проблемы вычислительного интеллекта: Материалы международной научной конференции. Том 1. - Херсон: ЧНТУб 2011ю - с. 76-78.
4. Gerald J. Kowalski, Mark T. Maybury. Information Storage and Retrieval Systems. Theory and Implementation. Second Edition. Kluwer Academic Publishers 2002.
5. Greengrass Ed. Information Retrieval: A Survey, 2000.
6. Stefano Cen, Marco Brambilla. Search Computing. Trends and Developments. Springer-Verlag Berlin Heidelberg 2011.
УДК 004.822
ЗАСТОСУВАННЯ МОВИ ПРОГРАМУВАННЯ PYTHON ДЛЯ ПОБУДОВИ БАЗ ЗНАНЬ ТА ЕКСПЕРТНИХ СИСТЕМ
-□ □-
На ocHoei фреймовог модел1 подання знань запропоновано принципи розробки баз знань та експертних систем утверсальною мовою програмування Python. Проанал1зовано об'ектно-ор1ентоват можливостг та засо-би ттроспекци Python. Розроблено демон-страцшну базу знань та подано приклади запитгв до нег
Ключов1 слова: база знань, онтолотя,
подання знань, експертна система
□-□
На основе фреймовой модели представления знаний предложены принципы разработки баз знаний и экспертных систем на универсальном языке программирования Python. Проанализированы объектно-ориентированные возможности и средства интроспекции Python. Разработана демонстрационная база знаний и даны примеры запросов к ней
Ключевые слова: база знаний, онтология,
представление знаний, экспертная система □-□
On the basis of frames for knowledge representation have been proposed principles for the development of knowledge bases and expert systems on general-purpose programming language Python. Object-oriented and introspection capabilities of Python have been analyzed. The demo of knowledge base and the examples of querying to it have been developed
Keywords: knowledge base, ontology, knowledge representation, expert system -□ □-
1. Вступ
Вщомо, що розвиток науки основуеться на отри-манш об'ективних i системно-оргашзованих знань, як допомагають людям рацюнально оргашзувати свою дiяльнiсть i виршувати рiзнi проблеми, котрi виникають в ü процесс Сучасш комп'ютерш технологи зумовили розвиток шженерп знань - обласи науки про штучний штелект, яка вивчае методи i засоби отримання, представлення, структурування
В.Б. Копей
Кандидат техычних наук, доцент Кафедра технологи нафтогазового машинобудування 1вано-Франмвський нацюнальний техшчний ушверситет нафти i газу вул. Карпатська, 15, м. 1вано-Франмвськ, 76019 Контактний тел.: (03422) 4-30-24 E-mail: vkopey@gmail.com
Л.М. Семанишин
Астрант
1вано-Франмвська ф^я Вщкритого мiжнародного уыверситету розвитку людини «УкраТна» вул. Набережна, 42а, м. 1вано-Франмвськ, 76010 Контактний тел: 096-990-89-38 E-mail: symanyshyn_lesja@mail.ru
i використання знань. Iнженерiя знань пов'язана з розробкою баз знань i експертних систем [1,2].
База знань - це сукупшсть фак^в i правил лопч-ного висновку (виведення) в обранш предметнш область Правила лопчного висновку - це правила пере-творення вихщно! системи факив (суджень) в нову систему факив (висновюв). Наприклад, за такими правилами з вихщних факив "ва люди смертш" i "Сократ - людина" можна зробити висновок "Сократ смертний". В даному випадку правилом висновку е
