Nakacio sam Vam primer Fakture. Sustina je da se napravi Query QFaktura koji u sebi sadrzi i tabelu Dokument i tabelu Faktura. Buduci da je ako ste videli u modelu entitet Faktura specijalizovan entitet od Dokumenta veza izmedju Dokumenta i Fakture je 0-1 Vrsta dokumenta je entitet koji sluzi da se po njemu vrsi diskriminacija i u ovom slucaju atribut VrstaDokumentaID u entitetu Dokument je Diskriminator i on predstavlja matematicki operator "ili", sto znaci da je neki dokument ili Faktura ili Putni nalog ili ...
U formi Faktura videcete da je RecordSouce u stvari Upit ili Query QFaktura, takodje polje FakturaID namerno sam ostavio da se vidi kao i polje VrstaDokumentaID i jedno i drugo polje moraju imati default vrednost s time sto je u polju VrstaDokumentaID vrednost ona koja je adekvatna vrednosti iz tabele VrstaDokumenta, a u polju FakturaID upisite bilo kuju vrednost zbog veze koja je napravljena sa osobinom Cascade Update cim se dodeli vrednost DokumentID automatski se dodeli i vrednost FakturaID.
Ovo je klasican primer Generalizacije i Specijalizacije kao tipa veze.
Na isti nacin cete odraditi i ostale slucajeve, kao i za Partnera s time sto za partnera imate primer Fakture dat na ovom forumu
http://www.elitesecurity.org/t401604-Neaktivni-artikli-bazi
Nisam se bavio fizickom strukturom baze zato su svi tipovi podataka Text(50)