Forum LibreOffice i OpenOffice korisnika

Poštovanje,
Pokušavam da napravim bazu podataka koja bi obuhvatila stranke
i kao subform sve neophodne korake i nalaze u pregledu stranke.

Problem je što mi je za tabelu Pregledi potrebna velika tabela. Koliko sam
shvatio,
limit Base je za jednu tabelu oko 130 polja. Međutim, potrebe su kod mene
oko 3 puta veće. Kako da to rešim? Dodatnim subformama? Da li je to
stabinlno
rešenje? Ako neko ima iskustva, molim za savet.

--
Srdačan pozdrav,
Stevanović Vladislav

U sre, 25. 08 2010. u 19:13 +0200, Vladislav Stevanovic piše:
> limit Base je za jednu tabelu oko 130 polja

Tako mali broj može biti samo limit na broj kolona u tabeli, ne mogu
sada na brzinu da potražim koliko taj limit iznosi.

Ako imate tabelu sa više od 130 kolona sigurno je da ste pogrešno
dizajnirali Vašu bazu podataka.

OpenOffice.org Base može i da se poveže na spoljne servere za baze
podataka (Oracle, MySQL,...). Znam da se koristi i za baze od po više
gigabajta podataka.

S poštovanjem,
Goran Rakić

Ideja je da napravim bazu podataka koja bi podmirila Pacijentov karton
(videti Pdf prikačeni fajl). Svaka kockica
ili linija utom Pacijentovom kartonu bi bilo jedno polje, tj kolona). Dakle,

podataka za unos ima dosta.
Neki savet?

2010/8/25 Goran Rakic <grakic@devbase.net>

> U sre, 25. 08 2010. u 19:13 +0200, Vladislav Stevanovic piše:
> > limit Base je za jednu tabelu oko 130 polja
>
> Tako mali broj može biti samo limit na broj kolona u tabeli, ne mogu
> sada na brzinu da potražim koliko taj limit iznosi.
>
> Ako imate tabelu sa više od 130 kolona sigurno je da ste pogrešno
> dizajnirali Vašu bazu podataka.
>
> OpenOffice.org Base može i da se poveže na spoljne servere za baze
> podataka (Oracle, MySQL,...). Znam da se koristi i za baze od po više
> gigabajta podataka.
>
> S poštovanjem,
> Goran Rakić
>
>
>


--
Srdačan pozdrav,
Stevanović Vladislav

U sre, 25. 08 2010. u 19:58 +0200, Vladislav Stevanovic piše:
> Ideja je da napravim bazu podataka koja bi podmirila Pacijentov karton
> (videti Pdf prikačeni fajl).

Lista odbacuje priloge, možete li da okačite datoteku negde?

Opšti savet pri dizajniranju baza podataka je da podelite podatke u
logičke entitete. Na primer, imate podatke o zdravstvenoj ustanovi,
pacijentu, unosima u karton,... sve u nezavisnim tabelama.

Pozdrav,
Goran

Goran Rakic wrote:
> U sre, 25. 08 2010. u 19:58 +0200, Vladislav Stevanovic piše:
>> Ideja je da napravim bazu podataka koja bi podmirila Pacijentov karton
>> (videti Pdf prikačeni fajl).
>
> Lista odbacuje priloge, možete li da okačite datoteku negde?
>
> Opšti savet pri dizajniranju baza podataka je da podelite podatke u
> logičke entitete. Na primer, imate podatke o zdravstvenoj ustanovi,
> pacijentu, unosima u karton,... sve u nezavisnim tabelama.
>
> Pozdrav,
> Goran
>

