Banco de dados - Ebook 2

Prévia do material em texto

BANCO 
DE DADOS
E-book 2
Gratuliano Lucena
Neste E-Book:
INTRODUÇÃO ����������������������������������������������4
MODELO LÓGICO E PROJETO 
FÍSICO DE BANCO DE DADOS ��������������� 6
PROJETOS CONCEITUAL X LÓGICO 
X FÍSICO ��������������������������������������������������������� 8
Entendimento do Projeto Conceitual ����������������������8
Entendimento do Projeto Lógico ����������������������������9
Conceitos de Metodologia Orientada a Objetos ����9
Entidades x Atributos x Relacionamento ������������ 11
Entidades ��������������������������������������������������������������� 12
Atributos ��������������������������������������������������������������� 13
Relacionamentos ������������������������������������������������� 14
RELACIONAMENTOS COM 
ENTIDADES��������������������������������������������������15
RELACIONAMENTOS COM 
ATRIBUTOS �������������������������������������������������17
CARDINALIDADES �����������������������������������18
CARDINALIDADES DE ATRIBUTOS ���20
IDENTIFICADOR ATRIBUTO CHAVE 
ÚNICA �����������������������������������������������������������24
Exemplo de um Projeto Lógico na terceira 
Forma Normal ������������������������������������������������������ 26
2
Conceitos do Projeto Físico �������������������������������� 29
LINGUAGENS ENVOLVIDAS EM UM 
SGBD ������������������������������������������������������������31
CRIAÇÃO DE SCRIPTS PARA 
GERAÇÃO DE BANCO DADOS 
FÍSICO �����������������������������������������������������������36
CONSIDERAÇÕES FINAIS ��������������������� 40
SÍNTESE �������������������������������������������������������42
3
INTRODUÇÃO
É fundamental entender quais elementos compreen-
dem tanto o modelo lógico quanto o modelo físico 
de banco de dados�
O Modelo Lógico abrange, em primeiro lugar, enten-
der a regra de negócio – que envolve o entendimento 
dos requisitos dos usuários –; com isso, encaminha-
-se uma solução intelectual de dados que atendam 
simultaneamente os requisitos do usuário e também 
as funções de inteligência do sistema� Há uma técni-
ca de banco de dados para desenvolver um desenho 
de banco de dados, conforme a solução intelectual 
desejada�
Esta técnica de desenho de banco de dados envol-
ve um diagrama gráfico, chamado de Diagrama de 
Entidade e Relacionamento (DER), onde se planeja a 
composição de tabelas, formulação dos índices, for-
mas de relacionamentos entre tabelas� Basicamente, 
podemos considerar essa técnica como a modela-
gem de dados – nesse momento, gera-se uma do-
cumentação por meio da ferramenta Case� 
O departamento de tecnologia da informação tem 
uma área chamada Administração de Dados (AD), 
que avalia o DER, que infere sobre a técnica e sobre 
o atendimento dos requisitos� E essa área tem poder 
de barrar o DER, caso haja alguma inconformidade. 
Esta área também tem a responsabilidade de orientar 
qual a melhor forma de desenvolver o DER.
4
Após a aprovação do DER pela AD, a Administração 
de Dados, por meio da ferramenta Case, cria automa-
ticamente um “script”, com comandos SQL, e o envia 
para a área do Administrador de Banco de Dados 
(DBA), e este se incumbe de dimensionar o espaço 
em disco para comportar a necessidade do volume 
de dados� E, então, executa o “script” fornecido pelo 
AD para a criação dos bancos dados.
A fase de criação do banco de dados executada pelo 
DBA é considerada o modelo físico do banco dados.
Em empresas de pequeno porte, o analista de siste-
ma executa as funções de AD e DBA. Essa situação, 
se for executada por analistas, pode comprometer a 
concepção dos bancos de dados; ou por desconhe-
cimento da técnica ou por negligência da técnica, 
refletindo no desempenho insatisfatório do sistema 
– por exemplo, demora no tempo de resposta� 
5
MODELO LÓGICO E 
PROJETO FÍSICO DE 
BANCO DE DADOS
Para se construir um banco de dados bem estrutu-
rado, há uma técnica chamada de modelagem de 
dados, em que se analisam as regras de negócio de 
forma científica – isso ajuda os técnicos de infor-
mática a entenderem a necessidade dos usuários�
A modelagem de dados é um trabalho exaustivo para 
distribuir as informações em conjuntos de informa-
ções que atendam ao melhor desempenho no tempo 
de resposta, que se adeque aos requisitos da inteli-
gência do sistema: em termos de protótipo de telas, 
em termos da facilidade operacional para o usuário, 
em termos de suportar as manutenções necessárias 
ao longo do ciclo de vida do sistema� Ainda, que se 
enquadre tecnicamente nas regras de modelagem de 
banco de dados� Por exemplo, o quanto uma tabela 
(conjuntos de informações pertinentes a um assunto) 
está relacionada à outra; relacionamento das tabelas, 
o quanto uma informação é dependente da outra; 
qual a forma de acesso por índices de cada tabela� 
Tudo isso é pensando e idealizado por um analista de 
sistemas, que primeiro passa por aprovação de um 
Administrador de Dados (AD). Após isso, a criação 
do banco de dados passa para um Administrador de 
Banco de Dados (DBA), que realiza a criação de ban-
6
co de dados por meio de um gerenciador de banco 
de dados (SGBD).
O momento de concepção de uma modelagem de da-
dos é conhecido como projeto lógico, em que se gera 
uma documentação com simbologia gráfica, a qual 
os técnicos em tecnologia da informação entendem 
como uma comunicação universal� Isso facilita para 
o técnico compreender a lógica dos bancos de dados, 
mesmo que não tenham sido idealizados por ele�
A criação dos bancos de dados num gerenciador de 
banco de dados (SGBD) é conhecida como projeto 
físico� 
7
PROJETOS 
CONCEITUAL X 
LÓGICO X FÍSICO
O objetivo aqui é conceituar o que contempla cada 
um dos projetos: Conceitual, Lógico e Físico�
Não só é esclarecido o que contém cada fase do 
projeto, mas explicam-se os conceitos e técnicas 
de como elaborar uma modelagem de dados, e em 
qual momento e o que determina a passagem de um 
projeto para outro�
Entendimento do Projeto 
Conceitual
O projeto conceitual compreende uma fase em que 
o técnico de tecnologia da informação passa por 
imersão para entendimento dos detalhes das ne-
cessidades do usuário, analisa cenários de proces-
sos, analisa volumes das informações, analisa os 
requisitos funcionais das regras de negócios e não 
funcionais, que envolvem necessidades para acesso 
e atualização de dados�
Após o técnico (Analista de Sistemas/Programador) 
estar seguro do entendimento de todas as nuances 
que envolvem as regras de negócios, ele parte para 
8
modelar os bancos de dados e entra na fase de pro-
jeto lógico�
Entendimento do Projeto 
Lógico 
O projeto lógico é uma conversão da regra de negó-
cio em um modelo gráfico – em que podemos usar 
ferramenta Case, que gera este artefato gráfico.
Conforme mencionado anteriormente, esse artefato é 
chamado de Diagrama de Entidade e Relacionamento 
(DER) ou de Modelo de Entidade e Relacionamento 
(MER), as duas referências referem-se ao mesmo 
artefato�
 Vamos estudar de forma mais detalhada as técnicas 
que envolvem a modelagem de dados�
Conceitos de Metodologia 
Orientada a Objetos
Todas as metodologias de desenvolvimento de sis-
temas – seja a estruturada, orientada a objetos, ágil 
– têm a necessidade de modelagem de dados� A 
orientada a objetos tem alguns conceitos comple-
mentares que integram com a modelagem de dados� 
Dentre esses conceitos é interessante entender al-
guns pontos básicos, conforme ilustrado na figura 1.
9
a) CLASSE – Abstração de um conjunto de objetos 
similares aos do mundo real, conforme exemplo na 
figura 1. O livro tem características (tamanho, tipo) 
mostradas nos objetos�
b) OBJETO – Qualquer coisa do mudo real ou abs-
trata, que tem tamanho e tipo� O objeto é subdivisão 
da classe; pode ocorrer termos de uma classe que 
não tem objetos, portanto, a classe é o próprio objeto, 
pois a estrutura da classe e objeto, tem a mesma es-
trutura com tamanho e tipo� No exemplo ilustrado na 
figura 1, os objetos têm as mesmas características 
da classe�
c) Relação de Classe com Objeto– Todo objeto é 
uma instância de uma Classe� Todas as instâncias 
de uma classe têm valores próprios para os atributos 
especificados na classe. Os objetos são representa-
dos por determinada classe e diferenciam-se entre 
si pelos valores de seus atributos� Os objetos ilustra-
dos na figura 1 (Bíblia, Relatório, Dicionário) podem 
ser encarados todos como livro; portanto, todas as 
características dos três objetos são as mesmas de 
um livro� O livro tem capa, páginas, título, índice, 
introdução, apresentação, glossário, etc� Todas as 
características são comuns aos objetos citados� Os 
objetos podem herdar todos os atributos do livro�
10
Objetos
Relatório
Anual
Dicionário
Livro
Classe
Figura 1: Conceitos Básicos Orientados a Objetos� Fonte: Elaboração 
própria�
Entidades x Atributos x 
Relacionamento 
Existem três formas básicas para trabalhar a mode-
lagem de dados: uma é chamada de entidade e faz 
referência a algum objeto do mundo real, concreto, 
por exemplo, uma pessoa; ou abstrato, por exemplo, 
um departamento� Outra é chamada de atributo, que 
detalha cada informação relacionada às entidades� 
E a terceira forma, sobre o relacionamento de de-
pendências entre as entidades ou entre os atributos�
A modelagem é uma engenharia de dados, que exige 
muita paciência, coerência, bom senso, conhecimen-
to de todas as técnicas de modelagem, entender o 
11
objetivo e o sentido de cada informação� Juntando 
tudo isso, é preciso trabalhar exaustivamente, com 
muita atenção e concentração para alcançar um re-
sultado de sucesso�
Entidades
É um conjunto de objetos do mundo real sobre os 
quais se deseja manter informações no banco de 
dados�
É retratado pelo desenho de um retângulo e pode 
representar objetos concretos (um empregado), con-
forme ilustrado na figura 2. Citamos alguns conteú-
dos possíveis, chamados de instâncias: João, Pedro, 
Paulo e Maria�
Empregado
João
Pedro
Paulo
Maria
Figura 2: Entidade Empregado� Fonte: Elaboração própria�
12
Um outro exemplo é para os objetos abstratos (um 
departamento), conforme ilustrado na figura 3. Citar 
conteúdos possíveis: Contabilidade, Financeiro, 
Jurídico e Pessoal�
 
Departamento
Contabilidade
Financeiro
Jurídico
Pessoal
Figura 3: Entidade Departamento. Fonte: Elaboração própria�
Atributos 
Atributo é um dado, corresponde a cada informação 
que compõe a entidade� Para cada atributo é neces-
sário identificar duas informações; dessas duas, uma 
é referente à quantidade que comporta o conteúdo do 
atributo; a outra é referente ao tipo do dado, que pode 
ser numérico ou alfanumérico� O Atributo também 
pode estar associado ao relacionamento�
Em um DER, uma entidade é representada por meio 
de um retângulo que contém o nome da entidade� 
O relacionamento é representado por um losango e, 
13
dentro dele, vai o nome do relacionamento� Os atri-
butos, ilustrados na figura 4, são representados por 
um traço mais um círculo� Quando o círculo estiver 
preenchido, identifica um atributo chave; e quando o 
círculo estiver vazio, identifica um atributo não chave.
Exemplos de atributos de entidades:
Empregado
Nome
Endereço
Salário
Departamento
Descrição
Número de
Funcionários
Figura 4: Atributos� Fonte: Elaboração própria�
Relacionamentos 
O relacionamento é um dos pontos importantes na 
modelagem de dados, pois representa a arte de fazer 
uma engenharia de dados com perfeição�
14
RELACIONAMENTOS 
COM ENTIDADES
Na modelagem de dados, há um item que exige um 
estudo minucioso para relacionar todas as entidades 
envolvidas num modelo de dados� A solução disso 
é analisar todas as dependências possíveis entre as 
entidades; para isso, utiliza-se o atributo para verificar 
a dependência�
Em um DER, um relacionamento (conforme ilustrado 
na figura 5) é representado por meio de um losango, 
que liga por traços as entidades� No lugar das linhas 
também são colocados informações de cardinalida-
des – o que será detalhado oportunamente� 
BA Nome doRelacionamento
Figura 5: Representação de notação gráfica de relacionamento. 
Fonte: Elaboração própria�
Quando se analisa o relacionamento entre as entida-
des, levando em conta os conteúdos das entidades 
(conforme ilustrado na figura 6), utiliza-se o conteúdo 
dos atributos para verificar a dependência. Temos 
duas entidades: na entidade Empregado, temos um 
atributo chamado nome; na entidade Departamento, 
15
temos o atributo Setor. Analisando a figura, obser-
vamos que João trabalha no setor de Contabilidade, 
e que o setor de Contabilidade tem um empregado 
de nome João� Note que perguntamos da entidade 
Empregado na direção da entidade Departamento, 
e também perguntamos do Departamento na dire-
ção do Empregado� Há que se fazer a pergunta nas 
2 direções, da esquerda (Empregado) para direita 
(Departamento) e da direita (Departamento) para a 
esquerda (Empregado).
Para os demais conteúdos, fazemos as mesmas 
perguntas idênticas ao que foi feito para João, ou 
seja, para o Pedro, Paulo e Maria�
Empregado DepartamentoLotação
Diagrama de Ocorrências (instâncias)
João
Pedro
Paulo
Maria
Contabilidade
Financeiro
Jurídico
Pessoal
Figura 6: Exemplo de Relacionamento com instâncias� Fonte: 
Elaboração própria�
16
RELACIONAMENTOS 
COM ATRIBUTOS 
Como foi previamente dito, o atributo é o principal 
mecanismo para analisar os relacionamentos entre 
as entidades, levando em conta os conteúdos dos 
atributos�
Podemos observar na figura 7: de um lado o Médico, 
que tem dois atributos: Nome e Celular; e do ou-
tro lado o paciente, com dois Atributos: Nome e 
Endereço� Temos o relacionamento entre médico e 
paciente, no centro há o relacionamento Consulta� 
Note que há o atributo dataDaConsulta, que serve 
para verificar quais são as consulta agendadas entre 
o médico e os pacientes. Observamos que a Dra. 
Flora tem duas datas agendadas com José: uma 
para o dia 05/02/2009 e outra para o dia 20/03/2009.
dataDaConsulta
Médico
Dr. Paulo
Dr. Flora
Ana
José
22/10/2007
05/02/2009
20/03/2009
Nome
Instâncias
PacienteConsulta
Celular Nome Endereço
Figura 7: Exemplo de relacionamento com atributos�Fonte: 
Elaboração própria�
17
CARDINALIDADES 
O modelo DER permite expressar cardinalidades mí-
nimas e máximas em cada relacionamento� A cardi-
nalidade mínima 1 também recebe a denominação 
de “associação obrigatória”, já que ela indica que 
o relacionamento deve obrigatoriamente associar 
uma ocorrência de entidade a cada ocorrência da 
entidade em questão�
Com base na mesma linha de raciocínio, a cardinali-
dade mínima 0 recebe a denominação de “associa-
ção opcional”�
Representação: (cardinalidade mínima, cardinalidade 
máxima), Cardinalidades Possíveis: (1,1); (1,N); (0,1); 
(0,N); (N,N).
Na figura 8, na cardinalidade mínima (1) e máxima 
(1) do Cliente, concluímos que o conteúdo do Cliente 
indica que, no mínimo, 1 obriga a ter um registro de 
um cliente em toda a entidade cliente, enquanto o 
máximo poderemos ter um registro de um cliente 
na entidade Cliente, já na entidade na entidade con-
ta, temos obrigatório um mínimo de um registro de 
conteúdo em toda a entidade conta, enquanto na en-
tidade conta, a cardinalidade N, indica que podemos 
ter mais de uma conta com conteúdo registrado em 
toda entidade conta�
A outra análise a ser feita é comparar a cardinalidade 
máxima do Cliente com cardinalidade máxima da 
Conta. Podemos deduzir que um (1) Cliente pode-
18
mos ter várias contas (1 para N, um para muitos); 
fazendo a pergunta ao contrário, que uma conta está 
associada somente um cliente, um para um (1,1). 
Cliente (1,1) (1,N) ContaConta Cliente
Figura 8: Exemplo de Cardinalidade� Fonte: ELMASRI, 2005
Podcast 1 
19
https://famonline.instructure.com/files/168934/download?download_frd=1
CARDINALIDADES 
DE ATRIBUTOS 
Vamos analisar a cardinalidade do próprio atributo, 
o quanto cada informação pode ter variação de con-
teúdo para cada atributo. Podemos classificar em 
vários tipos de análises�
a) Monovalorado: possui um valorúnico para cada 
atributo mostrado na entidade, conforme ilustrado 
na figura 9. No mundo real só existe um CPF por 
pessoa e só existe um nome por pessoa para cada 
empregado� Quando há homônimos de nomes, o CPF 
torna único o empregado, só existe um endereço para 
cada empregado�
Empregado
CPF
Nome
Endereço
Figura 9: Atributo Monovalorado. Fonte: Elaboração própria�
b) Multivalorado: dos atributos mencionados na 
figura 10, no caso o CPF, Nome e Endereço, são mo-
novalorados, por possuírem somente um conteúdo, 
enquanto que o telefone é multivalorado, porque 
pode possuir vários conteúdos: tem 2 números ce-
lulares, tem um número de telefone residencial, tem 
20
um número de telefone comercial e tem um número 
de telefone de contato� Juntando os telefones, temos 
cinco números de telefones, por isso esse atributo é 
considerado multivalorado�
Empregado
CPF
Nome
Endereço
Telefone (0,N)
Figura 10: Atributo Multivalorado� Fonte: Elaboração própria�
c) Autorrelacionamento (Relacionamento Unário): 
neste caso, na entidade Empregado, conforme ilus-
trado na figura 11, o atributo Nome ora pode ser de 
um Supervisor, ora de um subordinado; portanto, no 
relacionamento, podemos ter um atributo identifi-
cado para todos os empregados, o qual é o tipo de 
empregado, se é supervisor ou subordinado�
Empregado
N 1
Supervisionado
Supervisionado
Supervisor
Supervisor
Supervisiona
João
Pedro
Paulo
Maria
Figura 11: Autorrelacionamento� Fonte: Elaboração própria�
21
d) Relacionamento Binário: o relacionamento binário 
envolve a associação de duas entidades� Podemos 
classificar os relacionamentos binários de várias 
maneiras, em N:N (muitos-para-muitos), 1:N (um-
-para-muitos) e 1:1 (um-para-um). O relacionamento 
entre as entidades Empregado e Departamento, con-
forme mostrado na figura 12, tem uma associação 
de relacionamento perguntando do empregado na 
direção do departamento, na ordem 1 para N (um-
-para-muitos), e perguntando do departamento na 
direção do empregado, deduzimos que um depar-
tamento qualquer só tem um empregado, na ordem 
de 1 para 1 (um-para-um).
Empregado 1 N DepartamentoTrabalha
Figura 12: Relacionamento Binário� Fonte: Elaboração própria�
e) Relacionamento Entidade Associativa: Toda vez 
que temos um relacionamento de N para N (muitos-
-para-muitos), no caso mostrado na figura 13, o con-
teúdo de um CPF pode ter vários números de contas 
da entidade Conta Corrente, de um para muitos (1:N), 
perguntado da entidade conta corrente na direção da 
entidade cliente; se perguntarmos que o conteúdo 
de número de conta pode ter vários CPFs (casos de 
conta conjunta), portanto, conclui-se que o relacio-
namento é N para N (muitos-para-muitos). Nesse 
caso, criamos uma entidade nova chamada Cliente 
22
x Conta Corrente, juntando os atributos-chave CPF 
da entidade Cliente com o atributo Número Conta da 
entidade Conta Corrente� Essa junção deverá fazer 
parte da nova entidade Cliente x Conta Corrente; pelo 
fato desta junção ser chave em outras entidades, cha-
mamos esses atributos de chave estrangeira, e ainda 
juntamos com a chave estrangeira mais um atribu-
to: Data de Lançamento, próprio da tabela Cliente x 
Conta� A entidade Cliente x Conta Corrente terá as 
chaves compostas dos atributos CPF do Cliente + 
Número da Conta + Data Lançamento.
CPF Numero
Conta
Data
Lançamento
CPF
Nome
N NCliente
Cliente x Conta
Corrente
Numero
Conta
Descrição
Conta
CorrentePossui
Figura 13: Entidade Associativa. Fonte: Elaboração própria�
23
IDENTIFICADOR 
ATRIBUTO CHAVE ÚNICA
Cada entidade deve ter um identificador, ou seja, um 
atributo-chave: é o conjunto de um ou mais atributos 
cujos valores servem para distinguir uma ocorrência 
única em toda entidade. Exemplo: o atributo CPF está 
com o círculo do Cliente preenchido de vermelho e 
também os atributos Número Corredor + Número 
Prateleira, formando uma chave composta� Essa 
chave composta garante uma chave como único 
conteúdo dentro da entidade Prateleira, conforme 
ilustrado na figura 14, representação do modelo.
Cliente
CPF
Nome
Endereço
Departamento
Número
Corredor
Número
Prateleira
Figura 14: Autorrelacionamento� Fonte: Elaboração própria�
24
Os conceitos entre Entidade Forte e Entidade Fraca: 
na Entidade Forte há um atributo que pode ser chave 
única para toda a entidade. A figura 15 mostra que 
o CPF é um atributo que garante ser chave única na 
entidade EMPREGADO. Nessa situação, podemos 
considerar a entidade DEPENDENTE como entidade 
forte, enquanto que na entidade DEPENDENTE, o atri-
buto CPF Empregado não é suficiente para garantir 
como chave única; nesse caso, precisamos criar um 
atributo artificial – que é chamado de artificial por-
que não veio da regra de negócio, é idealizado pelo 
técnico que cria o modelo de dados� Esse atributo 
chama-se número do dependente. Com os atributos, 
podemos agora ter uma chave única para a entida-
de DEPENDENTE, constituído por chave composta. 
Exemplo: CPF 1 – Esposa (Número de Dependente 
1), CPF 1 – Filho 1 (Número de Dependente 2), CPF 
1 – filho 2 (Número de Dependente 3), com isso, ter-
mos as chaves: 11, 12, 13, o que garante a unicidade 
de chave na entidade�
25
CPF
Empregado
Nome Número
Dependente
Endereço
1 NEmpregado
CPF
Empregado
Nome
DependenteTem
Entidade Forte
A entidade tem um 
atributo (CPF Empregado) 
que pode ser chave única
Entidade Fraca
A entidade não tem um 
atributo que pode ser chave 
única, é necessário juntar com 
outro atributo para formar a 
chave única, fica assim CPF 
Empregado + Número 
Dependente (Chave 
composta). 
Figura 15: Identificador de Atributo composto para Chave Única. 
Fonte: Elaboração própria�
Exemplo de um Projeto Lógico 
na terceira Forma Normal 
 A modelagem está na terceira forma normal, con-
forme conceitos apresentados no módulo (ilustrado 
na figura 16). Antes, é necessário esclarecer sobre a 
utilização das figuras: todas as figuras em cor verde 
referem-se a entidades que são obtidas das regras 
de negócios relatadas pelo usuário; todas as figuras 
em cor laranja são criação do técnico que elabora 
26
o modelo de dados, para possibilitar a eliminação 
de dados redundantes (duplicidades), e também 
para conceber uma construção de atributos-chave 
que permitam um acesso ou atualização dos dados 
com níveis de desempenho que venha a garantir um 
tempo de resposta com excelência. As figuras em 
cor azul são os meios de relacionamentos entre as 
entidades�
Em toda a entidade em cor laranja temos uma relação 
de N:N (muitos-para-muitos), por isso, o técnico na 
modelagem de dados cria uma entidade chamada de 
associativa, trazendo os atributos de chave estran-
geira das entidades envolvidas no relacionamento�
É muito interessante observar que, toda vez que 
criamos uma entidade associativa, colocamos os 
nomes das duas entidades associadas� Por exem-
plo: Professor x Curso, e isso vale para as demais 
entidades associativas�
O modelo está pronto para uma ferramenta Case – 
própria para modelagem de dados –, por exemplo, 
a que foi estudada anteriormente (DBDesignerfork), 
e então construirmos o Diagrama de Entidade e 
Relacionamento (DER).
27
Número
Turma
Sala
CPF Aluno
Nome Aluno
Horário
CPF Prof
Nome Prof
Endereço Prof
Código Curso
Código Curso
Data Validade
Descrição 
Curso
Código
CursoN
N
N
N
N
N
N
N
N
N
N N
N
N
1
Professor X
Curso
Professor
Código
Disciplina
Nome
Disciplina
Números
Crédito
CPF Prof
Código
Disciplina
Data
Validade
Disciplina
Turma
Aluno
Curso
Curso X
Disciplina
CPF Prof
Número
Truma
Data
Validade
CPF Prof
CPF Aluno
Número
Turma
Código
Disciplina
Data
Validade
CPF Prof
CPF Aluno
Número
Turma
Matrícula
Data
Matrícula
Professor X
Turma
Ministra
Ministra
Pertence
CPF Prof
Código Curso
Data Validade
Professor X
Disciplina
CPF Prof
Número
Turma
Código
Disciplina
Data
Validade
Turma X
Disciplina
Aluno X
Disciplina
Turma X
Aluno
Atuação
Pertence
Pertence
Matrícula
Figura 16: Exemplo ProjetoConceitual de Relacionamento Sistema 
Acadêmico� Fonte: Elaboração própria�
28
Conceitos do Projeto Físico 
O projeto físico tem como origem o projeto lógico, 
que é a modelagem de dados, o chamado Diagrama 
de Entidade e Relacionamento (DER), que pode ser 
construído com a ferramenta Case DBDesignerfork. 
Podemos observar que todo atributo-chave tem, an-
tes do atributo, um desenho de chave e que, quando 
temos chaves compostas, há uma divisão em que 
acima ficam os atributos-chave e abaixo ficam os atri-
butos não chave – com um desenho de um losango 
antes do atributo, conforme ilustrado na figura 18.
O relacionamento (conforme ilustrado na figura 
17) é indicado por uma linha; nas extremidades da 
cada linha temos um desenho com os seguintes 
significados:
Entidade A Entidade B
Esta Barra Dupla 
significa que 
atributo chave 
ocorre somente 
uma vez
Este trio de 
linhas, significa 
muitos, chama 
pé de galinha
Figura 17:  Significado do relacionamento. Fonte: Elaboração pró-
pria�
No relacionamento, podemos analisar que o atributo 
chave da entidade “A” ocorre somente uma vez, e que 
o mesmo atributo da entidade “A” ocorre mais de uma 
29
vez na entidade “B” (N-Muitos); portanto, temos uma 
relação de 1:N (um-para-muitos).
Podemos observar que os dados estão prontos para 
geramos o projeto físico, dentro da própria ferramen-
ta DBDesignerfork,
Figura 18: Exemplo Projeto Lógico de Relacionamento Sistema 
Acadêmico. Fonte: Elaboração própria�
30
LINGUAGENS ENVOLVIDAS 
EM UM SGBD 
Antes de gerarmos o projeto físico, temos de pro-
videnciar alguns procedimentos� É preciso ter um 
gerenciador de Banco de Dados (SGBD) e um ge-
renciador de servidor. Devemos seguir os seguintes 
passos: 
Baixe um gerenciador de servidor, no caso o XAMP, 
no link: https://www�apachefriends�org/pt_br/do-
wnload�html; 
Baixe um SGBD, no caso, foi utilizado o MySQL, no 
link: https://www.mysql.com; 
Instale o XAMP; 
Ative o XAMP – duplo clique no ícone do XAMP, um 
clique no “start” do Apache e no “Start” do MySQL, 
conforme figura 19�
31
https://www.apachefriends.org/pt_br/download.html
https://www.apachefriends.org/pt_br/download.html
https://www.mysql.com/
Figura 19: Ativação dos servidores XAMP. Fonte: Elaboração pró-
pria. 
1. Instale o Workbench; 
2. Dê um duplo clique no ícone do Workbench; 
3. Acesse o Workbench (conforme figura 20) e, em 
seguida, crie uma conexão do MySQL no Workbench, 
conforme demonstrado na figura 21.
32
Figura 20: Acessar o MySQL. Fonte: Elaboração própria�
Figura 21: Criação de Conexão do MySQL. Fonte: Elaboração pró-
pria��
1. Acesse o DBDesignerfork e crie todas as tabelas, 
atributos, índices e relacionamentos (conforme figura 
22), clique no símbolo da tabela e solte sobre a área 
em branco na ferramenta, para criar os atributos e 
os tipos. Dê duplo clique sobre o símbolo da tabela 
que você criou na ferramenta�
33
Figura 22: Exemplo para criação de Tabelas, Atributos e Tipos, 
Índices e Relacionamentos� Fonte: Elaboração própria�
2. Após os cadastramentos das tabelas, atributos, 
tipos, e relacionamentos, temos que criar uma cone-
xão com o MySQLAcesse e o DBDesignerfork. Crie 
todas as tabelas, atributos, índices e relacionamentos 
(conforme figura 23). Clique no símbolo da tabela 
e solte sobre a área em branco na ferramenta para 
criar os atributos e os tipos; dê duplo clique sobre 
o símbolo da tabela que você criou na ferramenta�
3. Crie uma conexão com o MySQL, na ferramenta 
DBDesignerfork. Na barra de ferramenta clique em 
“Database”, clique em MySQL e informe os dados 
de conexão do MySQL em “Connection” – “Local 
Instance MySQL80”. No campo “Username” – “root”, 
“Password” (nome, no meu caso, deixei em bran-
co quando da criação de conexão do MySQL no 
Workbench).
34
Figura 23: Exemplo para criação de Conexão DBDesignerfork com 
MySQL. Fonte: Elaboração própria�
35
CRIAÇÃO DE SCRIPTS 
PARA GERAÇÃO DE 
BANCO DADOS FÍSICO
Na própria ferramenta DBDesignerfork, utilizamos 
todo o modelo lógico para gerar um script, confor-
me modelo na figura 24, para executar na ferramen-
ta Workbench para criar o projeto físico com todas 
as tabelas� Nesse caso, é utilizada a linguagem do 
SQL – chamada de DDL “Data Definition Language”� 
Linguagem usada no modelo lógico:
Figura 24: Exemplo para criação Script DBDesignerfork com MySQL. 
Fonte: Elaboração própria�
Apresentamos um exemplo do resultado do script 
gerado pela ferramenta DBDesignerfork:
CREATE TABLE Disciplina (
36
 Disciplina_Codigo INTEGER UNSIGNED NOT NULL 
AUTO_INCREMENT,
 Disciplina_Nome VARCHAR(40) NULL ,
 Disciplina_Creditos INTEGER UNSIGNED NULL ,
PRIMARY KEY(Disciplina_Codigo));
CREATE TABLE Professor (
 Professor_CPF INTEGER UNSIGNED NOT NULL 
AUTO_INCREMENT,
 Professor_Nome VARCHAR(40) NULL ,
 Professor_Endereco VARCHAR(40) NULL ,
PRIMARY KEY(Professor_CPF));
CREATE TABLE Turma (
 Turma_Numero INTEGER UNSIGNED NOT NULL 
AUTO_INCREMENT,
 Turma_Sala INTEGER UNSIGNED NULL ,
 Turma_Horario DATETIME NULL ,
PRIMARY KEY(Turma_Numero));
CREATE TABLE Curso (
 Curso_Codigo INTEGER UNSIGNED NOT NULL 
,
 Curso_Descricao VARCHAR(40) NOT NULL ,
37
PRIMARY KEY(Curso_Codigo));
CREATE TABLE Aluno (
 Aluno_CPF INTEGER UNSIGNED NOT NULL 
AUTO_INCREMENT,
 Aluno_Nome VARCHAR(40) NULL ,
PRIMARY KEY(Aluno_CPF));
CREATE TABLE ProfessorXCurso (
 Professor_CPF INTEGER UNSIGNED NOT NULL ,
 Curso_Codigo INTEGER UNSIGNED NOT NULL ,
 Professorxcurso_DataValidade DATE NULL ,
PRIMARY KEY(Professor_CPF, Curso_Codigo) ,
INDEX ProfessorXCurso_FKIndex1(Professor_CPF) ,
INDEX ProfessorXCurso_FKIndex2(Curso_Codigo),
 FOREIGN KEY(Professor_CPF)
 REFERENCES Professor(Professor_CPF)
 ON DELETE NO ACTION
 ON UPDATE NO ACTION,
 FOREIGN KEY(Curso_Codigo)
 REFERENCES Curso(Curso_Codigo)
 ON DELETE NO ACTION
38
 ON UPDATE NO ACTION);
O resultado do script gerado pela ferramenta 
DBDesignerfork, após a execução no workbench: 
temos o seguinte resultado com a criação de tabelas 
(figura 25). Assim, concluímos o projeto físico.
Figura 25: Execução de Script DBDesignerfork, em forma de Query 
no workbench. Fonte: Elaboração própria.
Podcast 2 
39
https://famonline.instructure.com/files/168935/download?download_frd=1
CONSIDERAÇÕES FINAIS
É essencial entender os conceitos e os artefatos 
que compõem o modelo lógico e o modelo físico 
de banco de dados� O Modelo Lógico abrange, em 
primeiro lugar, entender a regra de negócio, que é 
compreender os requisitos dos usuários, é o ponto 
de partida para desenhar o modelo de dados que 
compõe o modelo lógico�
O modelo lógico serve de insumo para o Diagrama 
de Entidade e Relacionamento (DER). Este, por sua 
vez, serve de insumo para o modelo físico�
No modelo de dados é o momento em que se planeja 
a composição de tabelas, formulação dos índices, 
formas de relacionamentos entre tabelas� 
O modelo de dados contribui muito para uma con-
cepção de banco de dados bem feita, por se tornar 
flexível às mudanças e, com isso, tornar mais fácil a 
manutenção da linha de código do aplicativo� 
A administração de dados (AD) é quem gerencia a 
modelagem de dados, e tem uma visão crítica para 
considerar o rigor das técnicas de modelagem de 
dados, o que ajuda a ter uma modelagem de dados 
mais consistente� Com isso, evita-se principalmente 
problemas com o tempo de resposta dos aplicativos�
A fase de criação de banco de dados do modelo 
físico é executada pelo Administrator de Banco de 
40
Dados (DBA) que toma como base o modelo de 
dados�
Pelo que estudamos até aqui, você já percebeu que é 
fundamental dominar todas as técnicas de modela-
gem dados para evitar construir um banco de dados 
de qualquer jeito, sem nenhuma preocupação com 
o desempenho no tempo de reposta�
Referências 
Bibliográficas 
& Consultadas
41
• Físico.
• Lógico.
• Conceitual.
Projetos: 
• Criação de scripts para geração de Banco Dados 
Físico.• Linguagens envolvidas em um SGBD.
Além disso, estudamos também:
Entendemos, neste módulo, os elementos que 
compreendem tanto o modelo lógico quanto o 
modelo físico de banco de dados.
Banco de 
Dados
DE
ATH
YST
• Metodologia Orientada a Objetos.
• Entidades x Atributos x Relacionamento
SÍNTESE
Referências 
Bibliográficas 
& Consultadas
ASCENCIO, A. F. G.; ARAÚJO, G. S. Estruturas de 
dados: algoritmos, análise da complexidade e 
implementações em JAVA e C/C++� São Paulo: 
Pearson Prentice Hall, 2010� [Biblioteca Virtual]
BARBOZA, F� F� M� et al� Modelagem e desenvol-
vimento de banco de dados. Porto Alegre: Sagah, 
2018� [Minha Biblioteca]
BOOCH, G�; RUMBAUGH, J�; JACOBSON, I� UML: 
guia do usuário. São Paulo: Campus, 2000�
CALSARA, A.; MACHADO, C. A. F.; REINEHR, S. S.; 
BURNETT, R� C� Aderência do RUP à norma NBR 
ISO/IEC 12207. Dezembro/2002. Disponível em: 
https://docplayer.com.br/18795196-Aderencia-do-
-rup-a-norma-nbr-iso-iec-12207.html� Acesso em: 
03 out� 2019�
DATE, C. J. Introdução a sistemas de bancos de 
dados. 7. ed. Rio Janeiro: Campus, 2000.
DBDesignerfork. Software livre para modelagem 
de Dados. Disponível em: https://db-designer-fork.
soft112.com. Acesso em: 05 set. 2019.
ELMASRI, R�; NAVATHE, S� Sistemas de banco de 
dados. 4. ed. São Paulo: Pearson, 2005. [Biblioteca 
Virtual]
GANE, C� Análise estruturada de sistemas. 7. ed. 
Rio Janeiro: LTC, 1993� 
HAY, D. C. Princípios de modelagem de dados. São 
Paulo: Makron, 1999. 
HEUSER, C� A� Projeto de banco de dados� 6�ed� 
Porto Alegre: Bookman, 2009. [Minha Biblioteca]
KRUCHTEN, P. Introdução ao RUP Rational Unified 
Process. 2. ed. Rio de Janeiro: Ciência Moderna, 
2003�
MEDEIROS, L. F. Banco de dados: princípios e práti-
ca� Curitiba: InterSaberes, 2013� [Biblioteca Virtual]
PRESSMAN, R� S� Engenharia de software. 5. ed. 
São Paulo: Makron Books, 2002. 
PUGA, S�; FRANÇA, E�; GOYA, M� Banco de dados: 
implementação em SQL, PL/SQL e Oracle 11g� 
São Paulo: Pearson Education do Brasil, 2013� 
[Biblioteca Virtual]
https://db-designer-fork.soft112.com/
https://db-designer-fork.soft112.com/
RAMAKRISHNAN, R�; GEHRKE, J� Sistemas de 
gerenciamento de banco de dados� 3� ed� Porto 
Alegre: AMGH, 2011� [Minha Biblioteca]
RESENDE, D. A. Engenharia de software e sistemas 
de informação. 2. ed. Rio Janeiro: Brasport, 2003�
SETZER, V� W� Banco de dados. 3� ed� Rio Janeiro: 
Edgard Blücher, 1989� 
SOMMERVILLE, I� Engenharia de software. 6� ed� 
São Paulo: Pearson, 1995. 
TELES, V� M� Extreme Programming. São Paulo: 
Novatec, 2004�
WOLFGANG, P� A� T�; KOFFMAN, E� B� Objetos, abs-
tração, estruturas de dados e projeto usando C++� 
Rio de Janeiro: LTC, 2008� [Minha Biblioteca]
	Introdução
	Modelo Lógico e Projeto Físico de Banco de Dados
	Projetos Conceitual x Lógico x Físico
	Entendimento do Projeto Conceitual
	Entendimento do Projeto Lógico 
	Conceitos de Metodologia Orientada a Objetos
	Entidades x Atributos x Relacionamento 
	Entidades
	Atributos 
	Relacionamentos 
	Relacionamentos com Entidades
	Relacionamentos com Atributos 
	Cardinalidades 
	Cardinalidades de Atributos 
	Identificador atributo chave única
	Exemplo de um Projeto Lógico na terceira Forma Normal 
	Conceitos do Projeto Físico 
	Linguagens envolvidas em um SGBD 
	Criação de Scripts para geração de Banco Dados Físico
	Considerações finais
	Síntese