Cvičení předmětu KIV/DB1
4. týden výuky, cvičící: Ing. Tomáš Kotouč

Na této stránce se ještě pracuje

Konceptuální model, ERA modely, Zadání kritérií semestrální práce

• Konceptuální model:

• ERA model - terminologie:
  • Jedná se o jistý popis uživatelské aplikace za účelem specifikovat následně strukturu databáze.
  • Používají se zkratky ERA model, E-R-A model, ER model a E-R model.
  • E = Entita (množina dat), R = Relace (vztah mezi entitami), A = Atribut (jednotlivé položky popisující množinu dat).
    
  • ER (E-R) model představuje relace entit bez popisných atributů. ERA (E-R-A) model představuje relace entit včetně popisných atributů.
  • Rozdíl mezi ER a E-R nebo mezi ERA a E-R-A není žádný.
  • V modelu mohou existovat různá integritní omezení (IO):
    • kardinalita vztahu,
    • povinnost členství ve vztahu.

• Prvním důležitým IO je kardinalita, která vyjadřuje stupeň povolené vazby. Ukážeme si na příkladu studenta studujícího předměty:
  • Pokud dovolíme, aby student měl zapsaný právě jeden předmět a předmět byl zapsán právě jedním studentem, mluvíme o vazbě 1:1.
    
  • Pokud dovolíme, aby student měl zapsan několik předmětů a předmět byl zapsán právě jedním studentem, mluvíme o vazbě 1:N.
    
  • Pokud dovolíme, aby student měl zapsan několik předmětů a předmět byl zapsán několika studenty, mluvíme o vazbě M:N.
    

• Druhým důležitým IO je povinnost členství ve vztahu (existenční závislost). Opět si ukážeme na příkladu studenta studujícího předměty:
  • Pokud dovolíme, aby student měl zapsán několik nebo taky žádný a předmět byl zapsán právě jedním studentem, mluvíme o vazbě 1:N(0).
    
    "Kolečko" uvnitř (dvojitá čára) vyznačuje povinné členství ve vztahu.
  • Takto mohou existovat vazby: 1:1(0), 1(0):1, 1(0):1(0), 1:N(0), 1(0):N, 1(0):N(0), M:N(0), M(0):N či M(0):N(0).

• Typické příklady na jednotlivé typy vazeb
  • 1:1
    • Ve velkých ekonomických systémech (typu SAP = německý IS pro velké podniky) jsou často informace o dodavatelých a odběratelých evidovány naprosto odděleně v nezávislých tabulkách a to přestože jeden partner může být jak dodavatelem tak i odběratelem a o dodavateli a odběrateli se eviduje mnoho stejných údajů (název, IČO, adresa, bankovní spojení). V těchto systémech je to z důvodu možnosti odděleného nasazení modulu Prodeje s Odběrateli bez nasazení modulu Nákupu s Dodavateli. Přesto je možné v systému tyto dvě tabulky propojit a to přes IČO. Protože v každé tabulce se daná firma může vyskytovat pouze jednou, jde o vazbu 1(0):1(0).
      
      Lepší řešení by bylo takové, že by společné údaje byli v jedné tabulce a speciální údaje o dodavateli a o odběrateli ve speciálních tabulkách. Spojení hlavní tabulky s ostatními je ovšem také 1:1(0).
      
    • Dalším příkladem je, když část atributů tabulky má mít přístupné jiná skupina uživatelů než zbylé atributy a my máme zabezpečit bezpečný přístup k záznamům tabulky. Příkladem může být tabulka studentů, kde bychom chtěli k některým atributům umožnit aktivní přístup přímo studentům a jiné atributy musí být proti aktivnímu přístupu studenta chráněny. Zde je vhodné tabulku rozdělit na dvě a svázat je vazbou 1:1.
      
    • Chybné je použití vazby 1:1, které nemá opodstatnění a které se dá vyjádřit pouze jednou tabulkou.
      
  • 1:N
    • Faktura má svou hlavičku a své položky
      
  • M:N
    • Student má zapsáno více předmětů a předmět může být zapsán více studenty.
      

• Dekompozice M:N vztahu
  • O co jde
    
  • Chybné řešení
    
  • Správný rozklad na tři tabulky s vazbami 1:N a N:1
    

• Zakreslování šipek, nejpoužívanější řešení
  • 
    

• Speciální případy zakreslování vazeb:
  • U pracoviště sledujeme jeho nadřazené pracoviště, což je údaj ze stejné tabulky:
    
  • Předmět může být nahrazen více předměty:
    
  • Zakreslení vazby Student-Osoba-Učitel
    

• Textový zápis Entit a Relací
  • Co je to klíč = taková množina atributů, která jednoznačně určuje každý záznam množiny dat (tabulky)
    
  • podtrhávání klíčů
  • NULL hodnota
  • jedinečnost
  • typy atributů a velikost
  • domény

• Příklady:
  • Manželství (od 1:1 až po M:N, závisí na omezujících podmínkách)
    • 
      
  • Sledování MHD pro dopravní podniky:
    • 
      
  • Rozvrhy:
    • 
      

• Jak je vidět z uvedeného, je vždy nutné si před programováním problém dobře promyslet, jinak se může stát, že budete muset celou aplikaci od základu přepsat.

• Zadání kritérií aplikace (studenti si vymyslí zadání aplikace dle uvedených kritérií sami):
  • Aplikace bude postavena alespoň nad pěti tabulkami.
  • Mezi tabulkami bude alespoň jedna vazba M:N (např.: student studuje více předmětů, jeden předmět studuje více studentů), tato vazba se rozkládá na tři tabulky s vazbami [Tabulka1] 1:N [Tabulka3] N:1 [Tabulka2].
  • Žádná z vazeb nebude 1:1 nebo musí být dokonale odůvodněna.
  • Z formulářů aplikace budou přístupné všechny tabulky a to pro zadávání (INSERT), změnu (UPDATE), mazání (DELETE) i prohlížení (SELECT).
  • Aplikace bude obsahovat alespoň jeden formulář s podformulářem.
  • V aplikaci zabezpečit konzistenci dat (nesmí nastat případ, kdy v jedné tabulce smažu otce (MASTER) a v jiné mi zůstanou synové (DETAIL)).
  • Jako aplikaci můžete použít jakoukoliv jinou databázovou aplikaci, kterou jste připravili pro jiný předmět nebo pro nějakou společnost nebo vlastní využití. Tato aplikace však musí splňovat uvedená kritéria. Při předvádění aplikace bude různými otázkami zkoumána nejenom funkčnost aplikace, ale také, zda aplikaci rozumíte (zda jste ji napsali sami).
  • Dokumentace musí splňovat podmínky Konceptuálního modelu.