Mi az a rész, és mit eszik?
Előadások a "Bevezetés a DBMS elméletébe"
Mielőtt elkezdené gyakorolni a modellezést, komplex adatbázis tervezését vagy egy töredezett adatbázis kezelését, legalább minimális elméleti ismeretekkel kell gazdagodnia. Az ősi időkben, amikor csak az adatbázisok álmodtak, valaki észrevette, hogy elmélet nélkül nincs gyakorlat.
MI AZ RDBMS ÉS MINT EAT
Azok, akik először hallanak adatbázisokról, nincs értelme modellekről, linkekről stb. Az első dolog, amire el kell indítanunk egy elbeszélést, az alapvető fogalommeghatározások, amelyekhez bejut az arzenáljába, könnyen megemésztheti minden más dolgot.
Az adatok bizonyos struktúrák formájában történő tárolására, azaz a környező világ egyes tárgyaira vonatkozó információk megrendelésére, mindig látható volt az emberiség számára. Ebben az esetben egy objektumot objektumként vagy absztraktabb fogalomként értelmezhetünk (például a termelés folyamatát).
Egy tárgy bevezetése az adatbázisba csak a csata fele. Még mindig szüksége van valamiféle jellemzésre, ahhoz, hogy kapcsolódjon hozzá egy bizonyos érték. És akkor be kell mutatni a "megadott" fogalmat. Ez - ez egy bizonyos mutató, amely jellemzi az objektumot és megad egy bizonyos értéket. És nem feltétlenül, hogy az objektumot egy adat határozta meg - sok lehet. Képzeld el, hogy egy hacker struktúrával van dolgod. A hackelés egy objektum. De az adatok - ez a hackelés, az illegális tevékenységek tapasztalata, az írásbeli kizsákmányolások száma és a hackelt gépek stb. Más szavakkal, az adatok egy adott objektum jellemzői. Ez az, ami mindenképpen érdekli az ügyfelet, aki a még mindig jövőbeli adatbázis felé fordult.
Hozzon létre egy több megabájtos fájlt tonna információval (ami egyébként esetleg felesleges), nem megoldás a problémára. A férfi szereti a kényelem, úgyhogy például áttörni az információkat a nagy hacker az ügyfél köteles arra, hogy csak a beceneve cracker, majd fogy-schaya körülbelül kiberbűnözők vált fegyver az igazság. Nagyon nehéz megszervezni ezt a rendszert, több évtizeddel azelőtt, hogy az egyes fájlok méltó adatbázissá váltak (az ini fájlban lévő adatbázis szintén stílusos - jegyzi meg dr.). Most minden sokkal könnyebbé vált a strukturált fájlok - adatbázisok és különböző adatszervezési modellek miatt.
Valójában a modell alapja ennek vagy az adatbázisnak az alapja. Egy vagy másik modellben meghatározzák az adatok, a bemeneti adatok típusai, a tárolási módok, a kezelés stb. Közötti kapcsolatokat. Az adatkommunikáció az alkalmazásprogramokkal DBMS vagy adatbáziskezelő rendszerek segítségével történik.
Tehát a DBMS olyan nyelvi és szoftvereszközök készlete, amelyek sok felhasználó számára létrehozzák, fenntartják és megosztják az adatbázist. Más szavakkal, a DBMS segítségével mindenki, aki (bizonyos jogokkal természetesen) kívánja, hozzáférhet az adatbázishoz, és kikeresheti az érdeklődését.
Ez vagy a DBMS a modelltől függ, amely az adatbázis alapja. Napjainkban a két leggyakoribb modell közösvé vált: a relációs modell (kapcsolati modell) és az objektumorientált modell (az objektummodell). Róluk, és ebben a cikkben tárgyalja.
Kezdjük a relációs modellel. A távoli 1969-ben egy amerikai matematikus, Dr. E.F. Codd (E.F. Codd) elemezte a régebbi rétegzett adatbázisok helyzetét, és arra a következtetésre jutott, hogy az ügy rossz. Az akkoriban elérhető összes modellben jelentős hiányosságok jelentek meg: az adatok redundanciája, a feldolgozás összetettsége és az információ tárolásának biztonsága, stb. A fájdalmas gondolkodás után Codd úgy döntött, hogy saját modelljét hozza létre - a relációs. Azok számára, akik rosszindulatúan kihagyták az angol nyelvet, emlékszem, hogy a kapcsolatot "hozzáállásnak" vagy "asztalnak" nevezik. A zseniális orvos csak felismerte az adatok tárolását táblázatos formában, vagyis ilyen "boltokat" szervezett logikai struktúrák formájában (a fizikai tárolási módok bármelyik lehet). Így a Codd képes volt elérni az információk bemutatását és a feldolgozás kényelmét. Ennek a géniusznak az eléréséhez elegendő volt egy logikai lekérdezés teljesítése, amely betartja a logikai algebra törvényeit, hogy hozzon létre egy adatlapot. Az adatkezelési operátorok között legalább három művelet van: sorok kivonása (SELECT), oszlopok kivonása (PRO-JECT) és táblák összevonása (JOIN). Ennek eredményeképpen kapunk egy táblázatot. És egy egyszerű következtetés mindezről: a relációs modell bármely műveletének eredménye egy olyan objektum, mint az objektum, amelyen a cselekmény végrehajtásra került.
Ez a leírt modell fő tulajdonsága.
Az alapismereteken túl alapvető modellekre is szükségünk van: az adattípus, az attribútum, a tuple, a reláció és az elsődleges kulcs.
Az adattípus olyan definíció, amely megfelel a programozási nyelv típusának koncepciójának. Más szóval, a relációs modell esetében meg lehet jegyezni az olyan alapvető típusokat, mint "egész számok", "húr", "szimbólumok", "lebegőpontos számok", "dátum" és "nap-gy" pénz :)).
Az attribútum egy oszlop egy adat táblában. Ha például a képernyő a hacker-támadásokkal, a kizsákmányolásokkal és a munkatapasztalattal kapcsolatos információkat tartalmaz, akkor ezek az oszlopok attribútumok.
A tuple egy sor egy táblázatban adattal. Így egy adott hackerre vonatkozó kimerítő információ egy tuple.
Az arány az egész tábla. A címkén használt adattípusok leírását a kapcsolat címének nevezik, és minden más (a tulajdonosi adatok) az összefüggés.
Az elsődleges kulcs az attribútumok (oszlopok) minimális halmaza, amely meghatározza az egyes táblák (sorok) egyedi egyediségét a (táblázat) függvényében. Amikor létrehoz egy adatbázist, nagyon alaposan meg kell vizsgálnia az elsődleges kulcskiosztást - példánkban a hacker beceneve nem megfelelő (hirtelen valaki meg akarja venni a bálványa becenevét.)). Előfordul, hogy a hitelesítéshez egy további sorszámú mezőt adnak be, amely minden egyes sor esetében egyedileg eltérő lesz. De senki sem tiltja meg az elsődleges kulcs két vagy három attribútumának kiválasztását: mindent, amennyit csak akar, ha csak ez a művelet logikailag indokolt lenne (az attribútumok egy hasonló tartományát elsődleges kulcsnak nevezik).
Az adatbázis hatékony kezelése érdekében biztosítani kell az adatkapcsolat biztosítását. Egyszerűen szólva, két vagy több táblát kell társítani egy adatbázisba (ha természetesen van). E célból egy úgynevezett "idegen kulcsot" találtak fel, amely egy olyan attribútum (vagy tulajdonságkészlet) egy táblázatban, amely egybeesik a másik elsődleges kulcsával. Ugyanakkor azt is figyelembe kell venni, hogy az egyik táblázat oszlopában lévő minden érték egybeesik a másik értékkel. Ennek a definíciónak a lényege a fogás, miután magyaráztam a lehetséges adatkapcsolatokat.
A DBMS elméletében háromféle kapcsolatot különböztetünk meg: egy-egy, egy-sok-sok-sok-sok-sok-sok. Minden fajról részletesen elmondom.
1. Egy-egy-egy. Ezt a típusú kapcsolatot akkor használjuk, ha az egyik tábla elsődleges kulcsa a másik kulcsa. Hogy világossá tegyük, példát adok: feltételezzük, hogy három táblázata van a hackerek adatbázisának. Az első információ a hackerről: születési dátum, nem (a lányok is crackerek;)) és ICQ. A második a hacker áramok (áramlási típus, komplexitás és kezdeti tőkebefektetések). A harmadik pedig az internethez való hozzáférés típusa (technológia, hozzáférési sebesség, biztonsági értékelés). Mindezek a táblázatok nem csökkenthetők egy, mert az internethez való hozzáférés és a hacker áramok (és nem csak róluk) közötti kapcsolat hiánya miatt zavaros leszünk. És amikor a kapcsolatot három különböző táblázat formájában hajtja végre (az elsődleges kulcs segítségével - az rendszám), akkor mind a magas feldolgozási sebességet, mind az adatok megrendelését biztosítja.
2. Egy-sok-sok. A legegyszerűbb kapcsolat. Ez akkor valósul meg, amikor az egyik asztal elsődleges kulcsát másolja. Ebben az esetben a második táblában ezt a kulcsot már külsõnek nevezik. Nem egyértelmű? Akkor ismét a példához fordulok. Vegyél két táblát - a hackerről ("Hackerek" táblázat) és az általa írt kizsákmányolások jellemzőiről ("Exploits" táblázat). Valójában egy-egy-sok mechanizmus kapcsolódik egymáshoz. Valóban, minden hacker lehet egy auto-
többszörös (többszörös) renget, de minden egyes kizsákmányolást egyetlen és egy szerző írhat (még akkor is, ha együtt dolgozik a hack csoportokban, egy ember egy bizonyos kizsákmányolással foglalkozik). Itt, mint az "Exploits" tábla idegen kulcsát, a hacker becenevet használják, és a kizsákmány neve az elsődleges kulcs. Ebben az esetben az "kulcsszó hacker" idegen kulcs a "Hackerek" tábla elsődleges kulcsa, és itt szándékosan be kell mutatni a két táblát, és meg kell szervezni a szükséges információkat. By the way, a "kizsákmányolás" attitűd nem feltétlenül feltétlenül csak egy attribútumból áll: hozzáadhatja azokat a operációs rendszerek jellemzőit, amelyekre a kizsákmányt alkalmazzák, a célok számát, a típusát (helyi vagy távoli) stb.
Itt, sőt, és minden információ a relációs modellről. Ennek a résznek a javítása érdekében azt fogom mondani, hogy számos DBMS épül az alapjain. Örömmel beszélnék a logikai algebráról, akinek törvényei a relációs modellen alapulnak, de sajnos a jelen cikk kötetek nem engedik meg nekem ezt.
És mi van az adatbázis többi részével? Milyen modellhez tartoznak? Valójában a relációs modell mellett vannak mások is. Senki sem kapott külön terjesztést, kivéve talán objektumorientált, amely később relációs jellegűnek tűnt (ezért nevezik néha relációnak) és ma is használják.
A relációs modell fő feltétele a normalizálás szabálya. Minden táblázatértéknek logikailag oszthatatlannak kell lennie, az oszlopok és sorok rendezetlenek, és nem lehetnek két azonos összefüggés. Az ilyen normalizáció gyakran sérti az objektumok közötti természetes hierarchikus kapcsolatokat, ami rendkívül kellemetlen, ezért a fejlesztők egy új DBMS-t javasoltak, azaz objektumorientált. Az ilyen paradigma lényege, hogy az általa meghatározott előmetrikus terület olyan tárgyak formájában jelenik meg, amelyek az úgynevezett osztályokhoz kapcsolódnak. Az osztály minden objektuma passzív jellemzőkkel vagy módszerekkel rendelkezik. Az objektum kezelése csak az ehhez kapcsolódó módszerekkel lehetséges. Egy objektum attribútumai az érvényes értékek egyike közül választhatnak, és meghatározott értékek határozzák meg az objektum viselkedését. Az attribútumok és módszerek azonos értékeivel rendelkező objektumok egy objektumosztályt definiálnak.
Kiderült, hogy az elmélet objektumorientált adatbázis hasonló a szervezet bármely objektum orientált programozási nyelv-CIÓ. Így van. Bármelyik objektumosztály örökölhető egy másik osztályból, és magában foglalhatja az összes módszert is. Emellett figyelembe kell venni a szabályokat inkapsu-lyatsii: módosítsa az értékeket az objektum attribútumok megengedhető csak a hatalom a módszereket. Végül a polimorfizmus az öröklött objektum metódusainak újradefiniálására szolgáló mechanizmus.
Az OODB fő előnye, hogy egy ilyen adatbázis figyelembe veszi az objektum viselkedési aspektusait, ellentétben a relációs DBMS-vel, amelyben a szerkezet és a viselkedés közötti megszakadás van. Az OODB végrehajtásához azonban speciális programozási nyelvekre van szükség, ami nagymértékben bonyolítja a tervező életét :).
Az ilyen átfedések elkerülése érdekében a relációs és az objektumorientált DBMS-t megpróbálták egyesülni. Világos, hogy ez megkövetelné a szabványok bővítését és a meglévő programozási nyelvek korszerűsítését. Így a nagyvállalatok, az IBM és az Oracle befejezték a DBMS-eket egy objektum felépítésével a rendszer relációs rendszermagja felett.
Minden egyes adatbázis modell esetében saját vezérlőnyelve van. Relációs modell esetén ez a nyelv SQL (strukturált lekérdezési nyelv vagy strukturált lekérdező nyelv). Ennek a nyelvnek az alkotói arra törekedtek, hogy gyermekük közelebb kerüljön az emberi (angol) nyelvhez, és ugyanakkor logikai jelentéssel töltse be.
Az SQL nyelv sokkal könnyebbé teszi azokat, akik folyamatosan foglalkoznak relációs adatbázisokkal. Szigorúan véve, anélkül, hogy egy strukturált nyelvi, hogy sok baleset lenne hogy pici-vel program például a C. Imagine: teljes mértékben Rabo tolvaj a táblázatban, akkor először létre kell hoznia az objektumot, majd Prog-esített kezelést neki kezelések (eltávolítása és hozzáadása sorok ). Ahhoz, hogy megszabaduljon az ilyen vérzéses-raj adatbázis-fejlesztők gondoskodott, a teremtés az SQL nyelv.
Minden SQL lekérdezés nagyon hasonlít a Boole algebra logikai feltételeire (aki nem hagyta ki a matan-ot, ami megért engem :)). Magától látja, ha az oldalsávra néz a fő parancsokkal.
Mint már említettük, vannak más típusok is, kivéve a relációsakat. Különösen objektumorientált. Természetes, hogy az ilyen adatbázisokat egy másik lekérdezési nyelvhez használják.
A legtöbb objektumorientált adatbázisban van egy egyszerű grafikus felület, amely lehetővé teszi a felhasználó számára a navigációs stílusban lévő objektumok elérését. Ez figyelmen kívül hagyja a kapszulázás elvét: senki sem tiltja meg, hogy közvetlenül meglássa az objektumok belsejét. De a szakértők szerint a navigációs stílus az OODB-ben bizonyos értelemben egy "lépés hátra" a relációs DBMS-k lekérdező nyelvéhez képest. Eddig a mu-chitelnye keresés a legjobb zap-rosov nyelvről az OODB-be.
Az adatbázis-hozzáférések alapnyelvei továbbra is egyszerű SQL-szintaxison alapulnak, és egyfajta kiterjesztésűek, amelyek az objektumokra vonatkoznak. Ilyen nyelvek például az ORION, az Iris és az O2 Reloop.
Mint látható, egyetlen relációs modell sem ismert az adatbázisok adatbázisáról. Napjainkban a fejlesztők számos újítással próbálják bővíteni szoftvertermékeiket, és objektumorientált bővítményekkel bővítik a meglévő relációs adatbázis-motort. Ezenkívül az SQL lekérdezési nyelv is módosul. Az SQL3-ban már léteznek konkrét módszerek az OODB-vel való együttműködésre, de megvalósításuk eddig nagyon sok kívánnivalót hagy maga után.
Az átlagember (vagyis az Ön igényeihez) elegendő relációs DBMS van, amelyet mindenhol használnak. Ez a népszerűség kedvelt a MySQL, és a kevésbé kedvelt Hozzáférés, valamint az MSSQL. Nagyon sok ilyen irányítási rendszer létezik, úgy döntöttél, és kiválaszthatja azt, amely többet jelent a szívednek. És ez a nehéz választás, mint mindig, ez az egyedülálló SPECIÁLIS indítás segít:).
Melyek az adatbázisok? A legtöbb esetben a programozók megoldása kétféleképpen korlátozható: helyi és ügyfél-kiszolgáló. Az első esetben "all-in-one" sampont kapunk. A másodikban különválasztjuk az adatokat és az ügyfélalkalmazást, és két szintet kapunk.
Azonban egy harmadik szint már régóta azonosított, és ez a háromszintű modell, amely körül megy. félve összetettségétől. Ebben a cikkben minden modellt külön-külön megvizsgálunk minden előnyével és hátrányával együtt.