» »

ER diagram Pregled/Pomoc

ER diagram Pregled/Pomoc

lurker1359 ::

Hi,
izdelal sem ER model, zdaj me pa zanima vaše mnenje če je zadeva vredo?
 ER model

ER model



Zanima me naslednje:
1) Bi moral entiteto datum in leto zdruziti v eno i nuporabiti atribut date? -ampak potem imam med krajem in datumum razmerje mnogo-mnogo in ne vem kako bi to drugače rešil.
2)Bi v entiteti SHRAMBA moral ime shrambe izpeljati ko posebej entiteto?
3)Vaše splošno mnenje kaj se vam zdi vredo in kaj naj spremenim?

Za vaša mnenja in nasvete se vam že v naprej zahvaljujem!

z3ro ::

Kolikor se spoznam na ER diagrame mislim da je tole čist napačno zastavljeno. Zakaj imaš vse atribute entitete Kamnina v posebej entitetah? Velikost, teža, oblika, vrednost,... so atributi kamnine. Datum in leto pomoje ne sodita med entitete. Pred entiteto Kraj pride še entiteta Naslov. Naj še kdo pokomentira sam tole je pomoje bolj bogo.

lurker1359 ::

Z entiteto KRAJ si zabeležim samo v katerem kraju je kamnina bila najdena tako da mislim da ne potrebujem še entitete NASLO, ali pač?
-Čet dam vse kot atribute potem ima zelo malo entitet :S (mislim da je beil orečeno, da se lastnosti, tipi, vrste zapišejo kot nove entitete...)
Upam da še kdo odgovori :)

epicVoid ::

Zero ti je že povedal, da zapiši velikost, teža in oblika kot atribute entitete Kamin.

Kraj ima atribute kot so: mesto(ime mesta), poštna številka, medtem ko naslov ima atribute, kot so: ulica, hišna številka.

z3ro ::

Tip se zapiše v novo entiteto, ja. Vse te lastnosti kamnine pa zagotovo ne. Par dodatnih entitet boš še moral najt.

lurker1359 ::

OK, sem malo popravil zadevo
 model

model


Pri kraju sem dodal LOKACIJO aka NASLOV, ampak, kako bi dodal datum? -kar med atribute kamnine (kdaj in kje je bila kamnina najdena)
-Ali je del s ceno za kater je bila prodana in komu je bila prodana v redu?

Za lažje razumevanje so tukaj (na hitro) zahteve naloge:
Zbiratelj kamnin, ki hoče imeti seznam vse kamnin ki obstajajo, koliko ima posameznih primerkov (in njihove lastnosti), kje in kdaj jih je našel, kje ima shranjene. Zapisane ima cene, ko pa jih proda si zabeleži za koliko in komu jih je prodal...

FTad ::

Ni mi jasno, zakaj si posebej delal entiteto: zaporedna številka, pa potem še pripadajoč ID. Jst bi to dal kar v entiteto Kamnina. Prav tako bi dal ceno kamnine v entiteto Kamnina.

Entiteta Shramba bi imela atribute: ID, ime_shrambe, tip
Entiteta Primerek: ID, ime, količina

Prav tako mi ni jasno, kaj bi ti vpisal pod lokacijo in potem še posebej kraj. A to naprimer Dolenjska in potem kraj npr Novo mesto?

lurker1359 ::

Hotel sem malo pridobit entitet, ker ne vem kaj naj še dodam, ker potrebujem vsaj 15 entitet... in če vse to dodam kot atribut, mi jih potem ostane bolj malo...

Recimo da tako, LOKACIJO sem dodal vmes, ker če ne je relacija med KAMNINA in KRAJ mnogo-mnogo, kar pa ni vredo :)

FTad ::

Jah, malo slabo si si zamislil, kaj bi vzel za bazo. Zakaj ravno kamnina? Daj raje kaj drugega

pogooglaj po netu, kaj bi lahko dal

lurker1359 ::

NIsem si sam izbral, saj to je problem...

lurker1359 ::

Bi se našel kdo ki bi mi malo pomagal to narediti, ker je čudna tema (ne vem kaj bi še lahko dodal za entitete) in se že malo zgubljen... :S

lurker1359 ::

OK, malo sem pogooglal, pregledal še kr nekaj er-modelov, in malo popravil in dodal svojega, upam da je vredo :)
 ER model

ER model


