Persistência entre Modelos de Dadosclodis/PMD/PMD_Intro111008.pdfIntrodução ao Hibernate. Persistência É um tópico vital para o desenvolvimento de aplicações; Quase todas as

Persistência entre

Modelos de DadosModelos de Dados

Clodis Boscarioli

Agenda:

� Persistência (Conceitos)

� Sistemas de Banco de Dados� Modelo Relacional;

� Normalização.� Normalização.

� Modelo Orientado a Objetos;

� Modelo Objeto-Relacional.

� Mapeamento Objeto-Relacional� Introdução ao Hibernate.

Persistência

� É um tópico vital para o desenvolvimento de aplicações;

� Quase todas as aplicações necessitam que dados sejam persistidos;sejam persistidos;

� Necessidades:� Armazenamento;� Busca;� Organização;� Compartilhamento dos dados.

Persistência

� Necessidades:� Integridade dos dados;� Controle de concorrência.

� Desempenho e a escalabilidade são fortemente � Desempenho e a escalabilidade são fortemente afetados pela estratégia de acesso a dados escolhida.

Sistemas de Banco de Dados

� Quando falamos Sistemas de BD, entendemos a junção de:� Sistema Gerenciador de Banco de Dados;� Banco de Dados.� Banco de Dados.

Sistema Gerenciador de Banco de Dados

Um Sistema Gerenciador de Banco

de Dados (SGBD) é uma coleção de

programas que habilitam usuários a

criar e manter um banco de dados.

usuários

O grande objetivo de um sistema de

BD é oferecer uma visão “abstrata”

dos dados, com disponibilidade

eficiente, aos usuários.

SGBD

PROGRAMAS

Mundo real

Visão Geral de um SGBD

SGBD

Usuários

Interface comaplicações

Programas deaplicações

Consultas(queries)

Esquema de Banco de Dados

Usuáriosnavegantes

Programadoresde aplicações

Usuáriossofisticados

Administra-dores de BD

Processadorde consultas

InterpretadorDDL

CompiladorDML

Pré-compiladorde comandos

DML

Programas deaplicações em código objeto

Componentes de execuçãode consultas

Gerenciadorde memória

Gerenciadorde transações

Gerenciador de buffer

Gerenciadorde arquivos

Armazenamento

em disco Índices

Arquivos dedados

Dados estatísticos BD

Dicionáriode dados

Banco de dados e Abstração de Dados� Um dos maiores benefícios dos sistemas de banco de dados é proporcionar aos

usuários uma visão abstrata dos dados. O sistema é capaz de ocultar alguns detalhes sobre a forma de armazenamento e a manutenção dos dados.

� A eficiência da recuperação de informações está relacionada à forma como as estruturas de representação são projetadas e, dado a complexidade e importância destas representações, elas devem ser protegidas em níveis de abstrações.

� Estes níveis facilitam a manutenção do sistema e a interação dos usuários com os sistemas. São eles:

Nível de visão: O mais alto nível de abstração. Proporciona uma visão parcial do banco de dados. Diferentes visões são usadas por diferentes usuários.

Nível lógico: Implica em definir quais dados serão armazenados e quais são os inter-relacionamentos existentes entre eles. Usado pelos administradores de banco de dados e programadores.

Nível físico: Mais baixo nível de abstração. Implica em como os dados estão, de fato, armazenados (descrição em detalhes das estruturas de dados). Administradores de banco de dados devem ter noções da organização deste nível.

Visão 1 Visão 2 Visão n......

Nível de visão

Nível lógico quais

Nível físico0 1 1 como

Modelos de Dados

� O Modelo de Dados é a principal ferramenta que fornece a abstração a um BD. É um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.

Esquema Geral de Modelagem de BD

Fonte: Ferreira et. al, 2005

Modelagem Conceitual

� A base do modelo entidade-relacionamento, o modelo E-R (MER), é representar o mundo real por meio de conjuntos de objetos chamados entidades e relacionamentos.

� A junção ordenada/lógica destes tipos de objetos representa a estrutura/esquema do mundo real, ou seja, deve suportar o armazenamento de dados que reflitam a situação do mundo real.armazenamento de dados que reflitam a situação do mundo real.

� As três noções básicas empregadas pelo MER:� Conjunto de entidades;� Atributos;� Conjunto de relacionamentos;� Esse modelo possui recursos de Extensão (generalização, especialização e

agregação).

O Conjunto de Entidades

� Segundo (Korth et. al, 2006):� uma entidade é uma “coisa” ou um “objeto” do mundo real que pode

ser identificada(o) de uma forma unívoca em relação a todos os outros objetos.

� cada entidade tem um conjunto de propriedades que assumem valores e, em alguns casos, assumem valores que devem ser únicos.

� uma entidade pode ser concreta, como uma pessoa ou um livro, ou pode ser abstrata, como um empréstimo ou uma viagem.pode ser abstrata, como um empréstimo ou uma viagem.

� um conjunto de entidades é o conjunto que abrange entidades de mesmo tipo e que compartilham as mesmas propriedades: os atributos.

� os conjuntos de entidades não são, necessariamente, conjuntos separados, ou, sempre disjuntos.

� Por exemplo: o conjunto de todos os clientes de um banco constituem o conjunto entidade cliente; o conjunto de todos os empregados do banco constituem o conjunto entidade empregado; a entidade pessoa pode pertencer ou ao conjunto cliente, ou ao conjunto entidade ou a ambos ou a nenhum deles.

Atributos

� Uma entidade é representada por um conjunto de atributos.� Atributos são propriedades descritivas de cada membro de um conjunto

de entidades e cada entidade tem seus próprios valores nos atributos.� Para cada atributo existe um conjunto de valores possíveis, chamado

domínio.

� Formalmente, um atributo de um conjunto de entidades é uma função que relaciona o conjunto de entidades a seu domínio.relaciona o conjunto de entidades a seu domínio.

� Cada entidade pode ser descrita pelo conjunto formado pelos pares (atributo-valor) referentes a cada atributo do conjunto em questão.

� Classes de Atributos: Simples; Compostos; Monovalorados; Multivalorados; Nulos; Derivados.

Conjuntos de Relacionamentos

� Um relacionamento é uma associação entre uma ou várias entidades. Exemplo:� Um relacionamento que associa o cliente Hayes como empréstimo L-15

especifica que o cliente Hayes é o cliente que realizou o referido empréstimo.

� Um conjunto de relacionamentos é um conjunto de relacionamentos de mesmo tipo.� Formalmente o relacionamento é uma relação matemática com n >= 2 (n =

número de conjuntos entidades).� Se E1, E2, ..., En são conjuntos de entidades, então um conjunto de � Se E1, E2, ..., En são conjuntos de entidades, então um conjunto de

relacionamentos R é um subconjunto de {(e1,e2,...,e3) | e1 ∈ E1, e2 ∈ E2, ..., en ∈

En} em que (e1,e2,...,e3) são relacionamentos.� A associação entre os conjuntos de entidades é referida como uma

participação: o conjunto de entidades E1, E2, ..., Em participa do conjunto de relacionamentos R.

� Uma instância de relacionamento em um esquema E-R representa a existência de uma associação entre essas entidades no mundo real no qual se insere o domínio que está sendo modelado.

� Grau do relacionamento: o relacionamento binário (envolve dois conjuntos entidades) é um relacionamento de grau 2. E assim por diante.


� Exemplo:� Considere os conjuntos entidades cliente e empréstimo. � Definimos o conjunto de relacionamentos devedor para denotar a

associação entre clientes e empréstimos bancários contraídos pelos clientes.

Jones 321-12-3123 Main Harrison

Smith 019-28-3746 North Rye

Hayes 677-89-9011 Main Harrison

Jackson 555-55-5555 Dupont Woodside

Curry 244-66-8800 North Rye

Williams 963-96-3963 Nassau Princeton

Adams 335-57-7991 Spring Pittsfield

L-17 1000

L-23 2000

L-15 1500

L-14 1500

L-93 500

L-11 900

L-16 1300


� A função que uma entidade desempenha em um relacionamento é chamada papel.

� Algumas vezes o “conjunto entidade” pode participar de um “conjunto relacionamento” mais de uma vez em papéis diferentes e, nessas situações, o papel é importante para interpretação do modelo.� Exemplo:

� Em relacionamentos recursivos, nomes explícitos de papéis são necessários para � Em relacionamentos recursivos, nomes explícitos de papéis são necessários para especificar como uma entidade participa de uma instância de relacionamento.

� Considere o conjunto de entidades empregado. Podemos ter um conjunto de relacionamentos trabalha_para que é modelado para ordenar os pares de entidades de empregado numa relação de hierarquia de cargos. Neste exemplo, os relacionamentos de trabalha-para são caracterizados pelos pares (gerente,empregado).

� Atributos descritivos em relacionamentos: atributos podem fazer parte de conjuntos relacionamentos para melhor descrever o mundo real.

� Exemplo: a data de último acesso em um conta bancária.

Mapeamento de Restrições

� Mapeamento das cardinalidades expressa o número de entidade às quais outra entidade pode estar associada via um conjunto de relacionamentos.

� Um para um: uma entidade em A está associada no máximo a uma entidade em B, e uma entidade em B está associada a no máximo uma entidade em A.

� Um para muitos: Uma entidade em A está associada a várias entidades em B. � Um para muitos: Uma entidade em A está associada a várias entidades em B. Uma entidade em B deve estar associada no máximo a uma entidade em A.

� Muitos para um: Uma entidade em A está associada a no máximo uma entidade em B. Uma entidade em B, pode estar associada a um número qualquer de entidades em A.

� Muitos para muitos: Uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A.

Interpretação:

Aluno

Aluno Curso

Curso1 1

1 N

Aluno

Aluno Curso

CursoN 1

N M

Conjunto relacionamento: Participa

Mapeamento de Restrições

� Dependência de Existência� Se a existência da entidade X depende da existência da entidade Y, então X é

dito dependente da existência de Y. � Operacionalmente, se Y deixar de existir, conseqüentemente, X deve deixar

de existir.� Exemplo:

� Considere o conjunto de entidades empréstimo e o conjunto de entidades pagamento (que mantém todas as informações sobre os pagamentos pagamento (que mantém todas as informações sobre os pagamentos realizados para um determinado empréstimo).

� O conjunto de entidades empréstimo é considerado dominante e o conjunto de entidades pagamento é considerado subordinado.

� Se todas as entidades de um conjunto participam de pelo menos um relacionamento R, este é dito total, se apenas algumas das entidades do conjunto participam do relacionamento, então este é dito parcial.

� A participação total está estreitamente relacionada à existência de dependência. Para haver dependência de existência, a participação da entidade subordinada ao relacionamento correspondente deve ser total.

Chaves� Por meio de chaves podemos diferenciar as diversas entidades

pertencentes a um conjunto de entidades, e os diversos relacionamentos pertencentes a um conjunto de relacionamentos.� Conjuntos de Entidades

� Superchave: conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira unívoca uma entidade em um conjunto de entidades.

� Chaves candidatas: Superchaves para as quais nenhum subconjunto possa ser uma superchave.possa ser uma superchave.

� Chave primária: chave candidata escolhida pelo projetista de banco de dados como a chave de significado principal para a identificação de entidades dentro de um conjunto de entidades.

� Uma chave é uma propriedade do conjunto de entidades e não de uma entidade individualmente. Quaisquer duas entidades individuais em um conjunto não podem ter, simultaneamente, mesmos valores em seus atributos-chave.

� A especificação de uma chave representa uma restrição ao mundo real do domínio que está sendo modelada.

Chaves

� Conjuntos de relacionamentos:� A composição da chave primária para um conjunto de

relacionamentos depende de uma estrutura de atributos associada ao conjunto de relacionamentos de R.

� Se o conjunto de relacionamentos não possui atributos então uma superchave deve ser formada pelas chaves de cada entidade participante do relacionamento.Se o conjunto de relacionamentos possui atributos então uma � Se o conjunto de relacionamentos possui atributos então uma superchave deve ser formada pelas chaves de cada entidade participante do relacionamento mais o conjunto de atributos deste.

� A estrutura da chave primária para o conjunto de relacionamentos depende do mapeamento da cardinalidade do conjunto.

� Muitos para muitos: união das chaves da entidade + atributos descritivos;

� Muitos para um ou um para muitos: chave da entidade do lado do muitos + atributos descritivos

� Um para um: qualquer umas das chaves primárias pode ser usada.

Projeto de um Esquema de BD

� Fases do projeto:� Levantamento de requisitos: quais são as necessidades dos usuários

do BD e como este BD será estruturado;� Construção do projeto conceitual: transcrever as necessidades

especificadas para um esquema conceitual de BD (MER);Especificação das necessidades funcionais: descrever as transações � Especificação das necessidades funcionais: descrever as transações que serão realizadas sobre os dados;

� Projeto lógico e físico: mapeamento do projeto conceitual para o modelo de implementação de dados no SGBD.

Modelo de Dados Relacional

� O Modelo Relacional (MR) é considerado o primeiro modelo de dados efetivamente usado em aplicações comerciais.

� Foi introduzido por Codd em 1970.� Foi introduzido por Codd em 1970.

� É o modelo que possui a base mais formal entre os modelos de dados, entretanto, é o mais simples e com estrutura de dados mais uniforme.

MR - Estrutura Básica

� Um banco de dados relacional consiste de uma coleção de tabelas de nomes únicos.

� Cada tabela possui um conjunto de linhas que representa um relacionamento entre um conjunto de valores.

� O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática – de onde se origina o nome deste modelo.

� Uma tabela é formada por um conjunto de colunas denominadas de atributos e por um conjunto de linhas denominadas de tuplas.

� Para cada atributo existe um conjunto de valores permitidos, chamado de domínio.

MR - Formalmente...

� Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio do atributo A2 e ... Dn denote o domínio do atributo Na da tabela T1. Qualquer linha da tabela que possui estes atributos é denotada pela tupla (d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn. Em geral, uma instância de T1 é um subconjunto de

D1 X D2 X ... X Dn.

� Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios.

As 12 Regras de Codd

� Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o quanto um banco de dados é relacional.

Algumas vezes as regras se tornam uma barreira e � Algumas vezes as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas.


1. Regra das informações em tabelas:As informações a serem armazenadas no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e colunas) e o vínculo de dados formadas por linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns. Isso se aplica tanto aos dados quanto aos metadados (que são descrições dos objetos do banco de dados).


2. Regra de acesso garantido:

Para que o usuário possa acessar as informações contidas no banco de dados, o método de referência deve ser o nome da tabela, o valor da chave primária e o nome do da tabela, o valor da chave primária e o nome do campo/coluna.


3. Regra de tratamento sistemático de valores nulos:

O SGBD deve ser capaz de tratar valores que não são fornecidos pelos usuários, de maneira que permita a distinção de dados reais. Valores nulos devem ter um distinção de dados reais. Valores nulos devem ter um tratamento diferente de “valores em branco”.


4. Regra do catálogo relacional ativo:Toda a estrutura do banco de dados (domínios, campos,

tabelas, regras de integridade, índices, etc) deve estar disponível em tabelas (também referenciadas como disponível em tabelas (também referenciadas como catálogo).

Sua manipulação é possível por meio de linguagens específicas. Essas tabelas são, geralmente, manipuladas pelo próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de dados.


5. Regras de atualização de alto-nível:

Essa regra diz que o usuário deve ter capacidade de manipular as informações do banco de dados em grupos de tuplas (registros), ou seja, ser capaz de grupos de tuplas (registros), ou seja, ser capaz de inserir, alterar e excluir várias tuplas ao mesmo tempo.


6. Regra de sub-linguagem de dados abrangente:

Pelo menos uma linguagem deve ser suportada, para que o usuário possa manipular a estrutura do banco de dados (como criação e alteração de tabelas), bem como extrair, (como criação e alteração de tabelas), bem como extrair, inserir, atualizar ou excluir dados, definir restrições de acesso e controle de transações (commit e rollback, por exemplo). Deve ser possível ainda a manipulação dos dados por meio de programas aplicativos.


7. Regra de independência física:

Quando for necessária alguma modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser necessária nas aplicações que fazem uso alteração deve ser necessária nas aplicações que fazem uso do banco de dados. Também devem permanecer inalterados os mecanismos de consulta e manipulação de dados utilizados pelos usuários finais.


8. Regra de independência lógica:

Qualquer alteração efetuada na estrutura do banco de dados como inclusão ou exclusão de atributos de uma tabela ou alteração no relacionamento entre tabelas não deve afetar o alteração no relacionamento entre tabelas não deve afetar o aplicativo que o usa.

Da mesma forma, o aplicativo somente deve manipular visões dessas tabelas.


9. Regra de atualização de visões:

Uma vez que as visões dos dados de uma ou mais tabelas são, teoricamente suscetíveis atualizações, um aplicativo que faz uso desses dados deve ser capaz de efetuar alterações, faz uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões. Essas atualizações, no entanto, devem ser repassadas automaticamente às tabelas originais.


10. Regra de independência de integridade:

As várias formas de integridade de banco de dados (integridade de entidade, integridade referencial, restrições, obrigatoriedade de valores, etc) precisam ser estabelecidas obrigatoriedade de valores, etc) precisam ser estabelecidas dentro do catálogo do sistema ou dicionário de dados, e ser totalmente independentes da lógica dos aplicativos.


11. Regra de independência de distribuição:

Alguns SGBDs, notadamente os que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentos que se encontrem plataformas/equipamentos que se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados.


12. Regra não-subversiva:

O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do mecanismos de segurança, regras de integridade do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema.

Estrutura Básica

� Um banco de dados relacional consiste de uma coleção de relações (tabelas) de nomes únicos.

� Cada tabela possui um conjunto de linhas que representa um relacionamento entre um conjunto de valores.

� O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática – de onde se origina o nome deste modelo.

� Uma tabela é formada por um conjunto de colunas denominadas de atributos e por um conjunto de linhas denominadas de tuplas.

� Para cada atributo existe um conjunto de valores permitidos, chamado de domínio.

Relação

� Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio do atributo A2 e ... Dn denote o domínio do atributo N da tabela T1. Qualquer linha da tabela que possui estes atributos é denotada pela tupla (d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn. Em geral, uma instância de T1 é um subconjunto de

D1 X D2 X ... X Dn.D1 X D2 X ... X Dn.

� Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios.

� O grau de uma relação é o número de atributos que a compõe.

Particularidades

� Atomicidade de atributo = primeira forma normal.

� Modelo relacional plano.

� O valor null.

� As relações interpretam/representam fatos sobre entidades e fatos sobre relacionamentos.

� Linguagem de consulta SQL.

Exercício: Interprete o MER e crie um MR correspondente.

Representação Tabular de Atributos Multivalorados

� Para um atributo multivalorado M, cria-se uma tabela T com uma coluna C que corresponde a M e as colunas correspondentes à chave primária do conjunto de entidades ou do conjunto conjunto de entidades ou do conjunto relacionamento do qual M é atributo.

� No exemplo da localização de departamento: cada elemento da nova tabela é uma localização de um departamento.

Representação Tabular da Generalização

� Para a situação:

num_conta saldo

conta

conta_poup conta_mov

ISAtx_juros limite

� Criar uma tabela para o conjunto de entidades de nível superior.

� Para cada conjunto de entidades de nível inferior, criar uma tabela que inclua:� Uma coluna para cada um dos atributos daquele conjunto de entidades

� Uma coluna para cada atributo da chave primária do conjunto entidades de


� Uma coluna para cada atributo da chave primária do conjunto entidades de nível superior.

� Assim:� conta, com os atributos número_conta e saldo

� conta_poupança, com os atributos número_conta e taxa_juros

� conta_movimento, com os atributos número_conta e limite_cheque_especial

� Se a generalização é mutuamente exclusiva: � nenhuma entidade é membro de mais de um conjunto de entidades de

nível imediatamente inferior ao conjunto de entidades de nível superior;� e todas as entidades do conjunto de entidades de nível superior são

membro também de um dos conjuntos de entidades de nível inferior.� Para cada conjunto de entidades de nível inferior, cria-se uma tabela que

inclua uma coluna para cada um dos atributos deste conjunto de entidades


inclua uma coluna para cada um dos atributos deste conjunto de entidades mais uma coluna para cada atributo do conjunto de entidades de nível superior

� Assim:� conta_poupança, com atributos número_conta, saldo e taxas_juros;� conta_movimento, com os atributos número_conta, saldo e

limite_cheque_especial

Representação Tabular da Agregação

� Relembrando...

seguro

nome

rua

cidade saldonúmero

empregado

Agente_emp

telefoneseguro

cliente empréstimodevedor

nome

� A tabela para o conjunto de relacionamentos agente_empréstimo inclui uma coluna para cada atributo, uma para chave primária do conjunto de entidades empregado e uma para o conjunto de relacionamentos devedor.

� Poderia também incluir uma coluna para cada um dos atributos descritivos descritivos do conjunto de relacionamentos agente_empréstimo, se eles existirem.

Representação Tabular da Agregação

� Assim:� cliente, com os atributos nome_cliente, seguro_cliente, rua, cidade;

� empréstimo, com os atributos número_empréstimo, total;

� devedor, com os atributos seguro_cliente, número_empréstimo;

� empregado, com os atributos seguro_empregado, nome_empregado, número_telefone;

� agente_empréstimo, com os atributos seguro_empregado, número empréstimo e seguro_cliente.

Diretriz de Projeto nº 1:� Modelar um esquema de relação de modo que seja

fácil explicar seu significado. Se uma relação corresponde a uma mistura de entidades e relacionamentos, resultarão em ambigüidades semânticas e a relação não poderá se explicada semânticas e a relação não poderá se explicada facilmente.

� Esquemas pobres porque violam a Diretriz 1:� Emp_dept: enome, ssn, datanasc, endereco, dnumero,

dnome, dgerssn.� Emp_proj: ssn, pnumero, horas, enome, pnome,

plocalização.

Redução de Valores Redundantes nas Tuplas

� Deve-se minimizar o espaço de armazenamento utilizado pelas relações básicas:� Agrupe atributos em esquemas de relações;

� Deve-se evitar situações que caiam em problemas de Anomalias na Atualização.

Diretriz Projeto nº 2:� Modelar esquemas de relações básicas de forma que

nenhuma anomalia de atualização possa ocorrer nas relações. Se houver a possibilidade de ocorrer alguma anomalia, registre-a claramente e tenha certeza de que os programas que atualizam o banco de dados operarão programas que atualizam o banco de dados operarão corretamente.

� Pode-se violar uma diretriz em prol do desempenho de uma consulta, entretanto, as medidas cabíveis devem ser tomadas para que os dados estejam sempre consistentes e íntegros.

Redução de Valores null nas Tuplas

� A existência de muitas possibilidades de uso do valor nullcausa desperdício de espaço no armazenamento e gera problema de entendimento do significado do atributos e da especificações de joins, e funções agregadas.

� Motivos para uso do null:� O atributo não se aplica à tupla;� O valor do atributo para a tupla é desconhecido;� O valor do atributo para a tupla é conhecido, mas ausente, ou seja,

ainda não foi registrado.

Diretriz Projeto nº 3:

� Até onde for possível, evite colocar os atributos em uma relação básica cujos valores freqüentemente possam ser nulos. Se os nulls forem inevitáveis, tenha certeza de que eles se aplicam somente em casos excepcionais e não na maioria das tuplas da relação.maioria das tuplas da relação.

� Ex: se só 10% dos empregados tiverem escritórios particulares, há pouca justificativa para incluir um atributo ESCRITORIO-NRO na relação EMPREGADO; pode ser criada uma relação EMP_ESCRITÖRIOS (ESSN, ESCRITORIO_NRO) que contenha apenas as tuplas dos empregados que possuírem escritórios particulares.

Impedimento para a Geração de Valores Ilegítimos nas Tuplas

� Considere os esquemas:� Esquema 1:

� Emp_locs (enome, plocalização)� Emp_proj1 (ssn, pnumero, horas, pnome, plocalização)

� Esquema 2:� Emp_proj: (ssn, pnumero, horas, enome, pnome, plocalização)

� A partir do esquema 1 é possível conseguir as mesmas informações que temos no esquema 2?

� Não, usando um JOIN conseguiremos tuplas ilegítimas.

Diretriz Projeto nº 4:

� Projete os esquemas de relações de forma que possam ser unidos (join) com igualdade de condições sobre os atributos que sejam chaves primárias ou chaves estrangeiras, de modo a primárias ou chaves estrangeiras, de modo a garantir que nenhuma tupla ilegítima seja gerada.

Normalização

� A normalização de dados pode ser vista como o processo de análise de determinados esquemas de relações com base em suas dependências funcionais e chaves primárias para alcançar as propriedades desejáveis:� Minimização de redundâncias;

� Minimização de modificações.� Minimização de modificações.

� O esquemas de relações insatisfatórias, que não alcançam certas condições – os testes de forma normal -, são decompostas em esquemas de relações menores que passam nos testes e, conseqüentemente, possuem as propriedades desejadas.

Conceitos

� A forma normal de uma relação refere-se à condição da mais alta forma normal alcançada e, conseqüentemente, indica o grau no qual foi normalizada.

� A normalização sempre deve estar acompanhada da garantia de duas propriedades:propriedades:

� Junção sem perdas: Garante que o problema de geração de tuplas ilegítimas não ocorra (propriedade crítica que deve sempre ser garantida);

� Preservação de dependências: Garante que cada dependência funcional será representada em alguma relação individual resultante da decomposição.

Primeira Forma Normal (1NF)

� Impedimento para a criação de atributos multivalorados, atributos compostos e combinações entre eles.

� Estabelece-se que o domínio de um atributo só deva incluir os valores atômicos e que o valor de qualquer atributo em uma tupla deve ter um atômicos e que o valor de qualquer atributo em uma tupla deve ter um único valor no domínio daquele atributo.

� A 1NF impede as “relações dentro de relações” ou “relações como valores de atributos dentro de tuplas”.

Primeira Forma Normal

� Considerando o departamento que possui um atributo multivalorado: localizações. Há três técnicas básicas para alcançar a primeira forma normal:

1. Remover o atributo DLocalizações que viola a 1NF e colocá-lo em uma 1. Remover o atributo DLocalizações que viola a 1NF e colocá-lo em uma relação separada, junto com a chave primária que identifica a entidade “departamento”.

2. Ampliar as chaves de forma a separar as tuplas da relação original DEPARTAMENTO, criando uma para cada localização de “departamento”.

3. Se um número máximo de valores puder ser estabelecido para o atributos, por exemplo, se é sabido que há no máximo três locais para cada departamento, substituir o atributo Dlocalizações por três atributos atômicos.

Segunda Forma Normal (2NF)

� Baseada no conceito de dependência funcional total.

� Uma dependência funcional X � Y será uma dependência funcional total se a remoção de qualquer atributo A de X funcional total se a remoção de qualquer atributo A de X implicar que a dependência não mais será assegurada, isto é, para qualquer atributo A ∈ X, (X – {A}) não determina funcionalmente Y.

� Uma dependência funcional X � Y é uma dependência parcial se um atributo A ∈ X puder ser removido de X e a dependência mesmo assim continuar existindo, ou seja, para algum A ∈ X, (X – {A}) � Y.

Segunda Forma Normal

� Exemplo de dependências funcionais totais e parciais:

� Considere o esquema:SSN, PNumero, Horas, Enome, Pnome, PlocalizaçãoSSN, PNumero, Horas, Enome, Pnome, Plocalização

� {SSN, PNumero} � Horas: é uma dependência funcional total (não são asseguradas nem SSN � Horas nem PNumero �Horas).

� {SSN, PNumero} � Enome: é uma dependência funcional parcial porque SSN � Enome é assegurada.


� Um esquema de relação R está na 2NF se todo atributo não primário A em R tem dependência funcional total da chave primária de R.

� O teste para a 2NF envolve verificar se os atributos do lado esquerdo das dependência funcionais fazem parte da chave primária. Se a chave dependência funcionais fazem parte da chave primária. Se a chave primária contiver um único atributo, a necessidade do teste não se aplica.

� A relação do slide anterior está na 1NF mas não está na 2NF. O atributo não primário enome viola a 2NF em razão da dependência funcional SSN � Enome. Enome é parcialmente dependente da chave primária (já que depende de SSN).


� Um esquema pode ser normalizado na 2NF por meio da criação de várias relações na 2NF nas quais os atributos não primários só estarão associados a dependências funcionais total.

Considere o esquema abaixo e suas dependências funcionais:� Considere o esquema abaixo e suas dependências funcionais:

SSN, PNumero, Horas, Enome, Pnome, Plocalização

SSN, PNumero � Horas

SSN � Enome

PNumero � Pnome, Plocalização


� Normalizando, cria-se três esquemas:

Esquema1: SSN, Pnumero, Horascom a dependência funcional: SSN, PNumero � Horascom a dependência funcional: SSN, PNumero � Horas

Esquema 2: SSN, Enomecom a dependênia funcional: SSN � Enome

Esquema 3: PNumero, Pnome, Plocalização com a dependência funcional: PNumero � Pnome, Plocalização

Terceira Forma Normal (3NF)

� De acordo com a definição original de Codd, um esquema de relação R está na 3NF se satisfizer a 2NF e se nenhum atributo não primário de R for transitivamente dependente da chave primária.

� Está baseada no conceito de dependência transitiva.

� Uma dependência funcional X � Y, em um esquema de relação R, será uma dependência transitiva se existir um conjunto de atributos Z que não é nem uma chave candidata nem um subconjunto de qualquer chave de R, e ambas X �Z e Z � Y forem asseguradas.

Terceira Forma Normal

� Como exemplo, considere o seguinte esquema com sua dependências funcionais:

Enome, SSN, DataNasc, Endereço, Dnumero, Dnome, DgerSSN

SSN � Enome, DataNasc, Endereco, DNumeroSSN � Enome, DataNasc, Endereco, DNumeroDNumero � Dnome, DgerSSN

A dependência funcional SSN � DgerSSN é transitiva para Dnumero, pois ambas as dependências SSN � Dnumero e Dnumero �DgerSSN são asseguradas e Dnumero não é nem chave primária nem um subconjunto da chave da relação.

�A normalização na 3NF para o exemplo se dá por meio da decomposição:

Terceira Forma Normal

Esquema 1: Enome, SSN, DataNasc, Endereço, Dnumero

com a dependência funcional: SSN � Enome, DataNasc, Endereco, DNumero

Esquema 2: Dnumero, Dnome, DgerSSN

com a dependência funcional: DNumero � Dnome, DgerSSN

Generalização

� As definições tratadas até aqui dizem respeito a parcialidade e transitividade de dependencias funcionais com respeito à chave primária da relação.

� Estas definições devem ser expandidas para a consideração de todas as chaves candidatas.chaves candidatas.

� 2NF: um esquema de relação R está na segunda forma normal se cada atributo não primário A de R não forem parcialmente dependente de nenhuma chave de R.

� 3NF: um esquema de relação R está na terceira forma normal se sempre que uma depependência funcional não trivial X � A for determinada em R, então: (A) qualquer X é uma superchave de R; ou (B) A é um atributo primário de R.

Mais um exemplo:

� Esquema Lotes:

Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preço, Imposto

� Dependências funcionais:� Dependências funcionais:

DF 1: Num_ID_Propriedade � Municipio_nome, Num_lote, Area, Preço, ImpostoDF 2: Municipio_nome, Num_lote � Num_ID_Propriedade, Area, Preço, ImpostoDF 3: Municipio_nome � ImpostoDF 4: Area � Preço

Colocando na 2NF:

� O esquema de relação Lotes viola a definição GERAL da 2NF porque Imposto é parcialmente dependente da chave candidata {Municipio_nome, Num_lote} em razão da terceira dependência funcional.

� Construímos então o esquema Lotes 1 removendo o atributo Imposto que viola a 2NF de Lotes, para colocá-lo com Municipio_nome em outro esquema: Lotes 2.esquema: Lotes 2.

� Lotes1 : Num_ID_Propriedade, Municipio_nome, Num_lote, Area, PreçoCom as DFs 1, 2 e 4

� Lotes2: Municipio_nome, ImpostoCom a DF 3.

Note que a DF 4 não viola a 2NF.

Colocando na 3NF:

� Lotes2 está na 3NF.

� Lotes1 não está pois a dependência funcional 4 viola a definição GERAL. � Área não é uma superchave;

� Preço não é um atributo primário em Lotes1.

� Construímos:� Lotes1a: Num_ID_Propriedade, Municipio_nome, Num_lote, Area

Com as DFs 1 e 2.

� Lotes1b: Area, Preço

Com a DF 4.

Forma Normal de Boyce-Codd (BCNF)

� Foi proposta como uma forma normal mais simples de 3NF, mas é considerada mas rígida que a 3NF.

� Toda relação BCNF está também em 3NF, mas o contrário pode não ser verdadeiro.pode não ser verdadeiro.

� Definição: Um esquema de relação R está na BCNF sempre que uma dependência funcional não trivial X � A for mantida em R, então X será uma superchave de R.

BCNF

� Suponha a seguinte situação para o último exemplo modelado:

Existem milhares de lotes cadastrados mas eles estão localizados em apenas duas cidades. E as áreas dos lotes nas duas cidades são definidas de formas diferentes. Assim, a duas cidades são definidas de formas diferentes. Assim, a dependência funcional Area � Municipio_nome deveria valer.

� Ainda assim, Lotes1a estaria na 3NF, pois Municipio_nome é um atributo primário.

BCNF

� Mas existe redundância de informação, pois a área que determina o município, como dito pela nova dependência funcional, pode ser representada uma única vez, em uma relação a parte.

� A BCNF sugere a decomposição do esquema Lotes1a em:

Lotes1ax : Num_ID_propriedade, Area, Num_lotecom as DFs 1 e 2.

Lotes1ay : Area, Municipio_nomecom a DF 5.

� Cuidado com a decomposição com perdas na junção!

BCNF - Exemplos

� Relembrando: Uma relação R está na BCNF sse R está na 3NF e nenhum atributo possua dependência transitiva em relação à chave primária.

Exemplo:Relação CURSA

ALUNO DISCIPLINA TUTOR

Nagiza Banco de Dados I Korth

Silvio Banco de Dados I Navathe

Silvio Banco de Dados II Setzer

Silvio Data Mining Duhran

William Banco de Dados I Korth

William Banco de Dados II Elmasri

Zélia Banco de Dados I Date

Camila Banco de Dados I Navathe

BCNF - Exemplo

Primeiro, têm-se que identificar as DF envolvendo atributos que pertençam a chave primária.

Tutor � Disciplina

Aluno, Disciplina � Tutor Há dependência transitiva da chave primária!

Relação CURSA

ALUNO DISCIPLINA TUTOR

� A relação acima está na 3NF e na BCNF?

BCNF - Exemplo

A relação está na 3NF pois possui somente atributos atômicos, não apresenta dependência parcial da chave primária e não existem DFs de um atributo não pertencente a chave primária em relação a atributos não pertencentes à chave primária. Porém, não está na BCNF pois possui chave primária. Porém, não está na BCNF pois possui dependência transitiva de um atributo chave com relação à chave primária.

A solução seria separar a relação em duas ou mais relações, de forma a eliminar a dependência transitiva:

Tutoria (Tutor, Disciplina)

Cursa(Tutor, Aluno)

� Considere a relação orientador abaixo. Suponha que as exigências básicas dessa relação sejam: Um aluno (IDAL) pode ter mais que uma especialização, uma especialização pode ter vários membros do

BCNF – Outro Exemplo

uma especialização pode ter vários membros do corpo docente (Fnome) como orientadores e um professor orienta somente em uma área de especialização.

Relação Orientador

IDAL Especialização Fnome

100 Matemática Caughy

150 Psicologia Jung

200 Matemática Riemann


� DF:Fnome � Especialização


250 Matemática Caughy

300 Psicologia Perls


� Há nessa relação uma anomalia de eliminação (por exemplo, se o aluno 300 sair da escola e se seus registros forem apagados, perde-se o fato de que Perls orienta em psicologia) e existe também uma


Perls orienta em psicologia) e existe também uma anomalia de inserção (Não se pode armazenar um orientador em uma área, a não ser que um aluno se especialize na cadeira).


Relação Al_Orient

IDAL Fnome

100 Caughy

Relação Orient_Discip

Fnome Especialização

Caughy Matemática

150 Jung

200 Riemann

250 Caughy

300 Perls

300 Riemann

Jung Psicologia

Riemann Matemática

Perls Psicologia

Agora sim, está na BCNF.

Dependência Multivalorada

“Dada uma relação qualquer com três atributos x, y e z, diz-

se que y depende de forma multivalorada de x sse

sempre que existirem duas tuplas (x1,y1,z1) e (x1,y2,z2)

existirão também duas tuplas (x1,y1,z2) e (x1,y2,z1)”.

� Refere-se à combinação de valores de atributos multivalorados disjuntos (y e z).

� x na verdade, relaciona-se com y e com z de forma independente.

“Uma tabela está na 4FN sse estiver na 3FN e não existirem dependências multivaloradas”.

� Exemplo: Dados sobre livrosRelação não normalizada: Livros(nrol, (autor), título, (assunto),

editora, cid_edit, ano_public)

4ª Forma Normal (4NF)

editora, cid_edit, ano_public)1FN: Livros(nrol, autor, assunto, título, editora, cid_edit,

ano_public)2FN: Livros(nrol,título, editora, cid-edit, ano_public)

AutAssLiv(nrol, autor, assunto)3FN: Livros(nrol, título, editora, ano_public)

Editoras(editora, cid-edit)AutAssLiv(nrol, autor, assunto)

Nrol Autor Assunto

1 aut1 ass1

1 aut1 ass2

1 aut2 ass1

1 aut2 ass2

2 aut1 ass3

2 aut1 ass4


2 aut1 ass4

2 aut1 ass1

2 aut3 ass3

2 aut3 ass4

2 aut3 ass1

� Redundância para representar todas as informações;� Evitar todas as combinações: representação não-uniforme (repete alguns elementos ou posições nulas).

Passagem à 4FN

� Geração de novas tabelas, eliminando Dependências Multivaloradas

� Análise de Dependências Multivaloradas entre atributos:autor, assunto� � Dependência multivalorada de nrol

Resultado:

4FN: Livros(nrol, título, editora, ano_public)

Editoras(editora, cid-edit)

AutLiv(nrol, autor)

AssLiv(nrol, assunto)

4ª Forma Normal – Outro Exemplo

Relação Aluno

IDAL Especialização Atividade

100 Música NataçãoDF múltiplas:

100 Contabilidade Natação

100 Música Tênis

100 Contabilidade Tênis

150 Matemática Jogging

DF múltiplas:IDAL � � EspecializaçãoIDAL � � Atividade

4ª Forma Normal – Outro ExemploRelação Aluno

IDAL Especializaçã

o

Atividade

100 Música Natação


Relação Aluno

IDAL Especializaçã

o

Atividade

100 Música Natação


100 Música Tênis



100 Música Esqui

100 Música Tênis



100 Música Esqui

100 Contabilidade Esqui

Ao inserir nova atividade ao aluno 100 com a especialização música, deve-se inserir também outra tupla, o que mostra uma anomalia de atualização.

4ª Forma Normal – Outro Exemplo

Relação Al_Espec

IDAL Especialização

100 Música

100 Contabilidade

Relação Al_Ativ

IDAL Atividade

100 Esqui

100 Natação100 Contabilidade

150 Matemática100 Tênis

150 Jogging

Agora sim, está na BCNF, sem dependências multivaloradas!


“Uma tabela está na 5FN sse estiver na 4FN e um relacionamento triplo não puder ser decomposto em relacionamentos binários sem geração de informação incorreta”.

Caso especial: Relacionamento envolvendo Chaves primárias de 3 tabelas, que nem sempre é possível decomposição correta.

Exemplo: relacionamento Agente-Companhia-ProdutoExemplo: relacionamento Agente-Companhia-Produto

Agente Companhia Produto

João Ford Carro

João GM Caminhão

5ª Forma Normal

