Arquitetura de Dados

Aula 1
PRINCÍPIOS DA ARQUITETURA DE DADOS

Introdução à arquitetura de dados; Características da arquitetura de dados; Modelo de dados, esquemas
e instâncias.
27 minutos
INTRODUÇÃO
Imprimir
Olá, aluno!
“Dados são o novo petróleo”: é possível que você já tenha lido ou ouvido esta expressão nas diversas mídias.
Quando usamos um celular, postamos uma foto no Instagram, acessamos um aplicativo, enviamos uma
mensagem no Whatsapp, ou fazemos um cadastro em um site de vendas, estamos gerando centenas ou
milhares de dados que são armazenados e processados para serem usados de diversas formas.
Conhecer o papel da arquitetura de dados nos contextos modernos é fundamental para que o profissional
possa escolher as melhores tecnologias para ajudar as organizações a alcançarem vantagens competitivas,
analisar transações e até mesmo prever comportamentos com inteligência computacional.
Vamos entender como os dados podem ser “explorados”? Ótimos estudos!
INTRODUÇÃO À ARQUITETURA DE DADOS
Dados são o novo petróleo. Tem valor, mas sem refino não podem ser usados. Podem ser
transformados em gás, plástico, produtos químicos etc. para criar uma entidade valiosa
que conduz uma atividade lucrativa; então os dados precisam ser quebrados, analisados
para ter valor
— (SILVA, 2019, s.p).
Esta foi considerada a primeira menção à analogia do petróleo com dados, feita pelo matemático britânico
Clive Humby, em 2006. Ainda que considerada polêmica, essa fala representa, de forma assertiva, as
proporções enormes que o estudo dos dados e informações ganharam na vida moderna. Cada ação que
efetuamos no nosso dia a dia gera centenas e/ou milhares de dados e, a partir deles, é possível hoje entender
ações do passado, compilar estatísticas e prever certos comportamentos aplicando modelos de aprendizado
de máquina. Com a massividade destes dados oriundos do uso de tecnologias como Big Data e IoT, dispomos
de um cenário profissional rico de oportunidades e profissões, como a do arquiteto de dados.
A arquitetura de dados cuida da organização dos sistemas e componentes que coletam, qualificam,
processam, armazenam, exploram, expõem e dão uso aos dados dentro de uma organização. Os arquitetos
que cuidam deste tema devem entender a estratégia do negócio, ou seja, quais objetivos a organização almeja
alcançar ao longo dos anos, a fim de orientar – por meio de estudos e alinhamentos – como os sistemas
devem se conectar e suportar essa estratégia.
O início da transformação das informações do mundo real em modelos matemáticos foi em 1948, com o
artigo A mathematical theory of communication (Teoria matemática sobre comunicação), redigido por Claude
Shannon e publicado na revista técnica do icônico Laboratório Bell (o mesmo onde surgiu o transistor). É
nesse artigo que o cientista trouxe ao mundo o conceito de bit, contração da expressão binary digit (em
português, dígito binário), que representa a menor unidade de informação que podemos obter sobre
qualquer coisa existente: é ou não é, sim e não, 1 ou 0, de uma forma binária e atômica (SHANNON, 1948).
Claude também foi responsável pelo primeiro circuito elétrico a implantar este conceito, e toda a era de
computação eletrônica foi fundada com base em seus estudos. Em um computador, sinais elétricos são
gerados, armazenados e operados de forma a processar (passar por cálculos matemáticos) desde poucos
bytes de informações, geradas, por exemplo, pelos nossos teclados, até volumes gigantescos de dados, como
os oriundos de equipamentos sensores de sismologia e astronomia.
Dados e sabedoria
Assim como temos adjetivos na língua portuguesa para qualificar coisas, um metadado é um dado
qualificador de outro dado. É nesse momento que passamos a ter informação, o próximo nível de
entendimento de um dado.
Quando essa informação começa a ser cruzada com outras pregressas, gerando conclusões, atingimos o
patamar do conhecimento. Imagine, por exemplo, que obtemos a informação de que uma casa fica no topo
da montanha. Sabendo disso, é possível começar a inferir algumas verdades: esta casa deve ser fria, pois
temos a noção pregressa de que o topo de uma montanha é um lugar onde venta muito. Também inferimos
que esta casa fica a uma altura positiva considerável do nível do mar, ou seja, a casa fica a vários metros do
chão; isso exemplifica, então, o conhecimento.
Por fim, quando cruzamos um conjunto de conhecimentos e aplicamos modelos científicos, razão e
experiências, aquele dado foi enriquecido e atingiu o patamar da sabedoria.
Essa hierarquia informacional também é conhecida como “pirâmide DIKW” (SHARMA, 2008), acrônimo oriundo
das iniciais de cada patamar de transformação do dado em inglês: Wisdom (sabedoria), Knowledge
(conhecimento), Information (informação) e Data (dados).
Figura 1 | Pirâmide DIKW

Fonte: elaborada pelo autor.
VIDEOAULA: INTRODUÇÃO À ARQUITETURA DE DADOS
Reforçaremos o entendimento do papel dos profissionais que lidam com dados e como as organizações
desejam utilizar seus mananciais de informações. Pesquisas mostram que o crescimento de dados em 2021
chegará a quase 100 Zetabytes, ou muito mais de um decilhão de bytes. Novas profissões surgiram e vamos
conhecê-las a fundo.
Videoaula: Introdução à arquitetura de dados
Para visualizar o objeto, acesse seu material digital.
CARACTERÍSTICAS DA ARQUITETURA DE DADOS
A arquitetura no contexto organizacional divide-se em diversas especialidades, tendo como mãe a arquitetura
corporativa. A função dela é alinhar, monitorar e garantir que a estratégia da empresa esteja sendo
executada, e que os planos propostos para o negócio em médio e longo prazo sejam cumpridos. Existem
alguns frameworks (padrões, referências) que auxiliam os arquitetos a tratar os diversos temas envolvidos.
Um dos frameworks de arquitetura mais conhecidos é, sem dúvida, o The Open Group Architecture
Framework (TOGAF®), cuja última versão (9.2) foi publicada mundialmente em abril de 2018. O TOGAF
considera que a arquitetura corporativa está dividida em quatro grandes componentes:
Quadro 1 | Componente conforme TOGAF

Componentes conforme TOGAF Descrição
Arquitetura de Negócio A partir das cadeias de valor de uma organização

(vendas, recursos humanos, tecnologia, logística,
etc.) são identificadas as capacidades e os serviços
que o negócio oferece.
Arquitetura de Aplicações A partir das capacidades que o negócio possui,

organizam-se os sistemas que vão suportá-las
(sistemas de atendimento, faturamento, ativação,
análise de crédito, etc.).
Arquitetura de Dados Como já vimos no início da aula, é responsável pela

organização dos sistemas e componentes que
coletam, qualificam, processam, armazenam,
exploram, expõem e dão uso aos dados dentro de
uma organização.
Arquitetura de Tecnologia Cuida de toda a infraestrutura (servidores,

elementos de rede, bancos de dados, sistemas
operacionais, diretórios, etc.) que suporta os
sistemas e mantém os dados.
Fonte: Elaborado pelo autor.
Dentro da arquitetura de dados, podemos ter diversas formas de enxergar suas características. Duas delas
são:
1. Camadas organizacionais
Barbieri (2019) indica algumas camadas orientadas pelo fluxo de informações em uma empresa:
Figura 2 | Estratégia de negócio

Fonte: adaptada de Barbieri (2019).
A partir da camada inferior, temos os requisitos das demandas de negócio, baseados na estratégia da
empresa para seus produtos ou serviços. Em seguida, temos o conjunto de dados e significados das
entidades com que o negócio opera (clientes, vendas, pedidos, reparos, etc.), bem como as regras que
devem ser aplicadas a elas. Na terceira camada, temos todo o ciclo de vida dos dados, desde quando são
adquiridos pelos sistemas até o seu descarte. Na penúltima camada, temos os tipos de dados e as formas
como são entregues (cargas, processamento, transmissão, transformações, etc.). E, finalmente, para organizar
todo esse ecossistema empresarial, é necessário estabelecer processos, procedimentos, padrões, capacitar
pessoas, medir desempenho... Funções típicas da governança de dados.
2. Jornada da informação
Durante a década de 1960, o Coronel da Força Aérea John Boyd (1927-1997) desenvolveu algumas teorias de
estratégia militar, sendo a mais famosa a que chamamos Ciclo OODA.
Figura 3 | Ciclo OODA
Fonte: Elaborado pelo autor
A fim de auxiliar a rápida tomada de decisão que os pilotos de caça precisavam ter durante a Guerra da
Coréia, Boyd criou um processo ágil e orientado ao tratamento de dados e ao uso das informações, cujo
conceito hoje é aplicado largamente na arquitetura de dados:
Figura 4 | Ciclo OODA

