Banco de Dados Página inicial Lição 1 Lição 2 Lição 3

PDF - VERSÃO DE IMPRESSÃO

ARQUITETURA DE BANCO DE DADOS III –

Nível Físico

objetivo
Após estudarmos os dois primeiros níveis da Arquitetura de Banco de Dados, chegamos ao 3º Nível, que é conhecido como
Nível Físico, ou melhor, esse é o nível onde fisicamente vamos trabalhar com o armazenamento dos dados. Nesse nível temos
que definir quais são os espaços físicos onde os dados serão armazenados, especificando características exclusivas para cada
tipo e dado que será armazenado, qual o tamanho que o dado vai ocupar na base de dados, como os dados estão organizados
e como o acesso será realizado.
 problematização
Agora que chegamos ao nível mais profundo dentro de um projeto de Banco de Dados, precisamos retomar a nossa terceira
lição, quando falamos sobre os níveis externo, conceitual, quando citamos que uma das principais características em se
trabalhar dentro do modelo de arquitetura de dados em 3 níveis é a independência de dados: Lógica e Física.

Agora, depois de conhecer os níveis externos e conceitual, você já deve ter observado que entre os dois modelos há
independência, pois, apesar de termos estudado apenas uma versão do DER (Diagrama Entidade Relacionamento), podemos
utilizar outros modelos de diagramas no nível Conceitual, que, conforme você for se familiarizando com as características de
Análise de Sistemas e de Banco de Dados, certamente terá contato.

Além de muitas outras formas de representação que podem ser desenvolvidas conforme a evolução do conhecimento e das
necessidades dos sistemas. O importante, nesse momento, é compreender que o nível Conceitual pode ser apresentado de
diversas formas, mas sempre estará representando o mesmo mundo externo, por isso citamos que existe a independência
lógica entre eles. Outra característica importante que citamos, e vamos aprofundar nessa lição é a independência física entre
os níveis Conceitual e Interno (ou nível físico).

Mas onde será que todos os dados ficam armazenados? Será que é necessário um lugar físico para isso? E se sim, como se
comunicam com os demais níveis da Arquitetura de um Banco de Dados?
Na lição de hoje vamos aprender que no nível físico, o Analista/DBA irá criar efetivamente o Banco de Dados, onde ficarão
guardados todos os dados coletados no mundo exterior, ou melhor, da realidade do usuário, e que devem ser capazes de
produzir as informações necessárias para dar suporte às decisões do usuário.

Quando falamos que existe a independência, significa que o nosso banco de dados pode ter estruturas diferentes, de acordo
com as características técnicas dos dados que serão armazenados e ainda podem ser de fornecedores diferentes. Se voltarmos
ao exemplo da construção de uma casa, podemos fazer uma comparação entre o desejo do cliente com a casa.

Figura 1 - Nível Conceitual Figura 2 - Nível Físico (Interno)

Fonte - Pixabay (2014, on-line). Fonte - Pixabay (2015, on-line) .

Nível Externo #PraCegoVer : planta baixa de uma casa com #PraCegoVer : foto de uma sala, com um
Casa com uma sala com 16m2, cozinha com cinco cômodos. grande sofá branco e almofadas brancas e
12m2, um dormitório com 15m2, um pretas, iluminação com LED roxo no teto.
banheiro com 6m2, com um terraço externo
com 33 m2 etc.

Figura 3 - Nível Conceitual Figura 2 - Nível Físico (Interno)

Nível Externo Fonte - Pixabay (2014, on-line).
Vivienda con salón de 16m2, cocina de
#PraCegoVer: planta 3D de uma casa com
12m2, dormitorio de 15m2, baño de 6m2,
con terraza exterior de 33 m2 etc. cinco cômodos. A imagem era a de uma
planta baixa, mas aos poucos começa a
tomar forma com paredes e revestimento.
Fonte - Pixabay (2015, on-line).
#PraCegoVer : Fotografia de uma sala com
paredes e chão claros, tapete xadrez em
tons verde, luminária ao lado esquerdo
apoiada no chão, sofá de três lugares
centralizado na imagem.

case
Seguindo o exemplo iniciado nas lições anteriores, vamos dar continuidade à criação do sistema para um Restaurante. No
segundo nível, conseguimos finalizar uma estrutura conceitual que representa o nosso sistema de Restaurante, que ficou
conforme a Figura 1, a qual podemos ver a seguir:

Figura 5 - Modelo DER – Modelo Conceitual. / Fonte : o autor.

