SUMit Roostersoftware > Wekelijkse Noot > Maart 2001 > Halfbroers English · Zoek...

Halfbroers

 Maandag, 12 maart 2001 Over Noot Januari 2001 Februari 2001
Maart 2001
Anoniem
Halfbroers
Oor Kip April 2001 Mei 2001
Automatiseerders zijn een bijzonder volkje. Ze leven een beetje naast de normale maatschappij, aan de rand, doch niet in de goot.

Deze bijzonderlingen kunnen ongewoon fel strijden over abstracte vraagstukken als:

  1. Is het object model van het database model afgeleid of andersom?
    antwoord
  2. Moeten een Class in de objectenlaag 1 op 1 staan tot een tabel in de databaselaag?
    antwoord
  3. Moet een attribuut van een Class dezelfde naam hebben als een kolom van een tabel?
    antwoord
Laat ik vrolijk eens wat olie op het vuur gooien met m'n persoonlijke antwoorden.

1. Het logische model

Is het object model van het database model afgeleid of andersom?

Nee. Geen van beiden.

Het objecten model en het database model zijn twee afgeleiden van een gemeenschappelijke bron: het conceptuele model. Logisch Ontwerp Zie het schema met afhankelijkheden in OO ontwikkeling.

De fase "Conceptual modelling" resulteert in een logisch model, input voor

  • OO modellering, wat input is om Classes en attributen te maken.
  • fysiek database design, wat input is om tabellen en kolommen te maken.
Het OO model en het fysieke database model verhouden zich als twee halfbroers, kinderen van een gemeenschappelijke ouder.

2. Equivalenten

Moet een object model 1 op 1 equivalenten hebben in een databaselaag?

Nee, absoluut niet.

Het OO model en fysiek database model mogen dan familie zijn, maar het zijn géén volle broers en zeker geen ééneiige tweeling. Elk heeft z'n unieke eigenschappen.

Object Model Fysiek Database Model
Implementeert many-to-many relaties met zaken als een Vector of Hashmap, desnoods aan beide zijden van de relatie, maar alleen als er een functionele noodzaak voor is. Many to Many Implementeert many-to-many relaties vrijwel altijd met een link tabel, die alleen key kolommen heeft.
Many to One Implementeert many-to-one relaties met een verwijzing naar een andere instance, echter alleen als er een functionele noodzaak voor is. Implementeert many-to-one relaties altijd met een foreign key aan de many kant, wat ook de functionele reden mag zijn.
Implementeert one-to-many relaties met zaken als een Vector of Hashmap, maar alleen als er een functionele noodzaak voor is. One to Many Implementeert one-to-many relaties met een index op de foreign key, maar alleen als er een technische reden is tot performance optimalisatie.
One to One Implementeert one-to-one relaties door entiteiten te combineren tot één classe, of een combinatie te maken van super en subclasses. Implementeert one-to-one relaties door verschillende tabellen te linken met een foreign key in de tabel met de laagste frequentie van gebruik.
Elk attribuut krijgt een plek in één specifieke classe, met sterke encapsulation. Zelfs keys worden niet dubbel opgeslagen. Een kolom kan gedenormaliseerd worden en dus voorkomen in diverse tabellen. Key informatie komt sowieso dubbel voor, in diverse tabellen en indexen.
Een method kan in diverse classes geïmplementeerd worden, gebruik maken van polymorfisme en inheritance. In sommige RDBMSsen kan de programmeur wat coding in stored procedures kwijt. Deze maken het systeem echter lastig te debuggen. Triggers voor stored procedures zijn bovendien storingsgevoelig omdat ze niet altijd actief staan.
Bij een object model zal een instance altijd tot één classe behoren. In een database kan een result set informatie van meerdere tabellen bevatten.
Conclusie: De result set van één enkele SQL query kan als bron dienen voor waardes van diverse attributen van diverse instances van diverse classes.

3. Mapping

Moeten attributen in de objectenlaag dezelfde naam hebben als in de database laag?

Nee, alsjeblieft niet.

Het aardige van een 3-tier architectuur is nu juist dat de lagen vrij onafhankelijk van elkaar zijn. De technische structuur van de database kan veranderen, zonder impact op het object model.

Het is bijvoorbeeld mogelijk om twee tabellen te combineren, om performance redenen. Dit kan zelfs na implementatie. Het zou dan te gek zijn als ook het object model aangepast moest worden.

Tips

  1. Maak alsjeblieft géén classes per tabel, maar één classe voor de hele database. Die database classe kan dan mooi met een SQL join kollommen uit diverse tabellen combineren.
  2. Hou de interface tussen database- en objectenlaag flexibel. Gebruik een result set als interface tussen DB en OO laag. Geef elke kolom in de SQL result set een vast alias, die in elke query hetzelfde is.
  3. Stem deze alias af op het conceptuele, logische model, niet op de fysieke database of classe structuur. Zo blijft de interface tussen object en database laag mooi op logisch niveau, compleet onafhankelijk van de fysieke implementatie.
Tot de volgende week,
Henk Jan Nootenboom
Februari 2001 · Anoniem · Halfbroers · Oor · Kip · April 2001
Home · Zoek...