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/


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.


Avaliação

• Um trabalho (a definir na 3ª aula): 30% da nota.• Um exame final: 70% da nota.


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”


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.


Modelo Relacional

• Baseado em tabelas, como:conta # nome saldo12345 Sandra 1000.2134567 Alice 285.48… … …

• É usado na maioria dos SGBD’s actuais.


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.


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.


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>


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.)


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


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


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)


Hierárquico

60’s

70's

80's

90’s

agora

Relacional Escolha da maioria das aplicações

BD OO BD Dedutivas

Rede


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)


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,…)


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.


• 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)


• 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


• 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


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


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


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


• 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)


• 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)


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.)


• 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


• 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


• Ê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


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


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)


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


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


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


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


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


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


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


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.


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


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)


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


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)


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


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.


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)


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 ...


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


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)


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


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


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.


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.


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


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.


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


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.


“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)


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


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


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


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.


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.


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.


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>)

...


Representaçao de um objecto complexo como um grafo


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.


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;

);


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;


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)


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.


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;

};


ODL - exemplo

Filme

Actor

título

ano duração

nome

tipo

endereçorua

cidade


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


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.


ODL - exemplo 2

Filme

Actor

título

ano duração

nome

tipo

endereçorua

cidade

actuam

participa


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


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; };


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


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.


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!).


• 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


• 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?


• 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


• 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


• 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


• 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


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.


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


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


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!


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


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;

};


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)


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),


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


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

Date post:	07-Apr-2016
Category:	Documents
Upload:	mariana-moreno
View:	213 times
Download:	1 times

MI, MIAC 2002Michel Ferreira, DCC - FCUP1–1 Sistemas de Base de Dados Michel Ferreira Email:...

Documents