Adatbázis-tervezés konzultáció

Adatbázis-tervezés konzultáció
2. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/

Az előadás tartalma Az adatbázis-tervezés automatizálási lehetőségei:
Elméleti bevezető A manuális adatbázis-tervezés problémái Az 1. Normálformánál A 2. Normálformánál Az automatikus relációs adatbázis-tervezés elmélete A Natural join fogalma A Natural joinolt tábla elemzése gyakorisági táblázatokkal Az automatikus tervezés algoritmusa MS Access adatbázis tervező varázslójának használata Mintapélda A mintaadatok importálása MS Accessbe Az adatbázis-tervező varázsló indítása Dekompozíció, tábla-elnevezések Független mezők táblához csatolása A kész relációs diagramm megtekintése Adatbázis tervezés és -generáció MS Visio Enterprise-ban Bevezető Grafikus felhasználói felület Alapbeállítások Táblák formázása Relációk formázása Új adatbázis generálása Visio-val Létező adatbázis tervének visszafejtése Visio-val Szakirodalom

A manuális adatbázis-tervezés problémái 1
Már említettük a Session1-ben, hogy a relációs adatbázisok tervezése rosszul struktúrált döntési probléma (Ill structured decision problem): Nem adható meg hozzá pontos algoritmus, amely garantálja, hogy az inputokból (gyakorlatban megfigyelhető nem fix hosszúságú adatstruktúrák) optimális outputokat (adatbázis-tervet) kapunk. Sőt, az sem biztos, mi az optimális output, hiszen az adatbázis rendszernek egymásnak ellentmondó követelmények közt kell egyensúlyozni (pl. gyorsaság  helytakarékosság) A normalizációs (Normalization) tervezési folyamat szöveges elemzésnek (Text Analysis) is nevezett első két lépésében rengeteg az olyan szubjektív elem, amely az adott alkalmazási területtel kapcsolatos, vagy egyszerűen a józan paraszti észen alapuló háttértudást követel (ezeket dőlten jelöljük): 1. Normálfoma: Dekompozíció A gyakorlatban megfigyelhető nem fix hosszúságú adatstruktúrákat szétbontjuk Egyedekre (Entity): Ezek azonos tulajdonságokkal leírható dolgok nagyszámú Előfordulását (Occourence) jelölik (pl. sok ember van, nemcsak egy) Néha nem könnyű eldönteni, mi számít nagyszámú előfordulásnak (pl. ha egy embernek max. 2 szeme van, a szemek nem biztos, hogy külön egyedet képeznek. Viszont az autóknak 4 kereke van, de lehet több is, az már igen) A szövegben pirossal jelöljük őket (pl. ember, könyv) A probléma adatai közt az egyedekhez Tulajdonságokat (Attribute) keresünk: Valamilyen tipusú (szám, szöveg, kép, hang) adott értékek Az egyedhez egy az egyben kapcsolódnak:(pl.egy embernek egy neve van) A szövegben lilával jelöljök őket (pl. egy könyvnek egy címe van) Néha egyáltalán nem könnyű eldönteni, mi minek a tulajdonsága: (pl. az Irányítószám a Cím tulajdonsága vagy a benne szereplő Településé?) Minden egyedből fix rekordhosszúságú Törzstábla (Master Table) lesz, Az egyedek tulajdonságaikból az egyes táblák mezői (Field) lesznek, Az egyedek előfordulásaiból a táblák rekordjai (Record) lesznek

2. Normálforma: Táblák elsődleges kulcsainak definiálása, összekapcsolásuk Elsődleges kulcs (Primary Key): olyan mező, amely az adott tábla rekordjait egyedileg azonosítja (ID), nincsenek benne megismétlődő (Unique), vagy üres (Null) értékek. Szöveges elemzésben narancssárga színnel ábrázoljuk: pl. SzemIgSzám Lehetnek: Természetes egyedi azonosítók (Natural Unique ID): Szem.ig.sz., TB-szám Összetett kulcsok (Compound Key): Több mezőből áll (pl.Név+Anyja neve), Mesterséges kulcsok (Artificial Key): automatikusan növekvő sorszám Néha nem könnyű választani a 3 megoldás közt, mert kölcsönös előnyeik-hátrányaik vannak: a természetes azonosító használatát tilthatja a jog, az összetett kulcs sok erőforrást fogyaszt és nem biztonságos, de ember számára éthetőbb, a mesterséges kulcs gyors és biztonságos, viszont ember számára nehezen értelmezhető Ezután leírjuk a táblák Kapcsolatait, Relációit (Relation): Ezek olyan hivatkozások két tábla (pl. A és B) közt, amelyek lehetővé teszik, hogy A tábla adatai birtokában visszakereshetők legyenek a B tábla csatlakozó rekordjai, így logikailag nem fix hosszúságú adatokat is tudunk tárolni, több táblába elosztva A relációkat Számosságukal (Cardinality) jellemezzük: A tábla hány rekordjához rekordjához a B tábla hány rekordja kapcsolódik (1:1, 1:több, több:több). A számosság mindig két oldalú, oda-vissza meg kell vizsgálni a A és B közt Néha nem könnyű eldönteni egy reláció számosságát, gyakran alábecsüljük, mert nem gondolunk a kivétles esetekre, amit szintén tárolni kell (pl. mindenki kapásból rávágja, hogy anya:gyerek = 1:több kapcsolat, de mi van ha a gyereket béranya hordja ki, aki nem egyezik petesejtet adóval?) A szöveges elemzésben a reláció nevét a kékkel, számosságot világos zölddel jelöljük:Pl. Egy ember (A) több könyvet (B) kölcsönözhet , de egy könyv (B) egy ember (A) által kölcsönözhető (egy időben) Néha nem könnyű eldönteni, hány relációt érdemes csinálni a táblák közt: e táblát minimálisan e-1 relációval lehet összefüggő rendszerbe kötni, ennél egy kicsit többet érdemes létrehozni, hogy támogassuk a gyakori visszakeresések gyorsítását. Értelmetlen a lehetséges legtöbb e×(e-1)/2-t létrehozni, mert a rengeteg idegen kulcs kezelése lelassítaná az írási/olvasási műveleteket, hiába lenne a visszakeresés nagyon gyors

Ezután megállapítjuk a relációk függési (Dependence) tulajdonságait: A tábla : B tábla = függő : függő (Mandatory:Mandatory) kapcsolatban van, ha A táblában csak akkor létezhet egy rekord, ha B táblában történik rá hivatkozás, és B táblában is csak akkor létezhet egy rekord, ha A táblában történik rá hivatkozás, kölcsönös függés áll fenn. Pl. egy menyasszonyhoz (A) egy vőlegény (B) tartozik, és egy vőlegényhez (B) egy menyasszony (A) tartozik. Nem létezhet menyasszony (A) vőlegény (B) nélkül, és nem létezhet vőlegény (B) menyasszony (A) nélkül A két rekord ilyenkor csak egyszerre hozható létre vagy törölhető le A tábla : B tábla = független : függő (Optional:Mandatory) kapcsolatban van, ha B táblában csak akkor létezhet egy rekord, ha A tábla egy rekordjához kapcsolódik, de A tábla rekordjai nem függenek B rekordjaitól, aszimmetrikus függés áll fenn. A tábla a Függetlenül létező/Szülő (Creator), B tábla a Leszármazott/Gyerek (Descendent/Child): pl. Egy könyvnek (A) több kiadása (B) jelenik meg, de egy kiadás (B) egy könyv (A) megjelenése. Nem létezhet kiadás (B) könyv (A) nélkül, de könyv (A) létezhet kiadás (B) nélkül (még nincs kiadva) Ilyenkor a rekordok létrehozására és törlésére a következő igaz: Nem lehet a „független” oldali táblában rekordot törölni, addig, amíg a „függő” oldalon hivatkozás történik rá. Pl. Nem törölhetek egy könyvet (A), amíg az összes kiadását (B) le nem töröltem Nem lehet a „függő” oldali táblához Kilógó rekordot (Outlier Record) hozzáírni, ami a „független” oldalon nem létező rekordra hivatkozik. Pl. Nem vehetek fel egy olyan kiadást (B), amely egy nemlétező könyvre (A) szól A tábla : B tábla = független : független (Optional:Optional) kapcsolatban van, ha A tábla rekordjai nem függenek B rekordjaitól, és B tábla rekordjai nem függenek A rekordjaitól. Kölcsönös függetlenség áll fenn. Pl. Egy ember (A) több könyvet (B) kölcsönözhet , de egy könyv (B) egy ember (A) által kölcsönözhető (egy időben). Létezhet könyv (B) kölcsönző ember (A) nélkül, és ember (A) is létezhet kölcsönzött könyv (B) nélkül. Mindkét táblában tetszőleges rekordokat hozhatok létre, vagy törölhetek le Néha a gyakorlatban nem könnyű eldönteni az egyedek egymástól való függését, mert nem egyértelműek az ok-okozati kapcsolatok (pl. egy Kft. résztulajdont szerezhet egy másik Kft.-ben, amely viszont az őt tulajdonló másik Kft.-nek is résztulajdonosa lehet)

Az automatikus relációs adatbázis tervezés elmélete 1
A fentiekből látható, hogy az automatizált relációs adatbázis tervezés nem egyszerű dolog, és viszonylag kevés gyártó kívál erre szoftveres megolást (lásd: Szoftverek) Automatizált tervezésre akkor van esély, ha: A gyakorlati adatstruktúrákhoz jelentős mennyiségű és jó minőségű mintaadatunk van: Nincs bennük sok hiányzó érték Nincs bennük sok elgépelés, vagy korruptálódott adat A különböző adatstruktúrák mezői a nevük és a tipusuk hasonlósága alapján megfeletethetők (pl. ami egyik adatforrásban RendszerDatum, az a másik adatforrásban is megvan RDatum vagy R_Date néven, dátumnak kinéző tipussal) Amelyeket már elektronikus formában tárolnak, vagy a megrendelő erőforrásokat biztosít az adatok normalizálatlan, széttagolt adatbázis táblákban történő rögzítésére (a legtöbbször nem adnak pénzt egy pocsék papír-alapú rendszer adatrögzítésére) Első lépésben, a normalizálandó rendszer összes jelenlegi tábláiból egyetlen gigantikus táblát gyártunk, Natural Joinok sorozatával: USACégbejegyzések Tulajdonos Cégnév Státusz Dick Cheney Haliburton Hazai cég Gyurcsányné Kutykurutty Inc. Off-shore NemzetköziÁtutalások Honnan Hova Összeg Dátum 11-Sep-01 31-Jan-02 CreditSuisseSzámlák Tulajdonos Számlaszám Egyenleg, $ Haliburton Kutykurutty Kft. 120 Al-kaida 400000 NaturalJoinTáblaFBI Személy Alelnök Cégnév Státusz Számla szám Egyenleg, $ Hova Összeg Dátum George Bush Dick Cheney Bill Clinton Al Gore Haliburton Hazai cég 9.64E+08 Gyurcsányné Kutykurutty Inc. Off-shore 120 31-Jan-02 Oszama Bin Laden Al-Kaida 400000 11-Sep-01 Dr. Pauler SANA021 Adabáziskezelés Elnökök Elnök Alelnök George Bush Dick Cheney Bill Clinton Al Gore TerrorSzervezetek Vezető Név Oszama Bin Laden Al-Kaida Dr. Pauler SANA021 Adabáziskezelés

Automatikus adatbázis tervezés 2
Természetes csatolás (Natural Join): SQL kódja: SELECT * FROM (Ugyfelek) NATURAL JOIN (Hitelek); (MS Access SQL-ben nincs ilyen, több lépésben lehet megoldani, más SQL-ben van) Adott egy Ugyfelek bal oldali (a lekérdezés FROM részében elsőként szereplő) tábla és egy Hitelek jobb oldali tábla Minden jobb oldali rekordot összehasonlít minden bal oldalival, a csatoló mező szerint egyező értékű rekordokat egybecsatolja Mindkét oldalról minden rekordot bevon az eredménybe, mindkét oldalról származó eredménymezőkben lehet Null Az egy oldali táblából származó sorok megtöbbszöröződhetnek az eredményben, mert a másik oldal több rekodjával is egyeznek, így nem maradnak egyedi kulcsok Eredmény rekordszám R: Max(J,B)  R  J+B Mindkét oldali tábla összes közös mezője szerint csatol, összes különböző mezőjét tartalmazza az eredményben A sok táblából páronként natural joinolt tábla: Struktúrája a problémában előforduló összes különböző (Mi vagy Mk, i, l = 1..n) adatmezőt tartalmazni fogja egyszer, A (j = 1..m) rekordjainak száma maximum az összes résztvevő táblák rekordszámának szorzata lehet, de ennél általában kisebb. Egy Excel Kimutatás segítségével gyakorisági táblát lehet készíteni a natural joinolt tábla bármely két mezöje (Mi és Ml) közt, amely a különböző értékkombinációjú rekordok előfordulási gyakoriságát méri. Az Mi mező legyen a kontingencia tábla soraiban, az Ml az oszlopaiban: tartozik 1:több Bal: Ugyfelek Ugyfel Nev Lakhely Aba Pécs Balogh Málom Cinege Olasz Gallai Siklós Garai Mohács Hegedűs Harkány Hoffman Pécsvárad Jánosi Kovács Komló Lakatos Sajó Takács Jobb:Hitelek Hitel Szam Ugyfel Nev 10 Balogh 11 Takács 14 Jakabfi 15 Hegedűs 16 Aba 17 Jánosi 18 Kovács 23 Sajó 25 Garai 29 Hoffman 93 Cinege Ugyfel Nev Lakhely Hitel Szam Aba Pécs 16 Balogh Málom 10 Cinege Olasz 93 Gallai Siklós Garai Mohács 25 Hegedűs Harkány 15 Hoffman Pécsvárad 29 14 Jánosi 17 Kovács Komló 18 Lakatos Sajó 23 Takács 11 AnyaNeve=Júlia, GyerekNeve = Gyuri: 1db rekord

Automatikus adatbázis tervezés 3
A gyakorisági táblabeli gyakoriságok elhelyezkedése a mezők közti reláció számosságát (Cardinality) adja meg: Ha a táblában soronként a gyakoriságok egy cellába tömörülnek, és oszloponként is egy cellába tömörülnek, akkor Mi : Ml = 1 : 1, vagyis kölcsönösen egyértelmű megfelelés áll fent a két mező értékei közt Ha a táblában soronként a gyakoriságok egy cellába tömörülnek, de oszloponként megoszlanak több cella közt, akkor Mi : Ml = több : 1 Ha a táblában oszloponként a gyakoriságok egy cellába tömörülnek, de soronként megoszlanak több cella közt, akkor Mi : Ml = 1 : több Ha a táblában a gyakoriságok soronként és oszloponként is megoszlanak több cella közt, Mi : Ml = több : több Ha mindkét mező esetén a Null (üres) értéket is beleveszem a gyakorisági táblába, ezek gyakoriságaiból a reláció függési típusára (Dependency) tudok következtetni: Ha mind Mi és Ml Null értékeinél lehetnek gyakoriságok, akkor Mi : Ml = független : független Ha Mi Null értékeinél lehetnek gyakoriságok, de Ml Null értékeinél nem, akkor Mi : Ml = függő : független Ha Ml Null értékeinél lehetnek gyakoriságok, de Mi Null értékeinél nem, akkor Mi : Ml = független : függő Ha Mi és Ml csak egyszerre kaphat Null értéket, és külön nem, akkor Mi : Ml = függő : függő

Az automatikus relációs adatbázis tervezés elméleti algoritmusa
Minden Mi mezőt összevetek egy másik Ml mezővel (i = 1..n-1, l = i+1..n) gyakorisági táblákban (összesen n×(n-1)/2 db) Keresem a mezők azon nagyobb csoportjait, amelyek függő:függő kapcsolatban állnak egymással, ezek lesznek az egyedek (Eg, g, h = 1..e) (1. Normálforma). A mezőcsoportok közt természetesen kell, hogy legyen átfedés. Minden egyedben keresek egy olyan Kg elsődleges kulcsmezőt (2. Normálforma): Amiben nincsenek ismétlődő értékek (gyakorisági táblában az összes gyakoriság 1), Amivel az egyed többi mezője (MEg) 1:több kapcsolatban áll: Kg : MEg = 1 : több (3. Normálforma) Ha nincs ilyen mező, akkor az egyed mesterséges elsődleges kulcsmezőt kap (2. Normálforma) Ezekután minden Kg elsődleges kulcsmezőt összevetek egy másik Kh elsődleges kulcsmezővel (g = 1..e-1, h = g+1..e) gyakorisági táblákban (összesen e×(e-1)/2 db): Az 1:1 kapcsolatban lévő kulcsok egyedeit összevonom egy egyedbe (1. Normálforma) Az 1:több kapcsolatban lévő egyedek közt relációt definiálok a több oldali egyedben idegen kulcsmező kijelölésével és megfelelő függés/függetlenségi beállításokkal (4. Normálforma) A több:több kapcsolatban lévő egyedek közé relációs egyedet teszek, ami idegen kulcsokat tartalmaz (5. Normálforma) Igyekszem az e db egyedet minimális számú (e-1 db) relációval összekötni, a redundáns relációkat letörlöm (4. Normálforma) Mindezek eredményeképpen a rendszer ER diagrammja felrajzolható Lássuk, hogy megy ez a gyakorlatban!

Az MS Access adatbázis-tervező varázslója 1
A Stores.xls fájlban egy NY, PA, OH álla-mokban tevékenykedő áruházlánz 160 üzletének natural joinolt adatai találhatók. Első lépésként, importáljuk ezt Accessbe (a végeredményt lásd: Stores.mdb): Fájl|Külső adatok|Import menüvel indítsuk el az importáló varázslót! Válasszuk ki az Excel fájlt, és jelöljük be, hogy oszlopfejléc az első sorban van Tovább gombbal lépve, bejelöljük, hogy új táblát szeretnénk Majd felülírhatjuk a mezők neveit, ha kell Majd magunk választunk elsődleges kulcsot (StoreID) Majd megadjuk az importált tábla nevét: Stores Majd a Befejez gombbal zárjuk a varázslót Erre a tábla megjelenik a Táblák listában Duplán kattintva rajta, megnézhetjük a tartalmát katt katt katt kat-kat katt katt katt katt

Access adatbázis-tervező varázslója 2
A Stores tábla kijelölése után Eszközök| Analizálás|Tábla menüvel indíthatjuk a Táblaanalizáló varázslót: Ez a gyakorisági táblás módszerrel meg-próbálja automatikusan dekompozícionál-ni a táblát, ha bejelöljük varázsló dönt-öt A széttagolt táblákat kijelölve a gomb-ra kattintva nevezhetjük el őket (az elne-vezésben segít, hogy a varázsló mit jelölt elsődleges kulcsnak a táblában, és ne adjuk meg már létező tábla nevét!) Ha úgy gondoljuk, valamely mezőt rossz táblába tette, egérrel áthúzhatjuk a táblák közt, illetve több mezőt egyszerre kijelöl-ve Shift+katt-tal, egy üres helyre húzva őket, új táblát készít belőlük A kézzel kibontott táblában gombbal jelölhetünk ki elsődleges kulcsot, ha nem lenne alkalmas mező, gombbal adha-tunk hozzá mesterséges kulcsot Az eredményben látható, hogy a varázsló a főbb összefüggéseket jól bontja ki: 1 városhoz(City) több üzlet(Store) tartozik 1 régióhoz(Region) több város(City) 1 megyéhez(County) több város(City) Azonban a bontás nem tökéletes: Nem veszi észre az állam(State):régió (Region)=1:több kapcsolatot, mert van olyan állam (OH), amiben csak 1 régió van, és ez megzavarja Nem bontja ki a telefonszámkörzet(Area): város(City) = több:több kapcsolatot A problémás mezőket mindig a tábla el- sődleges kulcsa elé rakja! katt katt katt katt katt katt katt katt

