1 ADMINISTRAÇÃO DE BANCO DE DADOS

Dados são usados por diferentes pessoas em diferentes departamentos por diferentes razões.
Entretanto, administração de dados deve prover o conceito de dados compartilhados. Usado
propriamente, o SGBD facilita:
1. Interpretação e apresentação de dados em formatos úteis, pela transformação de dados
brutos em informação.
2. Distribuição de dados e informação para a pessoa certa na hora certa.
3. Preservação do dado e monitoramento do uso do dado por períodos de tempo adequados.
4. Controle sobre duplicação e uso de dados, internamente e externamente.
Qualquer que seja o tipo da organização, o banco de dados deve suportar todas as operações
e todos os níveis de tomada de decisão administrativa. De fato, podemos argumentar o seguinte: O
papel principal do BD é dar suporte às tomada de decisão administrativa em todos os níveis da
organização.
A estrutura administrativa de uma organização pode ser dividida em três níveis: principal,
central e operacional. O nível da administração principal toma decisões estratégicas, o nível central
decisões táticas e o nível operacional toma decisões operacionais diariamente, como ilustra a figura
1.1.
O SGBD deve prover ferramentas que dêem a cada nível administrativo uma visão diferente
do dado e deve servir de suporte ao nível de tomada de decisão requerido. Usando esta estrutura,
podemos melhor ajustar o papel designado ao banco de dados em relação as atividades típicas de
cada nível administrativo.
• Nível Principal . O diretor executivo da companhia geralmente foca a formulação de
decisões estratégicas sobre o posicionamento de mercado da companhia, a natureza geral
das operações da companhia, a política geral interna e externa da companhia e outros
usos óbvios que formam o futuro da companhia. Neste nível o BD deve ser capaz de:
1. Prover informação necessária para tomada de decisão estratégica, planejamento
estratégico, formulação de políticas e definições de metas.
2. Prover acesso a dados internos e externos para identificar possibilidades de
crescimento e desenhar a direção deste crescimento.
3. Prover estrutura para definição e obrigação de políticas organizacionais.
4. Melhorar a possibilidade de um retorno positivo no investimento da cia pela pesquisa
de novos meios de reduzir os custos e/ou aumentar a produtividade.
5. Prover feedback para monitorar se a cia está atingindo os objetivos.
• nível intermediário. Tipicamente formula os planos operacionais para possibilitar as
metas do nível principal. Supervisiona, monitora e provê o controle geral das operações
da cia. Também escalona recursos com propósitos a curto e médio prazo. Neste nível o
BD deve ser capaz de:
1. Distribuir os dados necessários para as decisões táticas e planejamento.
2. Monitorar e controlar a alocação e o uso de recursos.
3. Prover estrutura para obrigar e assegurar a segurança e privacidade dos dados no BD.
Segurança significa proteger os dados de uso acidental ou intencional por usuários

1
 não autorizados. Privacidade trata os direitos das pessoas e organização para
determinar quem, o que, quando, onde e como os dados serão usados.

Nível Administrativo Tipo de Decisão

Estratégica
Principal

Central
Tática
SGBD
Operacional
Operacional

Banco de Dados

Figura 1.1 Níveis de tomada de decisão gerencial dentro de uma organização

• Nível Operacional. Os gerentes operacionais tratam as operações diárias da companhia.

A maior parte dos sistemas de informação desenvolvidos suportam esta tarefa. O BD
deve então:
1. Representar e suportar as operações da companhia tão corretamente quanto possível.
O modelo de dados deve ser flexível a fim de incorporar todas as representações
requeridas e os dados futuramente esperados.
2. Produzir resultados de consultas com nível de performance específicos. Respostas
rápidas para um grande número de transações no nível operacional.
3. Aumentar a capacidade operacional da cia a curto prazo.
O objetivo principal de um BD é prover um caminho para o fluxo de informação na
companhia. Um dos tópicos mais quentes no Gerenciamento de Escritórios é o ambiente de
escritório sem papel, no qual todos os dados são armazenados e gerenciados por um sistema de BD
capaz de gerenciar diferentes tipos de dados tais como voz, imagem, e outros.
As companhias de BD são também conhecidas como as corporações ou empresas de BD. As
empresas de BD devem ser definidas como a representação de dados das companhias que provêem
suporte para todas as operações presentes e futuras.

1.1 INTRODUÇÃO DE UM SGBD: CONSIDERAÇÕES ESPECIAIS

Ter um SGBD automatizado não garante que os dados serão utilizados corretamente para
prover as melhores soluções requeridas pelos administradores. Um SGBD é somente uma

2
ferramenta para gerenciar dados e deve ser utilizada efetivamente a fim de produzir os resultados
desejados. A solução para os problemas da companhia não é a mera existências de um sistema de
computador ou seus BD, mas certamente seu uso e gerenciamento efetivo.
A introdução de um BD representa uma grande mudança e desafio; é como ter um profundo
impacto sobre a organização. O impacto pode ser negativo ou positivo, depende de como o SGBD
introduzido é administrado. Por exemplo, um ponto chave é o SGBD deve se adaptar a organização
e não a organização se adaptar ao SGBD. A introdução de um SGBD é um processo que inclui três
aspectos importantes:
1. Tecnológico: SGBD como software e hardware. Inclui a seleção, instalação e
monitoramento do SGBD para que ele possa ser eficiente no armazenamento, acesso e
segurança dos dados.
2. Gerencial: Funções Administrativas. Somente o SGBD não garante o sucesso da
empresa é necessário elaborar cuidadosamente os projetos para assegurar o sucesso do
banco de dados. É necessário criar uma estrutura de pessoas responsáveis pela
administração do SGBD.
3. Cultural: Resistências corporativa às mudanças. O choque cultural causado pela
introdução de um SGBD deve ser avaliado cuidadosamente. A existência de SGBD
poderá causa efeitos nas pessoas, funções e interações. Normalmente as pessoas devem
ser treinadas, novas funções devem ser alocadas para as pessoas e o desempenho das
pessoas deve ser avaliado para o novo padrão.

1.2 A EVOLUÇÃO DA FUNÇÃO DE ADMINISTRAÇÃO DE BD

A administração de dados tem suas raízes no velho e descentralizado mundo de sistemas de

arquivos sem BD. Cada departamento era o dono dos seus próprios conjuntos de arquivos.
Consequentemente, os especialistas em processamento de dados começou a trabalhar dentro dos
departamentos. A figura 1.2 ilustra a estrutura organizacional resultante.
O custo dos dados e a duplicação de gerenciamento levou a necessidade de centralização da
função de administração de dados conhecida como processamento eletrônico de dados ou
Departamento de Processamento de Dados (DPD)

Departamento A Departamento B

Gerente Gerente

Administrativo Processamento de Administrativo Processamento de

dados dados

Arquivos Arquivos

3
 Figura 1.2 O especialista de processamento de dados nos departamentos

A chegada do SGBD e sua visão compartilhada dos dados produziu um novo nível de
sofisticação de gerenciamento e induziu que os DPD’s evoluíssem Departamento de Sistemas de
Informações (DSI), a figura 1.3 mostra com foi funcionalmente dividido este departamento. Este
departamento possuía as seguintes responsabilidades:
1. Auxiliar o usuário final no gerenciamento de seus dados.
2. Gerenciar de forma integrada os dados do usuário final na diferentes aplicações.

Sistemas de Informação

Desenvolvimento de Aplicação Operações de BD

Figura 1.3 A organização interna do DSI

Com o crescimento de aplicações de BD e o aumento de complexidade dos trabalhos, surgiu

a função de Administração da BD. A pessoal responsável pelo controle do banco de dados
centralizado e compartilhado é o Administrador de Banco de Dados (DBA). O tamanho e o papel da
função de DBA vária de empresa para empresa, assim como a localização dentro da estrutura
organizacional. No organograma da empresa, a função de DBA poderia ser definida como uma
assessoria ou um elemento em um nível do organograma. Colocar a função de DBA como assessor
freqüentemente cria um ambiente de consultoria, no qual o DBA tem a capacidade de planejar
estratégia de administração de dados, porém não tem a autoridade de força-la ou resolver possíveis
conflitos.
A função de DBA como um nível no organograma (autoritário) tem a
responsabilidade e autoridade para planejar, definir, implementar, e força política, padrões e
procedimentos usados na atividade de administração de dados. Na figura 5.4 é ilustrado as duas
formas apresentadas anteriormente.

Posição Autoritária

Sistemas de Informação

Desenvolvimento de Aplicação Administração de BD Operações de BD

4
 Posição de consultor

Sistemas de Informação

Administração de BD

Desenvolvimento de Aplicação Operações de BD

Figura 1.4 A localização da função de DBA

A decisão quanto a localização das funções de DBA dependerá do estilo de gerenciamento

da companhia e de fatores tais como o tamanho e complexidade das operações e da distribuição
geográfica da companhia. Estes fatores, também, auxiliam da determinação da estrutura interna da
área de DBA. Não existe uma estrutura organizacional padrão, porém alguns fatores podem
influênciar na estrutura organizacional da empresa. Tais como:
• O desenvolvimento de banco de dados distribuídos pode forçar a organização a
descentralizar aspectos funcionais da administração de dados. O banco de dados
distribuído requer um DBA central que defina e delegue responsabilidades aos DBA’s
locais, conseqüentemente, impõe ao DBA central novas e complexas atividades de
coordenação.
• A introdução de SGBDOO, normalmente, adiciona nova maneira de modelagem de dados
e atividades, assim expande e diversifica os serviços do DBA.
• A rápida expansão dos microcomputadores e redes locais (LAN) tendem a dispersar o
controle operacional dos dados, assim torna-se mais difícil a administração de dados
centralizada. O aumento da sofisticação e do poder dos pacotes de SGBD para
microcomputadores prover uma plataforma de fácil uso para fornecer informações aos
departamentos. Porém, tais ambientes facilitam a duplicação de dados, o que levam os
DBA’s a criar novos conjuntos de técnicas e estilos de gerenciar.
Embora não exista um padrão, é uma pratica comum definir as funções de DBA de acordo
com as fase de ciclo de vida do Banco de dados, a figura 5.4 mostra a organização funcional do
DBA. Se esta abordagem é adotada, então segue esta atividades:
1. Panejamento do banco de dados: inclui a definição de padrões, procedimentos e regras
de consistência.
2. Requerimentos do banco de dados: projeto conceitual.
3. Projeto lógico e de transações de banco de dados.
4. Depuração e teste do banco de dados.

5
 Adm. de BD

Planejamento Projeto Implementação Operações Treinamento

Conceitual Lógico Física Testes

Figura 15 A organização funcional do DBA

1.3 O PAPEL DO DBA

Como um genciador o DBA deve se concentrar em controlar e planejar as dimensões da

função da adimnistraçào do BD. O DBA é reponsável por:
1. Coordenar, monitorar a alocar recursos de administraçào da BD: pessoas e dados.
2. Definir metas e formular planos de estratégias para a função de admnistração de BD.
As funções incluem:
• Definição do esquema: a criação do esquema original do banco de dados. Isto é
realizado escrevendo-se um conjunto de definições que são traduzidas em DDL ou ODL
para um conjunto de tabelas ou classes que são permanentemente armazenadas no
dicionário de dados.
• Definição da estrutura de armazenamento e do método de acesso: a criação de
estruturas apropriadas de armazenamento e métodos de acesso. É feito escrevendo-se
um conjunto de definições que são traduzidas pelo compilador da linguagem de
definição de armazenamento de dados.
• Personalização do SGBD: a modificação de parâmetros padrões quase sempre é
necessária. A aplicação de correções no ambiente do SGBD.
• Concessão de autorização para acesso a dados: a concessão de diferentes tipos de
autorização para o acesso a dados aos vários usuários do banco de dados. Isto permite
ao DBA regular que partes do banco de dados os diferentes usuários podem acessar.
• Especificação de restrições de integridade: estas restrições são mantidas em uma
estrutura especial do sistema que é consultada pelo SGBD sempre que uma atualização
for realizado no banco de dados.

Há uma crescente tendência sobre a especialização da função gerenciamento de dados. Por

exemplo, o organograma organizacional usado por algumas companhias grandes faz uma distinção
entre um DBA e o administrador de dados (DA). O DA, também conhecido como o gerente do
recurso informação (IRM- Information Resource Manager), usualmente se reporta diretamente ao
topo gerencial e lhe é dado um alto grau de responsabilidade e autoridade do que ao DBA.
O DA é responsável por controlar a totalidade de recursos de dados da corporação, tanto
computadorizados como não. Os serviços de DA envolve um grande área de operações se
comparada ao DBA, porque o DA tem o desafio de controlar os dados computadorizados e os que
estão fora do escopo do SGBD. Os papeis de DA e DBA tendem a se sobrepor, mas o DA tem uma

6
atribuição de responsabilidade e autoridade que o DBA não tem. O localização do DBA dentro da
estrutura da organização varia de empresa para empresa. A tabela 5.1 mostra um contraste entre as
atividades do DBA e DA.

Administrador de dados (DA) Administrador de Banco de Dados (DBA)

Planejamento estratégico
Elabora metas a longo prazo
Elabora política e padronização
Escopo amplo
Longo prazo (futuro)
Orientação gerencial
Independente de SGBD
Controle e supervisão
Executa o plano para atingir as metas
Faz cumprir a política e procedimentos
Escopo estreito
Curto prazo (operações diárias)
Orientação técnica
SGBD específico

Tabela 5.1 Contraste das atividades e características entre DA e DBA

Um componente primário do sucesso da estratégia de administração de dados é a insistência

contínua do uso correto da política, procedimentos e padrões para a criação, uso, distribuição e
remoção de dados dentro do banco de dados. O DBA deve definir, documentar e comunicar a
política, os procedimentos e padrões antes de seu uso obrigatório. Basicamente:
• Política: são as regras gerais de direção e ações que deverão ser tomadas.
• Padrões: são regras utilizadas para avaliar a qualidade das atividades. Por exemplo,
padrões que definem como os programas de aplicações devem ser estruturados,
conversões de nomes a serem usados pelos programadores.
• Procedimentos: são instruções escritas que descrevem uma série de passos a serem
seguidos durante a execução de uma dada atividade.

Para ilustrar os conceitos acima vão olhar o seguinte exemplo:

Política:
• Todos os usuários deve possuir uma senha para acesso ao sistema.
• A senha deve ser trocada a cada 30 dias.

Padrões:
• A senha deve possuir no mínimo 5 caracteres.
• A senha deve possuir no máximo 12 caracteres.
• O seguro social não pode ser usado como senha.

Procedimento: Para cria a senha.

1. O usuário envia uma mensagem de solicitação de criação de conta ao DBA.
2. O DBA aprova o pedido e solicita a criação da conta ao suporte.
3. O suporte cria a conta, atribui uma senha temporária e envia a informação ao
usuário final. Uma cópia de criação de conta é enviada ao DBA.
4. O usuário final muda a senha de temporária para permanente.

7
2 MODELAGEM DE DADOS

Tradicionalmente, os projetistas de banco de dados tem a confiança de desenvolverem um

bom projeto. Mas o bom projeto depende das respostas que ele pode dar quanto as indagações do
usuário final. O bom projeto pode ser atingido após várias checagem . Felizmente, a arte de projetar
banco de dados pode ser reforçada pelo uso de ferramentas de projeto de banco de dados. Por
exemplo; ER-WIN (relacional) e Rational Rose (Orientado a objeto.- www.rational.com).
De acordo com o dicionário da língua portuguesa modelo significa “Imagem ou desenho que
serve para representar em escala pequena o objeto do mundo real”. Em outras palavras o modelo é
uma abstração de um objeto complexo do mundo real. Um modelo de dados é uma representação
relativamente simples, normalmente, gráfica da complexa estrutura de dados dos objeto do mundo
real, no caso de modelo de dados orientado a objeto é, também, representado as operações que
manipulam as estruturas de dados.
A principal função do modelo é nos ajudar a entender as complexidades do mundo real.
Dentro de um ambiente de banco de dados, um modelo de dados representa as estruturas de dados e
suas características, relações, restrições e transformações.
Usualmente, o projetista de banco de dados usa o modelo de dados como ferramenta de
comunicação para facilitar a interação entre o projetista, programadores de aplicação e o usuário
final. Se o modelo de dados é bem desenvolvido, ele pode favorecer um melhor entendimento da
organização. Esse importante aspecto da modelagem de dados foi resumido por um cliente, que teve
a seguinte reação; “Eu criei este negócio, eu tenho trabalhado com este negócio por vários anos,
e essa é a primeira vez, realmente, que tenho entendido como todos os pedaços se encaixam”.
Um bom projeto de banco de dados é a base para boas aplicações. Contrariamente,
indiferentemente da experiência dos programadores e/ou da eficiência do gerador de aplicações,
não podemos desenvolver boas aplicações sem um bom projeto de banco de dados. Um bom projeto
de banco de dados começa em construir um bom modelo de dados.
A importância do modelo de dados dificilmente pode ser desprezada. Os dados constituem
a unidade de informação mais básico utilizado por uma sistema. As aplicações são criadas para
gerenciar dados e auxiliar na transformação de dados em informações. Portanto, os dados são vistos
de diferentes formas por diferentes pessoas. Por exemplo, a diferença de visão da companhia entre
gerente e administrativo. Embora o gerente e administrativo trabalhem na mesma empresa o gerente
com certeza tem uma visão muito maior da companhia do que o administrativo.

2.1 O GRAU DE ABSTRAÇÃO DE DADOS

O comitê de padronização (ANSI/SPARC – The American National Standards

Institute/Standards Planning and Requirements Committee) definem três modelos de dados
diferentes que são baseados em graus de abstração: conceitual, externo e interno, conforme pode ser
visto na figura 2.1. Contudo, porém ao analisar a figura 2.1 tem-se a necessidade de expandir a
classificação dos modelos pela adição do modelo de dados físico, que será a implementação do
modelo interno para um SGBD específico.

2.1.1 O MODELO CONCEITUAL

O modelo conceitual, localizado no ápice da abstração, representa um visão global dos

dados. Ele é uma representação dos dados globais da empresa como visto pelo gerente de mais alto
nível. O modelo conceitual é a base para identificação e descrição dos principais objetos de dados,
evitando-se detalhes. O modelo de dados conceitual mais utilizado é o modelo Entidade-

8
relacionamento (E-R), que ao ser usado produzimos o esquema conceitual do escopo que está sendo
modelado.
Grau de Abstração Características

Modelo Independente de
Conceitual Alta
hardaware e software
Modelo
Externo

Modelo Independente de hardware e

Médio
Interno dependentte de software

Modelo
Externo
Dependente de
Modelo baixo
hardware e Software
Físico

Figura 2.1 Graus de abstração

Para ilustrar o uso de modelos conceituais, vamos examinar o ambiente de dados de um

pequeno colégio. Os principais objetos do colégio são: estudante, professores, cursos, classes e sala
de aula. Essas entidades são as principais entidades do os dados são coletados e armazenados. Na
figura 4.2 temos a representação das entidades e os atributos da entidade estudante.

Entidade

Estudante Professor Curso Turma Sala

Matrícula
Número_seguro
Primeiro_nome
Último_nome
Nome_meio Atributos de Estudante
Sexo
Data_nascimento
Endereço
Telefone

Figura 2.2 As entidades de um pequeno colégio

Com as entidades da figura 4.2 pode-se definir e descrever os relacionamentos entre aquelas
entidades (também chamado de associação ou interações). Os relacionamentos podem ser
classificados em um-para-um (1:1), um-para-muitos (1:N) ou muitos-para-muitos (N:M)

9
 Tendo identificado as entidades, um esquema conceitual é usado para relacionar uma
entidade a outra, com pode ser visto na figura 2.3. Note que na figura 2.3 os relacionamentos entre
as entidades são descritos através dos verbos: ensinar, conter, gerar e requer. Isto é, um professor
ensina uma turma, uma turma contém estudantes e uma turma requer uma sala. E, que, os
relacionamentos podem ser descritos de 1:N e de N:M.

Curso

gerar

N
1 N
Professor ensinar Classe contém Estudante
N M

requer

Sala

Figura 2.3 O esquema conceitual do pequeno colégio

O modelo conceitual produz algumas vantagens muito importantes. Primeiro, ele forma a
base para o esquema conceitual, no qual prover um entendimento relativamente fácil do ponto de
vista do ambiente dos dados. Por exemplo, pode-se ter um resumo detalhado do ambiente de dados
do pequeno colégio pelo exame do diagrama do esquema conceitual apresentado na figura 2.3.
Segundo, o modelo conceitual é independente de software e hardware. A independência de
software significa a não dependência do SGBD para implementar o modelo. A independência do
hardware significa que o modelo não depende do hardware usado na implementação do modelo.
Portanto, mudanças no hardware ou SGBD não terá qualquer efeito no projeto do banco de dados a
nível conceitual.

2.1.2 O MODELO INTERNO

Uma vez que o SGBD tenha sido escolhido, o modelo interno adapta o modelo conceitual ao
SGBD. Em outras palavras, o modelo interno requer que o projetista faça o mapeamento das
características e restrições do modelo conceitual para o modelo do SGBD escolhido. Pelo fato do

10
modelo depender da existência de software de SGBD específico, é dito ser dependente do software.
Logo, uma mudança no software de SGBD implica em mudança no modelo interno. No caso do
modelo de SGBD ser relacional menos detalhamento será necessário no modelo interno do que se
fosse escolhido outro paradigma (hierárquico, rede ou objeto).
No caso da figura 2.3, foi implementado o modelo interno pela criação do banco de dados de
um pequeno colégio através das tabelas: professor, curso, turma, estudante e sala. Também, deve-
se criar uma entidade de composição entre sala e estudante. Esta entidade terá o nome de
matrícula, como mostrado na figura 2.4. Em outras palavras, o esquema do banco de dados é o
modelo interno. O modelo interno também é independente do hardware, porque ele não é afetado
quando da mudança do computador no qual o software SGBD está instalado. Logo, uma mudança
no dispositivo de armazenamento ou mesmo uma mudança no sistema operacional não afetará os
requerimentos no projeto do modelo interno.

2.1.3 O MODELO EXTERNO

O modelo externo, baseando no modelo interno, é a visão do usuário final do ambiente de

dados. Entende-se por usuário final aquelas pessoas que usam os programas de aplicação, os
projetistas e implementadores do modelo. O usuário final, usualmente, opera em um ambiente no
qual uma aplicação tem um foco específico em uma unidade do negócio. O negócio é, geralmente,
divido em unidades tais como: vendas, financeiro, propaganda, e outras. Cada unidade de negócio
possui requerimentos e restrições específicas, e cada usuário um conjunto de dados. Portanto, os
programadores de aplicação trabalham dentro daquelas unidades de negócio vendo o conjunto de
dados apropriado de forma separada no modelo externo em relação ao modelo interno, de onde os
dados são derivados, essa divisão é mostrada na figura 2.4.

2.1.4 O MODELO FÍSICO

O modelo físico opera no mais baixo nível de abstração, descrevendo o modo como os
dados estão guardados na mídia de armazenagem, tais como discos e fitas. O modelo físico requer a
definição tanto dos dispositivos de armazenagem físico quanto dos métodos de acesso físico
necessários para obter os dados dentro daqueles dispositivos. Pelo fato do modelo físico requerer
tarefas de armazenamento e recuperação precisas e específica ao dispositivo, ele é dependente do
software e hardware. As estruturas de armazenamentos usadas são dependentes do software (SGBD
e sistema operacional) e do tipo de dispositivo que o computador pode manipular. A precisão
requerida na definição do modelo físico demanda que o projetista de banco de dados que trabalha
neste nível tenha um conhecimento detalhado do hardware e software usados para implementar o
projeto do banco de dados.
Em se tratando de modelo relacional, o projetista não necessita preocupar-se com as
características física para o armazenamento dos dados. Contudo, implementação de um modelo
relacional pode requerer ajustes finos a nível físico para melhorar a performance. O ajuste fino é
especialmente importante quando grandes banco de dados são instalados em ambiente de grande
porte.

Curso

gerar

11
N
MODELO 1 N
Professor ensinar Classe contém Estudante
 Figura 2.4 Uma divisão do modelo interno em modelos externos que são
representados pelo esquema externo

2.2 O MODELO ENTIDADE E RELACIONAMENTO

Pelo fato do modelo relacional ter tornado-se dominante em projeto de banco de dados, o
enfoque será todo neste modelo. Portanto, será estudado o modelo Entidade Relacionamento (E-R)
que vem sendo usado a vários anos e muito aceito. Ele é uma ferramenta normalmente usada para:
• Traduzir diferentes visões dos dados entre gerentes, usuários e analistas para amoldar dentro
de uma estrutura comum.
• Definir os requerimentos de processamento de dados e as restrições de integridade para
auxiliar o encontro de diferentes visões.
• Auxílio na implementação do banco de dados.

12
2.2.1 OS COMPONENTES DO MODELO E-R

O modelo E-R é a base do diagrama E-R, o qual representa o banco de dados conceitual
como visto pelo usuário final. Esses diagramas representam os três principais componentes do
modelo que são: entidade, atributos e relacionamento. Pelo fato da entidade representar um objeto
do mundo real, as palavras entidade e objeto são frequentemente utilizadas como sinônimo. Logo,
as entidades ou objetos do exemplo da figura 2.3 são: estudantes, sala, professor, e outras.

2.2.1.1 ENTIDADES

Uma entidade no modelo refere-se a uma conjunto de objetos ou entidades do mundo real e
não a um único objeto. Em outras palavras, a palavra “entidade” no modelo corresponde a uma ou
mais tabelas e não a uma linha de algum ambiente relacional. No modelo E-R uma única linha é
denominada de ocorrência da entidade. A entidade é representada por um retângulo contendo um
nome.

2.2.1.2 ATRIBUTOS

Os atributos descrevem as características que foram abstraídas dos objetos do mundo real e
representadas no modelo. O atributo é representado por um circulo contendo um nome e fica
conectado a entidade por uma linha. Por exemplo, na figura 2.6 a entidade estudante possui os
atributos: nome, data de nascimento (dt_nasc) e número do seguro (Nseguro).

13
3 INTRODUÇÃO A BANCO DE DADOS

Usualmente, as organizações prosperam quando seus gerentes agem na base das

informações relevantes. Para gerar informações relevantes eficientemente, é necessário acessar
rapidamente os dados (fatos primários) originais de onde as informações requeridas foram
produzidas. O gerenciamento de dados tem como foco principal uma coleção de dados armazenados
e que podem ser recuperados. Logo, constitui a atividade central de qualquer organização.
Normalmente, o gerenciamento de dados de forma eficiente requer o uso de base de dados
em computadores. Uma base de dados é uma estrutura integrada e compartilhada que mantém uma
coleção de:
• Dados do usuário final – que são, os fatos primários que interessa o usuário final.
• Metadados – “dados sobre dados”, através do qual os dados são integrados.
O metadados prover uma descrição das características e do conjunto de relacionamentos que
ligam os dados encontrados dentro do banco de dados. Uma linha de produtos foram estudas e
projetadas pela industria de computadores para manter e gerenciar dados, que são os SGBD’s
(Sistema Gerenciador de Banco de Dados).
Devido ao fato dos dados primários serem a fonte crucial de onde as informações são
derivadas, existem boas razões pelas quais os SGBD’s são importantes na nossa sociedade que é
baseada em informações. Os seguintes pontos são de extrema importância:
• Se os dados são importantes, devemos ter uma boa maneira de gerenciá-los. Os SGBD’s
permitem gerenciar de forma eficiente e eficaz os dados, o que não era possível antes do
seu surgimento.
• Os SGBD’s possuem linguagem para consulta que torna possível obter respostas rápidas
através de consultas “ad hoc”.
• O SGBD possibilita criar um ambiente para o usuário gerenciar e acessar os dados. A
disponibilidade dos dados combinado a ferramentas que transforma os dados em
informações úteis, o auxilia na tomada de decisões de forma rápida e segura.
• O total acesso aos dados da empresa de maneira bem gerenciado promove uma visão
integrada das operações da organização. Consequentemente, torna-se fácil ver como a
ação em um segmento da companhia afeto outro segmento. O ambiente do SGBD prover
um visão clara de toda a organização, como um grande diagrama.
• A possibilidade de dados inconsistentes é fortemente reduzida quando a base de dados
projetada é armazenada e gerenciada por um SGBD.
Estas são algumas das vantagens do uso de SGBD. Ao longo deste trabalho iremos descobrir
várias outras vantagens do uso de SGBD.
Um SGBD é uma coleção de programas que gerencia a estrutura do banco de dados e
controla o acesso aos dados armazenados, e possibilita o acesso compartilhado aos dados
armazenados por diferentes aplicações e usuários. A figura 1.1 mostra que o SGBD encontra-se
entre o banco de dados e os usuários. De fato, o SGBD faz as traduções dos pedidos do usuário em
códigos complexos afim de responder os pedidos.

14
Usuário
Estrutura do banco de Dados
Solicitação da Aplicação

Dados Metadados

SGBD Cliente

Usuário Dados Dados

Produto do
usuário

Solicitação da Aplicação
Fornecedor

Figura 1.1 O SGBD gerencia a interação entre o usuário e o banco de dados

3.1 PORQUE O PROJETO DE BANCO DE DADOS É IMPORTANTE

Um bom banco de dados não acontece por acaso; a estrutura de seu conteúdo deve ser
projetada cuidadosamente. Projeto de banco de dados é um aspecto crucial e se mau projetado pode
tornar o SGBD com baixa performance.
Um banco de dados bem projetado facilita o gerenciamento de dados e torna-se um precioso
gerador de informações. Mas, um projeto de banco de dados mau formulado abre a possibilidade de
se ter dados redundantes no banco de dados de forma descontrolada. A redundância descontrolada
são freqüentemente a fonte de dificuldades para tratar informações erradas.
Um banco de dados contém informações redundantes quando o mesmo dado é mantido em
localizações diferentes para a mesma entidade. Por exemplo, quando o número de telefone do
cliente é armazenada em um arquivo de cliente, arquivo de agentes de vendas e um arquivo de
mala direta. Se o número mudar a correção deve ser feitas em todos os locais ela ocorrer.
Entretanto, a existência de dados redundantes pode produzir entradas de dados incorretas e
dificilmente será possível determinar qual dado está correto. Um projeto de banco de dados pobre
tende a gerar erros que levam a tomar decisões erradas. As organizações que utilizam banco de
dados maus projetados freqüentemente falham porque os seus gerentes não tem acesso a
informações em tempo (ou mesmo corretas. Logo, os maus projetos de banco de dados devem ser
eliminados.
Devido ao fato dos bancos de dados serem a fonte de informações geradas, seus projetos são
objetos de estudo detalhado em ambientes modernos. O projeto de banco de dados é extremamente
importante.

15
3.2 ORIGEM HISTÓRICA DE BANCO DE DADOS: ARQUIVOS E SISTEMAS DE
ARQUIVOS

Historicamente, as primeiras aplicações em computador eram tarefas de escritórios:

processamento de pedidos, folha de pagamento e outras. Tais aplicações acessavam dados
armazenados em arquivos no computador. As solicitações por informações eram rapidamente
atendidas; relatórios eram gerados para transformar dados armazenados em informações úteis para a
tomada de decisões.
Embora os sistemas de arquivos sejam, hoje, obsoletos, existem boas razões para estudá-los
sobre alguns aspectos:
• Os sistemas de arquivos provêem uma perspectiva histórica útil sobre como manipular
dados.
• A existência de alguns problemas relacionados ao fato do sistema de arquivo ser
duplicado no banco de dado do software que o utiliza, dificultando o gerenciamento de
dados.
• A complexidade do projeto de banco de dados é de fácil compreensão uma vez que o
entendimento das características do sistema de arquivo são relativamente simples.
• Se existe a intenção em converter um sistema de arquivos obsoleto em um sistema de
banco de dados, as limitações básicas do sistema de arquivos torna-se úteis.
Em um passado recente, o gerente de quase todas as organizações pequenas eram capazes
de manter os dados necessários com o uso de sistema de arquivo manuais. Desta maneira, um
sistema de arquivo era, tradicionalmente, composto de uma coleção de fichas e eram mantidas em
um fichário.
A organização dos dados dentro do fichário era determinada de acordo com o uso do dados.
O conteúdo de cada conjunto de fichas era logicamente relacionado. Por exemplo, o conjunto de
fichas de um consultório deveria conter dados de pacientes, uma ficha para cada paciente. A figura
1.2 mostra um sistema de arquivos simples.

Dept. Vendas Dept. Pessoal

Arquivo Arquivo de Arquivo de

de clientes funcionário
vendas

Figura 1.2 Um sistema de arquivo simples

3.3 SISTEMAS DE BANCO DE DADOS

Os problemas inerentes a sistema de arquivos tornou o uso do sistema de banco de

dados bastante desejável. Ao contrário dos sistemas de arquivos, com seus vários arquivos

16
separados e não relacionados, o banco de dados consiste de dados relacionados logicamente e
armazenados em um único repositório de dados. Portanto, o banco de dados representa uma
mudança na forma como os dados do usuário são armazenados, acessados e gerenciados. O SGBD,
mostrado na figura 1.3, prover numerosas vantagens sobre o gerenciamento do sistema de arquivos
por facilitar a eliminação de dados inconsistentes, dados anormais e dependência estrutural dos
dados. Melhor ainda, a geração atual de SGBD além de armazenar a estrutura dos dados em locais
centrais, como também armazena o relacionamento entre os componentes. O SGBD prover todas
formas necessárias para o usuário acessar os dados.

O SISTEMA DE BANCO DE DADOS

Banco de dados

Dept. pessoal
SGDB Pessoal

Vendas

Dept. de Vendas

O SISTEMA DE ARQUIVOS

Dept. pessoal Dept. de Vendas

Pessoal Cliente Contas Estoque

Figura 1.3 Contraste entre banco de dados e sistema de arquivos

17
 Não podemos esquecer que o SGBD é apenas um dos vários componentes essenciais de um
sistema de banco de dados. O SGBD é o “coração” deste ambiente, mas como o “coração” não
funciona sozinho, assim outros componentes são necessários.

3.3.1 O AMBIENTE DO SISTEMA DE BANCO DE DADOS

O sistema de banco de dados refere-se a organização dos componentes que define e

regulamenta a coleção, o armazenamento, o gerenciamento e uso dos dados dentro de um ambiente
de banco de dados. De um ponto de vista de gerenciamento geral, o sistema de banco de dados é
composto de 5 partes principais mostrados na figura 1.4: hardware, software, pessoas,
procedimentos e dados.

Procedimentos
e Padrões Escreve e força

Administrador Administrador
Analistas do banco de do sistema
dados
Projetista do
banco de dados gerencia
Hardware

Programadores
Usuários
escrevem

Programas de Utilitários do SGBD

Aplicações
usam
SGBD
acessam

Dados

Figura 1.4 O ambiente do sistema de banco de dados

1. Hardware. Identifica todos os dispositivos físicos. O principal e mais fácil componente

de hardware a ser identificado é o computador. O computador poderia ser um
microcomputador, um minicomputador ou um computador de grande porte e mais todos
os periféricos acoplados ao equipamento em questão.

18
 2. Software. Refere-se a coleção de programas que são utilizados pelo computador dentro
do sistema de banco de dados. São três os principais tipos de software componentes: o
sistema operacional, o próprio SGBD e os programas de aplicações.
3. Pessoas. Este componentes inclui todos os usuários do banco de dados. Baseado em
funções primárias de serviços, podemos identificar 5 tipos de usuários em um sistema
de banco de dados:
• Administrador do sistema: supervisiona as operações gerais do sistema de banco de
dados.
• Administrador de banco de dados: conhecido como DBA, gerencia usuários do
SGBD e assegura que o banco de dados fique, sempre, em funcionamento.
• Projetista de banco de dados: projeta a estrutura do banco de dados, e o sucesso do
banco de dados se dará em função de um bom projeto.
• Analista de sistemas e programadores: projeta e implementa os programas de
aplicações. Eles projetam e criam as telas de captação de dados, relatórios e
procedimentos que são utilizados pelos usuários para acessarem e manipularem
dados do banco de dados.
• Usuário final: os usuários que utilizam as aplicações para executar as operações
diárias da empresa.
4. Procedimentos: são instruções e regras que governam o projeto e os usuários do banco
de dados. Eles são componentes cruciais no sistema de banco de dados.
5. Dados: a palavra dados engloba a coleção de fatos armazenados no banco de dados.
Devido ao fato do dado ser a matéria-prima para gerar informações, a determinação de
quais dados devem alimentar o banco de dados e como tais dados serão organizados é
a parte vital do serviço de um projetista de banco de dados.

3.3.2 TIPOS DE SISTEMAS DE BANCO DE DADOS

O SGBD, ao qual o sistema de banco de dados é baseado, pode ser classificado de acordo
com número de usuários e a localização do banco de dados.
1. O número de usuários determina se o SGBD é classificado como “usuário único”
(single-user) ou “múltiplos usuários” (multi-user). Um SGBD single-user suportar
somente um usuário por vez. Em outras palavras, se o usuário A está usando o banco de
dados, usuários B e C devem ficar esperando até que o usuário A conclua seu trabalho
no banco de dados. Se o banco de dados single-user executar sobre um computador
pessoal, ele é, também, chamado de banco de dados “desktop”.
2. A localização do banco de dados é usada para classificar o SGBD. Por exemplo, o
SGBD que suporta o banco de dados localizado em um único local é denominado de
centralizado. Mas, se o SGBD suportar a distribuição do banco de dados em diversas
localidades é denominado de distribuído.

19
3.3.3 AS FUNÇÕES DE UM SGBD

Um SGBD executa várias funções importantes que garantem a integridade e consistência

dos dados no banco de dados. A maioria desta funções são transparentes ao usuário final. E a
maioria desta funções só podem ser alcançadas através do uso de um SGBD. Essas funções incluem
gerenciamento de dicionário de dados, gerenciamento de dados armazenados, transformação e
apresentação de dados, gerenciamento de segurança, controle de acesso a múltiplos usuários,
gerenciamento de “backup” e “recovery”, gerenciamento de integridade de dados, linguagem de
acesso a dados, interface com programas de aplicações e interface de comunicação do banco de
dados.
1. Gerenciamento de dicionário de dados: o SGBD requer que a definição dos elementos de
dados e seus relacionamentos (metadados) fiquem armazenados em um dicionário de
dados. O SGBD utiliza o dicionário de dados para verificar a estrutura dos dados e seus
relacionamentos, assim evitasse a necessidade de se colocar códigos complexo nos
programas de aplicação para acessar os dados.
2. Gerenciamento do dado armazenado: O SGBD cria estruturas complexas necessárias ao
armazenamento dos dados, consequentemente livra os programas da complexa tarefa de
tratar as características físicas dos dados. Os atuais SGBD prove além do armazenamento
dos dados, armazena: os formulários de entrada de dados ou definições de telas,
definições de relatórios, regras de validação de dados, código de procedimentos,
estruturas para manipular com sons e imagens, e mais.
3. Transformação e apresentação de dados: O SGBD transforma os dados de entrada
conforme as estruturas de dados que são requeridas para armazená-los. Assim, o SGBD
evita que os programas faça a distinção entre formato de dados lógico e físico. Para
manter a independência de dados, o SGBD traduz os requerimentos lógicos em comandos
que localiza fisicamente os dados e os recupera. Em outras palavras, o SGBD prover aos
programas de aplicações com independência de software e abstração de dados.
4. Gerenciamento de segurança: O SGBD cria um sistema de segurança que obriga a todos a
passar por este sistema e mantém a privacidade dos dados. As regras de segurança
determinam quais usuários podem acessar o banco de dados, quais itens de dados os
usuários podem acessar e que operações de manipular dados o usuário pode executar
(leitura, adicionar, apagar e modificar). Isto é especialmente importante em sistemas de
banco de dados multi-usuários onde vários usuários podem acessar o banco de dados
simultaneamente.
5. Controle de acesso a múltiplos usuários: O SGBD cria estruturas complexas que permite
muitos usuários acessarem os dados. Com objetivo de prover integridade e consistência
de dados, o SGBD utiliza algoritmos sofisticados para assegurar que vários usuários
possam acessar o banco de dados concorrentemente e garantir a integridade do banco de
dados.
6. Gerenciamento de “backup” e “recovery”: O SGBD prover procedimentos para realizar
becape e recuperação do banco de dados de forma segura e integra. Os atuais SGBD
provêem utilitários que permite ao DBA executar procedimento de becape e recuperação.
A recuperação do banco de dados é necessária após uma falha e as vezes é preciso lançar
mão do becape para restaurar o banco de dados a um estado consistente.
7. Gerenciamento de integridade de dados: O SGBD aplica e força as regras de integridade
de dados para eliminar problemas de integridade de dados, consequentemente minimiza a
redundância e maximiza a consistência dos dados. Os relacionamentos de dados

20
 armazenados no dicionário de dados são usados para força a integridade de dados.
Assegurar integridade de dados é especialmente importante em sistemas de banco de
dados orientados a transações.
8. Linguagem de acesso a dados: O SGBD prover acesso aos dados no banco de dados via
linguagem de consulta. Uma linguagem de consulta é uma linguagem não procedural, isto
é ela permite que o usuário especifique o que deve ser feito sem ter que especificar como
ser feito. As linguagens de consulta do SGBD contém dois componentes: um a linguagem
de definição de dados (DDL) e o outro a linguagem de manipulação de dados (DML). A
DDL define as estruturas na qual os dados serão criados e a DML permite o usuário final
extrair dados do banco de dados. O SGBD, também, permite acesso aos dados através de
linguagens procedurais (3GL), tais como COBOL, C, PASCAL, Visual Basic e outras. O
SGBD, também, prover utilitários administrativos que são usados pelos DBA’s e
projetistas de banco de dados para criar, implementar, monitorar e manter o banco de
dados.
9. Interface de comunicação do banco de dados: A atual geração de SGBD prover rotinas de
comunicação especiais projetadas para permitir que o banco de dados atenda solicitações
dos usuários dentro de um ambiente de rede de computadores. De fato, a capacidade de
comunicação dos SGBD’s é o aspecto essencial dos modernos SGBD’s. Por exemplo, o
SGDB poderia prover funções de comunicação para acessar o banco de dados através da
internet, usando “browsers internet” como o netscape ou o explorer como “front end”.
Neste ambiente, a comunicação pode ser feita de várias maneiras:
• O usuário final pode gerar consultas, através de filtragens em formulários, para serem
tratadas pelo World Wide Web.
• O SGBD pode, automaticamente, publicar relatórios pré-definidos na internet, usando
o formato Web através de browser.
• O SGBD pode conectar-se a um terceiro system para distribuir informações via Email
ou outras aplicações tais como Lotus notes.

4 BANCO DE DADOS ORIENTADO A OBJETO

O uso de bancos de dados orientados a objeto é um fator emergente que integra bancos de
dados e tecnologia de orientação a objeto. Por um lado, a necessidade de realizar manipulações
complexas em bancos de dados existentes as novas gerações de aplicações de bancos de dados
geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado,
aplicações de linguagens orientadas a objeto e sistemas estão exigindo capacidades de bancos de
dados, tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas necessidades
estão levando à criação de sistemas poderosos, chamados de dados orientados a objeto, como
mostrado na figura 2.1. As grandes setas representam “herança”, e bancos de dados orientados a
objeto combinam (herdam) características e aptidões de bancos de dados.
Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa
nas universidades e centros de pesquisa. Em meados dos anos 80, eles começaram a se tornar
produtos comercialmente viáveis. Hoje, eles são mais de 25 produtos no mercado que podem ser
caraterizados como produtos de “bancos de dados orientados a objeto”. Além disso, os
comerciantes de bancos de dados relacionais estão começando a incorporar características de
orientação a objeto em seus produtos de próxima geração baseados em SQL.

21
 Tipo abstrato
de dados
Herança
Identidade do
objeto

Orientação a objeto

Recuperação
Transação
Versão
Consulta
Persistência

Integridade

Continuidade
Aptidões de Banco de Segurança
Dados

Desempenho

Banco de dados orientado a objeto

Figura 2.1 Banco de dados orientado a objeto

4.1 O QUE É UM BANCO DE DADOS ORIENTADO A OBJETO

Ainda que um consenso esteja começando a se formar sobre o que é orientação a objeto e o
que são bancos de dados orientados a objeto, ainda há alguma confusão. Mas, existem grupos que
estão trabalhando a padronização de um ambiente orientado a objeto, como o OMG (Object
Management Group).
Como já mencionado, os bancos de dados orientados a objeto integram a orientação a objeto
com aptidões de bancos de dados. Através de construções orientadas a objeto, os usuários podem
esconder os detalhes da implementação de seus módulos, compartilhar a referência a objetos e
expandir seus sistemas através de módulos existentes. A funcionalidade de banco de dados é
necessária para assegurar o compartilhamento concomitante e a continuidade das informações nas
aplicações. Através dos bancos de dados, os usuários podem obter o estado em que os objetos se
encontram, e estar atualizados entre as várias solicitações de programa, e vários usuários podem ao
mesmo tempo compartilhar a mesma informação. Os bancos de dados orientados a objeto
combinam os benefícios e conceitos da orientação a objeto com a funcionalidade dos bancos de
dados.
Nesta apostila, as seguintes definições serão usadas como referência para caracterizar
bancos de dados orientados a objeto:
A orientação a objeto é definida como:

Orientação a objeto = tipagem de dados abstratos

+ herança
+ identidade do objeto

22
 Aptidões de bancos de dados são definidas assim:

Aptidões de bancos de dados = continuidade

+ concomitância
+ transações
+ recuperação
+ filtragem
+ atualização
+ integridade
+ segurança
+ desempenho

Bancos de dados orientados a objeto = orientação a objeto + aptidões de banco de dados.

4.2 ORIENTAÇÃO A OBJETO

É uma disciplina abrangente, que tem permeado muitas áreas em computação, incluindo:
linguagens, interfaces com usuário, inteligência artificial, sistemas operacionais e banco de dados.
Pode ser definida como as disciplinas de modelagem de Software que tornam fácil construir
sistemas complexos a partir de componentes individuais. Que proporciona conceitos e ferramentas
para modelar e representar o mundo real. As vantagens da orientação a objeto na programação e
modelagem de dados são muitas. Como:
• Permite representação mais direta do modelo de mundo real.
• As transformações das requisições do sistema (definidas em termos de usuários) para a
especificação do sistema (definida em termos de computador) são fortemente reduzida.
• Possui a habilidade de construir grandes programas a partir de outros pequenos, pré-
fabricados.

4.3 SUMÁRIO DOS CONCEITOS DE ORIENTAÇÃO A OBJETO

Os três aspectos mais fundamentais do paradigma orientado a objeto são tipos de dados
abstratos, herança e identidade do objeto. Cada um destes conceitos contribui para a engenharia do
Software e para modelar as propriedades dos sistemas orientados a objeto.

4.3.1 TIPOS DE DADOS ABSTRATO

Tipos de dados são usados para descrever um conjunto de objetos com a mesma
representação. Várias operações são associadas com cada tipo de dados. Tipos de dado abstratos
estendem a noção de um tipo de dados “escondendo” a implementação das operações definidas pelo
usuário (“mensagens”) associadas com o tipo de dados. Linguagens que suportam tipos de dados
abstratos provêm construções para definir estruturas e as operações usadas para manipular
ocorrências (“instâncias”) das estruturas de dados diretamente. Além disso, todas as manipulações
de instâncias dos tipos de dados são feitas exclusivamente através de operações associadas com o
tipo de dados.

23
 Como exemplo, considere um vendedor como representado na figura 2.2. A classe vendedor
tem uma interface com as operações definidas: AdicionaNovaConta, DarPromoção e MudaCota.
O importante a considerar sobre a classe vendedor é que de maneira a inteirar com as instâncias
desta classe, estas operações são suficientes. Um procedimento que venha utilizar esta classe não
precisa se preocupar em como cada operação foi implementada, o que precisa fazer é utilizar as
operações para extrair as informações ou atualizar o estado do pessoal de vendas. Uma linguagem
que permita tipos de dados abstrato permitirá que instâncias de tipos de dados sejam manipuladas
somente através de uma coleção de operações associadas com o tipo.

N om e
Id a de
C on ta
O rdem

V a riá v eis de instâ ncia

A dicion a N ov a C on ta
D a rP rom oçã o
M u d a C ota

O pera çõ es

C la sse V endedor

Figura 2.2 A classe vendedor.

4.3.2 HERANÇA

O segundo conceito orientado a objeto poderoso é herança. Através da herança, módulos de

Software (classes) podem ser construídos no topo de uma hierarquia de módulos existente. O
comportamento da herança capacita o compartilhamento de código (e daí a reusabilidade) entre
módulos de Software. Considere a hierarquia de pessoas ilustrada na figura 2.3. Aqui cada
trabalhador de escritório é uma Pessoa. Semelhantemente, cada estudante é uma Pessoa. Pessoal de
vendas, engenheiros e secretárias são Pessoa.

Pessoa

Funcionário Estudante

Vendedor Secretária Graduado Não-graduado

Engenheiro

Figura 2.3 Hierarquia de classes

24
 A relação de “herança” indica que além dos atributos ou operações particulares a uma
subclasse, todas as operações e atributos da superclasse são herdados pelas subclasses. Esta é a
essência das hierarquias de heranças. Tipos de objetos herdam a maioria dos seus atributos de tipos
genéricos ou menos especializados.

4.3.3 IDENTIDADE DE OBJETO

O terceiro conceito poderoso orientado a objeto é a identidade de objeto. Identidade é aquela

propriedade de um objeto que distingue cada objeto dos outros. Com a identidade de objeto os
objetos podem conter ou se referir a outros objetos.

4.4 CONCEITOS ORIENTADOS A OBJETO

A orientação a objeto é uma metodologia de modelagem e desenvolvimento baseada nos

conceitos de orientação a objeto. Que pode ser definida mais precisamente como:

Orientação a objeto
Um conjunto de esquemas e princípios de desenvolvimento baseados em
estruturas de computação independentes conceitualmente conhecidas com
objeto. Cada objeto representa uma entidade do mundo real com a
habilidade de interagir consigo e com outros objetos.

Como podemos ver na definição, o uso de objetos torna a modularidade quase inevitável. Os
conceitos de orientação a objeto tem sido largamente aplicada em várias disciplinas relacionadas
com computação, especialmente aquelas que envolve programação complexas e problemas de
projeto. A tabela 2.1 resume algumas das contribuições para a orientação a objeto das várias
disciplinas relacionadas com computação.

Área relacionada a Computação Contribuições para a Orientação a Objeto

Linguagem de programação Redução do número de linhas de código
Diminuição do tempo de desenvolvimento
Aumento da reusabilidade de código
Mais fácil a manutenção do código
Aumento da produtividade do programador
Interface de usuário gráfica (GUI) Aumento na habilidade de criar interface “easy-to-
use”
Sistemas mais amigáveis para usuário final
Facilita a definição de padrões
Banco de dados Suporta tipo abstratos de dados
Suporta objetos complexos
Suporta a multimídia
Projeto Captura mais a semântica dos modelos de dados
Representa melhor o mundo real
Sistema Operacional Aumento da portabilidade do sistema,
consequentemente melhora a interoperabilidade do
sistema

Tabela 2.1 Resumo da contribuição das várias disciplinas

4.4.1 A EVOLUÇÃO DOS CONCEITOS DE ORIENTAÇÃO A OBJETO

25
 Os conceitos de orientação a objeto tem como base a programação orientada a objeto (POO),
que foi desenvolvida como forma alternativa de programação em relação aos métodos tradicionais.
Antes da POO, dados e procedimentos eram isolados um do outro. Programadores foram treinados
para identificar as fontes de dados, agrupá-los em arquivos e tabelas, para estabelecer relações e
restrições, e escrever procedimentos necessários para produzir certos resultados. Logo, no ambiente
de programação os dados são os componentes passivos, enquanto que os procedimentos que
manipulam os dados são os componentes ativos.
A rígida distinção entre dados e procedimento é fortemente visto em linguagens procedurais,
como exemplo a linguagem COBOL. Utilizando um linguagem procedural, o programador invoca
uma aplicação, que manipula os dados para prover informações. E de forma contrária, em
ambientes de POO o programador solicita aos objetos que execute operações sobre eles.
Os primeiros conceitos de OO apareceram em linguagens de programação tais como: Ada,
Algol, LISP, e SIMULA. Cada uma destas linguagens de programação fixa o estágio da introdução
dos conceitos de OO, que foram expandidos pelas linguagens sucessoras. Atualmente, O Smalltalk
e C++ são as linguagens de programação OO que dominam o mercado. Elas diferem
substancialmente no nível de inclusão da orientação a objeto. O Smalltalk representa um ambiente
puro de OO, enquanto que C++ é essencialmente uma extensão da linguagem C que suporta OO.
As LPOO foram desenvolvidas para prover um ambiente o mais natural possível aos
programadores de Software. Os principais objetivos foram:
• Prover um ambiente de desenvolvimento de Software de fácil uso.
• Prover uma poderosa ferramenta para modelagem de Software através de prototipação.
• Diminuição da equipe de desenvolvimento pela redução da quantidade de código.
Melhoria da produtividade do programador em função da reusabilidade de código.
A adoção de POO muda não somente o modo pelo qual os programas são escritos como
também a forma de agir dos mesmos. Manter em mente como a OO vê os dados do mundo real com
a habilidade de manipulá-los. Consequentemente, o ambiente de OO tem vários atributos
importantes:
1. O conjunto de dados não são passivos, isto é não são tratados de forma isolada.
2. Dados e procedimentos são agrupados, criando um objeto.
3. O objeto tem uma habilidade natural de agir consigo mesmo.
De fato, um objeto pode interagir com outros objetos para criar um sistema. Como tais
objetos carregam consigo os dados e os código torna-se fácil e mais natural produzir módulos de
sistemas reusáveis.

4.4.2. CONCEITOS DE ORIENTAÇÃO A OBJETO

A orientação a objeto tem seus conceitos baseado em LPOO’s, que freqüentemente são
consideradas como linguagens criadas, principalmente, por programadores para programadores, que
tende programar a seu modo no seu próprio mundo.

4.4.2.1 OBJETOS: COMPONENTES E CARACTERÍSTICAS

26
 Em sistemas orientados a objeto tudo é tratado como sendo objetos, como: um estudante,
uma fatura, um avião, um empregado, um serviço, um painel de menu, um relatório, e outros.
Alguns objetos são palpáveis (real) e outros não (abstrato). Podemos definir um objeto dentro do
ambiente de orientação a objeto da seguinte forma:

OBJETO
Um objeto é uma representação abstrata das entidades do
mundo real que tem um identificador único, propriedades
embutidas, e a habilidade de interagir com outros objetos e
consigo mesmo.

Note a diferença entre entidade e objeto. A descrição de uma entidade é baseada nos dados
componentes e nos relacionamentos com outras entidade, porém falta a habilidade para manipulá-
los. Posteriormente, outras diferenças serão apresentadas.
O ponto forte da definição de objetos é a identidade única. Para enfatizar este ponto,
examinemos os objetos do mundo mostrados na figura 2.4. Observe que, embora eles possuam
características comuns como: nome, seguro social, endereço, data de nascimento, e outras, cada
objeto tem existência independente no tempo e no espaço.

João B. Santos Maria A. Silva Pedro P. Alves

Objetos

Figura 2.4 Objetos estudantes do mundo real

4.4.2.2 IDENTIDADE DE OBJETO

A parte mais relevante de um objeto é sua identidade. A identidade do objeto é representada

por um Object ID (OID), o qual o é único para aquele objeto, e dois objetos distintos não podem
compartilhar o mesmo OID. O OID é atribuído pelo sistema no momento que o objeto é criado e
não pode ser mudado sob qualquer circunstância.
Não podemos confundir a chave primário do modelo relacional com o OID. Em contraste
com o OID, a chave primária é baseada em valores fornecidos pelo usuário para selecionar atributos
e pode ser mudada a qualquer momento. O OID é atribuído pelo sistema, e não depende dos valores
dos atributos do objeto, e não pode ser mudado. O OID pode ser apagado somente se o objeto for
apagado, e aquele OID não poderá ser reutilizado. Além disso, o OID único não é a ligado ao

27
endereço físico na memória permanente (disco rígido). Esta característica, permite aos sistemas
orientados a objetos a manter um independência de dados física.

4.4.2.3 ATRIBUTOS (VARIÁVEIS DE INSTÂNCIAS)

Os objetos são descritos através de seus atributos, conhecidos como variáveis de instância
em um ambiente orientado a objeto. Por exemplo, o estudante João B. Santos mostrados na tabela
2.2. Cada atributo tem um nome único e um tipo de dados associado. Por exemplo, o
número_seguro, o primeiro_nome, e outros. Tipos de dados tradicionais, também conhecidos
como tipos de dados básicos, são utilizados na maioria das linguagens de programação e inclui tipos
como: real, int, string e outros.

Variáveis de Instância Valoração

Número_seguro 45.758.999
Primeiro_nome João
Nome_meio B.
Último_nome Santos
Data_nascimento 27/02/1976
MGA_Semestre 2.89
MGA_Total 3.23
Disciplinas Matemática, inglês, outras

Tabela 2.2 Os atributos do objeto estudante

Os atributos, também, possuem domínios. O domínio descreve o conjunto de todos os

possíveis valores que um atributo possa ter. Por exemplo, a média geral acumulada no semestres
das notas de determinado aluno poderia ser representada como sendo o conjunto dos valores reais
entre 0 e 5, com duas casas decimais.
O estado do objeto é um conjunto de valores que os atributos do objeto possa ter em um
determinado instante do tempo. Embora o estado do objeto possa variar, o seu OID mantém-se o
mesmo. Se desejarmos mudar o estado do objeto, devemos mudar os valores de seus atributos. Para
mudar os valores dos atributos de um objeto devemos enviar uma mensagem ao objeto. Essa
mensagem chamará um método.

4.4.2.4 MENSAGENS E MÉTODOS

Para entender mensagens e métodos, vamos imaginar um objeto como sendo uma noz. O
núcleo da noz representa as estruturas de dados do objeto, e a casca seus métodos, conforme a
figura 2.5.

28
 4
Método 1 Método 2

Dados

Método 3 Método 4

Objeto X

Figura 2.5 A representação de um objeto

Toda operação executada sobre um objeto deve ser implementada por método. Os métodos
são usados para mudar os valores dos atributos do objeto ou retornar valores de atributos de objetos
selecionados. Os métodos representam as ações do mundo real, tais como o número do seguro do
estudante, adicionar um estudante a um curso, ou imprimir o nome e endereço de algum estudante.
Fazendo-se uma analogia métodos são equivalentes as funções em linguagens tradicionais. Em se
tratando de orientação a objetos, métodos representam os comportamentos dos objetos.
Todo método é identificado por um nome e possui um corpo. O corpo é composto de
instruções de computação escritas em alguma linguagem de programação para representar as ações
do mundo real. Com base na tabela 2.2 podemos definir um método que retornará a média das notas
acumuladas total e no semestre para estudante, como segue:

Nome do método

Método MédiaMGA:
xmga = 0;
Nome das variáveis de instância

Xmga = (MGA_semestre + MGA_total ) / 2; Corpo do método

return (xmga); Retorna a média

Para invocar um método uma mensagem tem que ser enviada o objeto. Uma mensagem
enviada com a especificação do objeto receptor, o nome do método e todos os parâmetros
necessários. A estrutura interna do objeto não pode ser acessada diretamente pelo provedor da
mensagem, no qual é outro objeto. Negar acesso a estrutura garante a integridade do estado do
objeto e esconde os detalhes de implementação. A habilidade de esconder os detalhes internos do
objeto (atributos e métodos) é conhecido como encapsulamento.
Um objeto pode enviar mensagens para mudar ou interrogar sobre o estado de outros objetos
(interrogar significa perguntar sobre os valores das variáveis de instância do outro objeto. Para
permitir executar acesso a outro objeto, o como do objeto deve conter referências aos métodos do
outro objeto). Na figura 2.6, podemos ver o esquema de envio de mensagens entre objetos.

29
 Objeto A Objeto B Objeto C

Eventos do Método X Método Y Método Z

mundo real
Dado Dado Dado
Método T Método U Método V

Mensagens

Figura 2.6 Envio de mensagens entre objetos

4.4.2.5 CLASSE

Os sistemas orientados a objetos classificam objetos de acordo com suas similaridade e

diferenças. Objetos que compartilham características comuns são agrupados em classes. Em outras
palavras, a classe é uma coleção de objetos similares com estrutura compartilhada (atributos) e
procedimentos (métodos).
Uma classe contém a descrição da estrutura de dados e os detalhes de implementação dos
métodos para os objetos daquela classe. Consequentemente, todos os objetos na classe
compartilham a mesma estrutura e responde as mesmas mensagens. Cada objeto da classe é
conhecido como uma instância da classe ou instância objeto. Na figura 2.7. podemos ver a
representação de uma classe.

Método Método Método Método

A classe contém 1 2 3 4 Uma classe é
a descrição dos composta de
método que Objeto 1 Objeto 2 Objeto 3 uma coleção de
representa o objetos.
comportamento
dos objetos na Objeto 4 objeto 5 Objeto 6
classe.

As instâncias objeto (1,2,3,4,5 e 6) compartilham a estrutura e os métodos da classe.

Figura 2.7 Ilustração da classe

Usando o exemplo mostrado na tabela 2.2, podemos definir uma classe denominada
Estudante para armazenar os objetos estudantes. Todos os objetos da classe Estudante, mostrado
na figura 2.8, compartilham a mesma estrutura (atributos) e respondem as mesmas mensagens
(implementado pelos métodos). Vamos considera os métodos: média_mga, disciplinas_cursando e
grade_horária. Cada instância de uma classe é um objeto com um único OID, e cada objeto sabe a
qual classe pertence.

30
 métodos média_mga disciplinas_cursando grade_horária
Objetos
Número_seguro João B. Santos
Primeiro_nome Maria A. Silva
Variavéis Nome_meio
de Data_nascimento Pedro P. Alves
instância MGA_semestre
MGA_total
Disciplinas

Figura 2.8 Representação da classe estudante

4.4.2.6 PROTOCOLO

A coleção de mensagens da classe, cada uma identificada por um nome, estabelece o objeto
ou protocolo da classe. O protocolo representa os aspectos públicos dos objetos, isto é, os aspectos
são conhecidos por outros objetos como também pelo usuário final. Em contrapartida, a
implementação dos métodos e da estrutura constitui os aspectos privados do objeto, na figura 2.9
são ilustrados tais aspectos.

Protocolo

Mensagem 1 Método 1 Método 2

Interface Implementação
pública Mensagem 2 Dados
privada
Mensagem 3 Método 3 Método 4

Mensagem 4

Figura 2.9 Os aspectos privados e públicos do objeto

Usualmente, uma mensagem é enviada para uma instância da classe (objeto). Quando o
objeto receptor é uma classe, a mensagem invocará um método da classe. Um exemplo de método
da classe é o método new da linguagem smalltalk. Usando-se smalltalk , o método de classe new
é um gatilho (“trigger”) para criar novos instâncias na classe (objeto com OID único) receptora.
Devido ao fato do objeto ainda não existe, a mensagem new é enviada para a classe e não para o
objeto.

31
 Aspecto Privado Aspecto Público

Protocolo

é uma coleção de
Definição da classe

Variáveis de Métodos são nomes Mensagens

instância de

pertence a uma
define um conjunto é implementado
de valores para por conjunto um
suas Objeto que dispara um
de

tem

Estado OID Procedimento

(único)

Figura 2.10 Sumário da características de orientação a objeto

Para entender melhor os conceitos que foram discutidos anterior a figura 2.10 resume as
características de objeto.

4.4.2.7 SUPERCLASSE, SUBCLASSE E HERANÇA

Classes são organizadas em hierarquia de classes. Uma hierarquia de classe assemelha-se a

uma árvore de cabeça para baixo na qual cada classe possui somente uma classe-pai. Uma
hierarquia de classe é conhecido como uma “class lattice” se suas classes puderem ter mais de um
pai. O termo classe é usado para categorizar objetos em grupos de objetos que possuem
características comuns. Por exemplo, uma classe automóvel inclui carros de luxos e, também, carros
populares. A figura 2.11 ilustra a generalização instrumentos musicais que inclui as
especialização instrumento de cordas e instrumentos de sobro.
A hierarquia de classe introduz um poderoso conceito da orientação a objeto conhecido com
herança. Herança é a habilidade de um objeto dentro de uma hierarquia herdar a estrutura de
dados e procedimentos (métodos) de uma acima na hierarquia. Na figura 2.11 a classe piano herda
a estrutura de dados e os métodos da superclasse instrumentos de corda e de instrumentos musicais.
E é através da herança que sistemas de orientação a objeto permite a reusabilidade de código.
Existem duas variações de herança: a simples e a múltipla.

32
 Instrumentos musicais superclasse

superclasse/
Instrumentos de corda Instrumentos de sobro subclasse

piano violino guitarra corneta flauta subclasse

Figura 2.11 A hierarquia de classe instrumentos musicais

4.4.2.7.1 HERANÇA SIMPLES

A herança simples existe quando uma classe tem somente um pai imediato. Na hierarquia de
instrumentos musicais as heranças ilustradas na figura 2.11 são do tipo simples. A maioria dos
sistemas suportam herança simples. Quando o sistema envia uma mensagem para um objeto da
classe, a hierarquia inteira é pesquisada para comparar o método, usando a seguinte seqüência:
1 - Busca a classe a qual o objeto pertence.
2 - Se o método não é encontrado, então busca na superclasse.
O processo de busca é repetido até que uma das situações abaixo ocorra:
1 - O método é encontrado.
2 - O topo da hierarquia é encontrado. O sistema gera uma mensagem indicativa de que o
método não foi encontrado.

4.4.2.7.2 HERANÇA MÚLTIPLA

A herança múltipla existe quando uma classe possui dois ou mais pais. Os objetos da classe
herda as características de suas superclasses. A figura 2.12 ilustra que uma classe pode ser derivada
de várias superclasses localizadas um nível acima na hierarquia de classes.

Veículo motorizado Bicicleta superclasses

motocicleta subclasse

Figura 2.12 Herança múltipla

33
4.4.2.8 SOBREPOSIÇÃO DE MÉTODOS E POLIMORFISMO

Podemos sobrepor a definição de métodos da superclasse pela definição de métodos a nível

da classe. Para ilustra a sobreposição de métodos, vamos utilizar a hierarquia de classes empregados
descrita na figura 2.13.

empregado
Variável de instância: salário
Método: bonus = salário * 0.05

Variável de instância: Pago_vôo_acumulado

Método: bonus = pago_vôo_acumulado * 0.05
piloto mecânico

Figura 2.13 Sobreposição de método na hierarquia de classe empregado

Vamos examinar o exemplo apresentado na figura 2.13, note que definimos um método
denominado bônus para calcular a gratificação de natal para todos os empregados. A computação
do bônus é especifica para cada categoria de empregado. No caso apresentado, com exceção de
piloto, um empregado recebe uma gratificação de salário igual a 5 porcento de seu salário. Pilotos
recebem de gratificação de natal o acumulado pago por vôo que é muito melhor do que o salário
anual. Por definição o método bônus da classe de piloto substituirá o método herdado na classe
empregado, e o método bônus será sobreposto na classe piloto pelo seu método local e será
aplicado a todos os objetos da classe. Contudo, a redefinição do método bônus na classe piloto não
afetará o cálculo da gratificação dos demais empregados. De forma contrária a sobreposição de
métodos, polimorfismo permite que diferentes objetos respondam a mesma mensagem de forma
diferente. Polimorfismo é um aspecto muito importante no ambiente de orientação a objetos porque
ele permite que objetos comporte-se de acordo com suas características específicas. Em termos de
orientação a objeto, polimorfismo significa:
1 - Que podemos usar o mesmo nome para definir um método em diferentes classes na
hierarquia de classes.
2 - O usuário pode enviar uma mesma mensagem para diferentes objetos que pertence a
diferentes classes e sempre gerar uma resposta correta.

4.5 - IDENTIDADE DE OBJETO

É a propriedade que o objeto tem que o distingue dos demais. O tipo mais comum de
identidade de objeto nas linguagens de programação, nos bancos de dados e nos sistemas
operacionais são os nomes de objetos definidos pelo usuário final. Utilizando a identidade do
objeto, os objetos podem conter outros objetos ou se referir a eles. Isso elimina a necessidade de
utilizar nomes de variáveis que não tenham suporte de identidade de objeto, mas apresenta algumas
limitações práticas. Uma limitação é que um único objeto pode ser acessado de várias maneiras:
assim, um objeto pode ser relacionado a diferentes variáveis o que torna difícil saber se se refere ao
mesmo objeto.

4.5.1 NOME DE CAMINHO DO SISTEMA OPERACIONAL

34
 Um método utilizado para a identificação de objetos são os nomes de caminhos do Sistema
Operacional como o UNIX e DOS. Esses SO possuem estruturas de diretórios hierárquicas nas
quais cada diretório contém um grupo de arquivos e possivelmente outros diretórios. O nome do
arquivo deve ser único no diretório e cada arquivo é acessível por um caminho.

4.5.2 CHAVES IDENTIFICADORAS

Um outro método de identificação de objetos é utilizar chaves exclusivas ou chaves

identificadoras. Esse mecanismo é normalmente utilizado em SGBD’s. P.ex: para um
armazenamento de tabela de banco de dados de funcionário a chave identificadora poderia ser o
nome completo. Para itens de armazenamento em tabelas no banco de dados, a chave identificadora
será o número do item.
Há três problemas principais relacionados com o uso de chaves identificadoras para a
identidade do objeto.
1 - Modificação das chaves identificadoras: a chave identificadora não pode (ou não deve)
mudar, embora sejam dados descritos pelo usuário final.
P.ex: o nome de um gerente de vendas é chave identificadora de gerente de vendas e
pode estar duplicado no objeto vendedor como um atributo.
Problema: ao mudar o gerente de vendas deve ter o cuidado de alterar suas referências.
2 - Não-uniformidade: é que as chaves identificadoras de diferentes tabelas possuem
diferentes tipos (inteiro, ponto flutuante e string de caracteres).
P. Ex: A companhia X utiliza números da previdência para identificar empregado.
Enquanto a companhia Y utiliza uma combinação de caracteres alfanumérico.
Problema: Uma fusão dessas duas empresas exigiria uma mudança em uma das chaves.
3 - Junções Antinaturais : recuperação de informações através do cruzamento de tabelas
distinta para recuperar informações. A quebra em tabelas é resultante do processo de normalização
que foge a realidade (na maioria dos casos).

4.6 - RESTRIÇÕES DE INTEGRIDADE DE BANCO DE DADOS ORIENTADO A OBJETO

Por meio de transações, os sistemas de gerenciamento de bancos de dados mapeam um

estado de banco de dados coerente (correto) em outro. A coerência do banco de dados é
normalmente expressa por predicados, ou condições, no estado corrente do banco de dados. Os
predicados podem também se aplicar a objetos ou valores de atributo no banco de dados. Os
predicados que capturam a coerência de um banco de dados são chamados restrições de integridade.
Geralmente, várias restrições de integridade devem ser forçosas em um estado de banco de dados
para garantir sua coerência. Veja alguns exemplos:

• A idade de uma pessoa não pode ser um número negativo.

• Um balancete deve ser inferior ou igual à soma dos depósitos.
• Se um empregado trabalha para um departamento, deve haver um registro desse
departamento no banco de dados.

35
 • O número da previdência social de cada empregado deve ser exclusivo no conjunto de
todos os empregados.
• Uma pessoa deve ter um nome, e este atributo não pode ficar vazio ou nulo.

Como todos esses exemplos sugerem, muitos tipos de restrições de integridade devem ser
impostos a um banco de dados para manter sua coerência.
Sistemas de bancos de dados relacionais possuem diversas categorias de restrições de
integridade, como restrições de integridade referenciais, domínios e restrições não-nulas (NOT
NULL). A maiorias dessas restrições valem também em bancos de dados orientados a objeto,
embora, devido às construções orientadas a objeto e ao expressivo poder do modelo de objetos,
algumas restrições não sejam mais relevantes (como as restrições referencias) ou tomem uma forma
diferente (como os domínios). Na verdade, os conceitos orientados a objeto dos bancos de dados
orientados a objeto introduzem outros tipos de restrição de integridade ou especificações de
restrição de integridade.
Entre as restrições de integridade dos bancos de dados orientados a objeto discutiremos as
seguintes:
1. Restrições de chave exclusiva/primária.
2. Restrições referenciais a existenciais.
3. Restrições NOT NULL.
4. Restrições de integridade de domínio.
5. Gatilhos (triggers).

4.6.1 - RESTRIÇÕES DE CHAVE

Nos bancos de dados relacionais, é comum a especificação de chaves, onde uma ou mais
chaves são especificadas para várias tabelas de bancos de dados. Nos bancos de dados orientados a
objeto, as chaves também são relevantes para todo tipo de grupo de tuplas ou instâncias da classe.
Conjunto de instâncias de uma classe podem ser a extensão da classe ou um objeto do conjunto
cujos elementos são especificados para serem instâncias da classe. Em ambos os casos, será útil
identificar um ou mais atributos como chaves, ambos como uma restrição e como uma dica para
fornecer pesquisas mais rápidas quando valores de chave forem fornecidos.
Portanto, uma chave é um ou mais atributos de uma classe que identifica exclusivamente
uma instância da classe em um grupo. Se uma chave consiste em mais de um atributo (coluna), ela é
chamada chave composta. A figura 2.14 ilustra duas chaves candidatas: o número do seguro social e
o nome do funcionário.

funcionario
chave número do nome
candidata seguro social
nome do
inteiro
funcionario
primeiro último

composiçao
caracter caracter de chave
candidata

36
 Figura 2.14 Chaves candidatas para a classe funcionário

4.6.2 RESTRIÇÃO REFERENCIAL EXISTENCIAL

Há um outro tipo de restrição para modelos baseados na identidade , que está relacionado a
restrições de integridade referencial: a restrição de identidade existencial. O objetivo de restrições
existenciais é indicar que, se um objeto é compartilhado referencialmente, então ele possui um
domínio “ativo”, ou seja, um grupo específico de objetos da mesma classe que no momento
existem. A restrição existencial indica que o objeto deve sempre existir em seu domínio ativo. A
figura 2.15 ilustra esta restrição para um objeto funcionário e número_telefone_serviço. Este
número é associado ao telefone de uma classe escritório, a existência da numero_telefone_serviço
esta vinculada a existência do telefone no escritório.

funcionário escritório

n úm ero do telefon e n úm ero do

de servico telefon e

string
RE

Figura 2.15 Restrição existencial – RE

4.6.3 RESTRIÇÃO NOT NULL

Os conceitos de um valor nulo(NULL) e uma restrição não-nula (NOT NULL) são úteis em
bancos de dados orientados a objeto. Para suportar a restrição não-nulo, o banco de dados orientado
a objeto deve suportar valores nulos. Um valor nulo representa um valor de atributo ausente.
Em muitas aplicações, valores nulos são essenciais para suportar análise estatística. Por
exemplo, suponha que desejemos obter a pontuação média em teste de todos os alunos de uma
classe. Algumas pontuações serão nulas, isto é, estarão ausentes ou indisponíveis por razões
diversas e não poderão ser consideradas.
Em geral, quando um atributo ou uma coluna é declarado como do tipo T, os valores de
atributo da classe podem ser valores T ou nulos. Por exemplo, se a idade for do tipo inteiro, então a
idade de uma pessoa poderá ser um valor maior ou igual a zero ou nulo. O nulo representa ausência
de informações ou desconhecida.

4.6.4 REGRAS DE INTEGRIDADE DE DOMÍNIO

São regras declaradas como predicados que não devem ser violados. Esta associada ao
domínio do estado do objeto. Ou seja, que valores são possíveis para as variáveis de instância dos
objetos valorados na classe. Exemplo: Os valores válidos para dias da semanas são entre 0-6, onde
0 é domingo e 6 é sábado.

37
4.6.5 GATILHOS (TRIGGERS)

São procedimentos ou ações no banco de dados que são ativadas quando determinadas
condições são satisfeitas. Um gatilho, conceitualmente, consiste em um componente condição e um
componente ação.

Exemplo:

Trigger Condição Ação

Abort_limit Atingir 75% do log file remover as transações mais
antigas não efetivadas.
idle_time_limit Ocioso durante 15 minutos remover a sessão ociosa

4.7 - TRANSAÇÕES, CONCORRÊNCIA, RECUPERAÇÃO, VERSIONAMENTO DE

BANCO DE DADOS ORIENTADO A OBJETO

Um dos mais importantes recursos dos sistemas de gerenciamento de banco de dados é o

compartilhamento concorrente dos recursos, conforme figura 2.16. Os SGBDOO’s permitem que
objetos e definições de objetos possam ser utilizados por vários usuários ao mesmo tempo. Para
controlar os acessos concorrentes, os SGBDOO’s utilizam várias técnicas de controle de
concorrência e gerenciamento de transações.
Algumas questões precisam ser consideradas no que diz respeito ao acesso concorrente a
objetos.
1) Em algumas situações, diferentes usuários podem tentar atualizar o mesmo objeto ao
mesmo tempo;
2) Em outras situações, diferentes grupos de usuários podem querer cooperar para a
construção de vários objetos.
3) Em alguns casos, os usuários desejam realizar várias atualizações no objeto e tornar
visíveis os resultados das atualizações somente depois que todas as operações se
concluírem.

