aula08

Prévia do material em texto

8ºAula
Modelagem de Dados
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
compreender o conceito e a importância da modelagem de dados;
desenvolver modelos de dados de sistemas;
entender as melhores práticas para definição dos modelos.
Prezados(as) alunos(as),
Nesta aula, vamos aprender os conceitos de modelagem 
de dados e entender, na prática, como projetar as estruturas de 
dados.
 
Bom Trabalho!
Bons estudos!
105
Análise de Sistemas I 50
Seções de estudo
1
1 – Projeto de sistemas
2 – Terminologia, a importância da padronização
3 – Modelos de dados
Um modelo de dados é uma coleção de conceitos 
matematicamente bem definidos que auxiliam a definição e a 
expressão das propriedades estáticas e dinâmicas dos objetos 
presentes em aplicações orientadas ao uso intensivo de dados. 
Aceita-se, em geral, que uma aplicação possa ser caracterizada 
por suas propriedades estáticas e dinâmicas e por restrições de 
integridade que as disciplinam. 
Stair (1998) afirma que “o propósito do projeto de 
sistemas é selecionar e planejar um sistema que satisfaça os 
requisitos necessários para obter a solução do problema”. São 
criados, para isso, alguns modelos de projetos para mostrar 
como o sistema deverá funcionar e quais resultados serão 
produzidos por ele. 
A análise estruturada tem igual preocupação com os 
processos e com os dados. Em relação a estes, ela os vê 
como entidades dotadas de atributos (campos), que serão 
representados através do 
relacionamento. Em relação aos processos, segundo a 
técnica da análise estruturada, bastam apenas quatro tipos de 
elementos para retratar a especificação de um modelo lógico: 
fluxo de dados, entidade externa (terminador), processo (ou 
função) e depósito de dados (arquivo). Tais elementos podem 
ser arranjados em uma configuração a que se dá o nome de 
2 - Terminologia, a importância da 
padronização
Embora não faça parte específica da engenharia da 
informação, a terminologia assume papel importante dentro do 
seu contexto, já que é uma forma básica e essencial para se 
manter o diálogo e o entendimento uniforme entre todos os 
participantes do projeto, desde os técnicos de processamento 
de dados até os dirigentes e usuários envolvidos.
É um investimento de retorno garantido e de máxima 
valorização, especialmente, se essa terminologia for definida 
de forma padronizada, única e de fácil identificação. 
Diferente do idioma, a Terminologia deve evitar ao máximo 
os sinônimos, pois, adotando esse princípio, tornará, entre 
outros benefícios, mais fácil a memorização e a associação 
com o conceito embutido.
Manter um padrão para os nomes dos objetos, das 
colunas e de todos os elementos do banco de dados é 
muito importante. Mesmo que você seja um desenvolvedor 
individual em um determinado projeto, futuramente, você 
pode precisar fazer alguma alteração no seu projeto, ou outras 
pessoas podem vir a trabalhar no seu projeto, se você mantiver 
um padrão, ficará mais fácil e rápido entender como o projeto 
foi feito.
Os nomes dos objetos que fazem parte do modelo de 
dados devem ser claros e objetivos, dessa forma, qualquer 
pessoa que olhar o projeto saberá o que determinado objeto 
quer dizer, baseado no seu nome que já identifica facilmente 
que tipo de informação estará armazenada ali. 
Por exemplo: Se vamos criar um local para guardar as 
informações dos clientes de uma loja, observe a estrutura a 
seguir:
CAMPO 2 JOSÉ DA SILVA
CAMPO 4 CAMPO GRANDE
CAMPO 5
Fonte: Acervo pessoal
Podemos ver, no exemplo acima, que os nomes 
escolhidos não nos dão uma boa ideia do tipo de informação 
armazenada ali. Mas, se observarmos o próximo exemplo, 
veremos que o nome claro e objetivo facilitará nosso 
entendimento a qualquer momento que precisarmos fazer 
uma consulta a este projeto.
NOME DA ENTIDADE: CLIENTES
CPF
NOME JOSÉ DA SILVA
ENDEREÇO
CIDADE CAMPO GRANDE
FONE
Fonte: Acervo pessoal
e, consequentemente, perderemos menos tempo nas futuras e 
Os termos usados dentro de todo o projeto de sistema 
podem facilitar muito o trabalho do analista quando são bem 
definidos, ou, ao contrário, podem causar muito transtorno e 
perda de tempo quando os nomes não são bem escolhidos, 
por isso é importante sempre cuidar da terminologia e da 
padronização das informações na hora de “desenhar” o 
sistema.
parte da modelagem de dados, saber qual a importância de 
3 - Modelos de dados
Os modelos de dados podem ser definidos como 
um conjunto de ferramentas conceituais para a descrição 
106
51
dos dados, dos relacionamentos entre eles e das restrições 
de consistência e integridade. Um modelo de dados é um 
conjunto de conceitos que podem ser utilizados para descrever 
a estrutura “lógica” e “física” de um banco de dados.
3.1 - DIAGRAMA ENTIDADE X 
RELACIONAMENTO (DER)
O modelo Entidade X Relacionamento foi criado por 
Peter, em 1976 e representa um modelo conceitual de alto 
nível. Esse modelo está mais próximo da visão do usuário. 
Por esse motivo a participação do usuário é intensa, haja vista 
que o entendimento se torna mais claro quanto às estruturas 
do sistema.
3.1.1 - OBJETOS DO MODELO ER
Entidade é uma estrutura estática que representa um 
objeto, concreto ou abstrato, do mundo real. Cada entidade 
possui um conjunto de propriedades que chamamos de 
atributos. Esses atributos formam a estrutura da entidade. 
Por exemplo, as entidades podem ser representações 
abstratas de funcionários da empresa, movimentos de vendas, 
produtos do estoque, alunos de uma escola, professores, 
notas etc.
As entidades são representadas por um retângulo, como 
mostra a figura 8.1.
ALUNO DISCIPLINA
Figura 8.1 – Representação das entidades
Fonte: Acervo pessoal
Posteriormente, quando o modelo ER for transformado 
em um Banco de Dados físico, essas entidades serão chamadas 
de TABELAS.
O Relacionamento é a associação entre as ocorrências 
das entidades. O relacionamento deve expressar o significado 
da associação no mundo real. 
Relacionamentos podem ser representados por uma 
“linha” na notação de James Martin ou por um “losango” na 
notação de Peter Chen.
Nas figuras 8.2 e 8.3 são mostrados exemplos de 
relacionamentos representados nas duas notações. As 
notações mudam a forma de representar a modelagem, 
porém as duas formas têm o mesmo significado. Em outras 
palavras, só muda o desenho do diagrama. As notações são 
formas diferentes de expressar a mesma ideia.
RELACIONAMENTO
ALUNO NOTA DO ALUNO
Figura 8.2 – Relacionamento na notação de James Martin
Fonte: Acervo pessoal
RELACIONAMENTO
ALUNO NOTA DO ALUNOtem
Figura 8.3 – Relacionamento na notação de Peter Chen
Fonte: Acervo pessoal
Relacionamentos podem ser obrigatórios (total) ou 
opcionais (parcial).
Os atributos formam a estrutura onde as informações 
serão armazenadas dentro da entidade ou do relacionamento. 
Os atributos caracterizam as entidades ou relacionamentos. São 
exemplos de atributos: 
INSTÂNCIA
As instâncias são as ocorrências dentro das entidades, ou 
seja, os dados que serão armazenados dentro dos atributos. 
São exemplos de instâncias:
(67) 9999-1234
As instâncias são o mesmo que os registros dentro das 
entidades e também podem ser chamadas de “tuplas”.
Domínio é o conjunto de valores que o atributo pode 
assumir. São exemplos de domínio:
M ou F
 - Os valores M e F fazem parte do domínio do 
atributo SEXO, pois estes são os valores que podem ser 
armazenados no espaço reservado para guardar a informação 
do SEXO.
 - O conjunto de siglas que representam os Estados 
brasileiros são o domínio do campo UF, pois este campo 
só poderá receber um valor que esteja dentro das siglas 
pertencentes a esse conjunto. Se tentarmos usar uma sigla, 
por exemplo, SS, estaremos tentando armazenar um valor que 
está fora do domínio do atributo, portanto não será aceito 
como válido.
menores que a data atual
 - Nesse exemplo, utilizamos a definição de um 
domínio como uma regra de validade da informação, ou seja, 
indicamos que fará parte do domínioda Data de Nascimento 
todas as datas válidas que sejam menores que a data atual. 
Significa que não poderei cadastrar ninguém cuja data de 
nascimento seja igual à data de hoje. Esse tipo de domínio 
também pode ser chamado de regra de validação.
A obrigatoriedade de um atributo indica que ele não 
pode existir dentro da entidade sem ter um valor preenchido, 
ou seja, o atributo não pode ficar vazio ou com valor nulo. A 
107
Análise de Sistemas I 52
obrigatoriedade dos atributos pode variar de acordo com os 
objetivos do projeto. 
Alguns atributos devem ser obrigatórios por definição, 
sem que isto precise ser informado pelo usuário. Por exemplo: 
na entidade ALUNO, o NOME do aluno não pode ficar vazio, 
por esse motivo ele é dito como atributo obrigatório, pois não 
faz sentido cadastrar um aluno sem o nome. Outra situação 
que pode fazer com que o campo deva ser obrigatório é a 
necessidade em atender os objetivos do negócio da empresa, 
por exemplo: Em uma loja de departamentos, um cliente 
não pode ser cadastrado sem que o seu número de CPF seja 
informado, portanto, o atributo CPF é obrigatório na entidade 
CLIENTE.
É a quantidade de relacionamentos das ocorrências de 
uma entidade com outra. A cardinalidade dos relacionamentos 
pode ser classificada como:
 – quando cada ocorrência de uma 
entidade se relaciona com apenas uma ocorrência da outra 
entidade;
 – quando cada ocorrência de 
uma entidade se relaciona com várias ocorrências da outra 
entidade;
 - quando cada ocorrência 
de uma entidade se relaciona com várias ocorrências da outra 
entidade e vice-versa. Por exemplo: Num sistema acadêmico, 
um curso tem várias disciplinas, e uma disciplina (língua 
portuguesa, por exemplo) pode aparecer em vários cursos.
Rui Barbosa
Castro Alves
Café Filho
Fernando Pessoa
Alunos
BIM 1 – 7,5
BIM 2 – 8,5
BIM 1 – 4,5
BIM 2 – 9,0
BIM 3 – 7,0
BIM 1 – 8,0
BIM 1 – 6,5
Notas
1 n
Figura 8.4 – Representação das cardinalidades
Fonte: Acervo pessoal
No exemplo da figura 8.4, cada aluno pode estar 
relacionado a várias notas. Isso caracteriza um relacionamento 
1 para N (muitos) entre ALUNOS e NOTAS, ou seja, um 
aluno pode ter várias notas.
É o relacionamento entre ocorrências da mesma entidade. 
No exemplo da figura 8.5, cada empregado está relacionado 
com o chefe do setor onde trabalha, mas o chefe do setor 
também é um empregado, por isso, um empregado pode estar 
relacionado com outro empregado.
EMPREGADO Supervisiona
Figura 8.5 – Auto-relacionamento
Fonte: Acervo pessoal
A chave da entidade serve para identificar as instâncias 
(registros, ocorrências) dentro da entidade, conhecida como 
chave primária. A chave serve também para relacionar 
uma entidade a outra, conhecida como chave estrangeira 
ou secundária. Por exemplo, dentro da entidade ALUNO 
podemos ter várias instâncias, ou seja, vários registros de 
alunos. No entanto, podem existir alunos com o mesmo 
nome, o que dificulta a identificação de um ou outro. Assim, 
cada instância dentro da entidade precisa de um identificador 
que o diferencia de todos os outros. A esse identificador 
chamamos de CHAVE.
As chaves podem ser formadas por um ou mais atributos, 
dependendo da necessidade da identificação da entidade.
Existem dois tipos de chaves: Chave Primária e Chave 
Estrangeira.
Também conhecida como Chave Principal, serve para 
identificar cada instância (tupla) dentro da entidade. 
Em uma mesma entidade não podem existir duas tuplas 
idênticas, por esse motivo as chaves não podem se repetir. A 
chave serve para dar unicidade à tupla, é ela que diferencia 
uma tupla de todas as outras. Todos os campos da entidade, 
exceto a chave, podem se repetir. 
A chave primária de uma entidade é formada por um ou 
mais atributos. Quando é formada por apenas um atributo, a 
chamamos de chave simples, quando é formada por dois ou 
mais atributos, a chamamos de chave composta.
Exemplo:
A entidade aluno possui a seguinte estrutura:
NOME
ENDEREÇO
BAIRRO
CIDADE
UF
CEP
E-MAIL
CPF
RG
FONE
Na estrutura existente, deve-se escolher um ou mais 
campos que irão compor a chave. Para isso, é necessário 
observar algumas regras para a criação da chave da entidade, 
108
53
que valem para qualquer entidade do sistema:
a. os atributos de uma chave nunca podem ficar vazios, 
são sempre obrigatórios;
b. uma chave não pode nunca se repetir. Se ela serve 
para dar unicidade à tupla, significa que não podem existir na 
mesma entidade duas chaves com conteúdos iguais;
c. ao escolher uma chave, devemos adotar o princípio 
da minimalidade, ou seja, a chave deve ser composta por 
um conjunto mínimo de atributos que sejam suficientes para 
formar a chave e para garantir que ela seja única dentro da 
entidade.
Na estrutura do exemplo, o campo NOME não pode 
ser escolhido como chave porque podem existir alunos 
com nomes iguais. O mesmo acontece com ENDEREÇO, 
pois pode haver dois alunos morando no mesmo endereço 
e assim por diante. O atributo CPF não se repetirá nunca, 
pois não existem dois CPFs iguais, mas antes de escolher o 
CPF como chave, temos que observar a regra da letra “a” 
citada anteriormente, que diz que uma chave não pode ser 
vazia. Isso significa que o CPF só poderá ser chave se todos 
os alunos tiverem um CPF. 
Se puder existir ao menos um aluno que não tenha 
CPF, esse atributo não poderá ser escolhido como chave. 
Poderíamos, então, optar por formar a chave com mais de 
um atributo. Poderíamos escolher o CPF e o nome para 
formarem juntos a chave. Nesse caso, poderíamos pensar que 
não haveria problema do CPF ficar vazio porque a chave seria 
formada pelos dois atributos juntos e o nome não ficaria vazio, 
mas, novamente, teremos problemas, mas os campos que 
formam a chave são todos obrigatórios, ou seja, não podem 
ficar vazios. Devemos observar também as recomendações a 
seguir:
1º: É recomendado evitar o uso de campos de texto 
como parte da chave, pois alguns gerenciadores de banco de 
dados trabalham mais lentamente quando a chave é formada 
por campos de texto;
2º: Pode também acontecer de termos dois alunos com 
o mesmo nome e que não tenham CPF. Isso faria com que 
tivéssemos duas chaves iguais.
A chave primária de uma entidade pode ser chamada de 
natural ou artificial. A chave será natural quando for formada 
por atributos que já fazem parte da entidade, ou seja, não é 
necessário “criar” nenhum atributo (como um “código”) para 
formar a chave.
A chave primária será chamada de artificial quando for 
formada por algum atributo que não faça parte da entidade 
modelada, ou seja, quando nenhum dos atributos já existentes 
na entidade, ou uma combinação desses atributos, não são 
necessários para que a chave seja única. Nesses casos em que 
a entidade não possua atributos suficientes para formar uma 
chave única, criamos uma chave artificial, que geralmente 
é um código ou número sequencial. Sendo ele sequencial, 
nunca irá se repetir.
A boa prática da modelagem de dados orienta que sempre 
de campos que não fazem parte do negócio que está sendo 
É claro que podemos pensar que um código sequencial irá facilitar, 
O princípio da minimalidade também orienta que uma 
chave primária artificial poderá ser usada quando o conjunto 
de atributos naturais que formam a chave for muito grande 
e essa entidade fizer relacionamento com várias outras 
entidades, ou seja, quando é necessário usar uma combinação 
de muitos atributos dentro da entidade para se ter uma 
chave única, pode-se criar uma chave artificial para facilitar 
o relacionamento com as outras entidades. Mas as chaves 
artificiais devem ser usadas com critério, para que não se 
tornem uma prática comum com o intuito apenas de criar 
uma chave “mais fácil”.
Como vimos acima, existem casos em que os atributos 
não são suficientes para formar uma boa chave. Quando isso 
acontece, teremos que criar um novo atributo identificador 
para ser a chave da entidade. No nosso exemplo, criaremos 
um atributo CÓDIGO para ser a chave, mas vale lembrar que 
só se deve criarum atributo identificador se a entidade não 
possuir atributos suficientes para formar a chave. A entidade 
ALUNO com a definição da chave ficará assim:
# CÓDIGO
NOME
ENDEREÇO
BAIRRO
CIDADE
UF
CEP
E-MAIL
CPF
RG
O campo-chave CÓDIGO está marcado com o símbolo 
“#”, para indicarmos que ele é a chave da entidade.
Também chamada de Chave Externa ou Chave 
Secundária, é usada sempre que há um relacionamento entre 
entidades. A chave estrangeira em uma entidade sempre se 
referencia a uma chave principal em outra entidade, ou seja, o 
relacionamento é feito sempre através da chave principal. Se 
uma chave principal de uma entidade for composta (por mais 
de um atributo), a chave estrangeira que se relaciona com ela 
em outra entidade também será composta, ou seja, elas devem 
ser compatíveis para a relação.
109
Análise de Sistemas I 54
primária da outra entidade, portanto, elas têm que ter obrigatoriamente 
a mesma estrutura e os campos devem ser dos mesmos tipos e 
A chave estrangeira, diferentemente da chave principal, 
não serve para identificar as tuplas da entidade, mas sim para 
relacionar as tuplas de uma entidade com as tuplas de outra.
Figura 8.6 – Representação de chave primária e estrangeira
Fonte: Acervo Pessoal
No exemplo acima, o código do aluno que aparece na 
entidade MATRÍCULA é uma chave estrangeira que está 
relacionada com o código do aluno na entidade ALUNO. 
A chave estrangeira deve ter o mesmo tipo e tamanho que a 
chave principal a que se refere. Diferente da chave principal, 
a chave estrangeira não precisa ser obrigatóriamente, a menos 
que as necessidades do projeto exijam que ela o seja.
Uma entidade pode ter mais de uma chave estrangeira, 
dependendo da quantidade de relacionamentos que ela terá 
com outras entidades.
A entidade pode ser classificada como Forte e Fraca.
 o Sua existência não depende de outra entidade
 o Sua chave é composta apenas por atributos 
próprios
 o Sua existência depende de outra entidade
 o Não possui atributos próprios suficientes para 
montar a chave.
ALUNO NOTA DO ALUNO
1 n
Figura 8.7 – Entidade forte e fraca
Fonte: Acervo Pessoal
No exemplo da figura 8.7, as ocorrências da entidade 
NOTA DO ALUNO só poderão existir no sistema se houver 
o ALUNO correspondente.
Quando a ocorrência de uma entidade (fraca) depender 
da ocorrência de outra entidade (forte), ocorrera a dependência 
existencial. Como foi visto anteriormente, uma entidade fraca 
depende de outra entidade para existir. É o mesmo que dizer 
que uma ocorrência de NOTA DO ALUNO só existirá se 
houver o ALUNO, ou seja, não pode existir uma nota lançada 
para um aluno se este aluno não estiver cadastrado no sistema. 
Se por um descuido um aluno for excluído do sistema, as 
notas desse aluno ficariam “perdidas”, sem relacionamento 
com ALUNO, ou seja, haveria uma quebra da integridade.
ALUNO NOTA DO ALUNO
1 n
Figura 8.8 – Integridade referencial
Fonte: Acervo Pessoal
Retomando a aula
importantes sobre modelagem de dados e algumas 
1 – Projeto de sistemas
Aprendemos, nesta seção, que projetar um sistema é 
criar modelos e definições que irão resultar em um sistema 
que esteja de acordo com o que o usuário espera, conforme 
suas necessidades e visando sempre resolver os problemas 
pelos quais foi solicitada a criação de um sistema.
Nesta seção, pudemos perceber a importância de se usar 
termos padronizados para facilitar o entendimento do projeto. 
Quando se faz um sistema, não devemos pensar apenas em 
facilitar o trabalho durante o projeto, é preciso enxergar mais 
à frente e tentar sanar problemas que ainda não aconteceram. 
Mas se os problemas ainda não apareceram, como vamos 
saber que eles poderão ocorrer? A resposta é muito simples: 
construir um projeto sem se preocupar com a padronização e 
com o uso de nomes e termos significativos irá, com certeza, 
dificultar o entendimento quando for necessário fazer alguma 
manutenção ou nova implementação. Portanto, podemos 
afirmar que a falta da padronização certamente causará um 
transtorno no futuro, por isso podemos evitá-lo antes que ele 
ocorra.
3 – Modelos de dados
Na terceira seção, aprendemos os conceitos básicos sobre 
modelagem de dados. Vimos também as regras e orientações 
para a criação das chaves das entidades e a importância de se 
ter uma preocupação especial com essas chaves na hora de 
projetarmos nossa estrutura de dados.
110
55
Disponível por www em: <http://www.youtube.com/
Disponível por www em: <http://www.youtube.com/
watch?v=0n_NX6-bXlk>. Acesso em 20/10/2013.
Vale a pena assistir
www em: <http://www.devmedia.com.br/introducao-a-
modelagem-de-dados/24953>. Acesso em 12/07/2013.
compostas. Disponível por www em: <http://www.
plugmasters.com.br/sys/materias/349/1/Modelagem-
de-Dados%3A-Chaves-Simples-e-Chaves-Compostas>. 
Acesso em 30/10/2013.
Vale a pena acessar
Vale a pena
Minhas 
111