Adatbziskezels 2 1 Elads Dr Pauler Gbor egyetemi
Adatbáziskezelés 2 1. Előadás Dr. Pauler Gábor, egyetemi docens PTE-TTK BRTT, 7624 Pécs, Ifjúság u. 6. F 104 Mobil: 30/9015 -488, Skype: gjpauler E-mail: pauler@t-online. hu Facebook: Pécs Gazdinfo Adatbázis http: //www. facebook. com/groups/278606362188127/ ftp: //gamma. ttk. pte. hu/pub/pauler/Database 2/
Az előadás tartalma A vállalati adatkezelő rendszerek Szervezeti előfeltételek Business Process Reengineering (BPR) Üzleti folyamat diagramm (BPD) Hibák és megoldásuk BPD-n BPR végeredménye Papír-alapú adatkezelés hátrányai Adatfolyam diagramm Táblázatkezelők Ellenpélda Mikor használjuk? Elrettentő esettanulmány Szakirodalom
Vállalati adatkezelő rendszerek: Szervezeti előfeltételek 1 A világ legnagyszerűbb adatkezelő rendszerének a bevezetése is biztos bukás lesz, ha a vállalati szervezet diszfunkcionális. Ezért foglalkozunk először ennek problémáival: Bármely 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 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)
Vállalati adatkezelő rendszerek: Szervezeti előfeltételek 2 Félisten Sajnos a magyar szervezeti-döntési kultúra erősen ellene hat Főisten ezen elveknek: Az ország 1000 éves feudalisztikus hagyományai miatt a Alisten magyar döntéshozók túl nagy szerepet tulajdonítanak a szervezeti hierarchia kialakításának (ki hajbókol kinek), egyszerű feladatokra is túl sok szintű, túl bürokratikus hierarchiát hoznak létre. Itt Parkinson törvénye (Parkinson’s Law) é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 frissen végzett Droid Pistik (Steve Droid), Szőke Nusik (Blondie Nusi), meg az 55 év körüli, melírozott hajú vén csatalovak (Old Spunk) (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, nyelik a nyugtatót, válnak, é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: Kávéfőz Feljelenti Nusi 7 Pletykál Nusi 6 Pasziánszozik Átírja Nusi 5 Aláírja Ellenőrzi Protekciós? Aláírta? Nusi 4 Nusi 3 Fénymásol Legépeli Fúrja Lepecsételi Lebabázik Nusi 2 Nusi 1 Ügyfelezik. Kenőpéz? Kinyomtatja
Vállalati adatkezelő rendszerek: BPR: Üzleti folyamat diagramm A BPR legfontosabb eszköze az üzleti folyamat diagramm (Business Process Diagram BPD): célja hogy leírja egy folyamat algoritmusát, intutját, outputját erőforrás- és időfogyasztását. Lényegében egy 2 dimenziós koordináta rendszerbe rendezett folyamatábra (az Advanced Database Diagram (ADD) szabvány szerinti jelölésekkel ismertetjük): Idő (Time): ez nem folytonos fizikai idő, hanem egyedileg elnevezett logikai töréspontok/mérföldkövek (Breakpoint/Milestone) által tagolt koordánata tengely: Szerepek (Roles): diszkrét beosztású koordináta tengely, a szervezet egyedileg elnevezett munkavégző egységeit mutatja (nem embereket, hanem pozíciókat, mert egy embert kirúghatnak!) vagy olyan üzleti partnereket, akik tevékenységeket végeznek A tevékenységeket (Activity) a folyamatábra blokkjai (Block) ábrázolják, melyek hossza arányos az időfogyasztásukkal, más erőforrás igényeiket (pl. munkaerő, gép) szövegesen lehet leírni. Lehetnek: Blokkpárok (Pairs of Blocks), amik folyamatvezérlő-elemeket írnak le. Korlátlan szinten egymásba lehet ágyazni őket, a beágyazott részek beljebb tabulálandók: Proc: A End. Proc: A Eljárás fejléc /lábléc paraméter listával és azok típus-ikonjaival. A Félkövérek (Boldface) hivatkozás-, a többiek érték szerint átadottak End. FOR: A Ciklus feltétel /lábléc ciklusváltozóval IF: B /Else ág /lábléc feltétellel Else. IF: B: End. IF: B Feltétel fejléc Az Egyedi blokkok (Single Bolcks) jelenthetnek: Step: Decl: Sql: Lokális változó-deklarációt típus-ikonokkal, Lépést , SQL-t Négyféle nyíl (Arrow) kapcsolhatja össze a blokkokat: Feltétel igaz ága ( ), Feltétel hamis ága ( )(ezt mindig a blokkok elé rajzoljuk, hogy kiadja a hierachikus beágyazódásukat, a többit mögéjük), Előrelépés ( ), Visszacsatolás (Feedback) ( ), csak ez léphet vissza időben (logikai értelemben) Vásárló-azonosítás l Új vevő Issu Sql: Lekéri Vevőket IF: Új vevő? Step: Rögzít Vevői adatokat End. IF: Új vevő? Step: Száml kibocs nd. Proc: Számláz Vevő Tota Sql: Lekér egységár Step: Beír Mennyis IF: Ár OK? Step: Tétel tárol Else. IF: Ár? Proc: Vissza Bar. Code Quantity Invoice. ID End. IF: Ár? Else. IF: Vonalkód? Proc: Ell. Vonalkódot End. IF: Vonalkód? nd. FOR: Tétel Step: Össz Totálokat Decl: Temp. Name Temp. Adress Step: Vevői adat lekérdez Eladó roc: Számláz Customer. ID Invoice. ID FOR EACH Tétel Step: Tétel oda Step: Tétel lehúz IF: Vonalkód OK? Számlá z. Kezdés. Tétel-feldolgozás Zár e
Vállalati adatkezelő rendszerek: BPR: Hibák és megoldásuk BPD-n 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. Feloldása: meg kell cserélni a műveletek sorrendjét: Idő: Kezdés +1óra +2óra …a Tűréshat MűUtasítás: végtelenségig ár vezet Megfelel? csináld kitalálás ő újra Mun- Megmunkál a kás ás Idő: Kezdés +1óra +2óra Mű- Tűréshat ár vezet ár kitalálás ő közlése Megmunkál Muna ás kás Felső vezet. Közé p-vez. 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úlyozatlansá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 +1 hét +2 hét …a Idő: Kezdés +1óra +2óra … hétvége … hóvége Okt at meg Okt -bíz Háat zas. Kér meg élet e-bíz Vad lem Kiszo áElin l-gál szat Ivátézv szat e polit i-kusokkal Telje -sítmén y OK? Kérele m Bea d. Hávány Foly zasa- élet mod Vad ávány szat Ivászat polit i-kusokkal Szerető -höz Dön -tés Utas Kup í-tás Kiszolg leráj Elintézv ál -ba e végtelenségig Alkal -maz. Ügyfél
Vállalati adatkezelő rendszerek: BPR: Hibák és megoldásuk BPD-n 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: Kiszolg ál Utas í-tás Jóvá hagy ? +15. nap Meg -oldás Utas Kérele í-tás m Bea dvány Elintézv e Jóvá hagy ? Csa -pat épít. +1 hét +2 hét +16. nap Meg -oldás Kezdés Csa -pat épít. $ Idő: Projekt Dön -tés Kérele m Bea dvány Foly amod vány Dön -tés Utas Átira í-tás t Bea dvány Foly amod vány Dön -tés Utas í-tás Kiszolg Elintézv ál e …a Gyártá Marke Gyártá Marke s. Fels Gyártá t t ő- s. Köz s. Alka Felső- Közép t Alkal Ügyfél vezet. ép-vez. l-maz. vezet. -vez. -maz. Kezdés +1 hét +2 hét végtelenségig Projekt Dön -tés Idő:
Vállalati adatkezelő rendszerek: BPR: Végeredmény Az alábbi példában egy gyógyszerkutató labor kutatási folyamatának BP diagrammja látható. 2006 -ban 1 naptári hónap alatt készült el, 3 db szakértő összesen 104 munkaórányi teljesítményével, 5000 Ft/h mérsékelt szakértői díj mellett 520 EFt ö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ásmegosztá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ő rendszervező 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 előadás tartalma A vállalati adatkezelő rendszerek Szervezeti előfeltételek Business Process Reengineering (BPR) Üzleti folyamat diagramm (BPD) Hibák és megoldásuk BPD-n BPR végeredménye Papír-alapú adatkezelés hátrányai Adatfolyam diagramm Táblázatkezelők Ellenpélda Mikor használjuk? Elrettentő esettanulmány Szakirodalom
J J L L L Vállalati adatkezelő rendszerek: A papír alapú rendszer hibái A szervezet rendberakása csak a szükséges, de nem elégséges feltétele a hatékony céges adatkezelésnek: 1 -1. PÉLDA: Magyar-Szőnyeg Kft. A további problémákat egy szőnyegeket és parkettákat eladó kisvállalkozás számlázási rendszerén mutatjuk be: Eddig papír alapú adatkezelést használtak, ennek előnyei: Könnyű használni: 6 évesen mindenki tud írni, 16 évesen akár ÁFA-s számlát kitölteni is Rugalmasság: ha valamely adat kimaradt, egyszerűen odaírják a számla margójára Azonban, a papíralapú számlázásnak hátrányai is vannak: Nagyon lassú, drága, sokat hibázó szoftver: manuális munka Az adattárolás fizikai anyagmozgatást igényel, nagyon drága és időrabló egy másik aktát visszakeresni, ezért a papír alapú űrlaptervezés alapelve: „rakjuk össze minden fontos dolog adatát (vevő, áru, stb. ) egy űrlapba, még ha nem is fér ki minden” Ez helypazarláshoz (Redundancy in Space Consumption) vezet: 1 számla max. 12 tételt tud tárolni, de a legtöbbön csak 1 -2 tétel van kihasználva, 11 -12 elpazarlódik Valamint adatvesztés(Data Loss) jöhet létre: ha a vevő 13 tételt vett, az utolsót nem lehet letárolni, vagy Egy új számlát kell megnyitni, ami munkaerő pazarlás (Redundancy in Workload): az összes vevői és eladói adatot újra be kell írni plusz 1 tétel kedvéért, Vagy, ha nem töltik ki csak, hozzákapcsozzák az eredeti számlához, az kétértelmű hivatkozásokhoz (Ambigous Reference) vezethet ha az eredeti számla elveszik Mindezek miatt a számlázást hatékonyan megoldani csak elektronikus rendszerrel lehet
Vállalati adatkezelő rendszerek: Adatfolyam diagram Vásárló-azonosítás l Új vevő Issu Sql: Lekéri Vevőket IF: Új vevő? Step: Rögzít Vevői adatokat End. IF: Új vevő? Step: Száml kibocs End. Proc: Számláz Vevő Tota Sql: Lekér egységár Step: Beír Mennyis IF: Ár OK? Step: Tétel tárol Else. IF: Ár? Proc: Vissza Bar. Code Quantity Invoice. ID End. IF: Ár? Else. IF: Vonalkód? Proc: Ell. Vonalkódot End. IF: Vonalkód? End. FOR: Tétel Step: Össz Totálokat Decl: Temp. Name Temp. Adress Step: Vevői adat lekérdez Eladó Proc: Számláz Customer. ID Invoice. ID FOR EACH Tétel Step: Tétel oda Step: Tétel lehúz IF: Vonalkód OK? Számlá z. Kezdés. Tétel-feldolgozás Zár e Ezért bármely elektronikus adatkezelő rendszer tervezéséhez szükség van Temp. Vevő egy rendszertervezési módszerre. Az EU-ban: VevőNév CRUD Erre a Structured System Analysis and Design Method (SSADM), VevőCím CRUD A tervek megjelenítésére a Uniform Markup Language (UML), Tétel A rendszerfejlesztési projekt levezetésére a (PRINCE) ajánlott Tétel. Leír R Ezek precíz véghezviteléhez igen jelentős mennyiségű pénzre és időre van Mért. Egys R szükség, ezért a legtöbb esetben egyszerűen kihagyják őket, vállalva a Vonal. Kód CR rendszer működésképtelenségéből eredő, már említett károkat ITJKód R Bármilyen primitív és hiányos rendszerterv is készül, nem nagyon hagyható Menny CRUD EgysÁr R ki belőle az a lépés, amikor az üzleti folyamat adott tevékenységeihez ÁFA% R megpróbálják összegyűjteni az elvégzésükhöz szükséges adatok körét BruttóÉrték= Ennek eszköze az adatfolyam diagram (Data Flow Diagram, DFD), ahol a (EgysÁr* BPD tevékenységeihez gyakorlati adatstruktúrákat (Empirical Data Menny*(+ Structure, EDS) kapcsolunk. ADD-ben a következő adataik vannak: ÁFA%/100)) Adatmező neve (Egyedi 1 EDS-en belül, de több közt ismétlődhet) Emp. Data. Struct Számla Mezőtípus-ikonok Szöv CRUDA EladóNév R Az opcionálisan kitöltendő mezők dőlt betűvel (Italics) Egész CRUDA EladóCím R A rendszer által automatikusan kitöltöttek félkövérek Tört CRUD EladóAdóSzám R (Bold) (Ezek lehetnek számítási képletek is) Bináris CRUDA VevőNév CRU Az adatmezők műveleti jogosultságai (Rights) Dátum CRUDA VevőCím CRU a műveletvégző részéről: Idő CRUDA Számla. Szám R Kép CRUDA ÉrtékesítőNév CR Create: létrehoz Hang CRUDA ÖsszÉrték= Read/retrieve: olvas Mozi CRUDA Sum(Tétel. BruttóÉrt Update: módosít Fizetve CRUD Delete: töröl Dátum Archive: archivál Idő
Az előadás tartalma A vállalati adatkezelő rendszerek Szervezeti előfeltételek Business Process Reengineering (BPR) Üzleti folyamat diagramm (BPD) Hibák és megoldásuk BPD-n BPR végeredménye Papír-alapú adatkezelés hátrányai Adatfolyam diagramm Táblázatkezelők Ellenpélda Mikor használjuk? Elrettentő esettanulmány Szakirodalom
Vállalati adatkezelő rendszerek: Táblázatkezelők: Ellenpélda A papír-alapú adatkezelés fő problémáit nem A B C D E F oldja meg automatikusan, ha elektronikus Számlaszá Készpénzfizetési számla CZ 184788 1 m: adatkezelést alkalmazunk. A rosszul Számlakibo kiválasztott és megtervezett elektronikus Magyar-Szőnyeg - csátó Vevő neve: Pauler Gábor Kft. adatkezelő eszköz csak növeli a 2 neve: 7300 Komló, problémákat! Címe: 7636 Pécs kisréti u. 2. 3 Pécsi u. 57 Pl. egy kisvállalkozás számlázási Adóigazgat rendszerére a lehető legrosszabb ási Számla 12649499 -2 -02 29 -Mar-04 megoldás, ha valaki nem ismeri fel, hogy azonosító kelte: ehhez adatbázis-kezelő kell, és úgy ahogy 4 száma: Áfapapíron van, változatlan struktúrával 1 Eredeti példány 25% 5 tartalom átteszi az egészet Excelbe: Termék Megnevezé Értéke, M. e. : Mennyiség. Egységár Minden munkalap közepén program- 6 száma se áfával: PVC ciklussal keresgélheti össze a téte 7 231281672 szegély f. m. 60 190 11, 400 leket, ami sok progizás, és lassú lesz 8 Eközben vidáman pazarolja a helyet 9 az üres Excel cellákkal, amelyek 10 11 helyet foglalnak 12 Mihelyt valami megváltozik, (pl. 13 eladóra, termékre bontott összesítés 14 kell) keservesen újraprogramozhatja 15 16 az egészet! CZ 184788 CZ 184789 CZ 184790 CZ 184791 17 100 számlára jól működik, 500 18 Tanulság: Mielőtt mindenféle számlánál már belassul, 1000 -nél 19 A számla fizetendő végösszege: 11, 400 tervezés – és ész – nélkül nekiállunk recseg-ropog, efelett meg összeomlik, 20 Az áthárított adó százalékértéke: 20% Excelben taknyolni, vagy kézzel lefagy. . . Emiatt ugyanúgy kell papíron bármiben programozni, gondoljuk át is vinni az ügyeket, megduplázva a a következőket: munkaerő felhasználást és a költségeket Egy nagy cégnél több millió számla keletkezik évente!
Vállalati adatkezelő rendszerek: Táblázatkezelők: Mikor használjuk? 1 1. Adattömeg (Data Mass): A fejlesztendő alkalmazás ne tartalmazzon nagy tömegű, tranzakció jellegű adatot, amelyek mérete lineárisan nő a szervezet működésével: ilyenkor még nagyon pici szervezeteknél is kőkeményen belép a táblázatkezelő jellegéből fakadó óriási erőforrás igény. DE: 1. 2007 -es Office-tól Excel munkalap 65535× 255 helyett 1024000× 1024 cellát képes kezelni, mikrovállalati alkalmazásnak elég lehet. 2. Excel képes külső adatforrásból 9 -10 M rekordos adatbázis táblát Kimutatás táblával (Pivot Table) aggregálni, diagrammolni 2. Relációk (Relations): A fejlesztendő alkalmazás ne tartalmazzon bonyolult logikai összekapcsolódású adatokat, amelyek egységei nem tárolhatók fix hosszúságú helyen, ezért normalizálva sok táblára kellene bontani, hivatkozásokkal összekötve. DE: 2017 -es Office-tól bevezették az Excel addigi primitív kis MS Jet adatbázis motorja helyett a Power. Queryt: Sok táblából és köztük lévő hivatkozásokból álló adatmodell kezelése Táblák akár cellaműveletekkel munkalapként, akár SQL műveletekkel adatbázis táblaként is kezelhetőek, szabadon váltogatva melyik jobb Programozás nélküli, kattintgatós-varázslós GUI 3. Önálló alkalmazás (Standalone Application): Excel egy adatbáziskezelőhöz képest korlátozottan támogatja a hálózati osztott adatelérést (csak olvasásra). DE: 2017 -es Officetól bevezették a megosztott mappából szimultán módosításra elérést, cellánkénti többfelhasználós módosítási történetek kezelésével, Viszont továbbra sem képes kezelni elágazó verziózást, ha konfliktusba kerül 2 felhasználó által ugyanarra beírt dolog.
Vállalati adatkezelő rendszerek: Táblázatkezelők: Mikor használjuk? 2 4. Intenzív statisztikai elemzés/optimalizáció-igény (Statistical Analysis /Optimization Requirement): Az Excel (VBA Analysis Toolpack grafikus felületű Add-In-el) előnyben van, ha statisztikai/optimalizációs elemzések sorozatát igényli egy adatbányászati alkalmazás (pl. Lineáris regresszió, ANOVA, korrelácószámítás, faktoranalízis, gradiens algoritmus, simplex algoritmus, korlátozás-szétválasztás). Adatbáziskezelőkhöz ezek igen drága adatbányászati csomagokban elérhetőek csak (Pl. Oracle + Express Objects vagy Rapid Miner), vagy ingyenes R-ben de annak nincs saját grafikus felülete. 5. Hibakeresési és tesztelési költség (Debug/Testing Cost): Mivel az Excelben cellafüggvényekkel lépésenként építjük az algoritmust, azonnal látszik, ha valami nem úgy működik, ahogy kell, így a tesztelés és debug idő- és a programozó absztrakciós képességei iránti szükséglete nagyságrendekkel kisebb, mint 4 GL nyelvek esetén 6. Határidő (Deadline): A fentiek miatt, az Excelben lehet a leggyorsabban kifejleszteni és tesztelni egy algoritmus, ráadásul a felhasználói felület programozása is gyorsabb, mint 4 GL nyelvekben, mert rendelkezésre áll a munkalap teljes funkcionalitása, amellett, hogy használhatunk 4 GL nyelvekre jellemző űrlap (Form) alapú felhasználói felületet is.
Vállalati adatkezelő rendszerek: Táblázatkezelők: Mikor használjuk? 3 7. Szoftver költség (Software Cost): Mivel az Excel az MS Office csomag része, lényegében ingyen áll rendelkezésre, mind a fejlesztő, mind a felhasználó számára 8. Betanítási költség (Tutorial Cost): Alap-alap felhasználói szinten az Excel ismerete eléggé elterjedt, ezért az Excelben készített alkalmazás előnye, hogy a felhasználónak nem egy vadonatúj felhasználói felületet kell megtanulnia, csak az alkalmazás-specifikus munkafüzet részek használatát 9. Munkaasztal (Desktop): Ha a felhasználó azt igényli, hogy az alkalmazás számított eredményeiből könnyen és gyorsan tovább tudjon számolni/ diagrammolni, az Excel-alapú felhasználói felület határozott előnyt élvez a programnyelvek által előállított űrlapokhoz (Form) képest, ha csak az alkalmazás által használt munkalapokat/cellákat zárjuk le: bármit hozzáépíthet és nem kell még külön adatexport felületet (pl. XML-ben) programoznunk hozzá.
Vállalati adatkezelő rendszerek: Táblázatkezelők: Elrettentő esettanulmány 2006 -ban egy Pécsen működő, finn székhelyű elektronikai alkatrészgyártó informatikusai azzal kerestek meg „hogy lehetne 65535 sornál többet kezelni ebbe’ a szaros Excelbe” A cég egy Baan nevű vállalatirányítási rendszert (http: //www. ssaglobal. com/solutions/erp/ln. aspx ) vezetett be, de ennek nagy költségein a felsővezetés takarékoskodni akart, és csak a könyvelés és pénzügy modulokat vezették be, a logisztikát nem, erre az volt a terv, hogy „majd a pécsi fiúk leprogizzák” Ez persze több 1000 ember×év fejlesztői munka lett volna, ezért létfontossági logisztikai adatokat Excelben kezeltek: pl. a darabjegyzék Száll. Cikk. Szótár Cikk SzállítóCikk (Bill Of Material, BOM), ami azt szabályozza, Száll. Cikk. Szót. ID Cikk. ID Száll. Cikk. ID hogy melyik késztermékbe hány és milyen Leírás Dec. Sor. Szám komponens épül be milyen verzióban mikortól Saját. Per. Száll Leírás meddig, egyetlen munkalapon volt Érv. Kezd. Dátum Holott ez testvérek közt szerényen is min 5 Vég. Dátum Érv. Vég. Dátum Száll. Cikk. ID Mérték. Egys. ID táblás adatbázissal kezelhető, de még arra sem Mérték. Egys. ID Saját. Cikk. ID FőCikk. ID jött rá senki, hogy adatbázis kell: makrókkal Kötelező-e Módosító akartak összefűzni több munkalapot. . . Módosító Módosítva Amikor az ólmozott-ólommentes forraszanyagú Módosítva Állapot alkatrész váltás miatt a komponensek száma Állapot megduplázódott, az Exceles nyilvántartás totálisan összeomlott: nem oda szállítottak, nem Komponens azt és nem annyit, amit rendeltek, emiatt havi 2 Komp. ID Tulajdonság Al. Per. FőCikk Tuld. ID 2. 5 MFt-ot vesztettek kötbérben Kezd. Dátum Név Mi 4 hónap alatt 9. 2 MFt-ért rendbe raktuk volna, Vég. Dátum AktuálisÉrték de ezt túl drágának találták, úgy maradt. . . FőCikk. ID Adattípus A cég a felsővezetés szűklátókörűsége miatt Al. Cikk. ID Mérték. Egys. ID 2006 -ban negatív üzemi eredményt ért el egy Kötelező-e Cikk. ID akkor évi 10 -12%-kal dinamikusan bővülő Módosító Módosítva piacon, a 2008 -as válságban elvesztette fő Állapot vevőjét és 2011 -ben csődbe ment. Ámen
Szakirodalom Szervezeti háttér: Jan Carlzon: www. andrewgibbons. co. uk/documents/Moments. doc Northcote C. Parkinson: http: //en. wikipedia. org/wiki/Parkinson's_law BPR: http: //www. businessballs. com/business-process-modelling. htm http: //www. altova. com/umodel/business-process-modeling. html http: //www. teamtechnology. co. uk/business-process-reengineering. html Üzleti folyamat diagram: http: //www. omg. org/bpmn/Documents/6 AD 5 D 16960. BPMN_and_BPM. pdf Adatfolyam diagram: www. inf. u-szeged. hu/oktatas/Tempus/folyamat. doc MS Visioban: http: //office. microsoft. com/hu-hu/visio-help/adatfolyamdiagram-letrehozasa-HP 010357132. aspx Smart. Draw-ban: http: //www. smartdraw. com/resources/tutorials/dataflow-diagrams/ http: //www. thekjs. essex. sch. uk/yates/data_flow_diagram_(dfd). htm Táblázatkezelők: Exceles kezdőlap: http: //excel. lap. hu/ Internetes Excel alaptananyag: http: //excel. freebase. hu/ Trükktár üzleti elemzőknek, kontrollereknek: http: //www. managementkiado. hu/termekek/index. php? id=0034412 Általános Excel trükkök: http: //msexcel. fw. hu/ Makróírás: http: //makromester. uw. hu/ Excel trükkoldal: http: //www. andrewsexceltips. com/ Excel trükkoldal: http: //www. andypope. info/ Exceles blog: http: //www. dicks-blog. com/
- Slides: 18