Kaj pravite zdaj? -Kaj bi še dodali za entitete? -Kaj bi spremenili?

epicVoid ::

- Stranka - Račun = 1 proti mnogo, ker račun zagotovo pripada 1 stranki.
- Nevem zakaj si povezal Kamnina - Postavka ?
- Cenik verjetno tudi ne obstaja, če kamnina ne obstaja, tako da ne vem zakaj opcijska relacija.
- Isto Kamnina - Lastnosti.... Kako si lahko neka lastnost "lasti" nobeno kamnino (200kg megle?) Ni logično ne ?
- Zakaj zaloga? Kaj je to ?

lurker1359 ::

-Kamnina postavka, zato ker če kupiš več kamnin iste vrste (recimo granit) imajo isto ceno in posledično daš ceni krat kolicina ki je v psotavki
-Zaloga? koliko je določenih artiklov (kamnin) na zalogi(v shrambi)

fosil ::

Briši zbiratelj, to je že stranka.
Zakaj ima kamnina id in še zaporedno številko?
Naslov gre pod stranko.
Lastnosti gredo pod kamnino.
Pa odloči se kaj naj bi predstavljala kamnina. Unikatne kose kamnin ali neke vrste razsute zadeve v stilu premoga.
Tako je!

lurker1359 ::

fosil je izjavil:

Briši zbiratelj, to je že stranka.
Zakaj ima kamnina id in še zaporedno številko?
Naslov gre pod stranko.
Lastnosti gredo pod kamnino.
Pa odloči se kaj naj bi predstavljala kamnina. Unikatne kose kamnin ali neke vrste razsute zadeve v stilu premoga.


Zaporedno stevilko sem dodal ker je v navodilih, da si zbiratelj beleže zaporedne številke primerkov.

-V bistvu nisem povsem prepričan kako se naj lotim zadeve, ker moram imeti seznam vse kamnin in njihovih lastnosti, potem pa moram še voditi katere kamnine imam in katere ne in katerih je na zalogi več primerkov (vsak primerek pa ima zaporedno številko)

Zbiratelj kamnin želi informatizirati svojo zbirko. Tako želi imeti podatke o vseh kamninah, ki obstajajo. Od določenih kamnin ima tudi enega ali več primerkov, določenih kamnin pa še nima. Za primerke si zapisuje zaporedno številko, velikost, obliko, težo, čistost in ostale podatke, ter lokacijo, kje jo je našel in kdaj. Primerke ima shranjene na različnih mestih (polica, omara, soba), kar si seveda prav tako beleži. Primerke kamnin tudi prodaja drugim zbiralcem. Tako ima za vsako zapisano vrednost, za katero jo želi prodati. Ko jo proda, si shrani dejansko vrednost, za katero jo je prodal ter komu jo je prodal. Tako hrani podatke tudi o že prodanih kamninah.

fosil ::

Jaz bi potem naredil entiteto kamnina in entiteto recimo vrsta_kamnine.
Tako je!

lurker1359 ::

Ok, sem malo spremenil:
 model

model


Bi bilo to malo bolj smileno?
-NIsem bil povsem prepričan, če je vredo da sem zalogo koliko je primerkov izpeljal iz same vrste, je vredo tako kot imam?
-Nadaljne kritike in nasveti so dobrodošli :)

bajsibajsi ::

Meni osebno se taka sestava baze zdi precej slaba - prevec povezav tabela, na tabelo, na novo tabelo... Baza mora biti pregledna, ucinkovita in hitra. To kar ti delas, je precej mala baza; predstavljaj si, da bi delal ogromno bazo in z njo upravljal. Ravno tako mora biti "avtomatiziran" prenos med logicnim podatkovnim modelom (ER) in relacijskim podatkovnim modelom. Vse to ti Oracle DataModeler, v katerem delas, omogoca.

En moj primer (ne ravno dober, ampak na tej masini nimam baz)

lurker1359 ::

Zgledoval sem se po primerih iz šole (kjer je bil način tak,...veliko povezav tabela na tabelo...) Verjamem da pri večjih bazah to lahko postane problem,.. ampak v tistih bazah verjetno ne bom vodil zbirke kamnin, ki mi povzroča že težave pri tem, kaj naj dodam da bom imel dovolj entitet da zadovoljim potrebe naloge (vsaj 15) :S

Zgodovina sprememb…

dellon ::

