Resumo

Evolução dos Sistemas de
Informação

Sistemas de Informação
gerenciamento de arquivos



baseados
em
programas e arquivos orientados a cada unidade
organizacional
rotinas específicas para tarefas específicas
dados armazenados em disco, usando uma
determinada estrutura de dados
USP – ICMC - GBDI
1
Dados
Aplicações
Arquivo 1
PROBLEMA?????
Arquivo 2
Arquivo 3
REDUNDÂNCIA
Aplicação de
Produção
Arquivos de Dados
de Produção
Produtos
Aplicação de
Vendas
Aplicação de
Compras
Arquivos de Dados
de Vendas
Arquivos de Dados
de Compras
Produtos
Produtos
REDUNDÂNCIA
Aplicação de
Produção
INCONSISTÊNCIA
Aplicação de
Vendas
Insere:
Insere:
Nome: Notebook
NroSerie:1111111
Nome: Notebook
NroSerie:1111111
Fabricante: Y
Fabricante: X
Arquivos de Dados
de Produção
Produtos
Arquivos de Dados
de Vendas
Produtos
Consistência de Dados

Dados em estado inconsistente
informações incorretas ou
contraditórias são fornecidas aos
usuários
USP – ICMC - GBDI
5
Consistência de Dados


Consistência é “estado ou caráter do que é
coerente, do que tem solidez, veracidade,
credibilidade, estabilidade, realidade”.
Consistência: se determinada informação é
replicada (redundância), seu valor é sempre o
mesmo
USP – ICMC - GBDI
6
SIs baseados em arquivos
Problemas?






Redundância e inconsistência de dados
Dificuldade de acesso aos dados
Isolamento de dados
Anomalias no acesso concorrente
Segurança
USP – ICMC - GBDI
7
Além disso...


SIs baseados em arquivos  dados gravados em
disco usando ESTRUTURAS DE DADOS
Acesso requer conhecimento destas estruturas 
DEPENDÊNCIA DE DADOS.
USP – ICMC - GBDI
15
15
46
63
81
97
16

99
8
Dependência dos Dados


Vários programas compartilhando os mesmos
dados  todos devem conhecer e manipular
as mesmas estruturas
E se houver uma alteração na estrutura de
dados?
TODOS OS PROGRAMAS TERÃO QUE SER ALTERADOS
USP – ICMC - GBDI
9
Independência dos Dados

Como tornar os programas
INDEPENDENTES da estrutura de dados?
CRIANDO UM SISTEMA QUE GERENCIE A ESTRUTURA
Aplicação 1
Aplicação 2
Sistema
Gerenciador de
Dados
Compartilhados
USP – ICMC - GBDI
15
46
63
81
97
15
16

99
10
Independência dos Dados
Sistema de Gerenciamento de Bases (ou Banco) de Dados
SGBD
Aplicação 1
SGBD
15
46
63
81
15
16
97
99

Aplicação 2
USP – ICMC - GBDI
11
SGBD
Sistema de Gerenciamento de Bases de Dados

conjunto de dados


base (banco) de dados
conjunto de programas para acesso e manipulação
dos dados
USP – ICMC - GBDI
12
SGBD

Sistema de propósito geral

armazenar grandes volumes de dados

permitir busca e atualização dos dados


eficiência
Manutenção de um conjunto lógico e organizado
de dados

completamente autônomo em relação às aplicações
USP – ICMC - GBDI
13
Aplicação
Aplicação
Aplicação
SGBD
Esquema - Definição
da base de dados
Instância –
Base de dados
SGBDs

Requisitos Fundamentais:

Segurança


Física (mais comum no passado)
Lógica

Usernames e passwords

Perfis de usuário
USP – ICMC - GBDI
15
SGBDs

Requisitos Fundamentais

(cont):
Integridade


consistência
validade
Nome: Joaquim Pereira
Cargo: Faxineiro
Salário:R$ 230.000,00
Arquivos de
Dados
?????
Restrições de Integridade!!!
USP – ICMC - GBDI
16
SGBDs

Requisitos Fundamentais



(cont):
Integridade - se contem apenas dados válidos, que
não contradizem a realidade que estão a representar.
Restrições de integridade, que definem o que é
válido e o que não é válido. Exemplos:
– um funcionário não pode pertencer a mais do que um
departamento
– o preço de venda de um produto deverá ser superior ao seu
custo.
– a referência de cada produto deve ser única
USP – ICMC - GBDI
17
SGBDs

Requisitos Fundamentais

Recuperação / Tolerância a falhas

Transações atômicas


(cont):
unidades lógicas de trabalho, em geral envolvendo várias
operações

Registros de Log

Backup
Controle da concorrência

gerenciamento de transações concorrentes
USP – ICMC - GBDI
18
Por que usar SGBDs?

Vantagens:






armazenamento persistente de dados e estruturas
de dados;
INDEPENDÊNCIA DE DADOS;
CONSISTÊNCIA DE DADOS;
ABSTRAÇÃO E INTERFACE;
acesso compartilhado (multiusuário e concorrente)
à informação;
distribuição de informações
USP – ICMC - GBDI
19
Por que usar SGBDs?

Vantagens:

reduz complexidade das aplicações
segurança
controle de acesso aos dados

backup

utilização de padrões


USP – ICMC - GBDI
20
Por que usar SGBDs?

Desvantagens


Custo financeiro
Um sistema a mais a ser aprendido e gerenciado
USP – ICMC - GBDI
21
Componentes de um SGBD
SGBD
Processador de
Consultas

Gerenciador de
Armazenamento
Banco de Dados
Dados e
Metadados
Os componentes funcionais do SGBD:


componentes de processamento de consultas
componentes de gerenciamento de
armazenamento
USP – ICMC - GBDI
22
Componentes de um SGBD

Conceitos importantes:
 Pragmatismo:
primeiro
modelagem
(documentada), seguida de definição e
instanciação, e só depois o uso
1.
2.
3.
4.
Modelagem: modelo entidade/relacionamento
Definição: SQL, subconjunto DDL
Instanciação: SQL, subconjuntos DDL/DML
Uso: SQL, subconjunto DML
USP – ICMC - GBDI
23
Componentes de um SGBD

Conceitos importantes:

SQL - Data Definition Language (DDL)


conjunto de comandos para definição do esquema da
base de dados
Exemplos em linguagem SQL




create table
alter table
drop table
Compilador/Interpretador DDL
USP – ICMC - GBDI
24
Componentes de um SGBD

Conceitos importantes


(cont.):
Metadados
Dicionário de Dados:





banco de dados do sistema
armazena descrição do esquema
armazena metadados
armazena restrições de segurança e integridade
outras denominações: catálogo de dados, diretório
de dados
USP – ICMC - GBDI
25
Componentes de um SGBD

Conceitos importantes

(cont.):
SQL - Data Manipulation Language (DML)





recuperação (consulta)
inserção
remoção
modificação
DML viabiliza manipulação dos dados de maneira
compatível com o modelo de dados
USP – ICMC - GBDI
26
Componentes de um SGBD

Conceitos importantes

(cont.):
Data Manipulation Language (DML)

Exemplos em linguagem SQL





insert
select
delete
update
...
USP – ICMC - GBDI
27
Componentes de um SGBD

Conceitos importantes

Procedural vs Declarativo

Procedural: exige especificação de quais dados são necessários, e
como obtê-los



requer uma sequência específica de operações a serem executadas
ex.: linguagens de programação como C e Pascal, e a linguagem de
projeto de bancos de dados álgebra relacional
Não-Procedural (Declarativo): exige apenas especificação de
quais dados são necessários, e não de como obtê-los


(cont.):
ex: SQL
A interface dos bancos de dados é definida pela
linguagem declarativa SQL (DDL + DML)
USP – ICMC - GBDI
28
Programadores
de aplicações
Usuários Finais
Interfaces de
aplicação
Aplicações
Usuários
Sofisticados
Consulta (Query)
DBAs
Esquema de BD
SGBD
Pré-compilador
de Comandos
DML  DML
embutido no .exe
Programas de
Aplicações em
Código Objeto
Compilador
DML
Componente de
avaliação e execução de
consultas
Gerenciador de
Transações
Interpretador
DDL
Processador de Consultas
Gerenciador de
Buffer
Gerenciador de
Arquivos
Gerenciador de Armazenamento
SGBD
Programas de
Aplicações em
Código Objeto
Processador
de Consultas
Pré-compilador
de Comandos
DML
[Silbesrchats]
Interpretador
DDL
Componente de
execução de consultas
Gerenciador de
Transações
Gerenciador de
Armazenamento
Compilador
DML
Gerenciador de
Buffer
Gerenciador de
Arquivos
Índices
Arquivos de
Dados
Dados
Estatísticos
Dicionário de
Dados
Evolução dos Sistemas de
Bases de Dados
USP – ICMC - GBDI
31
Evolução dos Sistemas de
Bases de Dados
Os programas de aplicação são executados no
servidor de dados – os terminais “burros”
executam quase nenhum processamento.
USP – ICMC - GBDI
32
Evolução dos Sistemas de
Bases de Dados
PC
USP – ICMC - GBDI
33
Evolução dos Sistemas de
Bases de Dados
PC
PCs mais potentes executam tanto o programa
de aplicação quanto o SGBD. O servidor de
arquivos provê espaço de armazenamento,
escasso à época.
USP – ICMC - GBDI
34
Evolução dos Sistemas de
Bases de Dados
USP – ICMC - GBDI
35
Arquitetura Cliente/Servidor
Aplicações
Dados e
Regras
SGBD
Servidor
Cliente
USP – ICMC - GBDI
36
Arquitetura Cliente/Servidor

Duas camadas
Aplicações
Dados e
Regras
SGBD
Servidor
BD + parte (pequena)
da lógica de negócio
USP – ICMC - GBDI
Cliente
Interface + maior parte
da lógica de negócio
37
Arquitetura Cliente/Servidor

Três camadas
Servidor de Aplicação
Dados e
Regras
Aplicações-Cliente
SGBD
Servidor
BD + parte comum da lógica
de negócio
USP – ICMC - GBDI
Cliente
Interface + parte
específica da lógica
de negócio 38
Arquitetura Cliente/Servidor

Quatro camadas
Servidor de
Aplicação
Dados e
Regras
Servidor de
Interface
Aplicações-Cliente
SGBD
Servidor
USP – ICMC - GBDI
Cliente
39
Aplicação
Aplicação
Aplicação
SGBD
Definição da base de
dados armazenada
Base de dados
armazenada
ESQUEMA
INSTÂNCIA
Esquema e Instância

Banco de dados:
Esquema


Definição
Estático (ou quase!)
Instância


Manipulação
Dinâmica
Esquema
Instância
Esquema e Instância
Esquema pode ser definido em 3 níveis
Three-Schema Architecture
Arquitetura Esquema de Três

Three-Schema Architecture (ou arquitetura
ANSI/SPARC)
1.
2.
3.

múltiplas visões para os usuários
armazenamento da descrição da base de dados
(esquema) em diferentes níveis de abstração
independência de dados
Incorporação de características
filosofia de bases de dados
importantes
da
Three-Schema Architecture
Nível Externo
ou de Visão
Sub-Esquemas (views)
Esquema Conceitual
e/ou Esquema Lógico
Esquema Físico
Visão 1
Visão 2
...
Visão N
Nível Conceitual
ou Lógico
Nível Interno ou Físico
Three-Schema Architecture

Nível Interno – esquema físico

descreve estrutura física de armazenamento
da base de dados

como os dados estão armazenados
Three-Schema Architecture

Nível Conceitual – esquema conceitual
e/ou lógico

descreve a estrutura da base de dados sem
detalhes de estrutura de armazenamento físico


quais dados
relacionados
estão
armazenados
e
como
descrição do esquema conceitual/lógico:


modelo conceitual (ex: MER)
modelo de implementação (ex: Modelo Relacional)
estão
Three-Schema Architecture

Nível Externo – sub-esquemas

define as visões dos usuários


descreve a parte da base de dados em que cada grupo
de usuários tem interesse
descrição de sub-esquemas:


modelo conceitual (ex: MER)
modelo de implementação (ex: Modelo Relacional)
Three-Schema Architecture
Nível Externo
ou de Visão
mapeamento
externo/conceitual
mapeamento
conceitual/interno
Visão 1
Visão 2
...
Visão N
Nível Conceitual
ou Lógico
Nível Interno ou Físico
Three-Schema Architecture

Visualização de níveis de esquema em
sistemas de banco de dados 
ABSTRAÇÃO
escondendo detalhes e complexidade nos
diferentes níveis
 visão mais geral ou mais específica

Recordando....

Three-Schema Architecture (ou
arquitetura ANSI/SPARC)



independência de dados
múltiplas visões para os usuários OK!!!!
armazenamento da descrição da base de dados
(esquema) em diferentes níveis de abstração
OK!!!!
Independência de Dados


Independência de dados na arquitetura
de três esquemas  capacidade de
modificar
o
esquema
em
determinado nível sem afetar o
esquema do nível superior
SGBD pode suportar:


independência física
independência lógica
Independência de Dados
Nível Externo
ou de Visão
Visão 1
Visão 2
...
Visão N
Nível Conceitual
ou Lógico
Independência
Física???
Nível Interno ou Físico
Independência de Dados

Independência física de dados



modificações no esquema interno não provocam
alterações nos esquemas lógico e externo
por que modificar esquema interno?
quando os esquemas em níveis superiores teriam
que ser alterados?
Independência de Dados

Independência
física
de dados
Modificações no
nível interno
– reorganização dos



dados – ex:
de novos
mecanismos
de
modificações
no inserção
esquema
interno
não provocam
acesso,nosnovos
índices,
mais
espaço de
alterações
esquemas
lógico
e externo
armazenamento.
por que modificar esquema interno?
quando os esquemas em níveis superiores teriam
que ser alterados?
Independência de Dados
Nível Externo
ou de Visão
Visão 1
Visão 2
...
Visão N
Nível Conceitual
ou Lógico
Independência
Lógica???
Nível Interno ou Físico
Independência de Dados

Independência lógica de dados

modificações no esquema lógico não provocam
alterações nos esquemas externos



aplicativos não precisam ser reescritos
por que modificar esquema lógico?
quando os esquemas em níveis superiores teriam
que ser alterados?
Independência de Dados

Independência
lógica
de dados
Modificações no
nível conceitual
– reestruturação

lógica – ex.:
tabelas, novos
atributos,
modificações
nonovas
esquema
lógico
não novas
provocam
restrições
integridade 
expansão.
alterações
nosdeesquemas
externos
aplicativos não precisam ser reescritos
No cado de redução, níveis superiores talvez
por que
modificar
esquema
lógico?
tenham
que ser
alterados.
Ex.: exclusão de
atributos,
relacionamentos,
ou superiores
restrições deteriam
quando
os esquemas
em níveis
integridade.



que ser alterados?
Sistemas de Banco de Dados
Ciclo de Vida
Mundo Real
Requisitos
de Dados
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Análise Funcional
Protótipo
Projeto Físico
SGBD
Requisitos
Funcionais
Projeto
Implementação
Dados e
Metadados
Aplicação
Sistemas de Banco de Dados
Desenvolvimento de Software
Mundo Real
Requisitos
de Dados
Requisitos
Funcionais
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Projeto Físico
SGBD
Análise Funcional
• Projetistas de
Interface
Projeto
Protótipo
• DBA
• Pessoal de Suporte e
Operação
Implementação
Aplicação
Dados e
Metadados
• Analistas de
Sistemas
• Programadores
• Usuários
• Operadores de Aplicação
Sistemas de Banco de Dados
Desenvolvimento de
Sistemas de Banco de Dados
Ciclo de Vida
Mundo Real
• Projetistas
de BD
Requisitos
de Dados
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Projeto Físico
SGBD
• Projetistas de
Interface
Protótipo
• DBA
• Pessoal de Suporte e
Operação
Dados e
Metadados
Requisitos
Funcionais
Análise Funcional
Projeto
Implementação
Aplicação
• Usuários
• Operadores de Aplicação
Desenvolvimento de Sistemas
de Banco de Dados [Elmasri]

Projeto conceitual

esquema conceitual para a base de dados



níveis conceitual/lógico e externo
baseado nos requisitos de dados
objetivos:




estrutura da base de dados
semântica
relacionamentos
restrições
Desenvolvimento de Sistemas
de Banco de Dados [Elmasri]

Projeto conceitual (cont.)
independente do SGBD
 pode incluir especificação em alto nível de:

aplicações
 características funcionais das transações


modelo conceitual – ex: MER
Desenvolvimento de Sistemas
de Banco de Dados [Elmasri]

Projeto lógico

esquema lógico


níveis conceitual/lógico e externo
mapeamento do modelo conceitual para o
modelo do SGBD

ex: Modelo Relacional
Desenvolvimento de Sistemas
de Banco de Dados [Elmasri]

Projeto lógico (cont.)

Passo1 – mapeamento independente de um
SGBD específico


mas... dependente do “paradigma” (relacional, OO,
relacional-objeto)
Passo 2 – ajustes de acordo com as
características e restrições do modelo
implementado por um SGBD específico
Desenvolvimento de Sistemas
de Banco de Dados [Elmasri]

Projeto físico

esquema físico


estruturas físicas de armazenamento





nível interno
organização de registros físicos
índices
número de discos
….
critérios:



tempo de resposta
espaço utilizado
número de transações
Modelagem de dados
Os Três Reinos - Abstração
Real
Percepção
Máquina
1
Usina
N
Peça
M
1
Tempo
Código
Código
Trabalha
N
Implementação
Imaginário
Material
Total de
horas
M
Empregado
N
N
Composta
por
1
Produto
Verifica
Nome-E
Idade
Padrão
Sigla
Nome-P
Peso
Representação
Modelagem
Idéias
Modelo E/R
Modelo Relacional
SGBD
Relacional
MER
SQL - DDL
DADOS
Modelagem de Dados Motivação

Por que modelar??

se


projetistas se apóiam pouco em metodologias
sistemáticas para conduzir o projeto da base de dados...
então




tempo e recursos são subestimados
resultado não atende às necessidades das aplicações
documentação é limitada
manutenção custosa
Modelos de Dados


Modelo de dados – “definição abstrata, autônoma e
lógica dos objetos, operadores e outros elementos
que, juntos, constituem a máquina abstrata com a
qual os usuários interagem”. (Date)

objetos

operadores
estrutura dos dados
comportamento dos dados
Modelos conceitual e de implementação (ou lógico)
Modelos de Dados

Modelos de dados (Elmasri)

Conceituais




Modelo Entidade Relacionamento (MER)
Modelo de Objetos da ODMG (Object Database and
Open Source Vendors)
….
de Implementação :

Ex: Rede, Hierárquico, NO-SQL, Relacional
Modelos Conceituais

Objetivo:

descrição do conteúdo da base de dados


NÃO considera estruturas de armazenamento
Enfoque:




compreensão e descrição da realidade (informação)
compreensão e seleção das propriedades relevantes da
informação
compreensão e descrição das restrições sobre os dados
diálogo com o usuário
Projeto Conceitual
Sistemas de Banco de Dados
Desenvolvimento de
Sistemas de Banco de Dados
Ciclo de Vida
Mundo Real
Requisitos
de Dados
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Projeto Físico
• Projetistas
de BD
SGBD
• Projetistas de
Interface
Protótipo
• DBA
• Pessoal de Suporte e
Operação
Dados e
Metadados
Requisitos
Funcionais
Análise Funcional
Projeto
Implementação
Aplicação
• Usuários
• Operadores de Aplicação
Modelagem Conceitual


Entrada: Requisitos de Dados
Processo:



modelagem – representação conceitual
modelo conceitual (Ex: MER)
Resultado: Esquema Conceitual



descrição sucinta (diagramas e texto)
clara, concisa, sem ambigüidades, sem contradições
padronizada
Modelagem Conceitual

Ex:






SDM (Semantic Data Model) [McLeod-81]
SAM (Semantic Association Model) [Su-86]
IFO [Abiteboul-87]
ME-R (Modelo Entidade-Relacionamento) [Chen-76]
Modelos Orientados a Objetos
 Object Model (ODMG), UML, OMT, OOAD, BOOCH
…..
Modelos de Implementação

Modelo em Rede:



dados representados por um conjunto de
registros
relações entre registros representadas por links
registros organizados no BD por um conjunto de
grafos
Modelos de Implementação

Modelo Hierárquico

similar ao Modelo em Rede



dados e relações representados por registros e links
diferença: no Modelo Hierárquico os registros
estão organizados em árvores
Sistema IMS (Information Management System IBM)
Modelos de Implementação

Modelo Relacional



difere por não usar links
relaciona os registros por meio de valores
possibilidade do desenvolvimento de
fundamentos matemáticos para sua definição


Cálculo Relacional e Álgebra Relacional
Precursor, Sistema R (IBM)
Sistemas de Banco de Dados
Desenvolvimento de
Sistemas de Banco de Dados
Ciclo de Vida
Mundo Real
Requisitos
de Dados
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Projeto Físico
• Projetistas
de BD
SGBD
• Projetistas de
Interface
Protótipo
• DBA
• Pessoal de Suporte e
Operação
Dados e
Metadados
Requisitos
Funcionais
Análise Funcional
Projeto
Implementação
Aplicação
• Usuários
• Operadores de Aplicação
MER - Modelo Entidade
Relacionamento

MER – Criado por Peter Chen


“The entity-relationship model: towards a
unified view of data”, ACM TODS, 1976.
Voltado para a representação dos
aspectos estáticos (informação) do
Domínio da Aplicação

Modelagem semântica dos dados
USP – ICMC – GBDI
MER - Modelo Entidade
Relacionamento

Popular



Simplicidade
Expressividade
Intuitivo  representação gráfica da
informação

Diagrama Entidade-Relacionamento
(DE-R)
USP – ICMC – GBDI
MER – Construtores Sintáticos
▪ Modelos de Dados definem um conjunto
(limitado) de Construtores Sintáticos
▪ um mesmo Construtor Sintático pode ser
usado para representar diversas situações do
mundo real
Sobrecarga Semântica
USP – ICMC – GBDI
MER – Construtores Sintáticos
▪ Conjunto de Entidades (CE)
▪ Conjunto de Relacionamentos (CR)
▪ Atributos de Entidades
▪ Atributos de Relacionamentos
USP – ICMC – GBDI
MER
▪ Entidades  “coisas”, objetos, pessoas,
entes, etc. do mundo real
▪ Conjuntos de Entidades  coleções de
entidades que têm a mesma “estrutura” e
o mesmo “significado” na modelagem
▪ estrutural e semanticamente iguais
USP – ICMC – GBDI
Conjunto de Entidades
▪ MER não trata Entidades individuais, apenas
Conjuntos de Entidades
▪ Notação DER: retângulo
Disciplina
Pessoa
USP – ICMC – GBDI
Conjunto de Relacionamentos
▪ Relacionamentos  associações entre
entidades do mundo real
▪ Conjuntos de Relacionamentos 
relacionamentos entre entidades dos mesmos
CEs
Disciplina
Pessoa
USP – ICMC – GBDI
Conjunto de Relacionamentos
▪ Notação DER: losango
Matricula
Disciplina
Trabalha
Escola
Pessoa
USP – ICMC – GBDI
Conjunto de Relacionamentos
▪ Ex: vários Conjuntos de Relacionamentos
envolvendo os mesmos Conjuntos de Entidades
Matricula
Pessoa
Faz
Prova
USP – ICMC – GBDI
Disciplina
Atributos
▪ Atributos  valores que representam
propriedades das entidades e
relacionamentos no mundo real
▪ atributos de entidades
▪ atributos de relacionamentos
USP – ICMC – GBDI
Atributos de Entidades
▪ Notação DER: elipses ligadas aos
Conjuntos de Entidades
Pessoa
Matricula
Disciplina
Sigla
Nome
Nome
No. USP
USP – ICMC – GBDI
Número
Créditos
Atributos de Entidades
▪ Idéia: os atributos de um Conjunto
de Entidades descreve todas as
entidades do conjunto
▪ Pergunta:
um
Conjunto
de
Entidades sem atributos tem
significado para a modelagem???
USP – ICMC – GBDI
Conjunto
▪ Conjuntos: conceito que fundamenta quase toda
a matemática;
▪ Definição: coleção de elementos distintos (sem
repetição) e sem ordem definida (apenas
eventual);
▪ Conjuntos são a base dos SBGDs;
▪ Como definir conjuntos em SGBDs?
USP – ICMC – GBDI
Restrição de Unicidade Chave
▪ Restrição de Unicidade:
▪ Todo conjunto de entidades deve ter
um atributo, ou um conjunto de
atributos, cujo valor identifique
univocamente cada entidade no
conjunto
CHAVE
USP – ICMC – GBDI
Restrição de Unicidade - Chave
▪ Chave Simples:
▪ Notação DER: grifar atributo chave
Pessoa
NUSP
Nome
CPF
USP – ICMC – GBDI
Anotação:
CPF é identificador
Restrição de Unicidade Chave
▪ Chave:
▪ principal meio de acesso a uma
entidade
▪ outros possíveis atributos identificadores
(outras chaves) podem ser anotados
separadamente, para efeito de
documentação e para o projeto lógico
USP – ICMC – GBDI
Restrição de Unicidade - Chave
▪ Chave Simples:
▪ Notação DER: grifar atributo chave
Pessoa
NUSP
Nome
CPF
USP – ICMC – GBDI
Anotação:
CPF é identificador
Restrição de Unicidade - Chave
▪ Chave Composta:
▪ entidade precisa de mais de um atributo
para identificação
▪ a concatenação de todos estes atributos
indica a chave única
▪ Notação DER: todos
os atributos da chave
grifados
Sala Aula
Campus
Bloco
Número
USP – ICMC – GBDI
Capacidade
Atributos
▪ Ex: onde colocar um atributo NOTA???
Pessoa
Matricula
Disciplina
Sigla
Nome
Nome
No. USP
Número
Créditos
USP – ICMC – GBDI
Atributos
▪ Ex: onde colocar um atributo NOTA???
Se fosse um atributo de Pessoa, cada pessoa
teria uma nota única para qualquer disciplina
Matricula
Pessoa
Nome
No. USP
Nota
USP – ICMC – GBDI
Disciplina
Sigla
Nome
Número
Créditos
Atributos
▪ Ex: onde colocar um atributo NOTA???
Se fosse um atributo de Disciplina, todas as
pessoas matriculadas numa disciplina teriam a
mesma nota
Pessoa
Disciplina
Matricula
Nome
No. USP
USP – ICMC – GBDI
Nota
Sigla
Nome
Número
Créditos
Atributos de Relacionamentos
▪ Ex: onde colocar um atributo NOTA???
em MATRICULA!!!
Pessoa
Nome
No. USP
Matricula
Nota
USP – ICMC – GBDI
Disciplina
Sigla
Nome
Número
Créditos
Atributos de Relacionamentos
▪ Observação: os CEs sempre possuem
atributos, mas os CRs podem existir mesmo
que não tenham atributos próprios
▪ existência de CR é justificada pela associação
entre os CEs
▪ ex:
queremos
representar
que
pessoas
matriculam-se em disciplinas, mas pode ser que
não estejamos interessados em indicar as notas
obtidas em cada matrícula
USP – ICMC – GBDI
Atributos

Tipos de atributos

Simples vs. Composto
simples (atômico): não dividido;
uma única parte
 composto: dividido em partes;
possui sub-atributos

USP – ICMC – GBDI
Atributo Composto
Pessoa
Nome
NUSP
Endereço
Composto
Pessoa
Notação
Rua
Número
CEP
Cidade
USP – ICMC – GBDI
Nome
NUSP
Endereço
Rua
Número
CEP
Cidade
Atributo Composto
Pessoa
Pessoa
Nome
NUSP
Notação
Endereço
EndRua
CEP
Cidade
Nome
Numero
Apart
USP – ICMC – GBDI
Nome
NUSP
Endereço
EndRua
CEP
Cidade
Nome
Número
Apart
Atributos

Tipos de atributos

Monovalorado vs. Multivalorado
monovalorado: pode assumir um
único valor para uma/um
entidade/relacionamento em particular
 multivalorado: pode assumir mais de
um valor para uma/um
entidade/relacionamento em particular

USP – ICMC – GBDI
Atributo Multivalorado
Aluno
Multivalorado
Aluno
Nome
Nome
N.Ser.Med.
Notação
Alergias
USP – ICMC – GBDI
N.Ser.Med.
Alergias
Atributos

Tipos de atributos

Armazenado vs. Derivado
armazenado: atributo da entidade
 derivado: valor pode ser obtido a partir
dos valores de outros atributos da
entidade ou de informação armazenada
em seus relacionamentos

USP – ICMC – GBDI
Atributo Derivado
Aluno
Derivado
Aluno
Nome
Nome
Data Nascimento
Notação
Idade
Data Nascimento
Idade
USP – ICMC – GBDI
Atributo Derivado
Pessoa
Matricula
Disciplina
Sigla
No. USP
Nome
Número
Créditos
Nome
Nro Disciplinas
USP – ICMC – GBDI
Conjunto de Relacionamentos -
Papéis
▪ Cada CE que participa de um CR tem um
PAPEL no CR
▪ Indicação opcional
▪ pode facilitar entendimento da
modelagem
Matricula
Pessoa
Matricula
Matriculada
emUSP – ICMC – GBDI
Disciplina
Conjunto de Relacionamentos -
Papéis
▪ Indicação de papéis deve ser feita sempre
que houver ambigüidade na interpretação
do CR
Empresa
Contrata
Contrata
Contratada
por
Contratado
por
Contrata
?
?
USP – ICMC – GBDI
Curso
Conjunto de Relacionamentos -
Papéis
▪ em geral CEs assumem papéis distintos em
CRs distintos
Pessoa
matriculada
matricula
em
Disciplina
Matricula
conclui
Concluir
Nota
USP – ICMC – GBDI
é concluída
Conjunto de Relacionamentos -
Papéis
▪ Auto-Relacionamento:
▪ um mesmo CE desempenha mais de um
papel num mesmo CR
tem pré-requisito
Pré Requisito
Disciplina
é pré-requisito
USP – ICMC – GBDI
Conjunto de Relacionamentos -
Cardinalidade
▪ Cardinalidade
Restrição estrutural
▪ todo CR associa uma ou mais entidades de
um CE1 a uma ou mais entidades de um CE2
▪ Cardinalidade determina o número de
relacionamentos dos quais cada entidade
pode participar
USP – ICMC – GBDI
Conjunto de Relacionamentos Cardinalidade
Ementa
1
Descreve
1
Disciplina
Um para Um
Professor
1
Tutora
N
Turma
Um para Muitos
Pessoa
N
Matricula
Muitos
para Muitos
USP – ICMC – GBDI
M
Disciplina
Conjunto de Relacionamentos –
Restrição de Participação
▪ Restrição de Participação
Restrição Estrutural
▪ Participação Total
▪ Participação Parcial
USP – ICMC – GBDI
117
Conjunto de Relacionamentos
▪ Considere o exemplo:
Curso
1
Possui
N Disciplina
 Se um curso deixar de existir, o que acontece com suas
disciplinas?
 Faz sentido guardar as disciplinas de um curso que não
existe mais?
 Uma disciplina pode existir sem estar associada a um
Curso?
USP – ICMC – GBDI
118
Conjunto de Relacionamentos –
Participação Total
▪ ex: toda entidade Disciplina deve
(obrigatoriamente!) participar de um
relacionamento Possui
deve estar associada
a uma entidade Curso
▪ Notação DER: linha dupla conectando o CE ao CR
Curso
1
Possui
N Disciplina
Participação Total de Disciplina em Possui
USP – ICMC – GBDI
119
Conjunto de Relacionamentos –
Participação Total
▪ Participação
Existencial
Total
ou
Dependência
▪ toda entidade de um CE deve participar,
obrigatoriamente,
de
relacionamento do CR
ao
menos
um
▪ uma entidade só existe se estiver associada a outra
entidade por meio de um relacionamento
USP – ICMC – GBDI
120
Conjunto de Relacionamentos –
Participação Parcial
▪ Participação Parcial
nem todas as
entidades de um CE participam de um CR
▪ uma entidade pode existir sem estar associada a
outra
▪ Notação DER: linha simples conectando o CE ao CR
Aluno
N
Monitora
N Disciplina
Participação Parcial de Aluno em Monitora
USP – ICMC – GBDI
121
Conjunto de Relacionamentos

Considere o exemplo, para a base de dados
de uma empresa:
Dependente
N
Possui
1 Funcionário
Nome
CPF
Nome
Parentesco
Como identificar um dependente na
SEMÂNTICA do domínio de aplicação?
USP – ICMC – GBDI
122
Conjunto de Relacionamentos –
Entidade Fraca
N
Possui
Dependente
1
Funcionário
Nome
CPF
Nome
Parentesco
um Dependente é identificado por meio do
Funcionário ao qual está associado
ENTIDADE FRACA!
USP – ICMC – GBDI
123
Conjunto de Relacionamentos –
Entidade Fraca
▪ Entidade Fraca
▪ não tem atributos que possam identificá-la
univocamente na SEMÂNTICA do domínio de
aplicação
▪ não tem chave (semântica) própria
▪ sua identificação depende de um relacionamento
com uma entidade de outro conjunto (chamada
de owner)
USP – ICMC – GBDI
124
Conjunto de Relacionamentos–
Entidade Fraca

Notação DER:
 Entidade Fraca: traço duplo no retângulo
 CR Identificador: traço duplo no losango
Entidade Fraca
Dependente
N
Possui
1 Funcionário
Nome
Parentesco
Relacionamento Identificador
Nome
CPF
USP – ICMC – GBDI
125
Conjunto de Relacionamentos–
Entidade Fraca

Chave Parcial:
um ou mais atributos de CEs
Fracas que podem identificar univocamente as
entidades fracas relacionadas a um mesmo owner
Dependente
N
Possui
1 Funcionário
Nome
CPF
Nome
Parentesco
Notação DER: traço pontilhado
Chave Parcial
USP – ICMC – GBDI
126
Conjunto de Relacionamentos –
Entidade Fraca
▪ Conjunto de Entidades Fracas:
▪ possui participação total no CR (chamado de CR
identificador)
▪ a cardinalidade do CR é sempre 1:N ou 1:1, mas
nunca N:M
Por que?
USP – ICMC – GBDI
127
Conjunto de Relacionamentos–
Entidade Fraca

Qual seria uma outra maneira de modelar a
informação contida em um Conjunto de Entidades
Fracas?


um atributo multivalorado composto  não é um bom
projeto
Quando modelar como Entidade Fraca?


quando tiver muitos atributos
quando a entidade fraca participar de
relacionamentos além daquele que a identifica
outros
USP – ICMC – GBDI
129
Conjunto de Relacionamentos–
Entidade Fraca

Ex:
Turma
Turma
N
1
Possui
Disciplina
N
Nome
Sigla
Nro Alunos
Matricula
N
USP – ICMC – GBDI
Aluno
Nome
NUSP
130
Conjuntos de Relacionamentos Grau
▪ Um Conjunto de Relacionamentos (CR) pode
envolver dois ou mais Conjuntos de Entidades
(CE)
▪ GRAU do CR é o número de CEs envolvidos
▪ Dois CEs  CR Binário
▪ Três CEs  CR Ternário
▪ ....
USP – ICMC – GBDI
131
Conjuntos de Relacionamentos Grau
Pessoa
N
M
Matricula
Disciplina
Binário
Aluno
Monitora
Monitora
Monitorada por
Disciplina
Auxiliado por
Professor
USP – ICMC – GBDI
Ternário
132
Relacionamento Ternário –
Determinando Cardinalidade...
▪ Dado um Professor e uma Disciplina, pode
existir mais de um aluno monitor que a
monitora
Aluno
N
Monitora
Disciplina
?
Professor
USP – ICMC – GBDI
133
Relacionamento Ternário –
Determinando Cardinalidade...
▪ Dado um Professor e um Aluno monitor, existe
no máximo uma disciplina que esse aluno
monitora
Aluno
N
Monitora
1
Disciplina
?
Professor
USP – ICMC – GBDI
134
Relacionamento Ternário –
Determinando Cardinalidade...
▪ Dado uma Disciplina e um Aluno monitor, mais
de um professor pode ser responsável
Aluno
N
Monitora
1
Disciplina
N?
Professor
USP – ICMC – GBDI
135
Relacionamento Ternário –
Cardinalidade
▪ Cardinalidades possíveis para Ternários:
▪
▪
▪
▪
1:1:1
1:1:N
1:N:P
N:M:P
Aluno
N
Monitora
1
Disciplina
N
Professor
USP – ICMC – GBDI
136
Relacionamento Ternário
▪ Podemos tentar “quebrar” o relacionamento ternário em
vários binários?
Aluno
Monitora
Monitora
N
Monitorada por
N
Disciplina
N
N
Auxilia
Auxiliar
N
Auxiliada
por
Professor
Ministra
N
Ministrada
por
Ministra
problema???
USP – ICMC – GBDI
137
Relacionamento Ternário
Problema
perda de informação semântica
 a informação representada por um conjunto de relacionamentos
ternário nem sempre pode ser obtida apenas com CRs Binários
 ex: como responder: Aluno A auxilia Professor P em qual
Disciplina?
Aluno
Auxilia
Monitora
N
Monitora
Monitorada por
Disciplina
N
N
N
Auxiliar
N
Professor
Auxiliada
USP
– ICMC – GBDI
por
Ministra
N
Ministrada
por
Ministra
138
Relacionamento Ternário
▪ Mesmo Conjunto de Entidades com vários
papéis
Compra
Vendido
Produto
N
Empresa
Negociar
P
M
Vende
Uma Empresa (vendedora) negocia Produtos com outra
Empresa (compradora)
USP – ICMC – GBDI
139
Relacionamento Ternário
M
Promover
Vendas
Compra
Vende
N
Assessora
Empresa
P
Uma Empresa (Assessora) Promove a Venda de
uma outra Empresa (Vendida) para uma terceira
Empresa (Compradora)
USP – ICMC – GBDI
140
Abstrações no MER-X

MER-X (MER Estendido)

suporte a Abstrações de Dados
Abstração de Agregação
 Abstração de
Generalização/Especialização

USP – ICMC - GBDI
145
Abstração de Agregação
 Conceito geral: construção de objetos
compostos a partir de objetos
componentes
 Idéia: elementos de modelagem podem
associar-se criando outros elementos que
representam essa associação
USP – ICMC - GBDI
146
Abstração de Agregação
 Agregação no MER-X:
 agregando Atributos a CE
 os valores dos atributos compõem a entidade
 agregando CE e CR
 combinar entidades relacionadas por meio de
um relacionamento e compor entidades
agregadas (de nível abstrato mais alto)
USP – ICMC - GBDI
147
Abstração de Agregação

Ex: parte do DER para uma aplicação
Consultório Médico
N
Paciente
RG
Nome
Atende
Data
M Médico
CRM
Nome
Como identificar cada atendimento (consulta)?
USP – ICMC - GBDI
148
Abstração de Agregação
Ex: parte do DER para uma aplicação
Consultório
Médicosó pode atender um dado
Problema:
cada médico

paciente uma única vez.
N
Paciente
RG
Nome
Atende
Data
M Médico
CRM
Nome
Como identificar cada atendimento (consulta)?
USP – ICMC - GBDI
149
Abstração de Agregação

Exemplo (cont...):

com RG, CRM e Data é possível identificar cada
consulta univocamente
Paciente N
RG
Nome
Atende
Data
M Médico
CRM
Nome
USP – ICMC - GBDI
150
Abstração de Agregação

Exemplo (cont...):

Na semântica da aplicação, a idéia de
Consulta é relevante

 compor uma entidade Consulta a
partir de um relacionamento entre uma
entidade Paciente e uma entidade
Médico, com uma Data específica
USP – ICMC - GBDI
151
Abstração de Agregação

Onde colocar Data ?
Consulta
Paciente N
Atende
RG
Nome
Data
M Médico
CRM
Nome
USP – ICMC - GBDI
152
Abstração de Agregação
Elementos
Componentes
Consulta
Paciente N
RG
Nome
Atende
Data
Relacionamento
Gerador da
Agregação USP – ICMC - GBDI
M Médico
Entidade
Agregada
(elemento
composto)
CRM
Nome
Atributo da Entidade
Agregada
153
Abstração de Agregação

Chave de Consulta composta por RG,
CRM e Data
Consulta
Paciente N
Atende
RG
Nome
Data
M Médico
CRM
Nome
USP – ICMC - GBDI
154
Abstração de Agregação

Exemplo (cont...):
Paciente N
RG
Nome
Atende
Data
Preço
Consulta
M Médico
CRM
Nome
N
Tem
1
Nro
Recibo
USP – ICMC - GBDI
155
Abstração de Agregação

Ex: parte do DER para uma aplicação PósGraduação

o Título sob o qual é realizada uma orientação é
único para todo o sistema

um atributo do relacionamento poderia identificálo univocamente
Professor M
Nome
Orienta
Título
N
AlunoPós
NUSP
USP – ICMC - GBDI
156
Abstração de Agregação

Abstrair a informação representada no
relacionamento Orienta e criar uma
agregação Projeto

a chave de Projeto é o atributo Título
Projeto
Professor M
Orienta
Nome
N
AlunoPós
NUSP
Título
USP – ICMC - GBDI
157
Abstração de Agregação

Exemplo (cont...):
Projeto
Professor M
Nome
Orienta
Título
Início
USP – ICMC - GBDI
N
AlunoPós
NUSP
N
Financia
1
Agência
de
Fomento
158
Abstração de Agregação

Ex: DER para um sistema de universidade


qual é a chave de Aula?
onde colocar a informação do livro texto adotado
pelo professor para a disciplina?
Livro
Texto
Aula
Professor N
Nome
Ministra
Data/Horário
N Disciplina
Código
USP – ICMC - GBDI
159
Abstração de Agregação

Ex: parte do DER para uma aplicação Agência de
Empregos
Candidato N
Entrevista
M Empresa
CNPJ
Nome
RG
Nome
Como modelar: algumas entrevistas resultam
numa oferta de emprego (com cargo e salário
inicial) e outras não....
160
USP – ICMC - GBDI
Abstração de Agregação
Entrevista
Candidato N
RG
Nome
M Empresa
Entrevista
1
CNPJ
Nome
Data
Resulta
N
Emprego
Cargo
Salario
USP – ICMC - GBDI
N_vagas
161
Abstração de Agregação
 Exemplo:

A Consulta também poderia ser identificada por um Número
de Registro, além de RG, CRM e Data

neste caso, um deles deve ser escolhido como chave principal
Consulta
Paciente N
RG
Nome
Atende
NroRegistro
USP – ICMC - GBDI
M Médico
CRM
Nome
Anotação
complementar:
RG, CRM e Data
são identificadores
Data
163
Abstração de Agregação

Indícios de uso da Agregação

semanticamente, as mesmas instâncias de um CE
participam de mais de um relacionamento
(instância) do mesmo CR


o CR possui um identificador próprio


ex: CEs paciente e médico, CR atende
ex: título, no CR orienta entre os CEs professor e
aluno_pós
necessidade de associar dois relacionamentos

ex: CRs entrevista e resulta
USP – ICMC - GBDI
164
Abstração de Generalização –
Introdução
Genérico
Especializa
(detalha)
Específico
Generaliza
(abstrai)
Is-a
Herança
USP – ICMC - GBDI
165
Abstração de Generalização –
Introdução
 MER  CE agrupa entidades de um mesmo
tipo
 CE expressa o tipo das entidades
 MER-X
 tipos podem ser especializados em subtipos
 entidades podem ser especializadas em subtipos de
entidades relevantes no domínio do problema
Abstração de Generalização/Especialização
USP – ICMC - GBDI
166
Abstração de Generalização –
Notação DER-X
Entidade Abstrata
(Entidade Genérica
ou Supertipo)
Pessoa
Entidade Detalhe
(Entidade Específica
ou Subtipo)
Direção do
Relacionamento:
Especialização
Aluno
Professor
Funcionário
USP – ICMC - GBDI
167
Abstração de Generalização
 Generalização - elementos de um conjunto
são distribuídos em diversos subconjuntos
(subtipos)
 relacionamento Is-a
Pessoa={p1, p2, p3, p4, ...}
Pessoa
Aluno= {p1, p3, ...}
Aluno
Professor
Funcionário
Aluno  Pessoa
USP – ICMC - GBDI
168
Abstração de Generalização
 Critério de Especialização – determina
como os elementos são distribuídos em
subconjuntos (subtipos) específicos
 Definido pelo Usuário
 Definido por Valor de Atributo
(ou Definido por Predicado)
Aluno
Pessoa
Professor
Funcionário
USP – ICMC - GBDI
169
Critério de Especialização
 Critério Definido pelo Usuário  CE(s)
Específico(s) indicado(s) explicitamente na inserção
da entidade
Pessoa
Aluno
Professor
Funcionário
USP – ICMC - GBDI
170
Critério de Especialização
 Critério Definido por Predicado  valores do(s)
atributo(s) de critério definem o(s) CE(s) Específico(s)
automaticamente na inserção da entidade
Nome
Pessoa
Vínculo
Critério de
Especialização
Vínculo
‘aluno’
‘funcionário’
‘docente’
Aluno
Professor
USP – ICMC - GBDI
Funcionário
171
Herança
 Conceito fundamental: HERANÇA
 CEs específicos herdam todos os
atributos do CE genérico
 OBS: em geral, atributos usados como
critério não são herdados pelos CEs
específicos
USP – ICMC - GBDI
172
Herança
Nome
Idade
Altura
Pessoa
Vínculo
Vínculo
N#USP
 a chave do CE
específicos é
herdada do CE
genérico
 chave definida
implicitamente
‘aluno’
Curso
‘docente’
Aluno
Professor
‘funcionário’
Funcionário
N#Func
Função
USP – ICMC - GBDI
173
Herança
 CEs específicos herdam todos os CRs definidos para o
CE genérico
Nome
Idade
Altura
1
Pessoa
possui
N
Plano Saúde
Vínculo
Vínculo
N#USP
‘aluno’
Curso
‘docente’
Aluno
Professor
‘funcionário’
Funcionário
USP – ICMC - GBDI
N#Func
Função
174
Herança em Múltiplos Níveis
Nome
Idade
Pessoa
Altura
Vínculo
N#USP
Curso
Aluno
Professor
Funcionário
N#Func
Função
Graduação
Semestre
Pós-Grad.
Formação
Técnico
Secretária
Especialidade
175
Nome
Exemplo:
Idade
Pessoa
Altura
Vínculo
N#USP
Curso
Aluno
Graduação
Herança
Múltipla
Funcionário
Pós-Grad.
Professor
Assistente
Prof/Aluno
Titulação
Doutor
Herança Múltipla
 Um mesmo CE participa como CE Específico em mais de
uma ocorrência da Abstração de Generalização
 Um mesmo CE possui mais de um supertipo “direto”
 CE específico "herda" todos os atributos e relacionamentos
dos seus supertipos
 atributos e relacionamentos herdados de um mesmo CE
genérico por caminhos diferentes na hierarquia são associados
(implicitamente) apenas uma vez ao CE específico
USP – ICMC - GBDI
177
Exemplo:
Herança Múltipla
Veículo
Aquático
Terrestre
Automóvel
Anfíbio
Barco
Herança Múltipla

Podemos criar uma hierarquia de
especialização com mais de um CE
genérico?
 NÃO!!!
Por que?
USP – ICMC - GBDI
179
Quando Especializar?
 CASO 1:
 determinados atributos aplicam-se somente a
alguns CEs específicos
Atributos
Genéricos
Nome
Idade
Altura
Pessoa
Atributos
Específicos
Vínculo
Vínculo
N#USP
‘aluno’
Curso
Atributos
Específicos
‘docente’
Aluno
Professor
‘funcionário’
Funcionário
N#Func
Função
Quando Especializar?
 CASO 2:
 existem relacionamentos
dos quais participam apenas
entidades de alguns CEs
específicos
Aluno
cursa
Disciplina
Pessoa
Professor
Funcionário
ministra
USP – ICMC - GBDI
181
Restrições da Abstração de
Generalização
 Restrição de Disjunção
 Exclusão Mútua
Ch
CEG
 Sobreposição
AG
 Restrição de Totalidade
 Especialização Total
 Especialização Parcial
CEE1
CEE2
AE1
AE2
...
CEEi
AEi
USP – ICMC - GBDI
184
Restrição de Disjunção
Sigla
Disciplina
Nome
Exclusão Mútua - uma
disciplina deve ser somente de
um tipo
Tipo
Tipo
D
‘grad’
‘pós’
Grad.
Pós-Gr.
Semestre
Nível
USP – ICMC - GBDI
185
Restrição de Disjunção
 Abstração de Generalização é mutuamente exclusiva
se, para qualquer par de CEEs j e k distintos, vale:
 CEEj  CEEk = 
AG
D
CEE1
CEE2
AE1
AE2
Notação
Ch
CEG
...
CEEi
Exclusão Mútua
D
USP – ICMC - GBDI
AEi
186
Restrição de Disjunção
Nome
Pessoa
Função
Função
O
‘vigia’
Vigia
Turno
‘secretário’
Secretário
Nível
Sobreposição - um
funcionário pode acumular
mais de uma função ao
mesmo tempo
‘bibliotecário’
Bibliotecário
Seção
USP – ICMC - GBDI
187
Restrição de Disjunção
 Abstração de Generalização é definida com sobreposição
se para algum par de CEEs j e k distintos:
CEEj  CEEk  

Ch
CEG
Notação
AG
O
CEE1
CEE2
AE1
AE2
Sobreposição
...
CEEi
O
AEi
USP – ICMC - GBDI
188
Restrição de Totalidade
Sigla
Nome
Tipo
‘grad’
Especialização Total qualquer disciplina é de
pelo menos um tipo:
graduação, pós-graduação,
e/ou especialização
Disciplina
tipo
‘pós’
Grad.
Pós-Gr.
Semestre
Nível
‘espec.’
Especializ.
N#Horas
USP – ICMC - GBDI
189
Restrição de Totalidade
 Abstração de Generalização é Total quando todas as
entidades genéricas estão em pelo menos um dos CEEs:
 UK CEEk = CEG
AG
CEE1
CEE2
AE1
AE2
Notação
Ch
CEG
...
Total
CEEi
USP – ICMC - GBDI
AE
i
190
Restrição de Totalidade
Nome
Função
‘vigia’
Vigia
Turno
Especialização Parcial –
uma pessoa pode, por
exemplo, ter a função de
Gerente de Recursos
Humanos (que não está
definida como subtipo)
Pessoa
função
‘secretário’
Secretário
Nível
USP – ICMC - GBDI
‘bibliotecário’
Bibliotecário
Seção
191
Restrição de Totalidade
 Abstração de Generalização é Parcial quando existem
entidades genéricas que não estão em nenhum CEE:
 Uk CEEk  CEG
Ch
CEG
Notação
AG
Parcial
CEE1
CEE2
AE1
AE2
...
CEEi
USP – ICMC - GBDI
AE
i
192
As Restrições da Abstração de
Generalização
 Restrições de cada ocorrência da abstração
dependem da semântica do mundo real
Ch
CEG
AG
CEE1
CEE2
AE1
AE2
...
CEEi
Possibilidades
Parcial Exclusiva
Parcial Sobreposta
Total Exclusiva
Total Sobreposta
AEi
USP – ICMC - GBDI
193
Parcial Exclusiva
Sigla
Há disciplinas que não são nem de
graduação nem de pós-graduação.
Ex: disciplinas para cursos de
treinamento em empresas
Disciplina
Nome
Tipo
tipo
D
‘grad’
‘pós’
Grad.
Pós-Gr.
Semestre
Nível
Uma disciplina só pode ser
de um tipo
USP – ICMC - GBDI
194
Total Exclusiva
Sigla
Só há disciplinas de
graduação, de pós-graduação,
e de especialização
Disciplina
Nome
Tipo
tipo
D
‘grad’
Uma disciplina ou é de graduação
ou de pós, ou de especialização
‘pós’
Grad.
Pós-Gr.
Semestre
Nível
‘espec.’
Especializ.
N#Horas
USP – ICMC - GBDI
195
Parcial Sobreposta
Nome
Pessoa
Além de Vigia, Secretário e
Bibliotecário, há outras funções
Função
função
O
‘vigia’
Vigia
Turno
‘secretário’
Secretário
Nível
‘bibliotecário’
Bibliotecário
Um funcionário pode acumular
mais de uma função, por
exemplo Secretário e
Bibliotecário, ao mesmo tempo
Seção
USP – ICMC - GBDI
196
Total Sobreposta
NUSP
Há somente alunos de
graduação, de pós-graduação,
e de especialização
Aluno
Nome
Tipo
tipo
O
‘grad’
‘pós’
Grad.
Pós-Gr.
Ano Ingresso
M/D
‘espec.’
Um aluno pode ao mesmo tempo
estar matriculado em um curso
de graduação e em um curso de
especialização, por exemplo
Especializ.
USP – ICMC - GBDI
197
Modelo Relacional

Criado por E. F. Codd (IBM)

“A relational model of data for large
shared data banks“. Communications of
the ACM, Volume 13 , Issue 6, June
1970.

Modelo de Implementação

projeto lógico
USP – ICMC – GBDI
198
Sistemas de Banco de Dados
Desenvolvimento de
Sistemas de Banco de Dados
Ciclo de Vida
Mundo Real
Requisitos
de Dados
Coleta/Especificação
de Requisitos
Projeto Conceitual
Projeto Lógico
Projeto Físico
• Projetistas
de BD
SGBD
• Projetistas de
Interface
Protótipo
• DBA
• Pessoal de Suporte e
Operação
Dados e
Metadados
Requisitos
Funcionais
Análise Funcional
Projeto
Implementação
Aplicação
• Usuários
• Operadores de Aplicação
Definição do Modelo
▪ “O modelo relacional representa
uma base de dados como uma
coleção de relações ”
[Elmasri&Navathe]
▪ Modelo Relacional – base teórica
em Teoria de Conjuntos
USP – ICMC – GBDI
200
Definição do Modelo
▪ Valores
▪ dados do mundo real
▪ Tabelas
▪ dados mantidos em tabelas  representam
coleções de objetos, entidades, associações,
etc, do mundo real
▪ tabelas são uma noção intuitiva para as
RELAÇÕES
USP – ICMC – GBDI
201
Terminologia
▪ Relação
▪ Tabela
▪ Tupla
▪ Registro, linha
▪ Atributo
▪ Campo
▪ Valor
▪ Relation Intension
▪ Esquema
▪ Relation Extension
▪ Instância
USP – ICMC – GBDI
202
Modelo Intuitivo
Nome NUSP
Curso ….
Paulo
9999
Info
Izabella 8888
Info
João
Comp
1111
Esquema
Instância
USP – ICMC – GBDI
203
Modelo Intuitivo
Nome NUSP
Curso
Atributo
Tupla
Paulo
9999
Info
Izabella 8888
Info
João
Comp
1111
Valor
USP – ICMC – GBDI
204
Valores

Modelo relacional  valores são atômicos

Valor Atômico

indivisível  não pode ser recuperado em partes


ex: endereço definido como um único atributo
monovalorado  pode ter apenas um valor

ex:


Idade de aluno é monovalorado
Irmãos de aluno é multivalorado
USP – ICMC – GBDI
205
Domínios
▪
Domínio de aplicação
▪
Exemplos:
▪
Escola
▪
Universidade
▪
Cidade
▪
Domínio de atributo
▪
Exemplos:
▪ Nomes de Alunos
▪ Códigos de Disciplinas
▪ Idade
USP – ICMC – GBDI
206
Domínios
▪ Especificação do Domínio de atributo:
▪ Nome
▪ Definição lógica
▪ Tipo de dado e formato de dado
USP – ICMC – GBDI
207
Especificação do Domínio
▪ Nome e Definição lógica. Ex:
▪ Nomes de Alunos: conjunto de todos os
nomes possíveis para pessoas
▪ Códigos de Disciplinas: conjunto dos
códigos das disciplinas oferecidas no ICMC
▪ Idade: conjunto de idades possíveis para
alunos
USP – ICMC – GBDI
208
Especificação do Domínio
▪ Tipo de dado e/ou formato. Ex:
▪ Nomes de Alunos – string de 60
caracteres
▪ Códigos de Disciplinas – string com três
letras seguidas de um traço e de quatro
dígitos: SCC-0240
▪ Idade – inteiro entre 15 e 100
USP – ICMC – GBDI
209
Esquema de Relações
▪ Esquema de relação: descreve a
relação
▪ R (A1, A2, ..., An)
▪ ou R = {A1, A2, ..., An}
▪ R - nome da relação
▪ (A1, A2, ..., An) - conjunto de atributos
que formam a relação
USP – ICMC – GBDI
210
Esquema de Relações
▪ N - grau da relação descrita por R
▪ número de atributos em
R
▪ Dom(Ai) - Domínio do Atributo Ai
▪ Ex:
▪ uma relação de Alunos que tenha os atributos
Nome, RG e Idade, tem o seguinte esquema:
Aluno(Nome, RG, Idade)
USP – ICMC – GBDI
211
Exemplo

Especificação dos domínios:
▪ Nomes de Alunos: conjunto de todos os
nomes possíveis para pessoas – strings de
60 caracteres
▪ RG: conjunto dos RGs válidos no Brasil –
números de 9 dígitos
▪ Idade: conjunto de idades possíveis para
alunos – inteiro entre 0 e 100
USP – ICMC – GBDI
212
Exemplo

Esquema da relação Aluno:


(cont.)
Aluno={Nome, RG, Idade}
Domínios dos atributos de Aluno:
Dom(Nome) = Nomes de Alunos
 Dom(RG) = RG
 Dom(Idade) = Idade

USP – ICMC – GBDI
213
Relações

Relação R – instância do Esquema de
Relação R (A1, A2, ..., An)

R(R)
R  Dom(A1) X Dom(A2) X ... Dom(An)
 R é um conjunto de tuplas
R={t1, t2, ... tk}

t = {v1, v2, ... vn}, vi  Dom(Ai)
USP – ICMC – GBDI
214
Relações
▪ Número total de tuplas possíveis:
▪ |Dom(A1)| X |Dom(A2)| X ... X|Dom(An)|
▪ R(R) contém apenas as tuplas válidas que
representam a situação de um determinado
instante do mundo real
▪ Esquema de Relação R (relation intension) 
mudanças pouco freqüentes
▪ Relação R (relation extension)  dinâmica
USP – ICMC – GBDI
215
Relações
▪ Exemplo:
▪ Esquema de Relação Aluno:
▪ Aluno = {Nome, RG, Idade}
▪ Possível relação:
▪ R(Aluno) = {<José, 12345, 21>,
<Pedro, 54321, 18>,
<Paulo, 321321, 22>}
USP – ICMC – GBDI
216
Relações
▪ Ordem das tuplas de uma relação
▪ relação  conjunto de tuplas
▪ matematicamente não existe a idéia de ordem
em conjuntos  não existe uma ordem em
particular para as tuplas de uma relação
OBS: na implementação de um SGBDR existe uma ordem
física de armazenamento das tuplas, determinando uma
ordem na recuperação das informações
USP – ICMC – GBDI
217
Relações
▪ Ordem dos valores de uma tupla
▪ tupla  lista de n valores dispostos em uma
ordem determinada de acordo com a disposição
dos atributos no esquema da relação
▪ Valores nas tuplas
▪ os valores de uma tupla são atômicos
▪ valor nulo (null )
▪ valor desconhecido
▪ valor não se aplica
▪ valor conhecido
mas não disponível
USP – ICMC – GBDI
218
Restrições das Relações

Restrição de domínio


Restrição de null para atributo


o valor de cada atributo A deve ser um valor
atômico pertencente a Dom(A)
determina quando o valor especial null é ou não
permitido para um atributo
Restrição de unicidade (CHAVE)

deve ser possível identificar univocamente cada
tupla da relação
USP – ICMC – GBDI
219
Restrição de Unicidade
▪ Relação é um conjunto de tuplas
▪ pela teoria de conjuntos  todas as tuplas
devem ser distintas
▪ para garantir esta propriedade de maneira
eficiente
▪ especifica-se uma Restrição de Unicidade 
definição de chave
USP – ICMC – GBDI
220
Restrição de Unicidade
▪ Superchave
▪ conjunto de atributos de uma relação R
que identifique univocamente cada tupla
▪ SCHk(R) = {Aj, ..., Ai}|{Aj, ..., Ai}  R
▪ Combinação de valores não se repete
▪ Exemplo:
▪ Aluno = {Nome, Idade, Curso, NUSP}
▪ SCH1(Aluno) = {Nome, Curso, Idade}
▪ SCH2(Aluno) = {NUSP, Nome}
USP – ICMC – GBDI
221
Restrição de Unicidade
▪ Chave
▪ é uma superchave da qual não se pode
retirar nenhum atributo e ainda
preservar a propriedade de
identificação unívoca  superchave
mínima
USP – ICMC – GBDI
222
CHAVE
▪ CHk(R) = {Ai, ..., Aj}|{Ai, ..., Aj} 
R
tg[CHk]≠ th[CHk]  g, h  R, g ≠ h
▪ Exemplo:
▪ Aluno = {Nome, Idade, Curso, NUSP}
▪ SCH1(Aluno) = {Nome, NUSP}
▪ CH1(Aluno) = {Nome}
▪ CH2(Aluno) = {NUSP}
USP – ICMC – GBDI
223
Chave
▪ Chave Candidata:
▪ pode existir mais de uma chave para
uma mesma relação
▪ cada uma das chaves é chamada de
Chave Candidata
▪ CH1(Aluno) = {Nome}
▪ CH2(Aluno) = {NUSP}
USP – ICMC – GBDI
224
Chave
▪ Chave Primária
▪ escolhida entre as chaves candidatas
▪ a chave primária é freqüentemente a
mais utilizada para acessos à relação
▪ Exemplo:
▪ CH0(Aluno) = {NUSP}
USP – ICMC – GBDI
225
Chave
▪ Notação no Esquema da Relação
▪ CH0(Aluno) = {NUSP}
▪ CH1(Aluno) = {Nome}
Aluno = {Nome, Idade, Curso, NUSP}
Chave secundária
Chave primária
USP – ICMC – GBDI
226
Base de Dados Relacional
▪ O esquema S de uma base de dados
relacional é composto por:
1) um conjunto de esquemas de
relações
S = {R 1, R 2, ..., R n}
2) um conjunto de Restrições de
Integridade 
USP – ICMC – GBDI
227
Base de Dados Relacional
▪ Uma base de dados relacional (uma
instância) é composta por:
▪ um conjunto de relações
BD = {R1, R2, ..., Rn}
tal que cada Ri é uma instância de R i
e cada Ri satisfaz todas as restrições
indicadas em 
USP – ICMC – GBDI
228
Base de Dados Relacional
R2
R1
BASE DE DADOS
R3
R4
USP – ICMC – GBDI
229
Exemplo
▪ Base de Dados para armazenar informações
sobre as diversas turmas de disciplinas oferecidas
num semestre
▪ Esquemas de Relações:
▪ Aluno = {Nome, NUSP, Idade, Curso}
▪ Disciplina = {Sigla, Nome, NCreditos}
▪ Matricula = {Aluno, Disciplina, Semestre, Ano, Nota}
USP – ICMC – GBDI
230
Restrições de Integridade
▪ Restrições de integridade
▪ regras a respeito dos valores que
podem ser armazenados nas
relações
▪ objetivo: garantir consistência
▪ quando definidas no domínio do
problema, devem ser sempre
satisfeitas na base de dados
USP – ICMC – GBDI
231
Restrições de Integridade
▪ Principais restrições de integridade
para um BD relacional:
▪ Restrições de Integridade da
Entidade
▪ Restrições de Integridade
Referencial
USP – ICMC – GBDI
232
Restrições de Integridade
▪ Restrição de Integridade da
Entidade
▪ a chave primária não pode ser
nula em nenhuma tupla de qualquer
relação
▪ se a chave primária for composta por
mais de um atributo, nenhum deles
pode ser nulo
USP – ICMC – GBDI
233
Restrições de Integridade
▪ Restrição de Integridade Referencial
▪ definida entre duas relações
▪ usada para manter consistência entre tuplas de
duas relações
▪ define que: se uma tupla t1 em uma relação R1
faz referência a uma relação R2, então t1
deve fazer referência a uma tupla existente
em R2
USP – ICMC – GBDI
234
Restrições de Integridade Referencial

Restrição de Integridade
Referencial está vinculada ao
conceito de chave estrangeira

conceito fundamental: compatibilidade
de domínio
USP – ICMC – GBDI
235
Restrições de Integridade Referencial
▪ Compatibilidade de Domínio:
▪ dados dois conjuntos de atributos
quaisquer C e D, ambos são compatíveis
quando o primeiro atributo de C tem o
mesmo domínio do primeiro atributo de D,
o segundo atributo de C tem o mesmo
domínio do segundo atributo de D, e assim
por diante
▪ ex:???
USP – ICMC – GBDI
236
Restrições de Integridade Referencial
▪ FK é uma Chave estrangeira em R1 que referencia
R2 se:
1) FK é compatível em domínio com toda a chave
primária PK de R2
2) o valor dos atributos FK numa tupla ti qualquer da
relação R1:
 ou é igual ao valor dos atributos PK de alguma tupla
tk da relação R2  ti[FK] = tk[PK], ti R1, tkR2

ou é nulo  ti[FK] = null
USP – ICMC – GBDI
237
Restrições de Integridade Referencial
▪ As duas condições para a ocorrência da
chave estrangeira determinam a
Restrição de Integridade
Referencial entre duas relações R1 e
R2
R 1[FK]
CE
USP – ICMC – GBDI
R 2[PK]
238
Restrições de Integridade Referencial
▪ Chave Estrangeira:
X = {A, B, C}
Y = {F, G, H}
Dom(F, G) = Dom(A, B)
{A, B} é chave primária em X
{F, G} é chave estrangeira em Y
USP – ICMC – GBDI
Pergunta: a chave
estrangeira {F,G}
pode ser nula? Por
que?
239
Restrições de Integridade Referencial
Pergunta: a chave
estrangeira
{Departamento} pode
ser nula? Por que?
▪ Exemplo:
Departamento = {Cod, NomeD}
Empregado = {NomeE, Departamento}
USP – ICMC – GBDI
240
Exemplo
Alunos = {Nome, No.USP, Idade}
R1(Alunos) = {<Mario, 1234, 20>,
<Paulo, 4321, null >,
<null , 1234, 22>,
<Thais, null, 24>,
<Mario, 1235, 22>}
Disciplina = {Sigla, Monitor}
R2(Disciplina) = {<SCE_104, 1234>,
<SCE_123, 2222>,
<SCE_149, 1234>,
<SCE_532, null >}
Quais restrições
de relação e de
integridade não
são satisfeitas
nas tuplas do
exemplo? Por
quê?
Mapeamento entre Esquemas –
Mapeamento MER  MRel
▪ MER - modelo conceitual
▪ usado para especificar conceitualmente a estrutura
dos dados de uma aplicação
▪ Projeto Conceitual – descrição carregada de semântica
▪ Modelo Relacional - modelo de implementação
▪ usado para suportar a implementação de aplicações
▪ Projeto Lógico
▪ SGBDR  SGBD que se apóia no modelo relacional
Passo 1

Como mapear Conjuntos de Entidades?
Disciplina
Aluno
Sigla
Nome
Nome
No. Créditos
NUSP
CPF
RG
USP – ICMC – GBDI
243
Atributo Composto
Pessoa
NUSP
Nome
Endereço
Rua
Número
CEP
Cidade
Pessoa = {Nome, NUSP, Rua,
Número, CEP, Cidade}
Passo 2

Como mapear Conjuntos de Entidades
Fracas?
Turma
N
Corresponde
1 Disciplina
Sigla
Nome
Número
Horário
Sala
No. Créditos
USP – ICMC – GBDI
245
Entidades fracas
Número
Sigla
Horário
Sala
Nome
Turma
No. Créditos
N
Corresponde
1 Disciplina
1
Tem
Disciplina = {Sigla, Nome, NroCreditos}
N
Aula Prática
Código
Turma = {Número, Sigla, Horário, Sala}
Horário
Laboratório
Aula_Prática = {Código, Horário, Laboratório, Número, Sigla}
Passo 3
▪ Como mapear Conjuntos de Relacionamentos
Binários com Cardinalidade 1:1?
Conferência
Nome
1
organiza
1
Comissão
Cod
Data
Instalação
USP – ICMC – GBDI
NroMembros
247
Relacionamentos Binários
▪ Cardinalidade 1:1
Conferência
1
Nome
organiza
1
Comissão
Cod
Data
Instalação
NroMembros
Conferência = {Nome}
Comissão = {Cod, NroMembros, Conferência, DtaInst}
Relacionamentos Binários
▪ Cardinalidade 1:1
Conferência
Nome
1
organiza
1
Comissão
Cod
Data
Instalação
NroMembros
Conferência = {Nome, CodComissão, DtaInst}
Comissão = {Cod, NroMembros}
Relacionamentos Binários
▪ Cardinalidade 1:1
Gerente
Nome
1
participa
1
(obrigatoriamente!)
Gerente = {Nome, Projeto}
Projeto = {Cod}
Projeto
Cod
 Restrição de null: na
relação Gerente o
atributo Projeto deve
ser definido como não
nulo.
Alternativas para o Mapeamento
Relacionamentos Binários 1:1
Conferência
1
Nome
organiza
1
Comissão
Cod
Data
Instalação
NroMembros
 Mapeamento usual:
 Conferência = {Nome, CodComissão, DataInstalação}
 Comissão = {Cod, NroMembros}
 Alternativa - uma só relação:
ConfCom = {Nome, CodComissão, NroMembros, DataInstalação}
Alternativas para o Mapeamento
Relacionamentos Binários 1:1
Pouca
Participação
1
Homem
Namora
Nome
Idade
tempo
Considerações: o CR Namora
representa relacionamentos de
namoro na USP São Carlos!
Mulher
1
Nome
Idade
 Mapeamento usual
Muitos valores
nulos!!
Mulher = {Nome, Idade}
Homem = {Nome, Idade, NomeM, tempo}
Alternativas para o Mapeamento
Relacionamentos Binários 1:1
 Mapeamento alternativo
Mulher = {Nome, Idade}
Homem = {Nome, Idade}
Namoro = {NomeH, NomeM, tempo}
Desvantagem????
Alternativas para o Mapeamento
Relacionamentos Binários 1:1
 Mapeamento alternativo
Mulher = {Nome, Idade}
Homem = {Nome, Idade}
Namoro = {NomeH, NomeM, tempo}
Desvantagem????
Mais relações e mais junções
Papéis dos Relacionamentos
1 Anterior
Diretor
Sucede
1 Sucessor
Nome
Diretor = {Nome, NomeAntecessor}
Passo 4
▪ Como mapear Conjuntos de Relacionamentos
Binários com Cardinalidade 1:N?
Professor
1
Ministra
N
Disciplina
Sigla
Nome
Horário
USP – ICMC – GBDI
Nome
No. Créditos
256
Relacionamentos Binários
▪ Cardinalidade 1:N
Professor
1
Ministra
N
Disciplina
Sigla
Nome
Horário
Nome
No. Créditos
Professor = {Nome}
Disciplina = {Sigla, Nome, Créditos, Professor, Horário}
Alternativas para o Mapeamento
Relacionamentos Binários 1:N
Pouca
Participação
Disciplina
Sigla
NCreditos
1
Considerações: poucos
alunos monitoram alguma
disciplina
Monitora
N
Horário
Aluno
NUSP
Nome
 Mapeamento usual:
Muitos valores
nulos!!
Disciplina = {Sigla, NCréditos}
Aluno = {NUSP, Nome, Sigla, Horário}
Alternativas para o Mapeamento
Relacionamentos Binários 1:N
 Mapeamento alternativo:
Disciplina = {Sigla, NCréditos}
Aluno = {NUSP, Nome}
Monitora = {NUSP, Sigla, Horário}
Obs: definir restrição de null para o
atributo Sigla (em Monitora), para
que ele não possa ter valor nulo
Passo 5
▪ Como mapear Conjuntos de Relacionamentos
Binários com Cardinalidade M:N?
Aluno
M
Matriculado
Sigla
NUSP
Nome
N
Disciplina
Nota
USP – ICMC – GBDI
Nome
No. Créditos
260
Relacionamentos Binários –
▪ Cardinalidade M:N
Aluno
Matriculado
M
N
Disciplina
Sigla
NUSP
Nota
Nome
Nome
No. Créditos
Aluno = {NUSP, Nome}
Disciplina = {Sigla, Nome, Créditos}
Matriculado = {NUSP, Sigla, Nota}
Passo 6
▪ Como mapear Conjuntos de Relacionamentos com grau > 2?
Projeto
CodP
Início
Fornece
P
Qtde
N
Fornecedor
CodF
M
Nome
Peça
Nome
USP – ICMC – GBDI
262
Relacionamentos Ternários
Projeto
CodP
Fornece
P
Qtde
Início
N
Fornecedor
CodF
M
Nome
Peça
Projeto = {CodP, Início}
Nome
Fornecedor = {CodF, Nome}
Peça = {Nome}
Fornece= {CodP, Nome, CodF, Qtde}
Relacionamentos Ternários
Aluno
NUSP
Monitora
1
Horário
Nome
N
Disciplina
Sigla
M
Nome
No. Créditos
Professor
Aluno = {NUSP, Nome}
Nome
Disciplina = {Sigla, Nome, No.Créditos}
Professor = {Nome}
Monitora= {NUSP, NomeProf, Sigla, Horário}
Passo 7
▪ Como mapear atributos multivalorados?
Aluno
NUSP
Nro.Ser.Med.
Alergias
Nomes
dos Pais
USP – ICMC – GBDI
265
Atributos Multivalorados
 1a Opção de Mapeamento
