[Database]Ontwerp ok?

[sh4d0wman]

Inleiding
Ik ben voor de fun bezig om een design te maken voor een simpel woordenboek programma. Talen zijn op dit moment gelimiteerd tot Thai en Engels. Het moet mogelijk zijn om van Thai naar Engels te zoeken en omgekeerd. In de toekomst moeten andere talen zijn toe te voegen.

Het lijkt mij het beste om dit allemaal in een database te zetten. Voor een goede opzet is normaliseren belangrijk. Hierbij het werk wat ik heb gedaan met een uitleg. Is dit voldoende of zie ik iets over het hoofd?

Voorwaarden
Voorwaarden van de applicatie:

- Een woord is uniek
- Het kan tot meerdere categorien horen, bijvoorbeeld: familie en vrienden
- Het kan tot meerdere types behoren, bijvoorbeeld: werkwoord en zelfstandig naamwoord
- Het woord kan meerdere definities hebben, bijvoorbeeld:
Het Thaise woord "song" betekend in Engels "to remember" en "to maintain".
- Zoeken van Thai naar Engels en omgekeerd. Niet van Engels naar andere talen. In de toekomst wel andere talen naar Thai en Thai naar andere talen.

Proef opzet
Uitgaande van de hierboven genoemde voorwaarden heb ik een spreadsheet opzet gemaakt van de data + fictieve data toegevoegd om te testen of mijn redenatie klopt.

De gebruikte namen zijn nog maar als test, om een en andere te verduidelijken:
ths_woord = het woord in Thaise karakters (is afhankelijk van word_ID)
th_woord = het woord in fonetisch Thai (is afhankelijk van word_ID)
onderste regel geeft aan of de data uniek is.

woord_id	ths_woord	th_woord	categorie	type	definitie
1	sohng	sohng	test1	verb	To maintain
1	sohng	sohng	test2	verb	To Remember
1	sohng	sohng	test3	noun	Figure
Uniek	Uniek	Uniek	1 of meer	1 of meer	1 of meer

Als dit juist is zou het in database formaat het volgende worden:
(vet + streep = prim key, streep = foreign key)

Tabel 1: Woorden
Woord_ID
Ths_Woord
Th_Woord
Cat_ID
Type_ID
Def_ID

Tabel 2: Categorie
Cat_ID
Cat_Naam

Tabel 3: Type
Type_ID
Type_Naam

Tabel 4: Definitie
Def_ID
EN


Zie ik nog iets over het hoofd of ben ik zo op de juiste manier bezig?

[Janoz]

Je praat wel over 1:N relaties, maar dat zie ik vervolgens niet in je tabel terug

[NMe]

- Het kan tot meerdere categorien horen, bijvoorbeeld: familie en vrienden

En het lijkt me dat een categorie meerdere woorden kan bevatten, toch? Dat zie ik ook niet echt in je ontwerp terug. Heb je al eens nagedacht over een kruistabel?

[Dido]

Het lijkt logischer om (met het oog op latere extra talen) een N:N link (via een hulptabel) te maken.

Die kan overigens prima koppelen aan dezelfde tabel.

Dus iets als
WOORD
WoordID
TaalID
Woord
WoordFonetisch

Vertaling
Woord.WoordID
Woord.WoordID

Categorie
CatID
Categorie

Woordcategorie
Woord.WoordID
Categorie.CatID

Etc., etc.

Wel een leuke trouwens... misschien vanavond eens spelen in Visio

[ Voor 9% gewijzigd door Dido op 09-08-2005 14:19 ]

[sh4d0wman]

Ik zal nog eens even over het ontwerp nadenken, altijd lastig met databases.. Het is wel belangrijk om dit deel goed te ontwerpen en er veel tijd in te steken, is later toch moeilijk te wijzigen.

Inmiddels heb ik wel een freeware design pakketje gevonden (DBDesigner4 van fabforce.net) dus als ik weer vragen heb dan kan ik een duidelijk schema toevoegen. Zoals het nu is opgezet valt er niet al te veel wijs uit te worden en het is nog niet echt logisch. Ik ga weer even prutsen

@ Dido, teken eens wat moois voor dit topic dank je, we zien wel of het lukt

[ Voor 5% gewijzigd door sh4d0wman op 09-08-2005 14:42 ]

[Dido]

sh4d0wman schreef op dinsdag 09 augustus 2005 @ 14:27:
@ Dido, teken eens wat moois voor dit topic

