projetar base de dados

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


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


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


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


Classificação dos SGBDs

BD Relacionais BDOR

Sistemas de arquivos BDOO


Simples Complexos

Com Linguagem Declarativa

Sem Linguagem Declarativa

Consultas

Dados


BD Relacionais BDOR



Simples Complexos



Consultas

Dados

-Dados são registros de tamanho fixo;

- Poucas consultas pré-definidas, em geral buscas por igualdade de campos dos registros.


BD Relacionais BDOR



Simples Complexos



Consultas

Dados

- Dados são linhas de tabelas cujos atributos possuem domínios simples

- Flexibilidade de consultas com SQL


BD Relacionais BDOR



Simples Complexos



Consultas

Dados

- Dados são objetos com estruturas complexas

- Capacidade de consulta limitada, baseada em navegabilidade por objetos


BD Relacionais BDOR



Simples Complexos



Consultas

Dados

- Dados são tabelas com estruturas complexas

- Uso do padrão SQL estendido (SQL3) para garantir flexibilidade nas consultas


BD Relacionais BDOR



Simples Complexos



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


Tendência

• O uso do modelo de dados Objeto-Relacional ainda está se difundindo

• O modelo relacional ainda é o dominante no mercado


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)


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


Visão geral dos artefatos


Projeto de Banco de

Dados

Projetista de Banco 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


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


Mapear atributos em colunas• Regra geral - mapear diretamente

– cada atributo transforma-se em uma coluna

• Atributos complexos - como mapear?


Cliente

nome : Stringtelefone : StringenderecoResidencial : Endereco

Endereco

logradouronumerobairrocidadeestadopaísCEP

Mapear atributos em colunas• Mapeamento de atributos complexos


Cliente

nome : Stringtelefone : StringenderecoResidencial : Endereco

Cliente

clienteID (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


Mapear classes em tabelas

• Analisar as classes persistentes

• O mapeamento dificilmente será direto– hierarquias de classes



• Como mapear?


Pessoa

nomeendereco

telefone

Fornecedor

produto

Funcionario

salariodataIniciohorasTrabalhadas


• 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




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

Funcionario

pessoaID (PK,FK)salariodataInicio

Pessoa

pessoaID (PK)nomeenderecotelefone

Fornecedor

pessoaID (PK,FK)produto

Pessoa

nomeenderecotelefone

Fornecedorproduto

Funcionario

salariodataIniciohorasTrabalhadas

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


Relacionamentos 1 para 1

• Como mapear?


Funcionario

salariodataInicio

CartaoPonto

horasTrabalhadas0..111 0..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




Funcionario

salario

dataInicio

CartaoPonto

horasTrabalhadas0..111 0..1

Mapeamento usando chaves estrangeiras

Mapeamento usando fusão de tabelas

Funcionario

pessoaID (PK)

salario

dataInicio

CartaoPonto

cartaoPontoID (PK)

horasTrabalhadas

pessoaID (FK)

Funcionario

pessoaID (PK)

salario

dataInicio

horasTrabalhadas

Relacionamentos um para muitos

• Como mapear?


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


Atividade

nome

Funcionario

salariodataInicio 1..*1 1..*1

Atividade

atividadeID (PK)nome

pessoaID (FK)

Funcionario

pessoaID (PK)salariodataInicio

Relacionamentos muitos para muitos

• Precisam de uma tabela extra para representar a associação


Cliente

clienteID (PK)

nome

telefone

enderecoResidencial

ClienteConta

clienteID (FK)

contaID (FK)

Conta

contaID (PK)

numero

saldoConta

numero

saldo

Cliente

nome

telefone

enderecoResidencial : 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


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


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.)


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


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)– ...


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

JavaHibernateJDO

.NETNHibernateiBATIS

PythonStromDjango 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

projetar base de dados

Documents