Englesko->Srpski i Srpsko->Engleski recnik - dizajniranje baze?

[mirzallica]

Hteo bih da napravim, ako nista malo da vezbam, jedan takav program. Interesuje me kako da dizajniram najbolje bazu da bi program mogao da radi prevod u oba smera? Bazu cu (nekako) sam popuniti...

Razmisljao sam da uradim ovako:

Tabela "eng"
id
rec

Tabela "ser"
id
id_eng
rec

Ovakva postavka bi trebalo dobro da radi za Englesko->Srpski prevod, ali kako bi se pokazala za Srpsko->Engleski nisam bas siguran. Svaka pomoc je dobrodosla. Hvala

 

[danijel00]

Ja bih pravio 4 tabele
ser:
id, rec
eng
id, rec

ser2eng
idser,ideng (gde je pk idser+ideng),

eng2ser
ideng,idser (isto pk idser+ideng)

ovo mi je nekako najoptimalnije i najbrze sto sam uspeo da smislim...
mozes za jednu rec na jednom jeziku da ponudis vise reci na drugom
i obrnuto, a pri tom ne moraju biti iste reci
npr rec a moze da znaci rec b i c na engleskom, a rec b moze da znaci a i f na srpskom
dok npr f na engleskom ne mora da znaci b...
sql bi bio jako jednostavan nad ovim
mozda bi jedino umetanje bilo malo komplikovanije? ne znam ni sam
moze lako da se proba

 

[ganelon]

A zar nebi to moglo sa tri tabele:
1. reči na srpskom (id, reč)
2. reči na engleskom (id, reč)
3. među-tabela koja bi sadržala samo indekse iz ostale dve tabele.

Na taj način bi funkcionisalo pretraživanje u oba smera prostim biranjem upita koji bi u jednom slučaju za englesku reč nalazio sve pripadajuće srpske, a u drugom za srpsu reč, sve pripadajuće engleske.
Ako grešim, nek me neko slobodno ispravi.

 

[danijel00]

meni se sa 4 vise svidja, bas zbog mogucnosti razlicitih prevoda iz jednog u drugi jezik...

 

[silverglider]

Ja bih malcice drugacije organizovao. Napravio bih za svako pocetno slovo po jednu tabelu (A, B, C itd) sa strukturom <id, language, word>. Dakle, u tabeli A bi stajale sve reci koje pocinju na A i na engleskom i na srpskom. Prva vezna tabela bi bila tabela sinonima (apartment = flat = condo =...). Druga vezna tabela bi bile relacije prevoda.

Tako da *nema* posebnog smera englesko-srpski ili srpsko-engleski; imas samo jedan editbox u kojem uneses rec i izaberes da li hoces prevod i/ili sinonime. Zbog toga sto nema posebnog smera, vrlo lako se ubaci u celu pricu i sledeci jezik, bez da mora da se menja struktura tabela ili dodaju nove tabele. Kada recnik naraste do par stotina hiljada reci, doci ce do izrazaja podela na odvojene tabele po pocetnom slovu zbog brzine pretrage.

Kao prvo prosirenje da se ide na pretrazivanje slicnih reci, jer rec moze biti data u nekom padezu (ako je imenica), mnozini/jedini ili vremenu (ako je glagol). Za pocetak moze da posluzi i jeftin trik sa dzokerom, a za kasnije ne bi bilo lose napraviti malo bolji algoritam za slicne reci. Kao sto ima na googlu recimo, ako uneses pogresno napisanu rec "apear", da program sam provali i ponudi "do you mean appear?". To bi resilo i generalne probleme kada bi nase "č" bilo napisano kao "c" ili "ch".

Kao drugo prosirenje bih uveo fraze i njihove prevode. Pa kada se ispise fraza (npr. "how do you do?"), da je svaka rec podvucena i da link vodi ka prevodu te rechi.

 

[Pharos]

Ja bih malcice drugacije organizovao. Napravio bih za svako pocetno slovo po jednu tabelu (A, B, C itd) sa strukturom <id, language, word>. Dakle, u tabeli A bi stajale sve reci koje pocinju na A i na engleskom i na srpskom.

Žurim, pa nemam vremena da detaljno odgovaram. Evo samo na brzaka.
Rečnik radnik u oba smera, ako u okviru baze praviš više tabela, tj. za svako početno slovo po jedanu tabelu, za koji se jezik opredeljuješ, srpski ili engleski?
U Srpskom nemaš wqxy, a u engleskom nemaš šđžčć. Plus za imena tabela nije preporučljivo da sadrže unicode karaktere, što ne znači da neće uvek raditi.
Plus zamislimo da pravimo offline rečnik i ja sad trebam da unesem reč u textbox, i za svake uneseni karakter poziva se funkcija textbox keypress (kako god) koja vrši LIKE upit. Tu je potpuno bespotrebno deljenje na više tabela.
Stvarno nemam vremena sad da produžujem, čim se vratim imaćete neki moj odgovor
pOz

 

