Adatbáziskezelés 2

1. Adatbáziskezelés 2 2. Előadás Dr. Pauler Gábor, egyetemi docens PTE-TTK IATT, 7624 Pécs, Ifjúság u.6. B104 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://szentagothai.ttk.pte.hu/pub/pauler/Database2

2. 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

3. Vállalati adatkezelő rendszerek: Egy táblás rendszerek 1 Struct tInvoice InvoiceNum As String SellerNameAs String SellerAddressAs String SellerTaxRegAs String BuyerNameAs String BuyerAddressAs String InvoiceDate As Date Item1NameAs String Item1MeasUnitAs String Item1Quantity As Double Item1UnitPrice As Single Item1TaxPerc As Single Item1GrossVal As Double Item2NameAs String Item2MeasUnitAs String Item2Quantity As Double Item2UnitPrice As Single Item2TaxPerc As Single Item2GrossVal As Double … TotalVal As Double End Struct • Az adatbázis/memória tábla (Database/Internal Table): fix struktúrájú, és hosszúságú, 1..n sorszámozott rekordokat (Record) tárol egymásután merevlemezen/memóriában: • A rekordok egy egyed (Enity) előfordulásaihoz (Occournce) tartozó tulajdonságokat (Property) írják le a következő adatokkal: • Mezőnév (Field name) • Mezőtípus (Field Type): String, Date, Integer, stb. a Byte-ban mért helyfoglalással • Min/Max/Alap érték (Min/Max/Default value) • Kötelező/Opcionális kitöltés (Required/Optional) •  Az adatbázis/memória tábla nagy tömegű rekord gyors elérését teszi lehetővé, mert a rekordok kezdőpozíciója előre kiszámítható az Index×RekordHossz szorzataként. •  De 1 tábla nem tudja megoldani azokat a problé-mákat, amelyek a gyakorlati adatstruktúrák nem fix hosszából erednek, mert ez egy fix struktúrájú tároló: • 2-1.PÉLDA: Tegyük fel, hogy Droid Pisti, az „eccerű” programozó úgy akarja megoldani a szőnyeg szám-lázási rendszert, úgy, hogy a papír alapú számla 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

4. Vállalati adatkezelő rendszerek: Egy táblás rendszerek 2 Számla EladóNév R EladóCím R EladóAdóSzám R VevőNév CRU VevőCím CRU SzámlaSzám R ÉrtékesítőNév CRU ÖsszÉrték= Sum(Tétel.BruttóÉrték) Fizetve CRUD Dátum Idő Tétel TételLeír R MértEgys R VonalKód CR ITJKód R Mennyis CRUD EgységÁr R ÁFA% R BruttóÉrték= (EgységÁr* Mennyis*(+ ÁFA%/100)) • 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) • Orsós Dzsenifer: 8-12 db gyereke van „aranyozskám, különbe’ mibű’ lenne szocsegíly, háazuramse dóggozik!” a kis Orsós Á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!

5. 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 (4th Generation Languages, 4GL) (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

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

7. 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 adat-struktúrát, amíg minden táblastruktúra fix hosszúságú lesz, így nagy se-bessé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: • Az eredeti nem fix hosszúságú struktúrákat is tárolni tudjuk a táblákat összekötő relációk (Relation) révén: a tábla rekordjait egyedileg azonosító elsődleges kulcs (Primary Key, PK) mezőre más táblából érték-egyezés-sel () hivatkozó idegen kulcs (Foreign Key, FK) mező. Miért? Például: • Minden tételnél kötelezően meg kell adni, mely számlához tartozik • Ez fix helyen tárolható, mert 1Tétel csak 1Számlához tartozik, viszont 1Számlára így már korlátlan sokTé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!

8. 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

9.  A normalizáció következtében a gyakorlati adatstruktúra kezdő számára rémisztően sok táblára esik szét, és a mini-mális hely- és munkaerőfogyasztásra optimalizált táro-lási struktúra totál más lesz, mint amit papíron látunk!!!  E struktúrát a fejlesztő is csak egy egyedkapcsolati diag-ramnak (Entity Relationship Diagram, ERD) nevezett techni-kával tudja áttekinteni, de a felhasználónak erre esélye sincs  Ezért a tárolási rendszer adatbázis táblái és a GUI űrlapjai (Form) közt nézettáblás SQL lekérdezések (View Table) te-remtenek kétirányú adatkapcsolatot: felhozzák a tárolt adatokat és visszaviszik a felhasználó által rögzítetteket Így a formokon a felhasználó szinte ugyanazt láthatja majd, mint papíron, de szinte korlátlan kapacitással fog működni (pl. a számlán max.12 tétel helyett sok 100-at bevihetünk) Vállalati adatkezelő rendszerek: Relációs adatbázis: Értékelése 2 JogiForma JogiForma FormaNév • Vevő • VevőID • KeresztNév • VezetékNév • Ajtó • Emelet • Épület • HázSzám • KözTerNév • KözTerTip • IrSzám • Mobil • E-mail • Eladó • EladóID • CégNév • JogiForma • EladóAdóSz • Ajtó • Emelet • Épület • HázSzám • KözTerNév • KözTerTip • IrSzám • Telefon • Mobil • E-mail • URL KözTerTip KözTerTip TipusNév IrSzám IrSzám Települ Ország SELECT Szamlak.SzlaSzam, Szamlak.Datum, Szamlak.VegOsszeg, Szamlak.Fizetve, Szamlak.EladoKod, Szamlak.VevoKod, Eladok.Nev, Eladok.AdoSzam, Ertekesitok.Nev, Cimek.HazSzam, Cimek.Emelet, Cimek.LakasSzam, Cimek.KozTerNev, Cimek.IranySzam, IrSzamok.Telepul, Vevok.Nev, Vevok.HazSzam, Vevok.Emelet, Vevok.LakasSzam, Vevok.KozTerNev, Vevok.IranySzam, IrSzam_1.Telepul FROM ((IranySzamok AS IranySzamok_1 INNER JOINVasarlok ONIranySzamok_1.IranySzam = Vasarlok.IranySzam) INNER JOIN(((IranySzamokINNER JOINCegek ONIranySzamok.IranySzam = Cegek.IranySzam) INNER JOIN Eladok ONCegek.AdoSzam = Eladok.AdoSzam) INNER JOINSzamlak ONEladok.EladoKod = Szamlak.EladoKod) ONVasarlok.VasarloKod = Szamlak.VasarloKod); Számla SzámlaID SzámlaSzám TételSzám NetÖsszÉrt BrtÖsszÉrt ÁFAÖssz Fizetve KibocsDátum KibocsIdő EladóID VevőID ÉrtékesítID Módosító Módosítva Állapot • Értékesítő • ÉrtékesítőID • KeresztNév • VezetékNév • Ajtó • Emelet • Épület • HázSzám • KözTerNév • KözTerTip • IrSzám • Telefon • Mobil • E-mail Ország Ország OrszNév ÁFA ÁFASáv ÁFA% Tétel TételID Mennyis NetÉrt BrutÉrt SzámlaID VonalKód Modosító Modosítva Állapot ITJ ITJKód Leírás ÁFASáv Termék VonalKód Leírás EgységÁr IITJKód MértEgys MértEgys MértEgys MEgysNév

10. Vállalati adatkezelő rendszerek: Táblázatkezelő, 4GL 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

11. A rendszerek kölcsö-nös előnyeinek-hátrá-nyainak kiegyenlítése céljából az idők folya-mán sok átjárást dol-goztak ki köztük, Az ODBC-vel és a Pivot táblákkal majd foglalkozunk Vállalati adatkezelő rendszerek: Táblázatkezelő, 4GL OPP, Relációs adatbázis összehasonlítása 2 ODBC Szerver adatlinkelés magas Rugal- masság Objektum orientált, Hierarchikus adatbázis kezelés 4GL nyelvek Makrók Relációs adatbázis Rugal- masság SQL utasítások cella függvényként Pivot tábla jelentések Fajlagos teljesítmény Makrók Munkalap objektumok Rugal- masság Táblázat kezelő alacsony Programozás komplexitása magas alacsony

12. 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

13. 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ásiDá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öveg-ké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,999.99..999,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))

