Bases de Dados - Dei-Isep

Nos anos 80 proliferam os SGBD relacionais na micro-informática.
O modelo relacional aplica-se muito bem a aplicações de informatização
tradicionais…
…mas…
As aplicações tornam-se cada vez mais complexas.
Surgem novos ‘tipos’ de informação que urge tratar: vídeo, audio, hipertexto,
imagem, etc.
…neste contexto…
Surge o paradigma object-oriented como forma de resolver estas questões.
O C++ consegue implantar-se com grande sucesso (entre outras linguagens de
programação object-oriented).
Surgem várias propostas para modelação object-oriented.
Surgem os SGBDOO.
A evolução dos SGBD neste contexto segue basicamente 2 direcções
1.
Acrescentar às linguagens de programação object-oriented características de
persistência.
Basicamente o que acontece é que se acrescenta persistência aos objectos criados
em linguagens de programação object-oriented.
Além da persistência muitos sistemas hoje em dia já implementam alguns dos
aspectos comuns em SGBD: linguagens de interrogação, noção de esquema de BD,
multi-utilizador e gestão de concorrência, noção de transacção, etc.
Uma das grandes vantagens desta abordagem é o facto de apenas existir um
sistema para programação e base de dados.
2.
Acrescentar ao modelo relacional características object-oriented.
A segunda abordagem consiste em acrescentar ao modelo relacional uma camada
superior object-oriented.
Isto permite uma mais fácil transição das bases de dados relacionais para as novas
bases de dados mas permanece normalmente a separação entre os dois mundos: o
programador da lógica da aplicação (numa linguagem tradicional qualquer - linguagem
host) e o desenhador da base de dados…
Existem algumas tentativas de tornar este aspecto invisível para o programador
através de extensões às linguagens de programação que façam a ‘tradução’ entre o
modelo de dados da aplicação e o modelo semi-relacional.
Áreas em desenvolvimento dos SGBDOO
Linguagens de consulta e acesso por navegação
Uso de inquéritos para aceder a um conjunto de objectos que obedeçam a um
determinado critério, e depois navegar pelas estruturas que compõem os objectos
encontrados
Optimização de respostas a consultas
Obtenção da informação no menor tempo possível
Objectos complexos
Representação de objectos que são constituídos à custa de outros, e/ou têm
referências para outros objectos
Abertura das linguagens de programação
Muitas BDOO estão ligadas a linguagens de programação específicas (C++,
Smalltalk, Lisp, etc) o que implica que o SGBD não seja um repositório de dados
independente…
Métodos armazenados nas BD
Algumas BDOO apenas armazenam a estrutura dos objectos (atributos ou dados)
Os métodos não são tratados pelo SGBD, sendo armazenados em ficheiros
‘normais’ externamente à base de dados.
Assim os métodos têm que ser ligados de forma ‘convencional’ ao programa
Num sistema que suporte o armazenamento de métodos é suficiente que o
utilizador apenas abra a base de dados, tendo disponível na altura os dados e os
respectivos métodos.
Áreas em desenvolvimento dos SGBDOO
Acesso à meta base de dados
Como meta base de dados entende-se a definição de classes, atributos e métodos
Grande parte das BDOO não trata a meta base de dados como objectos comuns
Isso impede que se consiga especificar consultas com o intuito de obter
informação sobre a estrutura das classes…
Definição dinâmica de classes
Este problema é muito semelhante ao do acesso à meta base de dados e tem a
ver com a possibilidade dinâmica de definição e alteração de classes
Regras de integridade
Normalmente os mecanismos de consistência das BDOO limitam-se aos
implementados nos próprios métodos
Outros tipos de controlo de consistência como ‘triggers’, constrangimentos ao nível
dos valores de atributos, etc, não estão disponíveis nas BDOO
Mecanismo de vistas
É pouco comum o suporte para vistas em BDOO
Existe uma opinião generalizada que o encapsulamento e a herança tornam a
definição de vista desnecessária.
Áreas em desenvolvimento dos SGBDOO
Integração com sistemas OOP
Apesar da maior parte das BDOO supostamente integrarem bastante bem com
linguagens de programação OO, essa integração ainda pode ser melhorada
permitindo, por exemplo, referências entre objectos persistentes e temporários
Ligação com SGBD não OO
No futuro próximo aumentará o uso de vários tipos de SGBD entre os quais as
BDOO
Para que se faça uso de todas as vantagens das BDOO é desejável que estas
interliguem com outros tipos de BD, em particular as BD relacionais
Para isso terão que existir desenvolvimentos ao nível de:
Suporte de interface SQL.
Execução de transacções distribuídas entre BDOO e BDR.
Etc.
Controlo de acessos
Este aspecto tem sido minimizado desde o inicio do desenvolvimento das BDOO
É necessário que se possam definir direitos ao nível dos objectos e das classes.
Só desta forma poderão as BDOO vir a ocupar lugar no desenvolvimento de
aplicações tradicionais de informatização de negócios
!"
#! $ $
OQL pretende definir uma extensão à linguagem C++ para
inquéritos a objectos, com os seguintes objectivos:
Modelo de dados (de objectos) = Sistema de tipos da linguagem
Verificação de tipos
Inquéritos
Separação entre tipos e extensões de tipos
As extensões de tipos (ex: Set, Bag, Array, List, etc.) podem ser colecções
explícitas de objectos de um tipo ou colecções criadas e mantidas pelo
programador
Possibilidade de combinar instruções de inquérito e de programação
Abstracção de dados
Sintaxe e semântica uniforme entre linguagem de inquérito e instruções da
linguagem
_______________________________________________________________
Nota:
O OQL é baseado em investigação da ARPA (Advanced Research Projects Agency)
U.S. Army Reseach Laboratory
Referência: Modern Database Systems, Won Lim, Addison-Wesley
!"
#! $ $
O modelo de dados (C++)
Uma classe é um tipo de dado definido pelo utilizador que
determina a estrutura e comportamento das instâncias
(objectos) dessa classe
Um tipo de dados abstracto é simulado por uma classe
que tem um conjunto de funções (métodos) públicos e não
tem atributos públicos
Sintaxe de um inquérito em OQL
<resultado> =
SELECT <objectos>
FROM <variável de intervalo> IN <colecção>
WHERE <predicado> ;
%
!"
#! $ $
class Person{
public:
Person(Name&, Address&, Birthdate&);
int age();
String sex();
Name name();
Address home_address();
virtual home_address();
void set_name( Name& );
void set_address( Address& );
…};
class Physician : public Person{
public:
String speciality();
Address office_address();
String phone();
virtual void print();
…};
class Medical_Record{
public: int patient_no();
Date date();
String diagnosis();
List< Lab_Test > lab_tests();
List< X_Ray > x_ray_tests();
…};
class Patient : public Person{
public:
int indent();
Physician family_doctor();
Set< Medical_Record > records;
virtual void print();
…};
&
!"
#! $ $
Devolver todos os doentes que são tratados pelo
Dr. J. Smith
Set <Patient> result;
result =
SELECT p
FROM Patient p IN Patients
WHERE p.family_doctor().name() == "J. Smith";
ou
result =
SELECT p
FROM Patient *p IN Patients
WHERE p->family_doctor().name() == "J. Smith";
!"
#! $ $
Devolver os doentes masculinos que foram
diagnosticados com gripe antes de 5 de Junho de
1998
Neste exemplo é possível observar a utilização de
colecções como membros de um objecto
Set <Patient> result;
result =
SELECT *
FROM Patient p IN Patients
WHERE p.sex() == “male”
&& EXISTS(SELECT r
FROM Medical_Record r IN p.records()
WHERE r.date() < Date(05,06,1998)
&& r.diagnosis() == "flu");
!"
#! $ $
Os tipos de resultados dos inquéritos em OQL
podem ser
1.
2.
3.
2.
O mesmo que o tipo de objectos da colecção que se está
a pesquisar (exemplos nos slides anteriores)
O tipo de uma classe pai do tipo de objecto da classe a
inquirir
Um novo tipo
Exemplo da obtenção de um tipo (através de cast)
Set <Person> result;
result =
SELECT (Person) p
FROM Patient p IN Patients
WHERE p.family_doctor().name() == "J. Smith";
!"
3.
#! $ $
Exemplo da obtenção de tipos sem relação directa com a
colecção
Projecção
class New_Object
{ public:
New_Object( Name&, int& );
…};
Set <New_Object> result;
result =
SELECT New_Object( p.name(), p.age() )
FROM Patient p IN Patients
WHERE p.age() < 10;
!"
3.
#! $ $
Exemplo da obtenção de tipos sem relação directa com a
colecção
Join
class Dr_Patient
{ public:
Dr_Patient( Physician&, Patient& );
…};
Set <Dr_Patient> result;
result =
SELECT Dr_Patient( d, p )
FROM Physician d IN Physicians, Patient p IN Patients
WHERE d.office_address().street == p.home_address().street()
&& d.office_address().city() == p.home_address().city();
!"
3.
#! $ $
Exemplo da obtenção de tipos sem relação directa com a
colecção
User-defined functions
Set <Patient> result;
result =
SELECT p
FROM Patient p IN Patients
WHERE
EXISTS(SELECT *
FROM Medical_Record r IN p.records()
WHERE EXISTS(SELECT *
FROM X_Ray x IN r.x_ray_tests()
WHERE x_ray_match(x.picture(), pattern)));
!"
#! $ $
Suporte para alteração de dados no OQL (UPDATE, INSERT e DELETE)
Alterar o número de telefone de todos os médicos cujo consultório se situa em 453
First St., Dallas, Texas para (214) 444-9999
UPDATE SET p.set_phone("214-444-9999")
FROM Physician p IN Physicians
WHERE p.address().street() == "453 First St.“
&& p.address().city() == "Dallas" && p.address().state() == "Texas";
Apagar todos os pacientes do Dr. Smith da colecção de pacientes.
DELETE FROM Patient p IN Patients
WHERE p.family_doctor().name() == "J. Smith";
Transferir todos os pacientes do Dr. Smith na colecção de pacientes que sofram de
tuberculose para uma nova colecção designada Tuberculosis_Patients
Set<Patient> Tuberculosis_Patients;
INSERT INTO Tuberculosis_Patients
SELECT * FROM Patient p IN Patients
WHERE p.family_doctor().name() == "J. Smith“
&& EXISTS( SELECT r FROM Medical_Record r IN p.records()
WHERE r.diagnosis() == "Tuberculosis" );
Exemplo da construção de um modelo OO
Considere-se uma empresa que aluga casas de
férias, de dois tipos: Campo e Praia. A base é o
arrendamento semanal.
Há quatro visões que ilustram o problema:
1.
2.
3.
4.
arrendatários – grupos de pessoas que procuram casa
para alugar
acordo de arrendamento
casa de campo
casa de praia
Exemplo da construção de um modelo OO
Considere-se uma empresa que aluga casas de férias, de dois tipos:
Campo e Praia. A base é o arrendamento semanal.
Há quatro visões que ilustram o problema:
1.
2.
3.
4.
Morada
arrendatários – grupos de pessoas que procuram casa para alugar
acordo de arrendamento
Nome
Morada
Telefone
Max Aluguer
casa de campo
Asdrubal Rua XXX 222333444
200,00
casa de praia
João
Rua YYY 212121212
300,00
Cod_Postal
Nº Quartos
Aluguer
Distância à Praia
PA
2200-000
3
500,00
2 Km
PB
3300-100
4
400,00
500 m
Cod_Postal
Nº Quartos
Aluguer
CA
2340-222
3
300,00
Sim
CB
4567-654
3
250,00
Não
Morada
1
3
4
Prática de Ski
%
Arrendatário
CASAS
Morada
Cod_Postal
Nº_Quartos
Aluguer
Nome
Morada
Telefone
Aluguer-Max
Mostrar aluguer
Acordo
arrendamento
Data_Início
Data_Fim
Aluguer
Aluguer casa
PRAIA
CAMPO
Dist_Praia
Prática_Ski
Computar total
do aluguer
&
AGREGAÇÃO
é o relacionamento “parte-todo” ou
“uma parte de”, na qual os objectos que
representam os componentes de alguma
coisa são associados a um objecto que
representa a estrutura inteira.
CLIENTE
ENCOMENDA
Nº_Encomenda
Data
Data_Entrega
símbolo de
agregação
ARTIGO
MÉTODOS
Os métodos só podem processar dados dentro da classe de objectos na qual
estão definidos.
Podem receber pedidos de métodos de outra classe, mas não podem processar
dados noutra classe de objectos.
Tipos de métodos
Métodos de manutenção
Permitem a manutenção das ocorrências de cada objecto e de cada estrutura de
classificação (generalização ou agregação): adicionar, alterar, remover,
seleccionar.
Estão incluídos em todos os objectos e têm funções como: controlo da
integridade, ligação de ocorrências, gestão de respostas.
Métodos de cálculo
Permitem cálculos sobre valores encapsulados no mesmo objecto.
Métodos de monitorização
Por exemplo, num sistema de stock o alerta de ter atingido o stock mínimo
MENSAGENS
Existe um método que é activado quando uma mensagem é enviada de uma
classe de objectos (endereçador) para outra classe de objectos (receptor)
A ligação de mensagens é um caminho de comunicação entre o
endereçador e o receptor.
1. um endereçador (classe de objectos) envia a mensagem
2. um receptor (classe de objectos) recebe a mensagem, e realiza um ou
mais métodos
3. o receptor retorna a resposta ao endereçador.
Completemos, agora, o nosso modelo
1
2
UTILIZADOR
3
CLIENTE
5
ENCOMENDA
4
4
ARTIGO - expedir
5
CLIENTE –calcular total (crédito excedido)
1
CLIENTE – mostrar informação
2
CLIENTE – adicionar ocorrência
3
ENCOMENDA – adicionar
encomenda
ARTIGO
'
Object/Relational mapping é o processo de conversão entre objectos e
o modelo relacional. Basicamente, para aproveitar as vantagens
desenvolvimento orientado a objectos, e guardar a informação
persistente nas bases dados relacionais, pois ainda são as mais
eficientes e fiáveis para grandes volumes de dados.
Os objectos de negócio isolam totalmente as regras de negócio, os
problemas de guardar os dados e os problemas de concorrência, são
todos encapsulados. Como os clientes só interagem com os objectos
de negócio, as alterações podem ser feitas na BD sem alterar código
no Cliente.
Os objectos de negócio podem ser implementados de várias modos,
desde uma configuração Cliente/Servidor a N-Tier.
As aplicações construídas com objectos têm uma manutenção mais
fácil. A arquitectura separa a responsabilidade em diferentes camadas
(ex. interface, objectos de negócio, e camada de dados)
Os objectos podem ser facilmente reutilizados.
As bases dados relacionais continuam a ser as melhores para
tratamento de grandes quantidades de dados.
'
Conversão de uma classe simples
Uma classe simples, é fácil de converter para
uma base de dados relacional, pois basta criar
uma tabela que tenha todos os atributos
persistentes dessa classe.
CCliente
Codigo : int
Nome : CString
Morada : CString
Telefone : CString
EMail : CString
'
Conversão da herança e herança múltipla
As três técnicas mais comuns para converter herança
múltipla em RDMBS são a conversão vertical, horizontal e
a filtrada. Para mostrar estas técnicas foi seguido o
seguinte exemplo de herança representado em UML
Pessoa
Nome : CString
Morada : CString
CProfessor
Vencimento : float
CAluno
AnoMatricula : int
'
Conversão vertical
Na conversão vertical cada classe é convertida
numa tabela, e as classes descendentes terão
que referenciar de alguma maneira a classe
ascendente (ex. através de uma chave). Sempre
que seja necessário informação , é preciso
efectuar uma operação de JOIN para aceder aos
dados.
'
Conversão horizontal
Na conversão horizontal, cada classe do nível
mais baixo da herança é convertida numa tabela.
Nessa tabela são também incluídos todos os
campos herdados do(s) pai(s).
%
'
Conversão filtrada
Na conversão filtrada todas as classes são
convertidas numa única tabela, portanto a tabela
terá que ter todos os atributos de todas as
classes, e será acrescentado um campo que
permitirá distinguir as subclasses.
&
'
Conversão de relações
O seguinte diagrama de classes representa três
classes simplificadas e as relações entre elas :
CEncomenda
Data : CString
Vendedor : CString
As classes podem ser convertidas
para uma base dados relacional,
dando origem a seguinte estrutura:
CLinhas
Preco : float
Quant : float
CCliente
Nome : CString
(
)
SGBDOO (OODBMS)
Os SGBDOO são o resultado da integração da tecnologia de base de dados com o paradigma
object-oriented
Desde finais da década de 80 que surgiram SGBDOO, tendo em poucos anos sido
desenvolvidas 3 gerações destes produtos.
A primeira geração data de 1986 com a introdução no mercado do G-Base, da empresa
francesa Graphael, seguido do GemStone da Servio Corporation em 1987 e do VBase da
Ontologic em 1988. O objectivo destes SGBDOO eram dar persistência aos objectos das
LPOO. Eram utilizados nos departamentos de investigação de grandes empresas.
A segunda geração começa em 1989 com o produto ONTOS da Ontologic, seguido de outros
como o ObbjectStore, o Objectivity/DB, etc. Estes produtos têm já usavam a arquitectura
cliente/servidor e tinham uma plataforma comum: C++, XWindows e Unix.
O Itasca foi o primeiro produto da terceira geração e surgiu em 1990.Era uma versão
comercial do Orion que foi um projecto de investigação do MCC (Microelectronics and
Computer Corporation). Outros produtos desta geração são o O2 e o Zeitgest.
(
)
Os produtos da terceira geração tinham características mais avançadas e tinham
linguagens de definição e manipulação de dados que eram orientadas para objectos e
computacionalmente completas.
Os SGBDOO mais importantes do mercado podem ser assim ordenados:
ORION/Itasca (nome da versão comercial a partir de 1990) da MCC
O2 (1986-1991) do Consorcio Altair
GemStone (1987) é o produto comercial mais antigo ainda hoje existente, em duas versões
GemStone/s (versão smalltalk) e GemStone/J (versão Java)
IRIS/OpenDB (1989) protótipo de investigação da HP
VBase/ONTOS (1988) de linguagem proprietária passou a C++.É totalmente distribuído.
ObjectStore (1989) tem suporte para documentos XML
POET (1999) – C++ e Java, suporta documentos XML e SGML.
Jasmine da CA
(
)
OMG: consorcio Object Management Group
Sun Microsystems, Borland, AT&T/NCR, HP, Hitachi, Computer Associates, Unisys e
Oracle
Criação de standards de facto, promoção de técnicas OO, …
ODMG, 2001 (Object Data Management Group)
ODMG -Object Database Management Group é um consórcio industrial que pretende definir
standards para bases de dados orientadas para objectos
Standards de linguagens de programação persistentes
Inclui standards para C++, Smalltalk e Java
ODMG-93
ODMG-2.0 (1997) e 3.0 (2000 - extensão do 2.0 para Java)
O standard ODMG C++ não altera a linguagem C++
Fornece funcionalidade para persistência via template classes e class libraries
(
)
ODMG definiu uma arquitectura de standards, com os seguintes componentes:
- modelo de objectos (ODM – Object Data Model)
- uma linguagem de definição de objectos (ODL –Object Definition Language) que
permite definir o modelo de objectos. Permite a definição de objectos complexos, de
relações entre esses objectos e dos métodos associados.
- uma linguagem de consulta (OQL – Object Query Language) que permite consultar os
objectos de estruturas complexas, de enviar mensagens a objectos, efectuar junções e
outras operações de tipo associativo. A sua sintaxe é do tipo SQL.
- ligações com LP OO via C++, Java e Smalltalk. A norma ODMG não definiu uma
linguagem de manipulação de objectos (OML – Object Manipulation Language), antes
propôs mapeamentos para as linguagens de programção OO mais divulgadas.
(
)
ODM define a base da norma ODMG em termos de, quais as características dos objectos
que podem ser armazenados numa BDOO, como é que eles se relacionam , como podem
ser manipulados, etc.
O modelo de dados é o do C++
Uma classe é um tipo de dado definido pelo utilizador que determina a estrutura e
comportamento das instâncias (objectos) dessa classe
Um tipo de dados abstracto é simulado por uma classe que tem um conjunto de
funções (métodos) públicos e não tem atributos pub
ODL é uma linguagem de especificação utilizada para definir interfaces para tipos de
objectos que aderem ao modelo de objectos da ODMG.
O principal objectivo da ODL é facilitar a portabilidade de esquemas de bases de dados
entre SGBDOO que adiram à ODL.
A ODL permite também uma maior facilidade de interligação entre diferentes
fornecedores de soluções nesta área.
(
)
Os tipos de objectos da ODL podem ser implementados numa grande variedade de linguagens
de programação.
A sintaxe da ODL estende a sintaxe da IDL (a linguagem de definição de interfaces do
CORBA).
A sintaxe da ODL é bastante próxima da sintaxe usada na definição de classes em C++.
Diversos princípios guiaram o desenvolvimento da ODL:
· a ODL deve suportar todas as construções semânticas do modelo de objectos da ODMG
· a ODL não deve ser uma linguagem de programação completa, deve ser fundamentalmente
uma linguagem para especificação de assinaturas de interfaces
· a ODL deve ser independente da linguagem de programação
· a ODL deve ser compatível com a linguagem de definição de interfaces da OMG (IDL)
· a ODL deve ser extensível, não apenas tendo em vista futuras funcionalidades, mas também
optimizações físicas
· a ODL deve ser prática, fornecendo valor acrescentado para os desenvolvedores de
aplicações, e ao mesmo tempo ser suportada pelos fornecedores de SGBDOO num intervalo
de tempo razoável após a publicação da sua especificação
(
)
Um ficheiro ODL pode conter uma ou mais especificações.
Essas especificações podem definir:
· Interfaces
· Constantes
· Tipos
· Módulos
OQL é uma linguagem associativa de consulta do ODMG
inspirada em SQL
originária do Software O2
OQL baseia-se no mesmo sistema de tipos de uma LP OO
Consultas podem ser embutidas dentro da LP OO
Consultas podem chamar operações programadas na LP OO
(
)
Objectos consultados:
Objectos com nomes
Extensões de classes (extent)
Linguagem funcional com expressões aninhadas
OQL não é uma linguagem completa para desenvolvimento de aplicações
OQL não possui comandos de alteração
alterações são feitas com o uso de operações definidas na LP OO
OQL é baseada em SQL 92, com extensões para OO
Objectos complexos
Identidade de objectos
Expressões de caminho
Polimorfismo
Chamada de operações
Late-binding
%
(
)
VANTAGENS DAS BDOO
Dados não homogéneos – permite representar dados com formatos variáveis. O modelo
relacional exigia homogeneidade dos tuplos e a atomicidade dos seua atributos.
Objectos complexos – utilizando os conceitos de herança e agregação dão origem a um
conjunto de tipos de dados praticamente ilimitado
Poder de modelação – permite a construção de modelos semânticamente mais ricos que
os modelos convencionais, atrvés de uma modelação mais natural e intuitiva.
Comportamento bem definido – o objecto apenas reage a determinadas mensagens e
para cada uma reage de forma bem determinada
Eliminação do ‘impedance mismatch’ – trabalha-se só com uma única linguagem
comum às bases de dados e ao nível aplicacional
Versões de objectos – para cada objecto podem ser mantidos pelo sistema as suas versões
anteriores, e mesmo versões alternativas do mesmo objecto.
Alterações bem localizadas – alterações à ‘caixa preta’ não afectam o resto do sistema
Reutilização do software – os objectos armazenados na BD são partilhados pelo nível
aplicacional.O código correspondente aos métodos definidos para as várias classes
persistentes é também partilhado, resultando numa efectiva reutilização do software.
&
(
)
DIFICULDADES DA TECNOLOGIA OO
Segurança – quem pode aceder, a que objectos, e para fazer o quê. O conceito de herança
ao longo de uma hierarquia de classe torna difícil a segurança de acessos a cada utilizador.
Recuperação/tolerância a falhas – é mais complexa que nas BD convencionais em que
as transacções são curtas e atómicas.
Controlo da concorrência – devido ao conceito de herança quando uma transacção acede
a instâncias de uma dada classe, qualquer transacção deve ser impedida de modificar as
super-classes e o mesmo às sub-classes
Interface com o utilizador - pelo facto de todas as operações terem de estar prédefinidas e as referências entre os objectos se fazerem por meio de apontadores, estamos
perante um modelo com características navegacionais, o que vem colocar algumas
limitações ao nível da interface com os utilizadores.