Dotaz: Umbrello vazba 1:1

[Kloban]

Ahoj, navrhuju si ERD v programu Umbrello a nějak tam vidím vazbu jen 1:n. Vazby n:m a 1:1 mi tam chybí. Je možné je nějak do diagramu přidat?
Díky Dan

Odpovědi

[Roslav]

Vyselectuj si ralation cez sipku, potom dvojklikom otvor properties a v dialogu v podmenu "Roles" mas "Multiplicity"

[Kloban]

Tím ale nastavím jen popisky. Šipka má stále na jedné straně vidličku.

[Roslav]

Obavam sa, ze to nebude mozne, dokonca aj v manualy maju priklad diagramu, kde boli kardinality vyriesene popiskami. Inak, 1:1 je neprirodzena relacia, co si pamatam z prednasky, co sme mali v skole pred tyzdnom, yevraj na take by sa mal architekt pozriet este raz, ci tam nie je chyba.

[Kit]

Kardinalita 1:1 je v pořádku. To by byly špatně všechny číselníky, lokalizace programů a dokonce i normalizované tabulky v databázích.

[Josef Kufner]

Není číselník náhodou 1:N?

[Kit]

K jednomu klíči je jen jedna hodnota. 1:1.

[OldFrog {Ondra Nemecek}]

Vztah 1:1 má smysl, pokud jsou dvě různé entity ve vztahu 1:1 (občan - občanka). Pak je mohu dát do dvou tabulek, takže budou moci vystupovat i nezávisle. Současně mám možnost snadno refaktorovat na vztah 1:N, pokud to okolnosti budou vyžadovat.

Třeba Propel s tím počítá http://propelorm.org/documentation/04-relationships.html#one-to-one-relationships

[Josef Kufner]

Zrovna občan a občanka není moc dobrý příklad, neboť občan může mít občanek více (např. pokud jednu ztratí, tak dostane novou a ztracená bude i nadále vedena v databázi doplněna o informaci o ztrátě), ale i žádnou (občan nemá trvalý pobyt a chodí po ČR s pasem).

Relace 1:1 je velmi vzácná záležitost. Obvykle přítomnost takové relace bude ukazovat na nějakou chybu nebo zbytečné omezení. I když určitě se najde pár příkladů, kdy to bude dávat smysl.

[Šangala]

Za prvé: U nás není povolené mít více občanek, a moje občanka se ne a ne ztratit. Jsme už ale velcí, takže to označovat vazbou 1:1 nebudeme.

Za druhé: 1:1 vazba při návrhu obvykle nevzniká (snad blob v oddělené tabulce v jiném tablespace/Db), ale může vznikat v budoucnu při rozšiřování bez zásahu do stávající struktury.

[OldFrog {Ondra Nemecek}]

Za prvé: U nás není povolené mít více občanek, a moje občanka se ne a ne ztratit. Jsme už ale velcí, takže to označovat vazbou 1:1 nebudeme.

Tady nerozumím - jak je to míněno?

Za druhé: 1:1 vazba při návrhu obvykle nevzniká (snad blob v oddělené tabulce v jiném tablespace/Db), ale může vznikat v budoucnu při rozšiřování bez zásahu do stávající struktury.

To je ono - k existující entitě mohu neinvazivně přidat další entitu. Pokud to není nadužito, je to IMHO docela elegantní.

[Šangala]

Tady nerozumím - jak je to míněno?

Tak jak je to napsáno ;), ber jako fakt, že u nás může mít jeden občan jednu občanku a jedna občanka jednoho občana, nicméně vazba 1:1 není vhodná, protože je sice vyžadována, ale ne dodržována.

[Josef Kufner]

Můžeš mít žádnou nebo jednu platnou občanku. Ale v databázi chceš mít i informace o již neplatných občankách, abys věděl, co se s nima stalo a že už neplatí (například v případě krádeže). Nebo naopak abys mohl ověřit, že nějaký starý záznam je pravdivý. Takže občanek můžeš mít u jednoho občana v databázi povícero, i když on bude mít v kapse jen jednu.

[Šangala]

OT:

(například v případě krádeže)

„Únos“ se tomu říká…

[Josef Kufner]

"Občanský průkaz byl unesen"?

[Šangala]

Co sem pleteš jakýsi průkaz ;)

„Občanka byla unesena!“

[Kloban]

JO táááák. To by mě nenapadlo.

[Šangala]

Asi to bude regionem (či mnou), ale mně nenapadlo první vůbec to, o čem si OldFrog a Josef Kufner myslí, že píšou, a říkal jsem si proč to OldFrog píše tak divně a docvaklo mi to sice brzo, ale až zpětně po přečtení dalšího postu.

[OldFrog {Ondra Nemecek}]

Obvykle přítomnost takové relace bude ukazovat na nějakou chybu nebo zbytečné omezení. I když určitě se najde pár příkladů, kdy to bude dávat smysl.

Myslíte to tak, že vztah 1:1 se ve světě kolem nás příliš často nevyskytuje (a mělo by se vše modelovat jako vztah 1:N) anebo tak, že je vhodné dát vše se vztahem 1:1 do jedné tabulky?

[Josef Kufner]

Nikde neříkám, že vše. Říkám, že to je neobvyklé a je to signál k zamyšlení, zda to je tak správně. Reálný svět a databáze spolu mají jen málo společného.

[Josef Kufner]

... a zrovna ten příklad s občankou je toho důkazem.

[OldFrog {Ondra Nemecek}]

Právě ten příklad s občankou je dobrý - ukazuje zcela reálnou situaci, kdy se rozhoduji jak do databáze uložit občana a občanku a kdy mám chybný předpoklad, který musím později opravit.

Zprvu předpokládám, že každý občan má jen jednu občanku. Udělám tabulku občan a tabulku občanka příčemž občanka se bude odkazovat primárním (unikátním) klíčem na občana. Vznikne vztah 1:1.

Pak se dozvím, že občanek může mít ve skutečnosti občan více. Do tabulky občanka přidám nový klíč, který učiním primárním (unikátním), původní sloupec, který se odkazuje na občana nechám, akorát už nebude unikátní (na jednoho občana se může odkazovat více občanek). Vznikne vztah 1:N.

Jediné, co jsem musel upravit jsou klíče a v případné orm vrstvě getter a setter, kterým občanovi přiděluji občanku (nově musí akceptovat/vracet seznam).

Pokud bych dal všechny parametry občanky do tabulky občana, musím refaktorovat mnohem víc.

Na tom chci ukázat, že pro dvě různé entity jsou dvě tabulky se vztahem 1:1 vhodnější a flexibilnější než jediná tabulka s více sloupci a že se může hodit dekomponovat entitu na dvě entity a uložit je do dvou tabulek i případě, že to vypadá zprvu na evidentní 1:1 vazbu a máte třeba nutkání ji modelovat pouhým přidáním několika sloupců (tj. skalárních hodnot). Důvodem vhodnosti je právě to, že můžu snadno přejít ke vztahu 1:N (mimoto bude databáze sémanticky lépe odpovídat skutečnosti - občanka je něco jiného něž občan a můžou existovat i nezávisle).

Uvedená dekompozice je podle mě další možná geneze tabulek 1:1 (mimo rozšiřování databáze beze změn tabulek jak uvádí Šangala).

Otravuju s tím kvůli tomu, že nechci aby vznikl pro náhodného čtenáře dojem, že 1:1 je automaticky nějaká chyba, které by se měl vyvarovat (může to tak sice být ale také nemusí).

Nu a můj dotaz na vás se týkal právě toho, jestli byste to dával všechno do _jedné_ tabulky anobo zda říkáte "kdekoli mám _dvě_ tabulky ve vztahu 1:1 bych se měl rovnou zamyslet, zda tam nemá být spíše 1:N". Která varianta platí?

[Josef Kufner]

Nikde jsem o přidávání sloupečků do jedné tabulky nemluvil. Celou dobu jde o to, že "kdekoli mám dvě tabulky ve vztahu 1:1 bych se měl rovnou zamyslet, zda tam nemá být spíše 1:N".

[OldFrog {Ondra Nemecek}]

Ok, dík za upřesnění. S tím souhlasím.

[Kit]

Vidím to naopak: Kdekoli vidím NULL v neklíčovém sloupci, ptám se, zdali by tomu sloupci nebylo lépe v samostatné tabulce s relací 1:1.

[Josef Kufner]

Nekomplikuje to zbytečně aplikaci okolo?

[Kit]

Zjednodušuje to updaty, stávají se z nich inserty. Zrychluje to vyhledávání. Dále je možné k nim přidat timestampy, ke každému takovému atributu zvlášť. Je možné udržovat i historické stavy, které jsou např. v personalistice dost důležité. Tím se to ovšem často změní na relaci 1:N.

Například trvalé bydliště vůbec nemusí být v základní tabulce o zaměstnanci, datum narození a rodné číslo také ne. Údaje o manželovi/manželce jsou také v samostatné tabulce. Zvyšuje to bezpečnost aplikace - všechny programy nepotřebují přístupy ke všem tabulkám.

Jak by to mohlo komplikovat aplikaci okolo? Naopak se spousta dotazů zjednoduší.

[Josef Kufner]

Tyto příklady mi zní spíš jako dobře udělaná dekompozice. Adresy bych dal stranou tak nějak automaticky a udělal je jako obyčejné 1:N. Manžel/manželka bych řešil jako obecné M:N relace mezi lidmi, neboť by se mohly hodit i další vztahy (milenka).

[OldFrog {Ondra Nemecek}]

Ale o dekompozici to celé je, ne?

[Kit]

Ano, je to o dekompozici. Osoba smí mít jen jedno trvalé bydliště, je to tedy relace 1:1. Přesto je vhodnější to nedávat do jedné tabulky, ale trvalé bydliště uložit do další tabulky s primárním klíčem té osoby.

[Josef Kufner]

Pak se ale na takové schéma podíváš, uvidíš vazbu 1:1, zamyslíš se, zda to je opravdu správně a uvědomíš si, že v případě změny trvalého bydliště není úplně ideální zapomenout to staré, že vedle adresy trvalého bydliště se hodí mít i kontaktní adresu, což je ale svou strukturou stejná adresa, jen v jiném vztahu k dané osobě. A najednou je z 1:1 vazba 1:N, nebo i dokonce M:N.

[Kit]

Ano, nad tím jsem se už také zamyslel. Záleží na požadavcích.

Kontaktní adresa má sice stejnou strukturu, ale raději bych ji dal do samostatné tabulky, aby mi z toho nevzniklo EAV.

[OldFrog {Ondra Nemecek}]

1+

Nicméně tím vzroste implementační náročnost - bude třeba vytvořit integritní omezení pro jednotlivé druhy adres (aktuální trvalé bydliště může být jen jedno). Navíc stejnou úvahu mohu provést prakticky na každou entitu (občan může změnit jméno, ulice se může přejmenovat atd... ), takže se musím předně zamyslet, zda a kde chci udržovat historii (revize) a kde pouze aktuální stav. Pak to bude pokaždé rozhodování mezi 1:1 nebo 1:N příp. N:M (pokud chci mít objekty uloženy jen jednou).

[Josef Kufner]

Implementační náročnost však může i klesnout. Obecnější kus kódu nemusí být nutně složitější, i když obvykle je těžší ho vymyslet. Na druhou stranu tak lze ušetřit nemálo duplikací či zbytečného dědění velmi podobných typů, což se projeví na snažší udržbě a dalším vývoji. Ale tady už hodně záleží na konkrétní aplikaci a nemá smysl to probírat tako obecně.

[OldFrog {Ondra Nemecek}]

Měl jsem na mysli hlavně pracnost vyplývající z nutnosti kontrolovat počet položek - je to sice 1:N ale trvalé bydliště může být aktivní pouze jedno.

Samotný kód nebude složitější a bude univerzálnější, protože analogický požadavek mohu v budoucnu často relizovat s minimální pracností. Takže ve výsledku se práce ušetří.

Ale už mlátíme slámu - nemá to skutečně smysl horem dolem rozebírat

[lertimir]

Nicméně zatím se žádný skutečný příklad na vazbu 1:1 neobjevil. Všechno byly vazby 1:N, s tím, že aktivní může být maximálně jeden (nebo právě jeden) prvek. Já osobně žádnou skutečnou 1:1 vazbu neznám, takovou kdy by mělo skutečný smysl rozdělit objekt do dvou tabulek, a zároveň to nebyla v podstatě skrytá vazba 1:N.

[Kit]

Však už to tady bylo: Zaměstnanec - rodné číslo. Zaměstnanec - trvalé bydliště. Zaměstnanec - manžel(ka). Kniha - ISBN. Pošta - PSČ.

[OldFrog {Ondra Nemecek}]

Pokud chcete zachovat historii máte z toho vazby 1:N.

[Kit]

O tom jsme se už bavili. ISBN a PSČ se to však netýká, tam zůstává vazba 1:1.

[lertimir]

A co získám, když budu mít oddělené ISBN od knihy a mít je ve dvou tabulkách a ne v jedné tabulce?

[Kit]

ISBN od knihy oddělovat nemusím, ale stále je to vazba 1:1. Spíš jsem asi měl uvést zaměstnanec - rodné číslo. U něj má oddělení větší význam a také je to relace 1:1.

[lertimir]

