[Normaliseren] Access Database

[Verwijderd]

Om er nog even op livors zijn topic door te gaan. hier

Ik ben ook bezig met het normaliseren en al ff bezig
Nu heb ik hopelijk alles goed genormaliseerd en ik post het even.



het gaat hierbij om deze opdracht:



ik heb alles eerst in een excel sheet gemaakt, die is hier te vinden Klik hier

Hopelijk zijn jullie zo vriendelijk mijn normalisatie na te kijken.. want anders ben ik ook desparete

Het is de bedoeling dat hij genormaliseerd word tot de 3e normaalvorm

[Verwijderd]

foutje

[Alarmnummer]

Kijk nog een goed naar de cardinaliteit tussen:

-wagen / race
iedere wagen doet maar aan 1 race in zijn hele leven mee?

-wagen / wagen motor
iedere wagen heeft 1 motor maar 1 moter hoort bij meerdere wagens?

-wagen banden / wagen
iedere wagen heeft maar 1 band??

en zou je niet beter resultaat ook aan race en coureur kunnen koppelen ipv wagen alleen?

dit zijn een paar puntjes die ik zag.. ik durf te wedden dat er nog wel meer fouten zijn.

[Verwijderd]

Op vrijdag 22 maart 2002 17:53 schreef Alarmnummer een moeilijk woord

Wat is cardinaliteit

[Verwijderd]

verhouding

anyways ik heb dat nu verandert, nu al beter?

[Alarmnummer]

Op vrijdag 22 maart 2002 17:57 schreef Livors het volgende:

[..]

Wat is cardinaliteit

hmmmm.... dit krijgen jullie als vak en jullie krijgen niet het begrip cardinaliteit??

[Alarmnummer]

Wauw.. je kan altijd winnen bij jullie bij iedere race doet maar 1 wagen mee

Aan iedere race kunnen meerdere wagens mee doen, en 1 wagen kan aan meerdere races mee doen, dus een many to many cardinaliteit.

dus een oo-------oo relatie.

en ga maar op je boek op zoek naar het woord 'generator'

[Verwijderd]

aha, ik snap je niet want er komen in feite alleen maar 1 op n relaties volgens de normalisatie regels

[Verwijderd]

Op vrijdag 22 maart 2002 18:01 schreef Alarmnummer het volgende:
Wauw.. je kan altijd winnen bij jullie bij iedere race doet maar 1 wagen mee

Aan iedere race kunnen meerdere wagens mee doen, en 1 wagen kan aan meerdere races mee doen, dus een many to many cardinaliteit.

dus een oo-------oo relatie.

Hoe stel je dat allemaal in bij access relaties, want dat
kan ik niet vinden

[Alarmnummer]

generator

[Sn3akz]

Klopt idd vrij weinig van (no offence)

Je bent op de goede weg, maar een hoop 1 op n relaties, maar zijn in werkelijkheid n op m.. Daar moet je dus een 'koppel-tabel' tussenzetten zodat je 2 1 op n relaties krijgt.. Heb alleen nu ff geen zin om me over jou probleem te buigen.. SUC6!!

P.S. Volgende keer ff wat kleinere screenshots posten asjeblieft.. 70% van het plaatje heb je niet nodig om te laten zien wat je bedoeld.

[Dash2in1]

Op vrijdag 22 maart 2002 18:03 schreef Erebus het volgende:
aha, ik snap je niet want er komen in feite alleen maar 1 op n relaties volgens de normalisatie regels

Hmm, hier nog nooit van gehoord... is dit zo?

[TweakersOnly]

Een oplossing die ik voor het probleem naar voren draag.

Tabellen:
TEAM, COUREUR, AUTO, AUTOBAND, BAND, MOTOR, DEELNEMER, WEDSTRIJD, TOERNOOI PLAATS, SPONSOR en TEAMBAAS

1:N-Relaties:
TEAM - COUREUR
TEAM - AUTO
MOTOR - AUTO
AUTO - AUTOBAND
BAND - AUTOBAND
AUTO - DEELNEMER
WEDSTRIJD - DEELNEMER
TOERNOOI - WEDSTRIJD
PLAATS - WEDSTRIJD

{b]1:1-Relaties[/b]
TEAM - SPONSOR
TEAM - TEAMBAAS

Vreemde sleutels:
TEAM: Sponsornr, Teambaasnr
COUREUR: Teamnr
AUTO: Teamnr, motornr
AUTOBAND: Autonr, Autobandnr
DEELNEMER: Autonr, wedstrijdnr
WEDSTRIJD: Toernooinr, plaatsnr

Eventueel kan de relatie MOTOR-AUTO ook een 1:1 relatie zijn, hier ben ik niet zo goed van op de hoogte.

[Alarmnummer]

Probeer eerst eens alle entiteiten en de onderlinge relaties te tekenen en vergeet eerst die verwijzende sleutels even. Dat maakt het leven echt een stuk gemakkelijker

[Alarmnummer]

MOTOR - AUTO?? 1 op n relatie..

iedere motor hoot bij meerdere auto`s??.. eerder andersom.

[TweakersOnly]

Op vrijdag 22 maart 2002 18:29 schreef Alarmnummer het volgende:
MOTOR - AUTO?? 1 op n relatie..

iedere motor hoot bij meerdere auto`s.. eerder andersom.

Een auto heeft altijd 1 motor, een type motor kan in principe in meerdere auto's geplaatst worden. (I suggest )

[Verwijderd]

Op vrijdag 22 maart 2002 18:29 schreef Alarmnummer het volgende:
MOTOR - AUTO?? 1 op n relatie..

iedere motor hoot bij meerdere auto`s??.. eerder andersom.

Wij hebben een uitleg gehad van lik me
dus we weten niet eens hoe te beginnen, we doen maar wat

[Verwijderd]

zware offtopic, maar: kan je met ms access ook zulke knappe schemes van mysql maken? Of moet je dan eerst alles "overtypen/namaken" in access?

[Verwijderd]

Op vrijdag 22 maart 2002 18:37 schreef DiEana het volgende:
zware offtopic, maar: kan je met ms access ook zulke knappe schemes van mysql maken? Of moet je dan eerst alles "overtypen/namaken" in access?

Dan moet je het eerst na maken, want je bouwt de schemes
op basis van je tabellen, en die moet je dus creeren

[Verwijderd]

Op vrijdag 22 maart 2002 18:40 schreef Livors het volgende:

[..]

Dan moet je het eerst na maken, want je bouwt de schemes
op basis van je tabellen, en die moet je dus creeren

Spijtig.. want dat zou een te groot werk zijn voor mijn dbase
Het zou anders wel cool zijn als je zomaar je .sql files kon importeren, en dan schematjes laten genereren

Misschien bestaan er WEL zo'n proggietjes? (buiten het te dure ms visio)

[Verwijderd]

Op vrijdag 22 maart 2002 18:43 schreef DiEana het volgende:

[..]

Spijtig.. want dat zou een te groot werk zijn voor mijn dbase
Het zou anders wel cool zijn als je zomaar je .sql files kon importeren, en dan schematjes laten genereren

Misschien bestaan er WEL zo'n proggietjes? (buiten het te dure ms visio)

Ja zou best wel bestaan, ik heb er iig nog nooit van gehoord.
Maar ja, ik ben ook nog bezig om mySQL op z'n minst draaiende te krijgen

[Alarmnummer]

Ik heb in java een api geschreven die uit een database connectie vrij veel meta data van de database kan ophalen. Alleen kan ik bij access niet de relaties voor elkaar krijgen. Het zou verder niet veel werk zijn om de bij behorende ddl commando`s te genereren. Ik durf te wedden dat er genoeg tools zijn die hetzelfde kunnen.

[Verwijderd]

Op vrijdag 22 maart 2002 18:06 schreef Sn3akz het volgende:
Klopt idd vrij weinig van (no offence)

geen probleem, ik heb hier nog weinig oefening in(dit is mijn eerst normalisatie en hopelijk de laatste )

