Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Indeksi na dva atributa

[es] :: Access :: Indeksi na dva atributa

[ Pregleda: 2020 | Odgovora: 6 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.3dnet.co.yu.

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Indeksi na dva atributa13.11.2006. u 13:20 - pre 212 meseci
Da li u ACCESS moze ovo:

Tabela1:
1. ID (primarni ključ)
2. Atribut1
3. Atribut2
4. nebitno

EDIT:
...Da Atribut1+Atribut2 budu UNIQUE, pri čemu i Atribut1 i Atribut2 (zasebno) smeju imati duplikate (sem zajedno)?

Da li je u ACCESS bazama uobičajeno (ispravno) ovo (ukoliko je odgovore na ovo gore NE):

Tabela1:
1. Atribut1 (primarni ključ)
2. Atribut2 (primarni ključ)
3. ID
4. nebitno

... da ID bude običan AutoNumber, pa da se iz neke tabele 2 vrši vezivanje preko spoljnjeg ključa:

Tabela2:
1. ID
2. nebitno
3. Tabla1_ID (spoljni ključ ka Tabela1.ID)

...?


[Ovu poruku je menjao X Files dana 13.11.2006. u 14:32 GMT+1]
 
Odgovor na temu

BiloKoje
Beograd

Član broj: 40147
Poruke: 401



+4 Profil

icon Re: Indeksi na dva atributa13.11.2006. u 13:50 - pre 212 meseci
Ako ti prva varijanta (posle tvog EDITa) zadovoljava potrebe, znači dva polja, svako može da ima duplikate, ali zajedno ne mogu, onda druga varijanta otpada. Ovo prvo je moguće, to je složeni ključ.

edit: I ne treba onaj AutoNumber.
 
Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
89.216.236.*

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Re: Indeksi na dva atributa13.11.2006. u 15:37 - pre 212 meseci
Možda nisam baš najpreciznije definisao pitanje, evo šta zapravo hoću:

Ako imam dve tabele:

--- Tabela1 ---
1. Atribut1
2. Atribut2
3. Atribut3
4. Atribut4

Atribut1 + Atribut2 + Atribut3 + Atribut4 = zajedno treba da bude jedinstveno,
pa sam ove četiri stavke proglasio kao PK.

--- Tabela2 ---
1. ID
2. kako_sad_da_ukazem_na_neki_slog_tabele_1
3. nebitno

a) --- prva varijanta ---

Ako stavim ID kod tabele 1, onda gubim (da li?) mogućnost da na sistemskom
nivou osiguram jedinstvenost pojave Atribut1 + Atribut2 + Atribut3 + Atribut4.

1. ID
2. Atribut1
3. Atribut2
4. Atribut3
5. Atribut4

... jer ID (ako ga proglasim da bude AutoNumber) kad uđe u ključ sa ostale 4
stavke, uvek stvara jedinstvenost. U ovom slučaju, tabela 2 bi bila:

--- Tabela2 ---
1. ID
2. Tabela1.ID
3. nebitno

b) --- druga varijanta ---

Tabela 1 ostaje ista (bez ID-ja)

--- Tabela1 ---
1. Atribut1
2. Atribut2
3. Atribut3
4. Atribut4

--- Tabela2 ---
1. ID
2. Tabela1.Atribut1
3. Tabela1.Atribut2
4. Tabela1.Atribut3
5. Tabela1.Atribut4
6. nebitno

Ovo mi deluje strašno traljavo.

Dakle, pitanje je kako biste vi rešili ovaj slučaj i da li Access dozvoljava pravljenje
nekog indeksa složenog od više atributa, koji nisu deo primarnog ključa, a mogu se
podesiti da budu Unique?

 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Indeksi na dva atributa14.11.2006. u 13:31 - pre 212 meseci
Citat:
Ovo mi deluje strašno traljavo.

Potpuno pogresno. Drugi nacin, sa vestackim ID je traljav. Tebe samo uzasava pomisao da bi mogao da pravis kveri koji zahteva 4 polja u JOINu. Zavisno od toga sta su u stvari ona 4 atributa, mogao bi da imas velike probleme ako dodas vestacki kljuc, a mozda i nemas problema. Mnogo ljudi ce ti na ovom forumu i na forumu Baze Podataka odgovoriti da su autonumber polja i izmisljena da bi se lako dobio PK kad god ti treba. Traba biti veoma oprezan s tim pristupom. Za pocetnika nije dobar pristup, jer jednostavno pogresno naucis i shvatis celu ideju o relacionim sistemima.

Naravno da necu ulaziti u dalju diskusiju o vestackim i stvarnim PK, to smo radili na forumu Baze Podataka i svako je ostao pri svome.

:-)
 
Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
89.216.236.*

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Re: Indeksi na dva atributa15.11.2006. u 19:09 - pre 212 meseci
Zidar,

Možeš li da mi pojasniš tvoj odgovor na ovu temu. Nešto nisam shvatio:
Citat:

Citat:

Ja: Ovo mi deluje strašno traljavo.
Zidar: Potpuno pogresno.

Da li se slažeš da je ovo što sam napisao traljavo ili se ne slažeš? Shvatio sam
da misliš da to zapravo NIJE traljavo, nego baš onako kako treba. Potreban mi
je baš tvoe mišjljenje, jer želim da rešenje bude NAJPRIBLIŽNIJE rešenju koje je
u duhu baza podataka i "normalnih formi", a ne rešenje koje mi je najlakše za
kasniju instant implementaciju. Dakle, treba mi školski.

Citat:

Drugi nacin, sa vestackim ID je traljav.

Zapravo, mislio si na ono prvo rešenje (prvu varijantu, kako sam je ja nazvao)?

Citat:

Tebe samo uzasava pomisao da bi mogao da pravis kveri koji zahteva 4 polja u JOINu.

Kao što rekoh, baš mi treba školski, ma koliko bi to kasnije proizvelo složenije upite.

Citat:

Zavisno od toga sta su u stvari ona 4 atributa, mogao bi da imas velike probleme ako
dodas vestacki kljuc, a mozda i nemas problema.

Na kraju ovog posta ću predstaviti šta mi konkretno treba, pa bih te zamolio da mi predložiš
rešenje koje je najviše u duhu baza podataka, a ne rešenje koje će mi kasnije doneti
najkraći SQL.

Citat:

Mnogo ljudi ce ti na ovom forumu i na forumu Baze Podataka odgovoriti da su autonumber
polja i izmisljena da bi se lako dobio PK kad god ti treba. Traba biti veoma oprezan s tim
pristupom.

Znam, zato sam i postavio pitanje koji je ispravan način. I ja lično koristim AutoNumber ID-je
iz praktičnih razloga, pa iz samog koda rešavam neka obavezna ograničenja. Sada, hoću
rešenje koje rešava što više tih ograničenja na sistemskom nivou, i želim da to bude školski.

Citat:

Naravno da necu ulaziti u dalju diskusiju o vestackim i stvarnim PK, to smo radili na forumu
Baze Podataka i svako je ostao pri svome.
:-)

Onda sam naleteo na pravog čoveka ;) Baš mi treba neko ko drži do pravila, bez obzira što
kasnije mogu imati više muke sa upitima, vezama i sl.

Da napomenem da ja nisam baš neupućen u baze podataka, ali ih zaista koristim tek kao
nešto sa strane. Neke moje baze podataka na primer za organizovanje izložbi pasa (C++
Builder program koji pristupa Access bazama) rade godinama bez ikakvih problema. Ali
ja nisam zadovoljan svojim dizajnom baze, jer je sve rađeno na brzinu i tek toliko da
proradi.

E sada, za potrebe nekog ispita, NE TREBA mi da pokažm profesoru KAKO PROGRAM RADI, što
je očigledno, nego je cilj da pokažem da je baza ISPRAVNO projektovana.

Evo konkretan problem (koji je zapravo samo deo zadatka), ali hoću da to bude projektovano
u duhu baza podataka. Dakle zanima me kako najbolje projektovati tabele i uspostaviti veze.

Radi se o kategorizovanju pasmina, koje imaju otpriliko ovakvu strukturu:

Group 1: Sheepdogs and Cattle Dogs (except Swiss Cattle Dogs)
Section 1: Sheepdogs
Australia
Australian Kelpie
Belgium
Chien de Berger Belge - Groenendael
Chien de Berger Belge - Laekenois
Chien de Berger Belge - Malinois
Chien de Berger Belge - Tervueren
Schipperke
Czekoslovakia (Slovakia)
Ceskoslovenský Vlcak
Croatia
Hrvatski Ovcar
...
...
Section 2: Cattle Dogs (except Swiss Cattle Dogs)
Australia
Australian Cattle Dog
Belgium
Bouvier des Ardennes
Belgium/France
Bouvier des Flandres/Vlaamse Koehond
...
Group 2: ...
...
...
...

