tabel kwijt

Status
Niet open voor verdere reacties.

Zurrik

Gebruiker
Lid geworden
17 mrt 2006
Berichten
221
In de toegevoegde bijlage zie je dat ik in de relaties een tabel mis.Hij is er wel maar ik zie m niet, hoe kan ik deze wel te zien krijgen? Ik heb al vanalles geprobeerd.
 

Bijlagen

  • relaties.JPG
    relaties.JPG
    26,7 KB · Weergaven: 66
Ongevraagd advies:

Helaas kan ik je niet helpen je vermiste tabel terug te toveren omdat ik al een tijdje niets in Access gedaan heb. Echter als ik naar je plaatje kijk zie ik dat je in de tabel orders twee attributen heb opgenomen die als "process gegevens" kunnen worden aangemerkt. Te weten "subtotaal" en "totaalkosten". Omdat dit "process gegevens" zijn horen ze eigenlijk volgens de normaliseringsregels niet thuis in de database.

HTH
Weest gegroet,
Guus
 
klopt wel maar ik wil ten allen tijden weten wat de subkosten en de totaalkosten van een order zijn. Dus niet alleen berekenen maar ook terug kunnen vinden als ik ooit nog eens naar de order zoek. Zou je dat dan niet zo doen?
 
Zo te zien is je tabel er nog wel, maar moet je even een scrollbar kietelen.
Jammer dat je niet een volledige screenprint gemaakt hebt.
Tip: maximaliseer access en het betreffende venster in access en kijk of je dan de scrollbar hebt.
 
Ja hij is er ook nog wel en het werkt ook gewoon maar ik kan m niet zien. Heel raar vind ik. Bijgevoegd de hele screenshot. Kun je meteen "commentaar" geven als je wil.
 

Bijlagen

Ik vind hem leuk!

Schuif eens een andere tabel naar boven en kijk of ie dan tevoorschijn komt.
 
Dat lukt niet. Ik heb ook geen idee hoe dat de tabel daar komt. Als ik een nieuwe neer zet maakt ie een kopie, dus hij staat er echt. Heel raar. Is het niet mogelijk om access alles automatisch te laten ordenen. Dan haalt access misschien de tabel terug in beeld?
 
Nog een poging.

Maak het relatievenster heel klein (zodat niet alle tabellen erin passen).
Kijk of je dan naar boven kunt scrollen om de verstopte tabel te pakken te krijgen.

Of

Open het relatievenster.
Kies in menu Bewerken optie Indeling Wissen
Rechtermuisknop in relatievenster, optie alle relaties weergeven.
Je moet wel effies de tabellen weer op de juiste plaats schuiven, maar waarschijnlijk heb je ze dan weer allemaal in beeld.
 
Het eerste werkt niet maar het tweede wel. Hartelijk dank. Heb je nog aanmerkingen op mijn indeling, anders verwijder ik mijn JPG weer.
 
Als ik nummers achter veldnamen zie staan begin ik al te bibberen en te beven.
Bijvoorbeeld tabel Klanten, Prijsverhoging1 en Prijsverhoging2.
Dan denk ik meteen: nieuwe tabel Prijsverhoging met een klantID, datumingang, Prijsverhoging.

Ook velden als Klant?, Leverancier? etc doen me gruwelen. Nieuwe tabel SoortOrganisatie en in tabel Klant dan een veld IDSoortOrganisatie dat verwijst naar de nieuwe tabel.

Adres is ook een aparte tabel, een organisatie kan verschillende adressen hebben (postadres, afleveradres etc. (dit is dus weer een tabel soortadres)).

Al dit soort zaken vallen onder het hoofdstuk normalisatie. Er zijn nog meer plekken in je datamodel waar je nog even goed naar zou moeten kijken.

Meer informatie over normaliseren kun je onder andere op de volgende sites vinden:
http://www.webessence.nl/artikelen/SQL/Normaliseren/
http://www.phphulp.nl/php/tutorials/3/150/259/
http://home.planet.nl/~digihans/pc_help/access/tabel_query.htm
 
oke dank je, en ik maar denken dat ik goed bezig was. Ik ga de sites doornemen.
 
maar bijvoorbeeld adres. Dat wordt een aparte tabel zeg je, geldt dat ook voor adres van de werknemer?
 
En nog een vraagje?

Iets wat optioneel is, bijv transporteurcode. Waar moet dat staan. Dat geldt alleen als de klant transporteur is anders niet.
 
Een adres is een adres. Het adres van een werknemer hoort dus in de tabel adres. Bij de werknemer neem je dan een verwijzing naar het record in de tabel adres op.
Je moet ook nadenken hoe je met adreswijzigingen omgaat. Wil je het oude adres ook bewaren? Zo ja, dan moet je datamodel daarvoor geschikt zijn.

Voor de transporteurcode zou ik een algemeen veld bij de soortorganisatie opnemen (bijvoorbeeld een veld opmerkingen). Daar kun je dan dat soort informatie in opnemen.
Als een klant meerdere rollen kan hebben zoals ze in soortorganisatie staan dan moet je een n op m relatie tussen de tabellen klant en organisatie maken. Dat betekent een derde tabel met id, idKlant, idSoortOrganisatie, fldOpmerkingen
 
Dank je, ik dacht echt dat ik al een heel eind was met het uitsplitsen en normaliseren van de db. Als ik dit zo lees denk ik, waarom had ik dat zelf niet kunnen zien. Maar goed wederom Thanks. Als ik straks denk klaar te zijn met normaliseren, zet ik m nog eens op het forum.
 
Tja,

Databases ontwerpen is een kunst, een gave, een specialisatie waar ik normaliter dik voor betaald wordt. Moet ik je een rekening nummer geven?:D
 
Ik ben met alle hulp blij, maar zoals ik al eerder aangegeven had, is mijn stagevergoeding dusdanig weinig dat ik je nu al niet meer zou kunnen betalen. Misschien een uurtje of zo, haha. Dus ik laat het aan jou over. Krijg ik geen reactie, dan heb ik pech. Toch? Overigens je kunt ten alle tijde je rekeningnummer achterlaten hoor. Maar dat zegt niks. :)
 
Is het slim om een tabel personen te maken of is het beter om te splitsen in werknemers en contactpersonen?
 
Lees je vraag en je weet waarschijnlijk het antwoord al.
Een persoon kan dus verschillende rollen hebben.
Je zult dus een tabel rol moeten maken (contactpersoon, werknemer,...)
Afhankelijk of één persoon meerdere rollen kan hebben of niet (is werknemer én contactpersoon of is werknemer óf contactpersoon) zul je een 1 op n relatie of een n op m relatie moeten maken.

Normaliseren dus.
 
Wat ik niet snap is het volgende:

Ik ben afhankelijk van of het is een werknemer, of het is een contactpersoon. Is het een werknemer dan wil ik meer gegevens weten als dat het een contactpersoon is. Bijvoorbeeld zijn toestelnummer. Maar in welke tabel hoort dit dan? Want het is wel nodig natuurlijk.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan