Referential integrity kod više backend baza

znam da je nemoguce, ali kako naci pametno resenje.

primer:

firma ima trgovinu koja je smestena u jednu BE bazu, usluge koja su smestene u drugu BE bazu i knjizenja koja su smestena u trecu BE bazu, u koje se upisuju podaci iz prve dve baze, ili se podaci unose u tabele.

logicna veza izmedju ovih baza je tabela poslovni partneri, koja se nalazi u bazi knjizenja.
sve je u redu dok nekom ne padne na pamet da promeni ime poslovnog partnera (razloge necu navoditi).

promena naziva se oslikava na sva knjizenja, ali se ne oslikava na unete racune, kalkulacije,...

hvala na mozganju :)

mislim da ti je resenje problema u modelovanju baza. Vodi racuna da se podaci ne cuvaju na dva mesta nego samo na jednom a na ostalim bazama ih linkujes. Tada bi trebalo da promene nekoj tabeli budu "vidljive" i u ostalim bazama

i podesi ko sme da menja pojedina podatke

baza je sada na taj nacin modelovana...

Slažem se sa kolegom maliradoznalac po ovom pitanju. Suština je dobro izmodelovana baza. Jedinstvenost podatka morala bi da se napravi nad samom strukturom podataka. Jedno od intresantnih rešenja sam video u Upravi carina i često ga primenjujem prilikom modelovanja, a to je da se uvedu govoreći ključevi, gde bi jedna od informacija bila mesto nastanka n-torke. Ovo se odnosi na one entitete koji predstavljaju dinamiku sistema (npr. Faktura, Otpremnica, RadniNalog ...), dok entiteti koji predstavljaju statiku sistema (npr šifarnici JedinicaMere ...) morali bi biti jedinstveni (nove n-torke moraju nastati na jednom mestu) s time da se definiše procedura na koji način bi se vršila distribucija, ako ne postoji lokalna mreža.

Potpis

http://zoraneremija.wix.com/eremijacv

Ne znam koliko ste upuceni u problematiki racunovodstva, ali mislim da obojica predlazete resenja koja su u racunovodstvu nemoguca.

Baza knjizenja postoji iz razloga sto jedna firma moze imati npr.

vise maloprodaja
jednu veleprodaju
proizvodnju ...

Iz toga razloga su baze odvojene po prodajnim mestima (objektima) koja se mogu otvarati ili zatvarati. Nacin vodjenja pojedinih evidencija za pojedine vrste delatnosti, se bitno razlikuje pa je zbog toga mnogo lakse odrzavati tako razdvojene baze.

Baza knjizenja je i tu zbog zakljucnog lista, zavrsnog racuna, ...

Sve promene koje se evidentiraju u maloprodaji, veleprodaji ... moraju biti na jednom mestu to jest u bazi knjizenja, da bismo imali uvid u recimo karticu kupca koji je dobra kupio i u maloprodajnim objektima, i u veleprodaji pa i u proizvodnji. Sve je u redu sto se tice knjizenja kada pogledamo njegovu karticu, jer su baze MP, VP, proizvodnja.. linkovane na tabelu poslovni partneri koja se nalazi u bazi knjizenja. Kada se desi promena imena tog poslovnog partnera, nastaje problem jer se njegovo ime ne menja u fakturama koje su kucane na prodajnim mestima. To je jedini problem u ovako modelovanoj bazi na koji sam naisao i koji pokusavam da resim.

Pozdrav.

Ako dobro izmodelirate tj. preslikate realni sistem nema nemogućih rešenja. Često je na svojim predavanjima, nažalost sada pokojni prof. dr Branislav Lazarević sa FON-a govorio.

Potpis

http://zoraneremija.wix.com/eremijacv

Mislim da su kolege maliradoznalac i Zoran.Eremija u pravu. Greška je u modelovanju baza. Ne može se jedan entitet tipa šifarnik partnera dodeliti na upravljanje svim korisnicima. Dakle, na korišćenje da, putem linkovanja ali unos novih i ažuriranje se mora vršiti sa jednog mesta.

Pokušaj da u kontekstu ovog gore, organizuješ rad u firmi tako da za početak prepraviš forme i zabraniš da svako može da ažurira poslovne partnere. Usredsredi se na davanje i oduzimanje privilegija korisnicima.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

@ zeppelin

na osnovu evidencije se i modeluje baza, odnosno na osnovu podataka koje je potrebno evidentirati. Tako da razlicite evidencije ne podrazumevaju razlicite baze podataka.
Nemoj da posmatras maloprodaju, veleprodaju i ostale delove kao posebne celine. Bazu modeluj kao jedan veliki sistem, sto u tvom slucaju u stvari i jeste jedan veliki sistem, sudeci po tvom opisu. U tom sistemu mozes imati samo jednu tabelu u kojoj evidentiras npr poslovnog partnera. Gde ce se ta tabela fizicki nalaziti nije toliko bitno. NA jednom racunaru je fizicki a na ostalima se linkuje. Vodi racuna da je ne importujes nego linkujes.
E sad, ako imas problem sa uspostavljanjem veze izmedju racunara u razlicitim delovima preduzeca onda moras da napravis glavnu bazu na jednom mestu a na ostalim da pravis privremene kopije tabela koje ce se kasnije sinhronizovati sa glavnom bazom. Ovo moze napraviti velike probleme ako se ne podesi ko i na kom mestu ima privilegije za dodavanje, ko za izmenu i ko za brisanje.

Ili možda ti ne shvataš šta je sve moguće uraditi u Accessu kada se pravilno modeluje baza?
Nevolja sa većinom računovodstvenih programa je što vuku neizlečivo genetsko nasleđe "dBase-Clipper-Fox for DOS", gde je razmišljanje o postavkama baze bilo ograničeno pomenutim programima.

Potpis

The 11th Hour: The forces blocking change

U svom trecem postu samo sam zeleo da problem jos vise priblizim stvarnoj situaciji, posto ocigledno nisam do kraja objasnio problem, ili me oni koji su pokusali da pomognu nisu razumeli. Ako se procita prvi post vidi se da pominjem backend, sto znaci da koristim i frontend na nacin na koji je maliradoznalac u predposlednjem postu delimicno shvatio, ali mi u tom postu govori i da vodim racuna da linkujem a ne da importujem tabelu. Takodje pominjem i vise objekata koji se ne nalaze fizicki na istom mestu, tako da je nemoguce da se sa jednog mesta unose poslovni partneri, jer bi u tom slucaju proces izdavanja racuna predugo trajao. Delovi firme se moraju posmatrati kao odvojeni sistemi jer se i kontrola inspekcija i evidencija odvojeno vrsi. Po meni je takvu bazu i jednostavnije odrzavati...

Problem sam u medjuvremenu resio. Problem je bio delom u nepravilnom modelovanju, na koji ste me sve vreme upozoravali.

U svakom slucaju zahvaljujem se malomradoznalcu, Getsbi-ju, Zoran.Eremiji, koji su imali dovoljno vremena i volje da pomognu u resavanju problema, sto se za gospodina Catch 22 ne bi reklo zbog malicioznog odgovora. Ako neko nema nameru da pomogne, zbog cega ovaj forum ovako dugo i postoji, ne znam zasto ima potrebu da napise bilo sta.

^ Zašto misliš da sam želeo da budem maliciozan?
Moja namera je bila samo da iniciram nekakvu promenu načina razmišljanja oko osnovnog koncepta Access baze.
Izgleda da je nažalost bila pogrešno shvaćena...

Mislim da i dalje negde grešiš u koncipiranju relacione baze, sudeći bar po ovom delu tvog komentara:

Svaki poseban entitet iz stvarnog života je moguće unikatno identifikovati u dobro postavljenoj bazi, što onda omogućava i specifičnu obradu podataka (po potrebi) samo za taj entitet.
Al' i nemam ništa protiv ako ti smatraš da grešim i da je tvoj način bolji.

Potpis

The 11th Hour: The forces blocking change