Bases de Dados

Fazer download em ppt, pdf ou txt
Fazer download em ppt, pdf ou txt
Você está na página 1de 107

Bases de Dados

Carlos Carvalho
Norsistemas, Lda
Introdução
 Objectivo: oferecer uma noção geral sobre a
construção de sistemas de bases de dados
 Para tal é necessário dominar:
 modelos para o desenho lógico de bases de
dados - modelo Entidade Relacionamento
 modelos para a construção de projectos físicos
de bases de dados - modelo Relacional
 técnicas de controlo de dependência de dados
 métodos de consultas - Álgebra Relacional e
SQL
Conceitos gerais
 Base de Dados (BD): conjunto de dados
interrelacionados
 Por dados devemos entender factos conhecidos,
significado implícito, que podem ser armazenados
 Propriedades das BD:
 colecção lógica e coerente de dados com um

significado inerente
 é projectado, construído e preenchido com

dados para um propósito concreto


 representa algum aspecto do mundo real, o qual

é chamado de mini-mundo
Conceitos gerais
 Sistema de Gestão de BD (SGBD): sistema de
aplicações que permite aos utilizadores criarem e
manipularem BD’s de propósitos gerais
 Sistema de BD (SBD): conjunto formado pela BD e
pelas aplicações que a manipulam
 Por vezes os termo BD, SGBD e SBD são usados
indistintamente (por exemplo: o que é o Microsoft
Access?)
Conceitos gerais
Conceitos gerais
SBD x Processamento tradicional
 Auto-informação
 Separação entre programas e dados
 Abstracção dos dados
 Múltiplas perspectivas dos dados
Conceitos gerais
Entidades envolvidas

 Administrador da BD (DBA)
 Desenhador da BD
 Utilizadores da BD
 ocasionais
 inexperientes ou paramétricos
 sofisticados

 Analistas de Sistemas
 Programadores de aplicações
Conceitos gerais
Vantagens do uso de SGBD’s

 Controlo de redundância
 Partilha de dados
 Restrição a acessos não autorizados
 Representação de relacionamentos complexos
entre dados
 Tolerância a falhas
Conceitos gerais
Contra-indicação do uso de SGBD’s
 Investimento em software e hardware
 Generalidade de definição e processamento de
dados
 Sobrecarga originada pela provisão de controlo de
segurança, controlo de concorrência, recuperação
e integração de funções
 Simplicidade, boa definição e imutabilidade das
aplicações
 Necessidade de processamento em tempo real
das aplicações
 Inexistência de múltiplos acessos à BD
Conceitos e arquitecturas de SGBD’s
Modelos de dados
 As BD’s suportam níveis de abstracção dos
dados, omitindo detalhes de armazenamento
 Modelo de dados como um conjunto de conceitos
usados para descrever a estrutura de uma BD
 Por estrutura entenda-se o tipo dos dados,
relacionamentos e restrições que sobre eles
incidam
 Os modelos de dados classificam-se em:
 alto nível ou modelo de dados conceptual
 baixo nível ou modelo de dados físico
Conceitos e arquitecturas de SGBD’s
Esquemas e instâncias
 É importante distinguir a descrição da BD da
própria BD
 A descrição da BD é chamada de esquema ou
intenção da BD - especificada durante o projecto,
onde geralmente não ocorrem mudanças
 Os dados armazenados numa BD, num dado
instante temporal, constituem a instância ou
extensão da BD – esta altera-se sempre que
ocorre uma alteração na BD
 Os SGBD’s devem garantir que todas as
instâncias das BD’s obedecem aos esquemas das
BD’s
Conceitos e arquitecturas de SGBD’s
Arquitectura ANSI/SPARC

Arquitectura ANSI/SPARC
Conceitos e arquitecturas de SGBD’s
Arquitectura ANSI/SPARC
 Uma consequência da arquitectura ANSI/SPARC
é o da criação de uma independência dos dados
 Tipos de independência:
 independência lógica - capacidade de alterar o

esquema conceptual sem alterar o esquema


externo ou as aplicações do utilizador
 independência física - capacidade de alterar o

esquema interno sem alterar o esquema


conceptual, o esquema externo ou as
aplicações do utilizador
Conceitos e arquitecturas de SGBD’s
Linguagens de manipulação de dados
 Linguagem de Definição de Dados (DDL):
definição dos esquemas conceptual e interno (no
caso de SGBD’s onde a separação entre os
níveis interno e conceptual não é muito clara)
 Linguagem de Definição de Armazenamento
(SDL): especificação do esquema interno
(especificação do esquema conceptual  DDL)
 Linguagem de Definição de Perspectivas (VDL):
definição de perspectivas
 Linguagem de Manipulação de Dados (DML):
manipulação dos dados
Conceitos e arquitecturas de SGBD’s
Componentes de um SGBD

Esquema da estrutura de funcionamento de um


SGBD
Conceitos e arquitecturas de SGBD’s
Classificação dos SGBD’s
 O principal critério de classificação de SGBD’s é
o modelo de dados no qual assenta: a maioria
dos SGBD’s actuais baseiam-se no modelo
Relacional
 Outras classificações possíveis são:
 quanto aos utilizadores – SGBD monoutilizador ou
multiutilizador
 quanto à localização – SGBD local ou distribuído
 quanto ao ambiente – SGBD homogéneo
(composto por um único SGBD) ou heterogéneo
O modelo ER
 O modelo Entidade Relacionamento (ER ou MER)
é um modelo de dados conceptual de alto nível
 Os seus conceitos foram desenvolvidos para
estar o mais próximo possível da perspectiva que
o utilizador possui dos dados, não se
preocupando com a sua representação física
 O modelo ER é usado principalmente durante o
processo de projecto da BD
O modelo ER
Modelo de dados conceptual de alto nível

Descrição simplificada do projecto de uma BD


O modelo ER
Entidades e atributos
 O conceito básico do modelo ER é a entidade
 Entidade: objecto do mundo real, concreto ou
abstracto que possui existência independente
 Atributos: conjunto de propriedades da entidade
 Um atributo pode ser:
 composto  simplesmente valorado
 simples ou atómico  multivalorado
 Um atributo que é gerado a partir de outro
atributo é chamado de atributo derivado
O modelo ER
Entidade tipo, conjunto de valores, atributo chave
 Entidade tipo: agrupamento de entidades
similares (possuem os mesmos atributos, porém
com valores próprios para cada atributo)
 Cada entidade tipo é identificada pelo seu:
 nome
 conjunto de atributos

 Esquema da entidade tipo: descrição da entidade


tipo, especificando-se:
 o seu nome
 o nome de cada atributo
 restrições que incidam sobre as entidades
O modelo ER
Entidade tipo, conjunto de valores, atributo chave
 Atributo chave (ou chave): atributo cujos valores
são únicos em cada entidade tipo
 A chave pode ser usada para identificar única e
inequivocamente cada entidade
 Uma chave pode ser formada pela composição
de dois ou mais atributos
 Uma entidade tipo pode ter mais de um atributo
chave
 Domínio: determina o conjunto de valores que
são possíveis para um atributo
O modelo ER
Tipos e instâncias de relacionamento
 Um relacionamento tipo, entre entidades tipo, é
um conjunto de associações entre entidades
desse género
 Significa que estas entidades estão, de alguma
forma, relacionadas no mini-mundo

 Em cada relacionamento,
participam apenas uma
entidade de cada tipo
 Uma entidade pode
participar em vários
relacionamentos
O modelo ER
Grau de um relacionamento
 Grau de um relacionamento tipo: é dado pelo
número de entidades tipo que nele intervêm
 O grau de um relacionamento é ilimitado, porém,
a partir do ternário (grau 3), a sua compreensão e
dificuldade tornam-se impraticáveis
 No exemplo anterior, temos um relacionamento
binário (grau 2)
O modelo ER
Relacionamentos como atributos
 Se uma entidade não possuir existência bem
definida, é mais coerente representá-la como
atributo de uma entidade com que se relaciona
 Exemplo: em baixo, podemos ter DEPARTAMENTO
como atributo de EMPREGADO, ou EMPREGADO,
como atributo multivalorado de DEPARTAMENTO
O modelo ER
Relacionamentos recursivos
 Um relacionamento recursivo é um
relacionamento entre entidades da mesma
entidade tipo
 No esquema, temos um relacionamento recursivo,
onde um empregado pode supervisionar outro
empregado e um empregado pode ser
supervisionado por outro empregado
O modelo ER
Papéis das entidades nos relacionamentos
 Cada entidade tipo que participa num
relacionamento tipo desempenha aí um
determinado papel
 Os nomes de papéis não são importantes quando
todas as entidades participantes desempenham
papéis diferentes
 Noutras vezes, o papel torna-se essencial para
distinguir o significado de cada participação
(comum nos relacionamentos recursivos)
O modelo ER
Papéis das entidades nos relacionamentos
O modelo ER
Restrições em relacionamentos tipo
 Geralmente, os relacionamentos tipo sofrem certas
restrições (ditas estruturais) que limitam as possíveis
combinações das entidades participantes, e podem ser:
 Cardinalidade - indica o número de relacionamentos nos
quais uma entidade pode participar, podendo ser:
 1:1
 1:N (ou N:1)
 M:N
 Participação - define a existência de uma entidade
através do relacionamento, podendo ser:
 parcial
 total
O modelo ER
Restrições em relacionamentos tipo

Cardinalidade 1:1 
Participação
total

Participação
parcial

Cardinalidade M:N 
O modelo ER
Atributos de relacionamento
 Por vezes, torna-se necessário armazenar um
atributo no relacionamento tipo
 Quando temos relacionamentos 1:1, podemos
