Adatbázis-tervezés konzultáció

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

Az előadás tartalma Az adatbázis-tervezés fogalma A hatékony, korszerű adatbázis-tervezés feltételei: 1. Feltétel: Szürkeállomány 2. Feltétel: Hatékony szervezet, üzleti folyamatok átszervezése (BPR) 3. Feltétel: Relációs adatbáziskezelő rendszer (RDBM) alkalmazása 4. Feltétel: Adattárházak és On-Line Analytical Processing (OLAP) létrehozása Szakirodalom

Az adatbázis-tervezés fogalma
Az adatbázis-tervezés (Database Design, DBD): olyan folyamat, amelynek célja, hogy relációs adatbáziskezelőben (Relational Database Management System, RDBMS) definiált relációs adatbázissal (Relatioanal Database System, RDBS) elégítse ki az adatkezelő rendszerekkel (Data Management System, DMS) szemben megfogalmazott, egymásnak ellentmondó 10 követelményt: Redundancia-mentesség (Non-Redundancy): az adatok nem ismétlődhetnek, csak egyszer tároljuk el őket, a fajlagos helyfogyasztást minimalizálva Hatékonyság (Efficiency): gyors visszakeresés és adatmódosítás Rugalmasság (Flexibility): nem fix hosszúságú, bonyolult adatszerkezetek tárolása Programozhatóság (Programmability): az adatszerkezetek és a feldolgozó eljárások egyszerű módosítása Adatfüggetlenség (Data Independence): az adatok, és az adatszerkezet hardvertől, szoftvertől való függetlensége Metaadatok elekülönülése (Separation of MetaData): az adatok szerkezeti leírását és feldolgozási eljárásaikat az adatoktól elkülöníthető módon kell tárolni Adatintegritás (Data Integrity): a tárolt adatoknak folyamatos módosítások közepette is eleget kell tennie bizonyos szabályoknak Adatbiztonság (Data Safety): adatok védelme a hardver- és szoftverhibák ellen Adatvédelem (Data Security): az adatokat csak az arra jogosult felhasználók kezelhessék Osztott adathozzáférés (Shared Data Access): ugyanazokkal az adatokkal több felhasználó is dolgozhasson egyidejűleg. A követelmények teljesítése egymás rovására megy (pl. a sebesség maximalizálása tárhely-igény növekedést okoz, a helyigény minimalizálása lassítja a rendszert) Ezért az adatbázis-tervezés nem egyszerű, algoritmizálható folyamat, hanem rosszul struktúrált döntési probléma (Ill Structured Decision Problem), ahol az inputok és az outputok közt nem mindig van egyértelmű összefüggésrendszer. Emiatt az adatbázis-tervezés – szemben az adatbázis kezelők használatával – nem tanulható tudásanyag, hanem gyakorlati példák megoldásában alakuló gondolkodásmód Látni fogjuk, hogy hiánya óriási gazdasági kárt okozhat, illetve emberéletet is veszélyezetethet, és több 1000 órai programozás eredményét teheti használhatatlanná!

A rossz adatbázis-tervezés tünetei
A megrendelők – mivel nem informatikai szakemberek – gyakran elkövetik azt a hibát, hogy komplex, nagyméretű rendszerek kifejlesztésével tisztán programozókat bíznak meg, mert nem tudatosodik bennük, hogy a rendszerfejlesztés és az adatbázistervezés a programozástól külön szakma (ez olyan, mintha valaki a fogásszal akarná kivetetni a vakbelét is, hiszen az is orvos…) A programozók rendszerint kevéssé járatosak az adatbázis tervezésben, és egész nagy komplex rendszereket is megoldanak vidáman 6-7 adatbázis táblával (a helyes normalizáció diktálta helyett…), mondván „minek bonyolítsuk túl, ami esetleg kilóg ebből a struktúrából, azt kézzel melléprogramozzuk”. Ennek soha véget nem érő programozás lesz a vége (Ez tipikus olyan hallgatóknál, akik egy kicsit megtanulták a PHP-t és egy weboldal mögé tudnak 1db MySQL táblát tenni, és azt hiszik övék a világ, de egy másik táblával már nem biztos hogy össze tudják kötni…) A programozó – mert „szeret programozni” – hosszú időt eltölt olyan agoritmusok megírásával, ami SQL-ben már rég meg van írva (pl. Levalogatas, Osszerendezes eljárásnevek esetén erre kell gyanakodnunk), sokkal jobb minőségben, hardver és virtuális memória optimalizációval, csak tudni kellene, mire való az SQL!!! Az adatbázisból kimaradnak alapvető adatok, (pl. webes kereskedelmi rendszernél a rendelt árumennyiség), ez plus munkát okoz (egy 3db-os rendelést 3 külön rendelésként kell feladni) A felhasználó felület pocsék módon van megtervezve: egy művelethez 4 képernyőt kell összenézni, a különböző dolgok kódjai nem legördülő menüből választhatók (pl. közterület-tipusok a címben), hanem külön papírokról kell kinézegetni őket A rendszer bevezetés után azonnal összeomlik a gyakorlatban, és egyre súlyosbodó garanciális problémahalmazt tol maga elött, az ügyintézők egyre több kis kockás füzetet és sajtcédulát használnak mellette A rendszer minden kis megváltoztatása robbanásszerűen megnöveli a tárigényt, egyre nagyobb mértékű teljes átprogramozást követel (pl. egy új termék felvétele a rendszerbe szerver upgrade + még 1.5 hónap csúszás) Végső soron a rosszul megtervezett adatbázis rendszer kifejlesztési költségét veszteségként leírhatja a megrendelő, illetve még a munkaerő-szükségletet is megduplázza, mert az alkalmazottaknak vinni kell a régi, rosszul működő papír-alapú rendszert, és ki kell szolgálni a használhatatlan adatbázist is.

A hatékony adatbázis-tervezés 1.előfeltétele: Szürkeállomány
Ez két területen szükséges az adatbázis-tervezés során: Felsővezetői pozíció: a felsővezető dönt az adatbázis létrehozásárol, erőforrásokat biztosít a működéséhez és kiértékeli a rendszer eredményességét. Ehhez tisztában kell lennie az információtechnológia jelentőségével a szervezet versenybeli túlélése tekintetében, fel kell vállalnia a rendszer bevezetésével járó üzleti-emberi konfliktusokat, átmeneti veszteségeket és kockázatokat. Az ideális vezető kockázatkedvelő, sok dolog iránt nyitott, felsőfokon képzett, de egyetlen dologban sem túlságosan elmélyülő személyiségű, akinek képesnek kell lennie kommunikálni más személyiségű szakértőkkel: Adatbázis-tervezői pozíció: erős analitikus intelligenciával megáldott (megvert) személyiségű, felsőfokon képzett egyén, aki képes alaposan elmélyedni kutatóként egy szűk problémakör rejtelmeiben, illetve átlátni a probléma megoldásához szükséges komplex rendszereket. Az ilyen tipusú emberek legtöbbször kockázatkerülők, és szerényebb kommunikációs képességekkel rendelkeznek. A megfelelő szürkeállomány kitermelődését több tényező is fékezi: A puha diktatúra szűkkörű, politikailag korlátozott de viszonylag jó minőségű, főleg természettudományokban és matematikában erős, és nemzetközileg kapós elitképzése felől elindultunk a felsőfokú oktatás társadalmasítása felé – ugyanannyi vagy kevesebb erőforrásból! Ez a minőség erőteljes zuhanórepüléséhez vezetett, erodálódik az elitképzés és a tehetséggondozás A 1980-as évek gazdasági válsága miatt a 2000-es évek közepén kialakuló demográfiai mélypont következménye, hogy a felsőoktatási intézmények túlélésük érdekében mindenkit felvesznek, aki korábban szakmunkásképzőn sem jutott volna át, mert finanszírozásukat pusztán mennyiségi szempontok határozzák meg, a minőségieknek nincs szerepe. Ez sajnos ugyanúgy igaz a magánintézményekre, mint az államiakra, mert a szektorban látszatverseny folyik, a fejkvóták és a létszámok hatalmi alkukban dőlnek el. A kialakuló fogyasztói társadalom „fogyassz, ne gondolkodj” eszménye kiöli az emberekből a motivációt a nehezebb ismeretek elsajátítására és az új keresésére. Következmény: az adatbázis-tervezéssel kapcsolatos állások betöltetlenül állnak, amikor más, egyszerűbb informatikai területeken (pl. weblap-tervezés) már túltermelés van!