Če vas takole učijo v šoli potem vas učijo napačno in slabo. Si že slišal za normalizacijo?
Nevem zakaj bi potreboval vsa 15 entitet da dokažeš svoje znanje o bazah in ER diagramih. To je neumnost.
To nalogo bi se učinkovito in lepo naredilo z 4-5 tabelami. Več je nesmisel.

Če pa delate to nalogo da bo njen cilj na koncu normalizirati vse, potem pa je smiselno in spreglej zgornje očitke.

lurker1359 ::

Ja, tako nas učijo,... cilj je normalizacija, ja. Torej iz vidika da je cilj normalizacija je moj trenutni ER-model vredu?
 er

er

bajsibajsi ::

Hm.. ampak meni ne deluje ravno optimalno. Normalizacijo v okviru relacijskega modeliranja podatkov izvajamo zato, da si lazje predstavljamo in da naredimo optimalno bazo podatkov z namenom, da nam zasede cim manj prostora in je posledicno odzivni cas cim manjsi. To poteka v skladu z relacijsko algebro, pri relacijskem modelu gre za neodvisnost podatkov on nacina uporabe in je osnova za optimizacijo operacij. Normalizacije iz ER modela vi prakticno ne boste delali (vsaj mislim tako, mogoce se motim). Pac pa boste ER model "preslikali" v relacijski podatkovni model. ER model je prakticno zgolj neke vrste skica; sele relacijski podatkovni model je tisto, kar steje dejansko za uporabo v organizaciji (pred tem se doloci 1:N, 1:1, dodani atributi, novi tuji kljuci, sestavljeni kljuci, itd..). Normalizacija v upravljanju podatkovnih baz ni prakticno nic drugega, kot poenostavljen proces razbijanja ene relacije na vec relacij. No, ce vas tako ucijo - pac nimas kaj. :)

lurker1359 ::

bajsibajsi je izjavil:

Hm.. ampak meni ne deluje ravno optimalno. Normalizacijo v okviru relacijskega modeliranja podatkov izvajamo zato, da si lazje predstavljamo in da naredimo optimalno bazo podatkov z namenom, da nam zasede cim manj prostora in je posledicno odzivni cas cim manjsi. To poteka v skladu z relacijsko algebro, pri relacijskem modelu gre za neodvisnost podatkov on nacina uporabe in je osnova za optimizacijo operacij. Normalizacije iz ER modela vi prakticno ne boste delali (vsaj mislim tako, mogoce se motim). Pac pa boste ER model "preslikali" v relacijski podatkovni model. ER model je prakticno zgolj neke vrste skica; sele relacijski podatkovni model je tisto, kar steje dejansko za uporabo v organizaciji (pred tem se doloci 1:N, 1:1, dodani atributi, novi tuji kljuci, sestavljeni kljuci, itd..). Normalizacija v upravljanju podatkovnih baz ni prakticno nic drugega, kot poenostavljen proces razbijanja ene relacije na vec relacij. No, ce vas tako ucijo - pac nimas kaj. :)

Ja, dejansko imamo cel projekt razdeljen v dva dela, ki sta imenovana: 1)Izdelava ER-modela, 2)Normalizacija. Slednji pri nas pomeni pretvorbo logičnega modela v relacijski podatkovni model in vnos testnih podatkov... -Tako kot si rekel.
Tudi meni se ni zdelo optimalno da bi uporabil toliko tabel, ampak, so pri tem vztrajali (ker je baje to najboljši način). Sam sem si skoraj razbil glavo, da bi svoj model razširil in da bi kljub temu še imel nek smisel (večinoma sem pa dobil zmazek..), zato sem se odločil, da povprašam na tem foromu za vaša mnenja, saj zadevo obvladate veliko bolje od mene.
Zdaj me znaima smao, če moja "skica" zgleda, da bi naj bilo to to?


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Ne-relacijska baza

Oddelek: Programiranje
193876 (2499) mitjaR
»

Nahajališča fosilov, mineralov

Oddelek: Loža
206586 (5596) Okapi
»

Kje najti fosile na dolenjskem ali posavju

Oddelek: Loža
51440 (1196) midi
»

Luna verjetno mlajša

Oddelek: Novice / Znanost in tehnologija
176031 (4434) McGregorSL
»

Podatkovna baza

Oddelek: Programiranje
182554 (1528) amacar

Več podobnih tem