Sistemas de Base de Dados
•
•
•
•
Michel Ferreira
Email: [email protected] (melhor contacto!)
Gabinete: CIUP, Gab. 213, 22 6078830
Página da disciplina: http://www.ncc.up.pt/~michel/MI/SBD/
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–1
Bibliografia
Livro principal:
• Fundamentals of Database Systems, por Elmasri e Navathe (3rd edition),
Addison Wesley, 1999.
Recomendados:
• Database Systems: The Complete Book, by Garcia-Molina, Ullman, and
Widom (first edition), Prentice Hall, 2002.
• A Guide to the SQL Standard: A User's Guide to the Standard Database
Language SQL, (fourth edition), by C.J. Date and Hugh Darwen, AddisonWesley, 2000.
• PostgreSQL: Introduction and Concepts, Bruce Momjian, Addison-Wesley,
2001.
Podem ser utéis também:
• Livros sobre Unix, Perl, PHP e CGI.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–2
Avaliação
• Um trabalho (a definir na 3ª aula): 30% da nota.
• Um exame final: 70% da nota.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–3
Programa
• O Modelo Relacional de Bases de Dados
• Bases de Dados Orientadas por Objectos, Bases de Dados
“object-relational”, Bases de Dados semi-estruturadas e
Bases de Dados XML.
• Bases de Dados Lógicas (dedutivas).
• “Online Analytical Processing” (OLAP) e
“Datawarehousing”
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–4
O que é um sistema de gestão de BD?
1.
Gere uma grande quantidade de dados.
2. Permite um acesso eficiente a uma grande quantidade de dados.
3. Permite acesso concorrente a uma grande quantidade de dados.

Exemplo: banco e as caixas Multibanco.
4. Permite acesso seguro (atómico) a uma grande quantidade de dados.

Imaginem duas pessoas a editar o mesmo ficheiro UNIX – a última a gravar «ganha» - com
o problema de duas pessoas levantarem dinheiro da mesma conta via Multibanco ao mesmo
tempo – o novo saldo fica errado, qualquer que seja a pessoa a gravar em último lugar.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–5
Modelo Relacional
• Baseado em tabelas, como:
conta # nome
12345
34567
…
saldo
Sandra 1000.21
Alice
285.48
…
…
• É usado na maioria dos SGBD’s actuais.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–6
O Mercado dos SGBD’s
•
•
•
•
•
Empresas de SGBD’s Relacionais – Oracle, Sybase – estão entre as maiores empresas de
software do mundo.
IBM fornece o seu sistema relacional DB2.
A Microsoft fornece o SQL-Server, mais o Microsoft Access para SGBD’s baratos sobre
computadores pessoais, respondidos por sistemas “lite” da concorrência.
As empresas de BD relacionais também começam a sofrer a concorrência de empresas
de “BD orientadas-a-objectos”.
Muitos sistemas começam a ser “object-relational”, mantendo o núcleo relacional e
permitindo extensões baseadas em sistemas OO.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–7
Três aspectos no estudo de SGBD’s
1. Modelação e desenho de Bases de Dados.

2.
Permite a análise de questões antes de passar a uma fase de
implementação.
Programação: consultas e operações à BD como actualização
(update).

SQL = “intergalactic dataspeak.”
3. Implementação de SGBD’s.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–8
Linguagens de Consulta
Empregado
Nome
Departamento
Dept
Dept
Director
SQL
SELECT Director
FROM Empregado, Departamento
WHERE Empregado.nome = "Clark Kent”
AND Empregado.Dept = Departamento.Dept
Linguagem de Consulta
Data definition language (DDL) ~ semelhante a type defs em C ou Pascal
Data Manipulation Language (DML)
Consulta (SELECT)
UPDATE < nome da relação>
SET <atributo> = < novo-valor>
WHERE <condição>
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–9
Linguagens “Host”
C, C++, Fortran, Lisp, COBOL
Progr. Aplicação
Chamadas à
BD
SGBD
Variáveis locais
(Memória)
(Armaz.)
Linguagem “host” é completamente geral (Turing complete) mas não
fornece suporte primitivo a BD’s.
Linguagem de consulta — menos geral “não procedimental”, e optimizável
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–10
O modelo relacional é bom para:
Grande quantidade de dados —> operações simples
Navegar dentro de um número pequeno de relações
Aplicações difíceis para o modelo relacional:
• Desenho de circuitos VLSI (CAD em geral)
• CASE
• Informação gráfica
ALU
ADDER
A
FA
CPU
Adder
ALU
ADDER
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–11
Onde o número de “relações” é grande, relacionamentos são complexos
•
•
Modelo de Dados Orientado a Objectos
Modelo de Dados Lógico
Modelo de Dados Orientado a Objectos
1.
2.
3.
4.
Objectos Complexos – Estrutura embricada (apontadores ou
referências)
Encapsulamento, conjunto de funções de Acesso/Métodos
Identidade de Objecto
Herança – Definição de novas classes com base em classes antigas
Modelo de Objectos: normalmente a procura de objectos é por navegação explicita
Existe também uma linguagem de consulta em alguns sistemas
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–12
Modelo de Dados Lógico (Horn Clause)
• Prolog, Datalog
Se A1 e A2 então B
prolog B:- A1 and A2
Funções s(5) = 6 (sucessor)
Predicados com Argumentos sum(X,Y,Z)
X+Y=Z
sum(X,0,X) significa X + 0 = X (verdadeiro para todo X)
sum(X,s(Y),s(Z)):-sum(X,Y,Z)
significa X+(Y+1) = (Z+1) se X + Y = Z
Mais poderoso que o relacional
Pode calcular o fecho transitivo
edge(X,Y)
path(X,Y) :- edge(X,Y)
path(X,Z) :- path(X,Y) & edge(Y,Z)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–13
60’s
Hierárquico
Rede
70's
80's
Escolha da maioria das
aplicações
Relacional
90’s
BD OO
BD Dedutivas
agora
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–14
Modelo Entidade-Relacionamento
• Entidades:
objecto ou conceito do mundo real com uma existência independente
 com existência física, e.g. carro, empregado, produto, aluno, etc.
 com existência conceptual: uma empresa, uma profissão, um curso, etc.

• Atributos:

propriedades que caracterizam (e estão associadas) uma entidade
• atributos de Pessoa: nome, sexo, data nascimento, morada,
etc.
• Relacionamentos

representam interacções entre 2 ou mais entidades
trabalha(empregado, departamento)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–15
Modelo ER: Atributos
•
•
Valores dos atributos = Informação da BD
Domínios de atributos

•
conj. de valores que podem ser atribuídos a um atributo de uma entidade.
Tipos de atributos:

atributo simples ou atómico: não é divisível.

atributo composto: divisível em atributos simples com significado independente
• o atributo Endereço da entidade PESSOA pode ser decomposto em: Rua, Cidade e
CódigoPostal.

atributo de valor único: têm apenas um valor para uma determinada entidade

atributo de valores-múltiplos: pode tomar 1 ou mais valores de um conjunto de
valores para a mesma entidade.
• entidade CARRO, atributo Cor-do-carro (vermelho, branco, cinza, …)
• entidade PESSOA, atributo TítuloAcadémico (licenciado, mestre, doutor,…)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–16
Modelo ER: Atributos (cont.)
•
Tipos de atributos:

atributo derivado: pode ser derivado de outro atributo.
• Idade pode ser derivado de DataNascimento

atributo com valor nulo (NULL)
• quando o atributo não é aplicável a uma determinada entidade.
• Ex: o atributo TítulosAcadémicos só se aplica a pessoas com curso superior, sendo nulo
para as restantes.
•
Interpretações para o valor NULL:

o atributo não se aplica;

o valor do atributo não é conhecido ou está em falta.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–17
Modelo ER: Entidade Tipo
• Entidade Tipo:
determina o esquema para um conjunto de entidades que partilham a
mesma estrutura (atributos).
 caracteriza-se por um nome e uma lista de atributos.

Esquema da entidade-tipo EMPREGADO:
EMPREGADO(Nome, Idade, Salário)
• Atributo chave de uma entidade-tipo:

é o atributo que identifica de forma únivoca cada entidade.
• deve aparecer sublinhado.
Ex:
EMPRESA( Nome, Endereço, Presidente)
PESSOA( Nome, NumBI, DataNasc, Endereço, …)

pode ser constituído por mais do que um atributo simples.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–18
Requisitos de uma BDs de uma Empresa
•
Uma empresa está dividida em departamentos. Cada departamento tem um nome, um número e um gerente. Inclui
ainda a data em que o gerente começou a gerir o departamento. O departamento pode ter várias localizações.
•
Um departamento controla um determinado número de projectos. Cada projecto tem um nome, um número e uma
localização única.
•
Para cada empregado, guardar o nome, o número do BI, endereç, salário, sexo e data de nascimento.
Um empregado pertence a um departamento, mas pode trabalhar em vários projectos, que não são necessáriamente
controlados pelo mesmo departamento.
Tomar nota do número de horas por semana que um empregado trabalha num dado projecto. Tomar nota do supervisor
directo de cada empregado.
•
Tomar nota do número de dependentes de cada empregado para efeitos de seguro. Para cada dependente, guardar o
nome, sexo, data de nascimento e grau de parentesco para o empregado.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–19
Construção do modelo ER para a BD-Empresa
•
Identificar entidades-tipo e atributos:
1. DEPARTAMENTO( Nome, Num, {Local}, Gerente, GerData)
atributos com valores múltiplos: Local
2. PROJECTO( Nome, Num, {Localização}, DepCtl)
3. EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço,Salário,Dnasc, Dept, Super)
4. DEPENDENTE( Empregado, DNome, Sexo, Dnasc, GrauPar)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–20
Construção do modelo ER para a BD-Empresa
Falta representar:

1 empregado trabalha em N projectos

num. de horas que cada empregado trabalha em cada projecto Identificar entidades-tipo e
atributos:
•
Podemos representar esta info como:

atributo-composto-multivalor da entidade Empregado
TrabalhaEm( Projecto, Horas)

atributo-composto-multivalor da entidade Projecto:
Trabalhadores( Empregado, Horas)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–21
Relacionamentos
Falta representar (entre outros):
“um Departamento tem um Director que o dirige; um Director é um empregado”
Dirige( Departamento, Empregado)
•
O esquema Dirige traduz um relacionamento entre 2 entidades, Departamento e Empregado.
•
No modelo ER, uma entidade não pode referenciar directamente outra entidade; tal necessidade
traduz-se na definição de um relacionamento.
•
Outros relacionamentos:
TrabalhaPara(Empregado,Departamento)
Controla(Departamento,Projecto)
DependeDe(Dependente,Empregado)
Supervisiona(Empregado,Empregado)
TrabalhaEm(Empregado,Projecto,Horas)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–22
Esquema da BDs
Com a definição dos relacionamentos, algunds dos atributos são redundantes pelo que não devem ser
incluídos no esquema. O esquema consiste:
•
Entidades:
DEPARTAMENTO( Nome, Num, {Local}, )
PROJECTO( Nome, Num, {Localização} )
EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço,Salário,Dnasc)
DEPENDENTE( DNome, Sexo, Dnasc, GrauPar)
•
Relacionamentos:
trabalhaPara(Empregado,Departamento) dependeDe(Dependente,Empregado)
•
controla(Departamento,Projecto)
dirige(Empregado,Departamento, GerData)
supervisiona(Empregado,Empregado)
trabalhaEm(Empregado,Projecto,Horas)
Falta analisar o tipo de participação das entidades no relacionamentos.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–23
Relacionamentos (Grau e Atributos)
•
Grau de um relacionamento:

número de entidades no relacionamento.

Ex. de um relacionamento ternário:
fornece(Fornecedor, Produto, Projecto)
•
Relacionamentos com atributos.
Horas é um atributo do relacionamento
trabalhaEm(Empregado, Projecto, Horas)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–24
Relacionamentos (Restrições)
•
•
Restrições nos relacionamentos:

permitem limitar as combinações possíveis entre entidades participantes

Ex: um empregado trabalha para apenas um departamento.
Tipos de Restrições:

Cardinalidade dos Relacionamenos:
• tipo de participação das entidades no relacionamento
• 1 : N -- um para-muitos
trabalhaPara(Empregado, Departamento)
• M : N -- muitos-para -muitos
trabalhaEm(Empregado, Projecto, Horas)
• 1 : 1 -- um-para-muitos
dirige(Empregado, Departamento)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–25
Restrições nos Relacionamentos (cont.)

Tipo de participação:
• especifica se a existência de uma instância de entidade depende do seu
relacionamento com outra entidade, via esse relacionamento.
• Participação total (dependência existêncial)
– quando todas as instâncias de uma entidade estão relacionadas com
alguma instância de uma outra entidade participante no
relacionamento.
trabalhaPara(Empregado, Departamento)
• Participação parcial
– quando não se espera que todas as instâncias de uma entidade
participem no relacionamento.
dirige(Empregado, Departamento)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–26
Entidades Fracas
• Entidade Fraca:

é identificada pelo seu relacionamento (relacionamento
identificador) com determinadas entidades (entidade
identificadora)

tem sempre participação total (dependência existêncial) em
relação ao relacionamento-identificador.

Possui uma chave-parcial, que é o conjunto de atributos que
univocamente determinam a entidade fraca relacionada com a
mesma entidade-identificadora.

Ex: dependenDe(Dependente, Empregado)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–27
Modelo ER para a BDs sobre uma Empresa
•
Entidades-tipo:
DEPARTAMENTO( Nome, Num, {Local}, )
PROJECTO( Nome, Num, Local )
EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço, Salário, Dnasc )
DEPENDENTE( DNome, Sexo, Dnasc, GrauPar )
•
Relacionamentos:
trabalhaPara(Empregado,Departamento)
N:1
total/total
dependeDe(Dependente,Empregado)
N:1
total/parcial
controla(Departamento,Projecto)
1:N
parcial/total
dirige(Empregado,Departamento, GerData)
1:1
parcial/parcial
supervisiona(Empregado,Empregado)
1:N
parcial/parcial
M:N
total/total
Supervisor
Supervisionado
trabalhaEm(Empregado,Projecto,Horas)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–28
Diagramas ER
•
Ênfase na representação dos esquemas em vez de instâncias de entidades e
relacionamentos.
•
Notação para os diagramas:
Atributo
Atributo-Chave
Entidade-Tipo
Atributo-Multivalor
Entidade-Fraca
Atributo-Derivado
Relacionamento
Atributo-Composto
Relacionamentoidentificador
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–29
Diagramas ER (cont.)
E1
E1
R
1
E2
N
R
R
1:N
E2
E
(min,max)
Participação-total de E2
em R
Restrição-estrutural
da participaçaõ de E em R
• Uma entidade E participa num relacionamento R com restrição (min,max) em que
0 >= min <= max e max >= 0, se para cada entidade e de E, e participa pelo menos
min e no máximo max instâncias do relacionamento R.
min = 0 -- participação parcial
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–30
Exemplo Restrição-Estrutural
• No diagrama:
um empregado trabalha para um departamento
 Num departamento trabalham pelo menos 4 empregados

Empregado
(1,1)
(4,N)
trabalhaPara
Departamento
• Nomes para as entidades-tipo, atributos e relacionamentos deve ser
feita com critério:
entidades - nomes singular
 atributos - nomes
 relacionamentos - nomes ou verbos de forma a facilitar a leitura da
esquerda para
a direita

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–31
O Modelo EER (ER Extendido)
•
BDs recentes (Multimédia, GIS, CAD/CAM,…) requerem novos conceitos semânticos
de modelação:

•
subclasse, superclasse, especialização e generalização, herança de atributos, etc.
Subclasses e Superclasses



uma subclasse corresponde a um sub-conjunto de entidades com alguma característica comum
e pertencentes à mesma entidade-tipo
superclasse corresponde à entidade-tipo que aglutina os vários sub-conjuntos de entidades, i.e.
subclasses.
Ex:
Empregado
superclasse
subclasses
MI, MIAC 2002
Secretárias
Engenheiros
Michel Ferreira, DCC - FCUP
Técnicos
Directores
1–32
O Modelo EER (Relacionamento ISA)
• O relacionamento ISA (ou superclasse/subclasse) caracteriza a ligação
entre as subclasses e a respectiva superclasse
Director
isa
Empregado
Secretária
isa
Empregado
Técnico
isa
Empregado
uma entidade membro de uma subclasse representa a mesma entidadefísica de um membro da superclasse, apenas os “papeis” são diferentes.
 Ex. A entidade Director de nome X é a mesma entidade X de Empregado;

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–33
EER: Herança de Atributos
• As subclasses herdam todos os atributos da sua superclasse
• uma subclasse com todos os atributos que herda da superclasse, é uma
entidade-tipo.
• Porquê a divisão em subclasses?
Certos atributos aplicam-se a apenas algumas instâncias da superclasse
 Alguns relacionamentos podem ter participação de apenas alguns
membros de uma subclasse

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–34
EER: Especialização
• Especialização





é o processo de de definição do conjunto das subclasses de uma
entidade-tipo (superclasse da especialização)
e.g. {Secretária, Engenheiro, Técnico} especializa
Empregado com base no tipo de trabalho.
podemos ter várias especializações da mesma entidade-tipo com
base em diferentes características.
Podemos associar atributos específicos (extra) a cada subclasse
estabelecer relacionamentos-tipo específicos entre uma subclasse e
outras entidades-tipo ou outras subclasses
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–35
Diagrama EER
• 3 especializações de Empregado
Nome
Empregado
NumBI
d
d
EmpPrazo
Director
EmpEfectivo
Escalão
Secretária
Técnico
Engenheiro
Salário
Salário
Efiliado
dirige
Qualificação
EngTipo
VelEscrita
Sindicato
Projecto
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–36
EER: Generalização
•
Generalização: processo funcionalmente inverso da especialização.

eliminam-se as diferenças entre várias entidades-tipo, identificam-se as caracteristicas comuns que passarão a
caracterizar uma nova superclasse da qual as entidades-tipo originais são subclasses especiais.
Carro(Matricula, Nreg, Npass, VelMax, Preço)
Camião(Matricula, Nreg, Neixos, Tonelagem, Preço)
generalizando temos:
Nreg
Veículo
Matricula
Preço
d
Carro
Camião
Tonelagem
Npass
VelMax
MI, MIAC 2002
Neixos
Michel Ferreira, DCC - FCUP
1–37
Tipos de Especialização/Generalização
• Especialização definida-por-atributo
quando a divisão em subclasses se basei numa condição de membro
 e.g. condição tipoTrabalho=“secretária” determina quais dos empregados
vão pertencer à subclasse Secretária.

• Especialização definida-por-utilizador

quando não existe a condição.
• Especialização disjunta

d
quando as subclasses são disjuntas, i.e. cada entidade pode ser membro de
no máximo uma subclasse de especialização.
• Especialização com sobreposição o

quando a mesma entidade pode pertencer a mais do que uma subclasse,
e.g. a superclasse Pessoa pode decompor-se em subclasses Empregado,
Estudante, Licenciado (e.g. um assistente é um empregado da
universidade, é licenciado e é aluno de doutoramento)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–38
Tipos de Especialização/Generalização (cont.)
• Especialização Total (linhas duplas nos diagramas)
quando toda a entidade de uma superclasse tem de ser membro de alguma
sub-classe.
 e.g. especialização {EmpEfectivo, EmpPrazo} de Empregado. Todos
empregados estão numa das subclasses.

• Especialização Parcial (linha simples nos diagramas)

permite que uma entidade não pertença a qualquer das subclasses.
• Temos assim 4 tipos de especialização:
disjunta total; disjunta parcial; sobreposição total; sobreposiçaõ parcial
 o tipo de especialização é determinado a partir do significado na vida real

• A generalização de uma superclasse é habitualmente total

contém as entidades das subclasses de onde foi derivada.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–39
Modelo Relacional
• Introduzido por Codd (1970)
• Base de Dados = Conjunto de relações
• Relação <==> Tabela
Filme (Título, Ano, Duração, Tipo)
Esquema
atributos
Filme
Título
Ano
Zorro
1998
Guerra das Estrelas 1977
Mighty Ducks
MI, MIAC 2002
1991
Duração
Tipo
120
124
104
cor
cor
cor
Michel Ferreira, DCC - FCUP
tabela
tuplo
1–40
Esquema Relacional de uma BDs
Empregado(Pnome,Unome,EBI,Dnasc,Morada,Sexo,Salário,SuperBI,Ndep)
Departamento(Dnome,Dnum, DirBI, DirData)
Locais_Dep(Dnum,Dlocal)
Projecto(Pnome,Pnum,Plocal)
TrabalhaEm(EBI,Pnum,Horas)
Dependente(EBI,Nome,Sexo,Dnasc,GrauParentesco)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–41
Modelo Relacional: conceitos
• Domínio:

conjunto de valores de um dado tipo que caracterizam um atributo
• Tuplos:
sequência ordenada de valores (ordem da sequência é importante)
 tuplos de uma relação (ou tabela) não têm ordem
 os valores das componentes de um tuplo são atómicos

• no relacional não pode haver atributos compostos ou multivalor
• Chave de uma relação R
identifica de forma única os tuplos de R
 conjunto mínimo de atributos de R, t.q. não existem 2 tuplos distintos de R
com valores iguais nesses atributos.
 Uma relação pode ter várias chaves candidatas

• chave primária; chaves alternativas
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–42
Restrições Intrínsecas do Relacional
•
Integridade de entidade

•
Unicidade da chave

•
não podem existir 2 tuplos diferentes com valores iguais na chave
Chave externa

•
os valores da chave-primária não podem ser nulos
conjunto de atributos de uma relação que referenciam a chave de outra relação
Integridade referêncial

um tuplo de uma relação que se refira a uma outra relação, tem de se referir a um tuplo existente nessa relação
•
•
garante consistência entre tuplos de 2 relações
e.g. os tuplos correspondentes ao empregado-supervisor com EBI 3456789 e ao departamento número 5 têm de existir, dado o
seguinte empregado:
Empregado(João,Pinto,7654321,19975-03-04,R. das Fontainhas,M,250000,3456789,5)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–43
Interpretação de uma relação
•
•
•
•
Relações uniformizam a representação de factos sobre entidades e
relacionamentos
Um esquema de uma relação deve ser visto como uma declaração
Esquema de BD relacional = conjunto de esquemas relacionais +
conjunto de restrições de integridade
Operações no modelo relacional:
actualizações: inserir, remover e modificar
 consultas: álgebra relacional

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–44
Operação inserir
•
•
Permite inserir um ou mais tuplos numa tabela
pode violar qualquer dos 4 tipos de restrições:
domínio: se um dos valores não pertencer ao domínio
 chave: o valor da chave do novo tuplo já existe num outro tuplo da tabela
 integridade de entidade: se o valor da chave do novo tuplo for null
 integridade referêncial: se o valor de uma chave externa referir um tuplo não
existente.

•
Se uma das restrições for violada, opta-se por:
rejeitar a inserção (com aviso ao utilizador)
 ou, tentar corrigir a razão para a rejeição ocorrer.

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–45
Operação remover
• remove tuplos de valores de uma tabela
• pode violar apenas a integridade referêncial:

no caso de o tuplo a remover for referenciado por uma das chavesexternas de outro tuplo naBDs.
• Requer uma condição sobre os atributos de forma a selecionar o tuplo
ou tuplos a serem removidos

remover todos os empregados do departamento 10.
• Caso ocorra violação, opta-se por:
rejeitar a operação, ou
 procurar propagar a operação e remover todos os tuplos que referenciam o
que está a ser removido, ou
 alterar para null os valores dos atributos dos tuplos que referenciam o que
está a ser removido

• Operação modificar = remover+inserir (regras destas operações)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–46
Conversão do Modelo ER para o Modelo Relacional
•
Passo 1:



entidade-tipo
relação
atributos simples da entidade
atributos compostos
chave da entidade
atributos da relação
atributos individuais na relação
chave da relação
Sexo
...
Pnome
EBI
Nome
Empregado
Empregado
MI, MIAC 2002
Pnome
Unome
Unome
EBI
Sexo
...
Michel Ferreira, DCC - FCUP
1–47
ER
•
Passo 2:


Relacional
entidade-fraca
relação
Seja W uma entidade-fraca e E a entidade-identificadora de W:
Criar uma relação R em que:
•
•
atributos simples de W
chave-principal de E e chave-parcial de W
atributos de R
chave-principal de R
Nome
dependeDe
Empregado
EBI
Dependente
...
...
Chave-externa
Dependente
MI, MIAC 2002
EBI
Nome
Sexo
...
Michel Ferreira, DCC - FCUP
1–48
ER
•
Passo 3:


Relacional
relacionamento binário 1:1 R(E1,E2)
Sejam S e T as relações correspondentes às entidade E1 e E2, respectivamente.
Escolhes-se uma das relações, e.g. S (a que corresponde à entidade com participação total em R) e:
•
•
incluir como chave externa em S a chave-principal de T
incluir todos atributos simples do relacionamento R na relação S
Dnum
Empregado
EBI
dirige
(0,1)
Departamento
(1,1)
...
DirData
Chave-externa
Departamento Dnome
MI, MIAC 2002
Dnum
DirBI
DirData
Michel Ferreira, DCC - FCUP
1–49
ER
•
Passo 4:


Relacional
relacionamento binário 1:N R(E1,E2)
Sejam S e T as relações correspondentes às entidade E1 e E2, respectivamente.
Escolhes-se a relação que corresponde à entidade participante do lado N em R, suponha-se que é S:
•
•
incluir como chave externa em S a chave-principal de T
incluir todos atributos simples do relacionamento R na relação S
Dnum
EBI
trabalhaPara
Empregado
Departamento
1
N
...
Chave-externa
Empregado
MI, MIAC 2002
Pnome
...
EBI
... DNum
Michel Ferreira, DCC - FCUP
1–50
ER
•
Passo 5:

Relacional
relacionamento binário M:N R(E1,E2)
Criar uma nova relação S para representar o relacionamento R.
•
•
•
incluir como chave externa em S as chaves-principais das relações que representam as entidades E1 e E2
participantes em R
o conjunto das chaves-externas formará a chave-principal de S
incluir todos atributos simples do relacionamento R na relação S
Pnum
EBI
trabalhaEm
Empregado
Projecto
N
M
...
Horas
trabalhaEm
MI, MIAC 2002
EBI
Pnum
Michel Ferreira, DCC - FCUP
chaves-externas
e
chave-principal
Horas
1–51
ER
•
Passo 5:

Relacional
relacionamento binário M:N R(E1,E2)
Criar uma nova relação S para representar o relacionamento R.
•
•
•
incluir como chave externa em S as chaves-principais das relações que representam as entidades E1 e E2
participantes em R
o conjunto das chaves-externas formará a chave-principal de S
incluir todos atributos simples do relacionamento R na relação S
Pnum
EBI
trabalhaEm
Empregado
Projecto
N
M
...
Horas
chaves-externas
e
chave-principal
Nota: os relacionamentos 1:1 e 1:N
também podem ser transformados de
acordo com o passo 5.
trabalhaEm
MI, MIAC 2002
EBI
Pnum
Michel Ferreira, DCC - FCUP
Horas
1–52
ER
•
Passo 6:

Relacional
atributos-multivalor
Para cada atributo A multivalor, cria-se uma nova relação S que
•
•
inclui o atributo de A mais a chave-principal, K, da relação que representa a entidade ou relacionamento
que tem A como atributo multivalor.
A chave-principal de S será acombinação de A e K.
Dnum
Departamento
Dlocal
Ex: um departamento pode ter
várias localizações.
...
Locais_Dep
Dnum
Dlocal
Nota: os passos de 1 a 6 seriam suficientes
para converter o esquema-ER no
esquema-relacional para a BDs Empresa.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–53
ER
•
Passo 7:

Relacional
relacionamentos com aridade superior a 2 (mais de 2 entidades)
Para cada relacionamento R com aridade n>2, criar uma nova relação S:
•
•
•
incluir como chaves-externas em S, as chaves-principais das relações que representam as entidades participantes.
A chave-principal de S será o conjunto de todas as chaves-externas.
Incluir como atributos de S, todos os atributos do relacionamento R.
Fnome
Fornecedor
fornecimento
Projecto
Qtd
Pnum
Produto
Pnome
Fornecimento
MI, MIAC 2002
Fnome
Pnome
Pnum
Qtd
Michel Ferreira, DCC - FCUP
1–54
EER
•
Relacional
Passo 8: Converter cada especializaçao com m subclasses (S1,…,Sm) e superclasse (generalizada) C,
onde os atributos de C sao (k,a1,…,an) em que k é a chave primária, para relaçoes usando uma das
seguintes 4 opçoes:




8a – Criar uma relaçao L para C com atributos atrib(L) = (k, a1,…,an) e cp(L) = k. Criar uma relaçao Li para
cada subclasse Si, 1<=i<=m, com atributos atrib(Li)=(k) + (atributos de Si) e cp(Li) = k.
8b - Criar uma relaçao Li para cada subclasse Si, 1<=i<=m, com atributos atrib(Li)=(atributos de Si) +
(k,a1,…,an) e cp(Li) = k.
8 c - Criar uma única relaçao L com atributos atrib(L) = (k, a1,…,an) + (atributos de S1) + … + (atributos de
Sm) + (t) e cp(L) = k. Esta opçao é para uma especializaçao com subclasses disjuntas, e t é um atributo de tipo
que indica a subclasse a que cada tuplo pertence, se alguma.
8d - Criar uma única relaçao L com atributos atrib(L) = (k, a1,…,an) + (atributos de S1) + … + (atributos de
Sm) + (t1, …, tm) e cp(L) = k. Esta opçao é para uma especializaçao com subclasses sobrepostas, e cada ti,
1<=i<=m, é um atributo booleano que indica se um tuplo pertence à subclasse Si.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–55
Exercício de modelação
Os STCP pretendem construir uma base de dados sobre os percursos dos
seus autocarros. A base de dados deve guardar informação relativa aos
autocarros, como sejam a matrícula, a data de entrada em serviço, o número de
quilómetros,
a
data
da
próxima
revisão
e
o
tipo
(marca/modelo)
de
autocarro. Cada tipo de autocarro tem uma marca, um modelo, um número
de lugares sentados e um número de lugares de pé. A base de dados deve
guardar também informação relativa aos percursos. Um percurso é identificado por
um
número
(e.g.
78,
35)
e
tem
uma
distância
total
em
quilómetros.
Os
percursos
percorrem
paragens.
As
paragens
têm
um
número identificador, um nome, e uma localização decomposta em local,
rua e número. Existem limitações aos percursos que um determinado tipo
de autocarro pode fazer, inerentes às suas dimensões. Estas limitações
devem ficar registadas na base de dados. Existe um percurso especial
para quando um autocarro mais o respectivo condutor são alugados, e
este percurso não percorre paragens. Deve ser guardada também informação
relativa aos condutores, como sejam o número de BI, o nome, a morada, a data de
entrada em serviço e os percursos que cada condutor está habilitado a fazer (um
condutor
pode
estar
habilitado
a
fazer
vários
percursos).
Na
base
de
dados
deve
ficar
registada
também
informação
operacional
diária,
correspondente
ao
registo
de
saídas.
Existem
três
turnos
de
saída, 6h, 14h e 22h. Um autocarro e um condutor fazem no máximo uma
saída por dia, podendo não fazer nenhuma. A informação do registo de
saída inclui a data, o turno, o condutor, o autocarro e o percurso atribuído.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–56
Exercício de modelação (cont.)
•
•
•
Desenhe um diagrama-ER ou EER para a base de dados descrita acima indicando as
chaves das entidades, a cardinalidade dos
relacionamentos e o tipo de participações.
Converta o diagrama da alínea anterior para o modelo relacional justificando os passos
que efectua na conversão.
Diga se o seu modelo relacional consegue responder à questão
``Na data 24/12/00 no turno das 22h quantos autocarros fizeram o
percurso 78?''. Justifique.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–57
“Boas” relações: como?
•
o significado do esquema da relação deve ser simples de explicar

•
não combinar os atributos de várias entidades e relacionamentos numa única
relação
evitar relações que permitam o aparecimento de anomalias de inserção:
Emp_Dep(Enome, EBI, Dnasc, Morada, Dnum, Dnome, DirDep)
• inserir um tuplo de um novo empregado, teremos de incluir valores sobre o departamento
onde trabalha. Quando adicionamos info sobre o departamento, temos de ser consistentes
com os valores adicionados sobre o mesmo departamento para outros empregados
•
•
evitar ter atributos numa relação cujo valor pode ser nulo, pois nem sempre se
sabe qual a interpretação a aplicar.
conceber relações que possam ser combinadas por uma operação de junção
com base numa condição de igualdade em atributos que são chaves-principais
ou chaves-externas (evita-se gerar tuplos que não deviam existir -- spurious
tuples)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–58
Desenho de BDs
SGBD O-O
ODL
(object definition lang.)
Relações
Ideias
(info a modelar)
ER/EER
(entidade/relacionamento)
Conceptualização
•
SGBD Relacional
Implementação
A modelação visa definir a estrutura da BDs antes da sua implementação, de forma a permitir a sua
compreensão por parte dos utilizadores.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–59
Bases de Dados orientadas a objectos
• Os modelos de BD relacionais, hierárquicos e de rede tem
sido bem sucedidos nas aplicaçoes tradicionais que
requerem recurso a BD’s.
• Aplicacoes mais complexas revelaram algumas falhas
destes modelos:



Telecomunicacoes
Sistemas de Informaçao Geográfica
Multimédia
• Problemas:




Estruturas de objectos do mundo real mais complexas
Transacçoes de longa duraçao
Novos tipos de dados para representar imagens e outros objectos
binários de grande dimensao (BLOB’s)
Definiçao de operaçoes nao-standard para aplicaçoes específicas
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–60
BD’s orientadas a objectos (cont.)
• As BDOO permitem especificar num único processo de
modelaçao a estrutura de objectos complexos bem como as
operaçoes específicas aplicáveis a esses objectos.
• O crescente uso de linguagens de programaçao genéricas
OO torna útil a existencia de SGBOO onde a integraçao de
código seja facilitada.
• Os sistemas relacionais começam a incluir também
conceitos OO – sistemas “object-relational” – extendendose ao SQL – SQL3.
• Alguns protótipos de SGBDOO:


OPENOODB – Texas Instruments
ODE – AT & T Bell Labs
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–61
Conceitos de BDOO’s
• Identidade de objecto


Identidade única de cada objecto do mundo real
Identificador único (gerado pelo sistema)
•
•
•
•

Imutável
Usado uma única vez
Independente de atributos
Por vezes baseado no endereço físico
Os primeiros modelos OO requeriam que tudo – desde um simples
valor a um objecto complexo – fosse representado como um
objecto:
• Inteiros, strings, valores Booleanos – tem um identificador de
objecto.
• Nao é eficiente e os SBDOO distinguem entre objecto e valor.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–62
Conceitos de BDOO’s (cont.)
• Estrutura de objecto

O estado (valor actual) de um objecto complexo pode ser
construído a partir de outros objectos (ou outros valores) usando
construtores de tipo.
• Um objecto é formalmente representado por trio (i, c, v), onde i é um
idenficador de objecto único, c é um construtor de tipo e v é o estado
do objecto (ou valor corrente).
• Existem vários construtores de tipo:
–
–
–
–
–
–
Atom
Tuple
Set
List
Bag
Array
• O estado de um objecto, v, (i,c,v), é interpretado com base no
construtor.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–63
Estrutura de objecto
• Se o construtor c é atom o estado (valor) v é um valor
atómico do domínio de valores básicos suportados pelo
sistema (inteiros, strings, etc.).
• Se c = set, o estado v é um conjunto de identificadores de
objecto, referenciando objectos que, tipicamente, sao do
mesmo tipo.
• Se c = tuple, v é um tuplo da forma <a1:i1,a2:i2,...,an:in>
onde cada ai é um nome de atributo e cada ii é um IDO.
• Se c = list, v é uma lista ordenada [i1,i2,...,in] de IDO’s do
mesmo tipo.
• Os objectos podem ser estruturados arbitrariamente
aplicando vários tipos de construtores.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–64
Exemplos de objectos
O1 = (i1, atom, ‘Houston’)
O2 = (i2, atom, ‘Bellaire’)
O3 = (i3, atom, ‘Sugarland’)
O4 = (i4, atom, 5)
O5 = (i5, atom, ‘Research’)
O6 = (i6, atom, ‘1988-05-22’)
O7 = (i7, set, {i1,i2,i3})
O8 = (i8, tuple, <DNAME:i5,DNUMBER:i4,MGR:i9,LOCATIONS:i7,EMPLOYEES:i10,
PROJECTS:i11>)
O9 = (i9, tuple, <MANAGER:i12,MANAGER_START_DATE:i6>)
O10 = (i10, set, {i12,i13,i14})
O11 = (i11, set, {i15,i16,i17})
O12 = (i12, tuple, <FNAME:i18,MINIT:i19,LNAME:i20,SSN:i21,...,SALARY:i26,
SUPERVISOR:i27,DEPT:i8>)
...
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–65
Representaçao de um objecto complexo como um grafo
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–66
Objectos identicos vs. iguais
• Dois objectos tem estados identicos (deep equality) se os
grafos representando os seus estados sao identicos em
todos os aspectos, incluindo os IDO’s em todos os níveis.
• Dois objectos tem estados iguais (shalow equality) se a
estrutura dos seus grafos é a mesma e todos os valores
atómicos no grafo sao também os mesmos.

Exemplo:
•
•
•
•
•
•

O1 = (i1, tuple, <a1:i4,a2:i6>)
O2 = (i2, tuple, <a1:i5,a2:i6>)
O3 = (i3, tuple, <a1:i4,a2:i6>)
O4 = (i4, atom, 10)
O5 = (i5, atom, 10)
O6 = (i6, atom, 20)
Os objectos O1 e O2 tem estados iguais, enquanto O1 e O3 tem
estados identicos.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–67
Linguagem de definiçao de objectos (ODL)
• Uma linguagem de definiçao de objectos que inclua os construtores de
tipo descritos pode ser usada para definir os tipos de objectos de uma
determinada aplicaçao de BD.

Exemplo:
Definiçao de estruturas de dados de um esquema de BD OO:
define type Employee:
tuple (
fname:
minit:
lname:
ssn:
birthdate:
address: string;
sex:
salary:
supervisor:
dept:
MI, MIAC 2002
string;
char;
string;
string;
Date;
char;
float;
Employee;
Department;
Michel Ferreira, DCC - FCUP
);
1–68
Encapsulamento
• Na declaraçao dos objectos é possível incluir a definiçao dos métodos
aplicáveis sobre os objectos.
• Em BD relacionais um conjunto de operaçoes standard sao aplicáveis
sobre todos os objectos (selecçao, inserçao, etc.).
Exemplo:
define class Employee:
type tuple (
operations
fname:
minit:
lname:
ssn:
birthdate:
address: string;
sex:
salary:
supervisor:
dept:
age:
create_emp:
destroy_emp:
string;
char;
string;
string;
Date;
char;
float;
Employee;
Department;
integer;
Employee;
boolean;
);
end Employee;
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–69
Object Definition Language
• Um standard definido pelo ODMG (bem como o OQL (questões)).
• Permite especificar a estrutura (esquema) da BDs.

Não permite interrogar ou manipular a BDs
• Parece-se com C++ (e Smalltalk).
• O paradigma subjacente ao ODL é:
Modelar objectos e suas propriedades.
 Objectos são identificados de forma única (OID), distinguindo-se de
qualquer outro objecto.

• Para se atingir algum nível de abstracção:

Agrupam-se os objectos em classes.
• O que é que determina uma boa classe?