U s u á r io 1 U s u á r io 2

Figura 2.16 Acesso concorrente a objetos

38
 Dadas as situações, o sistema de banco de dados em questão deve garantir que o banco de
dados seja mantido em um estado coerente na presença de manipulações de objetos conflitantes e
em conjunto. A manipulação de objetos é via transações no BD. Tradicionalmente, uma transação é
uma seqüência de ações sobre os objetos persistentes e satisfaz as propriedades: atomicidade,
coerência, isolamento e durabilidade (ACID).

1) Atomicidade: Uma transação é um bloco de operações executado inteiramente ou nada é

executado. Em outras palavras, ou toda a seqüência de operações é aplicada ao BD ou nada
é feito.
2) Coerência: é a preservação de todas as restrições semânticas do BD. Um banco de dados é
considerado coerente se todas as restrições de integridade do estado do BD forem
satisfeitas. Supõe-se que a execução de uma transação na ausência de interferência de
outras transações concorrentes leve o banco de dados de um estado coerente a outro. Na
figura 2.17 é ilustrado esta coerência.
3) Isolamento: A execução de transações concorrentes que manipulam os mesmos objetos
compartilhados pode causar anomalias se as operações de intercalação não forem
protegidas umas das outras. O isolamento trata da segurança fornecida pelo sistema de
banco de dados em relação aos conflitos entre transações concorrentes. Há uma relação
inversa entre o nível de isolamento e a capacidade de processamento de transações
concorrentes. Mais especificamente, quanto mais as transações ficarem isoladas umas das
outras, maior a probabilidade de conflitos e, daí, abortos de transações. As transações
abordadas consomem recursos, elas devem ser tentadas novamente.

Estado S1 Estado S2

Pastas Pastas

Documentos transação Documentos

Funcionarios Funcionarios

Toda regra de integridade é

satisfeita

Figura 2.17 As transações mantêm o BD coerente

Os níveis de isolamento.
a) capacidade de serialização: é o maior nível de isolamento possível sem comprometer a
coerência do BD. As transações são serializáveis se a execução intercalada de suas
operações produzir os mesmos efeitos no BD que sua execução em ordem serial. A figura
2.18 ilustra as transações de T1 a T5.

39
 T1
T2
T3
Execução concorrente
T4 de T1, ..., T5

T5

T1 T2 T3 T4 T5

T1 T3 T2 T5 T4

Figura 2.18 Serialização da execução de transações

b) Leitura “sujas” (Dirty page) : é o nível mais restrito de isolamento do que a capacidade
de serialização é permitir leituras “sujas”. Significa: que uma transação T1 leia os estados
do objeto O1 modificados pela transação T2 antes de T2 terminar.

4) Durabilidade : é garantir que as atualizações de transações efetivadas nunca se percam. Isto

significa, que as transações efetivadas podem ser recuperadas no caso de o sistema ou o
meio apresentarem falhas. Uma vez que se informe ao usuário ou à aplicação que a
transação se efetivou, o sistema de banco de dados deverá fornecer redundância suficiente
para garantir que as atualizações serão preservadas apesar das falhas do sistema.
4.7.1 TRANSAÇÕES DE APLICAÇÕES OODB

As propriedades ACID são aplicáveis tanto para aplicações de banco de dados convencional
(relacional) como para aplicações de BDOO. Vários recursos são, no entanto, mais característicos
de aplicações de banco de dados avançadas, como o CAD, o CAM, CASE e escritórios inteligentes.

4.7.1.1 TRANSAÇÕES DEMORADAS

Transações que envolvem o acesso a vários objetos e consume um tempo relativamente

longo (horas ou dias) para serem concluídas. A essas transações estão associados os conceitos de
check-in e check-out.
Check-out: quando inúmeras operações necessitam ser realizadas em um objeto complexo
por um período longo de tempo.
Check-in: processo inverso ao check-out, quando as operações são concluídas o objeto é
disponibilizado para ser acessado de maneira concorrente.

4.7.1.2 TRANSAÇÕES ANINHADAS

É um modelo utilizado para tratar transações longas. Consiste de um conjunto de

subtransações, chamadas de transações-filhas, que são componentes de uma transação maior,

40
denominada transação-pai. As subtransações são isoladas umas das outras e satisfazem as
propriedades. ACID. A figura 2.19 ilustra um transação aninhada.

Transação longa

Transação concluída

Figura 2.19 Transação demorada com subtransações aninhadas

41
4.7.2 CONTROLE DE CONCORRÊNCIA

São utilizadas estratégias para a sincronização de operações de acesso e atualização

intercaladas em transações concorrentes. Os níveis de isolamento das transações são capturados no
mecanismo de controle de concorrência do SGBD. Tradicionalmente, três estratégias principais de
controle de concorrência têm sido utilizadas:
1) Os algoritmos pessimistas: pressupõem que transações concorrentes provavelmente
conflitarão e portanto adquirem bloqueios antes das operações de acesso e atualização.
2) Os algoritmos otimistas: pressupõem que as transações provavelmente operarão sem
conflitos e somente na hora de efetivação são feitas conferências para garantir o isolamento
das transações.
3) Versionamento: é criado uma nova versão de um objeto para a atualização. As transações
que só lêem objetos sempre poderão acessar um posição anterior e coerente do BD.
Há muitas variações e combinações dessas três estratégias fundamentais. Estratégias
baseadas no bloqueio são de longe os algoritmos mais utilizados nos SGBD’s. Os SGBDOO’s
normalmente permitirão que o usuário ou o programa de aplicação bloqueie ou faça o check-out
explícito dos objetos.

4.7.2.1 ESTRATÉGIAS DE BLOQUEIO

A maioria dos algoritmos de controle de concorrência utiliza o bloqueio para sincronizar a

execução de transações concorrentes. Cada objeto persistente pode ser bloqueado. Isto normalmente
é feito por meio de uma tabela de bloqueio, que contém os identificadores de objeto dos objetos
bloqueados. Antes que uma transação possa acessar um objeto, ela deve solicitar um bloqueio. Se
pelo menos uma outra transação estiver mantendo um bloqueio no momento, a transação terá de
aguardar até que o bloqueio seja liberado.

1) Bloqueio de duas fases: é normalmente utilizado para garantir que as transações sejam
serializáveis. Esse protocolo separa claramente uma transação em uma fase de crescimento
e outra de redução. Durante a fase de crescimento, todos os bloqueios devem ser
adquiridos, possivelmente de forma incremental. Durante a fase de redução, todos os
bloqueios são liberados, possivelmente de forma incremental. O seguinte protocolo de
bloqueio satisfaz ao protocolo de bloqueio de duas fases:
a) antes de realizar uma operação de leitura em um objeto, a transação deve adquirir um
modo de bloqueio compartilhado para esse objeto.
b) antes de realizar uma operação de gravação em um objeto, a transação deve adquirir um
modo de bloqueio exclusivo para esse objeto.
c) depois de liberar um bloqueio, a transação não deve mais adquirir bloqueios.

2) Bloqueio de multigranularidade: é a existência de diferentes níveis de bloqueio

(“granulo”). Permite que diferentes transações estabeleçam bloqueios em diferentes níveis.
O objetivo é minimizar o número de bloqueios a serem estabelecidos ao acessar o BD.
Exemplo: quando a maioria das instâncias da classe é acessada, é mais interessante
bloquear a classe toda do que uma instância por vez. O objetivo fundamental do protocolo

42
 de bloqueio de multigranularidade é minimizar o número de bloqueios a serem
estabelecidos ao acessar o banco de dados.
3) Bloqueio de hierarquia de classe: as classes em um BDOO são organizadas em hierarquias.
O bloqueio em uma superclasse bloqueia implicitamente todas as suas subclasses no
mesmo modo de bloqueio.
4) Bloqueio de intenção: é estabelecer intenção de bloqueio na classe antes de estabelecer
operação de bloqueio nas instâncias. Assim, uma transação deve estabelecer um bloqueio
com intenção de leitura (intention-read : IR) em uma classe antes de estabelecer bloqueios
de leitura em instâncias da classe. Da mesma forma, uma transação deve estabelecer um
bloqueio com intenção de gravação (intention-write: IW) em uma classe antes de
estabelecer bloqueios de gravação nas instâncias da classe.
Às vezes, uma transação pode querer ler muitas instâncias de uma classe e modificar
somente um número pequeno dessas instâncias. Isto pode ser feito pelo estabelecimento de
um bloqueio de leitura com intenção de gravação (RIW) na classe e, somente na hora de
realizar a gravação o bloqueio é estabelecendo. Na tabela 2.3 é mostrada uma matriz de
compatibilidade para diferentes tipos de bloqueios em uma esquema de bloqueio de
multigranularidade.

Observações importantes:

1 - Os BDOO possuem dois grânulo de bloqueios: classes e instâncias. Cada classe ou

instância pode ser bloqueada no modo compartilhado ou no modo exclusivo.
2 - Quanto mais “grosso” o nível de bloqueio menor concorrência e maior “overhead” do
sistema.

R W IR IW RIW

R S N S N N

W N N N N N

IR S N S S S

IW N N S S N

RIW N N S N N

Tabela 2.3 Matriz de compatibilidade para bloqueio de multigranularidade

4.8. VERSIONAMENTO

O gerenciamento de versão em um banco de dados orientado a objeto consiste em

ferramentas e construções que automatizam ou simplificam a construção e a organização de versões
ou configurações. Sem essas ferramentas, caberia ao usuário organizar e manter as versões. Uma
maneira de fazer isso seria utilizar uma convenção de nome que controlasse as várias versões do

43
mesmo objeto e a relação das versões entre si (a árvore de derivação). Esse procedimento é muito
trabalhoso e predisposto a erro. Assim, em aplicações de projeto complexas, o gerenciamento de
versão é um utilitário extremamente útil e poderoso.
Muitas aplicações de engenharia e de projeto utilizam o versionamento para criar
progressivamente mais versões aperfeiçoadas do objeto de projeto. Em aplicações de engenharia de
projeto, os objetos são normalmente armazenados em um repositório central (persistente). Os
projetistas fazem o check-out do objeto persistente a partir do banco de dados, trabalham nele e,
quando acharem que possuem a melhor implementação, fazem o check-in do objeto como uma
versão diferente. Depois que o objeto versionado é criado, novas versões do objeto podem ser
criadas de forma linear ou em grafo. A principal propriedade comum a todas as versões do mesmo
objeto é a identidade do objeto. Por toda a história versionada, um objeto pode passar por muitos
estados e até por modificações estruturais.
Se todas as versões de um objeto forem criadas seqüencialmente, obteremos um conjunto de
versões lineares. No versionamento geral, no entanto, vários projetistas podem criar versões
alternativas de um objeto. Na figura 2.20 é ilustrado o conjunto de versões de um objeto O1. Onde
cada versão possui sucessores e predecessores.

V1: Versão original

V3
Versões alternativas V2

V6
V4 V5

V7: Versão final

Figura 2.20 Conjunto de versões de O1

Por exemplo, para criar uma versão no SGBD Iris, um usuário deve primeiro nomear e fazer
um check-out dos sucessores e predecessores de uma versão. Usando a figura 6.1, temos: O
sucessor(v2) retornará todos os sucessores de v2:{v4, v5, v7} e o predecessor (v6) retornará os
predecessores de v6:{v3, v1}.

5 BANCO DE DADOS DISTRIBUÍDO

Banco de dados distribuído é um banco de dados único que pode ser compartilhado por
múltiplos computadores em uma rede. As aplicações acessam o banco de dados local e remoto por
processamento distribuído, e com transações em tempo real. As aplicações de banco de dados
distribuídos podem ser caracterizadas como aplicações de banco de dados distribuído. A
complexidade do sistema de banco de dados distribuído é transparente ao usuário final, porque ele é
tratado como um banco de dados lógico único pelo SGBDD – Sistema de Gerenciamento de Banco
de Dados Distribuído.

44
5.1 EVOLUÇÃO PARA SGBDD

A idéia de banco de dados distribuído surgiu da necessidade de acesso a dados corporativos

de forma rápida. Os fatores que contribuíram para a implementação de um ambiente
descentralizado foram: as operações de negócios tornaram-se descentralizada, a competitividade
crescente em um nível global , a demanda do cliente favorecendo a descentralização dos dados, o
surgimento do microcomputador com baixo custo substituindo o computador de grande porte
(“mainframes”), a adoção de redes locais e alto número de aplicações com compartilhamento de
dados. O banco de dados centralizado quanto acessado por múltiplos usuários simultaneamente fica
comprometido em seu tempo de resposta (“performance”). Em função das variáveis relacionadas
houve o surgimento do SGBDD.

5.1.1 VANTAGENS DO SGBDD

• Dados localizados mais próximos da demanda – os dados são distribuídos de acordo com a
requisição do negócio;
• Acesso mais rápido – os dados são distribuídos em vários locais;
• Processamento mais rápido – o processamento dos dados em diferentes locais não
sobrecarrega o sistema;
• Facilidades de ampliações – novos pontos de dados distribuídos podem ser adicionados à
rede sem afetar as operações normais;
• Melhora na comunicação – comunicação mais rápida e melhor entre as unidades de
negócios e os clientes, favorecendo a independência de informações locais necessárias aos
negócios;
• Redução nos custos de operações – os custos com as linhas de comunicação entre micros
ficam menores devido a distribuição dos dados.
• Menor falha – no caso de falha de alguma localidade, não afeta o sistema como um todo
(na maioria das vezes).

5.1.2 DESVANTAGENS DO SGBDD

• Complexidade de gerenciamento e controle – é mais complexo que o gerenciamento

centralizado, porque os dados são tratados diferentemente nas localidades. O
administrador de banco de dados tem que ter a habilidade para coordenar todas as
atividades do banco, como: controle de concorrência, segurança, becape, recuperação,
otimização de consultas e seleção de caminhos de acesso.
• Segurança – os problemas de segurança dos dados é proporcional a quantidade de
servidores, e a responsabilidade de gerenciamento dos dados é dividida para mais de
uma pessoa nas localidades. Em função das LAN’s e internet exigi-se procedimentos de
segurança, como firewalls;

3.2 PROCESSAMENTO DISTRIBUÍDO E BANCO DE DADOS DISTRIBUÍDO

Um banco de dados pode possuir processamento e dados distribuído. Um SGBD pode

armazenar dados em um único local (banco de dados centralizado) ou em diversos locais (banco de
dados distribuído) e pode suportar processamento em um local ou em vários locais.

45
5.2.1 PROCESSAMENTO DISTRIBUÍDO

Consiste em separar o processamento lógico do banco de dados entre dois ou mais

computadores independentes conectados na rede. Por exemplo, o controle de vendas de uma
empresa que possua mais de uma filial, mais com controle de entrada e saída de produtos
centralizado. Neste caso, o processamento da venda é local a cada filial e banco de dados
centralizado. Na figura 3.1 é ilustrado este ambiente.

Computador A

SGBD

Banco de
dados de
vendas

Brasília

Rede de
Comunicação
Computador B Computador C

São Paulo Taguatinga

Figura 3.1 Processamento distribuído

5.2.2 BANCO DE DADOS DISTRIBUÍDO

Um banco de dados distribuído é um banco de dados armazenado em múltiplos

computadores, porém em termos de visão da aplicação aparece como sendo um único banco de
dados. Na figura 3.2 é ilustrado um ambiente de banco de dados distribuído.
Os banco de dados distribuídos não estão sendo usados em todo o seu potencial, pois há
muitos pontos a serem definidos antes de se obter toda a flexibilidade e capacidade dos SGBDD’s.

5.3 CARACTERÍSTICAS DE UM BANCO DE DADOS DISTRIBUÍDO

Um sistema de banco de dados distribuído requer algumas características funcionais que

podem ser agrupadas e descritas como um conjunto de características transparentes, que dar ao
usuário a sensação de estar utilizando o sistema sozinho. Isto é, o usuário pensa que estar

46
trabalhando em um SGBD centralizando escondendo toda a complexidade de um SBDB distribuído
com total transparência. Segue as características transparentes:
• Distribuição transparente – permite que os vários segmentos de banco de dados seja
tratado como um único banco de dados lógico. O usuário não precisa saber que os dados
estão particionados em diferentes localidades.
• Transação transparente – permite a atualização dos dados em diversas localidades na
rede, garantindo que a transação seja completada ou abortada para manter a integridade
dos dados.
• Falha transparente – garante o funcionamento do sistema caso ocorra falha em um
determinada localidade.
• Performance transparente – permite que o sistema tenha a performance de um SGBD
centralizado, minimizando ao máximo a degradação pelo uso da rede, buscando sempre o
melhor caminho para os acessos remotos.
• Heterogeneidade transparente – permite a integração de diferentes SGBD’s locais
(relacional, híbridos, objeto e outros) em um esquema global, transferindo as requisições
do esquema global para o esquema do SGBD alvo.

Computador A

SGBD

Banco de
dados de
vendas

Brasília

Rede de Computador C
Computador B Comunicação

SGBD SGBD

Banco de Banco de
dados de dados de
vendas vendas

São Paulo Taguatinga

Figura 3.2 Banco de dados distribuído

47
6 A ARQUITETURA CLIENTE-SERVIDOR PADRÃO CORBA

A arquitetura comum para atender solicitações de objetos (Common object request broker
architecture – CORBA) é o mais importante e ambicioso projeto de “middleware” (servidor de
regras de negócio) já empreendido pela industria de computadores. O corba é produto de um
consórcio, denominado OMG (Object Management Group), que inclui em torno de 800
companhias, representado o espectro completo de industrias de computadores. A notável exceção é
a MICROSOFT, que possui seu próprio padrão de objetos distribuídos, denominado DCOM
(Distributed Component Object Model). Para os demais fabricantes de computadores o corba é a
próxima geração de middleware.
O barramento de objetos corba – ORB (Object Request Broker) define a forma de seus
componentes e como eles operam. Consequentemente, pela escolha de um barramento de objetos
aberto, a industria está, também, escolhendo criar campo de execução aberto para seus
componentes. O que faz o corba ser tão importante é que ele define “middleware” com o potencial
de incorporar todas as outras formas de “middleware” existentes no mercado. O middleware é um
termo vago que engloba todos os software de distribuição necessário para suportar as interações
entre o cliente e o servidor, ele é o bloco intermediário na arquitetura cliente/servidor conforme
pode ser visto na figura 4.1. Corba utiliza objetos padrões para tratar as aplicações existente no
barramento, e prover uma base sólida para os novos componentes. Ele especifica um conjunto
extenso de serviços relativos ao barramento para criar e apagar objetos, acessá-los por nome,
armazená-los em repositórios persistentes, externalizando seus estados, e definindo relacionamentos
aleatórios “ad hoc” entre eles.

Cliente Middleware Servidor

Figura 4.1 Os três blocos básicos da arquitetura cliente/servidor

6.1 OBJETOS DISTRIBUÍDOS

Talvez o segredo do sucesso da OMG seja criar especificações de interface e não código. As
especificações são escritas em Linguagem de Definição de Interface (IDL) que define os limites dos
componentes. Os componentes escritos em IDL deveriam ser portáveis através de linguagens,
ferramentas, sistema operacional e rede. E com a adoção da especificação em dezembro de 1994,
estes componentes passaria a interoperar com os agentes de objetos padrão CORBA.

6.2 O QUE É UM OBJETO CORBA DISTRIBUÍDO?

Objetos corba são “porções inteligentes” que podem viver em qualquer lugar na rede. Eles
são empacotados como componentes binários que os clientes remotos passam a acessar via
invocação de métodos. A linguagem e o sistema operacional usados para criar os objetos nos
servidores são totalmente transparentes ao cliente. Os clientes não necessitam saber onde os objetos
distribuídos residem ou qual sistema operacional o executa. Os objetos podem estar no mesmo

48
processo do cliente ou em qualquer maquina da rede intergalática. Os clientes não necessitam saber
como os objetos do servidor estão implementados. Por exemplo, um objeto servidor poderia estar
implementado como um conjunto de classes C++, ou o poderia ser implementado como milhares de
linhas de código COBOL, o cliente não sabe a diferença. O que o cliente necessita conhecer é a
interface pública dos objetos servidores. A interface é a ligação entre cliente e servidor.

6.3 TUDO ESTÁ NA IDL

Corba usa um padrão de IDL comprometida em especificar os limites dos componentes. A

interface, também, é comprometida com os potenciais clientes. Isto significa que o corba não prover
detalhes de implementação, a IDL pode ser utilizada para definir API’s (Application Program
Interface). Os métodos especificados na IDL podem ser escritos ou invocados por qualquer
linguagem que esteja preparada com o padrão corba – atualmente são C, C++, ADA,
SMALLTALK, COBOL e JAVA. Os programadores utilizam os objetos corba através de
construções nativas da linguagem. A IDL prover uma interface independente do Sistema
Operacional e das linguagens para todos os serviços e componentes que residem no barramento do
corba. A IDL permite que objetos clientes e servidores, escritos em linguagens diferentes, possam
operar entre si. Na figura 4.2 é ilustra a arquitetura da IDL corba.

C Java C Java

Client Stub Server Skeleton

CORBA IIOP ORB

Figura 4.2 A IDL do corba prover ligação entre linguagens na arquitetura Cliente/Servidor

A ambição do corba é padronizar em IDL todos os “middleware” cliente-servidor e todos os

componentes que são manipulados pelo ORB (Object request broker). “Torna tudo prego e é dado o
martelo”.

g O “prego” é a IDL corba. A IDL permite provedores de componentes especificar, na

linguagem de definição padrão, a interface e estrutura de objetos que ela suporta.

49
 ⎢ Para algum objeto requerer alguma coisa de outro objeto, ele deve conhecer a interface do
objeto alvo.

⎢ O repositório de interface corba contém a definição de todas essas interfaces. Ele contém
metadados que permite componentes descobrir outro objeto dinamicamente em tempo de
execução.

g O “martelo” inclui o conjunto de serviços distribuídos que os provedores OMG fornecem.

Estes serviços determinam quais objetos estão na rede, quais métodos eles provêem e quais os
adaptadores de interface eles suportam.

7 BIBLIOGRAFIA

1 – [COR 97] Coronel, Carlos & Rob, Peter. DATABASE SYSTEMS:design, implementation, and
management. 3ª edição, Course Technology, 1997, Canada.
2- [ORF 97] Orfali, Robert & at.all. The Essential Client/Server Survival Guide. 2ª edição, Wiley,
1997, New York.
3 – [ORF 98] Orfali, Robert & Harley, Dan. Client/Server Programming with Java and Corba. 2ª
edição, Wiley, 1998, New York.
4 – [KHO 94] Khoshafian, Setrag. Banco de dados orientado a objeto. IBPI Press, 1994, Rio de
Janeiro.
5 – [KOR 89] Korth, Henry F. Sistema de banco de dados. McGrall-Hill, 1989, São Paulo.

50