Transformação ODMG  Relacional O advento dos SGBDs OO não ameaçou minimamente a tecnologia relacional de SGBDs, que domina praticamente todo o mercado. Em conseqüência, e a despeito das diferenças entre os paradigmas OO e relacional, os BDs OO usam os SGBDRs como seu mecanismo de persistência (abordagem classe de objetos --> tabela). Catalogamos pelo menos cinco categorias dessa abordagem. Na primeira categoria, Transformação Esquema Objeto -- Esquema Relacional, a modelagem OO é usada para captar a natureza do domínio do problema, e então o esquema objeto é transformado em um esquema relacional (tabelas). A segunda categoria, Transformação Esquema Objeto -- Esquema Objeto-Relacional, utiliza a nova geração de SGBDs, chamada de objeto-relacional (SGBDOR), que estende o modelo relacional `convencional´ para o suporte a funcionalidades OO: identificadores de objeto (OID), herança, tipos complexos de dados, e tipos-operações definidos pelo usuário. A terceira categoria é chamada Camada OO no Topo de um SGBDR, em que uma camada de software é construída no topo de um SGBDR, simulando um SGBDOO. Exemplo: o SGBD Open ODB da HP. A quarta categoria é uma abordagem chamada de Integração de uma LPOO com um SGBDR. Por exemplo, uma recente API para o ambiente de desenvolvimento Borland C++ Builder permite acessar bancos de dados Paradox e Interbase de um programa em C++. A quinta categoria é Interoperabilidade de SGBDOO e SGBDR. Neste tipo de ambiente, é possível a um programa de aplicação trabalhar com dados recuperados tanto de SGBDOO quanto de SGBDR, via múltiplos tradudores (“gateways”). O foco desta disciplina são as duas primeiras abordagens, Mapeamento Esquema Objeto -- Esquema Relacional e Mapeamento Esquema Objeto -- Esquema Objeto-Relacional.

Implementação Relacional de BDs OO Transformação Esquema Objeto  Esquema Relacional O advento dos SGBDs OO não ameaçou minimamente a tecnologia relacional de SGBDs, que domina praticamente todo o mercado. Em conseqüência, e a despeito das diferenças entre os paradigmas OO e relacional, os BDs OO usam os SGBDRs como seu mecanismo de persistência (abordagem classe de objetos --> tabela). Catalogamos pelo menos cinco categorias dessa abordagem. Na primeira categoria, Transformação Esquema Objeto -- Esquema Relacional, a modelagem OO é usada para captar a natureza do domínio do problema, e então o esquema objeto é transformado em um esquema relacional (tabelas). A segunda categoria, Transformação Esquema Objeto -- Esquema Objeto-Relacional, utiliza a nova geração de SGBDs, chamada de objeto-relacional (SGBDOR), que estende o modelo relacional `convencional´ para o suporte a funcionalidades OO: identificadores de objeto (OID), herança, tipos complexos de dados, e tipos-operações definidos pelo usuário. A terceira categoria é chamada Camada OO no Topo de um SGBDR, em que uma camada de software é construída no topo de um SGBDR, simulando um SGBDOO. Exemplo: o SGBD Open ODB da HP. A quarta categoria é uma abordagem chamada de Integração de uma LPOO com um SGBDR. Por exemplo, uma recente API para o ambiente de desenvolvimento Borland C++ Builder permite acessar bancos de dados Paradox e Interbase de um programa em C++. A quinta categoria é Interoperabilidade de SGBDOO e SGBDR. Neste tipo de ambiente, é possível a um programa de aplicação trabalhar com dados recuperados tanto de SGBDOO quanto de SGBDR, via múltiplos tradudores (“gateways”). O foco desta disciplina são as duas primeiras abordagens, Mapeamento Esquema Objeto -- Esquema Relacional e Mapeamento Esquema Objeto -- Esquema Objeto-Relacional.

Transformação Esquema Objeto  Esquema Relacional Classe de Objetos  Tabela Relacional OID  Chave Primária, “Surrogate Key” Os métodos são implementados como “stored procedures”, ou “SQL-functions” ou “SQL-triggers” A rica semântica de método de instância é perdida Herança (só exclusão mútua) Alternativa 1: uma tabela para cada (sub)classe Alternativa 2: uma única tabela para todas as classes Alternativa 3: uma variação da alternativa 1 Em todas as alternativas: regras de integridade

Transformação Esquema Objeto  Esquema Relacional Herança Alternativa 1: Um novo atributo `Subtipo´, podendo ser NULL, é acrescentado na tabela-superclasse; este atributo deve garantir que todo registro em uma tabela-subclasse é disjunto Empregado Gerente Trabalhador

Transformação Esquema Objeto  Esquema Relacional Herança Usando o exemplo Empregado-Gerente-Trabalhador Empregado(ID, Subtipo, Nome, Endereço, Salário) Gerente(ID, Gratificação) Trabalhador(ID, HorasExtras) Regras de Integridade Subtipo {t | t = `Gerente´  t = `Trabalhador´  t IS NULL}  ID em Empregado com t = `Gerente´ então  ID em Gerente e  ID em Trabalhador  ID em Empregado com t = `Trabalhador´ então  ID em Trabalhador e  ID em Gerente  ID em Empregado com t IS NULL então  ID em Gerente e  ID em Trabalhador

Transformação Esquema Objeto  Esquema Relacional Herança Alternativa 2: tudo em uma tabela; um atributo `Tipo´, podendo ser NULL, é incluído, para indicar o tipo do objeto/registro; os demais atributos, salvo ID, podem ser nulos

Transformação Esquema Objeto  Esquema Relacional Herança Usando o exemplo Empregado-Gerente-Trabalhador Empregado(ID, Tipo, Nome, Endereço, Salário, Gratificação, HorasExtras) Regras de Integridade Tipo {t | t = `Gerente´  t = `Trabalhador´  t IS NULL} Se t = `Gerente´ então HorasExtras NULL Se t = `Trabalhador´ então Gratificação NULL Se t IS NULL então HorasExtras NULL, Gratificação NULL

Transformação Esquema Objeto  Esquema Relacional Herança Alternativa 3: sem o atributo Subtipo na superclasse; Usando o exemplo Empregado-Gerente-Trabalhador Empregado(ID, Nome, Endereço, Salário) Gerente(ID, Gratificação) Trabalhador(ID, HorasExtras)

Transformação Esquema Objeto  Esquema Relacional Herança Regras de Integridade Se ID = v em Empregado então ((ID = v em Gerente)   (ID = v em Trabalhador))  ((ID = v em Trabalhador)   (ID = v em Gerente))  ( (ID = v em Gerente)   (ID = v em Trabalhador))

Transformação Esquema Objeto  Esquema Relacional Qual é a Melhor Implementação Relacional de Herança? Consultas sobre estruturas de herança podem ser assim categorizadas Consultas em Superclasse: acessam atributos em superclasse Consultas em Subclasse: acessam atributos em subclasse Consultas Mistas: acessam atributos ao longo de estruturas de herança Prova-se que, para consultas em superclasse e em subclasse, a Alternativa 1 é pelo menos tão boa quanto as outras, em todos os casos A prova é baseada em um Modelo de Custos e em Categorias de Consulta - O Modelo de Custos leva em conta o tamanho dos registros de uma tabela e o seu número de registros

Transformação Esquema Objeto  Esquema Relacional Super classe Sub Mista Subtipo Única Tabela Sem subtipo

Transformação Esquema Objeto  Esquema Relacional Associação 1:1 Tabela_B(ID, IDA, ...) Tabela_A(ID, ...) Tabela_A(ID, IDB, ...) Tabela_B(ID, ...) Tabela_AB(ID, ...) Classe A Classe B 1 1 Chave primária Chave estrangeira Qual é a melhor transformação?

Transformação Esquema Objeto  Esquema Relacional Associação 1:N Tabela_B(ID, IDA, ...) Tabela_A(ID, ...) Classe A Classe B 1 N

Transformação Esquema Objeto  Esquema Relacional Associação M:N Tabela_A(ID, ...) Tabela_B(ID, ...) Tabela_AB(IDA, IDB, ...) Classe Associação Classe A Classe B M N

Transformação Esquema Objeto  Esquema Relacional Agregação Usando o exemplo Catálogo-Brinquedo Catálogo(ID, ...) Brinquedo(ID, ...) Composto_de(IDC, IDB, ...) chave estrangeira chave estrangeira

Transformação Esquema Objeto  Esquema Relacional Composição Usando o exemplo Universidade-Departamento Universidade(ID, ...) Departamento(ID, IDU, ...) Regras de Integridade Se Universidade.ID = v for removida então Departamento.IDU = v removido (“DELETE CASCADE”)