To si ale nerozumíme. Vazba 1:1 kterou nacpu do jedné tabulky jako různé fieldy je normální a všude. Ale celou dobu je tohle vlákno o tom, proč mít vazbu 1:1 mezi dvěma tabulkami. Ani zaměstnanec a rodné číslo nevidím pro důvod oddělovat.

[Kit]

Třeba proto, že programátor aplikace pro závodní stravování nemá důvod čumět do rodných čísel. A je spousta dalších aplikací se zaměstnanci, které rodné číslo nepotřebují. A také všichni zaměstnanci rodné číslo nemají.

[Šangala]

OT: Co bych za to docela dlouhý čas dal (fčil už je to v pohodě), kdyby byla vazba Osoba−>RČ vazbou 1:N a měli tam obě má rodná čísla…

[Kit]

Upřel jsem teď pohled na naši databázi, u které si vývojář neustále říkal: Tohle je vazba 1:1, tohle také 1:1 - to bude všechno v jedné tabulce. Výsledkem je tabulka, která má 130 sloupců, pár tisíc řádek a všechny dotazy jsou neskutečně pomalé - často i víc, než čtvrt hodiny. Jenom proto, že se do sestav neustále žvejkají i údaje, které k ničemu nepotřebuji.

[OldFrog {Ondra Nemecek}]

Nění chyba jinde? Co je to za dabatázový server? Nevidím důvod, proč by to mělo být tak pomalé - pokud tam jsou správně indexy a ty sloupce se všechny paušálně pokaždé netahají do aplikační vrstvy. A samozřejmě pokud není ten dotaz sám o sobě divoký (regexp, like, složetejší agregace a výpočty).

[Kit]

S tou historií se používá ještě jedno řešení: Při změně nebo zrušení záznamu se ten původní ukládá do archivní tabulky včetně časového razítka a označením toho, kdo tu změnu udělal. V hlavní tabulce je pak pouze aktuální záznam.

[Josef Kufner]

Jo, to je pěkné řešení. Moc nekomplikuje život a umožňuje logovat méně dat, než kolik v upravovaných řádcích je.

Ale vazba 1:1 tam také není.

[Kit]

V archivu už ne, ale v aktuální tabulce je jen jedno (platné) trvalé bydliště. Takže vazba 1:1.

[Roslav]

Ale na jednej adrese trvalého bydliska môže predsa žiť viac ľudí.

[OldFrog {Ondra Nemecek}]

Takže by to byl vztah N:1. Jenže je trochu problém, jak určit, zda jsou dvě adresy totožné. Proto jsou adresy obvykle vloženy duplicitně.

Snažili jsme se před několika lety pracovat s nějakou databází měst, ulic a psč (tuším že to bylo od České pošty), ale občas tam něco scházelo a bylo s tím spousta problémů (např. duplicitní zápis názvu města ve stylu Borová u Poličky versus Borová - jsou to stejná města nebo nejsou?).

Ideální by asi byla souřadnice bytu s vhodnou tolerancí, ale to by bylo zase jak z Orwella tak možná buďme rádi, že to nefunguje

[Josef Kufner]

Na webu potravinydomu.cz to tak je. Zadáš ulici, nabídne to města, PSČ a všecko ostatní. Takže napozadí tam mají databázi ulic a měst. Asi to fungovat bude. Myslím, že to je celkem užitečné při optimalizaci rozvážky nákupů.

[Kit]

Ta databáze je běžně dostupná na MVČR v XML.

[Josef Kufner]

A z OpenStreetMap si lze vycucnout celý svět.

[OldFrog {Ondra Nemecek}]

Jako že bych do samostatné tabulky přesunul třeba jen jeden sloupec? To mi přijde moc divoké.

Podle mě by měla rozhodovat sémantika těch dat, které chci do samostatné tabulky přesouvat. Pokud je to několik položek a představují samostatnou entitu - šup s tím do nové tabulky. Narozdíl od pana Kufnera si myslím, že databáze by měla s reálným světem souviset co nejvíce - přeci ho modeluje!

V gui pak bude na úpravu té entity samostatný dialog což je implementačně snadné, pro uživatele srozumitelné a flexibilnější pro rozšiřování.

Selecty budou u více tabulek složitější, bude tam více joinů. Což nebolí, pokud používám orm.

[Kit]

Pro vyjádření relace uvnitř tabulky jeden neklíčový sloupec zpravidla nestačí. Když zůstanu u té personalistiky, tak dalším důležitým atributem bývá datum změny. Souhlasím s tím, že by měla být zachována sémantika.

Selecty složitější nebudou. Místo ORM používám pohledy.