Databáze

nožiny účelově vybraných odpovídajících objektů - entit. KNIHA, ČTENÁŘ označují typ entit, vlastními entitami je kniha s ISBN 310, čtenář I34 apod.;
typy vztahů, do nichž entity vybraných typů mohou vstupovat. typům vztahů odpovídá příslušná množina objektů - vztahů. Např. ČTENÁŘ (typ entity) MÁ_VYPŮJČENO (typ vztahů) daný EXEMPÁŘ (typ entity). Entita čtenář I34 může být ve vztahu “MÁ_VYPŮJČENO” k entitě exemplář 00109;
na základě přiměřené úrovně abstrakce přiřadí jednotlivým typům entit a vztahů atributy, které blíže popisují vlastnosti entit a vztahů. TITUL (údaj popisného typu) pro entity typu KNIHA, DAT_ZPĚT (údaj popisného typu), kdy daný čtenář vrátil daný exemplář, tj. jde o atribut vztahů mezi čtenáři a exempláři ( typ vztahu je MÁ_VYPŮJČENO);
formulace příslušných integritních omezení vyjadřující s větší nebo menší přesností soulad vytvářeného schématu s modelovanou realitou (každý čtenář může mít vypůjčeno více exemplářů a každá kniha může být ve více exemplářích).
V datovém modelování se řeší jako hlavní problém transformace konceptuálního schématu do databázového modelu, jehož nejčastější případem je převod konceptuálního schématu E-R modelu do relačního modelu dat.
V technické etapě se nejprve navrhne relační tabulka (tzv. univerzální relace) tak, že bude obsahovat všechny potřebné údaje.Ve většině případů se však v ní některé konkrétní hodnoty jednotlivých údajů budou opakovat vícekrát. Takovýto nadbytečný (redundantní) výskyt zbytečně zvětšuje velikost tabulky a prodlužuje tak její zpracování. Navíc představuje velké problémy při změnách (aktualizaci) těchto údajů. Tento nedostatek je nutno odstranit dekomponováním takovéto tabulky do více tabulek postupem, který je označován termínem normalizace. Jde o činnost, která vede od nesprávně navržené relační tabulky k jejímu přetvořenému normalizovanému tvaru (NF).
Konceptuální model
konceptuální modelování vede k formálnímu popisu uživatelské aplikace
používá nástroje - konceptuální modely, výsledkem jsou konceptuální schémata
ta jsou nezávislá na pozdějším použití pro konstrukci schématu databáze
konceptuální schémata nevznikají přímo, ale integrací dílčích uživatelských pohledů - externích schémat
Konceptuální model 2
na DB úrovni jim odpovídají pohledy - popisují datové struktury vyhovující danému uživateli (jsou jen virtuální - fyzicky neexistují)
uvedená schémata tvoří jen statickou část řešení IS
specifikace chování (dynamika)
procesy, funkce (na konceptuální úrovni)
programy, kód (na fyzické úrovni)
Metodologie
při návrhu DB se postupuje v souladu s obecnými zásadami softwarového inženýrství v oddělených stádiích shora dolů
v každém stádiu volíme jistý model a metodu jeho tvorby, často pomocí podpůrného software CASE, od jedněch schémat ke druhým se přechází často algoritmicky (hlavně od konceptuálních k databázovým)
někdy integrujeme několik existujících IS (a tedy i DB) zdola nahoru
Objektově orientovaný přístup
je rozumné používat prostředky integrovaně - umožňují řešit specifikace v jednotlivých stádiích společně (k entitám by měl být přiřazen popis jejich chování pomocí jednoho aparátu)
o to se snaží zejména objektově orientovaný přístup (někdy dokonce konceptuální a databázová úroveň splývají)
Uživatelé DBS
správce dat - často odborný útvar zahrnující osoby odpovědné za autorizovaný přístup do databáze, udělující práva přístupu pro jednotlivé uživatele, sledují využívání databáze , modifikující přístupové cesty, …
aplikační programátoři - vytvářející uživatelské aplikace
Uživate