forståelse Database byggesten i server
hvert hus har et køkken, mindst et badeværelse og et soveværelse, en hoveddør, et VVS-system og andre ting. Disse ting kan arrangeres på forskellige måder og i forskellige tal for at producere forskellige huse. Sådan er det med databaser. Der er visse ting, som alle databaser har til fælles. I dette indlæg vil jeg introducere byggestenene, der udgør alle databaser og vise, hvordan de samles. Jeg vil også diskutere tre regler, der skal følges, når du bruger byggestenene.
materialet, der præsenteres i dette indlæg, skal være af værdi for enhver, der har nogen form for interaktion med databaser, men det er på et meget elementært niveau. For en mere omfattende diskussion af databasedesign, se min artikel, en intuitiv tilgang til databasedesign.
Mini-Verdener.
før vi kommer til byggestenene, lad os tage et øjeblik til at forstå udtrykket mini-verden, fordi det vil hjælpe os med at forstå byggestenene.
en database er en model af en mini-verden. En mini-verden kan være et medicinsk kontor, en detailvirksomhed, et bibliotek eller mange andre ting. Når vi ønsker information om mini-verdenen, vender vi os til den database, der modellerer den.
lad os sige, at du går til lægen for en aftale. Når du fortæller receptionisten, at du har en aftale, vil receptionisten forsøge at finde din aftale i modellen (databasen). Hvis modellen er blevet holdt opdateret med sin mini-verden, skal den være i stand til at bekræfte, at du har en aftale. Tilsvarende, hvis en virksomhed ønsker at vide, hvilken af deres kunder med stort volumen ikke har afgivet ordrer i de sidste 6 måneder, kan de henvende sig til modellen for deres mini-verden, hvis den er blevet holdt opdateret med den mini-verden.
en mini-verden kan være en hel virksomhed, eller det kan være en del af en virksomhed, såsom en bankfilial eller salgsafdelingen.
det første, en databasedesigner gør, er at forstå mini-verdenen, fordi designerens job er at designe en model af den mini-verden. Og for at forstå mini-verden, designeren starter med at identificere de byggesten, der vil gå ind i at samle en database.
Byggestenene
1. Enheder
en enhed er noget, der findes i mini-verdenen, og som har egenskaber, der er af interesse for os. For eksempel, i en skole tilmelding mini-verden, der er studerende enheder, kursus enheder, instruktør enheder, og andre. Studerende har navne, adresser, GPA ‘ er og andre egenskaber, der interesserer os. Kurser har titler, kreditter, gebyrer og andre. Og instruktører har navne, adresser, kvalifikationer og andre. Enheder er unikke. Hver elev er en unik enhed; der er John og Mary og så videre. Hvert kursus er en unik enhed, og hver instruktør er en unik enhed.
enheder behøver ikke at være fysiske ting. Selvom du ikke kan røre ved, se, eller lugte en tilmelding, det findes ikke desto mindre i mini-verdenen til skoletilmelding og har egenskaber, der er af interesse for os, såsom datoen for tilmeldingen, den studerende, der tilmeldte sig, det kursus, den studerende tilmeldte sig, og den endelige karakter modtaget. Salg er andre eksempler på enheder, der ikke har en fysisk komponent, men som har karakteristika af interesse for os (salgsdato, kunde, sælger, ordretotal, forsendelsesmetode, betalingsbetingelser osv.).
2. Enhedstyper
enheder af samme type tilhører en enhedstype. En enhedstype er et sæt enheder af den type. Den studerendes enhedstype er sættet af alle studerende. Kursusenhedstypen er sæt af alle kurser, og Instruktørenhedstypen er sæt af alle instruktører.
enhedstyper er det vigtigste koncept i dette indlæg. De bliver tabeller i en database.
3. Attributter
attributterne for en enhed er karakteristika for den enhed, der er af interesse for os. Som allerede nævnt omfatter elevernes attributter navn, adresse, GPA og andre. Kurser har Navne, kreditter, afdelinger, de tilhører, og andre. Og så videre med andre enhedstyper.
montering af byggestenene
Hvordan er disse byggesten repræsenteret i databasen? Hver enhedstype er repræsenteret af en tabel i databasen. I denne tabel er de enkelte rækker de unikke enheder, og kolonnerne er attributterne. Her er et eksempel på en tabel, der repræsenterer kreditkortenhedstypen:
regler for byggesten
når du arbejder med byggesten, er det vigtigt at følge visse regler, der ikke kun gør det lettere at arbejde med databaseobjekter, men også forhindre dataanomalier (dataanomalier er uden for rammerne af dette indlæg, men diskuteres detaljeret i min artikel, en intuitiv tilgang til databasedesign).
regel 1: hver tabel skal repræsentere en og kun en enhedstype.
databasen over skolens tilmelding mini-verden, ovenfor, har brug for følgende tabeller: Studerende, kursus, instruktør, tilmelding og andre, en for hver enhedstype identificeret i den mini-verden. Databasen for det medicinske kontor mini-verden har brug for et Lægebord, et Patientbord, et Aftalebord, et Medicinbord og andre. En tabel for hver enhedstype.
der er en undtagelse fra denne regel. Gør dig klar, her kommer hjernevrideren: Hvis to enhedstyper deler de samme attributter, og en enhed i en af enhedstyperne også er en enhed i den anden Enhedstype (en enhed er medlem af begge enhedstyper), kan de to enhedstyper repræsenteres i en tabel. Her er det igen: en Professorenhedstype og en Rådgiverenhedstype kan begge repræsenteres i en tabel, fordi rådgivere også er professorer, og de har de samme egenskaber (professor/rådgivernavn, professor/rådgiverkvalifikationer og andre). Og igen: En Mappeenhedstype og en undermappeenhedstype kan begge repræsenteres i en tabel, fordi alle undermappeenheder også er Mappeenheder, og de deler de samme attributter (mappetitel, mappestørrelse, antal elementer i mappen, overordnet mappe og andre). Bare en mere: medarbejder-og Manager-enhedstyperne kan begge repræsenteres i samme tabel, fordi medarbejdere og manager-enheder har de samme attributter, og manager-enheder også er medarbejderenheder. Denne undtagelse fra reglen undersøges nærmere i en anden blog:.
Bemærk forresten, at denne regel er grunden til, at den rigtige måde at navngive en tabel på er i entallet. Tabeller repræsenterer en enkelt Enhedstype.
regel 2: alle kolonner skal være atomare.
har du nogensinde spekuleret på, hvorfor databasetabeller muligvis har kolonner til by og stat, men kun en kolonne til adressen? Måske har du spekuleret på, hvorfor der ikke er en kolonne til Adressenummer, en anden til Adressegadetype (Blvd., Avenue osv.), en anden for lejlighed nummer, og så videre. Hvorfor er disse kolonner normalt alle klumpet sammen i en enkelt Adressekolonne? Svaret på alle disse spørgsmål ligger i en forståelse af atomicitet.
når vi siger, at en søjle er atomisk, mener vi, at den ikke kan opdeles yderligere og stadig bevare mening. Lad os lave en kolonne og kalde den Megaadresse, der indeholder en adresse sammen med by og stat.
men fordi vi gør søgninger, sorterer og andre operationer på dele af denne kolonne (Søg efter by, sortere efter stat, udskrive bare adressen del, og så videre), kan vi sige, at underafdelinger af denne kolonne har deres egen betydning (Gadeadresse, By og stat). Så MegaAddress er ikke atomisk. Et bedre bord ville være:
nu, hvad med streetaddress kolonne? Skal vi opdele det længere ned i StreetNumber, StreetName og StreetType? Så længe vi ikke gør noget væsentligt med underopdelinger af det—hvis vi ikke sorterer på gadenumre, søger efter alle veje eller veje osv.—så er kolonnen atomisk som den er. Men hvis vi gør disse ting, så er kolonnen ikke atomisk, og så skal vi opdele det som beskrevet.
regel 3: kolonner kan ikke multivalueres.
nogle enhedstyper indeholder attributter med flere værdier eller en attribut, der kan have mere end en værdi. I et Kursusbord kan der være en attribut kaldet forudsætninger. Da en kursusenhed kan have mere end en forudsætning, er Forudsætningsattributten en attribut med flere værdier. Når vi opretter en tabel til Kursusenhedstypen, kan vi ikke repræsentere Forudsætningsattributten som en kolonne i tabellen. For korrekt at repræsentere en attribut med flere værdier skal vi oprette en anden tabel til den og relatere den til den originale tabel ved hjælp af et en-til-mange-forhold (forhold diskuteres detaljeret i de kurser, jeg underviser på Interface Tachnical Training KVL100: Introduktion til Transact og 250: Transact for udviklere og i min artikel en intuitiv tilgang til databasedesign). Andre eksempler på attributter med flere værdier inkluderer en medarbejders pårørende, en læges kvalifikationer og så videre.
regel 3 siger, at der for en given enhed (række i en tabel) kun kan være en værdi i hver kolonne.
Resume
dette indlæg introducerede begrebet mini-verden som de aspekter af en virksomhed eller et andet miljø, som en database modellerer. Posten beskrev også en databasetabel som repræsenterer en enkelt Enhedstype, hvor rækkerne indeholder de enkelte enheder af samme type, og kolonnerne repræsenterer attributterne for disse enheder. Der blev indført tre regler for tabeller. Regel 1 angiver, at en tabel skal repræsentere en enkelt Enhedstype. Undtagelsen fra reglen er, når to enhedstyper deler de samme attributter, og enheder i en enhedstype er medlemmer af den anden Enhedstype. I så fald kan begge enhedstyper repræsenteres i samme tabel. Regel 2 siger, at alle kolonner i en tabel skal være atomare, hvilket betyder, at en kolonne ikke kan opdeles og stadig bevarer mening i mini-verden. Endelig angiver regel 3, at kolonner i en tabel ikke kan multivalueres, hvilket betyder, at der for en given enhed (række i en tabel) kun kan være en værdi pr.kolonne.
god fornøjelse!
Peter Avila
teknisk træning
Phøniks, det
attributter, databaser, enhedstyper, mini – verden, undermappe, værdier
Leave a Reply