Domeinmodellering-Opdracht/2 Activiteiten/Casus/Deelopdracht 3/2 Opdrachtbeschrijving

Uit Werkplaats
Ga naar: navigatie, zoeken

Domeinmodellering-Opdracht


 © comments



Deel III: Relational mapping + implementatie tot eenvoudig prototype


Achtergrond

We gaan nu verder met de al eerder in deze DM-cursus gebruikte beschrijving van de ziekenhuiscasus. We gaan in deze derde deelopdracht de uiteindelijke stap maken voor het realiseren van een [beperkt] prototype van een realistisch aandoend [eenvoudig, administratief] informatiesysteem. Bij de reeds uitgevoerde ‘wekelijkse’ studietaken is al op kleine, beperkte UoD’s geoefend met het ‘Rmap’-pen van een [ORM-] datamodel. In deze casus moet je de zo al verworven kennis en ervaring toepassen op een uitgebreidere, semi-realistische situatie. Daarnaast moet je zelf [nou ja, ietwat begeleid …] een aantal (GUI-) implementatie aspecten van het te gebruiken RDBMS uitzoeken en aanleren.


Leerdoelen

Na uitvoeren van deze leertaak ben je in staat om de verschillende aspecten die in de cursus zijn (en nog worden) behandeld rond het ontwerpen en implementeren van een [ORM-] datamodel (conceptuele schema), toe te passen in een ‘realistische situatie’.


Instructie

Organisatie:
werk ook voor dit casusdeel weer in de eerder gevormde groepjes van 3 studenten (met je eigen ‘casus-team’).


Deze studietaak behelst het verder uitwerken van het tussentijdse resultaat van de (ORM-) Informatie-Analyse aan de ziekenhuiscasus tot een database-structuur, gevolgd door het maken van een aantal user interfaces met achterliggende SQL-commando’s.


0) Als het, naar aanleiding van de op college besproken uitwerking van deel II van de casus, nodig was veranderingen in je conceptuele ORM-schema aan te brengen, doe dat dan en lever later (op papier) een afdruk van je eerdere en uiteraard je nieuwe ORM-CS + daarbij duidelijk aangegeven, welke veranderingen jullie hebben doorgevoerd [en zonodig: waarom]. Indien je alsnog andere modelleerkeuzes maakt, geef dan aan waarom je dat doet.


A) De Informatie-Analyse aan de ziekenhuiscasus moet nu afgerond worden
Zeer waarschijnlijk heb je in je datamodel nog niet aangegeven, van welk (data)type de diverse value-types waren (zoals string[..], numeriek, datum, e.d.). Doet dat dan nu en geef ook eventueel van toepassing zijnde ‘waarde-regels’ bij die value-typen aan en pas desgewenst bij ‘string’-types de maximale stringlengte (default: 10).


B) Rmap naar een [optimale] relationele database-structuur
Pas zonodig de ORM-schema aan om na Rmapping een optimale relationele database-structuur te krijgen; dat betekent meestal: zo weinig mogelijk tabellen, maar dan wel zonder redundantie [tenzij je bewust een bepaalde mate van redundantie wilt inbouwen, zoals bij bewuste keuze voor een of meer ‘denormalisatie’-mogelijkheden]. Geef voor de keuze van het Rmappen van subtypes/generalisaties het waarom van die keuze aan (dus waarom absorptie of net partitie of separatie?).

  • Indien de verkregen structuur betekent, dat er [bewust ingebouwde] redundantie zal zitten in de opgeslagen gegevens, geef dan een expliciete verklaring waarom je voor het inbouwen van die redundantie hebt gekozen.


Gebruik de VisioModeler-optie (‘Build Dictionary’ en vervolgens) ‘Edit Dictionary’ om daarna eerst de gegenereerde tabellen bij elkaar in een overzichtswindow te plaatsen en in staat te zijn [om na dubbelklikken op tabelnaam of kolomnaam] eigenschappen zoals die namen naar eigen smaak aan te passen (richt je daarvoor op het [verwachte] taalgebruik binnen de organisatie).


Vraag je [per tabel] af of het efficiënt is om een of meer extra indexen te [laten] creëren en indien ‘ja’, geef dat dan nu aan; wees niet te gretig met het definiëren van [extra] indexen! (Waarom niet?)


Zorg ervoor, dat [bij een vraag van de tool hierover] aangebracht wijzigingen worden ‘terug gemigreerd’ naar het onderliggende ORM-schema.