Dakle, postoji hijerarhijska struktura:

1.nivo: Postoji 10 Grupa (Group 1, Group 2, ...)
2.nivo: Svaka grupa ima odredjeni broj Sekcija, neke grupe manje neke više
3.nivo: Svaka Sekcija ima odredjeni broj Drzava, neke sekcije manje a neke vise
4.nivo: Naziv Rase (on je uvek i uvek jedinstven, bez duplikata)

Ovako ja vidim gornju strukturu:

| -------- | -------- | -------- | -------- |
| Atribut1 | Atribut2 | Atribut3 | Atribut4 |
| -------- | -------- | -------- | -------- |
| GRUPA | SEKCIJA | DRZAVA | RASA |
| -------- | ---------|--------- | -------- |
| Unique | Unique | Unique |
|<-------->|<------------------->|<-------->|
| GRUPA | SEKCIJA + DRZAVA | RASA |
|----------|---------------------|----------|

Pa sam mislio da to projektujem ovako:

Tabela1: Drzave (ovaj entitet mi treba zaseban u bazi i zbog drugih potreba druge potrebe)
1. naziv (PK)
2. ...

Tabela2: Grupe
1. naziv (PK)
2. ...

Tabela3: Sekcije
1. naziv (PK)
2. drzave.Naziv (PK) <--- veza ka Tabeli 1
3. ...

Tabela4: Rase
1. naziv (PK)
2. ...

Tabela5: Kompletna Pasmina
1. grupe.naziv <--- veza ka Tabeli 2
2. sekcije.naziv <--- veza ka Tabeli 3
3. drzave.naziv <--- veza ka Tabeli 1
4. rase.naziv <--- veza ka Tabeli 4

E sad, treba u nekoj drugoj tabeli da ukazem na neki slog iz tabele: "Kompletna Pasmina".

Tabela6: Upotreba
1. grupe.naziv <--- veza ka Tabeli 5
2. sekcije.naziv <--- veza ka Tabeli 5
3. drzave.naziv <--- veza ka Tabeli 5
4. rase.naziv <--- veza ka Tabeli 5
5. blablabla
6. itditditd

Postoji li pametniji nacin, kada je u pitanju ŠKOLSKI PRISTUP bazama podataka?
 
Odgovor na temu

Zidar
Canada

Moderator
Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Indeksi na dva atributa15.11.2006. u 21:54 - pre 212 meseci
Za teoriju je mnogo bolji Chachka. Ja u stvari nikad nisam formalno ucio teoriju, samo sam procitao dosta knjiga i imao srecu da na poslu imam slobodu da odlucujem o problemu 'teorija ili 'praksa''

Ipak, da pokusam, pa neka me Chachka dopuni ili ispravi ako nesto lupnem.

Ako prihvatiom da je skolski pristup = teorijski pristup, onda Autonumber ne sme da postoji, pogotovu ne da bi zamenio multi column key. Iz ovoga sledi da ako u nekoj tabeli imas tri ili cetiri kolone koje zajedno cine PK, onda je to PK. Uvodjenje vestackog kljuca nije dozvoljeno u teoriji (Codd), mada ima autora koji kazu suprotno (Chris Date ?). Posto je relacionu teoriju ipak izmailio Codd, meni je logicno da prihvatim njegov 'stav'.

Ako imas nesto sto lici na hijerarhiju, onda je PK za podredjenu (chlid) tabelu uvek napravljen od celog PK parent tabele plus neka kolona ili vise njih koje dovode do jedinstvenosti reda u child tabeli. Sve po Codd-u.

Tvoj slucaj:
1.nivo: Postoji 10 Grupa (Group 1, Group 2, ...)
2.nivo: Svaka grupa ima odredjeni broj Sekcija, neke grupe manje neke više
3.nivo: Svaka Sekcija ima odredjeni broj Drzava, neke sekcije manje a neke vise
4.nivo: Naziv Rase (on je uvek i uvek jedinstven, bez duplikata)

bi izgledao nekako ovako:

tabela 1: Grupa (PK: GrupaID) - nema parent tabele za ovu tabelu
tabela 2: Sekcija (PK: GrupaId, SekcijaID) FK: GrupaID
tablea 3: Drzava (PK: DrazvaID) - name parent tabele za ovu tabelu
tabela 4: DrazavaUgrupi (PK: GrupaID, sekcijaID, DrzavaID) FK1: GrupaId, SekcijaID, FK2: DrzavaID
tabela 5: Rasa (RasaID) - name paret tabele za ovu tabelu
tabela 6: pasmina (?) (PK: RasaID, GrupaID, sekcijaID, DrzavaID) FK1: rasaID, FK2: GrupaID, sekcijaID, DrzavaID

