Os casamentos costumam ser acompanhados de alegria e celebração, com inúmeros convidados, comida, bebida, música e dança. Mas tudo isso não pode acontecer sem a devida preparação e coordenação. Vamos dar uma olhada em como a modelagem de dados pode nos ajudar a organizar melhor um casamento para que tudo corra bem.
Antecedentes Preliminares
Embora todos saibamos como é uma cerimônia de casamento típica, não faz mal considerar brevemente alguns aspectos que podem afetar nosso modelo de dados.
Parceiros de casamento
Embora a maioria das culturas tradicionais tenha cerimônias entre um homem e uma mulher, os casamentos do mesmo sexo também ocorrem em outras sociedades. Nosso modelo de dados deve ser projetado de forma a acomodar todas as possibilidades.
Escala e complexidade
As cerimônias de casamento variam muito em tamanho, duração e complexidade. Algumas são ocasiões pequenas e modestas, mas outras são grandes celebrações. Na Croácia, por exemplo, você pode ter uma cerimônia de casamento simples em que um casal se casa na prefeitura, troca alianças e votos antes de seus convidados e participa de um jantar pós-cerimônia ou vai para casa. Em outros países, os casamentos podem ser bastante elaborados:podem envolver despedidas de solteiro/solteira, negociações, jantares, várias cerimônias e assim por diante. Em alguns casos, essas cerimônias podem durar vários dias e ocorrer em alguns locais diferentes! Novamente, nosso modelo de dados deve estar preparado para lidar com essas situações.
Resultado e despesas finais
Na maioria dos casos, o casal se casa após a celebração e recebe uma fatura de todos os custos (aluguel, alimentação e bebidas, banda, etc). Eles podem decidir contratar uma agência para cuidar de todos esses custos para eles, ou podem optar por lidar com tudo por conta própria. De qualquer forma, devemos levar em conta essas situações.
O modelo de dados:visão geral
Nosso modelo de dados para este artigo consiste em cinco seções:
- Locais
- Parceiros, produtos e serviços
- Casamentos
- Participantes
- Faturas
Discutiremos detalhadamente cada uma dessas áreas na ordem em que estão listadas acima. Enquanto trabalhamos no desenvolvimento do nosso modelo de dados, vamos assumindo o papel da agência que organiza o casamento.
Seção 1:Locais
Os Locations seção apresenta tabelas universais que podem ser usadas em muitos outros modelos de dados. Como observamos anteriormente, toda a cerimônia de casamento pode ocorrer em apenas um único local ou pode abranger vários locais. Vamos discutir as tabelas desta seção com mais detalhes.
O country table armazena informações sobre o país em que o casamento acontece. Na maioria dos casos, esse país corresponderá à localização de nossa agência, mas pode não ser o caso se operarmos internacionalmente. Cada país nesta tabela é definido exclusivamente por seu country_name .
Em seguida, precisamos armazenar a lista de todas as cidades e/ou vilas onde o casamento será organizado. Essas informações serão armazenadas na city tabela. Para cada cidade, armazenaremos seu nome e código postal, bem como o país em que está localizada.
A última tabela nesta área de assunto é location . Os locais são mais específicos, como prefeituras, igrejas, parques e assim por diante. Para cada local, armazenaremos seu nome e uma referência ao ID da cidade em que está localizado. A combinação desses dois atributos forma a chave exclusiva para esta tabela.
Para locais, observe que adotamos uma abordagem conservadora aqui para evitar cobrir os casos incomuns em que a cerimônia ocorre, digamos, em um trem ou avião (nesse caso, o “local” pode envolver várias cidades). Se quisermos cobrir esses casos, precisaríamos fazer algumas alterações em nosso modelo.
Seção 2:parceiros, produtos e serviços
Antes de passarmos para a parte central do nosso modelo de dados, precisamos armazenar a lista de todos os parceiros com os quais trabalhamos, bem como os produtos e serviços que eles oferecem. Para conseguir isso, usaremos cinco tabelas.
Em primeiro lugar, a lista de todos os parceiros com os quais trabalhamos é armazenada no partner dicionário. Para cada parceiro, armazenaremos seu partner_code exclusivo e partner_name .
Obviamente, nossos parceiros fornecerão serviços relacionados ao casamento, que podem incluir catering, organização de bandas, instalação de equipamentos de áudio e vídeo, suporte de aluguel e muito mais. Essencialmente, qualquer coisa que você possa pensar pode estar relacionada a um casamento de alguma maneira. Armazenaremos esta lista de serviços no service dicionário. Para cada serviço, armazenaremos:
service_code– um valor que usaremos internamente para denotar exclusivamente um serviço específico.service_name– nome do serviço. Observe que diferentes serviços podem compartilhar o mesmo nome. Isso ocorreria se dois de nossos parceiros oferecessem o mesmo serviço, o que é bastante provável. Seria até desejável que eles usassem o mesmo nome para o mesmo tipo de serviço, porque isso facilitaria muito a comparação de preços para os mesmos serviços.description– uma descrição textual opcional do serviço.picture– um link para o local onde a imagem de serviço associada está armazenada.price– o preço atual para este serviço. Ele pode conter um valor NULL se o preço não puder ser determinado sem primeiro avaliar vários fatores, como quantas pessoas planejam participar da cerimônia.
O
provides_service tabela relaciona os parceiros à lista de serviços que eles fornecem. Para cada combinação exclusiva de partner_id e service_id , armazenaremos uma descrição textual detalhada da natureza do serviço prestado pelo parceiro e se o serviço está disponível no momento. Também precisamos de tabelas para armazenar informações sobre produtos e suas relações com os parceiros. O
product tabela segue a mesma lógica do service tabela, exceto que, como o nome sugere, é específico para produtos. Nesta mesa, vamos armazenar todos os produtos possíveis que são essenciais para a maioria das cerimônias de casamento, como anéis, roupas, decorações, flores, móveis e muito mais. A última tabela nesta seção é o
provides_product tabela. Funciona exatamente como o provides_service tabela, exceto que é específico para produtos em oposição a serviços. Especifica qual dos nossos parceiros oferece o produto em questão. Seção 3:Casamentos
Finalmente chegamos ao coração do nosso modelo de dados:os Weddings seção. Ele contém cinco novas tabelas que fazem referência às tabelas de outras seções. Observe que as próprias tabelas desta seção também serão referenciadas nas próximas partes do nosso modelo.
No wedding mesa, guardamos a lista completa de todos os casamentos que estamos/estivemos envolvidos na organização. Cada casamento receberá seu próprio wedding_code exclusivo . Também armazenaremos os horários de início e término planejados para toda a cerimônia e atualizaremos os horários reais de início e término sempre que essas informações estiverem disponíveis. Além disso, armazenaremos o budget_planned valor para que pelo menos tenhamos uma estimativa de quanto tudo isso vai custar. Todos os outros detalhes relacionados ao casamento são armazenados em outras áreas do modelo de dados, então isso é tudo o que realmente precisamos por enquanto.
A ideia aqui é tratar cada casamento como uma série de eventos. Os eventos, por sua vez, estarão relacionados a ofertas de produtos/serviços desejados, ofertas rejeitadas e aceitas e outros detalhes relevantes. Para você ter uma ideia melhor de como tudo isso funciona, podemos dividir todo o casamento nos seguintes eventos:fase de planejamento, despedidas de solteiro/solteira, cerimônia e pós-festa/jantar. Claro, estes são apenas alguns dos eventos de casamento mais comuns. Todos os eventos de casamento são armazenados na tabela de eventos. Um event terá um id único.
Cada evento está associado a um único casamento e estará relacionado a um local ou a nenhum. O último caso surge se o evento for mais conceitual , como a fase de planejamento (já que não há um único local onde deva ocorrer). Tal como acontece com a própria cerimônia de casamento, um evento terá horários de início / fim planejados e reais, bem como um orçamento planejado. Observe que mantivemos as coisas simples aqui em relação aos locais. Se os eventos envolverem vários locais, precisaremos ajustar nosso modelo de dados.
Continuando, queremos armazenar todos os serviços e produtos relacionados a um evento. Para isso, usaremos três tabelas:status , product_included e service_included .
O status table é um dicionário que acompanha todos os status relacionados a produtos e serviços para um determinado evento. Inclui variáveis de sinalização que indicam se um produto/serviço foi oferecido, aceito ou rejeitado. Para cada registro nesta tabela, armazenaremos um status_name exclusivo .
As duas tabelas restantes nesta seção, intituladas product_included e service_included , se assemelham estrutural e conceitualmente. Para cada evento, armazenaremos a lista de produtos e serviços oferecidos e alteraremos seus status se forem aceitos ou rejeitados. Para cada registro nessas duas tabelas, armazenaremos os seguintes atributos comuns:
event_id– uma referência ao evento relacionado.provides_product_id/provides_service_id– referências às tabelas com produtos/serviços que nossos parceiros oferecem.price– preço proposto para o produto/serviço. Esse preço pode diferir do preço padrão registrado se propusermos uma oferta especial.current_status_id– uma referência aostatusdicionário indicando se este registro foi oferecido, aceito ou rejeitado.
Seção 4:Participantes
Se você está organizando um grande casamento, é provável que conheça a maioria dos convidados que planejam participar. É claro que os convidados que você convida – sejam amigos ou parentes – provavelmente trarão outras pessoas que você não conhece pessoalmente, como amigos ou colegas. Nesta seção, armazenaremos a lista completa dos convidados que foram convidados para o casamento, bem como suas funções.
A person tabela contém uma lista de todos os indivíduos que fazem parte do casamento. Para cada indivíduo, armazenaremos seu person_code exclusivo e nomes e sobrenomes. Claro que podemos adicionar mais detalhes se quisermos.
A seguir, definiremos todos os papéis possíveis que se pode assumir durante um casamento. Esses papéis incluem “convidado”, “padrinho”, “padrinho”, “dama de honra”, “noiva”, “noivo” e assim por diante. Para cada função, armazenaremos apenas o role_name exclusivo nesta tabela. Uma pessoa só pode assumir um papel para um casamento específico.
Em seguida, relacionaremos os casamentos aos seus participantes. Observe que o participate table contém apenas referências às tabelas wedding , person e role . A combinação de wedding_id e person_id serve como a chave alternativa para esta tabela.
O casamento consistirá em vários eventos, mas nem todos os participantes estarão envolvidos neles. Portanto, precisamos armazenar essas informações separadamente. No in_event tabela, armazenaremos pares exclusivos de chaves estrangeiras referenciando as tabelas event e participate . Todas as informações adicionais serão armazenadas nos details texto atribuído.
Seção 5:faturas
Estamos quase terminando! A última seção do nosso modelo de dados nos permite rastrear as despesas relacionadas ao casamento. Emocionante, certo?
Geralmente, geramos uma invoice por casamento, mas também poderíamos gerar mais se precisássemos. Esperamos que o valor total que faturamos ao casal corresponda ao nosso orçamento planejado, mas nem sempre é esse o caso. Para cada fatura, armazenaremos as seguintes informações:
wedding_id– uma referência ao casamento para o qual a fatura foi emitida.time_created– o carimbo de data/hora de quando a fatura foi gerada.due_date– a data em que a fatura deve ser paga.invoice_amount– o valor total que deve ser pago.payment_time– o carimbo de data/hora de quando o pagamento foi realmente emitido. Obviamente, esse atributo conterá um valor NULL até que o pagamento seja feito.paid– um sinalizador indicando se a fatura foi paga. Este atributo será definido como "True" assim que opayment_timeé atualizado.
A última tabela em nosso modelo diz respeito aos próprios itens faturados. Vamos armazená-los no
invoice_item tabela. Para cada registro, armazenaremos os seguintes detalhes:item_name– nosso nome escolhido para o item específico.item_price– o preço relacionado a esse item específico.invoice_id– o ID da fatura relacionada.service_included_id– o id do serviço ao qual o item da fatura está relacionado. Esse atributo pode ser definido como NULL se o item em questão não estiver realmente relacionado a nenhum serviço ou se for apenas uma cobrança adicional aplicada à fatura.product_included_id– o id do produto ao qual o item da fatura está relacionado. Esse atributo pode ser definido como NULL se o item em questão não estiver realmente relacionado a nenhum produto ou se for apenas uma cobrança adicional aplicada à fatura.
Resumo
Isso resume muito bem este modelo de dados! Mais uma vez, vemos o quão útil a modelagem de dados na organização das informações de uma empresa.
Como observamos, há muitas coisas que omitimos de nosso modelo de dados para simplificar. Por exemplo, nosso modelo deve rastrear históricos de ofertas, detalhes financeiros e muito mais.
Deixe-nos saber abaixo se você tiver alguma sugestão. Adoraríamos ouvir seus pensamentos!
