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

1. Adatbázis-tervezés konzultáció 3. 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 • Oracle Designer • Fogalma, telepítése • Grafikus felhasználói felület • Tervezési folyamata • Új alkalmazás hozzáadása • Üzleti folyamat diagramm • Egyed kapcsolati diagramm • Funkció hierarchia diagramm • Szerver modell diagramm • Programodul-jelöltek generálása • Programmodulok generálása • Programmodulok kézi finomítása • A kész űrlapok futtatása • A Designer értékelése • Advanced Database Diagram (ADD) • ADD Jelölésrendszer, példa az űrlapszekciók adatforrásaira • Példa multidimenzionális-hierarchikus (MDH) ADD-re • Az MDH-ADD rendszer működése • Hierarchikus dimenziók • Közös dimenziók • Alkalmazás-specifikus dimenziók • Rendszer dimenzió • Törzs és tranzakció szintek • Felfele elágazó dimenziók • Üzleti folyamatok • Funkciósávok, mérföldkövek • Eljárás hierarchia • Űrlaptervek, és szekció adatforrások • Az MDH-ADD rendszer értékelése, példa • MDH nélküli megoldás • Megoldás MDH-val Szakirodalom

3. Oracle Designer fogalma, telepítése 1 katt Az Oracle Designer az adatbázis-tervezési tevékenység teljes folyamatát - az utomatikus relációs elemzés kivételével -átfogóan támogató CASE eszköz, amely az Oracle relációs adatbázis szerveren (Orac-le Server) tárolt többfelhasználós tervtárra (Oracle Repository) épül, és az Oracle Developer Suite telepítőcsomag (ld.:http://www.oracle.com/technology/products/designer/index.html) része. A Designer telepítésének előfeltételei: • Oracle Server és Client szoftver telepítve: http://www.oracle.com/database/index.html • Rendszergazdai (Sysdba, System) felhasználói jogokkal rendelkezzünk benne • Új üres adatbázis létrehozása a szerveren a Repository tárolására • A Repository objektumait létrehozó, az aktuális verzió telepítőcsomagjához mellékelt *.sql scriptek lefuttatása • Extra jogosultságok megadása a reposito-ry-ba beléptetni kívánt Oracle server felhasználók (pl. OracleUser) számára • Designer telepítő Setup.exe futtatása Designer indítása Designer ikonnal: • Username/Password: repos_manager felhasználóként/jelszóval bejelentkezés • Database: repository adatbázisnév=data1 Repository Administration Utility(RAU) indít: • User Maintenance|User|Add gomb( ) új repository felhasználó definiálása • Extra jogokkal felruházott, már létező sima szerver felhasználó (pl. OracleUser) lehet • Minden bejelölhető jog megadása sql> connect sys/******@data1 as sysdba; sql> grant create session to oracleuser; sql> grant connect, resource to oracleuser; sql> grant create table to oracleuser; sql> grant create view to oracleuser; sql> grant create procedure to oracleuser; sql> grant create synonym to oracleuser; sql> grant create sequence to oracleuser; sql> grant select on dba_rollback_segs to oracleuser; sql> grant select on dba_segments to oracleuser; katt katt katt katt katt kat kat katt katt katt katt

4. Oracle Designer, fogalma telepítése 2 katt Ezután indítsuk el a Repository Object Navi-gator-t (RON). Ez a tervtár nézegetője: • Baloldalt van a szerkezetét leíró objektumfa • Jobb oldalon az éppen megnyitott objektum tulajdonságai (Property) láthatók • Jelöljük ki a fában a Global Shared Work-area munkaterület-objektumot, és a ( ) gombbal hozzunk benne létre egy új tárolót (Container), ahova az új felhasználó tervei kerülnek majd. A neve (Name) egyezzen meg a felhasználó nevével (OracleUser) • A File|Access rights menüvel nyissuk ki a hozzáférési jogok ablakát, ahol bal oldali objektum hierarchiában válasszuk ki az imént létrehozott Containert (OracleUser) • A felhasználó listára kattintva rendeljük hozzá a hasonló nevű felhasználót • A Grant Access gombbal nyissuk ki a hozzá tartozó jog-megadási ablakot, és jelöljük be az összes jogot: Select, Admin, Insert, Update, Delete, stb. Ezután indítsuk újra a Designert, jelentkezzünk be az újonnan definiált felhasználóként: • Username/Password: OracleUser felhasználóként/jelszóval bejelentkezés • Database: repository adatbázisnév/útvonal Ezzel a Designer használatra kész katt katt katt katt katt katt katt katt katt katt katt

5. ADesigner adatbázis-tervezési eszközei: Business Process Diagram (BPD): a célszervezet üzleti folyamat diagrammja Entity Relationship Diagram (ERD): az üzleti folyamat funkcióit kiszolgáló relációs adatbázis rendszer logikai terve Function Hierarchy Diagram (FHD): a BPD-n megjelenő tevékenységeket vagy döntéseket hiererachikusan szétbontja elemi üzleti funkciókra (Elementary Business Functions, EBF), amelyek egy munkaképernyőt képező algoritmikus folyamatlépések, és az ERD-ről egyed- illetve tulajdonsághasználati jogosultságok rendelhetők hozzájuk Data Flow Diagram (DFD): az üzleti folyamat mentén mozgó adatsruktúrák előtervezésére szolgáló eszköz, használata átugorható a következővel: Database Design Transformer (DDT): az ERD-n megjelenő logikai adatbázis tervet alakítja szerver modellé (Server Model, SM), ami az adatbázis fizikai terve Oracle táblastruktúrák,relációk és SQL formájában Application Design Transformer (ADT): elektronikus űrlapokat generál az FHD-ból az adatbázis felhasználói felületeként Design Editor (DE): a kész adatbázis és felhasználói felület terv objektum hierarchi-ájának, tulajdonságainak szerkesztője Matrix Diagram (MD): a BPD, FHD és ERD tervek kombinálása egy sokdimenzi-ós, dinamikus struktúrájú kimutatás táblá-ban, tömeges áttervezési műveletekhez Designer felhasználói felülete 1 katt katt katt katt katt katt katt katt katt

6. A Designer 2 szálon (Thread) tervez: • Adatbázis tervezése • Felhasználói felület tervezése Mindegyik szál 3 szintű (Level): • Felső: Logikai tervek az BPD, FHD, ERD tervezőkben • Közép: A 2 Design Transformer fizikai tervekké alakít logikaiakat • Alsó: A 2 Generate program megvalósítja a fizikai terveket az Oracle Forms űrlapkezelőben, illetve az Oracle Server-en A 2 szálat a következő helyen kötjük: • Az FHD-ben meg kell adni, hogy az elemi üzleti függvények, mint képernyők az ERD-ről milyen e-gyedek milyen tulajdonságait mi-lyen jogosultságokkal használják • Ezután a 2 szál automatikusan összekapcsolódik Lássuk az alkalmazás-tervezés lépéseit részletesen a Designer grafikus felhasználói felületén: 1.LÉPÉS:elindítjuk a designert, belog-olunk normál felhasználóként (pl.OracleUser) a repository adat-bázisba (pl.Data1) 2.LÉPÉS:elindítjuk a RON-t( ), és a bal oldali objektum hierarchiába az OracleUser konténert kijelölve ( ) hozzáadás gombra új alkalmazást (Application System) kérünk, majd elnevezzük (pl.Ovoda1) • Üzleti Folyamat Diagramm: • Szervezeti Egységek • Folyamatlépések • Indító események • Eredmények Designer tervezési folyamata 1 Gyökérfunkció • Funkció Hierarchia Diagramm: • Gyökérfunkció • Alfunkciók • Egyed-tulajd. hozzárendelés • Egyed-Kapcsolat Diagramm: • Egyedek • Tulajdonságaik • Kapcsolataik Database Design Transform Application Design Transform • Moduljelöltek: • Résztvevő komponensek • Építőelemek • Grafikai layout • Szerver Modell Diagramm: • Táblatervek • Mezők • Saját-idegen kulcsok Generate Module Generate Database • Modul+Form a kliens gépen: • Egy űrlapot hajt meg • HTTP szerveren keresztül • A felhasználó így fér hozzá • Adatbázis a szerveren: • Táblák, mezők • Saját-idegen kulcsok • Adattartalom katt katt katt katt katt

7. Designer tervezési folyamata 2 katt katt katt Ovoda1 katt katt katt 3.LÉPÉS:üzleti folyamat diagramm (BPD): • A Process Modeler indítása után File|New menüvel kérünk új BP diagrammot • A Select Object panelen kiválasztjuk az alkalmazás konténert(pl.Ovoda1),ide írunk • Kijön a New Diagram panel, ahol Create New Root Process gombbal új gyökérfo-lyamatot (Root Process) kérünk, amely az egész üzleti folyamatot szimbolizálja: • Short definition:definíció (pl.Ovoda1) • Label:címke (pl.OVODA1) • Erre megjelenik az üres BPD, egyetlen Unspecified nevű szervezeti egységgel • A szervezeti egység hozzáadása gombbal ( ) újat kérünk, és a paneljén beállítjuk a nevét (pl.OLTOZTETO) • A folyamatlépés hozzáadása gombbal ( ) újat kérünk, a paneljén megadjuk a nevét (pl.GYEREK_KIAD), és kijelöljük a dobozt • A folyamatindító hozzáadása gombbal ( ) folyamatindítót (Trigger) csatolunk hozzá és a paneljén elnevezzük (pl.SZULO_JON) • A folyamateredmény hozzáadása gombbal ( )eredményt (Outcome) csatolunk hozzá, paneljén elnevezzük (GYEREK_KIADVA) • Több folyamatlépés a nyíl gombbal () be-húzható összekötővel köthető össze • Minden folyamatlépéshez megadható az időszükséglete (Time), költsége (Cost), gyakorisága (Frequency) valamilyen idő-intervallumon (pl.Hour) • A kész BP digarammot File|Save diagram as menüvel menthetjük a repository objek-tum hierarchiájába (pl.Ovoda_BP_Diag1) katt katt katt katt katt katt katt katt katt katt katt katt katt katt katt

8. Designer tervezési folyamata 3 katt katt katt katt 4.LÉPÉS: egyedkapcsolati diagramm (ERD): • Az Entity Relationship Diagrammer indí-tása után File|New-el kérünk új ERD-t • A Select Object panelen kiválasztjuk az alkalmazás konténert(pl.Ovoda1),ide írunk • Erre megjelenik az üres ERD, majd az egyed hozzáadása gombbal ( ) új egye-det (Entity) adunk hozzá, és elnevezzük: • Name:az egyed neve a logikai terven • Short name:rövid név, ezt rakja a relá-ciók automatikusan generált nevébe • Plural:az egyedből készülő adatbázis-tábla fizikai neve többes számban • Az egyedek tulajdonságait (Attribute) az egyed-panel Attribute fülén állítjuk be: • Name:tulajdonság(táblában mező)név • Seq:mező sorszáma a táblában • Opt:nem kötelező kitölteni a mezőt • Format:tipusa:(Number,Varchar,stb.) • MaxLen:max.tárolási hossza,számjegy • Dec:ebből hány számjegy a törtrész • Primary:mező elsődleges kulcs-e, ami a tábla rekordjait egyedileg azonosítja • 2 egyed összekapcsolásához először kat-tintsunk a megfelelő reláció gombjára: • ( ):több:1,függő:független (gyakori) • ( ):több:1,független:független • ( ):több:1,független:függő (igen ritka) • ( ):több:1,függő:függő (igen ritka) • Ezek bontására relációs táblát fog berakni: • ( ):több:több, függő:független • ( ):több:több, függő:függő • Ezeket összevonja 1 táblába:( ):1:1,függő: független,( ):függetl:függetl,( ):függ:függ katt katt katt katt katt katt kat1 kat2 katt katt katt katt katt katt katt katt A reláció gombra kattintás után mindig arra az egyedre kattintunk, amit a re- láció bal oldalánra akarunk, majd a jobb ol- dalira. Ügyeljünk rá, hogy az ERD nem jelzi ki a relációkat tároló idegen kulcsokat!!! • Az ERD-t File|Save diagram as menüvel menthetjük objektumba (Ovoda_ER_DIAG1)

9. Az előadás tartalma • Oracle Designer • Fogalma, telepítése • Grafikus felhasználói felület • Tervezési folyamata • Új alkalmazás hozzáadása • Üzleti folyamat diagramm • Egyed kapcsolati diagramm • Funkció hierarchia diagramm • Szerver modell diagramm • Programodul-jelöltek generálása • Programmodulok generálása • Programmodulok kézi finomítása • A kész űrlapok futtatása • A Designer értékelése • Advanced Database Diagram (ADD) • ADD Jelölésrendszer, példa az űrlapszekciók adatforrásaira • Példa multidimenzionális-hierarchikus (MDH) ADD-re • Az MDH-ADD rendszer működése • Hierarchikus dimenziók • Közös dimenziók • Alkalmazás-specifikus dimenziók • Rendszer dimenzió • Törzs és tranzakció szintek • Felfele elágazó dimenziók • Üzleti folyamatok • Funkciósávok, mérföldkövek • Eljárás hierarchia • Űrlaptervek, és szekció adatforrások • Az MDH-ADD rendszer értékelése, példa • MDH nélküli megoldás • Megoldás MDH-val Szakirodalom

10. Designer tervezési folyamata 4 katt katt katt katt katt katt 5.LÉPÉS:funkció hierarchia diagramm (FHD): • A Function Hierarchy Diagrammer indí-tása után File|Newel kérünk új diagrammot • A Select Object panelen kiválasztjuk az alkalmazás konténert(pl.Ovoda1),ide írunk • Kijön a New Diagram panel, ahol Create New Function gombbal új gyökérfüggvényt (Root Function) kérünk, amely a funkció hierarchia csúcsa lesz: • Short definition:definíció (pl.Ovoda1) • Label:címke (pl.OVODA1) • Erre megjelenik az alap FHD, az OVODA1 gyökérfunkcióval, amit ( ) szimbólum jelöl • A függvény hozzáadása gombbal ( ) új függvényt(Function) adhatunk hozzá, majd paneljén elnevezzük(pl.GYEREK_KIOSZT) • Az alsószintű függvény dobozát egérrel be-húzzuk a felsőszintű függvény dobozába, mire a rendszer összeköti őket és az alsót bepozícionálja a felső alá. Ilyen módon tet-szőleges hierarchiát építhetünk függvé-nyekből, amelyek felbontják részlépésekre a folyamatlépést, egész adig még lejutunk az elemi üzleti függvényekig (EBF), ame-lyek elvégzéséhez szükséges adatok egy munkaképernyőn ábrázolhatók • Az EBF-ek dobozain duplakattolva előjön 1 panel, amin az ERD elemeit rendelhetjük hozzájuk:Entity Usages fülnél az egyed (tábla) használatokat, Attribute Usages fülnél a tulajdonság (mező) használatokat: Create:létrehoz,Retrieve:olvas,Update:ír • Az FHD-t File|Save diagram as menüvel mentjük objektumba (pl.Ovoda_FH_Diag1) katt katt katt katt katt katt húz kat kat katt katt katt katt katt katt katt katt

11. Designer tervezési folyamata 5 katt katt katt 6.LÉPÉS:adatbázis szerver model diagr(SMD): • Az Entity Relationship DiagrammerUtili-ties|Database Design Transformer|Run menüvel alakíthatjuk a logikai adatbázis ter-vet Oracle szerverre szabott fizikai tervvé • A Design editor|ServerModel|Oracleuser| Ovoda1|Server model diagram menüben az Add object( ) gombbal új üres szerver modell diagrammot kérünk, ami megjelenik • Az Edit|Include menüre 1 panelen a Table definitions-nál kiválasztjuk a diagrammra kerülő táblákat (pl.Szulok,Gyerekek), amik már idegen kulcsokkal diagrammolódnak ki • Az SMD File|Save diagram as menüvel menthető objektumként(Ovoda_SV_Diag1) 7.LÉPÉS: Oracle adatbázis (ODB) generáció: • A Design editorban kijelöljük a Server mo-del|Oracleuser|Ovoda1|Rel.table def.s-t • A Generate|Generate database panelen: • Database generációt választunk: • Megadjuk az adatbázis Username, Password, Connect beállításait • File prefix:a *.DDL adatbázis generáló SQL fájlnév-előtag (pl.Ovoda1ddl) • Directory:DDLkönyvtár(pl.Konyvtar1) • Stop on error:Megáll hibára?(Nem) • Start gomb, Execute DDL gomb Kész adatbázis ellenőrzése: Tools|Database Navigator| • Username, • Password, • Connect Oracleuser| Tables katt katt katt katt katt katt katt katt Database Navigator katt katt katt katt katt katt katt katt katt katt katt katt katt katt

12. katt Designer tervezési folyamata 6 katt katt katt 8.LÉPÉS:űrlap programmodul jelölt-generálás: • A Function hierarchy diagrammer|Utiliti-es|Application design transformer menü-vel készíthetünk az elemi üzleti függvények-ből (EBF) moduljelölt-forráskódokat: • Generate option:mit generáljon=Modul • Start function:melyik modultól kezdje • Prefix:modulfájlnév-előtag (pl.Ovoda) • Start num:kezdő modulsorszám • Screen:űrlapszoftver=Oracle Form • Utility:generáló nyelv=PL/SQL • Merge:mit vegyen ki az ERD-ből=Iden-tical Entities-azonos nevű egyedeket • Generate gombbal indítjuk a műveletet 9.LÉPÉS: űrlap programmodul generáció: • Nem minden moduljelölt-forráskódot fordít le automatikusan futtatható űrlappá, csak amit erre kijelölünk a Design editorban: • Modules|Oracleuser|Ovoda1|Module objektumfa-ágnála kiválasztott modul-jelöltek (pl.Ovoda0010) jelölt tulajdon-ságát (Candidate)=NO-ra állítjuk • A Generate|Generate module menüvel megnyitjuk a Generate Form panelt: • Generate option:mit generáljon=Form • Preserve layout:valamely létező űrlap-ba szerkessze bele, és őrizze meg an-nak elrendezését=No • Template name:az űrlap formázó sablon, amit használ=ofgwebt.fmb • Post generation:mit csináljon generá-lás után: Commit:űrlap futtatása, Brow-se/Edit mode:űrlap szerkesztése • Start gombbal indítjuk a generálást katt katt katt katt katt katt katt katt katt katt katt katt katt katt

13. Designer tervezési folyamata 7 A Designer az az űrlap programmodul alapjául szolgáló EBF-hez csatolt egyedek általunk megadott tulajdonságait jeleníti meg az űrlapon, a Session1–ben már tárgyalt tervezési szabályok szerint: • Az űrlappal 1munkaképernyő:1rekord kapcsolatban álló egyed lesz a bázis egyed (Base Entity) • A bázis egyeddel több:1 kapcsolatban álló egyedek csatolt egyedek (Join Entity) lesznek, és a bázisegyed tartalmával együtt egy nézettáblát (View) generáló adatforrás (Data Source) SQL lekérdezés jeleníti meg az adataikat az űrlapon, illetve viszi vissza beléjük a felhasználói inputokat • A bázis egyeddel 1:több kapcsolatban álló egyedek a főűrlapba ágyazott alűrlapon jelennek meg (Subform Entity), mert pl. 1 termékfajtához(Product) a főűrlapon több árazást(PricedProd)kell mutatni alűrlapon 10.LÉPÉS: a modulok manuális finomítása: • A Design editorOpen|Modules menüben indíthatjuk a Module Diagram-ot • Az Ovoda1|Module objektumfa-ágról húz-zunk be 1 modult a diagrammba, és láthatjuk az általa felhasznált táblákat • Az idegen kulcsmezőiken jobbkattolva, a megjelenítés(Display type) tulajdonságu-kat állítsuk legödülő listára (Pop List) • Az elsődleges kulcs tábláját (pl.Product) jobb oldalról!!! behúzzuk a rá hivatkozó idegen kulcs táblájába (pl.PricedProd) • Így az idegen kulcsokat nem kézzel kell kitölteni, hanem listából választhatók! húz katt Jobb katt

14. katt A kész adatbázis rendszer Connect Run katt katt katt katt katt katt 11.LÉPÉS: a kész űrlapok futtatása: • Az Oracle 11i Developer Suite Forms Developer csomagjával telpülő Forms Builder program indítása • File|Connect menüvel belogolunk az adat-bázisba: Username,Password,Connect • File|Open menüvel megnyitjuk az űrlap *.fmb modul fájlját, amit a Designer rend-szerint C:\oracle\ora9ids\Cgenf61-be rak • Layout menüvel kézzel szerkeszthetjük az űrlapelrendezést,formázását.Ha kész,akkor • A Forms Developer csomagból a Start OC4J Instance programmal elindítjuk a HTTP listenert, ami a futó űrlapot majd összekapcsolja az Oracle webszerverrel (a programot nem zárjuk be, tálcára rakjuk) • A Forms BuilderProgram|Run menü-jében futtatjuk az űrlapot, erre a webkereső elindul, és első futtatáskor rákérdez az Oracle Java Plugin telepítésére=OK, majd az űrlap megjelenik: • Query|Enter-rel vihetünk be adatot • Query|Execute menüvel kereshetünk • A Record menü elemei szolgálnak a rekordok közti mozgásra • Action|Exit menüvel léphetünk ki Az Oracle Designer értékelése:  Teljes tervezési folyamatot támogató CASE eszköz, nem egyszerű adatbázistervező  Pocsék telepíthetőség, mert a repository-t külön scriptekkel kel létrehozni, sok össze-akadási lehetőség a szerver beállításaival  Kritikán aluli vevőszolgálat és dokumentáció  Brutális erőforrás-pazarlás, ülteti a szervert húz katt katt katt Enter Execute Exit katt katt katt

15. Az előadás tartalma • Oracle Designer • Fogalma, telepítése • Grafikus felhasználói felület • Tervezési folyamata • Új alkalmazás hozzáadása • Üzleti folyamat diagramm • Egyed kapcsolati diagramm • Funkció hierarchia diagramm • Szerver modell diagramm • Programodul-jelöltek generálása • Programmodulok generálása • Programmodulok kézi finomítása • A kész űrlapok futtatása • A Designer értékelése • Advanced Database Diagram (ADD) • ADD Jelölésrendszer, példa az űrlapszekciók adatforrásaira • Példa multidimenzionális-hierarchikus (MDH) ADD-re • Az MDH-ADD rendszer működése • Hierarchikus dimenziók • Közös dimenziók • Alkalmazás-specifikus dimenziók • Rendszer dimenzió • Törzs és tranzakció szintek • Felfele elágazó dimenziók • Üzleti folyamatok • Funkciósávok, mérföldkövek • Eljárás hierarchia • Űrlaptervek, és szekció adatforrások • Az MDH-ADD rendszer értékelése, példa • MDH nélküli megoldás • Megoldás MDH-val Szakirodalom

16. EgyedNév EgyedNévID Szöveg EgészSzám TörtSzám Bináris Dátum Idő Kép Hang Mozi KötIdegKulcs OpcIdegKulcs Módosító Módosítva Állapot Kód KódID KódNév Az ADD MS Office rajzolóra fejlesztett diagramm: • Komplexen támogatja az adatbázis és grafikus felhasználói felületének tervezését, szemben az elszigetelt BP és ER diagram-mokkal, és több infót hordoz • Egyszerű,gyors szerkesztés, kis hardverigény • Nem generálható belőle automatikusan adatbázis, ezért előtervezési és gyakorló eszköznek ajánlott Oracle Designer, MS Visio vagy ERWin CASE eszközök használata előtt Egyedkapcsolat diagramm elemei: Egyed(Entity): lekerekített blokk • Egyedi Egyednév, aláhúzva • 1.-leges kulcs( ):egyednév+ID • Minden mezőt félkövéren sze-dünk, ha a rendszer tölti ki (pl. auto-számoz vagy -dátumoz) • A kötelező mezők normál, az opcionálisak dőlt szedésűek • A sima adatmezők előtti adat-tipus ikonok:( , , , , , , , , ) • A kötelező/ opcionálisidegen kulcsok ikonja:( ) • A tranzakció-leíró egyedek háttere sárga, végükön auto-kitöltős ISO-naplózó mezők • Dimenzió/törzs/kódleíró táblák kékek (utóbbiak rekordjai is) Reláció(Relation):derékszögben törő összekötő vonal, ahol: • Több oldalon csirkeláb( )van ezt mindig az idegen kulcs mellé kötjük az egyed blokkon • Egy oldalon vonal, az egyed- blokk aljára/tetejére kötjük • A függő oldal folytonos( ),a független oldal szaggatott( ) • Kapcsolat-megszakítás és kilógó rekordok létrejöttének tiltása( ): független oldalon hi-vatkozott rekord törlését,a füg-gőn kilógó beírását korlátozza • Hivatkozás-módosítás tiltó:( ) • Kaszkádolt törlés tiltása:( ) PaulerSoft™ Advanced Database Diagram (ADD) 1 Üzleti folyamat diagramm elemei: Hierarchikusan beágyazott, egyre beljebb tabulált blokk-párok(Blocks): • Eljárás fejléc (Proc):eljárásnév, paraméternév-lista, változótípus ikonokkal, félkövérrel szedve a függvényként visszadottakat Lábléc (EndProc):eljárásnév • Ciklus fejléc (FOR):ciklus feltétel Lábléc (EndFOR):ciklusváltozó • Feltétel fejléc (IF):feltétel formula Különben ág (ElseIF):feltétele Lábléc (EndIF):feltétel formula Egyedi dobozok (Single Block)hosz- szuk arányos az időszükségletükkel: • Lokális változó deklarálás(Decl): változólista, tipus-ikonokkal • Szekvenciális lépés (Step):kód • SQL lekérdezés (Sql):SQL kód Blokk összekötő nyilak (Arrow): • Igen(Yes):,Nem(No):,Előre (Step):,Ciklus újra(Back): • A nem nyilakat mindig bal oldalra rakjuk, hogy kiadják a hierarchiát • Csak az újra lép vissza időben • Proc:ProcNév • Szöveg • Egész • Tört • Dátum • Idő • Decl: • Szöveg • Egész • Tört • Dátum • Idő FOR:A IF:B • A tiltó jelre kétszer kat -tolva, a ki-töltőszint átlátszóra állítva a jel-zés sza-badra állít-ható: Step: ElseIF:B: Sql:Select From Where Group by Having Order by EndIF:B katt EndFOR:A EndProc:Proc

17. Főűrlap bázisegyed Cím CímID LakásSzám Emelet HázSzám KözTerNév Tel Fax KözTerTipID IránySzamID OrszágID Módosító Módosítva Állapot Személy SzemélyID TermAzon FelvettNév1 FelvettNév2 VezetékNév LeánykorNév SzülHely AnyjaNeve SzülDátum Módosító Módosítva Állapot Lakhely LakhelyID KezdDátum VégDátum SzemélyID CímID Módosító Módosítva Állapot • ŰrlapNév • ÜgyFélFelv • Azonosító • FelvettNév1 • FelvettNév2 • VezetékNév • LeánykorNév • SzülHely • AnyjaNeve • SzülDátum • LakhelyKezd • LakhelyVég • LakásSzám • Emelet • HázSzám • Tel • KözTerNév • KözterTip • IránySzám • Rögzítés • Azonosító • Szöveg • Opciógomb • Számmező • Bejelölőbox • Dátum • Idő • Kép • Hang • Mozi • KötIdegKulcs • OpcIdegKulcs • MakróGomb • Döntés • Kérdés? Az űrlap diagramm elemei: Űrlap(Form) szögletes blokk: • Felül az Űrlapnév kékben • Ezután különböző tipusú adatmegjelenítő kontrol-lok(Controls) a feliratukkal és a kontroll-ikonnal. Ezek mindegyike egy adattipus-hoz kapcsolódik, kivéve a számmezőt, ami egész és törtszámot is megjeleníthet • A félkövérrel szedett kont-rollok gépi kitöltésűek, a normál szedésűek köte-lezők,a dőltek opcionálisak • Az aláhúzás űrlap szekció-törést (Section Break) je-lez. A különböző szekci-óknak más tábla vagy le-kérdezés az adatforrása (lásd a példát később) • Tartalmazhat beviteli le-kérdezés-indító gombot Felugró űrlap(Popup Form): • Eldöntendő kérdést tar-talmaz, a BPD-n feltételi blokkpár kezdetét jelent. Példa az űrlapszekciókra: 1személytöbbcímenlak- hat (időben),és 1címen is lakhattöbbszemély (a Lak- hely relációs egyed lesz) • Az ÜgyfélFelvétel űrlap-hoz 1:1 kapcsolódik a Személy, ezért ez lesz a főűrlap bázisegyede és adatforrása a SzülDá-tum szekciózáró mezőig • A Személyhez 1:több kapcsolódik a Lakhely, ezért ez az alűrlap szek-ció bázisegyede lesz • A Lakhelyhez több:1 kapcsolódik a Cím,ezért ez az alűrlaphoz csatolt egyed lesz, ez is az al-űrlap szekcióban lesz. • Mivel 1 szekció adatfor-rása 1 tábla/lekérdezés lehet, ezért a Cím és a Lakhely mezőit egy SQL adatforrás lekérdezés tölti fel alűrlap szekció-ba:KezdDátum..IrSzmID A blokkok egy táblázatban jelennek meg, melynek fe- hér oszlopai az ERD dimen- ziói (Dimension), a szürkék a BPD mérföldkövei (Mile- stone),sorai hierarchikus szintek (Hierachic Levels) PaulerSoft™ Advanced Database Diagram (ADD) 2 Alűrlap bázisegyed Alűrlap csatolt egyed Sql:Select KezdDátum, VégDátum, LakásSzám, Emelet, … From ( Lakhely L Inner Join Cím C On C.CímID= L.CímID); Adatforrás(Data Source) összekötő: 2 irányú adatkapcsolat egy űrlapszek-ció és egy tábla/Sql lekérdezés közt: • Új rekord létrehozás tiltása:( ) • Létező rekord-megnézés tiltása:( ) • Rekord módosító beírás tiltása:( ) • Rekord törlésének tiltása:( ) Alűrlap adatforrás lekérdezés

18. JogiForma JogiFormaID JogiFormaNév Műszak MűszakID MűszakNév KezdIdő VégIdő MunkaNapID MuszakTipID Módosító Módosítva Állapot MűszakTip MűszakTipID MűszakTipNév BérTarifaID Szakasz SzakaszID KezdPontID VégPontID Módosító Módosítva Állapot Munkanap MunkanapID NapNév Dátum MunkahétID Munkahét MunkahétID SorSzám KezdDátum VégDátum NegyedévID Negyedév NegyedévID KezdDátum VégDátum Ország OrszágID OrszágNév KözTerTip KözTerTipID KözTerTipNév Cím CímID LakásSzám Emelet HázSzám KözTerNév Tel Fax KözTerTipID IránySzamID OrszágID Módosító Módosítva Állapot Régió RégióID RégióNév OrszágID Pont PontID Szélesség Hosszúság Magasság CímID Módosító Módosítva Állapot Partner PartnerID MegszűnOk KezdDátum VégDátum SzervezetID SzemélyID PartnerTipID Módosító Módosítva Állapot IránySzám IránySzámID TelepülNév RégióID Személy SzemélyID TermAzon FelvettNév1 FelvettNév2 VezetékNév LeánykorNév SzülHely AnyjaNeve SzülDátum NemID ÁllamPolgID Módosító Módosítva Állapot Beosztás BeosztásID MegszűnOk Fizetés KezdDátum VégDátum MunkavállID PozícióID Módosító Módosítva Állapot Munkaváll MunkavállID FelmondOk KezdDátum VégDátum SzemélyID SzervezetID Módosító Módosítva Állapot Nem NemID NemNév Osztály OsztályID OsztályNév VezetőID FőOsztályID Szervezet SzervezetID AdóSzám CégjegySzám SzervezetNév AlapítDátum JogiFormaID TelephelyID AnyaSzervID Pozíció PozícióID PozícióNév OsztályID Lakhely LakhelyID KezdDátum VégDátum SzemélyID CímID TartózkID Módosító Módosítva Állapot Elérhet ElérhetID TelMobil E-mail Skype KezdDátum VégDátum SzemélyID TartózkID Módosító Módosítva Állapot MunkNapl MunkNaplID Tevékenység SzolgáltatDíj KezdDátum VégDátum BeosztásID MűszakID PartnerID Módosító Módosítva Állapot Tartózk TartózkID TartózkNév PartnerTip PartnerTipID PartnerTipNév • ÜgyFélFelv • Azonosító • FelvettNév1 • FelvettNév2 • VezetékNév • LeánykorNév • SzülHely • AnyjaNeve • SzülDátum • LakhelyKezd • LakhelyVég • TartózkJelleg • LakásSzám • Emelet • HázSzám • Tel • KözTerNév • KözterTip • IránySzám • TelepülNév • RégióNév • OrszágNév • ElérhetKezd • ElérhetVég • Mobil • E-mail • Rögzítés Példa multidimenzionális-hierarchikus ADD-re • Proc:ÜgyfélFelvétel • ÜgyfélNév • MegjelenDátum • MegjelenIdő IF:Hajlandó még várni? EndProc:Ügyfél felvétel IF:Van szabad ügyintéző? Step:Új ügyfél felvétele

19. Idő Munkahét MunkahétID SorSzám KezdDátum VégDátum NegyedévID Munkanap MunkanapID NapNév Dátum MunkahétID MűszakTip MűszakTipID MűszakTipNév BérTarifaID Műszak MűszakID MűszakNév KezdIdő VégIdő MunkaNapID MuszakTipID Módosító Módosítva Állapot ÜzletiÉv ÜzletiÉvID KezdDátum VégDátum Negyedév NegyedévID KezdDátum VégDátum • Szervezet(Organization): bármely cég, intézmény, egyesület: • Jogi forma(LegalForm), Szervezet(Organization), Osztály(Department), Pozíció(Position), Munkavállalás(Employee), Beosztás(Employment), Munkanapló(WorkDiary) • Partner(Partner): a szervezet vevői, beszállítói, alvállalkozói: • PartnerTipus(PartnerType), • Partner(Partner), • Kontakt személy(Contact) • Ezután adjuk meg a probléma-specifi-kus dimenziókat (Problem Specific Di-mensions): • Pl. Termék(Product): • Beszállító(Supplier), Beszállítói termék katalógus (Supplier Catalog), Belső alkatrész katalógus (PartCatalog), Összeszerelési terv(AssemblyPlan) • Végül az adatbázis rendszer saját leírását tartalmazó dimenziót (System Dimension) adjuk meg: • Szerver(Server), • Kliens(Client), • Űrlap(Form) • Menü(Menu) • Modul(Module) • Lekérdezés(Query) A multidimenzionális-hierarchikus ADD működése 1 A multidimenzionális-hierarchikus (Multi-Dimensional Hierarchic) adatbázis terv (MDH-ADD) a következő részekből áll: • Az adatbázis által támogatott alkalmazás (Application) dimenziói (Dimension): adat-bázis táblák hierarchikus (Hierachic) szer-veződése, ahol 1 hirerachikus szint:1 tábla, és a felsőszintű:alsószintű táblákat 1:több számosságú reláció köti össze, és a táblákat a dimenzió neve alatt egy oszlopban hierarchikus sorban fentről le ábrázoljuk: • Elsőként azon a dimenziókat soroljuk fel,melyek közösek (Common Dimensi-ons) minden adatbázisban: • Idő(Time):lehet naptári-/munkaidő • Év(Year), Negyedév(Quarter), Hónap(Month), Hét(Week), Nap(Day), Műszak(Shift), Termelési ütem (ProdTick) • Tér(Space):szöveges-/vektor leirás • Ország(Country), Régió(State/ County), Település(City), Irányítószám-körzet(ZipZone), Közter(Street), Cím(Address) • Útvonal(Road), Szakasz(Sec-tion), Pont(Point) • Személy(Person): természetes személyek életrajzi adatai: • Nem(Gender),Személy(Person), Lakhely(Residence), Elérhetőség(Acessibility), Képzettség(Qualification), Nyelvtudás(Language), Jogosítvány(License)

20. Az előadás tartalma • Oracle Designer • Fogalma, telepítése • Grafikus felhasználói felület • Tervezési folyamata • Új alkalmazás hozzáadása • Üzleti folyamat diagramm • Egyed kapcsolati diagramm • Funkció hierarchia diagramm • Szerver modell diagramm • Programodul-jelöltek generálása • Programmodulok generálása • Programmodulok kézi finomítása • A kész űrlapok futtatása • A Designer értékelése • Advanced Database Diagram (ADD) • ADD Jelölésrendszer, példa az űrlapszekciók adatforrásaira • Példa multidimenzionális-hierarchikus (MDH) ADD-re • Az MDH-ADD rendszer működése • Hierarchikus dimenziók • Közös dimenziók • Alkalmazás-specifikus dimenziók • Rendszer dimenzió • Törzs és tranzakció szintek • Felfele elágazó dimenziók • Üzleti folyamatok • Funkciósávok, mérföldkövek • Eljárás hierarchia • Űrlaptervek, és szekció adatforrások • Az MDH-ADD rendszer értékelése, példa • MDH nélküli megoldás • Megoldás MDH-val Szakirodalom

21. Proc:ÜgyfélFelvétel • ÜgyfélNév • MegjelenDátum • MegjelenIdő IF:Hajlandó még várni? EndProc:Ügyfél felvétel • ÜgyFélFelv • Azonosító • FelvettNév1 • FelvettNév2 • VezetékNév • LeánykorNév • SzülHely • AnyjaNeve • SzülDátum • LakhelyKezd • LakhelyVég • TartózkJelleg • LakásSzám • Emelet • HázSzám • Tel • KözTerNév • KözterTip • IránySzám • TelepülNév • RégióNév • OrszágNév • ElérhetKezd • ElérhetVég • Mobil • E-mail • Rögzítés IF:Van szabad ügyintéző? Step:Új ügyfél felvétele A multidimenzionális-hierarchikus ADD működése 2 • A dimenziók felsőbb szintjein törzs- és kódtáblák talál-hatók, amelyek tartalma időben nagyon lassan változik, ezért nincsenek is bennük rendszernaplózó mezők, és rendszerint a fejlesztő tölti fel őket a rendszer átadása előtt adatimporttal, ezért ha csak kevés rekordból állnak, feltűntethetjük ezeket az ADD-n • A dimenziók alsóbb szintjein tranzakció-leíró táblák fog-lalnak helyet, amelyekben a rekordok életciklusa (Data LifeCycle): létrehozás(Create), módosítás(Modify), visz-szakeresés(Retrieve), törlés(Delete) gyorsan, tömegesen zajlik, ezért az ISO-szabvány teljeskörű minőség-mene-dzsment (Total Quality Management, TQM) előírásainak megfelelően rendszernaplózást végzünk, hogy minden adatváltozásnál nyomon lehessen követni, mikor történt, és melyik felhasználó érte a felelős • Azt mindig az adott alkalmazás dönti el, melyik hierarchia szint számít már tranzakciósnak (pl. a Katolikus egyház szervezetében az Osztály egyed inkább törzs, de egy piramisjáték (Multi-Level Marketing, MLM)-alapon szerve-ződő cégében, vagy egyházéban keményen tranzakció!) • A legtöbb dimenzió felfele ágazó hierarchiájú (Fork Dimension): 1 egyednek több felettes egyede is lehet (pl. a Műszaknak a Munkanap és a Műszaktipus is felettese) • Üzleti folyamatok (Business Process) leírása: • A szervezet(Organization) dimenzió hierarchikus szintjei-hez szürke oszlopok-ban időbeli logikai töréspontokat, mérföld-köveket (Milestones) rendelünk, és az ezek alkot-ta koordináta rendszerben ábrázoljuk a folyamatábrát. • Ezt eljárások(Procedure) egymásba ágyazásával bont-hatjuk le az űrlap(Form) tervezéshez kellő elemi üzleti függvények (Elementary Business Functions) szintjéig • Az űrlaptervek szekciói és az egyedkapcsolati diagramm közt adatforrás (Data Source) csatolásokat hozunk létre, adott elérési jogosultságokkal:Create/Read/Write/Delete

22. Szervezet SzervezetID AdóSzám CégjegySzám SzervezetNév AlapítDátum JogiFormaID TelephelyID AnyaSzervID Elérhet ElérhetID TelMobil E-mail Skype KezdDátum VégDátum SzemélyID TartózkID Módosító Módosítva Állapot Osztály OsztályID OsztályNév SzervezetID VezetőID Partner PartnerID MegszűnOk KezdDátum VégDátum SzervezetID SzemélyID PartnerTipID Módosító Módosítva Állapot Személy SzemélyID TermAzon FelvettNév1 FelvettNév2 VezetékNév LeánykorNév SzülHely AnyjaNeve SzülDátum NemID ÁllamPolgID Módosító Módosítva Állapot FőnökElér FőnökElérID TelMobil E-mail Skype KezdDátum VégDátum BeszállFőnökID Módosító Módosítva Állapot HelyettElér HelyettElérID TelMobil E-mail Skype KezdDátum VégDátum FőnökHelyettID Módosító Módosítva Állapot Beszáll BeszállID BeszállNév MegszűnOk KezdDátum VégDátum Módosító Módosítva Állapot BeszállFőnök BeszállFőnökID TermAzon FelvettNév1 FelvettNév2 VezetékNév LeánykorNév SzülHely AnyjaNeve SzülDátum BeszállID Módosító Módosítva Állapot FőnökHelyett FőnökHelyettID TermAzon FelvettNév1 FelvettNév2 VezetékNév LeánykorNév SzülHely AnyjaNeve SzülDátum BeszállFőnökID Módosító Módosítva Állapot Az MDH-ADD rendszer értékelése: • Kezdő adatbázis-tervezők számára riasztó-an hat, hogy a leggagyibb, legegyszerűbb pizzafutár rendszerhez is 35-40 táblával kellene megindulni a közös dimenzióknál • Az ezzel kapcsolatos munkaigényen sokat lehet csökkenteni sablonokkal(ld.ADD.doc) • Az MDH előnyei akkor jönnek elő igazán, amikor a kezdő tervező gyakran alátervezi a rendszert a valóságos probléma komp-lexitásához képest, vagy az ügyfél folya-matosan új igényekkel áll elő, pl. „Jajj, hát bele kellene tenni a beszállító cég címét, de még a főnökének az elérhetőségét, ja de az is változhat, attól függ melyik idő-szakban vannak, de ha nem elérhető, akkor tárolni kellene a helyetteséét is!”: • MDH környezet nélkül a kezdő ilyenkor ész nélkül elkezdi definiálni az egyre újabb táblákat, hogy az 1.Normálforma szabályai szerint kibontsa a gyakorlati adatstruktúra belső 1:több kapcsolatait (Beszáll, BeszállFőnök, FőnökElér, FőnökHelyett, HelyettElér, +4 új tábla hozzáadása, a karbantartó munkaké-pernyőkkel) vagy még rosszabb eset-ben hanyagolja a normalizációt és berak mindent 1 táblába!!! • MDH-ban a szükséges új táblák és munkaképernyők száma: 0.00db!!! Mert a beszállító Partner, ami lehet Szervezet, aminek Osztályai vannak, amiknek Vezetői Személyek, akiknek már van időszaki Elérhetőségük!!! • Itt térül meg a kezdeti erőfeszítés! Figyeljük meg a teljesen felesleges táblasruktúra ismétlődést!

23. Szakirodalom Oracle adatbázis szerver: • http://www.oracle.com/technology/products/designer/index.html Oracle Designer: • http://www.oracle.com/database/index.html Adatbázis-tervezési diagramm rendszerek: Alapvető elmélete: • Angolul: • http://en.wikipedia.org/wiki/Entity-relationship_model • http://www.webopedia.com/TERM/e/entity_relationship_diagram.htm • http://databases.about.com/cs/specificproducts/g/er.htm • Magyarul: • http://www.agt.bme.hu/szakm/adatb/er/er.html Diagramm rajzoló szoftverek: • http://www.conceptdraw.com/en/products/cd5/ap_er_diagram.php • http://www.smartdraw.com/specials/context/erddataflow.htm ADD sablon: • ADD.doc