� Formato necessário quando existem apenas algumas combinações entre os 3 atributos (tabela c/ tripla).

� Situação: Se um agente vende um certo produto e ele � Situação: Se um agente vende um certo produto e ele representa uma companhia, então ele vende um produto

fabricado por esta companhia � Todos os pares se

combinam!

Agente Companhia Produto

João Ford Carro

João Ford Caminhão

João GM Carro

5ª Forma Normal

Neste caso, é possível decompor uma tripla em três relações binárias com eliminação de certas redundâncias.

João GM Carro

João GM Caminhão

Carlos Ford Carro

Agente Companhia

João Ford

João GM

Agente Produto

João Carro

Companhia Produto

Ford Carro

Ford Caminhão

As três relações abaixo estão na 5FN:

5ª Forma Normal

� Eliminação de certas redundâncias:- Apenas uma vez está dito que Ford produz carros;

- Apenas uma vez está dito que João é agente da GM.� Apesar do aumento no número de tabelas, o número total de

tuplas na forma normalizada é menor.

João GM

Carlos Ford

João Caminhão

Carlos Carro

Ford Caminhão

GM Carro

GM Caminhão

Banco de Dados Orientado a Objetos - Motivações� Novas aplicações ficaram limitadas por restrições impostas pelo modelo

relacional.

� As aplicações convencionais possuem características comuns que as tornam passíveis de serem tratadas por bancos de dados relacionais:� Uniformidade: as informações a serem armazenadas podem ser � Uniformidade: as informações a serem armazenadas podem ser

estruturadas de maneira similar.� Orientação a registros: registros de tamanho fixo são adequados para a

representação desta informação.� Itens de dados pequenos: as informações são estruturadas em registros

pequenos.� Campos atômicos: os campos dentro de um registro são pequenos e de

comprimento fixo. Não há estruturas dentro dos campos, ou seja, a primeira forma normal pode ser mantida.

� O modelo de banco de dados orientado a objetos está baseado no paradigma de programação orientada a objeto.

Introdução e Motivações

� As aplicações mais novas, em geral, não possuem, no mínimo, uma das características já citadas.

� Exemplos dessas aplicações:� Computer-aided design (CAD) – projeto auxiliado por computador:

� É necessário armazenar os dados pertencentes a um projeto de � É necessário armazenar os dados pertencentes a um projeto de engenharia, incluindo os componentes do item que está sendo projetado, o inter-relacionamento dos componentes, as versões antigas do projeto.

� Computer-aided software engineering (CASE) – engenharia de software auxiliada por computador:

� É necessário armazenar os dados necessários para apoiar os desenvolvedores de software, incluindo o código-fonte, as dependências entre os módulos de software, as definições e o uso de variáveis e o histórico de desenvolvimento do sistema de software.

Introdução e Motivações

� Bancos de dados multimídia:� Contém imagens, dados espaciais, dados de áudio, dados de vídeo e

afins (envolvem principalmente o armazenamento de fotografias e dados geográficos, voz e vídeo).

� Office information system (OIS) – sistemas de informação de escritório:escritório:

� Necessidade de suportar dados para ferramentas para criação e recuperação de documentos e ferramentas para manutenção de calendários, permitindo solicitações pertencentes a agendas, documentos e conteúdos de documentos.

� Bancos de dados de hipertexto: � Necessidade de suportar o armazenamento/gerenciamento das estruturas

específicas e indexação de textos enriquecidos com links que apontam para outros documentos, permitindo a recuperação de documentos baseados em sua estrutura.

Modelagem de BDOOs

� Isso:

Modelagem de BDOOs

� Ao invés disso:

O Modelo de Dados Orientado a Objeto

� A estrutura objeto:

� Superficialmente, um objeto corresponde a uma entidade no modelo E-R.� Este paradigma se baseia no encapsulamento de dados e em código

relacionado a um objeto dentro de uma única unidade.� As interações entre um objeto e o resto do sistema deve ser via

mensagens.� Uma interface entre um objeto e o resto do sistema deve ser definida por � Uma interface entre um objeto e o resto do sistema deve ser definida por

um conjunto de mensagens permitidas.

� Em geral, um objeto tem associado a ele:

� Um conjunto de variáveis que contém os dados para o objeto; as variáveis correspondem aos atributos no modelo E-R;

� Um conjunto de mensagens ao qual o objeto responde; cada mensagem pode ter zero, um ou mais parâmetros;

� Um conjunto de métodos, cada qual sendo um corpo de código para implementar a mensagem; um método retorna um valor como resposta à mensagem.


� O termo mensagem em um contexto orientado a objeto se refere à passagem de pedidos entre os objetos sem considerar detalhes específicos de implementação.

� O termo chamar um método algumas vezes é usado para representar o ato de enviar uma mensagem a um objeto e a execução do método correspondente.

� Exemplo:� Considerando a entidade empregado em um banco de dados. Suponha que o salário anual � Considerando a entidade empregado em um banco de dados. Suponha que o salário anual

de um empregado seja calculado de maneiras diferentes para diferentes empregados. Por exemplo, os gerentes podem ter um bônus dependendo do desempenho do banco, enquanto os caixas podem obter um bônus dependendo de quantas horas eles trabalharam. É possível encapsular o código para calcular o salário para cada empregado como um método que é executado em resposta a uma mensagem salário_anual.

� Todos os objetos empregado respondem à mensagem salário_anual, mas fazem isso de diferentes maneiras. Pelo encapsulamento da informação sobre como calcular o salário anual dentro do objeto empregado, todos os objetos empregados apresentam a mesma interface.

� É possível modificar a definição de um objeto sem afetar o resto do sistema. Esta é uma das habilidades considerada como uma das maiores vantagens do paradigma de programação orientado a objetos.


� Os métodos de um objeto podem ser:� Somente leitura: não afeta os valores das variáveis em um objeto;� De atualização: pode mudar os valores das variáveis.

� As mensagens às quais um objeto responde podem ser, de maneira similar, classificadas como somente leitura ou de atualização, em função do método que implementa a mensagem.

� Cada atributo de uma entidade deve ser expresso como uma variável e um par de mensagens do objeto no modelo orientado a objeto. A variável é usada para armazenar o valor do atributo, uma mensagem é usada para ler o valor do atributo e o outro método é usado para atualizar o valor. Por exemplo:� O atributo endereço da entidade empregado pode ser representado por:

� Uma variável endereço;� Uma mensagem obter_endereço cuja resposta é o endereço;� Uma mensagem ajustar_endereço, que possui um parâmetro novo_endereço, para atualizar o

endereço.

� Por simplicidade muitos modelos orientados a objeto permitem que as variáveis sejam lidas ou atualizadas diretamente, sem ter de definir mensagens para isso.

Classes de Objetos

� Objetos similares são aqueles que respondem às mesmas mensagens, usam os mesmos métodos e têm variáveis de mesmo nome e tipo.

� Objetos similares são agrupados formando uma classes.� Cada um desses objetos é chamada de uma instância de sua classe.� A noção de uma classe no modelo de dados orientado a objeto corresponde à noção de um

conjunto entidade do modelo E-R.

� Exemplo de definição de uma classe:� Exemplo de definição de uma classe:

Class empregado {/* variáveis */

string nome;string endereço;date data_início;int salário;

/* mensagen */int salário_anual();string obter_nome();string obter_endereço();int ajustar_endereço (string novo_endereço);int tempo_emprego();

}

Classes de Objetos

� Cada classe é um objeto em si e inclui uma variável contendo o conjunto de todas as instâncias da classe.

� Uma classe objeto inclui:

� Uma variável conjunto valorada cujo valor é o conjunto de todos os � Uma variável conjunto valorada cujo valor é o conjunto de todos os objetos que são instâncias da classe;

� A implementação de um método para a mensagem new, que cria uma nova instância da classe.

Herança� Considerando um banco de dados orientado a objetos para a aplicação bancária

(exemplo – Korth), a classe clientes é similar à classe empregados, pois ambas definem variáveis para nome, endereço e assim por diante. No entanto, há variáveis específicas para empregados (salário) e variáveis específicas para clientes (classificação_crédito).

� Neste caso é desejável definir uma representação para as variáveis comuns em um único local. Para isso, combina-se empregados e clientes dentro de uma classe.

� Para permitir a representação direta de similaridades entre classes, necessita-se colocar as classes em uma hierarquia de especialização.� Empregado e cliente são especializações de pessoa.

� Este conceito é similar ao conceito de especialização no modelo E-R.

� Empregados e clientes podem ser representados por classes que são especializações de uma classe pessoa. Variáveis e métodos específicos a empregados são associados à classe empregados. Variáveis e métodos específicos a clientes são associados à classe cliente. Variáveis e métodos que se aplicam tanto a empregados como a clientes são associados à classe pessoa.