1. Observação: coleta de dados relevantes a partir de fontes confiáveis.
2. Orientação: contextualização dos dados coletados, criando consciência situacional.
3. Direção: analisar, comparar e pesar os dados para a tomada de decisão.
4. Ação: após a análise dos cenários informacionais, conduzir ações para responder à observação.
Ambas as visões citadas permitem analisar o aspecto dos dados e as informações sob a óptica organizacional
e operacional, sendo, portando, complementares.
Frameworks de dados
Assim como existem referências como o TOGAF®, no universo de arquitetura de dados temos um conjunto
de boas práticas e conceitos denominado Data Management Book of Knowledge (DMBoK®), que seria o
Corpo de conhecimento da gestão de dados, em português (BARBIERI, 2019).
VIDEOAULA: CARACTERÍSTICAS DA ARQUITETURA DE DADOS
Vamos falar um pouco sobre as características do DMBoK® e suas 11 funções estratégicas, contendo boas
práticas para lidar com a governança e com a arquitetura de dados. Existem, ainda, o Modelo de Capacidade
da Gestão de Dados (do inglês, Data Management Capability Model) e o Modelo de Maturidade da Gestão de
Dados (também do inglês, Data Management Maturity Model).
Videoaula: Características da arquitetura de dados

MODELO DE DADOS, ESQUEMAS E INSTÂNCIAS
Antes de criarmos uma base de dados que estará sob a gestão de um Sistema Gerenciador de Banco de
Dados (SGBD), precisamos descrevê-la. Esse material descritivo é chamado de Esquema. Podemos considerar
dois tipos de esquemas (SILBERSCHATZ; KORTH; SUDARSHAN, 2010):
• Esquema de dados de alto nível: também chamado de esquema de dados conceitual, exprime as
entidades (assuntos), seus atributos (campos) e suas relações (relacionamentos). Mostra uma visão mais
resumida e consolidada da organização dos dados. A visão é mais próxima da realidade dos usuários e mais
funcional.
• Esquema de dados de baixo nível: também chamado de esquema de dados físico, apresenta os dados tal
qual são armazenados, suas estruturas, seus tipos e restrições. É operacional e pragmático, com um nível de
detalhe mais granular e técnico.
Figura 5 | Esquema de dados de alto-nível
Já uma instância de banco é uma implementação desse esquema, traduzindo-se em tabelas com registros
reais armazenados no banco. É como a visão do conjunto de dados de um banco em um determinando
momento no tempo.
Ao descrever como os dados serão organizados, relacionados e integrados, estaremos criando o que se
chama de modelo de dados.
Modelos de banco de dados em sistemas de arquivos e hierárquicos

As primeiras implementações de bancos de dados foram feitas com base em agrupamento de registros
(nome, telefone, endereço, etc.) salvos em arquivos. Naturalmente, em função das tecnologias de
armazenamento e hardware em geral da época, usar um Sistema Gerenciador de Arquivos (File Management
System) apresentava diversas limitações. Posteriormente, surgiram os modelos de banco de dados
hierárquicos, desenvolvidos pela IBM, com o lançamento, em 1969, do Information Management System
(IMS), ou Sistema de Gerenciamento da Informação, em português (HAIGH, 2016).
Modelo de banco de dados relacional

Já a partir da década de 1980, surgiu, com os estudos de Edgar F. Codd, matemático que trabalhava na IBM, o
modelo de banco de dados relacional. Esse modelo trouxe consigo alguns conceitos importantes e marcantes
até hoje na indústria:
1. Aplicações dos conceitos matemáticos da teoria dos conjuntos para criar relações – daí o nome
relacional – e cruzamentos entre os dados contidos em tabelas e campos.
2. Normalização dos dados – com as estruturas de dados cartesianas, surgiu a necessidade de atomizar,
separar os dados em função de sua granularidade, surgindo o conceito de normalização de dados.
3. Linguagem de manipulação – era possível criar, alterar, excluir dados e modificar os esquemas do banco
usando uma linguagem com uma sintaxe mais próxima das buscas que uma pessoa poderia fazer. Era o início
do uso do Structured Query Language (SQL), ou Linguagem de Consulta Estruturada.
Modelo de banco de dados orientado a objetos

Com o advento do modelo de Programação Orientada a Objetos (POO), introduzida em linguagens como C++
e Java, surgiram dificuldades de acesso a estruturas de dados complexas e diretamente a partir de comandos
dessas linguagens, que lidam com o conceito de objetos (representações de coisas do mundo real), atributos
(propriedades dessas coisas) e métodos (ações que essas coisas podem realizar).
Modelo de banco de dados não relacional

Depois da era de grandes volumes de dados, o modelo relacional passou a perder em quesitos como
escalabilidade e processamento veloz dos dados. Surgiram, então, os modelos de bases chamados de NoSQL
(Não somente SQL, em português). Eles podem trabalhar com pares de valor-chave ou armazenando de
arquivos de definição como JSON ou XML (HURWITZ et al., 2015).
VIDEOAULA: MODELO DE DADOS, ESQUEMAS E INSTÂNCIAS
Além dos modelos de bases de dados que conceituamos, existem alguns modernos, como bases colunares,
muito utilizados em soluções que envolvam Big Data, bases em grafos, largamente utilizadas em análise de
relacionamentos de redes sociais e e-commerce, e bases espaciais, que permitem lidar com o
georreferenciamento de objetos e lugares.
Videoaula: Modelo de dados, esquemas e instâncias

ESTUDO DE CASO
Considere que você acabou de ser contratado como arquiteto de dados na empresa xData. Um dos clientes
da empresa hoje possui uma base de dados que usa o conceito de tabelas. Esses dados estão sendo
armazenados em um banco de dados SQL Server, executando em dois servidores que estão no datacenter da
empresa. Atualmente, o banco possui 4 tabelas com cerca de 100 mil dados armazenados em cada uma. As
principais entidades desse banco são clientes, pedidos, produtos e ordens de serviço.
Seu coordenador solicitou que você redigisse um desenho de arquitetura indicando:
• Uma descrição básica dos esquemas conceituais e físicos do banco de dados.
• O modelo de dados utilizado pelo banco.
• Uma informação sobre sua instância.
Com base nas informações que você obteve até agora, como desenharia esta arquitetura?
RESOLUÇÃO DO ESTUDO DE CASO
Esquema Conceitual: Clientes – Pedidos – Ordens de Serviço – Produtos.
Esquema Físico: 2 servidores de banco de dados instalados on-premise (dentro do datacenter local da
empresa).
Modelo de banco: as informações no texto nos dão duas dicas: bancos relacionais usam tabelas e suas
relações. Ao identificarmos o SQL Server como a base usada, confirmamos que é um banco de dados do tipo
relacional e não baseado em objetos ou NoSQL, o que é importante para nossa descrição.
Figura 6 | Módulo Lógico Simplificado
Fonte: SQL Server

A instância do banco, no momento presente, possui 4 tabelas com, aproximadamente, 400 mil dados ao todo
(4 tabelas x 100 mil dados).
Resolução do Estudo de Caso
 Saiba mais
Leia o arquivo Ciência dos dados publicado pelo Prof. Dr. George Henrique Godim da Fonseca.
Aula 2
MODELOS DE ARQUITETURA DE DADOS

Arquitetura de três esquemas ANSI/SPARC; Linguagens de arquitetura de dados; Arquiteturas
centralizadas.
28 minutos
INTRODUÇÃO
Olá, aluno!
Vamos agora aprofundar os conhecimentos a respeito do universo dos bancos de dados, explorando os
modelos e a linguagem de arquitetura de dados. Ambos são componentes complementares porque explicam-
se mutuamente em uma boa documentação. É papel do arquiteto de dados descrever de forma concisa, clara
e didática como os dados são organizados e distribuídos entre as bases.
Os modelos vão enriquecer nosso conhecimento profissional no que diz respeito ao desenho de soluções
robustas e dinâmicas para o mundo informacional. Já a linguagem ajudará na implementação de tudo o que
foi recomendado e prescrito nos esquemas de banco de dados.
Vamos entender como os dados podem ser modelados e acessados?
Ótimos estudos!
ARQUITETURA DE TRÊS ESQUEMAS ANSI/SPARC

