Problem sa relacijama u MSSQL

Pozdrav svima,

imam pocetnicki problem sa MSSQL. Napravio sam dve tabele, obe imaju primarne kljuceve tipa int, identity. Prva tabela (nazovimo je A) ima kolonu id_B, tipa int i iskljucenu opciju nulls jer treba da bude spoljni kljuc ka tabeli B. Napravio sam relacije preko diagrama, medjutim kada napravim View koji sadrzi sve kolone iz obe tabele i kada unesem vrednosti u polja (izuzev za primarne kljuceve), SQL prijavi gresku da spoljni kljuc id_B ne moze biti null. Kada pogledam samo tabelu B, vrednost primarnog kljuca postoji !

Sta radim pogresno, kako da se primarni kljuc iz druge tabele upise u polje spoljnog kljuca prve tabele ?

Potpis

America national sport is called baseballs. It very similar to our sport, shurik, where we take dogs, shoot them in a field and then have a party.

Pa očigledno je ovde problem. Ako se polje id_B veže na primarni ključ druge tabele, a za primarni ključ nisi uneo vrednost..

Da razjasnimo: id_B je foreign key i može imati vrednost koju ima polje primarnog ključa na koje se veže. Pošto nisi uneo vrednosti za primarni ključ te druge tabele, prva vrednost na koju naiđe baza je očigledno null i sad pođe da vidi gde je to id_B jednako null, a tamo stoji zabrana za null. Dakle, prvo unesi vrednosti za primarne ključeve. A zatim za id_B treba da uneseš neku vrednost što postoji u primarnom ključu na koji se veže.

Potpis

Commercial-Free !!!

Nije mi jasno. Ako sam ja stavio da je u drugoj tabeli primarni kljuc identity i da ima inkrement zar ne bi trebao sam da 'prenese' vrednost u spoljni kljuc prve tabele (kolona id_B) koja se generiše kada se insertuje novi red ?

Kako to da uradim, da kada napravim join na vise tabela i kada zadam insert nad njima da sam server popuni spoljne kljuceve sa novim vrednostima primarnih kljuceva joinovanih tabela ?

Potpis

America national sport is called baseballs. It very similar to our sport, shurik, where we take dogs, shoot them in a field and then have a party.

Neće se spoljnji ključevi popuniti vrednostima u drugoj tabeli kada ubaciš vrednost u polje koje je primarni ključ u prvoj tabeli. Relacija će samo obezbediti da kada dodaješ zapis u spoljnji ključ, da ta ista vrednost postoji u primarnom ključu u drugoj tabeli na koju je povezan.

Dakle ako imamo tabelu A gde je polje UnosID primarani ključ:
UnosID
-------
1
2
3

i ako imamo tabelu B gde je polje UnosID_FK spoljnji ključ, povezan relacijom sa UnosID iz prve tabele:
UnosID_FK
-----------
2
2
3

Dakle, kada se ubacuju vrednosti u tabelu A, neće se automatski popunjavati spoljnji ključ u tabeli B, to nema smisla. ALI primeti, kada ubacujemo vrednosti u polje UnosID_FK, možemo da ubacimo samo broj koji postoji u UnosID u tabeli A.

Najlakše je ovo razumeti na principu narudžbenica. Recimo da knjižara Plato primi narudžbu od tebe za tri knjige. Prva tabela je ona gde imamo narudžbe, a druga bi bila detalji narudžbe.



Dakle, ovde gore imamo ID narudžbe i npr. adresu kupca gde se šalje.

U drugoj tabeli bi imali:

Kako vidimo ovde, narudžba broj 1 koja ide Marku, sastoji se od knjiga 2442 i 1123.
Narudžba broj 2 koja ide Peri, sastoji se od knjiga 3231, 74831 i 8271.

Primary key u relaciji je polje NarudžbaID iz prve tabele, a foreign key je polje NarudžbaID iz ove druge tabele dole. Primeti da u drugu tabelu ne možemo da stavimo Narudžbu broj 3 jer ne postoji u prvoj tabeli.

Ništa se ne "INSERT-uje" samo od sebe, podatke ubacujemo i u prvu i u drugu tabelu sami, a relacija će samo da osigura da ne ubacimo nešto u drugu tabelu što ne postoji u prvoj.

Eto.

Potpis

Commercial-Free !!!

Sada mi je jasno - mislio sam da MSSQL sam upisuje vrednosti primarnih kljuceva u spoljne, kao Access.

Hvala ti na strpljenu i pomoći

Potpis

America national sport is called baseballs. It very similar to our sport, shurik, where we take dogs, shoot them in a field and then have a party.

Hm, koliko znam, ni Access neće ništa sam da ubaci - nema to, jednostavno, smisla. Ono što može da se odradi i u jednoj i u drugoj bazi, a na šta ti možda misliš, jeste CASCADE UPDATE i CASCADE DELETE - a šta to već jeste potraži u dokumentaciji ili za Access ili MS SQL (Books Online).

Potpis

Commercial-Free !!!

Tja, nisam baš toliki početnik
Mogu da ti pošaljem jedan Access-ov .mdb koji ima Query i radi celu onu priču odozgo. Zato me MSSQL zbunio.
Sećam se da sa pre dve godine napisao svoju bazu za evidenciju MP3 muzike u VB i Accessu, i da je bilo više tabela, ali mislim da nisam pisao extra procedure za populaciju spoljnih ključeva.
Kada malo razmislim, zaista nema logike. Mozda zbog Accessovog VBA, mada sam samo napisao običan SQL upit ...

Potpis

America national sport is called baseballs. It very similar to our sport, shurik, where we take dogs, shoot them in a field and then have a party.

Access ume da prenese PK kao FK u child tabelu. Ukoliko su relacije setovane, a u programu upotrebljavas FormSubform, onda u Subform ne moras ni da prikazes FK polje, uvek ce da se prenese ispravna vrednost sa forme.

:-)

Čekaj komšo, kako može Access da zna koju vrednost iz primary key-a želiš da bude foreign key u drugoj tabeli? Moraš negde da mu kažeš koja vrednost primarnog ključa se prepisuje u drugu tabelu kao foreign key, zar ne?



Da, ali zar to ne znači da si u glavnoj formi izabrao zapis gde Access onda lepo može da vidi koja je vrednost primary key polja i onda samo izvrši odgovarajući upit u drugoj tabeli.

Ako imamo dve tabele (parent-child odnos):

i drugu child tabelu:

I ako sad pokušamo da ubacimo sledeći zapis u ovu drugu tabelu, koju vrednost će Access da stavi za UserID (može i 1 i 2 i 3, pošto te vrednosti stoje u prvoj tabeli na koju se ova veže)?

Što se pregleda podataka tiče opet moramo da znamo koja je vrednost UserID ako nećemo da se prikažu sva polja, npr:

SELECT prva.*, druga.* FROM prva, druga WHERE prva.UserID = druga.UserID AND prva.UserID=2;

Ne znam kako drugačije može da zna, a ako mu mi nekako ne kažemo, koja je vrednost UserID prema kojoj vrši upit?

P.S.

Ma nemoj uopšte tako da shvataš, pričamo i razmenjujemo iskustva i slično - svako će ponešto da nauči. Pozdrav :)

Potpis

Commercial-Free !!!

U principu izbegavam programiranje u Access-ovom VBA, u stvari izbegavam sve gde se pominje Visual Basic sem kada muka natera Taj programčić sam radio u VB6 i prenošenje vrednosti iz PK u FK je lepo radio. Zapravo sam Query (kao što je po MSSQL-om View, da nebude zabune) je posle insertovanja novog recorda prebacivao vrednost iz PK u FK !



Da, u pravu si ! Ako nekazes preko nekog listbox-a ili slicno koju vrednost trazis u drugoj tabel on ne moze znati sta da stavi u FK. Ja sam napravio ovde zabunu Nisam dobro objasnio situaciju. Drugar mi je savetovao da ako imam veliku tabelu, da je izdelim na par manjih po nekim logičkim celinama, i da relacija bude jedan-prema-jedan. Tako kada se insertuje novi record u prvoj tabeli, u drugim tabelama se isto pravi novi record i njihovi PK se šalju prvoj tabeli.

E sada, koliko je to pametno uraditi ? Mislim, samo sebi komplikujem stvari, ali mi je drugar objasnio da MSSQL tada 'bolje/brze' radi ?!



Daleko o toga da sam se uvredio ili slično, baš naprotiv

Potpis

America national sport is called baseballs. It very similar to our sport, shurik, where we take dogs, shoot them in a field and then have a party.

Ej, nisam mislio nista ruzno. Access i VB rade drugacije. U VB sve mora da se programira i interfejsi tipaForma-Subforma nisu bas jednostavni. Access nije 100% programski jezik, nego je delom i interaktivno okruzenje. U to interaktivnom okruzenju postoji jedna struktura koja se zove forma sa subformom. Kad se subforma nanese na formu ond se definise veza izmedju njih kao Parent Field (forma) i Child Field (subforma). Od tog momenta sve i da hoces ne mozes da uneses u subformu u vezno polje nista drugo nego PK sa glavne forme. Forma/Subforma se prave za key entry i normalno je da user ne zeli da prekucava PK sa glavne forme u subformu. Nema koda, nema kverija, nema nista - zato kazem da u Accessu moze da se izvede unos FK automatski u child record, pod odredjenim uslovima <=> (koriste se forma i subforma, gde je forma Parent a Subforma je child). Forma i subforma ne postoje u VB, nego mora da se simulra taj efekat na neki drugi nacin, i onda stoji sve sto ste kazali - mora da se programski obezbedi da child tabela dobije korektnu vrednost u FK polju.

Samo razmenjujemo misljenja, ovo ionako ne resava covekov problem - "zasto ne radi u MySQL nesto sto radi u VB"

Srecna nova godina.

:-)