class pessoa {string nome;string endereço;

};class cliente isa pessoa {

int classificação_crédito};class empregado isa pessoa {

date data_início;int salário;

};class escriturário isa empregado {class escriturário isa empregado {

int número_escriturário;int número_conta_despesa;

};class caixa isa empregado {

int horas_por_semana;int número_estação;

};class secretária isa empregado {

int horas_por_semana;string gerente;

};

Herança

� Um benefício importante da herança em sistemas orientados a objeto é a noção de reusabilidade.

� Qualquer método de uma classe pode ser invocado por qualquer objeto pertencente a qualquer subclasse desta classe.

Para tratar a hierarquia de classes tem-se duas opções:� Para tratar a hierarquia de classes tem-se duas opções:� Associar à classe empregado todos os objetos empregado, incluindo aqueles

que são instâncias de escriturário, caixa e secretária.� Associar à classe empregado somente aqueles objetos empregado que não

são instâncias nem de escriturário, nem de caixa, nem de secretária.� É possível determinar o conjunto de todos os objetos empregado, nesse caso,

tomando-se a união daqueles objetos associados a todas as subclasses de empregado.

Herança Múltipla

� Suponha que precisemos distinguir entre escriturários, caixas e secretárias de tempo integral e tempo parcial. Além disso, assuma que são necessárias diferentes variáveis e métodos para representar empregados de tempo parcial e tempo integral. Então cada um desses empregados são classificados de duas maneiras diferentes.

secretária_TP

pessoa

empregado cliente

escriturário caixa secretária

caixa_TI caixa_TP secretária_TIescrit_TI escrit_TP

Herança Múltipla

� Existem certas variáveis e métodos específicos para empregado em tempo integral e outros específicos para empregado em tempo parcial. Assim, na hierarquia em análise, as variáveis e métodos para empregados de tempo integral devem ser definidos três vezes: uma vez para escriturário_TI, uma vez para secretária_TI e uma vez para caixa_TI. Redundâncias deste tipo são indesejáveis mediante alterações nas propriedades dos empregados de tempo integral (e parcial), que deverão ser feitas em dois lugares diferentes.

� Existe falha na exploração da reutilização de código.

� Nesta hierarquia também não se consegue representar os empregados que não são escriturários, caixas ou secretárias, mas que possuem características de serem ou de tempo parcial ou integral.

� Se existissem várias classificações de emprego, em vez de duas limitações neste exemplo, as limitações do modelo se tornariam muito mais aparentes.

Herança Múltipla

� Herança múltipla é a habilidade de uma classe herdar variáveis e métodos a partir de múltiplas superclasses.

pessoa

escrit_TI

empregado cliente

tempo_integral tempo_parcial caixa secretária

caixa_TI caixa_TP secretária_TI secretária_TPescrit_TP

escriturário

� Pode haver algum problema?

Herança Múltipla

� Assuma que, em vez de definir salário para a classe empregado, defina-se uma variável chamada pagamento para cada classe: tempo_integral, tempo_parcial, escriturário, caixa e secretária, como a seguir:� Tempo_integral: pagamento é um inteiro de 0 a 100.000 contendo um salário anual;� Tempo_parcial: pagamento é um inteiro de 0 a 20, contendo uma taxa horária de

pagamento.� Caixa e escriturário: pagamento é um inteiro de 0 a 20.000, contendo um salário anual;� Secretária: pagamento é um inteiro de 0 a 25.000, contendo um salário anual.� Secretária: pagamento é um inteiro de 0 a 25.000, contendo um salário anual.

� Considere a classe secretária_TP. Ela pode herdar a definição de pagamento tanto de tempo_parcial como de secretária. O resultado é diferente, dependendo da escolha feita.

� Opções:� Incluir ambas as variáveis, renomenado-as como tempo_parcial.pagamento e

secretária.pagamento;

� Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e secretária foram criadas;

� Forçar o usuário a fazer a escolha;� Tratar a situação como um erro.

Identidade de Objeto

� Os objetos em um banco de dados orientado a objeto correspondem a uma entidade na empresa que está sendo modelada. Uma entidade mantém sua identidade mesmo se algumas de suas propriedades mudam com o tempo.

� Um objeto mantém sua identidade mesmo se alguns ou todos os seus valores de variáveis ou definições de métodos mudarem com o tempo.

� Diferente do modelo relacional onde as tuplas de uma relação são diferenciadas somente pelos valores que elas contêm.

� Formas de identidade:� Valor: usado em modelos relacionais � um valor de dado é usado para identidade da

tupla;� Nome: usado em sistemas de arquivos � um nome fornecido pelo usuário é usado

para identidade dos arquivos;� Embutido: usado em sistemas orientados a objetos � a cada objeto é atribuído

automaticamente um identificador pelo sistema quando aquele objeto é criado.

Identidade de Objeto

automaticamente um identificador pelo sistema quando aquele objeto é criado.

� Identificadores de objetos são únicos. Exemplo de uso do identificador:� Um dos atributos de um objeto pessoa pode ser o atributo cônjuge, que é realmente

um identificador do objeto pessoa correspondendo ao cônjuge da primeira pessoa. Assim, o objeto pessoa pode armazenar uma referência ao objeto que representa o cônjuge de pessoa.

Objetos Compostos

� As referências entre os objetos podem ser usadas para modelar diferentes conceitos do mundo real. Um desses conceitos é o de objetos compostos.

bicicletaÉ parte de

roda freio marcha quadro

aro raio pneu pedal bloco cabo

É parte de

� O conceito de composição permite que os dados sejam vistos em diferentes granularidades por diferentes usuários.

Modelagem de BDOOs

� Representação no BDOO:� Um BDOO armazena objetos integralmente; � É possível recuperar um objeto a qualquer momento, inclusive todas as

referências.

� Linguagem de definição:� ODL (Object Definition Language);� Utilizada para criar definições de objetos.

� Linguagem de consulta:� OQL (Object Query Language);� Utilizada para recuperar objetos do banco.

Modelagem de BDOOs

Classes

Modelagem de BDOOs

Fabricante{OID1}

Ford

João da Silva

[OID1125, OID1127, OID1128]

Automóvel{OID12}

736194174

Ka

Preto

20000

OID1

[OID5123]

Objetos

Fábrica {OID1127}

Filial São Bernardo I

São Bernardo

250

Fábrica {OID1128}

Filial São Bernardo II

São Bernardo

130

Fábrica {OID1125}

Central

Camaçari

320

Motor{OID154}

Rocam 1000 16V

OID1

120CV

Peça{OID5123}

Correia Dentada

Ford

OID154

[OID1125, OID1127, OID1128]

Modelagem de BDOOs

Automóvel{OID12}

736194174

Ka

Preto

20000

Fabricante{OID1}

Objeto Complexo

Ford

João da Silva

Fábrica {OID1127}

Filial São Bernardo I

São Bernardo

250

Fábrica {OID1128}

Filial São Bernardo

II

São Bernardo

130

Fábrica {OID1125}

Central

Camaçari

320

Motor{OID154}

Rocam 1000 16V

120 CV

Modelagem Padrão ODMG – ODL

Especificação ODL

class Pessoa

(extent pessoas

key nss)

{

attribute struct Nomep{string sobrenome, string primeiro_nome} nome;

attribute string nss;

attribute date data_nascimento;

attribute enum Genero{M,F} sexo;

attribute struct Endereço

{short num, string logradouro, sort numapto, string cidade, string estado, short

cpe}

endereço;

short idade();

};

class Professor extends Pessoa( extent professores ){attribute string classificação;attribute float salário;

Especificação ODL

attribute float salário;attribute string escritório;attribute string telefone;relationship Departamento trabalha_em inverse Departamento::possui_professor;relationship set<aluno_grad> dá_assistência inverse AlunoGrad::assistente;relationship set<aluno_grad> no_comitê_de inverse AlunoGrad::comitê;void dar_aumento(in float aumento);void promove(in string nova_classificação);};

class Grau

( extent graus)

{

attribute enum GrauValores{A,B,C,D,F,I,P} grau;

relationship Disciplina disciplina inverse Disciplina::alunos;

Especificação ODL

relationship Disciplina disciplina inverse Disciplina::alunos;

relationship Aluno aluno inverse Alunos::disciplinas_completadas;

};

class Aluno extends Pessoa( extent alunos){attribute string classe;attribute Departamento cursa_eletiva_em;relationship Departamento especializa_em inverse

Especificação ODL

relationship Departamento especializa_em inverse

Departamento::possui_especializações;relationship set <grau> disciplinas_completadas inverse Grau::alunos;relationship set <DisciplinaCorrente> registrado_em inverse

DisciplinaCorrente::alunos_registrados;void alterar_especialização (in string nomed) raises disciplina_inválida);float mg();void registrado(in short nomseção; in ValorGrau grau)raise (disciplina_inválida,grau_invalido);};

select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome)

from s in departamentocc.possui_especializaçõeswhere s.classe = ‘Superior’order by sobrenome asc;

Especificação OQL

select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome)

from s in alunoswhere s.especializa_em.nomed = ‘Ciência da Computação’order by sobrenome asc;

Linguagens Orientadas a Objeto

� Para que estes conceitos básicos de orientação a objetos sejam usados na prática em um sistemas de banco de dados, eles devem ser expressos em alguma linguagem. Esta representação pode ser feita de duas formas:� Os conceitos são usados puramente como uma ferramenta de projeto

e são codificados, por exemplo, em um banco de dados relacional;� Os conceitos de orientação a objetos são incorporados em uma � Os conceitos de orientação a objetos são incorporados em uma

linguagem que é usada para manipular o banco de dados.� Extensão de uma linguagem de manipulação de dados, como a SQL,

pela adição de tipos complexos e orientação a objetos.� Tomar uma linguagem de programação orientada a objeto e estendê-la

para tratar banco de dados (são as linguagens de programação persistentes).

Linguagens de Programação Persistentes

� Linguagens de bancos de dados diferem das linguagens de programação tradicionais pelo fato de que elas manipulam diretamente os dados que são persistentes, ou seja, dados que continuam a existir mesmo depois que o programa que os criou tenha terminado.

� Uma linguagem de programação persistente é uma linguagem de programação estendida com estruturas para tratar dados persistentes. programação estendida com estruturas para tratar dados persistentes.

� Versões persistentes de linguagens de programação como C++ ou Smalltalk estão entre as mais importantes. Elas permitem que o programador manipule os dados do banco de dados sem passar por uma linguagem de manipulação de dados como a SQL.

� Essas linguagens são poderosas e é relativamente fácil cometer erros de programação que danifiquem o banco de dados.

Persistência de Objetos

� Persistência por classe: Declarar que uma classe é persistente. Assim, todos os objetos da classe são, por default, persistentes. Os objetos de classes não persistentes são transientes.

� Persistência por criação: Um objeto é persistente ou transiente, dependendo de como ele foi criado.

� Persistência por marcação: Todos os objetos são criados como transientes mas, � Persistência por marcação: Todos os objetos são criados como transientes mas, se um objeto deve persistir alem da execução do programa, ele deve ser marcado explicitamente como persistente antes do programa terminar.

� Persistência por referência: Um ou mais objetos são explicitamente declarados como objetos persistentes (raiz). Todos os outros objetos são persistentes se (e somente se) forem referidos diretamente, ou indiretamente, a partir do objeto persistente raiz.

Exemplos de SGBDOOs

Critério

Produto

Objectivity/DBObjectivity, Inc.www.poet.com

GemStone (*)GemStone Systemswww.gemstone.com

JasmineComputer Associates

www.cai.com

Definição de dados pelo usuário SIM SIM SIM

