Document:Conceptueel datamodel analyse

From WOSI
Jump to navigation Jump to search
Verslag over conceptueel datamodel analyse
Datum 5 april 2008
Fase Fase 5
Versie 1
Status
Auteurs Yohannes Afework & Alimasi Tschomba
Goedgekeurd door
Aangepast door

Inleiding

Dit document beschrijft een korte analyse van het actuele conceptueel datamodel van WOSI. Er is aan het database team gevraagd om het actuele conceptueel datamodel te laten valideren door zowel een woningbouw corporatie als het module en Framework team. Zonder enkele documentatie daarover. Het lijkt ons verstandig om eerst te gaan kijken naar de een aantal aspecten daarvan en daarna beginnen met de validatie procedure.


Hiervoor hebben we een korte analyse gemaakt van het datamodel en kort advies gegeven. Voor deze analyse hebben we het datamodel globaal de getoetst op de volgende aspecten:

  1. Correctheid
  2. volledigheid
  3. consistentie

Actueel Conceptueel datamodel (WOSI)

Dit conceptueel data model is gemodelleerd van uit een object-oriented (OO) modelling perspectief. De bedoeling hiervan is om data op te slaan als gegevens in de database. Als voorbeeld hieronder vind je de entiteit Persoon en de bijbehorende attributen met daarnaast voorbeeldgegevens voor een Persoon. (zie bijlage punt 1).

Analyse resultaat

Uit onze analyse is naar voren gekomen dat het conceptueel datamodel nog uitgewerkt moet worden op een paar punten voor de validatie hiervan, te weten:

  1. Alle woorden (in het commentaar) die onderstreept zijn moeten worden verbeterd op taalfouten (zie bijlage punt 2).
  2. Er zijn nog onduidelijkheden over entiteitentypen STOCK(23) TOE (22) en BUILDPART (6) (zie bijlage punt 2).
  3. Moduleteam kan het database team aangeven het nut van entiteitentype ASSESSMENT (4) (special verwerkt op verzoek van moduleteam).
  4. Het entiteitentype ASSESSMENT (4) moet “Appraisa” genoemd worden, omdat ASSESSMENT te algemeen is.
  5. Kunnen entiteittypen ADRESSTYPE (2) en CONTRACT (10) nog verwerkt worden?
  6. In de entiteitentype VHEGROUP moeten de attributen namen v vheg_startprice en vheg_endprice vervangen worden door vheg_ Maximumprice en vheg_Minimumprice

Voor het uitwerken van de bovengenoemde punten moeten de teamleider, mensen van de database team het requirements document uit fase 4 hebben. Het zou wellicht goed zijn als de kennismanager hierbij betrokken wordt bij het vinden van de documenten.

Of er moet een aanvullend requirements document gemaakt worden die de database teamleden kunnen gebruiken bij het uit werken van het datamodel.

Bijlage

Punt 1: voorbeeld

Tabellen Waarden
Persoon: Jan
Role: Student
Persoon Attribute (specifieke attribute): Studentnummer
Persoonvalue(waarde van specifieke attribute): 461824
Communicatie;: 020-984784636 / jan@hotmail.com
CommunicatieType Telefoon / email

Punt 2: Omschrijving entiteitentypen

Alle entiteittypen van het actueel conceptueel datamodel met bijbehorende omschrijvingen

