Adatbziskezels 2 2 Elads Dr Pauler Gbor egyetemi

Adatbáziskezelés 2 2. 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 Miért kell bele adatmodell? Objektum-hierarchia alapú adatmodell Relációs adatmodell No. SQL adatmodell Gráf adatmodell SAP HANA adatmodell Táblázatkezelők, OOP, Relációs, No. SQL, Gráf, HANA adatmodellek előnyeinek-hátrányainak összehasonlítása Relációs adatbáziskezelők Normalizációs folyamat 1. Normálforma: Dekompozíció Egyedek fogalma Azonosítónevek kiválasztása Relációs elemzés Számosság Függés Egyed-tulajdonság szabály Egyed-dekompozíciós szabály Tipikus kezdő hibák Szakirodalom

Vállalati adatkezelő rendszerek: Miért kell bele adatmodell? 1 Az adatbázis/memória tábla (Database/Internal Table): fix Struct t. Invoice struktúrájú, és hosszúságú, 1. . n sorszámozott rekordokat Invoice. Num As String (Record) tárol egymásután merevlemezen/memóriában: Seller. Name As String Seller. Address As String A rekordok egyed (Enity) előfordulásaihoz As String (Occournce) tartozó tulajdonságokat (Property) írják Seller. Tax. Reg Buyer. Name As String le a következő adatokkal: Buyer. Address As String Mezőnév (Field name) Invoice. Date As Date Mezőtípus (Field Type): String, Date, Integer, stb. Item 1 Name As String a Byte-ban mért helyfoglalással Item 1 Meas. Unit As String Item 1 Quantity As Double Min/Max/Alap érték (Min/Max/Default value) Item 1 Unit. Price As Single Kötelező/Opcionális kitöltés (Required/Optional) Az adatbázis/memória tábla nagy tömegű rekord gyors Item 1 Tax. Perc As Single Item 1 Gross. Val As Double elérését teszi lehetővé, mert a rekordok kezdőpozíciója As String előre kiszámítható az Index×Rekord. Hossz szorzataként. Item 2 Name Item 2 Meas. Unit As String De 1 tábla nem tudja megoldani azokat a probléItem 2 Quantity As Double mákat, amelyek a gyakorlati adatstruktúrák nem fix Item 2 Unit. Price As Single hosszából erednek, mert ez egy fix struktúrájú tároló: Item 2 Tax. Perc As Single 2 -1. PÉLDA: Tegyük fel, hogy Droid Pisti, az „eccerű” Item 2 Gross. Val As Double programozó úgy akarja megoldani a szőnyeg szám… Total. Val As Double lázási rendszert, úgy, hogy a papír alapú számla End Struct struktúráját 12 lehetséges tétel adataival egy az egyben egy adatbázis/vagy memória táblába teszi: Ha csak 1 tételünk van, 11 db helyét elpazaroljuk Ha jönne a 13. tétel a számlához, adatot vesztünk Ha nem akarunk adatot veszteni, új számlarekordot kell nyitni a 13. tételnek ugyanazon vevő adatok ismételt bevitelével, ami idő- és munkaerő pazarlás

