dbDesigner 4.0.5.6 Beta - 1/1

Pomocí Reverse Engineering se mi celkem v pořádku povedlo naimportovat do dbDesigneru již existující databázi. Akorát nastavení defaultních položek se občas vytratilo a CREATE TABLE, který pak generuje tabulka v dbDesigneru nebyl úplně shodný s CREATEM, který byl použit v originální databázi. Navíc mu chyběly u defaultních položek uvozovky, takže příslušný CREATE generovaný dbDesignerem mi ani nešel na MySQL serveru spustit. Ale to bych programu, který je zadarmo odpustila, pokud člověku jde hlavně o schéma tabulek jako takových. Já jsem si chtěla zpřehlednit databázi a zobrazit v ní referenční integritu dat. DbDesigner vypadá velice slibně a do budoucnosti určitě slibný je. Bohužel není dotáhlý do konce, má pár mušek a někdy se chová dosti nestandardně (např. při editaci položek tabulky a výběru typu políčka tabulky). Možná těch mušek bude více. Chtěla bych zde upozornit ta ty chyby, na které jsem zpočátku narazila a případně nastínit možnosti, jakými lze tyto nedostatky obejít.

dbDesigner si nepamatuje správně rozměry grafického schématu

Když jsem schéma uložila, zavřela a pak znovu pomocí dbDesigneru otevřela, zjistila jsem, že si nedokáže správně zachovat nastavenou uloženou šířku a výšku grafického schématu tabulek. V okně Navigátor se sice zobrazoval celý náhled plochy, ale na spodní kraje schématu se ve skutečnosti nešlo dostat.

Řešení

V nabídce Options > Model Options > Editing Options na to lze vyzrát tak, že správnou Canvas Size nastavíte na hodnoty Width = 1 a Height = 1. Původní hodnoty, které jste tam měli si ale zapamatujete. Projekt se celý přepočítá na šířku 1 a výšku 1. Neuvidíte sice nic, ale veškeré informace zůstanou zachovány. Následně opět v nabídce Options > Model Options > Editing Options si nastavíte správné hodnoty Canvas Size, tedy ty, které jste tam původně měli. Projekt se vám opět přepočítá a zobrazí již ve správné velikosti.

dbDesigner má problémy s exportem větších schémat do obrázku

V případě, že schéma má větší velikost než šířku: 5 880 px a výšku: 4 080 px mohou nastat problémy s exportem do obrázku. Udaná šířka a výška je jen přibližná. Přešnou šířku a výšku nelze určit, ale okolo této velikosti se začínají objevovat problémy. Pokus o export v nabídce "File > Export > Export Model as Image" Vám pak zahlásí chybu: "Invalid canvas state request". Při ukládání do obrázku se dbDesigner snaží oříznout bílá místa ze stran a na tomto oříznutí to zjevně hapá.

Řešení

Jediné řešení vidím v tom, že se člověk omezí model na šířku a výšku v rozměřech do 5 880 px a 4 080 px. Jenže to je nepoužitelné u větších databázových schémat!

Chybné vytváření relací mezi tabulkami

Dále jsem měla problémy s vytvářením vazeb cizích klíčů 1:n non-identifaing u již existujících tabulek. Tento problém patří mezi závažnější.

Relace 1:n jsou v dbDesigneru dvojího druhu:

• 1:n non-identifaing (one - to - many relation, FK not in PK) - ty jsou nejběžněji používané. Cizí klíč není zároveň primárním klíčem, a tudíž se indexy mohou v tabulce opakovat. Více záznamů v tabulce s cizím klíčem může ukazovat na konkrétní jednu položku v tabulce definované příslušnou relací.
• 1:n (one - to - many relation) - což jsou relace jen na primární klíče. Tyto relace například vznikají při rozdělení vazeb m:n, kdy se tyto relace roztrhnou na dvě propojení 1:n a ta "mezi-propojovací" tabulka právě obsahuje cizí klíče, které jsou zároveň i primárními klíči v tabulce.

Kromě těchto vazeb jsou tam samozřejmě ještě i vazby 1:1.

Nyní zpět k problému. Když jsem chtěla vytvořit propojení 1:n non-identifaing z jedné tabulky do druhé, tak tabulky dbDesigner sám propojil automaticky tabulky na primarní klíče. Což o to, to by až zas tak nevadilo, kdyby to šlo jednoduše změnit v popisu relace a říci mu, že v relaci 1:n má u jedné tabulky použít Id tabulky a u druhé tabulky místo Id nějaký jiný sloupec (náš cizí klíč). Při editaci relace se dbDesigner ale chová jinak, než by se očekávalo. Nemění totiž jen definici propojení sloupců. Místo toho, aby měnil nastavení relace, tak mění přímo sloupce! Konkréně při pokusu editace relace 1:n a změny primarního klíče (třeba Id) na jiný název sloupce, dbDesigner nenapojí relaci na tento zadaný sloupec, ale přejmenuje původní sloupec Id na nově zadaný název. Tudíž dojde k tomu, že sloupec Id úplně zmizí. A pokud nově zadaný název sloupce je navíc shodný s existujicím názvem položky v tabulce (například se skutečným cizím klíčem), tak tuto původní položku smázne! Takže vám začnou "mizet" pod rukama sloupce v tabulkách.

