Forstå Database Byggeklosser I SQL Server
Hvert hus har et kjøkken, minst ett bad og et soverom, en inngangsdør, et vvs-system og andre ting. Disse tingene kan ordnes på forskjellige måter og i forskjellige tall for å produsere forskjellige hus. Så det er med databaser. Det er visse ting som alle databaser har til felles. I dette innlegget vil jeg introdusere byggesteinene som utgjør alle databaser og vise hvordan de er satt sammen. Jeg vil også diskutere tre regler som må følges når du bruker byggesteinene.
materialet som presenteres i dette innlegget skal være av verdi for alle som har noen form for interaksjon med databaser, men det er på et svært elementært nivå. For en mer omfattende diskusjon av databasedesign, se min artikkel, En Intuitiv Tilnærming Til Databasedesign.
Mini-Verdener.
før vi kommer til byggesteinene, la oss ta et øyeblikk å forstå begrepet mini-verden fordi det vil hjelpe oss å forstå byggesteinene.
en database er en modell av en mini-verden. En mini-verden kan være et medisinsk kontor, en detaljhandel, et bibliotek eller mange andre ting. Når vi vil ha informasjon om mini-verdenen, går vi til databasen som modellerer den.
la oss si at du går til legen for en avtale. Når du forteller resepsjonisten at du har en avtale, vil resepsjonisten prøve å finne din avtale i modellen (databasen). Hvis modellen har blitt holdt oppdatert med sin mini-verden, bør den kunne bekrefte at du har en avtale. På samme måte, hvis en bedrift ønsker å vite hvilken av deres høyvolumskunder som ikke har lagt inn bestillinger de siste 6 månedene, kan de vende seg til modellen av deres mini-verden hvis den har blitt holdt oppdatert med den mini-verdenen.
en mini-verden kan være en hel bedrift, eller det kan være en del av en bedrift, for eksempel en bankfilial eller salgsavdelingen.
det første en databasedesigner gjør er å forstå mini-verdenen, fordi designerens jobb er å designe en modell av den mini-verdenen. Og for å forstå mini-verden, starter designeren ved å identifisere byggesteinene som vil gå inn i å sette sammen en database.
Byggesteinene
1. Enheter
en enhet er noe som eksisterer i miniverdenen og som har egenskaper som er av interesse for oss. For eksempel, i en skole påmelding mini-verden, det er student enheter, kurs enheter, instruktør enheter, og andre. Studentene har navn, adresser, Gpaer og andre egenskaper som interesserer oss. Kursene har titler, kreditter, avgifter og andre. Og instruktører har navn, adresser, kvalifikasjoner og andre. Enheter er unike. Hver student er en unik enhet; Det Er John Og Mary og så videre. Hvert kurs er en unik enhet, og hver instruktør er en unik enhet.
Enheter trenger ikke å være fysiske ting. Selv om du ikke kan berøre, se eller lukte en innmelding, eksisterer den likevel i skolens innmelding mini-verden og har egenskaper som er av interesse for oss, for eksempel datoen for innmelding, studenten som registrerte seg, kurset studenten registrerte seg og den endelige karakteren mottatt. Salg er andre eksempler på enheter som ikke har en fysisk komponent, men som har egenskaper av interesse for oss(salgsdato, kunde, selger, ordretotal, forsendelsesmetode, betalingsbetingelser, etc.).
2. Enhetstyper
Enheter av samme type tilhører en enhetstype. En entitetstype er et sett av entiteter av denne typen. Student entity-typen er settet av alle studenter. Emneenhet-typen er settet med alle emner, Og Underviserenhet-typen er settet med alle instruktører.
Entity-typer er det viktigste konseptet i dette innlegget. De blir tabeller i en database.
3. Attributter
attributtene til en enhet er egenskapene til den enheten som er av interesse for oss. Som allerede nevnt inkluderer studentattributter navn, adresse, GPA og andre. Kursene har navn, studiepoeng, avdelinger de tilhører, og andre. Og så videre med andre enhetstyper.
Montering Av Byggesteinene
hvordan er disse byggesteinene representert i databasen? Hver enhetstype representeres av en tabell i databasen. I den tabellen er de enkelte radene de unike enhetene, og kolonnene er attributtene. Her er et eksempel på en tabell som representerer kredittkort enhet-type:
Byggesteiner Regler
når du arbeider med byggesteiner, er det viktig å følge visse regler som ikke bare gjør det enklere å arbeide med databaseobjekter, men også hindre data anomalier (data anomalier er utenfor omfanget av dette innlegget, men er omtalt i detalj i min artikkel, En Intuitiv Tilnærming Til Database Design).
Regel 1: hver tabell skal representere en og bare en enhetstype.
databasen av skolen påmelding mini-verden, ovenfor, trenger følgende tabeller: Student, Kurs, Instruktør, Påmelding og andre, en for hver enhet-type identifisert i at mini-verden. Databasen til det medisinske kontoret mini-world trenger Et Legebord, Et Pasientbord, Et Avtalebord, Et Medisinbord og andre. En tabell for hver enhetstype.
det er et unntak fra denne regelen. Gjør deg klar, her kommer hjernen twister: Hvis to enhetstyper deler de samme attributtene, og en enhet i en av enhetstypene også er en enhet i den andre enhetstypen (en enhet er medlem av begge enhetstypene), kan de to enhetstypene representeres i en tabell. Her er det igjen: En Professor entitetstype og En Rådgiver entitetstype kan begge representeres i ett bord, fordi rådgivere også er professorer og de har de samme egenskapene (professor/rådgivernavn, professor/rådgiverkvalifikasjoner og andre). Og igjen: En mappeenhetstype og en undermappeenhetstype kan begge representeres i en tabell, fordi alle undermappeenheter også Er Mappeenheter, og de deler de samme attributtene(mappetittel, mappestørrelse, antall elementer i mappe, overordnet mappe og andre). Bare en til: Ansatte og Leder enhet-typer kan begge representeres i samme tabell, fordi ansatte og leder enheter har samme attributter og leder enheter er også ansatt enheter. Dette unntaket fra regelen er undersøkt nærmere i en annen blogg: SQL Server-Spørringen Selv Delta.
forresten, legg merke til at denne regelen er grunnen til at den riktige måten å nevne et bord er i singularet. Tabeller representerer en enkelt enhetstype.
Regel 2: alle kolonner må være atomiske.
har du noen gang lurt på hvorfor databasetabeller kan ha kolonner For By og Stat, men bare en kolonne for adressen? Kanskje du har lurt på hvorfor det ikke er en kolonne For Adressenummer, en annen For Adresse Gate Type (Blvd., Avenue, etc.), en Annen For Leilighet Nummer, og så videre. Hvorfor er disse kolonnene vanligvis samlet sammen i en Enkelt Adressekolonne? Svaret på alle disse spørsmålene ligger i en forståelse av atomicity.
når vi sier at en kolonne er atomisk, mener vi at den ikke kan deles videre og fortsatt beholde mening. La oss gjøre opp en kolonne og kaller Det MegaAddress som inneholder en gateadresse sammen med by og stat.
Men fordi vi gjør søk, sorterer og andre operasjoner på deler av den kolonnen (søk etter by, sorter etter stat, skriv ut bare gateadressedelen, og så videre), kan vi si at underavdelinger av den kolonnen har sin egen betydning (StreetAddress, By og Stat). Så, MegaAddress er ikke atomisk. Et bedre bord ville være:
nå, hva med Kolonnen StreetAddress? Skal vi dele det lenger ned I StreetNumber, StreetName og StreetType? Så lenge vi ikke gjør noe vesentlig med underavdelinger av det-hvis vi ikke sorterer på gatenumre, søker etter alle veier eller veier, og så videre – så er kolonnen atomisk som den er— Men hvis vi gjør disse tingene, er kolonnen ikke atomisk, og da, ja, vi bør dele den som beskrevet.
Regel 3: Kolonner kan ikke flere verdier.
Noen enhetstyper inneholder attributter med flere verdier, eller et attributt som kan ha mer enn en verdi. I En Emnetabell kan det være et attributt som kalles Forutsetninger. Fordi en emneenhet kan ha mer enn en forutsetning, Er Forutsetningsattributtet et attributt med flere verdier. Når vi oppretter en tabell for emnet entitetstype, vil Vi ikke kunne representere Forutsetningsattributtet som en kolonne i tabellen. For å kunne representere et multivalued attributt, må vi opprette et annet bord for det og forholde det til det opprinnelige bordet ved hjelp av et en-til-mange forhold (relasjoner diskuteres i detalj i kursene jeg underviser På Interface Tachnical Training SQL100: Introduksjon Til Transact-SQL OG SQL250: Transact-SQL For Utviklere og i min artikkel, En Intuitiv Tilnærming Til Databasedesign). Andre eksempler på multivalued attributter inkluderer en ansattes pårørende, en lege kvalifikasjoner, og så videre.
Regel 3 sier at for en gitt enhet (rad i en tabell) kan det bare være en verdi i hver kolonne.
Sammendrag
dette innlegget introduserte begrepet mini-verden som aspekter av en bedrift eller et annet miljø som en database modeller. Innlegget beskrev også en databasetabell som representerer en enkelt enhetstype der radene inneholder de enkelte enhetene av samme type, og kolonnene representerer attributtene til disse enhetene. Tre regler om tabeller ble introdusert. Regel 1 sier at en tabell skal representere en enkelt enhetstype. Unntaket fra regelen er når to enhetstyper deler de samme attributtene, og enheter i en enhetstype er medlemmer av den andre enhetstypen. I så fall kan begge enhetstyper representeres i samme tabell. Regel 2 sier at alle kolonner i et bord må være atom, noe som betyr at en kolonne ikke kan deles og fortsatt beholde mening i miniverdenen. Til Slutt sier Regel 3 at kolonner i en tabell ikke kan multivalueres, noe som betyr at for en gitt enhet (rad i en tabell) kan det bare være en verdi per kolonne.
Nyt!
Peter avila
TEKNISK OPPLÆRING For SQL Server Instruktør-Grensesnitt
Phoenix,AZ
Attributter, Databaser, Enhetstyper, mini-verden, undermappe, verdier
Leave a Reply