Vállalati adatkezelő rendszerek: Miért kell bele adatmodell? 2 Vagyis 1 táblás rendszer nem fix hosszúságú valós adat-szerkezet tárolása esetén egyszerre veszt adatot és pazarolja a helyet! 2 -2. PÉLDA: Az anyák adatait egy táblában akarjuk tárolni a gyerekeikével, de egy anyának igen eltérő számú gyereke lehet, ezért hasraütésre 8 gyerek adatainak csinálunk mezőket: Ügyfél. Név Szül. Idő Gyerek 1 Név. Gyerek 1 Szül. Idő Gyerek 8 Név Gyerek 8 Szül. Idő Kovács Jánosné 1958. 10. 23 Kovács István 1987. 01. 04 Nagy Józsefné 1968. 03. 12 Kövesi Dzsenifer 1987. 11. 04 O. Brian 2000. 09. 11 O. Leona 2007. 01. 16 Kövesi Ámor 2008. 02. 01 Kiss Károlyné 1972. 11. 02 Kiss Ili 2002. 10. 20 Kiss Vili 2004. 07. 08 Nagy Emília 1976. 10. 05 Kovács Jánosné, magyar átlaganya: átlag 0. 4 db gyereke van, a gazdasági helyzet miatt 7. 6 hely elpazarlódik (█ jelöli ezt) Kövesi Dzsenifer: 8 -12 db gyereke van a kis Kövesi Ámort már nem tudja a rendszer tárolni, adatot vesztünk, éhen hal. Adatmódosítási nehézségek: Ezenkívül, a merevlemez és memória sajnos nem gumiból készült, ami igen zavaró, ha számítana a rekordok adott fizikai sorrendjének megtartása adatváltozások közben: Nem lehet két rekord közé fizikailag 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. A gyakorlati adatstruktúrák tele vannak a mezők közti 1: több ( ) vagy több: több ( ) beágyazott kapcsolatokkal (Nested relationships): 1 vevőnek több címe lehet (időben) és több vevő lakhat 1 címen Plusz még beágyazva tartalmazhatják egymást (Nested sub-entity): 1 számlához több tétel tartozik, de annak is sok tulajdonsága van Emiatt nem lehet őket fix strukturális hosszú szerkezetben tárolni! Számla EladóNév R EladóCím R EladóAdóSzám R VevőNév CRU VevőCím CRU Számla. Szám R ÉrtékesítőNév CRU ÖsszÉrték= Sum(Tétel. BruttóÉrté Fizetve CRUD Dátum Idő Tétel. Leír R Mért. Egys R Vonal. Kód CR ITJKód R Mennyis CRUD EgységÁr R ÁFA% R BruttóÉrték= (EgységÁr* Mennyis*(+ ÁFA%/100))

Vállalati adatkezelő rendszerek: Adatbázis, Objektum-hierarchia adatmodell 1 Adatbázis (Database, DB): olyan integrált adatszerkezet, mely egy adatmodell (Data Model) szerint konzisztens módon tárolja: Több különböző objektum előfordulásainak adatait Az objektumok szerkezetét leíró meta-adatokat (Meta-Data) Az adatok feldolgozásához szükséges metódusokat, oly módon, hogy: Képes legyen a gyakorlatban megfigyelhető nem fix hosszúságú adatstruktúrákat (Non-fixed Lenght Physical Data Structure) (pl. 1 anyához több gyerek) adatvesztés (Data Loss) és hely-/processzoridő pazarlás (Redundancy) mentesen tárolni Egyértelmű hivatkozásokat (Disambigous References) tartalmazzon (pl. ne keverje az azonos címen alkó azonos nevű apát a fiával) Az adatbázisokat adatbáziskezelőn (Database Management System, DBMS) keresztül lehet hozzáférni. Az adatbázisok többfajta adatmodellen alapulhatnak: Objektum-hierarchia alapú (Object-Hierachy Based Database Management, OBDM): Ez azon alapul, hogy a 4. generációs programnyelvekben (4 th Generation Languages, 4 GL) (pl. C#, Java, Visual Basic, Delphi) megjelenik az objektum-orientált programozás (Object Oriented Programming, OOP), ahol egy objektum (Object) kollekció (Collection) elemei beágyazva (Nesting) tartalmazhatják egyszerűbb objektumok kollekcióját, és azok elemei is beágyazva tartalmazhatnak kollekciókat, stb. Így lehetségessé válik a gyakorlati adatstruktúrák 1: több kapcsolatainak közvetlen tárolása

Vállalati adatkezelő rendszerek: Objektum-hierarchia alapú adatmodell 2 Class Buyer Inherits Address ‘Data fields First. Name As String Lastname As String Cell. Phone As String E-mail As String ‘Embedded classes f. Address As Address End Class ‘Global list Dim Buyers As New _ List Of (Buyer)() Class Sales. Pers Inherits Address ‘Data fields First. Name As String Lastname As String Cell. Phone As String E-mail As String ‘Embedded classes f. Address As Address End Class ‘Global list Dim Sales. Persons As New _ List Of (Sales. Pers)() Class Street. Type ‘Data fields Type. Name As String End Class ‘Global list Dim Street. Types As New _ List Of (Street. Type)() Class Country Példaként a szőnyeg szám- ‘Data fields Cnt. Name As String lázó rendszert mutatjuk be End Class Visual Basic OOP nyelven: ‘Global list A gyakorlati adatstruktúrá- Dim Countries As New _ ból olyan adatstruktúrákat List Of (County)() Zip szedünk szét külön objek- Class Inherits Country tum osztály definíciókba, ‘Data fields As String amelyek fix számú mező- City ‘Embedded classes ben tárolhatók (pl. Vevőf. Country As Country Buyer, Eladó-Seller, stb. )End Class list Ha A osztály 1 példányá- ‘Global Dim Zips As New _ hoz B osztály több példá- List Of (Zip)() nya tartozhat, A megörökli Class Address B osztályt az Inherits Street. Type, Zip ‘Data fields kulcsszónál (az örökléseket Door As String jelöli), és B megjelenik Door As String A-ban beágyazott (embed- Floor As String House. Num As String ded) struktúraként Line. Phone As String Minden osztályt egy külön Fax As String List kollekcióban példá- ‘Embedded classes f. Street. Type As Street. Type nyosítunk, ami lehetővé f. Zip As Zip teszi új példányok hozzá- End Class list adását (. Add metódussal) ‘Global Dim Addresses As New _ törlését (. Remove metóList Of (Address)() dus), egyedi példánynév Class Legal. Format (. Name tulajdonság) vagy ‘Data fields Format. Name As String sorszám szerinti elérését End Class (Az OOP alapfogalmakról ‘Global list bővebben ld. : OOPAlapok) Dim Legal. Formats As New _ List Of (Legal. Format)() Class Seller Inherits Address, Legal. Format ‘Data fields First. Name As String Lastname As String Cell. Phone As String E-mail As String ‘Embedded classes f. Address As Address f. Legal. Format As Legal. Format End Class ‘Global list Dim Sellers As New _ List Of (Seller)()

Vállalati adatkezelő rendszerek: OOP adatmodell: Értékelése Az OOP adatmodell használata főleg (First person Shooter, FPS) játékokban, ipari folyamatvezérlésnél, haditechnikában lett népszerű, ahol a lekérdezés sebessége a legkritikusabb tényező (pl. rakétavezérlő rendszerek): Ha előre tudok definiálni egy lehetséges lekérdezési útvonalat, mert a „játék szabályai” megadják (pl. World Of Tanks: Hány tankom van a pályán? ), és e mentén állítom fel az objektum osztály hierarchiát, akkor az OOP modell utolérhetetlenül gyors, amíg a teljes objektum osztály hierarchia összes előfordulása befér a RAM-ba Ha az adatok akkorák, hogy nem férnek be egyben a fizikai RAM-ba, akkor az oprendszer memória swappelésére kell hagyatkoznunk, ami pl. Unix Solarisban nagyon jó, de bizonyos W-vel kedződő oprendszereknél egy rakás sz*r. Ilyenkor már kerülhet előnybe OOP-vel szemben relációs adatmodell, mert a korszerű relációs adatbáziskezelőkben (nem MS Access…) saját fejlett swappelés van. Ha nem tudok definiálni előre lehetséges lekérdezési útvonalat, hanem bármit le kell tudni kérdezni bármiből ad-hoc (pl. Mennyi a tankjaimban lévő átlagos üzemanyag-készlet? ), az OOP modell teljesítménye drámaian leeshet. Sajnos az üzleti életben nemigen vannak előre definiált „játékszabályok”, a fontos lekérdezések nagy része ad-hoc, ezért az OOP modell üzleti alkalmazásokban csak igen korlátozottan használható, és abszolút piaci előnye van a relációs modellnek, ami ugyan fajlagosan lassabb, de ad-hoc lekérdezéseknél (bármiből bármit) kiegyensúlyozottabb teljesítményt nyújt. Erre rátesz még egy lapáttal, hogy az OOP modell igen nehezen boldogul a többszörös több: több kapcsolatok modellezésével, pl: 1 Vevő több fajta Terméket vehet és 1 fajta terméket több Vevő vehet, 1 fajta Terméket több Bolt árulhat és 1 Bolt több fajta Terméket árulhat, 1 Vevő több Boltban vásárolhat, és 1 Boltban vásárolhat több Vevő. Ez pedig a falusi kilós bugyi turkálótól a szupermarketig előfordul a valóságban.

Vállalati adatkezelő rendszerek: Relációs adatmodell: Alapfogalmak E. F. Codd 1971 -ben feltalálta a relációs adatbáziskezelést (Relational database Management, RDM) és a következő egyszerű ötletre alapozva Relational Data Inc. néven céget alapított, ami ma Oracle néven ismert. . . Addig tördeli szét Rész-táblákra, Egyedekre (Entity) a gyakorlati adatstruktúrát, amíg minden táblastruktúra fix hosszúságú lesz, így nagy sebességű, kapacitású adatbázis táblákban (Database table) jól tárolható: Pl. az 1 táblás számlázási rendszernél gond volt, hogy 1 számlához csak fix számú tételt tudott tárolni, holott bármennyi lehet: Ezért bontsuk ki a tétel-adatokat egy külön táblába, ezáltal: Tételek Számlák Tétel. I Menny Összé Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ D Vonal. Kód is rt D D ám um e rt 1 -523551 CZ 184788 2004. 03. 29 Igen 22800 1 14299 -9 60 11400 1 2 CZ 184789 2004. 01 Igen 33200 1 -523552 13233 -7 50 hosszúságú struktúrákat is tárolni tudjuk a táblákat 11400 1 Az eredeti nem fix 1 -52355összekötő relációk (Relation) révén: a tábla rekordjait egyedileg azonosító 3 13233 -7 65 16600 2 elsődleges kulcs (Primary Key, PK) mezőre más táblából érték-egyezés 2 -134224 07813 -4 55 16600 kulcs (Foreign Key, FK) mező. Miért? Például: 2 sel ( ) hivatkozó idegen Minden tételnél kötelezően meg kell adni, mely számlához tartozik Ez fix helyen tárolható, mert 1 Tétel csak 1 Számlához tartozik, viszont 1 Számlára így már korlátlan sok Tétel hivatkozhat, és a számla adatokat csak egyszer kell hozzájuk kitölteni! Így az RDM feloldja a gyors↔rugalmas adatkezelés közti régi dilemmát!

Vállalati adatkezelő rendszerek: Relációs adatmodell: Értékelése 1 Ez egy normalizációnak (Normalization) nevezett 5 lépéses tervezési folyamatban valósul meg, aminek lépései a normál formák (Normal Formats), és ennek eredményeképpen: Nagy tárolási kapacitású, gyors memória/ adatbázis táblákkal dolgozhatunk (mióta az SSD merevlemezek elterjedtek, és kiesett a fizikai lemez/fejmozgás időszükséglete, a sebesség különbsége már nem oly nagy, attól függően hogy RAM-ban vagy HDD-n van éppen az adott táblarész) Elkerüljük az adatvesztést: mindent le tud tárolni, akkor is, ha az adatok hossza nagyon változik Megszűntetjük a redundáns idő- és helypazarlást: egyszer rögzítünk csak egy konkrét adatot és egy helyen tároljuk, nem megtöbbszörözve Elkerüljük a mezők közti kétértelmű hivatkozásokat Viszont nem minimalizáljuk a lekérdezés sebességét: ez mindig ellene hat a helytakarékosságnak, a kettő általában nem javítható egyszerre De a lekérdezési sebesség növelésére további denormalizációs technikák (Denormalization) léteznek, ahol csekély plusz helyfoglalás árán nagy sebességnövekedést igyekszünk elérni A relációs adatbázis kezelő (Relational Database Management System, RDMS) az RDM-re alapozva kezeli a relációs adatbázis rendszert (Relational Database System, RDS), ami egy: adatbázis táblákból (Database Table), mezőik közti hivatkozási kapcsolatokból (Relation), SQL nyelvű lekérdezésekből (SQL Query), űrlapokból (Form) álló rendszer

Vállalati adatkezelő rendszerek: Relációs adatmodell: Értékelése 2 Eladok Jogi. Forma Eladó Vevő Elado. I Nev Haz. Sza Emel Laka Koz. Te. N Jogi. Forma Koz. Te. T Ir. Sza VevőID EladóID Forma. Név Kereszt. Név D m et s ev ip m Cég. Név Vezeték. Név Jogi. Forma 1 Magyar 57 Pécsi Út 7300 Vevok Ajtó EladóAdóSz Kft. Emelet Vevo. I Nev Haz. Sza Emel Laka Koz. Ter. N Koz. Ter. TAjtó Ir. Sza Épület Emelet D m et s ev Köz. Ter. Tip ip m Ház. Szám Épület 1 Pauler 2 2 9 Kisréti Köz. Ter. Tip Utca 7636 Köz. Ter. Név Ház. Szám Ertekesito Ir. Szamok ITJk Tipus. Név Köz. Ter. Név Gábor Köz. Ter. Tip Értékes. I Elado. I Ir. Sza Telep Afa. Sa Nev Ir. Szám Köz. Ter. Tip D D m ul ITJKod Nev Mobil Ir. Szám v. Telefon 1 Szalai 1 7300 Koml E-mail Ir. Szám Mobil 231816 Melegbu 2 S. ó Számla Ir. Szám AFAk Termekek E-mail Számla. ID 7636 Pécs Egys 12 Települ rk Afa. Sa Afa URL Számla. Szá Ország SELECT Vonal. Kod Nev Mert. Egys Ar ITJKod v % Szamlak. Szla. Szam, Tétel. Szám Szamlak. Datum, Értékesítő NetÖsszÉr 1 0. 12 175194586197 PVCFolyómét 190 Ország 231816 Szamlak. Veg. Osszeg, Szamlak ÉrtékesítőID BrtÖsszÉrt Szamlak. Fizetve, 2 0. 25 78 szegély er 12 Ország Kereszt. Név ÁFAÖssz Szamla. I Datum Veg. Ossze Fizetv Elado. I Vevo. I Szamlak. Elado. Kod, Orsz. Név Vezeték. Név Fizetve D g e D D Szamlak. Vevo. Kod, Eladok. Nev, Ajtó Kibocs. Dátu Eladok. Ado. Szam, CZ 1847 11, 400 Yes 1 1 Emelet Kibocs. Idő Tetelek 03/29/0 Ertekesitok. Nev, 88 4 Épület Cimek. Haz. Szam, EladóID Tetel. I Mennyise Ertek Szamla. I Vonal. Kod Cimek. Emelet, Ház. Szám VevőID Cimek. Lakas. Szam, D g D Köz. Ter. Név Értékesít. ID Cimek. Koz. Ter. Nev, 1 60. 0011, 40 CZ 1847 17519458619 Köz. Ter. Tip ÁFA Módosító Cimek. Irany. Szam, A normalizáció következtében a gyakorlati adatstruktúra Ir. Szamok. Telepul, Ir. Szám ÁFASáv Módosítva 0 88 778 Vevok. Nev, kezdő számára rémisztően sok táblára esik szét, és a mini. Telefon ÁFA% Vevok. Haz. Szam, Állapot Mobil Vevok. Emelet, mális hely- és munkaerőfogyasztásra optimalizált táro. E-mail Vevok. Lakas. Szam, Tétel lási struktúra totál más lesz, mint amit papíron látunk!!! ITJVevok. Koz. Ter. Nev, Tétel. ID Vevok. Irany. Szam, ITJKód Mennyis E struktúrát a fejlesztő is csak egyedkapcsolati diag. Ir. Szam_1. Telepul Leírás NetÉrt FROM ramnak (Entity Relationship Diagram, ERD) nevezett techni- ÁFASáv Termék ((Irany. Szamok AS Irany. Szamok_1 BrutÉrt INNER JOIN Vonal. Kód Vasarlok Számla. ID kával tudja áttekinteni, de a felhasználónak erre esélye sincs ON Irany. Szamok_1. Irany. Szam = Leírás Vonal. Kód Vasarlok. Irany. Szam) Ezért a tárolási rendszer adatbázis táblái és a GUI űrlapjai Mért. EgységÁr INNER JOIN(((Irany. Szamok INNER Modosító JOIN Cegek IITJKód Mért. Egys (Form) közt nézettáblás SQL lekérdezések (View Table) te. Modosítva ON Irany. Szamok. Irany. Szam = Mért. Egys MEgys. Név Állapot Cegek. Irany. Szam) remtenek kétirányú adatkapcsolatot: felhozzák a tárolt INNER JOIN Eladok ON Cegek. Ado. Szam = Eladok. Ado. Szam) adatokat és visszaviszik a felhasználó által rögzítetteket INNER JOIN Szamlak Eladok. Elado. Kod = Így a formokon a felhasználó szinte ugyanazt láthatja majd, ON Szamlak. Elado. Kod) mint papíron, de szinte korlátlan kapacitással fog működni (pl. ON Vasarlok. Vasarlo. Kod = Szamlak. Vasarlo. Kod); a számlán max. 12 tétel helyett sok 100 -at bevihetünk)

Vállalati adatkezelő rendszerek: No. SQL Adatmodellek 1 A relációs adatmodell nagy teljesítményű, de nehezen tanulható: nagy szakértelmet, absztrakciós készséget és intuíciót/gyakorlatot igényel a tervezés, ami nem automatizálható ha rossz az ERD, rossz az egész! A relációs adatbázis szerver drága hardvert igényel, az SQL feldolgozás igen bonyolultan alakítható át felhőbeli működtetésre, sok kisebb gépen Nem minden alkalmazásban van szükség a relációs adatmodell által teljesített ACID kritériumok maradéktalan betartására: Atomicity: Undo-zni lehessen minden adatmódosítást, egy napló alapján Consistency: Az adatbázis ellenőrzi, hogy ne írhassanak bele ellentmondó, korruptált adatokat (pl. típusok, elsődleges/idegen kulcsok egyeztetése) Isolation: ha 2 felhasználó dolgozik egyszerre 1 táblán, nem láthatják egymás félkész adatait, csak már a véglegesen Rögzítettet (Committed) Durability: Kommitolt adat csak SSD-n tárolódhat, nem veszhet el áramkimaradásban/lefagyásban A No. SQL adatmodellek tudatosan feladnak követelményeket az ACIDból, amik az adott alkalmazásban nem fontosak (Pl. légi irányításban, a rendszernek tényleg mutatnia kell MINDEN gép pozícióját, különben egy 85 éves pakisztáni nagymama veséje 1800 km/h találkozási sebességgel fog átzúgni a te veséden. De ha Porn. Hubot használsz, túl fogod élni, ha lemaradsz pár képről…)

Vállalati adatkezelő rendszerek: No. SQL Adatmodellek 2 Nem adatbázis táblák rekordjaiban tárolják az információt, így nem merülnek fel az egyedek létrehozásának problémái, nem fix hosszúságú gyakorlati adatstruktúrákat direktben kezeli: Kulcs: Érték (Key: Value) párt leíró objektum-kollekciók RAM-ban/SSD-n (pl. Webprogramozásban a Session, a kliens-szerver kommunikációt tároló objektum), a kulcs nem muszáj hogy egyedi értékű legyen, de kevés ismétlődést tartalmazzon, fejlettebb változatában kulcs szerint rendezett a kollekció Dokumentum (Document): ugyanaz mint előző, de kulcs mindig egyedi azonosító, és az érték nemcsak egy adatmező lehet, hanem dokumentumonként eltérő szerkezetű mini-hierarchiák: Hierarchikusan egymásba dobozolt script nyelv: XML, JSON, YAML Ugyanennek memóriafoglalása bináris formában: BSON Szöveg/kép/mozi/hang fájlok hierarchikus könyvtár szerkezetben SSD-n (Tag)ekkel megjelölt fájl (pl. Instagram poszt, Flickr kép) Elem létrehozásakor/módosításakor/törlésekor csak a közvetlenül kapcsolódó elemekkel vizsgálja az Eseti konzisztenciát (Eventual consistency Check) nem az egész adatbázissal, ezért óriási adatbázisok (pl. Google kereső) könnyebb megosztott kezelése, felhőben, olcsóbb hardveren Viszont a konzisztencia sértés miatt elveszthet beírt adatot, vagy nem mindig a legfrissebb adatot mutatja A legtöbb adatmódosító műveletet nem lehet tökéletesen visszavonni Nincs szabványos lekérdező nyelve (mint a relációs adatmodellnek az SQL), rendszerint No. SQL adatbáziskezelőnként más és más Java metódusokkal kérdezhető le. Forrás: https: //www. w 3 schools. com/xml/simple. xml

Vállalati adatkezelő rendszerek: Gráf-alapú adatmodell Ha a fejlesztendő alkalmazásban olyan nagy a bizonytalanság, hogy a megrendelő/ annak szakértői sem tudják biztosan megadni a résztvevő objektumok (1: 1, 1: több, több: több) számossági viszonyait, ez igen megnehezíti a normalizációt és relációs adatmodell létrehozását. A Gráf adatbázis (Graph database) olyan eszköz, ami nagyszámú m Csomópont (Node) közt (m 1)×m közvetlen irányított összeköttetést, Élet (Edge), valamint a csomópontokhoz/élekhez tetszőleges számú Tulajdonságot (Property) képes létrehozni/ olvasni/ módosítani/ törölni: Relációs adatbázissal No. SQL Kulcs: Érték vagy Dokumentum adatbázissal Nem kell törődnöm vele, hogy a gráf hogyan működik, csak azzal hogy milyen tulajdonságokat aggatok a csomópontjaira/ éleire – bármit össze tudok kötni bármivel és le is tudom kérdezni, anélkül hogy normalizációt kellene végeznem! A sok közvetlen összeköttetés miatt előnybe kerül a relációs adatbázis SQL nyelvével szemben azon lekérdezésekben, ahol sok szinten összecsatolt táblákon kellene keresztülhaladni, és a csatoláshoz egyszerre többféle tulajdonságot kell egyeztetni (pl. Pia leimolás: Kik a barátaim vagy barátaim barátai, akik adott időpontban térben közel vannak hozzám ÉS szeretik a kézműves söröket ÉS magasabb jövedelműek, mint én? ) Új adatok tömeges, automatikus importálásakor/ módosításkor/ törléskor jóval lassabb, mint az SQL, mert m adathoz rengeteg, akár (m-1)×m összeköttetést kell Forrás: módosítani https: //www. imagenesmy. com/imagenes Ha No. SQL alapú a gráf, akkor ez sem teljesíti az ACID kritériumokat, ha relációs alapú, akkor igen, de /email-data-model-97. html akkor ugyanoly drága hardver kell hozzá Nincs egységes lekérdező nyelve, adatbáziskezelőnként más, rendszerint Java-ban írt eljárás könyvtárakon keresztül kezelhető.

Vállalati adatkezelő rendszerek: SAP HANA adatmodell Az SAP legújabb S/4 változatához fejlesztett HANA adatmodell a relációs adatmodellt fejleszti tovább, arra a technikai fejlődésre alapozva, hogy még a mechanikus HDD sebessége százada se volt a RAM sebességnek, az új SSD-k és a RAM sebessége már közel van egymáshoz: Megtartja a relációs modell ACID megfelelését, és az SQL nyelv adta gyors tömeges adat beszúrást/ törlést/ módosítást: az adatok az egyik fajta tárolási módjukban maradnak relációs adatbázis táblákban (fix struktúrájú rekordok sorfolytonosan egymásután a RAM-ban/ SSD-n, elsődleges/ idegen kulcsokon alapuló relációkkal összekötve) Sok tulajdonságot egyeztető, sok szinten csatoló lekérdezésekkor (pl. felsővezetői jelentések készítése On-Line Analytical Processing, OLAP-ban: a jelentés strutúrája/ aggregációja/ lefúrása/ mutatott adatai grafikus felületről, programozás nélkül max 5 másodperces frissítéssel változtatható) eléri a gráf adatbázisokét elérő lekérdezési sebességet, mert minden adatot egy második módon is tárol: oszloponként/ mezőnként sorfolytonosan egymás után a RAM-ban/ SSD-n. (Pl. ha a Forgalom mezőt kell összeadni, nem lépeget végig 100 M rekordon és olvassa fel egyenként mindegyik Forgalom mezőjét, hanem a tükörpéldányban tárolt Forgalom oszlopot összegzi) Kb. 10×. . 100× sebességnövekedést ér el sima relációs alapú OLAP-hoz képest. Lekérdező nyelve szabványos SQL-en, OLAP-on alapul, kiegészítésekkel A kétfajta (rekordonkéni, mezőnkénti) tárolási tükör közti szinkronizáció – megosztott elérés esetén is! – teljesen automatikusan, gyorsan, hardverközeli szinten folyik egy újfajta memóriamodul révén. Ezért brutálisan drága hardver kell hozzá, csak SAP-tól beszerezhető

Táblázatkezelő, OPP, Relációs, No. SQL, Gráf, HANA adatmodellek összehasonlítása 1 Az előnyöket zölddel a hátrányokat pirossal a közepes képességeket sárgával jelöljük Erőforr Elérési Tervez Create/ Import fogy. sebess Táblázatkezelő OOP Relációs No. SQL Gráf HANA Csak Bonyolult Közepes bonyolult Bonyolult relációs Egyszerű, Power. Queryvel objektum osztály relációs elemzés, normalizálatlan elemzés, kezel relációs hierarchia terv normalizáció adatokon adatmodellt normalizáció Csak manuális Automatikus Munkalap Automatikus adatb generáció programozással, manuális létrehoz, import kézzel generáció ERD-ből, generáció, multi generáció, ERD-ből, több 1 táblás import több táblás import fájl import nehéz import programoz táblás import Alacsony, amíg Alacsony, cella csak Alacsony, amíg Alacsony, de Alacsony, cella Óriási, üres cella nem kezd el előírt byte fogyaszt, nem kezd el sokdimenziós csak előírt byte is 100 byte oprendszer saját memória oprendszer esetben fogyaszt, saját fogyaszt memória cachelni cachelés memória cachelni robbanhat mem. cachelés Pointer A legalacsonyabb Pointer láncolást Indexeléssel m m elemű használ, amíg RAM elemű táblából használ, amíg elemű táblából halmazban m/2 -ba befér, addig Log 2(m) lépésben RAM-ba befér, használ, amíg RAM-ba befér, Log 2(m) lépésben talál meg közepes keres addig közepes lépésben keres Közepesnél SQL adatbázis Lassú, egy gyengébb, A legalacsonyabb, A legnagyobb, motor adaelemhez bár írható hozzá amíg RAM-ba befér optimalizációval dokumenamíg RAM-ba sok élet kell OOP makró tumokban tageket befér közepesnél gyorsabb keres módosítani Alapbol fix Alapból kezel Alapbol fix rugalmatlan Nagyon rugalmas, rugalmasan Alapból kezel struktúra, rugalmasan 1 cellában bármi bővíthető nem fix struktúra, rugalmas nem normalizációval bővíthető nem fix lehet normalizációval lehet struktúrákat fix struktúrákat lehet feloldani struktúrákat feloldani Gyenge osztott Minimális osztott kezelés, nincs kezelés nincs OK Gyenge OK OK tranzakc kezel Közepesen nehéz, Nagyon komplex: Nagyon Cellaképletekkel Nagyon komplex: SQL-ben az egyszerű: minden OOP szintaktikai eredményt OOP szintaktikai komplex: OOP szintaktikai Közepesen részeredményt tudás, absztrakciós definiálom, az tudás, nehéz SQL látunk, azonnali készség kell absztrakciós algoritmus absztrakciós debug készség kell automatikus készség kell Még nincs kialakult Közepes: Borzasztó nehéz: C ANSI SQL 95%-ban kialakult ANSI SQL 95%- Módosít Rugal- ACID Prog. sebess masság komplexit Sza vány

Táblázatkezelő, OPP/No. SQL/Gráf, Relációs/HANA adatbázisok közti átjárási utak ODBC Szerver adatlinkelés magas Rugalmasság OOP/No. SQL /Gráf Makrók Relációs /HANA o bj ek tu m M un k al ap ró k ok Rugalmasság M ak Fajlagos teljesítmény SQL utasítások cella függvényként Objektum orientált, Hierarchikus adatbázis kezelés Pivot tábla jelentések A rendszerek kölcsönös előnyeinek/hátrányainak kiegyenlítése céljából az idők folyamán sok átjárást dolgoztak ki köztük: alacsony Rugalmasság Táblázat kezelő Programozás komplexitása magas

Relációs adatbáziskezelés: Normalizáció: 1. Normálforma: Egyed 1. Normálforma: a gyakorlati adatstruktúrákat szét kell bontani (Decompose) egyedekre (Entity): egyed bármi lehet, ami: Nagy számban fordul elő (Occourence) (pl. Számla, Termék), Előfordulásai azonos tulajdonságokkal (Property) írhatók le (pl. Számla: Számlaszám, Kiállítási. Dátum, Végösszeg, Kiállító, Termék: Vonalkód, Név stb. ), ezért az egyed mindig fix hosszúságú struktúrában tárolható. A tulajdonságainak: (pl. Végösszeg) Van Logikai Neve(Logical Name): egyedi az egyeden belül: (pl. Végösszeg) Van Logikai adattípusa (Logical data type): a rendszerfüggetlen adatbázis tervben „nagyjából” milyen típusú lesz: egész, tört, szöveg, dátum, kép, stb. még konkrét fizikai helyfoglalás nélkül (pl. tört, 2 tizedes jeggyel) TIPIKUS KEZDŐ HIBA! Soha ne tároljunk számot, dátumot szövegként, vagy dátumot egész számként! Ha nem a megfelelő típust használjuk, erőforrást pazarolunk, és nem tudunk velük számolni! Lehet Alapértelmezett értéke (Default value): ha nem történik adatbevitel ezt mutassa (pl. 0. 00). Ha nincs megadva ilyen, akkor az adatbázisban a hiányzó értéket NULL jelöli: ez nem keverendő a nullával(0), ami egy szám! TIPIKUS KEZDŐ HIBA! Valaki Exceles tapasztalatai alapján, ahol a hiányzó érték az üres cella, és automatikusan konvertálódik zérus számmá, összekeveri a NULL-t a zérussal. A NULL értékű mező itt: Nem konvertálódik automatikusan zérussá! Nem lehet vele számításokat végezni! Nem lehet összehasonlítani mással: a NULL=NULL állítás is hamis! Lehet min/max értékhatára (Range) (pl. -999, 999. 99) Lehet kötelező kitöltésű(Reqired): Nem lehet NULL (de 0 igen, ha szám!) Lehet automatikusan kitöltött (Auto-fill) képlettel: (pl. =SUM(Tétel. Érték))

Relációs adatbáziskezelés: Normalizáció: 1. Normálforma: Azonosítónevek Az egyedek rendszer-független tábla tervek, ezért logikai neveik (Logical Name): Egyediek (Unique) az egész adatbázis terven belül Közmegegyezés szerint bármely nyelven egyes számban vannak (pl. Számla egyed), hogy megkülönböztessük a belőlük létrejövő Fizikai adatbázis tábláktól (Physical database table): Adott hardveren, adott oprendszer alól futó adott adatbáziskezelő része Fizikai nevük (Physical Name) mindig többes számú (pl. Számlák tábla) A fizikai tábla-mező nevek viszont megegyeznek a tulajdonságok logikai neveivel MI EZ A KAVARÁS A NEVEKKEL!? Egy nagy adatbázis tervben (pl. SAP vállalatirányítási rendszer mögötti adattárház) több 1000 tábla is szerepelhet, amin 10 -50 adatbázis-tervező dolgozik folyamatosan. Fontos egyértelműsíteni, melyik tábla van már kész, és melyik van csak tervezés alatt! Az egyed/tábla nevét „. ” választja el a tulajdonságétól/mezőnévtől (pl. Számla. Kiállítási. Dátum), kivéve SAP-ABAP, ahol „~” Egy egyeden/táblán belül a tulajdonságok nevei egyediek kell hogy legyenek (pl. nem hívhatom a Számlában a kiállítási- és a fizetési dátumot ugyanúgy, ezért: . Kiállítási. Dátum, . Fizetési. Dátum) Több egyeden/táblán keresztül a tulajdonság/mezőnevek ismétlődhetnek, sőt ajánlatos a hasonló dolgokat konzekvensen ugyanúgy hívni, az állandó szintaktikai hibák elkerülése végett (pl. ha az egész számlának, de külön egy tételének is lehet fizetési határideje, akkor ezt mindenhol. Fizetési. Dátum–nak hívjuk, ne hol így - hol úgy) Az egyed/tábla és tulajdonság/mező nevek kiválasztása: Ideális hosszuk 8± 3 karakter, Ne kezdődjenek számmal, Ne tartalmazzanak ékezetes betűket és speciális jeleket (pl. MS SQL, Access kezeli, de Oracle My. SQL, DBase nem, ha ezekbe importáljuk, az szívás!), Legyenek értelmes angol rövidítések (pl. P: túl rövid, nem derül ki, mi a fene ez, Partial. Installment: túl hosszú, könnyű elírni SQL kódban, ezért Part. Inst) Összetett szavakra nagy kezdőbetűs tagolás ajánlott az áttekinthetőség végett (pl. Part. Inst) de különben kisbetűk-nagybetűk az azonosítónevekben azonosak

Relációs adatbáziskezelés: Normalizáció: 1. Normálforma: Reláció-elemzés 1 Az egyedek szétbontásának eszköze a Relációs elemzés (Relational Analysis): Ez olyan állításokból áll, ahol az állítás különböző funkciójú részeit az áttekinthetőség miatt különböző színkódokkal jelöljük (lásd őket alább). Egy állítás mindig: Két Egyed (Entity) vagy Tulajdonság (Property) (nevezzük őket itt A-nak és B-nek) Kapcsolatát (Relation) elemzi Két oldalról (A kapcsolata B-hez + B kapcsolata A-hoz) Két jellemző szerint, ahol mind a kettőnek három lehetséges értéke lehet: Számosság (Cardinality): A hány előfordulásához B-ből hány tartoz(hat)? A: B=1: 1: A 1 előfordulásához B 1 előfordulása tartoz(hat), ÉS B 1 előfordulásához is A 1 előfordulása tartoz(hat): kölcsönösen egyértelmű hozzárendelés pl. 1 Bankszámlához 1 IBANKód tartozik, és 1 IBANKódhoz 1 Bankszámla tartozik A: B=1: több: A 1 előfordulásához B több előfordulása tartoz(hat), DE B 1 előfordulásához A 1 előfordulása tartoz(hat): pl. 1 Ügyfélhez több Bankszámla tartozhat, de 1 Bankszámlához 1 Ügyfél tartozik A: B=több: A több előfordulásához B több előfordulása tartoz(hat), ÉS B több előfordulásához A több előfordulása tartoz(hat) pl. 1 Bankhoz több Ügyfél tartozhat, és 1 Ügyfélhez több Bank tartozhat Függés (Dependency): A Kötelező (Required) előfeltétele-e B-nek, vagy B Opcionálisan (Optional) kapcsolódik hozzá? A: B=Függő: Ahoz B tartozik, ÉS Bhez A tartozik: kölcsönös függés (pl. nincs bankszámla IBAN nélkül és nincs IBAN bankszámla nélkül) A: B=Független: Függő: Ahoz B tartozhat, DE Bhez A tartozik: egyoldalú függés: (pl. nincs bankszámla ügyfél nélkül, de ügyfél lehet bankszámla nélkül) A: B=Független: Ahoz B tartozhat, ÉS Bhez A tartozhat: kölcsönös függetlenség: (pl. az ügyfél és a bank is létezhet egymás nélkül)

Relációs adatbáziskezelés: Normalizáció: 1. Normálforma: Reláció-elemzés 2 Elméletileg a számosság és a függés mind a 3× 3=9 variációja létezhet, de a gyakorlatban az adatbázis relációinak 90%-a (1: több, független: függő): pl. 1 Számlához több Tétel tartozhat, de 1 Tétel 1 Számlához tartozik. 5 -6%-a (több: több, független: független): pl. 1 Számlának több Termék Tétele lehet, és 1 Termék(fajta) több Számlán is Tétel lehet 2 -3%-a (1: több, független: független): pl: 1 Ember több Könyvet kölcsönözhet, de 1 Könyv 1 Ember által kölcsönözhető A többi fajta rendkívül ritkán, nagyon kivételes esetben fordul csak elő Hogyan használjuk a relációs elemzést az egyedek szétbontására? Egyed-tulajdonság szabály (Entity-property rule): Az egyedhez mindig 1: 1, függő: függő kapcsolódnak a tulajdonságai: pl. 1 Számlához 1 Számla. Szám tartozik, és 1 Számla. Számhoz 1 Számla tartozik Egyed-szétbontási szabály (Entity-decomposition rule): egyeden belül nem maradhat beágyazott 1: több, több: több kapcsolat vagy beágyazott egyed: ami így kapcsolódna hozzá, az más, kibontandó egyed/tulajdonság lesz: pl. 1 Számlához több Tétel tartozhat, de 1 Tétel 1 Számlához tartozik. 1: több+ független: függő kapcsolat: a számla és a tétel 2 külön egyed (és később tábla) lesz, és a tétel függ a számlától, anélkül nem létezhet EZ MOST KOMOLY, HOGY DEDÓS MÓDRA SZÍNES CERUZÁVAL MONDATOKAT KELLENE ÍROGATNOM? ! A PROFIK BIZTOS MÁSKÉPP CSINÁLJÁK! A relációs elemzés elég csúnya száraz elméleti anyag, de ha az ember elkapja (a nem túl bonyolult) logikáját, olyan mint a biciklizés, többet nem felejti el A relációs adatbázis létrehozásának folyamatában minden további lépés gépesíthető, de ez sajnos nem: a jó tervből már csak pár kattintás az üres adatbázis, ami feltölthető adatokkal. Ha a terv rossz, hiába király a hardver, az adatbáziskezelő, meg a programozók, ugyanúgy nem fog működni, mint papíron! A profik nem írogatják le ezt színes ceruzával, hanem egy nemsokára ismertetett diagram technikával terveznek előregyártott sablonokból, de ha új dolgot kell bizonytalan helyzetben elemezni, akkor tizedmásodperc alatt lejátsszák fejben!

Relációs adatbáziskezelés: Normalizáció: 1. Normálforma: Reláció-elemzés 3 VIGYÁZAT, TIPIKUS KEZDŐ HIBA! kezdőként gyakran alábecsüljük egy kapcsolat számosságát. Pl. Szőke Nusika azt hitte, kapcsolata Droid Pistivel 1: 1 lesz , holott volt az már 1: több, sőt több: több is. . . Ha valamit elsőre egyedek közti 1: 1 kapcsolatnak nézünk, akkor valószínűleg mi hibázunk, mert az a valóságban nagyon ritka. Sőt ha valami elsőre 1: több-nek látszik: 1 Ember több Könyvet kölcsönözhet, de 1 Könyv 1 Ember által kölcsönözhető. 1: több, független: független kapcsolat mindig gondolkodjunk általánosítva, vizsgáljuk meg a kivételes eseteket is, és időben hosszabb távon nézzük a dolgot, mert az adatbázisnak nem 1 másodpercig kell működni, hanem sok évig, és akkor már lehet több-több: 1 Ember több Könyvet Kölcsönözhet, és 1 Könyv is több Ember által Kölcsönözhető. több: több, független: független kapcsolat, mert időben egymás után többen is kivehetik ugyanazt a könyvpéldányt! VIGYÁZAT, TIPIKUS KEZDŐ HIBA!Ne keverjük össze egy dolog, pl. Termék példányait: 1 Számlához több Termék. Példány tartozhat, de 1 Termék. Példány 1 Számlához tartozhat. 1: több, független: független kapcsolat, mert egy konkrét cuccot egy számlán egy vevőnek max. egyszer lehet eladni a fajtájával: ez utóbbi magasabb számossággal kapcsolódhat, és gyakrabban szerepel az adatbázisokban önálló egyedként! 1 Számlának több Termék Tétele lehet, és 1 Termék(fajta) több Számlán is Tétel lehet. több: több, független: független kapcsolat: a számla, a termék, sőt a tétel is külön egyedek (és később táblák) lesznek, és számla meg a termék egymástól függetlenül is elvannak: lehet hogy egy terméket egyáltalán nem számláznak ki, és lehet hogy, egy számlán nem szerepel adott fajta termék VIGYÁZAT, TIPIKUS KEZDŐ HIBA! Ne keverjük össze az egyedet/táblát az előfordulásaival/rekordjaival: ahelyett, hogy Eladások. Január, Eladások. Február, stb. sok-sok táblát csinálgatnánk kézzel, lesz egy Eladások tábla Hónap, Összeg mezőkkel, ami sok-sok rekordot (MS SQL-ben kb. 100 milliót) tud automatikusan kezelni, amelyekben elmesélhetjük, mit csináltunk januárban, februárban, stb.

Szakirodalom Objektum hierarchia alapú adatmodell: https: //en. wikipedia. org/wiki/Object_database http: //en. wikipedia. org/wiki/Hierarchical_database_model http: //en. wikipedia. org/wiki/Nested_set_model Relációs adatmodell, normalizáció: http: //en. wikipedia. org/wiki/Edgar_F. _Codd http: //www. itworld. com/nl/db_mgr/05072001/ http: //support. microsoft. com/kb/283878/hu No. SQL adatmodell: https: //en. wikipedia. org/wiki/No. SQL Gráf alapú adatmodell: https: //en. wikipedia. org/wiki/Graph_database SAP HANA adatmodell: https: //help. sap. com/http. svc/rc/fb 8 f 7 a 9 f 7860468 b 84 a 07 eab 0 a 7 d 0 a 98/2. 0. 01/en. US/SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en. pdf

Slides: 23

Download presentation