Pomoć oko dizajna baze

Pozdrav svima,

molio bi za pomoć vezano za ovaj primjer ali posmatran sa strane stolara.

Nešto razmišljam ovako, kada škola pošalje neki stol u stolariju da se popravi nameću se tu neke tabele ali mi problem predstavlja kako locirati pravu tabelu od koje posmatramo događaj.

Imao bi tabele:

stolar (ime i prezime: marko marković, petar petrović)
stolovi (proizvodni broj: 1234, 2345)
servis (datum servisa, usluga, odgovorna osoba škole koja potpisiva tu uslugu: 22.2.2018, poliranje i bojenje, direktor škole Nikola Šop)
škola (id broj, naziv, odgovorna osoba: 1234567890123, oš Branka Ćopića, direktor škole Nikola Šop)

Ovdje gledam ovo sa strane stolara pa ne mogu da shvatim da li je stolar glavna tabela ili servis? Molio bi nekoga da mi ovo pojasni.

Na netu sam našao i ovaj primjer sa slike:



pa mi nije jasna ova veza manufacturer - model - car.

Kako je ispravno razmišljati kada su baze u pitanju ili da auto ima više modela ili da model ima više auta???

Ili još jedna kombinacija da proizvođač ima više modela koji opet imaju više auta???

Hvala Vam puno na strpljenju i pomoći.

lp

U konkretnom slučaju oko automobila, odgovor bi bio da proizvođač proizvodi više modela automobila i to svaki model u više tipova, u ovom slučaju tabela (Car), koji se mogu razlikovati po vrsti ugrađene opreme, boji itd.

Potpis

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

Na konkretnom primeru koji si postavio u pitanju je rent-a-car agencija.
Car je tabela gde se za konkretan automobil čuva registarski broj, kilometraža itd.
Model sadrži naziv modela, šifru modela i cenu dnevnog najma. Na primer, rent-a.car ima 10 automobila Opel Insignia (svi imaju drugačiju kilometražu, registarsku tablicu), ali postoji jedan slog u Model jer jer cena iznajmljivana na nivou modela, a ne pojedinačnog automobila.

U tabeli Manufacturer (koja je potpuno nepotrebna u postojećem modelu) nalaze se podaci o proizvođaču automobila, recimo Opel, Mercedes, Fiat. Ovo bi imalo smisla, kada bi, recimo, postojali ovlašćeni servisi, pa da znaš kod koga da šalješ na servis.

Pozdrav svima,

molio bi pojašnjenje vezano za slučaj ako imamo više proizvoda, koje treba sačuvati u bazi, sa različitim imenima polja (field name) na koji način se to ispravno uradi?

Gledao sam neke primjere pa u prvom slučaju ako sve ostavimo u jednoj tablici pojavljuju se previše null vrijednosti (previše null vrijednosti - ne znam koliko je to općenito dobro kod baza?!), drugi slučaj da se u tablici product ostave zajednička imena polja a ostala da se prebace u tablicu productdetail pa sve do toga da se ti detalji postavljaju pojedinačno po tablicama (detaljna razrada).

Ako možete da navedete neki jednostavan primjer i pojasnite ova tri slučaja kad je šta dobro.

Hvala svima

Upravo tako. U jednoj tabeli cuvas podatke koji su zajednicki za sve proizvode, a onda zasebne tabele u vezi 1:1 za svaku grupu proizvoda sa poljima koja su specificna samo za tu grupu.
Na primer tabela prevozna sredstva sa podacima koji se vode za sva sredstva, a onda u vezi 1:1 tabele Putnicka, Motocikli, kamioni...
sa podacima koji su specificni za pojedinu grupu. Ima dosta primera na forumu, ali trenutno ne uspevam da nadjem ni jedan reprezentativan

Znači veza je 1:1 prevozna sredstva : putnička, motocikli, kamioni...

Pošto su polja različita za te detalje kako se rješava forma za unos kada se unosi novo prevozno sredstvo?

Da li tu ima neki combo box ili nešto drugo što će pozvati neku formu ili subformu samo za to prevozno sredstvo, neki vb kod?

Ili jednostavno napraviti cijeli popis pa popuniti samo neka polja (zajednička) i ovisno od detalja nekog prevoznog sredstva?

Ima vise nacina. Na primer forma i podforme sa svojstvom visible na false, pa kad na formi izaberes vrstu iz comba automatski postaje visible odgovarajuca podforma. Nemam sad vremene, ako stignem postavicu veceras

Hvala puno Dexxxl.

Svaki primjer je dobro došao jer vizualno mogu vidjeti kako to izgleda a to mi je puno zgodnije nego kad je opisno.

Mislio sam da je ovo jednostavnije ali kako napredujem sve više se divim ljudima od struke, koje znanje treba imati da se čovjek uhvati u koštac s ovim.

Malo kasnim, ne stizem zbog obaveza, sto poslovnih, sto kafanskih :)
Evo dva primera

Hvala puno Dexxxl.

Nije ništa od glavu, kafanske obaveze se ne smiju propuštati. :)

Pozdrav svima,

u slučaju da ne koristimo za PK autonumber tip podatka nego neki drugi kako možemo postaviti provjeru unosa da nas access upozori da u bazi već imamo unešen taj podatak?

Za ispitivanje i proveru unesenih podataka i dobijanje poruke na ekranu u vidu: „Ovaj zapis već postoji” treba će ti poznavanje VBA programskog jezika. Evo nešto slično što kod mene radi u jednoj aplikaciji.

Potpis

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

Pozdrav svima,

zamolio bi iskusne kolege za jedno pojašnjenje vezano za dobavljače i kupce.

Primjetio sam da se koriste dvije varijante:

1) Podaci o dobavljačima i kupcima idu u jednu tabelu.
2) Podaci o dobavljačima i kupcima idu u dvije tabele (tabela dobavljač i tabela kupac).

Pošto ovo ne razumijem najbolje možete li mi reći koje su prednosti i nedostaci ovih varijanti.

Gledao sam Northwind bazu podataka i u njoj se koristi varijanta broj 2 (posebno dobavljači, posebno kupci).

lp

Ako ti jedan klijent nikada neće biti i kupac i dobavlač onda mogu dve tabele. Ako klijent može da bude i kupac i dobavljač onda u jednu.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Kada bi postojalo rešenje koje je uvek bolje, onda bi svi radili na taj način.
Nekako, krećeš iz sredine.

Zamisli da imaš situacije:
1. Ogroman broj kupaca, mali broj dobavljača (zamisli, na primer telekom firmu, imaju stotine hiljada "kupaca" a samo nekoliko stotina dobavljača. Šta bi bilo da se i kupci i dobavljači drže u jednoj tabeli. Zamisli situaciju da treba da napraviš izveštaj o dobavljačima, a u tabeli ti je samo jedan procenat slogova ili manje vezan za dobavljače).
2. ogroman broj dobavljača a mali broj kupaca (na primer fabrika automobila sa hiljadama kooperanata, a imaju samo veleprodaju koja ima nekoliko dsetina auto-kuća koje su kupci, pa dalje plasiraju u maloprodaju).
3. postoji umeren broj i kupaca i dobavljača i većinom se pojavljuju i kao kupci i kao dobavljači.
4. postoji puno kupaca dobavljača, ali se uglavnom javljaju ili kao kupci ili kao dobavljači.

Možda o kupcima imaš malo podataka, a o dobavljačima znatno više. Da li onda gurati mnogo NULL polja u jednu tabelu koja je zajednička za kupce i dobavljače?

Dizajn tabele je rezultat sistem analize i ne postoje unapred najbolja rešenja za svaku moguću situaciju.

Dobro de ne treba preterivati, čim Carduel ovo pita sigurno se radi o nekom jednsotavnom slučaju.

Čak i kada je složen, nema razloga da se redudatno uinosi isti komitent dva puta. Problem raznorodnih podataka zavisno od tipa komitenta se rešava odvahanjem speicičnih podataka za svaki ti u posebne table a a srodni podaci se ostavljaju u osnovnoj tabeli. Kada ti trebaju podaci o kupcima onda uzmes osnovu tabelu i povezes je sa tabelom sa podacima o kupcima. Kad ti trebaju podaci o dobavljacima ,onda, opet, uzmes osnovnu tabeli i povezes je sa tabelom sa podavima o dobavljacima.

Ako je baza baš tolika da i filtiranje po tipu predstavlja zahtevan posao onda radis nemarnu redundansu u neke privremene tabele da izbegnes cesto filtriranje.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Naravno da se slažem sa tobom, Peđa.
Možda nisi čitao od početka ovu temu, ali je postavljač krenuo sa primerom stolarske radnje, čiji su dobavljači fabrike i radionice za izradu nameštaja, a kupci proizvoda i usluga škole.
U ovom slučaju, praktično se nikada jedan entitet neće naći u ulozi i kupca i dobavljača.

Naravno, neke zajedničke podatke može držati u istoj tabeli, ali ima smisla razdvojiti specifične uloge u dve tabele.
Inače, kada sam rekao da kreće iz sredine, ovo nije prvo takvo pitanje, pa sam zato to spomenuo. Već je bilo pitanja, tipa šta je bolje da li ovo ili ovo, a da nije opisan konkretan problem.
Zato mi se čini da Carduel ima pogrešan utisak da postoje neki trikovi i prečice u dizajnu baze, a da nije svestan procesa sistemske analize.

Ovde se na mnogo mesta mogu naći pitanja tipa: Zašto mi je ovaj upit spor?
Na to svi graknu, zato što je dizajn loš (što je najčešće tačno). A odgovor na pitanje: Šta je dobar dizajn, može biti vrlo jednostavno - to je takav dizajn gde se rezultati upita dobijaju brzo.
Ne pravi se dizajn baze po nekakvom šablonu, već se pravi na osnovu pretpostavke na koji se način koriste podaci iz baze, koji su potrebni izveštaji, koje su procedure, kako se kreću informacije kroz firmu i koje su to informacije, pa se na osnovu toga modeluje i baza.

Hvala Vam na odgovorima, meni i jeste najveći problem što ne razumijem tu logiku stvari pa nemam pojma odakle bi krenuo. Najviše me rasturi često korišten termin u prepisci a to je: "koristi se ovisno od situacije" i onda sam donji 100%. :D

Ovo je pitanje nevezano za moju temu nego me zanimalo pošto je kolega napravio nekakve 3 tablice i dobavljače i kupce strpao sve u jednu.

A pošto nemam pojma o tome ako možete još koju rečenicu da napišete o ovome.

1) Da li Null vrijednosti usporavaju upite, izvještaje, ...?
2) Evo tek sad primjetih da se podaci dupliciraju ako su dvije tablice a jedna je firma i dobavljač i kupac.

Nekako mi se čini da je previše ovoga tipa može i ovako a može i onako, a može i ....

Hvala još jednom.

Pa izdvojis info i stavis samo id u te dve tabele. Usteda sa dve tabele je u tome sto ti ne treba uslov vise. Ne znam koliko imas tih stvari i koliko su ti slozeni upiti...

Ma to su klasični slučajevi, nešto malo dobavljača cca 5 - max 20 i veći broj kupaca što fizičkih što pravnih osoba.