#PraCegoVer: diagrama com retângulos, que representam entidades, interligados por losangos; estes representam relacionamentos, com um indicativo ao lado

de cada retângulo, informando a quantidade de relacionamentos existentes entre as entidades; eles podem ser 1, quando há apenas um vínculo, ou N quando
há vários vínculos. O retângulo cliente está interligado aos retângulos cardápio e funcionário, por meio de um losango, no qual está escrito “atende”, sendo que
ao lado de cliente e cardápio temos a letra N e ao lado de funcionário o número 1. Ligado a cardápio, temos produto e prato. Entre cardápio e produto, há um
losango com a palavra “compõe” e, neste relacionamento, temos o número 1 ao lado de produto e a letra N ao lado de cardápio. Na relação entre cardápio e

prato, temos o losango de relacionamento com a palavra “vende” e a cardinalidade N ao lado de cardápio e 1 ao lado de prato. Vinculado a prato temos um
relacionamento com receita, identificado pelo losango “tem”, com o número 1 em ambos os lados. Relacionado à receita, há o relacionamento participa, que
está vinculado à ingrediente, com a cardinalidade N em ambos os lados. Ingrediente está relacionado a estoque, por meio do relacionamento mantém, com a
cardinalidade 1 ao lado de ingrediente e N ao lado de estoque. O Estoque está relacionado a produto, pelo relacionamento está, com a cardinalidade N ao lado
de estoque e 1 ao lado de produto. Atrás do retângulo Produto, temos o Retângulo Produto Pronto e Bebidas, em uma cor azul mais clara e apagada. A Entidade
produto está relacionada a fornecedor, por meio do relacionamento fornece, com a cardinalidade 1 ao lado de fornecedor e N ao lado de produto. Fornecedor
está relacionado a contas a pagar pelo relacionamento gera, com a cardinalidade N ao lado de gera e 1 ao lado de fornecedor.

O próximo passo, agora, é identificar quais são os atributos que existem em cada uma das entidades, que, no modelo físico,
iremos chamar de tabelas. Os atributos das tabelas serão denominados campos. Durante essa identificação, vamos fazer uma
análise nos atributos para buscar identificar se existe algum atributo que é único. Observe o exemplo a seguir

Tabela 1 - Tabela de atributos / Fonte : o autor.

#PraCegoVer: a tabela possui três colunas e sete linhas. A primeira linha contém o nome da tabela, que é chamada “Tabela: Cliente”. A segunda
linha organiza as colunas da tabela, que são, da esquerda para a direita, Campo, Tamanho e Tipo. A primeira linha possui as seguintes informações:
nome_cli, 60, char; a segunda linha: cpf_cliente, 11, char; a terceira linha: dt_nascimento, 8, decimal; a quarta linha: lim_credito, 6, decimal; e a
sétima e última linha possui as informações: vip, 1, boolean.

Como podemos observar na tabela acima, a entidade Cliente foi transformada na tabela Cliente, com o atributo nome,
 que gerou o campo nome_cli este ; é um campo tipo char (campo que aceita todos os tipos de caracteres) com tamanho
máximo de 60 caracteres.
O atributo CPF, que gerou o campo cpf_cliente , é um campo tipo char também, com tamanho máximo de 11 caracteres.
Já o atributo data de nascimento gerou o campo dt_nascimento que , é um campo tipo date (campo que somente aceita
datas) com tamanho máximo de 8 caracteres.
Foi identificado, ainda, nas regras de negócio, nível externo, que o restaurante dá um limite de crédito para clientes
especiais, identificados como Clientes VIP. Desta forma, o limite de crédito gerou o campo lim_credito que é um campo
,

tipo decimal (campo que aceita receber apenas números e tem casas decimais) com tamanho máximo de 6 números,
que possibilitaria um limite de até 999.999,99.
Por último, foi criado um campo VIP para identificar se o cliente é VIP ou não. Nesse caso, o campo tem um tipo Boolean
(Tipo boleano, que aceita somente dois estados, como sim/não, por exemplo).

Analisamos, portanto, que somente o campo cpf_cliente é um campo único, ou seja, os demais campos podem ter o mesmo
conteúdo (dados) para outros clientes, mas o CPF identifica, apenas, uma pessoa. Por exemplo: o Restaurante pode ter vários
clientes com o nome José da Silva, vários clientes VIPs, com o mesmo limite de crédito, ou ainda que nasceram no dia
01/01/1980, porém com o CPF 123.456.789.11 vai existir, apenas, para um cliente. Nesse caso, conseguimos identificar um
campo único para a tabela, que vai ser muito útil para fazermos os relacionamentos.