Gebruik nu de tool-optie ‘Generate Database’ en genereer in eerste instantie een Textfile met SQL-DDL. Gebruik daarbij bij voorkeur de ‘ODBC Generic Driver’ (vul in het veld ‘Database Name’ ‘iets’ in). In het gegenereerde tekstbestand staat een heleboel documenterend commentaar (commentaarregels beginnen steeds met ‘--‘ ).

  • Analyseer vervolgens heel kritisch of de VisioModeler-tool wel correcte DDL heeft gegenereerd. Geef je bevindingen hierover in je eindverslag aan (zoals van wat er ontbreekt, teveel is, fout erin staat e.d.).
  • Geef de (al dan niet gecorrigeerde) CREATE-TABLE-commando's waarmee deze database-structuur te creëren is. De bewaking van alle bij de Informatie-Analyse gevonden constraints, moet zoveel mogelijk gebeuren via SQL2 en moet in elk geval volledig zijn.

Nogmaals: Als je hiervoor gebruik maakt van door de casetool gegenereerde SQL-DDL-code, controleer het resultaat dan uitdrukkelijk op correctheid ! ! ! (De tool genereert deels te veel en deels te weinig ...)


C) Gebruik de bepaalde database-structuur voor het genereren van een MS-Access-database
Via diezelfde menu-optie ‘Generate Database’ van de VisioModeler-casetool kun je een MS Access-database laten genereren. Uit het met VisioModeler 3.1 meegeleverde readme.txt-bestand halen we daarover het volgende:

To generate an Access database later than version 3.x, proceed as follows:
  1.	Build the logical (table) model (.imd file)
  2.	Choose Database > Generate Database
  3.	At step 1 of the generate database wizard, check the Generate New Database option
  4.	At step 2 of the generate database wizard, choose the Microsoft Access driver, check the Create MDB file option 
   	and hit the New button (do not enter a data source name in this step) 
  5.	Check the User Data Source option
  6.	Select Microsoft Access Driver (*.mdb) and click Finish
  7. 	On the ODBC Microsoft Access dialog, enter a Data Source Name (e.g. Test) and hit the Create button
  8. 	On the New database Dialog, enter a database name (e.g. Test.mdb) then check the Format Version 3.x and hit OK
  9. 	Hit OK in reponse to the successful database creation message, then hit OK in the ODBC Access setup dialog box
 10.  	Step 2 of the generate wizard now displays the data source name: now enter an MDB filename (e.g. Test.mdb) and hit Next
 11.	Hit Next then hit OK on the next screen (no need to enter anything), or simply hit Finish
 12. 	If prompted for adding indexes on foreign keys to your model, you may hit No
 13. 	When prompted to see the DDL script, hit Yes 

 To open this database in a later version of Access (e.g. Access 2000), proceed as follows:
  1.  	In Explorer, double-click the database filename (e.g. Test.mdb) 
  2.  	On the Convert/Open Database dialog, check the Convert Database option and hit OK


Mocht het je niet lukken op deze manier de database te laten genereren, dan kun je hem altijd nog handmatig aanmaken. Dat is uiteraard wel wat meer werk...


Afhankelijk van wat en hoe precies aan MS Access-onderdelen geïnstalleerd is, verloopt het bovenstaande correct.
(N.B. Via Tools/Relationships uit de MS Access-menubalk kun je de aanwezige, gegenereerde samenhang tussen de verschillende tabellen grafisch weergegeven zien. Controleer die op correctheid! Breng desgewenst veranderingen aan in de database-structuur en geef [op papier] je verklaring voor die doorgevoerde veranderingen.)

  • Voer in elk van de tabellen (minimaal) een tiental gegevensrecords in, zodat je er queries op los kunt laten.
  • Uiteraard moet je daarbij ervoor zorgen, dat je test-database ‘integer’ is.


D) Antwoorden op (je) ‘onderzoeksvragen’ zoals geformuleerd bij deel I van deze casus
Bij deelopdracht 1 van deze casus heb je zelf ideeën geformuleerd over enerzijds de wijze waarop het systeem op een flexibele wijze zou kunnen omgaan met bijvoorbeeld regels rond ‘aantal lopende medicijnverstrekkingen’ en anderzijds over drie te beantwoorden ‘management’-vragen.

  • A) Als je dat nog niet gedaan hebt: implementeer die flexibele wijze voor (o.a.) die medicijnverstrek-kingen dan nu. Mocht je echter tot de conclusie zijn gekomen, dat jullie toenmalige ideeën daarover niet gerealiseerd kunnen worden, geef hier dan expliciet de verklaring waarom dat echt niet kan.
  • B) Geef de SQL-queries waarmee antwoorden verkregen kunnen worden op de bij deel I door jullie zelf geformuleerde drie ‘management’-vragen.


