t aula 11 - ipp.ptncastro/teoricas/taula11.pdf · 4. casa de praia joão rua yyy 212121212 300,00...
Post on 27-Jan-2021
4 Views
Preview:
TRANSCRIPT
-
��������� ���� �
��������������
��������������������������
-
��������� ���� �
���������������������������� ������� 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 LaboratoryReferê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 =SELECT FROM IN WHERE ;
-
��������� ���� &
� !�" ������ ���#!��$��$�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 result;result =
SELECT pFROM Patient p IN PatientsWHERE p.family_doctor().name() == "J. Smith";
ouresult =
SELECT pFROM Patient *p IN PatientsWHERE 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 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. O mesmo que o tipo de objectos da colecção que se estáa pesquisar (exemplos nos slides anteriores)
2. O tipo de uma classe pai do tipo de objecto da classe a inquirir
3. Um novo tipo
2. Exemplo da obtenção de um tipo (através de cast)Set result;result =
SELECT (Person) pFROM 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çãoclass New_Object{ public:New_Object( Name&, int& );
…};
Set 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
� Joinclass Dr_Patient{ public:Dr_Patient( Physician&, Patient& );
…};
Set 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 result;result =
SELECT pFROM Patient p IN Patients
WHEREEXISTS(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-9999UPDATE SET p.set_phone("214-444-9999")
FROM Physician p IN PhysiciansWHERE 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_PatientsSet Tuberculosis_Patients;INSERT INTO Tuberculosis_PatientsSELECT * FROM Patient p IN PatientsWHERE 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. arrendatários – grupos de pessoas que procuram casa
para alugar2. acordo de arrendamento3. casa de campo4. 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. arrendatários – grupos de pessoas que procuram casa para alugar2. acordo de arrendamento3. casa de campo4. casa de praia 300,00�212121212Rua YYYJoão
200,00�222333444Rua XXXAsdrubal
Max AluguerTelefoneMoradaNome
4567-654
2340-222
Cod_Postal
Não250,00�3CB
Sim300,00�3CA
Prática de SkiAluguerNº QuartosMorada
3300-100
2200-000
Cod_Postal
500 m 400,00�4PB
2 Km500,00�3PA
Distância à PraiaAluguerNº QuartosMorada
134
-
��������� ���� �&
���������������������
NomeMoradaTelefoneAluguer-Max
Arrendatário
Mostrar aluguer
Data_InícioData_FimAluguer
Acordoarrendamento
Computar totaldo aluguer
MoradaCod_PostalNº_QuartosAluguer
Prática_SkiDist_Praia
CASAS
PRAIA CAMPO
Aluguer casa
-
��������� ���� �
���������������������
� 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.
Nº_EncomendaDataData_Entrega
ENCOMENDA
CLIENTE ARTIGO
símbolo deagregação
-
��������� ���� ��
���������������������
� 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 mensagem2. um receptor (classe de objectos) recebe a mensagem, e realiza um ou mais métodos3. o receptor retorna a resposta ao endereçador.
-
��������� ���� ��
���������������������
Completemos, agora, o nosso modelo
CLIENTE – mostrar informação
CLIENTE – adicionar ocorrência
ENCOMENDA – adicionarencomenda
UTILIZADOR
CLIENTE ENCOMENDA ARTIGO
1 2
5 4
3
4
5
1
2
3
ARTIGO - expedir
CLIENTE –calcular total (crédito excedido)
-
��������� ���� ��
�'�������������������������
� 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.
CClienteCodigo : intNome : CStringMorada : CStringTelefone : CStringEMail : 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 :
CLinhasPreco : floatQuant : float
CEncomendaData : CStringVendedor : CString
CClienteNome : CString
As classes podem ser convertidas para uma base dados relacional, dando origem a seguinte estrutura:
-
��������� ���� ��
(��������)��������������������
� SGBDOO (OODBMS)Os SGBDOO são o resultado da integração da tecnologia de base de dados com o paradigma object-orientedDesde 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 andComputer 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 classeUm 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 O2OQL 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 aninhadasOQL não é uma linguagem completa para desenvolvimento de aplicaçõesOQL não possui comandos de alteração� alterações são feitas com o uso de operações definidas na LP OOOQL é 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.
top related