Projetar Base de Dados
Analisar
Serviços
Arquiteto de
Software
Projetar
Arquitetura
Projetar
Serviços
Revisor de
projeto
Prototipar
Interface
gráfica
Arquiteto de
Informação
Analisar
Casos de Uso
Projetar
Casos de Uso
Analista de
Sistemas
Check
List
 bla bla
 bla
 blabla
Projetar
Subsistemas
<<subsystem>>
decisões do
arquiteto
Projetar
classes
Projetar
Base de Dados
Projetista de
Banco de Dados
Revisar
Projeto
Objetivos desta atividade
• Apresentar uma visão geral sobre tipos mais
usados de banco de dados
• Discutir orientações para o mapeamento
objeto-relacional
• Discutir formas de acesso aos dados
armazenados
• Aplicável tanto ao RUP como a SOA
Projetar base de dados | 3
Visão geral
• Sistemas de banco de dados (SGBD)
relacionais são a forma de armazenamento de
dados mais utilizadas atualmente
– Padrão estabelecido no mercado
– Ferramentas de suporte (backup/replicação)
– Velocidade no acesso aos dados
Projetar base de dados| 4
Visão geral
• A mudança de paradigma de programação
para a orientação a objetos gerou um série de
tentativas para migração do paradigma de
armazenamento de dados
– Banco de dados orientado a objetos (BDOO)
• Mais próximo das linguagens de programação
– Banco de dados objeto-relacional (BDOR)
• Extensão do modelo relacional com suporte OO
Projetar base de dados| 5
Banco de dados orientado a objetos
• Mapeamento direto de objetos para persistência
• Suporte a tipos de dados complexos
– Especialização / Generalização
– Tipos complexos
– Comportamento de objetos
• Problemas:
– Falta de padronização e base formal
• Tentativa de padronização: ODMG
– Grande esforço tecnológico e financeiro para migração
– Velocidade na recuperação da informação
– Ferramentas de apoio
• Backup/Replicação
Projetar base de dados| 6
Banco de dados objeto relacional
• Pode ser visto como uma camada de abstração
construída sobre a tecnologia relacional
• Mantém as vantagens do modelo relacional e
acrescentam características do modelo OO
– Modelo eficiente (Relacional)
– Modelo rico (OO)
• O padrão SQL:1999 (ou SQL3) incorpora as
abstrações necessárias para suporte ao modelo
de dados OR
Projetar base de dados| 7
Classificação dos SGBDs
Com Linguagem
Declarativa
BD Relacionais
BDOR
Sistemas de arquivos
BDOO
Consultas
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 8
Classificação dos SGBDs
-Dados são registros de
tamanho fixo;
Com Linguagem
Declarativa
Consultas
- Poucas consultas prédefinidas,
em geral buscas
BD Relacionais
por igualdade de campos
dos registros.
Sistemas de arquivos
BDOR
BDOO
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 9
- Dados são linhas de
tabelas cujos atributos
possuem domínios simples
Classificação dos SGBDs
- Flexibilidade de consultas
com SQL
Com Linguagem
Declarativa
BD Relacionais
BDOR
Sistemas de arquivos
BDOO
Consultas
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 10
Classificação dos SGBDs
- Dados são objetos com
estruturas complexas
Com Linguagem
Declarativa
BD Relacionais
- Capacidade de consulta
limitada,
baseada em
BDOR
navegabilidade por objetos
Consultas
Sistemas de arquivos
BDOO
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 11
- Dados são tabelas com
estruturas complexas
Classificação dos SGBDs
- Uso do padrão SQL
estendido (SQL3) para
garantir flexibilidade nas
consultas
Com Linguagem
Declarativa
BD Relacionais
BDOR
Sistemas de arquivos
BDOO
Consultas
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 12
Classificação dos SGBDs
Com Linguagem
Declarativa
BD Relacionais
BDOR
Sistemas de arquivos
BDOO
Consultas
Sem Linguagem
Declarativa
Simples
Dados
Complexos
Projetar base de dados| 13
Tendência
• As maiores empresas de desenvolvimento de SGBD’s estão
investindo no SGBD Objeto-Relacional (OR)
– Oracle
– IBM/DB2
– PostgreSQL
• Versões atuais de suas ferramentas já suportam mecanismos
OR
• Problemas
– Devido a maior gama de tipos e estruturas de dados a performance
não é a mesma de um SGBDR
– Ainda não existem muitas ferramentas que suportem os modelos de
dados OR
Projetar base de dados| 14
Tendência
• O uso do modelo de dados Objeto-Relacional
ainda está se difundindo
• O modelo relacional ainda é o dominante no
mercado
Projetar base de dados| 15
Considerações
• Vamos assumir um SGBD relacional como
meio de armazenamento
• Passos para outros meios de armazenamento
não estão contemplados
• Sugestões para aumentar desempenho devem
ser discutidas com o projetista responsável
(geralmente um DBA)
Projetar base de dados | 16
Considerações
• O diagrama de classes está no mesmo nível de
abstração do esquema lógico de banco de
dados, porém utilizando outro paradigma
• O processo apresentado se baseia em uma
série de passos a serem executados para
efetuar a migração entre os paradigmas OO e
relacional
• Questionamentos sobre o modelo de classes
(particularmente os relacionamentos) podem
surgir e devem ser discutidos com os analistas
Projetar base de dados| 17
Visão geral dos artefatos
Modelo de
Análise e Projeto
Requisitos Não
Funcionais
Projetista de
Banco de Dados
Projetar Base
de Dados
Projeto de
Banco de
Dados
Projetar base de dados | 18
Passos para Projetar base de dados
1. Mapear classes persistentes
2. Mapear relacionamentos das classes
persistentes
3. Identificar índices
4. Definir restrições de integridade
5. Definir características de armazenamento
6. Criar estruturas de armazenamento
7. Definir forma de acesso aos dados
Projetar base de dados | 19
Passo 1. Mapear classes persistentes
• Mapear classes em tabelas
– Em geral, não é um mapemanto 1:1
• Mapear atributos em colunas
•
Tipos primitivos usados no diagrama de classes
geralmente tem seu correspondente no BD
• Identificar chaves
Projetar base de dados | 20
Mapear atributos em colunas
• Regra geral - mapear diretamente
– cada atributo transforma-se em uma coluna
• Atributos complexos - como mapear?
Cliente
nome : String
telefone : String
enderecoResidencial : Endereco
Endereco
logradouro
numero
bairro
cidade
estado
país
CEP
Projetar base de dados | 21
Mapear atributos em colunas
• Mapeamento de atributos complexos
Cliente
Cliente
nome : String
telefone : String
enderecoResidencial : Endereco
clienteID (PK)
nome
telefone
logradouro
numero
cidade
estado
país
CEP
Projetar base de dados | 22
Mapear atributos em colunas
• Considerar também os valores máximos e
mínimos para cada atributo
• O atributo pode ser chave?
– Preferencialmente, um único atributo para chave
– Chaves devem ser estáveis!
– Colunas com valores seqüenciais gerados
automaticamente
Projetar base de dados | 23
Mapear classes em tabelas
• Analisar as classes persistentes
• O mapeamento dificilmente será direto
– hierarquias de classes
Projetar base de dados | 24
Mapear classes em tabelas
• Como mapear?
Pessoa
nome
endereco
telefone
Fornecedor
produto
Funcionario
salario
dataInicio
horasTrabalhadas
Projetar base de dados | 25
Mapear classes em tabelas
• Estratégias de mapeamento
– uma única tabela para todas as classes da hierarquia
– uma tabela para cada classe da hierarquia
– uma tabela para cada classe concreta da hierarquia
• Devem ser levados em consideração
– Espaço em disco
– Facilidade no acesso aos dados
– Velocidade no acesso aos dados
Projetar base de dados | 26
Mapear classes em tabelas
Pessoa
nome
endereco
telefone
Diagrama de classes
Funcionario
salario
dataInicio
horasTrabalhadas
Fornecedor
produto
Uma única tabela
para todas as classes
da hierarquia
Uma tabela para cada
classe da hierarquia
Pessoa
pessoaID (PK)
nome
endereco
telefone
Pessoa
pessoaID (PK)
nome
endereco
telefone
produto
salario
dataInicio
tipoDoObjeto
Fornecedor
pessoaID (PK,FK)
produto
Funcionario
pessoaID (PK,FK)
salario
dataInicio
Uma tabela para cada
classe concreta da
hierarquia
Fornecedor
pessoaID (PK)
nome
endereco
telefone
produto
Funcionario
pessoaID (PK)
nome
endereco
telefone
salario
dataInicio
Projetar base de dados | 27
Passo 2. Mapear relacionamentos das
classes persistentes
• Relacionamentos 1 para 1
• Relacionamentos 1 para muitos
• Relacionamentos muitos para muitos
Projetar base de dados | 28
Relacionamentos 1 para 1
• Como mapear?
Funcionario
salario
dataInicio
CartaoPonto
horasTrabalhadas
1
0..1
Projetar base de dados | 29
Relacionamentos 1 para 1
• Chaves estrangeiras - FK (foreign key)
– se as classes tiverem relacionamentos com outras
classes
• Fusão das tabelas
– se uma das classes for não persistente
• A decisão é caso-a-caso
Projetar base de dados | 30
Relacionamentos 1 para 1
Funcionario
Funcionario
CartaoPonto
salario
dataInicio
CartaoPonto
pessoaID (PK)
cartaoPontoID (PK)
salario
horasTrabalhadas
dataInicio
pessoaID (FK)
Mapeamento usando chaves
estrangeiras
horasTrabalhadas
1
0..1
Funcionario
pessoaID (PK)
salario
dataInicio
horasTrabalhadas
Mapeamento usando fusão
de tabelas
Projetar base de dados | 31
Relacionamentos um para muitos
• Como mapear?
Funcionario
salario
dataInicio
Atividade
nome
1
1..*
Projetar base de dados | 32
Relacionamentos um para muitos
• Mapeados através de chaves estrangeiras
• A chave estrangeira é inserida na tabela com multiplicidade *
do relacionamento
Funcionario
Funcionario
salario
dataInicio
Atividade
nome
1
1..*
pessoaID (PK)
salario
dataInicio
Atividade
atividadeID (PK)
nome
pessoaID (FK)
Projetar base de dados | 33
Relacionamentos muitos para muitos
• Precisam de uma tabela extra para representar a associação
Cliente
Cliente
Conta
nome
numero
telefone
enderecoResidencial : Endereco
1..*
Conta
clienteID (PK)
contaID (PK)
nome
numero
telefone
saldo
enderecoResidencial
1..* saldo
ClienteConta
clienteID (FK)
contaID (FK)
Projetar base de dados | 34
Passo 3. Identificar índices
• Otimização de consultas
• Custo extra na inclusão, remoção e atualização
de dados
– Não aconselhável em tabelas pequenas
Projetar base de dados | 35
Que colunas indexar?
• Chaves primárias são sempre indexadas
• Consultas x operações de manutenção
(inclusão/atualização/remoção de dados)
• Analisar descrições dos casos de uso e
requisitos não funcionais
– freqüência das operações
– requisitos de desempenho
Projetar base de dados | 36
Passo 4. Definir restrições de integridade
• Definir restrições sobre as informações que serão
armazenadas.
• Definir se serão utilizados ou não os recursos do SGBD para
implementação das restrições
– restrições de integridade para chaves primárias e estrangeiras
(usualmente criadas automaticamente)
– restrições relacionadas a regras de negócio não são
implementadas pelo banco automaticamente
• Implementação no banco ou na aplicação (por exemplo, na fachada)?
• Determinar como essas restrições serão implementadas
(triggers, procedures, etc.)
Projetar base de dados | 37
Passo 5. Definir características de
armazenamento
• Definição de requisitos de espaço e
organização física para o banco de dados
– Densidade das informações nas páginas de disco
– Localização das páginas de disco através de drivers
de disco
– Espaço em disco alocado para as estruturas de
dados
Projetar base de dados | 38
Passo 6. Criar estruturas de
armazenamento
• Normalmente é feito por um DBA
• Usar ferramenta como apoio
• Envolve:
–
–
–
–
criar a base de dados, tabelas, colunas, etc.
definir índices para chaves primárias
popular tabelas de referência (ex.: estados do brasil)
...
Projetar base de dados | 39
Passo 7. Definir forma de acesso aos
dados
• Existem 2 formas básicas para a aplicação ter acesso aos
dados que estão no banco de dados
– Acesso via o driver do banco de dados (JDBC)
– Utilização de um framework ORM (Object Relational Mapper) para
acesso a dados
• As duas abordagens não invalidam a estrutura da camada de
persistência modelada até agora para a aplicação
• Hoje a maioria das aplicações utiliza um framework ORM para
acesso aos dados
Acesso via o driver do banco de dados
• O acesso via o driver do banco de dados exige que o
desenvolvedor escreva as consultas diretamente em
linguagem SQL
• O código em SQL fica dentro do código da aplicação
• Essa abordagem de acesso aos dados exige um re-trabalho
maior se for necessária a mudança do SGBD escolhido
– Todas as consultas devem ser revisadas, pois mesmo havendo um
padrão, os desenvolvedores dos SGBD adicionam funções ou
construções não compatíveis entre os SGBD
Utilizando um framework ORM
• Os desenvolvedores se preocupam apenas em
entender o funcionamento do framework
• Todo o acesso aos dados é gerenciado pelo
framework escolhido
– Gerenciamento de conexão com o BD
• Todas as configurações de acesso aos dados
são feitas no framework
– Maior controle sobre como os dados são
acessados
Alguns exemplos de Frameworks ORM
• Varia de acordo com a linguagem de programação
Java
Hibernate
JDO
.NET
NHibernate
iBATIS
Python
Strom
Django ORM
Observações
• Utilizar um framework ORM é interessante
para evitar muitos esforços na hora de mudar
o SGBD escolhido
• Deve-se levar em consideração o tempo que
será gasto para a equipe aprender a usar um
ORM