Det er almindeligt kendt, at den bedste måde at lære noget på er at praktisere det i et virkeligt scenarie. Det samme gælder naturligvis for databasemodellering. Derfor besluttede jeg i denne artikel at lære dig, hvordan du opretter en simpel databasestruktur ved at tage et lærebogseksempel på et hotelværelsesreservationssystem. Jeg vil vise dig, hvordan du kommer i gang og give dig nogle ideer til at udvide modellen.
Databasemodellering:Discover, Discover, Discover
I denne artikel vil vi designe en datamodel for et hotelværelsesreservationssystem. Vi leder efter en datamodel, hvor vi kan repræsentere informationer om værelserne, gæsterne og de reservationer, der er booket på vores imaginære VERTABELO***** Hotel. Alle disse oplysninger vil blive gemt i tabeller.
Databasemodellering er en cyklisk opdagelsesproces. Vi identificerer først hovedtabellerne og dens attributter. I vores model er hovedtabellerne:room , guest og reservation . Derefter fortsætter vi med at forfine vores tabeller ved at finde deres attributter eller kolonner. For eksempel room tabel har attributter som:rum number , name og smoke flag blandt andre.
Reservation tabel har attributter date_in , date_out , status (annulleret, bekræftet) og made_by (online, personligt, telefon, mail), mens attributterne for tabellen guest er:first_name , last_name og member_since . Måske har du lyst til reservation bordet har brug for flere attributter (som værelsestype, antal senge), vi vil dække dette punkt senere, indtil da, overvej vores reservation tabel ufuldstændig. Følgende datamodel oprettet i Vertabelo viser hovedtabellerne.
Datatyper:Hvad er domænerne med tilladte værdier for en kolonne?
Bemærk, at hver kolonne har en datatype (varchar, heltal, dato, boolean) for at angive, hvilken slags værdier der kan tildeles til kolonnen. For eksempel kolonnen smoke på bordet room er boolesk datatype, hvilket betyder, at kun sand eller falsk er de tilladte værdier.
Primære nøgler:CPR-nummeret for hver post
Hver tabel skal have en kolonne (eller mere end én), der fungerer som en identifikator for hver post i tabellen. Denne kolonne kaldes den primære nøgle (PK), og bedste praksis for databasedesign tyder på, at hver tabel skal have en PK.
Hvis vi tager et kig på den tidligere Vertabelo-datamodel, vil vi se, at hver tabel har en kolonne kaldet id med en PK-indikator til højre. Disse id-kolonner danner PK'en (som en konvention kalder vi id PK kolonnen).
Et vigtigt koncept, måske indlysende for mange læsere, er, at en PK-kolonne ikke kan have duplikerede værdier. Med andre ord har hver PK-kolonne en unik begrænsning, og ethvert forsøg på at oprette en ny post med en duplikeret værdi vil blive afvist med en fejl af databaseadministratoren.
Fortsæt med at opdage; Find nye databaseobjekter
En reservation er et af de mere komplekse elementer at repræsentere i denne datamodel. En reservation kan have mange værelser tilknyttet (f.eks. "Jeg ønsker at reservere et dobbeltværelse og et separat værelse med 3 senge til mine børn"). Dette forretningskrav tilføjer 4 ting til vores model:
En ny tabel: Vi skal oprette en ny tabel kaldet room_reserved , hvor vi opbevarer alle rum, der hører til én reservation.
Tilføj to referencer: En reference er et meget vigtigt element i en datamodel. En reference beskriver, hvordan en tabel er relateret til en anden tabel. I vores model hører hvert reserveret værelse til én reservation, så vi vil bruge en reference til at modellere dette faktum. Denne reference er grafisk repræsenteret som en linje, der forbinder begge tabeller.
Desuden, da hver reservation tilhører én gæst, er vi nødt til at oprette en ny reference, der forbinder guest og reservation tabeller.
Flyt en kolonne: Da vi kan have flere værelser, der hører til en reservation, skal vi tillade annullering pr. individuelt værelse, derefter flytter vi attribute status fra reservation til reserved_room tabel.
Den opdaterede datamodel er vist i følgende diagram designet i Vertabelo:
Hvad sker der med de tabeller, der er forbundet med en reference?
Når vi opretter en reference mellem to tabeller, tilføjes en ny kolonne til en af tabellerne. Denne netop tilføjede kolonne kaldes en fremmednøgle og fungerer som en pegepind til den anden tabel, hvilket tillader forbindelser mellem tabeller. Tag for eksempel et kig på følgende diagrammer:
Fig. 1 Tabeller reservation og guest før og efter tilføjelse af en reference
Fortsæt med at opdage; Gå efter mere
Et punkt, der venter på at blive modelleret, er det faktum, at værelser kan bruges af nogle gæster i en periode. For at repræsentere denne forretningskendsgerning har vi tilføjet 2 tabeller:hosted_at og occupied_room .
Bemærk, at hver person, der boede på hotellet, vil have en registrering i hosted_at . Denne post vil have en reference til det værelse, han/hun besatte, og til gæsten. Det er derfor hosted_at har en dobbelt reference til guest og occupied_room .
Tabellen occupied_room vil have én post for hvert værelse, der lejes, på denne post kan vi finde felterne:check_in og check_out af typen tidsstempel, der angiver, hvornår lejen begynder og slutter. En tidsstempeldatatype gemmer et tidspunkt med vilkårlig præcision. Hvert occupied_room post vil også have en reference til det værelsesnummer, der lejes og indirekte via hosted_at til de gæster, der boede på dette værelse.
Vi tilføjede også tabellen room_type til datamodellen; tanken er at gruppere rummene efter rumkategori eller værelsestype. For eksempel kan "standard dobbeltseng", "luksus 2 dobbeltsenge" være typebeskrivelser. Vi har også en max_capacity-attribut her.
Øvelser: Databasedesign er en let at nærme sig disciplin, men det tager tid at blive fagekspert. Hvis du gør dine første trin med databasedesign, så prøv at fuldføre den aktuelle datamodel for at tillade:
- Hvis to eller flere gæster deler værelse, tillad forskellig ind- og udtjekning for hver gæst.
- I nogle tilfælde kan hoteller ændre konfigurationen af værelserne (f.eks. fra standard 1 dobbeltseng til 2 luksusdobbeltsenge). Tilføj elementerne til datamodellen, der repræsenterer disse konfigurationsændringer, og bevar historikken for hvert rum.