Академический Документы
Профессиональный Документы
Культура Документы
A
DIOGO ALENCAR BERNARDI
Modelo relacional
A abordagem relacional est baseada no princpio de que as informaes em uma base de dados podem ser consideradas relaes matemticas e que esto representadas de maneira uniforme com o uso de tabelas bidimensionais. Ao se fazer a anlise para o desenvolvimento de uma aplicao, muito importante saber se os tipos de dados a serem armazenados so tipos simples, tais como strings e nmeros. Se este for o caso, mais indicada a utilizao de SGBDs relacionais.
Vantagens
Os SGBDs relacionais possuem uma caracterstica muito importante: so extremamente confiveis e mais eficientes, se comparados maioria dos SGBDs orientados a objetos disponveis no mercado. Alm disso, o modelo de dados relacional foi criado para permitir a representao de uma grande variedade de problemas usando um pequeno conjunto de conceitos simples. Atravs da linguagem de consulta SQL (Structured Query Language) possvel fazer a busca e recuperao dos dados neSQL40.indb 46 09.02.07 00:17:16
47
MODELAGEM
cessrios de forma bastante eficiente. Dentre as vantagens do modelo relacional, talvez a mais importante esteja relacionada com a persistncia dos dados. As regras e rotinas para tratamento da persistncia dos dados podem ser criadas no prprio banco de dados relacional.
Desvantagens
Uma das grandes desvantagens do modelo relacional pode ser observada no momento da realizao da anlise de um sistema a ser implementado: a grande dificuldade em abstrair a realidade, ou seja, traduzir para um modelo de tabelas, com suas relaes entre si, suas chaves primrias e estrangeiras, um problema do mundo real.
Vantagens
No modelo Orientado a Objetos, a abstrao da realidade mais simplificada, pois um objeto nada mais do que uma abstrao direta da realidade. Por exemplo: um computador tem teclado, cpu e mouse. O teclado um objeto, a cpu outro objeto e o mouse tambm um objeto. Outra grande vantagem deste modelo a questo da reutilizao. Um objeto pode ser facilmente reutilizado no mesmo programa ou at mesmo em programas diferentes. O modelo orientado a objetos foi projetado para a criao e representao de estruturas complexas de uma maneira coerente e uniforme. Isto representa uma grande vantagem em relao ao modelo de dados relacional, que foi criado sem se preocupar com o armazenamento de estruturas mais complexas. Outro ponto a favor do modelo orientado a objetos a facilidade em expressar relaes complexas entre objetos.
Desvantagens
O paradigma orientado a objetos apresenta um problema: os bancos de dados atuais no oferecem uma boa aderncia aos princpios da orientao a objetos. Isto , em termos de armazenamento, os bancos de dados orientados a objetos no conseguiram ainda substituir a tecnologia comprovadamente eficiente dos bancos de dados relacionais. Em funo disso, os administradores e desenvolvedores de bancos de dados acabam ficando em uma situao difcil, pois mesmo querendo adotar a orientao a objetos, eles tm que parar na hora de manipular seus dados. At mesmo linguagens de programao orientadas a objetos, como Java, acessam os bancos de dados de maneira convencional e utilizando SQL. Com isso, um mesmo programa acaba tendo uma parte orientada a objetos e outra parte estruturada, fazendo com que as caractersticas da orientao a objetos no possam ser exploradas na sua plenitude. Devido a isso, o que est ocorrendo nos dias de hoje que o desenvolvimento orientado a objetos, mas o banco de dados relacional ou objeto-relacional. No modelo orientado a objetos, a implementao acaba se tornando mais complicada do que no modelo relacional, pois as estruturas de dados usadas no banco e as usadas na programao podem ser completamente diferentes. Isso refora a necessidade da criao de uma camada de persistncia, fazendo com que se gaste um bom tempo do desenvolvimento para mapear as estruturas da programao em estruturas do banco de dados.
SQL40.indb 47 09.02.07 00:17:17
e de herana; A representao de um relacionamento feita incluindose dentro de um objeto os object identifiers dos outros objetos com os quais ele se relaciona; o Object Identifier um identificador interno do banco de dados para cada objeto. Os object identifiers so atribudos e utilizados somente pelo SGBD, nunca pelos usurios. No possuem um padro nico de implementao como os bancos relacionais. Assim, cada produto tem a sua prpria especificao para criao de classes e relacionamentos; Os BDPOO tendem a seguir um padro estabelecido pelo ODMG (Object Database Management Group). A ltima verso disponibilizada pelo ODMG a verso 3.0, que pode ser obtida em no endereo www.odmg.org. Caractersticas dos BDOR Com relao aos Bancos de Dados Objeto-Relacionais, podese dizer que as principais caractersticas so: Um banco objeto-relacional um banco que permite o armazenamento de objetos em suas tabelas; Uma classe representa um domnio, atuando como um data type para uma coluna. A classe, diferentemente dos bancos orientados a objetos, no representa mais um elemento envolvido em relacionamentos; Todas as regras de um banco relacional continuam vlidas; Uma coluna cujo data type seja uma classe, s poder ter uma instncia desta classe. Imagine, por exemplo, uma coluna cujo data type seja uma classe TELEFONE. Nos BDOR, esta coluna no poder ter vrias instncias da classe TELEFONE, mas apenas uma. Se o banco fosse OO, poderia ter mais do que uma. Dentre as principais vantagens dos BDOR, pode-se citar que todo o suporte para ao paradigma orientado a objetos est presente. Alm disso, j existe um padro de implementao estabelecido, determinando uma certa facilidade de convivncia com os sistemas j existentes. Na Tabela 3 podem ser observados alguns dos principais BDOR disponveis no mercado.
Fabricante Descrio IBM Informix e DB2 Oracle Corporation Oracle 9i PostgreSQL Global Development Group PostgreSQL Micro Database System, Inc. TITANIUM Intersystems Cach Tabela 3. Principais BDOR no mercado.
Esse encapsulamento torna as aplicaes mais confiveis, permitindo at mesmo que o prprio SGBD ou a estrutura de suas tabelas possam ser alterados sem a necessidade de revisar e recompilar os programas. Apesar disso, o modelo de classes de um projeto orientado a objetos no pode simplesmente ser traduzido em um script SQL de criao de banco de dados, necessrio realizar o mapeamento de objetos em um modelo de dados Entidade-Relacionamento.
49
MODELAGEM
Ao se realizar uma transposio de um modelo orientado a objetos para um modelo relacional, algumas regras devem ser seguidas (vale destacar aqui que essas regras no so rgidas): 1. Todas as tabelas (ou relaes) devem ter uma chave primria. Em um sistema orientado a objetos, cada objeto nico. Essa unicidade garantida atravs da introduo de um identificador de objetos (OID Object IDentifier). Esse OID gerado pelo sistema, no podendo ser alterado pelo usurio. Seu valor no depende dos valores dos atributos do objeto. Para fazer essa implementao no modelo relacional, deve ser criado um atributo OID para cada tabela. Na Figura 1 mostrado um exemplo de como seria o mapeamento do objeto Pedido para a tabela Pedido. 2. Mapeamento de atributos. Existem trs tipos de atributos para serem mapeados. Os atributos simples so mapeados para colunas. Os atributos compostos podem ser mapeados em vrias colunas. J os atributos multivalorados devem ser mapeados em tabelas onde a chave primria composta pela chave primria da tabela que representa a classe que contm o atributo multivalorado e pela chave primria que representa o atributo multivalorado. Na Figura 2 pode ser observado um exemplo de mapeamento de um atributo simples (Nome e DtNascimento) e de um atributo composto (Endereco). J na Figura 3 pode ser observado um exemplo de mapeamento de um atributo multivalorado (Telefone). 3. Herana: pode-se mapear este conceito de trs formas. A primeira simplesmente criar uma tabela para cada classe. A segunda forma criar uma nica tabela
para toda a hierarquia de classes. Por ltimo, pode-se criar uma tabela para cada classe concreta.
Figura 1. Exemplo 1. Figura 2. Atributos simples e compostos. Figura 3. Atributos multivalorados. Figura 4. Mapeamento de uma tabela por classe. Figura 5. Uma nica tabela para toda a hierarquia de classes.
Na tcnica de criao de uma tabela para cada classe (Figura 4), os atributos da tabela so os atributos especficos da classe e mais uma coluna de chave estrangeira que referencia a chave primria da tabela pai. As desvantagens do uso dessa tcnica que so geradas muitas tabelas no banco de dados, fazendo com que haja uma demora maior para ler e gravar os dados. Por esse mesmo motivo, algumas consultas acabam sendo bastante dificultadas, obrigando a criao de views para agilizar o processo. Se for utilizada a segunda forma (Figura 5), a classe raiz tomada por base, pois nela que todos os atributos so armazenados. Essa tcnica facilita as consultas, pois os dados de um objeto esto em uma nica tabela O principal problema que, potencialmente, h um desperdcio de espao no banco de dados. Alm disso, a performance pode ser prejudicada. Caso se opte por criar uma tabela para cada classe concreta (Figura 6), deve-se incluir em cada tabela tanto os atributos especficos, quanto os atributos herdados da classe que ela representa. Como os dados de uma classe ficam todos em uma nica tabela, as consultas so facilitadas.
SQL40.indb 49 09.02.07 00:17:18
4. Associaes Muitos-para-Muitos: neste caso devemos criar uma tabela associativa em que a chave primria composta pelas chaves primrias das tabelas associadas famosa e j conhecida entidade ou tabela associativa. Na Figura 7 pode ser visto um exemplo da transposio de uma associao muitospara-muitos. No modelo orientado a objetos havia dois objetos (Aluno e Disciplina), que no modelo relacional passaram a ser representados por trs tabelas (Aluno, Disciplina e Frequenta). 5. Associaes Muitos-para-Muitos com Classe de Associao: neste caso, aplica-se a regra da associao muitos-paramuitos e os atributos da classe associativa permanecero na tabela que gerada para mapear a associao. Na Figura 8 podese observar um exemplo de como feita a transposio de um associao de muitos para muitos. 6. Associaes Um-para-Muitos: neste caso, a tabela cujos registros podem ser endereados diversas (lado Muitos do relacionamento) vezes a que herda a referncia da tabela cuja correspondncia unitria. Na Figura 9 pode-se observar um exemplo onde a tabela Pedido possui uma chave estrangeira (FK) que referencia a tabela Cliente. 7. Associaes Um-para-Muitos com Classe de Associao: neste caso, aplica-se a regra da associao um-para-muitos e os atributos da classe associativa so herdados como atributos normais pela tabela que herda a chave estrangeira (ver Figura 10). 8. Associaes Um-para-Um: nesse tipo de associao, o analista deve optar por gerar uma nica tabela no modelo relacional, ou ento gerar duas tabelas (uma para cada classe).
Figura 6. Uma tabela para cada classe concreta. Figura 10. Associao um-para-muitos com agregao. Figura 9. Associao um-para-muitos. Figura 8. Associao muitos-para-muitos com agregao. Figura 7. Associao muitos-para-muitos.
SQL40.indb 50 09.02.07 00:17:18
51
MODELAGEM
Se for escolhida a primeira opo, os atributos da classe agregada devem ser colocados na mesma tabela da classe agregadora. Nessa tcnica, a performance melhor, pois preciso acessar uma nica tabela. Alm disso, o objeto agregado automaticamente excludo quando o objeto agregador eliminado, no havendo a necessidade da implementao de triggers ou rotinas especiais na aplicao para garantir a consistncia do banco de dados. A grande desvantagem dessa tcnica que a incorporao dos atributos aumenta a quantidade de pginas que so recuperadas em cada acesso tabela. No caso da opo ser pela gerao de duas tabelas, uma delas deve herdar como um atributo normal (chave estrangeira) a chave primria da outra tabela. Essa tcnica facilita a manuteno das tabelas e torna a estrutura do banco de dados mais flexvel. Porm, as consultas necessitam de uma operao de juno (join) ou pelo menos dois acessos ao banco de dados. Se o acesso aos dados de ambas as tabelas no for muito freqente, esta alternativa aceitvel, caso contrrio, essa alternativa pode no ser a mais adequada. Outra desvantagem de gerar uma tabela para cada classe que para manter a consistncia do banco de dados entre essas tabelas, por ocasio de operaes de excluso de objetos, necessrio implementar triggers ou rotinas especiais na aplicao. Na Figura 11 pode ser observado um exemplo da utilizao da tcnica de gerao de uma nica tabela, com a utilizao de um prefixo para distinguir os atributos (PagCh). Os objetos Pedido e Pagto em cheque so transpostos na tabela Pedido. J na Figura 12 demonstrada a utilizao da segunda tcnica (gerao de duas tabelas), onde os objetos Pedido e Pagto em cheque so transpostos nas tabelas Pagamento e PagamentoCheque.
Exemplo de mapeamento
A Figura 13 mostra como seria o mapeamento de um sistema simplificado de controle de uma biblioteca. Atravs deste exemplo, pode-se observar a aplicao de algumas das regras explicadas na seo anterior. importante lembrar que as regras descritas admitem uma certa variao, no sendo totalmente rgidas.
Concluso
Nos casos onde se faz necessrio realizar o mapeamento de um modelo orientado a objetos para um modelo relacional, mais do que qualquer outro fator, o mais importante realizar uma anlise criteriosa, analisando cada caso individualmente. O fundamento dessa anlise deve estar baseado nas regras de mapeamento existentes, porm, como todas as regras, sempre existem excees que precisam ser analisadas com cuidado. As regras de mapeamento j adquiriram certa maturidade, uma vez que vm sendo propostas e aperfeioadas h vrios anos. Alguns autores definem as regras de forma bastante genrica, enquanto outros especificam detalhadamente cada regra, preocupandose com as possveis excees e at mesmo subdividindo algumas regras. Porm, todos so unnimes em afirmar que uma boa anlise individual sobre cada caso, verificando os objetos inFigura 11. Associao um-para-um uma nica tabela. Figura 12. Associao um-para-um uma tabela para cada classe. Figura 13. Mapeamento do modelo de dados de um sistema de controle bibliotecrio simples.
dividualmente e como um todo, muito importante. At mesmo quando so utilizadas ferramentas que fazem o mapeamento de forma automtica, deve-se analisar o modelo obtido para verificar
como ficaram as tabelas, pois pode haver excees que precisam ser tratadas de forma manual.
SQL40.indb 51 09.02.07 00:17:18