förstå Databasbyggnadsblock i SQL Server
varje hus har ett kök, minst ett badrum och ett sovrum, en ytterdörr, ett VVS-system och andra saker. Dessa saker kan ordnas på olika sätt och i olika antal för att producera olika hus. Så är det med databaser. Det finns vissa saker som alla databaser har gemensamt. I det här inlägget kommer jag att presentera byggstenarna som utgör alla databaser och visa hur de monteras. Jag kommer också att diskutera tre regler som måste följas när man använder byggstenarna.
materialet som presenteras i detta inlägg bör vara av värde för alla som har någon form av interaktion med databaser, men det är på en mycket elementär nivå. För en mer omfattande diskussion om databasdesign, se min artikel, ett intuitivt tillvägagångssätt för databasdesign.
Mini-Världar.
innan vi kommer till byggstenarna, låt oss ta en stund att förstå termen mini-world eftersom det hjälper oss att förstå byggstenarna.
en databas är en modell av en mini-värld. En mini-värld kan vara ett medicinskt kontor, en detaljhandel, ett bibliotek eller många andra saker. När vi vill ha information om minivärlden vänder vi oss till databasen som modellerar den.
låt oss säga att du går till läkaren för en tid. När du berättar för receptionisten att du har ett möte, kommer receptionisten att försöka hitta ditt möte i modellen (databasen). Om modellen har hållits aktuell med sin minivärld bör den kunna bekräfta att du har ett möte. På samma sätt, om ett företag vill veta vilken av deras stora volymkunder som inte har lagt order under de senaste 6 månaderna, kan de vända sig till modellen för sin mini-värld om den har hållits aktuell med den mini-världen.
en mini-värld kan vara ett helt företag, eller det kan vara en del av ett företag, till exempel en bankfilial eller försäljningsavdelningen.
det första en databasdesigner gör är att förstå minivärlden, eftersom designerns jobb är att designa en modell av den minivärlden. Och för att förstå minivärlden börjar designern med att identifiera byggstenarna som kommer att gå in i att montera en databas.
Byggstenarna
1. Enheter
en enhet är något som finns i minivärlden och som har egenskaper som är av intresse för oss. Till exempel i en mini-värld för skolregistrering finns studentenheter, kursenheter, instruktörsenheter och andra. Studenter har namn, adresser, GPA och andra egenskaper som intresserar oss. Kurser har titlar, krediter, avgifter och andra. Och instruktörer har namn, adresser, kvalifikationer och andra. Enheter är unika. Varje elev är en unik enhet; Det finns John och Mary och så vidare. Varje kurs är en unik enhet och varje instruktör är en unik enhet.
entiteter behöver inte vara fysiska saker. Även om du inte kan röra, se eller lukta en anmälan, finns den ändå i skolans inskrivningsminivärld och har egenskaper som är av intresse för oss, till exempel Datum för anmälan, studenten som anmälde sig, kursen studenten registrerade sig i och slutbetyget fick. Försäljning är andra exempel på enheter som inte har en fysisk komponent men som har egenskaper av intresse för oss (försäljningsdatum, kund, säljare, order totalt, leveransmetod, betalningsvillkor etc.).
2. Entitetstyper
entiteter av samma typ tillhör en entitetstyp. En entitetstyp är en uppsättning enheter av den typen. Studentenhetstypen är uppsättningen av alla studenter. Kursens entitetstyp är uppsättningen av alla kurser och instruktörens entitetstyp är uppsättningen av alla instruktörer.
Entity-typer är det viktigaste konceptet i det här inlägget. De blir tabeller i en databas.
3. Attribut
attributen för en entitet är egenskaperna hos den entiteten som är av intresse för oss. Som redan nämnts inkluderar elevernas attribut namn, adress, GPA och andra. Kurser har namn, krediter, avdelningar de tillhör och andra. Och så vidare med andra entitetstyper.
montering av byggstenarna
hur representeras dessa byggstenar i databasen? Varje entitetstyp representeras av en tabell i databasen. I den tabellen är de enskilda raderna de unika entiteterna och kolumnerna är attributen. Här är ett exempel på en tabell som representerar Kreditkortsenhetens typ:
Byggblockregler
när du arbetar med byggstenar är det viktigt att följa vissa regler som inte bara gör det lättare att arbeta med databasobjekt utan också förhindrar dataavvikelser (dataavvikelser ligger utanför ramen för detta inlägg men diskuteras i detalj i min artikel, ett intuitivt tillvägagångssätt för databasdesign).
regel 1: varje tabell ska representera en och endast en enhetstyp.
databasen för skolans inskrivningsminivärld, ovan, behöver följande tabeller: Student, kurs, instruktör, inskrivning och andra, en för varje enhetstyp som identifieras i den minivärlden. Databasen för medical office mini-world behöver ett Läkarbord, ett patienttabell, ett mötesbord, ett Läkemedelstabell och andra. En tabell för varje entitetstyp.
det finns ett undantag från denna regel. Gör dig redo, här kommer hjärnan twister: Om två entitetstyper delar samma attribut och en entitet i en av entitetstyperna också är en entitet i den andra entitetstypen (en entitet är medlem i båda entitetstyperna), kan de två entitetstyperna representeras i en tabell. Här är det igen: en Professor enhetstyp och en rådgivare Enhetstyp kan båda representeras i en tabell, eftersom rådgivare också är professorer och de har samma attribut (professor/rådgivare namn, professor/rådgivare kvalifikationer och andra). Och igen: En Mappenhetstyp och en undermappenhetstyp kan båda representeras i en tabell, eftersom alla Undermappenheter också är Mappenheter och de delar samma attribut (mapptitel, mappstorlek, antal objekt i mapp, överordnad mapp och andra). Bara en till: typerna anställd och Chefsenhet kan båda representeras i samma tabell, eftersom anställda och chefsenheter har samma attribut och chefsenheter är också anställda enheter. Detta undantag från regeln undersöks närmare i en annan blogg: SQL Server – Självkopplingsfrågan.
lägg förresten märke till att denna regel är anledningen till att det rätta sättet att namnge en tabell är i singularen. Tabeller representerar en enda Enhetstyp.
regel 2: alla kolumner måste vara atomära.
har du någonsin undrat varför databastabeller kan ha kolumner för stad och stat, men bara en kolumn för adressen? Kanske har du undrat varför det inte finns en kolumn för adressnummer, en annan för Adressgatyp (Blvd., Aveny, etc.), en annan för lägenhetsnummer, och så vidare. Varför är dessa kolumner vanligtvis alla klumpade ihop i en enda Adresskolumn? Svaret på alla dessa frågor ligger i en förståelse för atomicitet.
när vi säger att en kolumn är atomär menar vi att den inte kan delas upp ytterligare och fortfarande behåller mening. Låt oss göra en kolumn och kalla det MegaAddress som innehåller en gatuadress tillsammans med stad och stat.
men eftersom vi gör sökningar, sorterar och andra operationer på delar av den kolumnen (Sök efter stad, Sortera efter stat, Skriv ut bara gatuadressdelen osv.) kan vi säga att underavdelningar i den kolumnen har sin egen betydelse (Streetadress, stad och stat). Så, MegaAddress är inte Atom. Ett bättre bord skulle vara:
nu, vad sägs om streetadress kolumnen? Ska vi dela upp det längre ner i gatunummer, gatunamn och StreetType? Så länge vi inte gör något betydande med underavdelningar av det—om vi inte sorterar på gatunummer, söker efter alla vägar eller vägar, och så vidare—då är kolumnen atomär som den är. Men om vi gör dessa saker, så är kolonnen inte atomär och då, ja, vi borde dela upp det som beskrivet.
regel 3: kolumner kan inte multivalueras.
vissa entitetstyper innehåller flervärderade attribut, eller ett attribut som kan ha mer än ett värde. I en kurstabell kan det finnas ett attribut som kallas förutsättningar. Eftersom en kursenhet kan ha mer än en förutsättning är attributet förutsättning ett flervärderat attribut. När vi skapar en tabell för Kursenhetstypen kommer vi inte att kunna representera attributet förutsättning som en kolumn i tabellen. För att korrekt representera ett multivalent attribut måste vi skapa ett annat bord för det och relatera det till det ursprungliga bordet med hjälp av ett en-till-många-förhållande (relationer diskuteras i detalj i de kurser jag undervisar på Interface Tachnical Training SQL100: Introduktion till Transact-SQL och SQL250: Transact-SQL för utvecklare och i min artikel, ett intuitivt tillvägagångssätt för databasdesign). Andra exempel på multivalenta attribut inkluderar en anställds anhöriga, en doktors kvalifikationer och så vidare.
regel 3 säger att för en given enhet (rad i en tabell) kan det bara finnas ett värde i varje kolumn.
sammanfattning
detta inlägg introducerade begreppet mini-världen som aspekter av ett företag eller annan miljö som en databas modeller. Posten beskrev också en databastabell som representerar en enda entitetstyp där raderna innehåller de enskilda entiteterna av samma typ och kolumnerna representerar attributen för dessa entiteter. Tre regler för tabeller infördes. Regel 1 anger att en tabell ska representera en enda Enhetstyp. Undantaget från regeln är när två entitetstyper delar samma attribut och entiteter i en entitetstyp är medlemmar i den andra entitetstypen. I så fall kan båda entitetstyperna representeras i samma tabell. Regel 2 säger att alla kolumner i en tabell måste vara atomära, vilket innebär att en kolumn inte kan delas upp och fortfarande behåller mening i minivärlden. Slutligen anger regel 3 att kolumner i en tabell inte kan multivalueras, vilket innebär att för en viss enhet (rad i en tabell) kan det bara finnas ett värde per kolumn.
Njut!
Peter Avila
SQL Server Instructor – Interface teknisk utbildning
Phoenix, AZ
attribut, databaser, Entitetstyper, mini-world, undermapp, värden
Leave a Reply