Ezenkívül nem ír fel olyan rendundáns relációkat, amelyek a lekérdezések gyorsításához kellenének: 1 államhoz(State) több város(City) tartozik 1 államhoz(State) több megye(County) 1 államhoz(State) több számkörzet(Area) A varázsló viszont detektálja, hogy a város: telefonszámkörzet kapcsolat kevés kivé-teltől eltekintve majdnem több:1 kapcsolat: 3 olyan City van csak, ahol több Area kód is jelen van. Ha ezek eltűnnének, az el-sődleges kulcs (City) egyértelműen meg-határozná az Area-t, így az a City tábla rendes mezője lehet (ld. 3.Normálforma) A varázsló feltételezi, hogy a kilógó esetek elgépelés miatt vannak, és kinyit egy ablakot, amiben lehetőséget ad arra, hogy 1 City számára kiválasszunk a több előforduló közül 1 érvényes Area kódot, visszanyomva a City:Area kapcsolatot több:több kapcsolatból több:1 kapcsolatba Az adattisztítási műveletek végeztével a varázsló felkínálja, hogy készítsen-e olyan lekérdezést, amely egy nézettáblában összerakja az eredeti natural joinolt táblát a szétbontott táblákból, és azt átnevezve más névre,beáll a helyére az adatbázisban A varázslót befejez gombbal bezárva bele-írja az adatbázisba a szétbontott táblákat és a köztük lévő relációkat, meghagyva az eredeti táblát is Eszközök|Kapcsolatok menüben megte-kinthető a szétbontott szerkezet relációs diagrammja, és kézzel tovább finomítható! katt katt katt katt katt katt katt

Ha a varázsló elégséges adat híján nem bontott ki egy relációt (pl. állam(state): régió(Region) = 1:több), a szétbontott táblát (Regions1) kijelölve, a varázslót újraindítva, azt kézzel tovább bonthatjuk: Ilyenkor a táblából kibontandó mezőket Shift+katt-al kijelöljük, és egérrel kihúz-zuk egy üres helyre, ahol új táblát alkot-nak, amit gombbal elnevezhetünk, gombbal pedig elsődleges kulcsot jelölhetünk ki benne. Az MS Access adatbázis-tervező varázslójának előnyeit és hátrányait a következőkben foglalhatjuk össze:  Képes automatikus dekompozíciót végrehajtani, ha a natural joinolt táblában elégséges mennyiségű és reprezentati-vitású (Representativeness) adatot kap: vagyis az adatok minden, a valóságban gyakran előforduló kombinációjából kap a gyakoriságukkal arányosan rekordokat  Automatikusan detektálja az elsődle-ges kulcsnak alkalmas mezőket  Automatikusan detektálja, ha egy tábla egy mezőjét nem határozza meg egyértelműen a tábla elsődleges kulcsa (3. Normálforma megsértése), és ilyenkor a kilógó adatok módosítását javasolja  csak 1:több, független:függő kapcsola-tokat tud felismerni, igy messze nem használja ki a gyakorisági táblás elemzés összes lehetőséget  n szétbontott egyedet n-1 relációval köt össze, nem kínálja fel a lekérdezéseket katt katt húz gyorsító redundáns relációk létrehozását, mert ehhez be kellene gyűjteni adatokat a felhasználótól arról, hogy mely mezőből (belépési pont) mely mezőt (kilépési pont) milyen gyakorisággal akar lekérdezni.  Abszolút használhatatlan, ha nincsen elégséges mennyiségű mintaadat az elemzéshez, vagyis az estek 95%-ában, például, amikor klasszikus papír alapú rendszerre fejlesztünk rá. Igazából olyan, már régóta működő adatbázisokat lehet vele kijavítani, amiben kisebb normalizá-ciós hibák vannak.  Általában nincs elég adat,ha üzleti mé-retű táblás rendszert akarunk normalizálni vele, mert n tábla szétbontá-sához átlagosan 16/6×n×(n-1) reprezen-tatív rekord kell az alábbi tábla alapján: 100 táblához reprezentatív rekord kell! Megállapítjuk,hogy a varázsló inkább tanulási segédeszköz, de annak sem tökéletes

