Relatie leggen

[fredmatrack]

Hallo,

 

momenteel ben ik bezig met een database waarin een inventaris komt van alles wat in onze klaslokalen te vinden is: stoelen, computer, gordijnen, water, stopcontacten,...

 

Op dit moment heb ik een tabel met lokalen tblLokalen(lokaalid en lokaalnummer) en per categorie van items een tabel: tblICT(ictid, type, serienummer), tblNutsvoorzieningen(nutsid,type, aantal),...

 

Nu is het zo dat we elk item een uniek nummer (piustiennr) willen gaan geven binnen de school. Elk apparaat krijgt dan een sticker met dat nummer op.

 

De vraag is, hoe maak ik het best deze nummering aan? Ik kan in elke tabel met items wel een veld 'piustiennr' aanmaken en dat zal prima gaan. Echter, als er nadien iemand wil gaan zoeken op dat nummer, dan moet die al op voorhand weten in welke tabel dat nummer (mogelijk) voorkomt.

bv. een computer met nummer 1234 is dan enkel te vinden via het veld piustiennr in de tabel tblICT.

 

Via scripting is dat wel op te lossen, maar is het een goede oplossing? Is het niet beter van met een extra tabel piustiennrs te werken en die te linken?

 

Graag uw mening. Bedankt!

[AvD]

Duidelijk analyseprobleem. Kijk in het documentatie-gedeelte van het forum eens naar de normalisatieregels. Dan zie je vanzelf waar je mis zit.

[fredmatrack]

Klopt, een analyseprobleem. Nu heb ik wel wat ervaring in het maken van dit soort dingen, maar vaak kom ik dan tegen een 'extra moeilijkheid' van FileMaker terecht. Zo gaat FileMaker bijvoorbeeld plots extra instanties maken van een tabel als je een bepaalde relatie legt. Dat is iets dat ik MySQL, Oracle,... nog niet ben tegen gekomen.

 

Vandaar dus mijn vraag, wie kan hier een concrete werkwijze voorstellen?

[AvD]

Zo gaat FileMaker bijvoorbeeld plots extra instanties maken van een tabel als je een bepaalde relatie legt. Dat is iets dat ik MySQL, Oracle,... nog niet ben tegen gekomen.

Klopt, en hier heb je een punt. Ik vond dat ook heel vervelend. In de praktijk heb je binnen het technisch FileMaker concept geen andere keus dan deze multiple occurrences te accepteren. Zorg er alleen voor dat ze een duidelijke en ondubbelzinnige naam hebben.

[JeanWM]

Ik vond dat ook heel vervelend. In de praktijk heb je binnen het technisch FileMaker concept geen andere keus dan deze multiple occurrences te accepteren.

 

Pardon me, eigenlijk hebben we binnen FileMaker wel een keuze.

 

We moeten duidelijk een onderscheid maken tussen data model en database model.

 

Een datamodel is, zo uit het vuistje, een algemeen model hoe de informatie zou moeten georganiseerd worden en wat je met de informatie zou kunnen/moeten doen.

Een relationeel model is zo een ding en voor zover ik weet, tot nu toe, het enige.

 

Een database model daarentegen is een model van je te ontwikkelen database. Big difference.

 

Binnen het data model, en hier gaat het bij velen mis, spreken we enkel over een formal model.

 

Er bestaat echter ook een symantic model.

Een Entity-relationship is een voorbeeld van zo'n model.

 

Eigenlijk heb je beide nodig, het hangt ervn af hoe je design van je database is: bottom-up of top-down benadering. En hier gaan er velen de mist in door het zo gemakkelijk kunnen leggen van relaties binnen FileMaker, je trekt simpel een lijntje tussen twee veldbenamingen (en eigenlijk geen relationship-key).

 

Bij een formal model ga je de structuur en de integriteit beschrijven en hoe queries uit te voeren op de door het model getoonde data.

 

Wat het relationele model betreft, hebben we te maken met rekenkundige relaties (voor de structuur), first-order logic (voor de integriteit), en relationele algebra en calculus (voor query).

 

Als je dat een beetje door elkaar gaat halen bij de opbouw van een FileMaker toepassing, verkrijg je inderdaad het probleem van extra instanties.

 

Velen laten zich verleiden tot het spinneweb model (het door elkaar halen van de models), terwijl het beter is om vanuit iedere basistable te vertrekken en het altijd zo te houden.

Dat wil dan inderdaad zeggen dat je bepaalde zaken zult moeten scripten.

Maar binnen FileMaker is scripten de eigenlijke ontwikkelingsmotor, hier doe je aan coding.

Dat wil zeggen dat het daar de ideale plaats is om als ontwikkelaar de applicatie te gaan beheren en ook beheersen.