bases de dados

Curso Secundário Tecnológico de InformáticaEstrutura Organização e Tratamento de Dados

12º Ano

Ano Lectivo 1996/97

Bases de Dados Bases de Dados e Sistemas de Informação

ÍNDICE

1. BASES DE DADOS E SISTEMAS DE INFORMAÇÃO.......................................................................................

1.1 BD’S E SGBD’S ..................................................................................................................................................1.2 ARQUITECTURA DE UMA BASE DE DADOS ............................................................................................................1.3 ARQUITECTURA DE UM SISTEMA DE GESTÃO DE BASES DE DADOS .......................................................................

2. O MODELO ENTIDADE-ASSOCIAÇÃO.............................................................................................................

2.1 ENTIDADES ..........................................................................................................................................................2.2 ASSOCIAÇÕES ......................................................................................................................................................

2.2.1 Graus de um associação..............................................................................................................................2.3 ATRIBUTOS E VALORES ........................................................................................................................................2.4 DOMÍNIOS ............................................................................................................................................................2.5 ATRIBUTOS ..........................................................................................................................................................

2.5.1 Atributos Elementares.................................................................................................................................2.5.2 Atributos Compostos....................................................................................................................................2.5.3 Atributos conjuntos de valores.....................................................................................................................2.5.4 Atributos Identificadores.............................................................................................................................

2.6 OCORRÊNCIA DE UMA ENTIDADE ..........................................................................................................................2.7 ASSOCIAÇÃO SEM ATRIBUTOS E ASSOCIAÇÃO COM ATRIBUTOS ..............................................................................

3. O MODELO RELACIONAL DE BASES DE DADOS..........................................................................................

3.1 PARALELO ENTRE O MODELO RELACIONAL E O SGBD ..........................................................................................3.2 CHAVES PRIMÁRIA, CANDIDATA E SECUNDÁRIA ....................................................................................................3.3 INTEGRIDADE REFERENCIAL .................................................................................................................................3.4 INTEGRIDADE DE ENTIDADE .................................................................................................................................

4. DERIVAÇÃO DAS TABELAS RELACIONAIS A PARTIR DO MODELO ENTIDADE-ASSOCIAÇÃO............................................................................................................................................................

4.1 ASSOCIAÇÕES DO TIPO UM-PARA-UM (1:1) ............................................................................................................4.1.1 Associação unária um-para-um...................................................................................................................4.1.2 Associação binária um-para-um..................................................................................................................

4.2 ASSOCIAÇÕES DO TIPO UM-PARA-VÁRIOS (1:N) .....................................................................................................4.3 ASSOCIAÇÕES DO TIPO VÁRIOS-PARA-VÁRIOS (N:M) ..............................................................................................4.4 EXERCÍCIOS .........................................................................................................................................................

GLOSSÁRIO...............................................................................................................................................................

1 - Bases de Dados e sistemas de informação2 - O modelo Entidade-Associação3 - O Modelo Relacional de Base de Dados4 - Derivação de tabelas relacionais a partir do modelo entidade-associação5 - Operações sobre tabelas6 - Normalização de tabelas7 - Criação de uma base de dados em Access8 - Execução de Querys em Access

Prof. José C. Silva 3

Base de Dados

SGBD

UtilizadoresFig. 1 - O sistema gestor da base de dados SGBD.


1. BASES DE DADOS E SISTEMAS DE INFORMAÇÃO

1.1 BD’s e SGBD’s

Base de Dados (BD) - é um sistema cuja finalidade é registar, actualizar, manter e disponibilizar a

informação relevante para a actividade de uma organização.

Um sistema de base de dados é composto por duas partes fundamentais:

a estutura lógica e física em que a informação se encontra organizada;

o sistema gestor da base de dados (SGBD).

O sistema gestor de base de dados gere toda a informação contida na base de dados e

constituí a interface entre a informação e os utilizadores, quer sejam utilizadores finais quer sejam

programadores.



1.2 Arquitectura de uma Base de Dados

O real que pode ser informatizável, pode ser descrito utilizando um modelo conceptual,

podendo ter vários modelos externos dependendo dos utilizadores, mas apenas posssuí um

modelo interno onde está situada a BD física.

A arquitectura de uma base de dados está dividida em três níveis:

Nível externo - são as visões individuais dos vários utilizadores.

Nível conceptual - compreende um esquema conceptual que acenta num modelo de

dados que foi definido.

Nível interno - é onde está o esquema de armazenamento dos dados da BD, a BD

física.


REAL INFORMATIZÁVEL

MODELOCONCEPTUAL

MODELO

INTERNO

MODELOS

EXTERNOS

MODELOS

EXTERNOSMODELOS

EXTERNOS

BDFísica

Fig. 2 - Arquitectura de uma Base de Dados (BD).



. . . VISÃO IVISÃO IVISÃO I

ESQUEMA

CONCEPTUAL

Fig. 2 Níveis de arquitectura de uma Base de Dados.

ESQUEMA

DE ARMAZENAMENTO


1.3 Arquitectura de um Sistema de Gestão de Bases de Dados

No sistema de bases de dados Access, são identificáveis os seguintes elementos:

A base de dados propriamente dita, constiuída por um conjunto de de objectos, tais como tabelas (tables),consultas (queries), formulários(forms), relatórios (reports),e módulos (modules). A base de dadosé armazenada num ficheiro .mdb.

A engine da base de dados, constituída por um conjunto de programas responsáveis pela execução de todas as operações de acesso à base de dados. Actua como um gestor de dados(data manager).

O interface gráfico, que disponibiliza o acesso dos utilizadores à criação de tabelas, definição de consultas, criação de relatórios e formuláriosde apresentação de dados


PROFESSORESALUNOS

Bases de Dados O modelo Entidade-Associação

2. O MODELO ENTIDADE-ASSOCIAÇÃO

O modelo entidade-associação procura criar uma simulação da realidade. Esta é vista como um conjunto de entidades, interagindo umas com as outras, através de um conjunto de associações ou relacionamentos de vários tipos.

Por exemplo, numa ESCOLA podem definir-se as entidades PROFESSORES, ALUNOS, DISCIPLINAS, SALAS DE AULA, etc. Cada entidade representa um conjunto de elementos: a entidade PROFESSORES representa um conjunto dos professores, a entidade ALUNOS um conjunto de alunos, e assim por diante.

A vida na Escola é, em grande parte, a consequência de associações entre essas entidades. É, por isso, preciso analisar essas associações e representá-las através de um modelo. Vejamos alguns exemplos, aplicados a este caso:

Os ALUNOS estão associados com as DISCIPLINAS.

Cada aluno pode estar matriculado em várias disciplinas e cada disciplina é frequentada por vários alunos. Trata-se de uma associação de vários -para-vários, também designada de associação de m-para-n (m:n), uma vez que cada elemento da entidade ALUNOS pode estar associado com


DISCIPLINASALUNOSNM

matricular


vários elementos da entidade DISCIPLINAS (uma aluno matriculado a várias disciplinas) e, por sua vez, cada elemento da entidade DISCIPLINAS pode estar associado com vários elementos da entidade ALUNOS (uma disciplina é frequentada por vários alunos).A partir deste facto, é possível, conceptualmente, estabelecer uma associação entre as entidades ALUNOS e DISCIPLINAS. O nome dessa associação poderia ser naturalmente MATRICULAR.



Graficamente, as entidades são representadas por rectângulos contendo, no seu interior, o nome atribuído à entdidade. as associações entre entidades são representadas através de linhas, com losangos a representar as associações.

Num PARLAMENTO, podem definir-se as entidades DEPUTADOS e GRUPOS PARLAMENTARES, por exemplo. Vejamos uma possível associação entre essas duas entidades .

Os deputados podem estar integrados em grupos parlamentares. Temos assim uma associação entre a entidade DEPUTADOS e a entidade GRUPOS PARLAMENTARES. O nome a dar a essa associação pode ser, por exemplo, PERTENCER. Os nomes a dar às associações não são muito relevantes. O que verdadeiramente importa, é que se compreeenda o conteúdo e o tipo dessa asssociação.

Neste caso, estamos perante uma associação um-para-vários ou 1-para-n (1:n) entre a entidade GRUPOS PARLAMENTARES e a entidade DEPUTADOS, uma vez que um grupo parlamentar pode ter n deputados, mas um deputado pertencerá apenas a um grupo parlamentar

Imagine-se agora o caso de uma empresa que decidiu criar um Fundo de Pensões e estuda a forma de registar numa base de dados a associação entre os empregados e o Fundo.

Podem admitir-se no modelo duas entidades: a entidade EMPREGADOS (conjunto dos empregados da empresa) e a entidade ASSOCIADOS (conjunto dos associados do Fundo de Pensões). Evidentemente, estas duas entidades podem ser distintas, pois nada nos permite concluir do enunciadp da questão que todos os empregados sejam associados e que todos os associados sejam empregados. Basta admitir que a participação no Fundo de Pensões é livre e que, portanto, alguns empregados possam não participar. Por outro lado, o Fundo pode ser aberto à participação de familiares dos empregados e, nesse caso, pode haver associados que não sejam empregados da empresa.. Estas várias hipóteses são regras da organização (na terminologia das bases de dados, vulgarmente designadas por business rules) e devem ser reflectidas no modelo.

Vamos analisar cada uma dessas hipóteses.

Exemplo 1:Regra:

Todos os empregados participam no Fundo de Pensões e só é permitida a participação de empregados.


GRUPOSPARLAMENTARES

DEPUTADOS1N

PERTENCER

11

R

A B

EntidadeObrigatória


11

Empregados Associados




A associação entre EMPREGADOS e ASSOCIADOS é uma associação de um-para-um, visto que cada elemento da entidade EMPREGADOS estará associado com um só elemento da entidade ASSOCIADOS e, do mesmo modo, cada elemento da entidade ASSOCIADOS estará relacionado com apenas um elemento da entidade EMPREGADOS.

Mas a regra impõe que todos os empregados sejam associados e que todos os associados sejam empregados. Em termos do modelo, todos os elementos da entidade EMPREGADOS e todos os elementos da entidade ASSOCIADOS participam na associação. Está-se assim perante um caso em que ambas as entidades são obrigatórias.

Uma entidade é obrigatória numa associação quando todos os elementos dessa entidade tiverem obrigatoriamente de participar na associação. Graficamente, uma entidade obrigatória é representada com um traço vertical, colocado no lado do rectângulo do qual estabelece a associação.

Exemplo 2:Regra:Todos os empregados são obrigatoriamente associados, mas o Fundo é aberto à participação de não empregados.

Continuamos perante uma associação de um-para-um, mas neste caso apenas a entidade EMPREGADOS é abrigatória. É obrigatória porque, de acordo com a regra estabelecida todos os empregados participam no Fundo. Mas a entidade ASSOCIADOS deixa de ser obrigatória uma vez que alguns elementos dessa entidade podem não ser empregados da empresa.

Exemplo 3:Regra:A participação no Fundo é livre para os enmpregados e o Fundo é aberto à participação de não empregados. Nem todos os empregados serão associados e haverá associados que não são empregados.



Continuamos a ter uma associação um-para-um, mas neste caso nenhuma das entidades é obrigatória.

Quando uma entidade não é obrigatória, pode haver elementos ou ocorrências dessa entidade quer não partcipam na associação, isto é, que não estão associados com nenhum elemento ou ocorrência da outra entidade.

2.1 Entidades

O termo entidade pode designar um conjunto de objectos do mesmo tipo, acerca dos quais se pretende recolher e registar informação. Por exemplo: pessoas, firmas, produtos, facturas,. livros, etc. Uma entidade é representada no modelo entidade-associação através de um rectângulo com o seu nome inscrito, conforme podemos ver no exemplo seguinte.

2.2 Associações

As associações representam os relacionamentos existentes entre as várias entidades.

Uma associação pode ser classificada como :- UNÁRIA - associa uma entidade com ela própria;- BINÁRIA - associa duas entidades;- TERNÁRIA - associa três entdidades;- COMPLEXA - associa entre si duas ou mais entidades.

2.2.1 Graus de um associação

a) ASSOCIAÇÃO 1:1 (de 1 para 1)

A cada ocorrência da entidade "A" está associada apenas uma ou nenhuma ocorrência de

entidade "B" e vice-versa. Vejamos o seguinte diagrama entidade-associação:


1 1

1BA

ALUNOALUNO

Unária Binária

BA

Ternária

A C

B

Professor leccionar Disciplina

1 1


O professor pode no máximo dar uma disciplina e uma disciplina pode no máximo ser dada

por um professor. Pode haver professores sem leccionar disciplinas e pode haver disciplinas que

não estão a ser leccionadas por nenhum professor.

b) ASSOCIAÇÃO 1:N (de 1 para N)

A cada ocorrência da entidade "A" estão associadas N ocorrências da entidade "B". A cada

ocorrência da entidade “B” está associada uma ou nenhuma ocorrência da entidade “A”. Vejamos o

seguinte diagrama entidade-associação.

Um departamento tem vários ou nenhum empregados e um empregado só pode trabalhar

num ou nenhum departamento.

c) ASSOCIAÇÃO M:N (de M para N)

A cada ocorrência da entidade "A" estão associadas N ocorrências da entidade "B". A cada

ocorrência de "B" estão associadas M ocorrências de "A". Consideremos o seguinte diagrama

Um indivíduo fala vários idiomas. Um idioma é falado por vários indivíduos.

2.3 Atributos e Valores

As entidades e as associações representam coisas, seres, conceitos e acontecimentos do mundo real qua são geradores de informação. Essa informação resulta da observação e registo dos seus atributos observáveis:


1 1

NBA

M 1

NBA

1 N

Departamento afectar Empregado

M N

Individuo falar Idiomas


O nome, a altura, o estado civil e a data de nascimento constituem atributos que podem caracterizar uma pessoa.

A marca, a cor e a cilindrada são exemplos de atributos de um automóvel.

O título, o número de páginas, o ano de publicação, e o editor são atributos que podem caracterizar um livro.

O numero, o nome, e a numero de contribuinte são atributos de um cliente.

A identificação dos atributos das várias entidades e associações constitui uma das fases mais importantes na construção de qualquer sistema de informação. Por exemplo considere-se a entidade ALUNOS, no sistema de informação de uma escola. Que tipo de informação relativo a cada aluno interessa à escola registar na base de dados? Como exemplo poderemos considerar os seguintes:

NomeAnoTurmaNúmeroMoradaCódigo PostalLocalidadeData de NascimentoEncarregado de Educação

Trata-se de uma lista de atributos que são comuns a todos os alunos. Um atributo é o nome de uma característica observável em todos os elementos de uma entidade. Cada atributo assume, para cada aluno um determinado valor.

Como exemplo, poderíamos considerar que para determinado aluno os valores assumidos por esses atributos seriam os seguintes:

Número 25Nome Telmo SilvaAno 12ºTurma KMorada Rua das Flores, 34Código Postal 8500Localidade PortimãoData de Nascimento 18/12/1977Encarregado de Educação Domitília Silva

2.4 Domínios

Ao conjunto de todos os valores elementares de um atributo dá-se o nome de domínio, e só serão considerados válidos, os valores que pertençam ao domínio definido.



Por exemplo para o atributo Número de aluno, os valores considerados válidos pertençem ao conjunto dos números inteiros não negativos menores que 35.

2.5

Atributos

2.5.1 Atributos Elementares

Cada atributo pode assumir valores de um domínio, e deve representar a mais pequena parcela no contexto de um sistema de informação, tais atributos têm o nome de atributos elementares. Exemplos de atributos elementares poderão ser a código postal da morada do aluno. Este atributo é indivisível, se o fizessemos estaríamos a perder informação.

2.5.2 Atributos Compostos

O caso de um atributo composto é o nome do aluno, poderiamos dividi-lo em primero nome, último nome e outros nomes.

2.5.3 Atributos conjuntos de valores

Existem casos em que um atributo é formado por um conjunto de valores e quando tal acontece é necessário repensar a definição do atributo. Reconsideremos o caso da entidade aluno de uma escola, poderiamos apontar como atributo as disciplinas frequentadas onde teriamos de colocar todas as disciplinas frequentadas pelo aluno.

O exemplo anterior entra em conflito com a própria definição de domínio de um atributo o qual recorde-se se definia como o conjunto de valores elementares. Como o campo disciplinas frequentadas não contém valores elementares, mas sim um conjunto de valores, será mais correcto definir a entidade disciplina e considerar a relação que existe com a entidade aluno.


ATRIBUTO DOMÍNIONúmero Todos os números inteiros não negativos

menores que 35.Nome Conjunto dos caracteres do alfabeto e o

símbolo ‘-‘ Ano Um de três números: 10, 11 ou 12. (Ensino

Secundário)Turma Conjunto das letras do alfabeto.

Morada Conjunto de todos os caracteres de texto.Código Postal Todos os números inteiros não negativos

entre 1000 e 9999.Localidade Conjunto de todos os caracteres de texto.

Data de Nascimento Conjunto de todas as datas num formato estabelecido.

Encarregado de Educação

Conjunto de todos os caracteres de texto.


EXERCÍCIOS

1. Desenhar os seguintes diagramas Entidade-Associação (DEAs):

a) Um departamento emprega várias pessoas, e uma pessoa trabalha para um máximo de um departamento.

b) Um director dirige no máximo um departamento. Um departamento tem no máximo um director.

c) Um autor escreve vários livros. Um livro pode ser escrito por vários autores.

d) Uma equipa é composta por vários jogadores. Um jogador joga apenas numa equipa.

e) Um professor lecciona no máximo uma disciplina. Uma disciplina é leccionada apenas por um professor.

f) Um cliente realiza várias encomendas. Uma encomenda diz respeito apenas a um cliente.

g) Um assinante é obrigatoriamente um cliente, mas um cliente pode não ser um assinante.

h) Cada actor pode participar em diversos filmes realizado por vários realizadores. Cada realizador pode realizar vários filmes em que participam vários actores.



2.5.4 Atributos Identificadores

Um atributo diz-se identificador de uma identidade se a poder identificar de maneira única e sem ambiguidades. Considerando o caso da entidade salas, poderiamos chegar ao seguinte conjunto de atributos:

SALAS (Número de sala, piso)

O único atributo que permite identificar de maneira única a sala é o seu número, uma vez que não existirão salas com o mesmo número.

Um atributo identificador aparece sempre a sublinhado, como acima se indica.

Um atributo identificador não admite valores repetidos, para que esse atributo possa referir de maneira única o elemento a que diz respeito.

2.6 Ocorrência de uma entidade

Os valores assumidos por uma entidade recebe o nome de ocorrência. Observemos o caso abaixo.

Tal como a figura indica existem três ocorrências da entidade Armazém e cinco da entidade Produto. Existem três armazéms: A1, A2 e A3 e existem cinco produtos: P1, P2, P3, P4 e P5.


ARMAZÉM PRODUTOArmazenar

Armazém Armazena Produto

A1 P1 A2 P2 A3 P3

P4 P5

Ocorrência de:

Armazém: 3

Produto: 5


2.7 Associação sem atributos e associação com atributos

Uma associação com atributos é aquela em que a própria associação pode conter atributos no caso abaixo a associação representada pelo verbo fornecer, isto é o fornecimento pode conter atributos, tal como a data do fornecimento.


Associação SEM atributos

Associação COM atributos

Fornecedor Produto

Funcionário DepartamentoAfectar

Fornecer

Bases de Dados O Modelo Relacional de Bases de Dados

3. O MODELO RELACIONAL DE BASES DE DADOS

Tal como o modelo hierárquico ou o modelo em rede, também o modelo relacional é um modelo que se aplica às bases de dados.

O modelo relacional de base de dados é implementado informaticamente através de sistemas de gestão de bases de dados conehcidos como SGBD’s.

O SGBD que iremos trabalhar é o Microsoft Access, o qual está preparado para trabalhar sob o sistema operativo Windows.

3.1 Paralelo entre o modelo relacional e o SGBD

Traçando um paralelo entre a teoria de base de dados e o modelo relacional, diriamos que para uma determinada entidade como a entidade ALUNO teremos uma tabela que nos permite registar os dados respeitantes a essa entidade.

Tal como vimos atrás, podem existir várias ocorrências de uma entidade pelo que convém registar toda esta informação de uma forma organizada. E o Access permite-nos fazê-lo de forma simples.

A uma entidade normalmente irá corresponder uma TABELA. Como sabemos uma tabela, para além do nome, é formada por uma conjunto finito de linhas e colunas. Nas colunas aparecerão os vários atributos da entidade ALUNOS e nas linhas as várias ocorrências dessa entidade. Mas para sermos mais precisos, diremos que nas colunas aparecem os CAMPOS da tabela ALUNOS e nas linhas os vários REGISTOS dessa entidade.

MODELO RELACIONAL SGBD - ACCESS

ENTIDADE: Alunos TABELA: Alunos

ATRIBUTOS da Entidade Alunos CAMPOS da Tabela Alunos

NomeAnoTurmaNúmero


Nome Ano Turma Número

ALUNOS


Como podemos constatar no exemplo anterior, à entidade ALUNOS do Modelo Relacional irá corresponder uma Tabela no SGBD, e os atributos da entidade corresponderão às colunas dessa Tabela.

Modelo Relacional ACCESS

OCORRÊNCIAS da Entidade Alunos REGISTOS da Tabela Alunos

Nome: Ana Nome: Silvia Ano: 12º Ano: 10º Turma: G Turma: J Número: 1 Número: 12

