1 / 26

Adatbázis-tervezés konzultáció 2. Előadás Dr. Pauler Gá bor , egyetemi docens, ev.

Adatbázis-tervezés konzultáció 2. Előadás Dr. Pauler Gá bor , egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/9015-488 E-mail: pauler @ t-online.hu. Az előadás tartalma.

radha
Download Presentation

Adatbázis-tervezés konzultáció 2. Előadás Dr. Pauler Gá bor , egyetemi docens, ev.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Adatbázis-tervezés konzultáció 2. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/9015-488 E-mail: pauler@t-online.hu

  2. 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

  3. 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.egyembernekegyneve van) A szövegben lilával jelöljök őket (pl. egykönyvnekegycí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 A manuális adatbázis-tervezés problémái 1

  4. 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. Egyember (A)többkönyvet (B)kölcsönözhet , deegykönyv (B)egyember (A) általkö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 A manuális adatbázis-tervezés problémái 2

  5. A manuális adatbázis-tervezés problémái 3 • 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. egymenyasszonyhoz (A)egyvőlegény (B)tartozik, és egyvőlegényhez (B)egymenyasszony (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. Egykönyvnek (A)többkiadása (B)jelenik meg, deegykiadás (B)egykö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. Egyember (A)többkönyvet (B)kölcsönözhet, deegykönyv (B)egyember (A) általkö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)

  6. 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

  7. 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:

  8. 1:több tartozik 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ő (Mivagy 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: AnyaNeve=Júlia, GyerekNeve = Gyuri: 1db rekord

  9. 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ő Automatikus adatbázis tervezés 3

  10. 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 automatikus relációs adatbázis tervezés elméleti algoritmusa

  11. 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

  12. Az MS Access adatbázis-tervező varázslója 1 katt • 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őkneveit, 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 kat-kat katt katt katt katt

  13. katt Access adatbázis-tervező varázslója 2 katt katt katt 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: • 1vá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

  14. Access adatbázis-tervező varázslója 3 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öbbváros(City) tartozik • 1államhoz(State) többmegye(County) • 1államhoz(State) többszá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 1City 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

  15. Access adatbázis-tervező varázslója 4 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ű 120-140 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 26400 reprezentatív rekord kell! Megállapítjuk,hogy a varázsló inkább tanulási segédeszköz, de annak sem tökéletes 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

  16. 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

  17. 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: http://www.ca.com/us/products/product.aspx?id=260) • 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

  18. MS Visio grafikus felhasználói felülete 1 katt katt 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 húz

  19. (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() MS Visio grafikus felhasználói felülete 2 katt jobb katt • 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 jobb katt katt katt katt katt katt katt katt katt katt katt

  20. katt MS Visio grafikus felhasználói felülete 3 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 húz katt katt katt katt katt katt katt katt katt katt katt

  21. MS Visio grafikus felhasználói felülete 4 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

  22. MS Visio grafikus felhasználói felülete 5 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 összetettel-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 húz katt katt has/have been katt katt katt katt katt katt

  23. 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

  24. katt Adatbázis generáció Visio-ból katt 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 /* This SQL DDL script was /* Driver Used : Microsoft Document: D:\PTE-PMMFK\AdatBa SET QUOTED_IDENTIFIER ON go /* Create Proba1 database. use master go create database "Proba1" go use "Proba1" go

  25. katt Adatbázis visszafejtés Visioban katt 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

  26. Szakirodalom Relációs adatbázistervezés elméleti háttere: • Magyarul: http://www.itb.hu/ajanlasok/a4/index.html#toc • Jim relációs tervezési honlapja: http://www.dcs.bbk.ac.uk/~steve/rdanineteen/ • http://www.redbrick.dcu.ie/~foo/ssadm/exam-stuff/rda.pdf • http://gawain.soc.staffs.ac.uk/modules/level1/CE51500-1/s1w8/RELATIONAL%20DATA%20ANALYSIS.htm Automatikus relációs adatbázis tervező szoftverek: • 240 szoftvertervező CASE eszköz listája: http://www.cs.queensu.ca/Software-Engineering/tools.html ebből ennyi tudja a mintaadatok alapján történő tervezést: • +1DataElements: http://www.plus-one.com/de_users_guide.html (nincs shareware) Szakirodalom MS Visio-hoz: • MS Visio honlap: http://office.microsoft.com/en-us/visio/default.aspx • Microsoft (2002) Visio 2002 lépésről lépésre, Szakkiadó, Budapest • Gabrillo (2004) Microsoft Office Visio 2003, Microsoft, Budapest

More Related