Budi bez brige, takve kardinalnosti ne treba da postoje, nemaju smisla, pa nema sta de se 'prevodi'. Mozes li da zamislis neki primer gde bi recimo zahtevana kardinalnost 3:3 ili 5:7 - za 5 soba mora da ima 3 kupatila? Sta fizicki znaci 0:9 - za nula narudzbi zahteva se 9 stavki? Ono sa sobama i kupatilima deuje jos i razumno: na svakom spratu, treba da bude 5 soba i tri kupatila. Ako stavis Sobe:kupatila dobijes 5:3, ali to nije ispravno. Treba reci spast:sobe = 1:5 AND sprat:kupatila = 1:3

Sve sto treba da znas je:
1:M, ciji je specijalni slucaj 1:1;
i
M:M koje moras da naucis da prevedes u dve veze 1:M i 1:N

U svakom slucaju, kljucevi se prenose sa strane 1 na stranu vise.

Jedna vazna primedba: ni jedan danasni sistem (ORACLE, SQL Server, DB2...) nije potpuno relacioni. Svi imaju slabost kod obavezne kardinalnosti. Na primer, lako je postici da 'stavka' ne moze da postoji bez 'narrudzbe'. Medjutim, ako zahtevamo da 'svaka narudzba ima bar jednu stavku', nema jednostavnog nacina da se to garantuje u danasnjim sistemima za obradu baza podataka. Taj do s elako nacrta u E-R dijagramu, ali se tesko primenjuje. Sledi da se ne moze bas sve sa dijagrama prevesti u fizicki projekat baze.

E-R dijagram je samo jedan nacin da se graficki opisu (nacrtaju) zavisnosti ismedju entiteta, ili, jdan nacin da se recenice koje opisuju veze izmedju entiteta 'napisu' pomocu simbola. Kasnije svaki entitet postaje relacija (tabela), i medju nekim relacijama se postavljaju FOREIGN KEY ogranicenja.

Tehnika crtanja E-R dijagrama razvijena je nezavisno od relacione teorije, priblizno u isto vreme. Kad je E. Codd, otac relacione teorije, saznao za E-R dijagrame, bio je zestoko protiv tehnike, ali je kasnije priznao da E-R dijagrami dovode brze do nekkave sheme baze podataka, brze od teorijskog postupka normalizacije. Razlog zasto je Codd bio protiv E-R dijagrama jeste sto E-R dijagrami pokazuju samo jedan deo ogranicenja i pravila koja mora da zadovolji relaciona baza. Uz to, E-R dijagrami vaze samo za staticne slucajeva, ne mogu se uspesno upotrebiti kada je proces koj baza treba da podrzi dinamicki. Pravcenje bilo kakvih promena ne moze se na zadovoljavajuci nacin prikazati E-R dijagramima. Posto je vecina realnih problema dinamicka, upotrebljivost E-R dijagrama se ozbiljno dovodi u pitanje. Na primer, kako u E-R dijagramu prikazati uslov da 'knjiga koja je pozajmljena iz biblioteke ne moze imati datum vracanja pre datuma pozajmljivanja'. U bazi jednostavno postavimo CHECK CONSTRAINT, ali to ne mozemo prikazati na E-R dijagramu. Niti mozemo da pokazemo u E-R dijagramu da knjiga koja je oznacena kao izgubljena ne moze vise da se dodeli ni jednom clanu biblioteke.

Praksa je pokazala da je Codd bio u pravu. Vecina ljudi nauci da nekako nacrta E-R dijagram i na osnovu toga napravi tabele i postavi FOREIGN KEYs, i tu se stane, gotov posao. Crtanje E-R dijagrama se izjednacuje sa projektovanjem baze podataka (database design), sto je nepravilno i opasno. Ako prihvatiom da je crtanje E-R dijagrama sve sto nam treba, pravimo dvostruku gresku. Prvo, slika sistemna koju daje E-R dijagram nije kompletna jer predstavljamo samo jedan tip ogranicenja, a sve ostalo se zanemaruje. Drugo, sve sisteme tretiramo kao staticne, iako to nisu, samo zato sto imamo lep alat, E-R dijagram, pa ga primenjujemo i gde treba i gde ne treba. Ako imas cekic, pa ti sve izgleda kao ekser, nesto nije u redu. A i opasno je.

Ovo naravno ne znaci da su E-R dijagrami losa tehnika, zanci samo da tu ne treba stati, ima jos mnogo toga sto se mora nekako predstaviti na papiru pre nego sto se predje na 'prevodjenje u fizicku model'.





Ali, teorija je teorija, a praksa je praksa, pa makar bila i pogresna.

Samo da dopunim Zidarevo izlaganje. Iako će ti retko trebati, skoro da se i nećeš susretati u praksi.
U teoriji postoji kardinalnost One (No Nulls) to Exactly n.
Primer: Jedno ODELJENJE može ili mora da zapošljava tačno (Exactly) n OSOBA. Ne više.
Ipak, ko što reče Zidar, "Sve što treba da znas je:......"

Getsbi je 100% u pravu. Kako u teoriji, tako i u praksi, postoje slucajevi 1: (tacno N), ili 1: (barem N) Na primer zahtev je "faktura mora da ima barem jednu stavku, faktura sa 0 ne sme da postoji" - trazi se 1: (1 ili vise). Problem je sto za sada, ni jedan komercijalni RDBMS ovo ne podrzava.

Tu je cak i teorija na klimavim nogama. Zbog FK, uvek mora da postoji Faktura pre nego sto postoji Stavka. Znaci, Faktura = 1 i broj stavki = 0, barem na trenutak. Zahtevati da u istom trenutku postoje i Faktura i Stavka u suprotnosti je sa zahtevom da prvo postoji Faktura. Mora da se desi
INSERT INTO Fakture (FakturaID)
pa tek onda
INSERT INTO Stavke (FakturaID, StavkaID, ArtiklID, Qty...)

Zahtev da UVEK postoji bar jedna stavka ako postoji faktura ne moze da se ostvari zato sto PRVO mora da postoji red u tabeli FAKTURA.

O ovome se uveliko raspravlja u krugovima koji definisu SQL standard i za nekoliko godina moguce je ocekivati nekakvo resenje i u praksi. To se naziva DEFERRED TRANSACTION RESOLUTION. Dozvoljava se (i zahteva) da se prvo uradi INSERT INTO Fakture, ali se transakcija ne potvrdjuje dok ne odradimo i INSERT INTO Stavke. Nesto slicno vec postoji u MS SQL 2008, naredba MERGE kojom se u jednom prolazu radi INSERT i UPDATE. Naravno da se fizicki prvo radi jedna pa druga operacija, ali to sistem sakriva od nas. Za sada u praksi, ovo se resava tako sto se zabrani svim korisnivima INSERT INTO za Fakture i Stavke. Onda se npravi stored procedura koja prima listu stavki kao parametar, i onda prcedura odradi celu transakciju. Ako je lista stavki prazna, ili taj INSERT ne uspe, radi se ROLLBACK za celu transakciju. Pomenuta procedura jedino ima pravo da dodaje redove u nase Fakture i Stavke. Generalno, dobra je praksa da samo odrdjene procedure imaju pravo da menjaju podatke.