[ALG] Datamodel / Data Ontwerp vraag in Access97

[ErikRo]

Ik moet / mag (mijn eerste) tabelontwerp binnen Access97 maken en dat leek niet zo moeilijk, op papier dan
Hoe de achterliggende functionaliteit eruit gaat zien heb ik al af, net als alle straks te gebruiken schermen. Code zal straks door iemand anders in ACCESS VB erachter gehangen worden aan de hand van mijn ontwerp en uitleg. Nu wil ik wel meteen het tabelontwerp volgens een "officiele" manier doen.

Nu kom ik toch wat dingen tegen die ik niet meteen in de boekjes terugvind.
Ik hoop dat jullie eea willen verbeteren danwel aanvullen of andere tips.

Vraag 1:
In een normale relationale DB join je twee tabellen met 1/n op 1/n relatie, omdat ze naar elkaar verwijzen en dezelfde data twee keer opslaan. Dus een lijntje ertussen trekken en klaar

Maar dit is niet normaal (denk ik) maar hier wel handig. Want ik wil namelijk alle adres data uit tabel1 kopieren dmv veld NummerID naar een adres data in tabel2. Zodat deze later of meteen aanpasbaar is in tegenstelling tot tabel1 (die alleen lezen is).
Tabel 2 bevat dus uiteindelijk het complete record (dossier) en met deze data zal uiteindelijk alles gebeuren. Zoals brieven maken, rapporteren, gegevens bijhouden.
Tabel1 dient dus eigenlijk meer als een soort voorvulling voor tabel2.

Moet ik nu nog steeds tabel 1 en tabel 2 tekenen met een join tussen velden NummerID?
Of alleen T2 met een join naar andere tabellen en T1 ergens los in een hoekje zonder enige join/koppeling?


Vraag 2:
Elke tabel (minimaal 20 stuks) krijgt aan het eind twee velden "DatumLaatsteMutatie" en "GebruikerLaatsteMutatie" om te kunnen zien wie de laatste mutatie heeft uitgevoerd. Dit wordt nergens getoond, maar is meer bedoeld voor intern gebruik bij eventuele problemen in de toekomst..
Deze "GebruikerLaatsteMutatie" wordt wel relationeel gekoppeld aan een gebruikers tabel. Maar als ik daardoor ook weer 20 extra lijnen naar die andere 20 tabellen trek, wordt het straks wel erg vol met lijnen die kris kras door elkaar lopen.
Is dit toch verplicht ondanks dat iedereen in één oogopslag wel ziet / snapt dat waar het vandaan moet komen. Of mag je hem dan weglaten voor de leesbaarheid?


Vraag 3:
Een simpele listbox "geslacht" die alleen "M" en "V" kent, moet ik die ook in een tabel vangen en tekenen? Of valt dat gewoon onder standaard veldvulling?


Vraag 4:
Een extra ID toevoegen wanneer wel en wanneer niet. Ik zelf zou zeggen hoe minder velden, hoe beter. Toch zie ik wel eens dat er bij een tabel waar minimaal één veld uniek lijkend veld aanwezig is bv hier "pakketcode" toch en extra uniek veld bijgemaakt is bv pakketID
Ik zelf zou zeggen koppel mbv dat eerste unieke veld naar een ander tabel. Maar ik hoorde van een programmeur dat hij dat zo geleerd had. Altijd zelf één uniek ID veld aan een tabel toe te voegen en daarmee te joinen. Waarom kon hij me niet vertellen. Zo hoorde het nou eenmaal.

Ben ik nou gek of .......
Creeer je soms zo ruimte voor toekomstige uitbreidingen? bv historie vastleggen, maar dat kun je toch vast ook wel achteraf toevoegen?


Vraag 5:

Externe hulp tabellen bv uit een andere omgeving bv oracle of andere backendsDB's, moet ik die ook tekenen / opnemen in mijn ontwerp. Maar hoe, want er is geen sprake van gekoppelde tabellen die ik kan slepen.
In VBA wordt straks de tabel aansproken, dan de waarden opgehaald, klaar.


