RelationeleDatabases

Relationele Databases (OLAP) – Volgens Xerox methode
Er zijn 2 grote risico’s in elke relationele, multi-user database.
1. Data verlies
2. Data corruptie
Door te programmeren volgens de Xerox methode word;
1. Data verlies, 100% voorkomen
2. Datacorruptie word zoveel mogelijk voorkomen 100% kan nooit. Corruptie kan in een database
volgens Xerox, alleen nog ontstaan door; een fout van de gebruiker. Je kunt denken aan een spel fout
in een naam. Toch zal de Xerox methode ook gebruikersfouten zoveel mogelijk beperken. Door zoveel
mogelijk invoer te controleren op correctheid. Dit levert een product op met een groter gemak voor
de gebruiker. Het brengt met zich mee een grotere verantwoordelijkheid voor de programmeur.
De gevolgen van niet via de Xerox methode programmeren;
1. Data verlies; dit kan voor uw klant een ramp betekenen.
2. Terwijl datacorruptie, zelfs als ontstaan door een spelfout een fout in een bedrag ect. ect. Onhandige
situaties voor de gebruiker van uw product kan opleveren.
Men kan stellen, dat een goede (relationele/OLAP) database altijd, altijd volgens de Xerox methode word
ontwikkeld. Zeker als men gebruik maakt van C#.
Dataverlies:
Dataverlies kan in een Xerox database niet voorkomen, omdat data niet fysiek kan worden gewist. Slechts
verplaatst naar bijv. de prullenbak.
Gewiste data is altijd terug te halen. In kassa systemen bijv. is deze functionaliteit absoluut noodzakelijk,
immers een kassa dient alles te registreren. Dataverlies van de registratie mag niet optreden, ook niet door
een fout van de gebruiker. Toch is de methode ook voor elk ander database systeem aan te bevelen.
Hoe werkt het?
Elke table in een Xerox database heeft het veld “ModifyKind (Char)” bij een insert in de DB zet je Modify kind
op ‘I’ bij een delete zet je modifykind op ‘D’ bij een Edit op ‘E’ ook andere “modifykinds” zijn denkbaar.
Als je elke SQL Query laat eindigen op; WHERE ModifyKind <> ‘D’ zie je alleen de records die niet “gewist” zijn.
(Lees de status deleted hebben)
Het zelfde scherm kan nu worden gebruikt om de inhoud van de vuilnisbak weer te geven hiervoor laat je de
SQL Query eindigen op; WHERE ModifyKind IS ‘D’
Het enige dat de programmeur hoeft te doen, is de gebruiker het gevoel geven dat hij naar de inhoud van de
prullenbak navigeert, en niet naar het zelfde scherm kijkt. (What you see, is what you get)
Ik kan u dit dit demonstreren in het Xerox framework wat mijn bezit is.
Het Xerox framwork voorkomt;
1. Dat 2 gebruikers in hetzelfde record kunnen wijzigen, waardoor corruptie kan ontstaan. (Algemeen
bekend als: record locking)
2. Het valideert zoveel mogelijk input zo goed mogelijk. (Bijv. de “11 proef” op banknummer)
3. Ook heeft een Xerox database verschillende gebruikers niveau’s, ook dit voorkomt corruptie, omdat
gebruikers alleen kunnen wat ze mogen. Je kan bijvoorbeeld een gebruikers niveau aan de prullenbak
koppelen waardoor alleen de geëigende persoon de inhoud kan bekijken en eventueel terug zetten.
Settings kan veranderen ect. ect. Aan elke actie in een Xerox database kan een gebruikers niveau
worden gekoppeld. Indien nodig kunnen ook meerdere databases in 1 Xerox framework worden
geplaatst, je zou bijvoorbeeld naast gebruikers niveaus ook afdelingsniveaus kunnen maken. Of
zelfs meerdere bedrijven gebruik laten maken van dezelfde centrale database door “bedrijfs
nivau’s”. Alles is mogelijk op het gebied van security in de Xerox database.
3 Tier, C# en de toekomst.
Een Xerox database is altijd 3 tier, dit zorgt er voor dat functionaliteit, hoewel opgeslagen in de unit horende
bij het form (Zelfs als de unit veel tabs heeft, deze kan men scheiden met het #region directive)
Men kan in C# merken dat de class altijd uit 2 files bestaat;
File 1 bevat de definitie van het scherm
File 2 bevat de functionaliteit van het scherm.
Dit is effectief 3 Tier en zorgt dat het product naadloos aansluit met bijv. Microsoft Expression, men kan hier
gemakkelijk de user-interface mee ontwerpen. Dit is natuurlijk niet altijd nodig, maar het kan wel altijd.
Waardoor je, je eigen mogelijkheden niet beperkt.
3 Tier is geen keuze in C#, C# is altijd 3 Tier automatisch, je kunt er niets aan doen. Je moet wel voorkomen dat
je 3 Tier gaat proberen te doen. En je functionaliteit in aparte classes op gaat slaan. Zo vergeet je welke
functionaliteit bij welk scherm hoort het zorgt voor chaos. C# zal altijd automatisch schermdesign en
functionaliteit scheiden.
3 Tier zal er voor zorgen dat je elke kant op kan met de user interface; Of dit nu een website, Windows
programma, Silverlight of presentation layer foundation kant is. Je kan die kant op elk moment kiezen, zonder
veranderingen aan de functionele code.
Discipline
Het programmeren volgens Xerox is een discipline waar men in moet worden opgeleid. Echter als men in het
bezit is van een Xerox framework kan de lead-developer (en dat is altijd de Application Framework developer)
Andere programmeurs de opdracht geven een scherm te bouwen en hier toezicht op houden/aanwijzingen
geven.
Na het maken van 2 a 3 schermen, snapt met het framework en daarmee Xerox methode. Men kan dus stellen
dat men in 1 a 2 maanden een echte Database specialist word. Afhankelijk van het niveau van de
programmeur.
Complex
Hoewel een Xerox database complex is, verbergt het diezelfde complexiteit voor de gebruiker. De gebruiker
ervaart alleen het gemak er van.
Tot slot
Hoewel ik dit schrijven (lang) niet op elk detail in ga. Geeft het wel een goed beeld van de filosofie achter de
Xerox methode en de manier van werken. Al kan hier een heel boek aan worden geweid.
Ik geef graag een demonstratie van het framework, maar ga niet in op de code technische kant. Alles is met
een bepaalde reden zo gemaakt en wetenschappelijk onderbouwd. Ik wil best brainstormen over de
verbetering van het framework, maar alleen met mensen die minimaal zelf 3 goedwerkende schermen
hebben gerealiseerd, met of zonder mijn hulp. Immers dit is een methode, die ik zelf niet heb bedacht.
Drs. Remi van Dongen [PhD, MSc, MBA]