Databaseontwerp voor e-commerce: ER-diagram voor online winkelen (2023)

Als u een ER -diagram nodig hebt voor een online winkelsysteem, zoek dan niet verder.In dit artikel krijgt u een compleet databasemodel voor online winkelen en stapsgewijze instructies over hoe u het kunt maken.We zullen ook praten over enkele ideeën om het model uit te breiden.

Een ER-diagram is een model voor het bouwen van de basis van elke toepassing die informatie gebruikt die is opgeslagen in databases. Datamodelleurs gebruiken ER-diagrammen zoals architecten hun tekentafels gebruiken: op een leeg canvas leggen ze de elementen neer die de structuur zullen vormen van wat ze gaan bouwen. Uiteindelijk is dit ontwerp klaar om het eindproduct te worden, in het geval van de architect een huis of gebouw. in het geval van de dataconfigurator, een database. Als u niet bekend bent met het werk van een datamodelleur, kunt u er een idee van krijgen door erover te lezenBasics voor gegevensmodellering in 10 minuten.

Elke toepassing die een database gebruikt, moet in de ontwerpdocumentatie een ER-diagram hebben dat de structuur van de opgeslagen gegevens weerspiegelt. Als uw app standaardfuncties biedt, b.v. een app voor het boeken van tickets of online bankieren, u hoeft uw ER-diagram niet vanaf een leeg canvas te maken. Er zijn kant-en-klare ER-diagramsjablonen die aan de meeste van uw behoeften voldoen. Je zult veel middelen vindendeze verzameling voorbeelden van ER-diagrammen.

Online winkelapps worden ook geleverd met redelijk standaardfuncties, zodat u tal van voorbeelden kunt vinden van online winkelen -ER -diagrammen die voldoen aan basisbehoeften.In dit artikel bieden we u een online shopping-ER-diagram dat u kunt gebruiken om te integreren als onderdeel van een e-commerce-applicatie met standaard online winkelfunctionaliteit.Misschien wilt u basisinformatie over lezenwat is een er-diagramWees klaar voor de volgende.

Welke voorwaarden moet een online winkelen -ER -diagram voldoen?

Een databasemodel voor een online winkelsysteem moet informatie kunnen opslaan over klanten die zich op de website registreren en bestellingen plaatsen. Ze moeten ook informatie opslaan over de producten die te koop zijn, met vermelding van de prijs en voorraadgegevens voor elk product. Klanten moeten een winkelwagentje kunnen hebben om de producten die ze uit de catalogus selecteren op te slaan voordat de klant klaar is om zijn bestelling te plaatsen. Elke klant zou op zijn beurt een verlanglijst (dwz een lijst met producten die hij zou willen kopen) moeten kunnen bijhouden zonder deze al in een winkelwagentje te hebben geplaatst. Wanneer de klant een bestelling bevestigt, moet het datamodel zowel de bestelgegevens als de betalings- en verzendinformatie kunnen vastleggen.

Als raamwerk moet het ER-diagram voor een online winkelsysteem worden gestandaardiseerd doorDerde normale vorm.De reden hiervoor is dat het online winkelsysteem puur transactioneel is en daarom continue en gelijktijdige updates moet ondersteunen voor de tabellen die het schema vormen.En u moet deze updates ondersteunen door gegevensintegriteit en consistentie strikt te handhaven.

Vervolgens bekijken we stap voor stap het maken van een ER-diagram voor een online winkelsysteem, waarbij we op elk moment de ontwerpbeslissingen analyseren die de ontwikkeling ervan sturen. Je moet er aan wennende taken van een database-ontwerperweten hoe u het project van het ontwerpen van een ER-diagram voor online winkelen moet uitvoeren. Het proces begint met het schetsen van een conceptueel model, het vervolgens omzetten naar een logisch model en ten slotte naar het fysieke model. Ik stel voor dat je het leestconceptuele, logische en fysieke datamodellenvoor meer informatie over de respectievelijke specificaties.

Stap 1: Maak een conceptueel gegevensmodel voor online winkelen

Om een conceptueel databasemodel voor een elektronisch inkoopsysteem te schetsen, moeten eerst de entiteiten die betrokken zijn bij het systeem en hun kenmerken worden geïdentificeerd.De volgende entiteiten zijn te vinden in de overgrote meerderheid van online winkelgegevensmodellen:

• Klant: Deze entiteit vertegenwoordigt klanten die een account aanmaken om bestellingen te plaatsen op het online winkelplatform.
• Product: Vertegenwoordigt alle producten die beschikbaar zijn voor aankoop op het platform.
• Categorie: Categorieën waarin de producten zijn gegroepeerd.
• mandate: Productbestellingen van klanten.
• Artikel besteld: Elk item dat deel uitmaakt van een bestelling.
• Betaling: De betaling van de klant nadat de bestelling is voltooid.
• Relais- Verzendinformatie met betrekking tot een bestelling, inclusief verzendadres en trackinginformatie.
• Dit: De virtuele winkelwagentje van de klant, waar producten worden opgeslagen voordat ze worden gekocht en deel uitmaken van een bestelling.
• Wensenlijst: Slaat de items op die door de klant zijn geselecteerd voor mogelijke toekomstige aankopen.

Om onze ERD voor een online winkelplatform in Vertabelo te maken, kunnen we beginnen met het tekenen van de entiteiten zonder relaties of attributen.

De relaties tussen de entiteiten zijn als volgt:

• Een klant kan meerdere bestellingen plaatsen.Dus tussenKlantimandaatEr moet een één-op-veel-relatie zijn.
• Een bestelling kan een of meer artikelen bevatten, die elk een enkel product vertegenwoordigen.Artikel besteldhet is een afhankelijke entiteitmandaat, aangezien het geen bestaansrecht heeft als er geen orde is. Naast,Artikel besteldverwantProductdoor een een-op-veel-relatie: elkArtikel besteldis gerelateerd aan eenProduct, en eenProducthet kan op veel dingen betrekking hebbenArtikel besteld
• Een bestelling wordt geassocieerd met een betaling en een levering, maar elke betaling en levering kunnen meerdere bestellingen dekken.Daarom zijn er een-op-veel-relaties tussen henBetaling imandaaten tussendoorRelaisimandaat.
• Een product kan maar tot één categorie behoren: er is een één-op-veel-relatie tussenProduct iCategorie.
• Winkelwagen en Verlanglijst zijn afhankelijke entiteiten vanKlant, Om deze redenDitiWensenlijstEen afhankelijkheidsrelatie onderhouden metKlant. In ruil daarvoor, elk exemplaar vanDiten vanWensenlijstverwijst naar een product, dus beide entiteiten hebben een veel-op-één relatieProduct.

Na het identificeren van alle entiteiten waaruit ons model bestaat en de onderlinge relaties, kunnen we het conceptuele model ontwerpen. Om dit te doen, nemen we het bovenstaande ER-diagram en verbinden we de entiteiten met de juiste relatietypen, zoals hierboven uitgelegd.

Door de relaties aan ons ER -diagram toe te voegen, hebben we een conceptueel model dat we kunnen gebruiken als blauwdruk om te bespreken met de rest van het softwareontwikkelingsteam.

Het tot nu toe gecreëerde conceptuele model is handig voor het tonen van belanghebbenden van het project en hun initiële validatie.Het is handig voor dit projectGebruik tekstannotaties bij gegevensmodellering.

Stap 2: Maak het logische model

Laten we doorgaan met het ER-diagram voor online winkelen. Nadat we de entiteiten waaruit het bestaat hebben geïdentificeerd en het conceptuele model hebben geschetst, moeten we de attributen definiëren waaruit elke entiteit bestaat. Zodra we de attributen hebben toegevoegd, hebben we een compleet logisch diagram.

Het is belangrijk om te benadrukken dat alle entiteiten een primaire identificatie moeten hebben, zodat ze later kunnen (in het fysieke model)Alle tabellen hebben een primaire sleutel.Ik stel voor dat je het leestWat is primaire sleutelAls dit nog niet bekend is.

Voor dit model is een belangrijke beslissing die het ontwerp bepaalt, dat elke entiteit een primaire back-upsleutel heeft. De reden voor het gebruik van back-upsleutels is dat de eisen in transactiesystemen, zoals B. elektronische inkoopsystemen, in de loop van de tijd nogal kunnen veranderen. Dus het hebben van een surrogaatsleutel voor alle tabellen kan ons in de toekomst hoofdpijn besparen. bijvoorbeeld bijProduct Tafel,item nummerHet zou een natuurlijke sleutel kunnen zijn, waardoor het niet nodig zou zijn om een ​​surrogaatsleutel voor de tabel te maken. Het kan echter gebeuren dat er nog een attribuut aan deze tabel wordt toegevoegd:Borg, en dezelfde SKU kan worden herhaald voor verschillende winkels. Dit zou de natuurlijke sleutel wordenitem nummer+Borg, wat ons in een echte nachtmerrie voor het herontwerpen van de database zou brengen.

