Datamodell för bröllopsorganisation

Bröllop åtföljs ofta av glädje och fest, med många gäster, mat, dryck, musik och dans. Men allt detta kan inte hända utan ordentlig förberedelse och samordning. Låt oss ta en närmare titt på hur datamodellering kan hjälpa oss att bättre organisera ett bröllop så att allt går smidigt.

Preliminär bakgrund

Även om vi för det mesta alla är medvetna om hur en typisk bröllopsceremoni ser ut, kan det inte skada att kortfattat överväga några aspekter som potentiellt kan påverka vår datamodell.

Bröllopspartners

Även om de flesta traditionella kulturer kommer att ha ceremonier mellan en man och kvinna, äger samkönade äktenskap även rum i andra samhällen. Vår datamodell bör utformas på ett sådant sätt att den rymmer alla möjligheter.

Skala och komplexitet

Bröllopsceremonier varierar mycket i storlek, varaktighet och komplexitet. Vissa är små, blygsamma tillfällen, men andra är storslagna högtider. I Kroatien kan du till exempel ha en enkel bröllopsceremoni där ett par gifter sig i stadshuset, byter ut sina ringar och löften inför sina gäster och antingen deltar i en middag efter ceremonin eller går hem. I andra länder kan bröllop vara ganska komplicerade:de kan involvera svensexor, förhandlingar, middagar, flera ceremonier och så vidare. I vissa fall kan dessa ceremonier pågå i flera dagar och inträffa på några olika platser! Återigen, vår datamodell bör vara förberedd för att hantera dessa situationer.

Slutligt resultat och utgifter

I de flesta fall gifter sig paret efter firandet och får en faktura för alla kostnader (hyra, mat och dryck, band, etc). De kan välja att anlita en byrå för att ta hand om alla dessa kostnader åt dem, eller så kan de välja att hantera allt på egen hand. Oavsett vilket bör vi ta hänsyn till dessa situationer.

Datamodellen:Översikt

Vår datamodell för den här artikeln består av fem avsnitt:

1. Platser
2. Partners, produkter och tjänster
3. Bröllop
4. Deltagare
5. Fakturor

Vi kommer noggrant att diskutera vart och ett av dessa områden i den ordning de är listade ovan. När vi arbetar med att utveckla vår datamodell kommer vi att överta rollen som byrån som organiserar bröllopet.

Avsnitt 1:Platser

Locations sektionen innehåller universella tabeller som kan användas i många andra datamodeller. Som vi noterade tidigare kan hela bröllopsceremonin äga rum på bara en enda plats, eller så kan den eventuellt sträcka sig över flera platser. Låt oss diskutera tabellerna i det här avsnittet mer i detalj.

country tabell lagrar information om det land där vigseln äger rum. I de flesta fall kommer detta land att matcha platsen för vår byrå, men det kanske inte är fallet om vi verkar internationellt. Varje land i den här tabellen definieras unikt av dess country_name .

Därefter måste vi lagra listan över alla städer och/eller byar där bröllopet kommer att organiseras. Denna information kommer att lagras i city tabell. För varje stad lagrar vi dess namn och postnummer, samt landet den är belägen i.

Den sista tabellen i detta ämnesområde är location . Platser är mer specifika, som rådhus, kyrkor, parker och så vidare. För varje plats lagrar vi dess namn och en referens till ID:t för staden den är belägen i. Kombinationen av dessa två attribut utgör den unika nyckeln för denna tabell.

För platser, observera att vi här har använt ett konservativt tillvägagångssätt för att undvika att täcka de ovanliga fall där ceremonin äger rum i t.ex. ett tåg eller ett flygplan (i vilket fall "platsen" kan involvera flera städer). Om vi ​​skulle vilja täcka dessa fall skulle vi behöva göra några ändringar i vår modell.

Avsnitt 2:Partners, produkter och tjänster

Innan vi går vidare till den centrala delen av vår datamodell måste vi lagra listan över alla partners vi arbetar med, samt de produkter och tjänster de erbjuder. För att uppnå detta använder vi fem tabeller.

För det första, listan över alla partners vi arbetar med lagras i partner lexikon. För varje partner lagrar vi deras unika partner_code och partner_name .

Naturligtvis kommer våra partners att tillhandahålla bröllopsrelaterade tjänster, som kan inkludera catering, organisera band, sätta upp ljud- och videoutrustning, tillhandahålla hyresstöd och mycket mer. I huvudsak kan allt du kan tänka dig vara relaterat till ett bröllop på något sätt. Vi lagrar den här listan över tjänster i service lexikon. För varje tjänst lagrar vi:

• service_code – ett värde som vi kommer att använda internt för att unikt beteckna en viss tjänst.
• service_name – tjänstens namn. Observera att olika tjänster kan dela samma namn. Detta skulle inträffa om två av våra partners råkar erbjuda samma tjänst, vilket är ganska troligt. Det skulle till och med vara önskvärt om de använder samma namn för samma tjänstetyp eftersom det skulle göra det mycket lättare att jämföra priser för samma tjänster.
• description – en valfri textbeskrivning av tjänsten.
• picture – en länk till platsen där tillhörande tjänstebild finns lagrad.
• price – det aktuella priset för denna tjänst. Den kan innehålla värdet NULL om priset inte kan fastställas utan att först utvärdera olika faktorer, till exempel hur många som planerar att närvara vid ceremonin.

provides_service Tabellen relaterar partners till listan över tjänster de tillhandahåller. För varje unik kombination av partner_id och service_id , lagrar vi en detaljerad textbeskrivning av typen av tjänst som tillhandahålls av partnern och om tjänsten är tillgänglig för närvarande.

Vi behöver också tabeller för att lagra information om produkter och deras relationer till partners. product tabellen följer samma logik som service tabell, förutom, som namnet antyder, det är specifikt för produkter. I den här tabellen kommer vi att lagra alla möjliga produkter som är nödvändiga för de flesta bröllopsceremonier, såsom ringar, kläder, dekorationer, blommor, möbler och mer.

Den sista tabellen i det här avsnittet är provides_product tabell. Det fungerar precis som provides_service tabellen, förutom att den är specifik för produkter i motsats till tjänster. Den anger vilka av våra partners som erbjuder produkten i fråga.

Avsnitt 3:Bröllop

Vi har äntligen kommit till hjärtat av vår datamodell – Weddings sektion. Den innehåller fem nya tabeller som refererar till andra sektioners tabeller. Observera att det här avsnittets egna tabeller också kommer att refereras i kommande delar av vår modell.

I wedding tabell lagrar vi den fullständiga listan över alla bröllop vi är/var med och organiserar. Varje bröllop kommer att tilldelas sin egen unika wedding_code . Vi kommer också att lagra de planerade start- och sluttiderna för hela ceremonin, och vi kommer att uppdatera de verkliga start- och sluttiderna när denna information blir tillgänglig. Dessutom lagrar vi budget_planned värde så att vi åtminstone har en uppskattning av hur mycket allt detta kommer att kosta. Alla andra detaljer relaterade till bröllopet lagras i andra delar av datamodellen, så detta är allt vi verkligen behöver för nu.

Tanken här är att behandla varje bröllop som en serie händelser. Händelser kommer i sin tur att vara relaterade till erbjudanden för önskade produkter/tjänster, avvisade och accepterade erbjudanden och andra relevanta detaljer. För att ge dig en bättre uppfattning om hur allt det här fungerar kan vi dela upp hela bröllopet i följande händelser:planeringsfas, svensexor, ceremoni och efterfest/middag. Naturligtvis är dessa bara några av de vanligaste bröllopsevenemangen. Alla bröllopsevenemang lagras i evenemangstabellen. En event kommer att ha ett unikt ID.

Varje evenemang är kopplat till ett enda bröllop, och det kommer antingen att vara relaterat till en plats eller ingen. Det senare fallet uppstår om händelsen är mer konceptuell , såsom planeringsfasen (eftersom det inte finns någon enskild plats där det måste ske). Precis som med själva bröllopsceremonin kommer ett evenemang att ha planerade och riktiga start-/sluttider, samt en planerad budget. Observera att vi har gjort det enkelt här när det gäller platser. Om händelser involverar flera platser måste vi justera vår datamodell.

Går vidare vill vi lagra alla tjänster och produkter som är relaterade till ett event. För att göra det använder vi tre tabeller:status , product_included , och service_included .

status table är en ordbok som håller reda på alla statusar relaterade till produkter och tjänster för en viss händelse. Den inkluderar flaggvariabler som anger om en produkt/tjänst har erbjudits, accepterats eller avvisats. För varje post i den här tabellen lagrar vi ett unikt status_name .

De återstående två tabellerna i det här avsnittet, med titeln product_included och service_included , liknar varandra strukturellt och konceptuellt. För varje evenemang lagrar vi listan över produkter och tjänster som erbjöds och ändrar deras status om de accepteras eller avvisas. För varje post i dessa två tabeller lagrar vi följande vanliga attribut:

• event_id – en referens till den relaterade händelsen.
• provides_product_id / provides_service_id – referenser till tabellerna med produkter/tjänster som våra partners erbjuder.
• price – föreslaget pris för produkten/tjänsten. Detta pris kan skilja sig från standardpriset vi har registrerat om vi föreslår ett specialerbjudande.
• current_status_id – en referens till status ordbok som anger om denna post erbjöds, accepterades eller avvisades.

Avsnitt 4:Deltagare

Om du organiserar ett stort bröllop, är chansen stor att du är bekant med de flesta gäster som planerar att delta. Naturligtvis kommer gästerna du bjuder in – vare sig de är dina vänner eller släktingar – troligtvis ta med andra personer du inte känner personligen, som deras vänner eller kollegor. I det här avsnittet lagrar vi hela listan över gäster som har bjudits in till bröllopet, såväl som deras roller.

person Tabellen innehåller en lista över alla personer som är med i bröllopet. För varje individ lagrar vi deras unika person_code och för- och efternamn. Vi kan naturligtvis lägga till mer information om vi vill.

Därefter kommer vi att definiera alla möjliga roller som man kan anta under ett bröllop. Dessa roller inkluderar "gäst", "bästa man", "brudgum", "brudtärna", "brud", "brudgum" och så vidare. För varje roll lagrar vi endast det unika role_name i denna tabell. En person kan bara ta på sig en roll för ett visst bröllop.

Därefter kommer vi att relatera bröllop till deras deltagare. Observera att participate Tabellen innehåller endast referenser till tabellerna wedding , person och role . Kombinationen av wedding_id och person_id fungerar som alternativ nyckel för denna tabell.

Bröllopet kommer att bestå av flera evenemang, men alla deltagare kommer inte att vara inblandade i dessa. Därför måste vi lagra denna information separat. I in_event tabell, kommer vi att lagra unika par av främmande nycklar som refererar till tabellerna event och participate . All ytterligare information kommer att lagras i details text tillskriven.

Avsnitt 5:Fakturor

Vi är nästan klara! Den sista delen av vår datamodell låter oss spåra utgifter relaterade till bröllopet. Spännande, eller hur?

Vi genererar vanligtvis en invoice per bröllop, men vi kunde också generera mer om vi behövde. Förhoppningsvis kommer det totala beloppet som vi fakturerar paret nära att matcha vår planerade budget, men det kanske inte alltid är fallet. För varje faktura lagrar vi följande information:

• wedding_id – en hänvisning till det bröllop som fakturan utfärdades för.
• time_created – tidsstämpeln för när fakturan genererades.
• due_date – det datum då fakturan ska betalas.
• invoice_amount – det totala beloppet som måste betalas.
• payment_time – tidsstämpeln för när betalningen faktiskt utfärdades. Naturligtvis kommer detta attribut att innehålla värdet NULL tills betalningen görs.
• paid – en flagga som anger om fakturan har betalats. Det här attributet kommer att ställas in på "True" så snart som payment_time är uppdaterad.

Den sista tabellen i vår modell avser själva fakturerade poster. Vi lagrar dessa i invoice_item tabell. För varje post lagrar vi följande information:

• item_name – vårt valda namn för det specifika föremålet.
• item_price – priset som är relaterat till den specifika artikeln.
• invoice_id – ID för den relaterade fakturan.
• service_included_id – ID för tjänsten som fakturaposten är relaterad till. Det här attributet kan ställas in på NULL om varan i fråga faktiskt inte är relaterad till någon tjänst eller om det bara är en extra avgift som vi har lagt ut på fakturan.
• product_included_id – ID för produkten som fakturaposten är relaterad till. Det här attributet kan ställas in på NULL om varan i fråga faktiskt inte är relaterad till någon produkt eller om det bara är en extra avgift som vi har lagt ut på fakturan.

Sammanfattning

Det sammanfattar det ganska mycket för denna datamodell! Återigen ser vi hur användbar datamodellering för att organisera ett företags information.

Som vi noterade finns det många saker som vi har utelämnat från vår datamodell för enkelhetens skull. Till exempel bör vår modell helst spåra erbjudandenshistorik, ekonomiska detaljer och mer.

Låt oss veta nedan om du har några förslag. Vi vill gärna höra dina tankar!