Pridruzujem se ovom savetu. Osnovne podatke o samom pacijentu u jednu
tabelu, o ustanovi u drugu, istorija bolesti u trecu, itd. Svaka tabela
treba da ima ID, Integer, kljuc za pretragu. I da se on automatski
inkrementuje u samoj bazi. U podredjenim tabelama se onda pozivate na ID
glavne tabele i mozete da imate neogranicen broj redova za isti podatak
iz glavne tabele (za ID iz Pacijent tabele = 234 mozete da imate 10,
200, 100000 redova u tabeli Pregledi, isto tako u tabelama izdati
lekovi, naplata, itd.

Ja bih napravio Glavnu tabelu Pacijent, pa podtabelu Pregledi, koja bi
dalje kontrolisala tabele Lekar, sestra (mozda zajedno u jednoj tabeli
osoblje na pregledu), anamneza, simptomi, dijagnoza, preporuceno
lecenje, izdati recepti, sve to lepo rasclanjeno tako da vise podataka
(po datumima) moze da se po potrebi dodaje. I tabelu tretmani mozda koja
bi imala polja oddatum i do datum, pa da se lako moze pregledati
istorija lecenja, filtrirati po potrebi i slicno.

I da se naravno ti neki od podataka mogu ponovo koristiti, smanjujuci
tako i broj prekucavanja istih podataka i velicinu tih podataka. I jos
se ti podaci mogu birati iz padajuce liste (lookup u odgovarajucoj
tabeli po ID-u master tabele.

Preporuka je da proucite primere baza (mislim da ih ima u Base-u,
posebno neka vrsta baze prosecne firme).

Pozdrav,
Ljubomir

Poštovanje,

Hvala na savetima, medjutim, iskrsao je novi problem.
Bazu koju sam uredjivao otvorio sam u drugom kompjuteru
na poslu sa instaliranim zadnjim Openoffice-om, malo menjao
i sačuvao na flešu promene. Sada na drugom kompjuteru kod kuće
ne mogu da otvorim fajl.
To jest, otvorim ga, ali je bez postojećih obrazaca a kada
mišem kliknem na Tabele otvori se prozor sa tekstom:
"Ne mogu da uspostavim vezu sa izvorom podataka
Nova baza 2. Klasa drjvera "" ne može biti učitana."

Kada pritinem na tom prozoru dugme "JOŠ"
dobijam sledeća dalja objašnjenja:
Ne mogu da uspostavim vezu sa izvorom podataka "Nova baza2".
Kod greške: 1000
Klasa drajvera "" ne može biti učitana.
Stanje za SQL: HY000
Klasa drajvera "" ne može biti učitana.

Šta to znači? Da je sve što sam radio nestalo?!


--
Srdačan pozdrav,
Stevanović Vladislav

Evo, napravio sam tabele, gledajući da ih rascepkam kao
što ste i savetovali. U svakoj tabeli sam stavio Identifikacioni
broj pacijenta, identifikacioni broj pregleda i datum pregleda.
Postoji tabela PACIJENTI, ZAPOSLENI i 16 tabela koji su
detalji pregleda.
Potrebno ih je povezati, za šta mi je potrebna mala pomoć,
jer je ovo za mene malo kompleksnije.



Srdačan pozdrav,
Stevanović Vladislav

Vladislav Stevanovic wrote:
> Evo, napravio sam tabele, gledajući da ih rascepkam kao
> što ste i savetovali. U svakoj tabeli sam stavio Identifikacioni
> broj pacijenta, identifikacioni broj pregleda i datum pregleda.
> Postoji tabela PACIJENTI, ZAPOSLENI i 16 tabela koji su
> detalji pregleda.
> Potrebno ih je povezati, za šta mi je potrebna mala pomoć,
> jer je ovo za mene malo kompleksnije.
>
>
>
> Srdačan pozdrav,
> Stevanović Vladislav
>
Malo veci problem je sto ja nikada nisam radio sa Base-om, a zadnji
projekat u MS Access-u je bio oko 2003 godine (program za turisticke
operatere koji sam vodio jedno vreme). A da imam vremena bas i nemam.

ti ID-jevi treba da budu primary kljucevi u podredjenoj tabeli,
obelezeni kao takvi i povezani sa poljem u glavnoj tabeli.

Bilo koja knjiga o bilo kojoj vrsti SQL-a ce pomoci oko ovog koncepta,
pa cak i knjige o MS Accessu. Ja sam ucio iz knjiga o Delphi-ju. Morate
ovladati ovom materijom, makar osnovnim pojmovima pre nego se upustite
dalje u projekat. Pravilno resavanje dizajna, ma koliko dugo vremenski
trajalo, ce vam se kasnije MNOGOGSTRUKO isplatiti, smanjujuci vreme oko
resavanja problema koji se mogu izroditi, velicine baze i usporenosti
programa.


Da li ste pogle neke vec gotove primere?

Na primer, posetite
http://wiki.services.openoffice.org/wiki...e_Examples

Takodje negde moze da se skine uputstvo za Base 2.0 na hrvatskom. Ako ne
mozete da ga nadjete, mailovacu vam ga.

Nekada se naprave posebne tabele svaka sa svojim primarnim kljucem, a
onda se napravi pomocna tabela koja samo sadrzi oba kljuca u posebnim
poljima, pa ta tabela sluzi da se te dve glavne tabele povezu bez
dupliranja podataka.

Na primer, proizvodni predmet ID 534 moze da se pravi u vise boja (ID 3,
5, 6), a proizvod 546 u ID 1, 3, 6, 7). Primer je banalizovan zbog
jednostavnosti, ali zamislite da boja ima 40-50.

Umesto na imate 40-50 polja za svaku mogucu boju, ili 50 redova za svaku
boju posebno, najlakse je imati odvojene tabele za proizvode i boje, a
da napravite jednu duplo podredjenu tablicu (primarni i sekundarni
kljuc) sa samo 2 polja: ProductID i ColorID.

U bazi bi onda imali podatke:

534; 3
534; 5
534; 6
546; 1
546; 3
546; 6
546; 7
(....;...)
(....;...)
(....;...)
(....;...)

Kada izvlacite sve moguce kombinacije, napravite upit nad glavnom
tabelom ali tako da su grupisani i u odnosu na podredjenu tabelu, tako
da je u bazi samo jedan artikal, ali se na spisku za izbor pojavljuje
vise puta, jedan za svaku mogucu boju.

Kada treba da zapisete koji artikal treba da se proizvodi, u tabelu
radni list cete upisati samo ProductID i ID boje (ako nema dodatnih
opcija kao cvrstina ili nesto slicno) i naravno ostalo kao datum izrade
i sl.

Jos jedan savet. Treba izbegavati da se osobine proizvoda i slicno
menjaju ako mogu da uticu da kasniji pregled. Tj. ako postoji sansa da
ce neko da menja npr dimenziju artikla, ili npr adresu gde lekar ili
pacijent zivi, bitno je nekako sacuvati stare podatke. Npr, kontakt
podatke o pacijentu cuvati u zasebnoj tabeli, i to tako da postoji datum
unosa podatka, a da se ogranici/oteza penjanje postojecih podataka vec
ohrabri npr kopiranje postojecih podataka u novi red sa tim datumom i
onda dati da tu kopiju menjaju.

Jos bolja varijanta moze da bude ako ako postoji jedinstvena tabela za
sve kontakte sa primarnim poljima TipKontakta (pacijent, osoblje) i ID i
datumom vazenja, cija kombinacija ce dovesti do izvlacenja listinga o
promenama adrese ili telefona i sl. u toku odredjenog perioda.

Valjda je ovo dovoljno za pocetak.

Ljubomir

U pon, 30. 08 2010. u 12:47 +0200, Ljubomir Ljubojevic piše:
> Takodje negde moze da se skine uputstvo za Base 2.0 na hrvatskom. Ako
> ne mozete da ga nadjete, mailovacu vam ga.

Video lekcije:
http://www.koprivnicki-poduzetnik.hr/ind...ceorg-base

Knjiga OpenOffice.org Base, Igora Kosa:
http://sr.openoffice.org/docs/hropen/

Za izradu izveštaja preporučujem Konstruktor izveštaja. Dodatak se može
preuzeti sa: http://sr.openoffice.org/prosirenja.html Pričali smo o
dodatku prošle godine na listi, a u poruci ima i linkova na literaturu:
http://sr.openoffice.org/servlets/ReadMs...&msgNo=327

O izradi modela podataka je bilo reči i u sledećoj temi:
http://sr.openoffice.org/servlets/ReadMs...&msgNo=236

Pozdrav,
Goran