[silverglider]

Žurim, pa nemam vremena da detaljno odgovaram. Evo samo na brzaka.
Rečnik radnik u oba smera, ako u okviru baze praviš više tabela, tj. za svako početno slovo po jedanu tabelu, za koji se jezik opredeljuješ, srpski ili engleski?

Ne opredeljujem se ni za jedan jezik, nego za rec. Kada nadjem rec u tabeli, imam drugo polje koje mi govori koji je to jezik (pojednostavljeno <id, language, word> kao sto sam naveo).
Kao rezultat korisniku vracam tabelu sa dva stupca za svaki par jezika - jedan column je jedan jezik, a drugi je onaj drugi jezik (ukoliko je biran dest jezik).

srpski               engleski
------------------------------------
stan                 flat [brit]
stan                 apartment [amer]
stan                 condominium (condo) [amer]

Ukoliko rec (npr. "star") postoji u oba jezika, vracam dve tabele, ne vidim zasto je to problem?

srpski               engleski
------------------------------------
star                 old
star                 aged
star                 elderly
star                 mature 

engleski             srpski  
------------------------------------
star                 zvezda
star                 poznata licnost

Ukoliko je koriscen dzoker kod pretrazivanja, ide i to u tabelu. S tim da se ponavljanje "star" u tabeli lako eliminise, naravno. Stvar je organizacije formulara da li covek zeli korisniku da ponudi src->dest jezike, mozda samo src pa da vrati prevod u svim postojecim jezicima u bazi, itd.
Mozda neko zeli samo da pogleda da li neka rec postoji uopste u recniku da bi proverio da li ju je ispravno napisao.

Upotrebom dzokera odnosno solidnim "similar" algoritmom za trazenje slicnih sekvenci u recima je korisniku data i vise nego dovoljna fleksibilnost.

U Srpskom nemaš wqxy, a u engleskom nemaš šđžčć. Plus za imena tabela nije preporučljivo da sadrže unicode karaktere, što ne znači da neće uvek raditi.

Kao sto rekoh, ovakvom organizacijom se uopste ne orijentisem na jezike, nego na reci. Tako da mi je sasvim svejedno sto u srpskom nema reci na x ili w. U tabeli X ce se nalaziti reci koje pocinju na X u engleskom, francuskom, nemackom itd.
Posebne tabele za reci koje pocinju slovima sa kukama i kvakama ne bih ni kreirao. Dakle, reci koje pocinju na č ili ć bi isle u "c" tabelu. Ako nista drugo, a ono zbog toga sto moram da pretpostavim da korisnik mozda i nema na racunaru instaliran serbian raspored odnosno da rec i kuca bas sa "c" (mozda je lik englez ili amer i ne razume nase specijalne znake, a video je kako rec "otpilike izgleda"). Tu je posao onog algoritma za "slicne" reci da nadje sve matching rezultate. Tim principom bi bili pokriveni i specijalni znaci u drugim jezicima; reci u nemackom koje pocinju na "ö" bi isle u "O" tabelu, reci u francuskom koje pocinju na "é" bi isle u "E" tabelu itd. Formiranje mape aliasa pocetnih slova u kodu ne bi trebalo da predstavlja nikome problem.

Plus zamislimo da pravimo offline rečnik i ja sad trebam da unesem reč u textbox, i za svake uneseni karakter poziva se funkcija textbox keypress (kako god) koja vrši LIKE upit. Tu je potpuno bespotrebno deljenje na više tabela.

Mozda bi u tom scenariju bilo bespotrebno, ali ne bi bilo minus. Cak stavise, moglo bi se profitirati od toga; u onkeypress eventu izdvajanje prvog karaktera i formiranje queryja je brza operacija (cpu+ram), a sam query se opet izvrsava nad prilicno manjim recordsetom (disk). Pa i menjanje imena tabele u generisanim queryju bi se menjalo u onkey eventu samo i ako je to prvi karakter.

Mislio sam da sam objasnio zasto bih delio ovde tabele; prvenstveno zbog organizacije koja je dovoljno fleksibilna da dozvoljava prosirivanje za nove jezike. I kada se dodaje nov jezik, vrsi se linkovanje na vec postojeci set reci iz srpskog. I da neko hoce da plasira to kao offline recnik za dva konkretna jezika, nista lakse nego napraviti kopiju baze i obrisati skriptom sve reci koje ne spadaju u ta dva jezika.

 

[mirzallica]

Pozdrav svima i stvarno sam prijatno iznenadjen brojem odgovora i zeljom da mi pomognete (a i drugima kasnije, naravno). Meni ovaj problem uopste nije izgledao trivijalno sto se i pokazalo na kraju po vasim odgovorima, ima dosta komplikovanih resenja, ali bitno je da to na kraju radi.

@silverglider
Nisam bas shvatio kako da izvedem vezu izmedju reci na srpskom i reci na engleskom. Pretpostavljam da bi najbolja varijanta bila ona preko vezne tabele koju je preporucio "ganelon". To bi izbacilo mogucnost da se npr. rec "star" pojavi 10 puta u jednoj tabeli, jer npr. ima 10 nacina za taj prevod.

Inace, bas sam hteo da postavim dodatno pitanje tipa "sta bi bilo kad bi bilo" ako bi baza narasla na recimo 100.000 reci, ali si dao odgovor u svom postu sa deljenjem tabela po pocetnim slovima reci.

 

[ganelon]

@silverglider
Ta veza koju je mirzallica pomenuo, i mene zanima. Jasna mi je podela na tabele po slovima ali nisam siguran da sam dobro razumeo vezu izveđu određene reči i pripadajućih prevoda. Rekao si da bi trebalo da postoje još dve tabele:
- tabela sinonoma i
- tabela sa relacijama prevoda.

Ako dobro kapiram, tabela sinonima bi takođe trebala da ima svoje "id" polje a tabela sa relacijama prevoda bi sadržala vezu (parove id vrednosti) između, primera radi, reči "star" i odgovarjućih sinonima "apartment; flat; condo ..." u jednom, odnosno "zvezda, poznata ličnost,..." u drugom slučaju (jeziku) i tako za svaki jezik koji se u programu koristi odnosno ponavljanje iste reči u različitim jezicima.
E sad, ako sam ja to dobro razumeo, onda bi id kodovi u "slovnim tabelama" morali da imaju neki svoj utvrđeni opseg id vrednosti jer ako u svakoj od tabela id kreće od 1, neće valjati. Ne kažem da je to neka prepreka, već samo pominjem u smislu pitanja da vidim da li sam ja to dobro "skopčao".

Again, ako grešim, slobodno ispravka.

 

[Pharos]

@silverglider
I ja sam te pogrešno razumeo
Ajde ako ti nije problem, daj nam E-R model. Ne kapiram šta želiš da kažeš. Odnosno kapiram donekle, ali ne znam kako to realizuješ.

