Normalisatie van adresgegevens

[-FoX-]

Soms weet ik niet goed hoe ver te gaan met database normalisatie; want je kan theoretisch wel een database model volledig gaan normaliseren; soms heb je ook nog met andere factoren rekening te houden zoals complexiteit en performance.

Ik zal een simpel voorbeeld stellen; waar het gaat om statische gegevens die binnen een web applicatie gebruikt worden.

DOCTOR
riziv
firstname
lastname
street
zipcode
city
telephone
mobile
fax
email
language_code
title
extra
last_modified
user_id

INSURANCE
id
firstname
lastname
street
zipcode
city
telephone
fax
email
extra
last_modified
user_id

RETIREMENTHOME
id
home_name
firstname
lastname
street
zipcode
city
telephone
fax
email
note
riziv
last_modified
user_id

MUTUALITY
code
name
street
zipcode
city
telephone
fax
last_modified
user_id

DENTIST
riziv
firstname
lastname
street
zipcode
city
telephone
mobile
fax
email
hourly_rate
last_modified
user_id

Ik denk dat het punt zo wel duidelijk is. Aangezien het hier om statische data gaat; dus 1x inserten en verder enkel maar lezen en refereren; vraag ik me af op welke manier er hier best genormaliseerd dient te worden.

Ik had gedacht aan volgende

code:

+----------+           +----------------+
| ADDRESS  |           | CONTACTPERSON  |
+----------+           +----------------+
id                        id
street                    firstname
zipcode                   lastname
city           1 ---- 1   address_id
                          telephone
                          fax
                          mobile
                          email

+--------+           +----------------+
| DOCTOR |          | INSURANCE |
+--------+           +----------------+
riziv                 id
contactperson_id     contact_person_id
language_iso         extra
title
extra

Zelfde voor de rest dus..

Waar doctor, insurance dan refereren naar contactperson (en die weer naar adres). Je kan hier nog verder gaan door zipcode, city er nog eens uit te halen; maar gaat dat niet te ver?

Hoe denken jullie erover?

[Woy]

Ik denk dat dat op zich best goed is. Alleen ik zou mischien toch overwegen om Address op te nemen in je Contactpersoon tabel aangezien het een 1-1 relatie is. Als er nog meerdere personenen op een adress zouden staan en je het adres voor al die personen in een keer wilt veranderen heeft het nog wel voordeel om die apart te zetten. Maar op deze manier zie ik het voordeel niet echt.

[-FoX-]

Verder is de relatie tussen de andere tabellen ook gewoon 1-1 met contactperson, dus in principe kan die dan ook weer overal opgenomen worden, zeg je?

Wat met doctor en dentis? Op zich ongeveer dezelfde entiteiten, en dezelfde PK, maar dan toch weer verschillend. Overerving is hier misschien wel van toepassing?

[Woy]

Maar kan het niet zo zijn dat een contactpersoon meerdere insurnaces heeft. Verder kan je met inheritance 2 verschillende aanpakken kiezen. Of je neemt een tabel waar zowel de velden voor Doctor en Dentist in zitten en laat voor een Dentist de velden die bij Doctor horen NULL of je maakt een gezamenlijke tabel waar hun gemeenschappelijke velden in zitten en dan voor elk type een aparte tabel waar de extra velden in zitten.

Als er maar heel weinig velden verschillen zou ik eerder de eerste aanpak gebruiken aangezien dat gewoon makkelijk is voor query's enzo. Maar als er meer velden extra bij komen dan is het vaak wat overzichtelijker om er meerdere tabellen van te maken omdat je anders een hele berg met null values krijgt.

Wat betreft het adres. Je kan het wel zo doen zoals je nu hebt gedaan daar is zeker niks mis mee. Maar ik zou er toch eerder een NAW tabel van maken. Het zijn toch gegevens die veel met elkaar te maken hebben. Het gaat namenlijk allemaal over hoe je iemand kan bereiken.

[-FoX-]

NAW tabel?

[Alarmnummer]

Binnen java probeer ik de data vaak wel te bundelen. Op het moment dat je nog meer velden hebt, zie je soms door het bomen het bos niet meer. Het werken met een 'value object' werkt dan wel een stuk prettiger. In de database laat ik het wel vaak in de tables staan (dus maak niet nog meer tables aan) als het object geen echte eigen identiteit heeft (zoals adres)

[ Voor 27% gewijzigd door Alarmnummer op 09-11-2006 21:35 ]

[-FoX-]

