DB-ontwerp vraagje

[Stijn]

Hoi,

Alweer voor mijn evenementen-website...

Ik wilde eerst elke foto (lees bestandsnaam) in mijn database de informatie
doorgeven (plaats, datum, gelegenheid...) maar bedacht dat dit misschien
niet zo slim is. Tenslotte gaan er erg veel foto's dezelfde gegevens krijgen
(ik schat een 30 tal). Dus: een aparte tabel met de informatie de
plaats,datum en gelegenheid, en het ID van die gegevens in de "foto" tabel
opnemen bij elke foto. Dat haalt de hoeveelheid informatie in de database
aanzienlijk naar beneden, met hetzelfde resultaat.

Als ik nu een Stored Procedure (Query in Access, want daar werk ik mee) maak
die dus een uitvoer geeft van al die gegevens, is dan die moeite niet voor
niets geweest? (Die query neemt toch ook plaats in denk ik dan, dus lichter
wordt mijn database er niet van...)

Of zie ik dat fout? Hoe zouden jullie het aanpakken?

Thanks,

Stijn

[Rene Pijlman]

Stijn:
>Ik wilde eerst elke foto (lees bestandsnaam) in mijn database de informatie
>doorgeven (plaats, datum, gelegenheid...) maar bedacht dat dit misschien
>niet zo slim is. Tenslotte gaan er erg veel foto's dezelfde gegevens krijgen
>(ik schat een 30 tal). Dus: een aparte tabel met de informatie de
>plaats,datum en gelegenheid, en het ID van die gegevens in de "foto" tabel
>opnemen bij elke foto.

Inderdaad, dat klinkt als een verstandig ontwerp. De
belangrijkste consequentie is dat een eventuele wijziging
(update) in de gedeelde gegevens slechts op één plaats hoeft te
worden aangebracht.

>Dat haalt de hoeveelheid informatie in de database
>aanzienlijk naar beneden, met hetzelfde resultaat.

De hoeveelheid informatie blijft gelijk, maar de hoeveelheid
redundante gegevens neemt af. Maar dat is een andere manier om
te zeggen wat jij al zegt: "met hetzelfde resultaat".

>Als ik nu een Stored Procedure (Query in Access, want daar werk ik mee) maak
>die dus een uitvoer geeft van al die gegevens, is dan die moeite niet voor
>niets geweest?

Nee hoor.

>(Die query neemt toch ook plaats in denk ik dan, dus lichter
>wordt mijn database er niet van...)

Hoeveelheid informatie, plaats, lichter,... wat zijn dat toch
allemaal voor vage begrippen?

Wat je aan het doen bent heet normaliseren van het datamodel.
Dat is goed.

Het belangrijkste voordeel is de enkelvoudige update,
gegarandeerde consistentie, betere semantische matching e.d.

Een bijkomend voordeel (bij heel grote databases) is dat een
genormaliseerde database minder opslagruimte nodig heeft,
althans bij een niet-comprimerende database-engine :-)

En die query, die neemt niet of nauwelijks plaats in. Het
resultaat van de query wordt pas samengesteld op het moment van
uitvoeren van de query.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Stijn]

"Rene Pijlman" <reply.in@the.newsgroup> schreef in bericht
news:1hgv6v47kglk7q5e01obqrg7rj1t04kuih@4ax.com...
> Stijn:

>>een aparte tabel met de informatie de
> >plaats,datum en gelegenheid, en het ID van die gegevens in de "foto"
tabel
> >opnemen bij elke foto.
>
> Inderdaad, dat klinkt als een verstandig ontwerp.

Bedankt!

>
> >Dat haalt de hoeveelheid informatie in de database
> >aanzienlijk naar beneden, met hetzelfde resultaat.
>
> De hoeveelheid informatie blijft gelijk, maar de hoeveelheid
> redundante gegevens neemt af. Maar dat is een andere manier om
> te zeggen wat jij al zegt: "met hetzelfde resultaat".

En waarschijnlijk correcter....

>
> >Als ik nu een Stored Procedure (Query in Access, want daar werk ik mee)
maak
> >die dus een uitvoer geeft van al die gegevens, is dan die moeite niet
voor
> >niets geweest?
>
> Nee hoor.

Oef!

>
> >(Die query neemt toch ook plaats in denk ik dan, dus lichter
> >wordt mijn database er niet van...)
>
> Hoeveelheid informatie, plaats, lichter,... wat zijn dat toch
> allemaal voor vage begrippen?

informatie = dat wat opslagruimte neemt
plaats = opslagruimte
lichter = minder opslagruimte

Bedoelde ik eigelijk...


> Wat je aan het doen bent heet normaliseren van het datamodel.
> Dat is goed.
>
> Het belangrijkste voordeel is de enkelvoudige update,
> gegarandeerde consistentie, betere semantische matching e.d.

Wow... dat zijn waarschijnlijk heel concrete begrippen, maar ik versta ze
niet :o)
Maar ik zoek ze op hoor...


> Een bijkomend voordeel (bij heel grote databases) is dat een
> genormaliseerde database minder opslagruimte nodig heeft,
> althans bij een niet-comprimerende database-engine :-)
>
> En die query, die neemt niet of nauwelijks plaats in. Het
> resultaat van de query wordt pas samengesteld op het moment van
> uitvoeren van de query.

Bedankt René voor je verhelderende toelichting!

Stijn

[Rene Pijlman]

Stijn:
>Rene Pijlman:
>> Hoeveelheid informatie, plaats, lichter,... wat zijn dat toch
>> allemaal voor vage begrippen?
>
>informatie = dat wat opslagruimte neemt
>plaats = opslagruimte
>lichter = minder opslagruimte

Oh ja, zo snijdt het wel hout :-)

>> Wat je aan het doen bent heet normaliseren van het datamodel.
>> Dat is goed.
>>
>> Het belangrijkste voordeel is de enkelvoudige update,
>> gegarandeerde consistentie, betere semantische matching e.d.
>
>Wow... dat zijn waarschijnlijk heel concrete begrippen, maar ik versta ze
>niet :o)
>Maar ik zoek ze op hoor...

Ik zal je helpen :-)

enkelvoudig: op één plaats, in één keer

update: wijziging

gegarandeerd: voortvloeiend uit het technisch model (i.p.v.
discipline van degene die de gegevens onderhoudt)

consistentie: niet tegenstrijdig (bijv. verschillende spellingen
van een auteursnaam in het voorbeeld hieronder)

"Semantische matching" vraagt om een toelichting, realiseer ik
me nu. Door de gezamenlijke gegevens van een evenement expliciet
te maken in het datamodel leg je in feite in de database extra
informatie vast, namelijk dat bepaalde foto's van hetzelfde
evenement zijn. Zonder die aparte tabel zou je alleen kunnen
zeggen dat de foto's te maken hebben met dezelfde plaats, datum
enz., maar je kunt niet het onderscheid maken tussen twee
verschillende evenementen die toevallig op dezelfde plaats,
datum enz. plaatsvinden.

Ik heb ooit met zoiets te maken gehad in een bibliografische
database.

Titel: Nooit meer slapen
Auteur: W.F. Hermans

Titel: De donkere kamer van Damocles
Auteur: Hermans, Willem Frederik

is iets heel anders dan:

Titel: Nooit meer slapen
Auteur: 17

Titel: De donkere kamer van Damocles
Auteur: 17

Id: 17
Naam: Hermans, W.F.

Omdat bij dat laatste model eenduidig is vastgelegd dat de twee
titels van dezelfde auteur zijn. In het eerste geval vergt dat
menselijke interpretatie.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl