database Building Blocks in SQL Server

Like This Blog 3

toegevoegd door Peter Avila November 21, 2012

elk huis heeft een keuken, ten minste een badkamer en een slaapkamer, een voordeur, een sanitair systeem, en andere dingen. Deze dingen kunnen op verschillende manieren en in verschillende aantallen worden gerangschikt om verschillende huizen te produceren. Zo is het ook met databases. Er zijn bepaalde dingen die alle databases gemeen hebben. In deze post, Zal ik de bouwstenen die deel uitmaken van alle databases te introduceren en laten zien hoe ze zijn samengesteld. Ik zal ook drie regels bespreken die moeten worden gevolgd bij het gebruik van de bouwstenen.

het materiaal dat in dit artikel wordt gepresenteerd, moet van waarde zijn voor iedereen die enige vorm van interactie met databases heeft, maar het is op een zeer elementair niveau. Voor een meer uitgebreide discussie over database design, zie mijn artikel, een intuïtieve benadering van Database Design.

Mini-Werelden.

voordat we bij de bouwstenen komen, nemen we even de tijd om de term mini-wereld te begrijpen, omdat het ons zal helpen de bouwstenen te begrijpen.

een database is een model van een mini-wereld. Een mini-wereld kan een medisch kantoor, een retail bedrijf, een bibliotheek, of vele andere dingen. Als we informatie willen over de mini-wereld, wenden we ons tot de database die het modelleert.

stel dat u naar de dokter gaat voor een afspraak. Wanneer u de receptioniste vertelt dat u een afspraak heeft, zal de receptioniste proberen uw afspraak te vinden in het model (de database). Als het model actueel is gehouden met zijn mini-wereld, moet het in staat zijn om te bevestigen dat u een afspraak heeft. Evenzo, als een bedrijf wil weten welke van hun grote-volume klanten hebben geen bestellingen geplaatst in de afgelopen 6 maanden, kunnen ze zich wenden tot het model van hun mini-wereld als het is actueel gehouden met die mini-wereld.

een mini-wereld kan een volledig bedrijf zijn, of het kan een onderdeel zijn van een bedrijf, zoals een bankfiliaal of de verkoopafdeling.

het eerste wat een Databaseontwerper doet is de mini-wereld begrijpen, omdat het de taak van de ontwerper is om een model van die mini-wereld te ontwerpen. En om de mini-wereld te begrijpen, begint de ontwerper met het identificeren van de bouwstenen die gaan in het samenstellen van een database.

De Bouwstenen

1. Entiteiten

een entiteit is iets dat bestaat in de mini-wereld en dat kenmerken heeft die voor ons van belang zijn. Bijvoorbeeld, in een school inschrijving mini-wereld, zijn er student entiteiten, cursus entiteiten, instructeur entiteiten, en anderen. Studenten hebben namen, adressen, GPA ‘ s en andere kenmerken die ons interesseren. Cursussen hebben titels, credits, Vergoedingen, en anderen. En instructeurs hebben namen, adressen, kwalificaties, en anderen. Entiteiten zijn uniek. Elke student is een unieke entiteit; er is John en Mary en ga zo maar door. Elke cursus is een unieke entiteit en elke instructeur is een unieke entiteit.

entiteiten hoeven geen fysieke dingen te zijn. Hoewel je een inschrijving niet kunt aanraken, zien of ruiken, bestaat het toch in de school inschrijving mini-wereld en heeft kenmerken die van belang zijn voor ons, zoals de datum van de inschrijving, de student die zich heeft ingeschreven, de cursus de student ingeschreven in, en het laatste cijfer ontvangen. Sales zijn andere voorbeelden van entiteiten die geen fysieke component hebben, maar die kenmerken hebben die voor ons van belang zijn (verkoopdatum, Klant, Verkoper, ordertotaal, wijze van verzending, betalingsvoorwaarden, enz.).

2. Entiteit-Types

entiteiten van hetzelfde type behoren tot één entiteit-type. Een entiteit-type is een verzameling van entiteiten van dat type. De student entity-type is de set van alle studenten. De cursus entity-type is de set van alle cursussen, en de instructeur entity-type is de set van alle instructeurs.

entiteitstypen zijn het belangrijkste begrip in deze post. Ze worden tabellen in een database.

3. Attributen

de attributen van een entiteit zijn de kenmerken van die entiteit die voor ons van belang zijn. Zoals reeds vermeld, studenten’ attributen omvatten naam, adres, GPA, en anderen. Cursussen hebben namen, credits, afdelingen waartoe ze behoren, en anderen. En zo verder met andere entiteiten-types.

assemblage van de bouwstenen

Hoe worden deze bouwstenen weergegeven in de database? Elk entiteitstype wordt weergegeven door een tabel in de database. In die tabel zijn de afzonderlijke rijen de unieke entiteiten en de kolommen de attributen. Hier is een voorbeeld van een tabel die het Kredietkaartentiteitstype weergeeft:

Bouwsteenregels

bij het werken met bouwstenen is het belangrijk om bepaalde regels te volgen die het niet alleen gemakkelijker maken om met databaseobjecten te werken, maar ook gegevensafwijkingen voorkomen (gegevensafwijkingen vallen buiten het bereik van dit bericht, maar worden in detail besproken in mijn artikel, een intuïtieve benadering van databaseontwerp).

Regel 1: elke tabel moet één en slechts één entiteitstype vertegenwoordigen.

de database van de mini-world heeft de volgende tabellen nodig:: Student, cursus, instructeur, inschrijving en anderen, een voor elke entiteit-type geïdentificeerd in die mini-wereld. De database van het medisch kantoor mini-world heeft een Dokterstafel, een Patiëntentafel, een Afsprakentafel, een Medicijnentafel en anderen nodig. Eén tabel voor elk entiteitstype.

er is een uitzondering op deze regel. Maak je klaar, hier komt de brain twister: Als twee entiteitstypen dezelfde kenmerken delen en een entiteit in een van de entiteitstypen ook een entiteit in het andere entiteitstype is (één entiteit is lid van beide entiteitstypen), kunnen de twee entiteitstypen in één tabel worden weergegeven. Hier is het weer: een Professor entity-type en een adviseur entity-type kunnen beide in één tabel worden weergegeven, omdat adviseurs ook professoren zijn en dezelfde attributen hebben (professor/adviseur naam, professor/adviseur kwalificaties, en anderen). En opnieuw: Een mapentiteitstype en een submap-entiteitstype kunnen beide in één tabel worden weergegeven, omdat alle submap-entiteiten ook Mapentiteiten zijn en dezelfde attributen delen (maptitel, mapgrootte, aantal items in de map, bovenliggende map en andere). Nog één: de Employee en Manager entity-types kunnen beide in dezelfde tabel worden weergegeven, omdat werknemers en manager entiteiten dezelfde attributen hebben en manager entiteiten zijn ook werknemer entiteiten. Deze uitzondering op de regel wordt nader onderzocht in een andere blog: SQL Server – De Self Join Query.

tussen haakjes, merk op dat deze regel de reden is waarom de juiste manier om een tabel een naam te geven in het enkelvoud is. Tabellen vertegenwoordigen een enkel entiteitstype.

regel 2: alle kolommen moeten atomisch zijn.

heeft u zich ooit afgevraagd waarom databasetabellen kolommen voor stad en staat hebben, maar slechts één kolom voor het adres? Misschien heb je je afgevraagd waarom er geen kolom is voor het adresnummer, een andere voor het adres Straattype (Blvd., Avenue, enz.), andere voor appartement nummer, en ga zo maar door. Waarom worden deze kolommen meestal allemaal samengevoegd in een enkele Adreskolom? Het antwoord op al deze vragen ligt in het begrijpen van atomiciteit.

wanneer we zeggen dat een kolom atomisch is, bedoelen we dat hij niet verder kan worden onderverdeeld en nog steeds betekenis behoudt. Laten we een column maken en het Megadress noemen dat een straatadres bevat samen met stad en staat.

maar omdat we zoeken, sorteren en andere bewerkingen uitvoeren op Delen van die kolom (zoeken op stad, Sorteren op staat, printen alleen het straatadres deel, enzovoort), kunnen we zeggen dat onderverdelingen van die kolom hun eigen betekenis hebben (straatadres, stad en staat). Megadress is dus niet atomisch. Een betere tafel zou zijn:

nu, hoe zit het met de kolom StreetAddress? Moeten we dat verder onderverdelen in straatnummer, straatnaam en StreetType? Zolang we niets belangrijks doen met onderverdelingen ervan – als we niet Sorteren op straatnummers, zoeken naar alle wegen of lanen, enzovoort—dan is de kolom atomisch zoals het is. Maar als we die dingen doen, dan is de kolom niet atomair en dan, ja, moeten we het onderverdelen zoals beschreven.

regel 3: kolommen kunnen niet meervoudig worden gebruikt.

sommige entiteitstypen bevatten attributen met meerdere waarden, of een attribuut dat meer dan één waarde kan hebben. In een Cursustabel, kan er een attribuut genaamd Prerequisites. Omdat een cursusentiteit meer dan één voorwaarde kan hebben, is het attribuut Prerequisite een attribuut met meerdere waarden. Wanneer we een tabel maken voor het type cursusentiteit, zullen we niet in staat zijn om het vereiste attribuut als een kolom in de tabel weer te geven. Om een kenmerk met meerdere waarden goed weer te geven, moeten we er een andere tabel voor maken en deze relateren aan de oorspronkelijke tabel met behulp van een één-op-veel relatie (relaties worden in detail besproken in de cursussen die ik geef op Interface Tachnical Training SQL100: Inleiding tot Transact-SQL en SQL250: Transact-SQL voor ontwikkelaars en in mijn artikel, een intuïtieve benadering van Database Design). Andere voorbeelden van multivalued attributen zijn de afhankelijke personen van een werknemer, de kwalificaties van een arts, enzovoort.

regel 3 zegt dat Voor een bepaalde entiteit (rij in een tabel) er slechts één waarde in elke kolom kan zijn.

samenvatting

deze post introduceerde het concept van de mini-wereld als de aspecten van een bedrijf of een andere omgeving die een database modelleert. De post beschreef ook een databasetabel als zijnde een enkel entiteitstype waarin de rijen de afzonderlijke entiteiten van hetzelfde type bevatten en de kolommen de attributen van die entiteiten vertegenwoordigen. Er zijn drie regels voor tabellen ingevoerd. Regel 1 bepaalt dat een tabel één entiteit-type moet vertegenwoordigen. De uitzondering op de regel is wanneer twee entiteitstypen dezelfde kenmerken delen en entiteiten in het ene entiteitstype lid zijn van het andere entiteitstype. In dat geval kunnen beide entiteitstypen in dezelfde tabel worden weergegeven. Regel 2 stelt dat alle kolommen van een tabel atomair moeten zijn, wat betekent dat een kolom niet kan worden onderverdeeld en nog steeds betekenis behouden in de mini-wereld. Ten slotte bepaalt regel 3 dat kolommen in een tabel niet multivalued kunnen worden, wat betekent dat er voor een bepaalde entiteit (rij in een tabel) slechts één waarde per kolom kan zijn.

Enjoy!

Peter Avila

SQL Server Instructor-Interface Technical Training

Phoenix, AZ