MI, MIAC 2002Michel Ferreira, DCC - FCUP1–1 Sistemas de Base de Dados Michel Ferreira Email:...
-
Upload
mariana-moreno -
Category
Documents
-
view
214 -
download
1
Transcript of MI, MIAC 2002Michel Ferreira, DCC - FCUP1–1 Sistemas de Base de Dados Michel Ferreira Email:...
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–1
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–2
BibliografiaLivro 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, Addison-Wesley, 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–3
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–4
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–5
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–6
Modelo Relacional
• Baseado em tabelas, como:conta # nome saldo12345 Sandra 1000.2134567 Alice 285.48… … …
• É usado na maioria dos SGBD’s actuais.
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–7
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–8
Três aspectos no estudo de SGBD’s1. Modelação e desenho de Bases de Dados.
Permite a análise de questões antes de passar a uma fase de implementação.
2. 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–9
Linguagens de ConsultaEmpregado
Nome Dept
Departamento
Dept Director
SQLSELECT DirectorFROM Empregado, DepartamentoWHERE Empregado.nome = "Clark Kent”
AND Empregado.Dept = Departamento.Dept
Linguagem de ConsultaData 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–10
Linguagens “Host” C, C++, Fortran, Lisp, COBOL
Progr. Aplicação
Variáveis locais
SGBD
Chamadas àBD
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
(Memória)
(Armaz.)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–11
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
CPUALU
ADDER
Adder
AFA
ALU ADDER
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–12
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 Objectos1. Objectos Complexos – Estrutura embricada (apontadores ou
referências)2. Encapsulamento, conjunto de funções de Acesso/Métodos3. Identidade de Objecto4. Herança – Definição de novas classes com base em classes antigas
Modelo de Objectos: normalmente a procura de objectos é por navegação explicitaExiste também uma linguagem de consulta em alguns sistemas
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–13
Modelo de Dados Lógico (Horn Clause)• Prolog, DatalogSe A1 e A2 então Bprolog 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 relacionalPode calcular o fecho transitivoedge(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–14
Hierárquico
60’s
70's
80's
90’s
agora
Relacional Escolha da maioria das aplicações
BD OO BD Dedutivas
Rede
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–15
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–16
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–17
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–18
• 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:
• 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.
Modelo ER: Entidade Tipo
EMPREGADO(Nome, Idade, Salário)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–19
• 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.
Requisitos de uma BDs de uma Empresa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–20
• 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)
Construção do modelo ER para a BD-Empresa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–21
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)
Construção do modelo ER para a BD-Empresa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–22
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)
Relacionamentos
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–23
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.
Esquema da BDs
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–24
• 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)
Relacionamentos (Grau e Atributos)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–25
• 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)
Relacionamentos (Restrições)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–26
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)
Restrições nos Relacionamentos (cont.)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–27
• 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)
Entidades Fracas
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–28
• 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 Supervisor Supervisionado
trabalhaEm(Empregado,Projecto,Horas) M:N total/total
Modelo ER para a BDs sobre uma Empresa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–29
• Ênfase na representação dos esquemas em vez de instâncias de entidades e relacionamentos.
• Notação para os diagramas:
Diagramas ER
Relacionamento-identificador
Relacionamento
Entidade-Fraca
Entidade-Tipo
Atributo
Atributo-Chave
Atributo-Multivalor
Atributo-Derivado
Atributo-Composto
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–30
Diagramas ER (cont.)
E1 E2R
E1 E2R
ER
1 N
(min,max)
Participação-total de E2 em R
1:N
Restrição-estruturalda participaçaõ de E em R
• Uma entidade E participa num relacionamento R com restrição (min,max) em que 0minmax 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–31
Exemplo Restrição-Estrutural
• No diagrama: um empregado trabalha para um departamento Num departamento trabalham pelo menos 4 empregados
• 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
Empregado DepartamentotrabalhaPara(1,1) (4,N)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–32
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
TécnicosSecretárias Engenheiros Directoressubclasses
superclasse
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–33
O Modelo EER (Relacionamento ISA)
• O relacionamento ISA (ou superclasse/subclasse) caracteriza a ligação entre as subclasses e a respectiva superclasse
uma entidade membro de uma subclasse representa a mesma entidade-fí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;
EmpregadoDirector isa
EmpregadoSecretária isa
EmpregadoTécnico isa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–34
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–35
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–36
Diagrama EER
Técnico EngenheiroSecretária
Director
ProjectoSindicato
VelEscritaQualificação EngTipo
dirige
SalárioEfiliado
d
d
Empregado
EmpEfectivo
EmpPrazo
Escalão
NumBI
Nome • 3 especializações de Empregado
d
Salário
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–37
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:
Veículo
Carro Camião
NpassVelMax
Tonelagem
Neixos
d
Preço
Nreg
Matricula
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–38
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
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 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)
d
o
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–39
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–40
Modelo Relacional
• Introduzido por Codd (1970)• Base de Dados = Conjunto de relações• Relação <==> Tabela
Filme Título Ano Duração TipoZorro 1998 cor120
Filme (Título, Ano, Duração, Tipo) Esquema
Guerra das Estrelas 124 corMighty Ducks 1991 104 cor
atributos
tabela
tuplo1977
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–41
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)
TrabalhaEm(EBI,Pnum,Horas)
Projecto(Pnome,Pnum,Plocal)
Dependente(EBI,Nome,Sexo,Dnasc,GrauParentesco)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–42
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–43
Restrições Intrínsecas do Relacional
• Integridade de entidade os valores da chave-primária não podem ser nulos
• Unicidade da chave não podem existir 2 tuplos diferentes com valores iguais na chave
• Chave externa 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–44
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–45
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–46
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 chaves-externas 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–47
Conversão do Modelo ER para o Modelo Relacional
• Passo 1: entidade-tipo relação
atributos simples da entidade atributos da relação atributos compostos atributos individuais na relação chave da entidade chave da relação
EmpregadoNome
Pnome
Unome
Sexo
EBI
...
Empregado Pnome Unome EBI Sexo ...
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–48
ER Relacional
• Passo 2: 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 atributos de R• chave-principal de E e chave-parcial de W chave-principal de R
EmpregadoNome
...
EBI
...
Dependente EBI Nome Sexo ...
DependentedependeDe
Chave-externa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–49
ER Relacional
• Passo 3: 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
EmpregadoDnum
DirData
EBI
...
Departamento Dnome Dnum DirBI DirData
Departamentodirige
Chave-externa
(0,1) (1,1)
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–50
ER Relacional
• Passo 4: 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
EmpregadoDnum
EBI
...
Empregado Pnome ... EBI ... DNum
DepartamentotrabalhaPara
Chave-externa
N 1
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–51
ER Relacional
• Passo 5: 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
EmpregadoPnum
EBI
...
trabalhaEm EBI Pnum Horas
ProjectotrabalhaEm
chaves-externase
chave-principal
M N
Horas
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–52
ER Relacional
• Passo 5: 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
EmpregadoPnum
EBI
...
trabalhaEm EBI Pnum Horas
ProjectotrabalhaEm
chaves-externase
chave-principal
M N
Horas
Nota: os relacionamentos 1:1 e 1:N também podem ser transformados de acordo com o passo 5.
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–53
ER Relacional
• Passo 6: 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.
DepartamentoDnum
...
Locais_Dep Dnum Dlocal
Ex: um departamento pode tervárias localizações.
Dlocal
Nota: os passos de 1 a 6 seriam suficientespara converter o esquema-ER noesquema-relacional para a BDs Empresa.
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–54
ER Relacional
• Passo 7: 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.
Fornecimento Fnome Pnome Pnum Qtd
FornecedorFnome
Pnome
Pnum
Projecto
Produto
fornecimento
Qtd
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–55
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–56
Os STCP pretendem construir uma base de dados sobre os percursos dosseus 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) deautocarro. Cada tipo de autocarro tem uma marca, um modelo, um númerode lugares sentados e um número de lugares de pé. A base de dados deveguardar também informação relativa aos percursos. Um percurso é identificado por um número (e.g. 78, 35) e tem uma distância total emquilómetros. Os percursos percorrem paragens. As paragens têm umnúmero identificador, um nome, e uma localização decomposta em local,rua e número. Existem limitações aos percursos que um determinado tipode autocarro pode fazer, inerentes às suas dimensões. Estas limitaçõesdevem ficar registadas na base de dados. Existe um percurso especialpara quando um autocarro mais o respectivo condutor são alugados, eeste 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 operacionaldiária, correspondente ao registo de saídas. Existem três turnos desaída, 6h, 14h e 22h. Um autocarro e um condutor fazem no máximo umasaída por dia, podendo não fazer nenhuma. A informação do registo desaída inclui a data, o turno, o condutor, o autocarro e o percurso atribuído.
Exercício de modelação
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–57
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 dosrelacionamentos 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 opercurso 78?''. Justifique.
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–58
“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–59
Desenho de BDs
• 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.
Ideias(info a modelar)
ER/EER(entidade/relacionamento)
ODL(object definition lang.)
Relações
SGBD Relacional
SGBD O-O
Conceptualização Implementação
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–60
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–61
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” – extendendo-se ao SQL – SQL3.
• Alguns protótipos de SGBDOO: OPENOODB – Texas Instruments ODE – AT & T Bell Labs
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–62
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–63
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–64
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–65
Exemplos de objectosO1 = (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–66
Representaçao de um objecto complexo como um grafo
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–67
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–68
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: string;
minit: char;lname: string;ssn: string;birthdate: Date;address: string;sex: char;salary: float;supervisor: Employee;dept: Department;
);
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–69
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 ( fname: string;minit: char;lname: string;ssn: string;birthdate: Date;address: string;sex: char;salary: float;supervisor: Employee;dept: Department; );operations age: integer;create_emp: Employee;destroy_emp: boolean;
end Employee;
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–70
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–71
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–72
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–73
ODL - exemplo
Filme
Actor
título
ano duração
nome
tipo
endereçorua
cidade
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–74
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:
relationship Set<Actor> actuam;
• 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;
•Em ODL é necessário que os relacionamentos tenham inversa.
Se S actuam para o filme F, Então F participa para o Actor S
Para cada objecto da classe Filme existe um conjunto de referências a objectos da classe Actor
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–75
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–76
ODL - exemplo 2
Filme
Actor
título
ano duração
nome
tipo
endereçorua
cidade
actuam
participa
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–77
ODL - exemplo
Filme
Actor
título
ano duração
nome
tipo
endereço
rua cidade
actuam
participa
Estúdio
nome endereço
possui
pertence
Presidente
nome anoInic
tem
preside
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–78
Classes do exemploclass 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;
};
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; };
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–79
Tipos em ODLTipos 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: Set: (1, 5, 6) Se T é um tipo, então Set<T> é o tipo cujos valores
são todos conjuntos finitos de elementos do tipo T. Bag: (1, 1, 5, 6, 6 ) Admite elementos repetidos. List: (1, 5, 6, 1, 6 ) string List<char> Array: Array<T,i> (T tipo, i inteiro) denota o tipo cujos elementos são vectores com i elementos do tipo T. Struct: Struct Morada {string rua, string cidade, integer código_postal}
Tipo-conjunto
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–80
Tipos admissíveis em ODLAtributos: 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 FilmeNÃ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–81
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–82
• Alguns objectos numa classe poderão ter propriedades não partilhadas por outros membros:
• 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;
Subclasses
Filme
Cartoons Policial
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–83
• 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 {};
Herança múltiplaFilme
Cartoon Policial
Cartoon-Policial
Quem tramou o Roger Rabit?
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–84
• 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.
Herança múltipla em ER
Cartoon Policial
Filme
isa isa arma
vozes
Actortitulo ano duração
tipo
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–85
• 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
e.g. especificar que uma pessoa pode apenas ter um pai restrições de integridade referencial
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.
Restrições
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–86
• um objecto pode ter várias chaves.
• Exemplos:
Interface Pessoa (key ncontrib) { propriedades... };
Chaves em ODL
Interface Filme (key (titulo, ano)){...};
Interface Empregado (key empID, empBI){...};
Chave é atributosimples
Chave é atributocomposto
2 chaves
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–87
• 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.
Princípios para boa modelação
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–88
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–89
O Modelo Relacional
Modelo daBase de dados(ODL, ER)
Esquema Relacional
Espaço emDisco
Definições ODLDiagramas ER
Tabelas:colunas: atributoslinhas: tuplos
Complexa organização em ficheiro e estruturas de índice
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–90
Do ODL para o Relacional• As relações aproximam-se mais da implementação, pelo que:
(ER, ODL)
• 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)
ou como tabela:Filme Título Ano Duração Tipo
Zorro 1998 cor120
Relacionalginástica mental
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–91
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; Actor( Nome, Rua, Cidade) attribute Struct {string rua, string cidade} endereço;
};
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
Harrison Ford
789 Palm Dr. Beverly Hills
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–92
Exemplo
interface Actor {attribute string nome;attribute Set<
Struct {string rua, string cidade} > endereço;
attribute Date dataNasc;};
Nome Rua Cidade
Harrison Ford
Harrison Ford
789 Palm Dr. Beverly Hills
5th Avenue New York
• 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)
DataNasc
10/5/50
10/5/50Judy Foster 300 Stars Av. Beverly Hills 18/7/62
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–93
Relacionamentos de valor único
• interface Filme {
• attribute string titulo;
• attribute integer ano;
• attribute integer duração;
• attribute enumeration {cor, preto-e-branco} tipo;
• relationship Set<Actor> actuam
• 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.
interface Estúdio {
attribute string nome;
attribute string endereço;
relationship Set<Filme> possui
inverse Filme::pertence;
};
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–94
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–95
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.
Policial
arma
Cartoon
Filme
isaisa
vozes
Actortitulo ano duração
tipo
Cartoon(titlo, ano, duração, tipoF, NomesEst, NomeActor, voz)
Filme(título, ano, duração, tipoF NomesEst, NomeActor),
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–96
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:
PnumQtd
FornecedorFnome
Pnome
Projecto
Produto
fornecimento
Pnum
FornecedorFnome
Pnome
Projecto
Produto
fornece
pode_fornecer usa
M N
NNM M
MI, MIAC 2002 Michel Ferreira, DCC - FCUP 1–97
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 relacionamento-ternário como uma entidade-fraca.
PnumQtd
Fornecedor
Fnome
Pnome
Projecto
Produto
fornecimentoff fpj
fpr
1 N
N
1
N 1