az adatbázis építőelemeinek megértése az SQL Server-ben
minden házban van konyha, legalább egy fürdőszoba és egy hálószoba, bejárati ajtó, vízvezeték-rendszer és egyéb dolgok. Ezeket a dolgokat különböző módon és különböző számban lehet elrendezni, hogy különböző házakat hozzanak létre. Így van ez az adatbázisokkal is. Vannak bizonyos dolgok, amelyek minden adatbázisban közösek. Ebben a bejegyzésben bemutatom az összes adatbázist alkotó építőelemeket, és megmutatom, hogyan vannak összeállítva. Három szabályt is meg fogok vitatni, amelyeket be kell tartani az építőelemek használatakor.
az ebben a bejegyzésben bemutatott anyagnak értékesnek kell lennie mindenki számára, aki bármilyen interakcióban van az adatbázisokkal, de nagyon elemi szinten van. Az adatbázis-tervezés átfogóbb megvitatásához, kérjük, olvassa el a cikkemet, az adatbázis-tervezés intuitív megközelítése.
Mini-Világok.
mielőtt rátérnénk az építőelemekre, szánjunk egy percet a mini-világ kifejezés megértésére, mert ez segít megérteni az építőelemeket.
az adatbázis egy mini-világ modellje. A mini-világ lehet orvosi rendelő, kiskereskedelmi üzlet, könyvtár vagy sok más dolog. Amikor információt akarunk a mini-világról, fordulunk az adatbázishoz, amely azt modellezi.
tegyük fel, hogy orvoshoz megy egy találkozóra. Amikor elmondja a recepciósnak, hogy megbeszélése van, a recepciós megpróbálja megtalálni a találkozót a modellben (az adatbázisban). Ha a modellt naprakészen tartották a mini-világával, akkor képesnek kell lennie arra, hogy megerősítse, hogy van egy találkozója. Hasonlóképpen, ha egy vállalkozás meg akarja tudni, hogy melyik nagy volumenű ügyfele nem adott le megrendelést az elmúlt 6 hónapban, akkor fordulhat mini-világának modelljéhez, ha azt a mini-világgal naprakészen tartották.
a mini-világ lehet egy egész vállalkozás, vagy lehet egy vállalkozás része, például egy bankfiók vagy az értékesítési osztály.
az adatbázis-tervező első dolga, hogy megértse a mini-világot, mert a tervező feladata az, hogy megtervezze annak a mini-világnak a modelljét. A mini-világ megértése érdekében a tervező először azonosítja azokat az építőelemeket, amelyek az adatbázis összeállításához vezetnek.
Az Építőelemek
1. Entitások
az entitás valami, ami létezik a mini-világban, és olyan tulajdonságokkal rendelkezik, amelyek érdekesek számunkra. Például egy iskolai beiratkozási mini-világban vannak hallgatói entitások, tanfolyam entitások, oktatói entitások stb. A diákok nevekkel, címekkel, GPA-kkal és egyéb jellemzőkkel rendelkeznek, amelyek érdekelnek minket. A tanfolyamok címekkel, kreditekkel, díjakkal és másokkal rendelkeznek. Az oktatóknak pedig vannak neveik, címeik, képesítéseik és mások. Az entitások egyediek. Minden tanuló egy egyedi entitás; ott van John és Mary és így tovább. Minden tanfolyam egyedi entitás, és minden oktató egyedi entitás.
az entitásoknak nem kell fizikai dolgoknak lenniük. Bár nem lehet megérinteni, látni vagy szagolni a beiratkozást, ennek ellenére létezik az iskolai beiratkozási mini-világban, és olyan jellemzőkkel rendelkezik, amelyek érdekesek számunkra, mint például a beiratkozás dátuma, a beiratkozott hallgató, a tanfolyam, amelybe a hallgató beiratkozott, és a végső osztályzat kapott. Az értékesítés olyan entitások további példái, amelyek nem rendelkeznek fizikai összetevővel, de amelyek számunkra érdekes jellemzőkkel rendelkeznek (értékesítés dátuma, ügyfél, eladó, megrendelés összege, szállítás módja, fizetési feltételek stb.).
2. Entitás-típusok
az azonos típusú entitások egy entitás-típushoz tartoznak. Az entitás-típus az ilyen típusú entitások halmaza. A hallgatói entitás-típus az összes hallgató halmaza. A tanfolyam entitás típusa az összes tanfolyam halmaza, az oktató entitás típusa pedig az összes oktató halmaza.
entitás-típusok a legfontosabb fogalom ebben a bejegyzésben. Táblázatokká válnak egy adatbázisban.
3. Attribútumok
az entitás attribútumai az entitás azon jellemzői, amelyek számunkra érdekesek. Mint már említettük, a diákok attribútumai közé tartozik a név, a cím, a GPA és mások. A kurzusoknak vannak nevei, kreditjei, osztályai, amelyekhez tartoznak, és mások. És így tovább más entitástípusokkal.
az építőelemek összeállítása
hogyan jelennek meg ezek az építőelemek az adatbázisban? Minden entitástípust egy táblázat képvisel az adatbázisban. Ebben a táblázatban az egyes sorok az egyedi entitások, az oszlopok pedig az attribútumok. Íme egy példa egy táblázatra, amely a hitelkártya-entitás típusát képviseli:
építőelem-szabályok
az építőelemekkel való munka során fontos betartani bizonyos szabályokat, amelyek nemcsak megkönnyítik az adatbázis-objektumokkal való munkát, hanem megakadályozzák az adat anomáliákat is (az adat anomáliák túlmutatnak ezen a poszton, de részletesen tárgyalják az adatbázis-tervezés intuitív megközelítése című cikkemben).
1.szabály: minden táblázatnak csak egy entitás-típust kell képviselnie.
az iskolai beiratkozási mini-világ adatbázisának fent a következő táblázatokra van szüksége: Diák, tanfolyam, oktató, beiratkozás és mások, egy minden egyes entitás-típushoz, amelyet abban a mini-világban azonosítottak. Az orvosi rendelő mini-world adatbázisának szüksége van egy Orvosasztalra, egy Betegasztalra, egy kinevezési táblára, egy Gyógyszerasztalra stb. Egy táblázat minden entitás-típushoz.
kivétel van e szabály alól. Készülj fel, itt jön az agy twister: Ha két entitás-típus azonos attribútumokkal rendelkezik, és az egyik entitás-típusban szereplő entitás a másik entitás-típusban is entitás (az egyik entitás mindkét entitás-típus tagja), akkor a két entitás-típus egy táblában ábrázolható. Itt van, újra: a professzor entitás-típusú és a Tanácsadó entitás-típusú egyaránt képviselteti magát egy táblázatban, mert a tanácsadók is professzorok és ugyanazokkal a tulajdonságokkal (professzor / tanácsadó neve, professzor / tanácsadó képesítések, és mások). És újra: A mappa entitás típusa és az almappa entitás típusa egyaránt ábrázolható egy táblában, mivel az összes almappa entitás is Mappaantitások, és ugyanazokkal az attribútumokkal rendelkeznek (mappa címe, mappaméret, a mappában lévő elemek száma, szülőmappa és mások). Csak még egy: az alkalmazott és a menedzser entitástípusok ugyanabban a táblában ábrázolhatók, mivel az alkalmazottak és a menedzser entitások ugyanazokkal az attribútumokkal rendelkeznek, és a menedzser entitások szintén alkalmazott entitások. A szabály alóli kivételt közelebbről megvizsgáljuk egy másik blogban: SQL Server – az Öncsatlakozási lekérdezés.
egyébként vegye figyelembe, hogy ez a szabály az oka annak, hogy a táblázat megnevezésének helyes módja egyes számban van. A táblák egyetlen entitástípust képviselnek.
2.szabály: minden oszlopnak atomosnak kell lennie.
gondolkodott már azon, hogy az adatbázis-tábláknak miért lehetnek oszlopai a város és az állam számára, de csak egy oszlopa van a címnek? Talán elgondolkodott azon, hogy miért nincs oszlop a Címszámhoz, egy másik a cím utca típusához (Blvd., Sugárút stb.), egy másik a lakás számához stb. Miért vannak ezek az oszlopok általában egyetlen Címoszlopba tömörítve? A válasz ezekre a kérdésekre az atomicitás megértésében rejlik.
amikor azt mondjuk, hogy egy oszlop atomi, akkor azt értjük, hogy nem osztható tovább, és továbbra is megőrzi jelentését. Készítsünk egy oszlopot, és nevezzük MegaAddress-nek, amely tartalmaz egy utcacímet a várossal és az állammal együtt.
de mivel az oszlop egyes részein kereséseket, rendezéseket és egyéb műveleteket hajtunk végre (város szerinti keresés, állam szerinti rendezés, csak az utcai címrész kinyomtatása stb.), elmondhatjuk, hogy az oszlop alrészeinek saját jelentése van (Utcacím, város és állam). Tehát a MegaAddress nem atomi. Jobb asztal lenne:
most, mi a helyzet a StreetAddress oszlop? Ezt tovább kellene osztanunk Utcanévre, Utcanévre és Utcanévre? Mindaddig, amíg nem teszünk semmi jelentőset a részegységekkel—ha nem rendezzük az utcaszámokat, keressük meg az összes utat vagy utat stb.—, akkor az oszlop atomi, ahogy van. De ha megtesszük ezeket a dolgokat, akkor az oszlop nem atomi, majd igen, fel kell osztanunk a leírtak szerint.
3.szabály: az oszlopok nem lehetnek többértékűek.
egyes entitástípusok többértékű attribútumokat tartalmaznak, vagy olyan attribútumot, amelynek egynél több értéke is lehet. A Tanfolyamtáblázatban lehet egy előfeltételnek nevezett attribútum. Mivel egy tanfolyam entitásnak több előfeltétele is lehet, az előfeltétel attribútum többértékű attribútum. Amikor létrehozunk egy táblázatot a tanfolyam entitástípushoz, nem tudjuk az előfeltétel attribútumot oszlopként ábrázolni a táblázatban. A többértékű attribútum megfelelő ábrázolásához létre kell hoznunk egy másik táblát, és az eredeti táblához kell kapcsolnunk egy-a-sokhoz kapcsolat segítségével (a kapcsolatokat részletesen tárgyaljuk az Interface Tachnical Training Sql100 tanfolyamokon: Bevezetés a Transact-SQL-be és az SQL250-be: Transact-SQL fejlesztőknek és cikkemben az adatbázis-tervezés intuitív megközelítése). A többértékű attribútumok további példái közé tartoznak a munkavállaló eltartottjai, az orvos képesítései stb.
a 3.szabály azt mondja, hogy egy adott entitáshoz (egy táblázat sorához) minden oszlopban csak egy érték lehet.
Összegzés
ez a bejegyzés bemutatta a mini-világ fogalmát, mint egy üzleti vagy más környezet szempontjait, amelyeket egy adatbázis modellez. A post egy olyan adatbázistáblát is leírt, amely egyetlen entitás-típust képvisel, amelyben a sorok az azonos típusú egyes entitásokat tartalmazzák, az oszlopok pedig ezen entitások attribútumait képviselik. A táblázatokra vonatkozóan három szabályt vezettek be. Az 1. szabály kimondja, hogy egy táblázatnak egyetlen entitástípust kell képviselnie. A szabály alóli kivétel az, amikor két entitás-típus azonos attribútumokkal rendelkezik, és az egyik entitás-típus entitásai a másik entitás-típus tagjai. Ebben az esetben mindkét entitás-típus ábrázolható ugyanabban a táblázatban. A 2. szabály kimondja, hogy a táblázat minden oszlopának atomosnak kell lennie, ami azt jelenti, hogy egy oszlop nem osztható fel, és továbbra is megőrzi jelentését a mini-világban. Végül a 3. szabály kimondja, hogy a táblázat oszlopai nem lehetnek többértékűek, ami azt jelenti, hogy egy adott entitáshoz (egy táblázat sorához) oszloponként csak egy érték lehet.
jó szórakozást!
Peter Avila
SQL Server oktató-interfész műszaki képzés
Phoenix, AZ
attribútumok, adatbázisok, entitás típusok, mini-világ, almappa, értékek
Leave a Reply