De perfecte documentatie

Omdat de eerder aangeschreven controleorganismen niet reageerden (zie actieplan) ben ik zelf een stap verder gegaan door een zoektocht naar de ideale documentatie aan te vatten.

De naar mijn mening optimale documentatie voor de doelstellingen die gesteld zijn heb ik gevonden. Op dit ogenblik bestaat deze uit een oplossing die gebruik maakt van actuele concepten en technologie (2008).

Toepassingsgebied voor de oplossing

Het niveau waarop een oplossing kan inwerken wordt hierna voorgesteld aan de hand van de ANSI/SPARC architectuur:

Het externe niveau wordt ons opgelegd.

We proberen een vertaalslag naar het conceptuele niveau te maken aan de laagst mogelijke kost.

Eén van de mogelijkheden die verder besproken worden heeft te maken met een universele ontologie. Indien deze kan gerealiseerd worden zal de vertaalslag voor alvast die norm komen te vervallen.

Het conceptuele niveau is het toepassingsgebied van dit document.

Het is tevens het niveau dat naar mijn ervaring meestal ontbreekt.

Het datamodel op dit niveau wordt het conceptuele datamodel genoemd, ook nog het logische datamodel (met logisch wordt fysisch bedoeld binnen ORM) of het relatiemodel.

Dikwijls gebruikt de functionele analist tegen beter weten in de fysische architectuur als een conceptueel datamodel.

In feite wordt het functionele zakelijke gebeuren slaaf van het fysische IT-gebeuren.

Wegens zijn eigen laksheid zal de deur van het functionele naar het fysische niveau gesloten blijven voor het conceptuele niveau. Wanneer dit conceptuele gebeuren ontbreekt zal het fysische niveau rechtstreeks met het externe niveau onderhandelen over de te leveren prestaties. Op intern vlak blijft het fysische niveau verweest en doelloos achter.

Het fysische niveau heeft te maken met de effectieve database systemen waarin de gegevens opgeslagen worden. Het fysische datamodel is bij uitzondering volledig gelijk aan het conceptuele.

De reden is dat op fysisch niveau andere criteria hanteert dan het conceptuele niveau. Performantie is het primaire criterium.

Een doorgedreven generiek model vormt een contradictie met performantie.

Een opslag van instantiëringsdata bij object oriënted data-approach vormt een contradictie met performantie.

Om performant te blijven op fysisch niveau worden variabelen geoptimaliseerd die niet conceptueel zijn. Onder andere:

o de database organisatie: relationeel, hiërarchisch, netwerk of object-georiënteerd

o de topologie van de database: centraal, gedistribueerd, federaal,…

o het toegangsprofiel: aanmaak, onderhoud of gewone opvraging van de gegevens (bij data warehouses bvb)

o gegevensprofielen: statistieken welke en in welk aantal de gegevens worden opgevraagd

o de fysieke kenmerken van de database

o het database management systeem (DBMS)

o de fysische verbinding met de database

o de protocollen van die verbinding

o de rechten die toegekend zijn binnen het DBMS aan de gebruiker

Conceptuele types kunnen samengebracht in sets en gemapped naar een fysisch niveau gevolgd door een gecontroleerde denormalisatie en de toevoeging van indexen.

Binnen de doelgroep van gebruikers staat het buiten kijf dat een instantiëring van de gegevens in overeenstemming met de klassen waartoe een gegeven behoort onmogelijk is.

De reden is dat de hoeveelheid gegevens gewoon te groot is om dergelijke opzet te overwegen.

Doelstelling

Zoals uit de eerdere pagina’s bleek is er een nood tot het modelleren en documenteren van producten, processen en procedures. Vooral wanneer er informatica-investeringen verbonden zijn aan de activiteiten.

Dit om te komen tot een werkbaar instrument om de controle op de processen, risico’s en kosten te behouden.

Vooral op het vlak van de levering van immateriële diensten is hier een lacune vast te stellen, met sommige spectaculaire maar ook algemeen maatschappelijk nefaste gevolgen.

De kredietcrisis is de laatste in een lange rij financiële crisissen die alleen in grootte mekaar naar de loef steken.

Criteria

We zoeken dus in feite een documentatie (en bij uitbreiding rapportering-) methode.

Deze moet aan volgende criteria voldoen:

l Een gegevensmodel bevatten

l Generiek zijn opgevat: aanpasbaar aan nieuwe/gewijzigde inhoud

l Documenteren en beschrijven van producten, risico's, processen, algoritmes en procedures

l Onmiddellijke toegang tot de informatie door personen en IT-systemen mogelijk maken

l Grafische voorstelling van de inhoud mogelijk maken.

In onze zoektocht zijn we gestoten op een paar mogelijkheden daartoe.

Verrechtvaardiging

Waarom een (generiek) datamodel als documentatiemethode gebruiken ?

Op het niveau van het conceptuele dient men generiek te werken om :

l Duidelijk te specificeren

l Niet permanent in wijzigingen van het model te vervallen die uiterst kostbaar zijn

l Nieuwe ontwikkelingen, zowel in de buitenwereld als intern, soepel op te vangen

l De middelen en hun gebruik kunnen in een schema weergegeven worden.

l Dit schema wordt een conceptueel datamodel wanneer er tabellen kunnen aangemaakt worden op basis van het model.

l Vermits een ander datamodel op fysisch niveau bestaat waar men de effectieve instanties opslaat zal dit conceptuele datamodel dienen als testmodel voor de functionele behoeften die uitgedrukt werden.

l Testen kunnen gebeuren op basis van aanwezige data in data warehouses of andere bronnen uit productie-omgeving.

Waarom een taxonomie gebruiken ?

Een gedefinieerd concept wordt steeds verder verfijnd tegenover zijn supertype.

Vb. -Een mens is een fysisch object
-Een Europeaan is een mens die op het Europese continent gewoonlijk verblijft
-Een Nederlander is een Europeaan die zijn voornaamste woonplaats in Nederland heeft of van Nederlandse nationaliteit is.

Daardoor:

ü Kan een heel precieze definitie gegeven worden omdat de niveaus van specialisatie in principe onbegrensd zijn.

ü Worden de eigenschappen en hoedanigheden van alle bovenliggende types geërfd door de onderliggende

ü Wordt de definitie voor iedereen binnen het domein beschikbaar

ü Kan het juiste niveau van specialisatie aangesproken wanneer een gegeven gebruikt wordt

Waarom is een thesaurus/verklarend woordenboek noodzakelijk ?

Een voldoende gemotiveerd antwoord is te vinden in de bijdragen:

http://www.fadyart.com/thesaurusNL.htm

Waarom een ontologie gebruiken ?

l Om een gestructureerde weergave van de domeinen waarin de onderneming werkzaam is delen en verrijken, zowel intern als extern.

l Vormt de kennisbank van de onderneming (knowledge base).

Meer motivatie is te vinden op:

http://www.fadyart.com/documentatieNL.htm

Aanpak

Vele zijwegen konden bewandeld die leidden naar prachtige theoretische uiteenzettingen en oplossingen.

Daar mijn bronnen bijna uitsluitend op het internet te vinden waren en de zijpaden via de hyperlinks letterlijk voor de hand lagen vroeg het wel wat evenwichtsoefening om slechts die paden te kiezen die gefocusseerd bleven op de doelstelling maar tegelijk op het vlak van de methodiek aantrekkelijk konden zijn.

De aanpak is dus hier ook, net zoals in de vorige pagina’s bottom-up.

Als alternatief kon een academische aanpak overwogen worden: vanaf een studie over de informatie theorieën vertrekken en uitkomen bij eventueel een nieuwe theorie of het ontdekken van een theorie die nog niet in toepassing is gebracht.

Dit is echter voer voor academici.

Zelf dien ik te vermijden uit te komen bij een theoretische oplossing voor een theoretisch probleem.

Een concrete oplossing voor de concrete problemen die aangehaald zijn is de doelstelling.

Wanneer gevonden, zou het interessant zijn deze te testen of te omschrijven vanuit theoretische benaderingen.

Even terzijde:

û Hetzelfde geldt voor de aanpak van nieuwe IT-ontwikkelingen: hou de aandacht op het werkelijke probleem

û De methodieken om te komen tot nieuwe ontwikkelingen waren soms onweerstaanbaar vanuit interessestandpunt.

û Bij kennisname stond ik, bij enkele van die theorieën perplex, omdat ze aantoonden dat de formulering ervan nooit in praktijk kon worden gebracht in de academische vorm die aangeboden werd.

û Natuurlijk doet dit geen afbreuk aan de verdiensten van de vele hulpmiddelen die wel praktisch toepasbaar zijn.

û Een frequentere toetsing theorie/praktijk zou echter welgekomen zijn voor allerlei theoretische benaderingen.

û De terminologie die gebruikt worden binnen verschillende benaderingen ligt mijlenver uiteen en de betekenis ervan is dikwijls totaal verschillend.

De weerhouden oplossing.

De weerhouden oplossing zal in verdere bijdragen verder uitgediept, vandaar de hier beperkt gehouden bijdrage over deze optie.

