Modelagem e Banco Dados (UniGoiás)

Prévia do material em texto

Sistemas de 
banco de dados 
 BRISIGHELLO, V.
Sistemas de banco de dados / Vinícius Brisighello 
Florianópolis, 2019; 20 páginas.
Copyright © 2019. Delinea Tecnologia Educacional. Todos os direitos reservados.
3
Sistemas de banco 
de dados
Apresentação
Neste momento, estudaremos sobre o processo de modelagem de banco de dados 
e, para isso, precisaremos fazer uma análise de suas definições e das três estruturas 
fundamentais dos sistemas: os dados, a informação e o conhecimento. A seguir, 
refletiremos as características e diferenças entre Sistema de Arquivos e Sistema de 
Banco de Dados.
Estudaremos os diferentes modelos de sistemas de banco de dados, sua evolução 
histórica, bem como suas principais funções, recursos e finalidades. Analisaremos 
os tipos de perfis e as perspectivas dos usuários e os profissionais relacionados a 
esses sistemas. Na sequência, veremos como funciona a arquitetura de sistemas de 
bancos de dados.
Definições
Para entendermos sobre Banco de Dados (BD, e em inglês database, sigla DB), 
primeiramente é necessário compreender as definições de Manãs (2007) e Rezende 
(2007) a respeito de três estruturas fundamentais dos sistemas: os dados, a 
informação e o conhecimento.
Os dados são os fatos em sua forma primária e sem qualquer tipo 
de tratamento, “uma representação simbólica (isto é, feita por meio 
de símbolos), quantificada ou quantificável” (SETZER; SILVA, 2005, 
p. 2). 
Atenção
Os itens de dados referem-se a como a organização irá armazenar suas informações 
e como elas serão registradas, levando em consideração que essas informações 
armazenadas não são organizadas para transmitir qualquer significado específico. 
Sendo que esses dados podem ser números, letras, figuras, sons ou imagens. 
4
Quando os dados são processados, ou seja, quando são relacionados logicamente 
e organizados para atingir um resultado definido, eles são transformados em 
informação. Exemplos de dados: número (1, 2), a palavra ‘cachorro’, nome ‘Teco’, 
cor ‘preta’, dentre outros. Exemplo de informação: ‘tenho um cachorro de cor preta, 
com 2 anos de idade, chamado Teco’. Veja na figura a seguir a representação desse 
processamento de dados, onde input (entrada) são os dados, e output (saída) é a 
informação. 
Figura: Transformação de dados (entrada) em informação (saída) 
Fonte: Plataforma Deduca (2018). 
Segundo Stair e Reynolds (2006), a informação pode ser aplicada na prática, 
funcionando como transmissora de entendimento e possibilitando a geração de 
cenários, o que consiste em conhecimento. Exemplo de conhecimento é reconhecer 
uma foto, associando à uma informação prévia. Com relação à parte de informação, 
de acordo com Turban, Rainer e Potter (2007), refere se aos dados que foram 
organizados de modo que tenham significado e valor para o receptor. Outro aspecto 
importante para o SI, conforme Imoniana (2005), está ligado ao conhecimento, 
que consiste em dados e/ou informações que, organizadas e processadas, 
emitirão entendimento, experiência e prática aplicados a um problema ou atividade 
empresarial.
Ao irmos ao supermercado fazer compras e ao final, após passar pelo caixa, 
recebemos o cupom fiscal com a relação dos itens comprados, seus respectivos 
códigos, quantidade e valores unitários, pode-se dizer que a pessoa tem dados em 
sua forma bruta, ou seja, por si só pode ou não ser relevante. Porém, quando esses 
5
dados passam por alguma transformação e passam a ter algum valor ou propósito 
para a empresa no tocante à tomada de decisões, eles passam a ser conhecidos 
como informação, que é o caso do cupom possuir data, hora, o número do caixa, 
nome do atendente, do supermercado, subtotal por item, total da compra, forma de 
pagamento e CPF do comprador.
A informação tornou-se recurso estratégico. Sua importância, como bem explica 
Valentim (1997), resulta numa busca constante por melhores resultados, sustentada 
pelo crescente desenvolvimento tecnológico, o qual possibilitou a transformação 
das organizações, principalmente no que diz respeito à sua estruturação, divisão do 
trabalho, acompanhamento de processos e novas formas de coordenação.
Durante muito tempo, a TI foi tratada e operacionalizada pelas empresas em 
ambientes circunscritos a Centros de Processamento de Dados (CPD), com pessoas 
altamente especializadas que respondiam por suas funções. Rezende e Abreu 
(2008) contam que esse período foi caracterizado pelo custo elevado na aquisição 
de equipamentos de informática e manutenção de uma equipe especializada no 
trato com aquelas tecnologias. Diante desse fato, e aliado às transformações pelas 
quais o ambiente empresarial vem passando ao longo dos últimos anos, o simples 
fato de se ter uma boa estrutura de informática deixou de ser fator diferencial para 
empresas na busca e manutenção de determinada vantagem de ordem competitiva 
(MAÑAS, 2007). Isso está relacionado à falta de estratégia objetiva de implantação 
de tecnologia, pela desconsideração de aspectos comportamentais e políticos 
envolvidos na implantação de um SI na organização e pela valorização apenas da 
tecnologia em detrimento da gestão da informação, cuja definição é
Decidir o que fazer com base em informação e decidir o que fazer 
sobre informação. É ter a capacidade de selecionar dum repositório de 
informação disponível aquela que é relevante para uma determinada 
decisão e, também, construir a estrutura e o design desse repositório. 
(ZORRINHO, 1995, p. 146). 
Entretanto, considera-se que: 
O conhecimento dos sistemas implica em conhecimento não só da parte 
técnica, mas também da parte organizacional com sua hierarquia, regras, 
organização e métodos, e também da parte das pessoas que irão compor 
o sistema: suas funções, necessidade de treinamentos, aspectos sociais 
e psicológicos que no conjunto atuarão para o bom funcionamento do 
sistema. (BOGHI; SHITSUKA, 2007, p. 81). 
6
A produção de conhecimento é realizada em três níveis: estratégico, tático e 
operacional. O nível estratégico é aquele destinado ao assessoramento para 
tomadores de decisões sobre assuntos de maior complexidade, possibilitando a 
adoção de medidas preventivas por parte da direção geral. A atividade em nível 
tático é direcionada a uma determinada área de interesse. E o nível operacional tem 
como objetivo a tomada de decisões baseada em fatos / ações (LIRA et al., 2008). 
Audy (2005) compreende conhecimento como o entendimento de um conjunto de 
informações e de como estas podem ser úteis para apoiar determinado processo, 
tarefa ou tomada de decisão. Em resumo, o dado gera informação e esta gera 
conhecimento. Segundo Laudon e Laudon (2004), um sistema de informação pode 
ser definido como um conjunto de componentes inter-relacionados trabalhando 
juntos para coletar, recuperar, processar, armazenar e distribuir informações, com 
a finalidade de facilitar o planejamento, o controle, a coordenação, a análise e o 
processo decisório em organizações. Um sistema de informação é formado por 
todos os componentes que coletam, manipulam e disseminam informações. Neste 
sistema há o uso de hardware, software, pessoas, sistemas de comunicação como 
linhas telefônicas, e os dados em sua forma primária. Suas principais atividades são 
a entrada de dados, o processamento dos dados em informação, o armazenamento 
destes e, por objetivo principal de um SI, a informação filtrada (REZENDE; ABREU, 
2008). 
Os SIs podem ter diversas classificações, como a forma evolutiva, quanto à 
abrangência da organização, bem como quanto ao suporte às decisões. Para 
Pereira e Fonseca (1997, p. 241), os sistemas de informação têm por finalidade “a 
captura e/ou a recuperação de dados e sua análise em função de um processo de 
decisão envolvem, de modo geral, o decisor, o contexto, o objetivo da decisão e a 
estrutura de apresentação das informações”. 
De forma estruturada, os Sistemas de Informação dão condições para que as 
empresas reajam às mutações do mercado e se sintam alicerçadas por um processodecisório forte o suficiente para garantir a resolução dos problemas. Veja na figura a 
seguir a sequência do processo de tomada de decisão: 
7
Figura: Processo de tomada de decisão
Fonte: Plataforma Deduca (2018). 
Logo, BD é uma coleção de dados relacionados que representam aspectos do 
mundo real (minimundo ou universo de discurso) e mudanças no mundo real devem 
ser refletidas neste ambiente. Esta coleção lógica e coerente de dados possui 
significado inerente e é construída em atendimento a uma proposta específica. Uma 
organização randômica (aleatória) de dados não pode ser considerada um BD. 
Minimundo é uma “porção da realidade captada pelo analista, 
que a gestão de negócios de uma organização tem interesse 
em observar, controlar e administrar. A complexidade existente 
no momento de analisar um minimundo pode levar o analista a 
subdividi-lo em partes menores, às quais damos o nome de visão 
de processo de negócio” (MACHADO, 2014, p. 18). 
Atenção
Os bancos de dados estão cada vez mais presentes em nosso dia a dia, visto que a 
maioria das atividades que realizamos envolvem, direta ou indiretamente, o uso de 
uma base de dados. Eis algumas aplicações representativas: 
8
• Aviação comercial – para reservas e informações de horários; 
• Bancos – para informações de clientes, contas, empréstimos e transações 
financeiras; 
• Economia – para armazenar informações sobre valores mobiliários, vendas e 
compras de instrumentos financeiros como ações e títulos; 
• Escolas – para informações de alunos, registros de cursos e notas; 
• Telecomunicações – para manter registros de chamadas realizadas, contro-
lar fluxo de dados móveis, gerar cobranças; 
• Transações de Cartão de Crédito – para compras com cartões de crédito e 
geração de faturas mensais. 
Sistema de Arquivos X Sistemas de 
Banco de Dados
Quando o acesso aos dados e seu gerenciamento são feitos diretamente por 
programas aplicativos, trata-se de um Sistema de Arquivos, também chamado de 
Sistema de Processamento de Arquivos Convencional. Nele, o processamento é sem 
BD, portanto os dados de diferentes aplicações não estão integrados, pois foram 
projetados para atender a uma aplicação específica. O mesmo objeto é múltiplas 
vezes representado nas várias aplicações, gerando redundância não controlada dos 
dados, inconsistência e redigitação.
Você lembra de alguma outra aplicação em que o banco de dados 
se faz útil? Há lugares em que ainda não há sistema gerenciador? 
Se houvesse, melhoraria a execução de tarefas? 
Reflita
Esses métodos mais antigos de gerenciamento computadorizado de dados 
comerciais (que infelizmente ainda podemos verificar em empresas de menor 
porte) eram típicos da década de 1960, em que as informações do computador 
eram armazenadas em arquivos no Sistema Operacional (SO). Para permitir que os 
usuários as manipulassem, o SO possuía diversos programas aplicativos, que tinham 
como desvantagens: 
9
• Anomalias de acesso concorrente – muitos sistemas permitem que múltiplos 
usuários atualizem os dados simultaneamente, sem controle. Imaginemos 
uma conta poupança com R$100,00 de saldo. Se dois titulares desta conta 
conjunta sacarem dinheiro (R$50,00 e R$100,00) ao mesmo tempo, em distin-
tos terminais de autoatendimento, o resultado das transações concorrentes 
pode deixar a conta inconsistente; 
• Dificuldade no acesso aos dados – supondo que o diretor de uma empresa 
solicite uma lista de todos os clientes que vivem numa rua da cidade com um 
determinado CEP. Se o sistema não foi projetado para tal solicitação, uma 
saída seria obter uma lista geral dos clientes e extrair a informação neces-
sária manualmente, requisitar um programa para processamento de dados 
necessário. 
• Se o filtro for outro, provavelmente o sistema também não conseguirá recupe-
rar os dados necessários de maneira conveniente e eficiente; 
• Isolamento de dados – se os dados estiverem desorganizados e com formatos 
diferentes, será difícil os programas recuperarem os dados adequadamente; 
• Redundância e inconsistência de dados - ao longo do tempo, arquivos têm 
seus formatos diferentes e os programas são desenvolvidos em diversas lin-
guagens de programação. Além disso, ocorre informação duplicada em di-
versos lugares, como numa instituição financeira que guarda o endereço e 
o número do telefone de um cliente em um arquivo que contém registros da 
conta de poupança e em um outro arquivo que contém registros da conta cor-
rente. E a inconsistência de dados pode ocorrer se a mudança de endereço de 
um cliente for efetuada num registro de conta corrente, mas não em qualquer 
outro lugar no sistema; 
• Problemas de segurança – cada perfil de usuário do sistema de banco de da-
dos deve ter um tipo de acesso específico. Exemplificando, o departamento 
de pessoal de uma instituição financeira hipotética que necessita apenas de 
parte do banco de dados para ter informações sobre os funcionários não pre-
cisam ter acesso às contas dos clientes do banco; 
• Problemas de integridade – caso seja necessário satisfazer certos tipos de 
restrições de consistência, como não permitir que o estoque de canetas esfe-
rográficas de uma papelaria seja menor que 10. 
Já o tratamento realizado por um Sistema Gerenciador de Banco de Dados (SGBD) 
funciona como uma interface entre o BD e os programas aplicativos. Portanto, um 
Sistema de Banco de Dados (SBD) envolve usuários (peopleware), dispositivos 
físicos (hardware), programas (softwares) e SGBD. 
10
Vamos agora observar na figura do que é composto um sistema de banco de dados. 
Diagrama: Componentes de um sistema de banco de dados 
 Fonte: Cardoso e Cardoso (2012, p. 18). 
Com SBD, cada informação é armazenada uma única vez. E, mesmo que possa 
ocorrer eventuais redundâncias, são controladas pelo sistema e invisíveis para 
o usuário. Esses sistemas são projetados para gerenciar blocos de informação, 
com estruturas definidas para armazenamento e mecanismos para manipulação e 
segurança, apesar das falhas de sistema ou de tentativas de acesso não autorizado. 
Se os dados precisarem ser compartilhados entre vários usuários, o sistema precisa 
evitar possíveis resultados anômalos. Segundo Date (2003, p. 6), um SBD é “um 
sistema computadorizado cuja finalidade geral é armazenar informações e permitir 
que os usuários busquem e atualizem essas informações quando as solicitar”. 
Sistema gerenciador de banco de 
dados 
Um Sistema Gerenciador de Banco de Dados (SGBD, em inglês: Database 
Management System, sigla DBMS) é uma coleção de programas que permite 
aos usuários criar e manter um banco de dados, facilitando os processos de 
compartilhamento, construção, definição e manipulação de BD entre vários usuários 
e aplicações. Suas principais funções são: 
11
• inclusão (INSERT) – são especificadas as colunas e os dados a serem inseri-
dos nas tabelas; 
• alteração (UPDATE) – são atualizados registros únicos ou em conjunto; 
• exclusão (DELETE) – são apagados dados desnecessários e/ou errados; e 
• consulta (SELECT) – são retornados resultados de uma pesquisa. 
 O papel do SGBD é fundamental na estrutura e consistência de SIs modernos, 
independentemente do porte ou do segmento empresarial. A maior parte dos 
BDs desenvolvidos nos SGBDs baseiam-se no modelo relacional para aplicações 
convencionais. Entretanto, esse modelo apresenta algumas limitações quando os 
dados a serem manipulados são mais complexos, como ocorre em: arquitetura, 
engenharia, experiências científicas, multimídia, sistemas de informações 
geográficas, telecomunicações, dentre outras, necessitando de melhores técnicas de 
acesso a estes dados. 
O paradigma de programação orientado a objetos vem ganhando cada vez mais 
espaço no cenário de desenvolvimento de aplicações, que faz com que o SBD 
também comporte os conceitos desta tecnologia. Neste contexto, novos modelos 
de banco de dados estão em ascendência (RODRIGUES JUNIOR, 2005). Dentre 
eles podemos citar os Sistemas Gerenciadoresde Banco de Dados Orientado 
a Objetos (SGBDOO) e os Sistemas Gerenciadores de Banco de Dados Objeto-
Relacional (SGBDOR). Os SGBDORs combinam as características da programação 
orientada a objetos com as estruturas utilizadas no modelo relacional. Num passado 
não tão distante, escolher o SGBD a ser utilizado em uma aplicação dependia 
de questões técnicas e do custo das licenças destes sistemas. Atualmente, 
isso não é impedimento, devido ao surgimento e disponibilidade de diversos 
SGBDs de qualidade, gratuitos e open source. O SGBD permite que os BDs sejam 
compartilhados por muitos usuários e aplicações, simultaneamente, através de 
estratégias de otimização de armazenamento e desempenho. Além do mais, 
preserva a integridade dos dados ao serem manipulados (NEVES, 2002). Vale a pena 
citarmos alguns exemplos de inúmeros SGBDs comerciais e gratuitos que estão 
disponíveis no mercado: 
• Cassandra: multiplataforma, código aberto; 
• DB2: multiplataforma, da IBM; 
• Firebird: multiplataforma, código aberto; 
• Interbase: multiplataforma, proprietário; 
• MS-Access: ambiente Windows, pertencente ao pacote Office; 
• MS-SQL Server: multiplataforma, proprietário; 
12
• MySQL: multiplataforma, da Oracle; 
• MongoDB: multiplataforma, NoSQL e código aberto; 
• Oracle: multiplataforma, edições proprietárias e livre; 
• PostgreSQL: multiplataforma, código aberto; 
• SQLite: multiplataforma, código aberto. 
Há também alguns programas utilitários que encontramos em um SGBD. Vamos 
conferi-los a seguir: 
• Backup: cria uma cópia completa do banco de dados, geralmente descarre-
gando (dumping) todo o banco de dados em um repositório. 
Também possibilita os backups incremental e diferencial. 
• Carregamento (loading): carrega arquivos e dados existentes dentro do ban-
co de dados. Útil para transferência de dados entre SGBDs ou entre SGBDs e 
outros sistemas (são ferramentas de conversão). 
• Monitoramento de desempenho: monitora o uso do BD e fornece estatísticas 
para o DBA, que pode tomar decisões para melhorar o desempenho. 
• Reorganização de arquivos: reorganiza os arquivos do banco de dados em 
uma nova forma, buscando melhorar seu desempenho. O SGBD oferece iso-
lamento das aplicações em relação aos dados, possibilitando que as aplica-
ções vejam os dados de forma abstrata, independente de detalhes físicos de 
implementação. 
O SGBD oferece isolamento das aplicações em relação aos dados, possibilitando 
que as aplicações vejam os dados de forma abstrata, independente de detalhes 
físicos de implementação. 
A linguagem SQL (Structured Query Language — Linguagem Estruturada de Consulta) 
é uma ferramenta utilizada para a comunicação com o banco de dados, via SGBD. 
Para Cardoso e Cardoso (2012), a SQL possibilita controle, definição e manipulação 
de dados, além de ser classificada, segundo Alves (2014), em três categorias: 
• DDL — Data Definition Language: trabalha com a estrutura e os objetos, tais 
como tabelas, banco de dados, visões (consultas previamente programadas 
para visualização rápida, sem armazenar e alterar) e índices (ordenam e me-
lhorar a velocidade de processamento do BD), de acordo com um determinado 
modelo de dados, criando (create), alterando (alter) e removendo ou excluindo 
(drop). 
13
Pense numa tabela que guarde dados de clientes com as colunas para: código, 
nome, endereço, cidade, UF (unidade federativa) e telefone. Para esta tabela existir, 
tem que haver um espaço dentro do SGBD, que será o banco de dados, que poderá 
ter a Tabela Clientes e outras, se necessário. Para criar o banco de dados, usamos: 
CREATE DATABASE MINHALOJA;
Caso não seja necessário mais o uso do BD, para apagá-lo: 
DROP DATABASE MINHA LOJA;
Se precisar mudar o nome do BD, não precisamos exclui-lo: 
ALTER DATABASE TESTE RENAME TO LOJA;
Dentro do BD, podemos criar as tabelas. Na loja, será preciso armazenar dados de 
clientes (código, nome, endereço, cidade, estado e telefone). Sua criação ficaria 
assim: 
CREATE TABLE CLIENTES (IDCLIENTE INT)
IDCLIENTE INT,
NOME VARCHAR (50), 
ENDEREÇO VARCHAR (100), 
CIDADE VARCHAR (30), 
UF CHAR (2) 
TELEFONE VARCHAR (15)
• DML — Data Manipulation Language: trabalha com linhas, excluindoas, inse-
rindo-as (cláusula insert), modificando-as (cláusula update) e recuperando-as 
(cláusula select). 
Para inserirmos dados na tabela Clientes, devemos indicar as colunas e os seus 
valores: 
14
INSERT INTO CLIENTES (IDCLIENTE, NOME, 
ENDERECO, CIDADE, UF, TELEFONE) 
VALUES (1, ‘Antônio’, ‘Rua Elis 
Joaquim, 123, Centro’, Santos’, ‘SP’, 
‘(11) 1234-1234’);
Caso precise alterar algum registro, como o nome do cliente que antes estava só o 
primeiro nome e será atualizado com o nome completo, utilizamos a sintaxe: 
UPDATE CLIENTES 
SET NOME – ‘Antônio Silva’
WHERE idcliente = 1;
E para podermos consultar todos os dados inseridos na tabela, digitamos e 
executamos o seguinte script: 
SELECT * FROM CLIENTES;
Se quisermos apenas alguns campos, como nome, cidade e UF: 
SELECT NOME, CIDADE, UF FROM CLIENTES
• DCL — Data Control Language: trabalha com usuários, atribuindo permissão 
(grant), removendo permissão (revoke) e negando permissão (deny). 
Todo SGBD precisa de um usuário para trabalhar com suas estruturas, que podemos 
controlar para que o público possa somente fazer consultas: 
GRANT SELECT ON CLIENTES TO PUBLIC
Se precisarmos tirar essa permissão concedida, o comando é: 
REVOKE SELECT ON products FROM PUBLIC;
SQL é a linguagem mais usada pelos SGBDs, que no seu primórdio eram 
incompatíveis entre seus diversos fornecedores. Houve, então, a necessidade de se 
gerar um padrão para a linguagem SQL, com a união de esforços entre o ANSI e a 
ISO (ELMASRI; NAVATHE, 2011). Para um sistema de banco de dados aplicado em 
um projeto de média ou alta complexidade, existe grande número de profissionais 
15
(usuários) envolvidos, desde a fase de criação do projeto, até a fase de manutenção 
propriamente dita. De acordo com Cardoso e Cardoso (2012, p. 24), “no ambiente 
de um sistema de banco de dados é importante definir os usuários e suas funções 
específicas, sendo que a cada um cabe uma tarefa diferenciada”. Enquanto alguns 
buscam conteúdo, outros apenas se preocupam em manter o sistema funcionando 
efetivamente. Para Alves (2014), os usuários podem ser classificados (diferenciados 
ou agrupados) da seguinte maneira: 
• DBA (Database Administrator, ou Administrador do Banco de Dados): respon-
sável pela parte física e por autorizar os acessos ao BD, coordenando e moni-
torando o uso do SGBD; 
• AD (Administrador de Dados): responsável pela parte lógica, sendo o projetis-
ta de BD, que constrói partes do modelo da base de dados;
• Analista de Sistemas: define e projeta aplicações sobre a base de dados.
• Programador: constrói aplicações usando os modelos lógicos existentes;
• Usuários Finais (casuais, especializados e leigos): acessam a base de dados 
por meio de aplicações, sem necessariamente possuir conhecimentos técni-
cos;
• Profissionais de Apoio Técnico: projetistas e desenvolvedores de ferramentas 
do SGBD. A arquitetura de três esquemas, também conhecida como arquite-
tura ANSI/SPARC, tem o objetivo de separar o usuário da aplicação do banco 
de dados físico, por meio de três diferentes níveis de esquemas (ELMASRI; 
NAVATHE, 2011, p. 23).
Vamos conhecer cada um deles:
• Visão interna: é aquela vista pelo responsável pela manutenção e desenvolvi-
mento do SGBD, que se preocupa com a recuperação e manipulação dos da-
dos dentro do BD (menor nível de abstração) e com características da tabela 
e do banco de dados, como tipos de dados a serem inseridos, como valores 
numéricos, lógicos, caracteres, data, hora, entre outros;
• Visão conceitual (ou lógica): utilizada pelo AD e pelo DBA, que são quem defi-
ne normas, procedimentos, o que será armazenado, relacionamentos e garan-
te segurança e confiabilidade, através de diagramas de modelagem;
• Visão externa: é aquela do usuário que operaos sistemas aplicativos, por 
meio de interfaces desenvolvidas pelo analista (programas), buscando o aten-
dimento de suas necessidades, conforme convenções da linguagem, platafor-
ma e arquitetura utilizadas (maior nível de abstração).
16
Arquitetura de sistemas de banco de 
dados
Agora que vimos sobre o Sistema Gerenciador de Banco de Dados, vamos 
compreender a sua arquitetura, que começou centralizada e hoje existe como 
cliente-servidor, monousuária e distribuída. 
Centralizada
Para Elmarsu e Nevathe (2011), a primeira arquitetura que surgiu foi a centralizada, 
em que um computador com grande capacidade de processamento para a época 
(conhecido como mainframe) era o hospedeiro do SGBD e dos emuladores para os 
vários aplicativos. Todo o processamento era executado nos servidores centrais, 
em que os usuários interagiam com o sistema via terminais que só apresentavam 
imagem e se comunicavam a partir dos comandos realizados nos denominados 
‘terminais burros’, conectados ao mainframe por redes de comunicação. Embora a 
arquitetura permitisse que muitos usuários manipulassem grande volume de dados, 
o custo operacional era alto, pois exigia um ambiente especial para as soluções 
centralizadas. Com o barateamento do hardware, os terminais foram sendo trocados 
por estações de trabalho, e naturalmente a tecnologia de banco de dados começou a 
aproveitar esse potencial de processamento no lado do usuário. 
Cliente-servidor 
Em seguida, veio a segunda (e mais utilizada) arquitetura, Cliente- -Servidor, que 
dividiu as tarefas de processamento, o que também reduz o tráfego de dados 
na rede, criando servidores especializados, como os servidores de arquivos. As 
máquinas clientes disponibilizam as interfaces para os usuários, de forma a 
capacitá-los ao uso de servidores. Esta arquitetura também tem autonomia para 
executar aplicações locais.
17
Figura: Banco de dados compartilhados em rede
Fonte: Plataforma Deduca (2019).
Mesmo assim, são necessárias soluções sofisticadas de software que possibilitem 
o tratamento de transações, suas confirmações (commits), desfazê-las (rollbacks), 
coleções de consultas (stored procedures) e gatilhos programados de consistência 
(triggers). No caso específico de BD, nesta arquitetura, um SGBD centralizado é 
implantado no servidor, e assim, as consultas (pelo servidor SQL) e funcionalidades 
transacionais são executadas no servidor. E no lado do cliente (múltiplos usuários), 
é possível formular as consultas e desenvolver programas aplicativos. O servidor 
SQL é conhecido como back-end machine (executa as consultas no SGBD e retorna 
os resultados ao cliente) e o cliente como front-end machine (executa as tarefas do 
aplicativo, fornecendo interface do usuário, a partir da tela e do processamento de 
entrada e saída).
Monousuária 
Há também a arquitetura Monousuária, típica de computadores pessoais, 
em que o BD se encontra no mesmo computador em que são executadas as 
aplicações por um único usuário. O computador pessoal (personal computer 
em inglês, ou simplesmente PC) trabalha em sistema stand-alone, ou seja, faz 
seus processamentos sozinhos. Antigamente esse processamento era bastante 
limitado; porém, com a evolução do hardware, vemos PCs com grande capacidade 
de processamento. Eles utilizam o padrão Xbase e, quando se trata de SGBDs, 
funcionam como hospedeiros e terminais. Desta maneira, possuem um único 
aplicativo a ser executado na máquina. 
18
Distribuída
Por fim, mas não menos importante, existe a arquitetura Distribuída, que é 
estruturada com dois ou mais BD armazenados em locais distintos, em uma rede 
de computadores, possibilitando tolerância a falhas, independência de localização, 
processamento distribuído de consultas e controle de consistência. Nesta arquitetura, 
cada servidor atua semelhante ao sistema cliente-servidor, porém as consultas 
oriundas dos aplicativos são feitas para qualquer servidor, indistintamente. Caso a 
informação solicitada seja mantida por outro servidor(es), o sistema se encarrega de 
obter a informação necessária, de maneira transparente para o aplicativo, que passa 
a atuar consultando a rede, independente de conhecer seus servidores. Exemplos 
típicos são as bases de dados corporativas, que costumam ficar hospedadas em 
servidores virtuais (na nuvem, ou seja, na internet), em que o volume de dados é 
gigantesco e, por isso, deve ser distribuído em diversos servidores. Porém, não é 
dependente de aspectos lógicos de carga de acesso aos dados, ou base de dados 
fracamente acopladas, em que uma informação solicitada vai sendo coletada 
numa propagação da consulta numa cadeia de servidores. Computação em 
nuvem proporciona serviços de Tecnologia da Informação (TI) sob demanda, com 
alcance global e provê serviços para as massas que vão desde o usuário final que 
hospeda seus documentos pessoais na Internet até empresas que terceirizam 
toda infraestrutura de TI para outras empresas. Não só recursos computacionais 
e de armazenamento são entregues sob demanda, mas toda a computação pode 
ser aproveitada na nuvem, o que já vemos com Office 365, Dropbox, Documentos 
do Google, hospedagens de sites, entre muitos outros. A característica básica é a 
existência de diversos programas aplicativos consultando a rede para acessar os 
dados necessários; porém, sem o conhecimento explícito sobre quais servidores 
dispõem desses dados. Agora que vimos sobre a arquitetura do Sistema Gerenciador 
de Banco de Dados, vamos estudar o histórico do banco de dados.
Fechamento 
Ao longo de nossos estudos, tivemos a oportunidade de identificar quais os 
componentes de um sistema de banco de dados e como é o seu funcionamento, 
bem como analisamos os fatores, bem como a sequência de características no 
processo de tomada de decisão para resolução de problemas. Vimos, também, as 
diferenças entre Sistema de Arquivos e Sistema de Banco de Dados.
19
Aprendemos sobre o a evolução, a arquitetura e as finalidades dos sistemas de 
bancos de dado. Conhecemos, portanto, os recursos disponíveis e os perfis de 
usuários e profissionais que utilizam o Sistema Gerenciador de banco de dados. 
20
Referências 
SETZER, V. W.; SILVA, F. S. C. Bancos de dados: aprenda o que são, melhore seu 
conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. 
SILBERSCHATZ, A.; KORTH, H. F.; SURDASHAN, S. Sistema de Banco de Dados. 3. ed. 
São Paulo: Pearson Makron Books, 1999. 
SILVA, R. P. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual Book, 
2007. 
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison - 
Wesley, 2007. 
STAIR, R. M.; REYNOLDS, G. W. Princípios de Sistemas de Informação. São Paulo: 
Pioneira Thomson, 2006. 
S.; SUMATHI, S.; ESAKKIRAJAN, S. Fundamental of Relational Database Management 
Systems. Studies in Computational Intelligence. v. 47, 2007. 
TAKAI, O.K.; ITALIANO, I.C.; FERREIRA, J.E. Introdução a banco de dados. 2005. 
Disponível em: <https://www.ime.usp.br/~jef/apostila.pdf>. Acesso em: 10 maio 
2018. 
TONSIG, S. L. Engenharia de Software: Análise e Projeto de Sistemas. São Paulo: 
Futura, 2003. 
TURBAN, E., RAINER, JR. R. K., POTTER, R. E. Introdução a Sistemas de Informação. 
1. ed. Rio de Janeiro: Elsevier, 2007. 
 ZORRINHO, C. Gestão da informação: condição para vencer. Lisboa: Instituto de 
Apoio às Pequenas e Médias Empresas (IAPMEI), 1995. 
Construção de 
modelo de dados
 BRISIGHELLO, V.
Construção de modelo de dados / Vinícius Brisighello 
Florianópolis, 2019; 23 páginas.
Copyright © 2019. Delinea Tecnologia Educacional. Todos os direitos reservados.
Construção de modelo 
de dados
3
Apresentação
Neste momento, buscaremos uma compreensão do que é um banco de dados, 
analisando seus aspectos introdutórios, bem como as características e as 
finalidades de seus diferentes modelos, sendo eles: o conceitual, o lógico, o físico e o 
de entidade e relacionamento.
Histórico de banco de dados
O primeiro BD surgiu no final de 1960, como evolução dos sistemasde arquivos 
de armazenamento em disco, criando estruturas de armazenamento. Conforme 
a evolução tecnológica, diferentes formas de representação, conhecidas como 
modelos de dados, foram criadas “para descrever a estrutura de um banco de dados, 
as operações para manipular estas estruturas, e certas restrições que o banco de 
dados deve obedecer” (ELMASRI, 2011, p. 137).
Segundo Elmasri e Navathe (2011), o modelo de dados consiste em: conjunto de 
estruturas de dados, como tabelas; conjunto de operadores, como linguagem de 
manipulação; e regras de integridade, definidas no esquema do BD. 
Para compreendermos como se deu a evolução do banco de dados, vamos discutir 
sobre o modelo hierárquico, o modelo em rede, o modelo relacional (amplamente 
utilizado), e por fim, o modelo orientado a objetos. Vamos detalhar cada um deles.
Modelo hierárquico
Os primeiros sistemas de banco de dados chegaram no fim da década de 1960. 
Os modelos de bancos de dados hierárquicos são considerados como o primeiro 
tipo de banco de dados de que se tem notícia. Esse modelo foi desenvolvido 
devido à consolidação dos discos endereçáveis e, em função dessa característica, 
a organização de endereços físicos do disco é utilizada na sua estrutura (ALVES, 
2014). Vamos conferir na figura a seguir um exemplo deste banco de dados.
4
Diagrama: Exemplo de um banco de dados hierárquico
Fonte: Adaptada de Takai et al. (2005).
De acordo com Alves (2014), um BD hierárquico é composto de árvores de registros. 
Dentre os diferentes tipos de registros (segmentos), existem as ligações pai-filho, 
sendo que um determinado registro somente pode possuir um registro pai. Em 
caso de problemas não hierárquicos, criava-se a redundância de dados, pois eram 
necessários mais índices, tornando os tempos de consulta e de processamento 
extremamente altos.
Cada nó da árvore contém registros; cada registro é um conjunto de campos 
(atributos); cada um contendo apenas uma informação. O registro da hierarquia que 
precede a outros é o registro-pai, os outros são chamados de registros-filhos.
A IBM criou o IMS (Information Management System), um dos 
bancos de dados hierárquicos mais conhecidos do mundo
Atenção
Só é possível representar relacionamentos um para (1:1) e (1:n) na forma hierárquica, 
pois o acesso ao BD é feito através de operações de ponteiros de baixo nível que 
unem (por links) os registros. As ferramentas que trabalharam com esta estrutura 
foram as linguagens de programação Clipper e Cobol, e o SGBD DB2.
Agora que conhecemos o modelo hierárquico, vamos abordar o modelo em rede.
5
Modelo em rede
Entre as décadas de 1970 e 1980, surgiu o modelo em rede, com estrutura derivada 
e mais completa do que o modelo hierárquico, composta por entidades (registros), 
atributos (itens de dados), tipos e ocorrência de registros, Linguagem de Definição 
de Dados (DDL) e Linguagem de Manipulação de Dados (DML). 
Em um BD em rede, um determinado registro pode possuir diversos registros pai. A 
única restrição é que em um tipo de ligação, um registro somente pode participar 
uma vez. O IDMS da Cullinet Software (final da década de 1980 foi adquirido pela 
Computer Associates, detentora da linguagem de programação Clipper) tornou-se um 
dos mais conhecidos (ALVES, 2014).
Vamos agora observar na figura a seguir um exemplo deste tipo de banco de dados.
Diagrama: Exemplo de banco de dados em rede
Fonte: Adaptada de Takai et al. (2005).
Agora que compreendemos um pouco sobre o modelo em rede, vamos nos 
aprofundar no modelo relacional.
Modelo relacional
Em meados da década de 1980, fruto dos trabalhos teóricos de Edgard F. Codd 
(IBM), surgiram o System R (IBM) e o INGRES (Universidade da Califórnia), que 
6
inauguraram o modelo relacional, que consiste em um BD com regras básicas de 
integridade que permitem o controle de preenchimento dos campos (das colunas) 
das tabelas existentes no banco de dados.
Assim, um sistema relacional é aquele no qual os dados são percebidos pelos 
usuários como tabelas. Vamos observar no quadro a seguir como está estruturado 
um modelo relacional.
Quadro: Exemplo de banco de dados relacional
COD_CLIENTE NOME RUA CIDADE
1 PEDRO A SÃO PAULO
2 MARIA B JUNDIAI
NUM_CC SALDO COD_CLIENTE NUM_CC
20121 1200 1 20121
21582 1320 2 21582
21352 652 2 21352
Fonte: Adaptada de Takai et al. (2005).
As ligações entre linhas de diferentes tabelas são feitas através do uso de valores 
de atributos. Cada instância do esquema (linha) é chamada de tupla (registro). As 
estruturas de dados desse modelo permitem: 
• Segurança - resguardar o BD de uma possível perda ou destruição de dados, 
a partir da restauração parcial ou total do banco de dados através de cópias 
de segurança;
• Compartilhamento - controle centralizado dos dados compartilhados por di-
versas aplicações, reduzindo a repetição de dados a um mínimo;
• Integridade dos dados - controles de acesso para que os dados possam ser 
acessados somente por pessoas autorizadas, separando programas dos da-
dos;
• Relacionamento entre tabelas com chaves primárias (primary key) e estran-
geiras (foreign key).
Segundo Heuser (2011), previamente à construção de bancos de dados, são 
utilizados padrões em textos e gráficos para modelar (planejar), fazendo uso de três 
níveis de abstração de dados para descrever e propor a uma organização. 
7
Como muitos usuários de BD são leigos nas técnicas de informática, faz-se 
necessário simplificar em um projeto a sua estrutura para oferecer uma visão geral 
dos dados, com os aspectos de interesse, possibilitado BD flexíveis (COUGO, 1997). 
Um dos momentos mais críticos no processo de desenvolvimento de um software 
é a modelagem de banco de dados, pois o produto final deve atingir os objetivos 
estabelecidos pelo requisitante.
Um erro durante a modelagem compromete a usabilidade do sistema final, tendo 
em vista a necessidade de retrabalho, que aumenta o custo do processo de 
desenvolvimento.
Para que isso não ocorra, detalharemos a seguir os passos fundamentais no 
processo de modelagem de um banco de dados. A figura a seguir elucida as etapas 
da modelagem de dados para o desenvolvimento de banco de dados. 
Diagrama: Etapas de modelagem de dados
Fonte: Adaptado de Cougo (1997).
Estas etapas referem-se às atividades de: 
• •	 Identificação	do	problema: estudo detalhado das atividades em questão. 
Quando não há conhecimento prévio sobre o negócio, entrevistas podem le-
vantar informações relevantes sobre as necessidades dos futuros usuários. 
Os Administradores de Dados se reúnem como usuários para entender e do-
cumentar seus requisitos, especificados e detalhados; 
• •	 Modelagem	conceitual	(alto	nível): é a representação que considera exclu-
sivamente o ponto de vista do usuário criador dos dados, levando em consi-
deração fatores técnicos para sua implementação. O nível conceitual especi-
fica como os dados são armazenados e relacionados, independentemente de 
como será implementado no BD. O Diagrama Entidade Relacionamento (DER) 
utiliza elementos gráficos, identificando entidades (um objeto ou evento do 
mundo real sobre o qual desejamos manter um registro, como, por exemplo, 
8
Aluno, Carro, Produto), atributos (é propriedade ou característica que descreve 
uma entidade; tais como nome, data de nascimento, telefone de uma pessoa) 
e relacionamentos (relação entre uma, duas ou mais entidades, na qual asso-
ciamos através da ação entre as entidades, como acontece com Pai – possui 
– Filho), para descrever o modelo de dados de uma aplicação com alto nível 
de abstração (CALIARI, 2007). Peter Chen criou o modelo Entidade-Relaciona-
mento (ER) para modelagem de dados para ambientes relacionais.
Diagrama: Ambientes relacionais
Fonte: Elaborado pelo autor (2018).
• Modelagem	 lógica	 (representativa	 ou	 de	 implementação): de acordo com 
Heuser (2011) e Machado (2014), o modelo lógico descreve e mapeia as es-
truturas que estarão presentes no BD, de acordo com as características da 
abordagem,de modo a não considerar ainda característica específica do 
SGBD que será utilizado. Evitam-se: um grande número de tabelas; tempo lon-
go de resposta nas consultas e atualizações de dados; desperdício de espaço; 
muitos controles de integridade no BD e muitas dependências entre dados;
• Modelagem	física	(baixo	nível): ocorre a implementação da estrutura lógica 
em um SGBD, administrando fisicamente os dados armazenados. Resume-se 
ao Structure Query Language (SQL), que é a linguagem necessária para geren-
ciar um BD relacional (OLIVEIRA, 2002). Aqui são detalhados os componentes 
da estrutura física do banco, como tabelas, campos, tipos de valores, índices, 
etc. Entram em cena os detalhes técnicos do projeto, atendendo a necessida-
de do cliente e já implantando a política de backup e segurança. Nessa fase, 
há a geração dos scripts em código SQL que vão criar a base de dados do 
sistema. Por isso, aqui a tecnologia aplicada já toma o lugar primordial, pois a 
parte de negócios já foi definida e estabelecida.
9
Figura: Os três níveis de modelagem, do maior ao menor grau de abstração
Fonte: Plataforma Deduca (2018).
Os requisitos podem ser descritos graficamente por diagramas, com declarações 
sobre as funções que o sistema deve oferecer de forma abstrata de alto nível. 
Também levando em consideração a engenharia de requisitos, que é um processo 
que engloba todas as atividades que contribui com a elaboração de um documento 
com todos os requisitos e sua manutenção, a etapa de engenharia de requisitos é a 
fase de descobrir analisar, verificar funções e restrições (GIMENES; HUZITA, 2005).
Os requisitos são a base de todos os produtos de software. Sua elucidação, 
gerenciamento e entendimento são problemas comuns a todas as metodologias 
de desenvolvimento. Segundo Pressman (2011) a tarefa de análise de requisitos é 
um processo de descoberta, refinamento, modelagem e especificação. O escopo do 
software, inicialmente estabelecido pelo engenheiro de sistemas e refinado durante o 
planejamento do projeto de software, é aperfeiçoado em detalhes. Modelos de fluxo 
de informação e controle exigidos, comportamento operacional e conteúdo de dados 
são criados. Soluções alternativas são analisadas e atribuídas a vários elementos de 
software (PRESSMAN, 2011).
A análise de requisitos possibilita que o engenheiro de software especifique a função 
e o desempenho do software, indique a interface do software com outros elementos 
do sistema e estabeleça quais são as restrições de projeto que o software deve 
enfrentar. A análise de requisitos proporciona ao projetista de software uma 
representação da informação e da função que pode ser traduzida em projeto 
procedimental, arquitetônico e de dados, oferecendo ao desenvolvedor e cliente os 
critérios para avaliar a qualidade logo que o sistema for construído. 
10
A Unified Modeling Language (UML) é uma linguagem de modelagem não 
proprietária de terceira geração. A UML não é um método de desenvolvimento, o 
que significa que ela não diz ao desenvolvedor o que fazer primeiro e em seguida, 
ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a 
comunicação entre objetos (SILVA, 2007). 
Observe no exemplo do diagrama a seguir, que ilustra três casos de uso, com suas 
respectivas ações: administrador, faculdade e usuário.
Figura: Exemplo de caso de uso
Fonte: ArgoUML Tours (2018).
A UML não indica como fazer um software. Ela indica apenas as formas que 
podem ser utilizadas para representar um software em diversos estágios de 
desenvolvimento, porque é uma forma de comunicar uma ideia. Portanto, a UML não 
pode ser considerada um processo de desenvolvimento, além de ser uma grande 
forma de padronizar as modelagens.
A UML é composta de um conjunto de diagramas, cada um enfocando um aspecto 
distinto do software a ser implementado. A utilização de diversos diagramas 
permite que falhas possam ser descobertas nos diagramas anteriores, diminuindo a 
possibilidade da ocorrência de erros durante a fase de desenvolvimento do software. 
É importante destacar que, embora cada diagrama tenha sua utilidade, nem sempre 
é necessário modelar um sistema utilizando-se de todos os diagramas, pois alguns 
deles possuem funções muito específicas (SAMPAIO, 2007). 
11
Segundo Martins (2007), quando se inicia o desenvolvimento de um novo sistema, 
ou mesmo de uma nova funcionalidade para um sistema existente, um dos primeiros 
passos a ser executado é o estudo e levantamento dos requisitos necessários para a 
construção do produto final. 
O Modelo Entidade de Relacionamento (MER) é um modelo muito usado na 
Engenharia de Software para referenciar objetos, também chamado de entidades, 
envolvido em um domínio de negócios, com seus atributos e como elas se 
relacionam entre si.
Este modelo evidencia de uma forma abstrata a estrutura na qual o banco de dados 
e aplicações irá se encontrar. O banco pode contar com muitas outras entidades, 
como tabelas e chaves, que só vão fazer sentido no contexto do banco de dados 
(MARTINS, 2007). 
Entidades são as partes envolvidas em bancos e podem ser físicas ou lógicas, de 
acordo com a realidade. Entidades físicas são aquelas que existem e são visíveis, 
como, por exemplo, um fornecedor. Já as logicas são aquelas que existem em razão 
de outras entidades físicas, que só irão fazer sentido dentro do domínio de negócio, 
porém na realidade não são objetos físicos, como, por exemplo, uma venda.
Atributos são características que expõem cada entidade dentro do domínio. Um 
exemplo de atributo seria o nome de um cliente (PRESSMAN, 2011). 
Veja que aluno é uma entidade, e cada aluno possui RA (Registro Acadêmico) que o 
identifica com nome e data de nascimento:
Diagrama: Exemplo de registro acadêmico
Fonte: Elaborado pelo autor (2018).
Silberschatz et al. (1999) afirmam que relacionamento é o nome do termo que 
referencia uma interação entre entidades.
12
Outras fases, além dessas apontadas anteriormente, ocorrem em paralelo. Na fase 
de especificação dos requisitos de dados, são especificados os requisitos funcionais 
da aplicação, por meio de Diagramas de Fluxo de Dados (DFD).
Os requisitos funcionais podem ser declarados como as funções de negócio ou 
atividades que o software ou sistemas faz ou fará para a satisfação do cliente 
(REZENDE, 2007). 
Os requisitos funcionais referem-se à descrição das diversas funções que o cliente 
necessita que o software ofereça. Esses requisitos definem a funcionalidade do 
sistema, ou seja, funções, ações ou operações que poderão ser utilizadas (TONSIG, 
2003).
O requisito funcional é parte fundamental, pois define uma função de um software ou 
parte dele. Os requisitos funcionais podem ser definidos como funções de negócio 
ou atividades de uma aplicação. Em outras palavras, requisitos funcionais são 
aqueles que caracterizarão o sistema e os serviços por ele oferecidos.
Requisitos não funcionais descrevem níveis desejáveis de qualidade da aplicação, 
como quão segura a aplicação será, o seu nível de usabilidade entre outros aspectos 
(ALVES,2009).
Para Bezerra (2003 apud AREND, 2013), requisitos não funcionais correspondem a 
especificações ou qualidades relacionadas aos requisitos funcionais. E requisitos 
suplementares são demais qualidades que não se enquadram nos requisitos 
anteriores e pertencem ao sistema como um todo.
Os requisitos não funcionais são aqueles que não estão relacionados diretamente 
às funções do sistema, mas se relacionam com propriedades emergentes do 
sistema, como confiabilidade, tempo de resposta e espaço de armazenamento. Eles 
podem definir restrições como capacidade de entrada e saída, representações de 
dados usadas nas interfaces do sistema; eles podem especificar o desempenho, 
proteção, disponibilidade, entre outras. Os requisitos não funcionais são raramente 
associados às caraterísticas individuais do sistema (SOMMERVILE, 2007). Sendo 
assim, requisitos não funcionais estão relacionados ao uso da aplicaçãoem 
termos de desempenho, usabilidade, confiabilidade, disponibilidade, segurança e 
tecnologias envolvidas. São aqueles que apresentam determinadas restrições que 
devem ser consideradas durante o desenvolvimento da aplicação tanto quanto na 
sua utilização.
13
Para Pfleeger (2004), os requisitos funcionais e os não funcionais devem ser 
identificados com os clientes de uma maneira formal e cuidadosa, já que os clientes 
nem sempre conseguem descrever com exatidão o que querem ou precisam, e os 
aspectos de negócios nem sempre são fáceis de serem entendidos. Os clientes 
possuem conhecimento sobre seus negócios, mas nem sempre conseguem 
descrever seus problemas para pessoas que não são da sua área. Descrições 
cheias de jargões e suposições podem trazer significados diferentes para a mesma 
coisa. Por isso, se não for bem organizada, a comunicação entre desenvolvedores e 
clientes pode levar a uma especificação equivocada ou incompleta.
Figura: Conversa com cliente, para identificação de requisitos funcionais e não funcionais
Fonte: Plataforma Deduca (2018).
Uma característica de sistemas de software é a complexidade do seu 
desenvolvimento, que aumenta à medida que o tamanho do sistema cresce 
(BEZERRA, 2015). “Essa necessidade leva o conceito de modelo, tão importante no 
desenvolvimento de sistemas. De uma perspectiva mais ampla, um modelo pode 
ser visto como uma representação idealizada de um sistema a ser construído” 
(BEZERRA, 2015, p. 4).
Um modelo consiste na captura de uma visão de um sistema físico. É uma 
abstração do sistema com um propósito de descrever aspectos estruturais ou 
comportamentais do software (GUEDES, 2011). Modelo é uma visão simplificada 
que descreve um sistema de um ponto de vista.
14
Modelos definem um conjunto de atividades, ações, tarefas, marcos e produtos 
de trabalho necessários para a engenharia de software. Esses modelos não são 
perfeitos, mas fornecem um roteiro útil para o desenvolvimento (PRESSMAN, 2011).
Modelo é uma visão simplificada que descreve um sistema de um ponto de vista e 
define um conjunto de atividades necessárias para construção de uma aplicação. A 
modelagem nada mais é que uma atividade de construir modelos que expliquem as 
características e o comportamento de uma aplicação.
Assim, a modelagem facilita o entendimento entre os envolvidos ao processo 
de levantamento de requisitos. As formas de modelagem mais utilizadas são 
a prototipação e a modelagem gráfica. Paralelamente ao projeto físico, são 
projetados os programas a serem usados acima do BD, descritos em linguagens de 
programação que suportam comandos da linguagem SQL.
Segundo Neves (2002), o BD relacional é utilizado preferencialmente pelos 
comércios e para problemas cotidianos. O modelo relacional surgiu do estudo 
realizado por Codd, em 1970, influenciado pela teoria dos conjuntos e pela álgebra 
relacional. O objetivo era que usuário entendesse conceitualmente a organização 
interna de um banco de dados. Além disso, o modelo de dados deveria estar 
normalizado, o que significa que deveria seguir regras para garantir a eficaz 
organização dos dados. 
Normalização de dados é o processo de organização das colunas e das próprias 
tabelas do BD relacional para minimizar a redundância e a dependência. Este 
processo comumente envolve a divisão de tabelas grandes em pequenas (e menos 
redundantes) e define relacionamentos entre elas.
De forma objetiva, o que se deseja é isolar dados de forma que a entrada, a 
remoção e a alteração de informações em um campo possam ser feitas em 
apenas uma tabela e se propagar pelo resto do banco de dados, de acordo com os 
relacionamentos já definidos.
Para isso, com auxílio da matemática, regras foram estabelecidas para se obter 
desempenho na manipulação dos dados, que resultou no conjunto de propriedades 
conhecido como Atomicidade, Consistência, Isolamento e Durabilidade (ACID). 
Atomicidade indica que todas ou nenhuma das operações devem ser aplicadas de 
maneira correta no banco de dados; Consistência significa que, independentemente 
da quantidade de transações, deve-se garantir que uma transação não execute 
operações concorrentes, que gerem estado inconsistente ao SGBD; Isolamento: 
transações podem ser executadas simultaneamente, sem que uma saiba o que 
15
(e se) a outra está executando; e Durabilidade vai determinar que a execução seja 
realizada com sucesso (SUMATHI; ESAKKIRAJAN, 2007).
Porém, só na década de 1980 que foi implementado, revelando-se versátil e 
adequado para solucionar casos nos níveis de conceituais e lógicos. A sua estrutura 
fundamental é a relação (ou relacionamento) constituída por um ou mais atributos 
(campos), que referenciam o domínio (tipo de dados a armazenar). Cada instância 
do esquema (linha) é designada por uma tupla (registro). Essas linhas e colunas 
formam as tabelas, também chamadas de relações (SILBERSCHATZ et al., 1999). 
Todavia, para evitar aspectos indesejáveis no modelo relacional, como repetição 
de informação, incapacidade de representação e até perdas, trabalhamos com 
integridade referencial (assegura que um valor que aparece em uma tabela para um 
determinado conjunto de atributos apareça em outro conjunto de atributos em outra 
tabela), chaves (primárias e estrangeiras) e junções de tabelas (podemos ter duas 
ou mais tabelas relacionadas, já que é comum precisarmos de dados de diferentes 
tabelas, agrupando-as por regras especificadas). 
No modelo relacional, cada linha de uma tabela representa um fato que corresponde 
geralmente a uma entidade ou a um relacionamento do mundo real. O nome da 
tabela e os nomes das colunas são utilizados para auxiliar na interpretação do 
significado dos valores em cada linha.
Para que o SGBD seja genuinamente relacional, deve armazenar os dados como 
relações de tal maneira que cada coluna seja identificada independentemente 
de seus nomes sem que a ordenação das linhas seja importante. As operações 
disponíveis para o usuário e as operações usadas internamente pelo sistema devem 
ser operações relacionais verdadeiras; e suportar pelo menos uma variante de 
operação de junção (ELMASRI; NAVATHE, 2011).
Chaves
Dependendo das características dos dados que se pretende armazenar, são 
estabelecidas restrições de integridade para relacionar as tabelas, utilizando-se de 
um campo identificador como chave. Se a chave primária corresponde a uma ou 
mais colunas, não possuindo valores duplicados dentro de uma tabela, uma chave 
estrangeira pode corresponder a uma ou mais colunas em que os valores estejam 
identificados necessariamente como chave primária da outra tabela. A chave 
estrangeira é o mecanismo de ligação e definição dos relacionamentos em um 
banco de dados relacional (DATE, 2000). 
16
A chave primária é escolhida a partir de chaves candidatas (possíveis de identificar 
exclusivamente as tuplas), que irá representar um valor único e não nulo (DATE, 
2000). Por exemplo, se tivermos as tabelas ‘clientes’ e ‘pedidos’, o atributo IDCliente 
da tabela ‘pedidos’ identifica a ligação com a tabela ‘clientes’. Este atributo é 
considerado chave estrangeira na tabela ‘pedidos’, e primária na tabela ‘clientes’. 
Quando a chave primária é simples, ela é formada por um único campo da tabela, 
sendo que este campo não pode ter dois valores ou mais registros de mesmo valor, 
e não pode conter registro nulo. Quando a chave é composta, portanto, formada por 
mais de um campo, os valores podem se repetir, mas não a combinação desses 
valores.
Com essa chave estrangeira, podemos facilitar as consultas e fazer cruzamento de 
dados através destas referências. Perceba que a chave estrangeira não será única 
dentro de uma tabela, mas no caso da chave primária, sempre será e deverá ser 
única.
Restrições do modelo relacional
Enquanto a aplicabilidade do modelo relacional se faz pertinente à prestação de 
serviços e ao comércio, o avanço da tecnologia influencia no desenvolvimento e na 
evolução de sistemas, adicionando novas características,conforme necessidade 
de se representar tipos de dados mais complexos, dando suporte a aplicações em 
Indústria, Comércio, Médica, Científica, Geoprocessamento, Eletrônica, Multimídia, 
Conhecimento e uma infinidade. 
As limitações do modelo relacional estão na dificuldade em representar objetos do 
mundo real, na incompatibilidade com as linguagens de programação orientada a 
objetos, na falta de suporte a grandes bancos de dados e a transações longas. Logo, 
os BD orientados a objetos oferecem flexibilidade, sem ser limitado pelos tipos de 
dados e linguagens de consulta (ELMASRI; NAVATHE, 2011). 
Atualmente, o volume de dados gerados por algumas organizações, como é o caso 
do Google, Amazon, Facebook, Netflix, entre outros, atinge o nível de petabytes 
(equivale a 1.000 terabytes, ou a 1.000.000 de gigabytes). Esses ambientes têm 
se mostrado bastante problemáticos nos processos de gerenciamento desses 
imensos volumes de dados, pois os principais problemas gerados com a utilização 
dos SGBDs relacionais estão concentrados na necessidade de conciliar o modelo 
relacional com a frequente demanda por escalabilidade.
17
Para analisar esse cenário, podemos usar o seguinte exemplo: considere uma 
aplicação web que é executada sobre um SGBD relacional. Devido a um aumento do 
número de usuários e acessos ao aplicativo, o sistema começa a ter uma perceptível 
queda de desempenho. Para corrigir o problema, podemos considerar duas soluções 
alternativas: fazer um upgrade nos recursos no servidor ou adicionar novos de 
servidores para a aplicação.
No entanto, essas soluções seriam totalmente ineficientes se o número de usuários 
continuar crescendo exponencialmente, isso porque o problema passa a ser os 
acessos à base de dados. A melhor solução, nesse caso, seria escalar o banco de 
dados de forma distribuída em vários servidores.
Agora que compreendemos o modelo relacional, vamos conhecer um pouco sobre o 
modelo orientado a objetos.
Modelo orientado a objetos
Os bancos de dados não convencionais, também conhecidos como BDs multimídia 
ou BD orientado a objetos, armazenam dados não alfanuméricos. De acordo com 
Elmasri e Navathe (2011), os dados não convencionais se dividem em quatro 
tipos diferentes, sendo eles: a imagem, os clipes de vídeo, os clipes de áudio e 
documentos (como livros e artigos). 
Quando se usa esse tipo de armazenamento, de maneira geral, ele funciona bem, 
exceto quando o volume de dados passa a ser descontrolado, muito grande, 
precisando de um sistema que gerencie as alterações, que facilite as consultas, 
e nesse ponto o banco de dados é um fator de extrema valia funcional. Segundo 
Silberschatz, Korth e Surdashan (1999), esse tipo de banco de dados ainda tem 
atributos referenciando cada objeto multimídia a quando ele foi criado, quem o criou 
e a qual categoria ele pertence.
Figura: Exemplo de banco de dados orientado a objetos
Fonte: Adaptada de Takai et al. (2005).
18
Além disso, mapear uma linguagem orientada a objetos para um banco relacional 
é sinônimo de custo, e esse paradigma economiza tempo na produção de um 
software. Nas áreas espaciais, telecomunicações, e nas áreas de física e biologia é 
comum seu uso, pois aumenta a performance.
Existem vários bancos de dados orientados a objeto, cada qual para uma aplicação 
e linguagem(ns) de programação também com mesmo paradigma. Vejamos alguns 
exemplos:
• Caché: suporta Java, .Net, C++ e XML;
• DB4Objects: utiliza uma linguagem própria, Object Query Language (OQL), su-
porta Java e .Net;
• Gemstone: DML como linguagem de consulta, suporta Java, C++, C# e XML;
• Jasmine: suporte a Java, Visual Basic, C e C++;
• Matisse: suporta Java, C#, C++, VB, Delphi, Perl, PHP, Eiffel, SmallTalk; 
• Objectivity/DB: suporta C#; C++; Java; Python, Smalltalk; SQL++ e XML;
• Ozone: suporta Java e XML; 
• O2: suporta C e C++;
• Versant: aplicado em áreas financeiras e médicas, sistemas de telecomunica-
ções, redes de transporte e logística, suporta Java e C++.
O BD Orientado a Objetos oferece modelo atual e intuitivo para o desenvolvimento 
de aplicações. De acordo com Larman (2000), o paradigma Orientação a Objeto (OO) 
aproxima a linguagem de computadores ao mundo real, facilitando a modelagem e a 
codificação, pois organiza objetos que interagem entre si. 
Esta técnica propõe reusabilidade, pois elimina redundância de código, aumentando 
a produtividade e melhorando a manutenibilidade, já que o encapsulamento impede 
o acesso direto aos dados dos objetos (LARMAN, 2000). 
Para Elmasri e Navathe (2011), o objeto tem identidade própria, possuindo atributos 
(característica) e métodos (ações). Já a classe é um conjunto de objetos que 
possuem características e comportamentos em comum. Por exemplo, os objetos 
‘Francisco’ e ‘Aparecida’ pertencem à classe ‘Pessoa’. 
De acordo com Deitel e Deitel (2010), o design orientado a objetos (Object-Oriented 
Design - OOD) modela software de maneira parecida àquela utilizada para descrever 
objetos do mundo real. Desta forma, objetos com características similares são 
abstraídos em classes, como, por exemplo, uma classe veículo, onde os objetos 
carro, caminhão e caminhonete possuem características em comum. De acordo 
19
com Guedes (2009), uma classe trata-se de uma abstração de um grupo de objetos 
semelhantes; portanto não é possível trabalhar com uma classe propriamente dita, 
mas apenas com suas instâncias, ou seja, com os objetos da mesma. Desta maneira 
o autor traz o exemplo da classe Pessoa. Segundo o autor, é possível trabalhar 
apenas com as instâncias desta classe como, por exemplo, João e Pedro, que são 
nomes que identificam seus objetos. O autor ainda faz uma analogia entre uma 
planta de uma casa, que exprime o conceito da classe, e uma casa de verdade. 
Assim, não é possível morar numa planta de uma casa, mas a partir dela pode-se 
contruir várias casas. 
De acordo com esta perspectiva, a planta da casa é vista como a classe enquanto 
a casa construída é considerada o objeto. O OOD ainda tem como característica 
o uso do princípio de herança, no qual novas classes são criadas observando as 
características de classes já existentes. Guedes (2009) explica que a utilização de 
herança permite o reaproveitamento de atributos e métodos, otimizando o tempo 
de desenvolvimento e diminuição de linhas de código, além de facilitar futuras 
manutenções.
Outro aspecto do design orientado a objetos é o encapsulamento de atributos e 
operações. De acordo com Deitel e Deitel (2010), os objetos possuem a propriedade 
de ocultamento de informações. 
Desta maneira, um objeto pode se comunicar com outro através de interfaces 
bem definidas, porém não têm permissão de saber como outros objetos são 
implementados, ou seja, os detalhes de implementação estão ocultos dentro do 
próprio objeto.
Por fim, as linguagens de programação tiram proveito do paradigma de orientação 
a objetos para construir softwares com baixo acoplamento e componentes 
reutilizáveis. Conforme destaca Deitel e Deitel (2010), a linguagem de programação 
Java é considerava uma linguagem orientada a objetos. Nesta linguagem, a unidade 
de programação é a classe, onde são definidos métodos, que implementam 
operações, e campos, que implementam atributos. O autor afirma que empacotar 
software como classes permite que sistemas de software futuros reutilizem as 
mesmas. Assim, grupos de classes relacionadas são normalmente empacotados 
como componentes reutilizáveis. Entre as vantagens da reutilização de classes 
existentes para construção de novas classes e programas, está a economia de 
tempo e esforço, além de possibilitar a construção de sistema mais confiáveis e 
eficientes, pois classes e componentes já existentes costumam já ter passado por 
extensos testes de depuração e ajuste de desempenho. 
20
Os BDOOs constituem uma importante etapa na evolução dos SGBDs, satisfazendo 
às exigências das aplicações com persistência e outros recursos na área de padrões 
e modelos ajustados.
FechamentoAo longo de nossos estudos, conseguimos revisar conceitos a respeito de banco 
de dados. Vimos sua evolução desde os sistemas de arquivos, até as arquiteturas 
que foram sendo criadas para poder gerenciar de modo eficaz dados para auxiliar 
nas tomadas de decisão. Concluímos, também, que não podemos ir direto ao SQL, 
usando um SGBD sem planejamento. Ou seja, para um banco de dados ter forma, 
existem fases de modelagem, que subsidiam o projeto de desenvolvimento de 
sistemas de informação.
Referências
AUDY, J. L. N.; ANDRADE, G. K. de; CIDRAL, A. Fundamentos de sistemas de 
informação. Porto Alegre: Bookman, 2005.
ALVES, P. R.C. Engenharia	de	Requisitos	para	Aplicação	WEB.Recife, 2009. 
Disponível em: <http://www.cin.ufpe.br/~in1020/arquivos/ monografias/2009_1/
pablo.pdf> Acesso em: 12 maio 2018.
ALVES, W. P. Banco de dados. São Paulo: Érica, 2014. 
AREND, R. C. Implementação	de	aplicação	web	para	controle	de	gastos	da	central	
telefônica da UTFPR. Pato Branco,2013. Disponível em: <http://repositorio.roca.
utfpr.edu.br/jspui/bitstream/1/2019/1/PB_COADS_2012_2_10.pdf> Acesso em: 12 
maio 2018.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de 
Janeiro: Elsevier, 2015.
BIO, S. R. Sistemas	de	informação: um enfoque gerencial. São Paulo: Atlas, 1996.
BOGHI, C.; SHITSUKA, R. Sistemas	de	Informação: um enfoque dinâmico. São Paulo: 
Érica, 2007.
21
BUILDING A USE CASE DIAGRAM. ARGOUML. Disponível em: <http://argouml.tigris.
org/tours/bdUseCaseDiagram.html>. Acesso em: 11 jun. de 2018.
CALIARI, F. M. Método	para	construção	de	ontologias	a	partir	de	Diagramas	
Entidade-Relacionamento. Curitiba, 2007. Disponível em: <http://livros01.
livrosgratis.com.br/cp035899.pdf>. Acesso em:10 abr. de 2018.
CARDOSO, V.; CARDOSO G. Sistemas de banco de dados: Uma abordagem 
introdutória e aplicada. São Paulo: Saraiva, 2012. 
COUGO, P. S. Modelagem conceitual e projeto de banco de dados. Rio de Janeiro: 
Elsevier,1997.
DATE, C. J. Introdução	a	sistemas	de	bancos	de	dados. 8. ed. Rio de Janeiro: 
Elsevier, 2003. 
DEITEL, P.; DEITEL, H. Java como programar. 8. ed. São Paulo: Pearson Prentice Hall, 
2010.
ELMASRI R.; NAVATHE S. B. Sistemas de banco de dados. São Paulo: Pearson, 2011. 
GIMENES, I.M.S., HUZITA, E.H.M. Desenvolvimento baseado em componentes: 
Conceitos e Técnicas. (s.c.): Ciência Moderna, 2005. 
GORDON, S. R.; GORDON, J. R. Sistema	de	informação: uma abordagem gerencial. 3. 
ed. Rio de Janeiro: LTC, 2006.
GUEDES, G. T. A. UML 2: uma abordagem prática. 2. ed. São Paulo: Novatec, 2011.
HEUSER, C. A. Projeto de banco de dados. Porto Alegre: Bookman, 2011. 
IMONIANA, J. O. Auditoria	de	Sistemas	de	Informação. 1. ed. São Paulo: Atlas, 2005.
LARMAN, C. Utilizando UML e padrões. Porto Alegre: Bookman, 2000. 
LAUDON, K. C.; LAUDON, J. P. Sistemas	de	Informação	Gerenciais	administrando	a	
empresa digital. 5. ed. São Paulo: Pioneira Thomson, 2004.  
LIRA, W. S. et al. A busca e o uso da informação nas organizações. Perspect.	ciênc.	
inf.	[on	line], v. 13, n. 1, 2008. Disponível em <http:// dx.doi. org/10.1590/S1413-
99362008000100011> Acesso em: 10 maio 2018. 
MACHADO, F. N. R. Projeto	e	implementação	de	banco	de	dados. São Paulo: Érica, 
2014. 
http://argouml.tigris.org/tours/bdUseCaseDiagram.html
http://argouml.tigris.org/tours/bdUseCaseDiagram.html
22
MAÑAS, A. V. Administração	de	Sistemas	de	Informação. 7. ed. São Paulo: Érica, 
2007. 
NEVES, D. L. F. PostgreSQL: conceitos e aplicações. São Paulo: Érica, 2002. 
OLIVEIRA, C. H. P. SQL: curso prático. São Paulo: Novatec, 2002.
OLIVEIRA, D. P. C. Sistemas de Informações Gerenciais: Estratégicas Táticas 
Operacionais. 12. ed. São Paulo: Atlas, 2008.
PEREIRA, M. J. L. B.; FONSECA, J. G. M. Faces	da	Decisão: as mudanças de 
paradigmas e o poder da decisão. São Paulo: Makron Books, 1997. 
PFLEEGER, S. L. Engenharia	de	software: teoria e prática. 2. ed. São Paulo: Prentice 
Hall, 2004.
PRESSMAN, R. S. Engenharia	de	software - uma abordagem profissional. 7. ed. São 
Paulo: McGraw-Hill, 2011.
REZENDE, D. A. Planejamento de informações públicas municipais: sistemas de 
informação e de conhecimento, informática e governo eletrônico integrados aos 
planejamentos das prefeituras e municípios. Revista	de	Administração	Pública, Rio 
de Janeiro, v. 41, n. 3, p., mai.-jun. 2007. 
REZENDE, D. A.; ABREU, A. F. Tecnologia	da	informação: aplicada a sistemas de 
informação empresariais. 5. ed. São Paulo: Atlas, 2008.
RODRIGUES JUNIOR, M. C. A implementação objeto-relacional no Oracle. SQL 
Magazine, ed. 15, ano 2, p. 8, 2005. 
SAMPAIO, M. C. História de UML. 2017. Disponível em: <http://www. dsc.ufcg.edu.br/
sam paio>. Acesso em: 9 ago. 2018.
SETZER, V. W.; SILVA, F. S. C. Bancos de dados: aprenda o que são, melhore seu 
conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005.
SILBERSCHATZ, A.; KORTH, H. F.; SURDASHAN, S. Sistema de Banco de Dados. 3. ed. 
São Paulo: Pearson Makron Books, 1999.
SILVA, R. P. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual Book, 
2007.
SOMMERVILLE, I. Engenharia	de	Software. 8. ed. São Paulo: Pearson Addison - 
Wesley, 2007.
23
STAIR, R. M.; REYNOLDS, G. W. Princípios	de	Sistemas	de	Informação. São Paulo: 
Pioneira Thomson, 2006. 
S.; SUMATHI, S.; ESAKKIRAJAN, S. Fundamental of Relational Database Manage 
ment Systems. Studies in Computational Intelligence, v. 47, 2007. 
TAKAI, O.K.; ITALIANO, I.C.; FERREIRA, J.E. Introdução	a	banco	de	dados. 2005. 
Disponível em: <https://www.ime.usp.br/~jef/apostila. pdf>. Acesso em: 10 maio 
2018.
TONSIG, S. L. Engenharia	de	Software: Análise e Projeto de Sistemas. São Paulo: 
Futura, 2003.
TURBAN, E., RAINER, JR. R. K., POTTER, R. E. Introdução	a	Sistemas	de	Informação. 
1. ed. Rio de Janeiro: Elsevier, 2007.
ZORRINHO, C. Gestão	da	informação: condição para vencer. Lisboa: Instituto de 
Apoio às Pequenas e Médias Empresas (IAPMEI), 1995. 
Banco de dados: 
conceito e aspectos 
 BRISIGHELLO, V.
Banco de dados: conceito e aspectos / Vinícius Bri-
sighello 
Florianópolis, 2019; 15 páginas.
Copyright © 2019. Delinea Tecnologia Educacional. Todos os direitos reservados.
3
Banco de dados: 
conceitos e aspectos
Apresentação 
Neste momento de nossos estudos, os aspectos introdutórios e o conceito de banco 
de dados, as principais vantagens de um banco de dados. Em seguida, analisaremos 
as especificidades e finalidades dos diferentes modelos. 
Aspectos Introdutórios
Segundo Heuser (2009, p. 22), banco de dados “é um conjunto de dados integrados 
que tem por objetivo atender uma comunidade de usuários”. E entre as principais 
vantagens de um banco de dados, podemos destacar: 
• Volume: como os dados são armazenados de forma digital, não há necessida-
de de arquivos de papel. 
• Agilidade nas informações: os computadores têm maior capacidade de pro-
cessamento que os seres humanos. 
• Menor trabalho: com eliminação do papel, as tarefas são sempre feitas pelo 
usuário final, por meio de um sistema. 
• Confiabilidade: as informações são mais precisas e atualizadas, pois estão 
disponíveis a qualquer momento. 
• Proteção: os dados não ficam expostos para qualquer pessoa acessar, mas 
sim apenas pessoas autorizadas têm acesso. 
• Compartilhamento de informações: como os dados podem ficar disponíveis a 
qualquer momento, vários departamentos dentro da organização têm acesso 
às informações simultaneamente. 
Neste contexto, uma forma de comunicação padronizada de acesso às informações 
de um banco de dados é por meio dos Sistemas de Gerenciamento de Banco 
de Dados (SGBDs). Amadeu (2015, p. 26) define o “SGBD como parcialmente 
responsável por garantir que todo estado do banco de dados seja um estado 
válido, isto é, um estado que satisfaça a estrutura e as restrições especificadas no 
esquema”. Assim, os SGBDs apresentam como base o modelo de dados relacionais, 
também conhecido por abordagem relacional. Silberschatz, Korth e Sudarshan 
4
(2006, p. 15) definem os modelos de dados relacionaiscomo “um conjunto de 
tabelas para representar tanto os dados quanto às relações entre eles”: 
Modelo de Dados: uma coleção de ferramentas conceituais para descrever 
dados, relações de dados, semântica de dados e restrições de consistência. 
Um modelo de dados oferece uma maneira de descrever o projeto de um 
Banco de Dados no nível físico, lógico e de view. (SILBERSCHATZ; KORTH; 
SUDARSHAN; 2006, p. 5). 
Vale ressaltar que neste momento adotaremos o termo modelo relacional em vez 
de abordagem relacional, optando assim pela forma mais utilizada na literatura. 
A abordagem relacional ou modelo de dados relacionais surgiu em 1970 por Ted 
Cood da IBM Research, tendo como conceito a relação matemática, tabelas e 
valores, e sua teoria está vinculada à teoria de conjuntos e na lógica de predicados 
de primeira ordem. 
Segundo Elmasri e Navathe (2011, p. 90), 
“[...] o modelo relacional representa o banco de dados como uma coleção 
de relações. Informalmente, cada relação se parece com uma tabela de 
valores ou, em alguma extensão, com um arquivo de registros plano”. 
O modelo relacional permite a representação da estrutura lógica do projeto com 
uma visão genérica. Sua estrutura é feita de forma clara e simples, possibilitando 
representar os dados do mundo real como objetos denominados entidade ou 
conjunto de entidades. 
Dessa forma, podemos entender que o modelo relacional é utilizado pela maioria dos 
SGBDs para a criação e a manipulação de informações em um banco de dados. No 
entanto, para que essas informações sejam manipuladas, faz-se necessário adotar 
uma modelagem de dados. 
Para Puga, França e Goya. (2013, p. 77): 
[...] a modelagem de dados é um método de análise que, a partir de fatos 
relevantes a um contexto de negócio, determina a perspectiva dos dados, 
permitindo organizá-los em estruturas bem definidas e estabelecer regras 
de dependência entre eles, além de produzir um modelo expresso por 
uma representação descritiva e gráfica. 
Como objetivos da modelagem de dados, que é considerado por muitos autores como 
a mais importante etapa no desenvolvimento de um banco de dados, podemos citar: 
5
• Entender melhor a regra de negócio do cliente. 
• Colher as informações que compõem o sistema. 
• Elaborar o banco de dados. 
• Contribuir na organização das informações. 
Agora que fizemos uma explanação geral do que tratará este assunto, vamos 
abordar o modelo conceitual. 
Modelo Conceitual 
O que seria o modelo conceitual? O que ele objetiva? Bem, podemos dizer que esse 
modelo tem como objetivo solucionar problemas do mundo real, criando elementos 
globais e interligando-os por meio de estruturas de informação. Para a criação de 
um banco de dados, devemos sempre dar o “start” primeiramente pelo modelo 
conceitual. Mas por que o modelo conceitual é o primeiro a ser criado? Justamente 
porque ele tem por obrigação demonstrar ao usuário final, que nem sempre terá um 
conhecimento de banco de dados, qual a estrutura e as regras de negócios que serão 
implementadas no banco. O modelo conceitual deve atender a todo o processo de 
solicitações cotidiana para que possamos ter esses dados estruturados fisicamente.
É importante destacarmos que o modelo conceitual não é associado 
e não faz parte de nenhum SGDB (Sistema Gerenciador de Banco 
de Dados). O modelo conceitual é útil para identificar e analisar se 
as regras de negócio estão bem definidas e dessa forma não haver 
erros futuros. 
Atenção
A figura a seguir demonstra de forma gráfica a criação de um modelo conceitual. 
6
Figura: Exemplo de modelo conceitual 
 
Fonte: Elaborada pelo autor (2018).
O modelo conceitual também pode ser representado por meio de texto, como: 
• Cadastro de responsáveis: dados necessários: campo Identificador único, 
nome do pai, nome da mãe, telefones. 
• Cadastro de alunos: dados necessários: campo identificador único, código 
identificador do responsável, nome do aluno, idade. 
Para verificarmos se realmente você entendeu como criar um modelo relacional, 
imagine agora se nós perguntássemos a você como você descreveria o modelo 
conceitual para armazenar os dados de um livro? Pense sobre isso e responda para 
você mesmo quais os itens cida. Vamos a ela: Cadastro de livros: identificador do 
livro, título, autor, editora, número de páginas, preço, ano de publicação, número de 
edição, ISBN. Agora que vimos sobre o modelo conceitual, vamos abordar o modelo 
lógico. 
Modelo Lógico
No que será que este modelo difere do modelo conceitual? Bem, podemos dizer 
que o modelo lógico só deve ser inicializado logo após a conclusão do modelo 
conceitual. Diferente do modelo conceitual, o modelo lógico será criado com base 
em um tipo de banco de dados, como SQL Server, Oracle, MySQL, dentre outros. 
Muitos analistas não aceitam que a etapa do modelo conceitual seja importante, 
pois na verdade muitos dizem que não há necessidade e, devido aos prazos curtos 
dos projetos, não criam o modelo conceitual e já começam o desenvolvimento para 
o modelo lógico. Muitos se dão conta de que então nem todo requisito ou solicitação 
ficou completa ou foi atendida corretamente e que poderia ser facilmente criada 
7
e interpretada na elaboração do modelo conceitual. Veja a seguir a representação 
gráfica do modelo lógico, seriam importantes para esse problema. 
A solução que iremos dar agora pode não ser exatamente igual à qual você pensou, 
mas existe uma grande chance de ser muito parecida. Vamos a ela: 
Cadastro de livros: identificador do livro, título, autor, editora, número de páginas, 
preço, ano de publicação, número de edição, ISBN. Agora que vimos sobre o modelo 
conceitual, vamos abordar o modelo lógico.
Figura: Exemplo de modelo lógico 
Fonte: Elaborado pelo autor (2018). 
O modelo lógico também pode ter sua representação de forma textual: 
• Parents (parent_id, father, mother). 
• Students (student_id, name, age, parent_id) parent_id referência Parents. 
• Telephone (telefone_number, parent_id) parent_id referência Parents. 
Agora que compreendemos um pouco sobre o modelo lógico, vamos ao modelo 
físico. 
Modelo Físico
De onde vem o modelo físico? Ele é concebido por meio do modelo lógico e nesse 
modelo é onde será definido os tipos de dados que serão armazenados. No modelo 
físico são criados os componentes de tabelas, campos, tipo de dados e valores, 
índice e uma série de outras informações que serão abordadas mais à frente. 
8
Figura: Exemplo de modelo físico
Fonte: Elaborado pelo autor (2018). 
Para entendermos melhor esse conceito de tabelas, representaremos o modelo 
físico apresentado na figura com tabelas e alguns respectivos valores, como 
podemos observar no quadro a seguir. 
Quadro: Modelo físico representado por tabelas 
Fonte: Elaborado pelo autor (2018). 
Vamos agora abordar sobre o modelo de entidade e relacionamento. 
9
Modelo Entidade Relacionamento 
Esse modelo é composto por três elementos: 
• Entidades; 
• Relacionamentos; 
• Atributos. 
Nesse modelo que iremos criar agora, o objetivo é entendermos a regra de negócio 
para que possamos projetar um sistema por meio das representações gráficas e de 
dados. 
Entidade
A entidade é um elemento/objeto/evento no qual queremos armazenar uma 
informação. Essa entidade corresponde a qualquer coisa do nosso cotidiano. As 
entidades são nomeadas com substantivos concretos ou abstratos que representem 
de forma clara sua função dentro do domínio. Para entendermos o que é essa 
entidade e qual a sua finalidade, podemos citar aqui que uma entidade pode ser, por 
exemplo, comum em vários sistemas como Cliente, Produto, Venda, Turma, Função, 
entre outros. No modelo ER as entidades são representadas graficamente por 
retângulos. 
Figura: Entidade 
Fonte: Elaborado pelo autor (2018).
Uma entidade é a representação de um elemento de dados para um fim específico 
existente no mundo real. Essa entidade terá uma ou várias informações. Cada 
ocorrência