Als ik bijtijds thuis ben dan schets ik wel gauw ff wat vanavond

[Dido]

Ik heb even heel snel het volgende in elkaar geflanst.

Uitgaande van je punten in de startpost, met de volgende opmerkingen:

Alle woorden staan in 1 tabel, met een verwijzing naar de taal (1 woord heeft 1 taal).

Type en categorie gaan via een koppeltabel, zodat 1 woord in meerder categorien past, maar 1 categorie ook meerdere woorden bevat. (idem voor type).

De koppeltabel vertaling koppelt de tabel woord aan zichzelf, zodat 1 woord meerdere vertalingen kan hebben, maar ook meerdere vertalingen kan zijn.

Hoewel er niet om gevraagd werd kun je nu zoveel talen toevoegen als je wilt, en tussen alle talen vertalen hoe je maar wilt. Het enige dat je tegenhoudt is het bijhouden van je data. Met een beetje moeite kun je alle mogelijke reslutaten die ik me zo snel kan bedenken en die je zou willen hebben uit een (SQL)query krijgen.


Disclaimer: snel gemaakt, open voor commentaar, notatie due to visio

[Nick_S]

Is het bij koppeltabellen niet gebruikelijker om geen id aan te maken en de primary key te laten bestaan uit de twee foreign keys? Zodat je daar ook geen dubbele in krijgt. (Een woord met twee dezelfde categorien bijvoorbeeld)

[JaQ]

Nick_S schreef op dinsdag 09 augustus 2005 @ 20:09:
Is het bij koppeltabellen niet gebruikelijker om geen id aan te maken en de primary key te laten bestaan uit de twee foreign keys? Zodat je daar ook geen dubbele in krijgt. (Een woord met twee dezelfde categorien bijvoorbeeld)

Dat ben ik zelf wel gewent, maar ik ken meerdere mensen die er standaard een ID voor plakken. Ergens die in de database engine schijnt het iets uit te maken (don't ask me what).

Anyway, als je een vertaling van een woord gaat opnemen, zou je dan ook niet synonymen moeten bewaren? De Nederlandse taal kent ladingen synonymen en op die wijze kan je je vertaling in het begin relatief eenvoudig houden (of zeg ik nou iets heel erg stoms?)

[sh4d0wman]

@ Dido, dank voor de Visio tekening! Ik zal dit ook even in mijn pakket verwerken en kijken wat ik nog toe wil voegen. Daarbij denk ik onder andere aan de opmerking van DrFrankenstoner.
Daarna zal ik eens uitzoeken waar ik mijn test database mee ga maken. Mocht ik een update op het design hebben dan zal ik die hier nog even posten.

[Dido]

Nick_S schreef op dinsdag 09 augustus 2005 @ 20:09:
Is het bij koppeltabellen niet gebruikelijker om geen id aan te maken en de primary key te laten bestaan uit de twee foreign keys? Zodat je daar ook geen dubbele in krijgt. (Een woord met twee dezelfde categorien bijvoorbeeld)

Dat kan inderdaad uitstekend. Ik ben zelf gewend om in iedere tabel een technische sleutel op te nemen, dat hangt vaak ook af van de standaards die je hanteert.
Je kunt dubbele occurrences overigens ook eenvoudig voorkomen door middel van een constraint.

DrFrankenstoner schreef op dinsdag 09 augustus 2005 @ 20:51:
Anyway, als je een vertaling van een woord gaat opnemen, zou je dan ook niet synonymen moeten bewaren? De Nederlandse taal kent ladingen synonymen en op die wijze kan je je vertaling in het begin relatief eenvoudig houden (of zeg ik nou iets heel erg stoms?)

In dit model is een synoniem een gewone vertaling
Dat is m.i. een groot voordeel van dit model: als de taal van woordvan en woordnaar gelijk zijn heb je een synoniem, je kunt dan inderdaad ook een thesaurus opzetten.

Het meeste werk zit in dit geval niet in het opzetten van de database, maar in het vullen ervan

sh4d0wman schreef op woensdag 10 augustus 2005 @ 08:45:
@ Dido, dank voor de Visio tekening! Ik zal dit ook even in mijn pakket verwerken en kijken wat ik nog toe wil voegen. Daarbij denk ik onder andere aan de opmerking van DrFrankenstoner.
Daarna zal ik eens uitzoeken waar ik mijn test database mee ga maken. Mocht ik een update op het design hebben dan zal ik die hier nog even posten.

Alsjeblieft
Of je technische sleutels in je koppeltabellen gebruikt moet je inderdaad zelf weten, als je geen standaard hebt die je moet volgen zou ik de keus af laten hangen van de DB die je gebruikt. In de documentatie daarvan is meestal wel te vinden wat het snelste is (performance is eigenlijk het enige criterium).

[ Voor 24% gewijzigd door Dido op 10-08-2005 08:49 ]

[a3konijn]

Het enige wat ik mis in Dido zijn opzet is dat in het voorbeeld zoals sh4d0wman hem geeft hij definities opneemt van woorden, i.p.v. een vertaling naar een ander woord.

Dus van Thai naar Engels: sohng = To maintain

Alleen van Engels naar Thai zou zijn: maintain = sohng

Dus misschien bij iedere woord ook een (uitgebreidere) definitie opnemen. En indien niet ingevuld dan toch het woord zelf tonen.

[Dido]

Goed punt, inderdaad. Zoiets kun je ondervangen met simpelweg een extra veld in tabel Woord.

[a3konijn]

Zowiezo heb je met werkwoorden en meervouden vaak de kans dat mensen (zeker als ze de taal niet kennen) niet weten wat de goede vervoeging (lees: kans op beste zoekresultaat) is. Dus zou je een woord op moeten splitsen in iets van een stam/basis + restant of iets dergelijks.

Denk aan:
maintain, maintenance == maint + ain / enance
bicycle, bicycling, to bicycle, bicycles == bicyl + e / ing / es

Wordt het vullen wel een stuk complexer van, maar het zoeken zal meer opleveren.

[ Voor 4% gewijzigd door a3konijn op 10-08-2005 12:08 ]

[Dido]

Dat kun je applicatief ondervangen door, als iemand maint invoert, alle resultaten te geven voor maintain en maintenance.

(LIKE is langzaam, maar de vraag is of performance zo belangrijk is. Overigens heb je maar 1 LIKE nodig, waarna je vertrouwt op de resulaten uit je Vertalingen tabel))

