En god datamodelleringsøvelse for begyndere er at oprette en datamodel af en onlinebutik . Hver gang jeg giver denne øvelse til mine elever, bliver jeg overrasket over, hvor svært det er for dem.
Find koncepterne...
Lad os se, hvordan det kan gøres. Vi ved, at vi skal lave en tabel for hvert koncept i domænet. Tænk på navneordene og navneord du ville bruge til at beskrive domænet. Alle navneord er groft sagt enten et begreb, en egenskab ved et begreb eller et eksempel . Hvad er de grundlæggende begreber i en netbutik? To ord dukker straks op:
- kunder – folk, der køber ting i vores butik, og
- produkter – varer folk køber i vores butik.
Hver kunde har et grundlæggende sæt data, der beskriver dem:id (du skal normalt bruge en id-attribut i din tabel), navn, e-mail og adgangskode. På samme måde har et produkt et id og et navn. Vi kunne tilføje flere attributter for kunder og produkter, men af hensyn til dette eksempel, vil disse gøre det. Vi tilføjer de to tabeller i vores model.
... Samt de abstrakte begreber
Dette er en butik, så selvfølgelig vil vi gerne vide hvad blev bestilt og af hvem . "Order" er et nøgleord i de fleste databaser, så vi bør ikke bruge det til et tabelnavn. I stedet bruger vi navnet purchase til det tredje bord i vores model. Tabellen skal på en eller anden måde være forbundet med customer og til product . Til at begynde med, lad os bare tegne en reference mellem purchase og customer , og mellem purchase og product .
customer-purchase reference er OK. Hvert køb foretages af én kunde; hver kunde kan foretage flere køb. Denne reference er kommet for at blive.
Der er dog noget galt med purchase-product reference. Der kan købes flere produkter i ét køb; flere køb kan omfatte det samme produkt. Men vores reference tillader kun at købe ét produkt i et enkelt køb. Lad os slette referencen og overveje en anden måde at modellere den på.
Et stort tekstfelt til alle købte produkter?
Hvad med at tilføje et stort tekstfelt, der kan gemme navne eller id'er på købte produkter? Nu kan vi købe flere produkter i et køb. Der er dog nogle problemer her:
- For det første er det vanskeligt at kontrollere, at produktet i
purchased_itemsfeltet er virkelig i databasen. - For det andet, hvis du vil ændre navnet på produktet (fordi du har stavet det forkert), skal du opdatere alle
purchased_itemsfeltforekomster ipurchasetabel. - Til sidst er det svært at analysere data i databasen. Hvis du for eksempel vil finde ud af, hvilket produkt der købes oftest, skal du bruge en tekst-understrengsoperation. Og det er aldrig særlig effektivt.
Flere produktkolonner i købstabellen?
Hvad er nogle andre muligheder? Vi ønsker, at et køb skal være forbundet med flere produkter, så måske skal vi tilføje flere purchase_item kolonner i en købstabel? Nå, det er kedeligt (jeg tilføjede kun 5 kolonner og blev træt) og skaber en kunstig og dum begrænsning på antallet af købte produkter.
Brug en mellemtabel!
Den fjollede løsning antyder den rigtige løsning. Vi ønsker at have en ubegrænset antal produkter forbundet med købet. Den eneste måde er at have en mellemliggende forbindelsestabel . Lad os kalde det purchase_item . purchase_item tabellen er forbundet med purchase og product . Nu kan et køb omfatte så mange produkter, som vi ønsker. Som en bonus kan vi tilføje yderligere data i tabellen:antal gange købt, samlet pris for denne vare, og så videre.
Konklusioner:
- Tabeller i modellen kan ikke kun repræsentere fysiske objekter som kunde eller produkt. Tabeller kan repræsentere mere abstrakte begreber som et køb. Andre eksempler kan være en reservation i et hotelreservationssystem, et book_loan i en model til bibliotek, en aftale i et system for læger osv.
- Når du modellerer en transaktion (dvs. køber eller sælger mange ting), har du normalt brug for tre borde :én for transaktionen (køb eller reservation i et hotelreservationssystem), én for ting købt/solgt i en transaktion (produkt, hotelværelse) og én for transaktionsvarer (købsvare, reservationsvare). Du kan tilføje yderligere oplysninger i den mellemliggende tabel, hvis du har brug for det.
Opret din egen butiksdatabasemodel med Vertabelo!