In elk geval is de naam van het attribuut dat fungeert als de primaire identifier de naam van de array gevolgd door_ID-KAART; Dit handhaaft een consistente nomenclatuur. Er zijn andere naamgevingsconventies die ik voor deze lay-out heb overgenomen (bijvoorbeeld door samengestelde namen te gebruiken, gescheiden door "_') die naar goeddunken van de ontwerper kunnen worden gewijzigd. Het maakt niet uit welkenaamgevingis geselecteerd.Het is belangrijk om er een te hebben en het altijd te onderhouden.

Laten we eens kijken hoe entiteiten eruit zien met hun attributen.In de volgende lijsten beschrijf ik alleen de attributen van elke entiteit zonder hun buitenlandse sleutels of afhankelijkheidssleutels.Zowel buitenlandse sleutels als afhankelijkheidssleutels worden automatisch weergegeven wanneer u het fysieke model exporteert.

Merk ook op dat dit een lijst is met de basiskenmerken van elke entiteit. Om uw eigen ER-diagram voor online winkelen te maken, kunt u zoveel functies toevoegen als u nodig acht.

entiteit constructie

Laten we hiermee beginnenKlantJuridische entiteit.We stellen attributen in voor de eerste en achternaam, e -mailadres, postadres en telefoonnummer van de klant.

DitiWensenlijstzijn entiteiten die afhankelijk zijnKlant.DitBevat elk product dat aan de kar en de hoeveelheid van het product is toegevoegd.Opgemerkt moet worden dat ik het product niet opneem of attributen die buitenlandse toetsen vertegenwoordigen (leesLees dit artikel voor meer informatie over vreemde sleutels) In deze lijst.Dit komt omdat ze aan het model worden toegevoegd wanneer het wordt omgezet in een fysiek ER -diagram.

Wensenlijsthet bevat alleen een lijst met producten. Volgens dezelfde redenering als hierboven, heb ik het product niet als een kenmerk opgenomen. Het verschijnt automatisch wanneer we het fysieke diagram maken.

De volgende entiteit isProduct, met attributen om op te slaanitem nummer,,Beschrijving,prijsideelVoor elk product.

IsCategorieDe entiteit is heel eenvoudig.Het enige kenmerk dat u nodig heeft (naast de Surrogate -toets) is de categorienaam.

IsmandaatHet bedrijf slaat de datum van elke bestelling en de totale prijs op.

Uw dochteronderneming,Artikel besteld, slaat de hoeveelheid en prijs op van elk artikel in een bestelling.

IsBetalingHet bedrijf slaat de betalingsdatum, de betaalmethode en het betaalde bedrag op.

En tenslotte,Relaisslaat verzenddatum, adres, stad, staat, land en postcode op.

Nadat we de attributen aan de entiteiten hebben toegevoegd, is het logische model voltooid.

Na het toevoegen van de features is het logische model compleet.

Mogelijke verbeteringen van erd online winkelen

Er zijn verschillende verbeteringen die we aan deze figuur zouden kunnen aanbrengen, maar we laten ze weg om te voorkomen dat het model te ingewikkeld wordt. In plaats van het wachtwoord op te slaan bij de klantgegevens, kunnen we bijvoorbeeld een subschema voor gebruikersauthenticatie toevoegen dat hierop volgtBest practices voor een gebruikersauthenticatiemodule.

Een andere mogelijke verbetering zou zijn om de voorraad- en prijsgegevens te scheiden van de productinformatie zelf, aangezien deze gegevens kunnen variëren afhankelijk van verschillende factoren (bijv. geografische locatie van de klant, voorraadbewegingen in inkomende en uitgaande operaties, etc. .etc.). Om meer functionaliteit aan het datamodel toe te voegen, zou het wenselijk zijn om de voorraad en prijs van elk product uit andere tabellen te halen. Maar voor de eenvoud laten we ze bij de productkenmerken.

Stap 3 - Maak het fysieke model

Zodra we het logische model hebben afgerond en gevalideerd door belanghebbenden, kunnen we het omzetten in een fysiek model. We hoeven het alleen maar te vragenVerticaalMaak het fysieke model van het logische model. Maar voordat je dat doet, raad ik je aan om ze te lezen8 dingen om te overwegen bij het bouwen van een fysiek datamodel.

Om het fysieke model te maken, vereist Vertabelo dat we het relationele databasebeheersysteem (RDBMS) kiezen om onze database te implementeren.Om dit te doen, biedt het ons een lijst met opties met de meest populaire databasemotoren.De keuze van RDBM's bepaalt enkele eigenschappen van het fysieke model die kunnen variëren van motor tot motor, b.v.het gegevenstype toegewezen aan elk kenmerk.

Voor dit voorbeeld kiezen we MySQL 8.x als doel-RDBMS. Zoals we in het onderstaande voorbeeld kunnen zien, werden bij het converteren van het fysieke model externe sleutelkolommen toegevoegd aan de juiste tabellen. Deze worden gemaakt door de relaties die we definiëren in het logische model.

Het fysieke model voegt de kolommen toe waaruit de externe sleutels en afhankelijkheidssleutels bestaan.

Laten we ze onderzoekenWensenlijsttafel als voorbeeld. In het logische model is dat deWensenlijstDe entiteit had alleen het kenmerkverlanglijst_id, die werd gebruikt als de primaire sleutel.Bij het converteren naar een tabel in het fysieke model verschijnen er nog twee kolommen:Customer_customer_idiProduct_id_product. Deze twee kolommen zijn vreemde sleutels voor deKlantiProductTabellen of

Nu hoef je alleen maar Vertabelo te vragen om het SQL-script te genereren. We voeren het uit op het RDBMS en laten de database gereed om verbinding te maken met de applicatie en informatie op te halen.

Een opmerkelijk aspect van het afgeleide fysieke model is dat afhankelijke entiteiten:Dit,Wensenlijst, iArtikel besteld- Heb een primaire sleutel die bestaat uit twee attributen.De ene is een surrogaatsleutel (elke identificatie) en de andere is een buitenlandse sleutel ten opzichte van de primaire sleutel van de entiteit waar het van afhangt.Dit is duidelijker te zien in het automatisch gegenereerde script.Laten we bijvoorbeeld eens kijken naar de DDL -code die door Vertabelo is gemaakt om dit te doenDitTafel:

-- Tabel: CartCREATE TABLE Cart (cart_id int NOT NULL, kwantiteit int NOT NULL,Customer_customer_id int NOT NULL,Product_product_id int NOT NULL,CONSTRAINT Cart_pk PRIMAIRE SLEUTEL (cart_cus-tomertéferenc) Cart) ALTER TABLE Cart ADD CONSTRAINT Cart_Customer FOREIGN KEY Cart_Customer (Customer_customer_id ) REFERENTIES Klant (customer_id);-- Referentie: Cart_Product (Tabel: Winkelwagen)ALTER TABLE Winkelwagen ADD_CONSTRAINProductProductProductTIGOREt REFERENCES Producto (product_id);

We kunnen dit zienCustomer_customer_idDe kolom maakt deel uit van de primaire sleutelDiten een externe sleutel ervoorKlantTabel in relatie totklant identificatiekolom van de laatste.HijProduct_id_productDe kolom daarentegen is slechts een vreemde sleutel voor deProductTafel. Dit omdatDitis geen dochterondernemingProduct, hoe gaat hetKlant.

Pas uw eigen ER -online winkelgrafiek aan

We hebben de stappen gezien die nodig zijn om een ​​eenvoudig ER-diagram voor online winkelen te maken en dit om te zetten in een werkende database in een RDBMS. Zoals we eerder vermeldden, kan dit model veel verbeteringen bevatten om sterkere beveiliging te bieden of direct bijgewerkte inventaris- en prijsinformatie. Er kunnen ook verbeteringen worden doorgevoerd om het gemakkelijker te maken om de producttabel bij te houden, nieuwe producten toe te voegen, de datums van bestaande producten te wijzigen of producten stop te zetten zonder de registratie van bestellingen, betalingen en leveringen te beïnvloeden. U kunt oefenen met het direct toevoegen van al deze verbeteringen door het ER-diagram te wijzigen inVerticaal.