Análise da Informação Manuel Martins

(1)

Análise da Informação

Manuel Martins

(2)

MODELO DE DADOS  é uma coleção de ferramentas conceituais para descrição de dados, relacionamentos entre esses dados, semântica de dados e restrições de consistência.

BANCO DE DADOS

PRINCIPAIS MODELOS

✓MODELO BASEADO EM OBJETOS

✓MODELO BASEADO EM REGISTROS

✓MODELO DE DADOS FÍSICO

(3)

GRUPOS DE MODELO DE DADOS

MODELO BASEADO EM REGISTROS  usados na descrição de dados nos níveis conceitual e visual. Utilizado para especificar a estrutura lógica geral do Banco de Dados e para fornecer uma descrição de alto nível da implementação. Utiliza a representação de REGISTRO. Principal modelo:

MODELO RELACIONAL.

PRINCIPAIS MODELOS BASEADOS EM REGISTROS

• RELACIONAL

• HIERÁRQUICO

• REDE

(4)

✓É possível reduzir diagramas entidade-relacionamento a uma coleção de TABELAS. Para cada ENTIDADE e para cada RELACIONAMENTO, existe uma ÚNICA TABELA que é designada com o mesmo nome da ENTIDADE ou do RELACIONAMENTO correspondente.

O MODELO RELACIONAL

✓A passagem do diagrama do MER para a representação do Modelo Relacional é denominado MAPEAMENTO do MER para o RELACIONAL e é uma das técnicas mais utilizadas por ser uma ligação entre os modelos de dados mais utilizados.

(5)

✓ Um BD RELACIONAL possui apenas um tipo de construção, que é a

TABELA. Uma tabela é composta por linhas (TUPLAS) e colunas (ATRIBUTOS).

O MODELO RELACIONAL

✓ Os RELACIONAMENTOS entre os dados também são representados

ou por TABELAS, ou através da reprodução dos valores de atributos.

(6)

FORNECEDOR PRODUTO

MODELO ENTIDADE RELACIONAMENTO - MER

COD_FORN

NOME

COD_FORN

NOME

COD_PROD

PEDIDO

ENTIDADE ENTIDADE

RELACIONAMENTO

ATRIBUTOS ATRIBUTOS

PREÇO QUANTIDADE

COD_PROD

ATRIBUTOS DO RELACIONAMENTO

ATRIBUTOS DO RELACIONAMENTO ENTIDADES  FORNECEDOR - PRODUTO

RELACIONAMENTO PEDIDO

(7)

FORNECEDOR

NOME COD_FORN

PEDIDO

COD_FORN PREÇO QUANTIDADE COD_PROD PRODUTO

NOME COD_PROD

MODELO RELACIONAL  TABELAS FORNECEDOR - PRODUTO - PEDIDO

MAPEAMENTO DO MER PARA O RELACIONAL

(8)

01- Qual modelo de banco de dados representa todos seus dados em tabelas simples, mas permite que as informações possam ser combinadas e recuperadas facilmente?

A- Hierárquico

B- Orientado a objetos C- Rede

D- Relacional E- Vetorial

QUESTÕES DE PROVAS

01-D / 02-C / 03-C

02- Na terminologia do modelo relacional, os dados são considerados conjuntos de valores chamados domínios. O modelo relacional representa uma tentativa de descrever banco de dados por meio de conceitos matemáticos (álgebra relacional).

03- Um estado de um banco de dados relacional consiste no conjunto de dados desse banco de dados em um momento particular do tempo.

ESTADO = INSTÂNCIA

(9)

✓ABORDAGEM RELACIONAL  está baseada no princípio de que as informações em um BD podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas (arquivo).

✓Este princípio coloca os dados (entidades e relacionamentos) nas ESTRUTURAS mais SIMPLES de armazenar dados, que são as TABELAS.

O MODELO RELACIONAL

(10)

✓Conceito Principal  vem da teoria dos conjuntos (ÁLGEBRA RELACIONAL) atrelado à ideia de que não é relevante ao usuário saber onde, nem como os dados estão (transparência).

✓Os usuários manipulam objetos dispostos em linhas e colunas das tabelas.

✓O usuário pode lidar com estes objetos usando um conjunto de operadores e funções de alto nível da ÁLGEBRA RELACIONAL.

O MODELO RELACIONAL

OBS: Toda tabela pode ser considerada um arquivo, porém, nem todo arquivo pode ser considerado uma tabela, ou seja, um arquivo é mais restrito que uma tabela.

(11)

O MODELO RELACIONAL TERMINOLOGIA DO MODELO RELACIONAL

• TABELA É CHAMADA DE  RELAÇÃO

• LINHA DE UMA TABELA É CHAMADA DE  TUPLA

• COLUNA DE UMA TABELA É CHAMADO DE  ATRIBUTO

• O TIPO DE DADO QUE DESCREVE CADA COLUNA É CHAMADO DE  DOMÍNIO.

(12)

O MODELO RELACIONAL TERMINOLOGIA DO MODELO RELACIONAL

• TABELA = RELAÇÃO

• LINHA = TUPLA = REGISTRO

• COLUNA = ATRIBUTO = CAMPO

• TIPO DE DADO = DOMÍNIO

(13)

NOME CPF ENDEREÇO D_NASC E_CIVIL

ANA 000... RUA... 01/09/87 CASADA

JOÃO 029... AV... 25/08/70 CASADO

MARIA 039... RUA... 10/04/90 SOLTEIRA

BETH 289... RUA... 23/07/78 DIVORC

PEDRO 187... AV... 09/06/60 CASADO LÚCIA 004... RUA... 12/11/89 SOLTEIRA

TUPLA

ATRIBUTO

RELAÇÃO TABELA

DOMÍNIO DO ATRIBUTO NOME = CARACTERES DO ALFABETO DOMÍNIO DO ATRIBUTO CPF = DÍGITOS DE 0 A 9

TABELA - EXEMPLO

(14)

BANCO DE DADOS RELACIONAL (BDR)  é uma coleção de TABELAS cada qual designada por um NOME ÚNICO.

TABELA  é um conjunto não ordenado de linhas (registros). Cada linha é composta por uma conjunto de CAMPOS e cada CAMPO (coluna/atributo) é identificado por um nome único.

Em um BANCO DE DADOS RELACIONAL os dados ficam armazenados em TABELAS !

(15)

Cod_Emp ^Nome Cod_Dpto Cat_Func

E5 ^Souza D1 C5

E3 ^Santos D2 C5

E2 Silva D2 C2

E1 ^Soares D1 C1

EXEMPLO DE TABELA MODELO RELACIONAL

(16)

• Cada Tabela tem um nome ÚNICO através do qual ela é referenciada.

• Cada Tabela contém um NÚMERO FIXO de colunas

• GRAU de uma tabela  número de colunas (atributos)

• CARDINALIDADE  número de linhas (tuplas)

• NÃO existem linhas IGUAIS.

• A ORDEM das linhas é IRRELEVANTE (a identificação não é feita pela localização, mas pelo valor da CHAVE PRIMÁRIA).

• Cada COLUNA tem um NOME ÚNICO (diferente das demais)

• A ORDEM das colunas é IRRELEVANTE (a coluna é identificada pelo seu nome).

• Cada coluna contém VALORES ATÔMICOS (não são permitidos grupos de valores - normalização).

CARACTERÍSTICAS DAS TABELAS - MODELO RELACIONAL

(17)

CARACTERÍSTICAS DAS TABELAS - MODELO RELACIONAL

• Cada valor de coluna é extraído de um determinado DOMÍNIO (conjunto de valores possíveis).

• Duas ou mais colunas podem ser definidas sobre um mesmo DOMÍNIO.

• OPERAÇÕES sobre colunas diferentes exigem que as colunas pertençam ao MESMO DOMÍNIO.

• CONEXÕES entre Tabelas somente serão expressas através de valores das colunas (CHAVE ESTRANGEIRA).

(18)

01- No modelo relacional, um dos itens de maior significância é a ordem em que as tuplas encontram-se no corpo de uma relação, pois tal ordem define os mecanismos de armazenamento e o desempenho das consultas.

QUESTÕES DE PROVAS

01-E / 02-E / 03-A

02- Em um banco de dados relacional, o atributo tem a mesma funcionalidade que a entidade, sendo responsável por representar o objeto real na sua totalidade.

03- O modelo relacional se estabeleceu como o primeiro modelo de dados para aplicações comerciais. Assinale abaixo a alternativa que melhor define o conceito de Banco de Dados Relacionais.

(A) Os dados são percebidos pelo usuário como tabelas.

(B) É um sistema computadorizado de armazenamento de registros.

(C) É o mais próximo do meio de armazenamento físico.

(D) Contém informações relativas a um tipo de entidade.

(E) É o modelo mais próximo do usuário.

(19)

CHAVE  é o conceito básico para IDENTIFICAR linhas e estabelecer RELAÇÕES entre TABELAS de um Banco de Dados Relacional. É um conjunto de um ou mais CAMPOS (ATRIBUTOS) de uma Tabela.

MODELO RELACIONAL

CHAVE  é um conjunto de atributos de uma relação (tabela) que pode ser utilizado para a realização de qualquer operação que envolva atributos e valores de atributos.

(20)

MODELO RELACIONAL

BANCO DE DADOS RELACIONAL - TIPOS DE CHAVES

✓ CHAVE PRIMÁRIA

✓ CHAVE ESTRANGEIRA

✓ CHAVE CANDIDATA

✓ CHAVE ALTERNATIVA

(21)

CHAVE PRIMÁRIA  é um campo ou conjunto de campos que identifica de forma EXCLUSIVA cada registro (TUPLA).

UMA CHAVE PRIMÁRIA

• NÃO PODE TER REPETIÇÃO

• NÃO PODE SER NULA

MODELO RELACIONAL

TIPOS DE CHAVES PRIMÁRIAS

• SIMPLES  UM SÓ ATRIBUTO

• COMPOSTA  DOIS OU MAIS ATRIBUTOS OBS  SUPERCHAVE = CHAVE PRIMÁRIA

(22)

✓ CHAVE PRIMÁRIA SIMPLES (um só campo)  exemplos típicos: CPF, número do título de eleitor ou o número de matrícula de um aluno em uma universidade.

✓ CHAVE PRIMÁRIA COMPOSTA (vários campos)  utilizada em situações em que não se pode garantir a exclusividade de uma linha (registro) usando apenas um campo (atributo).

TIPOS DE CHAVES PRIMÁRIAS

(23)

Cod_Emp N_Dep Nome Tipo D_Nasc

E1 01 João Filho 12/12/91

E1 02 Maria Esposa 01/01/50

E2 01 Ana Esposa 05/11/55

E6 01 Paula Esposa 04/07/50

E6 02 José Filho 03/02/85

EXEMPLO DE CHAVE PRIMÁRIA COMPOSTA - 2 CAMPOS

Campos da Chave Primária  Cod_Emp e N_Dep TAB_DEPENDENTES

NÃO É POSSÍVEL IDENTIFICAR UM EMPREGADO DE FORMA ÚNICA APENAS PELO CAMPO Cod_Emp !

(24)

CHAVE ESTRANGEIRA  é um campo de uma tabela que é CHAVE PRIMÁRIA de OUTRA TABELA. Uma chave estrangeira pode ter REPETIÇÃO, pode ser NULA e deve ter o mesmo tipo de dado da chave primária da outra tabela. É usada para definir o relacionamento entre duas tabelas.

CHAVE ESTRANGEIRA  é um atributo ou uma combinação de atributos, cujos valores aparecem necessariamente na chave primária de uma outra tabela.

(25)

EXEMPLO DE CHAVE ESTRAGEIRA

CodDepto NomeDepto CodEmp ^Nome ^CodDepto ^CatFunc

D1 Compras E1 Soares D1 C1

D2 Engenharia E2 Silva D2 C2

D3 Vendas E3 Santos D2 C5

D4 Comercial E5 Souza D1 C5

CHAVE CHAVE CHAVE

PRIMÁRIA PRIMÁRIA ESTRANGEIRA

Tabela-01 Tabela-02

CodDepto  é CHAVE PRIMÁRIA na Tabela-01 e é CHAVE ESTRANGEIRA na Tabela-02.

Foi usada para criar um relacionamento entre as 2 tabelas.

(26)

EXEMPLO DE CHAVE ESTRANGEIRA NULA

Sócio Nome Quadra ^Tipo Instrutor ^Nome

01 Nadal Q1 Saibro I1 Guga

02 Federer Q2 Grama I2 Safin

03 Djakovic Q3 Saibro I3 Agassi

04 Murray Q4 Grama I4 Sampras

Cod_Reserva Sócio Data Quadra Instrutor

01 01 02/06 Q1 I2

02 02 04/06 Q2 I1

03 02 05/06 Q2 I3

04 03 07/06 Q3 I4

05 01 08/06 Q1

06 04 09/06 Q4 I1

TAB_SÓCIO TAB_QUADRA TAB_INSTRUTOR

CH-Primária CH-Primária CH-Primária

TAB_RESERVA

CH-ESTRG

CH-ESTRG CH-ESTRG

NULA

CHAVE ESTRANGEIRA PODE TER REPETIÇÃO PODE SER NULA

CH-PRIMÁRIA

(27)

EXEMPLO DE CHAVE ESTRANGEIRA NULA

Cod_Reserva Sócio Data Quadra Instrutor

01 01 02/06 Q1 I2

02 02 04/06 Q2 I1

03 02 05/06 Q2 I3

04 03 07/06 Q3 I4

05 01 08/06 Q1

06 04 09/06 Q4 I1

TAB_RESERVA

CH-ESTRG

CH-ESTRG CH-ESTRG

NULA

CHAVE ESTRANGEIRA PODE TER REPETIÇÃO PODE SER NULA

CH-PRIMÁRIA

OBSERVE: NA TABELA DE RESERVA  TAB_RESERVA CÓDIGO DE RESERVA - 05  CH-PRIMÁRIA DA TABELA SÓCIO - 01 (NADAL)  CH-ESTRG

DATA - 08/06

QUADRA - Q1  CH-ESTRG

INSTRUTOR  CH-ESTRG = NULA - O SÓCIO NÃO QUIS INSTRUTOR !

(28)

• Uma relação pode ter várias chaves para identificação UNÍVOCA de suas tuplas, onde cada uma é denominada de Chave CANDIDATA.

• Entre as chaves CANDIDATAS UMA é escolhida pelo DBA (durante a fase de projeto lógico) para ser suportada pelo SGBD e assim, manter a restrição de UNICIDADE.

• Esta chave escolhida é denominada de Chave PRIMÁRIA. Desta forma, uma relação NUNCA apresentará tuplas (linhas) repetidas o que significa que é possível a identificação de cada tupla (linha) separadamente.

CHAVE CANDIDATA E CHAVE ALTERNATIVA

(29)

• Entre as Chaves CANDIDATAS, aquelas NÃO ESCOLHIDAS para ser a Chave Primária são denominadas de Chaves ALTERNATIVAS e podem ser utilizadas como chaves de consultas, chaves de ordenação lógica (em consultas por formulários e/ou relatórios) ou chaves de ordenação física das relações em termos de arquivos de dados.

• As chaves que NÃO PERTENCEM aos conjunto de Chaves CANDIDATAS, ou seja, são chaves que não permitem a identificação individual das tuplas da relação, são denominadas de CHAVES SECUNDÁRIAS.

CHAVE CANDIDATA E CHAVE ALTERNATIVA

(30)

✓ CHAVE CANDIDATA  é um atributo (campo) ou grupamento de atributos que têm a propriedade de identificar UNIVOCAMENTE uma ocorrência da entidade. Uma Chave Candidata pode vir a ser uma Chave PRIMÁRIA. A Chave Candidata que não é Chave Primária também chama-se Chave ALTERNATIVA.

✓ CHAVE ALTERNATIVA  é um campo de uma tabela que pode ser utilizado também como CHAVE PRIMÁRIA. Um exemplo típico é o campo CPF, que determina univocamente uma linha em uma tabela de um Banco de Dados Relacional.

MODELO RELACIONAL

(31)

QUESTÕES DE PROVAS

02- Chave candidata é um atributo especial capaz de identificar uma instância de determinada entidade de maneira única. Assim, durante a modelagem relacional de dados, todas as chaves candidatas nas entidades em análise se tornam chaves primárias dessas entidades.

01- Chave primária para a organização de tabela é um campo ou um conjunto de campos desta tabela que identifica um único registro.

03- Chave primária é um campo, ou um conjunto de campos, que abriga valores que individualizam cada registro. Esse campo não pode repetir-se em uma mesma tabela.

01-C / 02- E / 03- C - 04- C

04- Em uma tabela de um banco de dados relacional, se uma restrição de chave primária for definida como composta de mais de uma coluna, os seus valores poderão ser duplicados em uma coluna; no entanto, cada combinação de valores de todas as colunas na definição da restrição de chave primária deve ser exclusiva.

(32)

Cod_Emp N_Dep Nome Tipo D_Nasc

E1 01 João Filho 12/12/91

E1 02 Maria Esposa 01/01/50

E2 01 Ana Esposa 05/11/55

E6 01 Paula Esposa 04/07/50

E6 02 José Filho 03/02/85

EXEMPLO DE CHAVE PRIMÁRIA COMPOSTA - 2 CAMPOS QUESTÃO - 04

Campos da Chave Primária  Cod_Emp e N_Dep TAB_DEPENDENTES

NÃO É POSSÍVEL IDENTIFICAR UM EMPREGADO DE FORMA ÚNICA APENAS PELO CAMPO Cod_Emp !

(33)

PRINCIPAIS OBJETIVOS DA NORMALIZAÇÃO:

✓ELIMINAR REDUNDÂNCIA (o mesmo dado em mais de uma tabela).

✓DIMINUIR INCONSISTÊNCIA (o mesmo dado com valores diferentes em duas tabelas).

✓Possibilitar MAIOR PERFORMANCE nas pesquisas.

✓REDUZIR a NECESSIDADE de REESTRUTURAR as relações quando novos tipos de dados são introduzidos

✓Garantir que a SEMÂNTICA dos atributos seja CLARA.

NORMALIZAÇÃO  são regras utilizadas no desenho de um banco de dados que permitem um armazenamento consistente e um eficiente acesso aos dados.

MODELO RELACIONAL

(34)

FORMAS NORMAIS  são um conjunto de REGRAS que regem o modo como ATRIBUTOS podem ser ORGANIZADOS em TABELAS. As formas normais são 5.

MODELO RELACIONAL

A 4ª (4FN) e a 5ª (5FN) formas normais são chamadas de Formas Normais de BOYCE-CODD (FNBC).

(35)

FORMAS NORMAIS

PRIMEIRA FORMA NORMAL (1FN)  uma tabela (relação) está na 1FN se:

• TODOS os seus ATRIBUTOS são ATÔMICOS (INDIVISÍVEIS)

• NÃO SÃO MULTIVALORADOS.

1FN  NÃO HÁ GRUPAMENTO e NENHUM ATRIBUTO É MULTIVALORADO.

(36)

NORMALIZAÇÃO

Aluno (NÃO 1FN)

NOME IDADE DATA_NASC DISCIPLINAS N_MATR

01/01/1900 Português, Matemática, etc

PROBLEMAS

• DATA_NASC É UM GRUPAMENTO DIA_NASC/MÊS_NASC/ANO_NASC

• DISCIPLINAS É MULTIVALORADO  PORTUGUÊS, MATEMÁTICA, etc

GRUPAMENTO MULTIVALORADO

EXEMPLO-1 (1FN) - Considere a Tabela abaixo

Para atender a 1FN:

• DATA_NASC deve ser dividido (se tornar atômico)

• Devemos criar uma NOVA TABELA para disciplinas e colocar o nome de cada disciplina em linhas separadas (univalorado)

(37)

NORMALIZAÇÃO - EXEMPLO-1 (1FN)

Aluno (NÃO 1FN)

NOME IDADE DATA_NASC DISCIPLINAS N_MATR

01/01/1900 Português, Matemática, etc

TAB_Aluno (1FN)

NOME IDADE DIA_NASC MÊS_NASC ANO_NASC N_MATR

TAB_DISCIPLINA (^1FN)

DISCIPLINA N_MATR Português

Matemática

GRUPAMENTO MULTIVALORADO

As duas tabelas (TAB_Aluno e TAB_DISCIPLINA) estão na 1FN !

(38)

ALUNOS

CodAluno Nome Endereço Disciplinas

1214 Rui Costa Rua A Português, Matemática, Física 1250 Ana Maria Rua B Latim, Português, Inglês

1356 Carla Silva Rua C Economia, Matemática, Direito

1456 Hugo Leal Rua D Português, Matemática

NORMALIZAÇÃO

A tabela (ALUNOS) NÃO OBEDECE à primeira forma normal (1FN), pois o atributo DISCIPLINAS admite conjunto de valores (MULTIVALORADO).

EXEMPLO-2 (1FN)

(39)

ALUNOS

CodAluno Nome Endereço Disciplina1 Disciplina2 Disciplina3 1214 Rui Costa Rua A Português Matemática Física

1250 Ana Maria Rua B Latim Português Inglês

1356 Carla Silva Rua C Economia Matemática Direito 1456 Hugo Leal Rua D Português Matemática

NORMALIZAÇÃO

Esta tabela AINDA NÃO OBEDECE à primeira forma normal (1FN) porque, embora todos os campos sejam atômicos, existem campos repetidos para a mesma categoria  DISCIPLINA  Disciplina1,Disciplina2 e Disciplina3 !

EXEMPLO-2 (1FN)

(40)

ALUNOS

CodAluno Nome Endereço Disciplina 1214 Rui Costa Rua A Português 1214 Rui Costa Rua A Matemática 1214 Rui Costa Rua A Física

1250 Ana Maria Rua B Latim

1250 Ana Maria Rua B Português 1250 Ana Maria Rua B Inglês

1356 Carla Silva Rua C Economia 1356 Carla Silva Rua C Matemática 1356 Carla Silva Rua C Direito

1456 Hugo Leal Rua D Português 1456 Hugo Leal Rua D Matemática

NORMALIZAÇÃO - EXEMPLO-2 (1FN)

A tabela ALUNOS AGORA está na 1FN, pois todos os atributos contêm apenas valores elementares.

Apresenta, no entanto, grande REDUNDÂNCIA de informação, que se reflete na REPETIÇÃO dos IDENTIFICADORES (CodAluno), NOMES e ENDEREÇOS dos alunos.

(41)

• PROBLEMAS DE ATUALIZAÇÃO  se o endereço de um aluno for alterado, essa alteração tem de ser feita em várias linhas da tabela, sob o risco de gerar inconsistências na Base de Dados, ou seja, valores diferentes em linhas diferentes.

• PROBLEMAS DE INSERÇÃO  com a tabela estruturada desta maneira torna-se impossível registar um aluno que não esteja matriculado em alguma disciplina, mas que precisa fazer apenas prova, sem que o atributo DISCIPLINA fique com valor nulo não obedecendo à regra de integridade de entidade.

• PROBLEMAS DE EXCLUSÃO  para excluir a matrícula de um aluno é preciso eliminar várias linhas da tabela, e perder informações sobre o aluno, como NOME e ENDEREÇO.

ALÉM DESSE INCONVENIENTE TEMOS OS SEGUINTES:

(42)

FORMAS NORMAIS

SEGUNDA FORMA NORMAL (2FN)  uma tabela está na 2FN se:

• ESTIVER na PRIMEIRA forma normal (1FN)

• TODOS os ATRIBUTOS que NÃO PERTENCEM à CHAVE, DEPENDEM DA CHAVE através de uma dependência funcional ELEMENTAR, isto é, dependem da TOTALIDADE DA CHAVE e não apenas de UM dos seus atributos isoladamente (de uma parte da chave).

(43)

NORMALIZAÇÃO - 2FN

EXEMPLO  vamos supor uma TABELA (ENCOMENDA) para registar informações sobre as ENCOMENDAS realizadas por CLIENTES e os PRODUTOS nela contidos.

ENCOMENDA (N-Encomenda ; DataEnc ; TotalEnc ;

CodCliente ; NomeCliente ; End_Cliente ; CodProduto ; Descrição ; PreçoUnitário ; Quantidade; TotalProd)

A tabela ENCOMENDA encontra-se na 1FN porque todos os campos são atômicos e não existe repetição de valores.

Obs1: N-Encomenda e CodProduto são CAMPOS CHAVE (estão sublinhados) !

Obs2: DataEnc foi considerado pelo projetista como atômico.

(44)

ENCOMENDA (N-Encomenda ; DataEnc ; TotalEnc ;

CodCliente ; NomeCliente ; End_Cliente ; CodProduto ; Descrição ; PreçoUnitário ; Quantidade; TotalProd)

O campo N-Encomenda identifica cada encomenda feita por um cliente.

• De N-Encomenda dependem: DataEnc, TotalEnc, CodCliente, NomeCliente e End_Cliente; Quantidade, TotalProd

• De CodProduto dependem: Descrição, PreçoUnitário;

A tabela ENCOMENDA NÃO SE ENCONTRA na 2FN porque existem campos que dependem de partes diferentes da chave. Alguns dependem de N-Encomenda e outros de CodProduto.

AÇÃO  DIVIDIR A TABELA ENCOMENDA - CRIA A TABELA DETALHE !

(45)

ENCOMENDA (N-Encomenda, DataEnc, TotalEnc, CodCliente, NomeCliente, End_Cliente)

DETALHE (N-Encomenda, CodProduto, Descrição, PreçoUnitário, Quantidade, TotalProd)

A tabela ENCOMENDA agora encontra-se na 2FN, pois está na 1FN e tem uma chave simples (N-Encomenda), o que implica que todos os atributos não-chave dependem só dessa chave.

A tabela DETALHE não se encontra na 2FN, porque existem alguns atributos NÃO-CHAVE que dependem funcionalmente de parte da chave. Exemplo: Descrição, PreçoUnitário  dependem só do CodProduto (ou seja, de parte da chave e não da chave inteira).

NORMALIZANDO obtêm-se as seguintes tabelas.

(46)

DETALHE (N-Encomenda, CodProduto, Descrição, PreçoUnitário, Quantidade, TotalProd)

De N-Encomenda dependem os campos: CodProduto, Quantidade e TotalProd ;

De CodProduto dependem os campos: Descrição e PreçoUnitário.

TABELA DETALHE  NÃO se encontra na 2FN ! ANÁLISE DA TABELA DETALHE

VAMOS CRIAR UMA NOVA TABELA CHAMADA PRODUTO !

(47)

NORMALIZANDO MAIS UMA VEZ OBTEMOS AS SEGUINTES TABELAS QUE SATISFAZEM A SEGUNDA FORMA NORMAL - 2FN.

DETALHE (N-Encomenda, CodProduto, Quantidade, TotalProd) PRODUTO (CodProduto, Descrição, PreçoUnitário)

COMO ESSAS 3 TABELAS ESTÃO LIGADAS (RELACIONADAS) ? OBSERVE AS SETAS !

(48)

FORMAS NORMAIS

TERCEIRA FORMA NORMAL (3FN)  uma tabela está na 3FN se:

• ESTIVER na SEGUNDA forma normal (2FN  1FN)

• NENHUM atributo NÃO-CHAVE DEPENDER funcionalmente de algum OUTRO atributo que NÃO SEJA CHAVE. Ou seja, TODOS os atributos NÃO-CHAVE dependem funcionalmente APENAS da CHAVE.

VAMOS USAR AS TABELAS DO EXEMPLO ANTERIOR !

(49)

DETALHE (N-Encomenda, CodProduto, Quantidade, TotalProd) PRODUTOS = (CodProduto, Descrição, PreçoUnitário)

TABELAS DO EXEMPLO ANTERIOR

VAMOS ANALISAR ESSAS TABELAS SEPARADAMENTE !

(50)

A CHAVE desta tabela é N-Encomenda !

TABELAS DO EXEMPLO ANTERIOR

Nesta tabela existe um grupo de atributos NÃO-CHAVE que depende de um outro atributo NÃO-CHAVE.

NomeCliente e End_Cliente  dependem funcionalmente de CodCliente (que não é CHAVE !).Deste modo, conclui-se que esta tabela NÃO SE ENCONTRA NA 3FN.

Assim, devem ser retirados da tabela ENCOMENDA os atributos que dependem de CodCliente (Nome_Clente e End_Cliente) e criar com eles uma nova tabela (CLIENTE).

(51)

CLIENTE (CodCliente, NomeCliente, End_Cliente) A tabela CLIENTE já se encontra na 3FN, pois:

• TODOS os seus atributos são atômicos (1FN)

• Tem uma chave simples o que implica que todos os atributos NÃO- CHAVE dependem da totalidade da chave (2FN)

• Os atributos NÃO-CHAVE não dependem de nenhum outro atributo NÃO-CHAVE (3FN). NomeCliente, End_Cliente só dependem de CodCliente !

TABELA CLIENTE - NOVA !

(52)

Retiramos da tabela original (ENCOMENDA) os campos NomeCliente, End_Cliente, mas deixamos o campo (atributo) CodCliente. Como nenhum campo não-chave depende de outro campo não-chave a tabela ENCOMENDA está na 3FN.

TEMOS ENTÃO AS SEGUINTES TABELAS

ENCOMENDA (N-Encomenda, DataEnc, TotalEnc, CodCliente)

CLIENTE (CodCliente, NomeCliente, End_Cliente)

Como na tabela ENCOMENDA os atributos não-chave não dependem de nenhum outro atributo não-chave, a tabela CLIENTE está na (3FN).

(53)

Entre os seus atributos não-chave (Descrição e PreçoUnitário) não existe qualquer dependência funcional, ou seja, dependem apenas da chave. Logo PRODUTOS está na 3FN.

ANÁLISE DAS OUTRAS TABELAS

DETALHE (N-Encomenda, CodProduto, Quantidade, TotalProd) PRODUTO (CodProduto, Descrição, PreçoUnitário)

Entre os seus atributos não-chave (Quantidade e TotalProd) não existe qualquer dependência funcional, ou seja, esses atributos não-chave não dependem de nenhum outro atributo não-chave. Logo a tabela DETALHE está na 3FN.

(54)

NORMALIZAÇÃO - RESULTADO FINAL APÓS AS 3 FASES ENCOMENDA (N-Encomenda ; DataEnc ; TotalEnc ;

CodCliente ; NomeCliente ; End_Cliente ; CodProduto ; Descrição ; PreçoUnitário ; Quantidade; TotalProd)

TABELA ORIGINAL

ENCOMENDA (N-Encomenda, DataEnc, TotalEnc, CodCliente)

CLIENTE (CodCliente, NomeCliente, End_Cliente)

DETALHE (N-Encomenda, CodProduto, Quantidade, TotalProd) PRODUTO (CodProduto, Descrição, PreçoUnitário)

TABELAS NORMALIZADAS  1FN / 2FN / 3FN

COMO ESSAS 4 TABELAS ESTÃO LIGADAS (RELACIONADAS) ?

(55)

ENCOMENDA N-Encomenda DataEnc

TotalEnc CodCliente

DETALHE N-Encomenda CodProduto Quantidade

TotalProd PRODUTO

CodProduto Descrição

PreçoUnitário CLIENTE

CodCliente NomeCliente End_Cliente

TABELAS NORMALIZADAS  1FN / 2FN / 3FN

CHPRIM=N-Encomenda CHESTR=CodProduto

CHPRIM=N-Encomenda CHESTR=CodCliente

CHPRIM = CodCliente

CHPRIM = CodProduto

(56)

FORMAS NORMAIS

✓ 1FN

• TODOS ATRIBUTOS SÃO ATÔMICOS

• NÃO SÃO MULTIVALORADOS.

✓ 2FN

• ESTÁ NA PRIMEIRA 1FN

• TODOS ATRIBUTOS QUE NÃO PERTENCEM À CHAVE, DEPENDEM DA TOTALIDADE CHAVE

✓ 3FN

• ESTÁ NA SEGUNDA 2FN

• TODOS OS ATRIBUTOS NÃO-CHAVE DEPENDEM APENAS DA CHAVE.

(57)

Um modelo de base de dados que respeite os princípios estipulados até à 3FN é considerado ADEQUADO para funcionar num SGBD RELACIONAL.

A 4ª e a 5ª FORMAS NORMAIS SÃO CHAMADAS Formas Normais de BOYCE-CODD (FNBC)

4ª Forma Normal (4FN) 5ª Forma Normal (5FN)

NORMALIZAÇÃO

(58)

01- Em um banco de dados relacional, a primeira forma normal requer que todos os domínios de atributos incluam somente valores simples, não divisíveis, e que todo valor de atributo em todas as tuplas tenham apenas um valor do seu domínio.

QUESTÕES DE PROVAS

01-C / 02-C / 03- C / 04- E

02- Em uma tabela na segunda forma normal, todos os atributos não chave são dependentes da chave primária.

03- O objetivo da normalização de dados durante o projeto de banco de dados é prover um armazenamento consistente, o que evita redundância de dados e anomalias de manipulação de dados.

04- Se um esquema de relação tiver mais de uma chave, serão utilizadas técnicas de normalização para eliminar as chaves excedentes.

(59)

Há um tempo em que é preciso abandonar as roupas usadas Que já têm a forma do nosso corpo E esquecer os nossos caminhos que nos levam sempre

aos mesmos lugares É o tempo da travessia E se não ousarmos fazê-la Teremos ficado ... para sempre À margem de nós mesmos...

Fernando Pessoa

(60)

Um dos principais objetivos de Banco de Dados é MANTER a INTEGRIDADE dos dados. Dizer que os dados de um BD estão ÍNTEGROS significa dizer que eles REFLETEM CORRETAMENTE a REALIDADE REPRESENTADA pelo BD e que são CONSISTENTES entre si. Para garantir a integridade dos dados o SGBD oferece o mecanismo de restrições de integridade. Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD. Em SGBD Relacionais, existem as seguintes restrições de integridade conhecidas.

RESTRIÇÕES DE INTEGRIDADE

(61)

• São REGRAS a respeito dos valores que podem ser armazenados nas relações e que devem ser sempre satisfeitas. Existem regras que são consideradas necessárias a uma base de dados relacional.

✓ RESTRIÇÃO DE INTEGRIDADE DA CHAVE

✓ RESTRIÇÃO DE INTEGRIDADE DE DOMÍNIO

✓ RESTRIÇÃO DE INTEGRIDADE DA ENTIDADE

✓ RESTRIÇÃO DE INTEGRIDADE REFERENCIAL

3 MAIS IMPORTANTES  CHAVE - ENTIDADE - REFERENCIAL !

(62)

✓ RESTRIÇÃO DE INTEGRIDADE DA CHAVE  uma chave candidata qualquer não pode ter o mesmo valor em duas tuplas distintas da mesma relação.

✓ RESTRIÇÃO DE INTEGRIDADE DA ENTIDADE  a chave primária de qualquer relação não pode ser nula em nenhuma tupla dessa relação.

✓ INTEGRIDADE DE DOMÍNIO  especifica que o valor de um atributo (campo) deve obedecer a definição de valores admitidos para a coluna (o domínio da coluna).

(63)

✓ RESTRIÇÃO DE INTEGRIDADE REFERENCIAL  a restrição de integridade referencial declara que uma tupla em uma relação, que faz referência a outra relação, deve se referir a uma tupla existente nessa relação. O conceito de Integridade Referencial depende do conceito de CHAVE ESTRANGEIRA. A INTEGRIDADE REFERENCIAL é utilizada para garantir a Integridade dos dados entre as TABELAS RELACIONADAS.

(64)

Exemplo-01  considere um relacionamento do tipo 1:N entre a tabela CLIENTES e a tabela PEDIDOS (um cliente pode fazer vários pedidos).

Com a Integridade Referencial, o BD não permite que seja cadastrado um pedido para um cliente que ainda não foi cadastrado. Em outras palavras, ao cadastrar um pedido, o BD verifica se o código do cliente que foi digitado já existe na tabela CLIENTES. Se não existir, o cadastro do pedido não será aceito.

RESTRIÇÃO DE INTEGRIDADE REFERENCIAL

Exemplo-02  um filho de um funcionário não pode ser cadastrado como dependente (TAB_DEPENDENTE) sem que o pai trabalhe na empresa (TAB_FUNCIONÁRIO).

(65)

INTEGRIDADE SEMÂNTICA - são restrições de integridade que não se encaixam na categoria básica. São também conhecidas como REGRAS DE NEGÓCIO.

Exemplo: Para possuir carteira de habilitação o funcionário deverá ser maior que 18 anos (idade >= 18 anos).

A integridade semântica garante que o dado inserido em uma linha da tabela seja um valor válido. Assim, ele deve ser do mesmo tipo de dados definido na especificação da coluna na tabela.

Exemplo: um atributo de uma determinada entidade definido como DATA só conterá dados relativos a DATA. É a certeza que no campo DATA_CONTRATACAO só terá datas válidas. Caso um SGDB permita a inserção de um outro tipo de dado diferente do definido, a integridade semântica será violada. A integridade semântica em um SGDB é aplicada com a utilização de constraints.

Constraint - é uma regra que limita o valor que pode ser inserido, modificado ou eliminado em uma tabela.

(66)

GRUPOS DE MODELO DE DADOS

MODELO BASEADO EM REGISTROS  usados na descrição de dados nos níveis conceitual e visual. Utilizado para especificar a estrutura lógica geral do Banco de Dados e para fornecer uma descrição de alto nível da implementação. Utiliza a representação de REGISTRO. Principal modelo:

MODELO RELACIONAL.

PRINCIPAIS MODELOS BASEADOS EM REGISTROS

• RELACIONAL

• HIERÁRQUICO

• REDE

(67)

✓ Cada registro é uma coleção de atributos (campos).

✓ Os registros são organizados sob a estrutura de ÁRVORE com raiz. A raiz da árvore é a origem dos dados daquela árvore.

✓ A árvore é dividida em nós, onde cada nó é um registro.

✓ Entre dois nós (registros) não pode existir outros registros.

✓ Da raiz até uma folha (nó), existe apenas um caminho.

✓ Uma base de dados hierárquica pode ter várias árvores.

✓ Exemplo simples  relação pai-filho, onde o pai é a raiz, e o filho, o nó.

✓ A raiz pode ter muitas folhas, ou seja, o pai pode ter muitos filhos, mas um filho não pode ter vários pais.

✓ Se a relação hierárquica é quebrada tem-se um BD de REDE.

MODELO HIERÁRQUICO

(68)

DEPARTAMENTO

PESSOAL FINANCEIRO FINANCEIRO

011 ANTÔNIO 014 JOSÉ

023 BENTO 025 ALDO 030 BETH 032 HILDA

BANCO DE DADOS HIERÁRQUICO

(69)

✓A organização é semelhante a dos bancos de dados hierárquicos.

✓DIFERENÇA  no hierárquico cada registro filho pode ter apenas um registro

pai, no MODELO DE REDE, UM REGISTRO FILHO PODE TER VÁRIOS REGISTROS PAI, permitindo criar conexões mais complexas.

✓Exemplo: um BD representando o relacionamento conta-cliente de um

sistema bancário. Uma conta (filho) pode pertencer a mais de um cliente (pai).

✓A associação entre conta e cliente é chamada de LINK.

MODELO DE REDE

(70)

MODELO HIERÁRQUICO UM PAI !

MODELO EM REDE VÁRIOS PAIS ! DIAGRAMAS - HIERÁRQUICO x REDE

(71)

✓BANCO DE DADOS DISTRIBUÍDO  é uma coleção de várias Bases de Dados logicamente inter-relacionadas, distribuídas por uma REDE DE COMPUTADORES.

BANCO DE DADOS DISTRIBUÍDO - BDD

✓HOMOGÊNEOS  são compostos pelos mesmos bancos de dados.

✓HETEROGÊNEOS  são compostos por mais de um tipo de banco de dados. Esses dois tipos podem ser encontrados ao longo dos nós do sistema de BDD's.

TIPOS DE BANCO DE DADOS DISTRIBUÍDOS OUTROS TIPOS DE BANCOS DE DADOS

(72)

BANCO DE DADOS DISTRIBUÍDO - BDD

✓REPLICADOS  Quando os dados se encontram REPLICADOS, existe uma CÓPIA de cada um dos dados em cada nó, tornando as bases iguais (ex:

tabela de produtos de uma grande loja).

✓FRAGMENTADOS  os dados se encontram DIVIDIDOS ao longo do sistema, ou seja, em cada nó existe uma base de dados DIFERENTE se olharmos de uma forma LOCAL. No entanto, se analisarmos de uma forma GLOBAL os dados são vistos de uma forma ÚNICA, pois cada nó possui um catálogo que contém cada informação dos dados dos bancos adjacentes

Num banco de dados distribuído os arquivos podem estar REPLICADOS ou FRAGMENTADOS.

(73)

01- Em um banco de dados relacional, garante-se que determinado valor que aparece em uma relação para dado conjunto de atributos também apareça em um conjunto de atributos de outra relação por meio da:

A chave primária.

B chave candidata.

C integridade de domínio.

D integridade referencial.

E chave assimétrica.

QUESTÕES DE PROVAS

01-D / 02-C / 03-E

02- Integridade referencial baseia-se na ligação das informações das chaves estrangeiras com as chaves primárias, ou candidatas a primárias, da tabela de referência.

03- Na utilização de um banco de dados relacional, cabe exclusivamente ao sistema gerenciador de banco de dados (SGBD) o controle das restrições de integridade dos dados.