Herança Múltipla SIMSmalltalk - NÃO

Java - SIMSIM

Valida cardinalidade entre objetos SIM NÃO SIM (1)

Suporta transações longas SIM NÃO NÃOSuporta transações longas SIM NÃO NÃO

Linguagem de definição de atributos C++, Java, Smalltalk, SQL Java, Smalltalk

CC++ODQLJava

Armazena os métodos dos objetos no BDNÃO, os métodos são

armazenados no cliente.SIM SIM

Suporta ODL (Object DefinitionLanguage) SIM SIM NÃO

Suporta OQL (Object QueryLanguage) SIM NÃO SIM

Suporta SQL SIMSmalltalk - SIM

Java - NÃOSIM

via ODBC

Suporta consultas através de interface gráfica SIM SIM SIM

Exemplos de SGBDOOs

� Objectivity/DB� Integrado diretamente com a aplicação

� Não é necessário um processo separado;� APIs (Application Programming Interfaces):

� C++;� SmallTalk;� SmallTalk;� Java:

� Integração com IDE Eclipse;� Ferramentas de Administração e Projeto.

� Suporta SQL;� Suporta XML;

Exemplos de SGBDOOs

� GemStone� Armazena métodos dos objetos no banco� APIs:

� C++;� SmallTalk;� Java.� Java.

� Suporta SQL apenas através da interface SmallTalk;� Suporta XML, com ambiente de gerenciamento otimizado;� Compatível com .Net.

Exemplos de SGBDOOs� Jasmine

� Desenvolvido pela Computer Associates� APIs:

� C++;� SmallTalk;� Java;

� Oferece todas as funcionalidades de um BD relacional, além das � Oferece todas as funcionalidades de um BD relacional, além das capacidades da OO;

� Suporta OQL;� Suporta SQL;� Possui integração com ferramentas CASE.

Banco de Dados Relacional-Objeto: Introdução

� Modelos de dados relacionais-objeto estendem o modelo de dados relacional fornecendo um tipo de sistema mais rico, incluindo orientação a objetos e acrescentando estruturas especiais à linguagem de consultas relacionais, como a SQL, para tratar os tipos de dados acrescentados.

� É introduzido um sistema de tipos aninhados que permitem que os atributos de tuplas sejam de tipos complexos.tuplas sejam de tipos complexos.

� Essas extensões tentam preservar os fundamentos relacionais – em particular, o acesso declaratório ao dado – enquanto estendem o poder da modelagem.

� Os sistemas de banco de dados relacionais-objeto fornecem um caminho de migração conveniente para usuários de bancos de dados relacionais que desejam usar características orientadas a objetos.

Relações Aninhadas

� Primeira Forma Normal: exige que todos os atributos de uma relação tenham domínios atômicos. Um domínio é atômico se os elementos do domínio são considerados unidades indivisíveis.

� O modelo relacional aninhado é uma extensão do modelo relacional em que os domínios podem ser definidos como atômicos ou como relações. Então, o valor de domínios podem ser definidos como atômicos ou como relações. Então, o valor de uma tupla sob um atributo pode ser uma relação, e relações podem ser armazenadas dentro de relações.

� Assim, um objeto complexo pode ser representado por uma única tupla de uma relação aninhada.

Exemplo:

Considere um sistema de recuperação de documentos em que armazenamos, para cada documento, as seguintes informações:� Título do documento;� Lista de autores;� Data de aquisição;� Lista de palavras-chave.

� Uma relação para esta informação conterá domínios não-atômicos:

título lista_autores data lista_palavra_chave

(dia, mês, ano)

Plano de vendas {Smith, Jones} (1,abril, 89) {lucro, estratégia}

Relatório de status {Jones, Frick} (17, julho, 94) {lucro, pessoal}

Relação documento não-1NFdoc.

Exemplo:

título autor dia mês ano palavra_chave

Plano de vendas Smith 1 abril 89 lucro

Plano de vendas Jones 1 abril 89 lucro

Plano de vendas Smith 1 abril 89 estratégia

Plano de vendas Jones 1 abril 89 estratégia

Relatório de status Jones 17 junho 94 lucro

Relatório de status Frick 17 junho 94 lucro

Relatório de status Jones 17 junho 94 pessoal

Relatório de status Frick 17 junho 94 pessoal

Versão 1NF da relação documento não-1NF.

Tipos Complexos e Orientação a Objetos

� Sistemas com tipos complexos e orientação a objetos permitem que os conceitos de E-R, como atributos multivalorados, generalizações e especializações, sejam representados diretamente sem uma tradução complexa para o modelo relacional.complexa para o modelo relacional.

� XSQL – linguagem de consulta que estende a SQL com características de orientação a objetos.

Tipos Estruturados e Conjuntos

create type MinhaSeqüência char varying

create type MinhaData

(dia integer,

mês char(10),

ano integer)

create type Documentocreate type Documento

( nome MinhaSeqüência,

lista_autor setof (MinhaSeqüência),

data MinhaData,

lista_palavra_chave setof (MinhaSeqüência))

create table doc of type Documento.

Tipos Estruturados e Conjuntos

� Os tipos criados usando as declarações anteriores são gravados no esquema banco de dados. Logo, outras declarações que acessam o banco de dados podem fazer uso das definições desses tipos.

� Usualmente, sistemas de tipos complexos aceitam outros tipos de conjuntos, como matrizes e multiconjuntos.

� Matriz_autor MinhaSeqüência[10]: matriz de nomes de autor. Pode-se determinar quem é o primeiro autor, o segundo autor e assim por diante.

� Imprime-execuções multiset(integer): poderia representar o número de cópias de um documento impresso em cada execução de impressão do documento.

Exemplo:

Diagrama UML

Exemplo:

Esquema Relacional

Esquema Objeto-Relacional

Exemplo:

Objeto-Relacional

Definição dos Tipos

Herança

� A herança pode ser no nível de tipos ou no nível de tabelas.

� Herança de tipos:create type Pessoa

( nome MinhaSeqüência,seguro_social integer)

create type Estudante create type Estudante (graduação MinhaSeqüência,departamento MinhaSeqüência)

under Pessoacreate type Professor

(salário integer,departamento MinhaSeqüência)

under Pessoa

� Tanto estudante quanto professor herdam os atributos de Pessoa – isto é, nome e seguro_social. Estudante e Professor são chamados subtipos de Pessoa e Pessoa é um supertipo de Estudante, assim como de Professor.

Herança

� Suponha que queiramos armazenar informação sobre assistentes de ensino, que são, simultaneamente, estudantes e professores, talvez até mesmo em diferentes departamentos � herança múltipla

create type AssistenteEnsinounder Estudante, Professor

AssitenteEnsino deve herdar todos os atributos de Estudante e Professor.� AssitenteEnsino deve herdar todos os atributos de Estudante e Professor.

� Entretanto, existe um problema: os atributos seguro_social, nome e departamento estão presentes em Estudante, assim como em Professor.

� Seguro_social e nome são herdados de uma fonte comum, Pessoa. Então não há conflito causado por herdá-los a partir de Estudante, assim como de Professor.

� Departamento é definido separadamente em Estudante e Professor. De fato, um assistente de ensino pode ser um estudante de um departamento e um professor em outro departamento. Assim, deve-se usar o recurso de renomeação.

Herança

create type AssistentedeEnsino

under Estudante with (departamento as estudante_depto),

Professor with (departamento as professor_depto)

� Em muitas linguagens de programação, uma entidade deve ter exatamente um tipo mais específico, isto é, se uma entidade tem mais de um tipo, deve haver um tipo mais específico, isto é, se uma entidade tem mais de um tipo, deve haver um único tipo ao qual a entidade pertence e, esse único tipo deve ser um subtipo de todos os tipos aos quais a entidade pertence.

� Por exemplo, suponha que uma entidade seja do tipo Pessoa, assim como do tipo Estudante. Então, o tipo mais específico da entidade é Estudante, já que Estudante é um subtipo de Pessoa.

� Entretanto, uma entidade não pode ser do tipo Estudante e do tipo Professor, a menos que haja um tipo, como AssistentedeEnsino, que é um subtipo de Professor e de Estudante.

Herança

� A fim de que cada entidade tenha, exatamente, um tipo mais específico, teríamos de criar um subtipo para cada combinação possível dos supertipos. Dentro de um contexto universitário, por exemplo, poder-se-ia ter subtipos como:� EstudantenãoGraduadoEstrangeiro;� EstudanteGraduadoEstrangeiroJogadordeFutebol;� Etc...

� Uma melhor abordagem ao contexto de sistemas de banco de dados é permitir a um objeto ter múltiplos tipos, sem possuir um tipo mais específico.

� Sistemas relacionais-objeto podem modelar tal característica pelo uso de herança no nível de tabelas, e permitir que uma entidade exista em mais de uma tabela de uma vez.

Herança

� Herança de tabelas:

create table pessoas(nome MinhaSeqüência,seguro_social integer);

create table estudantes(graduação_MinhaSeqüência,departamento_Minhaseqüência)

under pessoas;

create table professores(salário integer,departamento MinhaSeqüência)

under pessoas;

Herança

� As sub-tabelas estudantes e professores herdam todos os atributos da tabela pessoas.

� Não há necessidade de criar tabelas adicionais, como assistentesdeensino, que herdam tanto de estudantes quanto de professores, a menos que hajam atributos específicos para entidades que são tanto estudantes como professores.

� Requisitos:� Requisitos:

� Cada tupla da supertabela pessoas pode corresponder a no máximo uma tupla em cada uma das tabelas estudantes e professores, isto é, ter os mesmos valores para todos os atributos herdados.

� Cada tupla em estudantes e professores deve ter, exatamente, uma tupla correspondente em pessoas, ou seja, com os mesmos valores para todos os atributos herdados.

Herança

� Sem a primeira condição, poderíamos ter duas tuplas em estudantes (ou professores) que corresponderiam à mesma pessoa.

� Sem a segunda condição, poderíamos ter uma tupla em estudantes ou em professores que não corresponderia a qualquer tupla em pessoa, ou que corresponderia a várias tuplas em pessoa.

� As sub-tabelas podem ser armazenadas de uma maneira eficiente sem replicação de todos os campos herdados. Atributos herdados, outros que não a chave primária da supertabela, não necessitam ser armazenados e podem ser derivados por meio de uma junção com a supertabela, baseada na chave primária.

Tipos Referência

� Um atributo de um tipo pode ser uma referência a um objeto de um tipo especificado.

� Exemplo: referências a pessoas são do tipo ref(Pessoa). O campo lista_autor do tipo Documento pode ser redefinido como:

lista_autor setof ( ref (Pessoa) )

que é um conjunto de referências a objetos Pessoa.

� As tuplas de uma tabela também podem ter referências a elas. A chave primária da tabela pode ser usada para criar essas referências.

� Alternativamente, cada tupla de uma tabela pode ter um identificador de tupla como um atributo implícito, e uma referência a uma tupla é simplesmente o identificador de tupla.

Consultas com Tipos Complexos

� A SQL foi estendida para manipular tipos complexos.

� Exemplo: encontre o nome e o ano de publicação de cada documento.

select nome, data.anofrom docfrom doc

� Observe que o campo ano do atributo composto data é referido pelo uso de uma notação de ponto.

SQL: Atributos Relação-Valorados

� A SQL estendida permite que uma expressão para uma relação apareça em qualquer lugar em que o nome da relação possa aparecer, como em uma

condição from.

� A habilidade de usar subexpressões livremente torna possível tirar vantagem da estrutura de relações aninhadas, de diferentes maneiras.

� Suponha a relação pdoc com o seguinte esquema:

create table pdoc

(nome MinhaSeqüência,

lista_autor setof (ref (pessoa)),

data MinhaData,

lista_palavra_chave setof (MinhaSeqüência))


� Encontre todos os documentos que têm a palavra “banco de dados” como uma de suas palavras-chaves:

select nome

from pdoc

where “banco de dados” in lista_palavra_chavewhere “banco de dados” in lista_palavra_chave

Observe que foi usado o atributo relação_valorado lista_palavra_chave em uma posição em que a SQL teria exigido uma subexpressão select-from-

where.


� Suponha que queiramos uma relação contendo pares da forma “nome_documento, nome_autor” para cada documento e cada autor do documento.

select B.nome, Y.nomefrom pdoc as B, B.lista_autor as Y

Já que o atributo lista_autor de pdoc é um campo conjunto_valorado, ele pode Já que o atributo lista_autor de pdoc é um campo conjunto_valorado, ele pode ser usado em uma condição from, onde deveria ser usado uma relação.

Da mesma forma, pode-se usar as funções agregadas nestes campos:

select nome, count (lista_autor)from pdoc

SQL: Expressões Path

� Suponha a tabela definida como a seguir:create table estudantes_phd

(orientador ref (pessoa) )under pessoa

Encontre agora os nomes dos orientadores dos estudantes de doutorado.

select estudantes_phd.orientador.nomefrom estudantes_phd

� Já que estudante_phd.orientador é uma referência à tupla na tabela pessoa, o atributo nome na consulta é o atributo nome da tupla da tabela pessoa;

� As referências podem ser usadas para esconder operações de junção;� Sem o uso de referências, o campo orientador de estudantes_phd seria uma

chave estrangeira.

Aninhar e Desaninhar

� A transformação de uma relação aninhada para uma relação na 1NF é chamada de desaninhar.

� A relação doc tem dois atributos (lista_autor e lista_palavra_chave) que são relações aninhadas.relações aninhadas.

� A conversão desta relação, com relações aninhadas, em uma relação básica pode ser feita da seguinte forma:

select nome, A as autor, data.dia, data.mês, data.ano, k as palavra_chave

from doc as B, B.lista_autor as A, B.lista_palavra_chave as K.

Aninhar e Desaninhar

� O processo inverso de transformação de uma relação 1 NF em uma relação aninhada é chamado aninhar.

select título, set (autor) as lista_autor, (dia,mês,ano) as data, set

(palavra_chave) as lista_palavra_chave

from doc_flatfrom doc_flat

groupby título, data

Funções

� Sistemas relacionais-objeto permitem que funções sejam definidas pelos usuários.

� Suponha que se desja uma função que, dado um documento, retorne a contagem do número de autores.

create function total_autor(um_doc Documento)returns integer as returns integer as

select count (lista_autor)from um_doc

Valores e Objetos complexos

� Criação de uma tupla do tipo definido pela relação doc:

(“plano de vendas”, set (“Smith”, “Jones”), (1, “abril”, 89), set (“lucro”, “estratégia”))

Inserindo essa tupla em uma relação:� Inserindo essa tupla em uma relação:

insert into doc

values (“plano de vendas”, set (“Smith”, “Jones”), (1, “abril”, 89), set (“lucro”, “estratégia”))

Benefícios do Modelo de Dados Objeto-Relacional

� Nova Funcionalidade

� Aumenta indefinidamente o conjunto de tipos e funções fornecidas pelo SGBD;

Desenvolvimento de aplicações simplificado� Desenvolvimento de aplicações simplificado

� Reuso de código;

� Consistência

� Permite a definição de padrões, código reusável por todas as aplicações.

Linguagem de Consultas paraBancos de Dados Objeto-Relacional

� O resultado de uma consulta ainda consiste de tabelas

� Um SGBD Objeto-Relacional ainda é relacional pois suporta dados armazenados em tabelas formadas por linhas e colunas

� A linguagem de consultas para BDOR é uma extensão da linguagem SQL, utilizada para definição e manipulação de dados e consultas

BDOO versus BDRO

� Extensões persistentes das linguagens de programação e sistemas relacionais-objetos estão direcionados a diferentes mercados.

� A natureza declaratória e o poder limitado da linguagem SQL (comparado com uma linguagem de programação) fornecem boa proteção de dados contra erros de programação e tornam otimizações de alto nível relativamente fáceis.contra erros de programação e tornam otimizações de alto nível relativamente fáceis.

� Linguagens de programação persistentes destinam-se a aplicações que tenham altas exigências de desempenho. Elas fornecem acesso com baixo overhead ao dado persistente e eliminam a necessidade de tradução do dado se os dados tiverem de ser manipulados usando uma linguagem de programação.

BDR versus BDOO versus BDRO

� Sistemas relacionais: tipos de dados simples, linguagens de consulta poderosas e alta proteção.

� Linguagem de programação simples baseada em BDOOs: tipos de dados complexos, integração com linguagem de programação, alto desempenho.desempenho.

� Sistemas relacionais-objeto: tipos de dados complexos, linguagens de consultas poderosa, alta proteção.

Algumas Considerações...

� SGBDOO - Principais Barreiras:� Culturais

� “Pra que mexer em time que está ganhando?”;� Falta de familiaridade com OO;� MID (medo, incerteza e dúvida);

� Grande parte dos SGBDOOs são desenvolvidos por empresas pequenas;pequenas;

� Risco de ficar “sem suporte”;� Financeiras

� Alto custo de migração;� Tempo para migração;� Treinamento de pessoal;� Necessidade de profissionais mais qualificados;

Algumas Considerações...

� SGBDOOs:� União de duas tecnologias

� Bancos de Dados;� Orientação a Objetos.

� Objetivos semelhantes ao SGBDR:Persistir dados;� Persistir dados;

� Recuperação;� Comparação;� Tratamento / Gerenciamento.

� Vantagem: Utilização da tecnologia OO.� Desvantagem: Ainda pouco popular.

Tendências

� SGBDO-R (Objeto-relacional)

� Ferramentas de Mapeamento Objeto-Relacional� Ex.: Hibernate (www.hibernate.org)

� Camada que provê interface para a aplicação� Camada que provê interface para a aplicação� Persistência de forma transparente� A aplicação trabalha como se estivesse conectada a um BDOO

Mapeamento Objeto-Relacional

� Modelo em 3 Camadas: Separação clara entre visualização, regra de negócio e dados.� Visualização: Camada responsável pelos elementos de

Interação com o usuário;Interação com o usuário;

� Negócio: Camada responsável pela implementação da regra de negócio;

� Dados: Camada responsável pelo armazenamento e integridade dos dados.

Mapeamento Objeto-Relacional

� Os dados são acessados na camada de negócios. O Mapeamento Objeto-Relacional é portanto, uma ferramenta de auxílio.

Hibernate

� Framework de mapeamento objeto relacional para aplicações Java;

� Open Source;

� Suporte:� Suporte:

� Coleções;

� Relacionamento entre objetos;

� Herança, polimorfismo e composições;

� Linguagem de consulta própria: (HQL –Hibernate Query Language).

Bibliografia Utilizada:� Sistemas de Banco de Dados. Abraham Silberchatz, Henry F. Korth e S.

Sudarshan. 4ª Edição. Editora Campus, 2006.� Introdução a Sistemas de Banco de Dados. C. J. Date. 7ª Edição, Editora

Campus, 2000.� Introdução a Banco de Dados (Apostila). Osvaldo Kotaro Takai, Isabel Cristina

Italiano, João Eduardo Ferreira. DCC-IME-USP, 2005.� Sistemas de Banco de Dados, Fundamentos e Aplicações. R Elsmari, S. B.

Navathe. Rio de Janeiro: Editora LTC, 2002. Sistemas de Banco de Dados, Fundamentos e Aplicações. R Elsmari, S. B. Navathe. Rio de Janeiro: Editora LTC, 2002.

� Sistemas de Banco de Dados. Ramez Elsmari e Shamkant B. Navathe. 4ª Edição. Editora Pearson Addison Wesley, 2005.

� Banco de Dados: Fundamentos, Projeto e Implementação. (Cap. 5). David M. Kroenke, 6ª Edição. Editora LTC, 1999.

� Uma Reflexão sobre Banco de Dados Orientados a Objetos. Boscarioli, et. al. CONGED, 2006.

� The Object-Oriented Database System Manifesto. Atkinson, et al. Agosto, 1989.� Fundamentals of Database Systems. Ramez Elsmari, Shamkant B. Navathe.

Addison Wesley Longman, 2000.

Documents

Persistência entre Modelos de Dadosclodis/PMD/PMD_Intro111008.pdfIntrodução ao Hibernate. Persistência É um tópico vital para o desenvolvimento de aplicações; Quase todas as