Nome: Telmo Nome: João Ano: 11º Ano: 11º Turma: K Turma: K Número: 23 Número: 20

Existem quatro Ocorrências da Entidade Alunos que irão corresponder a quatro Registos na Tabela Alunos.

3.2 Chaves primária, candidata e secundária

Na secção sobre atributos identificadores (2.5.4) afirmou-se que um atributo diz-se identificador se pode identificar de maneira única e sem ambiguidades uma entidade.

Assim, um atributo que possua as características de identificador já é uma chave candidata a chave primária.

Como podem existir várias chaves candidatas é fundamental pensar naquela - chave primária - que identificará a tabela de maneira única e inequívoca nas relações com as outras tabelas da base de dados.

A chave primária pode ser constituída por um único campo ou por uma conjunção de vários campos.

Uma tabela pode possuir um campo que seja a chave primária de outra tabela, diremos que estamos em presença de uma chave secundária, por vezes chamada de externa ou estrangeira.

Consideremos o caso da seguinte relação:


Nome Ano Turma NúmeroAna 12º G 1Silvia 10º J 12Telmo 11º K 23João 11º K 20

DISCIPLINASALUNOS

NMmatricular


Tomando em conta que existe um número único que identifica cada aluno da escola, e não existem alunos com o mesmo número, teremos as seguintes tabelas:

ALUNOS (Número aluno, Nome, Turma, Ano, Morada, Telefone, Data nascimento)DISCIPLINAS (CodDisciplina, Nome, Ano, CodGrupo)MATRÍCULAS (Número aluno, CodDisciplina, Ano Lectivo, Data matrícula)

Neste a chave primária da tabela ALUNOS será o campo Número de aluno, da tabela DISCIPLINAS será o campo CodDisciplina e da tabela MATRÍCULAS a chave primária é composta pelos campos Número de Aluno e CodDisciplina. Aparece sublinhado com um traço único.

Por sua vez, na tabela MATRÍCULAS temos duas chaves secundárias, que é o campo Número de aluno e o campo CodDisciplina, uma vez que são as chaves primárias da tabela ALUNOS e da DISCIPLINAS, respectivamente.

De notar que a chave primária aparece sublinhado com um traço único (___)e a chave secundária aparece sublinhado a tracejado. (- - - -)

3.3 Integridade referencial

Este é uma regra que define que um valor de uma chave externa tem de existir na tabela a que esse valor faz referência.

Por outras palavras, no exemplo anterior, não poderiamos inserir valores nos campos Número Aluno e CodDisciplina da tabela de MATRICULAS se não existissem os correspondentes registos nas tabelas ALUNOS e DISCIPLINAS. Não poderiamos por exemplo matricular o aluno nº 2001 na disciplina 10334, se ainda não tivessemos os dados dos aluno 2001 na tabela ALUNOS e da disciplina com o código 10334 na tabela de DISCIPLINAS.

3.4 Integridade de Entidade

É a regra que define que não devem existir no campo, ou no conjunto de campos, valores nulos.

Este é um princípio que o SGBD Access está preparado. Uma vez que defenimos um campo como chave numa tabela, quando estamos a fazer a entrada dos registos, o próprio programa não nos deixa passar para o próximo registo sem que o campo que é chave primária seja preenchido.


Bases de Dados Derivação de Tabelas a partir do Modelo Entidade-Associação

4. DERIVAÇÃO DAS TABELAS RELACIONAIS A PARTIR DO MODELO ENTIDADE-ASSOCIAÇÃO

Uma vez definido o Modelo Entidade-Associação de um sistema de informação é possível extraír as tabelas relacionais dessa mesma base de dados.

Para tal iremos analisar caso a caso, para sabermos que tabelas derivar e como estabelecer as suas chaves primárias. É importante não esquecer o princípio definido no final do capítulo anterior que recorde-se dizia, um campo, ou conjunto de campos, não deve ter conter valores nulos. O que por outras palavras significa que, numa tabela não devem aparecer registos em que algum ou alguns campos com valores nulos.

4.1 Associações do tipo um-para-um (1:1)

Considere-se as duas entidades A e B relacionadas através de uma associação do tipo um-para-um, em que a cada elemento de A corresponde no máximo um elemento de B, ou nenhum, e a cada elemento de B corresponde um ou nenhum elemento de A.

4.1.1 Associação unária um-para-um

É o caso de temos várias equipas que participam num torneio de futebol da escola. A relação que se estabelece é unária uma vez que as equipas que se formam na escola são as que vão participar do torneio e é uma relação 1:1 porque cada equipa joga cada vez apenas com uma única equipa.

À entidade EQUIPAS irá corresponder a tabela com o mesmo nome e uma vez que a associação possui atributos será criada uma segunda tabela com o nome de JOGO que registará não só as duas equipas intervenientes em cada jogo, mas também a data e hora da sua realização e os resultados. Assim temos,

EQUIPAS (CodEquipa, Nome, NumJogadores)JOGO (CodEquipa1, CodEquipa2, Data, Hora, Golos1,Golos2)


BA1 1

JOGO

EQUIPASEQUIPAS


Na tabela JOGO temos uma chave primária composta pelos campos CodEquipa1 e CodEquipa2, Data, os quais registam os códigos das duas equipas intervenientes em cada jogo, bem como a data da realização do mesmo.

Consideramos uma chave composta com três campos, pois eventualmente as mesmas equipas podem voltar a defrontar-se no mesmo torneio, e aí só a data irá distinguir os jogos.

Vejamos um exemplo prático. A Associação de Estudantes da Escola Secundária João de Deus está a realizar um torneio de futebol destinado a equipas da escola. Das quatro equipas apresentadas, vejamos que jogos se realizaram até ao momento:

De notar que em ambas as tabelas não exitem valores nulos.

Consideremos agora um segundo caso. Suponhamos que se realizaria numa determinada empresa um torneio de golfe entre os vários funcionários, assim teríamos:


Tabela: EQUIPAS

CodEquipa Nome NumJogadores

1 Os Bravos 12

2 Os InforTemíveis 13

3 Os Fortes 11

4 Os Invensíveis 11

Tabela: JOGOS

CodEquipa1 CodEquipa2 Data Hora Golos1 Golos2

1 2 22-01-97 14:00 1 2

4 3 22-01-97 14:00 3 2

3 1 22-01-97 16:00 2 1

4 2 22-01-97 16:00 1 1

JOGAR

FUNCIONÁRIO

FUNCIONÁRIO


Neste caso a associação que se estabelece também é unária, uma vez que os funcionários são também jogadores. Olhando para este caso deriva as tabelas:

4.1.2 Associação binária um-para-um

O tipo de associações um-para-um pode ser exaustivamente analisado considerando os seguintes casos:

não existem entidades obrigatórias; uma das entidades é obrigatória; ambas as entidades são obrigatórias.

Caso 1: Não existem Obrigatoriedades

Consideremos a seguinte associação entre os INVESTIGADORES e os CASOS que investigam, em que não exitem obrigatoriedades.

Nesta associação binária temos vários INVESTIGADORES (A, B, C, D) e vários casos em investigação (C1, C2, C3). Notemos que tal como a associação está definida existe um Investigador D que não tem nenhum caso atribuido.

Poderiamos definir para já as tabelas INVESTIGADORES e CASOS da seguinte maneira:

INVESTIGADORES (CodInv, Nome, Cargo, ...)CASOS (CodCaso, DataInício, Descrição, ...)

O problema que se coloca é como registar as Investigações já em curso. Será que colocando a chave da tabela INVESTIGADORES na tabela CASOS resolveria o problema? Vejamos a tabela de CASOS como ficaria definida:

CASOS (CodCaso, CodInv, DataInício, Descrição, ...)

De maneira nenhuma, uma vez que poderiam existir casos para os quais não existissem investigadores associados. Iríamos obter certos registos em que o campo Codinv estaria nulo, o quw não deve acontecer.


CASOSINVESTIGADORES1 1

C1C2C3

ABCD


Será que poderiamos colocar o CodCaso na tabela INVESTIGADORES ? O problema seria o mesmo! A solução será criar uma terceira tabela INVESTIGAÇÃO:

INVESTIGADORES (CodInv, Nome, Cargo, ...)CASOS (CodCaso, DataEntrada, Descrição, ...)INVESTIGAÇÃO (CodInv, CodCaso, DataInício, DataFim)

Ao criar esta tabela INVESTIGAÇÃO garantimos apenas que figuram os casos para os quais apenas exista já um investigador a trabalhar. E desta maneira permite que existam Investigadores que não tenham caso atribuído de momento, e casos para os quais não existam Investigadores ainda associados.

Vejamos com um exemplo:


Tabela: INVESTIGADORES

CodInv Nome Cargo

1 Bruno Santos Inspector

2 Aníbal Cruz Sub-Inspector

3 Carlos Tiago Inspector

4 Filipe Justino Director

Tabela: CASOS

CodCaso DataEntrada Descrição

1 15-08-96 Tráfico de Armas

2 17-09-96 Homicídio

3 16-10-96 Sequestro

4 22-11-96 Roubo


A derivação do Modelo Entidade-Associação diz, no caso de uma associação binária 1:1 sem obrigatoriedades, que temos de criar uma terceira tabela em que a chave primária é composta pelas chaves das entidades envolvidas, podendo existir outros campos da nova tabela que também participem da chave primária. No entanto, temos que analisar caso a caso.

Assim, neste exemplo em particular, a chave primária da tabela INVESTIGAÇÃO será composta pelos campos CodInv, CodCaso e DataInício. A tabela assim definida possibilita a um investigador reabrir um caso já encerrado. Uma vez que a DataInício da nova investigação será diferente, não existirão repetições na chave primária da tabela INVESTIGAÇÕES.


Tabela: INVESTIGAÇÃO

CodInv CodCaso DataInício DataFim

1 1 16-09-96 19-10-96

2 2 17-09-96 15-10-96

3 2 16-10-96 12-12-96

4 3 24-11-96 13-12-96


Caso 2: Uma das entidades é obrigatória

Consideremos o seguinte caso de um Centro de Formação de professores de uma escola. Cada formador tem de ser um professor com experiência profissional, mas nem todos os professores que frequentam o centro são formadores.

A associação estabelecida entre as entidades FORMADOR e o PROFESSOR, diz que a entidade FORMADOR é uma entidade obrigatória.

Uma vez que nem todos os professores são formadores, a associação entre professores e formadores pode ser assegurada através da inclusão do identificador da entidade PROFESSOR na tabela correspondente à entidade FORMANDOR. Assim, teremos as seguintes tabelas:

PROFESSOR (CodProf, Nome, Habilitações, ...)FORMADOR (CodForm, Nome, ... , CodProf )

Caso 3: Ambas as entidades são obrigatórias

Todos os funcionários do Estado participam no Fundo de Pensões e só é permitida a participação a funcionários.

Neste caso, uma vez que ambas entidades são obrigatórias, só existe a necessidade de criar uma única tabela com os seguintes campos:

FUNCIONÁRIOS (CodEmpr, Nome, ... , CodAssociado, Mensalidade, ... )

A tabela poderia ficar com o seguinte aspecto:


Tabela: FUNCIONÁRIOS

CodEmpr Nome CodAssociado Mensalidade

1 Carlos Castro 1245 20.000$00

2 Samuel Vinha 2545 15.000$00

3 Beatriz Bastos 989 25.000$00

... ... ... ...

FORMADORPROFESSOR 1 1

FUNCIONÁRIOS ASSOCIADOS1 1


4.2 Associações do tipo um-para-vários (1:n)

Considere-se as duas entidades A e B através de uma determinada associação do tipo um-para-vários (1:n), em que a cada elemento de A corresponde um ou mais elementos de B, mas a cada elemento de B corresponde apenas um elemento de A.

Neste tipo de associação podem acontecer quatro casos distintos:

não existem entidades obrigatórias; a entidade do lado 1 é entidade obrigatória; a entidade do lado n é entidade obrigatória; ambas entidades são obrigatórias.

Caso 1: Não existem entidades obrigatórias

Numa empresa existem várias áreas funcionais, em cada área trabalham vários funcionários, mas cada funcionário apenas pode pertencer a uma área funcional.

Neste caso existe a conveniência de criar uma terceira tabela com uma chave primária composta pelos identificadores das entidades ÁREAS e FUNCIONÁRIOS, e eventualmente mais algum atributo se a associação os possuir.

Assim, e para este caso, as tabelas seriam as seguintes:

ÁREAS (CodArea, Designação, ...)FUNCIONÁRIOS (CodFunc, Nome, ... )ÁREAS-FUNCIONÁRIOS (CodArea, CodFunc, DataAfectação)

Caso 2: A entidade do lado 1 é entidade obrigatória

Uma área só pode existir se tiver funcionários, mas podem existir funcionários que não pertençam a nenhuma área especifica.


BA1 n

ÁREAS FUNCIONÁRIOS1 n





Caso 3: A entidade do lado n é entidade obrigatória

Cada funcionário pertence obrigatoriamente a uma área, mas podem existir áreas sem funcionários.

Neste caso basta inserir o identificador da entidade não obrigatória ÁREAS na tabela da entidade obrigatória FUNCIONÁRIOS.


ÁREAS (CodArea, Designação, ...)FUNCIONÁRIOS (CodFunc, Nome, ... , CodArea)

Caso 4: Ambas entidades são obrigatórias

Uma área só pode exitir se tiver funcionários, e cada funcionário tem de pertencer no máximo a uma área.


ÁREAS FUNCIONÁRIOS1 n

1 nÁREAS FUNCIONÁRIOS

1 nÁREAS FUNCIONÁRIOS





Na verdade, o conjunto de atributos CodArea e CodFunc seria insuficiente como chave primária da tabela ÁREAS-FUNCIONÁRIOS pois, se o objectivo da tabela é registar as movimentações dos funcionários pelas várias áreas, pode muito bem acontecer que existam funcionários que tenham saído de uma área e tivessem voltado a entrar. Uma vez que existe a possibilidade de repetição, temos de acrescentar à chave primária também o campo DataAfectação.

4.3 Associações do tipo vários-para-vários (n:m)

Considere-se as duas entidades A e B através de uma determinada associação do tipo vários-para-vários (n:m), em que a cada elemento de A corresponde um ou mais elementos de B, e a cada elemento de B corresponde um ou vários elementos de A.

Este tipo de associação obriga sempre à criação de uma tabela para representar a associação das entidades envolvidas.

Analisemos a associação entre as alunos e as disciplinas em que se encontram matriculados.

Poderiamos dizer que cada aluno está matriculado a várias disciplinas e em cada disciplina estão matriculados vários alunos.

Como se trata de uma associação do tipo vários-para-vários, para além das tabelas ALUNOS e DISCIPLINAS, existirá uma terceira tabela para a associação entre entidades a que poderiamos chamar de MATRÍCULAS.

As tabelas poderiam ser as que se apresentam:


BAn m

ALUNOS DISCIPLINASn m


ALUNOS (CodAluno, Nome, Morada, ...)DISCIPLINAS (CodDisc, Designação, Nível, ... )MATRÍCULAS (CodAluno, CodDisc, DataMatricula)

Poderiamos concretizar com um exemplo:


Tabela: ALUNOS

CodAluno Nome Morada

1214 Rui Matias R: Flores, 4

1250 Ana Cruz Urb. Montinho

1356 Carla Tito R: Castro, 3

1456 Hugo Costa R: C - 1º F

Tabela: DISCIPLINAS

CodDisc Designação Nível

Ing10 Inglês 10º

Port11 Português 11º

Mat12 Matemática 12º

Fil10 Filosofia 10º

Tabela: MATRÍCULAS

CodAluno CodDisc DataMatricula

1214 Ing10 11-07-96

1250 Ing10 11-07-96

1456 Fil10 12-07-96

1356 Mat12 12-07-96


Este é o caso de uma relação binária, vejamos mais um exemplo sobre uma associação trenária do tipo vários-para-vários (m:n).

Suponhamos que pretendemos registar os filmes realizados por vários realizadores em que participam vários actores.

Se derivarmos as correspondentes tabelas iriamos obter:

ACTORES(CodActor, Nome, ...)FILMES (CodFilme, Título, ...)REALIZADORES(CodRealizador, NomeRealizador, ...)ACTORES-FILMES-REALIZADORES (CodActor, CodFilme, CodRealizador, ... )


FILMESACTORES FILMES REALIZADORESn m n m


4.4 Quadro Resumo

No quadro abaixo A, B e C representam as tabelas correspondentes às entidades A, B e C respectivamente e R representa a associação entre entidades. AtrR, representa um atributo da associação R.

ASSOCIAÇÕES

um-para-um (1:1) um-para-vários (1:n) vários-para-vários (m:n)

Unária2 tabelas

A(CodA, ... )R(CodA1, CodA2, ... )

Unária1 tabela

A(CodA1, ..., CodA2, ... )

Unária2 tabelas

A(CodA, ... )R(CodA1, CodA2, ... )

Binária

sem obrigatoriedades3 tabelas

A(CodA, ... )B(CodB, ...)R(CodA, CodB, AtrR, ...)

uma entidade obrigatória2 tabelas

se B entidade obrigatória

A(CodA, ... )B(CodB, CodA, ...)

Basta inserir o identificador da entidade não obrigatória na tabela da entidade obriga-tória.

ambas são entidadesobrigatórias

1 tabela

A(CodA, ..., CodB, ... )

Binária

sem obrigatoriedades3 tabelas


entidade lado 1 é entidadeobrigatória

3 tabelas


entidade lado n entidade obrigatória

A(CodA, ... )B(CodB, CodA, ...)

ambas são entidadesobrigatórias

3 tabelas


Binária

3 tabelas


_____________________________

Trenária

Esta associação será tratada como duas associações binárias, pelo que existirão, três tabelas para as enti-dades mais duas para as associações, ao todo cinco tabelas.

____________________________Mais do que três

entidades

Esta associação será sempre decomposta e tratada associ-ação a associação.



4.5 Exercícios

4.5.1 Desenhe o Diagrama Entidade-Associação e derive as tabelas relacionais.

A) Relacione cliente bancário com conta.

B) Relacione empregado com especialidade.

C) Uma escola tem vários clubes (Fotografia, Informática, Ténis de Mesa, ...), cada clube tem vários alunos, mas um só orientador, cada aluno só pode pertencer a vários clubes; cada clube só funciona numa mesma sala, mas como existem clubes a funcionar a dias diferentes, numa sala podem funcionar vários clubes. Cada clube tem de ser obrigatoriamente orientado por um professor, e cada professor só orienta um único clube.



D) Numa biblioteca existem vários exemplares de um livro, cada exemplar pode ser requisitado pelos leitores; cada leitor pode requisitar vários livros; no caso de não existir o livro, ou livros, pretendido(s) é feita uma reserva.

E) Numa empresa, cada departamento tem no máximo um carro, cada carro está associado pelo menos um departamento. Este carro é sempre utilizado por empregados autorizados desse departamento. Um empregado pode utilizar no máximo um carro. Um departamento pode ter vários empregados mas um empregado tem que pelo menos que trabalhar para um departamento.


Bases de Dados Normalização de tabelas

5. NORMALIZAÇÃO DE TABELAS

A normalização é um processo que consiste em estruturar as tabelas e atributos por forma a eliminar redundâncias e evitar problemas com a inserção, eliminação e actualização dos dados.

Podemos considerar três formas normais, designadas por primeira forma normal (1FN), segunda forma normal (2FN) e terceira forma normal (3FN). Existe uma relação que se estabelece entre as três formas normais, tal que,

uma tabela pode estar na primeria forma normal (1FN), mas não obedecer aos

requisitos para estar na segunda forma normal (2FN) ou na terceira forma normal

(3FN);

uma tabela pode estar na segunda forma normal (2FN), mas não estar na terceira

forma normal (3FN). No entanto as tabelas que estão na 2FN estão também na 1FN;

as tabelas que estão na terceira forma normal (3FN) estão também na 2FN e na 1FN.

Na prática, os procedimentos de normalização consideram-se geralmente satisfatórios se as tabelas atingirem a terceira forma normal (3FN). No entanto exitem situações em as tabelas mesmo estanto na terceira forma normal (3FN) não constituem o estado ideal, e para tal existem mais três formas normais conhecidas por:

forma normal de Boyce/Codd;

quarta forma normal (4FN);

quinta forma normal (5FN).

No entanto estas últimas formas normais não estão no âmbito do programa para a disciplina, pelo que conideraremos apenas a 1FN, 2FN e 3FN.

Existe uma hierarquia de formas normais que pode ser apresentada através de um conjunto de círculos concêntricos.

5.1 Primeria Forma Normal (1FN)


3FN

2FN

2FN

1FN

1FN

Se estiver na 1FN e se todos os atributos que não pertencem à chave primária dependem da totalidade da chave e não de nenhum dos seus elementos ou conjuntos isoladamente.

Todos os atributos assumem apenas

valores atómicos ou elementares, ie não

podem ser tipo subconjunto.

Se estiver na 2FN e se dos atributos que

não pertencem à chave forem inde-pendentes entre si.


Uma tabela encontra-se na primeria forma normal (1FN) se todos os seus atributos estejam definidos em domínios que contenham apenas valores atómicos, ie os domínios devem ser formados por valores elementares e não por conjuntos de valores. Aliás esta é uma condição para que uma tabela seja considerada como uma tabela do Modelo Relacional de Bases de Dados. Um atributo só pode admitir valores elementares e não conjuntos de valores.

Vejamos o seguinte exemplo… imaginemos uma tabela destinada a registar a informação sobre os alunos e as disciplinas em que estes estão matriculados.

ALUNOS(CodAluno, Nome, Morada, Disciplinas, ...)

Tabela: ALUNOS

CodAluno Nome Morada Disciplinas

1214 Rui Matias R. Flores, 4 Português, Matemática, Física

1250 Ana Cruz Urb. Montinho Latim, Português, Inglês

1356 Carla Tito R. Castro, 3 Economia, Matemática, Direito

1456 Hugo Costa R. C - 1º F Português, Matemática, Física

Esta tabela obedece à primeira forma normal (1FN), uma vez que o atributo DISCIPLINAS admite conjuntos de valores. Consideremos a tabela com alguns dados como exemplo:

Como podemos constatar, o atributo DISCIPLINAS apresenta o conjunto de disciplinas frequentadas por cada aluno.

Poderíamos repetir os valores na tabela para que o atributo DISCIPLINAS apenas contivesse um único valor. Assim a tabela ficaria com a seguinte forma:

Tabela: ALUNOS

CodAluno Nome Morada Disciplina

1214 Rui Matias R. Flores, 4 Português

1214 Rui Matias R. Flores, 4 Matemática

1214 Rui Matias R. Flores, 4 Física

1250 Ana Cruz Urb. Montinho Latim

1250 Ana Cruz Urb. Montinho Português

1250 Ana Cruz Urb. Montinho Inglês

1356 Carla Tito R. Castro, 3 Economia

1356 Carla Tito R. Castro, 3 Matemática

1356 Carla Tito R. Castro, 3 Direito

1456 Hugo Costa R. C - 1º F Português

1456 Hugo Costa R. C - 1º F Matemática

1456 Hugo Costa R. C - 1º F Física



A tabela ALUNOS agora está na 1FN, pois todos os atributos contêm apenas valores elementares. Apresernta no entanto grande redundância de informação, que se reflete na repetição dos identificadores dos nomes e moradas dos alunos.

Para além desse inconveniente, podem apontar-se ainda os seguintes:

Problemas de actualização - se a morada de um aluno for alterada, essa alteração tem de ser

feita em várias linhas da tabela, sob o risco de gerar incoerências na Base de Dados, ie numa

determinada linha o aluno poderá aparecer uma morada e noutra linha outra;

Problemas de inserção – com a tabela estruturada desta maneira torna-se impossível registar

um aluno que não esteja matriculado a nenhuma disciplina mas que se encontra a fazer apenas

exames, sem o atributo DISCIPLINA fique com valor nulo não obedecendo à regra de

integridade de entidade;

Problemas de eliminação - porque para anular a matrícula de um aluno implica ter de eliminar

várias linhas da tabela, e mesmo perder a informação do aluno, tal como NÚMERO, NOME e

MORADA.

Estes problemas acabam se criarmos uma tabela para registar os dados dos alunos, outra para registar os dados relativos a cada disciplina e uma outra para registar os dados da matricula de cada aluno em cada disciplina.Derivando as tabelas relacionais poderiamos obter:

ALUNOS (CodAluno, Nome, Morada, ...)DISCIPLINAS (CodDisciplina, Designação, ... )MATRÍCULAS (CodAluno, CodDisciplina, DataMatrícula)

Esta decomposição de tabelas permite eliminar os problemas de actualização, eliminação e inserção de dados nas tabelas.

5.2 Segunda Forma Normal (2FN)

Antes de vermos que condições uma tabela deve obedecer para estar na 2FN é necessário ver o conceito de dependência funcional trivial ou simples e dependência funcional elementar entre atributos.

5.2.1 Dependência Funcional Trivial ou Simples e Dependência Funcional Elementar

Considerarmos que uma tabela A tem os atributos X, Y, Z e W tal que:

A (x, y , z, w)



Se o atributo Z é funcionalmente dependente do atributo X, para um determinado valor de X, o valor de Z é sempre o mesmo. Pelo que X é um atributo determinante e Z o atributo dependente. A este tipo de dependência dá-se o nome de dependência elementar trivial ou simples. Vejamos a seguinte tabela:

Podemos observar que sempre que o valor de X é 1 o valor de Z é 2 (1ª, 3ª e 4ª linhas); sempre que X é 2 Z vale 5 (2ª e 5ª linhas). Como a cada valor de X está sempre associado o mesmo valor de Z, dizemos que existe uma dependência funcional simples entre o atributo X e o atributo Z.

Também pode acontecer o caso em que temos na tabela A o atributo W dependa não de um mas de dois atributos X e Y.

Observemos a tabela anterior para verificar que, sempre que existe uma ocorrência de X e Y, com X igual a 1 e Y igual a 3 respectivamente, o valor de W é sempre 7 (1ª e 4ª linhas). Da mesma maneira na 2ª e 5ª linhas, sempre que X e Y valem 2 e 4 respectivamente o valor de W é sempre 8.

Se neste segundo caso considerarmos que os atributos X e Y são chave primária e se o atributo W depender funcionalmente dos atributos X e Y como um conjunto e não depender de nenhum deles isoladamente, diz-se que o atributo W depende funcionalmente de X e Y como conjunto. A este tipo de dependência dá-se o nome de dependência funcional elementar.

5.2.2 Condições para que uma tabela esteja na 2FN

Consideremos uma tabela constituída por uma única chave candidata que funciona como chave primária. Esta tabela estará na segunda forma normal (2FN) se:

estiver na primeria forma normal (1FN);

e se todos os atributos que não pertencem à chave, dependem da chave através de uma

dependência funcional elementar (ie, dependem da totalidade da chave e não de um dos seus

atributos ou subconjuntos isoladamente).

Esta condição evidentemente só se aplica no caso da chave ser composta por mais de um


Tabela: A

X Y Z W

1 3 2 7

2 4 5 8

1 5 2 4

1 3 2 7

2 4 5 8

7 3 4 2


atributo. Caso a chave seja constituída por um único atributo a condição imposta é que os

restantes atributos dependam funcionalmente da chave.

Retomemos o exemplo dos alunos e das disciplinas, e consideremos a seguinte tabela:

ALUNOS (CodAluno, Nome, Morada, CodDisciplina, DesignaçãoDisciplina)

A chave primária é composta pelos atributos CodAluno e CodDisciplina.A condição para que esteja na 2FN é que todos os atributos que não pertencem à chave

dependam da totalidade da chave, o que não é o caso. Vejamos, os atributos Nome e Morada apenas depende do atributo CodAluno e o atributo DesignaçãoDisciplina apenas depende do atributo CodDisciplina, pelo que esta tabela não está normalizada, não obedece à 2FN. Para tal teríamos de decompô-la em três tabelas:

ALUNOS (CodAluno, Nome, Morada, ...)DISCIPLINAS (CodDisciplina, Designação, ... )MATRÍCULAS (CodAluno, CodDisciplina, DataMatrícula)

De notar que o atributo DataMatrícula depende da totalidade da chave primária da tabela MATRÍCULAS.

5.3. Terceira Forma Normal (3FN)

Para que uma tabela esteja na 3FN é necessário que:

esteja na 2FN;

não haver atributos que não fazem parte da chave que sejam funcionalmente

dependentes de qualquer combinação dos restantes.

Para além das condições exigidas para que a tabela esteja na 2FN, a terceira forma normal impõe que cada atributo dependa apenas da chave e não de qualquer outro atributo ou conjunto de atributos. O objectivo é eliminar aquilo que se chama de dependências transitivas. Voltemos ao exemplo da tabela A com os atributos X, Y e Z, em que X é a chave primária. Os atributos Y e Z dependem funcionalmente da chave X. Todavia verifica-se uma transitividade, o atributo Z também depende funcionalmente de Y.

Uma vez que se verifica essa transitividade, o atributo Z não depende apenas da chave, depende também de outro atributo. Não estão portanto reunidas as condições para que a tabela possa estar na 3FN, para tal era necessário que os campos que não pertencem à chave fossem mutuamente independentes.

Consideremos a seguinte tabela:

JOGO (CodJogo, Estádio, NomeÁrbitro, CategoriaÁrbitro)



Nesta tabela verifica-se que os atributos são funcionalmente dependentes da chave, mas existe uma transitividade, o atributo CategoriaÁrbitro depende funcionalmente de NomeÁrbitro, ie os atributos CategoriaÁrbitro e NomeÁrbitro não são independentes, pelo que a tabela não está na 3FN.

Esta situação acarreta problemas a nível de inserção, actualização e eliminação de dados.

Em termos de actualização, a informação relativa aos árbitro irá aparecer repetida na tabela. E se o árbitro mudar de categoria, essa alteração deverá ser feita em várias ocorrências desse CodÁrbitro. Se houver uma única tabela relativa aos árbitros, essa actualização seria feita apenas numa única ocorrência, uma única vez.

Quanto ao problema da inserção, significa que se existir um árbitro que não tenha ainda arbitrado nenhum jogo, mas estiver já associado a uma categoria, ele não poderá ser registado nesta tabela.

Quanto ao problema da eliminação, vejamos o caso em que existe um árbitro que tenha arbitrado um único jogo, se eliminarmos essa ocorrência ficaremos sem informção relativamente a esse árbitro.

A normalização transforma esta tabela no seguinte conjunto de tabelas, todas na 3FN:

JOGO (CodJogo, Estádio) ÁRBITRO (CodÁrbitro, Nome-árbitro, Categoria-árbitro)JOGO-ÁRBITRO (CodJogo, CodÁrbitro)

Se as tabelas de uma Base de Dados já estiverem nas três formas normais consideradas 1FN, 2FN e 3FN, então podemos considerar que estão normalizadas, salvo raras excepções em que será necessário verificar se estão normalizadas segundo a forma normal de Boyce Codd, a 4FN e a 5FN, mas como não estão no âmbito do programa, consideraremos apenas as três primeiras.


Bases de Dados Operações sobre tabelas

6. OPERAÇÕES SOBRE TABELAS

Numa Base de Dados relacional, a informação está organizada sob a forma de tabelas que

podem ser de dois tipos: tabelas base e tabelas virtuais. As tabelas base são aquelas que existem

como estrutura de dados armazenadas num suporte físico de Base de Dados. Por seu lado, as tabelas

virtuais resultam de querys.

Uma query é o que em português se designa por consulta, e uma query é uma consulta à

Base de Dados e consiste na execução de uma ou mais operações sobre tabelas de base ou sobre as

tabelas virtuais que resultam de outras consultas.

As operações de consulta à Base de Dados são normalmente feitas às tabelas base. As

operações fundamentais feitas sobre uma base de dados são:

Selecção\Restrição

Projecção

Produto Cartesiano

União

Diferença

Divisão

Intercepção

Junção (join)

6.1 Selecção ou Restrição

Uma selecção é uma operação aplicada sobre uma tabela da base de dados com a finalidade de extrair um subconjunto de registos que obedeçam a uma ou mais condições.

Uma condição pode envolver um ou mais campos de uma tabela e são definidas recorrendo a operadores relacionais =, <>, >, <, etc.

TABELA ou QUERYQUERY


Selecção


É possível executar uma operação de selecção a uma tabela de ALUNOS para obter todos os alunos que verifiquem a condição Idade>18. Neste caso, Idade seria um dos campos da tabela ALUNOS e o resultado da consulta seriam todos os alunos com idade superior a 18 anos. Vejamos a tabela de ALUNOS e o resultado da query.

Uma consulta à tabela no sentido de obter apenas os elementos relativos aos alunos com mais de 18 anos pode ser informalmente definida da seguinte maneira:

SELECIONAR CodAluno, Nome, IdadeDA TABELA ALUNOSONDE Idade > 18

Se ao query fosse dado o nome ALUNOS COM MAIS DE 18 ANOS, o resultado apareceria como uma tabela virtual ou query com o aspecto que se segue:


Tabela: ALUNOS

CodAluno Nome Idade

1214 Rui Matias 19

1215 Rafael Matos 17

1216 Rui Santos 18

1250 Ana Cruz 20

1251 Anabela Carmo 22

1252 Antónia Costa 16

1356 Carla Tito 15

Query: ALUNOS COM MAIS DE 18 ANOS

CodAluno Nome Idade

1214 Rui Matias 19

1250 Ana Cruz 20



Esta consulta traduz uma operação de selecção sobre a tabela ALUNOS e constitui um subconjunto de registos dessa tabela onde o campo Idade assume um valor superior a 18.

Uma restrição pode envolver várias condições, como se pode verificar através da consulta executada sobre a mesma tabela ALUNOS com o objectivo de obter os alunos com idades compreendidas entre os 17 e os 20 anos inclusivé. Informalmente poderiamos defini-la como:

SELECCIONAR CodAluno, Nome, IdadeDA TABELA ALUNOSONDE idade>=17 e idade <=20

6.2 Projecção

Uma projecção é uma operação que selecciona um subconjunto de campos de uma tabela.

TABELA ou QUERY QUERY


Query: ALUNOS ENTRE OS 17 E OS 20 ANOS

CodAluno Nome Idade

1214 Rui Matias 19


1216 Rui Santos 18

1250 Ana Cruz 20

Projecção


Vamos ilustrar a aplicação da operação de projecção sobre a tabela de ALUNOS definida do seguinte modo:

ALUNOS (CodAluno, Nome, Morada, Localidade, Idade)

Uma

projecção da tabela ALUNOS pode ser expressa informalmente da seguinte maneira:

SELECCIONAR Nome, Localidade, Idade DA TABELA ALUNOS

Se a esta consulta dermos o nome de NOMES LOCALIDADE E IDADE o resultado seria:

Para ilustrar o facto de que as consultas podem ser obtidas através de operações executadas sobre o resultado de outras consultas, ie querys a partir de outros querys, vamos criar um nova projecção sobre o query anterior definido por:

SELECCIONAR Nome, LocalidadeDA QUERY NOMES LOCALIDADE E IDADES

Se a nova query fosse designada por NOMES E LOCALIDADE , o resultado seria:

Tabela: ALUNOS

CodAluno Nome Morada Localidade Idade

1214 Rui Matias R: Flores, 4 Portimão 19

1250 Ana Cruz Urb. Montinho Faro 17

1356 Carla Tito R: Castro, 3 Faro 18

1456 Hugo Costa R: C - 1º F Lisboa 20

Query: NOMES LOCALIDADE E IDADES

Nome Localidade Idades

Rui Matias Portimão 19

Ana Cruz Faro 17

Carla Tito Faro 18

Hugo Costa Lisboa 20


De notar que o mesmo resultado se poderia obter executando a consulta sobre a tabela original de ALUNOS:

SELECCIONAR Nome, LocalidadeDA TABELA ALUNOS

A uma consulta ou query poderá ser aplicada uma operação de selecção e de projecção simultaneamente. Para obter Nome de todos os alunos com idade superior a 16 anos e que residem em Faro bastava fazer

SELECCIONAR NomeDA TABELA ALUNOSONDE Idade > 16 e Localidade = Faro

O resultado deste query NOMES ALUNOS DE FARO seria o seguinte:

Query: NOMES LOCALIDADE

Nome Localidade

Rui Matias Portimão

Ana Cruz Faro

Carla Tito Faro

Hugo Costa Lisboa


Apenas dois registos que obedecem às condições colocadas pela operação de restrição. Por seu turno a projecção restringe as colunas ao campo Nome.

Query: NOMES ALUNOS DE FARO

Nome

Ana Cruz

Carla Tito


6.3 Produto Cartesiano

O produto cartesiano de duas tabelas A e B é uma nova tabela formada por um conjunto de campos igual ao conjunto de campos de A acrescido dos campos de B. E será formada por todas as combinações de cada linha de A com cada linha de B.

Para que a operação seja possível não devem existir atributos comuns a ambas as tabelas. Se assim, fosse iria resultar numa tabela com atributos repetidos violando o princípio das tabelas relacionais.

O número de campos da nova tabela será igual à soma dos campos das duas tabelas.

TABELA A TABELA B

PRODUTO DE A POR B

O número de registos será igual ao número de registos de A vezes o número de registos de B. Esta operação tem pouco interesse prático, no entanto, é importante como passo intermédio para da operação de junção (join).


6.4 União

Esta é uma operação realizada entre duas tabelas. Para que essa operação seja possível, é necessário que as duas tabelas tenham o mesmo cabeçalho, ie tenham os mesmos campos definidos nos mesmos domínios. As tabelas que possuam esses requisitos dizem-se compatíveis para a operação de união.

TABELA A TABELA B

A UNIÃO COM B

A união das duas tabelas A e B produz uma terceira C, constituida por todas as linhas que pertençam a A ou a B. Considere-se o seguinte exemplo de alunos de duas escolas registados em tabelas diferentes, mas com a mesma estrutura e que se quer unir numa única.

A tabela resultante da união dos alunos das duas escolas seria:

Muito embora a união tivesse sido demonstrada envolvendo apenas duas tabelas, ela pode ser aplicada a três ou mais tabelas, desde que obedeçam à condição de ter os mesmos campos definidos nos mesmos domínios.

Tabela: ALUNOS ESCOLA 1 Tabela: ALUNOS ESCOLA 2

CodAluno Nome Idade CodAluno Nome Idade

1214 Rui Matias 19 1250 Ana Cruz 20

1215 Rafael Matos 17 1251 Anabela Carmo 22

1216 Rui Santos 18 1252 Antónia Costa 16

1356 Carla Tito 15

Tabela: ALUNOS

CodAluno Nome Idade

1214 Rui Matias 19


1216 Rui Santos 18

1250 Ana Cruz 20


1252 Antónia Costa 16

1356 Carla Tito 15


6.5 Diferença

A diferença é uma operação entre duas tabelas que devem possuir o mesmo campos definidos nos mesmos domínios.

TABELA B TABELA B

DIFERENÇA ENTRE A E B

O resultado da diferença entre as tabelas A e B é uma tabela C que contém as linhas que pertencem a A, mas que não pertencem a B.

6.6 Divisão

A divisão é uma operação que pode ser executada entre duas tabelas que possuam pelo menos um atributo em comum definido no mesmo domínio.

TABELA A TABELA B

DIVISÃO DE A POR B

Considere-se a tabela A com os atributos

x e y e a tabela B constituída apenas pelo atributo

y (definido no mesmo domínio do atributo y da tabela A).

A tabela que resulta da divisão de A por B é

Uma tabela constituída apenas pelo atributo x e contendo os registos que na tabela A têm como valor no atributo y todos os y constantes na tabela B.

Exemplificando, consideremos duas tabelas

Tabela: AX Ya ba ed eg hh bk e

Tabela: BYb

Tabela: A dividida por BXah

Na tabela A, só as linhas em que o atributo x contém os valores a e h, é que possuem o valor b no atributo Y, que é o único valor que a tabela B possui.

6.7 Intercepção

A intercepção é uma operação entre duas tabelas que possuam o mesmo cabeçalho e os mesmos domínios para os seus atributos.

Tabela A Tabela B

A INTERCEPÇÃO COM B

O resultado da intercepção das duas tabelas é uma nova tabela com o mesmo cabeçalho e formada pelas linhas que são comuns a ambas as tabelas. Vejamos o seguinte caso:

O resultado da intercepção é constituído pelo registo comum às duas tabelas.

6.8 Junção ( Join )

1214 Rui Matias 19

CodAluno Nome Idade

Tabela: INTERCEPÇÃO ESCOLA 1 COM ESCOLA 2

Tabela: ALUNOS ESCOLA 1 Tabela: ALUNOS ESCOLA 2

CodAluno Nome Idade CodAluno Nome Idade

1214 Rui Matias 19 1250 Ana Cruz 20

1215 Rafael Matos 17 1251 Anabela Carmo 22

1216 Rui Santos 18 1214 Rui Matias 19

1356 Carla Tito 15

Esta operação pode ser definida informalmente como a junção dos elementos de duas tabelas com base comum.

Tabela A Tabela B

JUNÇÃO ENTRE A E B

O seguinte exemplo ilustra o conceito de junção de duas tabelas. Considere-se as tabelas A e B

Tabela: AX Y Za b 1c d 2e F 1g h 2i j 3k l 1

Tabela: BU V Zm n 1o p 2q r 1s t 2u v 2

Tabela: A dividida por BX Y Z U Va b 1 m na b 1 q rc d 2 o pc d 2 s tc d 2 u ve f 1 m ne f 1 q rg h 2 o pg h 2 s tg h 2 u vk l 1 m nk l 1 q r

Os resultados da tabela da junção de A com B, explica-se do seguinte modo:

As duas tabelas têm um atributo comum Z.

O primeiro registo da tabela A o campo Z tem o valor 1; por sua vez, na tabela B, o campo Z tem o valor 1 nas linhas 1 e 3.

Daí que os dois primeiros registos da tabela de junção sejam a conjunção dos valores dos campos da primeira linha da tabela A com os valores dos campos das linhas 1 e 3 da tabela B.

As restantes linhas explicam-se da mesma forma.

O tipo de junção apresentado é a junção natural (natural join), pois baseia-se na relação de igualdade entre os valores dos campos. Nada impede, porém, que a operação seja executada considerando outro operador, que não a igualdade, na comparação dos campos.

De observar que a junção é uma projecção da restrição de um produto. Basta que se obtenha primeiro o produto de duas tabelas, e depois se aplique uma restrição que seleccione apenas os registos em que se verifique igualdade nos valores dos campos em determinado campo ou campos. Se ao resultado dessa restrição for aplicada uma projecção que elimine um dos campos para evitar existirem dois campos com o mesma designação, o resultado será o mesmo.

Bases de Dados A linguagem SQL

7. A LINGUAGEM SQL

A maior parte dos sistemas de gestão de bases de dados são sistemas relacionais e muitos desses sistemas são também sistemas SQL, por suportarem instruções do SQL.

O SQL significa Structured Query Language, derivou de uma outra linguagem SQUARE e lê-se como SEQUEL, foi definida por D. D. Chamberlin dos Laboratórios de Pesquisa da IBM em S. José Califórnia. O primeiro protótipo da linguagem foi implementado sobre a designação de System R. Enumeros produtos usaram depois de 70 a interface do SQL, mas seria a ANSI (American National Standats Institute) e a ISO (International Standarts Organization) a ditar um dialecto para o SQL como a interface para os sistemas relacionais. Muitos dos sistemas gestores de bases de dados usam o SQL é o caso do Informix, Oracle, Ingres, DB2, e o Microsoft Access.

A linguaguem SQL possui comandos que podemos englobar em três grandes categorias:

DDL (Data Definition Language) – Linguagem de definição de dados;

DML (Data Manipulation Language) – Linguagem de manipulação de dados;

DCL (Data Control Language) – Linguagem de control dos dados.

7.1 Linguagem de definição dos dados

Os comandos que pertencem a esta categoria são utilizados para criar e alterar a base de dados, tabelas e índices.

CREATE - comando usado para criar uma nova base de dados, e para criar novas tabelas numa base de dados.

DROP - é um comando utilizado para eliminar tabelas e índices.

ALTER - é usado para modificar uma tabela (criar, alterar ou eliminar campos).

7.2 Linguagem de manipulação dos dados

Os comandos que pertencem a esta categoria permitem actualizar e extrair informação da base de dados.

SELECT – comando usado para executar pesquisas à base de dados.

INSERT – permite introduzir nova informação na base de dados.

UPDATE – permite actualizar a informação contida em registos e campos.

DELETE – elimina registos das tabelas da base de dados.


7. 3 Linguagem de controlo dos dados

Os comandos desta secção permitem o controlo sob a informação na base de dados, pela atribuição de permissões de acesso, gestão da segurança e mesmo a anulação das transacções efectuadas na base de dados.

GRANT – permite conceder permissões de acesso à base de dados.

REVOKE – permite retirar as permissões de acesso à base de dados.

CONNECT – concede permissões de acesso às tabelas existentes.

DBA – concede todos os privilégios de administração da base de dados.

RESOURCE – concede permissões para aceder às tabelas existentes e criar novas tabelas.

COMMIT – permite que as transacções efectuadas sejam tornados permanentes.

ROLLBACK – permite que as transacções efectuadas sejam anuladas.


7.4 Comando SELECT

Tal como em português o comando SELECT quer dizer seleccionar, ie o comando SELECT permite efectuar pesquisas e sub-perquisas sobre a informação contida numa base de dados, mostrando o resultado sobre a forma de tabela virtual. O comando SELECT tem a seguinte sintaxe:

SELECT [ DISTINCT | DISTINCTROW | TOP n [PERCENT] ] <lista_campos>FROM <nome_tabela> {<alias>}{, <nome_tabela> {<alias>}}[WHERE <critério_pesquisa>][GROUP BY lista_campos_a_agrupar ][HAVING <critério_para_agrupar>][ORDER BY <nome_campo> [ASC|DESC] {,<nome_campo> [ASC|DESC]}]

O comando SELECT tem de possuir obrigatoriamente as duas primeiras linhas, todas outras opções são indicadas entre parentesis rectos:

SELECT lista_camposFROM lista_tabelas;

lista_campos

A lista_campos, é uma lista de campos e/ou expressões separadas por vírgulas. Se quisermos seleccionar todas as colunas de uma tabela, basta indicarmos o símbolo *.

Pelo que para seleccionar todas os campos da tabela alunos fariamos:

SELECT *FROM alunos;

Caso existam campos de mais do que uma tabela indicados nesta lista, cada campo será precedido pelo nome da tabela, separado de um ponto

SELECT aluno.nome, curso.designaçãoFROM aluno, curso;

DISTINCT

A opção DISTINCT omitirá registos que contém dados duplicados nos campos indicados.

Suponhamos que queremos ver todos os últimos nome dos autores, e apenas este campo, queremos sem dúvida evitar repetições de valores desse campo. Então faríamos:

SELECT DISTINCT ultnomeFROM autores;

Pelo que se tivermos vários autores em que o último nome é Castro, a tabela virtual resultante apenas conterá um registo com o nome Castro.

Podem ser indicados mais do que um campo, pelo que na tabela virtual uma combinação desses campos.


DISTINCTROW

A oção DISTINCTROW omitirá dados baseados em registos integralmente duplicados.Por exemplo poderiamos criar um query que fará a junção (join) nas tabelas de Leitores e de

Requisições pelo campo codleitor. A tabela de leitores não contém valores duplicados no campo codleitor, porque se trata de um campo chave, mas isso não acontece no caso da tabela de Requisições.

Imaginemos que queremos fazer o join das duas tabelas baseadas no campo codleitor, então faríamos:

SELECT DISTINCTROW nome FROM leitoresINNER JOIN requisições ON leitores.codleitor = requisições.codleitorORDER BY nome;

Se omitirmos o DISTINCTROW, a tabela virtual resultante mostrará várias linhas para cada leitor que tem mais do que uma requisição.

TOP n [PERCENT]

Devolve um certo número de registos que caibam no topo ou em baixo de um intervalo indicado na cláusula ORDER BY.

Suponhamos que queremos o conjunto dos 5 registos da tabela LEITORES, dos leitores mais velhos, que satisfaçam a condição de morar em Faro.

SELECT TOP 5, PrimNome, OutrosNomes, UltNomeFROM AlunosWHERE localidade = ”Faro” ORDER BY idade DESC;

Se quisermos 10 % dos leitores, dos leitores mais velhos, que satisfaçam a mesma condição, teríamos:

SELECT TOP 10 PERCENT, PrimNome, OutrosNomes, UltNomeFROM AlunosWHERE localidade = ”Faro” ORDER BY idade DESC;


7.4.1 Cláusula FROM

SELECT <lista_campos>FROM <nome_tabela> {<alias>}{, <nome_tabela> {<alias>}}

A cláusula FROM lista_tabelas, serve para indicar a lista de tabelas sobre as quais será aplicada a pesquisa, devem ser separadas por vírgulas.

nome_tabelas alias

A lista_tabelas indica as tabelas que participam na pesquisa, e aparecem separadas por vírgulas.

Poder-se-á criar um alias da tabela, isto é um outro nome pelo qual a tabela é conhecida, permitindo que sejam feitas operações sobre o mesmo campo,

SELECT X.codaluno,Y.codalunoFROM alunos AS X, alunos AS Y ;

7.4.2 Expressões e Funções de agregação

Uma expressão é uma combinação de colunas ligadas por operadores aritméticos. Os operadores aritméticos são os seguintes:

+ adição- subtração* multiplicação/ divisão

As funções de agregação do SQL são usadas nas expressões, consideremos as seguintes:

Count (*) conta o número de registos seleccionados.Sum (exp) soma os valores de um campo ou combinação de campos para

cada registo.Avg (exp) faz a média de todos os valores da expressão indicada.Max (exp) calcula o valor máximo da expressão indicada para todos os

registos.Min (exp) calcula o valor mínimo da expressão indicada para todos os

registos.


Vejamos alguns exemplos de aplicação destas funções para o sistema da biblioteca que temos vindo a estudar:

a) determinar o número de multas atribuidas aos leitores da nossa base de dados;

SELECT Count(*) AS TotalMultasFROM multas;

b) determinar qual a multa mais alta a mais baixa atribuída a um leitor;

SELECT Max (valor) AS MaisAlta, Min (valor) AS MaisBaixaFROM multas;

b) somar todas o valor de todas as multas já registadas;

SELECT Sum(valor)FROM multas;


7.4.3 Cláusula WHERE

Esta claúsula estabelece o critério que define que registos das tabelas indicadas na cláusula WHERE são afectadas pelo SELECT e tem o seguinte formato:

SELECT <lista_campos>FROM <lista_tabelas> WHERE <critério_pesquisa>

No critério_pesquisa aparecem os operadores lógicos AND, OR e NOT.

Existem três tipos de critérios de pesquisa:

I. Comparação;II. Ligação;III. Sub-interrogações (subquerys).

I. Critérios de pesquisa por comparação

a) Operador_relacional (=, <>, >, <=, >=, <)

b) [NOT] BETWEEN expressão1 AND expressão2

A palavra BETWEEN significa entre (dois valores dados pelas duas expressões).

c) [NOT] IN (lista_itens)

A palavra IN significa contido em (na lista de itens indicada).

d) [NOT] LIKE “string”

A palavra LIKE significa igual a. Aplica-se a campos tipo text.A “string” é um conjunto de caracteres.

Podemos usar caracteres especiais na string que permitirão pesquisar com mais precisão a informação que pretendemos.

* zero ou mais caracteres? um só caracter[a-z] qualquer letra minúscula[a0-2-] pesquisa o a, o 0, 1 e 2 e o símbolo –[a-z,A-Z] qualquer caracter que seja uma letra\ o próximo caracter não tem um significado real\* encontrar o símbolo *\\ encontrar o símbolo \


Vejamos mais alguns exemplos do comando SELECT com a cláusula WHERE.

a) seleccionar o codleitor que tem multas de valor superior a 200.

SELECT codleitorFROM multasWHERE valor > 200

O comando SELECT indica quais os campos que devem figurar o resultado da query.

Do ponto de vista das operações relacionais, trata-se de uma projecção da tabela multas.

A cláusula FROM indica o nome da tabela. A cláusula WHERE estabelece uma condição a que as linhas as tabela devem obedecer para figurarem na query. Só serão seleccionadas as linhas onde o campo valor possua um valor maior que 200. Ao fazer uma selecção de linhas, o WHERE estará a fazer uma restrição sobre a tabela multas.

b) seleccionar os leitores cujo telefone comece por 089.

SELECT telefoneFROM leitoresWHERE telefone LIKE “089*”

c) seleccionar os leitores cujo nome comece por uma letra de R a Z (maiúsculas ou minúsculas).

SELECT nomeFROM leitoresWHERE nome LIKE “[R-Z]*” OR nome LIKE “[r-z]*”

II. Critérios de pesquisa por Ligação

É fundamental que estejam definidos os relacionamentos entre as tabelas sobre as quais se deseja fazer um query envolvendo o comando SELECT com a cláusula WHERE.

A ligação é feita entre um ou mais campos de uma tabela e um ou mais campos da outra tabela. Caso os campos que se deseja estabelecer a ligação sejam iguais, deve-se preceder o nome do campo com o nome da tabela a que diz respeito.

