Modelagem de Dados

Prévia do material em texto

Modelagem de Dados
Introdução à Modelagem de Dados
Modelagem de Dados
	É uma técnica aplicada durante o desenvolvimento de um sistema para o computador, planejando cada etapa com atenção especial ao projeto de estruturação do banco de dados, cujo o objetivo é transformar uma idéia conceitual em algo que possa ser traduzidos em termos computacionais.
	Com a Modelagem de Dados de Dados é possível refinar um modelo conceitual durante as fases que compõem o projeto, eliminando redundância oi incoerência que possam inevitavelmente surgir.
Níveis de Abstração
Também podemos representá-lo assim:
MINIMUNDO
Levantamento e análise das necessidades
Projeto Conceitual
Projeto Lógico do Banco de Dados
Projeto Físico do Banco de Dados
Requisitos do banco de dados
Esquema conceitual num modelo de dados
 (Descrição dos dados e as operações que serão feitas )
Esquema Lógico 
(Diagrama de Entidade e Relacionamento,
Modelo Entidade-Relacionamento)
Especificação de transações e rotinas
(Dicionário de Dados)
Vamos dar início ao Projeto Conceitual
Definição das Entidades e seus atributos
Entidade
	Podemos definir entidade como um objeto do mundo real que possui atributos capazes de torná-lo identificável e tem existência independente.
	Essa existência pode ser física (pessoas, casa, relógio, computadores, funcionários, etc) ou apenas conceitual (serviço, disciplina escolar, consulta médica, etc).
	As entidades vão dar origem as tabelas do banco de dados.
Atributos
	São todos os dados que podemos guardar de uma entidade, ou seja, uma entidade possui uma ou mais propriedades capazes de descrevê-las.
	Por exemplo: a entidade CLIENTE possui como principais propriedades Nome, Endereço, Bairro, Cidade, Estado, CEP, RG, CPF, Telefone. Essas propriedades são importantes para que seja possível identificar um cliente. A essas propriedades dá-se o nome de Atributos.
	Os atributos vão dar origem aos campos das tabelas do banco de dados.
Exemplos de entidades com seus atributos
Cadastro do Aluno
Entidade: 
		Aluno
Atributos:
		Registro de Matrícula 
		Nome do aluno
		Data de Nascimento
		RG
		CPF
		Telefone
		Endereço
		Bairro
		Cidade
		CEP 	
Cadastro do Paciente
Entidade: 
		Paciente
Atributos:
		Código do paciente 
		Nome do paciente
		Endereço
		CPF
		RG
		Telefone
		Data de Nascimento
		Código do Convênio
		Código do Conveniado
		Sexo
		Estado Civil
Chave primária ou (PK - Primary Key)
	Uma chave primária é um atributo da tabela que permite identificar seus registros de forma única. Ela tem por função ainda aplicar uma ordenação automática aos registros, um vez que seu funcionamento é similar ao de um índice. 
	Uma chave primária evita que tenhamos registro duplicados, ou seja, não é possível ter dois ou mais registro contendo os mesmos valores nos campos que a compõem. 
	Exemplo:
	RM(PK)	Nome_aluno	Dat_Nasc	RG
	001		André Silva	11/09/79	29.000.000-X
	002		André Silva	21/07/76	25.000.000-5
	003		Carla Motta	11/09/79	28.000.000-3	
Ao definir um campo como chave primária, considere:
Não é permitido duplicidade de valores ou nulos (informações desconhecidas). 
Caso não exista um identificador único para uma determinada tabela, pode-se usar um campo que numere os registros seqüencialmente. 
Pode-se utilizar o valor deste campo para encontrar registros. 
O tamanho da chave primária afeta a velocidade das operações, portanto, para um melhor desempenho, devemos utilizar o menor tamanho que acomode os valores necessários que serão armazenados no campo.
OBS.: Nem toda tabela possui chave primária.
Identificação da chave primária em cada cadastro
Cadastro do Aluno
Entidade: 
		Aluno
