View
214
Download
1
Category
Preview:
Citation preview
Projetar Base de Dados
Arquiteto de Informação
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemas
Projetar Base de Dados
Analista deSistemas
CheckList bla bla bla blabla
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
decisões doarquiteto
<<subsystem>>
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
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 8
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
Classificação dos SGBDs
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 9
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
-Dados são registros de tamanho fixo;
- Poucas consultas pré-definidas, em geral buscas por igualdade de campos dos registros.
Classificação dos SGBDs
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 10
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
- Dados são linhas de tabelas cujos atributos possuem domínios simples
- Flexibilidade de consultas com SQL
Classificação dos SGBDs
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 11
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
- Dados são objetos com estruturas complexas
- Capacidade de consulta limitada, baseada em navegabilidade por objetos
Classificação dos SGBDs
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 12
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
- Dados são tabelas com estruturas complexas
- Uso do padrão SQL estendido (SQL3) para garantir flexibilidade nas consultas
Classificação dos SGBDs
BD Relacionais BDOR
Sistemas de arquivos BDOO
Projetar base de dados| 13
Simples Complexos
Com Linguagem Declarativa
Sem Linguagem Declarativa
Consultas
Dados
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
Projetar base de dados | 18
Projeto de Banco de
Dados
Projetista de Banco de
Dados
Projetar Base de Dados
Requisitos Não
FuncionaisModelo de Análise e Projeto
Passos para Projetar base de dados
1. Mapear classes persistentes 2. Mapear relacionamentos das classes
persistentes3. Identificar índices4. Definir restrições de integridade5. Definir características de armazenamento6. Criar estruturas de armazenamento7. 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?
Projetar base de dados | 21
Clientenome : Stringtelefone : StringenderecoResidencial : Endereco
EnderecologradouronumerobairrocidadeestadopaísCEP
Mapear atributos em colunas• Mapeamento de atributos complexos
Projetar base de dados | 22
Clientenome : Stringtelefone : StringenderecoResidencial : Endereco
ClienteclienteID (PK)nometelefonelogradouronumerocidadeestadopaísCEP
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?
Projetar base de dados | 25
Pessoanome
enderecotelefone
Fornecedorproduto
FuncionariosalariodataIniciohorasTrabalhadas
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
Projetar base de dados | 27
Diagrama de classes
Uma única tabela para todas as classes
da hierarquia
Uma tabela para cada classe da hierarquia
Uma tabela para cada classe concreta da
hierarquia
FuncionariopessoaID (PK,FK)salariodataInicio
PessoapessoaID (PK)nomeenderecotelefone
FornecedorpessoaID (PK,FK)produto
Pessoanomeenderecotelefone
Fornecedorproduto
FuncionariosalariodataIniciohorasTrabalhadas
FornecedorpessoaID (PK)nomeenderecotelefoneproduto
FuncionariopessoaID (PK)nomeenderecotelefonesalariodataInicio
PessoapessoaID (PK)nomeenderecotelefoneprodutosalariodataIniciotipoDoObjeto
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?
Projetar base de dados | 29
Funcionario
salariodataInicio
CartaoPontohorasTrabalhadas
0..111 0..1
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
Projetar base de dados | 31
Funcionario
salariodataInicio
CartaoPonto
horasTrabalhadas0..111 0..1
Mapeamento usando chaves estrangeiras
Mapeamento usando fusão de tabelas
Funcionario
pessoaID (PK)salariodataInicio
CartaoPonto
cartaoPontoID (PK)horasTrabalhadaspessoaID (FK)
Funcionario
pessoaID (PK)
salario
dataInicio
horasTrabalhadas
Relacionamentos um para muitos
• Como mapear?
Projetar base de dados | 32
Atividade
nome
Funcionario
salariodataInicio 1..*1 1..*1
Relacionamentos um para muitos• Mapeados através de chaves estrangeiras• A chave estrangeira é inserida na tabela com multiplicidade *
do relacionamento
Projetar base de dados | 33
Atividade
nome
Funcionario
salariodataInicio 1..*1 1..*1
AtividadeatividadeID (PK)nome
pessoaID (FK)
FuncionariopessoaID (PK)salariodataInicio
Relacionamentos muitos para muitos
• Precisam de uma tabela extra para representar a associação
Projetar base de dados | 34
Cliente
clienteID (PK)nometelefoneenderecoResidencial
ClienteConta
clienteID (FK)contaID (FK)
Conta
contaID (PK)numerosaldo
Conta
numerosaldo
Cliente
nometelefoneenderecoResidencial : Endereco 1..*1..* 1..*1..*
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 HibernateJDO
.NET NHibernateiBATIS
Python StromDjango 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
Recommended