Vraag 6:

Alle velden uit externe tabel opnemen is dat verplicht?
Eén ext. tabel is nogal groot, terwijl ik maar 5 velden eruit nodig heb. Mag ik alleen die 5 velden tekenen / opnemen of is dat "not done"


Ik hoop dat eea een beetje duidelijk overkomt, ik heb het nu 5 keer doorgelezen en zelfs ik snapte het
Alvast bedankt voor alle hulp.

[faabman]

ErikRo schreef op 03 maart 2004 @ 20:35:
Vraag 1:
In een normale relationale DB join je twee tabellen met 1/n op 1/n relatie, omdat ze naar elkaar verwijzen en dezelfde data twee keer opslaan. Dus een lijntje ertussen trekken en klaar

Maar dit is niet normaal (denk ik) maar hier wel handig. Want ik wil namelijk alle adres data uit tabel1 kopieren dmv veld NummerID naar een adres data in tabel2. Zodat deze later of meteen aanpasbaar is in tegenstelling tot tabel1 (die alleen lezen is).
Tabel 2 bevat dus uiteindelijk het complete record (dossier) en met deze data zal uiteindelijk alles gebeuren. Zoals brieven maken, rapporteren, gegevens bijhouden.
Tabel1 dient dus eigenlijk meer als een soort voorvulling voor tabel2.

Moet ik nu nog steeds tabel 1 en tabel 2 tekenen met een join tussen velden NummerID?
Of alleen T2 met een join naar andere tabellen en T1 ergens los in een hoekje zonder enige join/koppeling?

ik snap niet helemaal wat je hiermee wil zeggen, bedoel je nou genormaliseerd?? Het is in ieder geval niet de bedoeling om in een genormaliseerde db data dubbel op te slaan...

Vraag 2:
Elke tabel (minimaal 20 stuks) krijgt aan het eind twee velden "DatumLaatsteMutatie" en "GebruikerLaatsteMutatie" om te kunnen zien wie de laatste mutatie heeft uitgevoerd. Dit wordt nergens getoond, maar is meer bedoeld voor intern gebruik bij eventuele problemen in de toekomst..
Deze "GebruikerLaatsteMutatie" wordt wel relationeel gekoppeld aan een gebruikers tabel. Maar als ik daardoor ook weer 20 extra lijnen naar die andere 20 tabellen trek, wordt het straks wel erg vol met lijnen die kris kras door elkaar lopen.
Is dit toch verplicht ondanks dat iedereen in één oogopslag wel ziet / snapt dat waar het vandaan moet komen. Of mag je hem dan weglaten voor de leesbaarheid?

Als je echt een historie wilt bijhouden kun je beter een tbl_wijzigingen aanmaken waarin je bijhoudt wat er gewijzigd is (dus de oude data kopieren) en door wie (een FK naar de tbl_gebruikers)

Vraag 3:
Een simpele listbox "geslacht" die alleen "M" en "V" kent, moet ik die ook in een tabel vangen en tekenen? Of valt dat gewoon onder standaard veldvulling?

Ik ben zelf nogal eens geneigd om M/V op te slaan in een bit / boolean veld, is lekker klein...

Vraag 4:
Een extra ID toevoegen wanneer wel en wanneer niet. Ik zelf zou zeggen hoe minder velden, hoe beter. Toch zie ik wel eens dat er bij een tabel waar minimaal één veld uniek lijkend veld aanwezig is bv hier "pakketcode" toch en extra uniek veld bijgemaakt is bv pakketID
Ik zelf zou zeggen koppel mbv dat eerste unieke veld naar een ander tabel. Maar ik hoorde van een programmeur dat hij dat zo geleerd had. Altijd zelf één uniek ID veld aan een tabel toe te voegen en daarmee te joinen. Waarom kon hij me niet vertellen. Zo hoorde het nou eenmaal.

