I matrimoni sono spesso accompagnati da allegria e festa, con numerosi ospiti, cibo, bevande, musica e balli. Ma tutto questo non può accadere senza la preparazione e il coordinamento adeguati. Diamo un'occhiata più da vicino a come la modellazione dei dati può aiutarci a organizzare meglio un matrimonio in modo che tutto funzioni senza intoppi.
Precedenti preliminari
Sebbene siamo per lo più tutti consapevoli dell'aspetto di una tipica cerimonia nuziale, non può far male considerare brevemente alcuni aspetti che potrebbero potenzialmente avere un impatto sul nostro modello di dati.
Parti di matrimonio
Sebbene la maggior parte delle culture tradizionali abbia cerimonie tra un uomo e una donna, i matrimoni tra persone dello stesso sesso hanno luogo anche in altre società. Il nostro modello di dati dovrebbe essere progettato in modo tale da accogliere tutte le possibilità.
Scala e complessità
Le cerimonie nuziali variano notevolmente per dimensioni, durata e complessità. Alcuni sono piccole, modeste occasioni, ma altri sono grandi celebrazioni. In Croazia, ad esempio, puoi organizzare una semplice cerimonia di matrimonio in cui una coppia si sposa nel municipio, si scambia gli anelli e le promesse davanti ai propri ospiti e partecipa a una cena dopo la cerimonia o torna a casa. In altri paesi, i matrimoni possono essere piuttosto elaborati:possono comportare addii al celibato/nubilato, trattative, cene, cerimonie multiple e così via. In alcuni casi, queste cerimonie possono durare più giorni e svolgersi in luoghi diversi! Anche in questo caso, il nostro modello di dati dovrebbe essere preparato per gestire queste situazioni.
Risultato finale e spese
Nella maggior parte dei casi, la coppia si sposa dopo la celebrazione e riceve una fattura per tutte le spese (affitto, cibo e bevande, banda, ecc). Possono decidere di assumere un'agenzia che si occupi di tutti questi costi per loro, oppure possono scegliere di gestirli da soli. In ogni caso, dovremmo rendere conto di queste situazioni.
Il modello di dati:panoramica
Il nostro modello di dati per questo articolo è composto da cinque sezioni:
- Località
- Partner, prodotti e servizi
- Matrimoni
- Partecipanti
- Fatture
Discuteremo a fondo ciascuna di queste aree nell'ordine in cui sono elencate sopra. Mentre lavoriamo allo sviluppo del nostro modello di dati, assumeremo il ruolo dell'agenzia che organizza il matrimonio.
Sezione 1:Posizioni
Le Locations la sezione presenta tabelle universali che possono essere utilizzate in molti altri modelli di dati. Come abbiamo notato in precedenza, l'intera cerimonia nuziale potrebbe svolgersi in un solo luogo o potrebbe potenzialmente estendersi su più luoghi. Discutiamo più in dettaglio le tabelle di questa sezione.
Il country la tabella memorizza le informazioni sul paese in cui si svolge il matrimonio. Nella maggior parte dei casi, questo paese corrisponderà all'ubicazione della nostra agenzia, ma potrebbe non essere così se operiamo a livello internazionale. Ciascun paese in questa tabella è definito in modo univoco dal suo country_name .
Successivamente, dobbiamo memorizzare l'elenco di tutte le città e/o paesi in cui verrà organizzato il matrimonio. Queste informazioni verranno archiviate nella city tavolo. Per ogni città, memorizzeremo il nome e il codice postale, nonché il paese in cui si trova.
L'ultima tabella in questa area tematica è location . Le posizioni sono più specifiche, come municipi, chiese, parchi e così via. Per ogni località, memorizzeremo il suo nome e un riferimento all'ID della città in cui si trova. La combinazione di questi due attributi costituisce la chiave univoca per questa tabella.
Per le località, tieni presente che qui abbiamo adottato un approccio conservativo per evitare di coprire i casi insoliti in cui la cerimonia si svolge, ad esempio, in un treno o in un aereo (in tal caso, la "posizione" può coinvolgere più città). Se desideriamo coprire questi casi, dovremmo apportare alcune modifiche al nostro modello.
Sezione 2:Partner, prodotti e servizi
Prima di passare alla parte centrale del nostro modello di dati, dobbiamo archiviare l'elenco di tutti i partner con cui lavoriamo, nonché i prodotti e i servizi che offrono. Per raggiungere questo obiettivo, utilizzeremo cinque tabelle.
Innanzitutto, l'elenco di tutti i partner con cui collaboriamo è archiviato nel partner dizionario. Per ogni partner, memorizzeremo il suo partner_code univoco e partner_name .
Naturalmente, i nostri partner forniranno servizi legati al matrimonio, che potrebbero includere catering, organizzazione di bande musicali, installazione di apparecchiature audio e video, supporto per l'affitto e molto altro. In sostanza, qualsiasi cosa tu possa pensare può potenzialmente essere correlata in qualche modo a un matrimonio. Memorizziamo questo elenco di servizi nel service dizionario. Per ogni servizio memorizzeremo:
service_code– un valore che utilizzeremo internamente per denotare in modo univoco un particolare servizio.service_name– nome del servizio. Tieni presente che servizi diversi potrebbero condividere lo stesso nome. Ciò accadrebbe se due dei nostri partner offrissero lo stesso servizio, il che è abbastanza probabile. Sarebbe persino auspicabile che utilizzassero lo stesso nome per lo stesso tipo di servizio, perché ciò renderebbe molto più semplice confrontare i prezzi per gli stessi servizi.description– una descrizione testuale facoltativa del servizio.picture– un collegamento alla posizione in cui è archiviata l'immagine del servizio associata.price– il prezzo corrente per questo servizio. Può contenere un valore NULL se non è possibile determinare il prezzo senza prima valutare vari fattori, ad esempio quante persone intendono partecipare alla cerimonia.
Il provides_service la tabella mette in relazione i partner con l'elenco dei servizi che forniscono. Per ogni combinazione univoca di partner_id e service_id , memorizzeremo una descrizione testuale dettagliata della natura del servizio fornito dal partner e se il servizio è attualmente disponibile.
Abbiamo anche bisogno di tabelle per memorizzare le informazioni sui prodotti e le loro relazioni con i partner. Il product la tabella segue la stessa logica del service tabella, tranne che, come suggerisce il nome, è specifica per i prodotti. In questa tabella conserveremo tutti i possibili prodotti essenziali per la maggior parte delle cerimonie nuziali, come anelli, abiti, decorazioni, fiori, mobili e altro ancora.
L'ultima tabella in questa sezione è provides_product tavolo. Funziona proprio come provides_service tabella, tranne per il fatto che è specifico per i prodotti rispetto ai servizi. Specifica quale dei nostri partner offre il prodotto in questione.
Sezione 3:Matrimoni
Siamo finalmente arrivati al cuore del nostro modello di dati:i Weddings sezione. Contiene cinque nuove tabelle che fanno riferimento alle tabelle di altre sezioni. Tieni presente che le tabelle di questa sezione verranno referenziate anche nelle prossime parti del nostro modello.
Nel wedding tavolo, memorizzeremo l'elenco completo di tutti i matrimoni che siamo/siamo stati coinvolti nell'organizzazione. A ogni matrimonio verrà assegnato il proprio wedding_code univoco . Conserveremo anche gli orari di inizio e fine pianificati per l'intera cerimonia e aggiorneremo gli orari di inizio e fine reali ogni volta che queste informazioni saranno disponibili. Inoltre, memorizzeremo il budget_planned valore quindi abbiamo almeno una stima di quanto costerà tutto questo. Tutti gli altri dettagli relativi al matrimonio sono archiviati in altre aree del modello di dati, quindi questo è tutto ciò di cui abbiamo veramente bisogno per ora.
L'idea qui è di trattare ogni matrimonio come una serie di eventi. Gli eventi a loro volta saranno correlati alle offerte per i prodotti/servizi desiderati, alle offerte rifiutate e accettate e ad altri dettagli rilevanti. Per darti un'idea migliore di come funziona tutto ciò, potremmo suddividere l'intero matrimonio nei seguenti eventi:fase di pianificazione, addii al celibato/nubilato, cerimonia e after-party/cena. Naturalmente, questi sono solo alcuni degli eventi nuziali più comuni. Tutti gli eventi nuziali vengono memorizzati nella tabella degli eventi. Un event avrà un ID univoco.
Ogni evento è associato a un singolo matrimonio e sarà correlato a una località oa nessuna. Quest'ultimo caso si verifica se l'evento è più concettuale , come la fase di progettazione (poiché non esiste un'unica sede in cui deve svolgersi). Come per la cerimonia di matrimonio vera e propria, un evento avrà orari di inizio/fine pianificati e reali, nonché un budget pianificato. Nota che abbiamo mantenuto le cose semplici qui per quanto riguarda le posizioni. Se gli eventi coinvolgono più località, dovremo adattare il nostro modello di dati.
Andando avanti, vogliamo archiviare tutti i servizi e i prodotti correlati a un evento. Per farlo, utilizzeremo tre tabelle:status , product_included e service_included .
Lo status table è un dizionario che tiene traccia di tutti gli stati relativi a prodotti e servizi per un particolare evento. Include variabili flag che indicano se un prodotto/servizio è stato offerto, accettato o rifiutato. Per ogni record in questa tabella, memorizzeremo un status_name univoco .
Le restanti due tabelle in questa sezione, intitolate product_included e service_included , si assomigliano strutturalmente e concettualmente. Per ogni evento, memorizzeremo l'elenco dei prodotti e dei servizi offerti e ne cambieremo lo stato se vengono accettati o rifiutati. Per ogni record in queste due tabelle, memorizzeremo i seguenti attributi comuni:
event_id– un riferimento all'evento correlato.provides_product_id/provides_service_id– i riferimenti alle tabelle con i prodotti/servizi offerti dai nostri partner.price– prezzo proposto per il prodotto/servizio. Questo prezzo può differire dal prezzo standard che abbiamo in archivio se proponiamo un'offerta speciale.current_status_id– un riferimento allostatusdizionario che indica se questo record è stato offerto, accettato o rifiutato.
Sezione 4:Partecipanti
Se stai organizzando un grande matrimonio, è probabile che tu conosca la maggior parte degli ospiti che hanno intenzione di partecipare. Naturalmente, gli ospiti che inviti, siano essi tuoi amici o parenti, probabilmente porteranno altre persone che non conosci personalmente, come i loro amici o colleghi. In questa sezione memorizzeremo l'elenco completo degli invitati che sono stati invitati al matrimonio, nonché i loro ruoli.
La person la tabella contiene un elenco di tutte le persone che partecipano al matrimonio. Per ogni individuo, memorizzeremo il suo person_code univoco e nomi e cognomi. Ovviamente possiamo aggiungere ulteriori dettagli se lo desideriamo.
Successivamente, definiremo tutti i possibili ruoli che si potrebbero assumere durante un matrimonio. Questi ruoli includono "ospite", "testimone", "groomsman", "damigella d'onore", "sposa", "sposo" e così via. Per ogni ruolo, memorizzeremo solo il role_name univoco in questa tabella. Una persona può assumere un solo ruolo per un matrimonio particolare.
Successivamente, collegheremo i matrimoni ai loro partecipanti. Nota che il participate table contiene solo riferimenti alle tabelle wedding , person e role . La combinazione di wedding_id e person_id funge da chiave alternativa per questa tabella.
Il matrimonio sarà composto da diversi eventi, ma non tutti i partecipanti saranno coinvolti in questi. Pertanto, dobbiamo archiviare queste informazioni separatamente. Nel in_event tabella, memorizzeremo coppie univoche di chiavi esterne che fanno riferimento alle tabelle event e participate . Tutte le informazioni aggiuntive verranno memorizzate nei details testo attribuito.
Sezione 5:Fatture
Abbiamo quasi finito! L'ultima sezione del nostro modello di dati ci consente di tenere traccia delle spese relative al matrimonio. Emozionante, vero?
Di solito genereremo una invoice per matrimonio, ma potremmo anche generare di più se necessario. Si spera che l'importo totale che fattureremo alla coppia corrisponda molto al nostro budget pianificato, ma potrebbe non essere sempre così. Per ogni fattura, memorizzeremo le seguenti informazioni:
wedding_id– un riferimento al matrimonio per il quale è stata emessa la fattura.time_created– il timestamp di quando è stata generata la fattura.due_date– la data entro la quale la fattura deve essere pagata.invoice_amount– l'importo totale che deve essere pagato.payment_time– il timestamp di quando è stato effettivamente emesso il pagamento. Naturalmente, questo attributo conterrà un valore NULL fino al pagamento.paid– un flag che indica se la fattura è stata pagata. Questo attributo verrà impostato su "True" non appena ilpayment_timeè aggiornato.
L'ultima tabella del nostro modello riguarda gli articoli fatturati stessi. Li memorizzeremo nel invoice_item tavolo. Per ogni record, memorizzeremo i seguenti dettagli:
item_name– il nostro nome scelto per l'articolo specifico.item_price– il prezzo relativo a quell'articolo specifico.invoice_id– l'identificativo della relativa fattura.service_included_id– l'ID del servizio a cui è correlata la voce della fattura. Questo attributo potrebbe essere impostato su NULL se l'articolo in questione non è effettivamente correlato ad alcun servizio o se si tratta semplicemente di un addebito aggiuntivo che abbiamo applicato alla fattura.product_included_id– l'ID del prodotto a cui si riferisce l'elemento della fattura. Questo attributo può essere impostato su NULL se l'articolo in questione non è effettivamente correlato ad alcun prodotto o se si tratta semplicemente di un addebito aggiuntivo che abbiamo applicato alla fattura.
Riepilogo
Questo praticamente riassume tutto per questo modello di dati! Ancora una volta, vediamo quanto sia utile la modellazione dei dati nell'organizzazione delle informazioni di un'azienda.
Come abbiamo notato, ci sono molte cose che abbiamo omesso dal nostro modello di dati per semplicità. Ad esempio, il nostro modello dovrebbe idealmente tenere traccia della cronologia delle offerte, dei dettagli finanziari e altro ancora.
Fateci sapere in basso se avete suggerimenti. Ci piacerebbe sentire i tuoi pensieri!