Je bent op de goede weg, maar een hoop 1 op n relaties, maar zijn in werkelijkheid n op m.. Daar moet je dus een 'koppel-tabel' tussenzetten zodat je 2 1 op n relaties krijgt.. Heb alleen nu ff geen zin om me over jou probleem te buigen.. SUC6!!

tja die n-m relaties had me leraar het over ja en dat je dan een koppel tabel moest maken omdat n-m niet mogen voorkomen. Hoe dat gaat heb ik teweinig in de les van opgestoken, want als hij het even doet lijkt het simpel en dat doe je het zelf en dan gaan het licht uit

P.S. Volgende keer ff wat kleinere screenshots posten asjeblieft.. 70% van het plaatje heb je niet nodig om te laten zien wat je bedoeld.

mkay

[Alarmnummer]

Wat voor een niveau is de Mondriaan onderwijsgroep eigelijk? Ik zie wel vaker mensen van jullie school hier komen met vrij triviale vragen. Dingen die je gewoon in je onderwijs gehad moet hebben.

[baggah]

Alarmnummer: De meeste ict opleidingen daar zijn van het mbo nivo (nivo 4). (En als deze studenten van de Ijzerwerf komen hehehe dan moeten ze is op letten in de les).

Erebus/Livors: Zitten jullie op de Ijzerwerf zoja van welke docent hebben jullie dit?

[Infinitive]

Om een database schema in diverse normaal-vormen te brengen zijn ook formele manieren gevonden. Zo kan je voor de derde normaal vorm (en ook Boyce-Codd) gebruik maken van Functional Dependencies. Het handige hiervan is dat je een algortime toepast op je huidige schema en als resultaat krijg je het schema in de gewenste normaal vorm.

Over functional Dependencies zijn diverse boeken geschreven; een aardige introductie kan je krijgen in "Database Management Systems" [Ramakrishnan et al]. Of even naar wat slides kijken op www.cs.uu.nl/docs/vakken/db/ (hoewel dat waarschijnlijk niet genoeg is om zonder toelichting toe te kunnen passen).

[edit] Ik las net dat jullie mbo doen. Dan ben ik bang dat jullie nog niet aan Functional Dependencies toe zijn (niet rot bedoeld overigens).
[edit2] hierboven had ik nogal een lullige zin staan (nu aangepast) als je die misinterpreteerde. Mijn excuus voor degenen die dat toevallig gelezen hadden

[Alarmnummer]

Als ik hem was zou ik eerst een entiteit relatie diagram tekenen. Dan weet je tenminste alle relaties tussen de entiteiten en hun cardinaliteit. Dat omzetten naar een relationeel model is niet zoveel werk.

[Infinitive]

... maar daarna dan moet je dus nog normaliseren

[Alarmnummer]

yep.. maar hij moet (voor de verandering) zijn relaties goed hebben staan. En dat is op dit moment nog wel het grootste euvel

[Infinitive]

... mee eens, daarvoor kan je idd als hulpstuk een ER-diagram gebruiken. Weet de topicstarter hoe hij dat moet doen?

[Verwijderd]

Op vrijdag 22 maart 2002 20:46 schreef Baggah het volgende:
Alarmnummer: De meeste ict opleidingen daar zijn van het mbo nivo (nivo 4). (En als deze studenten van de Ijzerwerf komen hehehe dan moeten ze is op letten in de les).

Erebus/Livors: Zitten jullie op de Ijzerwerf zoja van welke docent hebben jullie dit?

Marcel Zondervan

PS. Geef jij ons geen TUX?

edit:
Ja dus, haha, nou ik snap het normaliseren iig beter als UNIX hoor (no offense trouwens, vind unix gewoon moeilijker)

[baggah]

Tja, Voor unix kan je mij altijd mailen ..... hee misschien voor dit ook wel.
Maar ik snap niet wat je nu als primary key gebruikt en wat als foreign key..Misschien ligt de screenshot...
Maar mag je niet iets doen als
Races:
-Raceid (primary key)
-Racebla

