ESTRUTURA E

MODELAGEM
DE DADOS
César Torres Fernandes

E-book 3
Neste E-Book:
INTRODUÇÃO���������������������������������������������� 3
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS OBJETO-
RELACIONAL������������������������������������������������ 4
VISÃO GERAL DE UM SGBDOR�������������� 8
Modelagem de dados����������������������������������������������8
Modelagem de banco de dados objeto-
relacional��������������������������������������������������������������� 10

SISTEMA DE GERENCIAMENTO DE
BANCO DE DADOS DISTRIBUÍDOS���� 14
SISTEMA DE BANCO DE DADOS
DISTRIBUÍDO����������������������������������������������19
SGBDD E AMBIENTE ������������������������������ 22
PROJETO DE BANCO DE DADOS
DISTRIBUÍDO���������������������������������������������29
Fragmentação de dados �������������������������������������� 29

REPLICAÇÃO DE DADOS�����������������������30
ALOCAÇÃO DE DADOS���������������������������31
CONSIDERAÇÕES FINAIS���������������������� 32
SÍNTESE������������������������������������������������������� 33

2
INTRODUÇÃO
Neste módulo, estudaremos os sistemas de geren-
ciamento de banco de dados objeto-relacional e
suas principais características. Em seguida, pas-
samos ao estudo dos sistemas de gerenciamento
de banco de dados distribuídos.

3
SISTEMA DE
GERENCIAMENTO DE
BANCO DE DADOS
OBJETO-RELACIONAL
Neste tópico, conheceremos um pouco sobre os
sistemas de gerenciamento de banco de dados
objeto-relacional e suas principais características.

Uma abordagem objeto-relacional (OR) para ge-

renciamento de dados usando Sistemas de
Gerenciamento de Banco de Dados Objeto-
Relacional (SGBDOR) — ou Object-Relational
Database Management System (ORDMS) — inclui
objetos que precisam de persistência. Por exemplo,
um modelo de dados, uma linguagem de consulta
para manipular, examinar, recuperar e armazenar
dados e um sistema de banco de dados.

Persistência, neste caso, diz respeito ao processo

de armazenamento de dados após o término de uma
aplicação. Existem três tipos básicos de bancos de
dados que podemos usar para persistência:
● Um sistema de gerenciamento de banco de dados
relacional (SGBDR).
● Um sistema de gerenciamento de banco de dados
orientado a objetos (SGBDOO).
● Um sistema de gerenciamento de banco de dados
objeto-relacional (SGBDOR).

4
Um modelo de dados é uma organização lógica de
objetos (entidades) do mundo real, suas restrições
e seus relacionamentos, que podem ser representa-
dos por diagramas utilizando diversas técnicas de
modelagem. Independentemente do método esco-
lhido para o projeto de banco de dados, a notação de
modelagem é importante porque permite a represen-
tação de relacionamentos entre entidades usando
uma representação padrão, que os projetistas de
banco de dados podem transformar em esquemas
de banco de dados usados para armazenar objetos
e seus relacionamentos.

Um banco de dados objeto-relacional é uma coleção

de objetos cujos comportamento, estado e relacio-
namentos podem ser visualizados ou manipulados
recorrendo-se a métodos de objetos, store proce-
dures ou a uma linguagem de consulta.

O uso de linguagens de programação orientadas a

objetos resultou em um conjunto de novos proble-
mas e incompatibilidade com os sistemas de banco
de dados relacionais, devido aos relacionamentos
complexos e aos tipos de dados definidos pelo usu-
ário. Desse modo, podemos considerar que:
● os relacionamentos complexos são definidos como
relacionamentos muitos-para-muitos e herança;
● os dados complexos podem ser objetos aninhados,
matrizes multidimensionais, dados não estruturados

5
(voz, vídeo), dados que não estão na primeira forma
normal e tipos de dados definidos pelo usuário.

A necessidade de armazenar os relacionamentos e

dados complexos é, em partes, resultado da utili-
zação das linguagens de programação orientadas
a objeto para desenvolver aplicativos. Antes das
linguagens orientadas a objetos, o modelo relacional
foi adequado para armazenar dados de aplicativos.
Devido à incapacidade do modelo relacional de re-
presentar adequadamente conceitos desse tipo de
linguagem de programação e do armazenamento
de dados complexos, foi necessário o surgimento
de um novo sistema de gerenciamento de banco de
dados: o objeto-relacional.

Podcast 1
Trata-se modelo que possui as seguintes vantagens:
● Remoção de incompatibilidade de impedância: a
principal vantagem de recorrer a um banco de da-
dos objeto-relacional em aplicações desenvolvidas
usando linguagens de programação orientadas a
objetos está na remoção da incompatibilidade de
impedância, ou seja, incompatibilidades que ocorrem
em cada interface entre dois conjuntos de ferramen-
tas devido aos diferentes modelos de representação
(Relacional e Orientado a objeto), pois representam
diferentes dados e tipos de computação.
● Facilidade de modelar objetos do mundo real e
relações entre eles: o uso dos sistemas de gerencia-
mento de banco de dados objeto-relacional oferece
uma maneira mais natural de representar entidades
do mundo real e seus relacionamentos. O SGBDOR

6
permite que o projetista pense nos problemas em
um nível mais alto de abstração sem o ônus de ma-
pear os dados da aplicação para tabelas no modelo
relacional.
● Capacidade de criar tipos de dados definidos pelo
usuário: a capacidade de criar tipos de dados de-
finidos pelo usuário em um banco de dados é algo
necessário, dado que capacita o sistema a aceitar a
criação de outros tipos de dados, o que aumenta a
expressividade e a capacidade de aplicações orien-
tadas a objeto, pois os objetos podem ser armaze-
nados diretamente em um banco de dados sem a
necessidade de converter objetos de aplicativo em
tipos de dados relacionais.
● Objetos e métodos armazenados juntos: nos sis-
temas de gerenciamento de banco de dados re-
lacionais, os dados são armazenados em tabelas
relacionais, ao passo que as store procedures são
armazenadas no esquema do banco de dados. No
entanto, em um sistema de gerenciamento de banco
de dados objeto-relacional, os dados e métodos para
manipular esses dados são armazenados juntos.
● Referências a objetos: em um SGBDR, as junções
relacionais são consideradas uma das mais caras
operações, pois elas consomem muitos recursos
para se executar. Em um sistema de gerenciamento
de banco de dados objeto-relacional, as tabelas re-
lacionadas podem ser acessadas usando referências
de objeto em vez de junções de tabela. As referên-
cias a objetos facilitam a navegação entre objetos
usando a notação de ponto orientada a objetos.

7
VISÃO GERAL DE UM
SGBDOR
À medida que se desenvolvem mais aplicativos
orientados a objetos, cada vez mais aparecem re-
quisitos complexos para os tipos de relacionamen-
tos e dados que esses aplicativos devem manipular.
Os sistemas de gerenciamento de banco de dados
objeto-relacional têm a capacidade de representar
dados complexos e os relacionamentos entre obje-
tos complexos. Em outras palavras, ele representa a
combinação de recursos das linguagens de progra-
mação orientadas a objeto e um sistema de banco
de dados relacional.

Modelagem de dados
A modelagem de dados é uma das partes mais im-
portantes do desenvolvimento de banco de dados
e aplicativos, visto que ela especifica os tipos de
propriedade e operações do mundo real, bem como
de que maneira deve ser representado no banco de
dados. Um modelo de dados consiste em um con-
junto de estruturas de dados para armazenar dados,
relacionamentos e restrições de integridade.

Existem diferentes níveis de abstração envolvidos

na modelagem de banco de dados. O primeiro é o
mapeamento de problemas do mundo real para um
modelo conceitual, que é uma análise profunda de

8
como o sistema será utilizado e todos os atributos
necessários para desenvolver o sistema. Uma vez
identificado o objetivo do sistema, os projetistas
podem determinar quais atributos serão necessários
para desenvolver o sistema.

Esta etapa auxilia tanto projetistas quanto usuários

a definir atributos e operações necessários, em vez
de criar atributos e operações que poderiam estar
relacionados ao sistema, mas não são necessários.
Assim, cria-se um modelo conceitual usando, em
geral, ferramentas de design e escrito em linguagem
formal, que podem ser entendidos pelos projetistas
e pelos quais o sistema está sendo desenvolvido.

Além de determinar o uso do sistema, a modelagem

conceitual também inclui a identificação de objetos,
métodos, relacionamentos e eventos entre objetos,
bem como o comportamento no limite externo do
sistema.

O segundo nível de modelagem de banco de dados é

transformar e mapear o modelo conceitual para um
modelo lógico que possa ser representado por um
sistema de banco de dados. O objetivo de um mode-
lo lógico é usar os recursos de um sistema de banco
de dados para implementar o modelo conceitual.

O terceiro nível de abstração envolvido na modela-

gem de banco de dados é o modelo físico de dados,
que nada mais é do que a implementação do modelo
lógico.

9
Modelagem de banco de dados
objeto-relacional
Semelhante ao modelo relacional, um modelo de
dados objeto-relacional deve ter os seguintes
componentes:
● Estruturas de dados usadas para armazenar dados:
a linguagem SQL (a partir da versão SQL: 2003)
fornece tipos de objetos e tabelas de objetos para
armazenar dados de objetos. Um tipo de objeto é
uma estrutura lógica que contém atributos de um
objeto. Antes de criar uma tabela de objetos, um
tipo de objeto deve ser criado com os atributos que
definem o tipo de objeto. Depois que um tipo de
objeto existe, uma tabela de objetos pode ser criada
usando comando SQL.
● Cada linha em uma tabela de objetos é uma ins-
tância de objeto único com os tipos de dados es-
pecificados no tipo de objeto. Os objetos são arma-
zenados em uma tabela relacional como objetos de
coluna, objetos de linha, ou tabelas aninhadas. Os
tipos de objetos usados como atributos em uma
tabela de objetos são armazenados como objetos
de coluna.

Assim, as tabelas de objetos criadas como um tipo

de objeto são armazenadas como objetos de linha.
Os objetos também podem ser armazenados em
tabelas aninhadas, nas quais cada coluna de objetos
é uma tabela.

10
● Restrições de integridade: restrições existem nos
objetos do mundo real e nos relacionamentos entre
objetos. Datas, horários e propriedades físicas dos
objetos são exemplos de restrições em entidades
físicas. Há, em outras palavras, restrições tanto no
mundo físico quanto no mundo abstrato. No mundo
abstrato, por exemplo, as restrições são colocadas
nos objetos por humanos ou por limites em tecno-
logia. Nos bancos de dados, as restrições são usa-
das para implementar as regras de negócios. Pode
haver também restrições impostas aos atributos
relacionados às limitações de hardware ou software.
As restrições definem, portanto, quais valores são
válidos para cada atributo.
● Relacionamentos: uma das principais diferenças
entre um SGBDR e um SGBDOR encontra-se em
como as relações são gerenciadas. Um banco de
dados relacional tem chaves primárias e estran-
geiras que relacionam tabelas entre si. Entretanto,
em um banco de dados objeto-relacional, os rela-
cionamentos entre objetos são dão por padrão com
identificadores de objetos (OID – Object Identifier).

Um SGBDOR atribui automaticamente um OID para

um objeto. Um OID é exclusivo para o ciclo de vida de
um objeto e opera independentemente dos valores
de seus atributos. Como os relacionamentos em um
banco de dados objeto-relacional são baseados em
valores que não podem ser alterados, um OID forne-
ce automaticamente a integridade da entidade, mas
não garante que os valores sejam únicos.

11
Ao utilizar um OID para representar relacionamentos,
em vez de chaves primárias e estrangeiras, resulta
em melhor desempenho para um banco de dados
objeto-relacional, pois as junções não são neces-
sárias para acessar dados em tabelas relacionadas.
Além dos OID, existem outros relacionamentos no
modelo objeto-relacional que são herança, isto é,
associação e agregação.
● Herança: a herança possibilita que projetistas to-
mem objetos que tenham atributos e métodos se-
melhantes, bem como abstraiam as semelhanças,
criando subclasses que herdam de uma superclasse.
Todas as instâncias de subclasses também são
instâncias da superclasse, assim como todas as
propriedades da superclasse são propriedades da
subclasse.

Chama-se o relacionamento entre uma subclasse

e uma classe herdada de IS-A; há vários tipos de
herança: única, múltipla, união, expressão mútua,
herança parcial, repetida e seletiva.
● Relações de associação: a associação relaciona
dois ou mais objetos independentes, criando com
isso um relacionamento entre eles. Um relaciona-
mento de associação é frequentemente referido
como um mecanismo de agrupamento ou particio-
namento. Os relacionamentos do tipo associação
são binários e podem ser um para um, um para mui-
tos ou muitos para muitos. Um SGBDOR deve manter
a integridade referencial desses relacionamentos.

12
● Relacionamentos de agregação: além da herança e
da associação, os bancos de dados objeto-relacional
também devem fornecer relacionamentos de agre-
gação entre os objetos. Uma agregação é um agru-
pamento de objetos cuja relação é todo-parte. Esse
relacionamento é uma coleção de objetos (subpar-
tes) que compõem uma coleção inteira.
● Encapsulamento objeto-relacional: um recurso das
linguagens de programação orientadas a objetos, o
encapsulamento é a capacidade de armazenar dados
e métodos juntos em um objeto. O encapsulamento
em um SGBDOR fornece independência lógica de
dados, permitindo modificações nos métodos dos
objetos sem ter que fazer alterações nos aplicativos
que os acessam.
● Abstração objeto-relacional: a abstração é um
recurso das linguagens de programação orientadas
a objeto que tem a capacidade de isolar aspectos
de um problema ou de certos dados importantes, ao
suprimir as informações que não são importantes
para a resolução do problema. A abstração permite
que os projetistas quebrem os problemas em pro-
blemas menores, quando da utilização dos dados
acessados por meio de métodos públicos.