Také při výmazu relace dochází k výmazu sloupce v tabulce, na které je relace provázána. Pozor na "undo", to v těchto případech nefunguje úplně 100% a nevrátí se mnohdy do stavu úplně před tím. Zmizlé sloupce tedy někdy nejdou jen pomocí undo jednoduše obnovit! Také když se přidá relace (relations) a pak se dá "undo", tak to smázne sloupec v tabulce, na který byla relace navázána!

V jednu chvíli jsem skoro rezignovala, že nebudu schopná vytvářet relace mezi tabulkami a začala si pročítat diskuzní fóra. Zjistila jsem, že nejsem sama, kdo má podobné problémy. Doufejme, že nová verze již bude mít tyto věci opravené. Na tento problém narážela již i diskuze vedená na fabforce.net.

Zdálo se, že budou fungovat následující rady:
"When creating a relationship from one table to another, use the right mousebutton to select the column."
"When you add a relationship, must click on the first table, and then right-click on the FK column of the second table."
Ale při aplikaci těchto rad mi to někdy hlásilo takovou divnou chybu, že změny nemohou být aplikovany na daný objekt, tak jsem z toho byla celá rozpačitá.

Řešení

Nakonec jsem vše vyřešila úplně jinak. V Model Options lze nastavit v Editing options "foreign key prefix". On pak ke každému klíči, který chce automaticky vytvořit, přidá zadaný prefix (např. prefix_). Výsledkem je to, že pro cizí klíč nepoužije přímo primární klíč id, ale místo něj si vytvoří klíč prefix_id. Náš cizí klíč se pak jmenuje prefix_id a je označen v tabulce jako FK (foreign key). V tabulce přibyde tento jeden sloupec. Ten když se pak následně v editaci relace změní na správný název sloupce (název našeho opravdového cizího klíče), tak pak je relace správně navázána :). Je nutné si ještě pohlídat, aby vytvořený prefix_id byl stejné definice jako váš opravdový cizí klíč a případně ještě předtím upravit prefix_id na shodnou definici! Protože předěláním relace relations z prefix_id na název opravdového cizího klíče dojde v podstatě ke smazání toho sloupce (opravdového cizího klíče) z tabulky a následně se jen přejmenuje prefix_id na soupec s názvem našeho původního cizího klíče. Pokud máte v dbDesigneru pouze strukturu tabulek a nikoli data, tak to celkem nevadí. Nevím přesně, jak by se to chovalo s daty, ale předpokládám, že by byly tímto způsobem smazány!

Pokud tedy chci provázat dvě tabulky relaci 1:n non-identifaing, tak používám zjednodušeně řečeno tento postup:

1. Nastavím si nějaký prefix pro klíče
2. Pak udělám propojení. To, z jaké tabulky do které bude směřovat relace, záleží na pořadí vybrání tabulek myší. Nejprve se vybere v menu druh relace a pak se klikne levým tlačítkem na jednu tabulku a pak levým tlačítkem na druhou tabulku. Tim jsou tabulky propojeny. V jedné se vytvoří klíč s naším prefixem, druhá tabulka má relaci navázánu na primární klíč.
3. Nový klíč s prefixem porovnám s definicí opravdového cizího klíče, na který chci mít relaci v konečné fázi napojenu. Pokud se definice neshoduje, upravím definici klíče s prefixem tak, aby se to shodovalo na opravdový cizí klíč v tabulce. Porovnání provádím v tabulce pomocí Edit table. Kouknu se zda mají například shodné položky jako NOT NULL, velikost apod.
4. Pak kliknu na relaci (relation) a upravím ji. Tam relaci predělám ze sloupce prefix_id na cizí klíč, jak ho chci mít pojmenován. Tím pádem mi relace smázne původní cizí klíč a prefix_id přejmenuje na můj zadaný sloupec. Nakonec jsem tam, kde jsem chtěla být. Mám sloupec cizího klíče graficky propojený na jinou tabulku. Není to dokonalé, ale používat to lze...

Výmaz sloupců tabulky při výmazu relace

Z nevyřešených případů mi stále ještě zůstává probém výmazu relace tak, aby při něm nevymazal dbDesigner i příslušný cizí klíč (FK). Po výmazu relace se totiž sloupec cizího klíče automaticky maže a zdá se, že to nelze nikde nastavit, aby se tak nedělo :(.

Řešení

Asi lze jedině doporučit dodatečně smazaný sloupec do tabulky ručně přidat.

Celkové hodnocení

Práce s dbDesignerem je dost pomalá. Člověk na ten program nesmí chvátat. Hlavně při přesunech po obrazovce, kdy výpočet a zobrazení nové polohy objektů trvá delší dobu. Jinak je dbDesigner celkem vyvedený, ovládání dosti připomíná Adobe Photoshop. Program obsahuje dost různých chyb (závažné i méně závažné) a Vy se musíte naučit s nimi pracovat. Pro menší MySQL databázi je to celkem přijatelná volba.

Obsah článku:

• 1/1

 

Copyright © 2010 Jitka Vachtová, všechna práva vyhrazena.