You are on page 1of 168

Persistncia entre

Modelos de Dados

Clodis Boscarioli
Agenda:

 Persistncia (Conceitos)
 Sistemas de Banco de Dados
 Modelo Relacional;
 Normalizao.
 Modelo Orientado a Objetos;
 Modelo Objeto-Relacional.

 Mapeamento Objeto-Relacional
 Introduo ao Hibernate.
Persistncia
 um tpico vital para o desenvolvimento de
aplicaes;
 Quase todas as aplicaes necessitam que dados
sejam persistidos;
 Necessidades:
 Armazenamento;
 Busca;
 Organizao;
 Compartilhamento dos dados.
Persistncia
 Necessidades:
 Integridadedos dados;
 Controle de concorrncia.
 Desempenho e a escalabilidade so fortemente
afetados pela estratgia de acesso a dados
escolhida.
Sistemas de Banco de Dados
 Quando falamos Sistemas de BD, entendemos a
juno de:
 SistemaGerenciador de Banco de Dados;
 Banco de Dados.
Sistema Gerenciador de Banco de Dados

Um Sistema Gerenciador de Banco usurios

de Dados (SGBD) uma coleo de


programas que habilitam usurios a
criar e manter um banco de dados.
PROGRAMAS
O grande objetivo de um sistema de
BD oferecer uma viso abstrata
dos dados, com disponibilidade
eficiente, aos usurios.
SGBD
Mundo real
Usurios Programadores Usurios Administra-
navegantes de aplicaes sofisticados dores de BD Usurios
Viso Geral
Interface com Programas de Consultas Esquema de
de um SGBD aplicaes aplicaes (queries) Banco de Dados

Programas de Pr-compilador Compilador Interpretador


Processador aplicaes em de comandos DML DDL
de consultas cdigo objeto DML
Componentes de execuo
SGBD de consultas

Gerenciador Gerenciador
Gerenciador de transaes de buffer
de memria
Gerenciador
de arquivos

Armazenamento
ndices Dados
em disco estatsticos
BD
Arquivos de Dicionrio
dados de dados
Banco de dados e Abstrao de Dados
 Um dos maiores benefcios dos sistemas de banco de dados proporcionar aos
usurios uma viso abstrata dos dados. O sistema capaz de ocultar alguns detalhes
sobre a forma de armazenamento e a manuteno dos dados.
 A eficincia da recuperao de informaes est relacionada forma como as
estruturas de representao so projetadas e, dado a complexidade e importncia
destas representaes, elas devem ser protegidas em nveis de abstraes.
 Estes nveis facilitam a manuteno do sistema e a interao dos usurios com os
sistemas. So eles:

Nvel de viso: O mais alto nvel de abstrao.


Proporciona uma viso parcial do banco de dados.
Nvel de viso
Diferentes vises so usadas por diferentes usurios.
Viso 1 Viso 2 ...... Viso n
Nvel lgico: Implica em definir quais dados sero
armazenados e quais so os inter-relacionamentos
existentes entre eles. Usado pelos administradores de
banco de dados e programadores.

Nvel fsico: Mais baixo nvel de abstrao. Implica em quais


como os dados esto, de fato, armazenados (descrio
Nvel lgico
em detalhes das estruturas de dados). Administradores
de banco de dados devem ter noes da organizao
deste nvel.
0 11 como
Nvel fsico
Modelos de Dados

 O Modelo de Dados a principal ferramenta que fornece a


abstrao 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
tipos de dados, relacionamentos e restries pertinentes aos
dados. Muitos modelos de dados tambm definem um
conjunto de operaes 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 juno ordenada/lgica destes tipos de objetos representa a


estrutura/esquema do mundo real, ou seja, deve suportar o
armazenamento de dados que reflitam a situao do mundo real.

 As trs noes bsicas empregadas pelo MER:


 Conjunto de entidades;
 Atributos;
 Conjunto de relacionamentos;
 Esse modelo possui recursos de Extenso (generalizao, especializao e
agregao).
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 unvoca em relao 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 emprstimo 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 no so, 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 so propriedades descritivas de cada membro de um conjunto
de entidades e cada entidade tem seus prprios valores nos atributos.
 Para cada atributo existe um conjunto de valores possveis, chamado
domnio.
 Formalmente, um atributo de um conjunto de entidades uma funo que
relaciona o conjunto de entidades a seu domnio.
 Cada entidade pode ser descrita pelo conjunto formado pelos pares
(atributo-valor) referentes a cada atributo do conjunto em questo.
 Classes de Atributos: Simples; Compostos; Monovalorados;
Multivalorados; Nulos; Derivados.
Conjuntos de Relacionamentos
 Um relacionamento uma associao entre uma ou vrias entidades. Exemplo:
 Um relacionamento que associa o cliente Hayes como emprstimo L-15
especifica que o cliente Hayes o cliente que realizou o referido emprstimo.
 Um conjunto de relacionamentos um conjunto de relacionamentos de mesmo tipo.
 Formalmente o relacionamento uma relao matemtica com n >= 2 (n =
nmero de conjuntos entidades).
 Se E1, E2, ..., En so conjuntos de entidades, ento um conjunto de
relacionamentos R um subconjunto de {(e1,e2,...,e3) | e1 E1, e2 E2, ..., en
En} em que (e1,e2,...,e3) so relacionamentos.
 A associao entre os conjuntos de entidades referida como uma
participao: o conjunto de entidades E1, E2, ..., Em participa do conjunto de
relacionamentos R.
 Uma instncia de relacionamento em um esquema E-R representa a existncia
de uma associao entre essas entidades no mundo real no qual se insere o
domnio que est sendo modelado.
 Grau do relacionamento: o relacionamento binrio (envolve dois conjuntos
entidades) um relacionamento de grau 2. E assim por diante.
Conjuntos de Relacionamentos
 Exemplo:
 Considere os conjuntos entidades cliente e emprstimo.
 Definimos o conjunto de relacionamentos devedor para denotar a
associao entre clientes e emprstimos bancrios contrados pelos
clientes.

Jones 321-12-3123 Main Harrison L-17 1000


Smith 019-28-3746 North Rye L-23 2000
Hayes 677-89-9011 Main Harrison L-15 1500
Jackson 555-55-5555 Dupont Woodside L-14 1500
Curry 244-66-8800 North Rye L-93 500
Williams 963-96-3963 Nassau Princeton L-11 900
Adams 335-57-7991 Spring Pittsfield L-16 1300
Conjuntos de Relacionamentos
 A funo 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 papis diferentes e, nessas situaes, o
papel importante para interpretao do modelo.
 Exemplo:
 Em relacionamentos recursivos, nomes explcitos de papis so necessrios para
especificar como uma entidade participa de uma instncia 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 relao de hierarquia de cargos. Neste exemplo, os relacionamentos de
trabalha-para so 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 bancria.
Mapeamento de Restries
 Mapeamento das cardinalidades expressa o nmero de entidade s quais
outra entidade pode estar associada via um conjunto de relacionamentos.

 Um para um: uma entidade em A est associada no mximo a uma entidade


em B, e uma entidade em B est associada a no mximo uma entidade em A.

 Um para muitos: Uma entidade em A est associada a vrias entidades em B.


Uma entidade em B deve estar associada no mximo a uma entidade em A.

 Muitos para um: Uma entidade em A est associada a no mximo uma


entidade em B. Uma entidade em B, pode estar associada a um nmero
qualquer de entidades em A.

 Muitos para muitos: Uma entidade em A est associada a qualquer nmero


de entidades em B e uma entidade em B est associada a um nmero
qualquer de entidades em A.
Interpretao:
1 1
Aluno Curso

1 N
Aluno Curso

N 1
Aluno Curso

N M
Aluno Curso

Conjunto relacionamento: Participa


Mapeamento de Restries
 Dependncia de Existncia
 Se a existncia da entidade X depende da existncia da entidade Y, ento X
dito dependente da existncia de Y.
 Operacionalmente, se Y deixar de existir, conseqentemente, X deve deixar
de existir.
 Exemplo:
 Considere o conjunto de entidades emprstimo e o conjunto de entidades
pagamento (que mantm todas as informaes sobre os pagamentos
realizados para um determinado emprstimo).
 O conjunto de entidades emprstimo 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, ento este dito parcial.
 A participao total est estreitamente relacionada existncia de
dependncia. Para haver dependncia de existncia, a participao 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 unvoca uma entidade
em um conjunto de entidades.
 Chaves candidatas: Superchaves para as quais nenhum subconjunto
possa ser uma superchave.
 Chave primria: chave candidata escolhida pelo projetista de banco de
dados como a chave de significado principal para a identificao de
entidades dentro de um conjunto de entidades.
 Uma chave uma propriedade do conjunto de entidades e no de uma
entidade individualmente. Quaisquer duas entidades individuais em um
conjunto no podem ter, simultaneamente, mesmos valores em seus
atributos-chave.
 A especificao de uma chave representa uma restrio ao mundo real do
domnio que est sendo modelada.
Chaves
 Conjuntos de relacionamentos:
 A composio da chave primria para um conjunto de
relacionamentos depende de uma estrutura de atributos associada
ao conjunto de relacionamentos de R.
 Se o conjunto de relacionamentos no possui atributos ento uma
superchave deve ser formada pelas chaves de cada entidade
participante do relacionamento.
 Se o conjunto de relacionamentos possui atributos ento uma
superchave deve ser formada pelas chaves de cada entidade
participante do relacionamento mais o conjunto de atributos deste.
 A estrutura da chave primria para o conjunto de relacionamentos
depende do mapeamento da cardinalidade do conjunto.
 Muitos para muitos: unio 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 primrias pode ser usada.
Projeto de um Esquema de BD
 Fases do projeto:
 Levantamento de requisitos: quais so as necessidades dos usurios
do BD e como este BD ser estruturado;
 Construo do projeto conceitual: transcrever as necessidades
especificadas para um esquema conceitual de BD (MER);
 Especificao das necessidades funcionais: descrever as transaes
que sero realizadas sobre os dados;
 Projeto lgico e fsico: mapeamento do projeto conceitual para o
modelo de implementao de dados no SGBD.
Modelo de Dados Relacional

 O Modelo Relacional (MR) considerado o primeiro


modelo de dados efetivamente usado em aplicaes
comerciais.
 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 Bsica

 Um banco de dados relacional consiste de uma coleo 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


relao matemtica 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


domnio.
MR - Formalmente...
 Suponha que D1 denote o domnio do atributo A1, D2 denote o domnio
do atributo A2 e ... Dn denote o domnio 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 esto, respectivamente em D1, D2 e Dn.
Em geral, uma instncia de T1 um subconjunto de
D1 X D2 X ... X Dn.

 Matematicamente, define-se uma relao como um subconjunto de um


produto cartesiano de uma lista de domnios.
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
nem todos os SGBDs relacionais fornecem suporte
a elas.
As 12 Regras de Codd

1. Regra das informaes em tabelas:


As informaes a serem armazenadas no banco de
dados devem ser apresentadas como relaes (tabelas
formadas por linhas e colunas) e o vnculo 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 so descries dos
objetos do banco de dados).
As 12 Regras de Codd

2. Regra de acesso garantido:


Para que o usurio possa acessar as informaes contidas
no banco de dados, o mtodo de referncia deve ser o nome
da tabela, o valor da chave primria e o nome do
campo/coluna.
As 12 Regras de Codd

3. Regra de tratamento sistemtico de valores nulos:


O SGBD deve ser capaz de tratar valores que no so
fornecidos pelos usurios, de maneira que permita a
distino de dados reais. Valores nulos devem ter um
tratamento diferente de valores em branco.
As 12 Regras de Codd

4. Regra do catlogo relacional ativo:


Toda a estrutura do banco de dados (domnios, campos,
tabelas, regras de integridade, ndices, etc) deve estar
disponvel em tabelas (tambm referenciadas como
catlogo).
Sua manipulao possvel por meio de linguagens
especficas. Essas tabelas so, geralmente, manipuladas
pelo prprio sistema no momento em que o usurio efetua
alteraes na estrutura do banco de dados.
As 12 Regras de Codd

5. Regras de atualizao de alto-nvel:


Essa regra diz que o usurio deve ter capacidade de
manipular as informaes do banco de dados em
grupos de tuplas (registros), ou seja, ser capaz de
inserir, alterar e excluir vrias tuplas ao mesmo
tempo.
As 12 Regras de Codd
6. Regra de sub-linguagem de dados abrangente:
Pelo menos uma linguagem deve ser suportada, para que o
usurio possa manipular a estrutura do banco de dados
(como criao e alterao de tabelas), bem como extrair,
inserir, atualizar ou excluir dados, definir restries de acesso
e controle de transaes (commit e rollback, por exemplo).
Deve ser possvel ainda a manipulao dos dados por meio
de programas aplicativos.
As 12 Regras de Codd
7. Regra de independncia fsica:
Quando for necessria alguma modificao na forma como
os dados esto armazenados fisicamente, nenhuma
alterao deve ser necessria nas aplicaes que fazem uso
do banco de dados. Tambm devem permanecer inalterados
os mecanismos de consulta e manipulao de dados
utilizados pelos usurios finais.
As 12 Regras de Codd

8. Regra de independncia lgica:


Qualquer alterao efetuada na estrutura do banco de dados
como incluso ou excluso de atributos de uma tabela ou
alterao no relacionamento entre tabelas no deve afetar o
aplicativo que o usa.
Da mesma forma, o aplicativo somente deve manipular
vises dessas tabelas.
As 12 Regras de Codd

9. Regra de atualizao de vises:


Uma vez que as vises dos dados de uma ou mais tabelas
so, teoricamente suscetveis atualizaes, um aplicativo que
faz uso desses dados deve ser capaz de efetuar alteraes,
excluses e incluses. Essas atualizaes, no entanto,
devem ser repassadas automaticamente s tabelas originais.
As 12 Regras de Codd
10. Regra de independncia de integridade:
As vrias formas de integridade de banco de dados
(integridade de entidade, integridade referencial, restries,
obrigatoriedade de valores, etc) precisam ser estabelecidas
dentro do catlogo do sistema ou dicionrio de dados, e ser
totalmente independentes da lgica dos aplicativos.
As 12 Regras de Codd

11. Regra de independncia de distribuio:


Alguns SGBDs, notadamente os que seguem o
padro SQL, podem ser distribudos em diversas
plataformas/equipamentos que se encontrem
interligados em rede. Essa capacidade de
distribuio no pode afetar a funcionalidade do
sistema e dos aplicativos que fazem uso do banco
de dados.
As 12 Regras de Codd

12. Regra no-subversiva:


O sistema deve ser capaz de impedir qualquer
usurio ou programador de transgredir os
mecanismos de segurana, regras de integridade do
banco de dados e restries, utilizando algum
recurso de linguagem de baixo nvel que
eventualmente possam ser oferecidos pelo prprio
sistema.
Estrutura Bsica
 Um banco de dados relacional consiste de uma coleo de relaes
