informatyka
M ie s ię c z n ik IS S N 0 5 42 -995 1 IN D E K S 3 6 1 2 4
nr 8 1 9 9 3 Sierpień Rok w ydania XXVIII
K O LEG IU M REDAKCYJNE:
mgr Jarosław D E M IN E T mgr inż. Piotr FU G LEW ICZ mgr Teresa JA B ŁO ŃS K A (sekretarz redakcji) W ładysław KLEPACZ (redaktor naczelny) mgr inż. Jan RYŻKO dr Zdzisław SZYJEW SKI
PR ZE W O DNIC ZĄCY RADY P RO G RA M O W EJ:
Prof. dr hab.
Juliusz Lech KULIKOW SKI
W YD A W C A :
W ydaw nictw o Czasopism i Książek Technicznych S IG M A NOT Spółka z 0.0.
ul. Ratuszowa 11 0 0 -9 5 0 W A RS ZA W A skrytka pocztowa 10 04
Redakcja:
01 -5 5 2 Warszawa,
PI. Inw alidów 10, p. 1 0 4 ,1 0 5 tel. 3 9 -1 4 -3 4
M ateriałów nie zamówionych redakcja nie zwraca
W spraw ach ogłoszeń prosim y zw ra cać się bezpośrednio
do Redakcji lub
Działu Reklam y i M a rk e tin g u 00-950 W arszaw a ul. M a zo w ie c k a 12 te le fo n : 27-43 -66 telefaks: 26-80 -16 teleks: 814877
W numerze:
S tro n aW ielowersyjne bazy danych - W aldem ar W ieczerzycki 1
IN F O R M IX - fikcje i fakty - D anuta K osm ow ska-M iszalska, P io tr Trojanow ski 5 K om puterow e w spom aganie decyzji o zakupie produktu - Tadeusz W itk o w sk i 9 Badania ankietow e cz. 2. G łów ne zagadnienia projektow ania i użytkow ania system ów inform a
tycznych - Stanisław W rycza, Tom asz P lata-P rzech lew ski 16
W spom aganie sprzętow e syntezy realistycznych obrazów - K a ro l M yszk o w sk i, P a w eł Rej,
A ndrzej W oj dala 21
N o w e k sią żk i 26
P T I 27
W najbliższych numerach:
# Jan G oliński om aw ia inform atykę gospodarczą - kierunek studiów , który jak o pierw sza w Polsce zaczęła kształtow ać Szkoła G łów na H andlow a w W arszawie.
# Tadeusz W itkowski zajmuje się systemem w spom agania przeznaczonym do podejm ow ania decyzji w sytua
cji wyboru jednego z wiełu możliwych w ariantów.
# M arek Wierzbicki charakteryzuje tworzenie obiektów przez dziedziczenie m ono- i polimorficzne.
# A rtu r K asprzyk opisuje etapy obiektow o-zorientow anej analizy i projektow ania, czyli tę część życia systemu, któ ra rzutuje na całą przyszłą jego strukturę i zachowanie.
# P io tr Porw ik zajmuje się m ultimedialnym i bazam i wiedzy.
W a ru n k i p r en u m e ra ty n a 1993 r.
Zam ów ienia na prenum eratę czasopism w ydaw anych przez W ydawnictw o SIG M A -N O T m ożna składać w dow olnym terminie. Mogą one obejm ow ać dow olny okres czasu, tzn. dotyczyć dowolnej liczby kolejnych zeszytów każdego czasopisma.
Zam aw iający może otrzym yw ać zaprenum erow any przez siebie tytuł począwszy od następnego miesiąca p o d o k o n an iu wpłaty.
Zam ów ienia na zeszyty sprzed d aty otrzym ania w płaty będą realizow ane w m iarę możliwości - z posiadanych zapasów magazynowych.
W arunkiem przyjęcia i realizacji zam ów ienia jest otrzym anie z banku potw ierdzenia dok o n an ia w płaty przez prenum eratora.
D okum ent wpłaty jest rów noznaczny ze złożeniem zamówienia.
W płat n a prenum eratę m ożna dokonyw ać na ogólnie dostępnych blankietach w U rzędach Pocztowych (przekazy pieniężne) lub B ankach (polecenie przelewu), przekazując środki p od adres:
Wydawnictwo SIGM A-NOT Spółka z o.o.
Zakład Kolportażu
00-950 Warszawa, skr. poczt. 1004 Wpłaty na prenumeratę od marca br. przyjmują także wszyst-
konto: kie urzędy pocztowe nadawczo-odbiorcze oraz doręczyciele na
PBK S.A. III O/Warszawa nr 370015-1573 terenie całego kraju
N a blankiecie w płaty należy czytelnie p o d ać nazwę zam aw ianego czasopism a, liczbę zam aw ianych egzemplarzy, okres prenum eraty oraz własny adres.
N a życzenie prenum eratora, zgłoszone np. telefonicznie. Z ak ład K olportażu ul. Bartycka 20, 00-950 W arszaw a, (telefony: 40-30-86, 40-35-89 oraz 40-00-21 wew. 249,293,299) wysyła specjalne blankiety zamówień w raz z ak tu aln ą listą tytułów i cennikiem czasopism.
O dbiorcy zagraniczni m ogą otrzym yw ać czasopism a poprzez prenum eratę dewizową (w płata dokonyw ana poza granicam i Polski w dewizach, wg cennika dewizowego z cenami podanym i w dolarach am erykańskich) lub poprzez zam ów ioną w kraju prenum eratę ze zleceniem wysyłki za granicę (zamawiający podaje dokładny adres odbiorcy za granicą, d okonując rów nocześnie w płaty w wysokości dw ukrotnie wyższej niż cena norm alnej prenum eraty krajowej).
• Egzemplarze archiwalne (sprzedaż przelewowa lub za zaliczeniem pocztowym) m ożna zam aw iać pisem nie, kierując zam ów ienia pod adresem : W ydawnictw o S IG M A N O T , S półka z o.o. Z ak ład K olportażu, 00-716 W arszaw a, ul. Bartycka 20, paw . B, tel. 40-37-31, natom iast za gotów kę m ożna je nabyć w K lubie Prasy Technicznej w W arszawie ul. M azowieckiej 12, tel. 26-80-17.
Istnieje możliwość zaprenum erow ania 1 egz. czasopisma po cenie ulgowej przez indyw idualnych członków stowarzyszeń naukow o-technicznych zrzeszonych w F S N T oraz przez uczniów zawodow ych i studentów szkół wyższych. Blankiet wpłaty na prenum eratę ulgow ą musi być op atrzo n y na wszystkich odcinkach pieczęcią koła S N T lub szkoły.
W przypadku zmiany cen w okresie objętym prenumeratą Wydawnictwo zastrzega sobie prawo do wystąpienia o dopłatę różnicy cen oraz prawo do realizowania prenumeraty tylko w pełni opłaconej.
Cena jednego egzemplarza: normalna 25000 zł, ulgowa 18750 zł Wartość prenumeraty w zl:
Normalna: kwartalna 75000, półroczna 150000, roczna 300000 Ulgowa: kwartalna 56250, półroczna 112 500, roczna 225000.
Skład i d ruk: D rukarnia S IG M A N O T Sp. z o.o. z. 283/93
In fo r m a ty k a n r 8, 1993 r.
W ALDEMAR WIECZERZYCKI Francusko-Polska Wyższa Szkoła
Nowych Technik Informatyczno-Komunikacyjnych Poznań
Wielowersyjne bazy danych
Pojawienie się tanich, bardzo efektywnych, graficz
nych stacji roboczych spowodowało zainteresowanie nowymi zastosowaniami systemów baz danych, prze
de wszystkim w systemach komputerowego wspoma
gania projektowania i komputerowego wspomagania inżynierii oprogramowania. Zastosowania te wyma
gają złożonych struktur danych, umożliwiających reprezentowanie schematów, rysunków, obrazów, dźwięków itp. oraz nowych typów związków między nimi. Ponieważ relacyjny model danych okazał się dla tych zastosowań niewystarczający, rozpoczęto po
szukiwania nowych modeli danych. Najbardziej obie
cującą propozycją było wykorzystanie w modelu danych paradygmatu obiektowego. Zaowocowało ono tak zwanymi obiektowymi bazami danych, z któ
rych najbardziej znanymi są: Orion, 0 2, GemStone, Ontos, ObjectStore, Exodus, Cactis, Vision, Iris i VBase.
Pierwsze próby zastosow ań obiektowych baz danych, w sze
roko rozum ianym kom puterow ym w spom aganiu projektow a
nia, wykazały konieczność rozszerzenia paradygm atu obiek
towego. Z praktycznego p u n k tu widzenia, w zastosow aniach tych jest w ym agana możliwość tw orzenia przez użytkow ników różnych wersji tego samego obiektu [1, 2, 3, 4, 5, 6, 8,9 , 11, 14].
T ak rozszerzone bazy danych są nazywane w ielow ersyjnym i o b ie k to w y m i b a z a m i d an y ch .
Problematyka
wielowersyjnych baz danych
O biekty wielowersyjnych baz danych są reprezentantam i stanu i zachow ania m odelow anych encji. Zm iana stanu encji wiąże się ze zm ianą w artości atrybutów obiektu, zm iana jej struktury - z m odyfikacją liczby i dziedzin atrybutów , n a to m iast zm iana zachow ania encji wiąże się z dodaniem do obiektu nowych m etod lub m odyfikacją ich kodu. W jednowersyjnych bazach danych nie m a możliwości zapam iętania stanów i za
chow ań obiektu sprzed jego kolejnych modyfikacji, przy jedno
czesnym zachow aniu ich pow iązań z tą sam ą encją. Reprezen
tow anie tej samej encji w postaciach sprzed i po modyfikacji stanu pow oduje konieczność utrzym yw ania dw óch różnych w ystąpień tej samej klasy, a w postaciach sprzed i po m odyfika
cji struktury lub zachow ania - dw óch różnych obiektów będących w ystąpieniam i dw óch różnych klas. W obu przypad
kach powiązanie tych dw óch obiektów z pojedynczą encją odbyw a się na poziomie aplikacji, a nie bazy danych.
W wielu zastosow aniach baz danych jest niezbędne tworze
nie, utrzym yw anie i operow anie n a wielu reprezentacjach tych samych encji, nazywanych wersjami obiektów . N a przykład, w wyniku projektow ania sam ochodu pow staje zazwyczaj kilka
jego w ersji w a ria n to w y c h : ekonom iczna, sportow a, luksuso
wa, dostaw cza, terenow a, kabriolet, pick-up itp. Wersje te różnią się między sobą wersjami kom ponentów : podw ozia, nadwozia, silnika itp., konstrukcją (strukturą) i zachowaniem:
przyspieszeniem, ham ow aniem , rozruchem , stabilnością itp. Są jed n ak utożsam iane z pojedynczym m odelem, produkow anym przez tę sam ą firmę, na bazie nieznacznie różniących się technologii i elementów m ateriałow ych. Poza wersjami final
nymi projektu, uznanym i w danym m omencie za satysfakcjo
nujące, w bazie danych m uszą być również przechowywane wersje niekom pletne, będące wynikiem poszczególnych etapów procesu projektow ania, np. wersji luksusowej sam ochodu.
W ersje te, nazw ane zwykle w ersjam i h isto ry czn y m i, w przy
padku niepomyślnych wyników testów, reklam acji użytkow ni
ków, zmieniającej się m ody, up o dobań itp., um ożliw iają pow rót do określonego etapu projektu, a następnie, po uwzględnieniu odpow iednich popraw ek, zaprojektow anie ulepszonej luksuso
wej wersji sam ochodu, zastępującej na rynku wersję poprzednią.
W ersje w ariantow e i historyczne nie dotyczą wyłącznie obiektu złożonego, będącego przedm iotem całościowego projektu.
W ogólności, każdy z kom ponentów występuje w wielu wers
jach, zarów no historycznych, ja k i w ariantow ych. W ynika to z równoległego rozw oju kom ponentów (podzespołów) obiektu złożonego, prow adzonego przez różne zespoły projektow e.
W powyższym przykładzie, wielowersyjny jest nie tylko silnik sam ochodu i podwozie, ale również śruba, nak rętk a i p o d k ład ka. Zauważym y, że nie wszystkie wersje w ariantow e kom ponen
tów m uszą być elementami wersji w ariantow ych obiektów złożonych. N iektóre z nich, z różnych pow odów , mogły być wyeliminowane w trakcie procesu projektow ania, inne będą wykorzystane w projekcie kolejnych wersji obiektu złożonego, np. wersji „com bi” i „lim uzyna” rozw ażanego sam ochodu.
W arto podkreślić, że podział wersji obiektu na historyczne i w ariantow e jest realizowany na poziom ie aplikacji, a nie m odelu wersjowania. Z atem o tym, które z wersji są historyczne, a które wariantow e, decydują użytkownicy (projektanci) apli
kacji bazy danych, a nie system zarządzania bazą danych.
W ersje pojedynczego obiektu są częściowo uporządkow ane.
Ich uporządkow anie odzwierciedla sposób ich wywodu: nie
które wersje są tw orzone od podstaw ; inne są w yprow adzane z istniejących wersji obiektu przez modyfikacje ich stanu i zachow ania. Zależnie od przyjętego m odelu wywodu, zbiór wersji obiektu może tworzyć drzewo, las lub acykliczny graf skierowany. Przykładow e częściowe uporządkow anie wersji obiektu przedstaw iono na rysunku 1. W yróżniono dziewięć wersji obiektu: wi , w2, w9. W ersje w, i w7 były utw orzone od podstaw . Pozostałe wersje były w yprow adzone z innych wersji obiektu.
Kluczowym problem em w wielowersyjnych obiektow ych bazach danych jest problem zachow ania ich spójności. Spójność wielowersyjnej bazy danych m a dw a aspekty. Po pierwsze, wiąże się z definicją transakcji, k tó ra przeprow adza bazę danych
In fo r m a ty k a n r 8 , 1993 r. 1
Rys, 1. L as wywodu wersji obiektu
z jednego stanu spójnego do innego stanu spójnego. Po drugie, wiąże się z wielowersyjnością. D otyczy wówczas konieczności zapewnienia użytkow nikow i bazy danych efektywnych m echa
nizmów identyfikacji wszystkich tych wersji obiektów , które są wzajemnie spójne. Jest to zadanie szczególnie trudne w przypad
ku bazy danych zawierającej dużą liczbę obiektów , z których każdy występuje w wielu wersjach. Zauważym y bowiem, że w przypadku obiektu składającego się z n kom ponentów , z których każdy występuje w m wersjach, potencjalnie m ożna utw orzyć m wersji obiektu złożonego.
W jednow ersyjnych bazach problem spójności zwykle roz
wiązuje się następująco. O biekt jednow ersyjny jest zdefiniowa
ny ja k o p ara {identyfikator_obiektu, w artość-obiektu). Jedno- wersyjna baza danych jest zdefiniowana ja k o zbiór zaw artych w niej obiektów , a stan bazy danych ja k o zbiór wartości zaw artych w niej obiektów . Jednow ersyjna baza danych jest uznaw ana za spójną, jeśli dokładnie reprezentuje stan m odelo
wanego fragm entu rzeczywistości. Rzeczywistość ta nie musi istnieć fizycznie. Przykładow o, w systemach wspom agających projektow anie m odelow ana rzeczywistość istnieje jedynie w wy
obraźni projektanta. Z form alnego p u nktu widzenia spójność bazy danych jest wym uszana przez ograniczenia integralnoś- ciowe, nakładane na wartości jej obiektów . W celu zachow ania spójności bazy danych dopuszcza się zm ianę jej stanu jedynie na drodze w ykonania transakcji, o których zakłada się z definicji, że przenoszą bazę danych ze stanu spójnego do innego stanu spójnego.
W przypadku wielo wersyjnych baz danych problem zacho
w ania ich spójności jest problem em znacznie bardziej złożonym.
O biekt - obecnie wielowersyjny - definiujemy tutaj ja k o parę (identyfikator^obiektu, zbiór^wersji_obiektu), a wersję obiektu - j a k o parę (identyfikator^wersji, wartość-wersji). Wielowersyj- ną bazę danych definiujemy ja k o zbiór obiektów wielowersyj- nych, a stan wielowersyjnej bazy danych - ja k o zbiór w artości wszystkich wersji zaw artych w niej obiektów.
K onsekw encją w prow adzenia wersji obiektów do bazy d a
nych jest fakt, że wielowersyjna baza danych nie jest nigdy spójna w klasycznym znaczeniu tego słowa. T raktow ana bo
wiem ja k o całość, nie odzwierciedla żadnego stanu rzeczywisto
ści. Rozważm y przykładow o bazę danych składającą się z trzech obiektów: silnika, nadw ozia i podw ozia. Silnik i podwozie w ystępują w pojedynczych wersjach. Nadw ozie występuje w dwóch wersjach: zamkniętej i otw artej (kabriolet), różniących się konstrukcją części dachowej. F ak t, że pojedyncze wersje silnika i podw ozia są spójne zarów no z jedną, ja k i drugą wersją nadw ozia, nie oznacza, że stan bazy danych {silnik, nadwozie, nadwozie, podwozie} jest stanem spójnym. W modelowanej 2
rzeczywistości bowiem nie występują sam ochody m ające jed n o cześnie dw a nadwozia.
Dalszą konsekwencją jest konieczność odrzucenia przyjętej w jednowersyjnych bazach danych definicji transakcji, jako procesu przenoszącego bazę danych ze spójnego stanu do innego stanu spójnego. Stan początkow y bazy danych jest bowiem w ogólności stanem niespójnym. Stąd konieczność określenia, które podzbiory zbioru wersji różnych obiektów są ze sobą spójne, a zatem do których podzbiorów m ożna adreso
wać transakcje.
Problem y spójności wielowersyjnych baz danych były roz
ważane w [7,10,12,13]. W pracach tych różnym i drogam i zm ierzano do w prow adzenia i utrzym yw ania tak zwanej sp ó j
ności częściow ej, rozum ianej ja k o spójność w yróżnionych części wielowersyjnej bazy danych. W spólną cechą wszystkich tych propozycji jest wersjowanie pojedynczych obiektów oraz jaw ne powiązanie wszystkich wzajemnie spójnych ich wersji.
K onieczność pam iętania i aktualizacji tych pow iązań kom plikuje zarządzanie obiektow ą bazą danych. K om plikacje te narastają w raz ze zwiększającą się liczbą obiektów wielowersyj
nych i wersji poszczególnych obiektów.
Odm iennym podejściem do problem u zachow ania spójności wielowersyjnej bazy danych jest podejście przedstaw ione w pra cy [4], w którym jednostką w ersjowania zam iast pojedynczego obiektu jest cała baza danych. Związany z tym podejściem model wielowersyjnej obiektowej bazy danych jest nazywany m o d elem z w ersjam i b a z d an y ch .
Poniżej, w sposób syntetyczny, zostanie przedstaw iony model z wersjami obiektów , im plem entow any w bazie danych Orion [7], oraz model z wersjami bazy danych, zaproponow any w pracy [4],
Model z wersjami obiektów
W systemie O rion, dostosow anym do potrzeb systemów w spom agania projektow ania, obiekty podzielono na wersjowa- ne i niewersjowane. W przypadku obiektów wersjowanych, w yróżniono trzy typy ich wersji: przejściow e (ang. transient), ro b o c z e (ang. working) i o sta te c z n e (ang. released), odzwiercie
dlające kolejne etapy typowego procesu projektow ego. Zm iana typu wersji, np. z przejściowej na roboczą, jest realizow ana za pom ocą tzw. operacji prom ocji (ang. promotioń). W ersje przej
ściowe odpow iadają pierwszemu etapow i procesu projektow e
go, w którym obiekty, w ogólności niekom pletne i niepopraw ne, są intensywnie m odyfikowane. Wersje te są dostępne wyłącznie dla ich projektanta. Z chwilą osiągnięcia stan u stabilnego, po wstępnym przetestow aniu, wersje przejściowe m ogą być prom o
wane do wersji roboczych. W ersje robocze są współdzielone przez projektantów tej samej grupy. N ie m ogą być m odyfikow a
ne. Stanow ią podstaw ę wywodu innych wersji przejściowych tego samego obiektu. Przetestow ana, spełniająca w ym agania projektow e wersja robocza może zostać udostępniona wszyst
kim użytkow nikom system u przez jej prom ow anie do wersji ostatecznej.
Z każdym obiektem wersjowanym, oprócz jego wersji, jest związany tzw. o b ie k t g eneryczny (ang. generic object), repre
zentujący tożsam ość m odelowanej encji. O biekt generyczny jest zbiorem wszystkich wersji obiektu i związków między nimi, wyrażonych hierarchią wywodu. M oże być zatem traktow any ja k o abstrakcja tych wersji. Z arów no obiektow i generycznemu, ja k i wersjom obiektu są przypisane unikalne identyfikatory.
Dzięki tym identyfikatorom , obiekty niewersjowane i wersje obiektu wersjowanego m ogą wskazywać n a inne obiekty. Jeżeli
In fo r m a ty k a n r 8 , 1993 r.
wskazywany obiekt jest obiektem wersjowanym, to wskazanie jest realizowane przez identyfikator konkretnej wersji obiektu lub identyfikator obiektu generycznego. W pierwszym przypad
ku m am y do czynienia ze wskazaniem statycznym , natom iast w drugim ze wskazaniem dynamicznym. Ze względu na niejed
noznaczność wskazań dynamicznych, w każdym obiekcie gene- rycznym wyróżnia się tzw. w ersję d o m y śln ą (ang. default version), której dotyczą w skazania dynamiczne. W ersja dom yśl
na obiektu jest wybierana przez projektanta. Jeżeli dla pewnych obiektów nie została określona, wtedy wersją dom yślną jest wersja ostatnio utw orzona. W skazania dynam iczne um ożliwia
ją elastyczne m odelow anie złożonych encji. W początkow ych etapach tego m odelow ania projektant zwykle tworzy coraz bardziej ulepsżone wersje poszczególnych kom ponentów złożo
nej encji i usuwa te, które z określonych pow odów nie są już dłużej potrzebne. Operacje tw orzenia i usuw ania wersji nie wymagają modyfikacji wskazań z innych obiektów , a co najwyżej zm iany wersji domyślnej m odyfikow anego obiektu generycznego.
O biekt wersjowany jest wystąpieniem wersjonowanej klasy.
W momencie utw orzenia przez aplikację nowego wystąpienia wersjowanej klasy, system autom atycznie tworzy obiekt genery- czny oraz pierwszą wersję obiektu. Wersje, poza identyfikatora
mi, m ają również przypisany unikalny w ram ach danego obiektu num er, odzwierciedlający kolejność ich tworzenia.
O biekt generyczny jest stru k tu rą danych, którą w sposób bezpośredni zarządza wyłącznie system. Zaw iera następujące atrybuty:
• liczbę utw orzonych wersji,
• num er, który zostanie przypisany nowej wersji obiektu,
• num er wersji domyślnej,
• flagę, określającą, czy została w skazana wersja dom yślna,
• drzewo wywodu wersji obiektu.
Sposób określania spójności między wersjami obiektów zale
ży od charakteru pow iązań między obiektam i. W przypadku pow iązań dynamicznych, dostęp do spójnych wersji obiektów jest realizowany przez odwoływanie się do wersji dom yślnych.
W związku z tym, w grupie pow iązanych obiektów w określo
nym momencie jest dostępny tylko jeden zbiór ich spójnych wersji. W przypadku pow iązań statycznych, odpow iedzialność
In fo r m a ty k a n r 8. 1993 r.
za adresow anie spójnych wersji obiektów spoczywa na tran sak cjach, k tóre nawigują w sieci w skazań między wersjami. Ponie
waż wskazania m ogą dotyczyć różnych wersji tego samego obiektu, w określonym momencie jest dostępnych wiele zbiorów spójnych wersji grupy powiązanych obiektów . Z ostało to zilustrow ane na rysunku 2, na którym w yróżniono dw a obiekty wersjowane O, i 0 2 oraz dwa obiekty niewersjowane: 0 3 i 0 A.
O biekt Ox występuje w pięciu wersjach: o\a, on, 0\c, 0\d, i oie, z których wersja oi* jest wersją dom yślną. O biekt 0 2 występuje w dw óch wersjach: o2a i Oi/>, z których wersja o2h jest wersją dom yślną. O biekt Oz wskazuje statycznie na wersje o\c obiektu 0i i oia obiektu 0 2. O biekt Oą wskazuje dynam icznie na obiekty generyczne O, i 0 2. Jest zatem pow iązany z wersjami dom yśl
nymi tych obiektów , tj. o1(, i o2b-
Model z wersjami bazy danych
U podstaw m odelu z wersjami bazy danych leży spostrzeże
nie, że jednow ersyjna baza danych przechowuje reprezentację pojedynczego stanu modelowanej rzeczywistości. R eprezenta
cja ta jest wynikiem modyfikacji w prow adzonych przez użyt
kow nika za pom ocą ostatnio w ykonanej transakcji. Zastępuje ona reprezentację stanu. U żytkow nik m odyfikujący stan choć
by jednego obiektu, faktycznie zmienia całą reprezentację stanu rzeczywistości. Przenosząc to rozum ow anie na wielowersyjne bazy danych m ożna zauważyć, że użytkow nik tworzący nową wersję obiektu w istocie tworzy reprezentację nowego stanu całej m odelowanej rzeczywistości. Zatem , jeżeli poprzedni stan m a być zachow any w bazie danych, to powinien być zachow any ja k o całość.
W om aw ianym m odelu pojedyncza reprezentacja stanu rze
czywistości jest nazyw ana w ersją b azy d a n y ch . W ielowersyjna baza danych jest zdefiniow ana ja k o zbiór logicznie niezależnych wersji bazy danych. Z form alnego punktu widzenia, wersja bazy danych jest parą składającą się z identyfikatora wersji bazy danych oraz zbioru wersji wszystkich obiektów zaw artych w wielowersyjnej bazie danych (po jednej wersji na obiekt).
U nikalne identyfikatory są nadaw ane wersjom bazy danych w sposób autom atyczny w chwili ich tw orzenia przez system zarządzania bazą danych. Stan wersji bazy danych jest zbiorem wartości zaw artych w niej wersji obiektów .
K oncepcja wersji bazy danych umożliwia przyjęcie klasycznej definicji transakcji, przy uwzględnieniu następującego rozsze
rzenia: transakcja jest procesem przeprow adzającym zbiór wersji bazy danych, każdą ze stanu spójnego do innego stanu spójnego. Przed lub po realizacji transakcji wersja bazy danych może być pusta.
U żytkow nik wielowersyjnej bazy danych operuje na niej za pom ocą transakcji, na dw óch różnych poziom ach. Poziom wyższy dotyczy wersji bazy danych. T ransakcje tego poziom u są nazywane tra n sa k c ja m i b azo w y m i (ang. database version transaction). N atom iast poziom niższy dotyczy obiektów w określonej wersji bazy danych: umożliwia ich odczyt, aktualiza
cję, tworzenie i kasowanie. T ransakcje tego poziom u są nazyw a
ne tra n sa k c ja m i o b ie k to w y m i (ang. object transaction).
T ransakcje obiektow e składają się z elem entarnych operacji.
Param etram i każdej operacji są identyfikatory obiektu wieło- wersyjnego i wersji bazy danych, które łącznie identyfikują wersję obiektu. Jeżeli wszystkie operacje transakcji dotyczą tej samej wersji bazy danych, to jej identyfikator może być przeniesiony z poziom u poszczególnych operacji n a w spólny poziom transakcji. O transakcji takiej mówimy, że jest adreso
w ana do pojedynczej wersji bazy danych. T ransakcja tak a jest w ykonyw ana zgodnie z zasadam i dotyczącym i jednow ersyjnych
3
baz danych. Pow oduje ona ewolucję zaadresow anej wersji bazy danych, niezależnie od ewolucji innych wersji bazy danych.
W przypadu, gdy operacje jednej transakcji dotyczą zbioru wersji bazy danych, każda z nich musi być przeprow adzona ze stanu spójnego do innego stanu spójnego. Transakcje takie są przydatne, przykładow o, w celu skopiow ania w artości obiektu z jednej wersji bazy danych do drugiej, przeglądania różnych wersji pojedynczego obiektu, porów nyw ania dwóch lub więcej wersji bazy danych itp.
T ransakcja bazow a tworzy now ą wersję bazy danych lub usuwa istniejącą. W celu utw orzenia nowej wersji bazy danych transakcja bazowa jest adresow ana do jednej z istniejących wersji bazy danych, zwanej dalej ojcem . N ow o utw orzona wersja bazy danych, zw ana synem , jest bezpośrednio po jej utw orzeniu logiczną kopią swego ojca. M oże ona po utw orzeniu ewoluować w wyniku w ykonania adresow anych do niej tran sakcji obiektowych. Ewolucja ta jest niezależna od ewolucji innych wersji bazy danych, w tym od ewolucji jej ojca. Ze sposobu tw orzenia wersji bazy danych w ynika, że ich zbiór ma stru k tu rę drzewa, nazywanego d rzew em w yw odu. Korzenieni tego drzewa jest szczególna wersja bazy danych nazywana w ersją p u stą . W ersja pusta bazy danych m odeluje stan rzeczy
wistości, w którym nie m a żadnych encji. Dzięki temu, wersja bazy danych wywiedziona z wersji pustej jest bezpośrednio po utw orzeniu pusta, a zatem zmiany wniesione do niej przez transakcje obiektowe są tworzeniem od podstaw . Usunięcie wersji bazy danych polega na zablokow aniu jej identyfikatora, który przestaje być dostępny dla transakcji. Usunięcie wersji bazy danych nie pow oduje usunięcia jej synów.
Wersja bazy danych najczęściej różni się od wersji ojca, z której została wywiedziona, jedynie częściowo. Oznacza to, że wersje tych samych obiektów , zaw arte w różnych wersjach baz danych, m ogą mieć te same wartości. W celu uniknięcia redundancji, wersje obiektów o tych samych wartościach są współdzielone przez różne wersje bazy danych. Powstaje jednak wówczas problem identyfikacji wersji obiektów, które należą do określonych wersji bazy danych. Problem ten rozw iązano za pom ocą tak zwanych zn aczn ik ó w w ersji. W konstrukcji znacz
ników wersji w ykorzystano hierarchiczną strukturę zbioru wersji bazy danych, wynikającą ze sposobu ich wywodu.
Znacznik wersji bazy danych jest skonstruow any w taki sposób, aby jednoznacznie identyfikow ał tę wersję i wszystkich jej przodków w drzewie wywodu wersji bazy danych. Jeżeli wersja bazy danych jest w-tym synem wersji bazy danych o znaczniku p, to jej znacznikiem jest p.n. Znacznikiem korzenia drzewa wywodu wersji bazy danych jest 0.
Poniższy przykład ilustruje sposób w ykorzystania znaczni
ków wersji w celu identyfikacji wersji obiektów . Rozważmy wielowersyjną bazę danych składającą się z czterech wersji bazy danych. Drzewo wywodu wersji bazy danych jest przedstaw ione na rysunku 3. W wielowersyjnej bazie danych jest zaw arty obiekt A . Z logicznego punktu widzenia, każdej wersji bazy danych jest przyporządkow ana pojedyncza wersja tego obiektu.
Ponieważ jednak wersje obiektu A w wersjach bazy danych 0.2 i 0.3 są identyczne, to współdzielą one pojedynczą wersję obiektu A. Przyporządkow anie wersji obiektu A do wersji bazy danych przy wykorzystaniu znaczników wersji zapisano w ta
beli 1, nazywanej tabelą asocjacji. Kolejne wiersze tej tabeli reprezentują w artość at pojedynczej wersji obiektu A. W artość ta może być dowolnie złożona, w szczególności może zawierać wyłącznie wskazania na inne obiekty (tj. ich identyfikatory).
Załóżm y teraz, że z wersji bazy danych o znaczniku 0.1 wywiedziono now ą wersję bazy danych, k tó ra otrzym uje znacz
nik 0.1.1 (por. rys. 3). W ersja a , obiektu A jest współdzielona 4
Rys. 3. D rzew o wywodu wersji bazy danych
przez wersje bazy danych 0.1 i 0.1.1. W takiej sytuacji przypo
rządkow anie wersji obiektu A do wersji bazy danych, przedsta
wione w tabeli 1, nie ulega zmianie, pod w arunkiem przyjęcia następującej zasady identyfikacji wersji obiektów:
jeżeli ż a d n a w ersja o b ie k tu nie je st ja w n ie p rz y p o rz ą d k o w a n a w ersji bazy d a n y c h , to w spółdzieli o n a w ersję o b ie k tu ze sw oim ojcem w drzew ie w yw o d u .
Tabela 1. Asocjacja obiektu A
Wersje obiektu A Znaczniki wersji
a0 0
al 0.1
a2 0.2, 0.3
Stosując tę zasadę, w przypadku odw ołania się do obiektu A w wersji bazy danych 0.1.1, należy odszukać jego odpow ied
nią wersję w bazie danych 0.1. A zatem odw ołanie dotyczy wersji a v
Powyższy m echanizm stosuje się rekurencyjnie dla dowolnej liczby przodków w drzewie wywodu wersji bazy danych, współdzielących poszukiw aną wersję obiektu.
Jak wynika z przedstaw ionego przykładu, znacznik wersji i związana z nim zasada identyfikacji wersji obiektów pozwala na całkowite wyeliminowanie uaktualnień pow iązań wersji obiektów z wersjami bazy danych, w przypadku tworzenia nowych wersji bazy danych, i zapewnia uniknięcie redundacji wersji obiektów.
Tabela 2. Asocjacja obiektu B
Wersje obiektu B Znaczniki wersji
b0 0
hl 0.2
t>2 0.1.1
Załóżm y na koniec, że w wielowersyjnej bazie danych są zaw arte obiekty A i B. Tabele asocjacji obu obiektów są oznaczone odpow iednio num eram i 1 i 2. W ynika z nich, że pary wersji: {a0, 60}, { a ,, 60}, {a2, ft,}, {a2, b0} , { a ,, b2} są spójne.
K ażda z tych p a r jest bowiem zaw arta w pewnej wersji bazy danych. O spójności p ar wersji: {a l , 6 ,} i {a2, b 2} nie m ożna się natom iast wypowiedzieć.
LITERATURA
[1] Adiba M.: Histories and Versions for Mutimedia Complex Objects. IEEE Data Engineering Bulletin, Dec., pp. 1-8, 1988
[2] Ahmed R., Navathe S.B.: Version Management of Composite Objects in CAD Databases. Proc. ACM SIGMOD Conf., 1991
d o k o ń c z e n ie n a s. 25
I n fo r m a ty k a n r 8 . 1993 r.
D A N U TA KOSMOWSKA-MISZALSKA Wojskowy Instytut Informatyki
Warszawa
PIOTR TROJANOWSKI
TRADEX SOFTWARE COMPANY Warszawa
INFORM IX - fikcje i fakty
Niniejszy tekst nawiązuje do opublikow anego w numerze kwietniowym IN F O R M A T Y K I artykułu L. K orbel, E. Miłosz i M. M iłosza System y zarządzania relacyjnymi bazam i danych oraz ich przydatność do budowy informatycznych systemów zarządzania.
W ciągu ostatnich lat w ielokrotnie były podejm ow ane próby porów nania dostępnych n a naszym rynku systemów zarządza
nia relacyjnymi bazam i danych (SZRBD). P róby takie pozos
tawiały zwykle uczucie niedosytu, częstokroć zdziwienia uzys
kanym i wynikam i oraz zażenow ania przedstawionym i wnios
kami. W ystępuje to głównie wtedy, gdy autorzy publikacji nie korzystają z m ateriałów źródłowych, własnych doświadczeń i m ateriałów porównawczych niezależnych firm badawczych, a posługują się m ateriałam i reklam owym i poszczególnych pro
ducentów i ich relacjami na tem at produktów konkurencyj
nych, a także m ateriałam i pochodnym i (omówieniami). Często porów nuje się różne wersje poszczególnych pakietów , a m iano
wicie wersje aktualne z wersjami daw no wycofanymi ze sprzeda
ży. Efektam i takiego podejścia są wyniki nie odzwierciedlające istoty spraw, prow adzące do fałszywych wniosków i ogólnie dezorientujące przyszłych użytkowników SZRBD.
W spom nianem u na wstępie artykułow i m ożna postaw ić wiele tego typu zarzutów . C harakterystyka kryteriów użyteczności SZR B D , p o traktow ana ja k o uświadom ienie przyszłemu użyt
kownikowi problem ów , które w konkretnych zastosow aniach m ogą być ważne, spełnia rolę na pewno pożyteczną. Ale om ów ienia poszczególnych pakietów muszą, w każdym zorien
tow anym w zagadnieniach czytelniku, budzić zastrzeżenia.
Przegląd czterech systemów (O R A C LE, PR O G R E SS, IN F O R - M IX i IN G R E S), nie jest przeprow adzony w sposób jednolity, uwzględniający te same aspekty, analogiczne cechy, czy uw ypu
klający najmocniejsze strony każdego z pakietów . W yciąganie w niosków porównawczych z tak zestawionego m ateriału jest chyba działaniem ryzykownym i może się okazać wysoce szkodliwym dla przyszłych użytkow ników SZRBD.
Poniższy tekst jest p róbą przedstaw ienia oprogram ow ania IN F O R M IX oraz pozycji tej firmy na rynku systemów za
rządzania relacyjnymi bazam i danych. Naszym celem było dostarczenie rzetelnych inform acji, które m ogą być w ykorzys
tane do własnych analiz i ocen czytelników.
Inform ix Software Inc. jest jednym z wiodących producentów systemów zarządzania relacyjnymi bazam i danych oraz oprog
ram ow ania narzędziowego do tworzenia oprogram ow ania użytkowego w spółpracującego z bazam i danych. Od wielu lat IN F O R M IX zajm uje się głównie tą częścią rynku oprog
ram ow ania, k tó ra dotyczy systemu operacyjnego U N IX oraz współpracujących z nim przez połączenia kom unikacyjne sys
In fo r m a ty k a n r 8 . 1993 r.
temów operacyjnych M S-D O S i M S-W indows. O program ow a
nie IN F O R M IX jest oferowane w p onad 500 wersjach dla kom puterów ponad 120 producentów dostosow anych do sys
temów operacyjnych U N IX (w różnych jego wersjach: SU N OS, U L T R IX , A IX , H P-U X itd.), N eX T STEP, M S-DOS, Novell N etw are, OS/2, M acintosh. Udział firmy IN F O R M IX w świa
towym rynku systemów zarządzania relacyjnymi bazami da
nych, pracującym i pod systemem operacyjnym U N IX , wynosi 37% (według International Data Corporation, 1992), a w E uro
pie 54% . Powyższe wyniki są przede wszystkim efektem szyb
kiego w ykorzystywania w swych p roduktach najnowszych osiągnięć technologii inform atycznej, ścisłego przestrzegania norm i standardów (X /O pen, A N SI, FIPS, ISO itd.) i oferow a
nia po konkurencyjnych cenach w ysokowydajnych serwerów baz danych oraz efektywnych, a zarazem prostych w obsłudze i nauce, narzędzi do tw orzenia oprogram ow ania użytkowego.
Firm a IN F O R M IX oferuje cztery grupy produktów :
• serwery baz danych,
• narzędzia do tw orzenia oprogram ow ania użytkowego,
• p rodukty sieciowe,
• p rodukty dodatkow e.
Serwery baz danych
I N F O R M IX -O n L in e
to serwer bazy danych o bardzo dużej wydajności, przeznaczo
ny do zastosow ań wymagających bieżącego przetw arzania transakcji (O LTP - On-Line Transaction Processing), ciągłej pracy, archiwizacji w czasie działania bazy danych w trybie on-line, wysokiego stopnia bezpieczeństwa danych oraz dużej niezawodności działania. C harakteryzuje się następującym i cechami:
• baza danych istnieje poza systemem plików systemu opera
cyjnego, m a bezpośredni dostęp do raw device, dostęp do niej odbyw a się w całości przez m echanizmy IN F O R M IX -O nL ine, co pozw ala zw ielokrotnić szybkość działania;
• możliwość w ykorzystywania architektury klient-serwer;
• wielkość bazy danych jest ograniczona jedynie pojem nością pamięci masowych;
• możliwość m onitorow ania i optym alizacji (strojenia) serwera bazy danych;
• istnienie wspólnego segm entu danych w pamięci operacyjnej (ang. shared memory)',
• możliwość przechowywania danych w zm iennych typu Bina
ry Large Object (BLOB) o wielkości do 2 GB, w których m ogą znajdow ać się: zapis wideo, zapis dźwięku, m apa, zdjęcie itd.;
• zarządzanie systemem dysków zwierciadlanych (ang. disk mirroring);
• wykorzystywanie możliwości kom puterów m ultiprocesoro- wych przez własne mechanizmy;
5
• możliwość archiw ow ania w czasie pracy serwera, zarów no zaw artości całej bazy danych ja k też zaw artych w niej zmian;
• bardzo duża niezaw odność bazy danych, realizow ana przez mechanizmy zabezpieczenia integralności bazy (referential in
tegrity, entity integrity, transaction logging, internal consistency checking) oraz m echanizmy szybkiego i niezawodnego od
tw arzania zaw artości bazy danych;
• zastosowanie stored procedures, tj. procedur funkcyjnych budow anych za pom ocą poleceń języka SQL oraz specjalizowa
nego języka SPL i składow anych w bazie danych, których wykorzystanie znacznie przyspiesza działania na tej bazie;
• w ykorzystanie protokołu two-phase commit, zabezpieczają
cego integralność bazy danych w przypadku transakcji realizo
wanej przez wiele serwerów baz danych;
• zastosow anie architektury wielowątkowej (ang. multithread
ing);
• w ykorzystanie rozwiązań m ultimedialnych;
• wysoki stopień bezpieczeństwa danych realizowany przez wielopoziomowy system praw dostępu i haseł oraz wykorzys
tanie stored procedures;
• w spółpraca z m aszynam i transakcyjnym i przez interfejs X /O pen - XA.
Spośród wymienionych cech na szczególną uwagę zasługuje możliwość określania więzów integralnościowych (ang. referen
tial integrity), cecha bardzo ważna, a rzadko jeszcze realizowana w SZRBD . Poczynając od wersji 5.0, serwer IN F O R M IX - -O nLine pozw ala dzięki im plem entacji pojęć klucza głównego (ang. primary key) i klucza obcego (ang .foreign key) relacji, na definiowanie pow iązań semantycznych między relacjam i (tab
licami). Zaw iera p o nadto konstrukcje, umożliwiające okreś
lenie tzw. reguł sem antycznych kluczy, definiujących w arunki towarzyszące niektórym operacjom na bazie danych. Dzięki nim m ożna określić, w jakich sytuacjach wolno np. dopisywać rekordy podrzędne lub kasow ać nadrzędne (w pow iązaniu master-detail) i narzucić akcje towarzyszące (np. kasowanie kaskadowe).
Serwer IN F O R M IX -O nL ine w wersji 5.01 zawiera również im plem entację tzw. mechanizm ów spustu (ang. triggering opera
tion). Są to konstrukcje umożliwiające definiowanie w arun
kowych akcji, „wyzwalanych” wybranym i operacjam i na bazie danych, przy czym spełnienie tych w arunków jest zależne nie tylko od struktury, ale także od bieżącej zaw artości tablic bazy danych.
I N F O R M IX -O n L in e /S e c u re
to serwer bazy danych IN F O R M IX -O nL ine o najwyższej istniejącej klasie bezpieczeństwa tj. klasie B \ według United States Department o f Defense ,, Orange B o o k" oraz klasy F 3/E 3 określonej przez European Information Technology Security Evaluation Criteria (ITSEC). Jest to pierwszy serwer bazy danych spełniający wym agania klasy bezpieczeństwa B \, który uzyskał stosow ny certyfikat U.S. National Computer Security Center (NCSC). IN FO R M IX -O nL ine/Secure współpracuje z systemami operacyjnym i o klasie bezpieczeństwa B \ (np.
U N IX System V Release 4.2 Enhanced Security), zapewniając bezpieczeństwo przez odpow iednią architekturę serwera bazy danych oraz wielopoziomowy system zabezpieczeń, wykorzys
tujący Discretionary Access Control i M andatory Access Con
trol. Należy nadmienić, że systemy operacyjne standardow o oferują użytkow nikom zaledwie klasę bezpieczeństwa C 2 (np.
SCO U N IX V/386 ver 3.2.4).
I N F O R M I X - S ta n d a r d E n g in e
to nie wym agający obsługi serwer bazy danych zalecany do baz m ałych i średnich, efektywny w systemach bez dużego o b ciążenia bieżącym przetw arzaniem transakcji.
6
Narzędzia do tworzenia oprogramowania użytkowego
D o tw orzenia oprogram ow ania w języku czwartej generacji IN F O R M IX -4 G L m ożna wykorzystywać kom pilator języka IN F O R M IX -4 G L generujący kod w ykonywalny oraz pakiet IN F O R M IX -4 G L R apid D evelopm ent System, składający się z kom pilatora języka IN F O R M IX -4 G L , generującego pseudo- kod, oraz z interakcyjnego interpretera pseudokodu. IN F O R - M IX -4G L R D S oraz program uruchom ieniow y (debugger) IN F O R M IX -4 G L ID składają się na doskonałe środow isko do tw orzenia oprogram ow ania użytkowego. Z a pom ocą tych dwóch narzędzi proces tw orzenia oprogram ow ania może się odbywać w sposób łatwy i szybki.
W ykorzystanie IN F O R M IX -4 G L R D S eliminuje długotrw a
ły proces kompilacji i konsolidacji program ów . Rzeczywista szybkość działania oprogram ow ania aplikacyjnego w spółdzia
łającego z IN F O R M IX -4 G L R D S w sposób nieznaczny ustępu
je szybkości działania wersji skom pilowanej. D latego też więk
szość oprogram ow ania użytkowego w języku IN F O R - M IX -4G L została napisana i jest eksploatow ana przy wyko
rzystaniu pakietu IN F O R M IX -4G L . W ielką zaletą IN F O R - M IX -4G L RD S jest to, że generowany przez ten pakiet pseudokod m ożna przenosić między różnym i kom puteram i i systemami operacyjnym i bez konieczności kompilacji, czego nie oferują inni producenci SZRBD . Z tej możliwości korzysta wiele firm tworzących oprogram ow anie użytkowe, obniżając w ten sposób swym klientom koszty niezbędnego o program o
wania narzędziowego, ponieważ na kom puterach użytkow ników może być instalow ane oprogram ow anie IN F O R M IX w wersji Runtime, którego cena stanow i od 30 do 70% ceny oprogram ow ania dostarczanego w pełnej wersji (Development).
Uzupełnieniem pakietu IN F O R M IX -4 G L R D S jest IN F O R - M IX -4G L /G X , będący interpreterem pseudokodu, umożliwia
jącym wykonywanie program ów napisanych w języku IN F O R - M IX -4G L w środow isku graficznym O penLook, O S F /M o tif i M S-W indows. Rozwiązanie to pozwala, aby jed n a wersja oprogram ow ania użytkowego napisanego w języku IN F O R - M IX -4G L była wykonyw ana zarów no w środow isku znak o wym, ja k i graficznym, bez konieczności zm ian w kodzie źródłowym oprogram ow ania.
W grupie narzędzi typu lower CASE, IN F O R M IX oferuje pakiety do generow ania pełnoekranow ych m enu (IN F O R - M IX -4G L M enus) oraz form atek ekranow ych (IN F O R - M IX -4G L Form s) wraz z kodem źródłow ym w języku IN F O R - M IX -4G L , szczególnie przydatne na etapie prototypow ania oprogram ow ania użytkowego.
D o grupy narzędzi do prototypow ania, a także łatwego i szybkiego tw orzenia prostych aplikacji, zaliczyć m ożna pakiet IN F O R M IX -S Q L . Jest to m oduł bardzo popularny w eks
ploatow anych zestawach oprogram ow ania IN F O R M IX , obej
mujący:
• interakcyjny edytor schem atów baz danych,
• interakcyjny edytor zdań języka SQL,
• generator i interpreter form atek ekranowych,
• generator i interpreter raportów ,
• generator menu.
Poza w spom nianym i pakietam i, do oprogram ow ania narzę
dziowego IN F O R M IX należą również następujące moduły:
IN F O R M IX -T P /T o lk it
to zestaw funkcji pozw alających na tworzenie i eksploatow anie oprogram ow ania napisanego w języku IN F O R M IX -4 G L , wy-
In fo r m a ty k a n r 8 , 1993 r.
i 4GL Client
i i i
4GL Application i
B u f f e r s -
Transaction M anager
INFORMIX-OnLine
=3 ! 4GL i Server
<5 — 1 Service A
§ J Service C
INFORMIX-OnLine or Printer Server
Rys. 1. Przykład zastosow ania m odułu IN F O R M IX -T P /T o o lK it pozwalającego na współpracę oprogram ow ania typu klient oraz oprogram ow ania serwera bazy danych z program ow ą m aszyną transakcyjną
korzystującego możliwości maszyn transakcyjnych oraz a r
chitektury klient-serwer. Przykład takiego rozwiązania został przedstaw iony na rysunku 1.
IN F O R M IX -O p e n C a s e /T o o lB u s
to kom pleksow e środow isko do tw orzenia oprogram ow ania, pozwalające n a integrację narzędzi typu CA SE innych p ro d u centów ze środowiskiem oprogram ow ania narzędziowego op ar
tego na języku IN F O R M IX -4G L (rysunek 2). Środowisko O penC ase/ToolB us zawiera:
• edytor program ów ,
• program Builder - narzędzie ułatwiające proces tworzenia i kom pilow ania program ów , których części pochodzą z różnych źródeł,
• Browser - narzędzie do przeglądania program ów ,
9 Development M anager - narzędzie do zarządzania realizacją systemu inform atycznego a jednocześnie mechanizm zarządza
nia poszczególnymi wersjami oprogram ow ania,
• pocztę elektroniczną w ykorzystującą oprogram ow anie ma
i k ,
• Tool M anager - narzędzie zarządzające dzałaniem powyż
szych modułów.
IN F O R M IX -O p e n C a s e /E n c a p s u la to r
to narzędzie umożliwiające integrację ze środowiskiem O pen
Case/ToolBus dodatkow ych produktów innych producentów , a tym samym korzystanie z jednolitego środow iska przy tw orzeniu oprogram ow ania użytkowego.
IN F O R M I X - 4 G L fo r T o o lB u s
to środow isko graficzne do tw orzenia oprogram ow ania użyt
kowego przy w ykorzystaniu języka IN F O R M IX -4 G L , um oż
liwiające w ykorzystanie narzędzi typu CASE przez interfejs O penC ase/T ool Bus.
IN F O R M I X - 4 G L R F
to oprogram ow anie narzędziowe pozw alające na tworzenie i eksploatow anie oprogram ow ania użytkow ego przeznaczone
go dla kom puterów przenośnych, wykorzystujących radiolinie ja k o łącza kom unikacyjne.
Język czwartej generacji IN F O R M IX -4 G L , o bardzo dużych możliwościach, pozwala napisać całą aplikację w tym języku.
Tym użytkow nikom , którzy z różnych pow odów preferują program ow anie w językach trzeciej generacji, IN F O R M IX oferuje pakiety IN F O R M IX -E S Q L , tj. język SQL zanurzony w języku trzeciej generacji (C, COBOL, F O R T R A N , ADA).
Rys. 2. Przykład zastosow ania w ybranego oprogram ow ania narzędziowego w spółpracującego z językiem IN F O R M IX -4 G L w ram ach jednolitego środow iska program ow ego IN FO R M D C -O penC ase/ToolB us
Produkty sieciowe
IN F O R M IX pozwala n a pracę w heterogenicznych sieciach kom puterow ych, obsługiwanych przez protokoły: TC P /IP , StarG R O U P , S P X /IP X , Pathway Access ( Wollongong). Baza danych IN F O R M IX może być rozproszona między kilka serwerów bazy danych, pracujących na różnych kom puterach z różnymi systemami operacyjnym i, w spółpracujących za po
m ocą różnych protokołów kom unikacyjnych (rys. 3). Integral
ność bazy danych zabezpiecza m.in. p ro to k o ł two-phase commit.
M ożliwa jest optym alizacja działania na bazie danych pod kątem minimalizacji obciążenia sieci. O program ow anie IN F O R M IX pracuje w architekturze klient-serwer, każdy z użyt
kow ników (klientów) może mieć dostęp do danych znajdują
cych się na dow olnym serwerze bazy danych.
W klasie produktów sieciowych IN F O R M IX oferuje dwa moduły:
I n fo r m a ty k a n r 8, 1993 r. 1
Rys. 3. Schemat rozproszonej bazy danych
I N F O R M IX -S T A R
uzupełnia możliwości serwera IN F O R M IX -O nL ine o obsługę rozproszonych baz danych, pozw alając na:
• rów noczesną pracę na kilku bazach danych zlokalizowanych na różnych serwerach w sieci,
• transakcje rozproszone, wykorzystujące p ro to k ó ł two-phase commit.
IN F O R M I X - N E T
uzupełnia funkcje serwera IN F O R M IX -S tan d ard Engine o możliwość połączenia ze zdalną, zlokalizowaną na innym serwerze sieci bazą danych, a w przypadku pracy z wykorzys
taniem architektury klient-serwer, umożliwia dostęp z kom- putera-klienta do rozproszonych baz danych.
Produkty dodatkowe
I N F O R M IX -T P /X A
to oprogram ow anie umożliwiające w spółpracę między serwe
rem bazy danych IN F O R M IX -O nL ine a m aszynam i tran sak cyjnymi z interfejsem spełniającym norm ę X /O pen X A , np.
T U X E D O System T ( U N IX System Laboratories), T op End (N C R ), Encine ( Transarc), U TM (Siem ens-N ixdorf), A IX /C IC S (IB M ). Zastosow anie takiego rozw iązania um oż
liwia przetw arzanie transakcji pochodzących z heterogenicz
nych, rozproszonych baz danych, pracujących na różnych kom puterach, z różnym i m aszynam i transakcyjnym i. W yko
rzystanie m aszyn transakcyjnych pozwala zw ielokrotnić szyb
kość przetw arzania transakcji.
IN F O R M IX -O n L in e /O p tic a l
to oprogram ow anie pozwalające na wykorzystywanie przez serwer bazy danych IN F O R M IX -O nL ine optycznych jednos
tek dyskowych.
I N F O R M I X - D a ta E x tr a c t
to interfejs umożliwiający dostęp ze środow iska IN F O R M IX do następujących systemów zarządzania bazam i danych: DB2, SQ L/D S, IM S/D B , D L /I, ID M S, A DABAS, T O TA L, S U P
RA, M O D E L 20, D A T A C O M /D B oraz plików typu VSAM i SAM .
W IN G Z
to graficzny arkusz kalkulacyjny, współpracujący z serwerami baz danych IN F O R M IX . Rdzeniem pakietu W IN G Z jest H yperScript - język program ow ania przeznaczony do tworze
nia aplikacji graficznych oraz do budow y graficznych interfej
sów użytkowników.
8
Nowe elementy
strategii firmy INFORM IX
Od dw óch lat firm a IN F O R M IX realizuje now ą strategię, zm ierzającą do całkowitej otw artości i elastyczności oprog
ram ow ania. Jej głównymi elem entam i są:
• udostępnianie producentom oprogram ow ania narzędziowe
go (w tym typu CASE) otw artego, dobrze zdefiniowanego interfejsu O penCase/ToolBus do oprogram ow ania IN F O R M IX,
• w spółpraca z program ow ym i m aszynam i transakcyjnym i dla serwerów baz danych IN F O R M IX -O nL ine, ja k również oprog
ram ow ania narzędziowego pozwalającego korzystać z hetero
genicznych rozproszonych baz danych, pracujących z różnymi m aszynam i transakcyjnym i na różnych kom puterach z różnymi systemami operacyjnymi.
Powyższe podejście zaow ocow ało szeroką ofertą oprogram o
w ania typu CASE, w spółpracującego z oprogram ow aniem IN F O R M IX , np.: U N IF A C E (Uniface Corporation), ISEE (W estm ount), RO SI-SQ L (H alstenbach G m bH ), PowerBuilder (Powersoft Corporation), ObjectView 2.0 (M atesys Corpora
tion), Q + E D atabase E ditor i Q + E D atabase L ibrary (Pioneer Software) itd. W ykorzystanie program ow ych m aszyn tran sak cyjnych spełniających interfejs X /O pen X A , zarów no przez serwer bazy danych IN F O R M IX -O nL ine, ja k i przez oprog
ram ow anie narzędziowe IN F O R M IX -4 G L , stw arza zupełnie nowe możliwości w zakresie rozproszonych baz danych. R oz
wiązanie takie pozw ala, aby korzystając z oprogram ow ania IN F O R M IX , wykonać „globalną” transakcję obejm ującą hete
rogeniczne rozproszone bazy danych, pracujące na różnych m aszynach transakcyjnych (spełniających interfejs X /O pen XA).
M am y nadzieję, że przedstaw ione inform acje pozwolą na skorygowanie i zweryfikowanie wielu danych dotyczących oprogram ow ania IN F O R M IX . Być może posłużą również jak o asum pt do przeprow adzenia własnych rzetelnych analiz porów nawczych.
LITERATURA
[1] Dokumentacja wersji 5 i wersji 4.10 oprogramowania INFORM IX [2] Fleming C.C., von Halle B.: Handbook o f Relational Database Design.
Addison-Wesley Publishing Company, 1990 [3] Kwartalnik INFORM IX Times
[4] Materiały informacyjne firmy INFORM IX Software, Inc.
Wskazówki dla Autorów
N ad syłane artykuły nie m ogą być publikow ane lub przeznaczone do opu blikow an ia w innych czasopism ach.
M ateriał oprócz tekstu zasadniczego pow inien zawierać:
* królki życiorys zaw od ow y A utora i jeg o zdjęcie,
* wykaz literatury,
* tabele.
* materiał ilustracyjny (rysunki, zdjęcia czarno-białe, wydruki) dołą
czony d o artykułu (nie wklejać m ateriału w tekst),
* podpisy pod ilustracje.
N a osobnej stronie prosim y podać: tytuł nau kow y, nazw isko i imię.
nazwę zakładu pracy, numer telefonu słu żb ow ego oraz inform ację, jaka drogą przekazać honorarium - kasa W ydaw nictw a, poczta, konto.
W zw iązku z naliczaniem podatku d o ch od ow ego prosim y także podać:
* oprócz nazwiska i im ienia - także drugie imię,
* im iona rodziców .
* datę i miejce urodzenia,
* numer identyfikacyjny PESEL,
* miejsce zam eldow ania,
* adres U rzędu Skarbow ego w łaściw ego dla miejsca zam ieszkania Autora.
In fo r m a ty k a nr 8 , 1993 r.
TADEUSZ WITKOWSKI
Kombinat Przemysłu Narzędziowego VIS Warszawa
Komputerowe wspomaganie decyzji o zakupie produktu
K om puterow e w spom aganie podejm ow ania decyzji coraz częściej jest stosow ane w różnych dziedzinach życia gospodar
czego i adm inistracyjnego. D otyczy to również poszczególnych etapów związanych z projektow aniem , wytwarzaniem oraz ekonom iczną analizą opłacalności produkcji wyrobów. W ar
tykule zostanie rozpatrzony system modeli kom puterow ego w spom agania podejm ow ania decyzji o zakupie p ro d u k tu w for
mie przetargu. Obejm uje on zarów no modele przeznaczone do wstępnej, ja k i ostatecznej analizy za pom ocą przybliżonej oraz dokładnej oceny. Proces w yboru p ro d u k tu uwzględnia przy tym zachowanie się na poszczególnych etapach tego procesu zarów no analityka, ja k i grupy decydentów, z uwzględnieniem aspek
tów psychologicznych podejm ow ania decyzji, podczas rozmów handlow ych dotyczących technicznych i ekonom icznych wa
runków zakupu.
Proces podejmowania decyzji o zakupie produktu
Proces podejm ow ania decyzji o zakupie p roduktu [5] składa się z pięciu etapów:
• uświadomienie problem u,
• poszukiwanie informacji,
• ocena w ariantów,
• decyzja o zakupie,
• reakcja n a zakup (rys. 1).
Rys. 1. Proces podejm ow ania decyzji o zakupie produktu
W większości przypadków przy podejm ow aniu decyzji ku p u jący (np. przedsiębiorstwo) rozpatruje wszystkie etapy procesu decyzyjnego związanego z zakupem produktu, zwłaszcza wtedy, gdy spotyka się z nową sytuacją.
Proces zakupu p ro d u k tu rozpoczyna się od tego, że kupujący uśw iadam ia sobie problem , czy też potrzebę zakupu. P o d stawowym etapem tego procesu jest poszukiwanie informacji, w którym kupujący może korzystać z następujących źródeł informacji: pryw atnych, handlow ych (ogłoszeń, wystaw) oraz źródeł ogólnodostępnych.
W wyniku zbierania informacji w zrasta stopień uświadom ie
nia (zorientowania) kupującego na tem at istniejących na rynku różnych m arek produktów oraz ich właściwościach. N a p o d stawie zebranych informacji powstaje pełny zestaw dostępnych dla kupującego m arek produktów , zawierający znacznie więcej elementów, niż zestaw pow stały n a etapie uśw iadom ienia p ro blemu o zakupie. Z ebrane informacje poszerzają zbiór do
In fo r m a ty k a n r 8, 1993 r.
pełnego zestawu, a za pom ocą dodatkow ej inform acji kupujący tworzy tzw. zestaw w yboru (rys. 2), z którego zostanie ostatecz
nie w ybrana najlepsza alternatyw a zakupu.
Rys. 2. K olejność tworzenia zestawu alternatyw m arek p ro d u k tu w procesie podejm ow ania decyzji o zakupie
D okonując w yboru kupujący, po pierwsze, rozpatruje p ro d u k t ja k o określony zestaw charakterystyk, przy czym różni k u pujący różnie oceniają ich przydatność; po drugie, jest on skłonny określać różne w skaźniki ważności (wagi) tych ch arak terystyk, które uważa za najbardziej przydatne; po trzecie, ja k o użytkow nik jest skłonny tworzyć zbiór własnych przekonań (obraz marki); po czwarte, dla każdej charakterystyki określa on funkcję użyteczności, przy czym funkcja ta przedstaw ia stopień oczekiwanego usatysfakcjonow ania użytkow nika przez posz
czególne właściwości produktu; po piąte, opinia o poszczegól
nych alternatyw nych m arkach p ro d u k tu pow staje u kupującego dopiero w wyniku przeprow adzonej przez niego dokładnej analizy.
O cena alternatyw poszczególnych m arek p ro d u k tu prowadzi do ich uporządkow ania w zestawie wyboru. U użytkow nika powstaje zam iar realizacji zakupu, przy czym dotyczy on najbardziej priorytetow ej m arki. Jednak na ten proces podej
m ow ania decyzji m ają wpływ różne czynniki (inhibitory) [3], takie np. ja k stosunek innych ludzi uczestniczących w procesie decyzyjnym, a także wpływ nieprzewidzianych okoliczności.
Schemat wyboru
marki produktu w przetargu
Przedstaw iony proces podejm ow ania decyzji o zakupie p ro duktu w formie przetargu w postaci wielokryterialnej, wielo
etapowej procedury kom puterow ego w spom agania decyzji [9]
składa się z następujących faz:
• podjęcie decyzji o zakupie niezbędnego p ro d u k tu (maszyn, m ateriałów itp.) przez przedsiębiorstwo,
• analiza potencjalnych dostawców produktu,
• przygotow anie i dostarczenie potencjalnym dostaw com za
pytań ofertowych,
• przeprow adzenie wstępnej analizy ofert przez analityka,
• rozm ow y handlow e dotyczące w arunków technicznych i eko
9
nom icznych dostaw y z wybranym i wstępnie dostawcam i,
• przeprow adzenie szczegółowej analizy ofert przez analityka,
• preferencyjne uporządkow anie ofert na radzie technicznej przedsiębiorstw a przez grupę decydentów,
• w ybór dostawcy p ro d u k tu i podpisanie kontraktu.
Podczas analizy i w yboru dostawcy nie zawsze trzeba wyko
nać po kolei wyżej przedstaw ione etapy, a w szczególnym przypadku możliwe są pow roty do etapów rozpatrzonych wcześniej.
Rys. 3. Schemat przepływu ofert podczas procesu decyzyjnego wyboru najlepszej oferty w przetargu
Rozpatrzm y system przepływu ofert podczas przeprow adza
nia i analizy procesu decyzyjnego o zakupie w w arunkach przetargu (rys. 3). System przedstawiający strukturę zbierania i przetw arzania informacji w tym zadaniu m ożna opisać w na
stępujący sposób:
v, - ogólna liczba ofert przedstaw ionych do przetargu, v2 - liczba ofert analizowanych wstępnie,
v3 - liczba ofert wyeliminowanych na etapie wstępnej oceny z pow odu oczywistej niekonkurencyjności przedstaw ionych w nich charakterystyk p roduktu (np. cena, czas realizacji zam ówienia itp.),
v4 - liczba ofert podlegających szczegółowej analizie,
v5 - liczba ofert, przekazanych oferentom w celu przedstaw ienia dodatkow ych informacji (dopracow ania ofert),
v6 - liczba ofert przekazanych do zatw ierdzenia przez organ zarządzania wyższego szczebla,
v7 - liczba ofert wyeliminowanych na etapie szczegółowej analizy, w których podane charakterystyki p ro d u k tu są mniej priorytetow e niż określone przez zbiór v6,
v8 - liczba ofert, wyeliminowanych na końcowym etapie podej
m ow ania decyzji,
v9 - liczba ofert, zatwierdzonych i wybranych ostatecznie przez organ zarządzania wyższego szczebla,
v10 - liczba ofert rozpatrzonych przez organizatora przetargu, v0 - liczba zapytań ofertowych, na które nie otrzym ano ofert, v00 - liczba zapytań ofertowych wysłanych dodatkow o do
sprzedawców na etapie analizy wstępnej, szczegółowej i k o ń cowej.
Załóżmy, że dla decydenta (kierownika przedsiębiorstwa), który m a rozwiązać problem w yboru w yposażenia techno
logicznego, najważniejszym kryterium jest cena produktu. D ru gim pod względem ważności kryterium jest odporność tego w yposażenia na zm iany technologii i asortym entu wytwarzanej produkcji, a więc cechy charakteryzujące elastyczność w za
kresie organizacji produkcji. Cechy charakteryzujące k onstruk
cję oraz wydajność wyposażenia, chociaż uwzględniane przez decydenta, są kryteriam i mniej ważnymi. Załóżm y ponadto, że dla każdego z wyżej przedstaw ionych czterech kryteriów decy
dent jest w stanie określić odpowiednie skale preferencji, pozwalające łatw o i szybko ocenić każdą z przedstaw ionych ofert, których może być kilkanaście. T aki zbiór ofert w dalszych rozważaniach nazwiemy A c. Załóżm y także, że na podstawie jakości posiadanej informacji decydent dochodzi do wniosku, że konstruow anie funkcji użyteczności jest niecelowe, ponieważ zajęłoby to m u stosunkow o dużo czasu. W takim przypadku decydent może zadowolić się podejściem, będącym początko
wym przybliżeniem rozwiązywanego problem u, np. wykorzys
tując relację przewyższania (dominacji) [7].
Wstępna ocena alternatyw przez analityka
Zaletą przedstawionej niżej m etody wykorzystującej relację przewyższania jest jej przystosow anie do oceny dużej liczby w ariantów (np. kilkudziesięciu). Jest to szczególnie istotne na etapie wstępnego rozpatrzenia ofert, gdyż um ożliwia utworzenie bardziej reprezentatyw nego pełnego zestawu m arek p roduktu [5],
Rozpatrzm y parę dopuszczalnych alternatyw nych decyzji (a', a"), odpow iadających w tym problem ie w yboru ze zbioru A c dwom różnym w ariantom wyposażenia. Z biór kryteriów I, składający się w rozpatryw anej sytuacji z czterech kryteriów, m ożna w ogólnym przypadku podzielić na następujące trzy klasy:
I + (a', a " ) - podzbiór kryteriów , na podstaw ie których w ariant a' dom inuje nad a",
r (a', a") - podzbiór kryteriów, na podstaw ie których w ariant a' jest rów now ażny a",
I~(a', a") - podzbiór kryteriów , n a podstaw ie których w ariant a" dom inuje nad a'.
Załóżmy, że m ożna określić względną ważność każdego z tych trzech podzbiorów zbioru kryteriów I, a także, że dla każdego takiego podzbioru m ożna sform ułow ać nowe kryterium , będące w ypadkow ą wszystkich kryteriów wchodzących do danego podzbioru.
Niech P + (a\ a"), P = (a a " ) , P~ (a', a") - trzy liczby (analo
giczne do ich wag) przedstaw iające względną ważność tych trzech podzbiorów . Inform acja ta jest podstaw ą do skon
struow ania relacji dom inacji (przewyższania).
N astępnie konstruuje się jedno lub kilka w arunków typu C [/> + (a\ a"), P m (a', a"), P~ (a\ a ")] > c, (1) takich, że relacja a 'R a" nie jest spełniona, jeżeli para a', a" nie spełnia tych w arunków.
Lewa część w arunku (1) jest interpretow ana ja k o wskaźnik zgodności - tj. stopień zgodności między ocenam i na podstawie
1 0 I n fo r m a ty k a n r 8 , ¡9 9 3 r.
