basis tabel met een-op-een relaties naar meerdere tabellen geeft: #FOUT

[JewelRE]

Hai, hierbij een vraag waarvan ik hoop dat jullie mij snel weer op weg kunnen helpen..

Ik heb enkel wat ervaring met aanpassingen in een bestaande database en het bouwen van een database op basis van 1 grote tabel. Nu is mij gevraagd om een nieuwe database te bouwen waarbij informatie niet uit 1 tabel wordt gehaald, maar waarbij de gegevens zijn opgesplitst in meerdere tabellen. (Dit in verband met een heel erg groot wordende tabel) Het betreft een database voor real estate met zo'n 200 panden (=adressen), waarbij het adres de basis is en overige tabellen bijbehorende zaken vermelden (te denken aan: contractgegevens, finaciele gegevens, gegevens voor 4 gebruikers, contactgegevens intern, etc). Op een formulier moet alle data ingevuld en weergegeven kunnen worden, met bovenaan het adres en daaronder overige gegevens op tabbladen volgens de gelijke opbouw als de tabellen. Elk adres bevat een eigen ID (handmatig in te voeren), welke mee moet worden genomen in elke tabel, om data per adres later weer in een rapport of query desgewenst te kunnen samenvoegen. Omdat ik de tabellen wil splitsen had ik al begrepen dat een weinig voorkomende een-op-een relatie nodig is.

Ik ben al begonnen met een opzet (Access 2010);
- tabellen (moeten er nog meer bij later): Address, activity, finance, general, links
- tabellen voor keuzevakken op formulier
- formulier (zoals boven beschreven)
- Relaties: Ik heb om het AddressID (primaire sleutel) mee te kunnen nemen van de tabel Address een-op-een (ref. integ. afgedwongen) relaties gemaakt naar de AddressID's op de overige 4 tabellen.
Hiernaast zijn er 5 andere relaties om keuzevakken op het formulier te krijgen: Activity heeft een "onbepaalde" relatie met tabel BA; General heeft 3 een-op-veel relaties met 3 verschillende tabellen met contactpersonen en een "onbepaalde" relatie met tabel Status. Deze laatste 5 relaties lijken respectievelijk te werken.

Na het invullen van gegevens op het formulier verschijnt de foutmelding "U kunt geen record toevoegen omdat voor de tabel Activity een gerelateerde record vereist is" en bij verder klikken op de besturingsknoppen verschijnt er "Update of CancelUpdate zonder AddNew of Edit" en verschijnt er in alle besturingselementen op het formulier: #FOUT.
Het formulier slaat geen record op, ook de tabellen blijven leeg.

Kan iemand zo zien wat ik niet goed doe?

Groetjes,
JewelRE

(PS. Mochten er na het lezen tips zijn om de opbouw slimmer aan te pakken, opbouwende kritiek is altijd welkom!)

 

[OctaFish]

Om te zien of je db slimmer kan, zullen we hem moeten zien. Wat is de reden dat je denkt dat je de tabel moet opsplitsen? Want je haalt je meer ellende op de hals dan dat het winst oplevert. Dus daar moet je een aanleiding voor hebben. En dan liefst niet iets als:

... maar waarbij de gegevens zijn opgesplitst in meerdere tabellen. (Dit in verband met een heel erg groot wordende tabel)

Want dat is een drogreden.

 

[JewelRE]

Dank voor het reageren!

Ik snap je opmerking omtrent het splitsen, maar in mijn geval de beste reden die er voor mij is: de baas wil het zo.
Zijn reden hiervoor daarentegen zou kunnen zijn dat meerdere afdelingen (verschillende vakgebieden) werkzaam zullen zijn met deze database waardoor gegevens niet door elkaar moeten komen te staan, maar wel verzameld op 1 plek.

 

[OctaFish]

Tenzij de baas een gediplomeerd databasebouwer is, die weet wat hij doet, is dat de volgende drogreden

Ik snap je opmerking omtrent het splitsen, maar in mijn geval de beste reden die er voor mij is: de baas wil het zo.

En we worden verwend, want er is er nog een:

Zijn reden hiervoor daarentegen zou kunnen zijn dat meerdere afdelingen (verschillende vakgebieden) werkzaam zullen zijn met deze database waardoor gegevens niet door elkaar moeten komen te staan, maar wel verzameld op 1 plek.

Ik ben misschien een beetje streng, maar een database moet je bouwen op basis van logica. En En als die ontbreekt, dan ben je alleen maar een hele diepe kuil voor jezelf (je maakt een niet te onderhouden database) en het bedrijf.

 

[JewelRE]

Haha, ach ja streng is soms niet verkeerd, ik snap je geloof ik ook wel