[a3konijn]

Eens, alleen ik bedoelde het eerder andersom:

Hoe kan je ervoor zorgen dat als iemand bycicles invoert, ervan uitgaande dat hij de taal niet goed kent en dus niet weet dat dit een meervoud betreft, en er dus in de database alleen bycicle opgeslagen staat toch de correcte vertaling teruggeven in plaats van met de melding komen dat bycicles niet gevonden kan worden?

[Mc.Boldy]

a3konijn schreef op woensdag 10 augustus 2005 @ 12:33:
Eens, alleen ik bedoelde het eerder andersom:

Hoe kan je ervoor zorgen dat als iemand bycicles invoert, ervan uitgaande dat hij de taal niet goed kent en dus niet weet dat dit een meervoud betreft, en er dus in de database alleen bycicle opgeslagen staat toch de correcte vertaling teruggeven in plaats van met de melding komen dat bycicles niet gevonden kan worden?

Als iemand bycicles zoekt vind ik een 'niet gevonden' wel op zijn plek Je oplossing tot het opdelen van de woorden is een goed alternatief, maar valt denk ik niet meer onder de noemer 'simpel' zoals de bedenker voor ogen had.

[Dido]

Je zou inderdaad een paar extra velden op kunnen nemen voor meervouden, verkleinwoorden, e.d. Hoever je daarin wil gaan is afhankelijk van hoe het ding egbruikt gaat worden en hoe veel tijd je erin wilt/kunt steken.

[a3konijn]

Dat is waar ja. SIMPEL.

En vooral het vullen wordt er zo niet echt gemakkelijker op.

[drm]

Dido:
Je zou inderdaad een paar extra velden op kunnen nemen voor meervouden, verkleinwoorden, e.d. Hoever je daarin wil gaan is afhankelijk van hoe het ding egbruikt gaat worden en hoe veel tijd je erin wilt/kunt steken.

Dat zou ik niet doen. Voor het Engels is daar een algoritme voor ontwikkeld door ene Martin Porter, (het zgn. Porter Stemming algorithm) dat Engelse woorden terugbrengt tot hun stam. Daarvan zijn vervolgens in allerlei westerse talen spin-offs gekomen, en er is ondertussen een enorme lijst met talen beschikbaar waarvoor je de stemmer algoritme's kunt vinden.

[google=Porter stemming algorithm]