# Fundamentos de Modelagem de Dados

## 1. Arquitetura de Dados

A **arquitetura de dados** define a estrutura, organização e integração dos ativos de dados de uma organização. É um blueprint que descreve como os dados são coletados, armazenados, transformados e distribuídos.

### Componentes Principais:
- **Modelos de dados**: Representações conceituais, lógicas e físicas
- **Fluxo de dados**: Como os dados se movem entre sistemas
- **Armazenamento**: Bancos de dados, data warehouses, data lakes
- **Integração**: APIs, ETL, mensageria
- **Governança**: Políticas, padrões e controles

### Objetivos:
- Eliminar redundância e inconsistência
- Facilitar integração entre sistemas
- Suportar decisões de negócio
- Garantir qualidade e segurança dos dados

---

## 2. Modelagem de Dados

A modelagem de dados é o processo de criar uma representação visual das estruturas de dados e suas relações. Existem três níveis principais:

### 2.1 Modelagem Conceitual

**Objetivo**: Representar a visão de negócio dos dados, independente de tecnologia.

**Características**:
- Alto nível de abstração
- Foco em entidades e relacionamentos
- Não considera implementação técnica
- Uso de Modelo Entidade-Relacionamento (MER)

**Elementos**:
- **Entidades**: Objetos do mundo real (Cliente, Produto, Pedido)
- **Atributos**: Propriedades das entidades (nome, CPF, data)
- **Relacionamentos**: Conexões entre entidades (Cliente REALIZA Pedido)
- **Cardinalidade**: 1:1, 1:N, N:M

**Notações Comuns**:
- Diagrama Entidade-Relacionamento (DER) - Peter Chen
- UML (Unified Modeling Language)

**Exemplo**:

CLIENTE (1,N) ----realiza---- (0,N) PEDIDO
   |                              |
   CPF                         número
   nome                        data
   telefone                    valor

Outro exemplo


### 2.2 Modelagem Lógica

**Objetivo**: Detalhar o modelo conceitual com estruturas que podem ser implementadas em SGBDs, mas ainda independente de tecnologia específica.

**Características**:
- Nível intermediário de abstração
- Define tipos de dados
- Especifica chaves primárias e estrangeiras
- Aplica normalização
- Independente de SGBD específico

**Elementos Adicionais**:
- **Chave Primária (PK)**: Identificador único
- **Chave Estrangeira (FK)**: Referência entre tabelas
- **Tipos de dados**: VARCHAR, INTEGER, DATE, etc.
- **Restrições de integridade**: NOT NULL, UNIQUE, CHECK

**Exemplo**:

CLIENTE
- CPF (PK) VARCHAR(11)
- nome VARCHAR(100) NOT NULL
- telefone VARCHAR(15)
- email VARCHAR(100) UNIQUE

PEDIDO
- numero (PK) INTEGER
- data DATE NOT NULL
- valor DECIMAL(10,2)
- cpf_cliente (FK) VARCHAR(11)

### 2.3 Modelagem Física

**Objetivo**: Implementar o modelo lógico em um SGBD específico, otimizando performance.

**Características**:
- Dependente de tecnologia
- Considera aspectos de armazenamento
- Define índices, partições, tablespaces
- Otimização de consultas

**Elementos Específicos**:
- **Índices**: B-Tree, Hash, Bitmap
- **Particionamento**: Horizontal, Vertical
- **Tablespaces**: Organização física do armazenamento
- **Views materializadas**: Pré-computação de resultados
- **Triggers e Stored Procedures**: Lógica no banco

**Exemplo (SQL Server)**:

CREATE TABLE Cliente (
    CPF CHAR(11) PRIMARY KEY,
    Nome NVARCHAR(100) NOT NULL,
    Telefone VARCHAR(15),
    Email VARCHAR(100) UNIQUE,
    INDEX idx_nome (Nome)
) ON [PRIMARY];

CREATE TABLE Pedido (
    Numero INT IDENTITY(1,1) PRIMARY KEY,
    Data DATETIME NOT NULL DEFAULT GETDATE(),
    Valor DECIMAL(10,2),
    CPF_Cliente CHAR(11) FOREIGN KEY REFERENCES Cliente(CPF)
) ON [PRIMARY];

---

## 3. Criação e Alteração de Modelos

### 3.1 Ciclo de Vida da Modelagem

1. **Levantamento de Requisitos**: Entender necessidades do negócio
2. **Modelagem Conceitual**: Criar DER inicial
3. **Modelagem Lógica**: Refinar com normalização
4. **Modelagem Física**: Implementar no SGBD
5. **Validação**: Testar e ajustar
6. **Manutenção**: Evoluir conforme necessidade

### 3.2 Alteração de Modelos

**Modelo Lógico**:
- Adicionar/remover entidades ou atributos
- Modificar relacionamentos
- Ajustar cardinalidades
- Reaplicar normalização

**Modelo Físico**:

-- Adicionar coluna
ALTER TABLE Cliente ADD DataNascimento DATE;

-- Modificar tipo de dado
ALTER TABLE Cliente ALTER COLUMN Telefone VARCHAR(20);

-- Adicionar restrição
ALTER TABLE Cliente ADD CONSTRAINT chk_email CHECK (Email LIKE '%@%');

-- Criar índice
CREATE INDEX idx_email ON Cliente(Email);

-- Remover coluna
ALTER TABLE Cliente DROP COLUMN Telefone;

### 3.3 Impactos de Alterações

- **Aplicações**: Código precisa ser atualizado
- **Performance**: Índices podem precisar ser recriados
- **Dados existentes**: Podem requerer migração
- **Integridade**: Validar consistência após mudanças

---

## 4. Técnicas de Engenharia Reversa

**Engenharia Reversa** é o processo de extrair modelos lógicos e conceituais a partir de bases de dados físicas existentes.

### 4.1 Objetivos

- Documentar sistemas legados
- Compreender estruturas complexas
- Facilitar manutenção e evolução
- Base para migração de sistemas

### 4.2 Processo

1. **Extração de Metadados**: Consultar catálogo do SGBD
2. **Identificação de Entidades**: Analisar tabelas
3. **Mapeamento de Relacionamentos**: FK revelam relacionamentos
4. **Recuperação de Regras de Negócio**: Constraints, triggers
5. **Desnormalização Reversa**: Identificar normalização aplicada
6. **Criação do Modelo Lógico**: Abstrair detalhes físicos
7. **Geração do Modelo Conceitual**: Visão de alto nível

### 4.3 Ferramentas

- **SQL Power Architect**
- **ERwin Data Modeler**
- **MySQL Workbench** (reverse engineering)
- **Oracle SQL Developer Data Modeler**
- **DBSchema**

### 4.4 Exemplo de Extração

-- Extrair estrutura de tabelas (PostgreSQL)
SELECT 
    table_name,
    column_name,
    data_type,
    is_nullable
FROM information_schema.columns
WHERE table_schema = 'public';

-- Identificar chaves estrangeiras
SELECT
    tc.table_name, 
    kcu.column_name,
    ccu.table_name AS foreign_table_name,
    ccu.column_name AS foreign_column_name
FROM information_schema.table_constraints AS tc
JOIN information_schema.key_column_usage AS kcu
    ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage AS ccu
    ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY';

---

## 5. Avaliação de Modelos de Dados

### 5.1 Critérios de Qualidade

**1. Completude**
- Cobre todos os requisitos do negócio?
- Todas as entidades necessárias estão representadas?

**2. Correção**
- Relacionamentos corretos?
- Cardinalidades apropriadas?
- Tipos de dados adequados?

**3. Simplicidade**
- Fácil de entender?
- Evita complexidade desnecessária?

**4. Flexibilidade**
- Suporta mudanças futuras?
- Extensível sem grandes refatorações?

**5. Integração**
- Compatível com sistemas existentes?
- Reutiliza estruturas quando apropriado?

**6. Performance**
- Otimizado para consultas frequentes?
- Índices apropriados?

**7. Normalização**
- Nível adequado de normalização?
- Evita redundância?

### 5.2 Técnicas de Validação

**Revisão por Pares (Peer Review)**:
- Especialistas técnicos revisam o modelo
- Identificam inconsistências e melhorias

**Prototipação**:
- Implementar parte do modelo
- Testar com dados reais
- Validar consultas típicas

**Simulação de Carga**:
- Estimar volume de dados
- Testar performance de consultas críticas

**Validação com Stakeholders**:
- Apresentar modelo para usuários de negócio
- Confirmar que atende requisitos

### 5.3 Métricas

- **Número de tabelas**: Complexidade geral
- **Grau de normalização**: Nível de redundância
- **Número de relacionamentos**: Integração entre entidades
- **Profundidade de hierarquia**: Complexidade de herança
- **Taxa de reuso**: Entidades compartilhadas

### 5.4 Checklist de Revisão

- [ ] Todas as entidades têm chave primária?
- [ ] Relacionamentos N:M foram resolvidos com tabela associativa?
- [ ] Atributos derivados foram minimizados?
- [ ] Nomes seguem padrões de nomenclatura?
- [ ] Tipos de dados são apropriados?
- [ ] Constraints de integridade estão definidas?
- [ ] Índices foram planejados?
- [ ] Documentação está completa?

---

## Resumo do Módulo

A modelagem de dados é fundamental para construir sistemas de informação robustos. Os **três níveis** (conceitual, lógico, físico) permitem evoluir gradualmente de uma visão de negócio para implementação técnica. A **engenharia reversa** é essencial para documentar e modernizar sistemas legados. A **avaliação contínua** garante que os modelos atendam requisitos funcionais e não-funcionais.

---

# 📝 QUESTÕES DE CONCURSO

## Questão 1 (CESPE - Banco do Brasil - 2021)
A modelagem conceitual de dados tem como objetivo representar a estrutura de dados de forma independente de qualquer sistema gerenciador de banco de dados específico, devendo incluir a definição de índices e tablespaces para otimização de desempenho.

<details>
<summary>👉 Ver Resposta</summary>

**ERRADO**

**Explicação**: A modelagem conceitual é de alto nível e independente de implementação técnica. A definição de índices e tablespaces é característica da **modelagem física**, que é dependente do SGBD específico. No nível conceitual, focamos apenas em entidades, atributos e relacionamentos do ponto de vista de negócio.

</details>

---

## Questão 2 (FCC - TRT - 2019)
No processo de modelagem de dados, a engenharia reversa é utilizada para:

a) Criar o modelo físico a partir do modelo conceitual
b) Gerar automaticamente índices de performance
c) Extrair o modelo lógico a partir do banco de dados implementado
d) Normalizar tabelas existentes
e) Criar triggers e stored procedures

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA C**

**Explicação**: A engenharia reversa consiste em extrair modelos lógicos (e eventualmente conceituais) a partir de bancos de dados físicos já implementados. É o processo inverso da modelagem tradicional. Útil para documentar sistemas legados ou entender estruturas complexas existentes.

- **A** é engenharia direta (forward engineering)
- **B** não é o objetivo principal da engenharia reversa
- **D** é uma técnica de refinamento de modelos, não necessariamente reversa
- **E** são elementos de implementação física, não modelagem

</details>

---

## Questão 3 (CESGRANRIO - Petrobras - 2018)
Considere as seguintes afirmações sobre modelagem de dados:

I. No modelo lógico, são definidas as chaves primárias e estrangeiras.
II. O modelo físico é independente do SGBD utilizado.
III. O modelo conceitual utiliza a notação de Diagrama Entidade-Relacionamento.

Está(ão) correto(s):

a) Apenas I
b) Apenas II
c) Apenas III
d) Apenas I e III
e) I, II e III

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA D (I e III)**

**Explicação**:

**I. CORRETO**: No modelo lógico, definimos as chaves primárias (PK) e estrangeiras (FK), tipos de dados e restrições de integridade, mas ainda de forma independente de SGBD específico.

**II. ERRADO**: O modelo físico é **dependente** do SGBD. Nele consideramos características específicas como índices, particionamento, tablespaces, sintaxe SQL específica do banco (Oracle, SQL Server, PostgreSQL, etc.).

**III. CORRETO**: O modelo conceitual frequentemente utiliza o DER (Diagrama Entidade-Relacionamento) ou notação UML para representar entidades e relacionamentos de forma visual e abstrata.

</details>

---

## Questão 4 (CESPE - CAIXA - 2021)
Na avaliação de um modelo de dados, é correto afirmar que:

a) A desnormalização sempre prejudica a qualidade do modelo
b) Modelos altamente normalizados sempre garantem melhor performance
c) A simplicidade deve ser equilibrada com a completude dos requisitos
d) Quanto mais tabelas, melhor a qualidade do modelo
e) A flexibilidade não é um critério relevante de avaliação

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA C**

**Explicação**: A avaliação de modelos requer equilíbrio entre múltiplos critérios. A **simplicidade** facilita manutenção e compreensão, mas deve atender todos os requisitos (completude). É um trade-off importante.

**Por que as outras estão erradas:**

- **A**: A desnormalização pode ser necessária para performance em consultas específicas (data warehouses, por exemplo)
- **B**: Excesso de normalização pode prejudicar performance devido a JOINs complexos
- **D**: Qualidade não é medida por quantidade de tabelas, mas por adequação aos requisitos
- **E**: Flexibilidade é crucial para permitir evolução do sistema sem grandes refatorações

</details>

---

## Questão 5 (FGV - Banco do Brasil - 2022)
Um analista recebeu a tarefa de documentar um sistema legado de 15 anos que não possui documentação atualizada. O banco de dados possui 200 tabelas interligadas. Qual técnica é mais adequada para esta situação?

a) Modelagem conceitual bottom-up
b) Engenharia reversa
c) Normalização incremental
d) Prototipação rápida
e) Modelagem dimensional

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA B**

**Explicação**: Para documentar um sistema legado existente, a **engenharia reversa** é a técnica adequada. Ela permite extrair modelos lógicos e conceituais a partir do banco de dados físico implementado, recuperando estruturas, relacionamentos e regras de negócio que não estão documentadas.

As outras alternativas não se aplicam:
- **A**: Modelagem conceitual é para novos sistemas
- **C**: Normalização trabalha com modelos já documentados
- **D**: Prototipação é para validar requisitos de novos sistemas
- **E**: Modelagem dimensional é para data warehouses/BI

</details>

---

## Questão 6 (CESPE - TRE - 2020)
Durante a criação de um modelo lógico, um DBA identificou que uma entidade "Funcionario" possui os atributos: CPF, Nome, Endereco_Rua, Endereco_Numero, Endereco_Cidade, Endereco_Estado, Departamento_Codigo, Departamento_Nome. Qual o principal problema deste modelo e como corrigi-lo?

<details>
<summary>👉 Ver Resposta</summary>

**RESPOSTA:**

O modelo apresenta **dois problemas principais**:

1. **Violação da 1FN (Primeira Forma Normal)**: Os atributos de endereço são compostos e deveriam ser atômicos ou agrupados em uma entidade separada.

2. **Dependência transitiva**: Os atributos de departamento (Departamento_Codigo e Departamento_Nome) criam dependência entre atributos não-chave, violando a 3FN.

**Correção sugerida:**

Criar três entidades:

FUNCIONARIO
- CPF (PK)
- Nome
- ID_Endereco (FK)
- Codigo_Departamento (FK)

ENDERECO
- ID_Endereco (PK)
- Rua
- Numero
- Cidade
- Estado

DEPARTAMENTO
- Codigo (PK)
- Nome

Isso elimina redundância, facilita manutenção e garante integridade referencial.

</details>

---

## Questão 7 (FCC - TRT - 2023)
Sobre os níveis de modelagem de dados, analise:

I. A modelagem física define como os dados serão armazenados fisicamente no disco.
II. Cardinalidade de relacionamentos é definida apenas no modelo físico.
III. O modelo lógico já especifica tipos de dados, mas não a sintaxe SQL específica.
IV. Índices são planejados no modelo conceitual para garantir performance desde o início.

Estão CORRETAS:

a) I e II
b) I e III
c) II e IV
d) I, II e III
e) Todas

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA B (I e III)**

**Explicação detalhada:**

**I. CORRETO**: O modelo físico define aspectos de armazenamento como tablespaces, particionamento, organização física em disco, compressão, etc.

**II. ERRADO**: A cardinalidade (1:1, 1:N, N:M) é definida já no **modelo conceitual** e mantida no lógico e físico. É uma característica do relacionamento entre entidades, não de implementação.

**III. CORRETO**: O modelo lógico especifica tipos de dados (VARCHAR, INTEGER, DATE) mas permanece independente de SGBD específico, não definindo sintaxe particular (exemplo: NVARCHAR do SQL Server vs VARCHAR do PostgreSQL).

**IV. ERRADO**: Índices são elementos de **otimização física**, não fazem parte do modelo conceitual que é focado apenas em entidades e relacionamentos de negócio.

</details>

---

## Questão 8 (VUNESP - IPSM - 2022)
Um modelo de dados bem avaliado deve apresentar qual das seguintes características?

a) Maximizar a quantidade de tabelas para garantir flexibilidade
b) Eliminar todas as formas de redundância, mesmo que prejudique performance
c) Equilibrar normalização com requisitos de performance
d) Priorizar sempre a 5FN (Quinta Forma Normal) em todos os casos
e) Evitar uso de chaves estrangeiras para reduzir complexidade

<details>
<summary>👉 Ver Resposta</summary>

**ALTERNATIVA C**

**Explicação**: Um modelo de dados de qualidade deve **equilibrar** diversos fatores, especialmente normalização e performance. Nem sempre a normalização máxima é ideal - em data warehouses e sistemas de leitura intensiva, alguma desnormalização controlada pode ser benéfica.

**Análise das outras alternativas:**

- **A**: Quantidade de tabelas não garante flexibilidade; pode gerar complexidade excessiva
- **B**: Eliminar toda redundância pode prejudicar severamente consultas e relatórios
- **D**: A 5FN é raramente necessária; geralmente 3FN é suficiente para sistemas transacionais
- **E**: Chaves estrangeiras são essenciais para garantir integridade referencial

**Conceito-chave**: Não existe modelo "perfeito", mas sim modelos **adequados** ao contexto (OLTP vs OLAP, requisitos de performance, volume de dados, etc.).

</details>

---