Za 5 i 6 nisam siguran, ne razumem tacno sta je sta. Ovako kako sam ja stavio, dozvoljava se da ista rasa bude prisutna u vise od jedne DrazavaUgrupi. Ako je rasID unique i u tabeli 6, onda imas PK: RasaID u tabeli 6, ostatak (GrupaID, sekcijaID, DrzavaID) sluzi samo da opise rasu i mora pripadati prethodno definisanom domenu DrazavaUgrupi, stoga FK:GrupaID, sekcijaID, DrzavaID.

Uoci situaciju u tabeli 2, gde je FK deo PK, to jest PK iz parent tabele je prenesen na child tabelu. Cini mi se da se to zove identifying relationship.
Ako u tabeli 6 pretpostavimo da je RasaID = PK, jos uvek imamo FK na DrzavaUGrupi, ali taj FK nije deo PK u child tabeli. To je non-identifying relationship

Nadam se da je nesto pomoglo.

Sta sam primetio u praksi: svi slucajevi koji se svode na hijerarhiju, u relacionim bazama mogu da koriste Autonumber za PK veoma efikasno. Veliki broj realnih problema moze da se razbije na podprobleme, koji mogu da lice na hijerarhiju, sto je veoma jednostavan model za manipulaciju i razumevanje, ako nema previse nivoa. Zato se mnogi profesinalci kunu u Autonumber (identity) - jer se stvari svedu na hijerarhiju. Medjutim, model koji izgleda kao hijerarhija, obicno nije kompletan. Nesto je propusteno sto se ne mora odmah videti i projektanti se mogu vaditi na ono "Nije bilo trazeno projektnim zadatkom". Ako ti se posle analize cini da tvoj DB model izgleda kao cista hijerarhija, imas negde veliki problem koji ili ne vidis jer je zadatak postavljen nekompletno, ili ne zelis da vidis jer bi bilo previse komplikovano. Ovu gresku najcesce cine dobri programeri, jer svaki problem mogu rese programiranjem, sto u stvari i vole da rade. Dobar programer ce mnogo brze da resi problem na nivou user interface, nego sto ce dobar DB modeler da resi problem na nivou logickog dizajna baze. U praksi treba naci balans izmedju ovo dvoje - efikasnost u programiranju i efektivnost u modeliranju baze. Kazem efikasnost i efektivnost, nije isto.

efficiency = doing things right = raditi stvari dobro (na dobar nacin) = resenje problema programiranjem
effectiveness= doing right things = raditi dobre stvari = resenje problema na nivou baze, dobrim modelom


 
Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.3dnet.co.yu.

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Re: Indeksi na dva atributa16.11.2006. u 12:37 - pre 212 meseci
Citat:

Ipak, da pokusam, pa neka me Chachka dopuni ili ispravi ako nesto lupnem.

Nadam se da će se 'pojaviti'. Nije kulturno da ga s namerom uplićem u svoje probleme...

Citat:

Ako prihvatiom da je skolski pristup = teorijski pristup,

Upravo to.

Citat:

tabela 1: Grupa (PK: GrupaID) - nema parent tabele za ovu tabelu
tabela 2: Sekcija (PK: GrupaId, SekcijaID) FK: GrupaID
tablea 3: Drzava (PK: DrazvaID) - name parent tabele za ovu tabelu
tabela 4: DrazavaUgrupi (PK: GrupaID, sekcijaID, DrzavaID) FK1: GrupaId, SekcijaID, FK2: DrzavaID
tabela 5: Rasa (RasaID) - name paret tabele za ovu tabelu
tabela 6: pasmina (?) (PK: RasaID, GrupaID, sekcijaID, DrzavaID) FK1: rasaID, FK2: GrupaID, sekcijaID, DrzavaID

Razumeo sam poentu ovakve hijerarhijske definisanosti, i tako ću nešto i uraditi.

Ovde si samo malo pomesao neke nazive. Trebalo je (valjda) Drzava_u_Sekciji, a ne DrazavaUgrupi.
Jer svaka sekcija u grupi može imati ponovo drzavu, npr (Australia):