(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


relao matemtica 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


domnio.
Relao
 Suponha que D1 denote o domnio do atributo A1, D2 denote o domnio
do atributo A2 e ... Dn denote o domnio 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 esto, respectivamente em D1, D2 e Dn.
Em geral, uma instncia de T1 um subconjunto de
D1 X D2 X ... X Dn.

 Matematicamente, define-se uma relao como um subconjunto de um


produto cartesiano de uma lista de domnios.

 O grau de uma relao o nmero de atributos que a compe.


Particularidades

 Atomicidade de atributo = primeira forma normal.


 Modelo relacional plano.

 O valor null.

 As relaes interpretam/representam fatos sobre


entidades e fatos sobre relacionamentos.

 Linguagem de consulta SQL.


Exerccio: Interprete o MER e crie um MR
correspondente.
Representao 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 primria do
conjunto de entidades ou do conjunto
relacionamento do qual M atributo.

 No exemplo da localizao de departamento: cada


elemento da nova tabela uma localizao de um
departamento.
Representao Tabular da Generalizao

 Para a situao:

num_conta saldo

conta

tx_juros ISA limite

conta_poup conta_mov
Representao Tabular da Generalizao

 Criar uma tabela para o conjunto de entidades de nvel superior.


 Para cada conjunto de entidades de nvel inferior, criar uma tabela que
inclua:
 Uma coluna para cada um dos atributos daquele conjunto de entidades
 Uma coluna para cada atributo da chave primria do conjunto entidades de
nvel superior.
 Assim:
 conta, com os atributos nmero_conta e saldo
 conta_poupana, com os atributos nmero_conta e taxa_juros
 conta_movimento, com os atributos nmero_conta e limite_cheque_especial
Representao Tabular da Generalizao
 Se a generalizao mutuamente exclusiva:
 nenhuma entidade membro de mais de um conjunto de entidades de
nvel imediatamente inferior ao conjunto de entidades de nvel superior;
 e todas as entidades do conjunto de entidades de nvel superior so
membro tambm de um dos conjuntos de entidades de nvel inferior.
 Para cada conjunto de entidades de nvel inferior, cria-se uma tabela que
inclua uma coluna para cada um dos atributos deste conjunto de entidades
mais uma coluna para cada atributo do conjunto de entidades de nvel
superior
 Assim:
 conta_poupana, com atributos nmero_conta, saldo e taxas_juros;
 conta_movimento, com os atributos nmero_conta, saldo e
limite_cheque_especial
Representao Tabular da Agregao

 Relembrando...
seguro rua
cidade nmero saldo
nome

cliente devedor emprstimo

Agente_
emp

empregado

seguro telefone
nome
Representao Tabular da Agregao

 A tabela para o conjunto de relacionamentos agente_emprstimo inclui uma


coluna para cada atributo, uma para chave primria do conjunto de entidades
empregado e uma para o conjunto de relacionamentos devedor.
 Poderia tambm incluir uma coluna para cada um dos atributos descritivos
descritivos do conjunto de relacionamentos agente_emprstimo, se eles existirem.

 Assim:
 cliente, com os atributos nome_cliente, seguro_cliente, rua, cidade;
 emprstimo, com os atributos nmero_emprstimo, total;
 devedor, com os atributos seguro_cliente, nmero_emprstimo;
 empregado, com os atributos seguro_empregado, nome_empregado, nmero_telefone;
 agente_emprstimo, com os atributos seguro_empregado, nmero emprstimo e
seguro_cliente.
Diretriz de Projeto n 1:
 Modelar um esquema de relao de modo que seja
fcil explicar seu significado. Se uma relao
corresponde a uma mistura de entidades e
relacionamentos, resultaro em ambigidades
semnticas e a relao no 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,
plocalizao.
Reduo de Valores Redundantes nas
Tuplas
 Deve-se minimizar o espao de armazenamento
utilizado pelas relaes bsicas:
 Agrupe atributos em esquemas de relaes;

 Deve-se evitar situaes que caiam em problemas de


Anomalias na Atualizao.
Diretriz Projeto n 2:
 Modelar esquemas de relaes bsicas de forma que
nenhuma anomalia de atualizao possa ocorrer nas
relaes. Se houver a possibilidade de ocorrer alguma
anomalia, registre-a claramente e tenha certeza de que os
programas que atualizam o banco de dados operaro
corretamente.

 Pode-se violar uma diretriz em prol do desempenho de uma


consulta, entretanto, as medidas cabveis devem ser tomadas
para que os dados estejam sempre consistentes e ntegros.
Reduo de Valores null nas Tuplas

 A existncia de muitas possibilidades de uso do valor null


causa desperdcio de espao no armazenamento e gera
problema de entendimento do significado do atributos e da
especificaes de joins, e funes agregadas.

 Motivos para uso do null:


 O atributo no se aplica tupla;
 O valor do atributo para a tupla desconhecido;
 O valor do atributo para a tupla conhecido, mas ausente, ou seja,
ainda no foi registrado.
Diretriz Projeto n 3:
 At onde for possvel, evite colocar os atributos em uma
relao bsica cujos valores freqentemente possam ser
nulos. Se os nulls forem inevitveis, tenha certeza de que
eles se aplicam somente em casos excepcionais e no na
maioria das tuplas da relao.

 Ex: se s 10% dos empregados tiverem escritrios


particulares, h pouca justificativa para incluir um atributo
ESCRITORIO-NRO na relao EMPREGADO; pode ser
criada uma relao EMP_ESCRITRIOS (ESSN,
ESCRITORIO_NRO) que contenha apenas as tuplas dos
empregados que possurem escritrios particulares.
Impedimento para a Gerao de Valores
Ilegtimos nas Tuplas
 Considere os esquemas:
 Esquema 1:
 Emp_locs (enome, plocalizao)

 Emp_proj1 (ssn, pnumero, horas, pnome, plocalizao)

 Esquema 2:
 Emp_proj: (ssn, pnumero, horas, enome, pnome, plocalizao)

 A partir do esquema 1 possvel conseguir as mesmas informaes


que temos no esquema 2?
 No, usando um JOIN conseguiremos tuplas ilegtimas.
Diretriz Projeto n 4:

 Projete os esquemas de relaes de forma que


possam ser unidos (join) com igualdade de
condies sobre os atributos que sejam chaves
primrias ou chaves estrangeiras, de modo a
garantir que nenhuma tupla ilegtima seja gerada.
Normalizao
 A normalizao de dados pode ser vista como o processo de anlise de
determinados esquemas de relaes com base em suas dependncias
funcionais e chaves primrias para alcanar as propriedades desejveis:
 Minimizao de redundncias;
 Minimizao de modificaes.

 O esquemas de relaes insatisfatrias, que no alcanam certas


condies os testes de forma normal -, so decompostas em esquemas
de relaes menores que passam nos testes e, conseqentemente,
possuem as propriedades desejadas.
Conceitos
 A forma normal de uma relao refere-se condio da mais alta forma
normal alcanada e, conseqentemente, indica o grau no qual foi
normalizada.

 A normalizao sempre deve estar acompanhada da garantia de duas


propriedades:

 Juno sem perdas: Garante que o problema de gerao de tuplas ilegtimas


no ocorra (propriedade crtica que deve sempre ser garantida);

 Preservao de dependncias: Garante que cada dependncia funcional ser


representada em alguma relao individual resultante da decomposio.
Primeira Forma Normal (1NF)
 Impedimento para a criao de atributos multivalorados, atributos
compostos e combinaes entre eles.

 Estabelece-se que o domnio de um atributo s deva incluir os valores


atmicos e que o valor de qualquer atributo em uma tupla deve ter um
nico valor no domnio daquele atributo.

 A 1NF impede as relaes dentro de relaes ou relaes como valores


de atributos dentro de tuplas.
Primeira Forma Normal

 Considerando o departamento que possui um atributo multivalorado:


localizaes. H trs tcnicas bsicas para alcanar a primeira forma
normal:

1. Remover o atributo DLocalizaes que viola a 1NF e coloc-lo em uma


relao separada, junto com a chave primria que identifica a entidade
departamento.
2. Ampliar as chaves de forma a separar as tuplas da relao original
DEPARTAMENTO, criando uma para cada localizao de departamento.
3. Se um nmero mximo de valores puder ser estabelecido para o atributos,
por exemplo, se sabido que h no mximo trs locais para cada
departamento, substituir o atributo Dlocalizaes por trs atributos
atmicos.
Segunda Forma Normal (2NF)

 Baseada no conceito de dependncia funcional total.

 Uma dependncia funcional X  Y ser uma dependncia


funcional total se a remoo de qualquer atributo A de X
implicar que a dependncia no mais ser assegurada, isto
, para qualquer atributo A X, (X {A}) no determina
funcionalmente Y.

 Uma dependncia funcional X  Y uma dependncia


parcial se um atributo A X puder ser removido de X e a
dependncia mesmo assim continuar existindo, ou seja, para
algum A X, (X {A})  Y.
Segunda Forma Normal
 Exemplo de dependncias funcionais totais e parciais:

 Considere o esquema:
SSN, PNumero, Horas, Enome, Pnome, Plocalizao

 {SSN, PNumero}  Horas: uma dependncia funcional total (no so


asseguradas nem SSN  Horas nem PNumero Horas).
 {SSN, PNumero}  Enome: uma dependncia funcional parcial porque SSN
 Enome assegurada.
Segunda Forma Normal

 Um esquema de relao R est na 2NF se todo atributo no primrio A


em R tem dependncia funcional total da chave primria de R.

 O teste para a 2NF envolve verificar se os atributos do lado esquerdo das


dependncia funcionais fazem parte da chave primria. Se a chave
primria contiver um nico atributo, a necessidade do teste no se aplica.

 A relao do slide anterior est na 1NF mas no est na 2NF. O atributo


no primrio enome viola a 2NF em razo da dependncia funcional SSN
 Enome. Enome parcialmente dependente da chave primria (j que
depende de SSN).
Segunda Forma Normal

 Um esquema pode ser normalizado na 2NF por meio da criao de vrias


relaes na 2NF nas quais os atributos no primrios s estaro
associados a dependncias funcionais total.

 Considere o esquema abaixo e suas dependncias funcionais:

SSN, PNumero, Horas, Enome, Pnome, Plocalizao

SSN, PNumero  Horas


SSN  Enome
PNumero  Pnome, Plocalizao
Segunda Forma Normal

 Normalizando, cria-se trs esquemas:

Esquema1: SSN, Pnumero, Horas


com a dependncia funcional: SSN, PNumero  Horas

Esquema 2: SSN, Enome


com a dependnia funcional: SSN  Enome

Esquema 3: PNumero, Pnome, Plocalizao


com a dependncia funcional: PNumero  Pnome,
Plocalizao
Terceira Forma Normal (3NF)

 De acordo com a definio original de Codd, um


esquema de relao R est na 3NF se satisfizer a
2NF e se nenhum atributo no primrio de R for
transitivamente dependente da chave primria.

 Est baseada no conceito de dependncia transitiva.

 Uma dependncia funcional X  Y, em um esquema de


relao R, ser uma dependncia transitiva se existir um
conjunto de atributos Z que no 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
dependncias funcionais:

Enome, SSN, DataNasc, Endereo, Dnumero, Dnome, DgerSSN

SSN  Enome, DataNasc, Endereco, DNumero


DNumero  Dnome, DgerSSN

A dependncia funcional SSN  DgerSSN transitiva para


Dnumero, pois ambas as dependncias SSN  Dnumero e Dnumero 
DgerSSN so asseguradas e Dnumero no nem chave primria nem um
subconjunto da chave da relao.
Terceira Forma Normal

A normalizao na 3NF para o exemplo se d por meio da


decomposio:

Esquema 1: Enome, SSN, DataNasc, Endereo, Dnumero


com a dependncia funcional: SSN  Enome, DataNasc,
Endereco, DNumero

Esquema 2: Dnumero, Dnome, DgerSSN


com a dependncia funcional: DNumero  Dnome,
DgerSSN
Generalizao
 As definies tratadas at aqui dizem respeito a parcialidade e
transitividade de dependencias funcionais com respeito chave primria
da relao.

 Estas definies devem ser expandidas para a considerao de todas as


chaves candidatas.

 2NF: um esquema de relao R est na segunda forma normal se cada


atributo no primrio A de R no forem parcialmente dependente de
nenhuma chave de R.

 3NF: um esquema de relao R est na terceira forma normal se sempre


que uma depependncia funcional no trivial X  A for determinada em
R, ento: (A) qualquer X uma superchave de R; ou (B) A um atributo
primrio de R.
Mais um exemplo:
 Esquema Lotes:

Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preo, Imposto

 Dependncias funcionais:

DF 1: Num_ID_Propriedade  Municipio_nome, Num_lote, Area, Preo, Imposto


DF 2: Municipio_nome, Num_lote  Num_ID_Propriedade, Area, Preo, Imposto
DF 3: Municipio_nome  Imposto
DF 4: Area  Preo
Colocando na 2NF:
 O esquema de relao Lotes viola a definio GERAL da 2NF porque
Imposto parcialmente dependente da chave candidata
{Municipio_nome, Num_lote} em razo da terceira dependncia funcional.

 Construmos ento 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.

 Lotes1 : Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preo


Com as DFs 1, 2 e 4

 Lotes2: Municipio_nome, Imposto


Com a DF 3.

Note que a DF 4 no viola a 2NF.


Colocando na 3NF:
 Lotes2 est na 3NF.

 Lotes1 no est pois a dependncia funcional 4 viola a definio GERAL.


 rea no uma superchave;
 Preo no um atributo primrio em Lotes1.

 Construmos:
 Lotes1a: Num_ID_Propriedade, Municipio_nome, Num_lote, Area
Com as DFs 1 e 2.

 Lotes1b: Area, Preo


Com a DF 4.
Forma Normal de Boyce-Codd (BCNF)

 Foi proposta como uma forma normal mais simples de 3NF,


mas considerada mas rgida que a 3NF.

 Toda relao BCNF est tambm em 3NF, mas o contrrio


pode no ser verdadeiro.

 Definio: Um esquema de relao R est na BCNF sempre


que uma dependncia funcional no trivial X  A for mantida
em R, ento X ser uma superchave de R.
BCNF

 Suponha a seguinte situao para o ltimo exemplo modelado:

Existem milhares de lotes cadastrados mas eles esto


localizados em apenas duas cidades. E as reas dos lotes nas
duas cidades so definidas de formas diferentes. Assim, a
dependncia funcional Area  Municipio_nome deveria valer.

 Ainda assim, Lotes1a estaria na 3NF, pois Municipio_nome


um atributo primrio.
BCNF

 Mas existe redundncia de informao, pois a rea que determina o


municpio, como dito pela nova dependncia funcional, pode ser
representada uma nica vez, em uma relao a parte.

 A BCNF sugere a decomposio do esquema Lotes1a em:

Lotes1ax : Num_ID_propriedade, Area, Num_lote


com as DFs 1 e 2.

Lotes1ay : Area, Municipio_nome


com a DF 5.

 Cuidado com a decomposio com perdas na juno!


BCNF - Exemplos
 Relembrando: Uma relao R est na BCNF sse R est na
3NF e nenhum atributo possua dependncia transitiva em
relao chave primria.
Exemplo:
Relao 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

Zlia Banco de Dados I Date

Camila Banco de Dados I Navathe


BCNF - Exemplo
Primeiro, tm-se que identificar as DF envolvendo atributos que pertenam a chave
primria.

Tutor  Disciplina
Aluno, Disciplina  Tutor H dependncia transitiva da chave primria!

Relao CURSA
ALUNO DISCIPLINA TUTOR

 A relao acima est na 3NF e na BCNF?


BCNF - Exemplo
A relao est na 3NF pois possui somente atributos
atmicos, no apresenta dependncia parcial da chave
primria e no existem DFs de um atributo no pertencente
a chave primria em relao a atributos no pertencentes
chave primria. Porm, no est na BCNF pois possui
dependncia transitiva de um atributo chave com relao
chave primria.
A soluo seria separar a relao em duas ou mais
relaes, de forma a eliminar a dependncia transitiva:
Tutoria (Tutor, Disciplina)
Cursa(Tutor, Aluno)
BCNF Outro Exemplo

 Considere a relao orientador abaixo. Suponha que


as exigncias bsicas dessa relao sejam: Um
aluno (IDAL) pode ter mais que uma especializao,
uma especializao pode ter vrios membros do
corpo docente (Fnome) como orientadores e um
professor orienta somente em uma rea de
especializao.
BCNF Outro Exemplo
Relao Orientador
IDAL Especializao Fnome
100 Matemtica Caughy
150 Psicologia Jung
200 Matemtica Riemann
250 Matemtica Caughy
300 Psicologia Perls
300 Matemtica Riemann

 DF:
Fnome  Especializao
BCNF Outro Exemplo

 H nessa relao uma anomalia de eliminao (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 tambm uma
anomalia de insero (No se pode armazenar um
orientador em uma rea, a no ser que um aluno se
especialize na cadeira).
BCNF Outro Exemplo
Relao Al_Orient Relao Orient_Discip

IDAL Fnome Fnome Especializao

100 Caughy Caughy Matemtica

150 Jung Jung Psicologia

200 Riemann Riemann Matemtica

250 Caughy Perls Psicologia

300 Perls

300 Riemann

Agora sim, est na BCNF.


Dependncia Multivalorada
Dada uma relao qualquer com trs 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)
existiro tambm duas tuplas (x1,y1,z2) e (x1,y2,z1).

 Refere-se combinao de valores de atributos


multivalorados disjuntos (y e z).
 x na verdade, relaciona-se com y e com z de forma
independente.
4 Forma Normal (4NF)

Uma tabela est na 4FN sse estiver na 3FN e no existirem


dependncias multivaloradas.

 Exemplo: Dados sobre livros


Relao no normalizada: Livros(nrol, (autor), ttulo, (assunto),
editora, cid_edit, ano_public)
1FN: Livros(nrol, autor, assunto, ttulo, editora, cid_edit,
ano_public)
2FN: Livros(nrol,ttulo, editora, cid-edit, ano_public)
AutAssLiv(nrol, autor, assunto)
3FN: Livros(nrol, ttulo, editora, ano_public)
Editoras(editora, cid-edit)
AutAssLiv(nrol, autor, assunto)
4 Forma Normal (4NF)
Nrol Autor Assunto
1 aut1 ass1
1 aut1 ass2
1 aut2 ass1
1 aut2 ass2
2 aut1 ass3
2 aut1 ass4
2 aut1 ass1
2 aut3 ass3
2 aut3 ass4
2 aut3 ass1

 Redundncia para representar todas as informaes;


 Evitar todas as combinaes: representao no-uniforme (repete
alguns elementos ou posies nulas).
Passagem 4FN

 Gerao de novas tabelas, eliminando Dependncias


Multivaloradas
 Anlise de Dependncias Multivaloradas entre atributos:
autor, assunto   Dependncia multivalorada de nrol

Resultado:
4FN: Livros(nrol, ttulo, editora, ano_public)
Editoras(editora, cid-edit)
AutLiv(nrol, autor)
AssLiv(nrol, assunto)
4 Forma Normal Outro Exemplo

Relao Aluno

IDAL Especializao Atividade

100 Msica Natao


DF mltiplas:
100 Contabilidade Natao IDAL   Especializao
IDAL   Atividade
100 Msica Tnis

100 Contabilidade Tnis

150 Matemtica Jogging


4 Forma Normal Outro Exemplo
Relao Aluno Relao Aluno

IDAL Especializa Atividade


IDAL Especializa Atividade
o
o
100 Msica Natao 100 Msica Natao

100 Contabilidade Natao


100 Contabilidade Natao
100 Msica Tnis
100 Msica Tnis
100 Contabilidade Tnis
100 Contabilidade Tnis
150 Matemtica Jogging

150 Matemtica Jogging 100 Msica Esqui

100 Msica Esqui 100 Contabilidade Esqui

Ao inserir nova atividade ao aluno 100 com a especializao msica, deve-se


inserir tambm outra tupla, o que mostra uma anomalia de atualizao.
4 Forma Normal Outro Exemplo
Relao Al_Espec Relao Al_Ativ

IDAL Especializao IDAL Atividade

100 Msica 100 Esqui

100 Natao
100 Contabilidade
100 Tnis
150 Matemtica
150 Jogging

Agora sim, est na BCNF, sem dependncias


multivaloradas!
5 Forma Normal (5NF)
Uma tabela est na 5FN sse estiver na 4FN e um relacionamento triplo no
puder ser decomposto em relacionamentos binrios sem gerao de
informao incorreta.

Caso especial: Relacionamento envolvendo Chaves primrias de 3 tabelas, que


nem sempre possvel decomposio correta.

Exemplo: relacionamento Agente-Companhia-Produto

Agente Companhia Produto


Joo Ford Carro
Joo GM Caminho
5 Forma Normal

 Formato necessrio quando existem apenas algumas


combinaes entre os 3 atributos (tabela c/ tripla).

 Situao: Se um agente vende um certo produto e ele


representa uma companhia, ento ele vende um produto
fabricado por esta companhia  Todos os pares se
combinam!
5 Forma Normal
Agente Companhia Produto

Joo Ford Carro

Joo Ford Caminho

Joo GM Carro

Joo GM Caminho

Carlos Ford Carro

Neste caso, possvel decompor uma tripla em trs


relaes binrias com eliminao de certas redundncias.
5 Forma Normal
As trs relaes abaixo esto na 5FN:

Agente Companhia Agente Produto Companhia Produto

Joo Ford Joo Carro Ford Carro

Joo GM Ford Caminho


Joo Caminho
Carlos Ford GM Carro
Carlos Carro
GM Caminho

 Eliminao de certas redundncias:


- Apenas uma vez est dito que Ford produz carros;
- Apenas uma vez est dito que Joo agente da GM.
 Apesar do aumento no nmero de tabelas, o nmero total de
tuplas na forma normalizada menor.
Banco de Dados Orientado a Objetos
- Motivaes
 Novas aplicaes ficaram limitadas por restries impostas pelo modelo
relacional.

 As aplicaes convencionais possuem caractersticas comuns que as tornam


passveis de serem tratadas por bancos de dados relacionais:
 Uniformidade: as informaes a serem armazenadas podem ser
estruturadas de maneira similar.
 Orientao a registros: registros de tamanho fixo so adequados para a
representao desta informao.
 Itens de dados pequenos: as informaes so estruturadas em registros
pequenos.
 Campos atmicos: os campos dentro de um registro so pequenos e de
comprimento fixo. No 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 programao orientada a objeto.
Introduo e Motivaes
 As aplicaes mais novas, em geral, no possuem, no mnimo, uma das
caractersticas j citadas.

 Exemplos dessas aplicaes:


 Computer-aided design (CAD) projeto auxiliado por computador:
 necessrio armazenar os dados pertencentes a um projeto de
engenharia, incluindo os componentes do item que est sendo projetado,
o inter-relacionamento dos componentes, as verses antigas do projeto.
 Computer-aided software engineering (CASE) engenharia de
software auxiliada por computador:
 necessrio armazenar os dados necessrios para apoiar os
desenvolvedores de software, incluindo o cdigo-fonte, as dependncias
entre os mdulos de software, as definies e o uso de variveis e o
histrico de desenvolvimento do sistema de software.
Introduo e Motivaes
 Bancos de dados multimdia:
 Contm imagens, dados espaciais, dados de udio, dados de vdeo e
afins (envolvem principalmente o armazenamento de fotografias e dados
geogrficos, voz e vdeo).

 Office information system (OIS) sistemas de informao de


escritrio:
 Necessidade de suportar dados para ferramentas para criao e
recuperao de documentos e ferramentas para manuteno de
calendrios, permitindo solicitaes pertencentes a agendas, documentos
e contedos de documentos.

 Bancos de dados de hipertexto:


 Necessidade de suportar o armazenamento/gerenciamento das estruturas
especficas e indexao de textos enriquecidos com links que apontam
para outros documentos, permitindo a recuperao de documentos
baseados em sua estrutura.
Modelagem de BDOOs

 Isso:
Modelagem de BDOOs

 Ao invs 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 cdigo
relacionado a um objeto dentro de uma nica unidade.
 As interaes 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
um conjunto de mensagens permitidas.

 Em geral, um objeto tem associado a ele:

 Um conjunto de variveis que contm os dados para o objeto; as variveis


correspondem aos atributos no modelo E-R;
 Um conjunto de mensagens ao qual o objeto responde; cada mensagem
pode ter zero, um ou mais parmetros;
 Um conjunto de mtodos, cada qual sendo um corpo de cdigo para
implementar a mensagem; um mtodo retorna um valor como resposta
mensagem.
O Modelo de Dados Orientado a Objeto
 O termo mensagem em um contexto orientado a objeto se refere passagem de pedidos entre os
objetos sem considerar detalhes especficos de implementao.

 O termo chamar um mtodo algumas vezes usado para representar o ato de enviar uma
mensagem a um objeto e a execuo do mtodo correspondente.

 Exemplo:
 Considerando a entidade empregado em um banco de dados. Suponha que o salrio anual
de um empregado seja calculado de maneiras diferentes para diferentes empregados. Por
exemplo, os gerentes podem ter um bnus dependendo do desempenho do banco, enquanto
os caixas podem obter um bnus dependendo de quantas horas eles trabalharam. possvel
encapsular o cdigo para calcular o salrio para cada empregado como um mtodo que
executado em resposta a uma mensagem salrio_anual.
 Todos os objetos empregado respondem mensagem salrio_anual, mas fazem isso de
diferentes maneiras. Pelo encapsulamento da informao sobre como calcular o salrio anual
dentro do objeto empregado, todos os objetos empregados apresentam a mesma interface.
 possvel modificar a definio de um objeto sem afetar o resto do sistema. Esta uma das
habilidades considerada como uma das maiores vantagens do paradigma de programao
orientado a objetos.
O Modelo de Dados Orientado a Objeto
 Os mtodos de um objeto podem ser:
 Somente leitura: no afeta os valores das variveis em um objeto;
 De atualizao: pode mudar os valores das variveis.

 As mensagens s quais um objeto responde podem ser, de maneira similar, classificadas


como somente leitura ou de atualizao, em funo do mtodo que implementa a
mensagem.

 Cada atributo de uma entidade deve ser expresso como uma varivel e um par de
mensagens do objeto no modelo orientado a objeto. A varivel usada para armazenar o
valor do atributo, uma mensagem usada para ler o valor do atributo e o outro mtodo
usado para atualizar o valor. Por exemplo:
 O atributo endereo da entidade empregado pode ser representado por:
 Uma varivel endereo;
 Uma mensagem obter_endereo cuja resposta o endereo;
 Uma mensagem ajustar_endereo, que possui um parmetro novo_endereo, para atualizar o
endereo.

 Por simplicidade muitos modelos orientados a objeto permitem que as variveis sejam
lidas ou atualizadas diretamente, sem ter de definir mensagens para isso.
Classes de Objetos
 Objetos similares so aqueles que respondem s mesmas mensagens, usam os mesmos
mtodos e tm variveis de mesmo nome e tipo.
 Objetos similares so agrupados formando uma classes.
 Cada um desses objetos chamada de uma instncia de sua classe.
 A noo de uma classe no modelo de dados orientado a objeto corresponde noo de um
conjunto entidade do modelo E-R.

 Exemplo de definio de uma classe:

Class empregado {
/* variveis */
string nome;
string endereo;
date data_incio;
int salrio;
/* mensagen */
int salrio_anual();
string obter_nome();
string obter_endereo();
int ajustar_endereo (string novo_endereo);
int tempo_emprego();
}
Classes de Objetos

 Cada classe um objeto em si e inclui uma varivel contendo o conjunto


de todas as instncias da classe.

 Uma classe objeto inclui:


 Uma varivel conjunto valorada cujo valor o conjunto de todos os
objetos que so instncias da classe;
 A implementao de um mtodo para a mensagem new, que cria uma
nova instncia da classe.
Herana
 Considerando um banco de dados orientado a objetos para a aplicao bancria
(exemplo Korth), a classe clientes similar classe empregados, pois ambas
definem variveis para nome, endereo e assim por diante. No entanto, h
variveis especficas para empregados (salrio) e variveis especficas para
clientes (classificao_crdito).

 Neste caso desejvel definir uma representao para as variveis comuns em


um nico local. Para isso, combina-se empregados e clientes dentro de uma
classe.

 Para permitir a representao direta de similaridades entre classes, necessita-se


colocar as classes em uma hierarquia de especializao.
 Empregado e cliente so especializaes de pessoa.

 Este conceito similar ao conceito de especializao no modelo E-R.

 Empregados e clientes podem ser representados por classes que so


especializaes de uma classe pessoa. Variveis e mtodos especficos a
empregados so associados classe empregados. Variveis e mtodos
especficos a clientes so associados classe cliente. Variveis e mtodos que se
aplicam tanto a empregados como a clientes so associados classe pessoa.
class pessoa {
string nome;
string endereo;
};
class cliente isa pessoa {
int classificao_crdito
};
class empregado isa pessoa {
date data_incio;
int salrio;
};
class escriturrio isa empregado {
int nmero_escriturrio;
int nmero_conta_despesa;
};
class caixa isa empregado {
int horas_por_semana;
int nmero_estao;
};
class secretria isa empregado {
int horas_por_semana;
string gerente;
};
Herana
 Um benefcio importante da herana em sistemas orientados a objeto a noo
de reusabilidade.

 Qualquer mtodo de uma classe pode ser invocado por qualquer objeto
pertencente a qualquer subclasse desta classe.

 Para tratar a hierarquia de classes tem-se duas opes:


 Associar classe empregado todos os objetos empregado, incluindo aqueles
que so instncias de escriturrio, caixa e secretria.
 Associar classe empregado somente aqueles objetos empregado que no
so instncias nem de escriturrio, nem de caixa, nem de secretria.
 possvel determinar o conjunto de todos os objetos empregado, nesse caso,
tomando-se a unio daqueles objetos associados a todas as subclasses de
empregado.
Herana Mltipla

 Suponha que precisemos distinguir entre escriturrios, caixas e secretrias de


tempo integral e tempo parcial. Alm disso, assuma que so necessrias
diferentes variveis e mtodos para representar empregados de tempo parcial e
tempo integral. Ento cada um desses empregados so classificados de duas
maneiras diferentes.

pessoa

empregado cliente

escriturrio caixa secretria

escrit_TI escrit_TP caixa_TI caixa_TP secretria_TI secretria_TP


Herana Mltipla
 Existem certas variveis e mtodos especficos para empregado em tempo
integral e outros especficos para empregado em tempo parcial. Assim, na
hierarquia em anlise, as variveis e mtodos para empregados de tempo integral
devem ser definidos trs vezes: uma vez para escriturrio_TI, uma vez para
secretria_TI e uma vez para caixa_TI. Redundncias deste tipo so indesejveis
mediante alteraes nas propriedades dos empregados de tempo integral (e
parcial), que devero ser feitas em dois lugares diferentes.

 Existe falha na explorao da reutilizao de cdigo.

 Nesta hierarquia tambm no se consegue representar os empregados que no


so escriturrios, caixas ou secretrias, mas que possuem caractersticas de
serem ou de tempo parcial ou integral.

 Se existissem vrias classificaes de emprego, em vez de duas limitaes neste


exemplo, as limitaes do modelo se tornariam muito mais aparentes.
Herana Mltipla
 Herana mltipla a habilidade de uma classe herdar variveis e mtodos a partir
de mltiplas superclasses.

pessoa

empregado cliente

tempo_integral tempo_parcial escriturrio caixa secretria

escrit_TI escrit_TP caixa_TI caixa_TP secretria_TI secretria_TP

 Pode haver algum problema?


Herana Mltipla
 Assuma que, em vez de definir salrio para a classe empregado, defina-se uma varivel
chamada pagamento para cada classe: tempo_integral, tempo_parcial, escriturrio, caixa e
secretria, como a seguir:
 Tempo_integral: pagamento um inteiro de 0 a 100.000 contendo um salrio anual;
 Tempo_parcial: pagamento um inteiro de 0 a 20, contendo uma taxa horria de
pagamento.
 Caixa e escriturrio: pagamento um inteiro de 0 a 20.000, contendo um salrio anual;
 Secretria: pagamento um inteiro de 0 a 25.000, contendo um salrio anual.
 Considere a classe secretria_TP. Ela pode herdar a definio de pagamento tanto de
tempo_parcial como de secretria. O resultado diferente, dependendo da escolha feita.
 Opes:
 Incluir ambas as variveis, renomenado-as como tempo_parcial.pagamento e
secretria.pagamento;
 Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e
secretria foram criadas;
 Forar o usurio a fazer a escolha;
 Tratar a situao 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 mantm sua
identidade mesmo se algumas de suas propriedades mudam com o tempo.

 Um objeto mantm sua identidade mesmo se alguns ou todos os seus valores


de variveis ou definies de mtodos mudarem com o tempo.

 Diferente do modelo relacional onde as tuplas de uma relao so


diferenciadas somente pelos valores que elas contm.
Identidade de Objeto

 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 usurio usado
para identidade dos arquivos;
 Embutido: usado em sistemas orientados a objetos  a cada objeto atribudo
automaticamente um identificador pelo sistema quando aquele objeto criado.

 Identificadores de objetos so nicos. Exemplo de uso do identificador:


 Um dos atributos de um objeto pessoa pode ser o atributo cnjuge, que realmente
um identificador do objeto pessoa correspondendo ao cnjuge da primeira pessoa.
Assim, o objeto pessoa pode armazenar uma referncia ao objeto que representa o
cnjuge de pessoa.
Objetos Compostos
 As referncias 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

 O conceito de composio permite que os dados sejam vistos em diferentes


granularidades por diferentes usurios.
Modelagem de BDOOs

 Representao no BDOO:
 Um BDOO armazena objetos integralmente;
 possvel recuperar um objeto a qualquer momento, inclusive todas as
referncias.

 Linguagem de definio:
 ODL (Object Definition Language);
 Utilizada para criar definies de objetos.

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

Classes
Modelagem de BDOOs
Automvel{OID12}

736194174 Objetos
Ka
Preto
20000 Fabricante{OID1}
OID1 Ford
[OID5123] Joo da Silva
[OID1125, OID1127, OID1128]

Pea{OID5123}
Motor{OID154}
Correia Dentada
Ford Rocam 1000 16V
OID154 OID1
[OID1125, OID1127, OID1128] 120CV

Fbrica {OID1125} Fbrica {OID1127} Fbrica {OID1128}

Central Filial So Bernardo I Filial So Bernardo II


Camaari So Bernardo So Bernardo
320 250 130
Modelagem de BDOOs
Automvel{OID12}

736194174
Ka
Preto Objeto Complexo
20000

Fabricante{OID1}

Ford
Joo da Silva
Fbrica {OID1127} Fbrica {OID1128}
Fbrica {OID1125}
Filial So Bernardo I Filial So Bernardo
Central II
So Bernardo
Camaari So Bernardo
250
320 130

Motor{OID154}
Rocam 1000 16V
120 CV
Modelagem Padro ODMG ODL
Especificao 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 Endereo
{short num, string logradouro, sort numapto, string cidade, string estado, short
cpe}
endereo;
short idade();
};
Especificao ODL

class Professor extends Pessoa


( extent professores )
{
attribute string classificao;
attribute float salrio;
attribute string escritrio;
attribute string telefone;
relationship Departamento trabalha_em inverse Departamento::possui_professor;
relationship set<aluno_grad> d_assistncia inverse AlunoGrad::assistente;
relationship set<aluno_grad> no_comit_de inverse AlunoGrad::comit;
void dar_aumento(in float aumento);
void promove(in string nova_classificao);
};
Especificao ODL

class Grau
( extent graus)
{
attribute enum GrauValores{A,B,C,D,F,I,P} grau;
relationship Disciplina disciplina inverse Disciplina::alunos;
relationship Aluno aluno inverse Alunos::disciplinas_completadas;
};
Especificao ODL

class Aluno extends Pessoa


( extent alunos)
{
attribute string classe;
attribute Departamento cursa_eletiva_em;
relationship Departamento especializa_em inverse
Departamento::possui_especializaes;
relationship set <grau> disciplinas_completadas inverse Grau::alunos;
relationship set <DisciplinaCorrente> registrado_em inverse
DisciplinaCorrente::alunos_registrados;
void alterar_especializao (in string nomed) raises disciplina_invlida);
float mg();
void registrado(in short nomseo; in ValorGrau grau)
raise (disciplina_invlida,grau_invalido);
};
Especificao OQL

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


s.nome.primeiro_nome)
from s in departamentocc.possui_especializaes
where s.classe = Superior
order by sobrenome asc;

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


s.nome.primeiro_nome)
from s in alunos
where s.especializa_em.nomed = Cincia da Computao
order by sobrenome asc;
Linguagens Orientadas a Objeto
 Para que estes conceitos bsicos de orientao a objetos sejam usados
na prtica em um sistemas de banco de dados, eles devem ser expressos
em alguma linguagem. Esta representao pode ser feita de duas formas:
 Os conceitos so usados puramente como uma ferramenta de projeto
e so codificados, por exemplo, em um banco de dados relacional;
 Os conceitos de orientao a objetos so incorporados em uma
linguagem que usada para manipular o banco de dados.
 Extenso de uma linguagem de manipulao de dados, como a SQL,
pela adio de tipos complexos e orientao a objetos.
 Tomar uma linguagem de programao orientada a objeto e estend-la
para tratar banco de dados (so as linguagens de programao
persistentes).
Linguagens de Programao Persistentes
 Linguagens de bancos de dados diferem das linguagens de programao
tradicionais pelo fato de que elas manipulam diretamente os dados que
so persistentes, ou seja, dados que continuam a existir mesmo depois
que o programa que os criou tenha terminado.

 Uma linguagem de programao persistente uma linguagem de


programao estendida com estruturas para tratar dados persistentes.

 Verses persistentes de linguagens de programao como C++ ou


Smalltalk esto entre as mais importantes. Elas permitem que o
programador manipule os dados do banco de dados sem passar por uma
linguagem de manipulao de dados como a SQL.

 Essas linguagens so poderosas e relativamente fcil cometer erros de


programao que danifiquem o banco de dados.
Persistncia de Objetos
 Persistncia por classe: Declarar que uma classe persistente. Assim, todos os
objetos da classe so, por default, persistentes. Os objetos de classes no
persistentes so transientes.

 Persistncia por criao: Um objeto persistente ou transiente, dependendo de


como ele foi criado.

 Persistncia por marcao: Todos os objetos so criados como transientes mas,


se um objeto deve persistir alem da execuo do programa, ele deve ser marcado
explicitamente como persistente antes do programa terminar.

 Persistncia por referncia: Um ou mais objetos so explicitamente declarados


como objetos persistentes (raiz). Todos os outros objetos so persistentes se (e
somente se) forem referidos diretamente, ou indiretamente, a partir do objeto
persistente raiz.
Exemplos de SGBDOOs
Produto

Critrio Objectivity/DB GemStone (*) Jasmine


Objectivity, Inc. GemStone Systems Computer Associates
www.poet.com www.gemstone.com www.cai.com
Definio de dados pelo usurio SIM SIM SIM
Smalltalk - NO
Herana Mltipla SIM SIM
Java - SIM
Valida cardinalidade entre objetos SIM NO SIM (1)
Suporta transaes longas SIM NO NO
C
C++
Linguagem de definio de atributos C++, Java, Smalltalk, SQL Java, Smalltalk
ODQL
Java
NO, os mtodos so
Armazena os mtodos dos objetos no BD SIM SIM
armazenados no cliente.
Suporta ODL (Object Definition
SIM SIM NO
Language)
Suporta OQL (Object Query
SIM NO SIM
Language)
Smalltalk - SIM SIM
Suporta SQL SIM
Java - NO via ODBC
Suporta consultas atravs de interface grfica SIM SIM SIM
Exemplos de SGBDOOs

 Objectivity/DB
 Integrado diretamente com a aplicao
 No necessrio um processo separado;
 APIs (Application Programming Interfaces):
 C++;
 SmallTalk;
 Java:
 Integrao com IDE Eclipse;
 Ferramentas de Administrao e Projeto.

 Suporta SQL;
 Suporta XML;
Exemplos de SGBDOOs
 GemStone
 Armazena mtodos dos objetos no banco
 APIs:
 C++;
 SmallTalk;
 Java.
 Suporta SQL apenas atravs da interface SmallTalk;
 Suporta XML, com ambiente de gerenciamento otimizado;
 Compatvel com .Net.
Exemplos de SGBDOOs
 Jasmine
 Desenvolvido pela Computer Associates
 APIs:
 C++;
 SmallTalk;
 Java;
 Oferece todas as funcionalidades de um BD relacional, alm das
capacidades da OO;
 Suporta OQL;
 Suporta SQL;
 Possui integrao com ferramentas CASE.
Banco de Dados Relacional-Objeto:
Introduo
 Modelos de dados relacionais-objeto estendem o modelo de dados relacional
fornecendo um tipo de sistema mais rico, incluindo orientao 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.

 Essas extenses tentam preservar os fundamentos relacionais em particular, o


acesso declaratrio ao dado enquanto estendem o poder da modelagem.

 Os sistemas de banco de dados relacionais-objeto fornecem um caminho de


migrao conveniente para usurios de bancos de dados relacionais que desejam
usar caractersticas orientadas a objetos.
Relaes Aninhadas

 Primeira Forma Normal: exige que todos os atributos de uma relao tenham
domnios atmicos. Um domnio atmico se os elementos do domnio so
considerados unidades indivisveis.

 O modelo relacional aninhado uma extenso do modelo relacional em que os


domnios podem ser definidos como atmicos ou como relaes. Ento, o valor de
uma tupla sob um atributo pode ser uma relao, e relaes podem ser
armazenadas dentro de relaes.

 Assim, um objeto complexo pode ser representado por uma nica tupla de uma
relao aninhada.
Exemplo:
Considere um sistema de recuperao de documentos em que armazenamos, para
cada documento, as seguintes informaes:
 Ttulo do documento;
 Lista de autores;
 Data de aquisio;
 Lista de palavras-chave.

 Uma relao para esta informao conter domnios no-atmicos:

ttulo lista_autores data lista_palavra_chave


(dia, ms, ano)
Plano de vendas {Smith, Jones} (1,abril, 89) {lucro, estratgia}
Relatrio de status {Jones, Frick} (17, julho, 94) {lucro, pessoal}

Relao documento no-1NFdoc.


Exemplo:
ttulo autor dia ms 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 estratgia

Plano de vendas Jones 1 abril 89 estratgia

Relatrio de status Jones 17 junho 94 lucro

Relatrio de status Frick 17 junho 94 lucro

Relatrio de status Jones 17 junho 94 pessoal

Relatrio de status Frick 17 junho 94 pessoal

Verso 1NF da relao documento no-1NF.


Tipos Complexos e Orientao a Objetos

 Sistemas com tipos complexos e orientao a objetos permitem que os


conceitos de E-R, como atributos multivalorados, generalizaes e
especializaes, sejam representados diretamente sem uma traduo
complexa para o modelo relacional.

 XSQL linguagem de consulta que estende a SQL com caractersticas de


orientao a objetos.
Tipos Estruturados e Conjuntos
create type MinhaSeqncia char varying
create type MinhaData
(dia integer,
ms char(10),
ano integer)
create type Documento
( nome MinhaSeqncia,
lista_autor setof (MinhaSeqncia),
data MinhaData,
lista_palavra_chave setof (MinhaSeqncia))
create table doc of type Documento.
Tipos Estruturados e Conjuntos
 Os tipos criados usando as declaraes anteriores so gravados no esquema
banco de dados. Logo, outras declaraes que acessam o banco de dados podem
fazer uso das definies desses tipos.

 Usualmente, sistemas de tipos complexos aceitam outros tipos de conjuntos,


como matrizes e multiconjuntos.
 Matriz_autor MinhaSeqncia[10]: matriz de nomes de autor. Pode-se
determinar quem o primeiro autor, o segundo autor e assim por diante.
 Imprime-execues multiset(integer): poderia representar o nmero de cpias
de um documento impresso em cada execuo de impresso do documento.
Exemplo:

Diagrama UML
Exemplo:

Esquema Relacional
Exemplo:

Esquema
Objeto-Relacional
Definio dos Tipos
Herana
 A herana pode ser no nvel de tipos ou no nvel de tabelas.

 Herana de tipos:
create type Pessoa
( nome MinhaSeqncia,
seguro_social integer)
create type Estudante
(graduao MinhaSeqncia,
departamento MinhaSeqncia)
under Pessoa
create type Professor
(salrio integer,
departamento MinhaSeqncia)
under Pessoa

 Tanto estudante quanto professor herdam os atributos de Pessoa isto ,


nome e seguro_social. Estudante e Professor so chamados subtipos de
Pessoa e Pessoa um supertipo de Estudante, assim como de Professor.
Herana
 Suponha que queiramos armazenar informao sobre assistentes de ensino,
que so, simultaneamente, estudantes e professores, talvez at mesmo em
diferentes departamentos  herana mltipla

create type AssistenteEnsino


under Estudante, Professor

 AssitenteEnsino deve herdar todos os atributos de Estudante e Professor.

 Entretanto, existe um problema: os atributos seguro_social, nome e


departamento esto presentes em Estudante, assim como em Professor.

 Seguro_social e nome so herdados de uma fonte comum, Pessoa. Ento no 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 renomeao.
Herana
create type AssistentedeEnsino
under Estudante with (departamento as estudante_depto),
Professor with (departamento as professor_depto)

 Em muitas linguagens de programao, uma entidade deve ter exatamente um


tipo mais especfico, 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. Ento, o tipo mais especfico da entidade Estudante, j que Estudante
um subtipo de Pessoa.
 Entretanto, uma entidade no 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.
Herana
 A fim de que cada entidade tenha, exatamente, um tipo mais especfico, teramos
de criar um subtipo para cada combinao possvel dos supertipos. Dentro de um
contexto universitrio, por exemplo, poder-se-ia ter subtipos como:
 EstudantenoGraduadoEstrangeiro;
 EstudanteGraduadoEstrangeiroJogadordeFutebol;
 Etc...

 Uma melhor abordagem ao contexto de sistemas de banco de dados permitir a


um objeto ter mltiplos tipos, sem possuir um tipo mais especfico.

 Sistemas relacionais-objeto podem modelar tal caracterstica pelo uso de herana


no nvel de tabelas, e permitir que uma entidade exista em mais de uma tabela de
uma vez.
Herana
 Herana de tabelas:

create table pessoas


(nome MinhaSeqncia,
seguro_social integer);

create table estudantes


(graduao_MinhaSeqncia,
departamento_Minhaseqncia)
under pessoas;

create table professores


(salrio integer,
departamento MinhaSeqncia)
under pessoas;
Herana
 As sub-tabelas estudantes e professores herdam todos os atributos da tabela
pessoas.

 No h necessidade de criar tabelas adicionais, como assistentesdeensino, que


herdam tanto de estudantes quanto de professores, a menos que hajam atributos
especficos para entidades que so tanto estudantes como professores.

 Requisitos:

 Cada tupla da supertabela pessoas pode corresponder a no mximo 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.