O case o(a) deixou intrigado(a)? Assista ao vídeo, a seguir, para conhecer um pouco mais sobre essa história:

Conceitualização
Como já foi citado no início desta lição, o Modelo Interno ou Físico do Banco de Dados é a camada mais avançada em relação
à gestão de dados e, consequentemente, é a camada mais técnica, no qual vamos encontrar as linguagens. Diferente de

outras ferramentas de Tecnologia da Informação, o Banco de Dados tenta manter um padrão de linguagem para fazer todos os
processos relativos aos dados. Essa linguagem base recebeu o nome geral de SQL ( Structured Query Language ), ou Linguagem
Estruturada de Consultas.

O grande desafio inicial do SQL é ser uma linguagem de alto nível, ou seja, uma linguagem próxima ao idioma humano, sendo,
ainda, adaptada ao modelo relacional. Como o SQL é uma linguagem que foi desenvolvida na década de 70, pela empresa
IBM, na Califórnia, Estados Unidos, naturalmente seus comandos derivam do idioma Inglês e seguem, em geral, a mesma
estrutura desse idioma. Mais para frente, vamos tratar sobre os principais comandos do SQL.

Dentro do SQL, temos poucos comandos e eles estão classificados conforme o tipo de função que realizam nos dados. O
primeiro grupo de comandos é o mais utilizado, e é denominado de DML ou Data Manipulation Language (Linguagem de
Manipulação de Dados), que serve, especificamente, para trabalhar com os dados. Nessa camada, teremos os comandos:

insert - insere dados nas tabelas;

update - altera os dados de uma tabela;
delete - apaga os dados de uma tabela;
select - seleciona e lê os dados de uma tabela.

create - cria uma tabela e os seus campos;

drop - elimina uma tabela completamente;
alter - altera uma tabela e os seus campos.

grant - atribui privilégios a usuários;

revoke - revoga os privilégios do usuário.
E os comandos de manipulação dos registros das tabelas são:
commit - efetiva a gravação dos dados fisicamente na tabela do Banco de Dados;
rollback - descarta todos os dados existentes, desde o último commit.

Nas próximas lições, exploraremos um pouco mais os comandos, mas, nessa lição, vamos trabalhar especificamente em nível
físico; então, o nosso próximo passo é criar o modelo físico do Banco de Dados, a partir do modelo conceitual. Para isso, nós
vamos trabalhar transformando todas as entidades, do modelo conceitual, em Tabelas.

Resgatando o sistema de restaurante, teremos, inicialmente, as seguintes tabelas:

CLIENTE, FUNCIONÁRIO, CARDÁPIO, PRODUTO, ESTOQUE, PRATO, RECEITA, INGREDIENTE, FORNECEDOR

 e CONTAS A PAGAR.

Agora, colocaremos os campos em cada tabela, ou seja, vamos identificar formalmente os dados que cada tabela vai
armazenar:

Cliente (CPF, nome, data de nascimento, vip, limite de crédito)

Como o Banco de Dados aceita somente uma palavra no nome do campo, teremos que usar underline “_” para simplificar os
atributos com mais de uma palavra na identificação. Nesse caso, teremos:

Cliente (CPF, nome, dt_nascimento vip, limite_crédito

, )

As demais tabelas serão definidas como:

Funcionário (CPF, nome, dt_nascimento, dt_contratação, salário)

Cardápio (nome, descrição, dt_validade)

Produto (nome_produto, descrição, peso, vlr_custo, preço_venda)

Estoque (nome_produto, quantidade)

Ingrediente (nome_ingrediente, descrição, peso, vlr_custo)

Prato (nome_prato, descrição, preço_venda, qtd_pessoas)

Receita (nome_prato, descrição, autor_receita, dt_registro)

Fornecedor (cnpj, nome_fornecedor, telefone, email)

Contas a pagar(numero_fatura, valor, data_vencimento, status).

O próximo passo é identificar a chave de acesso à tabela. Uma chave de acesso é um campo que recebe um valor único, ou
melhor, que jamais irá repetir para outros registros dentro da tabela. Relembrando que um registro é um conjunto de dados
de um lançamento dentro da tabela, por exemplo, no caso de cliente poderíamos ter como registro: (12345678911, “José
,

Maria”, 01/01/1980, sim, “1000,00”). Nesse caso, temos um registro do cliente José Maria, que nasceu em 01/01/1980, é um
cliente vip, com limite de R$1.000,00, e tem o CPF 12345678911.

Se analisarmos todos os dados, podemos ter outros clientes com o nome José Maria? A resposta é sim; em nossa
comunidade, é comum termos pessoas homônimas. Podemos ter outro cliente que nasceu no dia 01/01/1980? Sim, pois as
pessoas nascem no mesmo dia. VIP e com limite de crédito, com certeza teremos vários clientes que se enquadram nessas
características. E o CPF ? Podemos ter outro cliente com o mesmo número do CPF do cliente José Maria? Com certeza, não
podemos.

Desta forma, podemos dizer que o CPF é uma chave natural para a tabela cliente Dentro do nosso modelo físico, então,
.

vamos marcar a chave de acesso de forma diferenciada. Neste caso, vamos identificar a chave de acesso, sublinhando-a.

Cliente (CPF, nome, dt_nascimento vip, limite_crédito

, )
 Funcionário (CPF, nome, dt_nascimento, dt_contratação, salário)

Fornecedor (CNPJ, nome_fornecedor, telefone, email)

Contas a pagar (numero_fatura, valor, data_vencimento, status).

Cardápio (nome, descrição, dt_validade)

Nas outras tabelas, ainda, temos que fazer algumas análises, por exemplo, o Produto. No caso de Produto temos 5 atributos, ,

ou campos, e poderíamos dizer que o nome_produto seria uma chave natural, pois não poderíamos ter 2 produtos com o
mesmo nome. No entanto, como esse é um item que pode ser externo ao restaurante, ou seja, ele será definido por um
fornecedor que pode colocar o nome que quiser, não é recomendado utilizar esse campo como chave. Nesse caso, teremos
,

que criar uma chave única artificial dentro do nosso banco de dados, a qual podemos chamar de código_produto O mesmo .

faremos com as tabelas ingrediente e prato observe: ,

Produto (código_produto, nome_produto, descrição, peso, vlr_custo, preço_venda)

Ingrediente (código_ingrediente, nome_ingrediente, descrição, peso, vlr_custo)

Prato (código_prato, nome_prato, descrição, preço_venda, qtd_pessoas)

Agora temos, ainda, as tabelas de estoque e receita. Se olharmos no modelo conceitual, vamos observar que ambas têm um
relacionamento 1:1, ou seja, sempre vamos ter apenas um registro de produto ou ingrediente relacionado a um registro de
estoque e, sempre, vamos ter apenas uma receita vinculada ao prato .

Nesse caso, é importante analisar se existe a necessidade física de criarmos duas tabelas do relacionamento 1:1, ou se
podemos apenas juntar as tabelas, colocando os atributos todos fisicamente em um só registro.

No caso de receita a sugestão é juntar prato com receita Observe que ambas as tabelas têm um campo com o nome de
, .

descrição porém com finalidade diferente. No caso de prato serve para descrever o prato e, no caso de receita serve para
, , ,

descrever o passo a passo da receita. Teríamos, então, uma nova tabela de prato na qual colocaremos a descrição de receita
,

com o nome de preparação com a seguinte especificação:

,

Prato (código_prato, nome_prato, descrição, preço_venda, qtd_pessoas, preparação autor_receita, dt_registro)

,

Vale, aqui, uma observação que os Bancos de Dados permitem a criação de um campo tipo texto longo que será
, o caso do
tipo do campo de preparação.

Em estoque , o único campo que temos diferente é o da quantidade Nesse caso, podemos levar quantidade para as tabelas
.

ingredientes e produtos eliminando a tabela estoque Teremos, então, as novas tabelas:

, .

Produto(código_produto, nome_produto, descrição, peso, vlr_custo, preço_venda, qtde_estoque )

Ingrediente (código_ingrediente, nome_ingrediente, descrição, peso, vlr_custo, qtde_estoque )

Feita a atribuição das tabelas, temos que fazer uma última validação, esta possibilitará resgatar os registros vinculados das
tabelas. Em todos os lugares onde tivermos uma cardinalidade N (mais do que 1 registro vinculado), isto é, temos que verificar
se o campo chave do lado 1 faz parte dos campos do lado N, caso não faça, vamos ter que o inserir para possibilitar o

relacionamento físico entre os registros.

Vamos iniciar com o relacionamento fornecedor: contas a pagar. Sabemos que a chave “ fornecedor ” terá que estar presente
em contas a pagar Quando fizermos referência a fornecedor, o CNPJ será sempre chave primária e, quando fizermos
.

referência a contas a pagar o CNPJ será uma chave estrangeira, pois ela vem de outra tabela ( fornecedor ) e serve,
,

basicamente, para conseguirmos vincular as duas tabelas fisicamente.

Figura 6: Modelo Conceitual – fornecedor:contas a pagar. / Fonte : o autor.

#PraCegoVer: Diagrama com 2 retângulos, que representam entidades interligadas por 1 losango. O primeiro retângulo à esquerda tem inscrito a
palavra fornecedor, com o número 1 ao lado direito do retângulo. À direita, interligando os dois retângulos há um losângulo, com a inscrição gera.
No último retângulo, à direita, está inscrito contas a pagar e tem ao seu lado esquerdo a letra N.

Fornecedor(cnpj, nome_fornecedor, telefone, email)

Contas a pagar(numero_fatura, cnpj valor, data_vencimento, status).
,

Para produto:fornecedor vamos seguir a mesma lógica:

Figura 7: Modelo Conceitual – fornecedor:produto. / Fonte : o autor

#PraCegoVer: diagrama com 2 retângulos, que representam entidades interligadas por 1 losango. O primeiro retângulo, à esquerda, tem inscrito a

palavra “fornecedor”, com o número 1, ao lado direito do retângulo. À direita, interligando os dois retângulos há um losango, com a inscrição
fornece . No último retângulo, à direita, está inscrito produto e tem ao seu lado esquerdo a letra N.

Teremos então:

Fornecedor(cnpj, nome_fornecedor, telefone, email)

Produto(código_produto, cnpj nome_produto, descrição, peso, vlr_custo, preço_venda, qtde_estoque

, )

Para produto:cardápio e prato:cardapio teremos:

,
 Figura 8: Modelo Conceitual –produto:cardápio / Fonte : o autor

#PraCegoVer: diagrama com 2 retângulos, que representam entidades interligadas por 1 losango. O primeiro retângulo, à esquerda, tem inscrito a

palavra produto, com o número 1, ao lado direito do retângulo. À direita, interligando os dois retângulos há um losango, com a inscrição compõe .

No último retângulo, à direita, está inscrito cardápio e tem ao seu lado esquerdo a letra N.

Figura 9: Modelo Conceitual –prato:cardápio / Fonte : o autor

#PraCegoVer: Diagrama com 2 retângulos, que representam entidades interligadas por 1 losângulo. O primeiro retângulo à esquerda tem inscrito a

palavra prato, com o número 1 ao lado direito do retângulo. À direita, interligando os dois retângulos há um losângulo, com a inscrição vende . No
último retângulo, à direita, está inscrito cardápio e tem ao seu lado esquerdo a letra N.

Prato(código_prato, nome_prato, descrição, preço_venda, qtd_pessoas, preparação autor_receita, dt_registro) ,

Cardápio(nome, código_produto, código_prato descrição, dt_validade)

Temos ainda um relacionamento N:N, entre ingredientes e prato (pois eliminamos a receita e um relacionamento ternário
com 3 entidades) entre cliente funcionário e cardápio
, .

Sempre que tivermos um relacionamento N:N e, na maioria das vezes, que tivermos um relacionamento ternário (com 3
entidades) precisaremos criar uma tabela de relacionamento, que vai conter a chave primária de todas as entidades
envolvidas. Essa chave será uma chave composta pelas chaves primárias das tabelas envolvidas e, se necessário, algum outro
atributo que a torne única.

Para prato:ingrediente teremos:

Figura 10: Modelo Conceitual –produto:cardápio. / Fonte : o autor.

#PraCegoVer: Diagrama com 2 retângulos, que representam entidades interligadas por 1 losângulo. O primeiro retângulo à esquerda tem inscrito a
palavra prato, com a letra N ao lado direito do retângulo. À direita, interligando os dois retângulos há um losângulo, com a inscrição tem . No último
retângulo, à direita, está inscrito o ingrediente e tem ao seu lado esquerdo a letra N.

Prato(código_prato, nome_prato, descrição, preço_venda, qtd_pessoas, preparação autor_receita, dt_registro) ,

Ingrediente(código_ingrediente, nome_ingrediente, descrição, peso, vlr_custo, qtde_estoque .)

Ingredientes do Prato( código_prato, código_ingrediente qtde_usada) ,

E para o relacionamento atende que está entre cliente:funcionário:cardápio vamos ter:
,

Cliente (cpf, nome, dt_nascimento vip, limite_crédito

, )

Funcionário(cpf, nome, dt_nascimento, dt_contratação, salário)

Cardápio(nome, código_produto, código_prato descrição, dt_validade)

Atende( cpf_cliente,cpf_funcionario, data, código_produto, código_prato )

Para finalizar o processo ainda podemos fazer mais alguns refinamentos, juntando algumas tabelas, mas, a princípio vamos
manter dessa forma, pois estamos apenas introduzindo o conteúdo.

Ficou interessado(a) sobre esse tema? Clique no play a seguir e assista ao vídeo:

saiba aplicar
Para finalizar nossa lição, vamos voltar ao exemplo do sistema de agenda de compromissos. Na lição anterior definimos o
modelo conceitual e agora é a hora de transformarmos o modelo conceitual em um modelo de físico. Para relembrar, o DER
que finalizamos foi o seguinte:
 Figura 11: Exemplo Entidades e Relacionamentos com Cardinalidade – Sistema de Compromissos / Fonte : o
autor.

#PraCegoVer Diagrama com retângulos, que representam entidades interligados por losangos, que representam relacionamentos, com um
indicativo ao lado de cada retângulo, informando a quantidade de relacionamentos existentes entre as entidades, sendo que eles podem ser 1,
quando há apenas um vínculo ou N quando há vários vínculos. Na imagem temos uma entidade relacionada a entidade compromisso e a entidade
compromisso relacionada a pessoa. Em ambos os relacionamentos a cardinalidade é N em todas as extremidades.

A partir desse modelo, vamos agora definir as tabelas. Nesse caso teremos 5 tabelas, pois temos 3 entidades e dois
relacionamentos: N:N. Considerando isso, podemos definir então:

Pessoa(cod_pessoa, nome, telefone, whatsapp, email)

Compromisso(dt_compromisso, horário, título, local, temas_tratados)

Atividade(cod_atividade, descrição_atividade)

Participa(cod_pessoa, dt_compromisso, horário)

Está(dt_compromisso, horário, cod_atividade)

No caso, os dois relacionamentos N:N serão tabelas de relacionamentos, que terão armazenadas apenas as chaves de
acesso das tabelas principais, que permitirão o armazenamento dos dados de cada reunião, atendendo aos requisitos
levantados no modelo conceitual.

Por último, apenas considerando que este não é um bom nome para uma tabela, pois não tem um significado
autoexplicativo do tipo de registro que ela armazena, vamos renomeá-la para atividades do compromisso .

Atividade do Compromisso (dt_compromisso, horário, cod_atividade)

Agora que você já conhece os 3 níveis de abstração que devem ser desenvolvidos, com certeza vai enxergar o mundo dos
dados de forma diferente. Observe, no seu dia a dia, quanta informação você tem a sua volta, não é mesmo? Tente abstrair
 dados de tudo o que está envolvido em um determinado momento e, com essas informações, responda: como tudo seria

armazenado em um Banco de Dados? É um belo exercício para treinar a sua visão analítica!

Na nossa próxima aula estudaremos os Bancos de Dados Relacionais, até mais!

Atividade do Compromisso (dt_compromisso, horário, cod_atividade)

Agora que você já conhece os 3 níveis de abstração que devem ser desenvolvidos, com certeza vai enxergar o mundo dos
dados de forma diferente. Observe, no seu dia a dia, quanta informação você tem a sua volta, não é mesmo? Tente abstrair
dados de tudo o que está envolvido em um determinado momento e, com essas informações, responda: como tudo seria
armazenado em um Banco de Dados? É um belo exercício para treinar a sua visão analítica!

Em nossa próxima aula estudaremos os Bancos de Dados Relacionais, até mais!

REFERÊNCIAS
PIXABAY. [ Sem título ]. 2014. 1 fotografia. Disponível em: https://pixabay.com/pt/photos/planta-planta-de-assoalho-354233/ Acesso
.

em: 24 fev. 2022.

PIXABAY. [ Sem título ]. 2015. 1 fotografia. Disponível em: https://pixabay.com/pt/photos/corredor-apartamento-interior-621741/ .

Acesso em: 24 fev. 2022.

PIXABAY. [ Sem título ]. 2016. 1 fotografia. Disponível em: https://pixabay.com/pt/photos/sala-de-estar-design-de-interiores-1835923/ .

Acesso em: 24 fev. 2022.

MENU PDF VERSÃO DE IMPRESSÃO

-