Informasjonsintegrasjon – hva er utfordringene
•Download as PPTX, PDF•
0 likes•841 views
The document discusses the challenges of information integration. It notes that while XML is useful for defining protocol elements, it does not provide semantics on its own. Any XML document defining protocol elements must also include clear prose describing the semantics and meaning. The document also shows examples of XML schema definitions and compares different data models for their ability to represent concepts and relationships.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Recently uploaded
Recently uploaded (20)
Informasjonsintegrasjon – hva er utfordringene
- 1. Informasjonsintegrasjon – hva er utfordringene? Stian Danenbarger <stian@bouvet.no> Rådgiver, Bouvet ASA Twitter: @stidan
- 2. EII
- 3. ?
- 8. Begrep/ konsept Referent/ Term/ objekt symbol
- 10. Konseptet ‘representasjon av begrepet’ <element name="foo"> <oneOrMore><choice> <element name="bar"><text/> </element> <element name="baz"><text/> </element> </choice></oneOrMore> </element> <!ELEMENT foo ( bar | baz)* > Begrep/ <xs:complexType name="foo"> <xs:choice minOccurs="0"> konsept maxOccurs="unbounded"> <xs:element name="bar"/> <xs:element name="baz"/> </xs:choice> </xs:complexType> Referent/ Term/ objekt symbol
- 11. #%*¤! KONSENSUS!
- 15. XML XML “While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics.” XML “Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.” RFC 3470, “Guidelines for the Use of XML within IETF Protocols” January 2003 XQuery
- 19. 70% 60% 70% 95% 70% modell 1 30% modell 2 80% 40% 90%
Editor's Notes
- EII (Enterprise Info. Integr.) er ikke et nytt begrep. Noen mener begrepet ble første gang ble gjort allment kjent av analytikerfirmaet Standish Group i 2002*), mens andre refererer til løsninger utviklet på det sene 90-tallet. Det tidligste artikkelen jeg har funnet om distribuerte spørringer over databaser er fra 1981…**) *) http://www.cs.washington.edu/homes/alon/files/eiisigmod05.pdf **) P. A. Bernstein, N. Goodman, E. Wong, C. L. Reeve,and J. B. R. Jr. Query processing in a system fordistributed databases (sdd-1). ACM Trans. DatabaseSyst., 6(4):602{625, 1981
- Fra starten var målet med EII å muliggjøre såkalte «fødererte» spørringer over data fra multiple kilder i tilnærmet «sann tid» - altså uten å gå den lange veien om å ekstrahere, transformere og laste alle dataene inn inn i et datavarehus. Man utformet typisk et «virtuelt» skjema å spørre mot, basert på en felles, såkalt «kanonisk» datamodell for virksomheten. EII-løsningene håndterte reformuleringen av spørringene til hver kilde, og var gjerne enten basert på relasjonsbase-teknologi, eller sentrert rundt XQuery og XML – altså mer strukturerte spørringer enn søkemotorer tradisjonelt har vært i stand til…
- Behovet for å sammenstille («integrere») data er selvsagt ikke nytt. De fleste av dere har sikkert hatt befatning med løsninger for sammenstilling av strukturerte data: Delte databaser, datavarehus…og ikke minst manuelt! Alle kjenner vel fortsatt til «integrasjonsløsninger» der stressede kundebehandlere henter ut data fra ulike kilder og klipper og limer sammen noe i full fart…!
- Behovet for II har ikke akkurat minsket de senere årene, for å si det mildt..: Én ting er den eksponensielle veksten av mengden informasjon – både strukturert og ustrukturert – som innebærer en dobling hvert 2,3 år.De konkurransemessige kravene til raske omstillinger, sammenslåinger og muligheten til å inngå i nye konstellasjoner med andre virksomheter økerSosiale medier og søkemotorer øker de ansattes forventninger til sømløs deling og sammenstillingSamfunnets krav til virksomhetens juridiske etterrettelighet øker…Samtidig sier Forrester at oppmerksomheten rundt dagens kommersielle EII-løsninger har avtatt…!
- EII lover et kjapt og fleksibelt tjenestelag som i tilnærmet sann tid kan besvare vilkårlige spørringer over heterogene kilder, strukturert eller ustrukturert, distribuert over hele selskapet – og kanskje til og med utenfor? Kan bygge tjenester over denne, og realisere «Sømløs virksomhet»… What’s not to like?!?
- Informasjonsintegrasjon er selvsagt et område som er fullt av utfordringer – mange opplagte – og det ville føre for langt å gå inn på alle her. MEN…Min sterke påstand er at et underliggende misforhold mellom menneskelig symbolbruk, EIIs intensjoner og ÉN implementasjonsmessig antakelseer årsak til mange av utfordringene, og dette resulterer i systemer som er unødig rigide og dyreimplementasjons- og forvaltningsmessig. Dette igjen bidrar til dårligere datakvalitet, og til svekkede muligheter til å styre virksomheten etter sanntidsdata. Vi ser at kostnadene og kompleksiteten så langt har hindret mange virksomheters EII-initiativer, selv om besparelsene kan være enorme.Etterpå skal vi vise hvorfor vi er så stolte av hva vi har fått til i Hafslund.
- For å underbygge påstanden vil jeg først introdusere den såkalt «Ogdens trekant», som er en visuell framstilling av en sammenheng allerede beskrevet av Aristoteles – sammenhengen mellom et fysisk objekt og informasjonsobjektet som representerer det – for eksempel et skilt eller et ord brukt i dagligtale… I og utenfor en organisasjon:Samme referent – ulik konseptuell forståelseUlik forståelse gir ulik symbolbrukForståelsen og symbolbruken varierer over tid, med kontekst, fra individ til individ…
- Begrepet «rød» - men for hvem? MegEn kunstnerEn forsker som analyserer fargespektreBegrepet «kunde» – men for hvem?…Og ikke minst alle relasjonene mellom begrepene…
- Det blir ikke bedre når vi skal kodifisere begrepene og relasjonene på metanivå – som når vi skal representere dette i relasjonsbaser, UML eller XML…Ikke rart representasjonene blir forskjellige i de ulike systemene… (tre ulike eksempler til høyre)
- …Men kan vi ikke bare standardisere begrepene eller relasjonene, eller komme fram til en konsensus…?Ressurskrevende!Tar laaaang tid (år) – i praksis alltid etterslep i forhold til faktisk brukInnen man er enige, er enigheten allerede utdatertFortolkningen av symbolene og representasjonene varierer – over tid, med kontekst, fra individ til individ… Opplevd rigiditet leder blant annet til «kreativ» og inkonsistent bruk av registreringsfelter – én viktig årsak til lav datakvalitet – og sammenstilling på feil premisser…
- Jeg nevnte et underliggende misforhold mellom menneskelig symbolbruk ogÉN implementasjonsmessig antakelse – på engelsk kalt:«the Closed World Assumption" *)CWA er en underliggende antakelse som gir en ekstrem forenkling av verdens kompleksitet og tvetydighet, og også en riktig forenkling for mange implementasjonsformål…:Antar at settet av entiteter og relasjoner er komplett (bøkene i et bibliotek, passasjerene på et fly)Omvendt: Entiteter og relasjoner som ikke er eksplisitt representert antas å ikke eksistereNavn antas unikt identifiserendeEtt predefinert skjema definerer skopet og tolkningen av domenet – må kun sjekke sjekke den ene modellens struktur for å besvare en spørringUlemper:Rigiditet: Ikke egnet for hyppige, inkrementelle utvidelser av ufullstendig og irregulær informasjonmed ulik struktur, som når man sammenstiller fra mange kilder (NULL og OPTIONAL er primitive workarounds) …Tette bindinger: Ett felles skjema krever konsensus og resulterer i omfattende koordineringskostnader og betydelig risiko (systemendringer må gjøres synkront)...Effektivt eksekveringsmessig - ineffektivt implementasjons- og forvaltningsmessig*) Raymond Reiter, 1978. “On Closed World Data Bases”, Logic and Data Bases, H. Gallaire and J. Minker, eds., New York: Plenum Press, 55-76
- Klassisk eksempel på CWA:Relasjonsmodellen: SQL og relasjonsbaser - som transaksjonssystem og for modellering av svært avgrensede, strukturerte domener - eksepsjonelt vellykket i virksomhetssammenheng. Velprøvd og optimalisert. Naturlig å forsøke å overføre en vellykket tilnærming til andre områder...Delt relasjonsbase («mini-EII»):Ett felles, delt skjema som må forhåndsdefineresSammenhengen mellom det modellerte domenet og skjemaet er implisitt - i beste fall dokumentert for utviklereTett kopling mellom data og skjemaAvgrenset, strukturert domene ("CWA" og identitet, relasjoner, NULL)Proprietær, ofte begrenset støtte for ustrukturert informasjon, f.eks. gjennom nøkkelordsøkLagrer data - ikke informasjon (eksempel tall -> saldo). Domenespesifikk kontekst og relasjoner svært begrenset, eller mangler. Kontekstuell tolkning overlatt til applikasjonsutviklerne(!)ETL - ikke sanntid (støttet i noen nyere løsninger), spørringer mot foreldede dataOR-mappinger må kodes om ved hver endring ("rippeleffekt")Synkron koordinering: Semantikken uttrykkes i forretningslogikken. Endringer som påvirker det delte skjemaet krever omfattende manuell innsats, nedetidUlemper:Tid (endringer krever tidkrevende synkron koordinering)Kost (endringer krever kostbar synkron koordinering)Kvalitet (oftest utført av utviklere med svakere kontekstforståelse enn domeneeksperter)
- Fødererte SQL-spørringer over distribuerte relasjonsbaserTilnærming: Ett felles, "virtuelt" ("mediert") skjema, reformulerer til spørringer over datakildeneStrukturell («syntaktisk»), skjemasentrisk integrasjon av data – dyrt ved endringer ("rippeleffekt"), nye kilder (lineær kost, burde falle…?)Tette, strukturelle koplinger, avhengighet mellom produsent og konsumentUlemper og fordeler langt på vei samme som for delt relasjonsbase (over), men i tilleggOmfattende koordineringskostnader (endringer må gjøres synkront). Semantikken uttrykkes i forretningslogikken. Endringer som påvirker det delte skjemaet krever omfattende manuell innsats, nedetid
- Fødererte XQuery-spørringer over distribuerte kilder som kan generere XMLXML: Generisk enkodingStandard dokumenttyper gir (grovkornet) kontekst, OK for statiske, høyvolumstransaksjoner mellom kjente aktørerHva med referering til entiteter utenfor dokumentkonteksten ("den virkelige verden")?Hva med mange-til-mange-relasjoner? (Navnerom og modularisering gir mer finkornet kontekst, hvor kanskje enkeltutsagn kan sies å være en logisk konklusjon?)Ulemper med XQuery og XML som basis for EII:Som for (fødererte) relasjonsbaser...!Ytelse og skalering. Tidlig eksempel: Kryssdatabase-join av to enorme tabeller, konv. til XML (3x større), så sende over nettet, XQuery-prosessorer ikke optimale… Bør minimere datatrafikk!
- …Men hva med Datavarehus, BI…?Fordel for datavarehus:Persistering å foretrekke framfor virtualisering når kildene av en eller annen grunn ikke er direkte tilgjengelig, eller når det er behov for å ta vare på historikkUlemper som delte relasjonsbaser, men i tillegg:Ekstra dyrt å sette opp, ekstra dyrt å forvalte
- …Men hva med søkemotorer…?Datamodellene er i praksis dokumenter med attributter («skjema»), samt én eller flere taksonomier – termsett som er ordnet hierarkisk – for å støttefasettert søkInformasjonsmodellene forvaltes i praksis under CWA (navn unikt identifiserende, representasjon innebærer eksistens -> én kanonisk datamodell)Endringer i modellene enklere enn relasjonsbaser, men kan krevetidkrevendereindekseringOfte relativt begrensede spørrespråk, men stadig bedre…Stort potensiale – begrenses av proprietære datamodeller og spørrespråk, CWA – men lovende utvikling hos noen leverandører…
- …Hva med integrasjon – EAI,skreddersydd «punkt til punkt» og «hub and spoke»…?Integrasjon er "rørleggervirksomhet" - en nødvendig, men ikke tilstrekkelig forutsetning...Ofte skreddersydde adaptere (semantikken nedfelt i logikk som kun utviklere kan tolke) - dyrt å implementere, dyrt å vedlikeholde, svak forvaltningKodifiserer "hvordan", ikke "hvorfor"...«…Med nok kode kan jeg integrere alt!» - men så endrer noe seg (Sisyfos…)Proprietære, leverandøravhengige løsninger
- I "hub and spoke" ble kanoniske datamodeller etterhvert vanlige - all mapping via denne -> betydelig tap av betydning (semantikk), selv om man operererte med mer enn én modellhttp://enterpriseintegrationpatterns.com/CanonicalDataModel.html
- Integrasjon: SOA/ESB (evt. m/BPM)Videreutvikling av EAI - lover mer dynamisk "røropplegg"...Data er usynlige tupler i "kjelleren" - nye data isoleres i lageneWS kan gi løsere koplinger (dokumentbaserte/hendelsesbaserte meldinger), men dette hjelper ikke mottaker til å forstå - krever:skreddersømorganisatorisk enighet (endringer har lang tidskonstant), ellerstandarder (endringer har veldig lang tidskonstant...)Avansert SOA benytter CIM og "kanonisk skjema» – fortsatt CWA
- Er vi dømt til «gummisålenettverk" og manuell informasjonsintegrasjon (aka "dreiestolintegrasjon") for å besvare vilkårlige spørringer over heterogene kilder? :-) Fordeler:"Fuzzy logic" :-)Kontekstforståelse (hvis utført av domeneeksperter)Ulemper:TidKostKvalitetFortsatt vanlig EII-metode for legacy-systemer uten egnede APIer og med logikk og datadefinisjoner som få i organisasjonen forstår...
- Eksponensiell vekst av mengden informasjon – både strukturert og ustrukturert.Økt konkurranse krever raske omstillinger, sammenslåinger og muligheten til å inngå i nye konstellasjoner med andre virksomheterDe ansattes forventninger til sømløs deling og sammenstilling økerKravene til virksomhetens juridiske etterrettelighet økerEII lover et kjapt og fleksibelt tjenestelag som i tilnærmet sann tid kan besvare vilkårlige spørringer over heterogene kilder, strukturert eller ustrukturert, distribuert over hele selskapet. Kan bygge tjenester over denne, og realisere «Sømløs virksomhet»…
- Min påstand er altså at systemer basert på CWA er fornuftig og riktig for komplette domener, men ineffektivt implementasjons- og forvaltningsmessigfor EIIKonsekvensene er unødig høye kostnader ved endring eller samhandling med andrefortsatt lav datakvalitet,fragmentert og forsinket operasjonell styringsinformasjon, ogtapte automatiseringsmuligheter…!Puh! Nok problemfokus… Etterpå skal vi vise hvorfor vi er så stolte av hva vi har fått til i Hafslund. Følg med, følg med, …!