colocar o atributo de relacionamento em qualquer
das entidades, de preferência, numa cuja
entidade tipo tenha participação total
 Caso seja 1:N, podemos colocar o atributo na
entidade tipo com participação N
 Porém, se for N:M, então o atributo deverá
permanecer no relacionamento tipo
O modelo ER
Entidades tipo fracas
 Entidades fracas: são aquelas que, por si só,
podem não ter, um atributo chave
 Estas entidades necessitam de estar ligadas com
uma entidade pertencente à entidade tipo
proprietária
 Esta ligação é
chamada de
relacionamento
identificador
O modelo ER
Relacionamento ternário
 O número de entidades que participam num
relacionamento tipo é irrestrito e representam
mais informação do que vários relacionamentos
binários
 Exemplo: um
motorista pode
efectuar uma viagem
para uma localidade
conduzindo um dado
veículo numa
determinada data
O modelo ER
Diagrama ER
O modelo ER
Diagramas ER
O modelo ER
Diagramas ER
O modelo ER
Diagramas ER
O modelo ER
Diagramas ER
O modelo ER
Diagramas ER
O modelo ER
Diagramas ER
O modelo ER
Modelo Entidade Relacionamento Estendido (ERE)
 O modelo Entidade Relacionamento Estendido
(MERE) visa fornecer uma semântica para
permitir a representação de informações
complexas
 O MERE engloba todos os conceitos do MER
mais os conceitos de:
 subclasse
 superclasse
 generalização
 especialização
 herança de atributos
O modelo ER
Modelo ERE (subclasses e superclasses)

Em muitos casos, uma


entidade tipo possui
diversos subgrupos de
entidades que são
significativas e
precisam de uma
representação
explicita
O modelo ER
Modelo ERE (subclasses e superclasses)
 Antes de ser componente de uma subclasse, uma
entidade deve ser componente de uma
superclasse
 Herança de atributos: a subclasse herda todos os
atributos da superclasse, porque a entidade de
subclasse apresenta as mesmas características
da mesma entidade da superclasse
 Uma subclasse pode herdar atributos de
superclasses diferentes
O modelo ER
Modelo ERE (subclasses e superclasses)

Uma subclasse pode ter relacionamentos específicos


com outras entidades ou com a própria entidade que
é a sua superclasse:
O modelo ER
Modelo ERE (especialização)
Especialização é o
processo de definição
de um conjunto de
classes de uma
entidade tipo, sendo
esta chamada de
superclasse da
especialização.

O conjunto de subclasses é formado baseado


nalguma característica que distinga as entidades
entre si.
O modelo ER
Modelo ERE (especialização)
 O processo de especialização permite-nos:
 definirum conjunto de subclasses de uma
entidade tipo
 associaratributos específicos adicionais para
cada subclasse
 estabelecer relacionamentos tipo específicos
entre subclasses e outras entidades tipo
O modelo ER
Modelo ERE (generalização)
A generalização pode ser
pensada como um
processo de abstracção
inverso ao da
especialização, no qual
são suprimidas as
diferenças entre diversas
entidades tipo,
identificando as suas
características comuns e
generalizando estas
entidades numa
superclasse.
O modelo ER
Modelo ERE (especialização/generalização)
 Existe diferença semântica entre especialização e
generalização:
 Na especialização, a ligação entre a
superclasse e as subclasses é feita através de
um traço simples, indicando participação
parcial por parte da superclasse
 Na generalização, a ligação entre a
superclasse e as subclasses é feita através de
um traço duplo, indicando participação total por
parte da superclasse
O modelo ER
Modelo ERE (especialização/generalização)
 A letra d dentro do círculo que especifica uma
especialização ou uma generalização significa
disjunção
 Uma disjunção numa especialização ou
generalização indica que uma entidade da
entidade tipo que representa a superclasse pode
assumir apenas um papel dentro da mesma
O modelo ER
Modelo ERE (especialização/generalização)
Além da disjunção
podemos ter um
sobreposição (overlap),
representado pela letra o.
No caso da sobreposição,
uma entidade de uma
superclasse pode ser
membro de mais do que
uma subclasse numa
especialização ou
generalização.
O modelo ER
Modelo ERE (múltipla herança)
Uma subclasse pode
ser definida através
de múltipla herança,
ou seja, ela pode ter
diversas
superclasses,
herdando
características de
todas
Um gerente é um empregado que possui
características de GERENTE e herda as de
ENGENHEIRO e de QUADRO
O modelo Relacional
 O modelo relacional (MR) foi criado por Codd em 1970
 Representam-se os dados como uma colecção de
relações, onde cada relação é representada por uma
tabela
 Cada linha da tabela representa uma colecção de dados
relacionados, cujos valores podem ser interpretados como
factos que descrevem uma instância de uma entidade ou
de um relacionamento
 O nome da tabela e das suas colunas são usados para
facilitar a interpretação dos valores armazenados em cada
linha
 Todos os valores de uma coluna são do mesmo tipo