De oplossing houdt een ontologie in die volgens de OWL-standaarden is opgebouwd.

Ontologieën zijn de bouwstenen van het toekomstig “begrijpend” web.

Met het begrijpend web wordt bedoeld dat er logica kan opgebouwd worden door informatica systemen uit gegevens die op een bepaalde manier voorhanden zijn.

Zowel mensen als machines zullen de informatie in een ontologie begrijpen.

Enerzijds heeft men het datamodel: concepten en relaties tussen concepten worden beschreven en geordend in een taxonomie.

Concepten worden vertegenwoordigd door “klassen”.

Wanneer men elementen uit die klasse aanmaakt zullen die individuen, samen met het bovenliggend model leiden tot wat men een kennisbanken (knowledge base) noemt.

Het bijzondere aan OWL is dat het toelaat via zoekrobotten langs het internet aan de gegevens te komen.

Na medeontwikkelaar geweest te zijn van het internet had Tim Berners-Lee een droom: kennis vergaren, vergroten en laten interpreteren door IT-systemen uit de informatie die via het internet beschikbaar kwam.

OWL is een standaard van het W3C-consortium die in 2004 is goedgekeurd.

Deel uitmaken van een gemeenschap die daaraan meewerkt, terwijl deze deelname de eigen vooropgestelde doelen bevredigd. Meer nog, door wisselwerking met andere ontologieën, een ongebreideld potentieel tot optimalisering verkrijgen. Dit moet de natte droom van elke met kennis begane persoon zijn.

De opvraging uit de bestanden gebeurt door (voorlopig beperkt in aantal) robotten aan de hand van een gehanteerde taal: SPARQL die door menselijk verstaanbare parameters kan ingesteld.

De eerlijkheid gebiedt te zeggen dat dit voorlopig een kennis van het ondervraagde model behoeft. De robotten zullen zeker nog verder geoptimaliseerd.

We kunnen ons niet voorstellen dat een ontologie uit de losse hand kan opgebouwd.

Er is ontwikkelingssoftware voor nodig die de complexe en rijke eigenschappen (inclusief relaties) helpt beheren.

Die software is in beperkte mate aanwezig.

Zelf kan ik de gratis software aanraden van de Stanford universiteit: Protégé, te downloaden op http://protege.stanford.edu/

Er is prachtige documentatie bij verstrekt die echter een paar versies achterloopt.

Op vandaag (oktober 2008) raad ik versie 3.4 aan met de OWL uitbreiding.

De software is ontworpen door de ontwikkelingsafdeling van de medische faculteit.

De faculteit informatica heeft zelf ook een programma: Chimaera.

Waarschijnlijk zullen commerciële pakketten mekaar opvolgen.

Verder zijn er redeneer-robotten beschikbaar die helpen met het beheren van de eigenschappen van de concepten. Deze kunnen via het software-pakket aangesproken worden.

Het is mijn plan in de komende weken een eerste aanzet tot ontologie te publiceren.

Bronnen

Visie van Tim Berners Lee op het semantisch web: http://www.sciam.com/article.cfm?id=the-semantic-web

Pagina's van het W3 Consortium over OWL: http://www.w3.org/2001/sw/WebOnt/

Mail lijsten over OWL: http://lists.w3.org/Archives/Public/public-swbp-wg/

Web service ontologie door middel van OWL: http://www.daml.org/services/owl-s/

Andere onderzochte mogelijkheden

Mogelijkheid 1: UML

Eén van die methodes heeft te maken met object geörienteerde programmatuur.

Op het programmatuur niveau worden 13 schematypen onderscheiden die het gebruik van objecten in de programmatie ondersteunen.

In het “Bronnen” gedeelte van dit document wordt voldoende verwezen naar documentatie over dit onderwerp.

Eén groep, “Business modelling and integration” is in juni 2005 opgenomen in de OMG (Object Management Group) groep. Op vandaag, augustus ’08, is daar geen “white paper”, geen agenda, geen overzicht van de gedane werken, road map, slechts een paar presentaties, van 2001 tot 2006 die niets met het onderwerp dat we hier behandelen te maken heeft.

Jaarlijks wordt ook een conventie georganiseerd die eerder algemene trends blootlegt maar bij mijn opzoekingen nog geen bruikbare aanpak.

Dit doet niets af aan de prestaties van OMG op andere vlakken, ze zijn nl. de grondleggers van de UML talen (Unified modelling language).

De meest bruikbare van die diagrammen op het vlak van ondernemingsdocumentatie zijn:

- Activiteits diagrammen (de goeie ouwe stroomschema’s). Ze geven aan wie (via de verticale kolommen) wat (via de horizontale rijen) doet (via de toelichting op die lijn, normaal in de linker marge). Deze modellen duiden ook de voorwaarden aan (in object georienteerde terminologie event, de ouderwetse trigger) waaronder een bepaalde actie plaatsheeft (via het optie-symbool of logische “OF” symbool).

- Use case diagrammen die simulaties aangeven van interacties van de gebruiker met de software.

Beide diagrammen dienen slechts als ondersteuning van de documentatie die we op het oog hebben.

In totaal bevat de versie 2.0 dertien soorten diagrammen.

Deze hebben betrekking op programmeerwerk, te gebruiken in verschillende omstandigheden/stadia en worden dus niet verder in behandeling genomen.

Behalve op het vlak van UML heeft de OMG-groep vele andere standaarden ontwikkeld.

Interessant is ook dat UML kan geconverteerd naar XML voor communicatie over de verschillende computer platformen heen.

Op dit ogenblik is dus niet op te maken welke richting deze werkgroep zal uitgaan.

Het blijft mogelijk dat in de schoot van de OMG-groep een ontwikkeling plaatsvindt van documentatie die interessant zal blijken.

Ik denk dat de gekozen optie de meest flexibele is om een soepele omslag te voorzien naar een andere methodologie. Dit is zeker een niet te onderschatten voordeel van de gekozen optie.

Deze optie classificeren we zelfs niet als verdienstelijke poging wanneer we ons oogmerk van een gedegen zakelijke documentatie op het oog hebben.

Bruikbare concepten

Geen.

Actie

Openstaan voor de ontwikkeling van een tussenlaag naar objectgeoriënteerde programmatie die echter niet de data-opslag volgt.

Bronnen

Algemene vragen : http://ootips.org/

Hulpmiddelen voor OO ontwikkeling :

http://www.cetus-links.org/oo_ooa_ood_tools.html

http://www.embedded.com/

http://www.sybase.com/products/modelingmetadata/powerdesigner/

Unified modelling language (UML) :

Omschrijving van de gedragingen die een systeem dient aan te nemen via Use Case modellering : http://www.iit.edu/~rhurlbut/xpt-tr-97-03.html

Algemene informatie : http://www.holub.com/goodies/uml/index.html

http://www.objectsbydesign.com/tools/modeling_tools.html

http://www.agiledata.org/essays/dataModeling101.html

Hulpmiddelen (Tools) : http://www.puml.org/

http://www.objectsbydesign.com/tools/umltools_byCompany.html

http://www.oose.de/umltools.htm

Use Case model informatie : http://www.pols.co.uk/use-case-zone/use-case-papers

http://usecasehelp.com/wp/white_papers.htm

Bestaande pogingen tot ondernemings (business) modellering.

http://bmi.omg.org/

http://www.bpmi.org/

Mogelijkheid 2: ISO 10303 – STEP – EPISTLE – EXPRESS

In tegenstelling tot de voorgaande mogelijkheid spreken we hier over een weloverwogen, bestaande en toegepaste methodiek.

ISO 10303

Oorspronkelijk ontworpen voor de overdracht van CAx (CAD, CAE, CAM,...) gegevens, dus erg technisch, materieel (diensten ben ik niet tegengekomen) georiënteerd.

De voornaamste pionierswerkzaamheden zijn, in mijn ogen:

- het generieke datamodel

- de ontwikkeling van een communicatie- en beschrijvingstaal : EXPRESS

- aan die taal is een grafische vorm verbonden die in een brede kring wordt gebruikt: EXPRESS-G

- sinds een aantal jaren zijn 2 andere voorstellen tot standaard ingediend: EXPRESS-P voor procesbeschrijving en EXPRESS-I voor instantiëring.

Belangrijke industrieën gebruiken de standaard om gegevens uit te wisselen met hun toeleveranciers, gegevens over de opbouw van hun vestigingen, het onderhoud van de machines,….

Als voornaamste kan men vernoemen: de petroleumsector (met Matthew West als pionier), de auto sector, de chemische sector, de nucleaire sector,…

Voor de geïnteresseerden: het is onmogelijk om de standaard volledig onder de knie te krijgen tenzij men er een levenswerk van maakt, er zijn nl. duizenden blz door te nemen. Belangrijker is die aspecten eruit te nemen die belangrijk zijn in uw activiteitsdomein.

STEP

Staat voor Standard for the Exchange of Product model data en is de naam die gewoonlijk gebruikt wordt wanneer we over ISO 10303 spreken.

EPISTLE

Staat voor

European

Process

Industries

STEP

Technical

Liaison

Executive

En coördineert de informele contacten tussen de verwerkende industrieën om STEP – gebruik te bevorderen. Dit project is van Europees strategisch belang en wordt als dusdanig gesponsord door de EU.

Voor verdere informatie verwijs ik naar de website van Matthew West en andere documentatie waarnaar onder “Bronnen” is verwezen.

In de datastructuren komen we nog entiteiten tegen met meerdere attributen, of samengestelde informatie.

Resultaat

De redenen waarom ik deze mogelijkheid niet weerhouden heb zijn:

- het ontbreken van een ontologie: de norm is erg georiënteerd naar definities van producten, dus naar het woordenboek aspect van documentatie die we op het oog hebben

- de norm is onderworpen aan auteursrechten

- de ontwikkelingen liggen praktisch stil

- productbeschrijving en minder op de functioneel zakelijke waardoor ze eerder werden overgenomen door nieuwe ontwikkelingen in die domeinen: UML, XML, semantic Web,…

- om te kunnen aansluiten bij dergelijke ISO standaard dient men gesteund te zijn door een activiteitssector. De bancaire en verzekeringssector zijn niet direct aangetrokken tot een aanhechting.

Bruikbare concepten

EXPRESS-G zou bruikbaar geweest zijn mocht de standaard open geweest zijn.

Hij dient best ook gekend omdat vele schema’s gebruik maken van deze notatietechniek.

Bronnen

1. Algemeen

Matthew West: http://www.matthew-west.org.uk/

NIST standard link to STEP: http://www.mel.nist.gov/msidstaff/sauder/SCL.htm

Wikipedia:

http://en.wikipedia.org/wiki/ISO_10303

http://www.wikistep.org/index.php/Main_Page

2. EXPRESS

Algemeen:

http://deslab.mit.edu/DesignLab/dicpm/step.html

http://dblp.l3s.de/d2r/page/publications/conf/er/MaLF03

Hulpmiddelen (Tools) overzicht: http://pdesinc.aticorp.org/vendor/STEPtoolkits_vendor.html

Platform waarop een performante tool kan geïnstalleerd die gratis is en onder Java draait: http://www.eclipse.org/

Hulpmiddelen (Tools) leveranciers :

http://www.steptools.com/

http://www.eurostep.com/

http://www.metabula.com/index.html

http://www.edrawsoft.com/express-g.php

http://www.jsdai.net/eclipse/express-g/screenshots

EXPRESS-G Beschrijving:

http://ftp.si2.org/si2_publications/htmlSpecs/DR/part3.fm4.html

http://iaiweb.lbl.gov/IFC/IFC_Release_2.0/FINAL_Model/EXPRESS-G/

Datawarehousing, generieke gegevensmodellering: http://www.dama-nj.org/presentations/Kalido_Generic_Data_Modeling.pdf

Epistle: http://www.matthew-west.org.uk/documents/princ03.pdf. Dit werk vormt voor mij tevens de basis van wat generieke datamodellering betekent.

Mogelijkheid 3: Object Role Modelling

ORM is voor het eerst beschreven rond 1996.

Bijzonder is dat vertrokken wordt vanuit atomaire feiten en dat relaties tussen die feiten gelegd worden met benoeming van de rollen die de attributen spelen.

In tegenstelling tot entiteits/relatie modellen en UML (class diagrammen) ontbreken attributen in ORM. De entiteiten vertegenwoordigen “elementaire feiten” die verbonden zijn door relaties.

ORM kan omgeslagen worden naar structuren op basis van attributen zoals ER of UML.

Deze aanpak is opgenomen in de versie .NET van Microsoft Visual studio onder het onderdeel Enterprise architecture met als tool Visio.

Wanneer daar gebruikt kan code gegenereerd die via SQL-instructies entiteiten aanmaakt met beperkingen op de attributen zoals grafisch gedefinieerd.

Deze entiteiten kunnen gebruikt om testdata in op te nemen die de zakelijke regel bevestigt of verwerpt.

Visio kan ook afzonderlijk aangeschaft maar dan zonder code-generatie.

Bruikbare concepten

ü Duidelijk onderscheid tussen de realiteit van de business, de functionaliteiten in functie van informatica (meestal object georiënteerd) en de opslag van gegevens.

ü Belang van relaties tussen feiten.

ü Uitgebreide notatie conventie die ook duidelijk is wanneer men ermee vertrouwd wordt.

ü Testmogelijkheden van aannames in zakelijke regels.

Resultaat

De uitgebreide grafische notatie is niet interpreteerbaar zonder voorkennis.

De toegang tot gegevens via ons voorstel kan rechtstreeks via internet.

Bronnen

Basis voor ontwikkeling van ISO 15926: http://www.orm.net/