Adatbázis tervezést részlegesen támogató CASE-eszközök: MS Visio
A fentiekből látszik, hogy jelenleg nincs olyan szoftver, amely teljesen automatizálná az adatbázis-tervezést. Sok munkával létre lehetne ugyan hozni (a relációs elemzés a mesterséges intelligencia kutatások egyik jelentős területe), de csak akkor működne jól, ha hatalmas munkával belevinnék a józan paraszti észnek (Common Sense) nevezett tudásbázis jelentős részét, pl: „A Gergely és a Julián naptár egymáshoz képest 15 nap eltérést mutat” „Egy villanykapcsolónak két állása van” „Egy nő nem eshet egyszerre több férfitól teherbe, de 1 szuka több kankutyától igen” Egy gyakorlott adatbázis-tervező viszont ennél jóval kisebb erőfeszítéssel bőven megtervez bármily bonyolult adattárházat Ezért fontosak a számítógéppel segített szoftvertervezésnek (Computer Aided Software Engineering, CASE) azon adatbázis tervezést részlegesen támogató eszközei, amelyek lehetővé teszik, hogy az emberi kreativitás és intuíció maximális gyorsasággal dolgozzon az adatbázis-tervezés során. A következőkben ezekkel foglalkozunk. Az MS Visio a Microsoft Office csomag része, és általános célú tervezési diagramm rajzoló szoftver, melynek mi a keresztfunkcionális folyamatábrájával (Business Process Diagram, BPD) és az egyedkapcsolati diagrammjával (Entity Relationship Diagram, ERD) foglalkozunk. Az MS Visio önmaga egy kis erőforrás-igényű programocska (150MB telepítve), de a Microsoftra jellemző módon nem telepíthető a .Net környezet (9MB) és a Visual Studio (1630MB) nélkül. Aki kis erőforrás-igényű CASE eszközt keres, az jobban jár az ERWin-nel (ld: Az MS Visio 3 változatban létezik: Standard: ebben csak BPD van, ERD nincs Professional: ebben már van BPD és ERD is, létező adatbázisokból képes visszafejteni (Reverse Engineering, RE) az ERD-t, de nem tud az ERD-ből automatikusan új adatbázist generálni Enterprise: ez már képes új üres adatbázist generálni ERD-ből, Accessben, SQL Server-ben, stb. Viszont ez nem része az MS Hallgatói csomagnak

MS Visio grafikus felhasználói felülete 1
A Visio-t más Office termékekhez hasonlóan kell telepíteni, ezért ezt nem tárgyaljuk. Indítás után ki kell választani a diagramm kategóriát (Category) / mintát (Template): ERD-hez: Database Database Model Diagram(Metric) BPD-hez: Business Process Crosfunctional Flowchart(Metric) A Visio kezelésével kapcsolatban mindkét fajta diagram esetén alapszabály, hogy ne a 0-ról kezdjünk diagrammot építeni, mert borzasztó sok időt elvisznek az alap for-mázások, hanem legyenek jól leformázott sablonjaink: MintaBPD.vsd, MintaERD.vsd A következőkben a BPD rajzolása esetén ér-vényes felhasználói felületet ismertetjük: Az elinduló BPD varázslóban válasszunk horizontális (Horizontal) funkciósávokat Adjuk meg a számukat(Number of Bands) Legyen címsor(Include Titlebar),OK gomb A képernyő jobb oldalán megjelenik az üres diagramm,balon rajzelem (Shape) paletták: Basic flowchart:Folyamatábra elemek Process( ): folyamat Decision( ): döntés Cross Funct.:BPD-specifikus elemek Functional band( ): funkciósáv Separator( ): mérföldkő Az elemek egérrel húzhatók a diagrammba Duplakattra írható beléjük felirat Feliratozott nyíl-elemekkel összeköthetők a kapcsolódási pontjaiknál(×) A diagramm File|Save as menüvel menthe-tő *.vsd diagramm fájlba, vagy *.gif képbe katt katt katt katt katt katt katt katt katt katt húz

(A Varlist típus sok elemű szöve-ges értéklista) Format: formá-zó maszk, pl. „00.00” Value:alapértel-mezett érték Prompt:felirat Lang.:nyelv A sablonunkban 4 előszínezett és feliratozott nyíl van a Session1 -ben tárgyaltak szerint: Igen:() Nem:() Lép: előrelépés időben () Újra:ciklus visz-szacsatolás() Az elemeken jobbkattolva, a tulajdonsága-ikat szerkeszthetjük. Alapértelmezésben az elemeknek három tulajdonsága van: Cost(Text):költség Duration(Text):időtartam Resources(Text):igényelt erőforrások Mivel ezek nem túl informatívak, a saját sablonunkban (lásd.: MintaBPD.vsd) csak folyamatkezdő( ) és -vég( ) elemeknél hagyjuk meg, a tevékenység( ) és dön-tés elemeknél( ) a Define gombbal új egyedi tulajdonságokat adtunk hozzájuk: UnitCost(Currency):egységköltség DurationSec(Number):időtartam, sec EntityUsages(VarList):egyedhaszná-latok: Session1–ben már említettük, hogy minden tevékenységhez/ döntés-hez egyedek kapcsolhatók az ERD-ről Create: létrehozás, Read: olvasás, Write: írás, Update: módosítás, Nullify: kiürítés, Delete: törlés jogosultságokkal. Ez az alapja a felhasználó felület tervezésnek PropertyUsages(VarList):az egyedek tulajdonságaihoz történő hozzáférési jogosultságok szabályozása Min/MaxFreqPerDay(Number):napi min/max gyakoriság ciklusos dologhoz FormUsages(VarList):munkaképer-nyő használatok, jogosultságokkal Az egyedi tulajdonságok (Custom Proper-ties) ablakban a következőket állíthatjuk: Label: a tulajdonság címkéje, Type: tipusa:Text,Number,Date,Currency katt jobb katt jobb katt katt katt katt katt katt katt katt katt katt katt

ERD rajzolása esetén a felhasználói felület jó-val bonyolultabb(sablont ld:MintaERD.vsd): Jobb oldalon a diagramm, balon a rajzelem paletta(Entity Relationship(Metric)) jele-nik meg, innen húzhatjuk be az elemeket Az elemeken jobb/duplakattolva külön ab-lakban jelenik meg a tulajdonságszerkesztő az elemekbe közvetlenül nem írható szö-veg, ez igen zavaró és helypazarló dolog File|Save as menüvel menthető az ERD *.vsd diagramm fájlba vagy *.gif képbe Az alapértelmezett formázásokhoz képest a MintaERD.vsd sablonban egyedileg állítjuk: Database|Options|Drivers menüben a cél adatbázist MSSQL-re Database|Options|Document menüben: A Relations fülön adjuk meg, mit mutasson a relációknál: Relationships: kapcsolati vonal Crow’s feet:csirkeláb több oldalon Referential action:ref.integritás.ell General fülön adjuk meg a tervformát: Relational:mutassa a mezőtipust Conceptual names: logikai nevek Table fülön adjuk meg a táblaformát: Datatypes=Show physical:fizikai adattípusok használata a terven A Visio ERD mind az adatbázis logikai modelljét (egyedek, tulajdonságok, logikai adattipusok), mind a cél adatbázisra szóló fizikai modellt (táblák, mezők, cél adatbázis fizikai adattípusai) tárolja. Az ERD-re logikai neveket érdemes kiírni (táblanevek egyes számban), de fizikai adattípusokkal katt katt katt katt húz katt katt katt katt katt katt katt katt katt katt katt

Az egyed dobozán duplakattolva előjön a Database Properties panel: Definition:az egyed fizikai (Physical) (töb-bes számú) és logikai (Conceptual) nevei Columns: a tulajdonságok/mezők leírása: Physical Name: mezőnév DataType:adattipus:bit,int,varchar(n), float(n,d),Datetime Ügyeljünk, hogy a stringhosszokat 4,8,16,32-re szabjuk, és a mesterséges elsődleges kulcshoz írjuk oda az autosorszámozó identity-t Req’d: kötelező kitölteni PK: elsődleges kulcs, több mező kijelö-lése összetett elsődleges kulcsot jelent Move Up/Down: mezősorrend váltás Edit gomb: mező spec. tulajdonságai: Definition|Default: alapértelme-zett érték, függvény is lehet Data Type: felhasználói adattipus (User Defined Type,UDT) is lehet Check:ellenőrző szabály a mezőre PrimaryID: elsődleges kulcs formázás Indexes: 1 vagy több mező együttes felin-dexelése egyedi (Unique) vagy ismétlődő értékű (Non-unique) indexszel (Index): olyan, a felhasználónak nem hozzáférhető, rekordmutató(Pointer) tipusú mező, mely a rekordok viszszakeresését gyorsítja, ezért a gyakran lekérdezett relációk idegen kul-csait szoktuk indexelni (elsődleges kulcsok alapban egyedi indexesek). A rekordok tör-lését és beszúrását viszont lassítja, ezért indexet csak indokolt esetben használjunk Triggers:mező módosulásakor lefutó kód katt katt katt katt katt katt katt katt katt katt katt katt katt katt

Az relációs összekötőn duplakattolva előjön a Database Properties panel: Definition: a 2 tábla csatolt mezőit egérrel összehúzzuk,Associate gombbal bekapcs Name: a reláció logikai és fizikai nevei Verb phrase: az 1 oldal logikai neve Inverse phrase:több oldal logikai neve Itt súlyos programozási hiba található a Visioban: ha 2 tábla 2 vagy több relá-cióval kapcsolódik párhuzamosan (pl. az időszakokat leíró NapTipusTort tábla KezdHetNap és VegHetNap ide-gen kulccsal hivatkozik a HetNapNev tábla HetNapNevID elsődleges kulcsá-ra),azonos logikai neveket kapnak, ami később fordítási hibát okoz. Ezt elkerü-lendő írjuk át másra a verb phrase-üket: has/had/had been, stb. Miscellaneous:egyéb beállítások: Cardinality:a reláció több oldalán hány rekordnak kell hivatkozni az 1 oldal egy rekordjára: Zero or more:lehet, hogy 1 sem One or more:legalább 1 Relationship type=non-identifying:a több oldalon levő idegen kulcs ne le-gyen a több oldali tábla összetett el-sődleges kulcsának a rész-mezője Referential action:referenciális integritás: No action: lezárva, független oldalon nem enged törölni hivatkozott rekordot, függőn írnhat hozzá kilógó rekordot Cascade:függő rekordot rekurzíve töröl Do not enforce:ellenőrzés kikapcsolva katt katt katt katt katt húz katt has/have been katt katt katt katt katt

Adatbázis generáció Visio-ból
Az Enterprise változat képes a kész ERD-ből (lásd: MintaERD.vsd) legenerálni egy üres adatbázist létrehozó *.DDL(Data Definition Language) SQL-kódot a Database|Gene-rate menüben (lásd:MintaERD.DDL), amivel borzalmas mennyiségű manuális munkát takarít meg, ezért szeretjük: Lefordítja az ERD-t és elvégzi a logikai és fizikai validációját (a Database|Options| Drivers menüben beállított adatbázisban), a hibákat kijelzi az Output ablakban: Sajnos, a legkevésbé sem informatív fordítási hibaüzeneteket írogatja ki Tapasztalati alapon ki lehet találni, mivel van baja a tervben A figyelmeztetésekre (Warning) még megcsinálja a fordítást, csak a súlyos hibákra (Error) nem Generate DDL/Generate new database: DDL kódot vagy kész adatbázist gyártson File name: DDL kód szövegfájl neve Installed Visio Driver=MS SQL: milyen adatbáziskezelőnek írja scriptet Database:a létrehozandó adatbázis neve Review tables:generálandó táblák listája View DDL script?=Yes: a DDL script meg-tekintése szövegszerkesztő ablakban A scriptet (MintaERD.DDL) adatbáziskezelő-ben futtatva az üres adatbázis létrejön katt katt katt katt katt katt katt katt /* This SQL DDL script was /* Driver Used : Microsoft Document: D:\PTE-PMMFK\AdatBa SET QUOTED_IDENTIFIER ON go /* Create Proba1 database. use master create database "Proba1" use "Proba1"

Adatbázis visszafejtés Visioban
A Professional és Enterprise változat képes rá, hogy 1 létező adatbázisból (ld:Stores.mdb) visszafejtse (Reverse Engineer) a tervét és ezt beletegye egy már létező tervsablonba (ld:MintaERD.vsd) a Database|Reverse Engineer menüben: Installed Visio Drivers=Access:adatbázis meghajtó kijelölése Data Source=Access:adatforrást megad Filename=Stores.mdb: az adatbázisfájl User/Password:felhasználói név és jelszó, ha nincs, hagyjuk őket üresen Object types:a visszafejtendő adatbázis objektumok (jelöljünk be mindent!) Select tables:jelöljük be a visszafejtendő táblákat Review selection:a visszafejtendő táblák és az őket alkotó objektumok áttekintése Add shapes curr. page=Yes: új egyedek hozzáadása a terv- hez, Finish gomb A kibővített terv: ERDReverse Ügyeljünk rá, hogy Visio ERD-ben az egyedek dobozai nem fedhetik át egymást, ilyenkor a Visio elkez- di vadul elpakolni őket összekavar- va a teljes tábla elrendezést. Ezért mindig legyen elég üres helyünk a terven, amit az oldalméret növelé- sével érhetünk el File|Page setup menüben. Az ajánlott oldalméret nagyobb tervekhez az A1-es katt katt katt katt katt katt katt katt katt katt katt katt katt

Szakirodalom Relációs adatbázistervezés elméleti háttere:
Magyarul: Jim relációs tervezési honlapja: Automatikus relációs adatbázis tervező szoftverek: 240 szoftvertervező CASE eszköz listája: ebből ennyi tudja a mintaadatok alapján történő tervezést: +1DataElements: (nincs shareware) Szakirodalom MS Visio-hoz: MS Visio honlap: Microsoft (2002) Visio 2002 lépésről lépésre, Szakkiadó, Budapest Gabrillo (2004) Microsoft Office Visio 2003, Microsoft, Budapest

Adatbázis-tervezés konzultáció

Hasonló előadás

Az előadások a következő témára: "Adatbázis-tervezés konzultáció"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

Adatbázis-tervezés konzultáció

Hasonló előadás

Az előadások a következő témára: "Adatbázis-tervezés konzultáció"— Előadás másolata:

Hasonló előadás

Projectumról

Visszajelzés