SQL alapjai: Információk tárolása a táblázatokban

Ez a fejezet a könyvből származik

Ez a fejezet a book könyvből származik

Példák táblázatokra

Eddig megvitattuk a táblázatok elméletét, de Ön nem látott valódit. A következő szakaszokban néhány tényleges táblázatot láthat. Megtekintünk egy táblázatot, hogy lássuk, hogyan néz ki mind az Oracle, mind az Access alkalmazásban. Megbeszélünk néhány tervezési döntést, amelyet sok táblázat összeállításához használnak. Megvizsgáljuk az ebédek adatbázisának táblázatait is, amelyet a könyv számos példája felhasznál.

1-12 Példa az Oracle és az Access táblázataira

Ez a szakasz ugyanazt a táblázatot mutatja mind az Oracle, mind az Access programban. Ez az első alkalmunk megvizsgálni, hogyan viszonyulnak az Oracle és az Access.

Önnek kell eldöntenie, mennyire hasonlítanak és mennyire különböznek egymástól. Számomra ez a példa azt mutatja, hogy körülbelül 90 százalékban hasonlóak és körülbelül 10 százalékban különböznek egymástól. Természetesen ez csak egy példa. Lehet, hogy felteszi magának a kérdést, hogy mely százalékokat használja ennek leírására.

Az Oracle táblázatok két olyan formátumban jeleníthetők meg, amelyek nagyon hasonlóak, de vannak néhány apró eltérésük. Hogy itt a dolgok egyszerűek maradjanak, csak az egyik ilyen formátumot mutatom be. A következő Oracle táblázatot az „SQL Command Line” környezet használatával szereztük be. A másik Oracle formátum az „Adatbázis kezdőlap” környezetben fordul elő. Röviden tárgyalom a szakasz végén található megjegyzésekben.

l_employees táblázat: Oracle formátum

Az Oracle és az Access közötti hasonlóságok

Az oszlopok neve az oszlop tetején található. Az oszlopnevek a táblázat felépítésének részei, nem pedig a táblázat adatainak részei.
Előfordul, hogy az oszlopfejlécekben látható oszlopnevek csonkák. Ez enyhe probléma. Kapsz eszközöket a kezelésére.
A szöveges adatokat tartalmazó oszlopok balra igazodnak.
A számokat tartalmazó oszlopok jobbra vannak igazítva.
A dátumokat tartalmazó oszlopok gyakran csak a dátumot jelenítik meg. A dátum megjelenítésének formátuma nem része az adatoknak. A dátum értékét a táblázat tárolja, de a dátum formátumát külön megadjuk. A dátum valójában tartalmaz dátumot és időt is, de az idő gyakran nem jelenik meg.
A valutaösszegeket megjelenítő oszlopok valójában számokként vannak tárolva, és a dollárjeleket és a tizedespontokat egy formátumban adják meg.

Különbségek az Oracle és az Access között

Megjelenítési keret: Az Oracle megjeleníti a karakteradatok sorait. Az Access grafikus technikákat alkalmaz az adatok rácsban történő megjelenítésére és a rács határainak színezésére.

Ügy: Az Oracle tábla mind nagybetűvel jelenik meg. Az Access táblázat csak az első betűhöz használ nagybetűket. Általános szokás az adatbázisok ilyen módon történő beállítása. A vegyes betűs adatok elhelyezhetők egy Oracle táblában, de ez megnehezíti az adatok kezelését, így az Oracle adatai általában vagy nagybetűvel, vagy pedig kisbetűvel jelennek meg. A hozzáférési adatokat úgy kezeljük, mintha nagybetűsek lennének, bár vegyes betűkkel jelennek meg. Ettől szebben néz ki, de néha megtévesztő is lehet. Az Accessben az adatok vegyes betűknek tűnnek, de az adatok úgy viselkednek, mintha nagybetűvel íródtak volna. Például John és jOhn különbözik az Access-ben, de úgy kezelik őket, mintha ugyanazok lennének.

Oszlopfejlécek: Az Oracle több sort is használhat egy oszlopfejléchez. Az Access egyetlen sorban jeleníti meg a fejlécet.

Dátumformátumok: A fenti dátumok az Oracle és az Access azonos dátumformátumot használva mutatják. Azért hoztam létre ezt itt, mert azt szerettem volna, ha az Oracle és az Access hasonlónak tűnik. Azonban a számítógépen a dátumok valószínűleg különböző formátumokat fognak használni.

Az Oracle és az Access egyaránt sokféle formátumban jelenítheti meg a dátumokat. Mindegyik alapértelmezett formátumot használ a dátumokra, amikor nincs megadva más formátum. Az Oracle azonban egy módszert használ az alapértelmezett dátumformátum megadásához, az Access pedig más módszert használ.

Dátum igazítás: Az Oracle a dátumokat balra, míg az Access jobbra igazítja.

Nullák: Ebben a könyvben úgy állítottam be az Oracle-t, hogy a nullákat mindig (null )ként jelenítse meg minden táblázat minden oszlopában. Ezt nem lehet könnyen megtenni az Access alkalmazásban.

Helyzetmutató: Az Access táblázat tartalmaz egy rekordválasztót és egy mutatót a rekord egy adott mezőjére, amely lehetővé teszi az adatok módosítását. Az Oracle táblázat ezeket nem tartalmazza.

Adatok hozzáadásának lehetősége: Az Accessben egy üres sor a táblázat alján azt jelzi, hogy új adatsorok adhatók meg a táblázatban. Ekkor megjelenik egy további oszlop is, amelynek neve „Új mező hozzáadása”. Ez nem az Oracle-ben történik.

A másik Oracle formátumot az „Adatbázis kezdőlap” környezetben használják. Számos technikai különbség van benne, de egyik sem fogja megkérdőjelezni a folyamat megértését. Íme néhány ilyen különbség:

A táblázatok a webböngésző oldalain jelennek meg.
Az oszlopfejléceket soha nem csonkolják.
Minden mező balra igazított.
A nullákat kötőjelekkel mutatják
A dollár összegeket nem formázzák automatikusan.

1-13 Néhány tervezési döntés az l_employees táblázatban

Az l_employees tábla néhány tervezési döntést tartalmaz, amelyekre szeretném felhívni a figyelmét, mert ezek a relációs adatbázisok néhány általános gyakorlatát tükrözik. Mint minden tervezési döntés, más módon is meghozhatták őket. Ez nem az egyetlen módja az asztal megtervezésének. Lehet, hogy nem is ez a legjobb módszer. De gyakran találkozhat ezekkel a tervezési döntésekkel, és tisztában kell lennie velük.

l_employees táblázat

Tervezési döntések, amelyekkel tisztában kell lenni

A telefonszám oszlop szöveges adatokat tartalmaz, nem számokat. Bár az adatok számoknak tűnnek, és az oszlop neve számot mond, valójában szöveges adattípussal rendelkezik. Ezt meg tudja állapítani az igazításával, amely balra található. A táblázat ilyen módon történő összeállítása az az oka, hogy a telefonszám adatait soha nem fogják használni számtani célokra. Soha nem adhat hozzá két telefonszámot, és nem szaporíthatja őket. Csak szövegmezőként használja őket, ahogy vannak. Tehát ez a táblázat szövegként tárolja őket.
Az alkalmazott_azonosító oszlop számokat tartalmaz. Ezt meg tudja állapítani az igazításával, ami jobbra van. Most nem végezzük a számolást a munkavállalói azonosítókkal, soha nem adjuk össze őket, akkor miért nem ez a szövegmező is? A válasz az, hogy a számokat gyakran használják az elsődleges kulcsoszlopokhoz akkor is, ha nem végeznek velük számtant. Ez lehetővé teheti a számítógép számára, hogy gyorsabban kezelje az asztalt.
A manager_id oszlop számokat tartalmaz, de nem elsődleges kulcs oszlop. Akkor miért nem tartalmaz szöveget? Ennek az oszlopnak meg kell egyeznie a worker_id oszloppal, ezért ugyanazt az adattípust kapta, mint az oszlop. Ez javítja a két oszlop összehangolásának sebességét.
A táblázat neve, l_employees, furcsának tűnhet. Az l azt jelzi, hogy ez a táblázat egy táblázatcsoport része. A csoport összes táblájának neve ugyanazzal a betűvel kezdődik. Ebben az esetben azt mutatja, hogy a táblázat a Lunches adatbázis része. (Itt használom a kifejezést adatbázis a kapcsolódó táblázatok gyűjteményét jelenti.)
Az adatbázisokat tervező emberek jelentős mennyiségű munkát végeznek az objektumok következetes elnevezésében, standard előtagok, utótagok, rövidítések és oszlopnevek használatával. Ez az egész modellt könnyebben érthetővé és használhatóbbá teszi az egyes adatbázisokhoz kifejlesztett kódok számára.

1-14 Az ebédek adatbázisa

A könyv SQL példáinak többsége a Lunches adatbázisra épül. Az adatbázis teljes listáját a webhelyről szerezheti be. A könyv elolvasásához meg kell értenie a történetet és az adatokat, tehát itt van az alaptörténet.

Van egy kis cég, tíz alkalmazottal. Ez a cég három alkalommal szolgál fel ebédet alkalmazottai számára. Minden alkalmazott annyi részt vehet ezekből az ebédekből, amennyit ütemezése megenged. Amikor az alkalmazottak regisztrálnak egy ebédre, akkor válogathatnak, mit akarnak enni. A rendelkezésükre álló tíz étel közül választhatnak. Dönthetnek úgy, hogy ezekből az élelmiszerekből egyetlen adagot vagy dupla adagot fogyasztanak. A Lunches adatbázis nyomon követi ezeket az információkat.

Ez a történet. Most nézzük meg az adatokat. Amikor ezt adatbázisnak hívom, akkor azt értem, hogy ez egy kapcsolódó táblák gyűjteménye. Az asztalok együttesen elmondják a történetet. Az adatbázisban hét táblázat található:

Alkalmazottak (l_employees)
Osztályok (l_departments)
Konstansok (l_konstansok)
Ebéd (l_lunches)
Élelmiszerek (l_foods)
Beszállítók (l_suppliers)
Ebéd elemek (l_lunch_items)

Annak bemutatására, hogy ezek a táblák mind kapcsolatban vannak egymással, és hogy megkülönböztessük őket más általunk használt tábláktól, ezeknek a tábláknak a neve előtagként l betűvel van ellátva. Ha több szó van, például lunch_items, a szóközöket aláhúzás karakterekkel helyettesítik. Ez segít a számítógépnek megérteni, hogy a két szó együtt egyetlen név.

l_employees táblázat

Az l_employees táblázat felsorolja az összes alkalmazottat. Minden alkalmazott azonosítható munkavállalói azonosítóval, amely egy szám, amelyet neki rendeltek. Ez lehetővé teszi a vállalat számára, hogy két azonos nevű embert alkalmazzon. Az elsődleges kulcs az alkalmazott_azonosító oszlop.

Minden alkalmazottnak van egy vezetője, aki egyben a vállalat alkalmazottja is. A vezetőt munkavállalói azonosítója alapján azonosítják. Például a manager_id oszlop azt mutatja, hogy Jim Kernt a 201-es alkalmazott irányítja. A 201-es alkalmazott Susan Brown.

Susan Brown és Carol Rose az egyetlen alkalmazott, akinek nincs vezetője. Ezt azért mondhatja el, mert a manager_id oszlopokban van egy null. Ezek a nullák azonban különböző dolgokat jelentenek.

Susan Brown a cég vezetője. A null ebben az esetben nem azt jelenti, hogy nem tudjuk, ki a menedzsere. Inkább azt jelenti, hogy nincs menedzsere.