Mogelijkheid 4: Entiteit/relatie model

Dit model is in 1976 beschreven door Peter Chen en sindsdien ruim toegepast en verder ontwikkeld om de conceptuele laag te omschrijven.

Tevens lijkt het model best geschikt om ontologieën te beschrijven.

In de literatuur wordt dikwijls verwezen naar ER (entity/relationsship) diagrammen of ERD’s.

Een entiteit beschrijft een gegeven (met eventuele attributen).

Een relatie beschrijft wat de ene entiteit voor de andere doet of betekent.

Ook relaties kunnen attributen hebben en worden opgeslagen.

Er is ruime beschikbaarheid van pakketten die ERD’s ondersteunen, zelfs met reverse engineering : zie het bronnengedeelte.

Bij de diagrammen zijn verschillende conventies van notaties mogelijk, onder andere IDEF1x (ICAM DEFinition Language) en dimensional modeling.

Een entiteit is een onafhankelijk gegeven dat kan geïdentificeerd worden.

Dit gegeven kan een fysisch aspect zijn van de realiteit zoals een bankbiljet, een concept zoals een aankooporder ter beurs of een event zoals de uitvoering van de aankoop ter beurs van een effect.

Ook hier maakt men onderscheid tussen entiteitstype of categorie of klasse van de ene zijde en een entiteit als instantie van een type anderzijds. Er zijn uiteraard vele instanties mogelijk van een entiteistype.

Dit maakt een onderscheid mogelijk tussen een kennismodel en een opslagmodel.

De kennis is opgeslagen in de entiteitstypes, de productiegegevens in de entiteiten.

Wanneer entiteiten als zelfstandige naamwoorden worden bekeken, kunnen we de relaties gelijkstellen met werkwoorden die 2 zelfstandige naamwoorden verbinden.

Bvb. Wanneer “klant” en “effect” zelfstandige naamwoorden zijn kan de relatie kopen gelegd.

We bekomen dan De klant koopt een effect.

Een entiteit wordt voorgesteld in een rechthoek, de relatie tussen entiteiten in een ruit.

Een opvraging uit dit modeltype maakt gebruik van de bevragingstaal ERROL (Entity Relationship Role Oriented Language) met enkele afgeleiden.

ERROL laat toe in geschreven natuurlijke taal een opvraging op te bouwen of gewoon door in de diagrammen aan te duiden welke output men wenst.

ERROL is bijzonder geschikt voor opvraging uit ontologieën en het semantisch web.

Zowel entiteiten als relaties kunnen attributen hebben.

Bvb. De klant kan als attribuut een geldrekeningnummer hebben en een effectenrekeningnummer. Het effect kan als attributen een ISIN-code hebben, een uitgever, een munt van notering. De relatie kopen kan als attribuut een beursland, een beursplaats en een markt hebben.

De entiteiten hebben normaal een unieke sleutel.

Bronnen

Wikipedia: "http://en.wikipedia.org/wiki/Entity-relationship_model"

1. Proprietary ER diagramming tools (uit Wikipedia)

· ModelRight: innovative and complete physical modeling tool - free community edition for MySQL.

· SmartDraw: point and click drawing method combined with many templates creates professional diagrams.

· Sparx Enterprise Architect: full UML 2.1 which includes data modeling.

· SQLyog Enterprise edition (GUI client for MySQL) has a diagramming tool that will generate ER-diagrams at the same time as reading or generating physical database objects and can save in a XML-based format for later use.

· Toad Data Modeler: ER modeling tool with support for both logical and physical modeling. Includes reverse engineering, SQL generation and report generation features for several db systems.

· Visio: The Enterprise Architect version supports generating and reverse engineering databases

· Visual Paradigm: Cross platform UML tool which supports round-trip engineering an ERD with a database.

2. Free software ER diagramming tools

Tools that can interpret and generate ER models, SQL and do database analysis.

· BrModelo: Braziliaaanse tekenaar van ERMs.

· DBDesigner-Fork: a fork of DBDesigner to make it work with other databases such as PostgreSQL.

· Ferret (software): ERM tool distributed with Debian and Ubuntu.[3]

· Gliffy: Online charting website.

· ModelRight: innovative and complete physical modeling tool - free Community Edition for MySQL.

· Mogwai ERDesigner NG

· MySQL Workbench: tool for graphically creating schemas (or, only in commercial version, reverse engineering schemas) [Beta Software], works with many database engines.

· Open System Architect: ER Diagram modeller the last version dates from 2005.

· Power*Architect: ER Diagram modeller in Java, forward and reverse engineering for several databases, open-source (originally proprietary software).