Group 1:
Section 1:
Australia
...
Section 2:
Australia
...

... ali koliko vidim, PK i FK su svakako ispravno postavljeni.

Citat:

Ovako kako sam ja stavio, dozvoljava se da ista rasa bude prisutna u vise od jedne DrazavaUgrupi.

Ne. Za razliku od folderske strukture, u kojoj neki fajl "readme.txt" može postojati u više nezavisnih foldera,
ovde je naziv Rase unikat, i može/mora postojati u tačno jednoj grupi+sekciji+drzavi+ta rasa, i nigde više.

Citat:

Ako je rasID unique i u tabeli 6, onda imas PK: RasaID u tabeli 6, ostatak (GrupaID, sekcijaID, DrzavaID)
sluzi samo da opise rasu i mora pripadati prethodno definisanom domenu DrazavaUgrupi, stoga FK:GrupaID,
sekcijaID, DrzavaID.

Da. rasaID je unique, onda je PK samo RasaID, a ostalo FK.

Citat:

Uoci situaciju u tabeli 2, gde je FK deo PK, to jest PK iz parent tabele je prenesen na child tabelu. Cini mi se
da se to zove identifying relationship.
Ako u tabeli 6 pretpostavimo da je RasaID = PK, jos uvek imamo FK na DrzavaUGrupi, ali taj FK nije deo PK u
child tabeli. To je non-identifying relationship

Potpuno sam razumeo šta si hteo da kažeš. Uprvo ta verzija je ona koja mi treba.

Citat:

Nadam se da je nesto pomoglo.

Svakako. Ovo je najbolje objašnjenje koje sam do sada dobio na ovu temu.

Nego znaš šta mi je sada "sinula", kada si sve ovo rekao o identifying/nonidentifying relationship:

1) PK jedne tabele (ili neki njegov deo) ukazuje na PK druge tabele (ili na neki njegov deo) - ovo je običan slučaj
2) obično polje jedne tabele ukazuje na PK druge tabele (ili na neki njegov deo) - nonidentifying relationship

Sad obrati pažnju:

3) PK jedne tabele (ili neki njegov deo) ukazuje na OBIČAN atribut, autoincrement ID druge tabele. Šta želim ovime
da postignem - da se oslobodim silnih linija veze (valjda se to zove kardinalnost) i upotrebim samo jednu, pri čemu
mi je taj ID ta jedna jedina nedvosmislena unikatna veza.

To sam ja pitao na forumu baze podatak pre nekoliko dana, i sada već (za mene) čuveni chachka mi je ovo perfektno
objasnio:

Citat:

Sto se tice:
Citat:

Citat:
X Files: (Čak mislim da standard "iso/iec 2382-17:1996" sam naziv spoljni ključ jasno vezuje za pojam primarnog
ključa nekog drugog etiteta)

isti taj standard (koji je btw povucen, ako ne laze internet) kaze da primarni kljuc nedvosmisleno identifikuje jedan red
tabele, te po njemu sledi da su i atribut ID i par atributa (drzava_ID, grad) iz tabele 'MESTO' u stvari primarni kljucevi.
Po meni se, u duhu tog standarda, u prvom postu ispravno koristi termin 'FOREGN KEY'.

U SQL-u se terminom PRIMARY KEY oznacava kljuc koji se uzima kao default kljuc za foreign key referenciranje. To ne
znaci da se referenciranje ne moze vrsiti i po ostalim kljucevima (pa cak i po ne kljucnim atributima sto ja ponekad
koristim). Na zalost ti ostali kljucevi (i atributi) se u SQL-u moraju definisati upotrebom UNIQUE INDEX-a, jer mene to
asocira na fizicko uredjenje baze.


Voleo bih da se sada javi i chachka kaže i da li smatra da bi imalo ikakvog pametnog uticaja imati
nekakav običan autoincrement ID koji bi smanjio te silne linije veze između dva entiteta.

Citat:

efficiency = doing things right = raditi stvari dobro (na dobar nacin) = resenje problema programiranjem
effectiveness= doing right things = raditi dobre stvari = resenje problema na nivou baze, dobrim modelom

Lepo izraženo.

U svakom slučaju, čak i ako schachka ne vidi ovaj thread, dobio sam puno odgovore na puno nedoumica koje sam imao.

Hvala.

 
Odgovor na temu

[es] :: Access :: Indeksi na dva atributa

[ Pregleda: 2020 | Odgovora: 6 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.