Návrh zacyklené databáze

[Xerox]

Zdravím

Kamarátovi som vymyšlal štruktúru databázy pre jeho projekt do školy, avšak vyučujúci mu ho vratil na prerobenie, kvôli tomu že je to udajne "zacyklené". Nemám zas až toľko skúseností s navrhovaním, preto by som bol rád keby mi to niekto objasnil prečo je tento návrh zle. Sporná je tabuľka zboží ,pretože je su v nej cudzie klúče zákazník a dodavatel

[Reklama]

[Franta]

A proč tam jsou? Musí tam být? ;-)

[Mirek]

a proc jsou tam tabulky zakaznik a dodavatel? proc to neni jen jedna tabulka - co kdyz nekdo je zakaznikem i dodavatelem, pak tam musi byt 2x a v kazde tabulce tam muzou byt o nem jine udaje -takze zmatek (napr. kdyz nekdo opravi telefon, jen u odberatele)
a proc jsou tam tabulky dodavky a odber? proc to neni jedna tabulka, ktera se lisi znamenkem v poctu (např. dodavky +, odber -)

[Franta]

On je ten návrh vůbec dost zmatlaný. Pár tipů k zamyšlení:

- Kde je návrh-zadání? Předhodil jsi sem špatný fyzický model a čekáš, že ostatní přijdou na původní zadání (pomocí věštecké koule zřejmě) a pošlou ti správný fyzický model.
- Skutečně potřebuješ všude umělé PK (číselné ID)?
- Jedno zboží (kus) může být součástí několika dodávek nebo několika odběrů? Divné, ne? Nebo tím zbožím myslíš artikl a ne konkrétní kus? Pak je zase divná ta vazba na zákazníka -- co když si každý kus odebere jiný zákazník? A co je potom druh?
- Než začneš klikat tabulky v nějakém GUI nástroji, zkus si nejdřív něco přečíst o datovém modelování.

[JS]

Moc toho o datovem modelovani nevim, ale hadal bych, ze problem je skutecne v tom, ze ty cizi klice dodavatel a zakaznik jsou v tabulce zbozi zbytecne navic. K teto informaci se totiz da dostat vhodnym joinem pres tabulky odber nebo dodavky. Navic vztah zakaznik-zbozi i dodavatel-zbozi jsou v relaci many-to-many skrze odber nebo dodavky, a tedy nemohou byt zaroven ve vztahu one-to-many.

[Reklama]

[backup]

cyklus vidim napr. v situaci, kdy se bude mazat nejaky zakaznik a pres cascade delete se tedy budou mazat vsechny polozky zbozi s tim zakaznikem -> tim se budou mazat vsechny odbery ktere maji ti id_zbozi a tim se budou mazat vsechny zakaznici , kteri referencuji ty id_odbery a tim se budou mazas vsechny polozky zbozi, ktere maji toho zakaznika, ktery ma byt pres id_odber smazan, .....

[Xerox]

Ďakujem za konštruktívnu kritiku:)

Zadanie som zabudol napísať. Zadaním bolo vytvoriť databázu na ktorú bude možne vymyslieť okolo 20 SQL dotazov a aby boli z každého typu... Idea na riešenie tohoto zadania bolo vytvorenie databázy na obsluhu jednoduchého skladu. V databáze budu zaznamenané položky tovaru, ich dodávatelia, odberatelia, a potom druh, ktorý bude taktiež určovať mernú jednotku. Čiže v tabuľke zboži su uložené už konkrétne názvy resp. konkrétny tovar(artikel). Odber a dodavky je pravda že by to mohlo byť v jednej tabuľke, ale je to skutočne lepšie mať to v jednej alebo dvoch oddelených tabuľkách? Ako ste už poukázali nie je to pre všetky pripady, v tom sa mám čo učiť:) Akú literatúru odporúčate k problematike dátového modelovania?

[devnull]

Nechcu spekulovat jestli dat dodavatele/zakaznika, odber/dodavku do jedne tabulky - zkusim jen poznamky k tvemu reseni

1. zbozi
- vazba mezi zakaznikem a zbozim je podle me nesmysl
- "pocet_kusu" bych prejmenoval na "pocet" - to jestli jde o kusy nebo kila mas v druhu
- pokud vazbou na dodavatele myslis to, ktery dodavatel je zbozi schopen dodat, pak by tam mela byt vazba n:n ( cili treba mezi zbozi a dodavatele dat tabulku dodava_zbozi( id_zbozi INT, id_dodavatel INT ). Pokud s tou vazbou toto nemyslel tak ju zrus - je to nejspis stejny nesmysl jako u zakaznika

2. odber - muze byt pokud ti nevadi ze nepujde udelat jeden odber na vice zbozi naraz - pokud bys to tak chtel, tak by se muselo z odberu vyhodit id_zbozi a pocet kusu a udelat na to novou tabulku napr "odebirane_zbozi" ( id INT, id_odber INT, id_zbozi INT, pocet NUMERIC). Tabulka by pak v diagramu byla mezi odberem a zbozim, takze pak by ke kazdemu odberu muhlo existovat n zaznamu jaky zbozi zakaznik odebira

3. dodavka - viz, odber

[Michal]

Zdravím nechci zakládat nový topic, ale mám stejný problém. Vytvořil jsem databázi pro multimediální obsah, mám vytvořenou i aplikaci v php která funguje, vše běží (podle mě) správně, přesto mi byla databáze vrácena pro špatný návrh struktury a údajné zacyklení.

Ví někdo kde je chyba?

[Logik]

Ad zacyklení: nevím, kdo Vám to přednáší, ale zacyklení foreign keys vůbec není chyba. Je spousta příkladů, kde to bez cyklických FK nejde. Chyba je, když foreign keys nemají smysl: to je příklad prvního z příkladů, proč tu bylo už vysvětleno.

V druhém případě ale FK co vidím smysl mají, navíc tam ani cyklický vztah nevidím. Není možné to, že vyexportujete pro cvičícího SQL skript, ve kterém jsou definice FK před definicemi užívajících tabulek?

V druhém případě se mi nelíbí např. oddělení  interpreta a herce, filmu, seriálu a epizody, tp by imho chtělo spojit. S tím, že nejlépe by měla být jedna tabulka pro díla, jedna pro osoby a pak tabulky na vztahy (osoba, dílo (herec, interpret, režisér, autor...)), dílo-dílo (býti částí jiného díla, např. píseň částí alba, epizoda částí seriálu). Zásadní chyba (nenormalizace) je uvedení kategorie u fota jako VARCHAR, to chce alespoň samostatnou tabulku, stejně pravděpodobně špatně je složka, jestli dobře chápu význam.

V každém případě, pokud to cvičící vrátil pouze s uvedeným komentářem, tak není dobrý cvičící, on není ani špatný cvičící, on je přinejmenším hodně špatný cvičící....

[turista]

Ja tam vidim tyto hlavni problemy:

- redundantni FK dodavatel a zakaznik - kazda redundance musi byt velmi dobre zduvodnena, napr. zvysenim vykonu, coz je v semestralce nepodstatne
- zbozi ma prave jednoho dodavatele - v praxi tomu vubec nemusi byt
- zbozi ma prave jednoho zakaznika - to je jeste podivnejsi

doporuceni: vypustit sloupce dodavatel a zakaznik z tabulky zbozi, tim se vyresi vsechny tri problemy

A mensi problemy:
- urcita redundance je i zbozi.pocet_kusu, to se da vzdy dopocitat ze skladovych pohybu v tabulkach odber a dodavky, pokud to tam mas musi to byt podchyceno triggerem nebo db procedurami
- rozmysli se, jestli budes mit nazvy tabulek v mnoznem nebo jednotnem cisle
- stav jako jeden bit je trochu malo, stavu bude v praxi vice nez dva
- jak uz bylo zmineno: dvojice odber/dodavky a dodavatel/zakaznik mohou byt slouceny - napr. do tabulek pohyb a subjekt

[podlesh]

Zdravím nechci zakládat nový topic, ale mám stejný problém. Vytvořil jsem databázi pro multimediální obsah, mám vytvořenou i aplikaci v php která funguje, vše běží (podle mě) správně, přesto mi byla databáze vrácena pro špatný návrh struktury a údajné zacyklení.

Ví někdo kde je chyba?

Jaký smysl má vazba album_interpret? Předpokládám "seznam všech interpretů kteří se podíleli na tvorbě zvukových nahrávek" - ten lze lze získat tak, že udělám dotaz přes audio_interpret a audio_album. Zavádění další vazby je tedy zbytečné a navíc komplikuje aplikaci která musí její obsah udržovat. Navíc databáze nedokáže kontrolovat konzistenci, takže se tam při chybě může stát že nějaký interpret je v audio_interpret ale není v album_intepret (a opačně).

Něco jiného by bylo pokud by v databázi měli být uloženi lidé co se nepodíleli na jednotlivých záznamech, ale podíleli na albu (autor grafiky bookletu, například). To by pak bylo možné vyjádřit touto vazbou (i když termín interpret by byl přinejmenším podivný), ale pořád by to bylo velmi řešení (chyběla by tam informace jak se podílel).

Další chybou je opět (stejně jako u skladu) zavedení dvou tabulek pro stejnou datovou entitu. Nejenom že z toho návrhu vidím že se mi to tam opakuje (aneb: když vidím dvojmo, tak žem buď pil nebo je to špatně), ale dokonce jsou naprosto reálné případy hrajících režisérů a režírujících herců (např. Mezl, Eastwood).

No a ještě takový tip: uvádět věk jako int je docela nepraktické, protože se jaksi časem mění... mnohem lepší je mít u osoby datum (nebo alespoň rok) narození a pak jen dopočítat věk aktuální a věk v kritické době (v tomto případě při natáčení).

Na závěr bych ještě uvedl jeden případ, kdy je možné zavést zcela korektní FK cyklus: stává se že je několik epizod seriálu sestříháno a vydáno jako film. To lze reprezentovat jako vazbu 1:N.

[ateista]

podle me je tam zbytecne audio_interpret. protoze mam audio->album->interpret cimz je jasne definovane i audio->interpret. Zduvodnitelne by to bylo asi jedine vykonem...