Carol Rose új bérlet. A manager_id oszlopában szereplő null azt jelentheti, hogy még nem rendelték hozzá egy menedzserhez, vagy azt jelentheti, hogy az információt még nem vitték be az adatbázisba.

l_departments táblázat

Minden alkalmazott egy osztálynak dolgozik. Az osztály kódja az l_employees táblában látható. Az egyes részlegek teljes neve az l_departments táblázatban látható. A táblázat elsődleges kulcsa a dept_code.

Ezek a táblák összekapcsolhatók a dept_code oszlopok egyezésével. Például az l_employees táblázat megmutatja, hogy a 202-es alkalmazottnak, Jim Kernnek SAL osztálykódja van. Az l_departments táblázat azt mondja, hogy az értékesítési részleg a SAL osztálykódot használja. Ez azt mondja nekünk, hogy Jim Kern az értékesítési osztályon dolgozik.

l_konstansok táblázat

Az l_constants táblázat néhány állandó értéket tartalmaz, és csak egy sora van. Ezeket az értékeket az adatbázis többi táblájával együtt használjuk. Várhatóan ezek az értékek ritkán változnak, ha egyáltalán. Külön táblában tárolva az SQL-kódot rugalmasan biztosítja, alternatívát kínálva ezen értékek SQL-be történő kemény kódolásához. Mivel az állandótáblázatnak csak egy sora van, ezért nincs szüksége elsődleges kulcsra.

l_ ebéd asztal

Az l_lunches táblázat regisztrálja az alkalmazottat, hogy részt vegyen egy ebéden. Minden felszolgált ebédhez hozzárendel egy ebéd azonosítót. Például a 207-es alkalmazott, Dan Smith, részt vesz egy ebéden, 2011. november 16-án. Az ebédjét úgy azonosítják, hogy lunch_id = 2.

Az lunch_id oszlop a táblázat elsődleges kulcsa. Ez egy példa a helyettesítő kulcs, amelyet más néven a értelmetlen elsődleges kulcs. Minden sorhoz egyedi szám tartozik, de ennek a számnak nincs belső jelentése. Ez csak egy kényelmes név, amelyet a sornak, vagy az objektumnak használunk, amelyet a sor képvisel - ebben az esetben egy ebéd.

Az l_lunches táblázat a helyettesítő kulcs használatának leggyakoribb módját mutatja. Általában egyetlen oszlop az elsődleges kulcs. Az oszlopnak minden sorban más és más értéke van.

Egyes adatbázis-tervezők szeretnek helyettesítő kulcsokat használni, mert javíthatják az adatbázisban lévő lekérdezések hatékonyságát. A helyettesítő kulcsokat elsősorban egy olyan elsődleges kulcs helyettesítésére használják, amelynek sok oszlopa lenne, és amikor egy táblát gyakran sok más táblához kapcsolnak.

Más tervezők nem szeretik a pótkulcsokat, mert inkább azt, hogy minden oszlop tartalmazzon értelmes adatokat. Ez egy vita terület az adatbázis-tervezők között, mindkét oldalon sok előnye és hátránya. Az adatbázisokat használó embereknek csak tisztában kell lenniük azzal, hogy ezek az oszlopok értelmetlen számok, amelyeket az egyik táblázat összekapcsolásához használnak.

l_foods táblázat

Az l_foods táblázat felsorolja azokat az ételeket, amelyeket az alkalmazott választhat ebédjéhez. Minden ételt beszállítói azonosító és termékkód azonosít. Ez a két oszlop együtt alkotja az elsődleges kulcsot. A termékkódok a szállítóké. Két szállítónak lehetősége van arra, hogy ugyanazt a termékkódot használja a különböző élelmiszerekhez. Valójában az AS termékkódnak két különböző jelentése van. A JBR szállító ezt a termékkódot szódához használja, de a VSB szállító desszertként használja.