E) Opstellen van benodigde SQL-queries + tonen van resultaten met een [ietwat] primitieve GUI
Via Blackboard kun je een bijlage over het met MS Access maken van Grafische UserInterfaces ophalen. Bestudeer die bijlage eerst, voordat je doorgaat met het 2e deel van het volgende onderdeel.


N.B. Je bent niet verplicht gebruik te maken van MS Access; je mag bijvoorbeeld ook iets ontwikkelen met PHP/MySQL. Voorwaarde is wel, dat wij volledige toegang krijgen tot het systeem en bijvoorbeeld via een tool als phpAdmin de structuur, populatie en constraint-bescherming van de gegevenstabellen kunnen inspecteren en ook zien hoe gebruik is gemaakt van bijv. PHP om de data-integrity zo goed mogelijk te bewaken!


Bepaal eerst de [onderliggende] SQL-commando's ('queries' of andersoortig) die nodig zijn voor het beantwoorden van de hierna volgende informatievragen en ontwerp + implementeer daarna geschikte user interfaces voor de interactie met het MS Access-systeem:

  1. Maak voor gebruik bij de informatiebalie een form, waarmee het mogelijk is een plaatsnaam aan te geven en dat vervolgens een overzicht komt van alle op dat moment opgenomen patiënten uit die aangegeven plaats, op welke afdeling elk ligt en op welke datum zij/hij daar opgenomen is. Zorg ervoor dat binnen dat overzicht de gegevens geordend op achternaam getoond worden.
  2. Het ziekenhuismanagement wil een overzicht met daarop van een aan te geven afdeling hoeveel verschillende medicijnen [lees: medicijnsoort] aan hoeveel verschillende ooit opgenomen patiënten zijn verstrekt en wat de verhouding [het quotiënt] tussen die twee waarden is. Formuleer de SQL-query, test uit en zorg voor een geschikte user interface.
  3. Het ziekenhuismanagement wil één form met daarin de mogelijkheid om van een aan te geven afdeling twéé soorten informatie gelijktijdig te zien. Op de eerste plaats wil men op dat form een overzicht van de op dat moment op die afdeling aanwezige [= opgenomen] patiënten met hun kamernr, naam en opnamereden zien en elders op dat form tevens wat ‘statistische’ informatie over de totale capaciteit van de betreffende afdeling (dus: hoeveel bedden op alle kamers van de betreffende afdeling aanwezig zijn) en hoeveel van die bedden op dit moment bezet zijn. Je zult voor beide onderdelen aparte SQL-queries nodig hebben; formuleer die SQL-queries, test ze uit en maak een geschikte user interface waarmee de gevraagde gegevens worden getoond.


(Hint: afhankelijk van hoe je ‘datumwaarden’ opslaat, kun je hier eventueel -indien nodig- de ingebouwde MS Access-functie Year(Datumwaarde) e.d. gebruiken; zelfs groeperen op zo’n functiewaarde kan!)

Inlever-deadline

Inlever-deadline voor je uitwerking van deze derde casusdeelopdracht is (uiterlijk) vrijdag 7 januari 2010 om 16:00u op de kamer van Ger Paulussen (HG02.068) (deels op CD/diskette/USB-memory-stick + deels op papier).


In te leveren:

- op papier:

  • je uiteindelijke ORM-conceptueel schema (indien er ten opzichte van de vorige schema-versie veranderingen zijn aangebracht, dan dien je ook dat oude schema in te leveren + een overzicht van de doorgevoerde wijzigingen en een toelichting over het waarom van de wijzigingen).
  • De volledige SQL-DDL (create table-commando’s etc.) voor het creëren van een geoptimaliseerde database. Indien je moedwillig redundantie hebt ingebouwd, geef dan het waarom daarvoor aan.
  • Geef je bevindingen of de VisioModeler-tool correcte DDL heeft gegenereerd en/of wat er ontbrak, teveel was, fout erin stond e.d.).
  • De door jullie opgestelde SQL-queries voor het kunnen beantwoorden van de informatievragen bij onderdeel D.


- op CD/diskette/USB-memorystick:

  • je gehele ORM-VisioModeler-tool-uitwerking (dus: álle bestanden; .IMO, .IMD en evt. andere)
  • je MS Access-testdatabase met in elke gegevenstabel [indien maar enigszins mogelijk] minimaal 10 gegevensrecords. Uiteraard dient je database ‘integer’ (= nìet vervuild) te zijn. In/via diezelfde database dienen ook de gevraagde SQL-queries en GUI-forms aanwezig te zijn (beide typen getest op hun correcte functioneren!)


Veel succes.