Normalizeer controle

[Verwijderd]

Ik ben bezig aan het normalizeren, echter is dit een hele tijd geleden dat ik dit vorrige keer gedaan hebt.. vandaar dat ik even een controle wil
Het gaat over foto's die in een database opgeslagen moet worden.

Ik heb de volgende gegevens die opgeslagen moeten worden:
Headline (is eigenlijk de titel van de serie), City, Country, Keyword(s), Copyright(fotograaf dus), Datum, Url, fotograaf, adres fotograaf, wachtwoord fotograaf.

Ik heb nu de volgende tabellen opgesteld:
foto id, url, datum, city_id, headline_id, fotograaf_id
city id, city, country
headline id, naam
fotograaf id, naam, adres, wachtwoord
keywords id, keyword
relaties id, keyword_id, foto_id

klopt dit? of heb ik echt te lang niets met databases gedaan....

[Verwijderd]

Waarom maak je een aparte tabel voor de headline? Het veld 'naam' uit de tabel 'headline' kun je in dit geval gewoon in de tabel 'foto' opslaan.

Indien er meerdere headlines per foto kunnen zijn, klopt je tabel foto niet..

(immers een foto kan maar door één fotograaf gemaakt zijn, je zou dan meerdere keren dezelfde fotograaf bij dezelfde foto opslaan)

En waarom heeft de tabel relaties een ID veld? De twee velden samen zijn uniek, daar is geen key meer bij nodig..

[ Voor 48% gewijzigd door Verwijderd op 18-12-2004 13:38 ]

[Verwijderd]

ik dacht omdat de headline bij meerdere foto's voorkomt, is het ruimte besparing als je headline apart opslaat.
Immers is een int minder ruimte dan een varchar 25 ofzo...

toch?

[Verwijderd]

Verwijderd schreef op zaterdag 18 december 2004 @ 13:40:
ik dacht omdat de headline bij meerdere foto's voorkomt, is het ruimte besparing als je headline apart opslaat.
Immers is een int minder ruimte dan een varchar 25 ofzo...

toch?

Ah, accoord.. wat dat betreft is het handig om de relaties er even bij te zetten (n:m, 1:n, n:1 etc).. anders krijg je dit soort dingen

