Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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.

Hasonló előadás


Az előadások a következő témára: "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."— Előadás másolata:

1

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

3 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

4 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):Session1 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

5 A manuális adatbázis-tervezés problémái 2 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

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

7 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

8 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)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: Elnökök ElnökAlelnök George Bush Dick Cheney Bill ClintonAl Gore USACégbejegyzések TulajdonosCégnévStátusz Dick CheneyHaliburtonHazai cég GyurcsánynéKutykurutty Inc.Off-shore CreditSuisseSzámlák TulajdonosSzámlaszámEgyenleg, $ Haliburton Kutykurutty Kft Al-kaida NemzetköziÁtutalások HonnanHovaÖsszegDátum Sep Jan-02 TerrorSzervezetek VezetőNév Oszama Bin LadenAl-Kaida Dr. Pauler SANA021 Adabáziskezelés NaturalJoinTáblaFBI SzemélyAlelnökCégnévStátusz Számla szám Egyenleg, $HovaÖsszegDátum George Bush Dick Cheney Bill ClintonAl Gore Dick Cheney Haliburton Hazai cég E+08 Al Gore Gyurcsányné Kutykurutty Inc. Off- shore E+0831-Jan-02 Oszama Bin Laden Al-Kaida E+0811-Sep-01 Dr. Pauler SANA021 Adabáziskezelés

9 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ő (M i vagy M k, 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 (M i és M l ) közt, amely a különböző értékkombinációjú rekordok előfordulási gyakoriságát méri. Az M i mező legyen a kontingencia tábla soraiban, az M l az oszlopaiban: Bal: Ugyfelek Ugyfel Nev Lakhely AbaPécs BaloghMálom CinegeOlasz GallaiSiklós GaraiMohács HegedűsHarkány HoffmanPécsvárad JánosiHarkány KovácsKomló LakatosPécs SajóOlasz TakácsSiklós Jobb:Hitelek Hitel Szam Ugyfel Nev 10Balogh 11Takács 14Jakabfi 15Hegedűs 16Aba 17Jánosi 18Kovács 23Sajó 25Garai 29Hoffman 93Cinege Ugyfel Nev Lakhely Hitel Szam AbaPécs16 BaloghMálom10 CinegeOlasz93 GallaiSiklós GaraiMohács25 HegedűsHarkány15 HoffmanPécsvárad29 14 JánosiHarkány17 KovácsKomló18 LakatosPécs SajóOlasz23 TakácsSiklós11 tartozik 1:több AnyaNeve=Júlia, GyerekNeve = Gyuri: 1db rekord

10 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 M i : M l = 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 M i : M l = 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 M i : M l = 1 : több Ha a táblában a gyakoriságok soronként és oszloponként is megoszlanak több cella közt, M i : M l = 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 M i és M l Null értékeinél lehetnek gyakoriságok, akkor M i : M l = független : független Ha M i Null értékeinél lehetnek gyakoriságok, de M l Null értékeinél nem, akkor M i : M l = függő : független Ha M l Null értékeinél lehetnek gyakoriságok, de M i Null értékeinél nem, akkor M i : M l = független : függő Ha M i és M l csak egyszerre kaphat Null értéket, és külön nem, akkor M i : M l = függő : függő

11 Az automatikus relációs adatbázis tervezés elméleti algoritmusa Minden M i mezőt összevetek egy másik M l 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 (E g, g, h = 1..e) (1. Normálforma). A mezőcsoportok közt természetesen kell, hogy legyen átfedés. Minden egyedben keresek egy olyan K g 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 (M Eg ) 1:több kapcsolatban áll: K g : M Eg = 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 K g elsődleges kulcsmezőt összevetek egy másik K h 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!

12 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

13 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.Stores.xls Első lépésként, importáljuk ezt Accessbe (a végeredményt lásd: Stores.mdb): 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 kat-kat

14 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

15 Access adatbázis-tervező varázslója 3 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

16 Access adatbázis-tervező varázslója 4 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 húz katt 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

17 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

18 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

19 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.vsdMintaBPD.vsdMintaERD.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 húz katt

20 MS Visio grafikus felhasználói felülete 2 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:MintaBPD.vsd –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őlSession1 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 jobb katt jobb katt jobb katt (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:Session1 Igen:(  ) Nem:(  ) Lép: előrelépés időben (  ) Újra:ciklus visz- szacsatolás(  ) katt

21 MS Visio grafikus felhasználói felülete 3 ERD rajzolása esetén a felhasználói felület jó- val bonyolultabb(sablont ld:MintaERD.vsd):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: MintaERD.vsd 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 húz katt

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

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

24 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

25 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:MintaERD.vsdMintaERD.DDL 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önMintaERD.DDL 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 katt

26 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:Stores.mdbMintaERD.vsd Installed Visio Drivers=Access:adatbázis meghajtó kijelölése Data Source=Access:adatforrást megad Filename=Stores.mdb: az adatbázisfájlStores.mdb 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: ERDReverseERDReverse Ü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

27 Relációs adatbázistervezés elméleti háttere: Magyarul: Jim relációs tervezési honlapja: 1/s1w8/RELATIONAL%20DATA%20ANALYSIS.htmhttp://gawain.soc.staffs.ac.uk/modules/level1/CE /s1w8/RELATIONAL%20DATA%20ANALYSIS.htm 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)http://www.plus-one.com/de_users_guide.html 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 Szakirodalom


Letölteni ppt "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."

Hasonló előadás


Google Hirdetések