Ik kan 2 dingen doen;
1) ik vertel mijn baas dat hij drogredenen aanvoert voor het bouwen van een dergelijke database, met als gevolg dat ik per direct de grote-boze sollicitatie wereld kan gaan betreden, want dan is de klus geklaard. (Ik heb de database op basis van 1 tabel reeds gemaakt)
2) ik bouw de database naar zijn wens en werk nog even een aantal uren en heb in de tussentijd ruimte om een studie te volgen en een betere kans te hebben op de arbeidsmarkt.

Welke zal ik doen?

NB. De baas is op de hoogte van de complexiteit.

Wat betreft onderhoud volg ik je niet, met Access (2010) is er toch de mogelijkheid om records synchroon (als in mijn geval: tabellen gelinkt met unieke ID's, oftewel steeds 1 record per ID per tabel) te verwijderen?

 

[Tardis]

Je vergeet de belangrijkste.....

Optie 3, je maakt een voorstel met opties, plussen en minnen en hangt daar een advies aan.
Keuze is aan de opdrachtgever.
Betekent wel dat je goed moet weten waar je het over hebt, anders wordt je onvolwaardig gesprekspartner meteen onder tafel geveegd.

Wat me op optie 4 brengt, je stelt voor om eea nu meteen goed aan te pakken en stelt voor dat je eerst uit kan/mag zoeken wat de opties zijn.
Darna kom je met met optie 3.
Moet toch kunnen als je baas op de hoogte is van de complexiteit.

Tardis

 

[JewelRE]

Dank voor de reacties!
Niet geheel zoals verwacht desalniettemin kan ik ermee aan de slag. Heb contact opgenomen met een ervaren bouwer en zie net dat er een cursus van OctaFish is, deze zal ik eens bekijken.

Ik ga inderdaad maar beginnen met een goed (eigen) ontwerp bij de gestelde doelen en dan kijken hoe dicht we komen bij de opzet van de werkgever.

Ik heb al wat gezocht en vond onderstaande tekst op de MO-ondersteuningssite;

Een goed databaseontwerp is daarom een ontwerp dat:
- Uw gegevens opsplitst in tabellen op basis van onderwerp om zo redundante gegevens te voorkomen.
- Access de gegevens levert die het programma nodig heeft om de informatie in de tabellen op de gewenste manier samen te voegen.
- Helpt de nauwkeurigheid en integriteit van de gegevens te garanderen.
- Voldoet aan uw wensen op het gebied van gegevensverwerking en -rapportage.

Hiervan raak ik wat in de war -> wel of niet splitsen van de tabellen? Ik wil jullie niet mijn werk laten doen, maar kunnen jullie mij wel een richting geven waarin ik moet denken of waar ik informatie kan vinden over een goede opbouw?

Groet,
JewelRE

 

[OctaFish]

In de cursus wordt het normaliseringsproces uitgelegd, en daarnaast zijn er diverse webpagina's die er wat dieper op ingaan. Typ als zoekterm 'database normaliseren' en je vindt een schat aan informatie.
De essentie is, dat je het bronbestand goed bekijkt, en daarin aangeeft welke gegevens herhalend terugkomen. Die zijn geschikt om naar een aparte tabel te verplaatsen. Als je bijvoorbeeld een (Excel)tabel hebt met daarin Ordernummers, dan zijn die in beginsel uniek. Heb je in diezelfde tabel ook de klantgegevens staan, en doen klanten meerdere orders, dan staan die klantgegevens er meerdere malen in. Klantgegevens moeten dus naar een aparte tabel. Heb je per order verschillende produkten, dan zul je per order ook meerdere regels hebben, Daarin staat dan steeds hetzelfde ordernummer, maar elke keer een ander artikelnummer, en dus die herhalende klantgegevens. Daar kun je ook een splitsing voor maken.
In bovenstaand voorbeeld zitten twee niveau's: de klantgegevens vind je terug op zowel orderniveau als orderregel niveau. Klantgegevens zijn eigen 'entiteiten', en die splits je op basis van de 1e Normaalvorm. Klantgegevens zijn niet afhankelijk van de orders. Orderregels splits je op basis van de 2e Normaalvorm, want Orderdetails horen bij een Order.
Normaal gesproken haal je eerst alle blokken er uit die zelfstandig zijn, de 1e Normaalvorm dus. Vervolgens ga je naar de 2e Normaalvorm over, en als volgende stap naar de 3e Normaalvorm.

 

[JewelRE]

Ik heb mijn onderzoek gedaan en heb besloten af te zien van het splitsen van tabellen. Ook ik zie geen technische noodzaak om deze aanpassing door te voeren, door het gebruik van query's en rapporten volstaat een grote tabel ook prima.

Allen dank voor de feedback en succes! Wie weet tot de volgende keer!