O modelo de dados de datas importantes

Você está esquecendo alguma coisa? Um modelo de dados para ajudá-lo a lembrar datas importantes – antes que elas aconteçam.

Você já esqueceu uma data importante – o aniversário da sua mãe ou o seu aniversário? Ou que você está dando uma palestra? Sim, coisas assim acontecem na vida real. Talvez não para todos nós, mas para alguns de nós (inclusive eu), eles certamente fazem. Para evitar esses desastres, criaremos um modelo de dados que você pode usar como plano de fundo para um aplicativo que o notificará na hora certa.

É hora de dizer adeus a todos aqueles rostos desapontados e tristes e aos presentes que não foram comprados a tempo. :)

Vamos mergulhar direto no modelo.

O modelo de dados

Nosso objetivo é criar um modelo de dados para uma aplicação que nos permita definir eventos futuros e todas as ações relacionadas a eles. O aplicativo deve notificar os usuários quando eles fizerem uma determinada coisa da vida real e marcar essa coisa como concluída quando estiver concluída. Algumas tarefas estão se repetindo, por exemplo. esse evento aciona um evento futuro em um momento que definimos.

Claro, também precisaremos desenvolver aplicativos web e mobile para tornar este sistema realmente útil. Mas, por enquanto, vamos nos concentrar no modelo de dados.

O modelo consiste em três áreas temáticas:

User accounts & dates
Events & actions (definition)
Events & actions (real)

Descreveremos cada uma dessas três áreas de assunto na ordem em que estão listadas.

Seção 1:Contas de usuário e datas

Os usuários de nosso aplicativo podem criar seus próprios perfis de usuário e armazenar datas importantes de sua escolha. Para suportar isso, usaremos as tabelas a seguir.

A user_account tabela é semelhante em estrutura às descritas em muitos artigos de modelo de dados, mas vamos repeti-la mais uma vez. Para cada usuário, armazenaremos:

first_name e last_name – O nome e o sobrenome do usuário.
user_name – O nome de usuário selecionado do usuário.
password – O valor de hash da senha que o usuário selecionou.
mobile – O número de telefone celular fornecido pelo usuário.
email – O e-mail usado durante o processo de registro.
confirmation_code – Um código de confirmação enviado ao usuário para concluir seu registro.
confirmation_time – Quando o usuário concluiu o processo de confirmação.
insert_ts - O carimbo de data/hora em que este registro foi inserido.

Após a conclusão do registro, o usuário poderá selecionar suas próprias datas importantes. Esta lista é armazenada na tabela selected_date. Embora estejamos falando de datas, o que o usuário está realmente selecionando são regras que denotarão datas. Primeiro, descreveremos todos os atributos nesta tabela e, em seguida, discutiremos como os usuários podem definir regras usando esses atributos. Os atributos são:

user_account_id – O ID do usuário que inseriu este registro.
date_year , date_month e date_day - Valores inteiros que representam as partes da data (ano, mês e dia do mês).
date_weekday – Uma representação textual do número ordinal do dia da semana. Estamos usando texto porque permite que os usuários selecionem valores mais complexos – eles podem definir o dia da semana e a semana do mês, por exemplo, na segunda segunda-feira de cada mês.

Observe que todas as quatro partes da data podem ser NULL. Não permitiremos registros com todos os valores NULL, portanto, verificaremos programaticamente se pelo menos uma parte da data NÃO é NULL.

E agora alguns exemplos:

Se quisermos selecionar uma data exata, por exemplo, 31.12.2018, definiremos os valores para date_year =2018, date_month =12 e date_day =31. Isso define algo que acontecerá apenas uma vez, nessa única data.
Se usarmos a combinação date_year =2019 e date_month =1, deixando os dois valores restantes NULL, definimos algo que se repetirá durante todo o mês de janeiro de 2019.
A combinação date_year =2019 e date_day =2 acionaria um evento no segundo dia de cada mês em 2019.
Se inserirmos o valor , estamos definindo algo que acontecerá na segunda segunda-feira de cada mês.

Seção 2:eventos e ações (definição)