SAIBA MAIS
Saiba mais sobre a Abstração. Leia o artigo Mo-
delos teóricos em ciência da informação: abstra-
ção e método científico, de Luís Fernando Sayão
(2001), disponível em: http://www.scielo.br/pdf/ci/
v30n1/a10v30n1. Acesso em: 19 nov. 2019.

13
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
DISTRIBUÍDOS
Durante as décadas de 1970 e 1980, as instituições
usavam sistemas de gerenciamento de banco de
dados centralizados, ou seja, todos os dados es-
tavam armazenados em um único local, normal-
mente em um mainframe, o acesso aos dados for-
necido por meio de terminais sem capacidade de
processamento.

Essa abordagem centralizada (Figura 1) funcionava

bem no atendimento a necessidades de informa-
ções estruturadas das instituições, mas era insufi-
ciente quando eventos exigiam mudanças rápidas
e agilidade no tempo de resposta e de acesso às
informações, não atendendo às necessidades de
um ambiente mais dinâmico.

SGBD
Resposta

Solicitação

Banco de Dados
Local

Figura 1: Sistema de gerenciamento de banco de dados centralizado.

Fonte: Adaptada de Rob e Coronel (2011).

14
Surgia, então, a necessidade de acesso rápido e não
estruturado aos bancos de dados, utilizando con-
sultas para gerar informações no momento em que
eram necessárias para a tomada de decisão. Dessa
forma, os sistemas de gerenciamento de banco de
dados relacionais eram capazes de oferecer um am-
biente em que se atendesse às necessidades de
informações não estruturadas, empregando con-
sultas por uma linguagem declarativa (linguagem
SQL, por exemplo).

Esse tipo de sistema de gerenciamento de banco

de dados, contudo, ainda não tinha capacidade de
transmissão aceitável em comparação aos modelos
hierárquico e em rede. Ao longo desse tempo, surgi-
ram importantes transformações sociais, econômi-
cas e tecnológicas que influenciaram no desenvolvi-
mento de sistemas e o projeto de bancos de dados.

As instituições começaram a realizar suas opera-

ções comerciais e financeiras de maneira descen-
tralizada, pois houve aumento da competição no
nível global. Assim, nascia a ideia de gerenciamento
descentralizado, com gestores tentando atender
às demandas dos clientes e às necessidades do
mercado em um mundo cada vez mais globalizado.

Com a evolução tecnológica, começamos a ter com-

putadores de baixo custo e com uma capacidade
semelhante à de computadores de grande porte.
Surgiram dispositivos sem fio (portáteis) com várias
funções e serviços de dados (por exemplo, telefones
celulares) e as redes de computadores se tornaram

15
cada vez mais rápidas, complexas e com custos de
implantação mais acessíveis às instituições, sendo
consequentemente adotada cada vez mais pelas
corporações, como soluções computadorizadas
alinhadas às suas estratégias.

Nesse cenário, as aplicações começaram a geren-

ciar tipos diferentes de dados (voz, vídeo, música,
imagens etc.), acessando-os a partir de diferentes
localizações dispersas geograficamente. Nos últi-
mos anos, o acesso a dados de modo rápido tornou-
-se um fator muito importante para a tomada de
decisão. A necessidade de descentralização das
estruturas de gerenciamento com base na divisão
e descentralização das unidades comerciais e fi-
nanceiras das instituições fez com que os bancos
de dados descentralizados ficassem com acesso e
localização dispersos geograficamente.

Outros fatores que influenciaram a necessidade de

mais armazenamento e processamento de dados de
forma descentralizada foram a crescente aceitação
da internet como plataforma de acesso e distribuição
de dados; o surgimento e a disseminação do uso
de dispositivos de comunicação de dados sem fio
(Personal Digital Assistants, smart phones, tablets
etc.); o crescimento rápido de empresas fornecedo-
ras de serviços de desenvolvimento, manutenção e
operação de aplicações, bem como o aumento do
foco na análise de dados (datamining e datawa-
rehouse) por parte das instituições.

16
 SAIBA MAIS
Leia Data Mining e Data Warehouse, de Ederson
Tyiuji Noya, Guilherme de Freitas Perinazzo, Gui-
lherme Masao Oyakawa e Rafael Silva de Milha
e saiba mais de datamining e datawarehouse. Dis-
ponível em:

https://edisciplinas.usp.br/pluginfile.php/777919/
course/section/288273/Seminario_Data%20Mi-
ning%20e%20Data%20Warehouse.pdf. Acesso
em: 19 nov. 2019.

Considerando os avanços sociais, econômicos e

tecnológicos, Rob e Coronel (2011) afirmam que
os bancos de dados centralizados estão sujeitos a
diversos problemas:

a) queda de desempenho em relação ao número

crescente de localizações remotas;

b) altos custos na manutenção de sistemas

centralizados;

c) problemas de confiabilidade associados à de-

pendência de um local central e à necessidade de
replicação de dados;

d) problemas de escalabilidade associados aos

limites físicos impostos por um local único;

e) rigidez organizacional associada ao fato de o

banco de dados não ser flexível e ter a agilidade
exigida pela instituição.

17
O ambiente mais moderno e dinâmico de negócios
gerou uma demanda por aplicações com acesso a
dados de diferentes fontes em diferentes localiza-
ções geográficas, surgiu assim a necessidade de
um sistema de gerenciamento de banco de dados
distribuído.

18
SISTEMA DE BANCO DE
DADOS DISTRIBUÍDO
Para Rob e Coronel (2011), um sistema de geren-
ciamento de banco de dados distribuído (SGBDD)
controla o armazenamento e o processamento de
dados relacionados logicamente por meio de siste-
mas interconectados, sendo que dados e operações
de processamento são distribuídos em diversas lo-
calizações geográficas.

Por seu turno, Casanova e Moura (1999) defendem

que os sistemas de gerenciamento de bancos de
dados distribuídos (SGBDD) ampliam as funcio-
nalidades usuais de gerência de dados, permitindo
que o armazenamento de um banco de dados possa
ser dividido pelos nós de uma rede de comunicação
de dados, sem que os usuários percam uma visão
integrada do banco.

O uso de sistemas de gerenciamento de banco de

dados distribuídos apresenta diversas vantagens
(ROB; CORONEL, 2011):
● Os dados são dispersos geograficamente para
atender a demandas das instituições.
● O acesso aos dados é mais rápido, pois traba-
lha com um subconjunto dos dados armazenados
localmente.
● O processamento dos dados é mais rápido, pois
um SGBDD distribui a carga de processamento do
trabalho entre diversos locais.

19
● Promoção e aprimoramento das comunicações
entre departamentos, equipes e clientes.
● Possibilidade de ampliação da rede de uma local
sem afetar as operações de outras localizações.
● Diminuição dos custos operacionais, pois os com-
putadores têm baixo custo e bom desempenho, per-
mitindo adicionar estações de trabalho a uma rede.
● Visto que os dados se distribuem em vários locais,
existe a diminuição de risco de falha em ponto único,
pois o trabalho se mantém nas outras estações.
● Transformação de computadores e seus sistemas
com interface gráfica mais amigáveis, simplificando
o treinamento e a utilização por parte dos usuários
finais.
● Existência da independência do processador, pois
os usuários finais com seus computadores, indepen-
dente do processador, podem acessar e processar
os dados armazenados localmente.

Por outro lado, segundo os mesmos autores, as des-

vantagens encontradas em sistemas gerenciadores
de banco de dados distribuídos são:
● Aumento na complexidade de gerenciamento e
controle por parte dos administradores de banco
de dados.
● Necessidade de tratar e solucionar a integridade
dos dados, gerenciamento de transações, controle
da concorrência, backup, otimização de consultas
etc.

20
● Responsabilidade da segurança dos dados é com-
partilhada por diversas pessoas em diferentes locais.
● Falta de padrões de comunicação de dados no
nível do banco de dados.
● Necessidade de ampliação do armazenamento e
infraestrutura, pois são necessárias várias cópias
de dados em diferentes locais.
● Existência do aumento de custos associados ao
treinamento, pois o valor desses cursos costuma
ser mais elevado.
● Bancos de dados distribuídos exigem infraestru-
tura duplicada para operar, aumentando os custos
de projeto de um banco de dados desse tipo.

Por tudo que foi posto até o momento, nota-se que

diversas questões devem ser consideradas no âm-
bito de projetos de banco de dados distribuídos.

21
SGBDD E AMBIENTE
No processamento distribuído, o processamento
lógico do banco de dados é compartilhado entre
dois ou mais locais fisicamente independentes e
conectados por uma rede de computadores. Observe
a Figura 2.

Local 1
Local 2
SGBD

Rede de
Comunicação Local 3

Banco de Dados
Local

Figura 2: Ambiente de processamento de dados distribuído. Fonte:

Adaptada de Rob e Coronel (2011).

O banco de dados distribuído, por sua vez, armazena

o banco relacionado logicamente por dois ou mais
locais independentes conectados por uma rede de
computadores. O sistema de processamento distri-
buído utiliza um banco de dados em um único local
e compartilha o processamento com diversos locais
(Figura 3). Em um SGBDD, o banco é composto de
várias partes, os fragmentos de banco de dados,
que ficam alocados em diferentes locais e podem
ser replicados em vários desses locais, sendo cada

22
fragmento gerenciado por seu processo de banco
de dados local.

Local 2

SGBD
Local 1

SGBD
Fragmento 2
Rede de
Comunicação
Local 3
Fragmento 1
SGBD

Fragmento 3

Figura 3: Ambiente de banco de dados distribuído. Fonte: Adaptada

de Rob e Coronel (2011).

Notamos, então, que o processamento distribuído

não exige um banco de dados distribuído. Porém,
um banco de dados distribuído exige processamento
distribuído. O ambiente para um SGBDD deve ter, no
mínimo, alguns componentes:
● Infraestrutura:
ƒ Estações de trabalho.
ƒ Meios de comunicação.
ƒ Componentes de hardware e software para redes
de computadores.

23
● Software:
ƒ Processador de transações – PT: software que
recebe e processa as solicitações de dados das
aplicações locais ou remotas.
ƒ Processador de dados – PD: software residente
em cada estação de trabalho, armazenando e re-
cuperando dados existentes no local.

Um sistema de gerenciamento de banco de dados

distribuído deve conter e executar todas as opera-
ções características de um sistema de gerencia-
mento de banco de dados centralizado. Por exemplo:
receber, tratar, validar, analisar e executar as solici-
tações de aplicativos e/ou usuários finais; garantir
a consistência, segurança e integridade do banco
de dados; buscar, ler e validar dados e apresentá-
-los conforme o formato solicitado pela aplicação
ou pelo usuário final.

Rob e Coronel (2011) afirmam ainda que, além disso,

um sistema de gerenciamento de banco de dados
distribuído, para ser classificado como tal, deve
apresentar no mínimo doze características, a saber:

1. Uma interface de aplicação para permitir a in-

teração com usuários finais, aplicações e outros
sistemas de gerenciamento de banco de dados.

2. Uma função de validação para analisar solicita-

ções quanto à correção sintática.

24
3. Uma função de transformação para decompor
as solicitações de dados com maior complexidade
em componentes atômicos.

4. Uma função de otimização de consulta para en-

contrar e utilizar a melhor estratégia de acesso.

5. Um mapeamento da localização dos dados de

fragmentos de banco de dados locais ou remotos.

6. Uma interface de Entrada/Saída para leitura e

gravação de dados do ou para o armazenamento
local permanente.

7. Uma função de formatação para preparar a apre-

sentação dos dados ao usuário final ou aplicação.

8. Uma função de segurança para fornecer privaci-

dade de dados a bancos de dados locais ou remotos.

9. Uma função de backup e recovery para assegurar

que os bancos de dados estejam disponíveis e re-
cuperáveis em caso de falha.

10. Funções de administração para permitir que o

administrador do banco de dados possa realizar
suas operações.

11. Controle da concorrência, gerenciamento de

acessos simultâneos e garantia da consistência
dos dados entre fragmentos de banco de dados.

12. Gerenciamento de transações para permitir

a sincronização de transações locais e remotas,
bem como transações entre os diversos segmentos
distribuídos.

25
Todas essas funções devem ser realizadas pelo
sistema de gerenciamento de banco de dados dis-
tribuído de forma transparente para as aplicações e
para os usuários finais. Assim, os usuários finais não
precisam saber que o banco de dados está dividido
em fragmentos, tampouco onde estão localizados.

Dado o aumento do uso de sistemas de gerencia-

mento de banco de dados relacionais, diversos fa-
bricantes implementaram seus próprios bancos de
dados distribuídos (ROB; CORONEL, 2011). Contudo,
não existe uma maneira fácil de compará-los, sendo
assim, Christopher J. Date escreveu um conjunto
de 12 regras para um banco de dados distribuído:

1. Independência de local: pode haver um banco

de dados centralizado em cada local, responsável
também por segurança, controle de concorrência,
backup e recuperação.

2. Independência do local central: não existe depen-

dência de um local central na rede de computadores,
todos apresentam os mesmos recursos.

3. Independência de falhas: o sistema não é afe-

tado por falhas ou por manutenções que ocorrem
nos nós da rede.

4. Transparência de localização: o usuário final não

precisa saber a localização dos dados.

5. Transparência de fragmentação: para o usuário,

a fragmentação é transparente, como se existisse
um único banco de dados lógico.

26
6. Transparência de replicação: para o usuário, exis-
te um único banco de dados lógico, pois o SGBDD
gerencia todos os fragmentos de modo transparente.

7. Processamento de consultas distribuídas: uma

consulta pode ser executada em várias localizações
de PD diferentes.

8. Processamento de transações distribuídas: uma

transação pode atualizar dados em diversos locais
diferentes.

9. Independência de hardware: o sistema pode ser

executado em qualquer plataforma de hardware.

10. Independência do sistema operacional: o siste-

ma deve ser executado em qualquer plataforma de
sistema operacional.

11. Independência de rede de computadores: o sis-

tema deve ser executado em qualquer plataforma
de rede de computadores.

12. Independência de banco de dados: o sistema

deve dar suporte a sistemas de banco de dados de
qualquer fabricante.

Podcast 2

Em relação à distribuição de processamento e

distribuição de dados para um SGBD totalmente
distribuído, temos uma perspectiva conhecida por
processamento em vários locais e dados em vários
locais (multiple-site processing, multiple-site data

27
– MPMD), em que o SGBDD tem suporte para vários
processadores de dados e de transações em diver-
sas localizações. Nesse cenário, podemos classificar
os SGBDDs como homogêneos ou heterogêneos,
dependendo dos níveis de suporte e dos diferentes
tipos de SGBD utilizados:
● SGBDD homogêneo: neste ambiente, temos um
único tipo de SGBD centralizado na rede, assim, o
mesmo sistema é executado em diferentes plata-
formas de servidores.
● SGBDD heterogêneo: neste ambiente, temos di-
ferentes tipos de SGBD centralizados na rede, po-
dendo dar suporte, inclusive, a SGBD com diferentes
modelos (hierárquico, em rede ou relacional), sendo
executados em vários tipos de plataformas, sistemas
operacionais e tipos de redes.

28
PROJETO DE BANCO DE
DADOS DISTRIBUÍDO
Em um projeto de banco de dados distribuído, além
dos conceitos relacionados aos projetos de mo-
delos de banco de dados em rede, hierárquicos e
relacionais, devemos considerar outros aspectos,
como fragmentação de dados, replicação de dados
e alocação de dados.

Fragmentação de dados
A fragmentação de dados é a possibilidade de dividir
um objeto simples (banco de dados ou uma tabela)
em dois ou mais fragmentos, uma vez que as in-
formações dessa operação ficam armazenadas no
catálogo de dados distribuído. Existem três formas
de realizar a fragmentação:
1. Fragmentação horizontal: possibilita a divisão
de uma tabela em subconjuntos de linhas (tuplas),
nos quais cada fragmento é armazenado em um nó
diferente.
2. Fragmentação vertical: possibilita a divisão de
uma tabela em subconjuntos de atributos (colu-
nas), e cada fragmento armazenado fica em um nó
diferente.
3. Fragmentação mista: possibilita a combinação
das estratégias anteriores, ou seja, uma tabela pode
ser dividida em vários fragmentos horizontais, cada
um com um subconjunto de atributos.

29
REPLICAÇÃO DE DADOS
A replicação de dados é a possibilidade do arma-
zenamento de cópias de dados em diversas loca-
lizações por meio de uma rede de computadores,
atendendo a necessidades específicas de informa-
ção do projeto de banco de dados, auxiliando na
disponibilidade de dados e no tempo de resposta,
reduzindo diretamente os custos de comunicação e
consulta. No entanto, a replicação acarreta cargas
adicionais de processamento ao SGBDD para a ma-
nutenção de cada cópia de dados existente, além de
aumentar os custos de armazenamento e tempos
de processamento das transações.

Podemos ter as seguintes situações em relação à

replicação de dados:
● Replicação total: permite o armazenamento de
diversas cópias de cada um dos fragmentos em
diversas localizações.
● Replicação parcial: permite o armazenamento de
diversas cópias de alguns fragmentos em diversas
localizações.
● Não replicação: permite o armazenamento de cada
fragmento em um único local, ou seja, não há dupli-
cação de fragmentos no banco de dados.

30
ALOCAÇÃO DE DADOS
A alocação de dados tem relação direta com o modo
como o banco de dados é fragmentado, pois a dis-
tribuição de dados por uma rede de computadores
pode ser realizada por meio de particionamento,
replicação de dados ou uma combinação de ambas.
Os tipos de alocação de dados são:

a) centralizada de dados: em que todo o banco de

dados é armazenado em um único local;

b) particionada de dados: em que o banco de dados

é dividido em duas ou mais partes separadas e ar-
mazenado em duas ou mais localizações.

c) replicada de dados: em que cópias de um ou mais

fragmentos do banco de dados são armazenados
em várias localizações.

A alocação de dados relaciona-se com o modo como