O resultado é um tabela virtual que satisfaz a condição indicada na cláusula WHERE.


Vejamos mais alguns exemplos do comando SELECT com a cláusula WHERE.

a) mostrar o título dos livros requisitados pelo leitor numero 194.

SELECT livros.tituloFROM requisitardevolver reqdev, livrosWHERE livros.isbn = reqdev.isbn AND reqdev.codleitor = 194

b) mostrar o título e a localização de todos os livros cujo assunto seja generalidades.

SELECT livros.titulo, livros.localizaçãoFROM livros, assuntos, livrosassuntos livassWHERE livros.isbn = livass.isbn AND lisass.codassunto = assuntos.codassunto

AND assuntos.nomeassunto LIKE “generalidades”

Este comando ilustra uma operação de junção (join), a qual sabemos é decomposta numa projecção de uma restrição de um produto.

Se observarmos o comando atentamente verificamos que a cláusula FROM define um produto entre as tabelas livros, assuntos e livrosassuntos.

Os campos indicados logo depois do comando SELECT executam uma projecção, definindo os campos que irão figurar na tabela virtual resultante do query.

A cláusula WHERE estabelece a restrição, definindo as condições a que uma linha da tabela produto deve obedecer para que ser possa figurar no resultado da query.

III. sub-interrogações

É que podemos fazer uma sub-query, ie, o critério de pesquisa da cláusula WHERE pode ser uma novo comando SELECT.

Se fizermos uma sub-query o comando SELECT não poderá conter a cláusula ORDER BY, e apenas poderá ter um campo na lista de campos.

É possível usar uma das cinco opções:

WHERE expressão operador_relacional [ALL |ANY |SOME | [NOT ]IN | [NOT ] EXIST ]


Vejamos mais alguns exemplos do comando SELECT com a cláusula WHERE:

a) O nome dos leitores que ainda não devolveram os livros

SELECT primnome, ultnomeFROM leitorWHERE codreq = ANY

(SELECT codreqFROM requisitardevolverWHERE datadev is NULL);

No exemplo apresentado temos uma query dentro outra query (ie, uma query com subquery). Neste caso, a subquery determinará todos os codreq da tabela reqdev em que o campo datadev estará em branco. A query princípal mostrará o primeiro e o último nome dos leitores cujo codleitor figure nos registos encontrados pela subquery.

b) Todos os ISBN ilustrados cujo título é Os Lusíadas

SELECT isbnFROM livrosWHERE ilustra = “S” AND isbn IN

(SELECT isbnFROM livrosWHERE titulo = “Os Lusíadas”);

No exemplo apresentado atrás, temos querys dentro de querys (ie, uma query com subquery). Como explicação do funcionamento da segunda query poderíamos dizer que a subquery, indicada entre parentesis, irá determinar os isbn de todos os livros da tabela livros em que o título seja Os Lusíadas. Desses isbn encontrados, o comando irá mostrar apenas aqueles em que o campo ilustra tenha o valor S. Ie, na globalidade apenas serão mostrados os isbn dos livros com o titulo Os Lusíadas e com ilustrações.


Exercícios Propostos I

Resolve os seguintes exercícios no Microsoft Access usando comandos SQL.Os exercícios devem ser resolvidos sobre a base de dados AlunosCursos.mdb

1. Projecção e Restrição sobre a tabela de ALUNO.

“ Obter uma lista com os nomes e moradas dos alunos que moram em Faro.”

2. Junção (Join) da tabela aluno com a tabela DISCIPLINA.

“ Obter uma lista com os nomes dos alunos, a disciplina e a nota do 3º período de todos os alunos que não moram em Faro.”

3. Funções Max e Min.

“Obter a idade do aluno mais velho, e a idade do aluno mais novo.”

4. Função Avg.


“Obter a média de idades dos alunos de Faro.”

5. “Obter o nome dos alunos matriculados à disciplina de EOTD12.”

6. “Obter a média das notas finais do aluno nº 3 na disciplina de AI durante os três anos.”


7.4.4 Cláusula GROUP BY

A cláusula GROUP BY combina os registos com valores iguais de um campo num único registo. Cria-se um valor para cada registo se incluirmos as funções de agregação do SQL, tal como o Sum ou o Count, no comando SELECT.

SELECT <lista_campos>FROM <lista_tabelas> WHERE <critério_pesquisa>[GROUP BY lista_campos_a_agrupar ]

Na lista_campos_a_agrupar podem estar até 10 campos usados para agrupar os registos. A ordem dos campos determina os vários níveis de agrupamento, desde o nível mais alto até ao nível mais baixo de agrupamento.

Esta cláusula é opcional.

Usamos o comando WHERE para excluir registos que não queremos agrupar, e usamos a cláusula HAVING para filtrar os registos depois de agrupados.

Um campo na lista_campos_a_agrupar de qualquer tabela indicada na opção FROM, mesmo que não seja incluída logo após o SELECT. O SGBD não pode agrupar campos do tipo de dados memo e OLE objects.

Vejamos o seguinte exemplo do comando SELECT com a cláusula GROUP BY.

a) Contar o número de requisições de livros de cada leitor.

SELECT codleitor, Count(isbn) AS Total_RequisiçõesFROM RequisitarDevolverGROUP BY codleitor


7.4.5 Cláusula HAVING

Especifica que registos agrupados serão mostrados pelo comando SELECT com a cláusula GROUP BY. Depois do GROUP BY ter agrupado os registos, o HAVING mostrará os registos agrupados que satisfaçam as condições da cláusula HAVING.

SELECT <lista_campos>FROM <lista_tabela> [WHERE <critério_pesquisa>][GROUP BY lista_campos_a_agrupar ][HAVING <critério_para_agrupar>]

A claúsula HAVING é opcial.

O critério_para_agrupar é uma expressão que determina que registos agrupados serão mostrados.

O HAVING pode significar “que tenham”, depois dos registos terem sido agrupados pelo comando GROUP BY, o HAVING determinará que registos serão mostrados dentre os registos agrupados.

Podemos incluír mais do que um campo na cláusula ORDER BY. Os registos serão classificados primeiro pelo primeiro campo listado após ORDER BY. Registos com nomes iguais neste primeiro campo, serão classificados pelo valor do segundo campo, e assim por diante.

Vejamos o seguinte exemplo.

a) Mostrar o total de requisições de cada leitor, para leitores com mais de 3 requisições.

SELECT codleitor, count(isbn) AS TotalRequisiçõesFROM requisitardevolverGROUP BY codleitorHAVING count(isbn) > 3;

b) Mostrar a média de requisições de cada leitor com média superior ou igual a 20 requisições.

SELECT codleitor, avg(isbn) AS MédiaRequisiçõesFROM requisitardevolverGROUP BY codleitorHAVING avg(isbn) > = 20;


7.4.6 Cláusula ORDER BY

Classifica os dados exibidos por um campo ou campos em ordem ascendente ou descendente.

SELECT <lista_campos>FROM <lista_tabelas> [WHERE <critério_pesquisa>][ORDER BY <nome_campo> [ASC|DESC] {,<nome_campo> [ASC|DESC]}]

Por defeito a ordem de classificação é ascendente de (A-Z,0-9). A palavra reservada ASC no final de cada campo que se queira classificar por odem ascendente. E a palavra reservda DESC utiliza-se depois de cada campo que se deseja classificar por ordem descendente.

Vejamos alguns exemplos.

a) Lista classificada por ordem crecente pelo último nome dos leitores registados. Para leitores com nome igual ordena depois pelo primeiro nome.

SELECT ultnome, primnomeFROM leitorORDER BY ultnome, primnome

b) Lista classificada por ordem descendente pelo titulo dos livros registados.

SELECT tituloFROM livrosORDER BY titulo DESC


EXERCÍCIOS PROPOSTOS II


1. “ Número de matriculas de cada aluno.”

2. “Lista classificada por ordem crescente de todos os alunos registados.”

3. “Média do 3º período de cada aluno, para médias superiores ou iguais a 14.”

4. “Lista classificada por ordem decrescente de todos os alunos registados.”


5. “Seleccionar o número e o nome dos alunos que estejam matriculados apenas a uma disciplina”.

6. “Professores que só estejam a leccionar uma disciplina”

7. “Todas as disciplinas e respectivos professores do curso de Informática. As colunas da tabela virtual deverem ser Código, Disciplina e Professor. Em que código corresponde ao código da disciplina indicada como Disciplina e Professor corresponde ao nome do professor. Lista ordenada pela designação da disciplina.


EXERCÍCIOS PROPOSTOS II


7. “ Número de matriculas de cada aluno.”

SELECT codaluno, Count(coddisciplina) AS TotalMatriculasFROM matriculaGROUP BY codaluno;

8. “Lista classificada por ordem crescente de todos os alunos registados.”

SELECT *FROM alunoORDER BY nome ;

9. “Média do 3º período de cada aluno, para médias superiores ou iguais a 14.”

SELECT codaluno, Avg(nt3p) AS MediaFROM matriculaGROUP BY codalunoHAVING Avg(nt3p) >= 14;

10. “Lista classificada por ordem decrescente de todos os alunos registados.”

SELECT *FROM alunoORDER BY nome DESC;


11. “Seleccionar o número e o nome dos alunos que estejam matriculados apenas a uma disciplina”.

SELECT codaluno, nomeFROM alunoWHERE codaluno = ANY

(SELECT matricula.codaluno FROM matricula,aluno WHERE aluno.codaluno=matricula.codaluno GROUP BY matricula.codaluno HAVING Count(*)=1);

12. “Professores que só estejam a leccionar uma disciplina”

SELECT nomeFROM professorWHERE codprofessor = ANY

(SELECT discprof.codprofessorFROM disciplinaprofessor discprof, professorWHERE professor.codprofessor=discprof.codprofessorGROUP BY discprof.codprofessorHAVING Count(*)=1);

8. “Todas as disciplinas e respectivos professores do curso de Informática. As colunas da tabela virtual deverem ser Código, Disciplina e Professor. Em que código corresponde ao código da disciplina indicada como Disciplina e Professor corresponde ao nome do professor. Lista ordenada pela designação da disciplina.

SELECT disciplina.coddisciplina AS Código,disciplina.designação AS Disciplinas, professor.nome AS ProfessorFROM disciplina,curso,professor, disciplinaprofessor AS discprofWHERE curso.nome="Informática" AND

discprof.codprofessor=professor.codprofessorORDER BY disciplina.designação


GLOSSÁRIO

atributo - Base de Dados - BD - campo - chave primária - chave secundária - chave estrangeira - domínio - entidade - modelo Entidade-Associação - modelo relacional - obrigatoriedade - ocorrência - registo - relação - SGBD - Sistema Gestor de Base de Dados ou do inglês DBMS Database Management Systemtabela - valor -

bases de dados

Documents