A chamada arquitetura ANSI/SPARC (American National Standards Institute/Standards Planning And
Requirements Committee) foi proposta em 1975, com base e suporte do Conference/Committee on Data
Systems Languages (CODASYL), consórcio por trás do desenvolvimento dos bancos hierárquicos e da
linguagem de desenvolvimento COBOL (KISHANSING; SUTHAR, 2014).
Nessa arquitetura, temos um modelo de três camadas, distribuídas desta forma:
1. Camada interna ou física.
2. Camada conceitual.
3. Camada externa.
A camada interna ou física descreverá como os dados estão armazenados de fato, ou seja, qual Sistema
Gerenciador de Banco de Dados (SGBD) é usado, em que nuvens ou servidores se encontram, quais são suas
partições, qual seu tamanho em disco, quais as quantidades de tabelas, quais capacidades de atendimento às
requisições, etc. Trata-se de uma visão de máquina sobre o banco de dados. Nessa camada, temos duas
subdivisões relevantes: a operação dos discos, memória e dispositivos fica a cargo do sistema operacional,
comandado pelo SGBD. Este é o responsável pelas solicitações de operações de escrita, leitura, atualização e
deleção ao sistema operacional.
A camada conceitual ou lógica é a chave deste modelo, provendo sua maior vantagem: desacoplar a parte
física do banco de suas estruturas lógicas. Independentemente do banco a ser utilizado e instalado na
solução, existe uma camada que vai tratar da visão do negócio sobre os dados, suas especificações, regras de
processamento, descrições e, em especial, a semântica (significado) dos dados.
A camada externa representa como a informação é apresentada aos usuários. Cada usuário ou grupo de
usuários requer informações personalizadas, oriundas de cruzamentos de diversas tabelas. Imagine uma
organização com variados departamentos e suas respectivas despesas: o departamento financeiro terá visões
globais sobre todos os setores, mas cada repartição quererá ver suas próprias despesas, às vezes até
cruzando-as com informações de outros setores, como RH, a fim de determinar e controlar seus custos de
forma independente. Nesse caso, usa-se o conceito de views (visões) de banco de dados. Trata-se de
estruturas de dados virtuais que no modelo relacional representam o resultado do cruzamento dinâmico de
duas ou mais tabelas e que podem ser consultadas por comandos SQL tal qual fossem tabelas de fato. Sua
grande vantagem é permitir flexibilidade e não ser necessária a criação/alteração/deleção das tabelas de
dados de origem. O foco é mostrar os conteúdos do banco que sejam relevantes para os usuários.
Figura 1 | Conteúdos de banco de dados

Com o uso desse modelo de três esquemas, temos duas características importantíssimas: desacoplamento e
modularidade. O desacoplamento ocorre pela possibilidade de troca ou melhora da camada física sem
precisarmos alterar significativamente a camada conceitual. Por sua vez, não alterar ou alterar pouco a
camada conceitual permite manter a camada externa, sem criar tanto impacto aos usuários. A modularidade
vem em tratar a base de dados exatamente como compartimentos, com cada camada sendo um módulo
dentro do banco de dados.
O modelo ANSI/SPARC nunca foi um modelo formal, e existem críticas pelo entendimento de que é um
modelo ideal, não sendo necessariamente seguido à risca pelos fabricantes e desenvolvedores. De qualquer
forma, é uma referência importante no mercado até hoje.
VIDEOAULA: ARQUITETURA DE TRÊS ESQUEMAS ANSI/SPARC
O arquiteto de dados pode detalhar a camada conceitual utilizando o modelo de entidade-relacionamentos.

Nele, as entidades são objetos ou ações existentes no mundo real, como um cliente ou uma venda. As
entidades são substantivos e, as ações, verbos. As entidades têm atributos, que são qualidades daquele
objeto. Vamos ver um exemplo de modelo.
Videoaula: Arquitetura de três esquemas ANSI/SPARC
LINGUAGENS DE ARQUITETURA DE DADOS
Junto com as pesquisas do matemático Edgar F. Codd, que culminaram com a criação do banco de dados
relacional na década de 1970, surgiu também uma linguagem que, até os dias de hoje, é amplamente
consolidada e usada no campo da tecnologia da informação: a Structured Query Language ou SQL
(Linguagem de consulta estruturada, em português) (IBM, 2011).
O primeiro SGBD a implementar a linguagem SQL foi o Sistema R, produto das pesquisas de Edgar no Centro
de Pesquisas de Almaden, em San José, Califórnia. Tratava-se do resultado de uma prova de conceito para o
banco relacional (IBM, 2011).
A abrangência e completude da linguagem a tornaram um modelo e inspiração para outras linguagens e

sistemas e fizeram com que ela se tornasse, anos mais tarde, uma norma ISSO/IEC. A ideia era criar uma
sintaxe que permitisse ser próxima à lógica de consulta humana e com comandos expertos, que pudessem
ser combinados para realizar complexas pesquisas dentro do SGBD.
O último padrão para a linguagem data de 1999 (SQL-99) e divide-se em um conjunto de comandos de núcleo
(core) e comandos adicionais ou opcionais (packages), que atendem a manipulações de dados de domínios
específicos (exemplo: bancos de dados espaciais).
A linguagem está dividida em grupos de comandos, para finalidades distintas (CEZAR, 2017):
1. Data Definition Language.
2. Data Manipulation Language.
3. Data Control Language.
Linguagem de Definição de Dados (DDL)

A Linguagem de Definição de Dados (Data Definition Language, em inglês, ou DDL) contém comandos para a
criação do banco em si, ou seja, para a manipulação dos objetos do banco de dados, criando seu esquema. É
possível criar uma base de dados, excluir uma base ou alterá-la, por exemplo.
Eis algumas sintaxes:
• CREATE TABLE [nome da tabela] ([definição da coluna]) [parâmetros da tabela].
• ALTER [tipo de objeto] [nome do objeto] [parâmetros].
Linguagem de Manipulação de Dados (DML)

Uma vez feita a criação dos objetos que vão sustentar o esquema do banco, é preciso popular seus dados. Os
comandos existentes nesse grupo de comandos servem a esse propósito; por eles, podemos inserir dados,
pesquisá-los, atualizá-los e exclui-los.
Alguns comandos importantes:
• INSERT INTO [nome da tabela] [colunas] VALUES [valores].
• SELECT [nome da coluna] from [nome da tabela] where [condições].
• UPDATE [nome da tabela] SET [nome da coluna = valor].
• DELETE FROM [nome da tabela] where [condição].
Linguagem de Controle de Dados (DCL)

Este conjunto de comandos permite ao administrador do SGBD controlar o acesso ao banco em si e aos seus
objetos. Por ele, é possível controlar que outros tipos de comandos podem ser executados por um grupo ou
um usuário específico. Podemos, por exemplo, conceder e remover permissões de um usuário.
Alguns comandos relevantes:
• GRANT [Tipo de Comando DML] ON [nome da tabela] TO [usuario(s)].
• REVOKE [Tipo de Comando DML] ON [nome da tabela] TO [usuario(s)].
VIDEOAULA: LINGUAGENS DE ARQUITETURA DE DADOS
Vamos entender quais as principais diferenças de um banco de dados que usa SQL em relação aos chamados
NoSQL (Não só SQL, em português). As bases de dados NoSQL são importantes na atualidade em função das
novas tecnologias de informação nos campos de mídias sociais, localização geoespacial e big data.
Veja algumas características dos tipos de bases (outras serão exploradas no vídeo):
Quadro 1 | Características dos tipos de bases
Características NoSQL SQL
Esquema Dados independentes de Dados seguindo um esquema

esquema. definido e sincronizado.
Variabilidade Alta tolerância à variabilidade ou Segue definições de estrutura de

sazonalidade. dados com menos flexibilidade.
Fonte: elaborado pelo autor.
Videoaula: Linguagens de arquitetura de dados

ARQUITETURAS CENTRALIZADAS
Ao longo dos anos de atualização dos conceitos e usos dos SGBDs, surgiram, em pararelo, outras tecnologias
de hardware e computação, o que originou novas formas de implantar a infraestrutura necessária para utilizar
um banco de dados com aplicações consumidoras.
A arquitetura de implantação do consumo de dados evoluiu e precisou se ajustar a essas novas tecnologias,
desde os tempos do mainframe até o advento dos ambientes clouds atuais.
Arquitetura centralizada ou de uma camada (Single Tier, em inglês)

(MUKTHAR, 2019)
Característica da era dos mainframes (computadores de grande porte que iniciaram a era dos grandes
processamentos corporativos e científicos), a arquitetura de uma camada tinha o SGBD instalado e acessado a
partir da mesma máquina e sob o mesmo sistema operacional. Todo o processamento estava nessa máquina
e os comandos para acesso e consulta às aplicações e ao banco eram feitos por meio dos dumb terminals, ou
“terminais burrinhos”, em português.
Em termos de benefícios desse modelo, ele era simples e eficiente, no entanto, os custos de manutenção do
servidor bem como a falta de escalabilidade eram pontos fracos.
Arquitetura de duas camadas (Dual Tier, em inglês)

Conforme o advento da computação distribuída, com servidores menores e mais baratos e com os
computadores pessoais (PC), surgiram os primeiros modelos de duas camadas, nos quais havia um servidor
de banco de dados que era acessado por um computador cliente com poder de processamento. Este foi o
surgimento do modelo client-servidor. O cliente faz uma requisição ao servidor, o servidor responde com os
dados e o cliente processa o recebimento, apresentando-o ao usuário, que pode fazer novas consultas, num
círculo virtuoso.
Este modelo apresentava um custo menor comparando-se ao uso do mainframe, entretanto, precisa de
grandes investimentos nas redes de comunicações de dados e na aquisição dos clientes.
Arquitetura em três camadas (Three-Tier, em inglês)

A proposta do modelo em três camadas era permitir o desacoplamento do servidor de banco diretamente às
máquinas clientes. Também permitia o processamento offline, ou seja, os usuários poderiam solicitar
informações das aplicações sem a necessidade de aguardar o resultado na mesma hora, o que é eficiente
para processamentos massivos.
Figura 2 | Processamento offline

Nesse modelo, temos um ou mais servidores intermediários, normalmente vinculados a aplicações que vão
trabalhar regras de negócio, e estes, então, comunicam-se com o banco para realizar os processamentos.
Podemos tipificar as três camadas da seguinte forma:
• Camada de apresentação: é por onde o usuário vai interagir para atender a suas demandas informacionais.
• Camada de aplicação: é nela que uma determinada aplicação é instalada, e é ela que atende às requisições
da camada de apresentação, processa e submete à camada de banco de dados para tratamento.
• Camada de banco de dados: é onde o SGBD fica instalado, normalmente em um servidor diferente daquele
da aplicação, permitindo que haja desacoplamento e aumentando a segurança do sistema (se o servidor de
banco de dados sofrer algum problema, o servidor de aplicação pode, por exemplo, enfileirar as requisições, e
assim que o banco for restabelecido, processará a fila normalmente).
VIDEOAULA: ARQUITETURAS CENTRALIZADAS
Vamos falar sobre arquitetura de implantação de bancos de dados em cloud e quais os bancos das principais
nuvens do mercado. Nesse modelo, uma organização pode contratar somente os servidores (a modalidade
PaaS – Platform-as-a-Service) ou serviços gerenciados, consumindo e publicando informações sem preocupar-
se com quais servidores está lidando ou onde eles estão fisicamente. Esse modelo barateia os custos de
infraestrutura, na medida em que a organização não precisa alugar ou possuir um data center físico, e
também permite que a atualização do parque seja efetiva e que a criação dos bancos seja feita de forma
muito mais rápida do que no modelo on-premisses.
Videoaula: Arquiteturas centralizadas

ESTUDO DE CASO
Considere que você acabou de ser contratado como arquiteto de dados na empresa xDB. Seu chefe solicitou
que você desenhasse uma solução para uma nova aplicação a ser instalada no parque aplicacional. Ela deve
ter um banco de dados que vai atender a uma aplicação de vendas, e esta aplicação de vendas tem um app
para celular, que será o canal de comunicação com o cliente. O banco de dados deverá ser criado com
algumas especificações de esquema:
• Nome do banco: venda_db.
• Tabelas principais: cliente, venda, produto.
• Essas tabelas deverão ter permissões de leitura para 3 usuários: Fabiana, Augusto e Miguel.
• Existirá, ainda, uma view que permitirá ver dados de clientes e vendas juntos.
Esse banco ficará hospedado no data center do cliente, dentro de um único servidor, executando Linux. A
aplicação e o app também ficarão hospedados cada um em um servidor, ambos executando Windows Server.
Qual seria o modelo de camadas dessa solução? Quais comandos seriam usados para criar o banco, as tabelas
e conceder as permissões? Que tipos de comandos são esses? Como você descreveria o modelo de camadas
física, conceitual e externa desta solução?
Para este caso, precisamos ir decompondo as informações aos poucos:
• A aplicação deve ter um banco de dados que vai atender a uma aplicação de vendas, e esta aplicação de
vendas tem um app para celular, que será o canal de comunicação com o cliente.
Nesse trecho, podemos identificar o modelo de três camadas, da seguinte forma:
Figura 3 | Modelo três camadas

Na sequência, temos informações sobre qual banco deverá ser criado, bem como suas tabelas e permissões:
• Este banco de dados deverá ser criado com algumas especificações de esquema:
Nome do banco: venda_db.
Tabelas principais: cliente, venda, produto.
Essas tabelas deverão ter permissões de leitura para 3 usuários: Fabiana, Augusto e Miguel.
Existirá, ainda, um view que permitirá ver dados de clientes e vendas juntos.
Utilizando a linguagem SQL, é possível inferir os seguintes comandos:
CREATE DATABASE venda_db;
CREATE TABLE cliente (
Nome text(50),
Email text(50),
Endereco text(100)
);
CREATE TABLE venda (
data text(50),
cliente (50),
produto text(100)
);
CREATE TABLE produto (
Nome_prod text(50),
Descricao text(250)
GRANT SELECT ON TABLE venda_db TO Fabiana,Augusto,Miguel;
CREATE VIEW cliente_venda AS
SELECT venda.data, cliente.nome, produto.nome, produto.descricao
FROM cliente, produto, venda;
Os comandos de CREATE são do tipo DDL; o comando de GRANT é DCL; e o comando de SELECT (como o que
está dentro da view) é do tipo DML.
Seguindo o caso exposto, temos uma dica sobre a infraestrutura, que nos ajudará a completar a visão das 3
camadas:
• Esse banco ficará hospedado no data center do cliente, dentro de um único servidor, executando Linux. A
aplicação e o app também ficarão hospedados cada um em um servidor, ambos executando Windows Server.
Figura 4 | Windows Server.
Já sabendo como é a composição dos dados da solução e seu modelo de três camadas, podemos, ainda,
fornecer uma visão com relação ao modelo de três esquemas:
Figura 5 | Modelo três esquemas.

 Saiba mais
Você poderá conhecer mais comandos e sintaxes do SQL nos links a seguir:
https://www.w3schools.com/SQl/sql_view.asp
https://www.dataquest.io/blog/sql-commands/
https://www.codecademy.com/articles/sql-commands
Aula 3
TIPOS DE ARQUITETURAS DE DADOS

Arquitetura cliente-servidor; Arquitetura de banco de dados distribuídas; Arquitetura em cloud.
29 minutos
INTRODUÇÃO
Olá, aluno! Você já pensou como muitas vezes o nosso armário fica bagunçado e precisamos parar para
arrumá-lo? Assim, usamos gavetas diferentes de acordo com cada peça ou com cada cor de roupa, colocamos
acessórios em caixas organizadoras... Ou seja, há muitas maneiras de se organizar um armário. Você deve
estar pensando: mas o que isso tem a ver com a arquitetura de dados?
Podemos dizer que a arquitetura de dados é uma espécie de arrumação, de modo que cada empresa
encontra a melhor forma para organizar os seus dados, os ativos digitais, e como relacioná-los.
Uma arquitetura eficiente garante, com segurança, o acesso aos dados no tempo adequado e de forma
compreensível para os seus usuários, pois sem um projeto de organização, a empresa perderá tempo quando
necessitar recuperar as informações. Tempo, nos dias de hoje, vale muito!
Está pronto para aprender mais um pouco sobre esse assunto tão instigante? Bons estudos!
BANCO DE DADOS: ARQUITETURA CLIENTE-SERVIDOR
Com a necessidade de se armazenar os dados de uma forma organizada e, ao mesmo tempo, permanente,
surgiram os bancos de dados. Em face do grande volume de dados que estão cada vez mais vindo à tona no
mundo moderno e digital, os bancos de dados tornaram-se ainda mais importantes e usuais.
Os modelos de bancos de dados mais comuns são os centralizados, o cliente/servidor, os paralelos e os

distribuídos. Vamos começar vendo o banco de dados cliente/servidor.
O objetivo do banco de dados cliente/servidor, ou de arquitetura em camadas, como também é conhecido, é

fornecer suporte ao desenvolvimento e à execução de aplicações de bancos de dados. Esse tipo de sistema é
considerado simples, dividido entre as máquinas cliente, ou front-ends, e a(s) máquina(s) servidor, ou back-
end.
O Sistema de Gerenciamento de Banco de Dados (SGBD) é uma arquitetura dependente do servidor. Os

computadores que dão acesso ao banco de dados são chamados de servidores, e quem realiza requisições ao
servidor é chamado de cliente. O servidor possui configurações robustas, que recebem os serviços pedidos
pelas estações clientes, como a impressão de um trabalho ou uma consulta ao banco de dados.
De acordo com Date (2004), os clientes do sistema cliente/servidor são as diversas aplicações executadas em
cima no SGBD, tanto aplicações escritas por usuários como programas de aplicações comuns, escritos em
linguagem de programação de terceira ou quarta geração, ou, ainda, aplicações fornecidas pelo fabricante do
SGBD ou por terceiros. Em outras palavras, o sistema cliente é responsável por solicitar serviços e por receber
respostas e interface de usuário. Em relação ao servidor, não há diferença entre aplicações escritas pelo
usuário e aplicações internas: todas usam a mesma interface. As estações clientes são os microcomputadores
com sistemas operacionais de interface gráfica, apresentando, normalmente, configurações modestas.
No caso de o sistema cliente realizar uma consulta ao banco de dados, o servidor retorna os registros
resultantes da consulta, ou dataset, ao cliente. O servidor só vai funcionar quando o cliente solicitar alguma
tarefa.
No servidor, há recursos que são compartilhados com os clientes, como o diretório, arquivos e impressora.
Para o cliente ter acesso, é preciso ter autorização do administrador e uma senha para cada usuário.
As aplicações ou ferramentas fornecidas pelos fabricantes têm a função básica de auxiliar na criação e na
execução de outras aplicações. As ferramentas servem para que os usuários, principalmente os finais, criem
aplicações sem ter de escrever programas em uma linguagem de programação convencional. Podemos citar
como exemplo de ferramenta o gerador de relatórios (report writer), cuja finalidade é permitir que os usuários
finais obtenham relatórios formatados a partir do sistema sob requisição.
Existe a possibilidade de termos mais de um servidor, como: o servidor de banco de dados, o servidor de
aplicações, o servidor de impressão e o servidor de internet. É importante saber que a arquitetura
cliente/servidor permite a utilização de mais de um servidor para a mesma tarefa.
O sistema cliente/servidor é completamente dividido em duas partes: servidor e clientes; nesse sentido, será
que é possível executar os dois em máquinas distintas? Ou seja, há possibilidade de ter um processamento
distribuído?
Essa possibilidade existe e nós vamos conhecê-la ainda nessa aula.
VIDEOAULA: BANCO DE DADOS: ARQUITETURA CLIENTE-SERVIDOR
A arquitetura cliente/servidor pode ser dividida em dois tipos: duas camadas (two-tier architecture) e
multicamadas, que usualmente possui três camadas (three-tier architecture).
No tipo duas camadas, temos, na primeira camada, o cliente, que se comunica diretamente com a segunda
camada, o servidor. Essa comunicação ocorre por meio de uma aplicação cliente.
O segundo tipo é um pouco mais complexo, pois existem três componentes envolvidos no processo: anfitrião
(host), servidor e cliente. O servidor de aplicação age como uma ponte entre o cliente e o servidor de banco de
dados (o anfitrião, ou host). Agora, ele é o responsável pela manipulação das regras de negócio
(procedimentos e restrições) do banco de dados e gerencia todas as requisições oriundas dos clientes antes
de encaminhá-las ao servidor de banco de dados.
Videoaula: Banco de dados: arquitetura cliente-servidor
BANCO DE DADOS: SISTEMA DISTRIBUÍDO
“Processamento distribuído” nada mais é do que um termo que se refere às máquinas diferentes que podem
estar conectadas entre si para formar uma rede de comunicações, de tal modo que uma única tarefa possa
ser dividida entre as máquinas que estão na rede, por exemplo, a Internet. Essas máquinas comunicam-se
umas com as outras por meio de um software de gerenciamento de rede.
Quando falamos em um sistema de banco de dados distribuído, o banco de dados é armazenado em mais de
um computador, que vamos chamar de “nós”. Os computadores nesse tipo de sistema comunicam-se entre si
a partir dos meios de comunicação, por exemplo, redes de alta velocidade, redes sem fio, entre outros. É
importante mencionar que os computadores não compartilham a memória principal e o relógio.
No sistema distribuído, os dados ficam em vários lugares, e isso é motivo de preocupação e dificuldades.
Nesse sistema, os processadores, dependendo do contexto, recebem o nome de nó, e possuem funções e
tamanhos diferentes. Alguns exemplos são os microcomputadores, as estações de trabalho, etc.
A tabela ou a relação r nos bancos de dados distribuídos em relação ao armazenamento podem dividir-se em
três classificações: replicação, fragmentação e replicação e fragmentação.
Na replicação, o sistema contém réplicas que são idênticas, sendo que cada uma delas é armazenada em sites
diferentes.
Já na fragmentação, essa relação possui vários fragmentos, e cada fragmento, somente, é armazenado em um
site diferente.
Na replicação e fragmentação, por sua vez, a relação também possui vários segmentos, porém o sistema
mantém diversas réplicas de cada fragmento.
Dizemos que um dado é replicado quando em cada nó há diversos representantes dos dados armazenados. O
quanto cada nó suporta para a replicação é fundamental no momento de atingir o máximo potencial de um
sistema distribuído.
É importante sabermos, nesse contexto, que cada fragmento deve possuir informação suficiente para que
permita a reconstrução da relação original. Há dois modos de se fazer uma fragmentação: a fragmentação
horizontal e a vertical. Na fragmentação horizontal, a relação é dividida separando-se as tuplas (linhas) de r
em dois ou mais fragmentos, já na fragmentação vertical, divide-se a relação pela decomposição do esquema
R da relação r.
Cabe salientar que as réplicas podem ser fragmentadas novamente, e assim por diante.
O acesso aos dados em um sistema distribuído geralmente é acompanhado de transações que preservam as
propriedades de atomicidade, consistência, isolamento e durabilidade. Vamos ver o que significa cada uma
dessas propriedades?
Na propriedade de atomicidade, todas as operações da transação são retratadas de forma correta no banco
de dados, se uma estiver errada, nenhuma o será. A consistência significa que quando se executa uma
transição isolada é preservada toda a consistência do banco de dados. Quando cada transação é
independente de outras concorrentes, estamos diante da propriedade de isolamento. E, por fim, a chamada
durabilidade nada mais é do que a propriedade de, após a realização de mudanças, com a transição tendo
sido bem-sucedida, a alteração persistir no banco de dados.
VIDEOAULA: BANCO DE DADOS: SISTEMA DISTRIBUÍDO
Falhas em um sistema de banco de dados distribuído

Do mesmo modo que um sistema de banco de dados centralizado, o sistema distribuído também pode
apresentar falhas. Essas falhas podem ser as mesmas do sistema centralizado, além de outras, como falha na
comunicação entre nós, perda de mensagens e o particionamento da rede.
O importante é que cada um desses problemas seja avaliado e considerado ao se realizar o projeto de
recuperação desse tipo de banco de dados, pois para que um sistema funcione de forma apropriada e
robusta, ele precisa detectar qualquer tipo de falha e fazer a reconfiguração enquanto essa falha é recuperada
Videoaula: Banco de dados: sistema distribuído
BANCO DE DADOS: CLOUD (NUVEM)
Em sistemas com base na web, utilizamos um protocolo de comunicação chamado Protocolo de Transferência
de Hipertexto, mais conhecido como HTTP. O software servidor, quando é executado em um servidor da web,
deve esperar por uma requisição de um usuário. Se o usuário pede uma requisição, a requisição HTTP é
enviada, então o software responde e retorna a página web pedida, com uma resposta do HTTP.
Podemos utilizar um banco de dados em conjunto com uma página web. Quando isso acontece, um servidor
de banco de dados é acionado.
Atualmente, podemos dizer que saber como armazenar e trabalhar com os dados de uma empresa é a peça-
chave para o sucesso. Nesse aspecto, o banco de dados é considerado um sistema muito importante, pois a
partir dele as informações são mantidas protegidas e podem ser gerenciadas.
Os dados estão presentes nas empresas de forma cada vez mais volumosa, então, é necessário acessá-los de
maneira correta, rápida e em qualquer lugar, por isso as empresas passaram a buscar alternativas que
pudessem suprir essas necessidades, assim surgiu o banco de dados na nuvem.
Os bancos de dados que são baseados em nuvem (Figura 1) permitem que os usuários armazenem,
gerenciem e recuperem os dados por meio de uma plataforma na nuvem, que é acessível pela internet. Esses
dados podem ser estruturados, não estruturados e semiestruturados.
Podemos chamar os bancos de dados em nuvem de bancos de dados como serviço (DBaaS), pois, na maioria
das vezes, são oferecidos como serviços gerenciados.
Figura 1 | Dados em nuvem
Fone: elaborada pela autora.
Você deve estar se perguntando: mas qual a vantagem de se ter um banco de dados em nuvem? São muitas:
custos menores de TI, tecnologias com processos automatizados, como recuperação de falha, e mais
acessibilidade, ou seja, desde que se tenha uma conexão com a internet, é possível acessar o banco de dados
na nuvem de qualquer lugar e a qualquer hora.
A Nuvem Privada Virtual (Virtual Private Cloud – VPC) é um método que utiliza as vantagens das nuvens
públicas e das privadas, podendo ser considerada uma forma mais simples de migrar para um ambiente de
nuvem. Uma VPC é formada pela reserva de recursos computacionais em um provedor de nuvem pública,
porém, de forma dedicada. Assim, podemos dizer que “uma nuvem privada” foi criada em um provedor de
nuvem pública e são usados mecanismos de autenticação e criptografia para isolar os recursos alocados dos
demais clientes da nuvem pública. Além disso, a nuvem privada virtual é uma configuração de um sistema
construído sobre a nuvem pública e separado por essa criptografia para que um usuário possa ter acesso a
recursos de forma privada.
As nuvens que quando administradas por provedores diferentes podem compartilhar alguns recursos entre si
são chamadas de nuvens federadas. Sempre que houver um compartilhamento, é necessário um mecanismo
de autenticação e controle de acesso aos recursos, o que é uma vantagem, já que o cliente pode usar um
mesmo identificador para acessar recursos de diferentes provedores.
Os projetos que envolvem banco de dados costumam ser mais desafiadores, assim, a empresa pode
aprimorar as habilidades da sua equipe de TI ou confiar na experiência em banco de dados da equipe do
provedor de serviços.
VIDEOAULA: BANCO DE DADOS: CLOUD (NUVEM)
O banco de dados em nuvem é uma realidade, porém, muitas empresas ainda têm receio de colocar os seus
bancos de dados, que possuem conteúdos importantes e sigilosos, em nuvens gerenciadas por terceiros; no
entanto, essa opção é uma realidade muito segura.
Há dois modelos principais de bancos de dados na nuvem. O mais tradicional é muito parecido com um banco
de dados gerenciado de forma local, com exceção, claro, do provisionamento de infraestrutura, sendo a opção
mais recente e mais vantajosa também, além de ser a mais utilizada nos dias de hoje: o banco de dados como
serviço (DBaaS). Esse banco de dados é baseado em um sistema em nuvem, porém é necessário ter uma
assinatura e fazer o pagamento de uma taxa.
Videoaula: Banco de dados: cloud (nuvem)
ESTUDO DE CASO
A empresa X vem crescendo de forma exponencial nos últimos anos e, para gerenciar os seus dados, possui
um sistema baseado em arquivos, o que gera muitos problemas, como dados duplicados, preços diferentes
do mesmo produto, dentre outros.
Isso acontece porque a empresa possui mais de um departamento e cada um gerencia os seus próprios
dados de forma independente. Essa situação traz alguns problemas: além de gastar tempo inserindo os
dados, ocupa espaço desnecessário nos discos rígidos do computador e leva ao desperdício de recursos
materiais, já que é necessário imprimir formulários de checagem. Há, ainda, outro problema: caso seja
necessário alterar algum dado, é preciso avisar todos os departamentos envolvidos separadamente, o que é
um desperdício de tempo.
Visando a acabar com essas situações, a empresa X contratou você para pensar uma forma de solucionar o
caso apresentado. Explique como você resolveria todos esses problemas.
A primeira medida necessária para resolver esse problema é uma investigação de requisitos em todos os
departamentos. A partir das informações coletadas, cria-se um modelo de dados para desenvolver um
sistema de banco de dados centralizado para a empresa. Com esse banco de dados operacional, devem-se
estabelecer interfaces de consulta e preenchimento para cada departamento.
Como as necessidades de cada departamento são diferentes, as interfaces devem ser direcionadas tanto para
reduzir as dificuldades de acesso quanto para permitir a restrição de dados por departamento.
A coerência e a organização dos dados é obtida pelo modelo de dados e pela sua implementação em um
sistema de banco de dados. Assim, o estudo de requisitos levanta quais informações devem ser mantidas e
armazenadas, bem como as relações entre elas.
Na escolha de uma estrutura de dados baseada em SQL, os dados serão inseridos, consultados e atualizados
usando comandos que operam sobre tabelas do modelo de dados em vez de arquivos livres com informações
abertas.
A arquitetura interna dos sistemas de banco de dados também está otimizada para armazenamento e
consulta, permitindo arquivos menores e processamento mais rápido de consultas. Além disso, facilita as
cópias de segurança e define condições de entrada e saída de dados coerentes para a interface.
 Saiba mais
Capítulo 8 do livro Sistema de Banco de Dados trata dos bancos de dados paralelos e distribuídos.
SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de Banco de Dados. Barueri: Grupo GEN, 2020.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788595157552/. Acesso em: 7 out.
2021.
Aula 4
NORMALIZAR DADOS
Modelo conceitual; Modelo lógico; Modelo físico de dados.
31 minutos
INTRODUÇÃO
Olá, aluno!
No desenvolvimento de um software, uma das fases mais críticas é a modelagem de um banco de dados que
atinja o objetivo estabelecido pelo cliente, ou seja, que contenha em detalhes os tipos de informações que
devem ser armazenadas.
Um modelo de banco de dados serve para que um usuário que não entende sobre o assunto passe a
compreender, de forma fácil, a sua estrutura. Quando se modela um banco de dados, temos três níveis de
abstração desses dados: modelo conceitual, modelo lógico e modelo físico.
Pode-se obter um detalhamento a partir de gráficos ou até mesmo por meio de uma descrição textual.
Na aula de hoje, veremos o modelo conceitual e lógico e finalizaremos com a modelagem física.
Está pronto para aprender um pouco mais sobre a arquitetura de banco de dados? Bons estudos!
MODELO CONCEITUAL
Durante a modelagem de um banco de dados, podem ocorrer alguns erros, que podem comprometer o uso
do projeto final e acarretar um retrabalho e um aumento no custo do projeto. Para que isso não aconteça, ou
para pelo menos minimizar as chances de um possível retrabalho, alguns passos devem ser seguidos. O
primeiro é a identificação do problema, seguido pela modelagem conceitual e lógica, finalizando com a
modelagem física.
Uma modelagem conceitual, ou Modelo Entidade Relacionamento (MER), ou, ainda, modelo conceitual, é um
conceito que descreve o que deve conter, ou seja, ser armazenado no banco de dados, independentemente
do Sistema Gerenciador de Banco de Dados (SGBD) que será implantado (ALVES, 2020).
Nesse modelo, não se descreve como os dados vão ser armazenados, apenas apresentam-se os dados e as
relações. Nessa etapa, só será considerado o ponto de vista do usuário, que é o criador dos dados, e costuma
ser representado por meio de um diagrama. O foco do modelo conceitual não é mostrar informações
complicadas, mas sim representar, de forma visível, todo o conteúdo do banco de dados, discutindo as
necessidades do cliente.
A técnica que costuma ser utilizada na modelagem conceitual é conhecida como Entidade-Relacionamento
(ER). Essa técnica utiliza-se de um diagrama gráfico que representa as tabelas dos bancos de dados
(entidades), os relacionamentos e os atributos, chamado de Diagrama Entidade-Relacionamento (DER).
O primeiro passo que se deve fazer ao analisar um estudo de caso é listar todas as entidades que vão compor
o modelo conceitual. Um modo de identificar as entidades é procurar por informações que possuam algum
significado, elas são representação de algo que existe. Representamos uma entidade por meio de um
retângulo com o nome da informação que deve ser reconhecida. O nome de uma entidade deve ser composto
por um ou mais substantivos, em letras maiúsculas, e deve estar no singular. Vale destacar que não devem ser
usadas preposições.
A ligação entre as entidades é chamada de relacionamento, que é a interação entre tais entidades. O
relacionamento é representado por meio de losangos, havendo três tipos de relacionamento entre as
entidades:
• Relacionamento um-para-um: um item da entidade A pode relacionar-se com apenas um item da entidade B.
• Um-para-muitos: um item da entidade A pode relacionar-se com vários itens da entidade B.

• Relacionamento muitos-para-muitos: vários itens da entidade A podem relacionar-se com vários itens da
entidade B.
Figura 1 | Modelo conceitual
Fonte: Heuser (2011, p. 5).
As informações que identificam uma entidade são chamadas de atributos. Os atributos são representados por
um círculo ou uma elipse e podem ser categorizados de 5 modos: simples, composto, derivado, multivalorado
ou determinante.
VIDEOAULA: MODELO CONCEITUAL
Identificação do problema
Criar uma aplicação que envolve banco de dados não é uma tarefa muito simples, pois implica alguns
projetos, como o do banco de dados dos programas que acessam e atualizam os dados e o do esquema de
segurança para controlar o acesso a esses dados.
É muito importante atentar para as necessidades dos usuários, pois eles desempenham um papel
fundamental em todo esse processo.
Nesta primeira etapa, é feito um estudo detalhado de todas as atividades em questão, porém, quando não se
tem conhecimento sobre o negócio, devem ser realizadas entrevistas, que têm como objetivo conseguir
informações importantes sobre as necessidades dos usuários. Quem conduz a entrevista com os usuários são
os administradores de dados.
Os requisitos são a chave de todos os produtos que envolvem software. A descrição, o gerenciamento e o
entendimento são problemas recorrentes a todo tipo de metodologia de desenvolvimento. É pela análise de
requisitos que se identificam as necessidades de recursos e também a complexidade do projeto do banco de
dados. Ela identifica as relações e os tipos de dados necessários a partir das informações de armazenamento
e consulta.
Após esse levantamento do problema e essa entrevista com os usuários, o próximo passo é realizar a
modelagem conceitual. Depois da modelagem conceitual, é feita a modelagem lógica e, por fim, a modelagem
física.
Videoaula: Modelo conceitual

MODELO LÓGICO
Vamos ver, agora, outro modelo para os bancos de dados, o chamado modelo lógico. O modelo lógico
também é chamado de modelo de dados de baixo nível, ou representativa, ou, ainda, de implementação,
possuindo um detalhamento do banco de dados próximo da visão de um profissional de banco de dados.
O modelo lógico só deve ser iniciado após o modelo conceitual ter sido concluído. Esse tipo de modelo
depende do tipo de SGBD (relacional, hierárquico, rede ou orientado a objetos) utilizado na implementação,
como SQL Server, Oracle, MySQL, dentre outros. Nesse modelo, as entidades, que são representadas por
retângulos no diagrama do modelo conceitual, vão se tornar tabelas do banco de dados, com nome e
definição das colunas que formam sua estrutura.
O modelo lógico é um passo importante para a construção do modelo físico e, antes de ser iniciado, já é
necessário se conhecer o tipo de banco de dados que vai ser utilizado, para que a implementação do modelo
físico seja feita de forma correta, por meio de um sistema gerenciador de banco de dados (MARTELLI; FILHO;
CABRAL, 2018).
Nesse ponto do projeto de banco de dados, ainda não definimos as características particulares de cada
atributo, como tamanho ou tipo de dado. Nós apenas vamos relacioná-los com suas respectivas tabelas
(ALVES, 2014).
Em um SGBD relacional, os dados estão organizados na forma de tabelas. A Figura 2 apresenta um exemplo
de um banco de dados relacional que foi projetado a partir do modelo conceitual da Figura 1.
Figura 2 | Tabelas de banco de dados relacionais
Fonte: Heuser (2011, p. 6-7).
Um modelo lógico de um banco de dados relacional deve definir quais tabelas o banco contém e, para cada
tabela, quais os nomes das colunas.
Há um grupo de analistas que acreditam que o modelo conceitual não é importante, sendo, portanto,
desnecessário. Normalmente, os prazos para concluir os projetos são curtos, por esse motivo, esses analistas
não criam o modelo conceitual e já iniciam o projeto a partir do desenvolvimento do modelo lógico.
Felizmente, muitos projetistas percebem que, pulando a etapa do modelo conceitual, nem todo requisito ou
solicitação fica completo ou é atendido corretamente, o que poderia ter sido evitado se primeiro fosse
elaborado o modelo conceitual (PICHETTI; VIDA; CORTES, 2021).
De acordo com Machado (2020), quando pulamos o modelo conceitual durante a realização de um projeto,
somos levado à vinculação tecnológica de nosso raciocínio, perturbando a interpretação pura e simples de um
contexto. É preciso ter a cautela de adaptar as tecnologias de gestão de dados à realidade das necessidades
de cada projeto e às formas de representação usadas no cotidiano dos usuários dos bancos de dados. Um
erro comum é inverter o sentido de prioridade e impor restrições de sistemas e formatos de dados sobre o
problema trabalhado.
VIDEOAULA: MODELO LÓGICO
No modelo lógico, as entidades, que são representadas por retângulos no diagrama do modelo conceitual,
vão se tornar tabelas do banco de dados, com nome e definição das colunas que formam sua estrutura. Uma
ferramenta que facilita todo o processo para implementar os modelos, e também uma das mais utilizadas, é
o MySQL WorkBench, que disponibiliza muitas funcionalidades.
A Figura 3 apresenta a tela inicial do software.
Figura 3 | Tela inicial
Fonte: captura de tela do MySQL Workbench.
Para criar um novo diagrama, basta acessar o ‘+’, junto a Models (Figura 4).
Figura 4 | Novo diagrama

Em seguida, vamos clicar em Add Diagram para proceder à criação de um novo diagrama (Figura 5).
Figura 5 | Adicionar diagrama
O próximo passo é criar as tabelas e indicar os campos. Para criar tabelas, clique no ícone na barra lateral,
conforme Figura 6.
Figura 6 | Criar tabela

Depois, deve-se indicar um nome para a tabela (por exemplo, “Cliente”) e definir quais campos fazem parte
dessa tabela (Figura 7).
Figura 7 | Definição de campos
Por fim, é hora de criar as tabelas necessárias.
Figura 8 | Criação das tabelas

Videoaula: Modelo lógico
MODELO FÍSICO
Após aprendermos os modelos conceituais e lógicos, vamos ver, nesse bloco, o modelo físico. Esse modelo é a
parte final do projeto de um banco de dados e está relacionado ao profissional de SGBD; nele, mostra-se em
detalhes como serão arquivadas as informações no banco de dados. Esse modelo apresenta as definições
detalhadas da estrutura física, como o nome dos campos, o tipo de dados, o tamanho dos campos, os índices,
os valores, as nomenclaturas, a exigência de conteúdo, etc., que são projetados de acordo com os requisitos
de processamento e com o uso mais econômico dos recursos computacionais.
Nesse modelo, os detalhes técnicos do projeto, a necessidade do cliente e a política de cópia e segurança são
implantados.
Para construir o banco de dados, é necessário ter como base os desenhos dos modelos conceitual e lógico.
Nessa fase do projeto, utilizamos a linguagem declarativa, que permite a definição da estrutura do banco de
dados. Em SQL, essa linguagem é chamada de Linguagem de Definição de Dados (DDL). O público-alvo desse
modelo, geralmente, são os profissionais da área de informática, como engenheiros, técnicos, analistas,
programadores, etc.
Para que um modelo conceitual ou lógico seja transformado em modelo físico, são necessários alguns passos,
como as definições dos atributos de uma tabela (colunas), que serão os índices, o tipo desse atributo
(numérico, caractere, data, outros), a exigência de sua existência ou não, e sua identificação como chave
primária ou estrangeira na tabela em si (MACHADO, 2020).
Quando convertemos um modelo lógico em um modelo físico, cada um dos atributos que há nas entidades do
modelo deve ter um conjunto de propriedades relativas a uma coluna de uma tabela.
Há algumas regras que devem ser seguidas quando se converte o modelo lógico em modelo físico, por
exemplo, o nome da coluna deverá seguir as convenções e regras de metodologia utilizadas ou da
administração de dados da empresa, bem como os requisitos semânticos do SGBD.
Qualquer alteração no modelo físico não afetará as aplicações que utilizam o banco de dados, pois o modelo
não envolve aspectos funcionais do banco de dados. Podemos dizer que o modelo físico, na prática, é um
processo contínuo, pois mesmo depois de o banco de dados já estar implementado e em funcionamento, é
possível fazer modificações para aprimoramento. Este processo é chamado de sintonia (tuning) de banco de
dados.
O modelo físico detalha o estudo dos métodos de acesso do SGBD para a criação dos índices necessários para
cada informação colocada nos modelos conceitual e lógico.
Atualmente, há muitos modelos de SGBD. Esses modelos podem ser pagos ou gratuitos e de código aberto.
Alguns exemplos são (MARTELLI; FILHO; CABRAL, 2018):
• Gratuitos: Microsoft SQL Server Express, Oracle Database Express Edition,
• De código aberto: MySQL, Firebird, mSQL, etc.
• Pagos: Oracle Database, Microsoft SQL Server, Microsoft Access, SAP Sybase Database, etc.
VIDEOAULA: MODELO FÍSICO
Os modelos conceitual, lógico e físico são nada mais do que visões diferentes, com níveis de profundidade
distintos, para os mesmos dados. É fundamental saber que, a partir de um modelo, o modelo seguinte pode
ser derivado.
Vamos ver o caminho completo, desde o início do levantamento de dados até o modelo físico?
O analista de banco de dados, para desenvolver uma aplicação, observa a realidade, ou realiza entrevistas
quando não há conhecimento prévio, para que possa organizar suas ideias, compreender e documentar os
requisitos com vistas a construir um banco de dados. Nessa primeira fase, ele faz o levantamento e a análise
dos requisitos.
A segunda fase é o que chamamos de “projeto conceitual”, cujo objetivo é definir um modelo de dados
conceitual. Nesse modelo, devemos incluir a descrição das entidades do banco de dados, dos atributos das
entidades, dos relacionamentos entre entidades, além das possíveis restrições.
A terceira fase é o projeto lógico, que é feito a partir do projeto conceitual. Esse modelo depende do SGBD
que será usado para implementar o banco de dados.
A quarta e última fase é o projeto físico, que tratará das estruturas em memória e organização dos arquivos
do banco de dados (arquivos de índices). O projeto físico é aquele que será efetivamente implementado no
banco de dados.
Videoaula: Modelo físico
ESTUDO DE CASO
Uma livraria de pequeno porte está se expandindo e, para que essa expansão ocorra de forma bem-sucedida
e definitiva, a empresa quer desenvolver um banco de dados para registrar todas as compras, tanto as feitas
por ela quanto as feitas pelos clientes.
Imagine que você foi contratado para elaborar um modelo físico para este banco de dados, conforme o
detalhamento a seguir:
• Devem ser armazenados os dados pessoais do cliente.
• O pedido deve conter o número, o código do cliente, a data e o valor do pedido.
• Também devemos ter uma tabela que contenha as informações sobre o livro.
• Precisamos de uma tabela que contenha os itens do pedido.
• Devemos ter uma tabela para a editora: código, nome, e-mail.
• Queremos uma forma de verificar se o livro consta no estoque.
Antes de iniciar o modelo, é muito importante conhecer as necessidades do cliente. Nesse caso, os pontos
principais são:
• Devem ser armazenados os dados pessoais do cliente.
• O pedido deve conter o número, o código do cliente, a data e o valor do pedido.
• Também devemos ter uma tabela que contenha as informações sobre o livro
• Precisamos de uma tabela que contenha os itens do pedido.
• Devemos ter uma tabela para a editora: código, nome, e-mail.
• Queremos uma forma de verificar se o livro consta no estoque.
Figura 9 |Tabela Cliente

Fonte: elaborada pela autora.
Figura 10 | Tabela Pedido
Figura 11 |Tabela Livro
Figura 12 | Tabela Itens do pedido
Figura 13 | Tabela Editora

Figura 14 | Tabela Estoque
A Tabela Cliente relaciona-se com a Tabela Pedido por meio do Cod_cliente e Cliente_Cod.
A Tabela Pedido relaciona-se com os Itens do pedido por meio do Num_pedido e Livro_cod.
A Tabela Livro relaciona-se à Tabela Estoque por meio do Cod_livro de ambas as tabelas.
A Tabela Editora relaciona-se com a Tabela Livro por meio do Cod_editora e Editora_Cod_editora.
A Tabela Itens_pedido relaciona-se com a Tabela Livro por meio do Iditens_pedido e Cod_livro.
Figura 15 | Tabela livro
 Saiba mais
Há várias ferramentas no mercado que permitem desenhar os modelos. Uma dessas ferramentas
freeware é MySQL. Disponível em: https://www.fabforce.net/downloads.php
REFERÊNCIAS
7 minutos
Aula 1
BARBIERI, C. Governança de Dados: Práticas, conceitos e novos caminhos. Rio de Janeiro: Alta Books, 2019.
HAIGH, T. How Charles Bachman Invented the DBMS, a Foundation of Our Digital World. Communications of
ACM, [S. l.], v. 59, n. 7, p. 25-30, jul. 2016. Disponível em: https://cacm.acm.org/magazines/2016/7/204036-
how-charles-bachman-invented-the-dbms-a-foundation-of-our-digital-world/fulltext. Acesso em: 24 out. 2021.
HURWITZ, J.; NUGENT, A.; HALPER, F.; KAUFMAN, M. Big Data para leigos. Rio de Janeiro: Alta Books, 2015.
SHANNON, C. E. A Mathematical Theory of Communication. Bell System Technical Journal, [S. l.], v. 27, p.
623-656, out. 1948. Disponível em: https://archive.org/embed/bstj27-4-623. Acesso em: 22 out. 2021.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Database System Concepts. Nova York: McGraw-Hill, 2010.
SILVA, N. S.; SANTANA, G. A. Fundamentos de banco de dados. Londrina: Editora e Distribuidora Educacional
S.A., 2018.
Aula 2
CEZAR, D. F. O. Banco de Dados II. Londrina: Editora e Distribuidora Educacional S.A., 2017.
IBM. Relational Database. IBM, 2011. Disponível em:

https://www.ibm.com/ibm/history/ibm100/us/en/icons/reldb/. Acesso em: 27 out. 2021.
MICROSOFT. Banco de Dados NoSQL - O que é NoSQL?. Microsoft, [s. d.]. Disponível em:
https://azure.microsoft.com/pt-br/overview/nosql-database/. Acesso em: 28 out. 2021.
MICROSOFT. Dados não relacionais e NoSQL. Microsoft, 11 ago. 2021. Disponível em:
https://docs.microsoft.com/pt-br/azure/architecture/data-guide/big-data/non-relational-data. Acesso em: 26
out. 2021.
MUKTHAR, A. Three Schema Architecture. Zitoc.com, 16 set. 2019. Disponível em: https://zitoc.com/three-
schema-architecture/. Acesso em: 25 out. 2021.
Aula 3
ALVES, W. P. Banco de Dados. São José dos Campos: Editora Saraiva, 2014. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788536518961/. Acesso em: 23 set. 2021.
ALVES, W. P. Banco de Dados: teoria e desenvolvimento. São José dos Campos: Editora Saraiva, 2020.
Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788536533759/. Acesso em: 23 set. 2021.
DATE, C. J. Introdução a Sistemas de Bancos de Dados. Barueri: Grupo GEN, 2004. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595154322/. Acesso em: 7 out. 2021.
PICHETTI, R. F.; VIDA, E. S.; CORTES, V. S. M. P. Banco de Dados. Porto Alegre: SAGAH, 2021. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900186/. Acesso em: 23 set. 2021.
Aula 4
ALVES, W. P. Banco de Dados. São José dos Campos: Editora Érica/Editora Saraiva, 2014. Disponível em: Minha
Biblioteca. Acesso em: 30 set. 2021.
HEUSER, C. A. Projeto de banco de dados. 4. ed. Porto Alegre: Grupo A, 2011. Disponível em: Minha
Biblioteca. Acesso em: 30 set. 2021.
MACHADO, F. N. R. Banco de dados: Projeto e implementação. São José dos Campos: Editora Érica/Editora
Saraiva, 2020. Disponível em: Minha Biblioteca. Acesso em: 30 set. 2021.
PICHETTI, R. F.; VIDA, E. S.; CORTES, V. S. M. P. Banco de Dados. Porto Alegre: SAGAH, 2021. Disponível em:
Minha Biblioteca. Acesso em: 30 set. 2021.

Arquitetura de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 1

PRINCÍPIOS DA ARQUITETURA DE DADOS

Vamos entender como os dados podem ser “explorados”? Ótimos estudos!

INTRODUÇÃO À ARQUITETURA DE DADOS

— (SILVA, 2019, s.p).

Figura 1 | Pirâmide DIKW

VIDEOAULA: INTRODUÇÃO À ARQUITETURA DE DADOS

Videoaula: Introdução à arquitetura de dados

Para visualizar o objeto, acesse seu material digital.

CARACTERÍSTICAS DA ARQUITETURA DE DADOS

Quadro 1 | Componente conforme TOGAF

Arquitetura de Negócio A partir das cadeias de valor de uma organização

Arquitetura de Aplicações A partir das capacidades que o negócio possui,