Atributos:
		Registro de Matrícula (PK) 
		Nome do aluno
		Data de Nascimento
		RG
		CPF
		Telefone
		Endereço
		Bairro
		Cidade
		CEP 	
Cadastro do Paciente
Entidade: 
		Paciente
Atributos:
		Código do paciente (PK)
		Nome do paciente
		Endereço
		CPF
		RG
		Telefone
		Data de Nascimento
		Código do Convênio
		Código do Conveniado
		Sexo
		Estado Civil
Não esqueçam!
	Para uma utilização eficiente de bancos de dados como o Microsoft Access, SQL Server, ORACLE, DB2 ou qualquer outro banco de dados relacional, é importante o conhecimento e correto entendimento dos conceitos de entidades e atributos.
	Entidade: irá originar uma tabela no banco de dados e é formado por um conjunto de atributos.
	Atributo: irá originar os campos de uma tabela e é cada propriedade que identifica a entidade.
	Chave primária: define atributo com único e não permitirá duplicidade de registro neste campo.
Exercício para fixação dos conceitos Entidades e Atributos
Crie no seu caderno as entidades e atributos para cada situação apresentada abaixo, representa também a chave primária e justifique sua escolha:
Cadastro de produtos; (exemplo papelaria)
Cadastro de funcionário; (exemplo escola)
Cadastro de fornecedores; (exemplo tecido)
Cadastro de departamentos; (exemplo empresa)
Identifique dentre as palavras abaixo quais são as entidades (com no mínimo dois atributos) e seus possíveis atributos, identifique caso houver a chave primária:
		ConsultaMédica 		Nome		Duração			Data			Gênero 		Ator			Horário			Filme		Editora			Livro			Diretor		Autor
		Paciente
Modelagem de Dados
Níveis de Abstração
Também podemos representá-lo assim:
MINIMUNDO
Levantamento e análise das necessidades
Projeto Conceitual
Projeto Lógico do Banco de Dados
Projeto Físico do Banco de Dados
Requisitos do banco de dados
Esquema conceitual num modelo de dados
 (Descrição dos dados e as operações que serão feitas )
Esquema Lógico 
(Diagrama de Entidade e Relacionamento,
Modelo Entidade-Relacionamento)
Especificação de transações e rotinas
(Dicionário de Dados)
Conceitos que serão utilizados nesta aula
Entidade
Atributos
Chaves
Eventos ou Relacionamentos
Cardinalidade
Conceito de Chaves
Chave primária: (PK - Primary Key) é a chave que identifica cada registro dando-lhe unicidade. A chave primária nunca se repetirá. 
Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um relacionamento com a chave primária de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave primária seja composta na origem, a chave estrangeira também o será. 
Relacionamentos ou eventos
Um banco de dados é composto por diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, é necessário existir uma interligação entre as tabelas, essa interligação é chamada de RELACIONAMENTO ou EVENTO.
Portanto os relacionamentos expressam de que maneira as entidades deverão trocar informações entre elas.
Cada tabela será relacionada com outra tabela a partir dos campos chaves.
Cardinalidade
Os relacionamentos entre as tabelas tem número de ocorrências diferentes uns dos outro que é representado através de sua cardinalidade que podem ser classificada como:
Um para Um 		(1 – 1)
Um para Vários 	(1 – N)
Vários para Vários	(N – N)
Der 
Diagrama de Entidade e Relacionamento
	O Diagrama de Entidade e Relacionamento é a ferramenta utilizada para demonstrar graficamente todas as entidades que farão parte da solução de banco de dados desenvolvida e/ou projetada, bem como os relacionamentos entre elas, apontando suas cardinalidades em detalhes.
Modelo de Dados
Símbolos para a criação do DER
MER 
Modelo Entidade-Relacionamento
	Representação detalhada dos campos de cada tabela, qual o campo Chave Primária (PK) e Chave Estrangeira (FK), os relacionamentos entre as tabelas, bem como as cardinalidades existentes.
Exemplo 1:
Diagrama de Entidade e Relacionamento
Modelo Entidade-Relacionamento
Departamentos
Cod_Depto(PK)
Nome_Depto
Atribuicao_Depto
Chefe_Depto
Funcionarios
Cod_Func(PK)
Nome_Func
RG_Func
CPF_Func
Fone_Func
End_Func
Cod_Depto(FK)
1
N
Exemplo 2: 
Diagrama de Entidade e Relacionamento
Modelo Entidade-Relacionamento
Departamentos
Cod_Depto(PK)
Nome_Depto
Atribuicao_Depto
Chefe_Depto(FK)
Funcionarios
Cod_Func(PK)
Nome_Func
RG_Func
CPF_FuncFone_Func
End_Func
Cod_Depto
1
1
Exemplo 3: Diagrama de Entidade e Relacionamento
Modelo Entidade-Relacionamento
Sempre que existir um relacionamento com cardinalidade N-N, será necessário a criação de uma nova tabela para esse relacionamento
Disciplinas
Sigla_Disc(PK)
Nome_Disc
Bases_Disc
Conteudo_Disc
CargaHora_Disc
Alunos
RM_Aluno(PK) Nome_Aluno 
DtaNasc_Aluno
RG_Aluno
CPF_Aluno
Fone_Aluno End_Aluno
Bairro_Aluno
Cidade_Aluno
CEP_Aluno
1
1
Matricula
Cod_Mat(PK)
Data_Mat
Sigla_Disc(FK)
RM_Aluno(FK)
N
N
Exercícios
Em seu caderno elabore o MER (Modelo Entidade-Relacionamento) que represente as entidades, os atributos, os campos chaves (primária e estrangeira), identificando as cardinalidades de cada Diagrama de Entidade e Relacionamento abaixo:
Motorista
Licença
Renova
Cliente
Produto
Compra
Crie o DER e o MER de cada situação, fazendo o teste de mesa para confirmar a cardinalidade definida.
	Cliente efetua locação de produtos
	Condomínio disponibiliza uma vaga de garagem.
	Funcionário recebe premiação
	A sala de aula tem lotação de alunos
Defina o DER e o MER do seguinte estudo de caso:
Em uma visita a uma administradora de imóveis (Imobiliária) foram levantadas as seguintes informações:
A imobiliária administra condomínios formados por propriedades;
Cada propriedade é de uma ou mais pessoas. Uma pessoa pode possuir diversas propriedades;
 cada propriedade pode estar alugada para no máximo uma pessoa. Uma pessoa pode alugar diversas propriedades.
Bom trabalho!
Normalização
O objetivo da normalização é evitar os problemas provocados por falhas no Projeto do Banco de Dados, bem como eliminar a "mistura de assuntos" e as correspondentes repetições desnecessárias de dados. 
Qual o objetivo da normalização?
	Uma Regra de Ouro que devemos observar quando criamos um Projeto de um Banco de Dados baseado no Modelo Relacional de Dados é a de "não Misturar assuntos em uma mesma Tabela". 
	Por exemplo na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetição desnecessária bem como inconsistência dos dados. 
Para que normalizar?
	O Processo de Normalização aplica uma série de Regras sobre as Tabelas de um Banco de Dados, para verificar se estas estão corretamente projetadas. Embora existam 5 formas normais, na prática usamos um conjunto de 3 Formas Normais. 
	Normalmente após a aplicação das Regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do que originalmente existia. 
	Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manutenção
Regras da Normalização
	Cliente		
	Codigo(PK)	Nome	Telefone
	123	Rachel Soares	555-861-2025
	456	James Borges	555-403-1659
555-776-4100
	789	Maria Fernandez	555-808-9633
Tabela não normalizada (ÑN)
	“Uma Tabela está na Primeira Forma Normal quando seus atributos não contém grupos de Repetição".
Resumo dos Procedimentos:
Identificar a chave primária da entidade;
Identificar o grupo repetitivo e excluí-lo da entidade;
Criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo.
Primeira Forma Normal: (1FN)
Tabelas na 1FN
	Cliente	
	Codigo(PK)	Nome
	123	Rachel Soares
	456	James Borges
	789	Maria Fernandez
	Telefone	
	Codigo(FK)	Telefone
	123	555-861-2025
	456	555-403-1659
	456	555-776-4100
	789	555-808-9633
	“Ocorre quando a chave Primária é composta por mais de um campo. Neste caso, devemos observar se todos os campos que não fazem parte da chave dependem de todos os campos que compõem a chave. Se algum campo depender somente de parte da chave composta, então este campo deve pertencer a outra tabela”. 
Resumo dos Procedimentos:
Identificar os atributos que não são funcionalmente dependentes de toda a chave primária.
Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles.
A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.
Segunda Forma Normal: (2FN)
	Cursos			
	Numero_Matricula	Cod_Curso	Avaliação	Descricao_Curso
	001	201	15/03	Word Avançado
	010	201	15/03	Word Avançado
	101	210	15/03	Excel Avançado
	(PK)			
Tabela com chave composta – Não está na 2FN
Chave primária Composta: Numero_Matricula, Cod_Curso
	Avaliação		
	Numero_Matricula	Cod_Curso	Avaliação
	001	201	15/03
	010	201	15/03
	101	210	15/03
	(PK)		
Tabelas na 2FN
	Curso	
	Cod_Curso(PK)	Descricao_Curso
	201	Word Avançado
	210	Excel Avançado
Chave primária Composta: Numero_Matricula, Cod_Curso
	“Na definição dos campos de uma entidade podem ocorrer casos em que um campo não seja dependente diretamente da chave primária ou de parte dela, mas sim dependente de um outro campo da tabela, campo este que não a Chave Primária”. 
Resumo dos Procedimentos:
Identificar todos os atributos que são funcionalmente dependentes de outros atributos “não chave”;
Removê-los e criar uma nova entidade com os mesmos.
A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.
Terceira Forma Normal: (3FN) 
Tabela na 2FN que não atende a 3FN
	Vencedores de Torneios			
	Torneio	Ano	Vencedor	Data de nasc. do vencedor
	Indiana Invitational	1998	Al Fredrickson	21/7/1975
	Cleveland Open	1999	Bob Albertson	28/9/1968
	Des Moines Masters	1999	Al Fredrickson	21/7/1975
	Indiana Invitational	1999	Chip Masterson	14/3/1977
	( PK)			
Chave primária Composta: Torneio, Ano
41
Tabelas na 3FN
	Vencedores de Torneios		
	Torneio	Ano	Vencedor
	Indiana Invitational	1998	Al Fredrickson
	Cleveland Open	1999	Bob Albertson
	Des Moines Masters	1999	Al Fredrickson
	Indiana Invitational	1999	Chip Masterson
			
	 (PK)		
	Datas de nasc. de jogadores	
	Jogador	Data de nascimento
	Chip Masterson	14/3/1977
	Al Fredrickson	21/7/1975
	Bob Albertson	28/9/1968
Chave primária Composta: Torneio, Ano
	Após a normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema.
	Projetar o banco de dados significa criar um MER (Modelo Entidade x Relacionamentos) onde são indicadas quais tabelas farão parte do banco de dados, quais os campos de cada tabela, qual o campo que será a Chave Primária (PK) nas tabelas que terão Chave Primária e quais tabelas terão o campo chave estrangeira (FK) (normalizar) e quais os relacionamentos (impor cardinalidade) entre as tabelas.
Resultados esperados após a Normalização
Exemplo de M.E.R.
Nota: Os campos que aparecem em negrito representam a Chave Primária de cada tabela.