BANCO

DE DADOS
Gratuliano Lucena

E-book 2
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
 Classe

Livro

Objetos

Relatório
Anual

Dicionário

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:

Nome

Empregado Endereço

Salário

Descrição

Departamento

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.

A B
Nome do
Relacionamento

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 Lotação Departamento

Diagrama de Ocorrências (instâncias)

João Contabilidade

Pedro Financeiro

Paulo Jurídico

Maria 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.

Médico Consulta Paciente

Nome Celular dataDaConsulta Nome Endereço

Instâncias
22/10/2007
Dr. Paulo Ana
05/02/2009
Dr. Flora José
20/03/2009

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) Conta Cliente (1,N) Conta

Figura 8: Exemplo de Cardinalidade. Fonte: ELMASRI, 2005

Podcast 1

19
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.

CPF

Empregado 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.

CPF

Nome
Empregado
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.

Supervisionado Empregado Supervisor

N 1

Supervisiona

João Supervisor
Pedro
Paulo
Maria
Supervisionado

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 Trabalha N Departamento

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.

Conta
Cliente N Possui N Corrente

Nome Descrição
CPF Numero
Conta

Cliente x Conta
Corrente

CPF Numero Data

Conta Lançamento

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.

CPF

Cliente Nome

Endereço

Número
Corredor

Departamento

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

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).

Empregado 1 Tem N Dependente

Nome
Número
Dependente
CPF
Endereço
CPF Empregado
Empregado
Nome

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
 CPF Prof
Professor X
Código Curso
Curso
Data Validade

Código
Curso
Ministra N Curso
Descrição
N Curso
N
CPF Prof
Professor Nome Prof Pertence
Endereço Prof

N
Código Curso
Ministra Curso X
Código Curso
Disciplina
Data Validade
CPF Prof
Professor X Código
Disciplina Disciplina
Data
N
Validade Código
Disciplina
1 Nome
N Disciplina Disciplina

Atuação Números
N Crédito

CPF Prof Pertence

Número Professor X CPF Prof
Truma Turma Número
Data
Turma X Turma
Validade
Disciplina Código
Disciplina
Data
N Validade
N
N
Número
Turma
Turma Sala
Pertence
Horário
CPF Prof
CPF Aluno
N Número Aluno X
Turma Disciplina
Código
Disciplina
Matrícula Data
Validade

N
N N
CPF Prof

CPF Aluno CPF Aluno

Aluno
Turma X Número
Turma Nome Aluno
Aluno
Matrícula
Data
Matrícula

Figura 16: Exemplo Projeto Conceitual 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 Este trio de

significa que linhas, significa
atributo chave muitos, chama
ocorre somente pé de galinha
uma vez

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
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
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
 SÍNTESE

DE

ATH
Banco de
YST
Dados

Entendemos, neste módulo, os elementos que

compreendem tanto o modelo lógico quanto o
modelo físico de banco de dados.

Projetos:

• Conceitual.

• Lógico.

• Metodologia Orientada a Objetos.

• Entidades x Atributos x Relacionamento

• Físico.

Além disso, estudamos também:

• Linguagens envolvidas em um SGBD.

• Criação de scripts para geração de Banco Dados

Físico.
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]
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]