@mirzallica
Kako je zamišljena baza? Da ti uneseš podatke u bazu pa da jednostavnim upitom, bez intervencije neke spoljne aplikacije (VB, C#, Delphi...), dobiješ "sirove" rezultate ili da aplikacija treba da vrši neku obradu podataka pa da se uz pomoć nje dobiju krajnji rezultati.

Šta sam mislio pod jedan, a šta pod dva.
1. Ti unosiš podatke u bazu i kad pokreneš upit SELECT... FROM ... ... da krajnji rezultat budu sve reči engleskog koje odgovaraju ekvivalentoj reči iz srpskog.
2. U neka polja u bazi unosiš straing (memo, text, kako već) tipa
(old aged elderly mature) pa da onda pomoću neke aplikacije čitaš taj string i od stringa praviš niz odvajajući reči belim znakom.
rec[0]=old
rec[1]=aged
rec[2]=elderly
rec[3]=mature
...
I onda u aplikaciji staviš za tu i tu reč na srpskom, ekvivalentne reči na engleskom su i onda brojač od 0 do n i dalje ređaš rec...

 

[silverglider]

Tabela prevoda je prosta many2many relacija, odnosno formiranje parova ID-jeva reci jednog jezika i drugog jezika. Sama izvedba moze da se uradi na vise nacina. Na primer:

1. <id-src> - <id-dest>
Preklapanje ID-jeva moze da se resi na vise nacina; na primer, da generator ID-jeva kao prvi karakter vrati ime tabele odnosno slovo (A1, A2, A3...An)

2. <id-src, table-src> - <id-dest, table-dest>
Ovde su ID-jevi obicni generisani integeri, ali se dodaje i ime tabele u drugi column, tako da kombinacija ID-ja i naziva tabele opet jednoznacno odredjuje record. Mada, ako sve tabele koriste zajednicki increment generator, preklapanja ID-jeva ne bi trebalo da bude.


Ovo oko sinonima, radi se vise o lepoj dodatnoj opciji koju bi svaki recnik trebalo da ima, nego o nekoj tehnickoj neophodnosti. Tabela relacija sinonima je na tehnickom nivou ista kao i tabela prevoda, samo sto se logicki razlikuje u tome sto se vezuju reci iz istog jezika (a ne drugog).
Teoretski bi mogla i tabela sinonima da se upotrebi kod prevoda; na primer, kada trazim prevod reci, ne trazim sve parove, tj. sve moguce prevode, nego nadjem prvi prevod i onda izvadim sve sinonime prevoda. Teoretski, naravno - u praksi ovo i ne bi imalo previse smisla, osim ako tabela prevoda ne bi bila drasticno veca od tabele sinonima (a ova potonja bila odlicno odrzavana).

Dalje, kao lep dodatni feature bih upotrebio sto vise dodatnih informacija o samoj reci. Znaci, da record izgleda recimo ovako:

1. ID - naravno, unique identifikator
2. jezik - (srpski, engleski, francuski, nemacki, itd)
3. rec - sama rec
4. tip - imenica, pridev, glagol, itd ("cook" znaci "kuvar", ali "to cook" znaci kuvati)
5. osnovni oblik - ako je glagol, da se polje iskoristi za infinitiv, kod imenica moze da se iskoristi za nominativ ili razlikovanje jednine/mnozine, itd
6. komentar - za uopsteni i neobavezni komentar; tipa, da rec spada u "sleng" ili u neki od dijalekata (ono, neke reci se pojavljuju u britanskom engleskom, ali ne i u americkom, i obratno), da li je znacenje vezano za pojedinu oblast (medicina, komunikacije, ekonomija, itd). Sve se to moze i skracenicama odnosno simbolima resiti.

 

[mirzallica]

Kao prvo SRECNA NOVA GODINA!!!

@Pharos
Konkretno nisam ni razmisljao kako bi sam program trebalo da izgleda, jer mislim da to u ovoj fazi nije ni mnogo bitno. Ako baza bude dobro dizajnirana lako cu programski moci da izvedem razlicite stvari (upite) nad bazom...
Zbog te stvari sam i postavio pitanje, jer ako dizajniram bazu, pa je onda i napunim, a tek onda shvatim da me ogranicava u nekim stvarima mogu komotno da se ubijem.

 

[Pharos]

Za one najosnovnije stvari, ja bi stavio samo 2 tabele i svaka tabela ima po tri kolone.
Tabela Srpski.
id_srp
reč_srp
id_eng

Tabela Engleski
id_eng
reč_eng
id_srp

E sad, id_srp i id_eng su primari ključevi i označavaju id date reči iz srpskog ili engleskog jezika.
reč_srp i reč_eng predstavljaju tu reč.
A ova druga polja id_eng i id_srp nisu primarni ključevi već neka polja tipa varchar, text,nebitno. U njih se smešta neki niz tipa 1,56,345,346. Taj niz sadržvi id-jeve svih reči engleskog jezika koje su ekvivalent toj reči iz srpskog jezika. Stvaranje tog niza radi se na nivou aplikacijepo nekom algoritmu. Tj. uneseš u bazi sve reči srpskok, pa onda uneseš u bazu sve reči engleskog i onda za svaku reč srpskog ili engleskog tražiš ekvivalentne reči i tako menjaš onaj niz da dobiješ nešto tipa 1,56,345,346.

E sad te napredne opcije programa tipa menjanje imenica kroz padeže, glagole kroz glagolska vremena... Time ne bih smarao bazu, već bi aplikacija morala time da se pozabavi. Onda bi naravno pored postojećiš kolona u tabelama dodao i kolonu koja označava tip reči.

E sad, ja nikad nisam radio ovako nešto jer je prilično smor posao, a ima mnošto ovakvih stvari a netu, pa ne znam kako bi se ova ideja pokazala u stvarnosti. Ne bih ti preporučio da se zezaš s tim rečnikom osim ako ne praviš nešto revolucionarno i imaš super razrađen biznis plan. Jednom kad projektuješ bazu i napraviš aplikaciju, sve ostalo ti je čista fizikalija ali to traje i traje...

 

[Pharos]

E kako mi je palo na pamet to rešenje baze.
Prvim za nekog klijenta između ostalog i private message board system.
Sad ti u okviru aplikacije možeš adminu da pošalješ poruku (nije dozvoljena komunikacija sa ostalim članovima al može da se uključi) i pregledaš spisak poruka koje si poslao i spisak poruka koje si primio. I pored svake poruke imaš checkbox gde možeš da selektuješ više poruka i njih da brišeš, premeštaš...
Vrednost checkbox-ova smeštam u niz i kad brišem poruke, prosleđujem upit bazi da se brišu sve poruke iz tabele inbox, outbox, kako već čiji se id nalazi u tom nizu.

Potpuno ti je isti slučaj i sa traženjem reči iz engleskog koje odgovarajudatoj reči iz srpskog. Tražiš sve reči iz tabele Engleski čiji se id nalazi u id_eng iz tabele Srpski.

Možda je malčice offtopic, ali sam hteo da kažem odakle mi ideja

 

[danijel00]

pharos... to sa nizom brojeva u jednom polju je koncepcijski potpun promasaj za relacionu bazu... puno je lakse prikazati niz polja kao jedno polje, nego cupati id-eve iz stringa...

 

[Nick]

@Pharaos
"Relacija R je u Prvoj normalnoj formi (1NF) ako su sve vrednosti njenih atributa atomske" - definicija iz knjige Baze podataka s FON-a.

Mislim da je već prilično dobro razrađena ideja za bazu. Da sumiram:

1. Tabele za svako od slova iz alfabeta i naše latinice (ili ćirilice)

1.1. Polja u svakoj od tabela bi bila ID, Rec, ostala idu opciono (silverovi predlozi; proširenja ne narušavaju strukturu baze u budućnosti)​

2. Tabela Prevodi(IDRec1, Tabela1, IDRec2, Tabela2) koja je jedna agregacija
3. Opciono tabela Sinonimi(IDSinonim1, Tabela1, IDSinonim2, Tabela2).

Najbitnije je odraditi stavke 1 i 2. Izmena koju sam uneo u odnosu na silverov predlog je posebna tabela za svako slovo u svakom od jezika. Tabele bi se zvale ENG_A, ENG_B... SRP_A...
Postoji i opcija ako aplikacija generiše ID reči, zadnje dve cifre određuju poziciju slova (ili sličan neki mehanizam) pa bi onda tabela Prevodi imala samo IDRec1, IDRec2.
Naravno preporučujem da se tabela zove Prevodi_ENG jer može biti joše jezika.

 

[danijel00]

normalizacija nije uvek apsolutno neophodna, mada je poželjna, bar do nekog razumnog nivoa (mene su učili da idem do treće normalne forme...) a ono što je pharaos predložio liči na flat file society |))

