Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій

Наводяться шляхи реінженірінгу баз даних автоматизованих інформаційних систем з метою упорядкування алфавітної однорідності ідентифікаційних реквізитів, введених в систему на різних мовах, та їхнього розміщення по відведених для них полях БД залежно від алфавіту представлення реквізитів для підвище...

Full description

Saved in:
Bibliographic Details
Date:2005
Main Authors: Алексеев, В.А., Ільїн, С.А., Терещенко, В.С., Ференц, Д.А.
Format: Article
Language:Ukrainian
Published: Інститут програмних систем НАН України 2005
Subjects:
Online Access:https://nasplib.isofts.kiev.ua/handle/123456789/1353
Tags: Add Tag
No Tags, Be the first to tag this record!
Journal Title:Digital Library of Periodicals of National Academy of Sciences of Ukraine
Cite this:Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій / В.А. Алексеєв, С.А.Ільїн, В.С. Терещенко, Д.А. Ференц // Проблеми програмування. — 2005. — N 2. — С. 3-14. — Бібліогр.: 8 назв. — укр.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine
_version_ 1859633045606236160
author Алексеев, В.А.
Ільїн, С.А.
Терещенко, В.С.
Ференц, Д.А.
author_facet Алексеев, В.А.
Ільїн, С.А.
Терещенко, В.С.
Ференц, Д.А.
citation_txt Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій / В.А. Алексеєв, С.А.Ільїн, В.С. Терещенко, Д.А. Ференц // Проблеми програмування. — 2005. — N 2. — С. 3-14. — Бібліогр.: 8 назв. — укр.
collection DSpace DC
description Наводяться шляхи реінженірінгу баз даних автоматизованих інформаційних систем з метою упорядкування алфавітної однорідності ідентифікаційних реквізитів, введених в систему на різних мовах, та їхнього розміщення по відведених для них полях БД залежно від алфавіту представлення реквізитів для підвищення ефективності вирішення функціональних задач з пошуку інформації в системі по цих реквізитах при використанні методів чіткого пошуку.
first_indexed 2025-12-07T13:12:49Z
format Article
fulltext Методи і засоби програмної інженерії © В.А. Алексеєв, С .А . Ільїн , В.С. Терещенко, Д.А. Ференц, 2005 ISSN 1727-4907. Проблеми програмування. 2005. №2 3 УДК 681.3 В.А. Алексеєв, С .А .Ільїн , В.С. Терещенко, Д.А. Ференц РЕІНЖЕНІРІНГ БАЗ ДАНИХ ІНФОРМАЦІЙНИХ СИСТЕМ З РОЗГАЛУЖЕНОЮ МЕРЕЖЕЮ ПУНКТІВ ЗБОРУ ПЕРВИННОЇ ІНФОРМАЦІЇ Наводяться шляхи реінженірінгу баз даних автоматизованих інформаційних систем з метою упорядкування алфавітної однорідності ідентифікаційних реквізитів, введених в систему на різних мовах, та їхнього розміщення по відведених для них полях БД залежно від алфавіту представлення реквізитів для підвищення ефективності вирішення функціональних задач з пошуку інформації в системі по цих реквізитах при використанні методів чіткого пошуку. Вступ В автоматизованих інформаційних системах (АІС) з широко розгалуженою мережею пунктів збору первинної інфор- мації, що пов’язана з ідентифікаційними реквізитами (прізвище, ім’я та по бать- кові), іноді виникають проблеми орфогра- фічного характеру (порушуються правила, що регулюють способи передачі мови на письмі [1]), які можуть призвести до знач- ного зниження ефективності роботи таких АІС, а то й до повного їх колапсу, коли, скажімо, система на запит у процесі інфо- рмаційного пошуку не може знайти у базі даних необхідні ідентифікаційні реквізити (ІР), хоча достеменно відомо, що вони там є. Передусім це стосується тих систем, які вже давно введені в експлуатацію. Їхні ре- сурси (інформаційні і програмні) започат- ковані давно і з часом поступово нарощу- вались, мережа пунктів збору збільшува- лась, кількість програмних та апаратних компонентів теж. Ці компоненти могли створюватись в різні часи і різними колек- тивами розробників. Дії цих колективів були недостатньо узгоджені між собою. В процесі розробки та експлуатації таких систем нормативи та вимоги до них могли змінюватись, але корективи не завжди вносились у вже працюючі компоненти. А ще могли виникати нагальні потреби опе- ративної зміни якихось компонентів, до- робки, а то й розробки їх заново, що не завжди узгоджувалось з уже працюючими. У пунктах збору спочатку могла вноситись інформація однією мовою, зго- дом – іншою, причому в одних задачах це могло бути враховано, а в інших ні. На одних пунктах збору первинної інформації ІР могли вноситись в одному регістрі, а на інших – в іншому. Архітектура баз даних (БД) могла змінюватись, а інформація БД неодноразово модифіковуватись. Та й ав- томатизовані робочі місця (АРМ) на пунк- тах збору, ще за часів введення системи в експлуатацію, працювали в MS DOS, де кодові таблиці не співпадають з кодовими таблицями MS Windows (наприклад, ко- дова таблиця No 866 та No 1251 Windows в ASCII), наявний драйвер клавіатури не завжди був розрахований на українську мову, що змушувало операторів застосо- вувати літери інших алфавітів. До того ж треба додати людський фактор як під час занесення громадянами даних про ІР до певних карток та анкет, так і під час вве- дення їх операторами багаточисельних пунктів збору в систему. Але нашою метою є не пошук при- чин виникнення такого становища, а по- шук шляхів його виправлення. І саме цьому присвячена дана стаття. А причини тут наведені лише для більшого загост- рення уваги на цій проблемі та аналізу її наслідків. 1. Визначення проблеми Дослідивши детально описану вище ситуацію, що склалася в давно вже працюючій інформаційній системі, можна зробити висновок про те, що вона може привнести в БД системи наступні негати- вні явища, так чи інакше пов’язані з орфо- графічними проблемами записів ідентифі- каційних реквізитів ІР, що не дозволяють ідентифікувати ці реквізити в БД у разі використання методів чіткого пошуку: Методи і засоби програмної інженерії 4 • наявність в БД крім літер, використовуваних в системі алфавітів, ще й “заборонених” символів (цифр, розділових знаків, спеціальних симво- лів, прогаликів перед реквізитом або кількох разом в інших місцях тощо), що не передбачені для використання в написанні ІР; • наявність в БД однакових ІР, але введених у різних регістрах (верхній – великі літери, регістр – малі); • наявність в ІР літер, що належать різ- ним алфавітам або однакові за написом ІР можуть бути подані літерами різних алфавітів (наприклад, ІВАНОВ може бути написано літерами як українсь- кого, так і англійського алфавітів); • місцезнаходження ІР одного алфавіту в полі БД, призначеного для ІР іншого алфавіту. Це може відбуватися в системах, які оперують ІР, записаними кількома мо- вами. Можна сказати, в рамках системи, так би мовити, “взаємодіють” кілька алфа- вітів: два, три або навіть і більше. Назвемо такі системи 2-алфавітними, 3-алфавіт- ними,...,N-алфавітними. Під алфавітом (абеткою) будемо розуміти сукупність лі- тер, апостроф та прогалик, упорядкованих певним чином, на відміну від інших ви- значень, наприклад: сукупність літер, складових знаків та інших графем даної системи письма, розміщених у певному порядку [2], впорядкована певним образом сукупність взаємно відмінних знаків (лі- тер, цифр, спеціальних і службових знаків) та прогалику [3], впорядкований набір усіх літер цифр та знаків конкретної мови [4], не кажучи вже про алфавіти, що вико- ристовуються в мовах програмування. Подолати ці негативні явища мо- жна тільки тоді, коли будуть вирішені від- повідні задачі. Більше того, вирішення цих задач необхідно періодично повторювати під час, скажімо, проведення регламент- них робіт на БД, тому що за наявності ба- гатьох джерел введення інформації не мо- жна гарантувати у подальшому появи цих явищ знову. Першу задачу – вивільнення БД від “заборонених” при написанні ІР символів вирішити легко під час профілактичних робіт на БД інформаційної системи, вилу- чивши їх програмними засобами або замі- нивши на прогалики залежно від попере- дньої домовленості. Другу задачу – зняття ускладнень з інформаційно-пошукових процесів через наявність в системі ІР в різних регістрах теж вирішити неважко. Для цього достат- ньо невеличкого додатку до програмних засобів пошуку, в якому ідентифікація лі- тер проводиться незалежно від регістру, в якому вони введені та зберігаються. А ще краще (і це буде видно трохи згодом) пе- ревести всі реквізити в БД у верхній ре- гістр і для унеможливлення у подальшому вводу реквізитів у нижньому регістрі мо- дифікувати програмні засоби вводу даних первинної інформації для автоматичного переводу у верхній регістр при внесенні реквізитів у систему. Третя задача дещо складніша. Вона полягає у приведенні записів ІР у алфаві- тну норму, тобто зробити їх алфавітно-од- норідними (всі літери запису ІР у полі БД мають бути одного алфавіту), а для цього при локалізації неоднорідності потрібно вміти програмно знаходити літеру необ- хідного для даного ІР алфавіту, що збіга- ється за написанням з помилковою літе- рою (іншого алфавіту), щоб поміняти їхні коди. Саме такі помилки превалюють у БД. Якщо ж помилкова літера за написан- ням не збігається з жодною літерою необ- хідного алфавіту, тоді програмне виправ- лення неможливе. Тут потрібне втручання оператора для визначення початкового за- пису ІР у вхідних документах, що негати- вно відбивається на часі реінженірінгу БД. Четверта задача полягає в розмі- щенні вже алфавітно-однорідних ІР у при- значених для них залежно від алфавіту полях БД, а для цього треба вміти програ- мно визначати приналежність реквізиту до того чи іншого алфавіту. Вирішення цих задач і є метою ре- інженірінга БД інформаційної системи, в якій для записів ІР використовуються де- кілька алфавітів для зняття описаної про- блеми. Зрозуміло, тут перш за все йдеться про 3-алфавітні системи, як про найбільш актуальні на даний момент у нашій країні з трьома національними мовами: україн- Методи і засоби програмної інженерії 5 ська, російська та англійська. Саме вони є найбільш вживаними для заповнення де- яких громадянських документів обліко- вого характеру. Часто ці мови розділяють за письмом: кирилицею та латиницею [2], хоча, строго кажучи, це не зовсім так. Ан- глійський алфавіт (26 літер) не співпадає на 100% з латинським письмом (25 літер), а український (33 літери) та російський (33, але дещо інші літери) алфавіти – з ки- риличним (43 літери) письмом. Але, не дивлячись на це, не будемо відходити від такого умовного розподілу. Тим більше що він прийнятий і в додатках середовища MS Windows, а ми розглядатимемо різ- ницю та збіжність написання літер назва- них вище алфавітів не самих мов, як філо- логічних та лексичних засобів людського спілкування з їхніми фонетичними, мор- фологічними, синтаксичними особливос- тями [5], а їхніх представлень, саме пред- ставлень, в цих додатках та програмних засобах ведення БД. Серед літер кожного з цих алфаві- тів є такі, що за написанням (графічним зображенням у кожному з прийнятих у додатках MS Windows шрифтів): • збігаються між собою у всіх трьох алфавітах; • збігаються в кожній парі алфавітів окремо (в кожній парі – це для загаль- ного випадку); • притаманні саме цьому, тільки одному алфавіту (з числа тих, що розгляда- ються). Перелік цих літер, як тих, що збі- гаються, так і тих, що не збігаються по на- писанню для вибраних українського, ро- сійського та англійського алфавітів у вер- хньому регістрі, наведено у табл. 1. Зро- зуміло, що для нижнього регістру таблиця буде іншою, а тому для зменшення склад- ності задачі і трудомісткості її вирішення і пропонувалося вище вводити та зберігати ІР в одному (верхньому) регістрі. Таблиця наведена для 3-алфавітної системи, для конкретного випадку – тільки для вказаних алфавітів. Розглянемо більш загальний випадок – 3-алфавітну систему з трьома будь-якими національ- ними алфавітами, застосувавши при цьому формальний опис “взаємодіючих”, в рам- ках інформаційної системи та сформульо- ваної вище проблеми, алфавітів. 2. Формальний опис взаємодіючих алфавітів Нехай 1M , 2M , 3M – множини лі- тер національних алфавітів відповідно 1A , 2A , 3A , а )( 1Ab i , )( 2Abα , )( 3Ab β – елементи цих множин (літери вказаних алфавітів): 11 )( MAb i ∈ для { }1...,,2,1 Li ∈ ; 22 )( MAb ∈α для { }2...,,2,1 L∈α ; 33 )( MAb ∈β для { }3...,,2,1 L∈β ; де 1L , 2L , 3L – кількість елементів в мно- жинах 1M , 2M , 3M відповідно. Теоретико-множинне об’єднання цих множин (так звана “взаємодія” алфа- вітів 1A , 2A , 3A в рамках проблеми й Таблиця 1. Перелік літер, що збігаються і не збігаються по написанню для українського, російського та англійського алфавітів у верхньому регістрі Літери, що по написанню не збігаються з літерами інших алфавітів, а є тільки в наступних алфавітах Літери, що по написанню збігаються тільки в наступних парах алфавітів українському російському англійському українському, російському українському, англійському російському, англійському Літери, що збігаються в усіх трьох алфавітах Ґ, Є, Ї Ё, Ъ, Ы, Э D, F, G, J, L, Б, Г, Д, Ж, З, І - А, В, Е, К, М, N, Q, R, S, U, И, Й, Л, П, У, Н, О, Р, С, Т, V, W, Y, Z Ф, Ц, Ч, Ш, Щ, Х Ь, Ю, Я Методи і засоби програмної інженерії 6 інформаційної системи) породжує літер- ний (символьний) простір системи – нову, так би мовити, просторову множину M , елементами якої є всі літери всіх алфаві- тів, задіяних у системі. Можна сказати, що ці елементи складають 3-вимірний простір літер, вимірами якого є кожний із “взає- модіючих” алфавітів як поняття, а не су- купність літер. Ця просторова множина є сумою цілого сімейства підмножин [6, с. 18], що виникають через взаємне комбіно- ване перерізання заданих множин: кожна з кожною попарно, усі разом, ще й різниці просторової множини з перерізаннями за- даних множин. Для формального запису цього утворення введемо символьне по- значення таких підмножин – v wM . Воно має два індекси: верхній v вказує на кіль- кість множин, підмножиною яких є позна- чена підмножина, і нижній w − на конкре- тні множини, підмножиною саме яких є позначена підмножина. Наведемо це утво- рення із залученням описаного символь- ного позначення підмножин: 3 123 2 23 2 13 2 12 1 3 1 2 1 1 321 MMMMMMM MMMM ⊕⊕⊕⊕⊕⊕⇔ ⇔⇔ UU , де 1 1M – підмножина множини 1M ( 1 1 1 MM ⊂ ) літер тільки в алфавіті 1A ; 1 2M – підмножина множини 2M ( 2 1 2 MM ⊂ ) літер тільки в алфавіті 2A ; 1 3M – підмножина множини 3M ( 3 1 3 MM ⊂ ) літер тільки в алфавіті 3A ; 2 12M – підмножина двох множин: 1M та 2M ( 1 2 12 MM ⊂ , 2 2 12 MM ⊂ ) літер алфаві- тів 1A , 2A , які за написом збігаються; 2 13M – підмножина двох множин: 1M та 3M ( 1 2 13 MM ⊂ , 3 2 13 MM ⊂ ) літер алфаві- тів 1A , 3A , які за написом збігаються; 2 23M – підмножина двох множин: 2M та 3M ( 2 2 23 MM ⊂ , 3 2 23 MM ⊂ ) літер алфавітів 2A , 3A , які за написом збіга- ються; 3 123M – підмножина трьох множин: 1M , 2M , 3M ( 1 3 123 MM ⊂ , 2 3 123 MM ⊂ , 3 3 123 MM ⊂ ) літер алфавітів 1A , 2A , 3A , які за написом збігаються. Розподіл вказаних підмножин по графах табл. 1 для вже дослідженого нами випадку (якщо прийняти український ал- фавіт за 1A , російський за 2A , а англійсь- кий за 3A ) буде наступним: 1 1M – графа 1, 1 2M – графа 2, 1 3M – графа 3, 2 12M – графа 4, 2 13M – графа 5, 2 23M – графа 6, 3 123M – графа 7. Схематичне зображення об’єднання множин 1M , 2M , 3M , їхнього комбінованого взаємного перерізання та породжених цим дійством підмножин 1 1M , 1 2M , 1 3M , 2 12M , 2 13M , 2 23M , 3 123M пока- зане на рис.1. Кожній літері відповідає певний код з кодової сторінки, а множині – об- ласть визначення кодів літер відповідного алфавіту 1A , 2A або 3A на кодовій сторі- нці (наприклад, кодова сторінка No 1251 Windows для Power Builder 8.03 стандарт- ної системи кодування ASCII). Відомо, що на цій кодовій сторінці можна виділити область визначення кодів для літер алфа- вітів 1A , 2A та 3A . Деякі області визна- чення кодів літер можуть перерізатися або навіть бути єдиними для кількох алфавітів (наприклад, для українського та російсь- кого). Деякі області визначення кодів лі- тер можуть бути різними, хоча відповідні їм літери збігаються за написанням (на- приклад, український та англійський). Це вносить додаткові складнощі в задачу роз- пізнавання належності літери до того чи іншого алфавіту. 3. Перевірка алфавітної однорідності ідентифікаційного реквізиту Перевірка алфавітної однорідності ІР зводиться до аналізу (визначення) на- лежності літер цього ІР до досліджених Методи і засоби програмної інженерії 7 вище семи підмножин: 1 1M , 1 2M , 1 3M , 2 12M , 2 13M , 2 23M , 3 123M і залежно від цього робиться висновок про подальші дії: − поставити позначку в БД про алфаві- тну однорідність цього запису ІР, щоб при наступній перевірці не перевіряти його знов; − перенести запис ІР в інше призначене для нього поле, якщо він однорідний, але знаходиться не на “своєму” місці в БД та поставити позначку; − поміняти код літери, якщо вона хоча і збігається по написанню, але належить іншому алфавіту, та поставити позна- чку; − провести організаційні дії, якщо в за- писі ІР застосовано літери іншого ал- фавіту, навіть з іншим графічним зо- браженням, виправити які можна, тільки перевіривши первинні докуме- нти, де вперше з’явився цей ІР, та від- коригувавши його вручну. Таким чином, варіантів перевірки однорідності може бути тільки сім по кі- лькості підмножин. В кожному з них може бути три випадки стосовно підмножини, що досліджується саме в цьому варіанті: • 1: всі літери ІР належать цій підмно- жині; • 2: деякі літери ІР належать цій підмно- жині; • 3: жодна з літер ІР не належить цій під- множині. Третій випадок по кожному із семи варіантів розглядати нема сенсу, тому що він характерний для кожного варіанту і дії щодо нього необхідні однакові: потрібно перевірити інші варіанти, тому що цій підмножині ІР не належить. Розглянемо варіанти визначення належності літер ІР до вказаних підмно- жин. Наприклад, перевіримо по всіх мож- ливих семи варіантах ІР, що знаходиться у полі, призначеному для ІР, написаних, скажімо, в алфавіті 1A : � варіант 1 – аналіз літер ІР щодо нале- жності їх підмножині 1 1M : • випадок 1: всі літери ІР належать підмножині 1 1M – ІР є алфавітно однорідним і належить алфавіту 1A ; • випадок 2: деякі літери ІР належать підмножині 1 1M – ІР є алфавітно неоднорідним і необхідно дослідити інші літери, що не належать алфавіту 1A , відповідно до шляхів, викладених у подальших варіантах, визначивши перед тим, до якої під- множини належать ці літери; Рис. 1. Схематичне зображення об’єднання множин літер алфавітів в 3-алфавітній системі Методи і засоби програмної інженерії 8 � варіант 2 – аналіз літер ІР щодо нале- жності їх підмножині 1 2M : • випадок 1: всі літери ІР належать під- множині 1 2M – ІР знаходиться не у своєму полі БД і його треба пе- ренести до поля ІР з літерами ал- фавіту 2A ; • випадок 2: деякі літери належать під- множині 1 2M – в ІР є граматичні по- милки (застосовано літери іншого алфавіту, навіть з іншим графічним зображенням), виправити які можна тільки через організаційні дії (пере- вірку первинних документів, де вперше з’явився цей ІР, та коригу- вання його вручну); � варіант 3 – аналіз літер ІР щодо нале- жності їх підмножині 1 3M : • випадок 1: всі літери ІР належать під- множині 1 3M – ІР знаходиться не у своєму полі БД і його треба перене- сти до поля ІР з літерами алфавіту 3A ; • випадок 2: деякі літери належать під- множині 1 3M – висновки ті ж, що й у попередньому варіанті; � варіант 4 – аналіз літер ІР щодо нале- жності їх підмножині 2 12M : • випадок 1: всі літери належать підмножині 2 12M – тут потрібна до- даткова перевірка кодів цих літер: якщо вони відносяться до області визначення кодів алфавіту 1A , то ІР є алфавітно-однорідним; якщо до алфавіту 2A , то треба змінити код літери на відповідний код цієї лі- тери з області визначення кодів лі- тер алфавіту 1A ; • випадок 2: деякі літери належать під- множині 2 12M – шлях той же, що й у попередньому випадку цього варіа- нта; � варіант 5 – аналіз літер ІР щодо нале- жності їх підмножині 2 13M : • випадок 1: всі літери належать підмножині 2 13M – висновки ті ж, що й у попередньому варіанті, але відносно алфавіту 3A ; • випадок 2: деякі літери належать під- множині 2 13M – шлях той же, що й у попередньому пункті цього варіа- нта; � варіант 6 – аналіз літер ІР щодо нале- жності їх підмножині 2 23M : • випадок 1: всі літери ІР належать під- множині 2 23M – ІР знаходиться не у своєму полі БД і його треба перене- сти або до поля 2A , або до поля 3A , замінивши коди літер, що знахо- дяться в області визначення кодів літер не “свого” алфавіту, на відпо- відні коди цих літер “свого” алфа- віту; • випадок 2: деякі літери ІР належать підмножині 2 23M – висновки ті ж, що й у випадку 2 варіанта 2 та 3; � варіант 7 – аналіз літер ІР щодо нале- жності їх підмножині 3 123M : • випадок 1: всі літери належать підмножині 3 123M – тут потрібна додаткова перевірка кодів цих лі- тер: якщо вони відносяться до об- ласті визначення кодів алфавіту 1A , то ІР є алфавітно-однорідним, якщо до алфавіту 2A або 3A , то треба змінити код літери на відповідний код цієї літери з області визначення кодів літер алфавіту 1A ; • випадок 2: деякі літери належать під- множині 3 123M – шлях той же, що і в попередньому випадку цього ва- ріанта. Перевірка завершена: досліджені всі можливі варіанти, тобто всі підмножини для вибраної кількості алфавітів. Для ін- ших полів ІР викладки будуть ідентич- ними. Визначення належності алфавітно- однорідного ІР до певного алфавіту 1A , Методи і засоби програмної інженерії 9 2A , 3A базується на визначенні належно- сті його літер як елементів до множин 1M , 2M , 3M . 4. Розширення задачі на довільну кількість алфавітів Читачі, мабуть, помітили, що склад підмножин 1 1M , 1 2M , 1 3M , 2 12M , 2 13M , 2 23M , 3 123M має деякі особливості. Їх можна розділити на три групи залежно від кіль- кості множин, представлених своїми еле- ментами в цих підмножинах. До першої групи віднесемо 1 1M , 1 2M , 1 3M , тому що кожна з них є підмножиною тільки однієї множини. До другої групи – підмножини 2 12M , 2 13M , 2 23M : кожна з них є підмножи- ною двох множин. До третьої групи – під- множину 3 123M : вона є підмножиною усіх трьох множин. Таким чином, 3-алфавітна “взаємодія” породжує три групи підмно- жин. Неважко визначити, що в інформа- ційній N-алфавітній системі “взаємодія” N алфавітів приведе до створення сімейства підмножин множини літерного (символь- ного) простору M системи, яке можна представити у вигляді N груп підмножин. В першій групі – підмножини, кожна з яких є підмножиною тільки однієї мно- жини (містить окремі літери тільки одного алфавіту, v=1), у другій групі – підмно- жини, кожна з яких є підмножиною двох множин (містить окремі літери двох алфа- вітів, v=2) і так далі, в v-й групі – підмно- жини, кожна з яких є підмножиною m множин (містить окремі літери m алфаві- тів, v=m), в N-й групі завжди буде одна підмножина (містить окремі літери всіх N алфавітів, v=N). Кількість підмножин v NK у v-й групі (v=m) визначається математич- ним сполученням із N елементів по m ( { }Nm ,...,2,1∈ ), а загальна кількість під- множин NK дорівнює ∑∑ == == N m m N N v v NN CKK 11 , де m NC – комбінаторна функція [7] ма- тематичного сполучення із N елементів по m ; N – кількість множин (кількість алфавітів в системі); v – номер групи підмножин ( { }Nv ...,,2,1∈ ); m – кількість множин, підмножиною яких є дана підмножина (в даному разі кількість множин та номер групи підмножин збігаються – m = v); v NK – кількість підмножин в v-й групі підмножин (кожна з підмножин цієї групи містить окремі літери m алфавітів з N алфавітів, які є в системі, для v = m). При збільшенні N кількість під- множин v NK по групах дуже швидко зрос- тає. Це видно навіть поверховим оглядом при порівнянні рис.1, 2 та 3. На рис. 2 показане схематичне зо- браження об’єднання 4-х множин 1M , 2M , 3M , 4M , їхнього комбінованого взає- много перерізання та породжених цим дійством підмножин по групах: 1 4K =4 ( 1 1M , 1 2M , 1 3M , 1 4M ), 2 4K =6 ( 2 12M , 2 13M , 2 14M , 2 23M , 2 24M , 2 34M ), 3 4K =4 ( 3 123M , 3 124M , 3 134M , 3 234M ), 4 4K =1 ( 4 1234M ). Рис. 2. Схематичне зображення об’єднання множин літер алфавітів в 4-алфавітній системі Методи і засоби програмної інженерії 10 На рис. 3 показане схематичне зо- браження об’єднання 5-ти множин 1M , 2M , 3M , 4M , 5M , їхнього комбінованого взаємного перерізання та породжених цим дійством підмножин по групах: 1 5K =5 ( 1 1M , 1 2M , 1 3M , 1 4M , 1 5M ), 2 5K =10 ( 2 12M , 2 13M , 2 14M , 2 15M , 2 23M , 2 24M , 2 25M , 2 34M , 2 35M , 2 45M ), 3 5K =10 ( 3 123M , 3 124M , 3 125M , 3 134M , 3 135M , 3 145M , 3 234M , 3 235M , 3 245M , 3 345M ), 4 5K =5 ( 4 1234M , 4 1235M , 4 1245M , 4 1345M , 4 2345M ), 5 5K =1 ( 5 12345M ). На рис. 3 деякі підмножини зустрі- чаються двічі, але це не значить, що таких підмножин і у загальній сукупності об’єднання кілька. Це тільки прояв особ- ливостей графічного зображення схеми. В табл. 2 наведена кількість під- множин по групах як результат комбіно- ваного взаємного перерізання початкових множин, для N-алфавітних, де N={1, 2, …, 9}, систем. Ця таблиця являє собою фрагмент трикутника Паскаля з біноміальними кое- фіцієнтами, а взаємодію N алфавітів, вір- ніше, їхніх множин, в системі можна роз- глядати як розклад біному Ньютона, сте- пінь якого дорівнює N, у повній відповід- ності до основ класичної математики і, зо- крема, теорії множин та комбінаторики. Стосовно викладок щодо шляхів вирішення поставленої задачі для N-алфа- вітних систем, то вони будуть аналогіч- ними, але з відповідними корективами кі- лькості підмножин та груп цих підмно- жин. 5. Практична реалізація запропонованих шляхів вирішення задачі Наведені в статті викладки знай- шли практичне втілення у одному з про- Рис. 3. Схематичне зображення об’єднання множин літер алфавітів в 5-алфавітній системі Методи і засоби програмної інженерії 11 грамно-технічних комплексів широко роз- галуженої в Україні автоматизованої ін- формаційної системи. В межах цього програмно-техніч- ного комплексу створено програмний мо- дуль міжплатформеного обміну даними, що може функціонувати як на Web-сервері окремого комп'ютера, так і на Web-сер- вері, вмонтованому в СКБД Oracle. Мо- дуль служить для завантаження файлів даних, що надходять з численних пунктів збору інформації до центральної бази да- них (OC Sun Solaris 9, СКБД Oracle), та для обміну даними з АІС, які мають інші платформи (наприклад, UNIX) та СКБД (приміром, MS SQL, Sybase Anywhere, Progress). При цьому можуть підтримува- тися різні протоколи передачі даних (UUCP, FTP) та формати файлів (текстові, XML). Функції модуля розширені за раху- нок додаткових функцій фільтрування да- них при завантаженні їх у БД. Під час та- кого фільтрування здійснюється перевірка даних (реквізитів) на належність до пев- ного алфавіту та приведення їх до алфаві- тної однорідності. Програмний модуль написано мо- вою Java, яка, на наш погляд, найліпше підходить для створення розподілених до- датків, орієнтованих на роботу з реляцій- ними базами даних, різноманітними ме- режевими сервісами, підтримує сучасні технології розробки програмних комплек- сів, що працюють у середовищі Internet/intranet [8], а це є чи не найбільш важливою вимогою до програмних засобів модуля. У роботі програмного модуля між- платформеного обміну даними задіяні як внутрішні Java-класи (String, ResultSet, Prepared, Statement, Connection…), так і Java-класи, створені для виконання спе- цифічних задач – завантаження інформації із різних файлів даних, файлів-квитанцій до центральної бази даних (Import21, Import22, ImportRI, ImportKVT…). Для ре- алізації алгоритму фільтрації даних додат- ково створено ще два Java-класи: � langs служить для приведення симво- лів даних до певного алфавіту і реалі- зує методи: • getLanquaqe – визначення мови да- них; • intoUkrainian – заміни кодів симво- лів на коди літер українського ал- фавіту; • intoRussian – заміни кодів символів на коди літер російського алфавіту; • intoLatin – заміни кодів символів на коди літер англійського алфавіту; � SlashTokenizer, що служить для зчиту- вання даних з файлів даних і реалізує методи: • removeillegal – видалення символів, заборонених для використання в базі даних; • LangTranslator – заміни літер кири- лиці на літери англійського алфа- віту, що збігаються за написанням. Ці Java-класи викликаються в про- цесі завантаження інформації в БД, ство- рюються їхні об'єкти, яким передається керування. За допомогою методів, перелі- Таблиця 2. Кількість підмножин (по групах і загалом) для N-алфавітних систем v NK (v=m) N v=1 v=2 v=3 v=4 v=5 v=6 v=7 v=8 v=9 NK 1 1 1 2 2 1 3 3 3 3 1 7 4 4 6 4 1 15 5 5 10 10 5 1 31 6 6 15 20 15 6 1 63 7 7 21 35 35 21 7 1 127 8 8 28 56 70 56 28 8 1 255 9 9 36 84 12 6 126 84 36 9 1 511 Методи і засоби програмної інженерії 12 чених вище, проводиться посимвольний аналіз кожного реквізиту, зчитаного з файлу даних. Всі символи переводяться до верхнього регістру. Символи, які заборо- нені для використання в базі даних, вилу- чаються, а непередбачені замінюються на прогалики. Далі відбувається процес ви- значення алфавіту конкретного реквізиту, після чого згідно з алгоритмом прово- дяться заміни кодів символів, які не нале- жать кодам даного алфавіту, на відповідні йому коди. Після завершення фільтру- вання реквізиту керування передається до класу, що викликав даний, який саме і здійснює процес завантаження відфільт- рованої інформації до бази даних. Під час функціонування модуля фі- льтруванню підлягає облікова інформація, сукупність якої однозначно ідентифікує особу або транспортний засіб. Такими ві- домостями можуть бути: прізвище, ім'я, по батькові, серія та номер паспортного до- кумента, реєстраційний № автомобіля, рейс літака чи потяга. На рис. 4 наведено блок-схему ал- горитму приведення ІР до алфавітної од- норідності, за яким відбувається робота описаного програмного модуля, для розв’язання задачі усунення алфавітної неоднорідності записів ІР у БД відповідно до табл. 3, де наведені літери та їхні коди (таблиця No 1251) для різних алфавітів, що збігаються за написанням. На рис. 5 наведено блок-схему ал- горитму визначення мови, за яким відбу- вається робота описаного програмного модуля, для розв’язання задачі розмі- щення ІР у визначених для них полях БД. В результаті нарощування функцій модуля за рахунок роботи фільтру інфор- мація, що зберігається в БД, стає більш придатною для аналітичної обробки, час та ресурси, які витрачаються на пошукові операції в БД значно знижуються. Це слу- жить більш ефективному використанню користувачами системи зібраної в БД ін- формації. Рис. 4. Блок-схема алгоритму приведення ІР до алфавітної однорідності Алфавіт було визначено як рос. Дані конкретного поля Поле = Поле , перетворене до рос. алфавіту так Алфавіт було в изначено як укр. або кирилиця Поле = Поле, п еретворене до укр. алфавіту так Поле = Поле, перетворене до англ. алфавіту ні н і Кінець Методи і засоби програмної інженерії 13 Таблиця 3 Кирилиця Латиниця Літера український алфавіт Російський алфавіт англійський алфавіт I 178 – 73 A 192 192 65 B 194 194 66 E 197 197 69 K 202 202 75 M 204 204 77 H 205 205 72 O 206 206 79 P 208 208 80 C 209 209 67 T 210 210 84 X 213 213 88 Рис. 5. Блок-схема алгоритма визначення мови Літери відповідних граф таблиці1: * - 'Ґ', 'Є', 'Ї' (графа 1) ** - 'Ё', 'Ъ', 'Ы' ,Э (графа 2) *** - 'Б', 'Г' , 'Д' , 'Ж', 'З' , 'И' , 'Й' , 'Л' , 'П', 'У ', 'Ф' , 'Ц' , 'Ч' , 'Ш', 'Щ', 'Ь', 'Ю' , 'Я' (графа 4) **** - 'D', 'F', 'G', 'J', 'L', 'N', 'Q', 'R', 'S', 'U', 'V', 'W', 'Y', 'Z' (графа 3) *****- 'A', 'B', 'C', 'E', 'H', 'K', 'M', 'O' 'P', 'T', 'X' (графа 7) Дані конкретного поля Дані міс тять літери, можливі лише в українс ькому алфавіті (*) український Дані міс тять літери, можливі лише в рос ійському алфавіті (**) російс ький так ні так Дані містять літери, можливі лише в кирилиці (***) так ні Дані містять літеру ' I' укр. або англ. алфавіту український так кирилиця ні Дані містять літери, можливі лише в англійс ькому алфавіті (****) англійс ький так ні Дані містять літери, с хожі за написанням в укр., рос. та англ. алфавітах, в кодах кирилиці (*****)так англійський ні Дані містять літеру 'I' укр. або англ. алфавіту український так кирилиця ні ні Кінець Методи і засоби програмної інженерії 14 Висновки Запропонований шлях визначення алфавітної однорідності або неоднорідно- сті ІР дозволяє серед літер ІР, які належать одному алфавіту, гарантовано визначати літери, що хоча за написанням і збіга- ються, але за кодами (кодової сторінки) належать іншому алфавіту. Це дає змогу програмно поміняти коди таких літер, що неможна зробити при виборі інших шля- хів, реквізиту на необхідні для вибраного алфавіту і, тим самим, збільшити алфаві- тну однорідність ІР у БД інформаційної системи, що у свою чергу знизить ймовір- ність помилок системи при інформаційно- пошукових операціях (відповідно до ме- тодів чіткого пошуку) за запитами по цих ІР і підвищить ефективність роботи самої системи. 1. Словник іншомовних слів. – Київ: Головна редакція УРЕ АН УРСР, 1974. – 776 c. 2. Советский энциклопедический словарь. – М.: Изд. «СЭ», 1989. – 1632 с. 3. Першиков В.И., Савинков В.М. Толковый словарь по информатике. – М.: Финансы и статистика. 1991. – 543 с. 4. ДСТУ 2226-93 (ГОСТ 34.003). Державний стандарт України. Автоматизовані системи. Терміни та визначення. – К.: Держстандарт України, 1994. – 5 с. 5. Пентилюк М.І., Іващенко О.В. Українська мова: Підручник-комплект. – К.: Ленвіт, 2001. – 352 с. 6. Энциклопедия кибернетики : В 2-х т. Т. 2. – Киев: Гл. ред. УСЭ, 1974. – 724 с. 7. Бронштейн И.Н., Семендяев К.А. Справочник по математике для инженеров и учащихся ВТУЗов. – Лейпциг: Изд. «Тойбнер», М.: Наука, 1980. – 976 с. 8. Мак-Лахлин Б. Java и XML: – Пер. с англ. – СПб: Символ-Плюс, 2002. – 544 с. Отримано 29.03.04 Про авторів Алексеєв Віктор Анатолійович, канд. техн. наук, завідувач відділу Ільїн Сергій Анатолійович, провідний програміст Терещенко Валерій Савелійович, канд. техн. наук, старший науковий співробітник Ференц Дар’я Антонівна, провідний інженер-програміст Місце роботи авторів: Інститут програмних систем НАН України, м. Київ, пр-т Академіка Глушкова, 40 тел.: (044) 526 4228, 526 6321 e-mail: alecseev@isofts.kiev.ua; e-mail: terek@isofts.kiev.ua
id nasplib_isofts_kiev_ua-123456789-1353
institution Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn 1727-4907
language Ukrainian
last_indexed 2025-12-07T13:12:49Z
publishDate 2005
publisher Інститут програмних систем НАН України
record_format dspace
spelling Алексеев, В.А.
Ільїн, С.А.
Терещенко, В.С.
Ференц, Д.А.
2008-07-25T16:18:48Z
2008-07-25T16:18:48Z
2005
Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій / В.А. Алексеєв, С.А.Ільїн, В.С. Терещенко, Д.А. Ференц // Проблеми програмування. — 2005. — N 2. — С. 3-14. — Бібліогр.: 8 назв. — укр.
1727-4907
https://nasplib.isofts.kiev.ua/handle/123456789/1353
681.3
Наводяться шляхи реінженірінгу баз даних автоматизованих інформаційних систем з метою упорядкування алфавітної однорідності ідентифікаційних реквізитів, введених в систему на різних мовах, та їхнього розміщення по відведених для них полях БД залежно від алфавіту представлення реквізитів для підвищення ефективності вирішення функціональних задач з пошуку інформації в системі по цих реквізитах при використанні методів чіткого пошуку.
uk
Інститут програмних систем НАН України
Методи і засоби програмної інженерії
Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
Reengineering of database of information systems with the advanced network of items of collection of the primary information
Article
published earlier
spellingShingle Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
Алексеев, В.А.
Ільїн, С.А.
Терещенко, В.С.
Ференц, Д.А.
Методи і засоби програмної інженерії
title Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
title_alt Reengineering of database of information systems with the advanced network of items of collection of the primary information
title_full Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
title_fullStr Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
title_full_unstemmed Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
title_short Реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
title_sort реінженірінг баз даних інформаційних систем з розгалуженою мережею пунктів збору первинной інформацій
topic Методи і засоби програмної інженерії
topic_facet Методи і засоби програмної інженерії
url https://nasplib.isofts.kiev.ua/handle/123456789/1353
work_keys_str_mv AT alekseevva reínženíríngbazdanihínformacíinihsistemzrozgaluženoûmerežeûpunktívzborupervinnoiínformacíi
AT ílʹínsa reínženíríngbazdanihínformacíinihsistemzrozgaluženoûmerežeûpunktívzborupervinnoiínformacíi
AT tereŝenkovs reínženíríngbazdanihínformacíinihsistemzrozgaluženoûmerežeûpunktívzborupervinnoiínformacíi
AT ferencda reínženíríngbazdanihínformacíinihsistemzrozgaluženoûmerežeûpunktívzborupervinnoiínformacíi
AT alekseevva reengineeringofdatabaseofinformationsystemswiththeadvancednetworkofitemsofcollectionoftheprimaryinformation
AT ílʹínsa reengineeringofdatabaseofinformationsystemswiththeadvancednetworkofitemsofcollectionoftheprimaryinformation
AT tereŝenkovs reengineeringofdatabaseofinformationsystemswiththeadvancednetworkofitemsofcollectionoftheprimaryinformation
AT ferencda reengineeringofdatabaseofinformationsystemswiththeadvancednetworkofitemsofcollectionoftheprimaryinformation