O modelo Relacional
 Na terminologia do modelo relacional:
 cada tabela é chamada de relação
 uma linha de uma tabela é chamada de tuplo
o nome de cada coluna é chamado de atributo
o tipo de dados que descreve cada coluna é
chamado de domínio
O modelo Relacional
Domínios, tuplos, atributos e relações
 Um domínio D é um conjunto de valores atómicos
(indivisíveis)
 Na especificação do domínio é importante
destacar:
 tipo
 tamanho
 gama do atributo

Coluna Tipo Tamanho Gama


#Mecanografico Numérico 10,0 03000000-25999999
Nome Caracter 30 a-z; A-Z
Salario Numérico 5,2 00100,00-12999,99
O modelo Relacional
Domínios, tuplos, atributos e relações
 Esquema de relação R é denotado por R(A1, A2, ..., An)
 cada atributo Ai é o nome do papel desempenhado por
um domínio D no esquema de relação R
 D é chamado domínio de Ai e é denotado por dom(Ai)
 Grau da relação R é dado pelo número de atributos
presentes no seu esquema de relação
 A instância r de um esquema de relação, denotado por
r(R) é um conjunto de n-tuplos r = [t1, t2, ..., tn] onde os
valores de [t1, t2, ..., tn] devem estar contidos no domínio D
 O valor nulo também pode fazer parte do domínio de
um atributo e representa um valor desconhecido para
um determinado tuplo
O modelo Relacional
Atributo chave de uma relação
 Uma relação é um conjunto de tuplos distintos 
combinação dos valores dos atributos num tuplo
não se pode repetir na mesma tabela
 Um subconjunto de atributos numa tabela que
garanta que não existem valores repetidos para os
diversos tuplos da mesma é chamada de
superchave de um esquema de relação
 Toda a relação possui pelo menos uma
superchave: o conjunto de todos os seus atributos
O modelo Relacional
Atributo chave de uma relação
 Uma chave é uma superchave da qual não se
pode extrair qualquer atributo
 Exemplo:
o conjunto de atributos: (#Matrícula, Nome,
Endereço) é uma superchave para
ESTUDANTE, porém, não é uma chave
o conjunto (Nome da Revista, Volume,
#Revista) é uma superchave e uma chave, pois
qualquer dos atributos que seja retirado faz
com que deixemos de ter uma superchave
O modelo Relacional
Atributo chave de uma relação
 Quando uma relação possui mais que uma chave
(não confundir com chave composta), cada uma
destas são chamadas de chaves candidatas e
apenas uma delas deve ser escolhida como
chave primária
 Uma chave estrangeira (atributo(s) de uma
relação que são chave noutra) de uma relação
especifica um relacionamento entre relações
O modelo Relacional
Do modelo ER ao modelo Relacional
O modelo Relacional
Do modelo ER ao modelo Relacional
 8.º Passo: cada especialização com m
subclasses {S1, S2, ..., Sm} e superclasse SC,
onde os atributos de SC são {c, a1, a2, ..., an},
onde c é a chave primária de SC, converte-se em
tabelas utilizando uma das seguintes opções:
 cria-se uma tabela T para SC com os atributos
A(T) = {c, a1, a2, ..., an} e chave C(T) = c; cria-se
uma tabela Ti para cada subclasse Si (1  i  m),
com os atributos: A(Ti) = {c}  A(Si), onde C(Ti) = c
 cria-se uma tabela Ti para cada subclasse Si (1  i
 m), com os atributos: A(Ti) = A(Si)  {c, a1, a2, ...,
O modelo Relacional
Do modelo ER ao modelo Relacional
 cria-se uma tabela T com os atributos A(T) = {c, a 1,
a2, ..., an}  A(S1)  ...  A(Sm)  {t} e C(T) = c,
onde t é um atributo tipo que indica a subclasse à
qual cada tuplo pertence, caso isto venha a ocorrer
 Cria-se uma tabela T com atributos A(T) = {c, a 1,
a2, ..., an}  A(S1)  ...  A(Sm)  {t1, t2, ..., tm} e
C(T) = c; esta opção é para generaliza-ções com
sobreposição (overlapping), e cada ti (1  i  m), é
um atributo booleano indicando se o tuplo pertence
ou não à subclasse Si. Embora funcional, esta
opção pode gerar uma quantidade muito grande
de valores nulos.
O modelo Relacional
Dependência funcional e normalização
 Uma dependência funcional é uma restrição entre
dois conjuntos de atributos de uma BD
 Consideremos o esquema R de uma BD que
possui n atributos A1, A2, ..., An, ou seja, R = {A1,
A2, ..., An} como a representação universal da
base de dados
 Uma dependência funcional, representada por X
 Y entre dois conjuntos de atributos X e Y que
são subconjuntos de R especificam uma restrição
nos tuplos que podem compor uma instância da
relação r de R
O modelo Relacional
Dependência funcional e normalização
 Nesta restrição estabelece-se que para qualquer
par de tuplos t1 e t2 em r que verificam t1.[X] = t2.
[X], é obrigatório existir t1.[Y] = t2.[Y]
 Isto significa que os valores do componente Y
num tuplo em r depende de, ou é determinada
pelos valores do componente X
 Para X  Y lê-se: Y é funcionalmente dependen-
te de X, ou X determina (funcionalmente) Y
O modelo Relacional
Dependência funcional e normalização
 Normalização: processo pelo qual são eliminados
esquemas de relações (tabelas) não satisfatórios,
decompondo-os, através da separação de seus
atributos em esquemas de relações menos
complexas, mas que satisfaçam determinadas
propriedades desejáveis
 O processo de normalização, como foi proposto
inicialmente por Codd, conduz um esquema de
relação através de um conjunto de testes para
certificar se o mesmo está na 1.ª, 2.ª e 3.ª Formas
Normais (estas baseiam-se em dependências
funcionais dos atributos do esquema de relação)
O modelo Relacional
Dependência funcional e normalização (1.ª FN)
 Considera que todos os atributos de uma
tabela têm de ser atómicos (indivisíveis), ou
seja, não são permitidos atributos multivalo-
rados, atributos compostos ou atributos
multivalorados compostos.
O modelo Relacional
Dependência funcional e normalização (2.ª FN)
 Baseia-se no conceito da dependência funcional
total
 Uma dependência funcional X  Y é total se
removemos um atributo A qualquer de X e a
dependência funcional deixar de existir
 Caso não se trate de uma dependência funcional
total, estaremos perante uma dependência
funcional parcial
O modelo Relacional
Dependência funcional e normalização (2.ª FN)
 Exemplo:

{ #MecanoEmp, #ProjectoEmp }  Horas

é uma dependência funcional total, pois se


removermos o atributo #MecanoEmp ou o
atributo #ProjectoEmp, a dependência
funcional deixa de existir
O modelo Relacional
Dependência funcional e normalização (2.ª FN)
 Uma tabela T está na 2.ª FN se estiver na 1.ª FN
e todo atributo que não compõe a chave primária
C é totalmente (funcionalmente) dependente da
chave primária C
 Se uma tabela não está na 2.ª FN a mesma pode
ser normalizada gerando outras tabelas cujos
atributos que não fazem parte da chave primária
sejam totalmente (funcionalmente) dependentes
da mesma, ficando então as tabelas na 2.ª FN
O modelo Relacional
Dependência funcional e normalização (3.ª FN)
 Gira em torno do conceito de dependência
transitiva
 Uma dependência funcional X  Y numa tabela T
é uma dependência transitiva se existir um
conjunto de atributos Z que não é um subconjunto
das chaves de T e são válidas as dependências
XZeZY
O modelo Relacional
Dependência funcional e normalização (3.ª FN)
 Exemplo:
EMPREGADO (#Mecano, Nome, #Depart, NomeDepart,
#MecanoSuper)
 Verifica-se a seguinte dependência transitiva:
#Mecano  { NomeDepart, #MecanoSuper }

X Y
#Mecano  #Depart

Z
#Depart  { NomeDepart, #MecanoSuper }
O modelo Relacional
Dependência funcional e normalização (3.ª FN)
 Uma tabela está na 3.ª FN se estiver na 2.ª FN e
não houver dependências transitivas entre
atributos não chave
 No exemplo, o esquema de relação
EMPREGADO daria origem a dois outros
esquemas, como se segue:
EMPREGADO (#Mecano, Nome, #Depart)

DEPARTAMENTO (#Depart, NomeDepart, #MecanoSuper)


O modelo Relacional
A álgebra relacional
 A álgebra relacional é uma colecção de
operações formais que são usadas para
manipular as relações
 Estas operações destinam-se a:
 seleccionar tuplos de relações individuais
 combinar tuplos relacionados de relações
diferentes
visando especificar consultas às BD’s
 O resultado de cada operação é uma nova
operação, a qual também pode ser manipulada
pela álgebra relacional
O modelo Relacional
A álgebra relacional (select - selecção)
 Objectivo: seleccionar um subconjunto de tuplos de
uma relação devendo estes satisfazer uma condição
de selecção
 Forma geral:
 <condição_de_selecção> (<nome_da_relação>)
 onde:
  representa a operação
 <condição_de_selecção> é uma expressão
booleana aplicada sobre os atributos da relação
 <nome_da_relação> é o nome da relação
sobre a qual será aplicada a operação
O modelo Relacional
A álgebra relacional (select - selecção)
 Exemplos:
CONSULTA1 =  Salario < 250.000,00 (EMPREGADO)
CONSULTA2 =  (Relação = “Filho”) .and. (Sexo = “Feminino”)
(DEPENDENTE)
 Operadores relacionais aplicáveis: <, , >, , = e 
 Operadores booleanos aplicáveis: .and., .or. e
.not.
 A operação select é unária
 não é possível aplicar a operação sobre tuplos de
relações distintas
O modelo Relacional
A álgebra relacional (project - projecção)
 Objectivo: seleccionar um subconjunto de colunas
de uma relação
 Forma geral:
 <lista_de_atributos> (<nome_da_relação>)
 onde:
 representa a operação
 <lista_de_atributos> representa a lista de

atributos desejados
 <nome_da_relação> é o nome da relação

sobre a qual será aplicada a operação


O modelo Relacional
A álgebra relacional (project - projecção)

 Exemplo:
CONSULTA3 =  NomeDependente, DataNascimento
(DEPENDENTE)
O modelo Relacional
A álgebra relacional (projectselect)
 As operações project e select podem ser usadas
de forma combinada, permitindo que apenas
determinadas colunas de determinados tuplos
possam ser seleccionados
 Forma geral:
 <lista_de_atributos> ( <condição_de_selecção>
(<nome_da_relação>))
 exemplo:
CONSULTA4 =  Nome, #Departamento, Salario ( Salario < 250.000,00
(EMPREGADO))
O modelo Relacional
A álgebra relacional (operações matemáticas)
 Levando em consideração que as relações
podem ser tratadas como conjuntos, podemos
aplicar um conjunto de operações matemáticas
 Estas operações são: união () , intersecção ()
e diferença (–)
 Este conjunto de operações é binário
 Existe a necessidade de as tabelas possuírem
tuplos exactamente do mesmo tipo
O modelo Relacional
A álgebra relacional (operações matemáticas)
 união – o resultado desta operação representada
por R  S é uma relação T que inclui todos os
tuplos que se encontram em R e todos os tuplos
que se encontram em S
 intersecção – o resultado desta operação
representada por R  S é uma relação T que
inclui os tuplos que se encontram em R e em S ao
mesmo tempo
 diferença – o resultado desta operação
representada por R – S é uma relação T que inclui
todos os tuplos que se encontram em R mas não
em S
O modelo Relacional
A álgebra relacional (operações matemáticas)
 Consideremos a seguinte consulta:
Obter todos os empregados que trabalham no
departamento número 2 ou que supervisionam
empregados que trabalham no departamento
número 2

CONSULTA5 =  #Departamento = 2 (EMPREGADO)


CONSULTA6 =  #MecanograficoSuper (CONSULTA5)
CONSULTA7 =  #Mecanografico (CONSULTA5)
CONSULTA8 = CONSULTA6  CONSULTA7
O modelo Relacional
A álgebra relacional (operações matemáticas)
 Consideremos a seguinte consulta:
Obter todos os empregados que desenvolvem
algum projecto e que trabalham no
departamento número 2

CONSULTA9 =  #MecanograficoEmp (EMPREGADO_PROJETO)


CONSULTA10 =  #Mecanografico ( #Departamento = 2 (EMPREGADO))
CONSULTA11 = CONSULTA9  CONSULTA10
O modelo Relacional
A álgebra relacional (operações matemáticas)
 Consideremos a seguinte consulta:
Obter todos os empregados que não
desenvolvem projectos

CONSULTA12 =  #MecanograficoEmp (EMPREGADO_PROJETO)


CONSULTA13 =  #Mecanografico (EMPREGADO)
CONSULTA14 = CONSULTA13 – CONSULTA12
O modelo Relacional
A álgebra relacional (produto cartesiano)
 O produto cartesiano é uma operação binária que
combina todos os tuplos de duas tabelas
 O produto cartesiano não exige que os tuplos das
tabelas possuam exactamente o mesmo tipo
 O resultado de um produto cartesiano é uma nova
tabela
 O formato geral da operação entre duas tabelas R
e S é:
RxS
O modelo Relacional
A álgebra relacional (produto cartesiano)
 Consideremos a seguinte consulta:
Obter todos os funcionários que desenvolvem
projectos em Braga

CONSULTA15 = EMPREGADO_PROJETO x PROJETO


CONSULTA16 =  #MecanograficoEmp, #ProjectoEmp ( (#ProjectoEmp = #Projecto)
.and. (Local = ‘Braga’) (EMPREGADO))
O modelo Relacional
A álgebra relacional (operações matemáticas)
 Consideremos a seguinte consulta:
Obter todos os funcionários que desenvolvem projectos em Braga

 A operação produto cartesiano não é muito utilizada por não oferecer um resultado optimizado (ver operação
seguinte)

CONSULTA15 = EMPREGADO_PROJETO x PROJETO


CONSULTA16 =  #MecanograficoEmp, #ProjectoEmp ( (#ProjectoEmp =
#Projecto) .and. (Local = ‘Braga’) (EMPREGADO))
O modelo Relacional
A álgebra relacional (join - junção)
 A operação junção actua de forma similar à
operação produto cartesiano
 A tabela resultante conterá apenas as
combinações dos tuplos que se relacionam de
acordo com uma determinada condição de junção
 A forma geral da operação junção entre duas
tabelas R e S é a seguinte:
R [X]<condição_de_junção> S
O modelo Relacional
A álgebra relacional (join - junção)
 Consideremos a seguinte consulta:
Obter todos os funcionários que desenvolvem
projectos em Braga

CONSULTA17 = EMPREGADO_PROJETO [X] #ProjectoEmp =


#Projecto PROJETO

CONSULTA18 =  Local = ‘Braga’ (CONSULTA17)


O modelo Relacional
SQL - Structured Query Language
 SQL é um conjunto de declarações que é
utilizado para aceder aos dados utilizando
SGBD’s
 Nem todos os SGBD’s usam SQL
 A linguagem SQL processa conjuntos de registos
em vez de os processar individualmente,
fornecendo navegação automática através dos
dados, permitindo manipulações mais complexas
 A linguagem SQL pode ser usada para todas as
operações relativas a uma BD e pelos diversos
utilizadores da mesma
O modelo Relacional
SQL (CREATE TABLE - DDL)
 Objectivo: criar uma nova tabela (ou relação)
 Forma geral:
CREATE TABLE <nome da tabela>
(<nome coluna1> <tipo coluna1> <NOT NULL>,
<nome coluna2> <tipo coluna2> <NOT NULL>,
...,
<nome colunan> <tipo colunan> <NOT NULL>);
 onde:
 <tipo coluna > pode ser: char(n); integer; float;
i
decimal(m, n)
 A restrição not null indica um atributo obrigatório,
caso contrário pode assumir um valor nulo
O modelo Relacional
SQL (CREATE TABLE - DDL)
 Exemplo: criar a tabela EMPREGADO
CREATE TABLE EMPREGADO
(Nome char(30) NOT NULL,
#Mecanografico integer NOT NULL,
BI integer,
#Departamento integer NOT NULL,
#MecanograficoSuper integer,
Salario decimal(7,2) NOT NULL);
O modelo Relacional
SQL (DROP TABLE - DDL)
 Objectivo: excluir uma tabela (ou relação) da BD
 Forma geral:
DROP TABLE <nome da tabela>;
 Exemplo: excluir a tabela EMPREGADO
DROP TABLE EMPREGADO;
 Obs.: Observe que neste caso, a chave da tabela
EMPREGADO, (#Mecanografico) é utilizada
como chave estrangeira ou como chave primária
composta em diversas tabelas que devem ser
devidamente corrigidas
O modelo Relacional
SQL (ALTER TABLE - DDL)
 Objectivo: inclusão de novos atributos numa
tabela (ou relação)
 Forma geral:
ALTER TABLE <nome da tabela> ADD
<nome de coluna> <tipo de coluna>;
 Obs.: No caso do comando ALTER TABLE, a
restrição NOT NULL não é permitida pois assim
que se insere um novo atributo na tabela, o valor
para o mesmo em todos os tuplos será nulo
O modelo Relacional
SQL (SELECT - DML)
 Objectivo: selecção de tuplos e atributos numa ou
mais tabelas (ou relações)
 Forma geral:
SELECT <lista de atributos>
FROM <lista de tabelas>
WHERE <condições>;
 Exemplo: obter o Nome e o #Mecanografico dos
funcionários que trabalham no departamento
número 2
SELECT Nome, #Mecanografico
FROM EMPREGADO
WHERE #Departamento = 2;
 Expressão:  Nome, #Mecanografico ( #Departamento = 2 (EMPREGADO))
O modelo Relacional
SQL (SELECT - DML)
 Em SQL também é permitido o uso de condições
múltiplas
 Exemplo:
SELECT Nome, #Mecanografico, Salario
FROM EMPREGADO
WHERE #Departamento = 2 AND Salario > 250.000,00;
 Expressão algébrica correspondente:
 Nome, #Mecanografico, Salario
( #Departamento = 2 .and. Salario > 250.000,00 (EMPREGADO))
O modelo Relacional
SQL (SELECT - DML)
 A operação pode envolver diversas tabelas
 Exemplo: obter o número do departamento que controla
projectos localizados no Porto
SELECT t1.#Departamento
FROM DEPARTAMENTO_PROJECTO t1,
PROJECTO t2
WHERE t1.#Projecto = t2.#Projecto AND t2.Local = ‘Porto’;
 t1 e t2 são chamados "alias" (sinónimos) e representam a
tabela à qual são associados
 Um sinónimos é importante quando há redundância nos
nomes das colunas de duas ou mais tabelas que estão
envolvidas numa expressão
O modelo Relacional
SQL (SELECT - DML)
 Exemplo: considere a seguinte consulta
SELECT e1.Nome, e1.#Mecanografico
FROM EMPREGADO e1, EMPREGADO e2
WHERE e1.#Mecanografico = e2.#MecanograficoSuper;
 Esta consulta decorre da seguinte expressão
algébrica:
 Nome, #Mecanografico
(EMPREGADO [X] #Mecanografico_t1 = #MecanograficoSuper_t2
EMPREGADO)
O modelo Relacional
SQL (SELECT - DML)
 O operador  dentro do especificador SELECT
selecciona todos os atributos de uma tabela
 A exclusão do especificador WHERE faz com que
todos os tuplos de uma tabela sejam
seleccionados
 Exemplo:
SELECT 
FROM EMPREGADO;
O modelo Relacional
SQL (SELECT - DML)
 Ao contrário da álgebra relacional, a operação
SELECT em SQL permite a geração de tuplos
duplicados como resultado de uma expressão
 Para evitar isto, devemos utilizar o especificador
DISTINCT
 Exemplos com e sem DISTINCT:
SELECT #Departamento SELECT DISTINCT #Departamento
FROM EMPREGADO; FROM EMPREGADO;
O modelo Relacional
SQL (SELECT - DML)
 Podemos gerar consultas aninhadas em SQL
utilizando o especificador IN
 Este faz uma comparação do especificador WHERE
da consulta mais externa com o resultado da consulta
mais interna
 Exemplo: obter o nome de todos os funcionários que
trabalham nos projectos localizados no Porto
SELECT e1.Nome, e1.#Mecanografico, e1.#Departamento
FROM EMPREGADO e1, EMPREGADO_PROJETO e2
WHERE e1.#Mecanografico = e2.#MecanograficoEmp AND
e2.#ProjectoEmp IN (SELECT #Projecto FROM
PROJECTO WHERE Local = ‘Porto’);
O modelo Relacional
SQL (SELECT - DML)
 Para seleccionar um conjunto de tuplos de forma
ordenada devemos utilizar o especificador
ORDER BY
 Exemplo: obter todos os empregados por ordem
alfabética
SELECT Nome, #Mecanografico, #Departamento
FROM EMPREGADO
ORDER BY Nome;
O modelo Relacional
SQL (INSERT INTO - DML)
 Objectivo: inserção de valores numa tabela (ou
relação)
 Forma geral:
INSERT INTO <nome da tabela> (<lista de
colunas>) VALUES (<lista de valores>);
 onde:
 <lista de valores> é a lista dos valores,
separados por vírgulas, que se pretendem
inserir na tabela e com correspondência
directa com os atributos constantes da lista de
atributos especificada em <lista de colunas>
O modelo Relacional
SQL (INSERT INTO - DML)
 Exemplo:
INSERT INTO EMPREGADO
VALUES (‘Jorge Gonçalves’, ‘60606060’,
‘66666666’, 3, ‘20202020’, 4000000,00);
 Como se pretendem inserir valores para todos os
campos, então não é necessário especificar os
seus nomes
O modelo Relacional
SQL (INSERT INTO - DML)
 Exemplo:
INSERT INTO EMPREGADO
(Nome, #Mecanografico, BI, #Departamento, Salario)
VALUES (‘João de Campos’, ‘70707070’, ‘77777777’,
3, 250000,00);
 Neste caso o campo #MecanograficoSuper não
possui valor, pelo que se especificaram as outras
colunas
 Outra forma de se elaborar esta inserção seria:
INSERT INTO EMPREGADO
VALUES (‘João de Campos’, ‘70707070’, ‘77777777’,
3, ‘ ‘, 250000,00);
O modelo Relacional
SQL (UPDATE - DML)
 Objectivo: efectuar alterações numa tabela (ou
relação)
 Forma geral:
UPDATE <tabela>
SET <coluna> = <expressão>
WHERE <condição>;
 onde:
 <coluna> é o nome do atributo que se
pretende alterar
 <expressão> é um valor ou o resultado de
uma expressão que irá constituir o novo valor
do campo <coluna>
O modelo Relacional
SQL (UPDATE - DML)
 Exemplo: actualizar o salário de todos os
empregados que trabalham no departamento 2
para 300.000,00
UPDATE EMPREGADO
SET Salario = 300000,00
WHERE #Departamento = 2;
O modelo Relacional
SQL (DELETE - DML)
 Objectivo: eliminar um ou mais tuplos de uma
tabela tabela (ou relação)
 Forma geral:
DELETE FROM <tabela>
WHERE <condição>;
 Exemplo: eliminar os registos nos quais o
empregado trabalhe no departamento 2 e possua
salário maior que 350.000,00
DELETE FROM EMPREGADO
WHERE Salario > 350000,00 and #Departamento = 2;
O modelo Relacional
SQL (DML)
 Nos casos de todas as actualizações
apresentadas, as <condições> podem ser
uma consulta que utiliza o comando
SELECT, onde o comando será aplicado
sobre todos os registos que satisfizerem as
condições determinadas pelo comando de
selecção
Bases de Dados

Carlos Carvalho
Norsistemas, Lda

Você também pode gostar