Herana
 Sem a primeira condio, poderamos ter duas tuplas em estudantes (ou
professores) que corresponderiam mesma pessoa.

 Sem a segunda condio, poderamos ter uma tupla em estudantes ou em


professores que no corresponderia a qualquer tupla em pessoa, ou que
corresponderia a vrias tuplas em pessoa.

 As sub-tabelas podem ser armazenadas de uma maneira eficiente sem replicao


de todos os campos herdados. Atributos herdados, outros que no a chave
primria da supertabela, no necessitam ser armazenados e podem ser derivados
por meio de uma juno com a supertabela, baseada na chave primria.
Tipos Referncia
 Um atributo de um tipo pode ser uma referncia a um objeto de um tipo
especificado.

 Exemplo: referncias a pessoas so do tipo ref(Pessoa). O campo lista_autor do


tipo Documento pode ser redefinido como:

lista_autor setof ( ref (Pessoa) )

que um conjunto de referncias a objetos Pessoa.

 As tuplas de uma tabela tambm podem ter referncias a elas. A chave primria
da tabela pode ser usada para criar essas referncias.

 Alternativamente, cada tupla de uma tabela pode ter um identificador de tupla


como um atributo implcito, e uma referncia 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 publicao de cada documento.

select nome, data.ano


from doc

 Observe que o campo ano do atributo composto data referido pelo uso de uma
notao de ponto.
SQL: Atributos Relao-Valorados
 A SQL estendida permite que uma expresso para uma relao aparea em
qualquer lugar em que o nome da relao possa aparecer, como em uma
condio from.

 A habilidade de usar subexpresses livremente torna possvel tirar vantagem da


estrutura de relaes aninhadas, de diferentes maneiras.

 Suponha a relao pdoc com o seguinte esquema:


create table pdoc
(nome MinhaSeqncia,
lista_autor setof (ref (pessoa)),
data MinhaData,
lista_palavra_chave setof (MinhaSeqncia))
SQL: Atributos Relao-Valorados

 Encontre todos os documentos que tm a palavra banco de dados como


uma de suas palavras-chaves:

select nome
from pdoc
where banco de dados in lista_palavra_chave

Observe que foi usado o atributo relao_valorado lista_palavra_chave em


uma posio em que a SQL teria exigido uma subexpresso select-from-
where.
SQL: Atributos Relao-Valorados
 Suponha que queiramos uma relao contendo pares da forma
nome_documento, nome_autor para cada documento e cada autor do
documento.

select B.nome, Y.nome


from pdoc as B, B.lista_autor as Y

J que o atributo lista_autor de pdoc um campo conjunto_valorado, ele pode


ser usado em uma condio from, onde deveria ser usado uma relao.

Da mesma forma, pode-se usar as funes agregadas nestes campos:

select nome, count (lista_autor)


from pdoc
SQL: Expresses 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.nome
from estudantes_phd

 J que estudante_phd.orientador uma referncia tupla na tabela pessoa, o


atributo nome na consulta o atributo nome da tupla da tabela pessoa;
 As referncias podem ser usadas para esconder operaes de juno;
 Sem o uso de referncias, o campo orientador de estudantes_phd seria uma
chave estrangeira.
Aninhar e Desaninhar

 A transformao de uma relao aninhada para uma relao na 1NF


chamada de desaninhar.

 A relao doc tem dois atributos (lista_autor e lista_palavra_chave) que so


relaes aninhadas.

 A converso desta relao, com relaes aninhadas, em uma relao bsica


pode ser feita da seguinte forma:

select nome, A as autor, data.dia, data.ms, 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 transformao de uma relao 1 NF em uma
relao aninhada chamado aninhar.

select ttulo, set (autor) as lista_autor, (dia,ms,ano) as data, set


(palavra_chave) as lista_palavra_chave
from doc_flat
groupby ttulo, data
Funes
 Sistemas relacionais-objeto permitem que funes sejam definidas pelos
usurios.

 Suponha que se desja uma funo que, dado um documento, retorne a


contagem do nmero de autores.

create function total_autor(um_doc Documento)


returns integer as
select count (lista_autor)
from um_doc
Valores e Objetos complexos

 Criao de uma tupla do tipo definido pela relao doc:

(plano de vendas, set (Smith, Jones), (1, abril, 89), set (lucro,
estratgia))

 Inserindo essa tupla em uma relao:

insert into doc


values (plano de vendas, set (Smith, Jones), (1, abril, 89), set (lucro,
estratgia))
Benefcios do Modelo de Dados
Objeto-Relacional
 Nova Funcionalidade
 Aumenta indefinidamente o conjunto de tipos e funes fornecidas
pelo SGBD;
 Desenvolvimento de aplicaes simplificado
 Reuso de cdigo;
 Consistncia
 Permite a definio de padres, cdigo reusvel por todas as
aplicaes.
Linguagem de Consultas para
Bancos 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 extenso da linguagem
SQL, utilizada para definio e manipulao de dados e consultas
BDOO versus BDRO

 Extenses persistentes das linguagens de programao e sistemas


relacionais-objetos esto direcionados a diferentes mercados.

 A natureza declaratria e o poder limitado da linguagem SQL (comparado


com uma linguagem de programao) fornecem boa proteo de dados
contra erros de programao e tornam otimizaes de alto nvel
relativamente fceis.

 Linguagens de programao persistentes destinam-se a aplicaes que


tenham altas exigncias de desempenho. Elas fornecem acesso com baixo
overhead ao dado persistente e eliminam a necessidade de traduo do
dado se os dados tiverem de ser manipulados usando uma linguagem de
programao.
BDR versus BDOO versus BDRO

 Sistemas relacionais: tipos de dados simples, linguagens de consulta


poderosas e alta proteo.

 Linguagem de programao simples baseada em BDOOs: tipos de


dados complexos, integrao com linguagem de programao, alto
desempenho.

 Sistemas relacionais-objeto: tipos de dados complexos, linguagens de


consultas poderosa, alta proteo.
Algumas Consideraes...
 SGBDOO - Principais Barreiras:
 Culturais
 Pra que mexer em time que est ganhando?;
 Falta de familiaridade com OO;
 MID (medo, incerteza e dvida);
 Grande parte dos SGBDOOs so desenvolvidos por empresas
pequenas;
 Risco de ficar sem suporte;

 Financeiras
 Alto custo de migrao;
 Tempo para migrao;
 Treinamento de pessoal;
 Necessidade de profissionais mais qualificados;
Algumas Consideraes...

 SGBDOOs:
 Unio de duas tecnologias
 Bancos de Dados;
 Orientao a Objetos.
 Objetivos semelhantes ao SGBDR:
Persistir dados;

 Recuperao;
 Comparao;
 Tratamento / Gerenciamento.

 Vantagem: Utilizao da tecnologia OO.


 Desvantagem: Ainda pouco popular.
Tendncias

 SGBDO-R (Objeto-relacional)

 Ferramentas de Mapeamento Objeto-Relacional


 Ex.: Hibernate (www.hibernate.org)
 Camada que prov interface para a aplicao
 Persistncia de forma transparente
 A aplicao trabalha como se estivesse conectada a um BDOO
Mapeamento Objeto-Relacional

 Modelo em 3 Camadas: Separao clara entre


visualizao, regra de negcio e dados.
 Visualizao: Camada responsvel pelos elementos de
Interao com o usurio;
 Negcio: Camada responsvel pela implementao da
regra de negcio;
 Dados: Camada responsvel pelo armazenamento e
integridade dos dados.
Mapeamento Objeto-Relacional

 Os dados so acessados na camada de negcios.


O Mapeamento Objeto-Relacional portanto, uma
ferramenta de auxlio.
Hibernate
 Framework de mapeamento objeto
relacional para aplicaes Java;
 Open Source;
 Suporte:
 Colees;
 Relacionamento entre objetos;
 Herana, polimorfismo e composies;
 Linguagem de consulta prpria: (HQL
Hibernate Query Language).
Bibliografia Utilizada:
 Sistemas de Banco de Dados. Abraham Silberchatz, Henry F. Korth e S.
Sudarshan. 4 Edio. Editora Campus, 2006.
 Introduo a Sistemas de Banco de Dados. C. J. Date. 7 Edio, Editora
Campus, 2000.
 Introduo a Banco de Dados (Apostila). Osvaldo Kotaro Takai, Isabel Cristina
Italiano, Joo Eduardo Ferreira. DCC-IME-USP, 2005.
 Sistemas de Banco de Dados, Fundamentos e Aplicaes. R Elsmari, S. B.
Navathe. Rio de Janeiro: Editora LTC, 2002.
 Sistemas de Banco de Dados. Ramez Elsmari e Shamkant B. Navathe. 4
Edio. Editora Pearson Addison Wesley, 2005.
 Banco de Dados: Fundamentos, Projeto e Implementao. (Cap. 5). David M. Kroenke,
6 Edio. Editora LTC, 1999.
 Uma Reflexo 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.