1 ADDRESS Zelfs meerdere hebben. Een VHE moet ook een adres hebben. Deze entiteit voorkomt redundantie
2 ADRESSTYPE Er zijn 2 adrestypen: woonadres en correspondentieadres. Misschien dat er nog wel meer te verzinnen zijn...
3 APPOINTMENTSTATUS Een afspraak kan verschillende statussen hebben (Open, Afgerond, Uitgesteld, etc. )
4 ASSESSMENT Deze entiteit komt uit het model van het moduleteam. Is nog geen controle over de correctheid geweest.Een bankrekening word (wordt) gebruikt voor verschillende betalingsacties voor huur of loon.Kan gekoppeld zijn aan een corporatie OF een persoon
5 BUILDPART Bouwdeel is alles wat te maken heeft met onderdelen in een VHE. Dit kan een kraan zijn, een aanrecht,een kast, enz. Een bouwdeel kan deel uitmaken van een vooraad (voorraad) maar als het al in gebruik is, is dat niet het geval.
6 COMMUNICATION' Een persoon kan meerdere manieren hebben van communiceren (telefoon, mobiele telefoon, fax, email, etc. ).
7 COMMUNICATIONTYPE Er zijn verschillende types van communicatie. Bijv. Telefoon, Mobiel, Email en in de toekomst misschien Skype?
8 COMPLAINT Klacht is iets wat belangrijk is. Het is input van klanten en mededingers en zorgt ervoor dat het bedrijf goed loopt en gerespecteerd blijft. Een klacht kan over allerlij (allerlei )dingen gaan, daarom staat het in direct contact met Contract. In bijna alle gevallen gaat de klacht over een contract ofover iets dat daarmee te maken heeft.
9 CONTRACT Er zijn verschillende soorten contracten, dit is te zien bij "inheritance_3". Als alle contracten dezelfde relatie moeten hebben heb ik de relatie verbonden met de hoofdtabel, klasse. Is de prijs bruto of netto???
10 CONTRACTATTRIBUTE Per type contract kunnen er attributen worden toegevoegd om op te slaan. Zelfde situatie als bij 'Persoon'('Person')
11 CONTRACTTYPE Er zijn verschillende typen contracten. Bijv. : Onderhoudscontract, huurcontract, etc.
12 CONTRACTVALUE Dit is de koppeling tussen een attribuut en een persoon, waar natuurlijk een waarde voor moet worden ingevuld.
13 INTEREST Dit is een intresse in een VHE of een groep VHE's.
14 MAINTENANCEAPPOINTMENT Hier wordt een afspraak voor het onderhoud van een VHE opgeslagen. De monteur is een onderhoudsmonteur of een rechtspersoon.
15 PERSON Een persoon kan iedereen zijn die iets met de woningbouwcorporatie te maken heeft. In onze tabel zijn dat: Werknemer, huurder, ondernemer, crediteur en leverancier. Voor elke soort persoon is een aparte tabel, deze erven standaard eigenschappen van deze tabel, zoals: Naam, adres.
16 PERSONATTRIBUTE Aan een specifieke rol kunnen speciale attributen worden gekoppeld die niet in de entiteit 'Persoon' zitten.
17 PERSONROLE Een persoon kan verschillende rollen hebben (werknemer, rechtspersoon, monteur, huurder, etc)
18 PERSONVALUE Hier wordt de waarden van de combinatie attribuut en persoon opgeslagen.
19 PROJECT Een project is iets waarbij de woningbouwcorporatie extern iets laat uitvoeren. Dit is meestal een onderzoek,onderhoud of nieuwbouw project. Deze drie projecten erven dan ook van Project.
20 STATUSINDICATOR Aan een VHE kunnen 1 of meerdere statussen gehangen worden. Hierbij moet gedacht worden aan 'bewoond', 'getaxeerd', 'verkoop', 'verhuur', etc. Denk er om dat een groot aantal statussen ook verkregen kan worden uit de procesdata. Je zou dus met een query kunnen kijken of een VHE op dat moment bewoond wordt door iemand d.m.v. de contracten.
21 STOCK Een voorraad bevat meerdere bouwdelen en maakt deel uit van een contract. Wat is Voorraad? Wat is het nut van Voorraad? Waarom is Voorraad gekoppeld aan Contract?
22 TOE TOE staat voor Te Onderhouden Eenheid Dit kan vanalles (van alles)zijn, bijvoorbeeld een trap/trappenhuis, lift, hal, balie, drankautomaar enz!!!: Te onderhouden eenheid wordt (nog) niet gebruikt. Het nut ervan is onduidelijk.
23 UNITSTATUSINDICATOR Zie de entiteit Statusindicator. De opmerking kan gebruikt worden om, jawel: een opmerking eraan te plakken.
24 VHE VHE staat voor verhuurbare eenheid. VHE zijn ruimte's(ruimtes) die verhuurd worden/kunnen worden Hieronder kan vallen: Woning (huis, apartement(appartement), flat, villa, boerderij enz),Kantoorgebouw,Garage, enz Deze naamgeving is een strijd met de modelstandaard van WOSI. Omdat iedereen deze term gebruikt, hebben we ervoor gekozen het zo te laten.
25 VHEGROUP Dit is een groep van VHE's. Groeptype bepaald wat voor groep het is. (flat, wijken, etc.)