· StarUML - supports UML and ER Diagrams.

3. Free software Diagram tools

Deze hulpmiddelen maken geen ER diagrammen aan, ze tekenen alléén de vormen zonder kennis van wat ze betekenen en genereren dus ook geen SQL.

· Kivio: flowcharting programma dat ER diagrammen ondersteund.

· Dia: programma dat toelaat vele soorten diagrammen te tekenen, ook ERD’s, eventueel met plug-ins (vb. tedia2sql) kan SQL gegenereerd.

4. ERROL (Entity Relationship Role Oriented Language) opvragingstaal

Wikipedia: "http://en.wikipedia.org/wiki/ERROL"

Mogelijkheid 5: ISO 15926

Deze standaard bouwt verder op ISO 10303 waarvan o.a. de grafische weergave wordt overgenomen.

Hij introduceert ontologieën die op een hoog niveau uniform zijn voor verschillende industrieën, op een lager niveau wordt hij per industrie geïndividualiseerd.

De ontologie en aansluitende taxonomie is een diepgaande ontwikkeling die door vele industrieën is aangegrepen om onderlinge communicatie en gegevensverwerking toe te passen.

De instantiëring dient wel op basis van een gedefinieerde klasse te gebeuren.

Alweer Matthew West heeft een pioniersrol volbracht.

In de datastructuren komen we nog entiteiten tegen met meerdere attributen, of samengestelde informatie.

De relaties worden opgeslagen. Wanneer men bedenkt dat de rijkdom van Europa niet ligt in de aanwezigheid van grondstoffen of energiebronnen maar steunt op een optimale aanwending van deze middelen in een lokale markt, begrijpt dat de relaties belangrijker zijn dan de pure gegevens.

ISO 15926 introduceert ook de 4° dimensie (tijd) als sleutel tot informatie.

Zo zal een begin- en eindtijdstip opgegeven worden waarbinnen een relatie geldt.

Bruikbare concepten

Generieke datamodellen

Introductie van een ontologie

Introductie van een taxonomie

Introductie van een thesaurus

Bronnen

Algemene websites: http://15926.org/home/tiki-index.php

Sponsors: http://www.fiatech.org/

ISO: http://www.tc184-sc4.org/

EU implementation guide: http://www.european-pedc.eu/Presentations/Glendinning%20Ian.pdf

Ontology for process plants: http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema.html

Projecten:

http://www.btinternet.com/~Chris.Angus/epistle/documents/ep00108/ep00108.pdf

Smartplant project: http://nl.intergraph.be/programs.asp

Intergraph project: http://www.intergraph.com/

Bentley project: http://www.bentley.com/en-US/Products/ProjectWise+Lifecycle+Server/

Hulpmiddelen (Tools): http://www.posccaesar.org/RDS/

Mogelijkheid 6: GELLISH

Deze ontologie is oorspronkelijk gebaseerd op ISO 15926 en bevat elementen van ORM (Object Role Modeling).

Wat geldt voor ISO 15926 gaat ook op voor Gellish.

De bedoeling van de ontwerper is te komen, via interactie met de gebruikers, tot een universele ontologie. Uiteraard zou dit revolutionair zijn.

In eerste instantie sta ik tov de doelstelling nogal sceptisch.

De oorsprong van de taxonomie ligt op het wetenschappelijk domein (GELLISH staat voor Generic Engineering Language) en, hoewel stevig gesteund op tevens filosofische, zelfs meta-fysische (Kant) grondslagen, is het voor de immateriële dienstverlening in vele opzichten vreemd aandoend. Een voorbeeld: software wordt als een materieel iets beschouwd “omdat het gegevens overbrengt”. Zelf zou ik daar eerder een concept van gemaakt hebben met een mogelijk materieel aspect wanneer de software is opgeslagen op een gegevensdrager.

Tov de methode (zie verder) sta ik echter zeer positief.

GELLISH heeft als sleutel ook een context gegeven zodat toch een variatie aan definities toegelaten is.

De methode

Þ De informatie is gewoon leesbaar door gebruikers en computer interpreteerbaar

Þ In de datastructuren komen we geen entiteiten tegen met meerdere attributen, alleen atomaire informatie.

Þ De relaties worden opgeslagen zoals in het ISO15926 model.

Þ Er wordt onderscheid gemaakt tussen een kennismodel (knowledge base) en zijn geïnstantieerde tegenpartij.

Þ Het kennismodel staat gelijk met de klassenstructuur die een taxonomie volgt die voor alle toepassingen identiek zou moeten zijn tot een bepaald niveau.

Þ Het is niet verplicht eerst een klasse aan te maken om een instantiëring te definiëren.