(al had ik het ook moeten zien aan het feit dat dat ID veld in de tabel foto's voorkomt)

[ Voor 11% gewijzigd door Verwijderd op 18-12-2004 13:42 ]

[Verwijderd]

verder geen fouten te ondekken generaal?

[Wacky]

Je genormaliseerde database kun je controleren door toegangspadanalyses te maken voor de overzichten die je later wil hebben.

Met zo'n toegangspadanalyse kijk je dus of je voor het gewenste overzicht van de ene entiteit naar de andere entiteit kan komen om daar de gewenste informatie vandaan te halen

[Verwijderd]

eehm... ok, ik ben gestopt na 2,5 jaar TI in gouda... misschien heb ik deze les gemist
wat is een toegangspadanalyse???

ok, om even logisch na te denken.
ik denk dat je bedoeld dat je vanaf 1 punt naar alle punten kan gaan.

je moet bijvoorbeeld op city kunnen zoeken en dan toch achter alle keywords kunnen komen..
Zoiets?

[ Voor 47% gewijzigd door Verwijderd op 18-12-2004 13:56 ]

[Mithrandir]

Het hergebruiken van headlines om minder ruimte in je database te gebruiken is onzin. Je moet je namelijk de volgende vraag stellen: heeft de data werkelijk met elkaar te maken of is het toeval dat twee headlines hetzelfde zijn?
Als je een van de headlines namelijk veranderd, wil je niet dat de ander meteen meeveranderd, maar als het wel bij elkaar moet horen wil je natuurlijk dat ze beiden aangepast worden.

[BasieP]

Wacky schreef op zaterdag 18 december 2004 @ 13:47:
Je genormaliseerde database kun je controleren door toegangspadanalyses te maken voor de overzichten die je later wil hebben.

Met zo'n toegangspadanalyse kijk je dus of je voor het gewenste overzicht van de ene entiteit naar de andere entiteit kan komen om daar de gewenste informatie vandaan te halen

is dat niet een entiteit relatie diagram?

Mithrandir schreef op zaterdag 18 december 2004 @ 14:01:
Het hergebruiken van headlines om minder ruimte in je database te gebruiken is onzin. Je moet je namelijk de volgende vraag stellen: heeft de data werkelijk met elkaar te maken of is het toeval dat twee headlines hetzelfde zijn?
Als je een van de headlines namelijk veranderd, wil je niet dat de ander meteen meeveranderd, maar als het wel bij elkaar moet horen wil je natuurlijk dat ze beiden aangepast worden.

hangt er van af, wanneer het dus zo is dat headlines 'EXPRES' dezelfde waarde hebben, en het juist de bedoeling is dat wanneer je er 1 veranderd, de anderen mee veranderen dan is het juist wel handig dat hij dit in een apparte tabel zet.

idd, wanneer het toeval is als een headline 2x voorkomt moet je dit niet in een apparte tabel doen.

Trouwens hangt het er ook een beetje van af hoe groot de database is. Wanneer je veel preformance wil, dan kan je beter de headline gewoon in de 'foto' table gooien, want dan zoek je hem wat sneller op.

wanneer je een grote database heb, of snelheid niet je eerste prioriteit is, dan kan je het idd beter los doen, want dat scheeld ruimte

[ Voor 58% gewijzigd door BasieP op 18-12-2004 14:05 ]

[Verwijderd]

Verwijderd schreef op zaterdag 18 december 2004 @ 13:45:
verder geen fouten te ondekken generaal?

Nou ja, afgezien van dat overbodige ID veld, en de gemaakte opmerking m.b.t. headlines (als je 'm bij één foto wijzigt, verandert hij voor alle foto's), zie ik zo niets wat niet klopt ofzo. Maar ik weet ook niet precies wat je er mee wilt.

Als je een DB aan het ontwerpen bent, zou ik eens kijken naar Sybase Powerdesigner. Daar kun je een evaluatieversie van downloaden, en die is echt handig. Zo hoef je zelf geen koppetabellen (zoals de tabel relaties) te maken, dat doet hij voor je. Je maakt een conceptueel datamodel, waarin je de velden neerzet. Daarna maakt hij het fysieke model voor je, en als je helemaal klaar is kan hij de database automatisch voor je genereren (rechtstreeks in de database, of via een SQL script). Daarnaast kan hij de tabellen voorzien van inhoud voor je, zodat je een grote testset kunt samenstellen.

[Verwijderd]

in dit geval van deze database hebben ze echt met elkaar te maken.
in deze database gaan namelijk allemaal wedstrijden. dus bijvoorbeeld feyenoord - psv.
"feyenoord - psv" zou dus een headline zijn. Een foto kan niet opeens naar een andere serie(headline) verplaatsen. het komt namelijk uit die wedstrijd!! Als het iets anders dan voetbal is dan zou het nogsteeds met elkaar gerelateerd zijn. Het is de titel van de serie.

Een foto hoeft echter niet met een serie(headline) verbonden te zijn.

[Verwijderd]

Verwijderd schreef op zaterdag 18 december 2004 @ 14:08:
in dit geval van deze database hebben ze echt met elkaar te maken.
in deze database gaan namelijk allemaal wedstrijden. dus bijvoorbeeld feyenoord - psv.
"feyenoord - psv" zou dus een headline zijn. Een foto kan niet opeens naar een andere serie(headline) verplaatsen. het komt namelijk uit die wedstrijd!! Als het iets anders dan voetbal is dan zou het nogsteeds met elkaar gerelateerd zijn. Het is de titel van de serie.

Strikt genomen zou het dan mooier zijn om een tabel 'clubs' te maken, en daar je headline zelf uit samen te stellen. Immers feyenoord speelt niet alleen tegen PSV (en dat is maar goed ook voor ze).

En misschien een andere naam verzinnen voor de tabel 'relaties'..

[ Voor 39% gewijzigd door Verwijderd op 18-12-2004 14:14 ]

[Verwijderd]

ok, de preformance is het belangrijkste.. ruimte moet ik toch genoeg hebben om de foto's op te kunnen slaan op de server.. dus die paar bytes per entree maakt ook niet meer uit!!

het word dus nu:
foto id, url, datum, city_id, headline, fotograaf_id
city id, city, country
fotograaf id, naam, adres, wachtwoord
keywords id, keyword
keylink id, keyword_id, foto_id

[Verwijderd]

Verwijderd schreef op zaterdag 18 december 2004 @ 14:12:
ok, de preformance is het belangrijkste.. ruimte moet ik toch genoeg hebben om de foto's op te kunnen slaan op de server.. dus die paar bytes per entree maakt ook niet meer uit!!

het word dus nu:
foto id, url, datum, city_id, headline, fotograaf_id
city id, city, country
fotograaf id, naam, adres, wachtwoord
keywords id, keyword
relaties id, keyword_id, foto_id

(eigenlijk is headlines dus een samengesteld veld)

netter is dan:

foto id, url, datum, thuisclub_id, uitclub_id, fotograaf_id
clubs id, city_id, naam
city id, naam
fotograaf id, naam, adres, woonplaats, wachtwoord
keywords id, keyword
keyword_foto keyword_id, foto_id

Eventueel kun je city_id nog weer toevoegen om wedstrijden die in een ander stadion gespeeld worden ook correct weer te geven. Of de city gewoon helemaal niet koppelen aan de club (strict genomen zou een aparte tabel 'stadions' nog netter zijn)

[ Voor 15% gewijzigd door Verwijderd op 18-12-2004 14:16 ]

[Wacky]

BasieP schreef op zaterdag 18 december 2004 @ 14:02:
[...]
is dat niet een entiteit relatie diagram?
[...]

In het ERD zie je alleen welke tabellen een relatie hebben, niet hoe deze relatie verloopt (via welke velden dus). Door die toegangspadanalyse controleer je dus of het veld met de FK bestaat en of je door deze FK ook in de andere tabel de benodigde gegeven kan vinden.

(althans, zo is het mij ook 2 weken geleden uitgelegd op school )

[Verwijderd]

echter is hier het probleem dat alle informatie doormidel van iptc eruit word gehaald.
in de iptc staat een veld genaamd headline. In de IPTC staan geen specefieke velden voor uit en thuis club.
Nu kan ik wel ervoor zorgen dat iedere fotograaf standaar invult [$thuisclub - $uitclub] in de headline field, echter zorgt dat weer voor problemen als het geen wedstrijd is! Het kan namelijk ook gewoon een perconferentie zijn, of een portreten serie......

[Verwijderd]

Ok, wat hier staat is onzin, m'n database was nog niet compleet ingevuld....

[ Voor 119% gewijzigd door Verwijderd op 18-12-2004 21:30 ]