Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • HiperBem
  • wiki
  • Wiki
  • banco_dados

Last edited by Rafael Victor Ruwer Araujo Nov 11, 2019
Page history
This is an old version of this page. You can view the most recent version or browse the history.

banco_dados

Home Cronograma Sprints Requisitos Gerência de Projeto Horários Disponiveis
Mockups Banco de Dados Material de estudo Arquitetura Git Workflow Configuração
Padronização do Código Testes

Página do Banco de Dados

A aplicação utiliza o Firebase Realtime Database para a persistência de dados. O Realtime Database é um banco de dados de documentos NoSQL, sendo possível armazenar documentos JSON em qualquer estrutura, sem restrições de integridade (schema-less).

O desenvolvimento do banco de dados se deu de forma incremental, conforme as user stories foram sendo desenvolvidas nas sprints.


Sprint 1

Nessa sprint, foi inicializado o desenvolvimento do modelo de dados, modelando as fichas de anamnese de um usuário. Para isso, foi realizada uma modelagem conceitual levando em consideração os requisitos do projeto. A Figura 1 apresenta a modelagem conceitual desenvolvida.

Modelo conceitual do banco de dados durante a sprint 1.

Figura 1: Modelo conceitual do banco de dados durante a sprint 1.

Considerando que todas as informações de identificação de um usuário estão relacionadas a uma anamnese, atributos como nome, email e data de nascimento, por exemplo, estão ligados à entidade Anamnese, e não a Usuário.

O atributo modificações contém o nome dos atributos que foram modificados entre uma ficha de anamnese e a ficha imediatamente anterior. Essa informação é armazenada no Firebase para melhorar o desempenho da aplicação e reduzir a quantidade de requisições ao serviço de banco de dados. Desse modo, a diferença entre duas fichas é calculada apenas uma vez (na sua criação), e não toda vez que a mesma é exibida (o que necessitaria de uma requisição extra pela ficha anterior, além da execução de um algoritmo de diffing).

Os sub-atributos frequência, dos atributos medicamentos e hábitos, possuem uma restrição de integridade de domínio: pode ser apenas um valor de um conjunto de códigos de frequência suportados pela aplicação. Os valores predefinidos, e o significado dos mesmos, podem ser vistos na Tabela 1.

Tabela 1: Domínio dos valores dos sub-atributos frequência dos atributos medicamentos e sintomas.

Valor do campo Descrição
6-6h a cada 6h
8-8h a cada 8h
12-12h a cada 12h
24-24h a cada 24h
1xw uma vez por semana
1-3xw de uma a três vezes por semana
3xw três vezes por semana
+3xw mais de três vezes por semana
sm:-1d menos de um maço por dia
sm:1d um maço por dia
sm:+2d mais de dois maços por dia
daily diariamente
occasionaly ocasionalmente
rarely raramente
never nunca

Esquema físico1

Definiu-se que os dados serão armazenados no Firebase de acordo com a identificação do usuário. A partir do objeto raiz, cada usuário possui um objeto onde seu id é a chave, e suas anamneses, entradas no diário e exames são seu valor, conforme exemplo abaixo:

{ // raiz do Firebase
    [userId: string]: {
        anamneses: {
            [creationDate: number /* timestamp */]: AnamnesisRecord
        }
        
        // diário e exames serão definidos nas próximas sprints
    }
}

Os objetos AnamnesisRecord armazenam as informações de uma ficha de anamnese, conforme definido abaixo:

class AnamnesisRecord {
    creationDate: string        // data de criação: formato ISO 8601 (YYYY-MM-DDTHH:mm:ss)
    name: string                // nome
    email: string               // email
    birthDate: string           // data de nascimento: formato ISO 8601 (YYYY-MM-DD)
    weight: number              // peso: decimal, quilogramas
    height: number              // altura: inteiro, centímetros

    symptoms: string[]          // sintomas
    pathologies: string[]       // patologias
    familyPathologies: string[] // histórico familiar
    lifeRhythm: string          // ritmo de vida
    eatingStyle: string         // alimentação

    medicines: {                // medicamentos
        name: string            //   nome
        frequency: string       //   frequência (restrição de domínio)
    }[]
    habits: {                   // hábitos
        name: string            //   nome
        frequency: string       //   frequência (restrição de domínio)
    }[]

    changes: string[]           // modificações
}

1: a definição dos esquemas físicos está usando uma sintaxe parecida com a do TypeScript, por ser bastante parecida com a sintaxe de JSON (com a adição de tipos).

Clone repository
  • arquitetura
  • banco_dados
  • configuracao
  • cronograma
  • git workflow
  • gp
  • Home
  • horarios
  • material de estudo
  • mockups
  • padronização
  • requisitos
  • retrospectivas
  • sprints
  • testes