Wagen:
-Wagenid (primary key)
-Wagenbla

KoppelWagenRace:
-Raceid (foreign key)
-Wagenid (foreign key)

Ik weet niet of dit netjes genoeg is en of dit wel mag.....

edit:

Laat maar dit is ugly want dit is niet echt nodig lijkt me....

[edit2]
Bij nader inzien gebruik de resultaten tabel om racewagens en races aan elkaar te koppelen.. ?
[/edit2]

[Pogostokje]

Als je trouwens nog eens op het punt komt dat je handmatig SQL code moet gaan intikken, dan zal je er achter komen dat je geen handige veldnamen gebruikt. Al die spaties, hele woorden en zelfs een komma'tje hier een daar maken het er niet handiger op. Probeer zinvolle maar korte veldnamen te gebruiken (je moet even een standaard ontwikkelen voor jezelf) en het liefst helemaal geen spaties of leestekens gebruiken.

Access is vergevingsgezind, het is alleen maar lastig voor jezelf ... andere databases slaan je om de oren als je zo'n naamgeving gebruikt.

[Alarmnummer]

Ik had dat nog niet eens gezien en nog erger: ik wist niet eens dat dat geldige identifiers zijn Maar hij heeft 100% gelijk, de namen zijn naadje

ps: liefst ook zo weinig mogelijk met afkortingen gaan werken (als dat idee in je was gaan borrelen). Afkortingen zijn kut omdat je niet goed ziet wat er gebeurd. Je moet extra moeite doen (onnodig) en dat leidt tot extra fouten.

[dusty]

Op vrijdag 22 maart 2002 17:59 schreef Erebus het volgende:
verhouding

anyways ik heb dat nu verandert, nu al beter?

[afbeelding]

Genoeg tijd voor andere mensen om commentaar te geven, zal ik de rest van de commentaar maar doen?

conclusies uit je schema:

1 wagen kan meerdere bandentypes hebben.
1 bandtype heeft maar 1 wagen

resultaten worden aan de hand van de wagen opgeslagen, het maakt niet uit van welke race deze resultaat is geweest (wordt namelijk niet bepaald)

Zodra een wagen een type band gebruikt, mag deze niet meer veranderen. (anders zou dat 'bij' het resultaat van een race worden opgeslagen.)

je vertrouwd je database niet, dus sla je maar voor de zekerheid op hoeveel coureurs er bij de team hoort, immers is dat heeeeeeeeeeeeeeeeel moeilijk te bepalen aan de link van de coureur bij welke team deze zit.

Een team wordt geindentificeerd aan de hand van de coureurnaam.

De wagenteam is gelijk aan de team identificatie.

De wagenidentificatie wordt gelijkgesteld aan de naam van de banden leverancier.

De wagen identificatie is gelijk aan de resultaat van een race.

Bovendien heeft deze wagen identificatie de naam van het land.

Bovendien geeft deze wagen identificatie de naam van de motor weer.

Volgens mij staan er nog wat FK's verkeerd gedefinieerd.

Bovendien zie ik verbindingen tussen tabellen die gewoon NIET gemaakt kunnen worden omdat er geen overeenkomstige kolommen in beide tabellen zijn.

De enige relatie die je zou kunnen leggen (maar NIET is gelegd) is de coureurID van resultaat aan de coureur tabel.

Volgens mij kan iemand beter even overnieuw beginnen om alle gegevens over te schrijven alles op een groot papier te zetten, overnieuw in te delen en dan pas onderverdelen in tabellen en duidelijk aangeven wat in welke tabel is gelinks aan wat in welke andere tabel.

[Alarmnummer]

ERD is all the man needs to start

[dusty]

Op zaterdag 23 maart 2002 01:51 schreef Alarmnummer het volgende:
ERD is all the man needs to start

Zal ik aardig zijn en de nederlandse vertaling geven:

ERD is alles wat de man nodig heeft om te starten.

Jawel, de afkorting is voor de verandering hetzelfde. (terwijl alle drie de woorden toch echt vertaald zijn )