Buscar

Cursinho online - Modelagem de Dados Completo

Prévia do material em texto

Modelagem de Dados
Estrutura do Conteúdo
	Este conteúdo está estruturado em dois capítulos:
Capítulo 1: Introdução a banco de dados
· Tópico 1: Visão geral
· Tópico 2: Técnicas de análise de dados
· Tópico 3: Normalização de dados e de sistemas.
Capítulo 2: Relacionamento
· Tópico 1: Modelo de Entidade de Relacionamento
· Tópico 2: Cardinalidade do Relacionamento
· Tópico 3: Autorrelacionamento.
CAPÍTULO 1
INTRODUÇÃO A BANCO DE DADOS
Visão Geral 
	Neste tópico, vamos apresentar conceitos e instruções em lógica.
Conteúdos:
	Banco de dados
	Conceitos relacionais
	Vantagens de uso de um banco de dados
	Banco de dados relacional.
	Ao finalizar este tópico, você será capaz de:
	Explicar conceitos relacionais.
	Definir as vantagens de um banco de dados.
	Reconhecer um SGBD.
	Explicar o que é banco de dados relacional.
Introdução
	Nas últimas décadas, acompanhamos um grande avanço tecnológico. Com isso, cresceu também a necessidade de armazenamento de dados.
	Nesse cenário, o armazenamento de dados é muito importante para a tomada de decisões. 
	Como isso acontece na prática?
	Por exemplo, como o setor de marketing de uma empresa identifica o cliente, suas preferências, seus fatores de decisão de compras e outras informações?
	Vejamos um exemplo a seguir.
Exemplo
	O banco de dados pode ter um uso eficiente em uma aplicação web de comércio eletrônico.
	Por meio da aplicação web em comércio eletrônico, o sistema solicita as preferências do cliente durante o cadastro no site.
	Quando o cliente acessar a página novamente, em outro dia, aparecerá uma lista de itens de sua preferência.
	Isso significa que a aplicação grava um histórico de operações do cliente e exibe seus produtos preferidos com base nessas informações.
	Com isso, a chance de o cliente fazer um novo pedido aumenta.
Banco de Dados
	Não é novidade que as informações ficam em banco de dados, certo?
	Você já parou para pensar em como esses dados são armazenados?
	Pense na maneira como eles manipulados e em como a informação fica guardada.
	Para que possamos responder a essas questões, precisamos:
· Conhecer as técnicas que representam a modelagem de dados.
· Entender que não há banco confiável sem modelagem de dados.
A modelagem de dados define, de maneira lógica, qual o melhor processo para que determinada necessidade seja atendida, ou seja, é ela que define a estrutura do banco de dados.
	Vamos entender melhor o que significa modelar um banco de dados?
	Você já viu alguém construir um prédio de cima para baixo? Claro que não! Criar um banco de dados sem modelagem seria como construir um prédio de cima para baixo. Nesse sentido, a modelagem de dados define a base, o alicerce, do banco de dados.
	Antes que você possa responder a perguntas sobre banco de dados, é necessário entender alguns conceitos. Para modelar um sistema de informações, precisamos identificar e especificar dois pontos importantes.
Os dados e as informações que o sistema processará.
As funções que comporão o sistema de banco de dados.
Exemplo
	Vamos ver alguns exemplos de utilização do banco de dados? Para isso, navegue pelas setas.
Sistema de Farmácia
	O sistema de farmácia precisaria incluir uma base de dados para:
· Controle de estoque (entrada e saída de medicamentos)
· Documentos fiscais
· Relatórios
· Cadastro de fornecedores (laboratórios)
· Cadastro de clientes para serviços de delivery
· Controles financeiros
· Controles de funcionários etc.
Sistema educacional
O sistema educacional precisaria incluir uma base de dados para:
· Cadastro de alunos matriculados
· Rendimento escolar
· Relatórios administrativos e pedagógicos
· Cadastro de professores
· Disciplinas e carga horária
· Biblioteca
· Financeiro
· Recursos humanos etc.
A análise de dados é muito importante no processo de modelagem. Ela ajuda a compreender a natureza e a estrutura dos dados que um sistema processa e usa. Vamos entender quais são os objetivos e as técnicas mais utilizadas na modelagem!
	Podemos dizer que o banco de dados possui as seguintes características:
1	É um conjunto de informações organizadas e relacionadas.
2	Contém informações que são tratadas como uma unidade, um assunto comum.
Essas características definem o banco de dados como um arquivo que armazena diversas informações organizadas e distribuídas em tabelas, que estão relacionadas e comunicam-se umas com as outras, nos permitindo responde a algumas perguntas:
	Quais são os fornecedores que atendem às farmácias da zona sul de São Paulo?
	Quais são os fornecedores que atendem às farmácias da zona sul de São Paulo?
	Quantos alunos estão matriculados no Módulo I do Curso Técnico em Desenvolvimento de Sistemas?
	Perguntas como essas só podem ser respondidas porque existem dados e informações armazenados em um banco de dados. Incrível, não?!
Conceitos Relacionais
	Você sabe o que são conceitos relacionais? Vamos conhecê-los!
Tabelas
Campos e registros
Dara Base Monagement System (DBMS) ou Sistema Gerenciador de Banco de Dados (SGBD)
Banco de dados relacional
	A seguir, veremos conceitos de forma mais detalhada.
Tabelas
	De modo geral, todos sabemos o que é uma tabela. No entanto, como as tabelas são a base para entender e construir um banco de dados, é melhor checarmos se nossa ideia sobre tabela está correta, não é mesmo?
Uma tabela é um conjunto de linhas e colunas em que os valores de dados são inseridos. As informações são armazenadas justamente nesta intersecção entre linhas e colunas, a qual denominamos células de memórias.
	As tabelas são as unidades básicas de um Sistema Gerenciador de Banco de Dados Relacional (SGBDR).
	Precisamos definir um nome para identificar, representar e localizar os valores de dados inseridos na tabela. De que maneira definimos esse nome? Por exemplo, se a tabela vai armazenar informações de produtos, é recomendado definir o nome dessa tabela como Produtos.
Campos e Registros
	Você sabe o que representam campos e registros em uma base de dados?
No ambiente de sistemas de informação, cada célula de uma tabela que armazena um dado ou um valor é definida como campo. Campo é uma unidade de memória que armazena informações.
Um conjunto de campos ou células é chamado de registros. Logo, uma tabela que armazena dados e informações é composta por campos e registros.
Exemplo
	Vamos imaginar uma tabela chamada Agenda. Nessa tabela, podemos definir os campos Nome, Telefone, Celular e E-mail.
					Campo			Registro
A linha de cabeçalho da tabela		É a menor unidade	É o conjunto de
é utilizar para identificar os 		de armazenamento	campos 
campos e as referências das 		de informação. 	referentes a
informações armazenadas.		Exemplo: Nome.	um mesmo 
								elemento.
								Exemplo: cada
								registro é
								composto por:
								Nome,
				Campos			Telefone,
								Celular, E-mail.
Nome		Telefone	Celular		E-mail
 Luís		3688-1234	3690-4545luis@sistemas.com.br
									 Registros
	Beatriz		4455-9876	3690-2233beatriz@sistemas.com.br
		As linhas de detalhe da tabela são utilizadas para
		armazenas as informações dos valores de dados
		inseridos e que serão processados.
Conceitos Relacionais
Campos e Registros
	Sabemos que o registro é um conjunto de campos. Quando acessamos um registro, estamos acessando diversos campos e informações.
O objetivo de um registro é permitir o acesso a diversas informações armazenadas em seus próprios campos.
	Cada registro pode ser considerado uma linha da tabela. Uma tabela com várias linhas são vários registros, várias ocorrências com os mesmos campos, mas com informações iguais ou diferentes.
Data Base Management System (DBMS) ou Sistema Gerenciador de Banco de Dados (SGBD)
	Os SGBD são programas responsáveis pelo controle de acesso dos usuários à base de dados, bem como pelo controle do armazenamento, alteração e recuperação dos dados.
Acesso dos usuários à base de dados
Armazenamento de dados
Alteração de dados
Recuperação de dados
	O SGBD garante a independência física e lógica dos dados em relação aos programas que os manipulam.
	Vocêconseguiu perceber a importância do SGBD?
Banco de Dados Relacional
	É um aplicativo em que todas as tabelas, índices, consultas, relatórios e códigos são armazenados em um único arquivo.
	Um banco de dados relacional é um grupo de tabelas interligadas.
	Por exemplo, um banco de dados relacional será composto por um relacionamento entre as tabelas de clientes, locações, filmes, réplicas, fornecedores etc.
	Após conhecer os conceitos de tabelas, campos, registros, SGBD e banco de dados relacional, você pode estar se perguntando:
Qual é a função de um projetista de banco de dados? Tem alguma ideia da resposta?
	Pois, vamos lá...
A principal função do projetista de um banco de dados relacional é realizar a definição e organização das tabelas, decidindo por mais campos elas devem se relacionar (comunicar).
Vantagens de um Banco de Dados
	A utilização das bases de dados oferece muitas vantagens.
	As vantagens mais significativas são:
· A alteração e recuperação dos dados é mais rápida.
· Os dados e as informações ocupam menos espaço para serem armazenados.
· Muitos usuários podem compartilhar as mesmas informações ao mesmo tempo.
· A redundância de dados é minimizada.
· As inconsistências podem ser evitadas.
· Os padrões podem ser estabelecidos.
· Os níveis de segurança podem ser implementados.
Utilizar um banco de dados pode ser muito prático, não é mesmo?
A seguir, vamos ver de que maneira esses bancos de dados podem estar presentes em nosso dia a dia.
Informação
	Quando falamos de banco de dados, estamos falando também em informação. e o que é informação?
Informação é um conjunto organizado de dados. Um banco de dados relaciona informações com o objetivo de atender às necessidades do usuário, seguindo padrões regulares de organização da informação.
	Se pararmos para pensar, veremos que vários bancos de dados fazem parte de nossas vidas. Vamos conhecer alguns exemplos deles no cotidiano? 
Dicionário
Lista telefônica
Controle do acervo de uma biblioteca
Sistema de controle dos recursos humanos de uma empresa
Dados pessoais de uma pessoa e muitos outros
Desafio
	Considerando as informações apresentadas até aqui, assinale a opção mais adequada para completar a lacuna da frase a seguir. 
	A principal função do analista de banco de dados relacional é realizar a definição e organização das............., decidindo por quais campos elas devem se relacionar (comunicar).
( ) dados
( X ) tabelas
( ) colunas
( ) informações
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	No curso de TI, você está estudando Banco de Dados, e eu professor pediu para que apontasse as vantagens do uso de um SGBDR. Nesse caso, você apontou duas vantagens.
	Marque V para as verdadeiras vantagens apontadas e F para as falsas.
								V	F
Maior nível de segurança.					X
Alteração de dados em diferentes locais.				X
Usuários não compartilham as mesmas informações.			X
Recuperação e alteração dos dados com maior rapidez.	X
	Questão 2
	Seu professor de Banco de Dados apresentou a seguinte tabela para estudo:
Nome	Telefone	Celular		E-Mail
Luís	3688-1234	3690-4545	luis@sistemas.com.br
Beatriz	4455-9876	3690-2233	beatriz@sistemas.com.br
	Complete as sentenças da coluna de afirmações, numerando-a de acordo com a coluna de termos.
TERMOS
( 1 ) ARMAZENAMENTO
( 2 ) CELULAR
( 3 ) CAMPO
( 4 ) REGISTRO
AFIRMAÇÕES
4	O campo nome pode ser acessado em qualquer......
3	Luís é uma informação armazenada no......nome.
1	Um campo é a menor unidade de........de informação.
2	.........é um campo.
Encerramento do Tópico
	Neste tópico, você aprendeu os conceitos e as instruções em lógica.
	Agora você já sabe explicar conceitos relacionais, consegue definir as vantagens de um banco de dados, reconhece um SGBD e é capaz de explicar o que é banco de dados relacional. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Vamos prosseguir em nossos estudos? Siga para o próximo tópico.
Técnicas de Análise de Dados
	Neste tópico, apresentaremos as técnicas de análise de dados que permitem identificar problemas e analisa-los, a partir de diferentes abordagens e técnicas.
	As técnicas de análise são importantes, pois orientam a projeção e a manutenção do banco de dados.
	Conteúdos:
· O que é análise de dados?
· Para que serve a análise de dados?
· Como estruturar o banco de dados.
· Compartilhamento e integração de dados.
Ao finalizar este tópico, você será capaz de:
· Identificar problemas relacionados a dados.
· Explicar o compartilhamento e a integração de dados em um sistema.
· Analisar e estruturar um banco de dados.
Definição de Análise de Dados
	Análise de dados é um conjunto de diferentes técnicas que permite investigar, estruturar e conceituar a realidade do ponto de vista dos dados, independentemente dos processos que as manipulam.
A análise de dados nos ajuda a enxergar o sistema como se nós fôssemos os dados.
Utilização da Análise de Dados
	A análise de dados é utilizada para:
								Ferramenta Evitar
	Entender melhor as	Ferramenta para		 	 para 	problemas
	situações-problema o desenvolvimento	 administração de redundância
				 de sistemas		 de dados	de dados
 Ajudar na 		Estruturar o	 Permitir o Organizar a Simplificar 
 investigação 	 banco de dados de	 compartilhamento dos sistemas a visão
 dos processos	 maneira adequada		de dados e o 	 da 
							 compartilhamento organização
						 de informações perante 
									 as
							 	 informações
	Muita coisa, não?!
Melhor Conhecimento do Problema
	Os problemas podem se apresentar de maneira mais concreta ou mais abstrata.
	Vamos entender melhor cada um desses dois casos? 
Problema concreto
· Criar um relatório para visualizar os clientes do Brasil.
Problema abstrato
· Controlar informações de infração de trânsito do Estado de São Paulo.
· Gerenciar as informações de compras de passagens em aeroportos.
Para resolver problemas de qualquer nível de abstração, podemos adotar um método conhecido como top-down.
Top-down
	Também conhecido como método de refinamento sucessivo. Esse método baseia-se na estratégia de dividir para conquistar o resultado. O problema é dividido em subproblemas (problemas menores) que podem ser mais fáceis de resolver.
	Com isso, você divide a situação-problema em situações de menor complexidade e soluciona uma de cada vez até atingir o objetivo.
	Veja na ilustração a seguir:
	Sabemos que um problema complexo pode ser entendido por completo. No entanto, ele precisa ser analisado a partir de pontos diferentes.
	A análise de dados focaliza um sistema a partir das funções que o compõem. Além disso, ela fornece uma visão alternativa para estudar o sistema.
Um sistema é um objeto virtual. Se olharmos para um sistema a partir de diferentes pontos de vista, poderemos destacar detalhes diferentes em cada um dos pontos.
	Nenhum dos pontos exibe uma visão completa do sistema. Para ser um bom analista, é preciso conhecer duas técnicas comumente usadas.
Exemplo 1:
Ponto de vista dos dados
Observe que o dado (objeto) pode ser visualizado a partir de pontos específicos.
Aqui é possível ver os números 6,4 e 2
Ao girar, visualizamos outros números:3, 5 e 6
Exemplo 2:
Ponto de vista das funções
Vamos considerar a definição da palavra automóvel a partir de pontos de vista diferentes.
Veículo para transportar pessoas
Veículo com quatro rodas, impulsionado por um motor de combustão interna, projetado para transportar pessoas
	Como vimos nos exemplos, o mesmo objeto pode gerar diversos pontos de vista. A mesma coisa acontece com a análise de sistemas. Para termos uma análise mais segura, temos de analisar o sistema a partir de pontos diferentes.
Como Estruturar o Banco de Dados
	Observe o esquema.
	Como você já sabe, banco dedados é um conjunto de objetos que estão relacionados entre si e de maneira organizada.
	Os objetos que compõem o banco de dados podem ser tabelas (de clientes, locações, filmes, réplicas, fornecedores etc.), consultas, relatórios, entre outros.
	Para projetar um banco de dados de maneira adequada, é necessário conhecer a estrutura e a origem dos dados que serão armazenados. Por isso, é indispensável questionar os interessados no projeto e levantar toda informação possível.
	Na concepção de um sistema, questionar corresponde à fase da entrevista conhecida como Análise de Requisitos. Já os interessados no projeto são as pessoas que vão usar os dados. Observe o esquema para compreender melhor.
						Análise de
						Requisitos
 Projeção de		Questionamento		 Levantamento
banco de dados	aos interessados		 de informações
						Usuários
						dos dados
	com o processo de Análise de Requisitos, evitam-se possíveis contratempos que poderiam acontecer no futuro, como comprometimento no acesso ou na consulta de dados armazenados no banco de dados.
	Esses contratempos futuros poderiam gerar retrabalho e complicações na recuperação dos dados, além da indisponibilidade do banco de dados, causando consequências irreparáveis.
Entender o conceito e o modelo do que queremos fazer é fundamental para o sucesso do banco de dados.
Recuperação de dados
	É a visualização dos dados em uma consulta ou relatório, organizados de forma lógica e racional.
Compartilhamento e Integração de Dados
Banco de Dados Não Integrado
	Atualmente, ainda é possível encontrar, nas organizações, sistemas diversos com sua própria base de dados.
	Mas será que utilizar bases de dados próprias é a melhor maneira de trabalhar? Parece que não.
	Por essa razão, não é recomendado manter essa estrutura na administração de bancos de dados. Observe o esquema.
	Baseado nessa organização, você não acha que fica difícil realizar uma leitura dessa ilustração?
	Fica difícil, não é mesmo? Agora, tente imaginar isso funcionando.
	O bando de dados não integrado é uma maneira de organização arriscada, sabe por quê? Porque os mesmos dados podem ser replicados em mais de um arquivo, gerando redundância. Além disso, até o processo de recuperação, atualização e processamento desses dados fica redundante.
	Com isso, a integração e a troca de informações entre os sistemas se faz de maneira trabalhosa, podendo gerar insegurança e diversas complicações futuras para outras áreas da organização que precisam dessas informações consolidadas.
	Não há garantia de que esses dados redundantes sejam confiáveis, no sentido de apresentarem os mesmos valores ou até mesmo alguma compatibilidade com o conteúdo.
Redundância
	É a duplicidade desnecessária de dados em uma base de dados.
Banco de dados centralizado
	Muitas vezes, os dados são entendidos e definidos de maneira diferente dentro da organização. Essas diferenças nas definições, em muitos casos, são a origem da redundância e, consequentemente, da inconsistência dos dados.
	A maneira recomendada para o compartilhamento de informações em um banco de dados diz que devemos utilizar um único banco de dados (principal), pois, assim, evitamos a redundância e inconsistência das informações. Com isso, o retrabalho e a necessidade de trocar informações entre os sistemas é eliminada.
	Observe a ilustração. Veja como a organização do banco de dados centralizado é evidente e a visualização fica mais simples!
Inconsistência
	É um erro de informação armazenada no sistema, informação inválida.
	É comum que algumas pessoas percam tempo discutindo os conceitos de modelagem em reuniões e, mesmo assim, na hora de realizar alguma manutenção, surjam diversos problemas.
	Você sabe por que surgem esses problemas? Por cada de falta de conhecimento de conceitos durante a modelagem.
	Nesse ponto, a análise de dados é fundamental, pois:
· Oferece técnicas que permitem realizar o estudo sobre os dados.
· Preocupa-se em conseguir um acordo entre os usuários em relação à definição dos dados na organização.
Está percebendo a importância da análise dos dados?
Agora que você já sabe como a análise de dados é importante, precisa saber, também, que existem algumas técnicas para investigar, estruturar e conceituar os dados. Vamos conhecer as duas mais usadas?
Normalização de dados
	A normalização dos dados é uma técnica formal, simples e de fácil aplicação.
	No entanto, essa técnica é bem rigorosa. Visa à simplificação dos arquivos, mas não ajuda na investigação do problema.
Modelagem Entidade-Relacionamento (MER)
	A MER é uma técnica menos formal.
	No entanto, é extremamente útil para investigar as necessidades dos usuários em relação aos dados.
	Aplicando essas técnicas da forma correta, é possível estruturar uma base de dados segura.
Saiba Mais
Para aprofundar seus conhecimentos sobre análise de dados, navegue pelo site Devmedia:
http://www.devmedia.com.br/
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	A empresa em que você trabalha possui uma estrutura descentralizada em diversos sistemas com vários bancos de dados, conforme o modelo a seguir.
	Entretanto, as vantagens da centralização do banco de dados são bem conhecidas e podem melhorar a estrutura atual de sua empresa.
	Marque V para as verdadeiras vantagens e F para aspectos que não são vantagens em relação a centralização do banco de dados.
								V	F
Maior participação dos diversos setores na tomada			X
 de decisões.
Inexistência de duplicidade de registros nos diversos		X
 bancos de dados.
Melhor integração e troca de informações com outros		X 
sistemas da empresa.
Segurança e confiabilidade na recuperação de informações 	X
contidas no banco.
	Questão 2
	Você foi contratado por uma empresa de TI para trabalhar com análise de dados.
	As duas técnicas de análise comumente utilizadas para essa finalidade são:
( ) A. Classificação das informações e Generalização dos dados.
( ) B. Histórico dos registros e Mapeamento de relacionamentos.
( ) C. Levantamento de requisitos e Esquematização de processos.
( X ) d. Normalização de dados e Modelagem entidade-relacionamento.
Encerramento do Tópico
	Neste tópico, você aprendeu as técnicas de análise de dados que permitem identificar e analisar problemas a partir de diferentes abordagens.
	Agora você já sabe identificar problemas relacionados a dados, consegue explicar o compartilhamento e a integração de dados em um sistema e é capaz de analisar e estruturar um banco de dados. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Vamos prosseguir em nossos estudos? Siga para o próximo tópico!
Normalização de Dados e de Sistemas
	Neste tópico, apresentaremos os principais conceitos de normalização de um banco de dados. Além disso, conheceremos técnicas para organizar e normalizar um sistema.
	Conteúdos:
· Organização de um sistema
· Análise da organização do sistema
· Sistema normalizado
· Conceitos de normalização
· Separação dos atributos multivalorados
· Ligação do item ao pedido
· Definição da chave das tabelas criadas.
Ao finalizar este tópico, você será capaz de:
· Definir conceitos de normalização.
· Identificar e analisar um sistema normalizado.
· Explicar os componentes do Modelo Entidade-Relacionamento (MER).
· Eliminar detalhes que dificultam as operações sobre os dados.
· Minimizar as redundâncias e os consequentes riscos de inconsistências.
· Reduzir e facilitar as manutenções.
· Separar atributos multivalorados.
· Aplicar chaves nas tabelas criadas.
· Realizar ligações entre tabelas utilizando os conceitos apresentados.
Normalização de dados
	Você já ouviu falar em normalização de banco de dados?
A normalização é uma técnica de análise de dados que visa determinar a melhor formação para uma estrutura de dados.
	Vamos conhecer os principais objetivos dessa técnica? 
Eliminar detalhes que dificultam as operações sobre os dados.
Minimizar as redundâncias e os consequentes riscosde inconsistências.
Reduzir e facilitar as manutenções.
Organização do Sistema – Exemplo
	Vamos entender melhor a normalização a partir de um exemplo.
	Imagine que você precisa organizar um sistema de cadastro de pedidos para uma organização e levantou as seguintes informações:
1	
· Dados do pedido
· Código da organização
· Número do pedido
· Data do pedido
· Data de nascimento
· Código de vendedor
· Nome do vendedor
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
· Itens (10 por pedido)
· Código do item
· Quantidade
· Preço unitário
· Preço total
· Valor total do pedido
Agora, analise o conteúdo do sistema.
2
1. O cliente solicitante mudar de endereço.
2. O espaço em disco for limitado e a demanda de pedidos for grande.
3. O cliente alterar o número de itens por pedido para um número maior.
4. Houver necessidade de enviar uma correspondência a todos os clientes.
Análise da Organização do Sistema – Exemplo
	Visualizar o que foi percebido no levantamento das informações.
Exemplo 1
	O endereço do cliente está guardado em cada de seus pedidos. Com isso, a mudança exigirá que todos os pedidos sejam verificados e muitos sejam alterados.
	E se o endereço não for alterado em algum deles? Automaticamente você terá a inconsistência.
Exemplo 2
	O sistema foi projetado para armazenas até 10 itens. Se o pedido tiver menos de 10 itens, o espaço correspondente aos itens restantes ficará sem utilização, consumindo espaço no disco.
Exemplo 3
	O sistema está preparado para armazenar 10 itens por pedido. Caso haja a necessidade de rever a quantidade de itens, o sistema sofrerá modificações críticas, o que pode demandar muito tempo e gerar altos custos.
Exemplo 4
	Se o número de itens por pedido for alterado, o preço total do item, o valor e outros dados que estiverem ligados a eles deverão ser recalculados.
	Se isso não for feito, você terá outra inconsistência de informação.
Exemplo 5
	O sistema poderá ser usado como base para envio de mala direta a todos os clientes.
	No entanto, o mesmo cliente poderá receber mais de uma cópia da mesma correspondência por conta da inconsistência do endereço. Além disso, clientes que não têm pedido cadastrado no sistema não receberão a carta.
Análise da Organização do Sistema
	A partir do exemplo apresentado, você deve ter observado que muitos problemas podem acontecer, certo?
	Esses problemas acontecem por erros que não foram analisados e pela falta de conhecimento dos conceitos. Desse modo, podemos dizer que sistema não está normalizado.
	Agora pense: o que podemos fazer para evitar problemas futuros?
Usar a técnica de normalização para produzir sistemas estáveis e confiáveis.
Sistema Normalizado
	Agora que você já sabe o que é e como funciona a normalização de dados, vamos conhecer o que significa ter um sistema normalizado.
	Vamos lá!
	Normalizar um sistema, às vezes, significa que você terá de dividi-lo e cada divisão conterá um tipo de informação.
	A seguir, vamos dividir a normalização em quadros para comparar com as informações do sistema estruturado anteriormente, sem a divisão.
	Pedido
· Dados do pedido
· Código da empresa
· Número do pedido
· Data do pedido
Cliente
· Código do cliente
· CNPJ/CPF
· Nome do cliente
· Endereço do cliente
· Sexo
· Data de nascimento
Vendedor
· Código do vendedor
· Nome do vendedor
Item do pedido
· Código do item:
· Quantidade
· Preço unitário
Para tomar decisões e definir o que pode e como deve ser arquivado, é preciso atuar de forma ética.
Componentes do MER
	O Modelo Entidade-Relacionamento (MER) é composto pelos objetos:
· Entidades
· Relacionamentos
· Atributos.
As vantagens do Modelo Entidade-Relacionamento (MER).
Sintaxe robusta
	Documenta e organiza uma especificação de maneira clara e precisa.
Comunicação com o usuário
	Facilita a visualização do usuário, permitindo que ele entenda facilmente a forma de representação gráfica.
Facilidade no desenvolvimento
	Oferece facilidade na definição do relacionamento entre as entidades.
Definição do escopo
	Fornece uma ilustração clara do escopo do sistema.
Integração entre aplicações
	Fornece um método que torna fácil a ligação entre diferentes aplicações.
O MER prevê relacionamentos entre entidades. Por isso, para entender como esse modelo funciona, precisamos conhecer bem os conceitos de entidades e atributos. Vamos lá?
Entidades
	É a representação de um conjunto de informações em formato de tabela.
Atributos
	É a informação que referencia a entidade.
Entidade
	Entidade é um objeto que existe no mundo real, com uma identificação diferente e um significado próprio. Podemos dizer que são as coisas que existem na organização ou que descrevem o negócio em si. Se algo existe e proporciona algum interesse em manter dados sobre ele, isso caracteriza uma entidade do negócio.
Uma entidade é uma tabela no banco de dados. Quando identificamos todas as entidades, estamos definindo quais serão as tabelas que teremos de criar em nosso banco de dados.
	Cada entidade representa objeto com as mesmas características. Portanto, um banco de dados compreende um conjunto de entidades do mesmo tipo.
	Por exemplo, no banco de dados de uma organização, algumas das entidades são:
CLIENTE
FUNCIONÁRIO
FORNECEDOR
Atributos 
	Atributos são os dados armazenados em um arquivo de tabela. Também podemos chamar o atributo de campo.
	Uma tabela ou entidade é composta e representada por um conjunto de atributos ou campos. Alguns atributos são opcionais, ou seja, em alguns casos, podem não estar presentes.
	Por exemplo, Nome, Endereço, Telefone, Cidade, Salário, Cargo e Departamento são campos ou atributos que podem compor as entidades ou tabelas Cliente e Funcionário. Vejamos:
Cliente
· Nome
· Endereço
· Telefone
· Cidade
Funcionário
· Salário
· Cargo
· Departamento
Agora, vamos conhecer os tipos de atributos!
Atributos 
	Os atributos dividem-se em alguns tipos.
Composto
	O conteúdo desse atributo pode ser dividido em outros atributos, como:
· Rua
· Número
· Complemento
· Bairro
· CEP
· Cidade
Simples
	Um atributo é considerado simples, quando não há relevância ou garantias na unicidade dos dados, pois é comum encontrarmos pessoas com o mesmo nome, como Maria ou José.
	No entanto, não podemos identificar de qual Maria ou José se trata. Por este motivo, esse atributo é considerado simples.
	Para entender melhor, vamos imaginar os brasileiros sem CPF ou RG. De que maneira poderíamos controlar essas informações?
Determinante
	É recomendado que sejam usados campos como CPF, CNPJ, Código do Fornecedor, Número da Matrícula etc.
	Os atributos determinantes serão as chaves primárias no banco de dados e seu uso tem implicações diretas na normalização de dados.
Multivalorado
	Atualmente, é comum que uma pessoa tenha mais de um número de telefone.
	Desse modo, durante a normalização, esse atributo é indicado com um asterisco antes de seu nome (*Telefone).
	Outro exemplo é o campo idioma para quem tem fluência em mais de uma língua. Com isso, temos a indicação (Idioma).
Nulo
	Por exemplo, imagine que seja solicitado um valor para o atributo número-apartamento durante um cadastro. A pessoa que está realizando o cadastro mora em uma casa. Logo, apenas definiremos valores para esse campo quando a pessoa morar em um prédio.
	Outro exemplo é o multivalorado idioma. Caso uma pessoa não tenha fluência em língua alguma, não necessitamos preencher o valor desse campo. Nesse caso, é colocado um valor especial (nulo) para a representação do atributo.
	Null também pode ser utilizado quando você não sabe o valor de um atributo. Por exemplo, quando a data de nascimento de uma pessoa é desconhecida.
Derivado
	Vamos pegar como exemplo os atributos idade e data-nascimento.
	Como sabemos, podemos determinar o valor da idade de uma pessoa a partir do campo data-nascimento.
	Desse modo, a idade é chamada de atributo derivado, pois é derivada do atributo data-nascimento.
	Alguns atributos podem ser derivados de entidades relacionadas.
	Outro exemplo é o atributo número-empregados de uma entidade departamento. Esse atributo pode ser derivadoda contagem de número de empregados que trabalham em um departamento.
Chave Primária
	Vimos que os atributos determinantes são as chaves primárias do banco de dados. No entanto, ainda precisamos entender o que significa uma chave primária.
	Primeiramente, é importante especificar como as entidades e os relacionamentos são identificados.
	Conceitualmente, entidades e relacionamentos individuais são diferentes, mas, em uma perspectiva de banco de dados, a diferença entre eles precisa ser expressa em termos de seus atributos.
	Você deve estar se perguntando: “Mas, afinal, o que é uma chave primária?”.
	Vamos entender a seguir!
A chave de uma tabela é um campo ou um conjunto de campos que identifica, de forma única, cada registro. A função da chave primária é garantir a unicidade dos registros.
	Por exemplo, o cadastro dos cidadãos brasileiros tem o CPF como chave primária. Não há duas pessoas com o mesmo número de CPF. 
Única
	Não podem existir dois registros com o mesmo valor para a chave primária.
	Em outras palavras, a tabela não pode ter duas linhas com os valores da chave primária repetidos.
Universal
	A chave é universal quando existem valores para ela em todos os registros da tabela.
	Por exemplo, se usarmos o CNPJ como chave do nosso cadastro de clientes, devemos questionar:
· Os clientes serão somente pessoas jurídicas? Se a resposta for sim, devemos fazer outra pergunta: nada será vendido para pessoas físicas?
· Os clientes possuem registro na Receita Federal? Possuem CNPJ?
· Os clientes são organizações brasileiras? Organizações estrangeiras não são cadastradas no CNPJ. Como vamos tratá-las no banco de dados?
Imutável
	Como você já deve estar imaginando – e como o próprio nome diz- a chave primária imutável não muda. Isso significa que, se um valor para a chave é atribuído a um registro, esse valor não será modificado.
	Por exemplo, se um código é definido durante o cadastro de um funcionário no momento em que ele é admitido na empresa, esse número deve permanecer sem modificações durante todo o tempo que existir na tabela de funcionários.
Normalização de Sistemas
	Agora que já entendemos a normalização dos dados, vamos passar para a normalização dos sistemas.
	Para normalizar um sistema, é necessário realizar a análise de dados, para que você possa, por meio da necessidade inicial, abstrair os passos que deverão ser executados. Além do que vimos até aqui, devemos seguir um roteiro com alguns passos:
	Agora, vamos mostrar como é feita a normalização de sistemas na prática! Para começar, observe a estrutura da entidade Pedido na tabela a seguir.
· Identificação do pedido
· Número da filial
· Número do pedido
· Nome da filial
· Endereço da filial
· Código do vendedor
· Nome do vendedor
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
· Itens solicitados (10 itens por pedido)
· Código do item
· Quantidade
· Preço unitário
· Descrição
· Preço total
· Valor total do pedido
· Imposto a recolher
· Sinal
· Restante a pagar
Na sequência, veremos os 10 passos a serem seguidos para realizar a normalização de sistemas.
Normalização de Sistemas: Passo 1
Passo 1: Identificação dos Atributos Calculáveis
	Para começar, precisamos saber que os atributos calculáveis mantidos em um banco de dados podem ser fonte de problemas.
	Cada vez um dos que entram na fórmula de cálculo é modificado, esses atributos precisam ter seus valores atualizado, ou seja, a fórmula deve ser recalculada.
	Isso consome tempo de processamento do computador, tornando o desempenho do sistema pouco amigável em alguns casos.
	Desse modo, precisamos alterar a estrutura da entidade, removendo o atributo Preço total e adicionando a fórmula em outro objeto, como consulta, relatório etc.
	O preço total de um item pode ser calculado pela fórmula Preço total = quantidade x preço unitário.
Normalização de Sistemas: Passo 2
Passo 2: Normalização da Entidade ‘Pedido’
	Observe que ainda temos os atributos calculáveis:
· Valor total do pedido – é a soma dos preços totais dos itens.
· Imposto a recolher – é calculado com base no valor total do pedido.
· Restante a pagar – é calculado pela fórmula: Restante a pagar = Valor total do pedido – Sinal.
Após a normalização, a estrutura ficará assim:
· Identificação do pedido
· Número da filial
· Número do pedido
· Nome da filial
· Endereço da filial
· Código do vendedor
· Nome do vendedor
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
· Itens solicitados (10 por pedido)
· Código do item
· Quantidade
· Preço unitário
· Descrição
· Sinal
Normalização de Sistemas: Passo 3
Passo 3: Separação dos Atributos Multivalorados
	Observe que os atributos que contêm mais de um valor são outra fonte de problemas. Vamos descobrir por quê?
	Por exemplo, de acordo com a entidade Pedidos, é possível apresentar até 10 itens. Os dados que se repetem precisam ser separados em outra tabela, por exemplo, Detalhes do Pedido.
	Observe a separação na ilustração a seguir:
Normalização de Sistemas: Passo 4
Passo 4: Ligação do Item ao Pedido
	Nesse momento, você pode estar se perguntando:
· Como relacionar o item ao pedido?
· Como vou saber quais são os itens de um pedido?
· Como vou saber a qual pedido um item corresponde?
Vamos esclarecer! Após separar os itens solicitados em tabelas diferentes, é necessário vincular o item ao pedido. Para isso, devemos inserir (ou copiar( a chave primária da tabela de Pedido para a tabela de Detalhes do Pedido.
	Observe o resultado obtido a seguir:
Normalização de Sistemas: Passo 5
Passo 5: Definição da Chave das Tabelas Criadas
	Como vimos anteriormente, a chave primária é um campo ou conjunto de campos que define um registro como único. No entanto, se analisarmos a estrutura anterior, o item ainda não foi definido como único, apenas o pedido.
	Como identificar, de forma única, um item pedido dentro da tabela de Detalhes do Pedido?
	Neste caso, precisamos definir a identificação por meio dos campos Identificação do pedido e dos subcampos Número da filial e Número do pedido.
	Agora, vamos alterar a estrutura da tabela de Detalhes do Pedido para atender às chaves:
Normalização de Sistemas: Passo 6
Passo 6: Fazer com que Cada Produto Dependa da Chave
	Agora, é necessário identificar se cada atributo depende, exclusivamente, da chave de sua tabela.
	Para isso, precisamos examinar os atributos da tabela Pedido, representada na imagem. Caso seja necessário, devemos dividir essa tabela.
	Observe que uma cópia do atributo Número da filial foi mantida na tabela de Pedido.
	O atributo é mantido para controlar qual Filial realizou o pedido. Com isso, não haverá pedido sem indicação de filial. O Nome da filial e o Endereço não dependem da chave, só do número da filial.
Pedido
· Identificação do pedido
· Número da filial
· Número do pedido
· Nome da filial
· Endereço da filial
· Código do vendedor
· Nome do vendedor
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
· Sinal
Normalização de Sistemas: Passo 7
Passo 7: Criação da Tabela ‘Filial’
	Recomendamos que os atributos Nome da filial e Endereço sejam movidos da tabela de Pedido para uma nova entidade em que a chave seja exatamente o Número da filial.
	Para isso, basta criar uma nova tabela chamada Filial. Além dos atributos de chave, devemos adicionar os campos Nome da filial e Endereço da filial.
	Ao final, a estrutura apresentará o seguinte layout:
Filial
· Identificação da filial
· Número da filial
· Nome da filial
· Endereço da filial
Normalização de Sistemas: Passo 8
Passo 8: Criação da Tabela ‘Vendedor’
	Você observou que o mesmo acontece com os atributos relacionados ao vendedor? Além disso, os atributos não dependem de outro código, apenas do código do vendedor. Desse modo, devemos realizar a normalização semelhante à anterior.
	Seguindo o raciocínio da tabela de Pedido, precisamos criar uma nova tabela chamada Vendedor para armazenar seus campos.
	Em seguida, após criar a entidade, vamos mover os atributos Código do vendedor e Nome do vendedor.
	Vamos obter o seguinte resultado:
	Vendedor
· Identificaçãodo vendedor
· Código do vendedor
· Nome do vendedor 
Normalização de Sistemas: Passo 9
Passo 9: Criação da Tabela ‘Cliente’
	Após a normalização na tabela Vendedor, ainda existem campos que não dependem da chave primária da tabela de Pedido, como Nome do cliente e Endereço do cliente.
	Vamos normalizar a tabela de acordo com o procedimento utilizado nas tabelas de Filial e Vendedor vistas anteriormente. Para isso, criaremos uma entidade com o nome de Cliente e moveremos os campos relacionados a ela.
	Como o CNPJ depende da chave primária da tabela de Pedido, precisamos manter uma cópia para registrar qual cliente está realizando o pedido. Para que o controle seja confiável, vamos utilizar o atributo CNPJ.
	Vamos obter o seguinte resulto:
	Cliente
· Identificação do cliente
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
Normalização de Sistemas: Passo 10
Passo 10: Layout Após Normalização
	Tabela Pedido
· Identificação do pedido
· Número da filial
· Número do pedido
· Código do vendedor 
· CNPJ do cliente
· Sinal
Tabela Detalhes do Pedido
· Identificação do item
· Número da filial
· Número do pedido
· Código do item
· Quantidade
· Preço unitário
· Descrição
Tabela Filial
· Identificação da filial
· Número da filial
· Nome da filial
· Endereço da filial
Tabela Vendedor
· Identificação do vendedor
· Código do vendedor
· Nome do vendedor
Tabela Cliente
· Identificação do cliente
· CNPJ do cliente
· Nome do cliente
· Endereço do cliente
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	Na empresa de TI em que você trabalha como técnico, um estagiário pediu que apontasse as vantagens na utilização do MER.
	Marque V para verdadeiras vantagens e F para falsas vantagens.
								V	F
Fornecer uma ilustração clara do escopo do sistema.		X
Documentar e organizar as especificações de forma 		X
precisa.	
Trabalhar sem que haja interligações entre diferentes			X
 aplicações.
Facilitar a visualização e entendimento do usuário pela 	X
representação gráfica.
		Questão 2
	Você está estudando Modelagem de Dados e seu professor passou um exercício sobre MER.
	Selecione os termos para completar, corretamente, as definições apresentadas a seguir.
TERMOS
A	 ATRIBUTO SIMPLES recebe um valor único que é armazenado em um arquivo de tabela, muitas vezes chamados de campo.
B	ENTIDADE é um objeto que existe no mundo real, com uma identificação diferente e significado próprio.
C	RELACIONAMENTO é a forma em que as entidades se interagem, podendo ser um para um, um para muitos e muitos para muitos.
D	ATRIBUTO COMPOSTO possui um conteúdo que poderá ser dividido em outros atributos, por exemplo o endereço.
Encerramento do Tópico
	Neste tópico, você aprendeu os principais conceitos de normalização de um bando de dados, além das técnicas para organizar e normalizar um sistema.
	Agora você já sabe definir conceitos de normalização, identificar e analisar um sistema normalizado, explicar os componentes do Modelo Entidade-Relacionamento (MER), eliminar detalhes que dificultam as operações sobre os dados e minimizar as redundâncias e os consequentes riscos de inconsistências.
	Além disso, é capaz de reduzir e facilitar as manutenções, separar atributos multivalorados, aplicar chaves nas tabelas criadas e realizar ligações entre tabelas utilizando os conceitos apresentados. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Você está prestes a concluir o capítulo.
	Na tela Síntese, disponibilizamos, para facilitar seus estudos, um .pdf com resumo dos conteúdos abordados neste capítulo.
Síntese
	Navegue no mapa conceitual que sintetiza o conteúdo que acabamos de trabalhar.
CAPÍTULO 2
RELACIONAMENTO
Modelo Entidade-Relacionamento (MER)
	Neste tópico, vamos descobrir como representar as estruturas de dados da forma mais próxima ao mundo real.
	Conteúdos:
· Relacionamentos: a “alma” do banco de dados
· Atributos e entidades
· Critérios para identificar entidades
· Subentidades, entidades fracas e atributos das subentidades
· Especialização e generalização
· Nome e identificação dos relacionamentos
Ao finalizar este tópico, você será capaz de:
· Aplicar os conhecimentos na normalização de dados.
· Analisar as ligações entre tabelas.
· Interpretar a comunicação entre os dados.
· Explicar o que é MER.
· Identificar o conceito de relacionamentos.
· Mostrar quando se utilizam os atributos.
· Aplicar o conceito de dependência funcional.
MER
	No capítulo anterior, conhecemos o Modelo Entidade-Relacionamento (MER).
	Agora, vamos rever alguns conceitos e nos aprofundar um pouco mais neste assunto.
O MER tem o objetivo de representar as estruturas de dados da forma mais próxima do mundo real dos negócios.
MER é uma técnica de análise que cria e estrutura os dados a partir de identificação das entidades que são necessárias para armazenar informações.
	Como já vimos, os principais elementos utilizados por essa técnica são:
· As tabelas (entidades)
· Os relacionamentos entre as tabelas
· Os atributos (campos) das entidades e dos relacionamentos
O resultado da aplicação dessa técnica é o Modelo Entidade-Relacionamento (MER).
	O MER que representa a estrutura do banco de dados de uma videolocadora.
	É importante entender bem o funcionamento do negócio para o qual está sendo criado o MER. Nesse sentido, para levantar as informações sobre qual entidade utilizar, é necessário questionar.
Precisamos armazenar informações sobre o quê?
Relacionamentos e Atributos
	Vamos conhecer as características de relacionamentos e atributos por meio de um infográfico?
Entidades
	Vamos entender melhor o que são entidades e quais são os critérios para identificá-las?
Dependência Funcional
	O conceito de dependência funcional estabelece que todo atributo depende, unicamente, da chave da tabela.
	Vamos utilizar a entidade Cliente como exemplo. Para isso, foram relacionados alguns campos.
Número do cliente (chave)
Nome
Sexo
Endereço
Estado civil
Subentidade
	Uma tabela é considerada subentidade de outra, se a primeira tabela for um subconjunto da segunda.
	Por exemplo, imagine um clube de futebol que realiza campeonatos eventuais para seus sócios. Agora, vamos à regra!
Para ser jogador, é preciso ser sócio do clube, e a mesma regra deve ser aplicada para técnicos e árbitros.
	Refletindo sobre o problema, quais são as possíveis entidades identificadas?
	Talvez você tenha imaginado as seguintes entidades:
Entidade Jogador
						Entidade árbitro
		Entidade técnico
	
Vamos conferir se está correto?
Subentidade – exemplo
	Relembrando: a regra informava claramente que, para ser árbitro, jogador ou técnico, é necessário ser sócio do clube.
	Com isso, em nossa reflexão, as entidades árbitro, jogador e técnico são subentidades da tabela Sócio.
	Vamos ver isso em formato de esquema?
Entidade Sócio
Entidade Jogador	 Entidade árbitro 	Entidade técnico
	Por outro lado, podemos dizer que um sócio pode ser um titular ou dependente. Nesse caso, sócio titular e sócio dependente são subentidades de sócio.
Atributos das Subentidades – exemplo
	Quando definimos os atributos de uma subentidade, precisamos considerar os atributos da entidade de origem.
	No exemplo anterior, a entidade Jogador é um subconjunto da entidade Sócio, pois todos os jogadores são sócios. Desse modo, todos os atributos de sócio são também atributos de jogador.
	Isso significa que precisamos nos preocupar apenas com os atributos específicos de um jogador.
Atributos de Sócio
· Número do sócio (chave)
· Nome do sócio
· Endereço do sócio
· Data de nascimento
· Sexo
· Estado civil
Atributos de Jogador
· Número do sócio (chave)
· Equipe a que pertence
· Gols marcados
· Gols sofridos (caso seja goleiro)
· Cartões amarelos
· Cartões vermelhos
Saiba Mais!
Atributos de Jogador
É notável que todo jogador tem um nome, entretanto, o atributo nome do jogador não é necessário, pois jogador é uma subentidade de sócio e todos os atributos de sócio são atributosde jogador também.
A chave de jogador é número do sócio. Isso porque a chave de uma subentidade é sempre a chave da entidade da qual ela é derivada.
Especialização
	Para entender o que é especialização, vamos usar o exemplo do clube de futebol. Quando você examina uma entidade (Sócio) e descobre que existem subconjuntos importantes (Jogador, Árbitro e Técnico) e, a partir dela, você cria subentidades, então, você está realizando uma especialização.
Fazemos uma especialização quando existem atributos que só se aplicam a um subconjunto da entidade.
	Veja o exemplo:
Se verificarmos que Jogador, Árbitro e Técnico são subconjuntos de sócio e que existem atributos que são específicos de Jogador, Árbitro e Técnico, fazemos uma especialização, criando-se entidades. Vejamos:
Entidade Sócio
Subconjuntos = Subentidades = Especialização
Entidade jogador		Entidade árbitro	 Entidade técnico
Generalização
	A generalização é um processo que funciona no sentido contrário ao da especialização. Neste caso, ao examinarmos duas ou mais entidades, descobrimos que vários de seus atributos são comuns.
Entidade Fraca
	Você já ouviu falar em entidade fraca? Se não, vamos conhecê-la!
Entidade fraca é uma tabela cuja contém a chave de outra tabela.
	Por exemplo, a entidade Pedido tem como chave:
· Número da filial
· Número do pedido.
O número da filial faz parte da chave para torna-la única e comum com outra chave, diferenciando, apenas, o número do pedido. No entanto, o número da filial é a chave de outra entidade.
Nesse caso, dizemos que a entidade é fraca, uma vez que ela precisa usar a chave de outra entidade para tornar a sua chave única.
Nomes dos Relacionamentos
	É recomendado que os nomes definidos em um relacionamento sejam sempre uma expressão que envolva os nomes das entidades e um verbo que indique a natureza do vínculo.
	Desse modo, o formato deve ser o seguinte:
entidade verbo entidade
	Por exemplo, que nome poderíamos utilizar para o relacionamento entre sócios e títulos? Observe o raciocínio.
Sócio	 possui título	título	 pertence a sócio
			 ou
Entidade verbo entidade	entidade verbo entidade
Identificação de Relacionamento
	Vamos entender como identificamos um relacionamento?
	Quando quisermos saber se existe um relacionamento entre duas entidades, precisamos analisar duas questões:
1
Existe um vínculo entre os campos das tabelas?
2
A partir do campo de uma tabela, somos capazes de localizar um valor associado na outra entidade?
	Se a resposta for sim para algumas destas questões, está caracterizado um relacionamento.
	Vejamos um exemplo:
	Dado um produto, podemos localizar seu fornecedor?
	Resposta: Sim. Basta saber o código do produto, que é a sua chave e que deve estar relacionada com a tabela de fornecedor.
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	Você foi contratado para analisar o Modelo de entidade-relacionamento (MER) de uma empresa que comercializa celulares.
	Você diagramou o MER a seguir, de acordo com o levantamento feito com os funcionários dessa empresa.
	Ao fazer isso, verificou que a entidade:
( X ) A. Pedido foi inserida no MER, pois um cliente poderá realizar mais de um pedido.
( ) B. Vendedor foi inserida no MER, pois um pedido não necessariamente precisa de um cliente.
( ) C. Item não seria necessária, pois as informações do pedido poderiam estar dentro da entidade Pedido.
( ) D. Cliente não seria necessária, pois as informações do cliente poderiam estar dentro da entidade Pedido.
	Questão 2
	Você foi contratado para desenvolver o MER, utilizando especialização, para o cadastro de funcionários de uma empresa de transporte público. Após analisar a situação, você diagramou o MER a seguir:
	Em seu diagrama, verificamos que a entidade:
( ) A. Fiscal possui o atributo CATEGORIA_HABILITACAO.
( ) B. Secretária possui o atributo NUM_CARTEURA_MOTORISTA.
( X ) C. Funcionário possui os atributos TIPO_FUNCIONÁRIO e NOME.
( ) D. Motorista não possui atributos que caracterizam uma especialização.
Encerramento do Tópico
	Neste tópico, você aprendeu como representar as estruturas de dados da forma mais próxima ao mundo real.
	Agora você já sabe aplicar os conhecimentos na normalização de dados, analisar as ligações entre tabelas, interpretar a comunicação entre os dados e explicar o que é MER.
	Além disso, é capaz de identificar o conceito de relacionamento, mostrar quando utilizamos os atributos e aplicar o conceito de dependência funcional. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Vamos prosseguir em nossos estudos? Siga para o próximo tópico!
Cardinalidade do Relacionamento
	Neste tópico, apresentaremos ideias para elaborar novas estruturas de raciocínio a partir de diferentes técnicas de normalização. As competências e as habilidades estão relacionadas aos conceitos de cardinalidade do relacionamento.
	Conteúdos:
· Regras e restrições
· Restrição de pedido
· Cardinalidade
· Cardinalidade representando subentidades
· Relacionamentos redundantes.
Ao finalizar este tópico, você será capaz de:
· Definir regras e restrições na cardinalidade do relacionamento.
· Usar cardinalidade representando subentidades.
· Explicar relacionamentos redundantes.
Introdução
	Os relacionamentos definidos entre as entidades estão sujeitos às regras de negócio e às restrições que determinam quantos objetos podem participar de um relacionamento.
	Também podem existir regras que determinam se os objetos de uma entidade precisam, obrigatoriamente, participar do relacionamento.
	Essas regras dão origem ao que chamamos de cardinalidade do relacionamento.
	Vamos entender melhor a cardinalidade?
Cardinalidade
	Um dos princípios fundamentais sobre o relacionamento de um banco de dados relacional. Nela são definidos os graus de relação entre duas entidades ou tabelas.
Regras e Restrições
	Para entender as regras e as restrições do relacionamento, vejamos uma ilustração:
CLIENTE				PRODUTO
CLIENTE				PRODUTO
			SOLICITA	
	
	Você observou que dois clientes estão vinculados a mais de um produto?
	Você acha que o que está representado na ilustração está correto?
( X ) Sim
( ) Não
Comentário
	Sim, não existe nenhum impedimento para que um cliente solicite apenas um produto. Um cliente pode solicitar 	N (muitos) produtos. Dessa forma, a representação está correta!
Restrição de Pedido
	Agora, observou a ilustração com a tabela de Pedido:
CLIENTE			
PEDIDO
	CLIENTE 
						PEDIDO
CLIENTE				
					PEDIDO
			FAZ
	Repare que um pedido está ligado, ao mesmo tempo, a mais de um cliente. Você acha que isso é possível?
( ) Sim
( X ) Não
Comentário
	Não, isso não é possível! Um pedido pertence a, no máximo e no mínimo, um cliente, ou seja, não existirá pedido sem cliente, nem pedido relacionado a mais de um cliente.
Cardinalidade
A cardinalidade caracteriza o número mínimo ou máximo de valores de atributos associados a cada instante da entidade ou do relacionamento.
	Considere A um atributo da entidade E.
Cardinalidade – Exemplo
Exemplo 1
	Imagine um sistema de venda de produtos em que um cliente pode realizar diversos pedidos, assim como um cliente pode não realizar pedido.
	A cardinalidade que representa essa situação é a seguinte:
Exemplo 2
	Agora imagine um sistema de venda de produtos em que um pedido pertence a um e só um cliente:
	Podemos representar a cardinalidade desse relacionamento da seguinte forma:
Cardinalidade
	Por meio da análise da cardinalidade, também podemos verificar a situação dentro das entidades.
	Basta verificar, por meio das ligações, se há dados incompatíveis ou informações que podem gerar duplicidade de dados e causar inconsistência nas informações.
Símbolos
	Vimos que o Modelo Entidade-Relacionamento (MER) é um diagrama que mostra, de forma gráfica, as entidades e os vínculos entre elas.
	Além disso, também vimos que as entidades são representadas por retângulos,e os relacionamentos, por losangos, que ligam as entidades.
Modelo Entidade-Relacionamento (MER)
Entidade como subentidade de outra
	Precisamos conhecer bem esses elementos para quando tivermos de montar um diagrama. Você está preparado?
	Para desenhar o diagrama, devemos seguir alguns passos.
1
	Fazer uma lista das entidades
2
	Identificar os relacionamentos entre as entidades
3
	Estabelecer as cardinalidades {0,N}, {1,1}, {1,N}
4
	Desenhar um retângulo para cada entidade
5
	Ligar as entidades com suas subentidades
6	
	Ligar os retângulos com losangos representado os relacionamentos
7
	Indicar as cardinalidades
	
Vamos pensar a partir de um exemplo?
Identificação de Entidades e Relacionamento
	Agora, vamos elaborar o diagrama para uma videolocadora. Primeiro, precisamos fazer a lista das entidades.
CLIENTE
	PEDIDO					FORNECEDOR
				 Filme
	GÊNERO			 		 DETALHES 
							DO PEDIDO
Posicionamento das Entidades para Definição dos Relacionamentos
	Depois de identificar as entidades (tabelas), precisamos reposicioná-las para definir o relacionamento entre elas e a relação de cardinalidade.
	Tudo isso deve ser representado com os símbolos adequados.
CLIENTE				PEDIDO
				
					DETALHES
					DO PEDIDO
					FILME
FORNECEDOR
					GÊNERO
Aplicação dos Relacionamentos e dos Fluxos de Relacionamento
	Reposicionadas as entidades (tabelas), aplicamos o relacionamentos (representados por losangos) com seus respectivos fluxos de relacionamentos (linhas simples, sem setas). 
Definição das Cardinalidades
	Depois da definição dos relacionamentos e dos fluxos entre as entidades, passamos aos registros das cardinalidades, representados por indicadores nos fluxos dos relacionamentos.
As CARDINALIDADES são indicadas sobre, sob ou ao lado do fluxo de relacionamento, e entre parênteses (1,N).
	Agora, vamos analisar a cardinalidade passo a passo.
	Observe que a Cardinalidade da entidade Cliente está definida no lado aposto (ao lado da entidade Pedido).
	Assim será feito!
	Entidade de um lado e a sua Cardinalidade do outro (sentido cruzado).
Interpretando as Cardinalidades Individualmente
	Vamos aprender como devemos ler o esquema aplicando as CARDINALIDADES? Elaboramos um passo a passo para que você possa acompanhar melhor. 
	O primeiro relacionamento que estudaremos será o que está destacado:
	Cliente FAZ Pedido.
	Tipo de Relacionamento: 1 para 1 ou representação técnica – 1:1
	A leitura correta é a seguinte: 1 Cliente FAZ 1 Pedido.
	Tipo de Relacionamento: 1 para N (muitos) ou representação técnica – 1:N
	A leitura correta é a seguinte: 1 Cliente FAZ N (muitos) Pedidos.
	Tipo de Relacionamento: N (muitos) para 1 ou representação técnica – N:1
	A leitura correta é a seguinte: N (muitos) Clientes FAZEM 1 Pedido.
	Tipo de Relacionamento: N (muitos) para N (muitos) ou representação técnica – N:N
	A leitura correta é a seguinte: N (muitos) Clientes FAZEM N (muitos) Pedidos.
	O próximo relacionamento que está destacado é: Pedido GERA Detalhes do Pedido.
	Tipo de Relacionamento: 1 para 1 ou representação técnica – 1:1
1 Pedido GERA 1 Detalhes do Pedido ou
	Tipo de Relacionamento: 1 para N (muitos) ou representação técnica – 1:N
1 Pedido GERA N (muitos) Detalhes do Pedido
	Tipo de Relacionamento: N (muitos) para 1 ou representação técnica – N:1
N (muitos) Pedidos GERAM 1 Detalhe do Pedido
	Tipo de Relacionamento: N (muitos) para N (muitos) ou representação técnica – N:N
N (muitos) Pedidos GERAM N (muitos) Detalhes do Pedido
	Seguindo, teremos:
Detalhes do Pedido RECEBE Filme
	Tipo de Relacionamento: 1 para 1 ou representação técnica – 1:1
1 Detalhes do Pedido RECEBE 1 Filme
	Tipo de Relacionamento: N (muitos) para 1 ou representação técnica – N:1
N (muitos) Detalhes do Pedido RECEBEM 1 Filme.
	O próximo relacionamento será:
Fornecedor FORNECE Filme
	Tipo de Relacionamento: 1 para 1 ou representação técnica – 1:1
1 Fornecedor FORNECE 1 Filme
	Tipo de Relacionamento: 1 para N ou representação técnica – 1:N
1 Fornecedor FORNECE N (muitos) Filmes ou
	Tipo de Relacionamento: N (muitos) para 1 ou representação técnica – N:1
N (muitos) Fornecedores FORNECEM 1 Filme
	Tipo de Relacionamento: N (muitos) para N (muitos) ou representação técnica – N:N
N (muitos) Fornecedores FORNECEM N (muitos) Filmes
	E para finalizar, o último relacionamento deste esquema:
Filme RECEBE Gênero
	Tipo de Relacionamento: 1 para 1 ou representação técnica – 1:1
1 Filme RECEBE 1 Gênero
	Tipo de Relacionamento: N (muitos) para 1 ou representação técnica – N:1
N (muitos) Filmes RECEBEM 1 Gênero
Identificação de Relacionamentos Redundantes
	Você sabia que uma das funções da modelagem é eliminar a redundância de dados? Vamos fazer isso agora!
	O relacionamento entre cliente e filme indica o cliente associado a uma locação.
	Além disso, indica as locações pelas quais cada cliente é responsável.
	Será que precisamos mesmo desse relacionamento?
	Observando melhor o modelo de dados, vemos que já existem três relacionamentos que envolvem cliente e filme:
	Agora, vamos exemplificar como identificar e eliminar a redundância em um relacionamento.
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	Na empresa de TI em que trabalha, para explicar a um colega novato sobre Cardinalidade, você diagramou o seguinte relacionamento, sobre locação de filmes:
	A partir desse diagrama, você demonstrou a ele que um:
( X ) A. Cliente pode alugar vários filmes.
( ) B. Cliente pode alugar apenas um filme.
( ) C. Filme pode ser alugado apenas por um cliente.
( ) D. Filme não pode ser alugado por vários clientes.
	Questão 2
	Você está explicando, para um colega novato, o relacionamento entre os objetos de uma mesma entidade e, para isso, desenhou o seguinte diagrama:
	O diagrama expressa a ideia de:
( ) A. autodivisão: a entidade MATÉRIA é dividida automaticamente em disciplinas de pré-requisito.
( ) B. autorrestrição: a entidade MATÉRIA somente poderá se relacionar com a própria entidade
( ) C. autocontrole: a entidade MATÉRIA possui controle total sobre a entidade PRÉ-REQUISITO.
( X ) D. autorrelacionamento: a entidade MATÉRIA possui disciplinas que são pré-requisitos de outras matérias.
Encerramento do Tópico
	Neste tópico, você aprendeu a elaborar novas estruturas de raciocínio a partir de diferentes técnicas de normalização, que se relacionam aos conceitos de cardinalidade do relacionamento.
	Agora você já consegue definir regras e restrições na cardinalidade do relacionamento, sabe usar cardinalidade representando subentidades e é capaz de explicar relacionamentos redundantes. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Vamos prosseguir em nossos estudos? Siga para o próximo tópico!
Autorrelação
	Neste tópico, vamos começar a exercitar a criação de autorrelacionamentos e relacionamentos entre objetos da mesma entidade, bem como a definição do modelo de entidade de relacionamento para representá-los.
	Conteúdos:
· Relacionamento entre objetos da mesma entidade
· Autorrelacionamento
· Relacionamento binário
· Relacionamento inadequado
· Relacionamento ternário
Ao finalizar este tópico, você será capaz de:
· Explicar e identificar quando usar o autorrelacionamento.
· Descrever a funcionalidade de relacionamentos binários e ternários.
· Identificar cardinalidades dos relacionamentos binários e ternários.
Introdução
	Até agora, consideramos apenas relacionamentos que envolvem duas entidades diferentes.
	Você consegue imaginar relacionamentos que vinculam diferentes objetos de uma mesma entidade?
	Vamos conhecer os autorrelacionamentos, que representam vínculos entre objetos que fazem parte da mesma entidade.
	Após a apresentação dos conceitos, o relacionamento entre objetos da mesma entidade será explicado e ilustrado.
Relacionamento entre Objetos da mesma Entidade
	Analisar os diferentes diagramas.
Diagrama I
FUNCIONÁRIO
					CHEFIA
	
	A partir do diagrama, identificamos que:
· UmFUNCIONÁRIO é CHEFE de outro FUNCIONÁRIO
· A entidade FUNCIONÁRIO é única (independente do cargo ou função)
· Um FUNCIONÁRIO pode ser o próprio CHEFE ou outro FUNCIONÁRIO
Isso é possível porque existe um relacionamento entre as ocorrências da mesma entidade.
Diagrama II
PRODUTO
			COMPONENTES
	A partir do diagrama, identificamos que:
· Um PRODUTO é COMPONENTE de outro PRODUTO
· A entidade PRODUTO é única (independente do elemento)
· Um PRODUTO pode ser o próprio COMPONENTE ou outro PRODUTO
Isso é possível porque existe um relacionamento entre as ocorrências da mesma entidade.
Diagrama III 
PESSOA
				FILIAÇÃO
	A partir do diagrama, identificamos que:
· Uma PESSOA é PAI de outra PESSOA
· A entidade PESSOA é única (independente do grau familiar)
· Uma PESSOA pode ser o próprio PAI ou outra PESSOA
Isso é possível porque existe um relacionamento entre as ocorrências da mesma entidade.
Diagrama IV
CONSUMIDOR
				INDICA
	A partir do diagrama, identificamos que um CONSUMIDOR atual está indicando um novo CONSUMIDOR para uma determinada loja ou produto.
	Dizemos que há um relacionamento entre instâncias da mesma entidade, porém, com papéis diferentes, ou seja, um consumidor que já conhece um determinado produto indicando um novo consumidor que desconhece o produto.
Relacionamento entre Objetos da mesma Entidade – Exemplo
	Imagine que uma videolocadora está fazendo uma campanha para conseguir novos clientes por meio de indicações dos clientes atuais. Cada indicação valerá uma compensação ou um prêmio. Além disso, a videolocadora deseja vincular os novos clientes aos clientes que os indicaram. Para isso, também será preciso saber quais clientes fizeram a indicação.
	Podemos representar essa situação da seguinte forma:
	CIENTE INDICADOR				CLIENTE INDICADO
	
	Repare que os vínculos formam um relacionamento entre a entidade Cliente e ela mesma. Que nome podemos definir para esse relacionamento? Esse relacionamento pode ter o nome Cliente indica Cliente.
Autorrelacionamento
	As características do autorrelacionamento.
Representação	
	No MER, um autorrelacionamento é representado da seguinte maneira:
	Observe que as duas pontas do relacionamento terminam na entidade Cliente.
Papéis
	Quando temos um autorrelacionamento, podem surgir as seguintes dúvidas:
· Que papel representa cada extremidade?
· Quem é o cliente indicador (que indicou) e quem é o cliente indicado?
Nesse caso, devemos indicar, em cada extremidade, qual é o papel que aquele objeto está desempenhando no relacionamento.
Após a definição do nome dos papéis no modelo entidade-relacionamento, o diagrama passa a ser representado assim:
Cardinalidade
	Depois de definir os nomes dos papéis, é possível estabelecer as cardinalidades como:
· Cliente indicador (0,1) indica (0,N) Cliente indicado
(Um Cliente indicador poderá indicar zero ou mais clientes)
· Cliente indicador (0,1) indica (0,N) cliente indicado
(Um Cliente NÃO PODE (OU PODE) ser indicado por um Cliente indicador)
Depois de indicadas as cardinalidades, o modelo final ficará assim:
Tipos de Relacionamento
	Os relacionamentos também podem ser tratados como:
Binários
Inadequados
Ternários
	Analisaremos cada um deles a seguir.
Tipos de Relacionamento: binário
	Aprendemos que relacionamentos representam vínculos entre entidades.
	A maioria desses relacionamentos representa vínculos entre objetos que fazem parte de duas entidades. Tais vínculos são definidos como relacionamentos binários.
	Vamos considerar o relacionamento que pode existir no modelo de dados de uma escola:
	O relacionamento apresentado indica que um determinado professor está apto a lecionar uma ou mais matérias oferecidas pela escola. Também indica que pode haver diversos professores aptos a lecionar cada matéria.
	Por exemplo, o professor João pode estar apto para lecionar Matemática, Física e Química. A professora Maria pode estar apta a lecionar Química e Biologia. O professor José apto a lecionar apenas Matemática.
	Na mesma instituição, podemos ter o seguinte relacionamento:
	Este relacionamento indica quais são as matérias de um curso. Um curso inclui várias matérias e uma matéria pode fazer parte de vários cursos.
	Desse modo, o curso de Informática pode incluir as matérias de Tecnologia, Análise de Dados e Análise Funcional, entre outras. A matéria de Tecnologia faz parte de outros cursos, além do curso de Informática.
Tipos de Relacionamento: inadequado
	Agora, vamos considerar o relacionamento que indica que um professor foi escalado para lecionar uma determinada matéria. A solução abaixo não é uma solução adequada:
	O relacionamento apresentado indica, por exemplo, que o professor leciona matéria. No entanto, não sabemos em qual curso ele leciona a matéria.
	O relacionamento seguinte também é inadequado:
	Esse relacionamento indica, por exemplo, que o professor leciona no curso. No entanto, não podemos identificar a matéria que ele leciona.
Tipos de Relacionamento: ternário
	A solução para o problema apresentado no relacionamento inadequado é o chamado relacionamento ternário, que envolve três entidades:
Professor leciona matéria em um curso.
	Nesse tipo de relacionamento, podemos observar a associação de duas entidades: professor e curso, que dão origem a uma terceira entidade: matéria.
Exercícios de Fixação
	Agora, veja o quanto você sabe este assunto. Realize os exercícios a seguir e aproveite para fixar melhor os conceitos vistos até aqui.
	Questão 1
	Você foi contratado por uma faculdade para desenvolver o MER de um novo sistema. Após realizar o levantamento com os funcionários, você diagramou o seguinte modelo:
	Marque V para verdadeiro e F para falso, em relação às entidades do diagrama:
								V	F
PROFESSOR irá conter as chaves primárias das				X
 entidades MATÉRIA e CURSO.
CURSO irá conter as chaves primárias das entidades			X
 PROFESSOR e MATÉRIA.
MATÉRIA irá conter as chaves primárias das			X
 entidades PROFESSOR e CURSO.
LECIONA irá conter as chaves primárias das				X
 entidades CURSO, MATÉRIA e PROFESSOR.
	Questão 2
	Você foi contratado para desenvolver o MER de uma locadora de DVDs. Após levantamento com os funcionários, você diagramou o seguinte modelo:
	A análise do seu diagrama demonstra que a opção INCORRETA é:
( ) A. um filme RECEBE um ou muitos gêneros.
( ) B. um pedido GERA um detalhe do pedido que RECEBE muitos filmes.
( ) C. muitos fornecedores FORNECEM muitos filmes que RECEBEM muitos gêneros.
( X ) D. muitos clientes FAZEM muitos pedidos que GERAM somente um detalhe do pedido.
Encerramento do Tópico
	Neste tópico, você aprendeu a exercitar a criação de autorrelacionamentos e relacionamentos entre objetos da mesma entidade, bem como a forma de definição do modelo de entidade de relacionamento para representação dos relacionamentos criados.
	Agora você já sabe explicar e identificar quando usar o autorrelacionamento, consegue descrever a funcionalidade de relacionamentos binários e ternários e é capaz de identificar suas cardinalidades. Caso ainda tenha dúvidas, você pode voltar e rever o conteúdo.
	Você está prestes a concluir o capítulo, basta realizar as atividades propostas no jogo da tela a seguir.
	Na tela Síntese, disponibilizamos, para facilitar seus estudos, uma rquivo em .pdf com um resumo dos conteúdos abordados neste capítulo.
Síntese
image3.jpeg
image4.jpeg
image5.jpeg
image6.jpeg
image7.jpeg
image8.jpeg
image9.jpeg
image10.jpeg
image11.jpeg
image12.png
image13.jpeg
image14.jpeg
image15.png
image16.png
image17.png
image18.png
image19.jpeg
image20.png
image21.jpeg
image22.jpeg
image23.jpeg
image24.jpeg
image25.jpeg
image26.jpeg
image27.jpeg
image28.png
image29.png
image30.png
image31.png
image32.png
image33.png
image34.png
image35.png
image36.png
image37.png
image38.png
image39.png
image40.png
image41.png
image42.png
image43.png
image44.png
image45.png
image46.png
image47.png
image48.png
image49.png
image50.png
image51.png
image52.png
image53.png
image54.png
image55.png
image56.pngimage57.png
image58.png
image59.png
image60.png
image61.png
image62.png
image63.png
image1.jpeg
image2.jpeg

Continue navegando