Os objectos devem ter propriedades comuns (e.g. clientes de um banco)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–70
Declaração de Classes em ODL
class <nome> {
atributos: <tipo> <nome>;
relacionamentos <intervalo-tipo> <nome>;
métodos;
}
• Classes definem um tipo abstracto de dados com:
- atributos: propriedades que descrevem aspectos de um objecto por
atribução de valores ou referencia a outro objecto;
- relacionamentos: propriedades que correspondem a uma interacçao
mútua entre objectos;
- métodos (ou funções): que podem ser executados sobre objectos de
uma classe.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–71
Classes/Objectos em ODL
• class Filme {
attribute string titulo;
attribute integer ano;
attribute integer duração;
attribute enum Tfilme {cor, preto-e-branco} tipoFilme;
};
um objecto da classe Filme é o tuplo:
(“Hercules - Disney”, 1998, 94, cor)
• Os atributos podem não ser atómicos:
class Actor {
attribute string nome;
attribute Struct End {string rua, string cidade} endereço;
};
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–72
ODL - exemplo
ano
duração
título
tipo
Filme
Actor
rua
nome
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
endereço
cidade
1–73
Relacionamentos em ODL
• É natural que alguns atributos de objectos sejam referências para outros
objectos da mesma ou de outras classes.
• Como representar num objecto da classe Filme, o conjunto de Actor(es)
de um filme? Adiciona-se à classe Filme:
Para cada objecto da classe Filme
relationship Set<Actor> actuam;
existe um conjunto de referências
a objectos da classe Actor
• Relacionamentos-inversos: representamos os actores de um dado filme,
mas podemos estar também interessados nos filmes onde participa um
dado actor. Adicionar à classe Actor:
relationship Set<Filme> participa
inverse Filme::actuam;
Se S  actuam para o filme F,
Então F  participa para o Actor S
•Em ODL é necessário que os relacionamentos tenham inversa.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–74
Multiplicidade dos relacionamentos
• Para efeitos de relacionamento inverso, é importante saber
a multiplicidade do relacionamento, i.e. se um dado
objecto se relaciona com um único objecto, ou se se
relaciona com muitos outros.
• Multiplicidades mais comuns:



muitos-muitos (de C para D). Conjunto de D´s associado a cada C,
e para a inversa tem-se um conjunto de C´s associado a cada D.
muitos-um (de C para D). Para cada C existe um único D, e para a
inversa tem-se que para cada D existe um conjunto de C´s.
um-um (de C para D). Cada C está relacionado com um D e para a
inversa, cada D relaciona-se com um único C.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–75
ODL - exemplo 2
ano
duração
título
tipo
Filme
actuam
participa
Actor
rua
nome
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
endereço
cidade
1–76
ODL - exemplo
ano
duração
tipo
título
Filme
actuam
pertence
participa
possui
Estúdio
Actor
tem
Presidente
preside
nome
MI, MIAC 2002
endereç
o
nome
nome
anoInic
Michel Ferreira, DCC - FCUP
rua
endereço
cidade
1–77
Classes do exemplo
class Filme {
attribute string titulo;
attribute integer ano;
attribute integer duração;
attribute enum Tfilme
{cor, preto-e-branco} tipo;
relationship Set<Actor> actuam
inverse Actor::participa;
relationship Estúdio pertence
inverse Estúdio::possui;
};
class Actor {
attribute string nome;
attribute Struct End
{string rua, string cidade}
endereço;
relationship Set<Filme> participa
inverse Filme::actuam;
};
MI, MIAC 2002
class Estúdio {
attribute string nome;
attribute string endereço;
relationship Set<Filme> possui
inverse Filme::pertence;
relationship Presidente tem
inverse Presidente::preside;
};
class Presidente {
attribute string nome;
attribute string anoInic;
relationship Estúdio preside
inverse Estúdio::tem;
};
Michel Ferreira, DCC - FCUP
1–78
Tipos em ODL
Tipos básicos:
• tipos atómicos (string, integer, float, character, boolean,...)
• tipos interface (e.g., Filme, Actor), representam tipos mais complexos
definidos como estruturas com base em constructores tipo.
Constructors:
(1, 5, 6)
Bag: (1, 1, 5, 6, 6 )
List: (1, 5, 6, 1, 6 )
Array: Array<T,i>
Se T é um tipo, então Set<T> é o tipo cujos valores
são todos conjuntos finitos de elementos do tipo T.
Admite elementos repetidos.
string  List<char>
(T tipo, i inteiro) denota o tipo cujos elementos são
vectores com i elementos do tipo T.
Tipo-conjunto
Set:
Struct: Struct Morada {string rua, string cidade, integer código_postal}
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–79
Tipos admissíveis em ODL
Atributos: pode ser um tipo atómico ou struct; pode-se depois aplicar um
tipo-conjunto ao tipo atómico ou struct.
SIM: string, set of integer, bag of Actor
NÃO: Filme, set of set of integer
Um atributo não pode ser do tipo interface.
Relacionamentos: pode ser um tipo interface ou um tipo-conjunto aplicado
a um tipo interface.
SIM: Filme, set of Filme, list of Filme
NÃO: struct {Filme f, Actor a}, set of bag of Filme, set<integer>, integer
Um relacionamento não pode ser do tipo atómico.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–80
Correspondência entre ODL e ER
• Entidades tipo
Classes
• Atributos
Atributos
• Relacionamentos
Relacionamentos
No modelo ER, os relacionamentos tem apenas um nome nas duas
direcções e podem envolver mais do que 2 entidades (no modelo ODL,
não!).
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–81
Subclasses
• Alguns objectos numa classe poderão ter propriedades não partilhadas
por outros membros:
Filme
Cartoons
Policial
• Em ODL:
interface Cartoon: Filme {
relationship Set<Actor> vozes
inverse ...;
};
esta nova classe, além da propriedade vozes, herda ainda as propriedades da
classe Filme;
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–82
Herança múltipla
Filme
Cartoon
Policial
Quem tramou
o Roger Rabit?
Cartoon-Policial
• uma subclasse herda todas as propriedades das suas superclasses.
• as subclasses de uma classe podem dar origem a novas subclasses,
constituindo uma hierarquia de classes.
• uma classe pode ter mais do que uma superclasse.
Interface Cartoon-Policial: Cartoon, Policial {};
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–83
Herança múltipla em ER
titulo
Actor
ano
duração
tipo
Filme
vozes
isa
isa
Cartoon
arma
Policial
• as hierarquias são representadas por relacionamentos ISA.
• A isa B - A é um caso especial de B; A é uma especialização de B;
B é uma generalização de A.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–84
Restrições
• para além das restrições de estrutura e de tipos de valores, modelada
pelas classes (entidades), atributos e relacionamentos
• é necessário considerar outras restrições:

chave
conjunto de atributos que identificam de forma única um objecto ou
entidade


restrições de valor único


restrições de integridade referencial


e.g. especificar que uma pessoa pode apenas ter um pai
um valor referenciado por um objecto tem de existir.
restrições de domínio
o valor de um atributo tem de pertencer a um conjunto de valores.
e.g. idade de pessoas estão entre 0 e 150.


restrições gerais
asserções arbitrárias que têm de se verificar.
e.g. podíamos querer não registar mais do que 10 actores por filme.

MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–85
Chaves em ODL
• um objecto pode ter várias chaves.
• Exemplos:
Interface Pessoa
(key ncontrib)
{
propriedades...
};
Chave é atributo
simples
MI, MIAC 2002
Interface Filme
(key (titulo, ano))
{...};
Interface Empregado
(key empID, empBI)
{...};
Chave é atributo
composto
Michel Ferreira, DCC - FCUP
2 chaves
1–86
Princípios para boa modelação
• fidelidade
o modelo deve ser fiel ao mundo real
 os objectos (entidades) devem reflectir a realidade.
 Relacionamentos devem fazer sentido na parte do mundo em modelação