A hatékony adatbázis-tervezés 2.előfeltétele: Hatékony szervezet
Bármely üzleti vagy non-profit szervezet (Organization) két komponensből áll: Hierarchia (Hierarchy): milyen osztályok (Department), milyen részlegekre (Branch), milyen csoportokra (Team), műszakokra (Shift), és pozíciókra (Position) oszlanak, kik a felsővezetőik (Top management), középvezetőik (Mid-management), beosztottaik (Subordinates) Folyamat-struktúra (Process Flow): mik a folyamat inputjai (Inputs) (vevők, beszállítók, erőforrások), melyik pozíció, milyen időpontban, milyen tevékenységet (Activity) végezzen, mik a folyamat outputjai (Output) (pl. kiszolgált, elégedett vevők) Ezeket a szervezeti működési szabályzat, SZMSZ (Standard Operating Plan, SOP) rögzíti A Carlzon-tétel (Carlzon Principle) szerint a szervezet hatékony működésének az alapja, hogy a döntési hatáskörök (Authority), a felelősség (Responsibility), és a tevékenységhez szükséges információk (Information) arányosan legyenek elosztva minden pozíciónál: Ha valaki felelős valamiért, de nincs hatásköre dönteni róla, frusztrált lesz Ha valakinek van hatásköre, de nem kap a hozzá infókat, hülyeségeket fog csinálni Ha van hatásköröd, infód, de nem lehet felelősségre vonni, azt csinálsz, amit akarsz (Jan Carlzon egy topmenedzser volt, aki az 1970-es években a csőd szélén álló SAS légitársaságból virágzó vállalatot csinált pár év alatt a fenti elvekre alapozva. Ld.:Carlzon) Sajnos a magyar szervezeti-döntési kultúra erősen ellene hat ezen elveknek: Az ország 1000 éves feudalisztikus hagyományai miatt a magyar döntéshozók túl nagy szerepet tulajdonítanak a szervezeti hierarchia kialakításának (ki hajbókol kinek), egyszerű feladtokra is túl sok szintű, túl bürokratikus hierarchiát hoznak létre. Itt Parkinson törvénye (Parkinson’s Law, ld.: Parkinson) érvényesül: a bürokrata mindig a beosztottai számát gyarapítja, sosem a vetélytársaiét, ezért a bürokratikus szervezetek létszáma kellő erőforrások birtokában hajlamos évi 3-5%-kal önmagától nőni, függetlenül az elvégzendő munkamennyiségtől Ugyanakkor alig fordítanak figyelmet a folyamatstruktúrára, egyáltalán nem tervezik meg, hogy a legalsó pozíciókban lévőknek hogy kellene inputból outputot csinálni. Így a rendszerint ott lévő tapasztalatlan pályakezdők, meg az 55 év körüli, bodorított hajú hölgyemények (nekik nincs más esélyük, ha kirúgják őket, még utcalánynak sem kellenek) elkeseredetten nekiállnak egymással spontán koordinálni, és létrehoznak egy idegbajos pók hálójára emlékeztető folyamatstruktúrát, amely borzasztó lassan, hatalmas munkaerő- és pénz pocsékolással, igen bizonytalanul működik A következőkben áttekintjük, hogy az üzleti folyamatok újraszervezésénék (Business Process Reengineering, BPR) milyen eszközei vannak, és milyen problémákat old meg: Főisten Alisten Félisten Nusika1 Nusika2 Nusika3 Nusika4

Az üzleti folyamat diagramm (Business Process Diagramm, BPD)
Olyan folyamatábra, ami adott céllal, inputokkal és outputokkal rendelkező folyamat szerkezetét a felelősségi körökkel és az idő- és erőforrásigényekkel együtt ábrázolja. Kétdimenziós koordináta rendszerbe rendezett: Idő (Time) szerint: Nem egyszerű lineáris időskála (pl. 5.30, 5.40, 5.50, stb.), hanem egyedi azonosítónévvel ellátott logikai osztópontokkal (Breakpoints) vagy mérföldkövekkel (Milestones) nemlineáris módon tagolt koordináta tengely (pl. „kezdés+3nap”, „+2. hét szerdája”, „aktuális hónap utolsó munkanapja”) Tevékenység végző egységek (Actors) szerint: Diszkrét beosztású koordináta tengely, amely felsorol bármely hardvert/ szoftvert/ szervezeti osztályt vagy pozíciót (és nem konkrét embert, mert azt kirúghatják!)/ külső szereplőt (ügyfél, szállító, stb.), aki vagy ami felelős lehet tevékenységek elvégzéséért Blokkokból (Block) áll, amik: A blokk fajtáját mutató prefix-szel (pl. IF:, ENDIF:, FOR:, ENDFOR:, SUB:) és egyedi azonosítónevekkel rendelkeznek (8±3 karakter, nagy kezdőbetűs tagolás ajánlott pl. „SzámlaÁtutal”), valamint tartalmazhatnak programkódot is Hosszuk egyenesen arányos az időszükségletükkel Erőforrásigények rendelhetők hozzájuk (költség-, munkaerő- és gépigény). Egy részfolyamat (SubProcess) blokkjai beljebb tabulálva jelennek meg a főfolyamathoz (Main Process) képest A vörös háttérszínű blokkok nem gépesítendő, továbbra is manuálisan végzett dolgokat jelölnek A blokkok fajtái lehetnek: Tevékenységek (Activity) ( ) Döntések (Decisions) ( ), a prefixük egyszerű döntés esetén IF:, ciklus kezdete esetén FOR:. ENDIF: vagy ENDFOR: prefixű tevékenységekkel állhatnak párban, melyek lezárják a feltételes részt vagy a ciklust. Máshol leírt, beágyazott részfolyamatok (SubProcess) ( ), a prefixük SUB: A blokkokat 4 féle nyíl (Arrow) kötheti össze: Előrelépés (Step) ( ) Döntés igaz/hamis ága (Yes/No) ( , ), Visszacsatolás (Feedback) ( ): csak ez léphet hátrafele időben, a többi nyíl nem. Természetesen ez csak látszlagos időbeli visszalépés, ciklusos folyamatok újrakezdésének ábrázolásához használjuk, hogy ne kelljen őket sokszor leírni Konyha, 23. tojásfőző munkás Konyha, 22. tojásfőző munkás t Főzési végszakasz FOR: Megfőtt a tojás? (1fő, 5sec) ENDFOR: Megfőtt a tojás? Főzzed még! (1 fő, 0.1m3 gáz, 60sec, 30.00Ft) Tedd rá a fedőt! (1 fő, 10sec, 3.00Ft) Emeld le a fedőt! (1 fő, 10sec, 3.00Ft)

Üzleti folyamat diagrammok szerkesztési szabályai
Az alábbi példa egy közlekedési vállalat forda-naplózásának (járatok-járművezetők-járművek időbeli összerendelése) törlési folyamatát mutatja Megfigyelhető, hogy a viszonylag bonyolult, beágyazott ciklusokat és feltételeket tartalmazó algoritmus folyamatábrában történő áttekintését nagyban megkönnyíti néhány szerkesztési trükk: A részfolyamatok beljebb tabu- lálásánál követjük a Jackson-elvet (Jackson-principle): bármely algoritmus leírható 3 építőelem: Lépéssorozatok (Sequence): Döntések-szelekciók (Selection): Ciklusok (Iteration): hierarchikus egymásba ágyazásával, anélkül hogy szükség lenne követehetetlen GOTO utasításokra (vagyis a folyamatábrában nincsenek össze-vissza ugráló nyilak, az egyetlen hely, ahol időbeli visszalépés ( ) lehet, az a ciklus újrakezdése) Ha a folyamat blokksorozata egyik oldalán csak a Nem-nyilakat ( ) ábrázoljuk, és a másik oldalán a többit, akkor ezek szépen kirajzolják az egymásba ágyazás struktúráját Lépés1 Lépés2 Lépés3 IF: Lép1 ELSE: ENDIF: Lép2 FOR: ENDFOR: Ciklusmag

Tipikus szervezeti működési zavarok BP diagrammon és a megoldásuk 1
Sorrendi hiba (Follow-up error): A műveletvégzők spontán szervezkedésénél helytelen, fordított logikai műveleti sorrend alakul ki (pl. a munkás előbb gyártja le a munkadarabot, és a művezető csak utána találja ki a tűréshatárt), amely „majdnem végtelen ciklusokhoz” vezet a folyamatos korrekciós igény miatt, jelentősen elhúzva a teljes folyamat végrehajtásához minimálisan szükséges időt, amelyet a kritikus úthoz (Critical Path) tartozó folyamatidőnek nevezünk (bővebben lásd Lesson25). Feloldása: meg kell cserélni a műveletek sorrendjét: Idő: Kezdés óra óra … a végtelenségig Mű-vezető Mun-kás Idő: Kezdés óra óra Mű-vezető Mun-kás Megfelel? Megmunkálás Tűréshatár kitalálása Utasítás: csináld újra Tűréshatár kitalálása Tűréshatár közlése Megmunkálás Döntési felelősség feljebb tolása (Push-up game): Amikor az alkalmazottak információk és hatáskör híján soha nem mernek dönteni. Kézivezérlés (Over-control): Amikor a főnök monopolizálja a döntéseket, mert ettől hatalmasabbnak érzi magát, de soha nem tud időben dönteni. Üzletileg képzetlen kisvállalkozók követik el, vagy olyan vezetők, akiknek a személyisége nem elég nyitott és rugalmas a vezetéshez. Terhelés-kiegyensúlyozat-lanság (Unbalanced flow): A főnök vagy az alkalmazottak minden munkát egy olyan alkalmazottra tolnak, aki nem tud nemet mondani, vagy csak ő ért hozzá. Feloldása: Az alkalmazottakat információk és hatáskörök delegálásával fel kell készíteni az önálló, gyors döntésre, és ezután már csak periodikusan kell beszámoltatni őket: Idő: Kezdés hét hét … a végtelenségig Felső-vezet. Közép-vez. Alkal-maz. Ügy-fél Idő: Kezdés óra óra … hétvége … hóvége Felső-vezet. Közép-vez. Alkal-maz. Ügy-fél Oktat meg-bíz Kiszol-gál Kére-lem Elin-tézve Telje-sít-mény OK? Vadá-szat Ivá-szat politi-ku-sok-kal Há-zas-élet Kérelem Bead-vány Folya-mod-vány Elintézve Kiszolgál Utasí-tás Dön-tés Kup-leráj-ba Sze-rető-höz Vadá-szat Ivá-szat politi-ku-sok-kal Há-zas-élet

Tipikus szervezeti működési zavarok BP diagrammon és a megoldásuk 2
Labdázgatás (Snowballing game), egymásra mutogatás (Fingerpointing/Blaming game): amikor egy szervezet különböző részei erősen ellenérdekűek, vagy nem érdekeltek egy közös szervezeti célban, és megpróbálják egymásra tolni a felelősséget, illetve az ügyfelek problémáit, a végtelenségig húzva a folyamatot. A szervezeti részek felső vezetései közt nincs vagy rossz a kommunikáció, egy információ oda-vissza bejárja a szervezeti hierarchiát, hihetetlen módon lassítva a dolgokat (a „hivatalos út” csapdája). Az ilyen helyzet a korrupció melegágya, mert a felsővezetőket megvesztegetve - hogy közvetlenül szóba álljanak egymással - a folyamat valamennyire gyorsítható. Feloldása: adott cél elérésében érdekeltté kell tenni minden szervezeti részt, úgy hogy egyvalaki miatt mindenki bukjon, és csak együttműködve nyerhessenek. Az együttműködésre csapatot (Team) kell létrehozni minden szervezeti rész szakértőiből, melynek egy projekt (Project) keretében adott határidőre, adott erőforrások felhasználásával el kell érnie egy meghatározott célt. A csapat tagjai megegyeznek egy mindenki számára elfogadható ütemtervben, amelyet saját szervezeti részükben végrehajtatnak: Pro-jekt Dön-tés Csa-pat épít. Utasí-tás Bead-vány Kiszolgál Kérelem Elintézve Meg-ol-dás Jóvá-hagy? Idő: Kezdés hét hét … a végtelenségig Gyártás.Felső-vezet. Gyártás.Közép-vez. Gyártás.Alkal-maz. Ügyfél Market Felső- vezet. Market Közép-vez. Market Alkal-maz. Idő: Kezdés hét hét nap nap Gyártás.Felső-vezet. Gyártás.Közép-vez. Gyártás.Alkal-maz. Ügyfél Market Felső- vezet. Market Közép-vez. Market Alkal-maz. Kérelem Bead-vány Folya-mod-vány Elintézve Kiszolgál Utasí-tás Dön-tés Átirat $

Az üzleti folyamatok átszervezésének (BPR) végeredménye 1
Az alábbi példában egy gyógyszerkutató labor kutatási folyamatának BP diagrammja látható ban 1 naptári hónap alatt készült el, 3db szakértő összesen 104 munkaórányi teljesítményével, 5000Ft/h mérsékelt szakértői díj mellett 520EFt önköltségen Bármely programozásban járatos ember 1. reakciója ez lenne rá: „Ettől essek hasra? Első programom folyamatábrája bonyolultabb volt!”Miért készült ilyen sokáig,miért ilyen drága? Azért, mert elkészültéhez szükség van folyamatszervezési, és az adott folyamatban járatos szakértőre (min. 2 felsőfokú végzettségű ember) Ráadásul, ők nem egyszerűen optimalizálnak egy algoritmust, és diagrammon rögzítik: minden ábrázolt tevékenység mögött kőkemény hatalom-, hatáskör- és erőforrás-megosztási alkuk állnak, ha azt akarjuk, hogy a szervezet nagy része elfogadja a tervet Ezekhez az alkukhoz gyakran van szükség a felsővezető támogatására és részvételére a döntésben, ami az ő nagyon szűkösen rendelkezésre álló idejében történik, és így nem is lehet folyamatosan haladni. Ugyanis senki nem örül neki, ha egy pár hete a szervezetnél lévő rendszerszervező azt mondja neki: „Kedves Ödön, kiderítettük, hogy az ön által végzett munka teljesen felesleges a Beste Bank részére, ezért most áthelyezzük alacsonyabb beosztásba kevesebb pénzért többet dolgozni, vagy veheti a kalapját!”

Az üzleti folyamatok átszervezésének (BPR) végeredménye 2
Az elkészült BP diagramm lehetővé teszi, hogy a szervezet sokkal gyorsabb, hatékonyabb erőforrás-kihasználású, rugalmasabb folyamatokat hozzon létre, ezért nő a szolgáltatásának minősége és a versenyképessége. Ez pedig bőven, sokszorosan megtéríti a BPR látszólag tetemes költségeit (pl. a szóban forgó kutató gyógyszerlabor 5.5 órai működéssel termeli ki a fenti diagramm költségét) Ez persze csak akkor igaz, ha a rendszerfejlesztő megkapja a szervezet felsővezetőjének teljes felhatalmazást a változtatások bevezetésére. Hiszen a BPR következtében egzisztenciák, ház- és autó hitelek dőlhetnek be, karrierek törhetnek derékba, tehát komoly szervezeti ellenállással kell számolni. (pl. az 1990-es évek közepén egy átlagos magyar cég átvilágításakor ki lehetett mutatni, hogy a – gyakran vezető állású - alkalmazottak 30%-ának a munkája felesleges, ha kirúgnák őket, semmi nem történne) Ezenkívül, az elkészült BP diagrammnak még egy óriási haszna van: ez képezi egy relációs adatbázis rendszer (Relational DataBase System, RDBS) megtervezésének az alapját, amire majd egy integrált vállalatirányítási rendszer (Enterprise Resource Planning, ERP), illetve az adatbányászathoz szükséges adattárház (Data Warehouse, DW) alapulhat: A BP diagramm minden blokkja kiegészíthető olyan információkkal, hogy adott tevékenység vagy döntés elvégzéséhez milyen adatokra van szükség: Milyen egyedeket (Entity) használ: azonos tulajdonságokkal leírható dolgok, nagy számban fordulnak elő (Instance), azonosítójuk van Az egyedek milyen tulajdonságokkal (Attribute) jellemezhetők: bármely érzékszervekkel észlelhető és rögzíthető adat, meghatározott: Névvel (Name): jellemzően 8±3 karakter, speciális karakterek nélkül Adattipussal (Type): szám, szöveg, dátum, kép, hang, mozi, stb. Tárolási mérettel (Size): számjegy, karakter, pixel vagy byte, stb. Kitöltéssel (Required): kötelező(Compulsory,*)/opciós(Option,o) Az adott szerepet (Role) ellátó műveletvégzőnek (pl. adatrögzítő) 1 tevékenységnél milyen adatkezelési műveletekhez (Data Processing Operations) van jogosultsága (Rights) az egyes tulajdonságok tekintetében: Létrehozás (Create), Új beírás (Write), Olvasás (Read), Már létező módosítása (Modify), Már létező kiűrítése (Nullify), Létező törlése (Delete) Az ilyen módon kiegészített BP diagrammot adatfolyam diagrammnak (Data Flow Diagram, DFD) nevezzük. Idő: hét Ügyfél Market Közép-vez. Market Alkal-maz. Kérelem Bead-vány

A hatékony adatbázis-tervezés 3
A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 1 Az erős versenyben helytálló, gyorsan pörgő szervezet által termelt hatalmas adatmennyiséget papír-alapú adatkezelési rendszerben már képtelenség mozgatni az üzleti folyamat során, relációs adatbáziskezelő (Relational Database Management System, RDMS) rendszerre van szükség. Azonban, súlyos hiba lenne egy az egyben számítógépre tenni a papír-alapú struktúrát, a két eszköz eltérő tulajdonságai miatt: A papír logikailag rendkívül rugalmas struktúrájú adattároló: számot, szöveget, képet tárol, akár laponként változó szerkezetben, viszont visszakeresési sebessége borzalmasan lassú és élőmunka-igényes, mert fizikai anyagmozgatást igényel. Ezért a papír-alapú rendszerek adatstruktúráit, űrlapjait úgy tervezik, hogy minden fontos egyedből beleszorítanak egy pár fontos tulajdonságot, és csak pár rekordnak adnak helyet. (Erre látunk példát egy igen közkeletű űrlapon: az ÁFA-s számla a Számla, a Kibocsátó, a Vevő, egyedek tulajdonságait tudja tárolni, illetve a Megvásárolt tétel 12 előfordulását. Mivel az eladó neve és a fizetve jelzés lemaradt róla tervezéskor, egyszerűen ráfirkantják). Ennek a rugalmasságnak azonban nagyon nagy ára van a lassúság mellett is: A 13. megvásárolt tétel már nem fér rá, ezért vagy adatvesztés (Data loss) jön létre, Vagy új számlát kell nyitni, ami szinte megduplázza a munkát és a szükséges tárolóhelyet: minden más adatot feleslegesen még egyszer be kell írni, ez a redundancia (Redundancy) Vagy nem töltik ki a többi adatot, de ekkor nem egyértelmű a hivatkozás (Ambigous Reference), kié a számla

A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 2 Egy adatbázis tábla (Database Table) önmagában rendkívül rugalmatlan tároló: soraiban rekordok (Record) találhatók, amelyek egy egyed (pl. Ügyfél) adott előfordulásait (pl. „Kovács Jánosné”, „Nagy Józsefné”) tárolják, és a merevlemezen sorfolytonosan egymás után állnak. A rekordok csak azonos mező (Field) szerkezetűek lehetnek, a mezők az egyed-előfordulások tulajdonságait tárolják. Ezért a rekordok tárolási hossza fix, így előre kiszámítható, hol kezdődik a merevlemezen az n-edik rekord, anélkül, hogy végig kellene olvasni az előzőket, emiatt itt a visszakeresés gyors lesz, de ennek ára van: A valóságban előforduló adatszerkezetek NEM fix hosszúságúak (pl. egy anyának igen eltérő számú gyereke lehet – Kovács Józsefné: 0.6, Orsós Petronella Dzsenifer: 12). Ha fix számú gyerek adatait tudjuk csak tárolni, a legtöbbször tárolóhelyet pazarlunk (Redundancy), néhol pedig adatot vesztünk (Data Loss) Nem lehet két rekord közé beszúrni egy harmadikat, csak a végéhez írni, Ha kitörlünk egy közbülső rekordot, a helye ott marad kihasználatlanul. Az E.F Codd által 1971-ben feltalált relációs adatbáziskezelés (Relational DataBase Management, RDBM, lásd: Codd) nem fix hosszúságú struktúrákat kezelni képes, nagy sebességű, redundancia-mentes, adatvesztés-mentes, egyértelmű hivatkozásokat tárol: A nem fix hosszúságú gyakorlati adatstruktúrákat addig bontja szét (Decomposition), amíg fix hosszúságú rekord-struktúrákat tartalmazó táblákat nem kap Minden táblába rekordjaikat egyedileg (Unique) azonosító elsődleges kulcs (Primary Key) mezőket vezet be. Utána a szétbontott egyedeket az eredeti struktúra adatainak megőrzése érdekében relációkkal (Relation) köti össze: 2 tábla rekordjai közti hivat-kozási kapcsolat, ahol az 1 oldali tábla adott rekordjának elsődleges kulcsára a több oldali táblába rakott idegen kulcsmező (Foreign Key) megegyező értéke hivatkozik: több gyerek : 1 anyához

A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 3 Két tábla rekordjai közti reláció számossága elvileg háromféle lehet:1:1 pl. Menyasszo-nyok:Vőlegények, 1:több pl. Anyák:Gyerekek, több:több pl. Könyvek:Kikölcsönzők. De ezek ábrázolása megoldható kizárólag 1:több kapcsolatokkal: Ha két tábla rekordjai 1:1 kapcsolatban vannak, a két tábla összevonható egy táblába Ha a két tábla rekordjai több:több kapcsolatban vannak, ez ábrázolható, úgy hogy a két összekötött törzstábla (pl. Könyvek, Kikölcsönzők) elsődleges kulcsaira hivatkozó idegen kulcsokat tartalmazó relációs tábla (Relation Table) (pl. Kölcsönzések) köti őket össze 2db 1:több-höz kapcsolattal (1 Könyv vagy 1 Kölcsönző:több Kölcsönzés): Könyvek Kód Író Cím 1 Jókai Mór Arany 2 Kőszívű 3 Jancsó-Hernádi Közös... 4 Krúdy Gyula A pofon 5 Mike Tyson Kölcsönzések Kód KönyvKód KölcsKód 1 2 3 5 4 Kikölcsönzők Kód Név Cím 1 Nagy József 7622 Pécs, Rákóczi u. 80. 2 Kiss Katalin 7632 Pécs, Eszék u. 8. 3 Kovács Mihály 7632 Pécs, Nagy Imre u. 105. 4 Török István 7624 Pécs, Jakabhegyi u. 6. 5 Szabó Miklós 7621 Pécs, Fehérhegyi u. 1. (A relációs táblának is lehet elsődleges kulcsa, de annak nincs szerepe a kapcsolat ábrázolásában. Arra szolgál, hogy a relációs táblára is hivatkozhassanak más táblák.) Mivel egy nagy adatbázis sok táblája közti rengeteg relációt nem lehet áttekinthető módon ábrázolni a táblák tartalmán keresztül, szükség volt egy egyszerűsített szimbolikus ábrázolásmódra a táblaszerkezetek (egyedek) és relációik ábrázolására. Ez az egyedkapcsolati diagramm (Entity Relationship Diagram, ERD), amely a relációs adatbázis tervezés fő eszköze, és a következő jelöléseket alkalmazza: az egyedek névvel ellátott, lekerekített sarkú dobozok, bennük az elsődleges kulcsok narancsszínűek, elő-jelölőjük #, a sima tulajdonságok lilák, az idegen kulcsok sötétzöldek. A kötelezően kitöl-tendők előjelölője *, az opcionálisaké o, az 1:több kapcsolatot csirkeláb (Crow Leg) jelöli: Könyv # Kód * Író * Cím Kikölcsönző * Név Kölcsönzés * KönyvKód * Kölcskód 1 Könyv:több Kölcsönzés több Kölcsönzés:1 Kölcsönző

A hatékony adatbázis-tervezés 3.előfeltétele:relációs adatbázis 4
Kpfizetési számla # Számlaszám * Kibocsátó neve * Kibocsátó címe * Kibocs. Adósz. * Vevő neve * Vevő címe * Számla kelte * Áfa-tartalom% * Végösszeg * Áthárított adó% o Eladó neve o Fizetve Az adatfolyam diagramm tevékenységeinél rög-zített valós adatstruktúrák (pl. ÁFA-s számla) nem alkalmasak az adatbázisba tételre, mert tele vannak belső 1:több kapcsolatokkal, amelyek redundanciát, adatvesztést, és kétértelmű hivatkozásokat okoznak, pl: Egy számlához több tétel tartozik: együtt tá-rolva őket csak fix számú tételt tudunk kezelni Egy cég több eladót alkalmaz: de melyik adta melyik számlát melyik vevőnek? Egy vásárló több számlát kap: de miért kell mindig újra és újra beírni az összes adatát? Egy termék több tételben szerepel: de miért kell mindig újra kitölteni az ÁFA-százalékát? Ezért a valós adatstruktúrákat át kell tervezni, normalizálni (Normalize) kell 5 lépésben: 1. Valós adatstruktúra szétszedése belső 1:több kapcsolatokat nem tartalmazó egyedekre 2. Elsődleges kulcs kijelölése minden egyedben 3. Nem a kulcstól függő tulajdonságok kidobása külön egyedbe (pl. az irányí- tószám meghatározza a tele- pülésnevet, így ez különválik) 4. Az egyedek összefüggő rendszerbe kötése relációkkal 5. Több:Több kapcsolatok kivál- tása 1:több+relációs táblákkal A normalizáció eredményeként a valós adatszerkezet ember szá- mára áttekinthetetlenül sok egyed- re esik szét, de ez az adatbáziske- zelőt nem zavarja: helypazarlás nélkül, pontosan tárol adatokat és nagyon gyorsan keres vissza! Tétel * ITJ-kategória * Termék neve * Menny. egység * Mennyiség * Egységár * Érték Cég # Adószám * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Eladó # Eladókód * Adószám Számla # Számlaszám * Dátum * Végösszeg * Áthárít.adó% * Fizetve * Eladókód * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * SzlaSzám * Vonalkód Irányszám # Irányítószám * Településnév Vásárló # Vásárlókód Termékfajta # Vonalkód * Menny.egys. * Egységár * ITJ-kategória IparTermJegyz # ITJ-kategória * Áfa-sáv ÁfaKategoria # Áfa-sáv * Áfa%

A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 5 Egy belső orvoshoz több eset tartozik és egy eset is több belső orvoshoz tartozik Egy beteghez több eset tartozik, de egy eset csak egy beteghez tartozik BelsőOrvos # OrvosKód * Név * Beosztás * Tel * SzakTerül * Fizetés Beteg # SzemIgSzám * Név * LeányNév * Kor * CsaládÁll * Foglalkozás * Lakcím * HozzátartNév * Apanév * ApaFoglalk A normalizált szerkezetű relációs adatbázis az SQL nyelv segítségével kérdezhető le egyszerűen és nagy sebességgel: Pl. Lekérdezés: Kik a főorvos úr betegei? A belépési pont (Entry Point) az ismert információ (pl. főorvos), a WHERE (szűrőfeltétel) részben foglal helyet. A kilépési pont (Exit Point) az eredmény, ami kell (pl. beteg neve), a SELECT (kiválasztott eredmény) részben foglal helyet. A lekérdezési útvonal (Query Path) a két pont közt halad minimális számú reláción keresz-tül, és a FROM részben definálódik: ezt nem kell bepötyögni, csak az utat egérrel kihúzni! SELECT Beteg.SzemIgSzam, Beteg.Név FROM ( Beteg INNER JOIN Eset ON Eset.SzemIgSzam= Beteg.SzemIgSzam) OvosEset ON OrvosEset.EsetKod= Eset.EsetKod) BelsoOrvos ON BelsoOrvos.OrvosKod = OrvosEset.OrvosKod) WHERE BelsoOrvos.Beosztas = „Főorvos”; húz húz OrvosEset * OrvosKód * EsetKód Eset # EsetKód * SzemIgSzám húz OrvosEset OrvosKód EsetKód 11 411 412 13 413 Eset SzemIgSzám EsetKód GZ-II-2547 411 GF-I-3624 412 413

A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 6 Az SQL kód arra is alkalmas, hogy a normalizáció által széttagolt sok-sok táblából felhozzon/ azokba visszavi-gyen adatokat egy elektronikus, akár interneten is elérhető űrlapokból (Forms) álló grafikus felhasználói felületről, amely hasonlóan nézhet ki az eredeti papír űrlapokhoz, hogy ismerős legyen a felhasználónak. A nagy különbség, hogy ezek korlátlanul bővíthetők (pl. 1 számlának tetszőleges számú tétele lehet), az adatrög-zítés nagy része menüből mehet, és nem pötyögéssel, és a mögöttük álló normalizált táblaszerkezet gyorsan, pontosan tárol és keres vissza! SELECT Szamlak.SzlaSzam, Szamlak.Datum, Szamlak.VegOsszeg, Szamlak.Fizetve, Szamlak.EladoKod, Szamlak.VasarloKod, Eladok.Nev, Eladok.AdoSzam, Cegek.Nev, Cegek.HazSzam, Cegek.Emelet, Cegek.LakasSzam, Cegek.KozTerNev, Cegek.IranySzam, IranySzamok.TelepulNev, Vasarlok.Nev, Vasarlok.HazSzam, Vasarlok.Emelet, Vasarlok.LakasSzam, Vasarlok.KozTerNev, Vasarlok.IranySzam, IranySzamok_1.TelepulNev FROM ((IranySzamok AS IranySzamok_1 INNER JOIN Vasarlok ON IranySzamok_1.IranySzam = Vasarlok.IranySzam) INNER JOIN(((IranySzamok INNER JOIN Cegek ON IranySzamok.IranySzam = Cegek.IranySzam) INNER JOIN Eladok ON Cegek.AdoSzam = Eladok.AdoSzam) INNER JOIN Szamlak ON Eladok.EladoKod = Szamlak.EladoKod) ON Vasarlok.VasarloKod = Szamlak.VasarloKod); Cég # Adószám * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Eladó # Eladókód * Adószám Számla # Számlaszám * Dátum * Végösszeg * Áthárít.adó% * Fizetve * Eladókód * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * SzlaSzám * Vonalkód Irányszám # Irányítószám * Településnév Vásárló # Vásárlókód Termékfajta # Vonalkód * Menny.egys. * Egységár * ITJ-kategória IparTermJegyz # ITJ-kategória * Áfa-sáv ÁfaKategoria # Áfa-sáv * Áfa%

A hatékony adatbázis-tervezés 3.előfeltétele: relációs adatbázis rendszer 7 Az elektronikus űrlapok tartalmi tervezése az adatfolyam diagramm segítségével történik: Először a normalizáció eredményeképpen létrejött egyedeket rácsatoljuk a diagramm azon blokkjaira, ahol az adott tevékenység elvégzéséhez szükség van rájuk, és meghatározzuk, hogy a műveletet végző milyen jogosultságokat kapjon a kezelésükre (pl. a Számlaösszeállítás művelethez az Eladónak szüksége van az Eladó, Cég, Vásárló egyedekre olvasási joggal, a Számla, Tétel egyedekre létrehozási/írási joggal) Minden műveletből egy munkaképernyő lesz, és a hozzá kapcsolt egyedek egymás közti relációi automatikusan meghatározzák, hogyan fog kinézni a munkaképernyő: A munkaképernyővel 1:1 kapcsolatban álló egyed lesz a Bázis egyed (pl.: egy számlához egy számlaösszeállítás űrlap tartozik és fordítva is így igaz) A bázis egyeddel 1:több kapcsolatban álló egyedek Alűrlapon lévő egyedek lesznek (pl.: egy számlához több tétel tartozik, amiket fel kellene sorolni egy külön listában a számlán) A bázis egyeddel több:1 kapcsolatban álló egyedek Joinolt egyedek lesznek (pl.: egy számlát egy cég alkalmazásában álló egy bizonyos eladó ad ki, és egy vevő kapja, ezek tulajdonságait is fel kell tüntetni a számlán.) Eladó # Eladókód * Név * Adószám Számla össze- állítás Számla # Számlaszám * Dátum * Végösszeg * Áthárít.adó% * Fizetve * Eladókód * Vásárlókód Cég # Adószám * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Vásárló # Vásárlókód * Név * Házszám * Emelet * Lakásszám * Közterületnév * Közter.típus * Irányítószám Tétel # Tételkód * Mennyiség * Érték * Szlaszám * Vonalkód

A hatékony adatbázis-tervezés 4.előfeltétele: adattárház és OLAP 1
A relációs adatbáziskezelővel az űrlapokhoz teljesen hasonló módon jelentéseket (Reports) is generálhatunk. Ezek három dologban különböznek az űrlapoktól: Nem rögzíthetünk beléjük adatot, csak megjelenítik az adatbázis adatait, ezt viszont szöveges, táblázatos és diagrammos formában is meg tudják tenni Ezek az adatok nem a szervezet által végzett tevékenységek elemi, széttagolt tranzakció-jellegű adatai (Transaction Processing) (pl. egy adott számla végösszege) hanem régiókra, ügyfelekre, alkalmazottakra, termékekre, stb. csoportosított és összesített, aggregált adatok (Aggregate Data) (pl. Dél-Dunántúl régió 3. negyedéves összforgalma romlandó élelmiszerekből) Nem a szervezet alsó szintjén dolgozók használják fel őket rutinszerű egyszerű döntésekhez, hanem a felsővezetés a nem rutinjellegű stratégiai döntésekhez A jelentések statikus szerkezetűek (Static Structure): a mutatott adatok fajtái, csoportosítása és aggregációi fixek, csak az adattartalom frissül folyamatosan az adatbázisból. Az üzleti életben azonban olyan nagy a bizonytalanság, hogy a legnagyobb pénzt érő döntési problémák nem struktúráltak (Ill Structured Decision Problems) – a felsővezető nem tudja megadni, hogy milyen adatokra lesz szüksége 3 vagy 6 hónap múlva! Bármi kellhet, attól függ, mi lesz! Ezért rendszerfejlesztéskor általában elkezd követelni mindenféle fajta jelentést, ami csak eszébe jut: pl. „kérem a termékkategóriánkénti eladásokat negyedévenként, régiónként, üzletkötőnként, fogyasztói csoportonként” Egyszerűen nincsen tudatában, hogy ezzel a félmondattal egy több száz oldalas jelentést definiált, mert ezen halmazok elemei összeszorzódnak: pl. a 44 kategória diagrammja × 4 negyedév × 5 régió × 8 üzletkötő × 12 fogyasztói csoport = 1920 db diagramm A tapasztalatlan adatbázis szakember ezt el is készíti, és még büszke is rá, hogy milyen ügyes volt. A menedzser bele fog fulladni a kinyomtatott jelentésekbe! Senki nem olvas el 1920 oldalt, pláne nem egy elfoglalt felsővezető (max. 5 oldal/nap) Nagyon elégedetlen lesz, mert bár a rendszer működik, és sok pénzt fizettek érte, mégsem tudja használni semmire, hiába kap egy több mint ezer oldalas jelentést, neki csak az az öt szám kellene, amit pont nem talál benne. Ezt a jelenséget nevezzük jelentéstenger-csapdának (Report Flood Trap).

A jelentéstenger csapda on-line analitikus feldolgozás (On-Line Analytical Processing, OLAP) bevezetésével oldható fel, amely egy, a relációs adatbáziskezelésre épülő, de annál fejlettebb adatkezelési módszertan: Lehetővé teszi az adatok dinamikus, futás közben megváltoztatható struktúrában (Dynamic Structure) történő megjelenítését A felhasználó számára biztosítja a csoportosítások, aggregációk, rendezések bonyolult SQL programozás és adatbázis áttervezés nélküli, egyszerű grafikus felhasználói felületen (Graphic User Inteface, GUI) keresztül történő azonnali megváltoztatását, így nem kell az adatbázis programozókra várni Tárolási rendszere lehetővé teszi az ehhez szükséges nagytömegű, de viszonylag egyszerű aggregációs számítás gyors elvégzését Az OLAP tárolási rendszerének hierarchikus részei a nagy egységektől a kicsi felé haladva: Adattárház (Data Warehouse, DW): egy szervezet szabványos mezőtipusokat használó, összefüggő adatbázis terv alapján, azonos relációs adatbáziskezelőben tárolt összes, tisztított, szinkronizált, kompatibilis adata. Mivel az adattárház elég divatos frázis, gyakran büszkélkednek vele olyan szervezetek, akik nagyon messze vannak még tőle: NEM adattárház, amikor egy szervezet különálló informatikai szigetalkalmazásait furfangos programozók alkalmi megoldásokkal összekötögetik. Az ilyen rendszer recsegve-ropogva eleget tesz vezetői jelentésgenerációs feladatoknak de OLAP-ot és adatbányászatot már nem tud kiszolgálni (Ilyenre tipikus példa az átlagos magyar vegetáló kis-középvállalatok (KKV) rendszerei). A valódi adattárház több évnyi és százmillió forintnyi erőfeszítésre van ettől a helyzettől: az eredetileg elszigetelt adatbázisok terveinek egyesítése, tartalmuk szinkronizálása nem úszható meg a szervezet egészére kiterjedő BPR nélkül, ami költséges és sok konfliktussal járó dolog. Így önálló adattárház fejlesztése csak a legnagyobb cégek esetén térül meg. Ezért egy KKV számára sokkal reálisabb lehetőség adattárház létrehozására integrált vállalatirányítási (Enterprise Resoulce Planning, ERP) szoftver megvásárlása: Olyan adattárház, amely a szervezet különböző funkciói (pl. könyvelés, pénzügy, értékesítés, gyártás) szerint önmagukban is működőképes modulokra (Module) van osztva, és részenként is megvásárolható és bevezethető. A modulokat az OLAP terminológájával adattárnak (Data Mart) nevezzük, és olyan magas szinten vannak integrálva, hogy a teljes szervezeti működés összes folyamatára biztosítják a redundancia- és adatvesztésmentességet, valamint az egyértelmű hivatkozásokat Az ERP szoftver gyártók általában tanácsadói szolgáltatást is adnak a bevezetéskor

Az ERP szoftvergyártók a KKV-k igényeihez és finanszírozási lehetőségeihez igazodva különféle méretbeli, árbeli és tudásbeli verziókban kínálják termékeiket: Csak a nagy gyártók ( ) gyártanak minden funkcionális modult, a kisebbek nem Az ERP rendszerek sok szektor-specifikus tudást igényelnek: másképp működik egy bank, egy egyetem, egy olajtársaság. A nagy gyártók szépen elosztották egymás közt a szektorokat, hogy ne kelljen versenyezniük: Ezenkívül, nem olyan rugalmasak, mint azt fennen hirdetik magukról: a bevezetéskor inkább a szervezetnek kell a folyamatait az ERP-hez igazítani, mint fordítva. A gyártóknak annyi igazsága van gazságuk mellett, hogy egy kaotikus szervezetben nem lehet eredményesen ERP-t bevezetni, és így kikényszerítik a bevezetés során a drága és hosszadalmas BPR-t, amit általában szintén ők végeznek Ezért egy ERP-bevezetés költsége még egy jól működő céget is megráz: kb év, mire az ERP nem a veszteségeket meg a gondokat termeli, hanem elkezd stratégiai verseny-eszközzé válni, igaz attól kezdve a szervezetnek felmérhetetlen előnye van olyan versenytársakkal szemben, akiknek nincs, vagy kényelmességből, takarékosságból csak 1-2 modult vezettek be. Erre például szolgálhat a finn elektronikai alkatrészgyártó, az Elcoteq ( ) tündöklése és hanyatlása: bevezették a Baan rendszer ( ) könyvelés és pénzügy modulját, azonban a logisztikát nem, és kicsi, toldozott-foltozott szigetalkalmazásokkal pótolták. A felsőveze-tés szűklátókörűsége eredményeképpen 2006-ban negatív üzleti-üzemi eredményt sikerült elérniük egy évi 10-12%-kal dinamikusan bővülő piacon! ERP rendszerek Vállalat: kis közepes nagy Microsoft Navision X Microsoft Axapta SAP Business One SAP All-in-One SAP Business Suit ProgenMachinátor Progen - sERPa Szektor Microsoft SAP Axapta Navis Kis/nagykeresked. X gyártás üzleti szolgáltat. építőipar élelmiszeripar divat-, textilipar szállítmányozás jövedéki termékek államigazgatás szolgáltatás olajipar postai szolgáltatás banki szolgáltatás egészségügy gyógyszeripar vasúti szolgáltatás telekommunikáció média mérnöki fejlesztés

