Skip to content

GitLab

banco_dados · Changes

Page history
Update database with daily journal authored by Rafael Victor Ruwer Araujo's avatar Rafael Victor Ruwer Araujo
Hide whitespace changes
Inline Side-by-side
banco_dados.md
View page @ 4c03df10
......@@ -8,25 +8,25 @@
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_).
O desenvolvimento do banco de dados se deu de forma incremental, conforme as user stories foram sendo desenvolvidas nas sprints.
---
## Sprint 1
![Modelo conceitual do banco de dados.](files/db-conceitual.png)
**Modelo conceitual do banco de dados.**
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)
## Dados armazenados
**Figura 1: Modelo conceitual do banco de dados durante a sprint 1.**
### Fichas de anamnese
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.
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 abaixo.
**Tabela 1: Domínio dos valores dos sub-atributos _frequência_ dos atributos _medicamentos_ e _sintomas_.**
**Domínio dos valores dos sub-atributos _frequência_ dos atributos _medicamentos_ e _sintomas_.**
| Valor do campo | Descrição |
| -------------- | ------------------------------ |
......@@ -46,27 +46,12 @@ Os sub-atributos _frequência_, dos atributos _medicamentos_ e _hábitos_, possu
| `rarely` | raramente |
| `never` | nunca |
### Esquema físico<sup>1</sup>
#### 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:
O objeto `AnamnesisRecord` armazena 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)
......@@ -92,6 +77,57 @@ class AnamnesisRecord {
}
```
### Acompanhamento diário
O usuário deve conseguir usar a aplicação para um acompanhamento diário do seu humor, medicamentos, sintomas, nível de estresse e pressão arterial.
O acompanhamento do humor deve ser feito através do uso de emojis, para que o usuário possa facilmente indicar como se sente no momento que responde ao questionário de acompanhamento. Como emojis são caracteres [Unicode](https://home.unicode.org/), é possível armazená-los como dado textual no Firebase. Por conta disso, não foi preciso definir uma enumeração para mapear uma imagem para texto, nem persistir imagens dos emojis no Firebase. Isso permitiu a simplificação do modelo e da implementação da aplicação.
#### Esquema físico<sup>1</sup>
O objeto `JournalEntry` armazena as informações de uma entrada no acompanhamento diário, conforme definido abaixo:
```typescript
class JournalEntry {
humor: {
emotion: string // emoji
text: string // descrição do humor (raiva, feliz, ...)
}
bloodPressure: string // pressão arterial: XX/YY, XX e YY são números (ex. 12/8, 9/5, ...)
stressLevel: string // nível de estresse
symptoms: string[] // sintomas
medicines: string[] // medicamentos
}
```
### Exames
Ainda não definido.
---
## Esquema físico do banco de dados<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
}
journalEntries: {
[date: number /* YYYYMMDD */]: {
[time: number /* HHmmss */]: JournalEntry
}
}
// exames: ainda não definido
}
}
```
---
**<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).