Eu tenho mencionado um vago “algo”, mas esse algo é na verdade um evento. Eventos e ações são as razões pelas quais estamos aqui. Queremos relacionar o domínio do tempo com eventos e ações reais que acontecerão no futuro. Nesta área de assunto, armazenaremos as definições para todos os eventos e ações. Essas definições serão usadas posteriormente para criar eventos e ações reais.

O event table é definitivamente a tabela central nesta área de assunto, mas antes de descrevê-la, quero descrever dois dicionários, o event_catalog e o recurrence_interval . Ambos têm a mesma estrutura, com uma chave primária de incremento automático (id ) e o atributo de nome UNIQUE.

O event_catalog O dicionário armazenará valores como “aniversário”, “feriado”, “aniversário” e “outro”. Isso nos ajudará a classificar nossos eventos.

Por outro lado, o recurrence_interval armazenará valores como “ano”, “mês”, “semana” e “dia”. Este valor denota a unidade de tempo que passará antes que o referido evento/ação se repita (se for definido como um evento recorrente). Quando esse período de tempo passar, uma nova instância do mesmo evento/ação será gerada.

Agora estamos prontos para chegar ao cerne desta área de assunto. No event tabela, o usuário define todos os eventos que são importantes para ele. Para cada evento, armazenaremos:

selected_date_id – Refere-se à definição de data.
event_catalog_id – Indica o tipo do evento.
description – Uma descrição textual adicional desse evento.
recurring – Um sinalizador indicando se o evento é recorrente.
recurrence_interval_id – Define com que frequência o evento se repete (ano, mês, etc). Combinando a definição de data de selected_date com o intervalo de recorrência nos permitirá definir o ponto inicial do evento e quantos eventos após esse ponto inicial serão criados automaticamente. Dessa forma, poderíamos definir algo como:“A partir das 2 segundas-feiras de cada mês (a selected_date tabela), agendar reuniões diárias automaticamente (o event.recurrence_interval atributo)” .
recurring_frequency – Um número que indica quantas unidades (definidas por recurrence_interval_id ) tem que passar antes que este evento ocorra novamente (se for um evento recorrente). Para o exemplo anterior (reuniões diárias), definiríamos esse valor como 1.
recurring_times – O número de instâncias deste evento. Para o exemplo anterior, seria "5" (reuniões diárias de segunda a sexta).

Em seguida, precisaremos relacionar pessoas (conhecidas pelo usuário) com eventos. Uma lista de todas as pessoas inseridas por nossos usuários é armazenada no person tabela. Para cada pessoa, o usuário definirá um nome completo e quaisquer detalhes adicionais (se necessário).

Agora, essas pessoas podem estar relacionadas aos eventos do usuário. No related_event tabela, armazenaremos referências ao event e person bem como alguns details da natureza dessa relação. Observe que a mesma pessoa pode ser adicionada várias vezes para o mesmo evento. Isso pode fazer sentido se quisermos manter mais de um registro para apontar especificamente para algo especial (por exemplo, “convidar Sofia para a festa”; Sofia é uma convidada da festa e a cantora da banda na festa).

As duas tabelas restantes nesta área de assunto estão relacionadas às definições de ação.

As ações podem ser qualquer coisa relacionada ao evento. Por exemplo, se quisermos nos lembrar do aniversário da mamãe, seria ótimo se o aplicativo nos dissesse:“Comece a pensar no presente que você quer dar à sua mãe”, “Compre um presente para o aniversário da mamãe”, “Dê a mamãe Presente de B-dia. E alguns beijos também” e, finalmente, “Você fez isso com sucesso novamente este ano. Bravo para você (e para mim)!”

Ok, vamos falar sério novamente. Ações são conjuntos de textos predefinidos que devem notificar os usuários quando fazer algo. Teremos um dicionário com tipos de ação predefinidos como "começar a pensar", "comprar um presente", "encontrar um músico", etc. Uma lista de todas essas ações ÚNICAS é armazenada no action_catalog tabela. Ao definir um evento, o usuário escolherá uma ou mais action s relacionados a esse evento e defina os seguintes valores para cada um deles:

event_id – O ID do evento relacionado.
action_catalog_id – Um valor selecionado do action_catalog dicionário.
description – Uma descrição opcional dessa ação. Cada vez que essa ação for acionada, nosso aplicativo examinará esse atributo, lerá os comandos e executará essa ação.
action_code – Uma definição textual estruturada dessa ação.
starts_before – Define quantas unidades de tempo selecionadas decorrerão antes do início desta ação para o evento selecionado (se esta for uma ação recorrente). Se esse valor não for definido (ou seja, definido como NULL), as ações serão iniciadas no mesmo momento em que o evento for iniciado.
send_message – Um sinalizador indicando se uma mensagem deve ou não ser enviada ao usuário.
recurring – Indica se esta ação é recorrente ou não.
recurring_interval_id – Indica o intervalo/unidade para a recorrência (se esta for uma ação recorrente).
recurring_frequency – Indica o número de unidades selecionadas que devem decorrer entre duas recorrências da mesma ação (se esta for uma ação recorrente).
recurring_times – Quantas instâncias desta ação devemos criar?

A recorrência da ação segue o mesmo padrão da recorrência do evento. Se a ação for definida como recorrente, geraremos uma nova instância de ação após o período de tempo definido.

Seção 3:eventos e ações (reais)

Até agora, criamos um modelo de dados que nos permitiria inserir eventos e definir ações. Agora vamos passar para uma parte mais interessante do modelo:eventos e ações reais.

A event_instance tabela contém uma lista de todos os eventos que foram gerados automaticamente ou inseridos manualmente. Embora a geração automática seja bastante óbvia – é por isso que criamos este modelo – a inserção manual de eventos também é uma possibilidade. Podemos esperar que um evento seja inserido automaticamente no momento devido, então normalmente teríamos apenas eventos reais e passados nesta tabela. Ainda assim, pode acontecer que já tenhamos cuidado de algum evento futuro, por exemplo. preparamos para uma reunião que acontecerá no próximo mês. Nesse caso, devemos ser capazes de inserir manualmente um evento futuro (tempos de eventos sendo propostos de acordo com as regras definidas) e tudo relacionado a esse evento nesta tabela. Por outro lado, nosso aplicativo não substituirá ou duplicará esse evento. Ele reconhecerá os eventos que já inserimos usando o event_time valor. Para cada instância de evento, definiremos:

event_id – Faz referência ao event definição.
event_time – A hora real do evento, em formato textual estruturado.
insert_ts – O carimbo de data/hora real quando este evento foi inserido.
event_completed – Um valor booleano que indica se o evento foi concluído ou não. O evento é definido automaticamente como "concluído" se todas as ações relacionadas forem concluídas. Ele também pode ser definido manualmente como "concluído" pelo usuário.

O event_id – event_time par é a chave alternativa/ÚNICA desta tabela.

Lógica semelhante é usada para a action_instance tabela. As ações também serão geradas automaticamente quando forem devidas. Se uma ação for recorrente, teremos mais de uma ação definida para a mesma instância do evento. Para cada ação, definiremos:

action_id – Faz referência à action .
event_instance_id – Refere-se ao event_instance .
action_time – A hora real da ação, em formato textual estruturado.
insert_ts – Um carimbo de data/hora real quando este evento foi inserido.
action_completed – Um valor booleano que indica se a ação foi concluída ou não. A ação é definida como 'concluída' manualmente, pelo usuário. Se a instância de ação estiver definida como "concluída", novas instâncias não serão geradas (mesmo que a definição diga que deveriam ser).

Nesta tabela, a chave alternativa/ÚNICA é a combinação de action_id – event_instance_id – action_time .

A última tabela em nosso modelo é a message tabela. É usado para armazenar as mensagens geradas pelas ações. Essas mensagens são enviadas aos usuários. Para cada mensagem, armazenaremos:

action_instance_id – O ID da action_instance que gerou esta mensagem.
message_title – O título da mensagem.
message_text – O texto da mensagem, que contém uma descrição do motivo pelo qual esta mensagem foi gerada (ou seja, campos textuais das tabelas relacionadas).
insert_ts – O carimbo de data/hora em que esta mensagem foi gerada.
message_read – Um sinalizador que indica se a mensagem foi lida pelo usuário.

Compartilhe suas ideias sobre o modelo de dados de eventos importantes

Espero que tenham gostado do artigo de hoje. Você já se esqueceu de uma data importante? Você acha que esse modelo pode te ajudar? Por favor, conte-nos nos comentários abaixo.