Archief - [ALG]DB Database opdracht

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
B

Bontus

Legacy Member
Voor school heb ik een database opdracht.
Ik ga jullie de opdracht niet geven, want dit is inderdaad geen huiswerk forum, maar door men IAJ heb ik alle lessen van Informatica moeten missen, dus heb ik het wat moeilijk met de opdracht.
Ik heb dus een opdracht en de opgave luidt:

1# Teken een ER diagramma van de gegeven opdracht
2# Ga op een gestructureerde manier over van het ER diagramma naar het database schema
3# Normaliseer de databank tot en met BC

Puntje 1 weet ik wat ik moet doen, maar ik weet niet wat ze nu net van mij verwachten voor punt 2 en 3. Maar naart schijnt is normaliseren wel iets heel belangrijk.
Dit komt ook door het feit dat de persoon die de labo's databanken geeft een verschrikkelijke omhooggevallen nerd is, die er niet in geslaagd is ons iets duidelijk uit te leggen na 5 labo's van 3 uur pure tijdsverspilling.

Kan iemand kort uitleg geven?
Of heeft iemand een gelijkaardige opdracht ooit gemaakt, gelieve me te contacteren.
d

daVinci

Legacy Member
Ik denk dat gewoon erop neer komt dat je de entiteiten uit je ER schema moet gaan uitwerken in stap 2. Dus velden gaan definiëren, gegevens over de entiteiten zoeken die je wilt bijhouden. Bv. entiteit "Leerling", mogelijke attributen hierbij zijn: leerlingnummer (Primary Key), naam, voornaam, straat, PC, gemeente, enz.
In het ER model zorg je er best voor dat er geen "many-to-many" relaties meer aanwezig zijn, alvorens deze stap te beginnen.

In de 3de stap ga je moeten gaan normaliseren, redundantie wegwerken als het ware. moest je de entiteit leerling willen normaliseren voor een database, ga je werken met 2 tabellen. leerling (attributen: nummer (PK), naam, voornaam, adres, PC) en gemeente (attributen: PC (PK), gemeente). Met een relatie tussen beide velden PC.
Aangezien de gemeente afhankelijk is van de postcode voorkom je dat 1 postcode meerdere gemeentes kan hebben door te normaliseren.
B

Bontus

Legacy Member
Alvast bedankt.
Op zo'n ER-diagram hebben we al eens een oefening gemaakt en toen mochten we wel de veel op veel relatie gebruiken. Dus denk dat ik toch op die manier iets ga proberen schetsen. Het is gewoon nu al iets heel complex.

Dus daarna zou ik feitelijk een database moeten bouwen met een paar fictieve gegevens. Er staat wel niets in de opgave, dus veronderstel ik dat we iets met access ineen moeten flansen.
d

daVinci

Legacy Member
reteiP zei:
Alvast bedankt.
Dus daarna zou ik feitelijk een database moeten bouwen met een paar fictieve gegevens. Er staat wel niets in de opgave, dus veronderstel ik dat we iets met access ineen moeten flansen.
Klik om te vergroten...

Normaliseren kan je ook gewoon op papier doen hoor. Eigenlijk moet je het relatieschema van Access maken.
O

Obliv`

Legacy Member
reteiP zei:
Alvast bedankt.
Op zo'n ER-diagram hebben we al eens een oefening gemaakt en toen mochten we wel de veel op veel relatie gebruiken. Dus denk dat ik toch op die manier iets ga proberen schetsen. Het is gewoon nu al iets heel complex.

Dus daarna zou ik feitelijk een database moeten bouwen met een paar fictieve gegevens. Er staat wel niets in de opgave, dus veronderstel ik dat we iets met access ineen moeten flansen.
Klik om te vergroten...

In een ER diagram mogen nog wel many-to-many relaties zitten (dacht ik), maar in de vorm die daar op volgt (EER) niet meer. Omzetten naar een 1 - * en * - 1 dus.
s

solskjaer

Legacy Member
Als de steden/gemeenten in Belgie liggen heb je als sleutel: de samenstelling van postcode en gemeentenaam en niet enkel de postcode
s

solskjaer

Legacy Member
In de 3de stap ga je moeten gaan normaliseren, redundantie wegwerken als het ware. moest je de entiteit leerling willen normaliseren voor een database, ga je werken met 2 tabellen. leerling (attributen: nummer (PK), naam, voornaam, adres, PC) en gemeente (attributen: PC (PK), gemeente). Met een relatie tussen beide velden PC.
Aangezien de gemeente afhankelijk is van de postcode voorkom je dat 1 postcode meerdere gemeentes kan hebben door te normaliseren.
Klik om te vergroten...

Omdat de veronderstelling hierboven verkeert is
j

jodeman

Legacy Member
verkeerD
hoe davinci het zegt is het wel correct hoor, wordt altijd gedaan. Soms kan dat wel eens verkeerd zijn maar komt toch altijd goed terecht dus maakt eigenlijk niets uit. De post weet aan de hand van de postcode waar die brief moet terechtkomen he, met een naam zijn ze weinig.
c

crimineels

Legacy Member
jodeman zei:
verkeerD
hoe davinci het zegt is het wel correct hoor, wordt altijd gedaan. Soms kan dat wel eens verkeerd zijn maar komt toch altijd goed terecht dus maakt eigenlijk niets uit. De post weet aan de hand van de postcode waar die brief moet terechtkomen he, met een naam zijn ze weinig.
Klik om te vergroten...

Nee eigelijk toch ni, er zijn meerdere gemeentes met dezelfde postcode dus.. Als je de gemeentenaam niet wil opnemen in de PK zal je een gewone Gemeente ID moeten toekennen want een postcode is dus wel degelijk NIET uniek! :naughty:
T

Tyfius

Legacy Member
Gemeente en Deelgemeente hebben allebei dezelfde postcode, en allebei een kerklaan. Where does the mail go for number 2 ?

Het beste is inderdaad de beide te combineren.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan