ADMINISTRAÇÃO

DE BANCO
DE DADOS

BANCO DE DADOS
NÃO – CONVENCIONAIS

RECIFE
2018
 DAVID NASCIMENTO – MATRÍCULA:
JOÁS MARQUES GONÇALVES FILHO – MATRÍCULA:2016202111

ADMINISTRAÇÃO DE BANCO DE DADOS

BANCO DE DADOS NÃO-CONVENCIONAIS

Trabalho de Conclusão de 4º período ao Curso de

Tecnólogo em Sistemas para Internet , da Faculdade
São Miguel, como requisito parcial para obtenção de
nota na 2ª unidade do período de Administração de
Banco de Dados.

ORIENTADOR ( a ) : Professora Márcia Seabra

RECIFE
2018
1. Introdução
Os bancos de dados e a sua tecnologia estão provocando um grande impacto no crescimento
do uso de computadores. É viável afirmar que eles representam um papel crítico em quase
todas as áreas em que os computadores são utilizados, incluindo negócios, comércio
eletrônico, engenharia, medicina, direito, educação e as ciências da informação, para citar
apenas algumas delas. A palavra banco de dados é tão comumente utilizada que, primeiro,
devemos defini-la. Nossa definição inicial é bastante genérica. Um banco de dados é uma
coleção de dados relacionados. Os dados são fatos que podem ser gravados e que possuem
um significado implícito. Por exemplo, considere nomes, números telefônicos e endereços de
pessoas que você conhece. Esses dados podem ter sido escritos em uma agenda de telefones
ou armazenados em um computador, por meio de programas como o Microsoft Access ou
Excel. Essas informações são uma coleção de dados com um significado implícito,
consequentemente, um banco de dados.
A definição de banco de dados, mencionada anteriormente, é muito genérica. Por exemplo,
podemos considerar o conjunto de palavras que formam esta página como dados relacionados,
portanto, constituindo um banco de dados. No entanto, o uso do termo banco de dados é
geralmente mais restrito. Possui as seguintes propriedades implícitas:
• Um banco de dados representa alguns aspectos do mundo real, sendo chamado, às
vezes, de minimundo ou de universo de discurso (UoD). As mudanças no minimundo são
refletidas em um banco de dados.
• Um banco de dados é uma coleção lógica e coerente de dados com algum significado
inerente. Uma organização de dados ao acaso (randômica) não pode ser corretamente
interpretada como um banco de dados.
• Um banco de dados é projetado, construído e povoado por dados, atendendo a uma
proposta específica. Possui um grupo de usuários definido e algumas aplicações
preconcebidas, de acordo com o interesse desse grupo de usuários.
Em outras palavras, um banco de dados possui algumas fontes das quais os dados são
derivados, alguns níveis de interação com os eventos do mundo real e um público
efetivamente interessado em seus conteúdos.
Mas com o desenvolvimento de novas aplicações, a necessidade de armazenagem de
outros tipos de dados além dos convencionais, mostrou-se que os banco de dados tradicionais
possuíam algumas limitações. E por isso, novas modelagens de bancos de dados foram
desenvolvidas com o objetivo de atender a essas aplicações.
Esse trabalho apresenta o conceito básico de modelagem de banco de dados não
convencionais, a modelagem de banco de dados orientado a objeto. Na seção 2, apresentamos
alguns conceitos de bancos de dados convencionais, suas características e algumas de suas
dificuldades e limitações. Na seção 3, mostramos as categorias em que se dividem os bancos
de dados. Na seção 4, demonstramos alguns conceitos de bancos de dados não-convencionais,
de modelagem de banco de dados orientados a objetos, os aspectos desses bancos e exemplos
de aplicações utilizadas atualmente que usam este tipo de modelagem para adicionar seus
arquivos
2. Banco de dados Convencionais
Os modelos de dados e sistemas tradicionais, como relacionais, rede e hierárquico,
foram e são muito bem sucedidos no desenvolvimento de tecnologias de banco de dados,
necessárias para a maioria das aplicações de bancos de dados comerciais.
Fazendo uma breve definição sobre a modelagem banco de dados convencionais ( ou
relacionais ), podemos descrevê-los como uma modelagem relacional, onde é realizado um
mapeamento do MER ( modelo entidade/relacionamento) por meio de regras do próprio
mapeamento. E posteriormente, sua implementação é realizada em SQL ( Structured Query
Language, ou, Linguagem de consulta estruturada).
Esse tipo de modelagem de banco de dados domina o mercado atualmente. Eles tem se
tornado diariamente mais essenciais na sociedade moderna. Eles são desenvolvidos para as
denominadas aplicações tradicionais de banco de dados.
Qualquer que sejam essas aplicações, elas tem como objetivo realizar uma “ conversa”
entre usuários e dos dados, disponível de tal modo que venha a incluir todo usuário. Dentro de
uma empresa, deve garantir que os dados estejam disponíveis a toda hierarquia, com
informações precisas e consistentes, com acesso de acordo com o nível do indivíduo na
organização, e desenvolver métodos de cruzamentos de informações, facilitando a emissão de
relatórios e assim ter a noção de como andam os trabalhos dentro da empresa. Esses
bancos de dados devem ser projetados detalhadamente, verificando-se cada etapa, utilizando
sempre os mesmos mecanismos de normalização, relacionamento, classificação e outros
processos que devem garantir a integridade e a confiabilidade dos dados.
Como exemplo de bancos convencionais, podemos citar o comércio eletrônico. Neste
caso, uma aplicação web, que guarda informações sobre os usuários, seus gostos e produtos
mais visitados. Outro exemplo que é muito comum, é o registro de colaboradores nas
organizações. São salvas as informações pessoais dos funcionários, e suas informações dentro
da organização, como horários, folha de pagamento, folha de ponto, férias, atestados, etc.
Também é muito utilizado em logística, como controle de estoque, contatos de fornecedores,
lotes e registros de entrega e envio de mercadorias.
Um ponto importante e completamente essencial é a segurança na transmissão desses
dados. É necessário que seja utilizada a criptografia para envio dos mesmos, para que sejam
enviados e recebidos com integridade e sem violação em ambos os lados ( servidor e cliente).
Também é preciso controlar o acesso lógico e físico, gerenciar backups com o objetivo de
proteger um dos principais ativos da organização, sua base de dados.

2.1 Características do banco convencional

 Orientado a registros: toda tupla tem a mesma estrutura e todos os atributos tem um
tamanho fixo, não pode ser diferentes na mesma tabela;

 Tipos de dados simples: não estruturados, monovalorados (atômicos), ou seja, não podem
ter valores repetidos e nem atributos possuindo mais de um valor. Dados numéricos ou
caracteres;

 Operações DML simples: maneira simples de gerenciar registros, fornecer instruções

simples para inserir, atualizar, mesclar, excluir e alterar registros. Não envolve
procedimentos complexos de dados;
 Transações de curta duração: as transações são executadas mais rapidamente para não
afetar o acesso aos dados por outros usuários ou sistemas;

 Atualizações “in-place”: dados mais antigos não são mantidos no banco após atualização;

2.2 Dificuldade dos bancos convencionais

Os bancos de dados convencionais também tem suas limitações. Como por exemplo, quando
existem aplicações mais complexas que devem ser projetadas e implementadas. Essas novas
aplicações possuem características e requisitos que as diferenciam das demais, como
estruturas completas para objeto, transações de longa duração, novos tipos de dados para
armazenamento de textos longos e multimídia, e o aumento constante das linguagens de
programação orientadas a objetos para o desenvolvimento de softwares . E essas dificuldades
trouxeram a necessidade da criação de banco de dados orientados a objetos.

3. Categorias de aplicações de bancos de dados

Mencionamos no bloco anterior sobre a definição de aplicações de bancos de dados,

que são as responsáveis pela iteração entre usuários e banco de dados, garantindo sua
integridade e acesso disponível. Mas, essas aplicações podem ser divididas em três categorias.
São elas: para internet, de suporte a decisão e orientadas as transações.
Na internet, as transações são mais longas em função da manipulação dos diferentes
tipos de dados presentes na web, incluindo os de multimídia. Os perfil dos profissionais que
atuam nessa categoria, varia em função das caraterísticas singulares de aplicação. Sua
disponibilidade também varia de acordo com a necessidade da organização que a
desenvolveu, mas elas devem operar 24 horas por dia e 7 dias por semana. Também varia o
ambiente de desenvolvimento dessas aplicações de acordo com cada categoria, e para
orientação por objeto na internet é aconselhado usar SQL como opção nativa.
Aplicações de suporte a decisão devem representar as caraterísticas da organização
sem deixar pesar os aspectos de performance do banco. Os dados utilizados nesses bancos
devem responder aos requisitos de Data Warehouse e Datamarts. Para essas aplicações, os
usuários finais devem ter conhecimento em relacionamento de dados de um dicionários e o
DBA ter todo o conhecimento sobre os conceitos do data warehouse em execução. Toda
consulta é realizada de acordo com os requerimentos de negócio imediatos. Em caso de
consultas pré-definidas, o esforço para obter resultados será maior. No cenário da internet
atual, nos bancos de dados da internet, os requerimentos podem chegar por meio de vários
protocolos e com vários tipos de dados para atender a qualquer cliente online. Para essas
transações mais complexas e de longa duração, os bancos devem suportar aplicações de
multimídia e arquivos em formatos HTML e XML. Como exemplo desse último, temos os
sites E-commerce.
Já as aplicações orientadas a transações tem como característica principal suas
especificações rígidas. No lado do usuário, a tela exibe o que deve ser preenchido para obter
resultados bem definidos. Esses aplicativos dão suporte a operação da organização e as
transações devem ser pequenas e realizadas rapidamente, aumentando a produtividade no
operacional. As estruturas são em SQL e são pré-definidas levando em conta os resultados
esperados e a melhor performance de acesso físico aos dados. E para utilizar essas aplicações,
não é necessário que o usuário tenha conhecimento sobre processamento de dados. Na área de
desenvolvimento, estão envolvidos os desenvolvedores e os DBA ( Database Administrator ).

4. Bancos de dados não-convencionais

Como mencionado na seção 2.1, os bancos de dados convencionais possuem suas

limitações e restrições, que ocasiona a limitação de algumas aplicações. Por isso, começou a
propor o desenvolvimento de modelos de dados diferentes, com o objetivo de atender essas
aplicações específicas. E foi a partir daí que surgiu o modelo de dados orientado a objeto,
baseado na programação orientada a objetos. Vamos apresentar alguns conceitos,
características e exemplo desse modo de modelagem de dados na seção seguinte.

4.1 Bancos de dados orientados a objetos

Na década de 70, muitos sistemas de bancos comerciais foram projetados, onde muito
desses funcionam até hoje. Mas naquela época, não havia uma necessidade que levasse a ser
considerada as aplicações de bancos de dados. Porém, a medida que se elevou a memória
principal e tamanho de discos, a maior aceleração dos processamentos de dados, o menor
custo dos hardwares e a evolução do gerenciamento de banco de dados atualmente, levou a
implantação dessas aplicações e a adaptação de bancos de dados a elas.
Na modelagem orientada a objetos, cada informação é armazenada na forma de
objetos e só pode ser manipulada através de métodos. Utiliza o mesmo conceito de orientação
a objetos (objeto, métodos, herança, polimorfismo). Bancos de dados as informações são
armazenadas na forma de dados e são utilizadas tabelas. As aplicações mais recentes tem
exigido bancos de dados que atendam a seus níveis de processamento não convencionais.
Um exemplo de aplicações que não conseguem ser atendidas pelo modelo relacional é
o de aplicações financeiras. Hoje, as aplicações financeiras têm de tratar com dados de
imagem e de hipertexto. As novas modelagens de dados são desenvolvidas para ir de encontro
com as necessidades dessas aplicações.
A modelagem orientada a objetos tem alguns aspectos, os quais falaremos em seguida.

4.1.1 A Estrutura Objeto

Comparando com o modelo E-R, um objeto corresponde a uma entidade. Mas, a
orientação a objeto usa o encapsulamento de dados. E há um código relacionado a um objeto
dentro de uma única unidade. Toda interação entre um objeto e as outras partes do sistemas
são por mensagens. Portanto, essa interface entre sistema e objeto é definida por um conjunto
de mensagens permitidas.
De modo geral, os objetos tem associado a si um conjunto de variáveis, que contém os
dados para o objeto. No modelo E-R, essas variáveis são denominadas atributos. Também
estão associados um conjunto de mensagens permitidas, a qual o objeto responderá, onde
esses mensagens podem ter ou não parâmetros. E, um conjunto de métodos, onde cada um é
um corpo de código que implementa a mensagem, e um método retorna um valor como
resposta a mensagem.
Mensagem, na orientação a objetos, refere-se a passagem dos pedidos entre objetos,
não considerando detalhes específicos de implementação. Chamar um método pode ser usado
para representar o ato de enviar uma mensagem a um objeto e a execução do método.
Vamos demonstrar um exemplo. Em um banco, o banco de dados possui um objeto
chamado empregado. Suponhamos que o salário anual de um empregado seja d[calculado de
maneiras diferentes de acordo com sua função. Por exemplo, um gerente recebe o salário mais
um bônus por metas batidas, enquanto os caixas recebem um bônus por horas trabalhadas.
Lembrando que a orientação a objetos consiste no encapsulamento de dados, podemos realizar
esse processo com o código para calcular o salário de cada empregado, onde este será m
método executado em resposta a uma mensagem salario_anual. Neste exemplo, todas as
entidades empregado respondem a mensagem salário-anual, mas fazem isso de modo
individual em cada objeto. Como o método de calcular o salário está encapsulado dentro de
cada objeto empregado, todos esse objetos terão a mesma interface, mas vão calcular o salário
de maneira diferente. Em contra partida, como a interface externa apresentada a este objeto é
o conjunto de mensagens ao qual aquele objeto responde, então é possível modificar as
definições de métodos sem alterar o resto sistema. Aplicando ao exemplo, foi possível alterar
o método do objeto calcular o salário em diferentes objetos empregados, sem afetar o resto do
sistema. Essa habilidade de modificar a definição do objeto sem afetar o resto do sistema é
uma das vantagens da orientação a objetos.
Os métodos de um objeto podem ser classificados em: somente leitura e atualização.
Quando for o caso de somente leitura, não afetará os valores das variáveis no objeto. Já o
atualização, pode alterar os valores das variáveis. As mensagens que os objetos recebem
podem ser classificadas nesses mesmos tipos, mas em função do método que implementa a
mensagem.
No modelo orientado a objeto, atributos derivados de uma entidade no modelo E-R
podem ser expressos como mensagens somente leitura. Voltando ao exemplo da entidade
empregado, um atributo derivado emprego_tempo pode ser expresso como uma mensagem
emprego_tempo de um objeto empregado. Podemos determinar o tempo de emprego
implementando na mensagem o método de subtração da data_início a partir da data atual.
Em um modelo orientado a objeto, cada atributo deve ser expresso por uma variável e
um par de mensagens do objeto correspondente. A variável armazena um valor e uma
mensagem é usada para ler esse valor e o outro método é usado para atualizá-lo.
Voltando ao exemplo de objeto empregado, ele possui um atributo chamado endereço.
Esta atributo pode ser representado por uma variável endereço, uma mensagem
obter_endereço, cuja resposta será o endereço e uma mensagem ajustar_endereço, que possui
um parâmetro novo_endereço, para atualizar o endereço ( método ).
Muitos modelos de dados orientados a objetos permitem que as variáveis sejam lidas
e atualizadas diretamente sem ser necessário definir mensagens para isso, trazendo
simplicidade.

4.1.2 Classes de Objeto

É normal termos objetos semelhantes em um banco de dados. Utilizam os mesmos
métodos, tem variáveis do mesmo nome e tipo e respondem às mesmas mensagens. É inútil
definir cada objeto desse separadamente, então é melhor agruparmos esses similares em uma
classe. Cada objeto é uma instância de uma classe. Todos os objetos numa classe
compartilham um definição em comum, mas os valores designados às variáveis são
diferentes.
Comparando ao modelo E-R, uma classe no modelo orientado a objeto seria uma um
conjunto de entidades no outro modelo. Utilizando como exemplo uma empresa, temos como
classe empregados, clientes e contas.
Por exemplo, uma classe empregado. A definição a seguir está em pseudocódigo e sua
definição exibe variáveis e mensagens as quais os objetos da classe respondem. Só não são
exibidos os métodos para manusear não são mostrados aqui.
class empregado{
/* Variáveis */
string nome;
string endereço;
date data_início;
int salário;
/* Mensagens */
int salário_anual( );
string obter_nome( );
string obter_endereço( );
int ajustar_endereço( string novo_endereço );
int tempo_emprego( );
};

Nessa definição, cada objeto da classe empregado contém as variáveis nome e

endereço (Strings), início_emprego (Data) e salário (Inteiro). Cada objeto responde as
mensagens exibidas, salário_anual, obter_nome, ajustar-salário e tempo_emprego. Antes da
mensagem vem o tipo de resposta para a mensagem. A mensagem ajustar_endereço recebe
novo_endereço como parâmetro, especificando o novo endereço.
É similar o conceito de classes ao de tipos de dados abstratos. Porém, há vários
aspectos adicionais ao conceito de ambos. Se tratarmos cada classe como um objeto em si,
podemos representar essas propriedades adicionais. Podemos dizer então que uma classe
objeto inclui uma variável conjunto valorada onde seu valor é o conjunto de todos os objetos
que são instancias de uma classe e, a implementação de um método para a mensagem new,
que cria uma nova instância da classe.

4.1.3 Herança
Qualquer esquema de banco de dados orientado a objetos exige um grande número de
classes. Porém, muitas vezes essas classes são similares. Voltemos ao exemplo da aplicação
do banco. Espera-se que a classe clientes do banco fosse similar à classe de empregados, pois
ambas tem possuem variáveis para nome, endereço, etc. Porém, existem variáveis específicas
para cada classe. Seria melhor definir uma representação para as variáveis em comum em um
único lugar. Podemos faze-lo juntando empregados e clientes na mesma classe.
Para isso, necessitamos coloca-las em uma hierarquia de especialização. Dizemos que
empregado e clientes são uma especialização de pessoa, onde ambas são um subconjunto do
conjunto de todas as pessoas.
O conceito de hierarquia é similar ao de especialização do modelo E-R. Classes
similares são especializações de uma mesma classe, mas existem variáveis e métodos
específicos de cada classe especializada.
Vejamos a seguinte imagem:
 Nessa representação de hierarquia montamos o exemplo do banco. A especialização de
uma classe é denominada subclasse. No inverso, a classe chama-se superclasse. Nesse
exemplo, empregado é uma subclasse de pessoa e
caixa é uma subclasse de empregado; já a classe
empregado é uma superclasse de caixa e pessoa é
uma superclasse de empregado.

Analisando em pseudocódigo a hierarquia

de classe do exemplo banco, vemos que um
objeto representando escriturário possui todas as
variáveis da classe escriturário e também as
variáveis da sua superclasse empregado, que por
sua vez, recebe da sua classe pessoa. Isso é a
herança de variáveis, a propriedade onde os
objetos de uma classe possuem as variáveis
definidas em suas superclasses.

Uma vantagem importante da herança em orientação a objetos é a reusabilidade.

Através dela, além das variáveis que podem ser herdadas, com os métodos podem fazer o
mesmo processo, ele pode ser invocado por qualquer uma das subclasses da superclasse
principal.
É simples determinar quais objetos estão associados às classes nos ramos da
hierarquia. E, a maioria dos sistemas orientados a objetos permitem objetos que pertencem a
uma superclasse não pertençam a nenhuma subclasse da mesma.

4.1.4 Herança Múltipla

No modelo orientado a objeto, herança múltipla é a habilidade de uma classe herdar
variáveis e métodos a partir de múltiplas superclasses. Quando a herança múltipla é usada,
existe ambiguidade potencial se a mesma variável ou método pode ser herdada por mais de
uma superclasse.
Devemos observar a ambiguidade, pois não acontece em todos os casos de herança
múltipla. Existem alguns modos de tratar as ambiguidades. Por exemplo, podemos incluir
duas variáveis com nomes diferentes em cada classe, optar por escolher uma ou outra, forçar o
usuário a escolher uma explicita, tratar como um erro ou, no melhore casos, criar uma
variável única na superclasse principal.
Nenhuma dessas soluções é aceita como melhor e única, e varia de acordo com
necessidade específicas de cada sistema.

4.1.5 Identidade de Objeto

Uma entidade que é modelada em um banco de dados corresponde a um objeto em um

banco orientado a objeto. E mesmo que algumas de suas propriedades mudem com o tempo, a
identidade é mantida. O mesmo acontece com os objetos, em relação aos valores de suas
variáveis ou definições de métodos mudarem. A diferença é que esse conceito de identidade
não se aplica a tuplas do modelo E-R. O que vem a diferenciá-las é a diferença em seus
valores.
Temos como exemplo de identidade, as forma de valor, nome e embutido. No primeiro
exemplo, é usado um valor de dados para identidade. É como o valor de uma chave primária
no modelo E-R, que identifica a tupla. Por nome, é muito utilizado em arquivos
convencionais, e este identifica o arquivo unicamente, independente do conteúdo. No
embutido, a identidade já está embutida na linguagem de programação ou modelagem de
dados sem precisar de um identificador vindo do usuário. Esse modo de identificação é usado
nos sistemas orientados a objetos e cada objeto recebe um identificador do sistema quando é
criado.
A noção de identidade de objetos é conceitual e sistemas reais necessitam de um
mecanismo físico para identificar cada objeto. Os sistemas orientados a objetos possuem um
identificador de objetos, que é único por objeto. E eles nem sempre são armazenados de
forma fácil para uso do usuário.
Imaginemos um exemplo de identificador. Em um objeto pessoa, pode-se atribuir um
objeto cônjuge, que é um identificador do objeto pessoa e corresponde ao primeiro cônjuge da
pessoa. Portanto, o objeto pessoa pode armazenar uma referencia ao objeto que representa o
cônjuge de pessoa. Esta é uma habilidade de armazenar o identificador de um objeto como um
campo em outro objeto.
Geralmente, o sistema gera automaticamente o identificador ao objeto no banco de
dados. Isso pode ser benéfico, pois tira essa tarefa do usuário, mas deve-se ter cuidado, pois
estes identificadores são gerados pelo sistema e devem ser traduzidos no caso dos dados
serem movidos a outro sistema de banco de dados diferente. E, estes identificadores podem
ser redundantes se as entidades que são modeladas já têm identificadores únicos externos ao
sistema.

4.1.6 Objetos Compostos

Diferentes conceitos do mundo real podem ser modelados pelas referencias entre
objetos. Um desses conceitos é o de objetos compostos. Estes objetos contem outros objetos,
podendo existir vários níveis de composição, e isso cria uma hierarquia de composição entre
os objetos. Os links entre as classes devem ser interpretados como é-parte-de, em vez de
interpretação é-um de links em uma hierarquia de herança.
Nesses objetos, a classe principal contém uma referencia ou um conjunto de
referencias a objetos dos outros objetos derivados.
A composição é importante, pois permite que os dados sejam visualizados com
diferentes granularidades por diferentes usuários. Um usuário pode focar em instancias em
uma classe, sem se preocupar com os objetos das demais. A hierarquia de composição é usada
para encontrar todos os objetos contidos em uma instancia da classe principal.
Existem casos onde as aplicações possuem muitos objetos e nesses casos, o
relacionamento de composição, não é representado por uma hierarquia, e sim por uma
DAG( Gráfico Direcionado Acíclico).

4.2 Linguagens Orientadas a Objetos

Para usar na prática os conceitos de orientação a objetos em banco de dados, eles
precisam ser expressos em alguma linguagem. Essa expressão pode ser feita incorporando os
conceitos em uma linguagem usada para manipular o banco de dados ou usar esses conceitos
puramente como uma ferramenta de projeto e codifica-los em um banco. Usa-se diagramas
E-R para modelar dados e são, manualmente convertidas em um conjunto de relações.
Na abordagem orientada, existem várias linguagens que podem ser integrados esses
conceitos. Por exemplo:

> Estender uma linguagem de manipulação de dados, como a SQL, pela adição de
tipos complexos e orientação a objetos. Sistemas que oferecem essas extensões são chamados
sistemas relacionais-objeto.
> Outra escolha é pegar uma linguagem já orientada a objetos e estende-la a tratar
banco de dados. Essas linguagens são chamadas linguagens de programação persistentes.

4.3 Linguagens de programação persistentes

Linguagem de programação persistente é uma linguagem de programação estendida

para tratar dados persistentes. As linguagens de bancos de dados tradicionais não manipulam
dados persistentes, ou seja, dados que permanecem mesmo depois que o programa que o criou
tenha terminado. Os únicos dados que as linguagens de programação tradicionais manipulam
diretamente são os arquivos.

4.3.1 Persistência de Objetos

As linguagens orientadas a objeto possuem um conceito de objetos, um sistema que

define seus tipos e a estrutura para criá-los. Mas, esses objetos são transientes, ou seja,
desaparecem ao termino do programa. Para transformar uma linguagem para uma de
programação de banco de dados, é preciso fornecer meios de tornar os objetos persistentes.
Existem algumas propostas para fazer isso. Entre elas:

> Persistência por classe: em muitos bando de dados orientados a objetos, ao declarar uma
classe como persistente, dá-se a entender que os objetos nessa classe também podem ser.
Essas classes são chamadas persistíveis.

> Persistência por criação: um objeto será persistente ou transiente dependendo de como ele
foi criado. Através da sintaxe da criação de objetos transientes, é introduzida uma para os
objetos persistentes. Essa abordagem é muito utilizada em bancos orientados a objetos.

> Persistência por marcação: após a criação, marcar os objetos como persistentes. De início,
todos são criados como transientes, mas os que devem persistir após o termino do programa
deve ser marcado antes que isso ocorra.

> Persistência por referência: um ou mais objetos são declarados como persistentes (raiz).
Daí, todos os outros objetos só serão persistentes se forem referidos a partir do objeto raiz.
4.4 Exemplos de aplicações que usam bancos de dados orientados a objetos

Como mencionado anteriormente, existem aplicações que necessitam de padrões fora

dos limites dos banco de dados convencionais. Como exemplo dessas aplicações, temos:

-> Computer-aided design (CAD) – Projeto auxiliado por computador: o banco de dados
dessa aplicação CAD armazena os dados pertencentes a projetos de engenharia, incluindo os
componentes do item que está sendo projetado, o inter-relacionamento de componentes e
versões antigas do projeto. Também garante um baixo custo de aquisição de hardware e
software, uma arquitetura aberta para o usuário personalizar a parte operacional e uma maior
facilidade de implementação. O monitoramento gráfico dos dados do problema estudado e
suas possíveis soluções é garantido por uma modelagem icônica que desenvolvemos em
C.A.D., dotada de amplos recursos de edição. As alterações e configurações no modelo
podem ser controladas através da consulta criteriosa (S.Q.L.) ao conteúdo dos Bancos de
Dados.

-> Computer-aided software engineering (CASE) – engenharia de software auxiliada por

computador: Esse banco de dados CASE armazena os dados necessários para apoiar os
desenvolvedores de software na criação e planejamento. Esses dados incluem o código-fonte
das aplicações, as dependências existentes entre os módulos de software, as definições e o uso
de variáveis e o histórico de desenvolvimento do sistema de software, mantendo os estados
iniciais e suas atualizações.

-> Bancos de dados multimídia: esta tipo de banco contém todo tipo de dados multimídia,
seja vídeo, áudio, imagem, etc. Esses bancos surgiram devido a necessidade de
armazenamento de imagens, mapas, aplicações gráficas e sistemas de vídeo por demanda.

-> Office information systems (OIS) – Sistemas de informação de escritório: Esse sistema
automatiza o escritório, incluindo ferramentas baseadas em workstation para criar e recuperar
documentos da organização, ferramentas para manutenção de calendários de compromisso, e-
mail, correio eletrônico, etc. Um OIS é normalmente composto de uma ou mais unidades
centrais de processamento, unidades de controle , dispositivos de armazenamento, terminais
do usuário e interfaces para conectar esses componentes.

-> Banco de dados hipertexto: Hipertexto é um texto preenchido com links que apontam
para outros documentos. A world wide web é um exemplo. Os documentos hipertexto podem
também ser estruturados de formas específicas que ajudam a indexá-los. Os banco de dados
hipertexto deve possuir a habilidade de recuperar documentos baseados em sua estrutura.
5. Conclusão

Ao término deste trabalho, verificamos que existem outros tipos de

modelagem de dados. Além da modelagem de dados convencionais, como a
relacional, existe também uma modelagem orientada a objetos. Essa modelagem
veio da necessidade de atender a aplicações que exigiam uma performance
maior do que os banco de dados convencionais podiam oferecer. Não quer dizer
que os bancos de dados tradicionais estão com seus dias contados, ao contrário,
ainda hoje eles dominam o mercado, mas que, também existem outros métodos
de armazenagem de dados, e existem dados específicos que necessitam desse
tipo de armazenamento, trazendo ao usuário uma melhor interação entre ele e
máquina, através das aplicações e seus bancos de dados.
6. Bibliografia

Dias, E. (29 de Novembro de 2008). Slide Share. Acesso em 22 de Maio de 2018, disponível em
pt.slideshare.net: https://pt.slideshare.net/adorepump/banco-de-dados-orientado-a-objeto-
presentation

Elmasri, R., & Navathe, S. B. (20006). Sistemas de Bancos de Dados. São Paulo: Pearson.

Maria Salete Marcon Gomes Vaz, L. d. (2016). Conventional and Non-conventional data moddeling. p.
20.

Silberschatz, A., F., H. K., & Sudarshan, S. (1998). Sistema de Banco de Dados. São Paulo: Makron
Books.