Þ De relaties zijn in sterke mate gestandaardiseerd

Þ Daarenboven wordt de volledige ontologie opgeslagen in 1 enkele tabel.

Bruikbare concepten

Zie onder ISO 15926 +

Standaard relaties met afzonderlijke rolbepaling

Eén enkele tabel voor de ontologie

Verschillende contexten (domeinen) mogelijk voor elke definitie

Bronnen

Algemene website met vrije downloads: https://sourceforge.net/projects/gellish

WIKI : http://gellish.wiki.sourceforge.net/

STEPlib browser & editor: http://www.steplib.com/

Aanbieder van software die een dialect van Gellish toelaat: http://www.pkmsolutions.com/

Wanneer we spreken van een dialect, wordt de opper- ontologie die volgens de ontwerpers universeel is, niet volledig gevolgd.

Bronnen

Ik ben niet te beroerd om toe te geven dat ik ruim gebruik van Wikepedia heb gemaakt (Engelse versie). Als zoekrobot is meestal Copernic gebruikt (gratis versie).

Basis en werkwijze voor generieke datamodellering

Het werk op Matthew West’s website: http://www.matthew-west.org.uk/Documents/princ03.pdf heb ik als meest volwaardig beschouwd om mee te starten.

Woordenboek

Instantiëren

Hier dient de wiskundige betekenis van een instantie begrepen. Plastisch kan men spreken van een afdruk op basis van een sjabloon. Het sjabloon zijnde de gedefinieerde klasse.

Wanneer we een klasse die een geldrekening vertegenwoordigd aanmaken. Dan is rekening 000-0001111-11 een instantie van een geldrekening.

Object georiënteerde programmatuur (OO of Object Oriented)

Object oriëntatie heeft te maken met het aanmaken en classificeren van types procedures die gemeenschappelijk zijn aan liefst een zo groot mogelijk bereik.

Het object wordt dan geparametreerd volgens de omstandigheden met eigenschappen (werkwoorden) en methodes (statische parameters). Microsoft gebruikt een uitbreiding van het object georiënteerd model: het component model. Een component model bestaat uit verschillende objecten die samen een zelfstandig programma vormen. Zoals een activeX control. De component gaat een stap verder dan OO en zal een integraal deel uitmaken van je besturingssysteem door aanmelding in je computer registry.

Wat OO betreft kan informatie gevonden op www.omg.org.

Op het vlak van gegevensbeheer komt men ook uit op de traditionele entiteit/relatie modellen

OO heeft te maken met abstracties in gedragingen, niet met data.

Vanuit ons conceptuele niveau hebben we weinig boodschap aan de programmeertechnieken en hoeven we ons dit niet aan te trekken vermits we de niveau’s gescheiden houden.

De aanhangers van procedurele programmeertechnieken zijn wat in de verdediging gedrongen wegens het gebruiksgemak in de ontwikkeling van nieuwe projecten.

Misschien hebben de procedurele mensen ook een punt wanneer we in de praktijk merken dat naarmate we programma’s gebruiken we steeds tragen opstarten en afsluiten in een Windows omgeving en onze RAM niet snel genoeg kunnen uitbreiden om alle objecten en componenten te laden ?

Ontologie

Binnen een domein wordt kennis over dat domein op een formele wijze voorgesteld.

Dit kan door de definitie van concepten en relaties tussen die concepten.

De gebruikelijke werkwijze is:

Þ Definitie van klassen: soorten objecten, concepten of relaties

Þ Attributen van een klasse: eigenschappen, mogelijke gezichtspunten, parameters van een klasse

Þ Relaties : wijzen waarop klassen onderling kunnen verbonden worden

Þ Rollen: de rol die elke klasse speelt binnen een relatie

Þ Functies: termen in een vergelijking of andere berekening die een klasse kan innemen

Þ Beperkingen: beperking in de mogelijke waarden als invoer voor een attribuut

Þ Gebeurtenis: de gebeurtenis die een wijziging van waarden bij de attributen of relaties inluidt.

Þ Regels: regelgeving waaraan de klassen in het domein dienen te voldoen.

Þ Instantiëring: zie definitie

Het begrip ontologie stamt uit de filosofie.

Een prachtige documentatie is hier te vinden: http://www.radicalacademy.com/prcminicourseontology1.htm

Federale topologie

Een informatiesysteem bestaande uit verschillende autonome locale systemen die minstens een deel van hun informatie delen worden federale informatiesystemen genoemd. Wanneer de componenten van die systemen bestaan uit databases spreekt men van gefederaliseerde database systemen.

http://fadyart.com/