V souvislosti s příchodem Linqu a jeho spojení s SQL se objevilo na internetu mnoho článků popisujících tuto technologii – nepochybně je .NET Framework populární a má co nabídnout. Jednou ze skvělých vlastností LINQ to SQL je možnost pracovat s dědičností. Nicméně právě u často zmiňované dědičnosti není vždy zcela jasné, jak v relačních databázích funguje.
reklama
V souvislosti s příchodem Linqu a jeho spojení s SQL se objevilo na internetu mnoho článků popisujících tuto technologii – nepochybně je .NET Framework populární a má co nabídnout. Jednou ze skvělých vlastností LINQ to SQL je možnost pracovat s dědičností. Nicméně právě u často zmiňované dědičnosti není vždy zcela jasné, jak v relačních databázích funguje.
Jak dobře známo, že s pomocí entit a relací přímo dědičnost nevytvoříte – je třeba si pomoci "obezličkou". Principem je různé mapování na jednu nebo více tabulek, a to v celku nebo po částech, případně jejich částečné kombinace.
Základní možností, jak problém dědičnosti vyřešit je tzv. Table per Concrete Type (TPC). Funguje podobně jako na objektové principy chudší jazyk. Pro každý typ v hierarchii je vytvořena samostatná tabulka. Jako příklad předpokládejme dva objekty: zaměstnanec a ředitel, kdy ředitel je potomkem zaměstnance. Tabulka zaměstnanec bude obsahovat třeba sloupce (jméno, příjmení, adresa, plat). A tabulka ředitel řekněme (jméno, příjmení, adresa, plat, počet_sekretářek). Primární klíce jsou vynechány. Vidíme, že v obou tabulkách jsou duplikovány sloupce. Tato strategie je vhodná pro časté dotazy na konkrétní typy a nevhodná pro dotazy do bázového typu.
Opačným přístupem je Table per Subclass/Table per Type (TPS/TPT). Tato strategie využívá jednu tabulku pro bázový typ a speciální tabulky pro vlastnosti vyskytující pouze v poděděných typech. Náš příklad by tedy vypadal: zaměstnanec(jméno, příjmení, adresa, plat); ředitel(počet_sekretářek). Tato strategie má výhody, respektive nevýhody obrácené oproti TPC.
Třetí možnost (nikoli však nutně poslední) se nazývá Table per Hierarchy (TPH). Pracuje na principu řídké tabulky, kdy všechny typy jsou v jedné tabulce a vyplněny jsou vždy pouze sloupce odpovídající typu, který záznam představuje. Ostatní jsou NULL. Není těžké nahlédnout, že v případě velmi široké hierarchie dědění bude tabulka obsahovat mnoho sloupců, z nichž bude velká část nevyužita (databáze však fyzicky hodnoty NULL ukládají velmi úsporně). V našem případě by tabulka vypadala (jméno, příjmení, adresa, plat, počet_sekretářek) s tím, že sloupec počet_sekretářek bude pro zaměstnance, neředitele, Nullový. Výhodou jsou snadné dotazy na různé typy, především v případě vracení z jednoho objektu (například uložená procedura) více různých typů.
V souvislosti s posledním případem je třeba zmínit i speciální sloupec, tzv. diskriminátor. Obecně jej není třeba používat vůbec, velmi vhodný je však pro TPH, nicméně jeho použití při užití TPT nebo TPC není špatné a může být v jistých případech nápomocné. Tento sloupec – většinou číslo či jednoznakový char – slouží k určení, o jaký typ se jedná. A také případně k určení, jakými sloupci se zabývat.
Vzhledem k existenci objektových databází můžeme o potřebě realizace dědičnosti v relačních databázích pochybovat, avšak relační databáze stále hrají prim v používaných databází, takže reprezentace těchto vazeb může být velmi potřebná a využitelná.