Relaties : waarom toont FM dubbelgebruikte tabellen 2x ?

[Aerius]

Een ingewikkelde vraag met hopelijk een simpel antwoord. Daarom misschien best dat ik eerst even de situatie schets.

 

Als laatstejaarsstudent ICT moest ik een vrij complexe database schrijven op mijn stageplaats in Filemaker. Na lang nadenken en analyseren kwam ik tot de conclusie dat ik enorm veel tabellen nodig had (100tal), waar ik zowiezo niet buitenkon. Bij deze tabellen zitten voornamelijk koppeltabellen (om veel op veel relaties te kunnen realiseren van de vorm ->

 

TBLofferte - TBLkoppel001...049 - TBLartikel

 

Bij een offerte kunnen eindeloos veel artikels toegevoegd worden, en een artikel kan aan meerdere offertes toegevoegd worden. Vandaar dat ik die koppeltabel als noodzakelijk zie.

 

-------------------------------------------

Nu mijn vraag dan: Als ik bij de relaties, koppelingen ga leggen, dan ontstaan er een soort van kringkoppeling. Op zich geen erg. Maar FM laat dit niet toe en maakt dan een extra instantie van die tabel artikels en toont die ook in het relatiescherm. Als je dan weet dat ik veel tabellen nodig had, wordt heel het relatie-overzicht ONoverzichtelijk.

 

Als ik daar dan nog aan ga toevoegen, dat er ook nog een tabel vertalingen meespeelt, krijg ik dus in het relatie-overzicht, 2 tabellen per koppeltabel. Ik weet natuurlijk niet exact hoe Access hier achter de schermen mee omgaat ? Maar ik hoopte dat iemand mij kan vertellen waarom dit in Filemaker zo getoond wordt (en waarom je dit niet als 1 tabel kan tonen bij de relaties waar er een soort kring ontstaat ?)

 

Om heel te situatie toch nog even te verduidelijken heb ik in bijlage een figuur geplaatst die de situatie schetst voor 2 koppeltabellen.

 

----------

 

 

Ik hoop dat iemand mij kan helpen

 

mvg

Bart

[Koen Van Hulle]

Leuke vraag.

 

Het grootste nadeel die je vandaag hebt, is dat je Access kent en de relatiediagram in FileMaker op lijkt. maar schijn bedriegt.

 

Een paar basis zaken:

 

- FileMaker kent geen scheiding van Data en Interface en kent ook geen tussen layer (application layer). Dat houdt in dat je layouts maakt rechtstreeks op je data. Er is dus qeen query niveau tussen.

 

- Perspectief is een belangrijke trefwoord. Elke script en berekening wordt vanaf een bepaald tabel uitgevoerd. Die tabel staat op de grafiek. Zo'n tabel heet in FileMaker een occurence.

Bij een berekeningsveld ga je dan ook dat perspectief gaan bepalen; Je moet aangeven vanaf welke occurence deze berekening hij moet berekenen.

Een script wordt uitgevoerd vanop de huidige layout. Elke layout is gebasseerd op een occurence. Dit moet je aangeven bij aanmaken bij een layout. Dat wil zeggen dat alle records die getoond op deze layout behoren tot deze occurence.

 

Als je wil rekenen met gerelateerde data of gerelateerde data wil tonen, dan gaat FileMaker altijd vertrekken van de occurence waar je nu bent (dus vanaf je layout of de definitie van je berekeningsveld) en dan de relaties (draadjes) volgen tot aan je data.

 

Als je een cirulaire relatiediagram zou maken, zoals in Access, zou dat niet werken. FileMaker zou dan niet weten welk draadje hij moet volgen.

 

Dus de basis filosofie is anders.

 

- Je hoeft niet alles in 1 graph proberen te hangen. je kan ook meerdere kleinere graph's tekenen. Als een soort data eilandjes.

 

 

Wat je toepassing betreft:

Je moet je afvragen of het echt nodig is om 100-tabellen te hebben en of je data model niet onnodig complexer is dan nodig.

 

 

 

Koen

[Aerius]

Bedankt voor het heel duidelijke en snelle antwoord. Het is niet altijd even evident om over te schakelen naar een pakket dat je veel minder beheerst dan bv. in mijn geval Access. Toch is die overgang verder vrij goed verlopen.

 

Wat je toepassing betreft:

Je moet je afvragen of het echt nodig is om 100-tabellen te hebben en of je data model niet onnodig complexer is dan nodig.

 

Ik dacht aanvankelijk ook dat ik met veel minder alles zou kunnen realiseren. Maar spijtig genoeg was dit niet het geval. Omwille van kleine beperkingen die ik ondervond wanneer je bv. portalen gaat gebruiken (filteren op gegevens, hoewel ik hiervoor wel workarounds heb gevonden). En omwille van het feit dat praktisch alle koppeltabellen verschillende eigenschappen hebben. Zo is een hoogte voor sommige van die tabellen vereist; voor een andere dan weer 3 lengtes; voor een andere een aantal; voor nog een andere een kleur, diepte en een breedte, enzovoort, ...

 

Ik heb er dikwijls over nagedacht om alles in 1 grote tabel te brengen, maar ik zou dan ongelofelijk veel velden krijgen die (afhankelijk van het artikel) waarschijnlijk nooit zouden worden ingevuld. Weer een extra motivatie om met meer tabellen te gaan werken.

 

Bovendien was dit niet een opdracht zoals het typische schoolvoorbeeld met leerlingen, leraars, klaslijsten en klassen of producten, leveranciers, klanten,...

[Joris Aarts]

Een Access database bevat maar één ER-diagram en meestal een hele verzameling van queries (sommige als losse SQL-statements in Combo- of list boxes).

Het FileMaker relatiediagram is GEEN ER-diagram. Ga ervan uit dat wat je in Access met afzonderlijke queries doet, in FileMaker clusters (of eilandjes) van table occurrences (TO's) zijn. Dus voor elke speciale context ga je inderdaad extra TO's bijmaken. Dat organiseren is een uitdaging maar het is zeker te doen. En er bestaat een massa literatuur over.