Esquema de Banco de Dados e Mapeamento OO-Relacional

Esquema de banco de dados e mapeamento OO-Relacional
Referncias
H uma discusso detalhada de como tratar persistncia de objetos de vrias formas nos livros: Object-Oriented Modeling and Design for Database Applications, Blaha e Premerlani, Prentice Hall, 1998. Database Design for Smarties, Muller, Morgan Kaufmann Publishers, 1999. Este livro tambm cobre o mapeamento para SGBDs Objeto-Relacionais Nossa discusso um breve resumo do material desses dois livros Um tratamento completo no pode ser dado nesta disciplina devido a restries de tempo Tambm tem uma breve discusso de como montar um framework de persistncia no livro: Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design, Larman, Prentice-Hall, 1998. Frameworks profissionais de persistncia podem ser vistos nos
http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/proj1/proj9.htm[08/07/2013 21:27:59]
produtos TopLink e CocoBase Falaremos especialmente do mapeamento de um modelo OO para um esquema relacional No h tempo para tratar do mapeamento para SGBDs Objeto-Relacionais Supe-se uma certa familiaridade com o modelo relacional
Resumo da seo
Implementao da identidade de objetos Implementao de domains Implementao de classes Implementao de operaes Implementao de associaes simples Implementao de associaes avanadas Implementao de herana simples Implementao de herana mltipla Resumo dos passos para o mapeamento OO-Relacional
Implementao da identidade de objetos

Em SGBDOOs, objetos possuem identidade baseada na existncia, mas isso no automtico num SGBDR Com um SGBDR (ou quando usam-se arquivos para a persistncia), pode-se usar uma de duas alternativas: Identidade baseada na existncia O SGBDR gera um identificador nico (OID) para cada registro O OID armazenado numa coluna adicional e a chave primria da tabela Identidade baseada em valor Uma combinao de atributos identifica cada registro As duas alternativas podem ser misturadas num mesmo esquema Vantagens da identidade baseada na existncia A chave primria um atributo nico, pequeno e uniforme em tamanho Algumas tabelas no possuem uma combinao de atributos que possa ser chave primria Desvantagens da identidade baseada na existncia Alguns SGBDs podero no oferecer a gerao de
identificadores nicos A gerao de identificadores nicos pode necessitar de acesso a dados globais, interferindo assim com o controle de concorrncia e deixando a aplicao potencialmente mais lenta Pode complicar a depurao das aplicaes J que os OIDs no possuem semntica em nvel de aplicao Vantagens da identidade baseada em valor As chaves primrias possuem semntica clara em nvel de aplicao, facilitando a depurao e manuteno do BD A distribuio do BD pode ser mais fcil Porque no h gerao centralizada de identidade Mas manter a unicidade das chaves pode no ser simples Desvantagens da identidade baseada em valor Chaves primrias podem ser mais difceis de alterar Devido propagao causada por chaves estrangeiras usadas em associaes e herana A propagao poder no ser suportada automaticamente pelo SGBD Recomendaes Usar identidade baseada na existncia para esquemas maiores (com mais de 30 classes) No precisa incluir o OID como atributo no modelo UML Caso contrrio, para aplicaes pequenas, considere utilizar a identidade baseada em valor, ou uma combinao das duas tcnicas No modelo UML, acrescente o tag {OID} para os atributos que participam da chave primria H quem recomende usar identidade baseada na existncia sempre
Implementao de domains
Precisamos agora pensar sobre o tipo de dados que armazenaremos no BD Que tipos sero usados nas declaraes de colunas? Domains so usados para lidar com a questo
Um domain um subconjunto nomeado dos valores possveis para um atributo Domains: Promovem um projeto mais consistente do que com o uso direto dos vrios tipos de dados Facilitam as mudanas Ajudam a validar consultas O padro ANSI SQL-92 suporta o conceito de domain. Exemplo:
CREATE DOMAIN Boolean AS CHAR(1) NOT NULL DEFAULT 'T' CONSTRAINT Bool_Constraint CHECK (Boolean IN ('T', 'F'));
Pode-se assim criar domains para os tipos de dados que sero armazenados no BD Infelizmente, a maioria dos SGBDs no d suporte a domains! Portanto, domains so geralmente implementados: Usando clusulas CHECK do SQL na definio dos atributos Ou usando cdigo de aplicao Infelizmente, esse cdigo de verificao de domains deve ser inserido sempre que se define um atributo, j que no h suporte a domains ANSI Para domains simples tais como nomes, Strings e valores financeiros: Use o tipo de dado apropriado e especifique um tamanho Use tipos ANSI (CHARACTER, CHARACTER VARYING, ...) Ou use tipos do SGBD (Oracle: VARCHAR2, NUMBER, ...) Para domains de enumerao, h 4 solues String de enumerao: armazene o atributo de enumerao como string Use CHECK ou cdigo de aplicao para verificar valores Soluo simples mas no pode ser estendida a muitos valores Exemplo:
CREATE TABLE Pessoa ( EstadoCivil CHARACTER(1) NULL CHECK (EstadoCivil IN ('S', 'C', 'D', 'V')) ...
Codificao da enumerao: como acima, mas usando inteiros em vez de strings Uma tabela pode fornecer o mapeamento entre inteiros e strings correspondentes Vantagens: Mais fcil lidar com mltiplas lnguas Usam menos espao em disco Desvantagem (sria) Complica a depurao e manuteno (devido ao uso de "nmeros mgicos" sem semntica prpria) Um flag por valor de enumerao: use um atributo booleano para cada valor de enumerao Funciona bem apenas quando mltiplos valores podem ser aplicveis (atributos no mutuamente exclusivos) Exemplo:
CREATE TABLE xxx ( Vermelho CHARACTER(1) NULL Azul CHARACTER(1) NULL Amarelo CHARACTER(1) NULL ... )
Uma tabela de enumerao: os valores possveis para a enumerao so armazenados numa tabela parte Pode haver uma tabela por enumerao ou uma tabela para todas as enumeraes O cdigo de aplicao verifica que o valor do atributo pertence tabela Boa soluo quando h muitos valores Vantagem de ter os valores possveis no prprio BD em vez de t-los no cdigo Novos valores podem ser inseridos facilmente, sem modificar o cdigo Mas tabelas adicionais complicam o esquema e o cdigo genrico de manipulao Para pequenas enumeraes, mais fcil usar strings e um constraint em SQL Use quando h muitos valores ou valores
desconhecidos durante o desenvolvimento Exemplo:

CREATE TABLE TipoEstadoCivil ( Valor CHAR(1) PRIMARY KEY, DisplayString VARCHAR2(50) NOT NULL, Descricao VARCHAR2(2000)); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('S', 'Solteiro'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('C', 'Casado'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('D', 'Divorciado'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('V', 'Viuvo'); ) CREATE TABLE Pessoa ( EstadoCivil CHARACTER(1) NOT NULL DEFAULT 'U' REFERENCES TipoEstadoCivil(Valor), ... )
Para domains estruturados, h trs alternativas, todas vlidas em certas situaes Concatenao: jogue fora a estrutura e armazene o atributo como string Exemplo Uma Pessoa tem um Endereo O Endereo um domain estruturado (possui vrios atributos) Armazene o endereo inteiro como string Mltiplas colunas O Endereo seria armazenado na tabela Pessoa em colunas diferentes Tabela separada Pessoa referencia um registro da tabela Endereo Para domains multivalorados, use as tcnicas de domains estruturados No h suporte especial do modelo relacional, porque domains multivalorados no obedecem a primeira forma normal
Implementao de classes
No modelo de projeto, algumas classes so persistentes e outras no As classes persistentes tm o esteretipo UML
persistent Tratamos aqui apenas das classes persistentes As demais definem um comportamento transiente que deve ser tratado no cdigo da aplicao Uma classe contm atributos e operaes Discutiremos o que fazer com as operaes na prxima subseo De forma geral, cada classe persistente se transforma numa tabela e cada atributo se transforma numa coluna da tabela Para cada tabela, trata-se a questo de identidade vista acima Para cada atributo, trata-se a questo de domains vista acima O modelo relacional no trata a visibilidade dos atributos Todos os atributos so pblicos Para atributos que tm tag UML {OID}, use um constraint PRIMARY KEY Para atributos que tm tag UML {alternate OID} (alternate key), use um constraint UNIQUE Para atributos que tm tag UML {nullable}, no use o constraint NOT NULL, caso contrrio, use NOT NULL Alguns SGBDs permitem que voc use o constraint NULL que no faz parte do padro ANSI na definio de colunas
Implementao de operaes
Um SGBD Relacional no permite encapsular operaes (mtodos) com classes Por outro lado, stored procedures so possveis, o que permite colocar alguma funcionalidade dos mtodos dos objetos da aplicao no SGBD Alguns SGBDs oferecem tambm stored functions que retornam valor A questo bsica : "Que tipo de funcionalidade pode ser adequadamente colocada em stored procedures?" No final das contas, podemos particionar o cdigo entre o servidor de BD e as outras camadas (middle tier, cliente) O que melhor colocar no SGBD e o que melhor deixar fora? Algumas regras sobre o que evitar seguem: No se pode colocar operaes que lidam com aspectos transientes no SGBD
O cdigo de stored procedures no pode acessar os objetos que esto em memria nas outras camadas No se deve usar stored procedures para acessar dados atributo por atributo Um SGBDR acessa dados naturalmente por registro, no por atributo individual O acesso ao BD atributo por atributo resultaria numa aplicao muito lenta Evite stored procedures que tenham que deixar "estado transiente" armazenado no BD para fazer outras operaes subsequentes (no armazenar estado comportamental usado entre chamadas) Embora alguns SGBDs (Oracle, por exemplo) permitam que isso seja feito, melhor que cada chamada a um stored procedure seja reentrante e no dependa de estado O sistema resultante muito mais simples e fcil de manter e depurar Tal tipo de estado deve ser mantido na camada do meio (aplicao) Evite fazer grandes quantidades de verificao de erro, com condies de aborto, etc. no SGBD. Mantenha isso em outra camada (aplicao ou cliente) Algumas operaes de alto desempenho podero ser mais rpidas quando executadas numa linguagem compilada (em outra camada), em vez de uma linguagem interpretada para executar stored procedures (como PL/SQL do Oracle, Transact/SQL do SQLServer) Evite fazer aes transacionais (COMMIT, ROLLBACK) em stored procedures Faa isso em outra camada A semntica de transao expressa melhor na aplicao em si Seria ruim um programador chamar um stored procedure e, depois, ao verificar um erro e tentar fazer um ROLLBACK, descobrir que a transao j sofreu COMMIT O que pode ser colocado no SGBD como stored procedures? Fazer uma consulta dando um result set (um conjunto de registros) Insert/update/delete, mas apenas de registros inteiros, no atributo por atributo Verificao de regras de consistncia e outros business
rules Talvez este seja o motivo principal do uso de Stored Procedures Triggers podem ser valiosos aqui tambm Operaes que chamam outros stored procedures (para acessar o dicionrio, por exemplo) Verificao de erros (mas apenas erros relacionados com a estrutura do BD) Como tratar polimorfismo? Ao usar um SGBDR, no h suporte a polimorfismo Mesmo SGBDORs tm suporte fraco ou inexistente a polimorfismo Evite-o portanto, nas classes persistentes Pode usar em classes transientes Se o polimorfismo for usado na modelagem de classes persistentes, ele tem que ser transformado em if-thenelse e chamadas as stored procedures diferentes Todas essas restries explicam porque se fala do impedance mismatch!
Implementao de associaes simples

Associaes simples so: 1-para-1 0..1-para-1 1-para-muitos muitos-para-muitos Descrevemos mapeamentos recomendados, alternativos e desencorajados para cada tipo Sempre considere primeiro o mapeamento recomendado Mapeamentos alternativos podem ser usados por uma questo de desempenho, extensibilidade, ou estilo
Associaes 1-para-1
Recomendado Embutir a chave estrangeira em qualquer uma das classes A chave estrangeira poder ser nula se houver uma cardinalidade mnima de 0 no alvo Alternativo
A associao pode ser implementada numa tabela parte A chave primria da tabela de associao pode ser qualquer uma das duas chaves estrangeiras Vantagem: o esquema mais extensvel Se houver mudana na cardinalidade da associao, basta mudar o constraint, no a estrutura de tabelas Desvantagens: fragmentao do esquema e maior overhead de navegao (com joins) Desencorajado Combinao: no junte duas classes e sua associao numa nica tabela O esquema mais fcil de entender se seguir o modelo de objetos Associaes bi-direcionais: no coloque duas chaves estrangeiras, uma em cada tabela referenciando a outra Os SGBDs no vo manter a consistncia das associaes redundantes
Associaes 0..1-para-1
Recomendado Embutir a chave estrangeira na classe com a cardinalidade 0..1 A chave estrangeira NOT NULL
Associaes 1-para-muitos
Recomendado Embutir a chave estrangeira na classe com cardinalidade "muitos" Se a cardinalidade 1 (do alvo) puder ser 0-1, a chave estrangeira pode se nula Exemplo:
Alternativo A associao pode ser implementada numa tabela parte A chave estrangeira para a classe "muitos" a chave primria da tabela de associao Mesmas vantagens e desvantagens do mapeamento 1para-1 Exemplo:
Associaes muitos-para-muitos
Recomendado A associao mapeada para uma tabela distinta A chave primria da tabela de associao uma combinao das chaves estrangeiras Exemplo:
Implementao de associaes avanadas

Associaes avanadas so: Associao qualificada Classe de associao Associao ordenada Associao ternria
Associao qualificada
Lembre que uma associao qualificada uma associao "para-muitos" onde os objetos envolvidos do lado "muitos" so total ou parcialmente especificados usando um atributo chamado o qualificador Tais associaes aumentam a preciso do modelo Um qualificador seleciona um ou mais dentre vrios objetosalvo, com o efeito de reduzir a cardinalidade, s vezes at 1 Quando a cardinalidade final 1, a associao qualificada especifica uma forma precisa de selecionar o objeto alvo a partir do objeto fonte Exemplo: Uma descrio de vo se aplica a muitos vos A combinao de uma descrio de vo mais uma data de partida especifica um vo
Recomendado O mapeamento tal qual para a associao sem qualificador No exemplo acima, uma chave estrangeira seria includa na classe Vo
Classe de associao
uma associao com uma classe que a descreve A classe de associao pode participar de outras associaes Recomendado Implemente a associao com uma tabela distinta A chave primria da classe de associao uma combinao das chaves primrias das classes envolvidas na associao Exemplo:
Associao ordenada
Ocorre quando as ligaes entre objetos possuem uma ordem Exemplo: janelas podem estar ordenadas numa tela (indicando qual est na frente das outras) O tag UML {ordered} usado na associao ( ou {ordered by ...}) Recomendado Introduzir um nmero de sequncia como atributo
Associao ternria
Exemplo:
Recomendado Uma tabela distinta deve ser usada para representar a associao ternria
Agregaes
Recomendado Agregaes so associaes e so implementadas como tal
Implementao de herana simples (generalizao)

Recomendado Normalmente, a herana implementada com tabelas separadas para a superclasse e cada subclasse Idealmente, um objeto tem a mesma chave primria na hierarquia inteira A superclasse inclui um discriminador que indica qual subclasse se aplica Isso no mostrado no modelo de objetos A integridade referencial pode ser usada para garantir que um registro da superclasse exista para cada registro de uma subclasse Entretanto, se a superclasse for abstrata e exigir que haja um objeto de uma subclasse, a integridade referencial no pode solucionar o problema O cdigo da aplicao deve implementar a restrio Exemplo:
Pode-se usar uma View para cada subclasse, no sentido de consolidar os dados herdados e facilitar o acesso ao objeto Exemplo:
CREATE VIEW view_PagamentoCC AS SELECT pagamentoID, valor, tipoCC, numeroCC FROM Pagamento AS P JOIN PagamentoCC as CC ON P.pagamentoID = CC.pagamentoCCID
Alternativo Eliminao Como otimizao, subclasses que no contm atributos, fora a chave estrangeira, podem ser eliminadas Desvantagens O cdigo de navegao tem que saber se h uma tabela ou no para implementar a subclasse Falta de extensibilidade: se houver uma
adio subclasse, a tabela vai ter que voltar Exemplo:
Empurrar atributos da superclasse para baixo Elimine a superclasse e duplique seus atributos para cada subclasse Uma nica tabela contm todos os dados de um objeto (no h necessidade de join para reconstituir um objeto) Desvantagens Introduz redundncia no esquema Poder ser necessrio pesquisar vrias tabelas para achar um objeto Se vrios nveis de hierarquia estiverem envolvidos, a estrutura da generalizao (herana) perdida Exemplo:
Empurrar atributos da subclasse para cima Neste caso, as subclasses so eliminadas e todos seus atributos migram para a tabela da superclasse Atributo desnecessrios para certos objetos so nulos Essa alternativa viola a segunda forma normal porque alguns atributos no dependem completamente da chave primria Exemplo:
Abordagem hbrida Empurrar os atributos da superclasse para baixo mas manter a tabela da superclasse para navegar nas subclasses Exemplo:
Tabela de generalizao Semelhante ao mapeamento recomendado (tabelas para superclasse e subclasses) mas adicionando uma tabela de generalizao que amarra a chave primria da superclasse chave primria da subclasse A chave primria das subclasses a chave "natural" da tabela e no mais a mesma da superclasse como no mapeamento recomendo inicial
Implementao de herana mltipla

Recomendado Usar o mapeamento recomendado acima (tabelas distintas para superclasse e subclasses)
Resumo dos passos para o mapeamento OORelacional

1. Cada classe UML mapeada para uma tabela 2. Cada atributo da clase uma coluna da tabela 3. O tipo do atributo mapeado para um tipo da coluna, de acordo com regras de transformao de tipos 4. Se o atributo tem o tag UML {nullable}, a coluna tem constraint NULL; caso contrrio, tem constraint NOT NULL 5. Se o atributo UML tem um inicializador, adicionar a clusula DEFAULT coluna 6. Para cada classe sem generalizao ( raiz de hierarquia ou no participa de hierarquia) e com identidade baseada na existncia, criar uma chave primria inteira; com identidade baseada em valor, adicionar as colunas com tag UML {OID} ao constraint PRIMARY KEY 7. Para subclasses com uma nica superclasse com chave primria de uma coluna, adicionar a chave da superclasse ao constraint PRIMARY KEY e adicionar uma clusula REFERENCES para relacionar a coluna (chave estrangeira) chave primria da superclasse 8. Para subclasses com uma nica superclasse com chave primria de vrias colunas, use constraints de tabela PRIMARY KEY e FOREIGN KEY em vez do constraint de coluna do item anterior 9. Para herana mltipla, adicione uma coluna na subclasse para cada chave primria de cada superclasse; adicione um constraint de tabela FOREIGN KEY com todas essas colunas (que referenciam chaves primrias das superclasses)
10. Para classes de associao, adicione uma coluna para a chave primria de cada classe participando da associao; use um constraint FOREIGN KEY 11. Para tags UML {alternate OID}, adicione as colunas envolvidas ao constraint UNIQUE 12. Adicione CHECK para cada constraint explcito 13. Crie tabelas para as associaes que no usam chaves estrangeiras embutidas (muitos-para-muitos, ternrias, ...), e use constraint de tabela FOREIGN KEY 14. Para agregaes, use a opo ON DELETE CASCADE, ON UPDATE CASCADE na tabela agregadora
proj1-9 programa anterior

Esquema de Banco de Dados e Mapeamento OO-Relacional

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Esquema de Banco de Dados e Mapeamento OO-Relacional

Enviado por

Direitos autorais:

Formatos disponíveis

Esquema de banco de dados e mapeamento OO-Relacional