Alarmnummer schreef op donderdag 09 november 2006 @ 21:34:
Binnen java probeer ik de data vaak wel te bundelen. Op het moment dat je nog meer velden hebt, zie je soms door het bomen het bos niet meer. Het werken met een 'value object' werkt dan wel een stuk prettiger. In de database laat ik het wel vaak in de tables staan (dus maak niet nog meer tables aan) als het object geen echte eigen identiteit heeft (zoals adres)

Begrijp ik het goed dat je hier zegt dat je de tabellen in ongenormaliseerde vorm zou laten staan?

[Woy]

-FoX- schreef op donderdag 09 november 2006 @ 19:40:
NAW tabel?

Naam Adres Woonplaats.

-FoX- schreef op donderdag 09 november 2006 @ 23:08:
[...]

Begrijp ik het goed dat je hier zegt dat je de tabellen in ongenormaliseerde vorm zou laten staan?

Ik denk dat hij het meer over het adres heeft. Het is niet handig om echt alles in een tabel te stoppen.

[Janoz]

rwb schreef op donderdag 09 november 2006 @ 19:23:
Of je neemt een tabel waar zowel de velden voor Doctor en Dentist in zitten en laat voor een Dentist de velden die bij Doctor horen NULL

Het nadeel hiervan is dat je geen constraint specifiek voor doctor meer kunt leggen omdat die lang niet altijd voor dentist gelden. Maar goed, dit is 1 van die typische O/R mapping problemen

[Boss]

Misschien adres nog scheiden in straat + nummer (handig als je later een postcode-lookup wilt integreren)? En wat voor buitenlandse adressen?

[-FoX-]

Janoz schreef op vrijdag 10 november 2006 @ 10:03:
Het nadeel hiervan is dat je geen constraint specifiek voor doctor meer kunt leggen omdat die lang niet altijd voor dentist gelden. Maar goed, dit is 1 van die typische O/R mapping problemen

Hoe zou jij het dan wel doen?

Boss schreef op vrijdag 10 november 2006 @ 10:22:
Misschien adres nog scheiden in straat + nummer (handig als je later een postcode-lookup wilt integreren)? En wat voor buitenlandse adressen?

Heb ik ook al aan gedacht; het probleem is dat je erg ver kunt gaan en dan voor de minimale lookup al dadelijk met 4, 5 joins zit.. om dan nog maar niet te spreken als je de relaties laat zien. Maar ik denk dat dit qua performance nog wel niet zo'n probleem zal zijn?

Hoever moet je gaan als je buitenlandse adressen ook wil ondersteunen? Die hebben toch ook een street, nr, zip, city..

[Janoz]

-FoX- schreef op vrijdag 10 november 2006 @ 10:28:
[...]

Hoe zou jij het dan wel doen?

Ach, een beetje afhankelijk van de toepassing. Ik weet niet of er enkel nederlandse adressen in komen, of of er ook constraint specifiek voor dentist of doctor zijn. Binnen mijn buisnesslogic zou ik waarschijnlijk met inheritance gaan werken. Deze keuze is nu echter wel gebaseerd op wat duimzuigerij waarbij ik vermoed dat een heleboel acties nauwlijks verschillen voor een tandarts of dokter (dbc registratie oid), maar het kan in jouw toepassing natuurlijk ook zo zijn dat er geen enkele overeenkomsten zijn. Hoe ik het uiteindelijk in de database opsla weet ik nu nog niet. Ikzelf neig in eerste instantie naar een tabel voor de superclass en elke afgeleide class ook een tabel met hierin de specifieke velden van die afgeleide class, maar eigenlijk ga ik dat vooral van de O/R mapper af laten hangen vermoed ik ;)/

NAW zou ik gewoon bij de persoon houden. Niet opslaan in een apparte tabel. Je hebt nauwlijks voordelen en in 99,99% van de gevallen wordt het een 1 op 1 koppeling. Mocht je al twee personen hebben die op hetzelfde adres wonen dan heb je nog geen garanties dat ze tegelijk gaan verhuizen (mensen die gaan scheiden, kinderen die uit huis gaan). Bij een koppeling kun je al snel de fout maken dat je iedereen op dat adres meeverhuist.

Voor de buisnesslogic ga ik met Alarmnummer mee. Ondanks dat in de tabel allemaal losse velden staan zou ik binnen de buisnesslogic wel met een AdresObject werken, maar ook hier is het van een heleboel randvoorwaarden afhankelijk.

[Janoz]

-FoX- schreef op vrijdag 10 november 2006 @ 10:28:
Hoever moet je gaan als je buitenlandse adressen ook wil ondersteunen? Die hebben toch ook een street, nr, zip, city..

Ik wist dat ik ooit ergens wat gelezen had, maar met wat creatief googlen heb ik het weer kunnen vinden:

http://homepage.mac.com/b...hitect/global.htm#GLOBAL5