ja licno nisam nikako zadovoljan ovim vasim predlogom i dalje ostajem svom iz svoje prve poruke u topicu...
bespotrebno vijanje po puno tabela... po meni bi svaki noviji rdbms koji ima optimizacije pretrage stringova, bi to sigurno bolje odradio od biranja tabele u kojoj se traži reč
a definitivno tabla prevodi i ajd npr sinonimi treba da postoji za svaki smer npr srp u eng i eng u srp... možda moj primer nije bio najsretniji... ali ako se rec A prevodi u rec B, to NE znaci da ce se rec B prevoditi u rec A, po meni nije simetricna relacija... iskopacu neki zgodan konkretan primer ako me ne bude mrzelo...

 

[ganelon]

...ali ako se rec A prevodi u rec B, to NE znaci da ce se rec B prevoditi u rec A, po meni nije simetricna relacija... iskopacu neki zgodan konkretan primer ako me ne bude mrzelo...

To sam inače i mislio da te zamolim. Najozbiljnije. Obzirom da se tvoj i moj predlog, koncepcijski, razlikuju jedino u toj dodatnoj veznoj tabeli, pokušavao sam i sam da se setim nekog primera ali mi nikako nije polazilo za rukom (glavom ).

 

[Nick]

bespotrebno vijanje po puno tabela... po meni bi svaki noviji rdbms koji ima optimizacije pretrage stringova, bi to sigurno bolje odradio od biranja tabele u kojoj se traži reč

Pitanje je koja će biti baza. Da je postavljena na neki server koji ima dovoljno resursa, a pristupa se putem web strane - onda vozi dve tabele. Ali ovo bi trebalo da bude aplikacija koja se izvršava i na nekoj PII mašini, a baza će recimo biti Access. Njemu baš ne prija tabela od 100000 slogova. :S:

Nisam pametan. Voleo bih da neko ko je radio nešto sa sličnim obimom podataka kaže svoje mišljenje.

 

[Proday]

Mozda ti ovo bude od koristi.

Recnik je besplatan od domaceg autora.