PTI Rendszertervezs 2 Elads Dr Pauler Gbor egyetemi

PTI Rendszertervezés 2. Előadás Dr. Pauler Gábor, egyetemi docens PTE-TTK Inf. Tech és Biorobotika tsz. , 7624 Pécs, Ifjúság u. 6. F 104 Mobil: 30/9015 -488, Skype: gjpauler E-mail: pauler@t-online. hu Facebook: PTE-TTK PTI Rendszertervezés

Az előadás tartalma A vállalati adatkezelő rendszerek Egy táblás rendszerek és hátrányaik Objektum-hierarchia alapú adatbáziskezelés Relációs adatbáziskezelés Alapfogalma Értékelése Táblázatkezelők, Objektum-hierarchia és Relációs adatbázis ö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: Egy táblás rendszerek 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: Egy táblás rendszerek 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: 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) O. Dzsenifer: 8 -12 db gyereke van „aranyozskám, különbe’ mibű’ lenne szocsegíly, háazuramse dóggozik!” a kis O. Ámort már nem tudja a rendszer tárolni, adatot vesztünk, éhen hal. 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: Objektum-hierarchia alapú adatbáziskezelés 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 kétfajta 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ú adatbáziskezelés 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: Relációs adatbázis: 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 adatbázis: É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 táblákkal dolgozhatunk 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 adatbázis: É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: Táblázatkezelő, 4 GL OPP, Relációs adatbázis ö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 Táblázatkezelő OOP-hierarchia-alapú model Létreho Memória Elérési Számolá Rugal- Prog. Kód Imp/ z fogyaszt sebess si sebess masság komplexit újrafel Exp Az alkalmazást csak manuálisan lehet létrehozni a tervből Relációs modell Egy csomó szoftver automatikusan generál üres adatbázist ERD tervből A rugalmas struktúra miatt Jól tervezett normalizált több Minden cella több 100 byte-t alacsony fajlagos táblás struktura fajlagos fogyaszt, akkor is ha üres, helyfogyasztás, de az óriási fajlagos fogyasztás oprendszer virtuális memória fogyasztása alacsony, nagyon swappelését használja, ami gáz profi cachelés lemezről A legalacsonyabb, max. 65536 Pointer láncolást használ, 1 M Profi indexeléssel 100 M sorban átlag 32768 lépésben listaelemből 500 E lépésben talál rekordból 1 -et 25 lépésben talál meg egy elemet meg egyet meg A legalacsonyabb, bár írható hozzá OOP makró A legnagyobb SQL profi adatbáziskezelőkben mindenféle trükkökkel eléri az OOP sebesség 90%-át Teljesen fix, rugalmatlan Örökléssel-beágyazással elég struktúrájú táblák, amit csak Nagyon rugalmas, 1 cellában rugalmasan bővíthető nem fix bármi lehet normalizált tervezéssel lehet struktúrák feloldani! Nagyon komplex: tudni kell az SQL nyelv nagyon tömör, 1 SQL OOP alapelveit, és az adott sor = 400 -500 OOP sor, ez Cellaképletekkel egyszerű: minden részeredményt magunk szintaktikát, magas absztrakciót felgyorsítja a programozást, de előtt látunk, egyszerűbb debug követel, nem láthatók részered- megnehezíti, és normalizált mények, nehéz debug adatbázis kell hozzá!!! Elvileg!!! Open. Office, Google- Borzasztó nehéz egy kódot C- SQL nyelv 95%-ban szabványos Docs olvas Excel munkalapo- ből Basicbe, Delphibe, Javaba a fő adatbáziskezelők közt kat, de az életed ne tedd rá! áttenni Több táblás import/export ODBC 1 táblás import/export Csak manuális kódolású -vel akár távolról

Vállalati adatkezelő rendszerek: Táblázatkezelő, 4 GL OPP, Relációs adatbázis összehasonlítása 2 ODBC Szerver adatlinkelés magas Rugalmasság 4 GL nyelvek Makrók Relációs adatbázis o bj ek tu m M un k al ap ró k ok Rugalmasság M ak SQL utasítások cella függvényként Pivot tábla jelentések Objektum orientált, Hierarchikus adatbázis kezelés Fajlagos teljesítmény 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, Az ODBC-vel és a Pivot táblákkal majd foglalkozunk alacsony Rugalmasság Táblázat kezelő Programozás komplexitása magas

Az előadás tartalma A vállalati adatkezelő rendszerek Egy táblás rendszerek és hátrányaik Objektum-hierarchia alapú adatbáziskezelés Relációs adatbáziskezelés Alapfogalma Értékelése Táblázatkezelők, Objektum-hierarchia és Relációs adatbázis ö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

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ú adatbáziskezelés: http: //en. wikipedia. org/wiki/Hierarchical_database_model http: //en. wikipedia. org/wiki/Nested_set_model Relációs adatbáziskezelés: E. F. Codd: http: //en. wikipedia. org/wiki/Edgar_F. _Codd, http: //www. itworld. com/nl/db_mgr/05072001/ Normalizáció: www. inczedy. hu/~szikszai/adatbazis/ab 2. ppt http: //support. microsoft. com/kb/283878/hu