Conceitos genéricos sobre bases de dados

Os sistemas de ficheiros Todos os sistemas operativos criam um sistema de ficheiros, cuja finalidade é identificar as várias unidades lógicas de armazenamento da informação e criar um sistema hierárquico de directórios e ficheiros. Podemos ter, por exemplo, 3 unidades lógicas (C:, D: e E:) e apenas 2 unidades físicas (2 discos)… É desta forma que o SO cria, perante os olhos do utilizador, uma máquina virtual que pode não ter uma correspondência directa com os dispositivos físicos de hardware efectivamente instalados.

O sistema hierárquico de directórios e ficheiros Em cada unidade lógica existe uma zona principal de armazenamento – raiz – onde podem ser armazenados ficheiros e outros directórios. Ficheiro – conjunto de bytes que o SO identifica e trata como uma unidade, atribuindo-lhe um nome. Podem ser ficheiros de dados ou ficheiros executáveis. Para o SO isso não importa. Directório – área de armazenamento na qual podem ser guardados ficheiros e directórios. ÁRVORE HIERÁRQUICA (invertida uma vez que no topo é que se encontra a raíz)

As aplicações e o ficheiros O SO é responsável pela criação de um sistema de ficheiros. Num sistema de ficheiros cada aplicação é responsável pela criação e pela manutenção da estrutura interna dos seus ficheiros. Cada tipo de ficheiro possui a sua própria estrutura. Os ficheiros criados a partir do Word possuem uma estrutura diferente dos criados no Paint! O SO é o mesmo  o sistema de ficheiros utilizado é o mesmo!

Os sistemas de Bases de Dados Num sistema de bases de dados existe um sistema de software situado entre as aplicações e os dados, a que se dá o nome de SISTEMA DE GESTÃO DE BASES DE DADOS (SGBD). A finalidade fundamental dum SGBD consiste em isolar as aplicações e os dados, proporcionando uma visão lógica da organização da informação. E é esta visão lógica que constitui o modelo conceptual da base de dados.

Base de dados - BD O que é? Uma BD é um simples repositório de informação, relacionado com um determinado assunto ou finalidade, armazenada em computador em forma de ficheiros. Para que serve? Serve para gerir vastos conjuntos de informação de modo a facilitar a organização, manutenção e pesquisa de dados.

Vantagens das Bases de Dados Vantagens básicas sobre os modelos tradicionais: Compacidade – evita os tradicionais volumosos conjuntos de papeis Rentabilidade – a manutenção da informação em papel é um trabalho bastante mais penoso Velocidade – o computador consegue manusear grandes quantidades de informação num curto espaço de tempo Correcção – a informação tende a ser mais actual, correcta e precisa

Organizar a informação numa BD Campo – conjunto de bytes que correspondem a uma informação elementar sobre uma entidade ou um acontecimento. Registo – conjunto de campos relacionados com a mesma entidade ou acontecimento. Nome Morada Telefone Data nasc. Sexo João Porto 227899765 03-01-78 M Ana Almada 938567544 13-12-79 F Carla Sintra 917865430 19-09-80 registo campo

Desvantagem das BDs monotabela Cliente Endereço Telefone Produto Preço Quantidade Silva Porto 123 Alicate 0,50 € 5 Martelo 0,75 € 10 Costa Aveiro 444 Marques Lisboa 555 Serra 1,00 € 14 Existe informação repetida!!!

Desvantagem das BDs monotabela: solução… Tabela Clientes: Tabela Produtos: Id Nome Endereço Telefone 1 Silva Porto 123 2 Costa Aveiro 444 3 Marques Lisboa 555 Id Nome Preço 1 Martelo 0,75 € 2 Alicate 0,50 € 3 Serra 1,00 € Tabela Encomendas: IdCli. IdProd. Quant. 1 2 5 10 3 14

Características das BD’s As bases de dados devem facilitar o processo de: Adicionar novos ficheiros Remover ficheiros existentes Inserir novos dados num ficheiro Remover dados de um ficheiro Actualizar dados de um ficheiro Obter informação específica a partir de ficheiros da BD

Relativamente aos dados... Os dados estão organizados segundo uma determinada estrutura e interligados, tendo em vista: evoluírem independentemente dos programas; serem partilhados por programas de diferentes aplicações e em ambientes diferentes; a não redundância de informação; manter a sua integridade e protecção; a eficácia do sistema.

Sistema gestão de bases de dados SGBD O que é? São programas ou conjuntos integrados de programas que permitem definir, 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.

Sistema de Base de Dados Sistema BD = BD + SGBD Aplicação A S G B D Aplicação B Base de Dados Aplicação C

Exemplos de SGBD’s Oracle; Informix; DB; ADABAS; Ingres; MS Access; Foxpro; Etc...

Arquitectura dum SGBD Nível físico: corresponde à forma como os dados da BD são armazenados e organizados internamente no sistema informático. Nível conceptual: corresponde à forma como os dados são estruturados ou organizados ao nível da sua concepção lógica (o nº e o tipo de campos, as relações entre os dados, etc.) Nível de visualização: corresponde à forma como os dados são apresentados aos utilizadores.

SGBD: Arquitectura... Nível de visualização Nível conceptual Consulta do Aluno A Ficha do aluno Nome: _________ Idade: _________ Nível de visualização Disc. Nota1 Nota2 D1 12 15 D2 14 18 Nível conceptual Nível físico 110001100010 001011010101

Estas operações situam-se a nível conceptual SGBD: Funções I 1. Definição e alteração da estrutura de uma BD: criar uma nova base de dados; criar um novo ficheiro ou tabela; alterar a estrutura de campos de uma tabela; criar e alterar ficheiros de índices; eliminar ficheiros ou tabelas de uma BD. Estas operações são efectuadas através da chamada Linguagem de Definição de Dados – LDD. Estas operações situam-se a nível conceptual

Estas operações situam-se a nível de visualização SGBD: Funções II 2. Manipulação de dados sem alteração da estrutura da BD: consultas ou pesquisas de dados; inserção de novos dados; alteração de dados existentes; eliminação de dados. Estas operações são efectuadas através da chamada Linguagem de Manipulação de Dados – LMD. Estas operações situam-se a nível de visualização

SGBD: Funções III Controlo dos dados: estas operações têm a ver com a atribuição ou supressão dos direitos de acesso aos dados em relação a utilizadores ou grupos de utilizadores. Estas operações situam-se a nível de visualização – O administrador do sistema da BD

SGBD: Funções IV 4. Desenvolvimento de aplicações numa linguagem Hospedeira: estas aplicações têm por objectivo tornar mais fácil aos utilizadores finais o trabalho com a BD. O SGBD Microsoft Access permite a utilização de uma versão da linguagem de programação Visual Basic – VBA.

BD: esquemas e instâncias Base de dados Esquema Instância Design ou estrutura lógica com que a BD é definida; o modo como é concebida a organização da informação. LDD Dados concretos que a BD contém em cada momento, os quais podem variar com a utilização da BD. LMD

Modelos de Bases de Dados I Modelos baseados em objectos (representam a realidade através de objectos) Modelos baseados em registos (representam a realidade através de registos)

Modelos de Bases de Dados II Modelos baseados em objectos: Modelo E-R (entidades e relacionamentos entre as entidades) Modelo orientado por objectos Modelo semântico Modelo funcional Modelos baseados em registos: Modelo hierárquico Modelo de rede Modelo relacional (registos)

O modelo E-R O modelo E-R procura criar uma representação da realidade através dos conceitos de entidade e relacionamento. Entidade – algo no mundo real com uma existência independente. Uma entidade pode ser: Um objecto com existência física (carro, casa, empregado, …) Um objecto com existência conceptual (companhia, profissão, curso de universidade, …) Relacionamento – traduz as relações entre as entidades consideradas. Por exemplo: a relação existente entre a entidade Cliente e a entidade Produto (um cliente encomenda produtos a uma dada empresa)

Modelo E– R: Entidades I Atributos: elementos ou propriedades que caracterizam uma determinada entidade. Por exemplo, os atributos duma entidade Pessoa podem ser: Nome, Idade, Sexo, Morada, … No modelo E—R : As entidades são compostas ou caracterizadas por atributos. Graficamente, as entidades são representadas por rectângulos e os seus atributos por elipses. Quando definimos uma entidade estamos a definir uma classe de entidades.

Modelo E—R: Entidades II Endereço Nome Contribuinte Telefone Empresa Notas: uma entidade corresponde a uma tabela. os atributos da entidade correspondem aos campos da tabela os vários elementos das entidades correspondem aos registos.

E—R: valores e domínios dos atributos O domínio dum atributo é o conjunto de todos os valores que este pode assumir. Num SGBD, a definição dos domínios dos atributos costuma ser feita mediante a escolha de um entre vários tipos pré-definidos, como por exemplo: string (caracter) number (valores numéricos) memo (textos mais extensos) date (para datas) …

E—R: tipos de atributos I Atributo Composto: pode ser dividido em vários atributos básicos e com significado independente. Por exemplo, o atributo Endereço da entidade Pessoa pode ser dividido em Rua, Cidade, CódigoPostal. Atributo Atómico: atributo não divisível. Por exemplo, o atributo Idade da entidade Pessoa. Questão: Considere-se o atributo Disciplina da entidade Aluno. Este atributo está definido correctamente? NÃO! Disciplina deve ser entendido como uma entidade e não como um atributo (note-se que o aluno pode estar em mais do que uma disciplina).

E—R: tipos de atributos II Atributo identificador (Chave): identifica cada entidade concreta. Este atributo desempenha o papel de chave numa entidade ou tabela. Por exemplo, o atributo BI da entidade Pessoa é o atributo identificador dessa entidade. Para assegurar que existe um atributo que define de modo único e inequívoco cada entidade concreta, é bastante comum recorrer-se a um atributo “artificial”. Ou seja, cada entidade terá mais um atributo (sempre que necessário) do tipo IDEmpregado, IDAluno, IDProduto, …

Relações Tipos de relações: Após identificadas todas as entidades necessárias, bem como todos os atributos que definem cada entidade, é necessário perceber e definir o modo como as entidades se relacionam. No modelo E—R, um relacionamento é representado por um losango e por linhas que interligam as entidades entre si através do losango. Tipos de relações: Relações Unárias: uma classe de entidades pode manter um relacionamento consigo própria. Por exemplo, considere-se a entidade Empregados e a relação “o empregado x supervisiona o empregado y”. Empregados R

E—R: Relacionamentos I Relações Binárias: duas entidades ou classes de entidades que se relacionem. Por exemplo, considerem-se as entidades Alunos e Disciplinas e a relação R=“o aluno A está inscrito na disciplina B”. Alunos Disciplinas R

E—R: Relacionamentos II Relações Ternárias: três entidades ou classes de entidades que se relacionam. Por exemplo, considere-se a entidade Actores, Realizadores e Filmes e a relação R = “o filme A foi realizado pelo realizador B em que entrou o actor C” Realizadores Filmes R Actores

E—R: tipos de relacionamentos binários I Dentro das relações binárias, há ainda que considerar o modo como as entidades participam na relação: Relações um para um (1:1) – um empregado dirige um departamento Relações um para muitos (1:N) – um jogador marca muitos golos Relações muitos para muitos (M:N) – muitos empregados trabalham em muitos projectos

E—R: tipos de relacionamentos binários II Há que considerar também se todos os elementos de uma entidade têm de participar obrigatoriamente ou não na relação: Participação obrigatória em ambas as entidades Participação não obrigatória de uma das entidades Participação não obrigatória de nenhuma das entidades

E—R: Representação gráfica Relacionamento Entidade Alunos Inscrito Atributo Nome Participação obrigatória Atributo identificador B I Relação de a para b C.P. Rua Nº a b Atributo composto Morada

Modelo Relacional O Modelo Relacional procura criar uma representação realidade através de registos. Actualmente, praticamente todos os SG BD com grande implantação no mercado adoptam o modelo relacional -por isso são designados por SGBDR (SGBD Relacionais). É o caso do Access, Oracle, Paradox, etc...

Tabelas como elementos fundamentais Os elementos fundamentais de uma BD elaborada segundo o modelo Relacionam são as tabelas, onde a informação é estruturada em campos e registos. Dentro da mesma base de dados não podem existir tabelas com o mesmo nome Cada tabela corresponde a uma classe de entidades ou a um relacionamento entre entidades

Tabelas Nome Morada Idade Cargo Manuel Porto 48 Director Fernando Tabela “Empregados” : Nome Morada Idade Cargo Manuel Porto 48 Director Fernando Gondomar 46 Supervisor Ana 47 Secretária … Registos ou ocorrências de entidades concretas Campos ou atributos duma entidade ou classe de entidades

Propriedades das tabelas A ordem pela qual se dispõem as colunas não é importante e pode ser alterada sem que isso modifique o significado da informação contida na tabela. A ordem pela qual se dispõem as linhas da tabela não é importante e também pode ser alterada sem que isso modifique o significado da informação contida na tabela

Algumas regras… não podem existir duas colunas (campos ou atributos) com o mesmo nome não podem existir campos vazios; no caso do valor ser desconhecido ou não aplicavél, então deve ser preenchido com o valor nulo especial – “null” o domínio de cada atributo tem de ser constituído por valores atómicos: 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, donde não podem existir registos duplicados

Ao não respeitar as regras … Nome Morada Idade Disciplinas Manuel Porto 18 Português ; Inglês Gondomar 16 Francês ; Alemão Ana 17 Português;Alemão Nome Morada Idade Disciplinas Manuel Porto 18 Português Inglês Luís Gondomar 16 Francês Alemão Ana 17

Chaves de uma tabela I 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; uma chave pode ser constituída por mais do que um atributo – chave composta. Uma chave é um atributo ou conjunto de atributos que permite identificar de modo unívoco os registos de uma tabela

Chaves duma tabela II Nome Morada Idade Cargo Manuel Porto 48 Director Fernando Gondomar 46 Supervisor Ana 47 Secretária 29 Directora 28 Supondo que não podemos ter duas pessoas com o mesmo nome que moram na mesma localidade, podemos concluir que as combinações dos atributos “Nome” e “Morada” forma uma chave composta.

Chaves duma tabela III Todas as chaves possíveis de uma tabela – simples ou compostas – são designadas chaves candidatas. Entre estas, uma delas será a mais indicada ou a escolhida para desempenhar o papel de chave – essa será designada por chave primária. NOTA: é aconselhável que todas as tabelas possuam pelo menos um atributo identificador, que possa desempenhar o papel de chave primária evitando assim, ter de recorrer a uma combinação de atributos. É sempre possível (e bastante usual) recorrer a um atributo artificial, tal como “id”, “código” ou “identificação”.

Chave primária Uma chave primária deve ser: unívoca (deve ter um valor único para cada entidade concreta – definição de chave) não nula (nenhum dos atributos que formam uma chave primária poderá conter um valor nulo em nenhuma entidade concreta) não redundante (no caso da chave primária ser composta, não devem ser incluídos mais atributos do que os mínimos necessários para identificar os registos de modo unívoco)

Relacionamentos e chaves externas Os relacionamentos são estabelecidos através dos atributos que desempenham o papel de chaves primárias nas respectivas tabelas. Fornecedores CodForn Nome Morada Telefone Fornece CodForn CodProd Preço Produtos Cod Prod Nome Modelo Corresponde a uma tabela de relacionamento

Chave externa Fornece CodForn CodProd Preço Uma tabela de relacionamento deverá incluir, para além dos seus campos (atributos do relacionamento), as chaves das entidades que entram no relacionamento. Uma chave externa é um atributo que é chave primária de uma tabela e que vai aparecer como atributo de uma outra tabela NOTA: 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 I Existem três tipos de integridade: integridade da entidade (nenhum valor da chave primária pode ser nulo, nem igual a outros valores já existentes na tabela) integridade de domínio (o valor de um atributo tem de pertencer ao domínio desse atributo) integridade referencial (um dado valor de uma chave externa tem de existir como chave primária de outra tabela)

Preservação da integridade da informação II Médico Especialidade IdMed Dr. Luís Clínica Geral 001 Dr. Carlos Estomatologia 002 Dr. Lopes Dentista 003 ? Data Hora Consultório BI IdMed 18-10-03 16:00 201 1111 001 21-10-03 11:00 190 1112 17:00 200 1113 005 Ao inserir um novo registo

Preservação da integridade da informação III Médico Especialidade IdMed Dr. Luís Clínica Geral 001 Dr. Carlos Estomatologia 002 Dr. Lopes Dentista 003 Ao eliminar um registo Data Hora Consultório BI IdMed 18-10-02 16:00 201 1111 001 21-10-02 11:00 190 1112 003 17:00 200 1113 005 ?

Modelação de base de dados PROBLEMA 1ª Fase – análise da situação Análise do problema Independente do SGBD Requisitos da BD 2ª, 3ª e 4ª Fases – esboço geral, definição das entidades, atributos e relacionamentos. Desenho conceptual (modelo E—R) 5ª e 6ª Fases – eventual revisão da estrutura e derivação das tabelas Esquema conceptual (modelo Relacional) Esquema conceptual no SGBD 7ª Fase – desenvolvimento do esquema da BD num SGBD Dependente do SGBD 8ª Fase – criação de programas de aplicação Desenho físico

Derivação das Tabelas da BD Existem duas estratégias genéricas a considerar na tarefa de concepção do esquema de uma BD: Estratégia TOP-DOWN (do geral para o particular) Estratégia BOTTOM-UP (do particular para o geral) NOTA: estas duas estratégias não são exclusivas. Aliás podemos e devemos (de certa forma) utilizar as duas estratégias. Numa 1ª fase utilizamos a estratégia top-down e depois tentamos refinar a estrutura da BD utilizando a estratégia bottom-up, para que as tabelas fiquem adequadamente normalizadas.

Estratégia TOP-DOWN Parte-se de uma análise das entidades e dos tipos de relacionamento entre as entidades, segundo o modelo E-R, e, com base numa análise dos diferentes tipos de relacionamentos determinam-se as tabelas a incluir na base de dados. Quantas e que tabelas são necessárias para representar as entidades e relacionamentos do modelo E-R? DEPENDE DO RATIO DE CARDINALIDADE E DO GRAU DE PARTICIPAÇÃO DAS RELAÇÕES.

Abordagem top-down: quantas tabelas são necessárias? relacionamento 1:1 com participação obrigatória de ambas as entidades – é necessária uma tabela. relacionamento 1: 1 com participação obrigatória de apenas uma entidade – são necessárias duas tabelas. relacionamento 1:N ou N:1 com participação obrigatória do lado N – são necessárias duas tabelas. relacionamento 1: 1 com participação não obrigatória de ambas as entidades – são necessárias três tabelas. relacionamento 1:N ou N:1 com participação não obrigatória do lado N – são necessárias três tabelas. relacionamento N:M – são necessárias três tabelas.

Top-down – 1:1 com obrigatoriedade de ambos os lados nome vencimento nome telefone Coordenadores Departamentos dirige 1 Coordenadores Ana Alcides Carlos Departamentos C.C. Matemática Biologia nome telefone Nome_dept vencimento Ana 487287 C.C. 1200 Alcides 525223 Matemática 1190 Carlos 523454 Biologia 1010

Top-down – 1:1 com obrigatoriedade de apenas um lado dirige Professores Departamentos 1 nome telefone redução Professores Ana Alcides Joana Carlos Departamentos Informática Línguas Matemática E se tivesse uma só tabela? Professores: Departamentos: nome telefone Ana 487287 Alcides 525223 Joana 435436 Carlos 523454 nome redução nome_coord. Informática 6 Ana Línguas 5 Alcides Matemática 8 Carlos

Top-down – 1:N com obrigatoriedade do lado N dirige Professores Departamentos 1 N nome telefone redução Professores Ana Alcides Joana Carlos Departamentos Informática Línguas CFQ Português Matemática Professores: Departamentos: nome telefone Ana 487287 Alcides 525223 Joana 435436 Carlos 523454 nome redução nome_coord. Informática 6 Ana Línguas 5 Alcides CFQ 4 Carlos Português 10 Matemática 8

Top-down – 1:1 com não obrigatoriedade dos dois lados nome redução nome telefone dirige 1 1 Professores Departamentos Professores Ana Alcides Joana Carlos Departamentos Informática Línguas CFQ Português E se tivesse só duas tabelas? Professores: Direcção: Departamentos: nome telefone Ana 487287 Alcides 525223 Joana 435436 Carlos 523454 nome_prof nome_dept Ana Informática Alcides Línguas Carlos Português nome redução Informática 6 Línguas 5 CFQ 4 Português 10

Top-down – 1:N com não obrigatoriedade do lado N nome redução nome telefone dirige 1 N Professores Departamentos Professores Ana Alcides Departamentos Informática Línguas CFQ Português E se tivesse só duas tabelas? Professores: Direcção: Departamentos: nome telefone Ana 487287 Alcides 525223 nome_prof nome_dept Ana Informática Alcides Línguas Português nome redução Informática 6 Línguas 5 CFQ 4 Português 10

Top-down – N:M preço nome modelo nome telefone N M Fornecedores Produtos Fornecedores Ana André Pedro Produtos 001 002 003 Fornecedores: Fornecimentos: Produtos: nome telefone Ana 487287 André 525223 Pedro 678679 ID_Forn. ID_Prod. preço Ana 001 80 002 43 André 78 45 Pedro 003 67 nome modelo 001 A 002 B 003 AB

Estratégia BOTTOM-UP – o processo da normalização O objectivo é estruturar a informação em tabelas na forma que pode ser mais adequada do ponto de vista das operações a efectuar sobre a informação armazenada, evitando redundâncias desnecessárias e certos problemas associados à inserção, eliminação e actualização de dados. O processo da normalização consiste no seguinte: Definem-se as entidades com todos os atributos. Analisam-se as relações e dependências entre os atributos de cada entidade e compara-se a estrutura analisada com as formas normais que iremos conhecer. Sempre que uma tabela apresentar alguma característica não conforme a forma normal, reestruturam-se os atributos ou separam-se da entidade original para formar com eles uma nova tabela. Repete-se o processo até que todas as entidades estejam na forma normal pretendida.

Normalização Inicialmente foram estabelecidas 3 formas normais  1ª forma normal (1FN), 2ª forma normal (2FN) e 3ª forma normal (3FN). Relação entre estas formas normais: Uma tabela pode estar na 1FN mas não obedecer aos requisitos para que possa ser considerada na 2FN. Uma tabela pode obedecer aos requisitos da 2FN, mas não obedecer aos requisitos da 3FN. No entanto, se está na 2FN também está na 1FN. As tabelas que se encontram na 3FN também se encontram na 2FN e, consequentemente na 1FN. Na prática, os processos de normalização consideram-se satisfeitos se as tabelas atingirem a 3FN. Por vezes, a 3FN não constitui o estado final ideal a que as tabelas de uma BD relacional devem obedecer  surgiram então as formas normais: Forma normal de Boyce/Codd (FNBC); 4ª forma normal (4FN); 5ª forma normal (5FN).

Hierarquia das formas normais As tabelas do modelo relacional têm todas de estar na 1FN. Todas as tabelas que se encontram na 2FN estão igualmente na 1FN. O contrário não é verdade. À 3FN constitui o estado considerado satisfatório no processo de normalização. Todas as tabelas que estão na 3FN também estão na 2FN. O contrário não é verdade. A FNBC constitui um refinamento da 3FN. Todas as tabelas que estão na FNBC também estão na 3FN. O contrário não é verdade. A FNBC pode ser considerada como não inteiramente satisfatória. A 4FN define requisitos mais exigentes. As tabelas que estão na 4FN também estão na FNBC, mas o contrário não é verdade. A 5FN constitui o último estádio do processo de normalização. Raramente se encontram situações práticas em que o processo de normalização tenha de ser levado até este nível.

1FN Uma tabela encontra-se na 1FN se todos os seus atributos estiverem definidos em domínios que contenham apenas valores atómicos. Esta condição constitui aliás uma condição base para que uma tabela possa ser considerada como uma tabela do modelo relacional: um atributo só pode admitir valores elementares e nunca conjuntos de valores. Alunos: IDAluno Nome Morada Disciplinas A1 João Lisboa Matemática; Economia; Direito A2 Ana Porto Matemática; Física Não está na 1FN Surgem problemas de actualização, de inserção e de eliminação! A solução já conhecida: 3 tabelas  3FN! Ao transformá-la de modo a ficar na 1FN: Já se encontra na 1FN. No entanto este 1º passo é claramente insuficiente uma vez que existe redundância de informação! IDAluno Nome Morada Disciplinas A1 João Lisboa Matemática Economia Direito A2 Ana Porto Física

2FN – dependência funcional Consideremos a tabela A(x, y, z, w). Diz-se que o atributo z é funcionalmente dependente do atributo x se, para um dado valor do atributo x, o valor do atributo z é sempre o mesmo. Ou seja: conhecido o valor de x, sabe-se automaticamente qual é o valor que está na coluna relativa ao atributo z. Se estas regras se verificarem sempre, existe uma dependência funcional entre os atributos x e z (xz). x designa-se por determinante e z por dependente. Tabela A (com dados hipotéticos): x y z w 1 3 2 7 4 5 8 Sempre que x é 1, z é 2! Sempre que x é 2, z é 5! Da mesma forma: Sempre que {x,y} é {1,3}, w é 7! Sempre que {x,y} é {2,4}, w é 8! Dependência funcional entre {x,y} e w. ({x,y}  w) {x,y} é o determinante e w é o dependente.

2FN – dependência funcional elementar Consideremos: A x y z w 1 3 2 7 4 5 8 Existe dependência funcional entre {x,y} e w, mas w não é funcionalmente dependente de nenhum dos atributos x e y, quando estes são tomados isoladamente. Desta forma, diz-se que existe uma dependência funcional elementar entre {x,y} e w. Ou seja: {x,y}  w e x  w e y  w Dependência funcional elementar {x,y}  w

2FN Uma tabela encontra-se na 2FN se estiver na 1FN e se todos os atributos que não pertençam à chave dependerem da chave através de uma dependência funcional elementar (caso a chave seja composta) ou dependerem funcionalmente da chave (se esta não for composta). A tabela está na 1FN; A chave primária é constituída pelos atributos (IDAluno, Disciplina). Esta tabela não está na 2FN porque Nome é funcionalmente dependente de IDAluno!, e não o poderia ser, teria de ser do conjunto (IDAluno, Disciplina) como um todo! IDAluno Nome Morada Disciplina A1 João Lisboa Matemática Economia Direito A2 Ana Porto Física Para passar à 2FN, a solução é a criação de 3 tabelas: Alunos(IDAluno, Nome, Morada) Disciplinas(IDDisciplina, Nome) Matrículas(IDAluno, IDDisciplina, data) As 3 tabelas encontram-se agora na 2FN. E também se encontram na 3FN…

3FN Uma tabela encontra-se na 3FN se estiver na 2FN e nenhum dos atributos que não fazem parte da chave primária pode ser funcionalmente dependente de qualquer combinação dos restantes. Isto é, cada atributo depende apenas da chave e não de qualquer outro atributo ou conjunto de atributos. Por exemplo: Jogo(IDJogo, estádio, nome_árbitro, categoria_árbitro) Nesta tabela todos os atributos são funcionalmente dependentes da chave (a tabela está portanto a 2FN). Mas o atributo categoria_árbitro depende funcionalmente do atributo nome_árbitro. Os atributos categoria_árbitro e nome_árbitro são dependentes, logo a tabela não está na 3FN. Solução: Árbitro(IDÁrbitro, nome, categoria) Jogo(IDJogo, estádio) Jogo_Árbitro(IDÁrbitro, IDJogo)

FNBC I Esta forma normal está destinada a lidar com situações em que se verifique: A existência de mais do que uma chave candidata. Que duas chaves candidatas possuam elementos comuns. Uma tabela encontra-se na FNBC se estiver na 3FN e os únicos determinantes são chaves candidatas. Exemplo: numa Universidade, os alunos frequentam várias disciplinas. Cada professor lecciona apenas uma disciplina. Uma disciplina pode ser leccionada por vários professores. Cada aluno, em cada disciplina, tem apenas um professor. A tabela alunos(IDAluno, IDDisciplina, Professor) encontra-se na 3FN porque: 1. O atributo professor é o único atributo que não faz parte da chave. 2. Esse atributo depende irredutivelmente da chave porque:  não depende de IDAluno porque um aluno pode ter vários professores.  não depende de IDDisciplina porque uma disciplina pode ser leccionada por vários professores.

FNBC II IDAluno IDDisciplina Professor A1 D1 P1 D2 P2 A2 A3 D3 P3 A4 alunos(IDAluno, IDDisciplina, Professor) Repare-se que no exemplo apresentado: Existem duas chaves candidatas compostas: (IDAluno, IDDisciplina) e (IDAluno, Professor) As duas chaves têm em comum o atributo IDAluno. O atributo Professor não é chave candidata, mas é um determinante (o nome do professor determina a disciplina uma vez que cada professor só lecciona uma disciplina) Para a tabela estar na FNBC só as chaves candidatas podem ser determinantes. Portanto, esta tabela não está na FNBC. IDAluno IDDisciplina Professor A1 D1 P1 D2 P2 A2 A3 D3 P3 A4 P4 SOLUÇÃO criar as 2 tabelas seguintes: B(IDAluno, Professor) C(Professor, IDDisciplina) Ao eliminar esta linha elimina-se também o professor P2!

4FN - multidependência x   y C1   C2 Consideremos a tabela A(x, y, z, w). Diz-se que o atributo x multidetermina y (ou que y é multidependente de x), se a um determinado valor de x está associado um conjunto de valores de y e, ainda, que esse conjunto de valores de y é independente dos restantes atributos da tabela (de z e w, neste exemplo). x   y Esta definição estende-se também a conjuntos de atributos. Sejam C1 e C2 quaisquer conjuntos não vazios formados a partir do conjunto de atributos {x, y, z, w} da tabela A. Diz-se que o conjunto C1 multidetermina o conjunto C2 se, sendo dados valores de C1, existe um conjunto de valores de C2 associados, sendo esse conjunto de valores de C2 independente dos restantes atributos da tabela. C1   C2 A multidependência diz-se elementar se não existirem subconjuntos de C1 e subconjuntos de C2 entre os quais se verifique igualmente independência.

4FN I Uma tabela encontra-se na 4FN quando as únicas multidependências elementares são aquelas em que uma chave determina um atributo. A especificação da 4FN visa eliminar a possível existência de grupos repetidos independentes. Exemplo: considere-se o caso de uma escola em que os alunos, para além de frequentarem várias disciplinas, podem ainda inscrever-se em actividades extra-curriculares. Admita-se a seguinte tabela: A(Aluno, Disciplina, Actividade) Todos os atributos pertencem à chave, pelo que a tabela está na FNBC. Imagine-se a tabela com os seguintes dados: Esta tabela contém redundância em excesso! O atributo Disciplina é claramente um atributo que gera grupos repetidos, porque um aluno pode frequentar várias disciplinas. O atributo Actividade tem as mesmas características. É um atributo que pode assumir conjuntos de valores. É razoável admitir que o atributo Disciplina é independente do atributo Actividade Aluno Disciplina Actividade João Matemática Futebol Cinema Economia Ana Direito Teatro Informática Basquetebol

Estas duas tabelas estão na 4FN! 4FN II No exemplo anterior temos pois uma multidependência. A cada aluno corresponde: um conjunto de disciplinas um conjunto de actividades Simbolicamente: Aluno   Disciplina Aluno   Actividade Solução: transformar a tabela A em duas tabelas: B(Aluno, Disciplina) C(Aluno, Actividade) Aluno Disciplina Actividade João Matemática Futebol Cinema Economia Ana Direito Teatro Informática Basquetebol Aluno Disciplina João Matemática Economia Ana Direito Informática Aluno Actividade João Futebol Cinema Ana Teatro Basquetebol Estas duas tabelas estão na 4FN!

(Actor, Filme, Realizador) 5FN I Exemplo: Considere-se um estúdio de cinema e uma tabela destinada a representar as associações entre actores, filmes e realizadores, seja ela: (Actor, Filme, Realizador) Actor Filme Realizador A1 F1 R1 R2 F2 F3 A2 A3 R3 F4 R4 Da observação desta tabela, verifica-se que um actor pode participar em vários filmes e que um filme pode ser realizado por mais do que um realizador. E se tentarmos transformar esta tabela em duas tabelas? Actor Filme A1 F1 F2 F3 A2 A3 F4 Filme Realizador F1 R1 R2 F2 F3 R3 F4 R4 A1 F3 R3 A3 F3 R1

É pois possível a transformação da tabela inicial nestas três tabelas! 5FN II Não é possível a transformação da tabela inicial em duas tabelas, o que não implica que não seja possível a sua transformação em mais do que duas tabelas. Consideremos agora as seguintes tabelas: Actor Filme A1 F1 F2 F3 A2 A3 F4 Filme Realizador F1 R1 R2 F2 F3 R3 F4 R4 Actor Realizador A1 R1 R2 A2 A3 R3 R4 É pois possível a transformação da tabela inicial nestas três tabelas!

5FN III Dependência de Junção Considere-se a tabela A(a_1, a_2, …, a_n) e X_1, X_2, …, X_k subconjuntos de atributos da tabela A. Se a tabela A puder ser transformada nas seguintes tabelas: B_1, B_2, …, B_i diz-se que existe uma dependência de junção dessas tabelas. Simbolicamente este facto representa-se por: * { B_1, B_2, …, B_i } No exemplo anterior, a tabela A(Actor, Filme, Realizador) apresenta uma dependência de junção das tabelas (Actor, Filme) (Actor, Realizador) (Realizador, Filme)

5FN IV A verificação da 5FN apenas precisa de ser utilizada em relações que tenham 3 ou mais atributos como parte da chave. Uma tabela está na 5FN se o seu conteúdo não puder ser reconstruído a partir de tabelas menores. É pertinente salientar que o objectivo da 5FN é impedir que a decomposição de tabelas gere informações inconsistentes.