Javasolják az áremelést, de még nem lépnek hatályba. Az price_increase oszlopban szereplő nullák azt jelentik, hogy ezeknél az élelmiszereknél nem lesz áremelkedés.

l_suppliers táblázat

Az l_suppliers táblázat az ételek szállítóinak teljes nevét tartalmazza. Például az l_foods táblázat azt mutatja, hogy a hasábburgonyát az FRV szállítótól kapják. Az l_suppliers táblázat azt mutatja, hogy a Frank Reed's Vegetables a szállító teljes neve. E táblák elsődleges kulcsa a szállítóazonosító.

l_lunch_items táblázat

Amikor megnézi az l_lunch_items táblázatot, tisztában kell lennie azzal, hogy az item_number oszlopban lévő adatok jobbra vannak igazítva, mert ez egy számoszlop. A szállító_azonosító oszlopban lévő adatok balra vannak igazítva, mert szövegoszlop. Tehát, ha az első sort nézzük, akkor az 1 ASP nem egyetlen adat. Ehelyett az item_number értéke 1, a szállító_id értéke ASP.

Az l_lunch_items táblázat megmutatja, hogy az egyes munkavállalók mely ételeket választották ebédjére. Ebből is látszik, hogy egyetlen vagy dupla adagot akarnak-e. Nézze meg például a lunch_id 2 címet, amelyről már tudjuk, hogy Dan Smith november 16-i ebédje. Négy tételből áll. Az első elemet ASP-SW néven azonosítják. Itt a szállító_azonosító és a termék_kód oszlop adatait kötőjellel elválasztva helyezem el. Az l_foods táblázatba nézve azt találjuk, hogy ez egy szendvics. Az l_lunch_items táblázat azt mondja, hogy kettőt szeretne, ami a mennyiség oszlopban látható. Nézze meg, kitalálhatja-e az összes ételt, amit ebédjéhez szeretne.

A helyes válasz:

2 szendvics
1 rend sült krumpli
2 csésze kávé
1 desszert

A táblázat elsődleges kulcsa a táblázat első két oszlopából áll, az lunch_id és az item_number. Az item_number oszlop a nyakkendő-megszakító oszlop, amely az értelmetlen elsődleges kulcs másik típusa. Ebben a kialakításban az ebéd azonosítóját akartam használni az ebéden belüli egyes ételek azonosítására. Az ebédek többségében azonban több étel is van. Tehát nem használhatom az ebédazonosítót önmagában elsődleges kulcsként, mert ez több sort hozna létre a táblázatban, ugyanazzal az értékkel az elsődleges kulcsban, ami nem megengedett. Szükségem volt arra, hogy minden sorban más érték legyen az elsődleges kulcsban. Ezt teszi a nyakkendő-megszakító oszlop. Az item_number oszlop számozza meg az egyes ebédek tételeit. Ezért az ebédazonosító és a tételszám kombinációja egyedi azonosítást biztosít a táblázat minden sorához, és elsődleges kulcsként szolgálhat. Az ilyen típusú, egynél több oszlopot tartalmazó elsődleges kulcsot néha a-nak hívják összetett kulcs.

Az ebédek adatbázisának kihívást jelentő tulajdonságai

A legtöbb SQL-könyv szelíd és nem tartalmaz kihívásokat tartalmazó adatbázissal dolgozik. Ez a könyv más. Szándékosan tettem fel néhány funkciót az Ebéd adatbázisba, amelyek rossz eredményt okozhatnak, ha nem megfelelően kezeli őket. Megmutatom, hogyan tudatosuljon ezekben a helyzetekben, és hogyan kell kezelni őket. Számos valós üzleti adatbázis tartalmaz hasonló kihívásokat. Íme néhány közülük:

Két alkalmazott nem vesz részt egyik ebédnél sem - a 209. alkalmazott, Paula Jacobs és a 206. alkalmazott, Carol Rose.
Az egyik ebédnél nem rendeltek egy ételt - brokkolit.
Az egyik osztályon még nincsenek alkalmazottak - a személyzeti osztály.