Ha a szervezet szert tett működő adattárházra, ettől kezdve az adatok sem úgy jelennek meg az elemzés számára mint adott adatbázistáblák adott mezői, holott az OLAP relációs adatbázis kezelésen alapul: pl. ha biztosak lehetünk benne, hogy a Dátum vagy Régiókód az egész adattárház több 1000 táblájában ugyanolyan típussal, ugyanazt jelentik, akkor mindegy hogy melyik táblában tárolódnak, egyfajta „virtuális mezővé” válnak az OLAP tárolási rendszerében: Dimenzió (Dimension, DIM): egy adott típusú, értékhatárú mező Pl.: Sales, Profit Pozíció (Position, POS): egy dimenzió egy lehetséges értéke Pl.: Sales={Low, High}, Profit={Low, High} Adatkocka (Data Cube, DC): több dimenzió értékeinek összes lehetséges kombinációja, Pl.: Sales×Profit={ (Low,Low), (Low,High), (High,Low), (High,High) } cellákból áll Változó/mérték (Measure, MS): egy dimenziókból álló adatkocka celláiban megfigyelt azonos típusú értékek Pl.: Number of Customers Hierarchikus szintek (Hierarchic Levels, HL): Egy dimenzió halmaz-részhalmaz kapcsolatban álló felső/alsó szintű értékhalmazai A felsőbb szint egy értékéhez az alsóbb szint összes értéke tartozik Pl.: havi_eladások={jan..dec}  heti_eladások={1..4}  napi_eladások={H..P} Aggregáció (Aggregation): a hierarchikus szintek mentén történő felfele mozgás aggregációs függvények (Count:darab, Sum:összeg, Avg:átlag, Min, Max, Stdev:szórás, Var:variancia) segítségével Lefúrás (Drill): a hierarchikus szintek mentén történő lefele mozgás az aggregátumok mögött álló elemek kibontásával Az adatkockát tulajdonképpen a programozásból már ismert többdimenziós tömbök és az adatbázis táblák „közös gyermekeként” képzelhetjük el: Az adatbázis táblában csak sorok és oszlopok lehetnek, de sort/oszlopot bármikor be lehet szúrni/törölni A többdimenziós tömbben nemcsak sorok, oszlopok, hanem több dimenzió is lehet, de nem lehet deklaráció után dimenzió-értékeket beszúrni/törölni Az adatkocka objektum lehet sok dimenziós, és bármikor lehet dimenzió értékeket beszúrni/törölni, viszont szerkezete jóval bonyolultabb az előbbieknél

Képlet (Formula): Több adatkocka measure-jeiből (pl. eladás, ár, árrés) függvényekkel, matematikai műveletekkel kiszámított újabb adatkocka (pl. profit) A résztvevő adatkockák dimenzióinak NEM kell teljesen azonosnak lennie, elég, ha valamely hierarchikus szintű bontásukban kompatibilisek egymással A dimenzionális egyeztetést és a számításokat az OLAP motor (OLAP engine) automatikusan elvégzi Kivételekben történő bányászkodás (Mining by Exceptions): amikor a felsővezető az aggregált adatok közül kiugrót, szokatlant 1 kattintással, 1 perc alatt – programozás nélkül - lefúrással részekre bontja, és megtalálja a döntéshez szükséges infót (pl. a veszteségek oka), anélkül, hogy átnyálazná a mögöttes rekordot! Miért pont Buffaloban csökkentek a legjobban az eladások? katt A lojális vevőinket vesztjük el! Miért pont az alacsony –közepes profitabilitású csoportban nagy az esés? katt

Az OLAP rendszerek mezítlábas formáját, az Excel Kimutatásokat már a Lesson8–ban ismertettük. OLAP rendszereket számos gyártó kínál (lásd: OLAP), ezek két csoportra oszthatók: Relációs OLAP (ROLAP): az adatkockák nem tárolódnak fixen, hanem mindig relációs adatbázisból számolódnak ki. Ez lassabb, de kisebb tárigénye van Multidimenzionális OLAP (MOLAP): az adatkockák sokdimenziós linkrendszer segítségével fizikailag tárolódnak. Ez gyorsabb, de óriási a tárigénye Az OLAP adatkockák csillag/hópehely struktúrának (Star/Snowflake Structure) nevezett tábla-csoportokban tárolódnak az adattárházban: A struktúra középpontjában mindig tranzakciókat (pl. eladások), az üzleti folyamat műveleteit leíró egyedek találhatók, ezek OLAP-ban a tény- egyedek (Facts) A tényegyedekben szereplő elsődleges-/ idegen kulcsmezőket tényattribútumoknak (Fact Attribute) nevezzük, más mezőik mértékek (Measure) lesznek A tényegyedekre csatolódnak (Fact-Dimension Join) körben a dimenzió leíró egyedek (Dimensions) A dimenziók önmagukban is 1:több csatolásokkal (Intra-Dimension Join) láncba kapcsolt egyedekből álló fix szint-(Level) számú hierarchiát (Hierarchy) alkothatnak A dimenziókban szereplő elsődleges- és idegen kulcsok a dimenzió attribútumoknak (Dimension attribute), más mezőik a dimenzió leíró adatok (Dimension-related Data) Termék # Vonalkód * Név * Egységár * ITJ-kateg Cég # Adószám * TuldKód Vásárló # Vásárlókód * SzegmKód Számla # Számlaszám * Dátum * Végösszeg * Adószám * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * Szlaszám * Vonalkód ITJ # ITJ-kateg Szegmens # SzegmKód Tulajdonos # TuldKód

Bonyolultabb csillag, vagy hópehely-struktúrák szerkezetét az aggregációs diagrammon (Aggregation Diagramm) ábrázolhatjuk: ez olyan egyedkapcsolati (ER) diagramm, amely egy koordináta rendszerben van ábrázolva: Az X tengelyen az aggre-gációs szintek vannak Az Y tengely mentén vízszintes sávokban a tényegyedek, illetve az egyes dimenziók egyedei vannak A kocka-aggregátum egyedek (Cube Aggregates) a tényadatok sávjában, azok mögött jelennek meg. Cég # Adószám * CégNév * TuldKód Tulajdonos # TuldKód * TuldNév Termék # Vonalkód * Név * Egységár * KategKód TermékKateg # KategKód * TermKatNév Eredeti tényadatok Számla # Számlaszám * Dátum * Végösszeg * Adószám * Vásárlókód Tétel # Tételkód * Mennyiség * Érték * Szlaszám * Vonalkód Dimenziók Vásárló # Vásárlókód * Név * SzegmKód Szegmens # SzegmKód * SzegmNév HétSzegKat * HétSzám * SzegmKód * KategKód * Érték Nap # Dátum * HétSzám Hét # HétSzám HétSzeg * HétSzám * SzegmKód * Érték 1.Hét 2.Hét JóVevő Rossz Csavar Anya 58$ 72$ 25$ 20$ 26$ 79$ Aggregációs szintek JóVevő Rossz 1.Hét 137$ 51$ 2.Hét 142$ 46$

Szakirodalom Szervezeti háttér:
Jan Carlzon: Northcote C. Parkinson: Relációs adatbáziskezelés: E. F. Codd: OLAP: 77 OLAP szoftver rövid leírása és a gyártó honlapja:

Adatbázis-tervezés konzultáció

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

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

Adatbázis-tervezés konzultáció

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés