Bases de Dados PDF

AGRUPAMENTO DE ESCOLAS COELHO E CASTRO
CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

Governo da República Portuguesa
APONTAMENTOS – MÓDULO 2
TIC
MÓDULO 2
GESTÃO DE BASE DE
DADOS
Data: 25/11/2014 Pág 1 de 22


TIC
ÍNDICE
ASPECTOS GENÉRICOS SOBRE BASE DE DADOS ....................................................... 3
Dos ficheiros de dados aos Sistemas de Gestão de Base de Dados - (SGBD) ................... 3
Ficheiros de Dados, Registos e Campos ......................................................................... 3
Sistema de Gestão de Base de Dados ................................................................................. 5
Funções de um S.G.B.D. ................................................................................................. 5
As tabelas como elementos fundamentais do modelo relacional ........................................ 6
Propriedades das tabelas e regras da sua constituição .................................................... 6
Exemplos de violações das regras do modelo relacional: ............................................... 7
Chaves de uma tabela.......................................................................................................... 8
Relacionamentos e chaves externas .............................................................................. 10
Preservação da integridade da informação ................................................................... 11
MODELAÇÃO DA INFORMAÇÃO E DESIGN DE UMA BASE DE DADOS .............. 15

Objetivos a atingir num projeto de Base de Dados ........................................................... 15
Fases de um projeto de criação de uma Base de Dados Relacional .................................. 16
Estratégias para a conceção de Base de Dados ................................................................. 17
Estratégia de abordagem do particular para o geral (bottom-up) - o processo de
normalização ................................................................................................................. 17
Normalização segundo Edgar Codd.............................................................................. 19
Data: 25/11/2014 Pág 2 de 22


TIC
ASPECTOS GENÉRICOS SOBRE BASE DE DADOS

DOS FICHEIROS DE DADOS AOS SISTEMAS DE GESTÃO DE BASE
DE DADOS - (SGBD)
FICHEIROS DE DADOS, REGISTOS E CAMPOS
Num sistema informático a informação é organizada fundamentalmente em ficheiros.
Estes podem ser de vários tipos. Sob o ponto de vista das bases de dados os ficheiros
podem corresponder a dois tipos bem distintos de informação:
 Programas- ficheiros que armazenam instruções, procedimentos ou rotinas

para execução em computador.
 Ficheiros de dados que correspondem a informação produzida e manipulada

pelos utilizadores, como por exemplo: documentos de texto, imagens, folhas
de cálculo.
Os ficheiros típicos de uma Base de Dados são os ficheiros de dados de um formato

específico: conjunto de campos e registos, podendo-se então concluir que uma base
de dados é um conjunto de ficheiros de dados.
Por sua vez um ficheiro é um conjunto de registos, um registo é um conjunto de

campos sendo um campo um conjunto de caracteres
Numa forma simplificada um ficheiro de Base de Dados corresponde a um arquivo de

fichas, em que cada ficha corresponde a um registo de uma entidade (pessoa,
organização, produto, etc.) e em cada registo existe um determinado conjunto de
campos de informação, correspondentes aos atributos da entidade em questão.
Data: 25/11/2014 Pág 3 de 22


TIC
Nome. Daniela Silva Nome: Rui Silva Nome: Bernardo Cruz

Endereço: Rua 23, 12 Endereço: R. Santa,12 Endereço: R. Velha, 71
CP: 4500 Espinho C.P.:4535 Sanguêdo CP: 1900 Lisboa
Telef: 721172 Telef: 915491 Telef: 996699
Nome: Jorge Santos Nome: Ana Santos

Endereço:R. 21, 89 Endereço: R. Nova,12
4500 Espinho CP :1900 Lisboa
Telef 720011 Telef: 669966
Nome Endereço C.P. Telefone

Ana Santos R Nova, 12 1900 Lisboa 669966
Bernardo Cruz R. Velha, 71 1900 Lisboa 996699
Carlos Sousa R. Boa, 13 4000 Porto 448844
Daniela Silva Rua 23, 12 4500 Espinho 721172
Rui Silva R. Santa,12 4535 Sanguedo 915491
Jorge Santos Rua 21, 89 4500 Espinho 720011
Fig. 1: Correspondência entre um arquivo de fichas de um consultório médico num

ficheiro de Base de Dados.
Data: 25/11/2014 Pág 4 de 22


TIC
SISTEMA DE GESTÃO DE BASE DE DADOS

Os SGBD são programas ou conjuntos integrados de programas que permitem criar e
manipular bases de dados, em que os dados são estruturados com independência
relativamente aos programas de aplicação que os manipulam.
Base de Dados
Fx. de Dados
Registos
Programas de
aplicação que
Campos manipulam a base de SGDD
dados
Caracteres
Bytes
Bits
FUNÇÕES DE UM S.G.B.D.
O trabalho com Bases de Dados implica diversos tipos de operações sobre os ficheiros
e os dados que eles contêm, nomeadamente:
 inserir novos registos
 procurar e visualizar um registo
 eliminar registos
 selecionar registos e/ou campos
 ordenar os registos de um ficheiro
Data: 25/11/2014 Pág 5 de 22


TIC
 juntar ou intercalar registos de ficheiros diferentes
 fazer cópias ou duplicações de ficheiros
 alterar a estrutura de campos de um ficheiro
 eliminar ficheiros
 etc.
AS TABELAS COMO ELEMENTOS FUNDAMENTAIS DO MODELO

RELACIONAL
Os elementos fundamentais de uma Base de Dados elaborada segundo o modelo
relacional são as tabelas - em que a informação é estruturada em campos e registos.
Cada tabela é designada por um nome único dentro da Base de Dados e corresponde
a uma entidade ou a um relacionamento entre entidades.
Uma tabela é definida por um conjunto de colunas, correspondentes aos campos ou

atributos de uma entidade. Cada coluna ou campo da tabela tem um nome único dentro
da tabela; mas podem existir campos com o mesmo nome em tabelas distintas.
As linhas de uma tabela correspondem aos registos ou ocorrências de entidades

concretas.
As várias linhas podem conter dados repetidos em alguns campos, mas, considerando
o conjunto de todos os campos, não podem existir linhas iguais - cada linha representa
uma entidade única ou relacionamento único entre entidades.
PROPRIEDADES DAS TABELAS E REGRAS DA SUA CONSTITUIÇÃO

As propriedades das tabelas são as seguintes:
 a ordem pela qual se dispõem as colunas (campos ou atributos) da tabela não é

importante e pode ser alterada sem que isso modifique o significado da
informação da tabela.
Data: 25/11/2014 Pág 6 de 22


TIC
 a ordem pela qual se dispõem as linhas (registos) da tabela também não é

importante e também pode ser alterada sem que isso signifique alteração da
informação.
Estas propriedades são responsáveis pela grande flexibilidade e potencialidades de

manipulação da informação que caracterizam as Base de Dados relacionais.
Para que uma tabela seja corretamente constituída deve respeitar as seguintes regras:
 não pode haver duas colunas (campos ou atributos ) com o mesmo nome; cada
coluna é identificada de modo único;
 não deve haver campos vazios: caso o valor de um campo seja desconhecido
ou não aplicável, então deve ser preenchido com um valor nulo especial; os
S.G.B.D. podem admitir campos vazios, mas em relação aos campos - chave
isso não é permitido.
 o domínio de cada atributo deve ser constituído por valores simples (que não
possam ser subdivididos em partes elementares); não é permitido incluir mais
do que um valor em cada campo por registo.
 cada linha da tabela representa uma entidade ou ocorrência única, não podendo
por isso haver registos duplicados.
EXEMPLOS DE VIOLAÇÕES DAS REGRAS DO MODELO RELACIONAL:

Nº Nome Disciplinas
101 Abel Port; Mat
201 Ana Port; Ing; Fran
Rui Ing; Mat
310 Sandra Port; Ing; Mat
Tabela 1
Data: 25/11/2014 Pág 7 de 22


TIC
Nº Nome Disciplin Disciplin

101 Abel Port
a Mat
a
201 Ana Port Ing
220 Rui Ing Mat
201 Ana Port Ing
310 Sandra Ing Mat
Tabela 2
CHAVES DE UMA TABELA
Uma das regras da constituição de tabelas no modelo relacional determina que cada
linha representa uma entidade única, não podendo por isso haver registos duplicados.
Consideremos, por exemplo, relativa aos fornecedores de uma empresa.
Fornecedor
Nome Morada Localidade Telefone

Silva Rua Nova Lisboa 6633
Nunes Rua Velha Lisboa 6699
Metalin Rua Nova Lisboa 9966
Silva Rua Este Porto 4488
Sousa Rua Oeste Porto 6699

Tabela 3
Nesta tabela, não há nenhum atributo que, por si só, seja capaz de definir de modo
unívoco cada uma das linhas da tabela; por conseguinte, nenhum deles pode
desempenhar o papel de chave.
A tabela Fornecedor está corretamente constituída, segundo as regras do modelo

relacional: não existem linhas iguais, embora haja dados repetidos.
O problema que se coloca é o seguinte:
 Algum dos atributos ou campos da tabela permite-nos identificar de modo

unívoco cada registo da tabela?
Data: 25/11/2014 Pág 8 de 22


TIC
 A resposta é negativa, uma vez que, em qualquer campo aparecem valores

repetidos.
Um atributo ou conjunto de atributos designa-se por chave quando nos permite

identificar de modo único cada entidade concreta ou registo da tabela.
O conceito de chave corresponde ao conceito de atributo identificador mas com a

seguinte diferença:
 uma chave pode ser constituída por um atributo - chave simples;
 (ou) por mais do que um atributo - chave composta ou chave concatenada.
Codforn Nome Morada Localidade Telefone

101 Silva Rua Nova Lisboa 6633
102 Nunes Rua Velha Lisboa 6699
103 Metalin Rua Nova Lisboa 9966
104 Silva Rua Este Porto 4488
105 Sousa Rua Oeste Porto 6699

Tabela 4
Foi acrescentado o campo Codforn que identifica de modo unívoco a tabela, pois
nesse campo não haverá repetições.
Todas as chaves possíveis de uma tabela ou entidade - simples ou compostas - são

designadas chaves candidatas. Entre as chaves candidatas existentes numa tabela,
uma delas será a mais indicada ou a escolhida para desempenhar o papel de chave -
essa será designada por chave primária.
Uma chave primária deve respeitar as seguintes regras:
 ser unívoca - o ou os atributos que desempenhem esse papel, por definição,

têm de ter um valor único para cada entidade concreta (registo da tabela).
 não nula - nenhum dos atributos que formam uma chave primária poderá conter
Data: 25/11/2014 Pág 9 de 22


TIC
um valor nulo em nenhum registo.
 não redundante - no caso de uma chave primária ser composta, não deve ser
incluído mais atributos do que os mínimos necessários para identificar os
registos de forma única; um atributo de uma chave composta não poderá ser
retirado dessa chave, pois se o for, o atributo ou os atributos deixam de ser
unívocos.
RELACIONAMENTOS E CHAVES EXTERNAS

A característica essencial do modelo relacional é que permite estabelecer
relacionamentos entre entidades ou tabelas. Esses relacionamentos são estabelecidos
precisamente através dos atributos ou campos que desempenham o papel de chaves
primárias nas respetivas tabelas.
Consideremos, por exemplo, as duas entidades seguintes e os respetivos atributos:
 Fornecedor (Codforn, Nome, Endereço, Telef)
 Produto (CodProd, NomeProd, Modelo)
Pretendemos que a Base de Dados nos seja capaz de dar respostas a perguntas como:
 quais os produtos fornecidos por um fornecedor x?
 quais os fornecedores que podem fornecer o produto p?
Para tal, teremos de estabelecer um relacionamento entre duas entidades. Neste caso,
temos um relacionamento do tipo vários-para-vários (ou N para N), visto que:
 cada fornecedor pode fornecer mais do que um produto;
 cada produto pode ser fornecido por mais que um fornecedor.
Para traduzir este relacionamento em tabelas, necessitamos de três tabelas: para além
das duas tabelas correspondentes às duas entidades em causa (Fornecedor e Produto),
necessitamos de uma terceira tabela, onde iremos registar as relações entre as duas
Data: 25/11/2014 Pág 10 de 22


TIC
entidades, ou seja, os produtos fornecidos por cada fornecedor.
Enquanto Fornecedor e Produto representam entidades e correspondem a tabelas de

entidades, ForneceProduto não representa propriamente uma entidade, mas
ocorrências de relacionamentos; portanto, corresponde a uma tabela de
relacionamento.
FORNECEDOR FORNECEPRODUTO PRODUTO

CodForn CodForn CodProduto
NomeForn CodProduto NomeProduto
Endereço Preço Modelo
Telef
A tabela de relacionamento deverá incluir, entre os seus campos, as chaves das tabelas
das entidades que entram no relacionamento.
Quando a chave de uma tabela é incluída como campo numa outra tabela, então do
ponto de vista desta última tabela, diz-se que se trata de uma chave externa.
Portanto, uma chave externa é um atributo que é chave primária de uma tabela e que
vai aparecer como atributo de uma outra tabela.
É fundamentalmente através da inclusão de atributos que são chaves primárias, nas

suas tabelas de origem, em outras tabelas, onde são chaves externas, que são
estabelecidos os relacionamentos entre as diferentes entidades de uma Base de Dados
Relacional.
Numa tabela de relacionamentos, a chave primária é normalmente uma chave

composta, constituída precisamente por chaves externas.
PRESERVAÇÃO DA INTEGRIDADE DA INFORMAÇÃO

A realização das operações de atualização numa Base de Dados deve decorrer para
que a informação se mantenha consistente. A manutenção da consistência ou
integridade da informação numa Base de Dados deve ser assegurada pelo SGBD ou
pelas aplicações que foram criadas a partir desse mesmo SGBD.
Data: 25/11/2014 Pág 11 de 22


TIC
Uma Base de Dados Relacional deve assegurar dois tipos de integridade:
 integridade de entidade;
 integridade referencial.
A integridade de entidade impõe que os valores dos atributos que correspondem à

chave primária de uma entidade não podem ser nulos nem iguais a outros já existentes
na tabela.
A integridade referencial impõe que um valor de uma chave externa tem

obrigatoriamente de existir como elemento da chave primária da tabela
relacionada com aquela chave externa.
Sempre que é introduzido um valor num campo que é chave externa de uma tabela, o
sistema tem de certificar-se que esse valor existe na chave primária da tabela
referenciada por aquela chave externa. Caso contrário, a Base de Dados passaria a ter
uma inconsistência ou uma falha de integridade referencial.
Por outro lado, sempre que se quiser alterar ou apagar um registo numa tabela e
acontecer que esse registo esteja relacionado com registos de outra tabela (através de
um mesmo valor na chave primária da primeira tabela e na chave externa da segunda),
então estamos perante uma outra possibilidade de violação da integridade referencial
- ficarmos com registos que referenciam um registo que deixou de existir.
Data: 25/11/2014 Pág 12 de 22


TIC
Fornecedor
CodForn Nome Localidade
101 Silva Lisboa

102 Nunes Lisboa
103 Metalin Lisboa
104 Silva Porto
105 Sousa Porto
ForneceProduto
CodForn CodProd Preço

101 T1 10
101 C1 5
102 C2 7
103 T2 15
104 T1 11
105 T2 14
106 T2 15
106 C2 10
Produto
CodProd NomeProd Modelo
T1 Torneira TX
T2 Torneira TW
C1 Cano CK
C2 Cano CJ
Figura 1
Data: 25/11/2014 Pág 13 de 22


TIC
Com base nas tabelas apresentadas na figura 7, vejamos alguns exemplos concretos,
os casos mais comuns de violação da integridade referencial:
 Na tabela ForneceProduto pretendemos introduzir um registo em que o campo

CodForn tem o valor 110. Estamos perante um caso de violação da integridade
referencial. O campo CodForn é a chave externa na tabela ForneceProduto e
chave primária da tabela Fornecedor; ora, esta última, não existe nenhum
fornecedor com o código 110; portanto, a informação que pretendíamos
introduzir tem uma falha de integridade referencial (referencia algo que não
existe na Base de Dados).
 Pretendemos eliminar um registo, na tabela Produtos, correspondente ao

produto com o código C2. Se o fizermos, o que é que deve acontecer aos
registos da tabela ForneceProduto que dizem respeito a esse produto? Se os
mantivermos, estamos a criar uma falha de integridade referencial (a tabela
ForneceProduto tem registos que referenciam produtos que não existem na
tabela Produto).
 Pretendemos alterar, na tabela Produto, o registo com o código T2 para T3.

Trata-se de uma situação semelhante à anterior, pois desaparece um valor (T2)
numa tabela (Produto), enquanto numa outra tabela (ForneceProduto),
continuam a existir registos que fazem referência a esse valor.
O SGBD ou a aplicação que estiver a gerir a Base de Dados deve estar preparado para
evitar estas situações em que a informação perde consistência ou integridade
referencial, enviando mensagens ao utilizador que lhe permitam retificar a operação.
Data: 25/11/2014 Pág 14 de 22


TIC
MODELAÇÃO DA INFORMAÇÃO E DESIGN DE UMA

BASE DE DADOS
OBJETIVOS A ATINGIR NUM PROJETO DE BASE DE DADOS
De um modo geral, qualquer projeto de Base de Dados, que se pretenda bem elaborada
bem elaborado, deve procurar atingir os seguintes objetivos gerais:
 tornar possível a inclusão de toda a informação relevante que é necessário ter

em conta na Base de Dados;
 evitar a redundância ou repetição desnecessária da informação;
 procurar assegurar a consistência e integridade da informação perante as várias

formas de utilização da Base de Dados;
 proporcionar interfaces que apresentem a informação de uma forma fácil de

compreender e manipular por parte dos utilizadores da Base de Dados;
 proporcionar formas de controlo do acesso à informação, em conformidade

com as necessidades dos diferentes tipos de utilizadores e a eventual
necessidade de privacidade da informação.
Na fase de conceção ou desenho do esquema da Base de Dados deve ter-se em conta

principalmente os dois primeiros objetivos enumerados, ou seja, conseguir-se uma
boa estrutura da Base de Dados por forma a incluir toda a informação importante e,
ao mesmo tempo, evitar a redundância dessa mesma informação.
Data: 25/11/2014 Pág 15 de 22


TIC
FASES DE UM PROJETO DE CRIAÇÃO DE UMA BASE DE DADOS

RELACIONAL
As etapas de criação de uma Base de Dados Relacional poderão variar muito,
consoante o grau de complexidade do projeto e a experiência ou estilo de trabalho de
quem efetuar essa tarefa. As etapas típicas são:
 análise da situação para recolha da informação relevante a incluir na base

de dados;
 elaboração, no papel, de um primeiro esboço da estrutura geral da Base de

Dados, descrevendo as entidades e fluxos de relações entre ela, em
correspondência com a informação anteriormente recolhida;
 definição exata de cada entidade, através da enumeração dos seus atributos,

identificação dos atributos chave, etc.;
 determinação dos relacionamentos entre as diferentes entidades;
 revisão da estrutura de entidades, atributos e relacionamento, através de um

processo de normalização, para que a informação a incluir na Base de
Dados fique corretamente estruturada, evitando redundâncias, falhas de
consistência, etc.;
 derivação das tabelas da Base de Dados a partir da estrutura de entidades e

relacionamentos a que se chegou;
 desenvolvimento do esquema da Base de Dados num SGBD:
o criação das tabelas com as respetivas estruturas de campos; definição

das chaves primárias e respetivos índices.
o estabelecimento das relações entre as tabelas;
o indicações para validações dos dados a introduzir e para assegurar a

integridade da informação.
Data: 25/11/2014 Pág 16 de 22


TIC
o etc.
 criação de programas de aplicação, com interfaces gráficos, menus de

comandos, procedimentos de rotina ou de ajuda à realização de certas
tarefas, tudo no sentido de tornar mais fácil a utilização da Base de Dados.
ESTRATÉGIAS PARA A CONCEÇÃO DE BASE DE DADOS

Existem duas estratégias ou metodologias genéricas a considerar na tarefa da
conceção do esquema de uma Base de Dados:
 estratégia de abordagem do geral para o particular (top-down): nesta

estratégia, parte-se de uma análise das entidades segundo o modelo E-R, e,
com base numa análise dos diferentes tipos de relacionamentos entre as
entidades, determinam-se as tabelas a incluir na Base de Dados;
 estratégia de abordagem do particular para o geral (bottom-up): nesta

estratégia começa-se por considerar uma ou mais tabelas que contenham os
atributos ou campos considerados necessários à representação de cada
aspeto da situação e, com base num processo de normalização da
informação determinam-se as tabelas que são necessárias para a Base de
Dados.
ESTRATÉGIA DE ABORDAGEM DO PARTICULAR PARA O GERAL (BOTTOM-UP) - O

PROCESSO DE NORMALIZAÇÃO
Edgar Codd propôs um conjunto de normas para uma boa estruturação das bases de
dados relacionais, por forma a evitar as típicas anomalias de redundância ou perda de
integridade da informação. Este conjunto de normas ou processo de normalização é
composto pelas chamadas formas normais. Inicialmente foram estabelecidas três
formas normais:
 1ª forma normal (1FN)
Data: 25/11/2014 Pág 17 de 22


TIC
Posteriormente, surgiram outras formas normais, para além daquelas:
 Forma Normal de Boyce-Codd (FNBC)
 5ª forma normal (5FN).
Um modelo de base de dados que respeite os princípios estipulados até à 3ª forma

normal pode considerar-se, na maioria dos casos, como adequadamente elaborado
para funcionar num SGBD relacional.
As formas superiores destinam-se apenas a situações mais complexas e menos

comuns.
Em geral o processo de normalização consta do seguinte:
 Definem-se as entidades com todos os atributos considerados relevantes.
 Analisam-se as relações e dependências entre os atributos de cada entidade

(tabela) e compara-se a estrutura analisada com as formas normais.
 Sempre que uma entidade ou tabela apresentar alguma característica não

conforme a uma forma normal, reestruturam-se os atributos ou separam-se
da entidade original para formar com eles uma nova entidade ou tabela.
 Repete-se o processo até que todas as entidades (tabelas) estejam na forma

normal pretendida.
Data: 25/11/2014 Pág 18 de 22


TIC
NORMALIZAÇÃO SEGUNDO EDGAR CODD

A exemplificação da teoria da normalização vai ter por base a entidade Encomenda.
A entidade pode ser representada em duas formas:
NOTA DE ENCOMENDA
Nº: _____ Data: _____

Cliente
Código: ____ Nome: ___________________________________________

Morada: ______________________________________________________
Produto
Código Nome Preço Quantidade
Total
ou
Encomenda
Nr_nota enc
Data_enc
Cod_cliente
Nome_cliente
Morada_cliente
Produto *
Cod_prod
Preco_prod
Nome_prod
Quant_enc
Total_enc
Data: 25/11/2014 Pág 19 de 22


TIC
A Primeira Forma Normal (1FN)
Uma entidade está na 1ª Forma Normal se não contém grupos repetitivos.
Por grupo repetitivo entende-se um atributo ou conjunto de atributos que se repitam

para cada ocorrência da entidade.
Na entidade acima representada existe um grupo repetitivo para cada Nº de Nota de

Encomenda, constituído por toda a informação existente em cada linha de nota de
encomenda. Ou seja, a entidade não se encontra na 1FN porque os atributos
Cod_Prod, Preco_prod, Nome_Prod e Quant constituem um grupo repetitivo, porque
sempre que na mesma entidade existe informação referente a um novo produto é
imprescindível repetir o Nr_nota_encomenda, Data_enc, Cod_cliente, Nome_cliente,
Morada _cliente e Total_enc.
Quando uma entidade não está na 1FN diz-se que está na Forma Não Normalizada.
Passagem para a 1FN

Separar a entidade em duas, Encomenda e Encomenda_produto:
Encomenda Encomenda_produto
Nr nota enc Nr nota enc
Data_enc Cod_prod
Cod_cliente Preco_prod
Nome_cliente Nome_prod
Morada_cliente Quant_enc
Total_enc
Após a decomposição é conveniente analisar cada uma das entidades obtidas, pois
pode ocorrer que alguma delas ainda não se encontre na 1FN; o que não é o caso do
exemplo apresentado.
Segunda Forma Normal (2FN)
Uma entidade está na 2FN se:
 está na 1FN;
Data: 25/11/2014 Pág 20 de 22


TIC
 e todos os atributos não chave dependem da totalidade e não de uma parte

da chave.
Continuando com o exemplo anterior, a chave da entidade Encomenda_produto

consiste na concatenação dos atributos Nr_nota_enc e Cod_Prod.
Pelo facto de Nr_nota_enc e Cod_Prod constituírem a chave significa que:
 Nr_Nota_Enc e Cod_Prod ==> Preco_prod

 Nr_Nota_Enc e Cod_Prod ==> Nome_Prod
 Nr_Nota_Enc e Cod_Prod ==> Quant_enc
Mas, se for utilizada só parte dessa chave, nomeadamente o atributo Cod_Prod,
também é possível obter:
 Cod_Prod ==>Preco_Prod
 Cod_prod ==>Nome_Prod
Conclui-se deste modo que a entidade não se encontra na 2FN, pois os seus atributos
Preço_prod e Nome_prod não dependem da totalidade da chave (Nr_nota_enc,
Cod_prod), mas só de uma parte dessa chave (Cod_prod).
Passagem para a 2FN:
Separar a entidade Linha_Enc em duas entidades, Linha_Enc e Produto:

Encomenda Encomenda_produto Produto
Nr nota enc Nr nota enc Cod_prod
Data_enc Cod_prod Preço_prod
Cod_cliente Quant_enc Nome_prod
Nome_cliente
Morada_cliente
Total_enc
As três entidades anteriores estão na 2FN.
Terceira Forma Normal (3FN)
Uma entidade está na 3FN se:
 está na 2FN;
 e todos os atributos não chave não dependerem de outros atributos não
Data: 25/11/2014 Pág 21 de 22


TIC
chave.
No exemplo anterior, tanto a entidade Enomenda_produto como a Produto estão na
3FN. Este facto explica-se deste modo:
 Relativamente à Encomenda_produto não existe nenhum atributo não

chave que permita obter o atributo Quantidade, uma vez que este é o único
atributo não chave desta entidade.
 Relativamente à entidade Produto, não é possível obter o preço de um

produto através do seu nome, nem o nome do produto através do seu preço.
No entanto, o mesmo não se pode afirmar relativamente à entidade Encomenda,

porque:
 Cod_Cliente => Nome_Cliente
 Cod_Cliente => Morada_Cliente embora o Cod_Cliente não seja chave.
Conclui-se deste modo que a entidade Encomenda não se encontra na 3FN, pois os
seus atributos Nome_cliente e Morada_cliente não dependem da chave
(Nr_nota_enc), mas sim de um outro atributo também não chave (Cod_cliente).
Passagem para a 3FN:
Separar a entidade Encomenda em duas, Encomenda e Cliente.
Encomenda Encomenda_produto Produto Cliente

Nr nota enc Nr nota enc Cod_prod Cod_cliente
Data_enc Cod_prod Preço_prod Nome_cliente
Cod_cliente Quant_enc Nome_prod Morada_cliente
Total_enc
As quatro entidades estão agora na 3FN.
Data: 25/11/2014 Pág 22 de 22

Idioma

Bases de Dados PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bases de Dados PDF

Enviado por

Direitos autorais:

Formatos disponíveis

AGRUPAMENTO DE ESCOLAS COELHO E CASTRO

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

Data: 25/11/2014 Pág 1 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

MODELAÇÃO DA INFORMAÇÃO E DESIGN DE UMA BASE DE DADOS .............. 15

Data: 25/11/2014 Pág 2 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

ASPECTOS GENÉRICOS SOBRE BASE DE DADOS

 Programas- ficheiros que armazenam instruções, procedimentos ou rotinas

 Ficheiros de dados que correspondem a informação produzida e manipulada

Os ficheiros típicos de uma Base de Dados são os ficheiros de dados de um formato

Por sua vez um ficheiro é um conjunto de registos, um registo é um conjunto de

Numa forma simplificada um ficheiro de Base de Dados corresponde a um arquivo de

Data: 25/11/2014 Pág 3 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

Nome. Daniela Silva Nome: Rui Silva Nome: Bernardo Cruz

Nome: Jorge Santos Nome: Ana Santos

Nome Endereço C.P. Telefone

Fig. 1: Correspondência entre um arquivo de fichas de um consultório médico num

Data: 25/11/2014 Pág 4 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

SISTEMA DE GESTÃO DE BASE DE DADOS

 inserir novos registos

 procurar e visualizar um registo

 selecionar registos e/ou campos

 ordenar os registos de um ficheiro

Data: 25/11/2014 Pág 5 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

 juntar ou intercalar registos de ficheiros diferentes

 fazer cópias ou duplicações de ficheiros

 alterar a estrutura de campos de um ficheiro

AS TABELAS COMO ELEMENTOS FUNDAMENTAIS DO MODELO

Uma tabela é definida por um conjunto de colunas, correspondentes aos campos ou

As linhas de uma tabela correspondem aos registos ou ocorrências de entidades

PROPRIEDADES DAS TABELAS E REGRAS DA SUA CONSTITUIÇÃO

 a ordem pela qual se dispõem as colunas (campos ou atributos) da tabela não é

Data: 25/11/2014 Pág 6 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

 a ordem pela qual se dispõem as linhas (registos) da tabela também não é

Estas propriedades são responsáveis pela grande flexibilidade e potencialidades de

EXEMPLOS DE VIOLAÇÕES DAS REGRAS DO MODELO RELACIONAL:

Data: 25/11/2014 Pág 7 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

Nº Nome Disciplin Disciplin

Consideremos, por exemplo, relativa aos fornecedores de uma empresa.

Nome Morada Localidade Telefone

Nunes Rua Velha Lisboa 6699

Metalin Rua Nova Lisboa 9966

Silva Rua Este Porto 4488

Sousa Rua Oeste Porto 6699

A tabela Fornecedor está corretamente constituída, segundo as regras do modelo

O problema que se coloca é o seguinte:

 Algum dos atributos ou campos da tabela permite-nos identificar de modo

Data: 25/11/2014 Pág 8 de 22

CURSO PROFISSIONAL DE TÉCNICO DE TURISMO

 A resposta é negativa, uma vez que, em qualquer campo aparecem valores

Um atributo ou conjunto de atributos designa-se por chave quando nos permite

O conceito de chave corresponde ao conceito de atributo identificador mas com a

 uma chave pode ser constituída por um atributo - chave simples;

 (ou) por mais do que um atributo - chave composta ou chave concatenada.

Codforn Nome Morada Localidade Telefone

102 Nunes Rua Velha Lisboa 6699