Organizar festas infantis não é uma tarefa fácil:tudo tem que ser perfeitamente planejado e entregue. Caso contrário, o caos acontece. Cabe aos adultos – mais especificamente, os organizadores de festas – cuidar de tudo e fazê-lo corretamente.
Existe uma maneira melhor de fazer isso do que organizar tudo em um banco de dados? Não achamos!
As festas infantis variam muito. Algumas são simples, como festas de aniversário que incluem apenas convites, comida (lanches, bebidas e bolo) e talvez um palhaço ou um mágico para entreter as crianças. Outras partes são muito mais complexas. Eles podem exigir uma viagem para fora da cidade, acomodações para dormir e muitas outras atividades. Quanto mais complicada a festa, menos espaço para erros. Embora um palhaço com 10 minutos de atraso não seja grande coisa, ninguém quer esperar com um grupo de crianças entediadas por um ônibus com duas horas de atraso!
Vamos ver o que um modelo de dados pode fazer para ajudar os planejadores de festas a se manterem organizados.
O que precisamos em nosso modelo de dados?
Vamos supor que administramos um negócio de planejamento de festas. Teremos uma lista de serviços que oferecemos aos clientes. Esses serviços podem ser fornecidos por nós ou podemos usar parceiros (por exemplo, contratamos o palhaço).
Combinamos esses serviços e os oferecemos aos clientes como um pacote de festa. Cada pacote tem um ponto inicial e final, ou cronograma. Isso inclui não apenas a festa em si, mas a organização da festa e a limpeza depois. Também podemos ter vários locais (por exemplo, uma festa começa com pizza em um restaurante e depois segue para a praia para nadar).
Também precisaremos relacionar atividades com funcionários, acompanhar o progresso das partes e cobrar por nossos serviços. Vamos ver como isso é feito.
O modelo de dados da festa infantil
Nosso modelo de dados de festa infantil consiste em quatro áreas temáticas:
Countries & citiesPartners & servicesEmployees & rolesParty
Apresentaremos cada área de assunto na mesma ordem em que está listada.
Seção 1:Países e Cidades
Esta área de assunto contém apenas duas tabelas. Eles não são específicos para este modelo, mas vamos usá-los em outras áreas temáticas.
Podemos esperar operar em várias cidades e talvez até em vários países. Portanto, precisaremos referenciar várias cidades. Isso nos ajudará a rastrear onde as partes estão localizadas e também quais serviços oferecemos em cada local.
O country dicionário contém apenas o country_name EXCLUSIVO valor. Para cada city , armazenaremos a combinação ÚNICA de postal_code – city_name – country_id .
Seção 2:Parceiros e Serviços
A seguir, vamos detalhar os serviços que forneceremos para nossos clientes.
Uma lista de todos os serviços possíveis é armazenada no service dicionário. Ele contém apenas o service_name EXCLUSIVO atributo.
Neste modelo de dados, todos os serviços são prestados por parceiros. Mesmo quando nossa empresa realmente fornece o serviço, nós a tratamos como um partner serviço (e nós somos o parceiro). O dicionário de parceiros armazenará todos os parceiros com os quais trabalhamos, inclusive nós. Para cada parceiro, armazenaremos um partner_name EXCLUSIVO . Os details O atributo armazena todos os detalhes adicionais relacionados a esse parceiro usando um formato não estruturado ou estruturado (por exemplo, usando pares nome-valor separados por separador predefinido).
O provides table é a tabela final e mais importante nesta seção. Para cada registro, armazenaremos:
partner_id– Opartnerque fornece um serviço.service_id– Oserviceeste parceiro fornece.city_id– Faz referência àcityonde este serviço é fornecido por esse parceiro.date_from– A data em que o parceiro começou a oferecer esse serviço.date_to– A data em que o parceiro deixou de oferecer esse serviço. Esse valor pode ser NULL se esse relacionamento com o parceiro de serviço ainda estiver em andamento.details– Todos os detalhes adicionais relacionados a esse serviço, como descrição do serviço, preço etc. Podemos esperar que todos os detalhes estejam em um formato textual estruturado, usando pares de valores-chave.
A combinação de
partner_id – service_id – city_id – date_from forma a chave UNIQUE nesta tabela. Ao inserir um novo registro, devemos verificar se ele não se sobrepõe a nenhum registro existente. Seção 3:Funcionários e Funções
Antes de passarmos para a parte central e mais importante do nosso modelo, precisamos examinar as tabelas relacionadas aos nossos funcionários e suas funções.
A tabela central nesta área de assunto é o employee tabela. Para cada funcionário, armazenaremos seu first_name , last_name , user_name e password . Eles usarão esses dois últimos atributos para acessar nosso aplicativo.
Uma lista de todas as funções possíveis é armazenada na role dicionário. Cada função é definida EXCLUSIVAMENTE por seu role_name . Os papéis estão relacionados às ações que cada funcionário executa durante uma festa. Portanto, podemos esperar valores como “gerente de grupo” ou “assistente” aqui.
As funções podem ser atribuídas aos funcionários por meio do has_role tabela. O employee_id – role_id par denotará os papéis ativos que cada funcionário tem naquele momento.
Seção 4:Parte
A Party área temática é a parte central deste modelo. Vamos usá-lo para relacionar tabelas de outras áreas de assunto, e também teremos algumas novas informações aqui.
A mesa central aqui é a party tabela. Para cada festa, armazenaremos:
city_id– Acityonde a festa acontecerá.client_id– Oclientesta festa é organizada.details– Uma descrição textual detalhada da festa.start_time_plannedeend_time_planned– O horário que agendamos para esta festa, incluindo configuração e limpeza.start_time_actualeend_time_actual– Os horários reais em que a festa (e seus serviços relacionados) ocorreu.price_offered– O preço que citamos para organizar esta festa para este cliente.time_offered– Quando a oferta foi feita.price_paid– O valor real que o cliente pagou por esta parte.time_paid– Quando o pagamento foi feito.
Cada parte está relacionada a um cliente. Já mencionamos o
client tabela, mas agora veremos o que está armazenado lá. Eu fui apenas com dados básicos:client_name , detalhes de contato (address , email , phone , mobile ) e quaisquer detalhes adicionais em formato textual. Cada parte também terá uma lista de serviços associados a ela. Essa lista é armazenada no
service_included tabela. Para cada registro, precisaremos de:party_id– Refere-se àparty.service_id– Faz referência aoserviceincluído na festa.provides_id– Faz referência aoproviderdesse serviço, bem como o próprio serviço. Esse atributo pode ser NULL, pois o atualizaremos quando selecionarmos o provedor específico.details– Quaisquer detalhes textuais adicionais relacionados a esse serviço nessa parte.start_time_plannedeend_time_planned– Os horários planejados em que o serviço deve ser prestado durante a festa.
Também precisaremos acompanhar o progresso de cada parte. Usaremos duas tabelas para fazer isso.
O
status A tabela listará todos os status possíveis que podem ser atribuídos a uma parte. Para cada registro, armazenaremos um status_name ÚNICO e três bandeiras:successful– Correu tudo bem? Ou houve problemas com nossos serviços?paid– A festa foi paga?final– Este é o status final para esta festa?
Atribuiremos status aos serviços adicionando novos registros ao
party_status tabela. Para cada registro, armazenaremos referências à party e service tabelas e o timestamp quando este status foi atribuído. A tabela final em nosso modelo é a
invoice tabela. Não é específico para este modelo, mas precisamos de uma estrutura básica para armazenar as faturas. Para cada fatura, registraremos:client_name– O nome do cliente no momento da emissão da fatura.party_id– Apartyrelacionadas a esta fatura.client_id– O ID doclientsendo faturado.invoice_amount,discount,vat_amount,total_amount– Os detalhes financeiros da fatura.time_issued- Quando esta fatura foi emitida ou adicionada ao banco de dados.time_paid- Quando esta fatura foi paga.
O que você faria com este modelo de dados?
Este modelo é bastante simples, mas vejo várias maneiras de melhorá-lo. Que mudanças você proporia? Existe algo que poderíamos organizar de forma diferente? Talvez precisemos adicionar ou remover um recurso. Por favor, diga-nos nos comentários.