o banco de dados é fragmentado. Os algoritmos de
alocação têm a necessidade de considerar diversos
fatores, como objetivos de desempenho e disponi-
bilidade dos dados; tamanho, números de linhas e
número de colunas das relações que uma entidade
mantém com outras; tipos de transação a se apli-
car, aos atributos acessados por tais transações e
também dados sobre a topologia ou capacidade de
transmissão da rede de computadores.

31
CONSIDERAÇÕES FINAIS
Neste texto, abordamos uma visão geral sobre o sis-
tema de gerenciamento de banco de dados objeto-
-relacional, no qual apresentamos todos os concei-
tos e as características desse tipo de SGBD, suas
vantagens e desvantagens, bem como sua relação
com as linguagens de programação orientadas a
objeto.

Na sequência, estudamos o sistema de gerencia-

mento de banco de dados distribuídos, conceitos e
características, incluindo as 12 Regras para a com-
paração de banco de dados distribuídos, as quais
foram elaboradas por Christopher J. Date.

32
 SÍNTESE

ESTRUTURA E
MODELAGEM DE DADOS

MODELAGEM DE DADOS 3

– Neste módulo, abordamos uma breve visão dos sistemas de gerenciamento de

banco de dados objeto-relacional, ou seja, os conceitos básicos, as vantagens de
projeto e implantação desses sistemas, bem como uma descrição da modelagem de
dados em sistemas de gerenciamento de banco de dados objeto-relacional�

– Em seguida, estudamos conceitos dos sistemas de gerenciamento de banco de

dados distribuídos e uma descrição do ambiente desses sistemas� Ainda, temos uma
descrição detalhada do projeto dos SGBDD e das 12 Regras de Christopher J� Date
para classificar um SGBD como um sistema de banco de dados distribuído�
Referências Bibliográficas
& Consultadas
ALVES, W. P. Banco de Dados: teoria e desenvolvi-
mento. São Paulo: Érica, 2014.

ASCENCIO, A. F. G.; ARAÚJO, G. S. Estruturas

de dados: algoritmos, análise da complexidade
e implementações em JAVA e C/C++. São Paulo:
Pearson Prentice Hall, 2010 [Biblioteca Virtual].

CASANOVA, M. A.; MOURA, A. V. Princípios

de Sistemas de Gerência de Banco de Dados
Distribuídos. [s. p.] 1999. Disponível em: http://
www-di.inf.puc-rio.br/~casanova//Publications/
Books/1985-BDD.pdf. Acesso em: 19 nov. 2019.
DIETRICH, S. W.; URBAN, S. W. Fundamentals
of Object Databases: Object-Oriented and Object-
Relational Design. Editora Morgan & Claypool,
2011.

ELMASRI, R.; NAVATHE, S. B. Sistema de banco

de dados. 6. ed. São Paulo: Pearson Addison-
Wesley, 2010 [Biblioteca Virtual].

GUIMARÃES, A. M.; LAGES, N. A. C. Algoritmos

e estruturas de dados. Rio de Janeiro: LTC, 2008.
GUIMARÃES, C. C. Fundamentos de Bancos de
Dados: modelagem, projeto e linguagem SQL.
Campinas: Editora da Unicamp, 2003.

HEUSER, C. A. Projeto de banco de dados. 6. ed.

Porto Alegre: Bookman, 2008 [Minha Biblioteca].

MACHADO, F. N. R.; ABREU, M. P. Projeto de

Banco de Dados: uma visão prática. 8. ed. São
Paulo. Érica, 2004.

MEDEIROS, L. F.; Banco de dados: princípios e

prática. Curitiba: InterSaberes, 2013 [Biblioteca
Virtual].

OZSU, M.T.; VALDURIEZ, P. Principles of

Distributed Database Systems. 3. ed. Springer,
2011.

PUGA, S.; FRANÇA, E.; GOYA, M. Banco de da-

dos: implementação em SQL, PL/SQL e Oracle 11g.
São Paulo: Pearson Education do Brasil, 2013
[Biblioteca Virtual].

RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de

gerenciamento de banco de dados. 3. ed. Porto
Alegre: AMGH, 2008 [Minha Biblioteca].

ROB, P.; CORONEL, C. Sistemas de banco de da-

dos: projeto, implementação e gerenciamento. 8.
ed. São Paulo: Cengage Learning, 2011.
SAYÃO, L. F. Modelos teóricos em ciências da
computação: abstração e método científico. In:
Ciência da Informação, Brasília, v. 30, n. 1, p.
82-91, jan./abr. 2001. Disponível em: http://www.
scielo.br/pdf/ci/v30n1/a10v30n1. Acesso em: 19
nov. 2019.