Bevezetés a MySQL relációs adatbázisba:
A fogalmi relációs adatbázis nem más, mint fenntartani a szükséges kapcsolatot a több tábla között valamilyen elsődleges, egyedi vagy idegen kulcskoncepció használatával. Bármely adatbázis, amely gyakorlatilag követi ezt a megközelítést, és megfelelő kapcsolatot tart fenn az összes létrehozott táblázat között, akkor az adatbázis mindig relációs adatbázisnak tekinthető. A MySQL relációs adatbázis szintén ugyanazt a relációs struktúrát követi, tehát nem kétséges, hogy az SQL szerver relációs adatbázisnak is tekinthető, míg a „reláció” kifejezést a MySQL dokumentumok nem említették, vagy sem. Alapvető adatbázis, amely nem fogalmaz meg egy relációs adatbázist, minden táblázat sok adatot tartalmaz, beleértve a tranzakciós és a master is egyaránt, ezen adatok logikai kötésének megértése nagyon nehéz lesz a megfelelő üzleti logika ismerete nélkül. A relációs adatbázisok biztosítják ezt a megközelítést.
A MySQL relációs adatbázis relációs vezérlő rendszere:
A relációs adatbázis konkrét meghatározása alapján az emberek azt gondolják, hogy ez túl kritikus a fenntartáshoz, és zavart okoz. Ez azonban nem igaz állítás, a relációs adatbázis fõ napirendje, hogy elkerüljék az esetleges zavarokat vagy bonyodalmakat az adott adatbázishoz tartozó több tábla között, ahol ez segít a fejlesztõnek karbantartás és ellenõrzés nélkül, minden erõfeszítés nélkül. Ha olyan relációs kialakítást veszünk figyelembe, amely nagyon gyakori, akkor az adatbázisban meghatározott összes kapcsolódó táblázat között szigorú kapcsolat van fenn. Tegyük fel, hogy fontolgathatunk egy készlet-ellenőrző rendszert - ebben az esetben egy nagyon szigorú kapcsolatot kell fenntartanunk az összes tábla között, akik részt vettek a leltárhoz kapcsolódó további leírásban. Ezenkívül szigorúbb kapcsolatot kell fenntartania azokkal a gyermektáblákkal, amelyek emellett befolyásoltak bármilyen adatkezelési tevékenységet, például az adott leltárba való beillesztést vagy az onnan való törlést. Példaként három olyan táblát fogunk megvizsgálni, akik részt vesznek a készlet-ellenőrző rendszerben, feltételezve, hogy három egymással összefüggenek.
Táblázat neve: Készlet
| ID (elsődleges kulcs) | Leírás | Ár | Készlet |
Táblázat neve: Sales_Staff
| ID (elsődleges kulcs) | Név | kapcsolatba lépni |
Táblázat neve: Számla
| ID (elsődleges kulcs) | SalesStaff_ID (Sales_Staff elsődleges kulcs idegen kulcs) | Inventory_ID (a leltár elsődleges kulcsának idegen kulcsa) | Mennyiség | Ár | megjegyzés |
Most, figyelembe véve a fenti három táblát, megtervezhetjük a kapcsolat több tábla között az elsődleges kulcs és az idegen kulcs korlátozásának felhasználásával. A fenti példában a Számla a fő tranzakciós tábla, ahol az összes tranzakciós adatot sikeresen tárolják minden egyes számlageneráláskor az egyes ügyfeleknél vagy végfelhasználóknál, és ténylegesen minden számlaadatot sikeresen tároltak bármilyen referenciához. Most a számlának olyan leltár-részletekből kell előállítania, ahol egy teljes üzlet vagy szervezet számára a teljes lekérdezés tárolódott. Most figyelembe vesszük két kulcsfontosságú táblát, mint például a Leltár és az Értékesítés_tagos, mind a táblák az adott üzletben vagy szervezetben található bármely elem főtároló adatait tartják fenn, míg a Sales_Staff az összes üzletben vagy szervezetben dolgozó alkalmazottak adatait fenntartotta. Ahelyett, hogy ugyanazt a személyzetet vagy egy adott elemet minden alkalommal megőrizné a készlet-tranzakciós részletekben, valójában egy egyedi hivatkozást tartalmaz azokról a főtáblákról, amelyeket az üzlet vagy a szervezet valamely adminisztrátora fenntart. Tehát ezzel a speciális megközelítéssel könnyen elkerülhetjük az adatok redundanciáját vagy az adatok ismétlését, ami mindig segít az adatok lekérésében a több táblázat közötti fenntartott kapcsolat alapján. Ez a példa megadta az olyan relációs adatbázisok egyik kulcsfontosságú tulajdonságát, mint a MySQL relációs adatbázis, azaz feltételezzük, hogy egy számlaadatok mindig tartalmazzák a meghatározott készlet- és értékesítési munkatársak hivatkozását, de a készlet- vagy értékesítési munkatársak soha nem tudnak módosítani vagy frissíteni semmit a létrehozott számlán.
Tehát itt valóban fenntartott egy-sok kapcsolatot, ahol egy készletdarab létezhet többször a számlán, és ugyanaz az értékesítési munkatársi adat többször létezhet a számlán. Ez a kapcsolat elősegíti a fejlesztő számára az adatok zökkenőmentes lekérését egy adott csatlakozási feltétellel, valamint az ER diagram megértését vagy megtervezését. Itt is egy kulcsfontosságú pont, amelyet meg kell említeni, tegyük fel, hogy minden értékesítő személy megpróbál eladni valamit, ami a készletben van, és ezt az ilyen típusú kapcsolat fenntartása is biztosítja. Mint mindig, amikor a számlához bármilyen készlet hozzáadódik, ez automatikusan kivonja a készletet az eredeti készletből, így mindig megfelelő érvényesítési üzenetet fog küldeni, amikor az eladó személy megpróbál valamilyen számlát készíteni egy adott készletre. Ha alaposan megvizsgáljuk ezeket a táblázati viszonyokat, akkor a Készlet egy elsődleges kulcsneve Id, a Sales_Staff egyik elsődleges kulcsszava pedig az ID, a Számlának azonban két idegen kulcs van, amely valóban fenntartja a kapcsolatot az Inventory és a Sales_Staff táblákkal. Biztosítja azt is, hogy bármi beilleszthető a Számla táblába, amely ténylegesen létezik a Készlet vagy az Értékesítés_táblázat táblában, és konkrét adatok hiányában nem lehet egyetlen bejegyzést tenni a Számla táblába. Mivel a Számla táblának mindkét táblával egy-egy speciális idegen kulcs kapcsolata van, így csak az a tábla, amely létezik, csak a Számla táblázatban tudja bejegyzést tenni. Tehát mindig segíti a fejlesztőt abban az esetben, ha rossz beillesztést készít anélkül, hogy ezeket az adatokat a gyermektáblákon tárolná.
Útmutató a My SQL Relációs adatbázis telepítéséhez és letöltéséhez:
Számos verzió érhető el az interneten a MySQL telepítéséhez a helyi számítógépre, de a MySQL Szervezet egy nagyon érdekes funkcióval rendelkezik, a relációs adatbázis ingyenes mintájával, valamint olyan módszerekkel, amelyek fejlettebbek, mint a relációs adatbázis többi ingyenes mintája, lehetőséget ad a film adatainak tárolására, az egyik kulcsfontosságú pont a ártalmatlan felhasználói élmény, azt jelenti, hogy feltételezzük, hogy egy felhasználó valamilyen hibát követ el, ezért az adatbázis teljesen nem működik, ebben az esetben nagyon egyszerű, vagy mondhatjuk, hogy 2 perces feladat a helyreállítás ezt az adatbázist a forrásból.
1. Töltse le a MySQL relációs adatbázist az alábbról:
- http://downloads.mysql.com/docs/sakila-db.tar.gz
2. Az alábbi parancsfájl végrehajtása az archív csomag kicsomagolásához:
- tar –xzf xxxx-db.tar.gz
3. Kicsomagolása után 3 könyvtárat hoz létre, mint az alábbiak szerint:
- Xxxx / sakila-db.sql
- Sakila-schema.sql
- Sakila.mwb
4. Most futtassa a MySQL alapparancsot:
- Mysql –p (jelszó)
5. Most kövesse csak a sakila-db.sql és a sakila-schema.sql fájlokban szereplő utasításokat.
6. Ha az összes utasítást megfelelően követik, akkor létrejön egy új adatbázis “sakila” névvel, amely automatikusan megjelenik a MySQL relációs adatbázis listában.
Ajánlott cikkek
Ez a cikk útmutatóként szolgál a MySQL relációs adatbázishoz. Itt tárgyalták a relációs ellenőrző rendszert és a MySQL relációs adatbázis telepítésére vonatkozó útmutatást. A következő cikkben további információkat is megnézhet
- RDBMS interjúkérdések és válaszok
- Legfontosabb különbségek a MySQL és a NoSQL között
- A MySQL Cheat Sheet felhasználása
- DBMS interjúkérdések