Transformace E-R modelu na relační

Výsledkem konceptuálního modelování je E-R model, který může být dost vzdálený logickému modelu. Algoritmus na transformaci (převod) konceptuálního schématu na relační bývá součástí modelovacích nástrojů (Oracle: SQL Developer - Oracle, Enterprise architect). Některé konstrukce mohou mít několik variant převedení (několik různých).

R1(id_a, a)
R2(id_b, *b, c)
R2(id_a) ⊆ R1(id_a)

Transformace entity

Jediná možnost provázání dat ze dvou relací je referenční integritou (FOREIGN KEY).

  • název entity → název relace
  • atribut entity → atribut relace
  • povinnost atributu entity → NOT NULL
  • atributy edentifikátoru entity → PRIMARY KEY
  • alternativní klíče → UNIQUE
  • u slabých entit → identifikátor vlasníka domény atributů entity se “namapují“ na domény relacních atributů

Převod některých konstrukcí konceptuálního modelu (např. ISA hierarchie) má nekolik možných variant, implementace závisí na dalších okolnostech

Dědičnost entit, ISA

Z anglického is a. Podstatnou vlastností relačních databází, je že nepodporují dědičnost (a tím pádem ani polymorfismus).

Entity, které jsou součásti generalizační hierarchie a nejsou jejím zdrojem budou dále nazývány subtypy. Existují 3 možnosti transformace:

  • Single Table Inheritance. Vytvoření jedné tabulky, která sjednocuje atributy podentit. Je zachován zdroj hierarchie a kromě vlastních atributů ponese i atributy všech subtypů. Navíc bude mít atribut říkající o který subtyp se jedná. Dále se přidají integritní omezení, které zajistí výlučnost (disjunkci) subtypů. Tento způsob je vhodný pouze v případě, že se subtypy vzájemně neliší, v ostatních případech je nepraktický a nepřispívá struktury databáze.

  • Vytvoření tabulek pouze pro jednotlivé podtypy, tedy odstraníme zdroj hierarchie.
    Všem subtypům hierarchie jsou pak předány atributy zdroje i vztahy, na kterých se zdroj podílel. Pro všechny typy se budou duplikovat vztahy entit. Tento způsob je vhodný v případě, že zdroj hierarchie obsahuje velmi málo atributů a podílí se na velmi málo nebo žádném vztahu (např. pokud nese pouze identifikační atribut). V ostatních případech vede ke zbytečné duplikaci a opět nepřispívá k přehlednosti a v důsledku ani ke snadné udržitelnosti dat.https://www.martinfowler.com/eaaCatalog/concreteTableInheritance.html

  • Vytvoření tabulek pro všechny typy v hierarchii.
    Mezi zdrojem hierarchie a jeho subtypy se pak vytvoří vztahy. Ze subtypů se stanou slabé entity. Kardinalita ze strany zdroje je (0,1). tedy každá instance zdroje může mít vztah s max jedním subtypem. Kardinalita ze strany subtypu musí být (1,1) a identifikovaná právě jednou zdrojovou entitou.
    Tento způsob převodu se zdá nejvíce univerzálním, zachovává výhody generalizační hierarchie a je v souladu s požadavkem přehlednosti a snadnější udržovatelnosti struktury databáze.

Transformace vztahů

Jediná možnost provázání dat ze dvou relací je referencní integrita (FOREIGN KEY)

Vztah 1:1

Obě části jsou ve vztahu povinné

Dojde k sjednocení daných entit do jedné tabulky vuz(cislo_z, jmeno_z, adresa, spz, vyrobce, model). Kde navíc spz je NOT NULL a UNIQUE (protože byl identifikátorem).

Jen jedna část je povinná

Entity se nemohou spojit kvůli nepovinnosti jedné strany. Převedou se tedy na dvě tabulky, kde tabulka, jež je nepovinnou částí, bude mít ID odkaz na povinnou část.

Obě nepovinné

Lze vyřešit dvěmi způsoby. První řešení odpovídá předchozímu případu, akorát cislo_z v tabulce vuz bude nepovinný.


Vztah 1:N

Vztah M1:N

Dekompozice na tři tabulky.

Převod výlučných vztahů

Existují dvě možnosti transformace do tří tabulek.

  • Pomocí společných domén
  • Nemají-li identifikační klíče stejnou doménu, je nutný převod pomocí cizích klíču.

Související