Difference between revisions of "Document:Conceptueel datamodel analyse"
m |
m |
||
Line 71: | Line 71: | ||
Alle entiteittypen van het actueel conceptueel datamodel met bijbehorende omschrijvingen | Alle entiteittypen van het actueel conceptueel datamodel met bijbehorende omschrijvingen | ||
− | {| | + | {| width="100%" border="0" |
|- | |- | ||
| 1 | | 1 | ||
Line 174: | Line 174: | ||
|} | |} | ||
− | + | [[Category:Fase_5|Document:Conceptueel datamodel analyse]] | |
+ | [[Category:Database|Document:Conceptueel datamodel analyse]] |
Latest revision as of 12:07, 13 June 2008
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:
- Correctheid
- volledigheid
- 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:
- Alle woorden (in het commentaar) die onderstreept zijn moeten worden verbeterd op taalfouten (zie bijlage punt 2).
- Er zijn nog onduidelijkheden over entiteitentypen STOCK(23) TOE (22) en BUILDPART (6) (zie bijlage punt 2).
- Moduleteam kan het database team aangeven het nut van entiteitentype ASSESSMENT (4) (special verwerkt op verzoek van moduleteam).
- Het entiteitentype ASSESSMENT (4) moet “Appraisa” genoemd worden, omdat ASSESSMENT te algemeen is.
- Kunnen entiteittypen ADRESSTYPE (2) en CONTRACT (10) nog verwerkt worden?
- 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.) |