Ben ik nou gek of .......
Creeer je soms zo ruimte voor toekomstige uitbreidingen? bv historie vastleggen, maar dat kun je toch vast ook wel achteraf toevoegen?

wanneer je altijd een identity veld toevoegt (autonummering in access) dan weet je zeker dat je nooit het probleem krijgt waarin je db niet kan bepalen welk record er verwijderd moet worden omdat er geen unieke waarden zijn, daarnaast is het voor een devver handig om een veld op basis van een nummer aan te spreken (maar, dat is persoonlijk)

Vraag 5:

Externe hulp tabellen bv uit een andere omgeving bv oracle of andere backendsDB's, moet ik die ook tekenen / opnemen in mijn ontwerp. Maar hoe, want er is geen sprake van gekoppelde tabellen die ik kan slepen.
In VBA wordt straks de tabel aansproken, dan de waarden opgehaald, klaar.

gewoon via odbc of dsn een verbinding maken en alleen die velden importeren die nodig zijn

Vraag 6:

Alle velden uit externe tabel opnemen is dat verplicht?
Eén ext. tabel is nogal groot, terwijl ik maar 5 velden eruit nodig heb. Mag ik alleen die 5 velden tekenen / opnemen of is dat "not done"

nee, dat is niet verplicht


tips:
- Je hebt het telkens over het rekken van lijntjes, dat is imho een typische wizard benadering... Het gaat erom dat je de techniek erachter begrijpt... Met het trekken van een lijntje bepaal je namelijk voor een tabel een foreign key
- gebruik de search, er zijn op GoT genoeg van dit soort topics te vinden... daarnaast hebben we ook altijd nog google...

[ErikRo]

ik snap niet helemaal wat je hiermee wil zeggen, bedoel je nou genormaliseerd?? Het is in ieder geval niet de bedoeling om in een genormaliseerde db data dubbel op te slaan...

Euh, nee ik haal deze data op uit een externe database cq tabel. En kopieer deze data vervolgens naar mijn eigen DB cq tabel en die sla ik (eventueel iets gewijzigd) op. Met de die externe DB doe ik dus verder niets. Mag ik ook niet, want hij is niet van mij.
Opnemen in mijn tabel schema? Ergens in het functioneel ontwerp aangeven?

Als je echt een historie wilt bijhouden kun je beter een tbl_wijzigingen aanmaken waarin je bijhoudt wat er gewijzigd is (dus de oude data kopieren) en door wie (een FK naar de tbl_gebruikers)

Het is niet een echte historie, meer dat als er achteraf een fout is gemaakt met invoeren, dat we even kunnen kijken wie dat was en hem / haar hierop aanspreken.

wanneer je altijd een identity veld toevoegt (autonummering in access) dan weet je zeker dat je nooit het probleem krijgt waarin je db niet kan bepalen welk record er verwijderd moet worden omdat er geen unieke waarden zijn, daarnaast is het voor een devver handig om een veld op basis van een nummer aan te spreken (maar, dat is persoonlijk)

OK, dat ga ik dan voortaan ook altijd doen.

Ik ben zelf nogal eens geneigd om M/V op te slaan in een bit / boolean veld, is lekker klein...

OK, maar stel dat er ooit een waarde "O" van "onbekend" bijkomt. Moet ik dan wel een minitabel maken en deze in het ontwerp opnemen. Want access kent listboxen waarin je gewoon een paar mogelijke waarden invult. Hoeven niet perse in een tabel te staan. Maar dat weet ik vooraf niet want dat bepaalt de programmeur

[faabman]

om de optie van geslacht onbekend toe te voegen kun je in het veld NULL waarden toestaan... (wanneer je je db-model volledig uitnormaliseerd zul je denk ik wel een extra table moeten maken, maar, ik kan me eigenlijk geen situatie indenken waarbij het geslacht van iemand andere waarden aan kan nemen dan onbekend / man / vrouw en dus lijkt het me in dit geval onnodig...)