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

banco_dados · Changes

Page history
Document database authored Sep 06, 2019 by Rafael Victor Ruwer Araujo's avatar Rafael Victor Ruwer Araujo
Conceptual and physical model created in sprint 1. Bruno, Eduardo e Rafael.
Hide whitespace changes
Inline Side-by-side
banco_dados.md
View page @ 0af7075b
...@@ -4,8 +4,92 @@ ...@@ -4,8 +4,92 @@
# Página do Banco de Dados # Página do Banco de Dados
Aqui deve ser explicado com modelos e explicações como o Banco de Dados foi construido, onde se deve focar em: A aplicação utiliza o [Firebase](https://firebase.google.com/) 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_).
* Como ele foi desenvolvido, com Imagens e Diagramas O desenvolvimento do banco de dados se deu de forma incremental, conforme as user stories foram sendo desenvolvidas nas sprints.
* o Collections(Entities)
* o ScriptSQL ---
\ No newline at end of file
## 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.](files/db-conceitual-s1.png)
**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ísico<sup>1</sup>
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:
```typescript
{ // 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:
```typescript
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
}
```
---
**<sup>1</sup>:** a definição dos esquemas físicos está usando uma sintaxe parecida com a do [TypeScript](https://www.typescriptlang.org/), 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