• evitar redundância

usa mais espaço; sujeito a inconsistências.
• simplicidade conta

evitar mais elementos do que é necessário.
• escolher o tipo de elemento certo

por vezes pode usar-se um atributo ou uma entidade para representar um conceito
 se uma entidade possui apenas o nome, pode ser um atributo. Se possui mais informação
deve ser entidade.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–87
Exemplo Empregado-Departamento em ODL
class Employee
(key ssn)
{ attribute string name;
attribute string ssn;
...
attribute float salary;
relationship Department works_for
inverse Department::has_emps;
void reassign_emp(in string new_dname)
raises(dname_not_valid);
};
class Department
(key numD)
{
attribute integer numD;
attribute string name;
attribute set <string> location;
atribute struct Dep_Mgr{Employee manager,
date start_date};
relationship Set<Employee> has_emps
inverse Employee::works for;
void add_emp(in_string new_ename)
raises(ename_not_valid);
}
Complete o modelo com as classes Projecto e Dependente.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–88
O Modelo Relacional
Modelo da
Base de dados
(ODL, ER)
Definições ODL
Diagramas ER
MI, MIAC 2002
Esquema
Relacional
Tabelas:
colunas: atributos
linhas: tuplos
Michel Ferreira, DCC - FCUP
Espaço em
Disco
Complexa organização
em ficheiro e estruturas
de índice
1–89
Do ODL para o Relacional
• As relações aproximam-se mais da implementação, pelo que:
(ER, ODL) ginástica mental
Relacional
• Caso simples: ODL classe com atributos de valor único.
interface Filme {
attribute string titulo;
attribute integer ano;
attribute integer duração;
attribute enum {cor, preto-e-branco} tipo;
};
Criar uma relação com o mesmo nome e atributos da classe.
Filme( título, ano, duração, tipo)
Filme
Título
Ano
Duração
Tipo
Zorro
1998
120
cor
ou como tabela:
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–90
Classes sem relacionamentos
• O ODL permite atributos que podem ser estruturas ou conjuntos

Estruturas: criar um atributo para campo das estrutura.
interface Actor {
attribute string nome;
attribute Struct
{string rua, string cidade} endereço;
Actor( Nome, Rua, Cidade)
};

Conjuntos: criar um tuplo para cada valor do conjunto?
interface Actor {
attribute string nome;
attribute Set<
Struct {string rua, string cidade}
> endereço;
};
Nome
Rua
Cidade
Harrison Ford
789 Palm Dr.
Beverly Hills
Harrison Ford
5th Avenue
New York
Problemas: mais do que um atributo-conjunto? Criar tuplos para todas as combinações.
A classe pode não ter chave, mas a relação tem de ter!
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–91
Exemplo
interface Actor {
attribute string nome;
attribute Set<
Nome
Rua
Cidade
DataNasc
Harrison Ford
789 Palm Dr.
Beverly Hills
10/5/50
Struct {string rua, string cidade} Harrison Ford
> endereço;
Judy Foster
5th Avenue
300 Stars Av.
New York
Beverly Hills
10/5/50
18/7/62
attribute Date dataNasc;
};
• Redundância. Será grave? Vêr para N atributos do tipo Set e cada com M valores.
• Como modelar bags, lists, ou arrays?
Bag<Struct {string rua, string cidade}> endereço;
Actor(Nome,Rua,Cidade,NumVezes)
List<Struct {string rua, string cidade}> endereço;
Actor(Nome,Rua,Cidade,PosLista)
Array< Struct {string rua, string cidade},2> endereço; Actor(Nome,Rua1,Cidade1,Rua2,Cidade2)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–92
Relacionamentos de valor único
•
interface Filme {
interface Estúdio {
•
attribute string titulo;
attribute string nome;
•
attribute integer ano;
attribute string endereço;
•
attribute integer duração;
•
attribute enumeration {cor, preto-e-branco} tipo;
•
relationship Set<Actor> actuam
•
relationship Set<Filme> possui
inverse Filme::pertence;
};
inverse Actor::participa;
•
relationship Estúdio pertence
•
inverse Estúdio::possui;
•
};
•
Como tratar o relacionamento pertence?
 Incluir na relação Filme os atributos da relação Estúdio? E como seria tratado o
relacionamento inverso?
 Não.
 Proceder como com os relacionamentos um-um no modelo ER, i.e. incluir em
Filme os atributos chave de Estúdio.
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–93
Relacionamentos de valor múltiplo

Como tratar o relacionamento actuam?


Proceder como com os relacionamentos um-muitos ou muitos-muitos no ER...
Seja A  B um relacionamento multivalor:
1. Determinar as chaves de A e de B.
2. Pegar na relação correspondente à classe do lado “muitos”, seja A, e pegar na chave
de B e adicionar em A como atributos.
3. Se for muitos-muitos é necessário duplicar tuplos de A (como no ER);
Pare evitar redundância, cria-se uma nova tabela com as chaves de A e de B.
A relação Filme ficaria:
filme(Título, Ano, Duração, Tipo, NomeEstúdio, NomeActor)
(Um filme fica representado por tantos tuplos quantos os actores do filme! Redundância)
evitando redundância:
filme(Título, Ano, Duração, Tipo, NomeEstúdio) + filem-actor(Título,Ano,NomeActor)
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–94
Subclasses  Relações
Em ODL, um objecto pertence exactamente a uma classe (que herda as
propriedades de todas as superclasses)
 criar uma relação para cada classe (subclasse) com todos atributos
(incluindo os de herança) dessa classe.

titulo
ano
duração
Actor
tipo
Filme
Cartoon(titlo, ano, duração, tipoF, NomesEst, NomeActor, voz)
vozes
Filme(título, ano, duração, tipoF NomesEst, NomeActor),
isa
isa
arma
Cartoon
Policial
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–95
Relacionamentos de Grau Superior a 2 (ER)
envolve mais de duas entidades
 em geral, um relacionamento ternário representa mais informação do
que 3 relacinamentos binários:

Qtd
Fnome
Fornecedor
Pnum
fornecimento
Projecto
Pnome
Produto
Pnum
Fnome
M
Fornecedor
fornece
N
Projecto
M
M
pode_fornecer
N
N
usa
Produto
Pnome
MI, MIAC 2002
Michel Ferreira, DCC - FCUP
1–96
Relacionamentos ternários --> binários

fornecimento(f,p,j) tem significado diferente de
fornece(f,j), pode_fornecer(f,p), usa(j,p)
podemos converter um relacionamento-ternário em relacionamentos
binários, sem perda de informção, representando o relacionamentoternário como uma entidade-fraca.

Fnome
Fornecedor
Qtd
1
ff
N
fornecimento
Pnum
N
fpj
1
Projecto
N
fpr
1
Produto
MI, MIAC 2002
Pnome
Michel Ferreira, DCC - FCUP
1–97