Aluno
Aluno = {Nome, NSerMed}
Nome
N.Ser.Med.
Alergias
Alergias = {Nome, Alergia}
Atributos Multivalorados
 2a Opção de Mapeamento
Aluno
NUSP
valores possíveis: nome do pai
nome da mãe
Nome
Nomes Pais
Aluno = {NUSP, Nome, Pai, Mae}
Mapeamento entre Esquemas –
Os 7 Passos do Procedimento
1. Mapear
2. Mapear
3. Mapear
4. Mapear
5. Mapear
6. Mapear
7. Mapear
todos
todos
todos
todos
todos
todos
todos
os
os
os
os
os
os
os
CE
CE Fracas
CR de cardinalidade 1:1
CR de cardinalidade 1:N
CR de cardinalidade N:N
CR de grau maior ou igual a 3
atributos multivalorados
USP – ICMC – GBDI
268
Exercício – mapear para o Modelo
CPF
Relacional
estado
nome
RG
nome
1
Representante
Atua
1
Região
1
Pertence
Contato
N
1
É Feito
N
Cliente
telefones
endereço
nome
CNPJ
1
data
É Feita
Produto
cod
preço
N
Pertence
qtde
N
N
Venda
valor
data
nota
Abstrações

Como mapear Conjuntos de Entidades?
Disciplina
Aluno
Sigla
Nome
Nome
No. Créditos
NUSP
CPF
RG
USP – ICMC – GBDI
270
Mapeamento de Abstrações de
Dados
 O MER-X suporta duas abstrações de dados:
 Agregação
 Generalização
 Extensão do Mapeamento MER-MREL para
suporte às abstrações
Mapeamento de Agregação

Caso 1: CE Agregação é identificado por
atributo próprio + chaves dos CEs que
participam do CR gerador

uma mesma instância do CR gerador resulta em
mais de uma entidade agregada
Consulta
Paciente
RG
Nome
N
Atende
Data
Sala
M Médico
CRM
Nome
Mapeamento de Agregação
Caso 1: CE Agregação é identificado por
Noatributo
mapeamento
M-N,
própriotradicional,
+ chaves dos
CEsum
que
mesmo
paciente
poderá consultar o
participam
do CRnão
gerador

mesmo
médico novamente – nem
 uma mesma instância do CR gerador resulta em
mesmo
o retorno.
maispara
de uma
entidade agregada
Consulta
Paciente
RG
Nome
N
Atende
Data
Sala
M Médico
CRM
Nome
Mapeamento de Agregação
Consulta
Paciente
RG
Nome
N
Atende
M
Data
Sala
Médico
CRM
Nome
Médico = {CRM, Nome}
Paciente = {RG, Nome}
Consulta = {Paciente, Medico, Data, Sala}
Mapeamento de Agregação
 Caso 2: CE Agregação é identificado por um de
seus atributos
 as chaves dos CE que participam do CR gerador não
são necessárias para identificar a agregação
Projeto
Professor
NFunc
Nome
N
Orienta
Título
M
AlunoPós
NUSP
Nome
Mapeamento de Agregação

Caso 2a: cada instância do CR gera apenas uma
entidade agregada...
Projeto
Professor
NFunc
Nome
N
Orienta
M
Título
AlunoPós
NUSP
Nome
Aluno = {NUSP, Nome}
Professor = {Nfunc, Nome}
Projeto = {Título, Orientador, Aluno}
Mapeamento de Agregação

Caso 2b: cada instância do CR gera mais de uma
entidade agregada...
Projeto
Professor
NFunc
Nome
N
Orienta
M
Título
AlunoPós
NUSP
Nome
Aluno = {NUSP, Nome}
Professor = {Nfunc, Nome}
Projeto = {Título, Orientador, Aluno}
Mapeamento de Agregação

Caso 2b: cada instância do CR gera mais de uma
entidade agregada...
Esse mapeamento apresentaProjeto
um ganho
Ncom o título doM projeto
Alunosemântico,
como
Professor
Orienta
Pós
chave.
NFunc
Nome
Título
NUSP
Nome
Aluno = {NUSP, Nome}
Professor = {Nfunc, Nome}
Projeto = {Título, Orientador, Aluno}
Mapeamento de Agregação

Caso 3: mistura dos casos 1 e 2b. Duas
formas de identificar CE Agregação:
1. chaves dos CE que participam do CR gerador +
atributo da agregação
2. atributo próprio da agregação
Consulta
Paciente
RG
Nome
N
Atende
Data
Sala
M Médico
CRM
Nome
NroRegistroConsulta
também identifica
univocamente cada
consulta
Consulta
Paciente
RG
Nome
N
Atende
M Médico
Data
Sala
NroRegistroConsulta
CRM
Nome
Médico = {CRM, Nome}
Paciente = {RG, Nome}
Consulta = {Paciente, Medico, Data,
NroRegistroConsulta, Sala}

Exemplo (caso 1): um relacionamento R1 entre o
Professor P1 e a Disciplina D1 pode gerar várias
entidades Aula, mas o Livro Texto não muda para
cada uma destas aulas.... Livro
Texto
Aula
Professor
NFunc
Nome
N
Ministra
Data/Horário
Professor = {Nfunc, Nome}
N Disciplina
Sigla
Nome
Disciplina = {Sigla, Nome}
Aula = {Nfunc, Sigla, Data/Horário, LivroTexto}

Exemplo: um relacionamento R1 entre o Professor
P1 e a Disciplina D1 pode gerar várias entidades
Aula, mas o Livro Texto não muda para cada uma
destas aulas....
Livro
Texto
Aula
Professor
NFunc
Nome
N
Ministra
N Disciplina
Sigla
Nome
Data/Horário
Professor = {Nfunc, Nome}
Disciplina = {Sigla, Nome}
Ministra = {Nfunc, Sigla, LivroTexto}
Aula = {Nfunc, Sigla, Data/Horário}
A semântica permite
normalizar, gerando
uma nova relação.
Mapeamento da Generalização
 Três alternativas principais:
1. Mapear o CEG e os CEE em relações diferentes
2. Mapear o CEG e todos os CEE em uma única relação
3. Mapear cada CEE (e apenas) em sua própria relação,
junto com seus respectivos atributos genéricos
Mapeamento da Generalização - Alternativa 1 (relações diferentes)
Procedimento Padrão 1
Ch
CEG
AG
CEG = { Ch, AtC, AG }
CEE1 = { Ch, Ae1}
...
CEEk = { Ch, Aek}
disjunção
AtC
D
CEE1
Ae1
...
CEEk
Aek
Uma relação geral com um atributo de tipo (AtC)  disjunção.
Mapeamento da Generalização - Alternativa 1
Procedimento Padrão 2
CEG = { Ch, AtC, AG }
CEE1 = { Ch, Ae1}
...
CEEk = { Ch, Aek}
Ch
CEG
AG
AtC
O
CEE1
Ae1
...
sobreposição
CEEk
Aek
A relação geral não possui atributo de tipo  sobreposição.
Mapeamento da Generalização - Alternativa 1
Procedimento Padrão 3
CEG = { Ch, AG }
CEE1 = { Ch, Ae1}
...
CEEk = { Ch, Aek}
CEC={ Ch, AtC}
Ch
CEG
AG
AtC
O
CEE1
Ae1
...
sobreposição
CEEk
Aek
Uma terceira relação – CEC – que indica a qual tipo de entidade
uma dada entidade se refere (neste caso, sobreposição).
Mapeamento da Generalização - Alternativa 2 (única relação)
Procedimento Padrão 4
CEG = { Ch, AtC, AG, Ae1, ... Aek }
Ch
CEG
AG
AtC
D
CEE1
Ae1
...
disjunção
CEEk
Aek
Uma única tabela com todos os possíveis atributos de todas as
possíveis entidades, com atributo de tipo  disjunção.
Mapeamento da Generalização - Alternativa 2
Procedimento Padrão 5
CEG = { Ch, AtC, AG, Ae1, ... Aek }
Ch
sobreposição
CEG
AtC
AG
O
CEE1
Ae1
...
CEEk
Aek
Uma única tabela com todos os possíveis atributos de todas as
possíveis entidades, sem atributo de tipo  sobreposição.
Mapeamento da Generalização - Alternativa 2
Procedimento Padrão 6
CEG = { Ch, AG, Ae1,... Aek, BCEE1, .... BCEEk}
Ch
CEG
AG
AtC
O
CEE1
Ae1
...
sobreposição
CEEk
Aek
Uma única tabela com todos os possíveis atributos de todas as possíveis
entidades, sem atributo de tipo, e com atributos booleanos para
determinar quais atributos correspondem a quais entidades.
Mapeamento da Generalização - Alternativa 3 (não há relação genérica)
Procedimento Padrão 7
CEE1 = { Ch, AG, AE1 }
...
CEEk = { Ch, AG, AEk }
Ch
participação total
CEG
AG
AtC
CEE1
Ae1
...
Cada relação com seus
atributos
gerais
e
específicos.
CEEk
Aek
Sobreposição – uma dada
entidade pode ser várias
ao mesmo tempo.
Mapeamento da Generalização - Alternativa 3
Procedimento Padrão 8
CEEk = { Ch, AG, AEk }
CEC={ Ch, AtC}
Ch
participação total
CEG
AG
AtC
D
CEE1
Ae1
...
CEEk
Aek
Cada relação com seus
atributos
gerais
e
específicos.
E outra que indica de
qual tipo é cada instância
 disjunção.
Mapeamento da Generalização - Alternativa 3
Procedimento Padrão 9
CEEk = { Ch, AG, AEk }
CEC={ Ch, AtC}
Ch
AG
participação total
CEG
AtC
O
CEE1
Ae1
...
CEEk
Aek
Cada relação com seus
atributos
gerais
e
específicos.
E outra que indica de
qual tipo é cada instância
 sobreposição.
Os 9 Procedimentos Padrão
1 CEG = {Ch, AtC, AG} CEEi = {Ch, Aei}
2 CEG = {Ch, AG}
CEEi = {Ch, Aei}
3 CEG = {Ch, AG}
CEEi = {Ch, Aei}
CEC = {Ch, AtC}
4 CEG = {Ch, AG, AtC, Ae1, Ae2, .... Aem}
5 CEG = {Ch, AG, Ae1, Ae2, .... Aem}
6 CEG = {Ch, AG, Ae1, Ae2, .... Aem, BCEE1, BCEE2, ...BCEEm}}
7
CEEi = {Ch, AG, Aei}
8
CEEi = {Ch, AG, Aei}
CEC = {Ch, AtC}
9
CEEi = {Ch, AG, Aei}
CEC = {Ch, AtC}