14. 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állalat-irá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ásiDá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ásiDátum, .FizetésiDá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ésiDá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 MySQL, 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, PartialInstallment:túl hosszú, könnyű elírni SQL kódban, ezért PartInst) • Összetett szavakra nagy kezdőbetűs tagolás ajánlott az áttekinthetőség végett (pl. PartInst) de különben kisbetűk-nagybetűk az azonosítónevekben azonosak

15. 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 (RelationalAnalysis): 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étEgyed (Entity) vagy Tulajdonság (Property) (nevezzük őket itt A-nak és B-nek) Kapcsolatát (Relation) elemzi • Kétoldalról (Akapcsolata 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: A1 előfordulásához B1 előfordulása tartoz(hat), ÉS B1előfordulásához is A1 előfordulása tartoz(hat): kölcsönösen egyértelmű hozzárendelés • pl. 1Bankszámlához 1IBANKódtartozik, és 1IBANKódhoz1Bankszámlatartozik • A:B=1:több: A1 előfordulásához Btöbbelőfordulása tartoz(hat), DE B1 előfordulásához A1 előfordulása tartoz(hat): • pl. 1Ügyfélhez többBankszámlatartozhat, de 1Bankszámlához 1Ügyféltartozik • A:B=több:több: Atöbbelőfordulásához Btöbb előfordulása tartoz(hat), ÉS Btöbb előfordulásához Atöbb előfordulása tartoz(hat) • pl. 1Bankhoz többÜgyfél tartozhat, és 1Ügyfélhez többBanktartozhat • Függés (Dependency): AKötelező (Required) előfeltétele-e B-nek, vagy BOpcionálisan (Optional) kapcsolódik hozzá? • A:B=Függő: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ő: AhozBtartozhat, DE Bhez Atartozik: 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:Független: AhozB 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)

16. 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. 1Számlához többTételtartozhat, de1Tétel 1Számláhoztartozik. • 5-6%-a (több:több,független:független): pl. 1Számlának többTermékTétele lehet, és1Termék(fajta)többSzámlán isTétel lehet • 2-3%-a (1:több,független:független): pl: 1EmbertöbbKönyvetkölcsönözhet, de1Könyv 1Ember általkö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. 1Számlához 1SzámlaSzámtartozik, és 1SzámlaSzámhoz 1Számla tartozik • Egyed-szétbontási szabály (Entity-decomposition rule): egy 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. 1Számlához többTételtartozhat, de1Tétel 1Számláhoztartozik. 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!

17. 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: • 1EmbertöbbKönyvetkölcsönözhet, de1Könyv 1Ember általkö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: • 1EmbertöbbKönyvetKölcsönözhet, és1Könyv istöbbEmber általKö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: • 1Számlához többTermékPéldánytartozhat, de1TermékPéldány 1Számláhoztartozhat.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! • 1Számlának többTermékTétele lehet, és1Termék(fajta)többSzámlán isTé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, hogyEladásokJanuár, EladásokFebruár, stb. sok-sok táblát csinálgatnánk kézzel, lesz egyEladások tábla Hónap, Összeg mezőkkel, ami sok-sok rekordot (MS SQL-ben kb. 100milliót) tud automatikusan kezelni, amelyekben elmesélhetjük, mit csináltunk januárban, februárban, stb.

18. 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/ab2.ppt • http://support.microsoft.com/kb/283878/hu