Autor Zpráva
joe
Profil
Ahoj,

našel jsem pravidla, ale stále si nejsem jistý, kdy mám použít indentifying a kdy non-indetifying (indetifikující a neidentifikující) relaci.

Řekněme, že mám dvě tabulky, page a template, stránka má jednu šablonu a šablona může mít jen jednu stránku, tedy relace 1:1, identifikující, protože stránka bez šablony být nemůže (je to tak? Už někdy váhám i tady.). V takovém případě mi vznikne tento diagram.

A teď mi vznikne ale problém, protože v tabulce page mám primární klíč složený ze dvou sloupců - id a template_id. Pokud bude existovat více šablon (a tabulka template bude obsahovat víc jak jeden řádek), pak může být v tabulce page více řádků se stejným id, ale jiným template_id. Ale v aplikaci spoléhám na to, že id u stránky je jenom jedno...

Kde jsem teda udělal chybu a jak tedy správně používat identifikující a neidentifikující relace? A nebo je lepší se jim úplně vyhnout a jako primární klíč mít vždy sloupce označený id?
Jan Tvrdík
Profil
joe:
Správné řešení je mít page jako silnou entitu a template jako slabou entitu identifikačně závislou na page bez vlastního atributu podílejícího se na identifikaci.
Tedy tabulka page bude mít sloupce id (pk), name a content. Tabulka template bude mít sloupce id (pk), file, přičemž sloupec template.id bude odkazovat na page.id.

Otázkou samozřejmě zůstává, proč to potřebuješ mít ve dvou tabulkách.
joe
Profil
Díky za odpověď, osvěžil jsem si pojmy jako silná a slabá entita a dává mi to rozum, ALE...

Napřed k čemu to celé bude - jednoduché vlastní CMS a proč to potřebuju mít ve dvou tabulkách, protože to není tak jednoduché jako jsem to znázornil.

- šablona bude mít i další atributy - název, datum vytvoření, datum editace, do jaké prezentace patří, typ šablony

Když jsem si dělal návrhy, vždycky (asi špatně?) jsem měl sloupec id (auto increment), který řádek tabulky identifikoval. Jak píšeš, tak je pěkné mít primární klíč v template jen sloupec page_id (id), ale jak tu šablonu rozeznám v systému, kde chci pracovat s tou konkrétní šablonou? Tady by to ještě šlo podle id stránky.

Ale pokud by vznikla situace, že bych v primárním klíči měl tři sloupce, kdybych takový řádek chtěl v systému upravit, adresa na jeho editaci by pak musela být:

example.com/table/edit?column1=...&column2=...&column3=...

A to asi není ideální, ne, takže bych musel vytvořit sloupec id, s unikátním indexem, ale bohužel bez auto incrementu, protože ten je jenom na primárním klíči. Je to tak?
Jan Tvrdík_
Profil *
joe:
Ta editační URL taky může být example.com/table/edit/?id=123-456-798. Pak to nevypadá tak blbě. Nejsem si také jist rozumností návrhu, který potřebuješ primární klíč tvořený třemi sloupci. Nicméně pokud bys to tak skutečně chtěl, tak tabulka template může klidně mít sloupec id jako primární klíč s auto incrementem a pak unikátní index přes ty 3 sloupce.
joe
Profil
Jan Tvrdík:
Ok, tak teď teda nevím jestli si rozumíme :-) na návrh používám MySQL Workbench (zdá se mi to jako dobrý, šikovný a ideální program) a ten mi umožňuje vytvořit buď identifikující (že "přidává" cizí sloupec do primárního klíče druhé referenční tabulky) a neidentifikující, který primární klič v referenční tabulce nechává tak, jak byl.

Tzn., že bych měl používat jenom ty neidentifikující relace a primární klíče volit podle uvážení? :) Protože vůbec nevím k čemu mi je dobré, že mám primární klíč složený z více sloupců, skoro bych řekl že to může přinést akorát problémy.

Ta editační URL taky může být example.com/table/edit/?id=123-456-798
Ne vždy, co když ten jeden sloupec mohl být string a obsahoval by pomlčku? Mohlo by dojít ke kolizi s oddělovačem a tomu chci předejít.

Kdybys měl čas a chuť mi s tim ještě víc pomoc, abych to zase pochopil trochu víc a neudělal si zbytečně špatnej návrh hned na začátku, můžu se i finančně odvděčit.
Jan Tvrdík
Profil
joe:
na návrh používám MySQL Workbench
Já jsem ti poradil dle mě nejlepší řešení. S tím jak ho naklikat v MySQL Workbench ti ale neporadím. Nicméně myslím, že není důvod se omezovat tím, co ti umožní MySQL Workbench pohodlně naklikat. Snažíš se tam naklikat už relační nebo teprve konceptuální schéma?
joe
Profil
Jan Tvrdík:
Vytvářím databázový model. Nikdy jsem na teorii nebyl, takže už popravdě nevim, jakej je mezi těma schématama rozdíl.
Prostě a jednoduše to, jak databáze bude vypadat fyzicky.

Já jsem ti poradil dle mě nejlepší řešení
Vůbec nepíšu, že je špatné nebo ho nechci nějak zpochybňovat, ale pokud se nepletu, sedí asi jen na to, kdyby v té tabulce pro šablony skoro nic nebylo, ne? Pokud tam chci další údaje, v případě, že bych chtěl použít stejnou šablonu pro více stránek, musel bych mít více řádků se stejnýma datama a to si nemyslím, že je dobře. Resp. to odporuje nějaké normalizaci (jaké, to ale nevím :))
Tori
Profil
joe:
Řekněme, že mám dvě tabulky, page a template, stránka má jednu šablonu a šablona může mít jen jednu stránku, tedy relace 1:1“ [#1]
vs.
v případě, že bych chtěl použít stejnou šablonu pro více stránek“ [#7]
Jak to tedy je? :) podle #7 to vypadá spíš na 1-M:1 (page:template). Opakovat se v tom případě bude jen ID šablony v tabulce page a asi i typ šablony v tab. template, což mi připadá v pořádku.
joe
Profil
Pardon :) v úvodu byl jen příklad a pak jsem to více rozebral. Takže ještě jinak.

Chci udělat CMS, kde budou prezentace (id, název). Každá prezentace může obsahovat různý počet stránek (id). Stránka bude mí různé mutace (název, titulek, ...) a taky šablonu. Jedna šablona může patřit více stránkám.

Po nějaké době studování jsem dal dohromady takové schéma.

A teď nevím, jak propojit prezentaci a stránku.

Buď (to je právě ta identifikující relace, kdy se mi v tabulce stránka přidá do primárního klíče sloupec prezentace_id) a nebo (neidentifikující relace)? A proč, dokáže mi někdo vysvětlit co je správně?

(logicky se mi totiž zdají obě možnosti správné)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: