Persistência entre Modelos de Dados

Persistência entre
Modelos de Dados
Clodis Boscarioli
Agenda:
Persistência (Conceitos)
Sistemas de Banco de Dados
Modelo
Relacional;
Normalização.
Modelo
Orientado a Objetos;
Modelo Objeto-Relacional.
Mapeamento Objeto-Relacional
Introdução
ao Hibernate.
Persistência
É um tópico vital para o desenvolvimento de
aplicações;
Quase todas as aplicações necessitam que dados
sejam persistidos;
Necessidades:
Armazenamento;
Busca;
Organização;
Compartilhamento
dos dados.
Persistência
Necessidades:
Integridade
dos dados;
Controle de concorrência.
Desempenho e a escalabilidade são fortemente
afetados pela estratégia de acesso a dados
escolhida.
Sistemas de Banco de Dados
Quando falamos Sistemas de BD, entendemos a
junção de:
Sistema
Gerenciador de Banco de Dados;
Banco de Dados.
Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco
de Dados (SGBD) é uma coleção de
programas que habilitam usuários a
criar e manter um banco de dados.
O grande objetivo de um sistema de
BD é oferecer uma visão “abstrata”
dos dados, com disponibilidade
eficiente, aos usuários.
usuários
PROGRAMAS
SGBD
Mundo real
Visão Geral
de um SGBD
Processador
de consultas
Usuários
navegantes
Programadores
de aplicações
Interface com Programas de
aplicações
aplicações
Programas de
aplicações em
código objeto
Usuários
sofisticados
Consultas
(queries)
Pré-compilador
de comandos
DML
Administradores de BD
Usuários
Esquema de
Banco de Dados
Compilador
DML
Interpretador
DDL
Componentes de execução
de consultas
SGBD
Gerenciador
de memória
Gerenciador
de transações
Gerenciador
de buffer
Gerenciador
de arquivos
Armazenamento
em disco
Índices
Arquivos de
dados
Dados
estatísticos
Dicionário
de dados
BD
Banco de dados e Abstração de Dados
Um dos maiores benefícios dos sistemas de banco de dados é proporcionar aos
usuários uma visão abstrata dos dados. O sistema é capaz de ocultar alguns detalhes
sobre a forma de armazenamento e a manutenção dos dados.
A eficiência da recuperação de informações está relacionada à forma como as
estruturas de representação são projetadas e, dado a complexidade e importância
destas representações, elas devem ser protegidas em níveis de abstrações.
Estes níveis facilitam a manutenção do sistema e a interação dos usuários com os
sistemas. São eles:
Nível de visão: O mais alto nível de abstração.
Proporciona uma visão parcial do banco de dados.
Diferentes visões são usadas por diferentes usuários.
Nível de visão
Visão 1
......
Visão 2
Nível lógico: Implica em definir quais dados serão
armazenados e quais são os inter-relacionamentos
existentes entre eles. Usado pelos administradores de
banco de dados e programadores.
Nível físico: Mais baixo nível de abstração. Implica em
como os dados estão, de fato, armazenados (descrição
em detalhes das estruturas de dados). Administradores
de banco de dados devem ter noções da organização
deste nível.
Nível lógico
Nível físico
quais
0 11
como
Visão n
Modelos de Dados
O Modelo de Dados é a principal ferramenta que fornece a
abstração a um BD. É um conjunto de conceitos que podem
ser usados para descrever a estrutura de uma base de
dados. Por estrutura de uma base de dados entende-se os
tipos de dados, relacionamentos e restrições pertinentes aos
dados. Muitos modelos de dados também definem um
conjunto de operações para especificar como recuperar e
modificar a base de dados.
Esquema Geral de Modelagem de BD
Fonte: Ferreira et. al, 2005
Modelagem Conceitual
A base do modelo entidade-relacionamento, o modelo E-R (MER), é
representar o mundo real por meio de conjuntos de objetos chamados
entidades e relacionamentos.
A junção ordenada/lógica destes tipos de objetos representa a
estrutura/esquema do mundo real, ou seja, deve suportar o
armazenamento de dados que reflitam a situação do mundo real.
As três noções básicas empregadas pelo MER:
Conjunto de entidades;
Atributos;
Conjunto de relacionamentos;
Esse modelo possui recursos de Extensão (generalização, especialização e
agregação).
O Conjunto de Entidades
Segundo (Korth et. al, 2006):
uma entidade é uma “coisa” ou um “objeto” do mundo real que pode
ser identificada(o) de uma forma unívoca em relação a todos os outros
objetos.
cada entidade tem um conjunto de propriedades que assumem
valores e, em alguns casos, assumem valores que devem ser únicos.
uma entidade pode ser concreta, como uma pessoa ou um livro, ou
pode ser abstrata, como um empréstimo ou uma viagem.
um conjunto de entidades é o conjunto que abrange entidades de
mesmo tipo e que compartilham as mesmas propriedades: os
atributos.
os conjuntos de entidades não são, necessariamente, conjuntos
separados, ou, sempre disjuntos.
Por exemplo: o conjunto de todos os clientes de um banco
constituem o conjunto entidade cliente; o conjunto de todos os
empregados do banco constituem o conjunto entidade empregado;
a entidade pessoa pode pertencer ou ao conjunto cliente, ou ao
conjunto entidade ou a ambos ou a nenhum deles.
Atributos
Uma entidade é representada por um conjunto de atributos.
Atributos são propriedades descritivas de cada membro de um conjunto
de entidades e cada entidade tem seus próprios valores nos atributos.
Para cada atributo existe um conjunto de valores possíveis, chamado
domínio.
Formalmente, um atributo de um conjunto de entidades é uma função que
relaciona o conjunto de entidades a seu domínio.
Cada entidade pode ser descrita pelo conjunto formado pelos pares
(atributo-valor) referentes a cada atributo do conjunto em questão.
Classes de Atributos: Simples; Compostos; Monovalorados;
Multivalorados; Nulos; Derivados.
Conjuntos de Relacionamentos
Um relacionamento é uma associação entre uma ou várias entidades. Exemplo:
Um relacionamento que associa o cliente Hayes como empréstimo L-15
especifica que o cliente Hayes é o cliente que realizou o referido empréstimo.
Um conjunto de relacionamentos é um conjunto de relacionamentos de mesmo tipo.
Formalmente o relacionamento é uma relação matemática com n >= 2 (n =
número de conjuntos entidades).
Se E1, E2, ..., En são conjuntos de entidades, então um conjunto de
relacionamentos R é um subconjunto de {(e1,e2,...,e3) | e1 ∈ E1, e2 ∈ E2, ..., en ∈
En} em que (e1,e2,...,e3) são relacionamentos.
A associação entre os conjuntos de entidades é referida como uma
participação: o conjunto de entidades E1, E2, ..., Em participa do conjunto de
relacionamentos R.
Uma instância de relacionamento em um esquema E-R representa a existência
de uma associação entre essas entidades no mundo real no qual se insere o
domínio que está sendo modelado.
Grau do relacionamento: o relacionamento binário (envolve dois conjuntos
entidades) é um relacionamento de grau 2. E assim por diante.
Conjuntos de Relacionamentos
Exemplo:
Considere os conjuntos entidades cliente e empréstimo.
Definimos o conjunto de relacionamentos devedor para denotar a
associação entre clientes e empréstimos bancários contraídos pelos
clientes.
Jones
321-12-3123
Main
Harrison
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 função que uma entidade desempenha em um relacionamento é chamada
papel.
Algumas vezes o “conjunto entidade” pode participar de um “conjunto
relacionamento” mais de uma vez em papéis diferentes e, nessas situações, o
papel é importante para interpretação do modelo.
Exemplo:
Em relacionamentos recursivos, nomes explícitos de papéis são necessários para
especificar como uma entidade participa de uma instância de relacionamento.
Considere o conjunto de entidades empregado. Podemos ter um conjunto de
relacionamentos trabalha_para que é modelado para ordenar os pares de entidades de
empregado numa relação de hierarquia de cargos. Neste exemplo, os relacionamentos de
trabalha-para são caracterizados pelos pares (gerente,empregado).
Atributos descritivos em relacionamentos: atributos podem fazer parte de conjuntos
relacionamentos para melhor descrever o mundo real.
Exemplo: a data de último acesso em um conta bancária.
Mapeamento de Restrições
Mapeamento das cardinalidades expressa o número de entidade às quais
outra entidade pode estar associada via um conjunto de relacionamentos.
Um para um: uma entidade em A está associada no máximo a uma entidade
em B, e uma entidade em B está associada a no máximo uma entidade em A.
Um para muitos: Uma entidade em A está associada a várias entidades em B.
Uma entidade em B deve estar associada no máximo a uma entidade em A.
Muitos para um: Uma entidade em A está associada a no máximo uma
entidade em B. Uma entidade em B, pode estar associada a um número
qualquer de entidades em A.
Muitos para muitos: Uma entidade em A está associada a qualquer número
de entidades em B e uma entidade em B está associada a um número
qualquer de entidades em A.
Interpretação:
1
1
Aluno
Curso
1
N
Aluno
Curso
N
1
Aluno
Curso
N
Aluno
M
Curso
Conjunto relacionamento: Participa
Mapeamento de Restrições
Dependência de Existência
Se a existência da entidade X depende da existência da entidade Y, então X é
dito dependente da existência de Y.
Operacionalmente, se Y deixar de existir, conseqüentemente, X deve deixar
de existir.
Exemplo:
Considere o conjunto de entidades empréstimo e o conjunto de entidades
pagamento (que mantém todas as informações sobre os pagamentos
realizados para um determinado empréstimo).
O conjunto de entidades empréstimo é considerado dominante e o
conjunto de entidades pagamento é considerado subordinado.
Se todas as entidades de um conjunto participam de pelo menos um
relacionamento R, este é dito total, se apenas algumas das entidades do
conjunto participam do relacionamento, então este é dito parcial.
A participação total está estreitamente relacionada à existência de
dependência. Para haver dependência de existência, a participação da
entidade subordinada ao relacionamento correspondente deve ser total.
Chaves
Por meio de chaves podemos diferenciar as diversas entidades
pertencentes a um conjunto de entidades, e os diversos relacionamentos
pertencentes a um conjunto de relacionamentos.
Conjuntos de Entidades
Superchave: conjunto de um ou mais atributos que, tomados
coletivamente, nos permitem identificar de maneira unívoca uma entidade
em um conjunto de entidades.
Chaves candidatas: Superchaves para as quais nenhum subconjunto
possa ser uma superchave.
Chave primária: chave candidata escolhida pelo projetista de banco de
dados como a chave de significado principal para a identificação de
entidades dentro de um conjunto de entidades.
Uma chave é uma propriedade do conjunto de entidades e não de uma
entidade individualmente. Quaisquer duas entidades individuais em um
conjunto não podem ter, simultaneamente, mesmos valores em seus
atributos-chave.
A especificação de uma chave representa uma restrição ao mundo real do
domínio que está sendo modelada.
Chaves
Conjuntos de relacionamentos:
A composição da chave primária para um conjunto de
relacionamentos depende de uma estrutura de atributos associada
ao conjunto de relacionamentos de R.
Se o conjunto de relacionamentos não possui atributos então uma
superchave deve ser formada pelas chaves de cada entidade
participante do relacionamento.
Se o conjunto de relacionamentos possui atributos então uma
superchave deve ser formada pelas chaves de cada entidade
participante do relacionamento mais o conjunto de atributos deste.
A estrutura da chave primária para o conjunto de relacionamentos
depende do mapeamento da cardinalidade do conjunto.
Muitos para muitos: união das chaves da entidade + atributos
descritivos;
Muitos para um ou um para muitos: chave da entidade do lado do
muitos + atributos descritivos
Um para um: qualquer umas das chaves primárias pode ser usada.
Projeto de um Esquema de BD
Fases do projeto:
Levantamento de requisitos: quais são as necessidades dos usuários
do BD e como este BD será estruturado;
Construção do projeto conceitual: transcrever as necessidades
especificadas para um esquema conceitual de BD (MER);
Especificação das necessidades funcionais: descrever as transações
que serão realizadas sobre os dados;
Projeto lógico e físico: mapeamento do projeto conceitual para o
modelo de implementação de dados no SGBD.
Modelo de Dados Relacional
O Modelo Relacional (MR) é considerado o primeiro
modelo de dados efetivamente usado em aplicações
comerciais.
Foi introduzido por Codd em 1970.
É o modelo que possui a base mais formal entre os
modelos de dados, entretanto, é o mais simples e
com estrutura de dados mais uniforme.
MR - Estrutura Básica
Um banco de dados relacional consiste de uma coleção de tabelas de
nomes únicos.
Cada tabela possui um conjunto de linhas que representa um
relacionamento entre um conjunto de valores.
O conceito de tabelas está intimamente ligado ao conceito de uma
relação matemática – de onde se origina o nome deste modelo.
Uma tabela é formada por um conjunto de colunas denominadas de
atributos e por um conjunto de linhas denominadas de tuplas.
Para cada atributo existe um conjunto de valores permitidos, chamado de
domínio.
MR - Formalmente...
Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio
do atributo A2 e ... Dn denote o domínio do atributo Na da tabela T1.
Qualquer linha da tabela que possui estes atributos é denotada pela tupla
(d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn.
Em geral, uma instância de T1 é um subconjunto de
D1 X D2 X ... X Dn.
Matematicamente, define-se uma relação como um subconjunto de um
produto cartesiano de uma lista de domínios.
As 12 Regras de Codd
Edgard F. Codd, em 1985, estabeleceu as 12
regras de Codd que determinam o quanto um banco
de dados é relacional.
Algumas vezes as regras se tornam uma barreira e
nem todos os SGBDs relacionais fornecem suporte
a elas.
As 12 Regras de Codd
1.
Regra das informações em tabelas:
As informações a serem armazenadas no banco de
dados devem ser apresentadas como relações (tabelas
formadas por linhas e colunas) e o vínculo de dados
entre as tabelas deve ser estabelecido por meio de
valores de campos comuns. Isso se aplica tanto aos
dados quanto aos metadados (que são descrições dos
objetos do banco de dados).
As 12 Regras de Codd
2. Regra de acesso garantido:
Para que o usuário possa acessar as informações contidas
no banco de dados, o método de referência deve ser o nome
da tabela, o valor da chave primária e o nome do
campo/coluna.
As 12 Regras de Codd
3. Regra de tratamento sistemático de valores nulos:
O SGBD deve ser capaz de tratar valores que não são
fornecidos pelos usuários, de maneira que permita a
distinção de dados reais. Valores nulos devem ter um
tratamento diferente de “valores em branco”.
As 12 Regras de Codd
4. Regra do catálogo relacional ativo:
Toda a estrutura do banco de dados (domínios, campos,
tabelas, regras de integridade, índices, etc) deve estar
disponível em tabelas (também referenciadas como
catálogo).
Sua manipulação é possível por meio de linguagens
específicas. Essas tabelas são, geralmente, manipuladas
pelo próprio sistema no momento em que o usuário efetua
alterações na estrutura do banco de dados.
As 12 Regras de Codd
5. Regras de atualização de alto-nível:
Essa regra diz que o usuário deve ter capacidade de
manipular as informações do banco de dados em
grupos de tuplas (registros), ou seja, ser capaz de
inserir, alterar e excluir várias 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
usuário possa manipular a estrutura do banco de dados
(como criação e alteração de tabelas), bem como extrair,
inserir, atualizar ou excluir dados, definir restrições de acesso
e controle de transações (commit e rollback, por exemplo).
Deve ser possível ainda a manipulação dos dados por meio
de programas aplicativos.
As 12 Regras de Codd
7. Regra de independência física:
Quando for necessária alguma modificação na forma como
os dados estão armazenados fisicamente, nenhuma
alteração deve ser necessária nas aplicações que fazem uso
do banco de dados. Também devem permanecer inalterados
os mecanismos de consulta e manipulação de dados
utilizados pelos usuários finais.
As 12 Regras de Codd
8. Regra de independência lógica:
Qualquer alteração efetuada na estrutura do banco de dados
como inclusão ou exclusão de atributos de uma tabela ou
alteração no relacionamento entre tabelas não deve afetar o
aplicativo que o usa.
Da mesma forma, o aplicativo somente deve manipular
visões dessas tabelas.
As 12 Regras de Codd
9. Regra de atualização de visões:
Uma vez que as visões dos dados de uma ou mais tabelas
são, teoricamente suscetíveis atualizações, um aplicativo que
faz uso desses dados deve ser capaz de efetuar alterações,
exclusões e inclusões. Essas atualizações, no entanto,
devem ser repassadas automaticamente às tabelas originais.
As 12 Regras de Codd
10. Regra de independência de integridade:
As várias formas de integridade de banco de dados
(integridade de entidade, integridade referencial, restrições,
obrigatoriedade de valores, etc) precisam ser estabelecidas
dentro do catálogo do sistema ou dicionário de dados, e ser
totalmente independentes da lógica dos aplicativos.
As 12 Regras de Codd
11. Regra de independência de distribuição:
Alguns SGBDs, notadamente os que seguem o
padrão SQL, podem ser distribuídos em diversas
plataformas/equipamentos que se encontrem
interligados em rede. Essa capacidade de
distribuição não pode afetar a funcionalidade do
sistema e dos aplicativos que fazem uso do banco
de dados.
As 12 Regras de Codd
12. Regra não-subversiva:
O sistema deve ser capaz de impedir qualquer
usuário ou programador de transgredir os
mecanismos de segurança, regras de integridade do
banco de dados e restrições, utilizando algum
recurso de linguagem de baixo nível que
eventualmente possam ser oferecidos pelo próprio
sistema.
Estrutura Básica
Um banco de dados relacional consiste de uma coleção de relações
(tabelas) de nomes únicos.
Cada tabela possui um conjunto de linhas que representa um
relacionamento entre um conjunto de valores.
O conceito de tabelas está intimamente ligado ao conceito de uma
relação matemática – de onde se origina o nome deste modelo.
Uma tabela é formada por um conjunto de colunas denominadas de
atributos e por um conjunto de linhas denominadas de tuplas.
Para cada atributo existe um conjunto de valores permitidos, chamado de
domínio.
Relação
Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio
do atributo A2 e ... Dn denote o domínio do atributo N da tabela T1.
Qualquer linha da tabela que possui estes atributos é denotada pela tupla
(d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn.
Em geral, uma instância de T1 é um subconjunto de
D1 X D2 X ... X Dn.
Matematicamente, define-se uma relação como um subconjunto de um
produto cartesiano de uma lista de domínios.
O grau de uma relação é o número de atributos que a compõe.
Particularidades
Atomicidade de atributo = primeira forma normal.
Modelo relacional plano.
O valor null.
As relações interpretam/representam fatos sobre
entidades e fatos sobre relacionamentos.
Linguagem de consulta SQL.
Exercício: Interprete o MER e crie um MR
correspondente.
Representação Tabular de Atributos
Multivalorados
Para um atributo multivalorado M, cria-se uma tabela
T com uma coluna C que corresponde a M e as
colunas correspondentes à chave primária do
conjunto de entidades ou do conjunto
relacionamento do qual M é atributo.
No exemplo da localização de departamento: cada
elemento da nova tabela é uma localização de um
departamento.
Representação Tabular da Generalização
Para a situação:
num_conta
saldo
conta
tx_juros
conta_poup
ISA
limite
conta_mov
Representação Tabular da Generalização
Criar uma tabela para o conjunto de entidades de nível superior.
Para cada conjunto de entidades de nível inferior, criar uma tabela que
inclua:
Uma coluna para cada um dos atributos daquele conjunto de entidades
Uma coluna para cada atributo da chave primária do conjunto entidades de
nível superior.
Assim:
conta, com os atributos número_conta e saldo
conta_poupança, com os atributos número_conta e taxa_juros
conta_movimento, com os atributos número_conta e limite_cheque_especial
Representação Tabular da Generalização
Se a generalização é mutuamente exclusiva:
nenhuma entidade é membro de mais de um conjunto de entidades de
nível imediatamente inferior ao conjunto de entidades de nível superior;
e todas as entidades do conjunto de entidades de nível superior são
membro também de um dos conjuntos de entidades de nível inferior.
Para cada conjunto de entidades de nível inferior, cria-se uma tabela que
inclua uma coluna para cada um dos atributos deste conjunto de entidades
mais uma coluna para cada atributo do conjunto de entidades de nível
superior
Assim:
conta_poupança, com atributos número_conta, saldo e taxas_juros;
conta_movimento, com os atributos número_conta, saldo e
limite_cheque_especial
Representação Tabular da Agregação
Relembrando...
seguro
rua
número
cidade
nome
cliente
devedor
empréstimo
Agente_
emp
empregado
seguro
telefone
nome
saldo
Representação Tabular da Agregação
A tabela para o conjunto de relacionamentos agente_empréstimo inclui uma
coluna para cada atributo, uma para chave primária do conjunto de entidades
empregado e uma para o conjunto de relacionamentos devedor.
Poderia também incluir uma coluna para cada um dos atributos descritivos
descritivos do conjunto de relacionamentos agente_empréstimo, se eles existirem.
Assim:
cliente, com os atributos nome_cliente, seguro_cliente, rua, cidade;
empréstimo, com os atributos número_empréstimo, total;
devedor, com os atributos seguro_cliente, número_empréstimo;
empregado, com os atributos seguro_empregado, nome_empregado, número_telefone;
agente_empréstimo, com os atributos seguro_empregado, número empréstimo e
seguro_cliente.
Diretriz de Projeto nº 1:
Modelar um esquema de relação de modo que seja
fácil explicar seu significado. Se uma relação
corresponde a uma mistura de entidades e
relacionamentos, resultarão em ambigüidades
semânticas e a relação não poderá se explicada
facilmente.
Esquemas pobres porque violam a Diretriz 1:
Emp_dept:
enome, ssn, datanasc, endereco, dnumero,
dnome, dgerssn.
Emp_proj: ssn, pnumero, horas, enome, pnome,
plocalização.
Redução de Valores Redundantes nas
Tuplas
Deve-se minimizar o espaço de armazenamento
utilizado pelas relações básicas:
Agrupe atributos em esquemas de relações;
Deve-se evitar situações que caiam em problemas de
Anomalias na Atualização.
Diretriz Projeto nº 2:
Modelar esquemas de relações básicas de forma que
nenhuma anomalia de atualização possa ocorrer nas
relações. Se houver a possibilidade de ocorrer alguma
anomalia, registre-a claramente e tenha certeza de que os
programas que atualizam o banco de dados operarão
corretamente.
Pode-se violar uma diretriz em prol do desempenho de uma
consulta, entretanto, as medidas cabíveis devem ser tomadas
para que os dados estejam sempre consistentes e íntegros.
Redução de Valores null nas Tuplas
A existência de muitas possibilidades de uso do valor null
causa desperdício de espaço no armazenamento e gera
problema de entendimento do significado do atributos e da
especificações de joins, e funções agregadas.
Motivos para uso do null:
O atributo não se aplica à tupla;
O valor do atributo para a tupla é desconhecido;
O valor do atributo para a tupla é conhecido, mas ausente, ou seja,
ainda não foi registrado.
Diretriz Projeto nº 3:
Até onde for possível, evite colocar os atributos em uma
relação básica cujos valores freqüentemente possam ser
nulos. Se os nulls forem inevitáveis, tenha certeza de que
eles se aplicam somente em casos excepcionais e não na
maioria das tuplas da relação.
Ex: se só 10% dos empregados tiverem escritórios
particulares, há pouca justificativa para incluir um atributo
ESCRITORIO-NRO na relação EMPREGADO; pode ser
criada uma relação EMP_ESCRITÖRIOS (ESSN,
ESCRITORIO_NRO) que contenha apenas as tuplas dos
empregados que possuírem escritórios particulares.
Impedimento para a Geração de Valores
Ilegítimos nas Tuplas
Considere os esquemas:
Esquema 1:
Emp_locs (enome, plocalização)
Emp_proj1 (ssn, pnumero, horas, pnome, plocalização)
Esquema 2:
Emp_proj: (ssn, pnumero, horas, enome, pnome, plocalização)
A partir do esquema 1 é possível conseguir as mesmas informações
que temos no esquema 2?
Não, usando um JOIN conseguiremos tuplas ilegítimas.
Diretriz Projeto nº 4:
Projete os esquemas de relações de forma que
possam ser unidos (join) com igualdade de
condições sobre os atributos que sejam chaves
primárias ou chaves estrangeiras, de modo a
garantir que nenhuma tupla ilegítima seja gerada.
Normalização
A normalização de dados pode ser vista como o processo de análise de
determinados esquemas de relações com base em suas dependências
funcionais e chaves primárias para alcançar as propriedades desejáveis:
Minimização de redundâncias;
Minimização de modificações.
O esquemas de relações insatisfatórias, que não alcançam certas
condições – os testes de forma normal -, são decompostas em esquemas
de relações menores que passam nos testes e, conseqüentemente,
possuem as propriedades desejadas.
Conceitos
A forma normal de uma relação refere-se à condição da mais alta forma
normal alcançada e, conseqüentemente, indica o grau no qual foi
normalizada.
A normalização sempre deve estar acompanhada da garantia de duas
propriedades:
Junção sem perdas: Garante que o problema de geração de tuplas ilegítimas
não ocorra (propriedade crítica que deve sempre ser garantida);
Preservação de dependências: Garante que cada dependência funcional será
representada em alguma relação individual resultante da decomposição.
Primeira Forma Normal (1NF)
Impedimento para a criação de atributos multivalorados, atributos
compostos e combinações entre eles.
Estabelece-se que o domínio de um atributo só deva incluir os valores
atômicos e que o valor de qualquer atributo em uma tupla deve ter um
único valor no domínio daquele atributo.
A 1NF impede as “relações dentro de relações” ou “relações como valores
de atributos dentro de tuplas”.
Primeira Forma Normal
Considerando o departamento que possui um atributo multivalorado:
localizações. Há três técnicas básicas para alcançar a primeira forma
normal:
1.
2.
3.
Remover o atributo DLocalizações que viola a 1NF e colocá-lo em uma
relação separada, junto com a chave primária que identifica a entidade
“departamento”.
Ampliar as chaves de forma a separar as tuplas da relação original
DEPARTAMENTO, criando uma para cada localização de “departamento”.
Se um número máximo de valores puder ser estabelecido para o atributos,
por exemplo, se é sabido que há no máximo três locais para cada
departamento, substituir o atributo Dlocalizações por três atributos
atômicos.
Segunda Forma Normal (2NF)
Baseada no conceito de dependência funcional total.
Uma dependência funcional X Y será uma dependência
funcional total se a remoção de qualquer atributo A de X
implicar que a dependência não mais será assegurada, isto
é, para qualquer atributo A ∈ X, (X – {A}) não determina
funcionalmente Y.
Uma dependência funcional X Y é uma dependência
parcial se um atributo A ∈ X puder ser removido de X e a
dependência mesmo assim continuar existindo, ou seja, para
algum A ∈ X, (X – {A}) Y.
Segunda Forma Normal
Exemplo de dependências funcionais totais e parciais:
Considere o esquema:
SSN, PNumero, Horas, Enome, Pnome, Plocalização
{SSN, PNumero} Horas: é uma dependência funcional total (não são
asseguradas nem SSN Horas nem PNumero Horas).
{SSN, PNumero} Enome: é uma dependência funcional parcial porque SSN
Enome é assegurada.
Segunda Forma Normal
Um esquema de relação R está na 2NF se todo atributo não primário A
em R tem dependência funcional total da chave primária de R.
O teste para a 2NF envolve verificar se os atributos do lado esquerdo das
dependência funcionais fazem parte da chave primária. Se a chave
primária contiver um único atributo, a necessidade do teste não se aplica.
A relação do slide anterior está na 1NF mas não está na 2NF. O atributo
não primário enome viola a 2NF em razão da dependência funcional SSN
Enome. Enome é parcialmente dependente da chave primária (já que
depende de SSN).
Segunda Forma Normal
Um esquema pode ser normalizado na 2NF por meio da criação de várias
relações na 2NF nas quais os atributos não primários só estarão
associados a dependências funcionais total.
Considere o esquema abaixo e suas dependências funcionais:
SSN, PNumero, Horas, Enome, Pnome, Plocalização
SSN, PNumero Horas
SSN Enome
PNumero Pnome, Plocalização
Segunda Forma Normal
Normalizando, cria-se três esquemas:
Esquema1: SSN, Pnumero, Horas
com a dependência funcional: SSN, PNumero Horas
Esquema 2: SSN, Enome
com a dependênia funcional: SSN Enome
Esquema 3: PNumero, Pnome, Plocalização
com a dependência funcional: PNumero Pnome,
Plocalização
Terceira Forma Normal (3NF)
De acordo com a definição original de Codd, um
esquema de relação R está na 3NF se satisfizer a
2NF e se nenhum atributo não primário de R for
transitivamente dependente da chave primária.
Está baseada no conceito de dependência transitiva.
Uma dependência funcional X Y, em um esquema de
relação R, será uma dependência transitiva se existir um
conjunto de atributos Z que não é nem uma chave candidata
nem um subconjunto de qualquer chave de R, e ambas X Z e Z Y forem asseguradas.
Terceira Forma Normal
Como exemplo, considere o seguinte esquema com sua
dependências funcionais:
Enome, SSN, DataNasc, Endereço, Dnumero, Dnome, DgerSSN
SSN Enome, DataNasc, Endereco, DNumero
DNumero Dnome, DgerSSN
A dependência funcional SSN DgerSSN é transitiva para
Dnumero, pois ambas as dependências SSN Dnumero e
Dnumero DgerSSN são asseguradas e Dnumero não é nem chave primária nem um
subconjunto da chave da relação.
Terceira Forma Normal
A normalização
na 3NF para o exemplo se dá por meio da
decomposição:
Esquema 1: Enome, SSN, DataNasc, Endereço, Dnumero
com a dependência funcional: SSN Enome, DataNasc,
Endereco, DNumero
Esquema 2: Dnumero, Dnome, DgerSSN
com a dependência funcional: DNumero Dnome,
DgerSSN
Generalização
As definições tratadas até aqui dizem respeito a parcialidade e
transitividade de dependencias funcionais com respeito à chave primária
da relação.
Estas definições devem ser expandidas para a consideração de todas as
chaves candidatas.
2NF: um esquema de relação R está na segunda forma normal se cada
atributo não primário A de R não forem parcialmente dependente de
nenhuma chave de R.
3NF: um esquema de relação R está na terceira forma normal se sempre
que uma depependência funcional não trivial X A for determinada em
R, então: (A) qualquer X é uma superchave de R; ou (B) A é um atributo
primário de R.
Mais um exemplo:
Esquema Lotes:
Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preço, Imposto
Dependências funcionais:
DF 1: Num_ID_Propriedade Municipio_nome, Num_lote, Area, Preço, Imposto
DF 2: Municipio_nome, Num_lote Num_ID_Propriedade, Area, Preço, Imposto
DF 3: Municipio_nome Imposto
DF 4: Area Preço
Colocando na 2NF:
O esquema de relação Lotes viola a definição GERAL da 2NF porque
Imposto é parcialmente dependente da chave candidata
{Municipio_nome, Num_lote} em razão da terceira dependência funcional.
Construímos então o esquema Lotes 1 removendo o atributo Imposto que
viola a 2NF de Lotes, para colocá-lo com Municipio_nome em outro
esquema: Lotes 2.
Lotes1 : Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preço
Com as DFs 1, 2 e 4
Lotes2: Municipio_nome, Imposto
Com a DF 3.
Note que a DF 4 não viola a 2NF.
Colocando na 3NF:
Lotes2 está na 3NF.
Lotes1 não está pois a dependência funcional 4 viola a definição GERAL.
Área não é uma superchave;
Preço não é um atributo primário em Lotes1.
Construímos:
Lotes1a: Num_ID_Propriedade, Municipio_nome, Num_lote, Area
Com as DFs 1 e 2.
Lotes1b: Area, Preço
Com a DF 4.
Forma Normal de Boyce-Codd (BCNF)
Foi proposta como uma forma normal mais simples de 3NF,
mas é considerada mas rígida que a 3NF.
Toda relação BCNF está também em 3NF, mas o contrário
pode não ser verdadeiro.
Definição: Um esquema de relação R está na BCNF sempre
que uma dependência funcional não trivial X A for mantida
em R, então X será uma superchave de R.
BCNF
Suponha a seguinte situação para o último exemplo modelado:
Existem milhares de lotes cadastrados mas eles estão
localizados em apenas duas cidades. E as áreas dos lotes nas
duas cidades são definidas de formas diferentes. Assim, a
dependência funcional Area Municipio_nome deveria valer.
Ainda assim, Lotes1a estaria na 3NF, pois Municipio_nome é
um atributo primário.
BCNF
Mas existe redundância de informação, pois a área que determina o
município, como dito pela nova dependência funcional, pode ser
representada uma única vez, em uma relação a parte.
A BCNF sugere a decomposição do esquema Lotes1a em:
Lotes1ax : Num_ID_propriedade, Area, Num_lote
com as DFs 1 e 2.
Lotes1ay : Area, Municipio_nome
com a DF 5.
Cuidado com a decomposição com perdas na junção!
BCNF - Exemplos
Relembrando: Uma relação R está na BCNF sse R está na
3NF e nenhum atributo possua dependência transitiva em
relação à chave primária.
Exemplo:
Relação CURSA
ALUNO
DISCIPLINA
TUTOR
Nagiza
Banco de Dados I
Korth
Silvio
Banco de Dados I
Navathe
Silvio
Banco de Dados II
Setzer
Silvio
Data Mining
Duhran
William
Banco de Dados I
Korth
William
Banco de Dados II
Elmasri
Zélia
Banco de Dados I
Date
Camila
Banco de Dados I
Navathe
BCNF - Exemplo
Primeiro, têm-se que identificar as DF envolvendo atributos que pertençam a chave
primária.
Tutor Disciplina
Aluno, Disciplina Tutor
Há dependência transitiva da chave primária!
Relação CURSA
ALUNO
DISCIPLINA
TUTOR
A relação acima está na 3NF e na BCNF?
BCNF - Exemplo
A relação está na 3NF pois possui somente atributos
atômicos, não apresenta dependência parcial da chave
primária e não existem DFs de um atributo não pertencente
a chave primária em relação a atributos não pertencentes à
chave primária. Porém, não está na BCNF pois possui
dependência transitiva de um atributo chave com relação à
chave primária.
A solução seria separar a relação em duas ou mais
relações, de forma a eliminar a dependência transitiva:
Tutoria (Tutor, Disciplina)
Cursa(Tutor, Aluno)
BCNF – Outro Exemplo
Considere a relação orientador abaixo. Suponha que
as exigências básicas dessa relação sejam: Um
aluno (IDAL) pode ter mais que uma especialização,
uma especialização pode ter vários membros do
corpo docente (Fnome) como orientadores e um
professor orienta somente em uma área de
especialização.
BCNF – Outro Exemplo
Relação
IDAL
100
150
200
250
300
300
Orientador
Especialização
Matemática
Psicologia
Matemática
Matemática
Psicologia
Matemática
DF:
Fnome Especialização
Fnome
Caughy
Jung
Riemann
Caughy
Perls
Riemann
BCNF – Outro Exemplo
Há nessa relação uma anomalia de eliminação (por
exemplo, se o aluno 300 sair da escola e se seus
registros forem apagados, perde-se o fato de que
Perls orienta em psicologia) e existe também uma
anomalia de inserção (Não se pode armazenar um
orientador em uma área, a não ser que um aluno se
especialize na cadeira).
BCNF – Outro Exemplo
Relação Al_Orient
Relação Orient_Discip
IDAL
Fnome
Fnome
Especialização
100
Caughy
Caughy
Matemática
150
Jung
Jung
Psicologia
200
Riemann
Riemann
Matemática
250
Caughy
Perls
Psicologia
300
Perls
300
Riemann
Agora sim, está na BCNF.
Dependência Multivalorada
“Dada uma relação qualquer com três atributos x, y e z, dizse que y depende de forma multivalorada de x sse
sempre que existirem duas tuplas (x1,y1,z1) e (x1,y2,z2)
existirão também duas tuplas (x1,y1,z2) e (x1,y2,z1)”.
Refere-se à combinação de valores de atributos
multivalorados disjuntos (y e z).
x na verdade, relaciona-se com y e com z de forma
independente.
4ª Forma Normal (4NF)
“Uma tabela está na 4FN sse estiver na 3FN e não existirem
dependências multivaloradas”.
Exemplo: Dados sobre livros
Relação não normalizada: Livros(nrol, (autor), título, (assunto),
editora, cid_edit, ano_public)
1FN: Livros(nrol, autor, assunto, título, editora, cid_edit,
ano_public)
2FN: Livros(nrol,título, editora, cid-edit, ano_public)
AutAssLiv(nrol, autor, assunto)
3FN: Livros(nrol, título, editora, ano_public)
Editoras(editora, cid-edit)
AutAssLiv(nrol, autor, assunto)
4ª Forma Normal (4NF)
Nrol
1
1
1
1
2
2
2
2
2
2
Autor
aut1
aut1
aut2
aut2
aut1
aut1
aut1
aut3
aut3
aut3
Assunto
ass1
ass2
ass1
ass2
ass3
ass4
ass1
ass3
ass4
ass1
Redundância para representar todas as informações;
Evitar todas as combinações: representação não-uniforme (repete
alguns elementos ou posições nulas).
Passagem à 4FN
Geração de novas tabelas, eliminando Dependências
Multivaloradas
Análise de Dependências Multivaloradas entre atributos:
autor, assunto Dependência multivalorada de nrol
Resultado:
4FN: Livros(nrol, título, editora, ano_public)
Editoras(editora, cid-edit)
AutLiv(nrol, autor)
AssLiv(nrol, assunto)
4ª Forma Normal – Outro Exemplo
Relação Aluno
IDAL
Especialização
Atividade
100
Música
Natação
100
Contabilidade
Natação
100
Música
Tênis
100
Contabilidade
Tênis
150
Matemática
Jogging
DF múltiplas:
IDAL Especialização
IDAL Atividade
4ª Forma Normal – Outro Exemplo
Relação Aluno
Relação Aluno
IDAL
Especializaçã
o
Atividade
100
Música
Natação
100
Contabilidade
Natação
100
Música
IDAL
Especializaçã
o
Atividade
100
Música
Natação
100
Contabilidade
Natação
100
Música
Tênis
100
Contabilidade
Tênis
150
Matemática
Jogging
Tênis
100
Contabilidade
Tênis
150
Matemática
Jogging
100
Música
Esqui
100
Música
Esqui
100
Contabilidade
Esqui
Ao inserir nova atividade ao aluno 100 com a especialização música, deve-se
inserir também outra tupla, o que mostra uma anomalia de atualização.
4ª Forma Normal – Outro Exemplo
Relação Al_Espec
Relação Al_Ativ
IDAL
Especialização
IDAL
Atividade
100
Música
100
Esqui
100
Contabilidade
100
Natação
100
Tênis
150
Matemática
150
Jogging
Agora sim, está na BCNF, sem dependências
multivaloradas!
5ª Forma Normal (5NF)
“Uma tabela está na 5FN sse estiver na 4FN e um relacionamento triplo não
puder ser decomposto em relacionamentos binários sem geração de
informação incorreta”.
Caso especial: Relacionamento envolvendo Chaves primárias de 3 tabelas, que
nem sempre é possível decomposição correta.
Exemplo: relacionamento Agente-Companhia-Produto
Agente
João
João
Companhia
Ford
GM
Produto
Carro
Caminhão
5ª Forma Normal
Formato necessário quando existem apenas algumas
combinações entre os 3 atributos (tabela c/ tripla).
Situação: Se um agente vende um certo produto e ele
representa uma companhia, então ele vende um produto
fabricado por esta companhia Todos os pares se
combinam!
5ª Forma Normal
Agente
Companhia
Produto
João
Ford
Carro
João
Ford
Caminhão
João
GM
Carro
João
GM
Caminhão
Carlos
Ford
Carro
Neste caso, é possível decompor uma tripla em três
relações binárias com eliminação de certas redundâncias.
5ª Forma Normal
As três relações abaixo estão na 5FN:
Agente
Companhia
João
Ford
João
GM
Carlos
Ford
Agente
Produto
João
Carro
João
Caminhão
Carlos
Carro
Companhia
Produto
Ford
Carro
Ford
Caminhão
GM
Carro
GM
Caminhão
Eliminação de certas redundâncias:
- Apenas uma vez está dito que Ford produz carros;
- Apenas uma vez está dito que João é agente da GM.
Apesar do aumento no número de tabelas, o número total de
tuplas na forma normalizada é menor.
Banco de Dados Orientado a Objetos
- Motivações
Novas aplicações ficaram limitadas por restrições impostas pelo modelo
relacional.
As aplicações convencionais possuem características comuns que as tornam
passíveis de serem tratadas por bancos de dados relacionais:
Uniformidade: as informações a serem armazenadas podem ser
estruturadas de maneira similar.
Orientação a registros: registros de tamanho fixo são adequados para a
representação desta informação.
Itens de dados pequenos: as informações são estruturadas em registros
pequenos.
Campos atômicos: os campos dentro de um registro são pequenos e de
comprimento fixo. Não há estruturas dentro dos campos, ou seja, a primeira
forma normal pode ser mantida.
O modelo de banco de dados orientado a objetos está baseado no paradigma
de programação orientada a objeto.
Introdução e Motivações
As aplicações mais novas, em geral, não possuem, no mínimo, uma das
características já citadas.
Exemplos dessas aplicações:
Computer-aided design (CAD) – projeto auxiliado por computador:
É necessário armazenar os dados pertencentes a um projeto de
engenharia, incluindo os componentes do item que está sendo projetado,
o inter-relacionamento dos componentes, as versões antigas do projeto.
Computer-aided software engineering (CASE) – engenharia de
software auxiliada por computador:
É necessário armazenar os dados necessários para apoiar os
desenvolvedores de software, incluindo o código-fonte, as dependências
entre os módulos de software, as definições e o uso de variáveis e o
histórico de desenvolvimento do sistema de software.
Introdução e Motivações
Bancos de dados multimídia:
Office information system (OIS) – sistemas de informação de
escritório:
Contém imagens, dados espaciais, dados de áudio, dados de vídeo e
afins (envolvem principalmente o armazenamento de fotografias e dados
geográficos, voz e vídeo).
Necessidade de suportar dados para ferramentas para criação e
recuperação de documentos e ferramentas para manutenção de
calendários, permitindo solicitações pertencentes a agendas, documentos
e conteúdos de documentos.
Bancos de dados de hipertexto:
Necessidade de suportar o armazenamento/gerenciamento das estruturas
específicas e indexação de textos enriquecidos com links que apontam
para outros documentos, permitindo a recuperação de documentos
baseados em sua estrutura.
Modelagem de BDOOs
Isso:
Modelagem de BDOOs
Ao invés disso:
O Modelo de Dados Orientado a Objeto
A estrutura objeto:
Superficialmente, um objeto corresponde a uma entidade no modelo E-R.
Este paradigma se baseia no encapsulamento de dados e em código
relacionado a um objeto dentro de uma única unidade.
As interações entre um objeto e o resto do sistema deve ser via
mensagens.
Uma interface entre um objeto e o resto do sistema deve ser definida por
um conjunto de mensagens permitidas.
Em geral, um objeto tem associado a ele:
Um conjunto de variáveis que contém os dados para o objeto; as variáveis
correspondem aos atributos no modelo E-R;
Um conjunto de mensagens ao qual o objeto responde; cada mensagem
pode ter zero, um ou mais parâmetros;
Um conjunto de métodos, cada qual sendo um corpo de código para
implementar a mensagem; um método retorna um valor como resposta à
mensagem.
O 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 específicos de implementação.
O termo chamar um método algumas vezes é usado para representar o ato de enviar uma
mensagem a um objeto e a execução do método correspondente.
Exemplo:
Considerando a entidade empregado em um banco de dados. Suponha que o salário anual
de um empregado seja calculado de maneiras diferentes para diferentes empregados. Por
exemplo, os gerentes podem ter um bônus dependendo do desempenho do banco, enquanto
os caixas podem obter um bônus dependendo de quantas horas eles trabalharam. É possível
encapsular o código para calcular o salário para cada empregado como um método que é
executado em resposta a uma mensagem salário_anual.
Todos os objetos empregado respondem à mensagem salário_anual, mas fazem isso de
diferentes maneiras. Pelo encapsulamento da informação sobre como calcular o salário anual
dentro do objeto empregado, todos os objetos empregados apresentam a mesma interface.
É possível modificar a definição de um objeto sem afetar o resto do sistema. Esta é uma das
habilidades considerada como uma das maiores vantagens do paradigma de programação
orientado a objetos.
O Modelo de Dados Orientado a Objeto
Os métodos de um objeto podem ser:
Somente leitura: não afeta os valores das variáveis em um objeto;
De atualização: pode mudar os valores das variáveis.
As mensagens às quais um objeto responde podem ser, de maneira similar, classificadas
como somente leitura ou de atualização, em função do método que implementa a
mensagem.
Cada atributo de uma entidade deve ser expresso como uma variável e um par de
mensagens do objeto no modelo orientado a objeto. A variável é usada para armazenar o
valor do atributo, uma mensagem é usada para ler o valor do atributo e o outro método é
usado para atualizar o valor. Por exemplo:
O atributo endereço da entidade empregado pode ser representado por:
Uma variável endereço;
Uma mensagem obter_endereço cuja resposta é o endereço;
Uma mensagem ajustar_endereço, que possui um parâmetro novo_endereço, para atualizar o
endereço.
Por simplicidade muitos modelos orientados a objeto permitem que as variáveis sejam
lidas ou atualizadas diretamente, sem ter de definir mensagens para isso.
Classes de Objetos
Objetos similares são aqueles que respondem às mesmas mensagens, usam os mesmos
métodos e têm variáveis de mesmo nome e tipo.
Objetos similares são agrupados formando uma classes.
Cada um desses objetos é chamada de uma instância de sua classe.
A noção de uma classe no modelo de dados orientado a objeto corresponde à noção de um
conjunto entidade do modelo E-R.
Exemplo de definição de uma classe:
Class empregado {
/* variáveis */
string nome;
string endereço;
date data_início;
int salário;
/* mensagen */
int salário_anual();
string obter_nome();
string obter_endereço();
int ajustar_endereço (string novo_endereço);
int tempo_emprego();
}
Classes de Objetos
Cada classe é um objeto em si e inclui uma variável contendo o conjunto
de todas as instâncias da classe.
Uma classe objeto inclui:
Uma variável conjunto valorada cujo valor é o conjunto de todos os
objetos que são instâncias da classe;
A implementação de um método para a mensagem new, que cria uma
nova instância da classe.
Herança
Considerando um banco de dados orientado a objetos para a aplicação bancária
(exemplo – Korth), a classe clientes é similar à classe empregados, pois ambas
definem variáveis para nome, endereço e assim por diante. No entanto, há
variáveis específicas para empregados (salário) e variáveis específicas para
clientes (classificação_crédito).
Neste caso é desejável definir uma representação para as variáveis comuns em
um único local. Para isso, combina-se empregados e clientes dentro de uma
classe.
Para permitir a representação direta de similaridades entre classes, necessita-se
colocar as classes em uma hierarquia de especialização.
Empregado e cliente são especializações de pessoa.
Este conceito é similar ao conceito de especialização no modelo E-R.
Empregados e clientes podem ser representados por classes que são
especializações de uma classe pessoa. Variáveis e métodos específicos a
empregados são associados à classe empregados. Variáveis e métodos
específicos a clientes são associados à classe cliente. Variáveis e métodos que se
aplicam tanto a empregados como a clientes são associados à classe pessoa.
class pessoa {
string nome;
string endereço;
};
class cliente isa pessoa {
int classificação_crédito
};
class empregado isa pessoa {
date data_início;
int salário;
};
class escriturário isa empregado {
int número_escriturário;
int número_conta_despesa;
};
class caixa isa empregado {
int horas_por_semana;
int número_estação;
};
class secretária isa empregado {
int horas_por_semana;
string gerente;
};
Herança
Um benefício importante da herança em sistemas orientados a objeto é a noção
de reusabilidade.
Qualquer método de uma classe pode ser invocado por qualquer objeto
pertencente a qualquer subclasse desta classe.
Para tratar a hierarquia de classes tem-se duas opções:
Associar à classe empregado todos os objetos empregado, incluindo aqueles
que são instâncias de escriturário, caixa e secretária.
Associar à classe empregado somente aqueles objetos empregado que não
são instâncias nem de escriturário, nem de caixa, nem de secretária.
É possível determinar o conjunto de todos os objetos empregado, nesse caso,
tomando-se a união daqueles objetos associados a todas as subclasses de
empregado.
Herança Múltipla
Suponha que precisemos distinguir entre escriturários, caixas e secretárias de
tempo integral e tempo parcial. Além disso, assuma que são necessárias
diferentes variáveis e métodos para representar empregados de tempo parcial e
tempo integral. Então cada um desses empregados são classificados de duas
maneiras diferentes.
pessoa
empregado
escriturário
escrit_TI
escrit_TP
caixa
caixa_TI
cliente
secretária
caixa_TP secretária_TI
secretária_TP
Herança Múltipla
Existem certas variáveis e métodos específicos para empregado em tempo
integral e outros específicos para empregado em tempo parcial. Assim, na
hierarquia em análise, as variáveis e métodos para empregados de tempo integral
devem ser definidos três vezes: uma vez para escriturário_TI, uma vez para
secretária_TI e uma vez para caixa_TI. Redundâncias deste tipo são indesejáveis
mediante alterações nas propriedades dos empregados de tempo integral (e
parcial), que deverão ser feitas em dois lugares diferentes.
Existe falha na exploração da reutilização de código.
Nesta hierarquia também não se consegue representar os empregados que não
são escriturários, caixas ou secretárias, mas que possuem características de
serem ou de tempo parcial ou integral.
Se existissem várias classificações de emprego, em vez de duas limitações neste
exemplo, as limitações do modelo se tornariam muito mais aparentes.
Herança Múltipla
Herança múltipla é a habilidade de uma classe herdar variáveis e métodos a partir
de múltiplas superclasses.
pessoa
cliente
empregado
tempo_integral
escrit_TI
escrit_TP
tempo_parcial
caixa_TI
escriturário
caixa_TP
caixa
secretária
secretária_TI
secretária_TP
Pode haver algum problema?
Herança Múltipla
Assuma que, em vez de definir salário para a classe empregado, defina-se uma variável
chamada pagamento para cada classe: tempo_integral, tempo_parcial, escriturário, caixa e
secretária, como a seguir:
Tempo_integral: pagamento é um inteiro de 0 a 100.000 contendo um salário anual;
Tempo_parcial: pagamento é um inteiro de 0 a 20, contendo uma taxa horária de
pagamento.
Caixa e escriturário: pagamento é um inteiro de 0 a 20.000, contendo um salário anual;
Secretária: pagamento é um inteiro de 0 a 25.000, contendo um salário anual.
Considere a classe secretária_TP. Ela pode herdar a definição de pagamento tanto de
tempo_parcial como de secretária. O resultado é diferente, dependendo da escolha feita.
Opções:
Incluir ambas as variáveis, renomenado-as como tempo_parcial.pagamento e
secretária.pagamento;
Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e
secretária foram criadas;
Forçar o usuário a fazer a escolha;
Tratar a situação como um erro.
Identidade de Objeto
Os objetos em um banco de dados orientado a objeto correspondem a uma
entidade na empresa que está sendo modelada. Uma entidade mantém sua
identidade mesmo se algumas de suas propriedades mudam com o tempo.
Um objeto mantém sua identidade mesmo se alguns ou todos os seus valores
de variáveis ou definições de métodos mudarem com o tempo.
Diferente do modelo relacional onde as tuplas de uma relação são
diferenciadas somente pelos valores que elas contêm.
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 usuário é usado
para identidade dos arquivos;
Embutido: usado em sistemas orientados a objetos a cada objeto é atribuído
automaticamente um identificador pelo sistema quando aquele objeto é criado.
Identificadores de objetos são únicos. Exemplo de uso do identificador:
Um dos atributos de um objeto pessoa pode ser o atributo cônjuge, que é realmente
um identificador do objeto pessoa correspondendo ao cônjuge da primeira pessoa.
Assim, o objeto pessoa pode armazenar uma referência ao objeto que representa o
cônjuge de pessoa.
Objetos Compostos
As referências entre os objetos podem ser usadas para modelar
diferentes conceitos do mundo real. Um desses conceitos é o de objetos
compostos.
bicicleta
freio
roda
aro
raio
pneu
pedal
É parte de
marcha
bloco
quadro
cabo
O conceito de composição permite que os dados sejam vistos em diferentes
granularidades por diferentes usuários.
Modelagem de BDOOs
Representação no BDOO:
Um BDOO armazena objetos integralmente;
É possível recuperar um objeto a qualquer momento, inclusive todas as
referências.
Linguagem de definição:
ODL (Object Definition Language);
Utilizada para criar definições de objetos.
Linguagem de consulta:
OQL (Object Query Language);
Utilizada para recuperar objetos do banco.
Modelagem de BDOOs
Classes
Modelagem de BDOOs
Automóvel{OID12}
Objetos
736194174
Ka
Preto
20000
OID1
[OID5123]
Fabricante{OID1}
Ford
João da Silva
[OID1125, OID1127, OID1128]
Peça{OID5123}
Correia Dentada
Ford
OID154
[OID1125, OID1127, OID1128]
Motor{OID154}
Rocam 1000 16V
OID1
120CV
Fábrica {OID1125}
Fábrica {OID1127}
Fábrica {OID1128}
Central
Camaçari
320
Filial São Bernardo I
São Bernardo
250
Filial São Bernardo II
São Bernardo
130
Modelagem de BDOOs
Automóvel{OID12}
736194174
Ka
Preto
20000
Objeto Complexo
Fabricante{OID1}
Ford
João da Silva
Fábrica {OID1127}
Fábrica {OID1128}
Filial São Bernardo I
São Bernardo
250
Filial São Bernardo
II
São Bernardo
130
Fábrica {OID1125}
Central
Camaçari
320
Motor{OID154}
Rocam 1000 16V
120 CV
Modelagem Padrão ODMG – ODL
Especificação ODL
class Pessoa
(extent pessoas
key nss)
{
attribute struct Nomep{string sobrenome, string primeiro_nome} nome;
attribute string nss;
attribute date data_nascimento;
attribute enum Genero{M,F} sexo;
attribute struct Endereço
{short num, string logradouro, sort numapto, string cidade, string estado, short
cpe}
endereço;
short idade();
};
Especificação ODL
class Professor extends Pessoa
( extent professores )
{
attribute string classificação;
attribute float salário;
attribute string escritório;
attribute string telefone;
relationship Departamento trabalha_em inverse Departamento::possui_professor;
relationship set<aluno_grad> dá_assistência inverse AlunoGrad::assistente;
relationship set<aluno_grad> no_comitê_de inverse AlunoGrad::comitê;
void dar_aumento(in float aumento);
void promove(in string nova_classificação);
};
Especificação 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;
};
Especificação ODL
class Aluno extends Pessoa
( extent alunos)
{
attribute string classe;
attribute Departamento cursa_eletiva_em;
relationship Departamento especializa_em inverse
Departamento::possui_especializações;
relationship set <grau> disciplinas_completadas inverse Grau::alunos;
relationship set <DisciplinaCorrente> registrado_em inverse
DisciplinaCorrente::alunos_registrados;
void alterar_especialização (in string nomed) raises disciplina_inválida);
float mg();
void registrado(in short nomseção; in ValorGrau grau)
raise (disciplina_inválida,grau_invalido);
};
Especificação OQL
select struct (sobrenome:s.nome.sobrenome,primeiro_nome:
s.nome.primeiro_nome)
from s in departamentocc.possui_especializações
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 = ‘Ciência da Computação’
order by sobrenome asc;
Linguagens Orientadas a Objeto
Para que estes conceitos básicos de orientação a objetos sejam usados
na prática em um sistemas de banco de dados, eles devem ser expressos
em alguma linguagem. Esta representação pode ser feita de duas formas:
Os conceitos são usados puramente como uma ferramenta de projeto
e são codificados, por exemplo, em um banco de dados relacional;
Os conceitos de orientação a objetos são incorporados em uma
linguagem que é usada para manipular o banco de dados.
Extensão de uma linguagem de manipulação de dados, como a SQL,
pela adição de tipos complexos e orientação a objetos.
Tomar uma linguagem de programação orientada a objeto e estendê-la
para tratar banco de dados (são as linguagens de programação
persistentes).
Linguagens de Programação Persistentes
Linguagens de bancos de dados diferem das linguagens de programação
tradicionais pelo fato de que elas manipulam diretamente os dados que
são persistentes, ou seja, dados que continuam a existir mesmo depois
que o programa que os criou tenha terminado.
Uma linguagem de programação persistente é uma linguagem de
programação estendida com estruturas para tratar dados persistentes.
Versões persistentes de linguagens de programação como C++ ou
Smalltalk estão entre as mais importantes. Elas permitem que o
programador manipule os dados do banco de dados sem passar por uma
linguagem de manipulação de dados como a SQL.
Essas linguagens são poderosas e é relativamente fácil cometer erros de
programação que danifiquem o banco de dados.
Persistência de Objetos
Persistência por classe: Declarar que uma classe é persistente. Assim, todos os
objetos da classe são, por default, persistentes. Os objetos de classes não
persistentes são transientes.
Persistência por criação: Um objeto é persistente ou transiente, dependendo de
como ele foi criado.
Persistência por marcação: Todos os objetos são criados como transientes mas,
se um objeto deve persistir alem da execução do programa, ele deve ser marcado
explicitamente como persistente antes do programa terminar.
Persistência por referência: Um ou mais objetos são explicitamente declarados
como objetos persistentes (raiz). Todos os outros objetos são persistentes se (e
somente se) forem referidos diretamente, ou indiretamente, a partir do objeto
persistente raiz.
Exemplos de SGBDOOs
Produto
Critério
Objectivity/DB
Objectivity, Inc.
www.poet.com
GemStone (*)
GemStone Systems
www.gemstone.com
Jasmine
Computer Associates
www.cai.com
Definição de dados pelo usuário
SIM
SIM
SIM
Herança Múltipla
SIM
Smalltalk - NÃO
Java - SIM
SIM
Valida cardinalidade entre objetos
SIM
NÃO
SIM (1)
Suporta transações longas
SIM
NÃO
NÃO
Linguagem de definição de atributos
C++, Java, Smalltalk, SQL
Java, Smalltalk
C
C++
ODQL
Java
Armazena os métodos dos objetos no BD
NÃO, os métodos são
armazenados no cliente.
SIM
SIM
Suporta ODL (Object Definition
Language)
SIM
SIM
NÃO
Suporta OQL (Object Query
Language)
SIM
NÃO
SIM
Suporta SQL
SIM
Smalltalk - SIM
Java - NÃO
SIM
via ODBC
Suporta consultas através de interface gráfica
SIM
SIM
SIM
Exemplos de SGBDOOs
Objectivity/DB
Integrado diretamente com a aplicação
APIs (Application Programming Interfaces):
Não é necessário um processo separado;
C++;
SmallTalk;
Java:
Integração com IDE Eclipse;
Ferramentas de Administração e Projeto.
Suporta SQL;
Suporta XML;
Exemplos de SGBDOOs
GemStone
Armazena métodos dos objetos no banco
APIs:
C++;
SmallTalk;
Java.
Suporta SQL apenas através da interface SmallTalk;
Suporta XML, com ambiente de gerenciamento otimizado;
Compatível com .Net.
Exemplos de SGBDOOs
Jasmine
Desenvolvido pela Computer Associates
APIs:
C++;
SmallTalk;
Java;
Oferece todas as funcionalidades de um BD relacional, além das
capacidades da OO;
Suporta OQL;
Suporta SQL;
Possui integração com ferramentas CASE.
Banco de Dados Relacional-Objeto:
Introdução
Modelos de dados relacionais-objeto estendem o modelo de dados relacional
fornecendo um tipo de sistema mais rico, incluindo orientação a objetos e
acrescentando estruturas especiais à linguagem de consultas relacionais, como a
SQL, para tratar os tipos de dados acrescentados.
É introduzido um sistema de tipos aninhados que permitem que os atributos de
tuplas sejam de tipos complexos.
Essas extensões tentam preservar os fundamentos relacionais – em particular, o
acesso declaratório ao dado – enquanto estendem o poder da modelagem.
Os sistemas de banco de dados relacionais-objeto fornecem um caminho de
migração conveniente para usuários de bancos de dados relacionais que desejam
usar características orientadas a objetos.
Relações Aninhadas
Primeira Forma Normal: exige que todos os atributos de uma relação tenham
domínios atômicos. Um domínio é atômico se os elementos do domínio são
considerados unidades indivisíveis.
O modelo relacional aninhado é uma extensão do modelo relacional em que os
domínios podem ser definidos como atômicos ou como relações. Então, o valor de
uma tupla sob um atributo pode ser uma relação, e relações podem ser
armazenadas dentro de relações.
Assim, um objeto complexo pode ser representado por uma única tupla de uma
relação aninhada.
Exemplo:
Considere um sistema de recuperação de documentos em que armazenamos, para
cada documento, as seguintes informações:
Título do documento;
Lista de autores;
Data de aquisição;
Lista de palavras-chave.
Uma relação para esta informação conterá domínios não-atômicos:
título
lista_autores
data
lista_palavra_chave
(dia, mês, ano)
Plano de vendas
{Smith, Jones}
(1,abril, 89)
{lucro, estratégia}
Relatório de status
{Jones, Frick}
(17, julho, 94)
{lucro, pessoal}
Relação documento não-1NFdoc.
Exemplo:
título
autor
dia
mês
ano
palavra_chave
Plano de vendas
Smith
1
abril
89
lucro
Plano de vendas
Jones
1
abril
89
lucro
Plano de vendas
Smith
1
abril
89
estratégia
Plano de vendas
Jones
1
abril
89
estratégia
Relatório de status
Jones
17
junho
94
lucro
Relatório de status
Frick
17
junho
94
lucro
Relatório de status
Jones
17
junho
94
pessoal
Relatório de status
Frick
17
junho
94
pessoal
Versão 1NF da relação documento não-1NF.
Tipos Complexos e Orientação a Objetos
Sistemas com tipos complexos e orientação a objetos permitem que os
conceitos de E-R, como atributos multivalorados, generalizações e
especializações, sejam representados diretamente sem uma tradução
complexa para o modelo relacional.
XSQL – linguagem de consulta que estende a SQL com características de
orientação a objetos.
Tipos Estruturados e Conjuntos
create type MinhaSeqüência char varying
create type MinhaData
(dia integer,
mês char(10),
ano integer)
create type Documento
( nome MinhaSeqüência,
lista_autor setof (MinhaSeqüência),
data MinhaData,
lista_palavra_chave setof (MinhaSeqüência))
create table doc of type Documento.
Tipos Estruturados e Conjuntos
Os tipos criados usando as declarações anteriores são gravados no esquema
banco de dados. Logo, outras declarações que acessam o banco de dados podem
fazer uso das definições desses tipos.
Usualmente, sistemas de tipos complexos aceitam outros tipos de conjuntos,
como matrizes e multiconjuntos.
Matriz_autor MinhaSeqüência[10]: matriz de nomes de autor. Pode-se
determinar quem é o primeiro autor, o segundo autor e assim por diante.
Imprime-execuções multiset(integer): poderia representar o número de cópias
de um documento impresso em cada execução de impressão do documento.
Exemplo:
Diagrama UML
Exemplo:
Esquema Relacional
Exemplo:
Esquema
Objeto-Relacional
Definição dos Tipos
Herança
A herança pode ser no nível de tipos ou no nível de tabelas.
Herança de tipos:
create type Pessoa
( nome MinhaSeqüência,
seguro_social integer)
create type Estudante
(graduação MinhaSeqüência,
departamento MinhaSeqüência)
under Pessoa
create type Professor
(salário integer,
departamento MinhaSeqüência)
under Pessoa
Tanto estudante quanto professor herdam os atributos de Pessoa – isto é,
nome e seguro_social. Estudante e Professor são chamados subtipos de
Pessoa e Pessoa é um supertipo de Estudante, assim como de Professor.
Herança
Suponha que queiramos armazenar informação sobre assistentes de ensino,
que são, simultaneamente, estudantes e professores, talvez até mesmo em
diferentes departamentos herança múltipla
create type 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 estão presentes em Estudante, assim como em Professor.
Seguro_social e nome são herdados de uma fonte comum, Pessoa. Então não há
conflito causado por herdá-los a partir de Estudante, assim como de Professor.
Departamento é definido separadamente em Estudante e Professor. De fato, um
assistente de ensino pode ser um estudante de um departamento e um professor em
outro departamento. Assim, deve-se usar o recurso de renomeação.
Herança
create type AssistentedeEnsino
under Estudante with (departamento as estudante_depto),
Professor with (departamento as professor_depto)
Em muitas linguagens de programação, uma entidade deve ter exatamente um
tipo mais específico, isto é, se uma entidade tem mais de um tipo, deve haver um
único tipo ao qual a entidade pertence e, esse único tipo deve ser um subtipo de
todos os tipos aos quais a entidade pertence.
Por exemplo, suponha que uma entidade seja do tipo Pessoa, assim como do tipo
Estudante. Então, o tipo mais específico da entidade é Estudante, já que Estudante
é um subtipo de Pessoa.
Entretanto, uma entidade não pode ser do tipo Estudante e do tipo Professor, a
menos que haja um tipo, como AssistentedeEnsino, que é um subtipo de Professor
e de Estudante.
Herança
A fim de que cada entidade tenha, exatamente, um tipo mais específico, teríamos
de criar um subtipo para cada combinação possível dos supertipos. Dentro de um
contexto universitário, por exemplo, poder-se-ia ter subtipos como:
EstudantenãoGraduadoEstrangeiro;
EstudanteGraduadoEstrangeiroJogadordeFutebol;
Etc...
Uma melhor abordagem ao contexto de sistemas de banco de dados é permitir a
um objeto ter múltiplos tipos, sem possuir um tipo mais específico.
Sistemas relacionais-objeto podem modelar tal característica pelo uso de herança
no nível de tabelas, e permitir que uma entidade exista em mais de uma tabela de
uma vez.
Herança
Herança de tabelas:
create table pessoas
(nome MinhaSeqüência,
seguro_social integer);
create table estudantes
(graduação_MinhaSeqüência,
departamento_Minhaseqüência)
under pessoas;
create table professores
(salário integer,
departamento MinhaSeqüência)
under pessoas;
Herança
As sub-tabelas estudantes e professores herdam todos os atributos da tabela
pessoas.
Não há necessidade de criar tabelas adicionais, como assistentesdeensino, que
herdam tanto de estudantes quanto de professores, a menos que hajam atributos
específicos para entidades que são tanto estudantes como professores.
Requisitos:
Cada tupla da supertabela pessoas pode corresponder a no máximo uma
tupla em cada uma das tabelas estudantes e professores, isto é, ter os
mesmos valores para todos os atributos herdados.
Cada tupla em estudantes e professores deve ter, exatamente, uma tupla
correspondente em pessoas, ou seja, com os mesmos valores para todos os
atributos herdados.
Herança
Sem a primeira condição, poderíamos ter duas tuplas em estudantes (ou
professores) que corresponderiam à mesma pessoa.
Sem a segunda condição, poderíamos ter uma tupla em estudantes ou em
professores que não corresponderia a qualquer tupla em pessoa, ou que
corresponderia a várias tuplas em pessoa.
As sub-tabelas podem ser armazenadas de uma maneira eficiente sem replicação
de todos os campos herdados. Atributos herdados, outros que não a chave
primária da supertabela, não necessitam ser armazenados e podem ser derivados
por meio de uma junção com a supertabela, baseada na chave primária.
Tipos Referência
Um atributo de um tipo pode ser uma referência a um objeto de um tipo
especificado.
Exemplo: referências a pessoas são do tipo ref(Pessoa). O campo lista_autor do
tipo Documento pode ser redefinido como:
lista_autor setof ( ref (Pessoa) )
que é um conjunto de referências a objetos Pessoa.
As tuplas de uma tabela também podem ter referências a elas. A chave primária
da tabela pode ser usada para criar essas referências.
Alternativamente, cada tupla de uma tabela pode ter um identificador de tupla
como um atributo implícito, e uma referência a uma tupla é simplesmente o
identificador de tupla.
Consultas com Tipos Complexos
A SQL foi estendida para manipular tipos complexos.
Exemplo: encontre o nome e o ano de publicação de cada documento.
select nome, data.ano
from doc
Observe que o campo ano do atributo composto data é referido pelo uso de uma
notação de ponto.
SQL: Atributos Relação-Valorados
A SQL estendida permite que uma expressão para uma relação apareça em
qualquer lugar em que o nome da relação possa aparecer, como em uma
condição from.
A habilidade de usar subexpressões livremente torna possível tirar vantagem da
estrutura de relações aninhadas, de diferentes maneiras.
Suponha a relação pdoc com o seguinte esquema:
create table pdoc
(nome MinhaSeqüência,
lista_autor setof (ref (pessoa)),
data MinhaData,
lista_palavra_chave setof (MinhaSeqüência))
SQL: Atributos Relação-Valorados
Encontre todos os documentos que têm a palavra “banco de dados” como
uma de suas palavras-chaves:
select nome
from pdoc
where “banco de dados” in lista_palavra_chave
Observe que foi usado o atributo relação_valorado lista_palavra_chave em
uma posição em que a SQL teria exigido uma subexpressão select-fromwhere.
SQL: Atributos Relação-Valorados
Suponha que queiramos uma relação contendo pares da forma
“nome_documento, nome_autor” para cada documento e cada autor do
documento.
select B.nome, Y.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 condição from, onde deveria ser usado uma relação.
Da mesma forma, pode-se usar as funções agregadas nestes campos:
select nome, count (lista_autor)
from pdoc
SQL: Expressões Path
Suponha a tabela definida como a seguir:
create table estudantes_phd
(orientador ref (pessoa) )
under pessoa
Encontre agora os nomes dos orientadores dos estudantes de doutorado.
select estudantes_phd.orientador.nome
from estudantes_phd
Já que estudante_phd.orientador é uma referência à tupla na tabela pessoa, o
atributo nome na consulta é o atributo nome da tupla da tabela pessoa;
As referências podem ser usadas para esconder operações de junção;
Sem o uso de referências, o campo orientador de estudantes_phd seria uma
chave estrangeira.
Aninhar e Desaninhar
A transformação de uma relação aninhada para uma relação na 1NF é
chamada de desaninhar.
A relação doc tem dois atributos (lista_autor e lista_palavra_chave) que são
relações aninhadas.
A conversão desta relação, com relações aninhadas, em uma relação básica
pode ser feita da seguinte forma:
select nome, A as autor, data.dia, data.mês, data.ano, k as palavra_chave
from doc as B, B.lista_autor as A, B.lista_palavra_chave as K.
Aninhar e Desaninhar
O processo inverso de transformação de uma relação 1 NF em uma
relação aninhada é chamado aninhar.
select título, set (autor) as lista_autor, (dia,mês,ano) as data, set
(palavra_chave) as lista_palavra_chave
from doc_flat
groupby título, data
Funções
Sistemas relacionais-objeto permitem que funções sejam definidas pelos
usuários.
Suponha que se desja uma função que, dado um documento, retorne a
contagem do número de autores.
create function total_autor(um_doc Documento)
returns integer as
select count (lista_autor)
from um_doc
Valores e Objetos complexos
Criação de uma tupla do tipo definido pela relação doc:
(“plano de vendas”, set (“Smith”, “Jones”), (1, “abril”, 89), set (“lucro”,
“estratégia”))
Inserindo essa tupla em uma relação:
insert into doc
values (“plano de vendas”, set (“Smith”, “Jones”), (1, “abril”, 89), set (“lucro”,
“estratégia”))
Benefícios do Modelo de Dados
Objeto-Relacional
Nova Funcionalidade
Aumenta indefinidamente o conjunto de tipos e funções fornecidas
pelo SGBD;
Desenvolvimento de aplicações simplificado
Reuso de código;
Consistência
Permite a definição de padrões, código reusável por todas as
aplicações.
Linguagem de Consultas 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 extensão da linguagem
SQL, utilizada para definição e manipulação de dados e consultas
BDOO versus BDRO
Extensões persistentes das linguagens de programação e sistemas
relacionais-objetos estão direcionados a diferentes mercados.
A natureza declaratória e o poder limitado da linguagem SQL (comparado
com uma linguagem de programação) fornecem boa proteção de dados
contra erros de programação e tornam otimizações de alto nível
relativamente fáceis.
Linguagens de programação persistentes destinam-se a aplicações que
tenham altas exigências de desempenho. Elas fornecem acesso com baixo
overhead ao dado persistente e eliminam a necessidade de tradução do
dado se os dados tiverem de ser manipulados usando uma linguagem de
programação.
BDR versus BDOO versus BDRO
Sistemas relacionais: tipos de dados simples, linguagens de consulta
poderosas e alta proteção.
Linguagem de programação simples baseada em BDOOs: tipos de
dados complexos, integração com linguagem de programação, alto
desempenho.
Sistemas relacionais-objeto: tipos de dados complexos, linguagens de
consultas poderosa, alta proteção.
Algumas Considerações...
SGBDOO - Principais Barreiras:
Culturais
“Pra que mexer em time que está ganhando?”;
Falta de familiaridade com OO;
MID (medo, incerteza e dúvida);
Grande parte dos SGBDOOs são desenvolvidos por empresas
pequenas;
Risco de ficar “sem suporte”;
Financeiras
Alto custo de migração;
Tempo para migração;
Treinamento de pessoal;
Necessidade de profissionais mais qualificados;
Algumas Considerações...
SGBDOOs:
União de duas tecnologias
Bancos de Dados;
Orientação a Objetos.
Objetivos semelhantes ao SGBDR:
Persistir dados;
Recuperação;
Comparação;
Tratamento / Gerenciamento.
Vantagem: Utilização da tecnologia OO.
Desvantagem: Ainda pouco popular.
Tendências
SGBDO-R (Objeto-relacional)
Ferramentas de Mapeamento Objeto-Relacional
Ex.: Hibernate (www.hibernate.org)
Camada que provê interface para a aplicação
Persistência de forma transparente
A aplicação trabalha como se estivesse conectada a um BDOO
Mapeamento Objeto-Relacional
Modelo em 3 Camadas: Separação clara entre
visualização, regra de negócio e dados.
Visualização:
Camada responsável pelos elementos de
Interação com o usuário;
Negócio: Camada responsável pela implementação da
regra de negócio;
Dados: Camada responsável pelo armazenamento e
integridade dos dados.
Mapeamento Objeto-Relacional
Os dados são acessados na camada de negócios.
O Mapeamento Objeto-Relacional é portanto, uma
ferramenta de auxílio.
Hibernate
Framework de mapeamento objeto
relacional para aplicações Java;
Open Source;
Suporte:
Coleções;
Relacionamento entre objetos;
Herança, polimorfismo e composições;
Linguagem de consulta própria: (HQL –
Hibernate Query Language).
Bibliografia Utilizada:
Sistemas de Banco de Dados. Abraham Silberchatz, Henry F. Korth e S.
Sudarshan. 4ª Edição. Editora Campus, 2006.
Introdução a Sistemas de Banco de Dados. C. J. Date. 7ª Edição, Editora
Campus, 2000.
Introdução a Banco de Dados (Apostila). Osvaldo Kotaro Takai, Isabel Cristina
Italiano, João Eduardo Ferreira. DCC-IME-USP, 2005.
Sistemas de Banco de Dados, Fundamentos e Aplicações. R Elsmari, S. B.
Navathe. Rio de Janeiro: Editora LTC, 2002.
Sistemas de Banco de Dados. Ramez Elsmari e Shamkant B. Navathe. 4ª
Edição. Editora Pearson Addison Wesley, 2005.
Banco de Dados: Fundamentos, Projeto e Implementação. (Cap. 5). David M. Kroenke,
6ª Edição. Editora LTC, 1999.
Uma Reflexão sobre Banco de Dados Orientados a Objetos. Boscarioli, et. al.
CONGED, 2006.
The Object-Oriented Database System Manifesto. Atkinson, et al. Agosto, 1989.
Fundamentals of Database Systems. Ramez Elsmari, Shamkant B. Navathe.
Addison Wesley Longman, 2000.