Persistência Entre Modelos de Dados

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.
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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).
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
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)
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

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
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.
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!
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 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.
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,
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,
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))
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.
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
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.
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.

Persistência Entre Modelos de Dados

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Persistência Entre Modelos de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Persistncia entre

Um Sistema Gerenciador de Banco usurios

de Dados (SGBD) uma coleo de

Programas de Pr-compilador Compilador Interpretador

Nvel de viso: O mais alto nvel de abstrao.

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

O Modelo de Dados a principal ferramenta que fornece a

Fonte: Ferreira et. al, 2005

A juno ordenada/lgica destes tipos de objetos representa a

As trs noes bsicas empregadas pelo MER:

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

Algumas vezes o conjunto entidade pode participar de um conjunto

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

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

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

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

Conjunto relacionamento: Participa

O Modelo Relacional (MR) considerado o primeiro

Um banco de dados relacional consiste de uma coleo de tabelas de

Cada tabela possui um conjunto de linhas que representa um

O conceito de tabelas est intimamente ligado ao conceito de uma

Uma tabela formada por um conjunto de colunas denominadas de

Para cada atributo existe um conjunto de valores permitidos, chamado de

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

Edgard F. Codd, em 1985, estabeleceu as 12

1. Regra das informaes em tabelas:

2. Regra de acesso garantido:

3. Regra de tratamento sistemtico de valores nulos:

4. Regra do catlogo relacional ativo:

5. Regras de atualizao de alto-nvel:

8. Regra de independncia lgica:

9. Regra de atualizao de vises:

11. Regra de independncia de distribuio:

12. Regra no-subversiva:

Cada tabela possui um conjunto de linhas que representa um

O conceito de tabelas est intimamente ligado ao conceito de uma

Uma tabela formada por um conjunto de colunas denominadas de

Para cada atributo existe um conjunto de valores permitidos, chamado de

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

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

Atomicidade de atributo = primeira forma normal.

As relaes interpretam/representam fatos sobre

Linguagem de consulta SQL.

No exemplo da localizao de departamento: cada

tx_juros ISA limite

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

cliente devedor emprstimo

A tabela para o conjunto de relacionamentos agente_emprstimo inclui uma

Esquemas pobres porque violam a Diretriz 1:

Deve-se evitar situaes que caiam em problemas de

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

A existncia de muitas possibilidades de uso do valor null

Motivos para uso do null:

Ex: se s 10% dos empregados tiverem escritrios

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

A partir do esquema 1 possvel conseguir as mesmas informaes

Projete os esquemas de relaes de forma que

O esquemas de relaes insatisfatrias, que no alcanam certas

A normalizao sempre deve estar acompanhada da garantia de duas

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

Preservao de dependncias: Garante que cada dependncia funcional ser

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

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