BANCO DE DADOS

• Ramez Elmasri e Shamkant B. Navathe

• Capítulo 7: modelagem de dados u1lizando o
modelo En1dade-Relacionamento (ER)
• Carlos Alberto Heuser
• Capítulo 2: abordagem en1dade-relacionamento

Vanessa Borges – [email protected]

Projeto de banco de dados

• Obje%vo da abordagem de BD
• Oferecer abstração dos dados
• Separar aplicações dos usuários dos detalhes de hardware
• Ferramenta u9lizada → modelo de dados

Banco de Dados FACOM | UFMS 2

Modelos de Dados
• Uma caracterís+ca fundamental do uso de banco de dados é
a abstração dos dados.
• Ocultando os detalhes de armazenamento
• Para isso, é criado um Modelo de dados:
• Conjunto de conceitos que podem ser usados para descrever a estrutura de um
banco de dados
• Fornece o significado necessário para permi;r essa abstração

Tipos, relacionamentos e
restrições de dados

Banco de Dados FACOM | UFMS 3

Fases de um Projeto de Banco de Dados
• Existem várias propostas para representar um modelo de dados. Mini-
Podemos classificá-los de acordo com os conceitos usados para mundo Levantamento
descrever a estrutura do banco de dados: de requisitos

• Modelos conceituais ou alto nível

• Descrevem a estrutura de um banco de dados de acordo com a percepção dos Conceitual Ex: Modelo ER
usuários independentes de aspectos de implementação

• Modelos representa6vos (lógicos)

• Descrevem a estrutura de um banco de dados da forma como será manipulado
Ex: Modelo
pelo SGBD mais dependentes de aspectos de implementação
Lógico Relacional,
• Modelos ;sicos ou baixo nível Modelo OO
• Descrevem a estrutura de um banco de dados da forma como os dados são
fisicamente armazenados totalmente dependentes de aspectos de Ex:
implementação (registros, blocos, índices, etc.) implementação
Físico
específica para
um SGBD

Banco de Dados FACOM | UFMS 4

Modelos de Dados - conceitual
• Descrição do banco de dados independente do SGBD

En#dade, atributo e relacionamentos

Representa um Representa alguma Representa uma

objeto ou conceito propriedade de associação entre
do mundo real interesse. as en6dades
Descreve melhor uma
en6dade.

• Modelo En#dade e Relacionamento (ER)

Banco de Dados FACOM | UFMS 5

Modelos de Dados - lógico
• O modelo de dados representacional (ou lógico) são baseados em
registros.
• Modelo de Dados Relacional: o modelo mais difundido usado
atualmente

• Modelo de Dados: modelos de dados de rede e Modelo de dados

hierárquicos.

• Modelo de dados Orientados a Objetos: são uma nova família de

modelos de dados de implementação conceitual.

Banco de Dados FACOM | UFMS 6

Modelos de Dados - lógico
• Modelo de Dados Relacional:

Banco de Dados FACOM | UFMS 7

Modelos de Dados - ,sico
• Descreve a base de dados internamente (ajuste de performance).
• Indexação e estruturas de arquivos
• Transações e controle de concorrência
• O;mização
• Recuperação em casos de falhas
• Mecanismos de proteção (segurança)

• Tendência em produtos modernos é cada vez mais esconder o

modelo :sico.
• Implementação para um SGBD específico
• Levará em conta os Hpos de dados, restrições, Hpos de objetos e
outros objetos proprietários de cada SGBD

Banco de Dados FACOM | UFMS 8

Fases de um Projeto de Banco de Dados
• Existem várias propostas para representar um modelo de dados. Mini-
Podemos classificá-los de acordo com os conceitos usados para mundo Levantamento
descrever a estrutura do banco de dados: de requisitos

• Modelos conceituais ou alto nível

• Descrevem a estrutura de um banco de dados de acordo com a percepção dos Conceitual Ex: Modelo ER
usuários independentes de aspectos de implementação

• Modelos representa6vos (lógicos)

• Descrevem a estrutura de um banco de dados da forma como será manipulado
Ex: Modelo
pelo SGBD mais dependentes de aspectos de implementação
Lógico Relacional,
• Modelos ;sicos ou baixo nível Modelo OO
• Descrevem a estrutura de um banco de dados da forma como os dados são
fisicamente armazenados totalmente dependentes de aspectos de Ex:
implementação (registros, blocos, índices, etc.) implementação
Físico
específica para
um SGBD

Banco de Dados FACOM | UFMS 9

 Fases de um Projeto de Banco de Dados
Arquitetura de três esquemas (ANSI/SPARC)
§ Obje6vo: separar as aplicações do
usuário do banco de dados Isico
Descreve a parte do banco de
dados em que um grupo de
usuários (ou aplicações) em
parCcular está interessado
Descreve a estrutura do banco
de dados inteiro para uma
comunidade de usuários
(enCdades, relacionamentos,
restrições, etc)
Descreve a estrutura do
armazenamento >sico do
banco de dados.
Banco de Dados FACOM | UFMS 10
Fases de um Projeto de Banco de Dados
Arquitetura de três esquemas (ANSI/SPARC)
Segunda Navathe: relação entre os modelos e
os níveis da arquitetura três esquemas

Modelos

Modelo Modelo Modelo

Físico ER Relacional

Nível X
Níveis

interno

Nível Baseado em X
um projeto
conceitual conceitual

Nível Baseado em X
um projeto
externo conceitual

Banco de Dados FACOM | UFMS 11

Fases de um Projeto de Banco de Dados
Arquitetura de três esquemas (ANSI/SPARC)
• Independência de dados:
• Pode ser definida como a capacidade de se
alterar um esquema em um nível em um banco
de dados sem ter que alterar um nível superior.

• Existem dois tipos de independência de

dados:
• Independência de dados lógica:
• É a capacidade de alterar o esquema conceitual
sem ter que alterar o esquema externo ou as
aplicações do usuário;
• Independência de dados física:
• É a capacidade de alterar o esquema interno sem
ter que alterar o esquema conceitual, o esquema
externo ou as aplicações do usuário.

Banco de Dados FACOM | UFMS 12

Ramez Elmasri e Shamkant B. Navathe
BANCO DE DADOS
• Ramez Elmasri e Shamkant B. Navathe
• Capítulo 7: modelagem de dados u1lizando o
modelo En1dade-Relacionamento (ER)
• Carlos Alberto Heuser
• Capítulo 2: abordagem en1dade-relacionamento

Vanessa Borges – [email protected]

Categorias de Modelo de Dados
• Existem várias propostas para representar um modelo de dados. Mini-
Podemos classificá-los de acordo com os conceitos usados para mundo Levantamento
descrever a estrutura do banco de dados: de requisitos

• Modelos conceituais ou alto nível

• Descrevem a estrutura de um banco de dados de acordo com a percepção dos Conceitual Ex: Modelo ER
usuários independentes de aspectos de implementação

• Modelos representativos (lógicos)

• Descrevem a estrutura de um banco de dados da forma como será manipulado
Ex: Modelo
pelo SGBD mais dependentes de aspectos de implementação
Lógico Relacional,
• Modelos físicos ou baixo nível Modelo OO
• Descrevem a estrutura de um banco de dados da forma como os dados são
fisicamente armazenados totalmente dependentes de aspectos de Ex:
implementação (registros, blocos, índices, etc.) implementação
Físico
específica para
um SGBD

Banco de Dados FACOM | UFMS 14

Introdução
• Utilizando modelo de dados conceituais de alto nível
para o projeto do banco de dados
§Esquema conceitual
§ Projeto conceitual
§ Descrição concisa dos requisitos de dados
§ Inclui detalhes dos tipos de entidade, relacionamentos e
restrições
§ Transformado do modelo de dados de alto nível para o modelo
de dados da implementação

Banco de Dados FACOM | UFMS 15

Introdução
• O Modelo En+dade-Relacionamento (MER) é um modelo de
dados de alto-nível criado com o obje<vo de representar a
semân<ca associada aos dados do minimundo
• Caracterís7cas
• Proposto por Peter Chen em 1976
• Foi desenvolvido para facilitar o projeto lógico do BD
• Permite a representação da estrutura lógica global do BD
• É um dos modelos de dados com maior capacidade semânHca
• Representa um problema como um conjunto de enHdades e
relacionamentos entre estas enHdades

Banco de Dados FACOM | UFMS 16

Introdução
• O esquema conceitual criado utilizando-se o MER é chamado
de Diagrama Entidade-Relacionamento (DER)
• Unified Modeling Language (UML)

• MER: conjunto de conceitos e elementos de modelagem que

o projeHsta de banco de dados precisa conhecer.
• DER: resultado do processo de modelagem executado pelo
projeHsta de dados que conhece o MER.

Banco de Dados FACOM | UFMS 17

Introdução
• Elementos do diagrama ER
• Entidade
• Atributo
• Chave
• Relacionamento
• Cardinalidade

Banco de Dados FACOM | UFMS 18

Modelo ER – Tipo entidade
• Coleção ou conjunto de entidades que possuem os mesmos
atributos
Funcionário Empresa

Banco de Dados FACOM | UFMS 19

Modelo ER – EnAdade
• Qualquer coisa do mundo real envolvida no problema

• Pode ser um objeto com:

• Existência física: uma pessoa, um carro
• Existência conceitual: uma companhia, um emprego, um curso

Pessoa livro

Banco de Dados FACOM | UFMS 20

Modelo ER – Entidade
• Exemplo de enHdade – banco de dados empresa

A empresa é organizada em departamentos. Cada departamento tem um nome

exclusivo, um número exclusivo e um funcionário em par;cular que o gerencia. Um
departamento pode ter vários locais. Um departamento controla uma série de
projetos, cada um deles com um nome exclusivo, um número exclusivo e um local
exclusivo.

Banco de Dados FACOM | UFMS 21

MODELO ER – entidades e atributos
• Cada En9dade tem propriedades par9culares que são chamadas
de Atributos

• Uma en;dade FUNCIONÁRIO pode ser descrita pelo seu nome, o trabalho que
realiza, idade, endereço e salário

Nome Trabalho Idade Endereço

Salário
Funcionário

Banco de Dados FACOM | UFMS 22

Atributos
§Tipos de atributos:
• Simples versus composto
• Valor único versus mul2valorados
• Armazenado versus derivado
• Valores NULL
• Atributos complexos

Banco de Dados FACOM | UFMS 23

Atributos simples X composto
• Alguns atributos podem ser divididos em sub-partes com significados
independentes.
• Simples
• Cada entidade tem um único valor atômico para o atributos
• São atômicos (não podem ser decompostos)

• Composto
• O atributo pode ser composto por vários componentes
• Podem formar uma hierarquia

Banco de Dados FACOM | UFMS 24

Atributos simples X composto
• Notação gráfica:

Rua Número CEP

Nome Código Endereço

Funcionário

Banco de Dados FACOM | UFMS 25

Atributos multivalorado X monovalorado
• Muitos atributos têm apenas um valor (monovalorados).
Porém existem atributos que podem ter um conjunto de
valores (Multivalorados)
Monovalorados
­ Um único valor para cada en;dade (Ex: nome)
Mul+valorados
­ Múl;plos valores para cada en;dade (Ex: uma pessoa pode ter mais de um
telefone)

Banco de Dados FACOM | UFMS 26

Atributos multivalorado X monovalorado
• Notação gráfica

Rua Número CEP

Nome Código Endereço Telefone

Funcionário

Banco de Dados FACOM | UFMS 27

Atributos armazenado x derivado
• Armazenados
• Está de fato armazenado em um DB
• Derivados
• Pode ser determinado através de outros atributos ou através de entidades
relacionadas
• Pode ou não ser armazenado no BD
• Exemplo:
• Idade = Data_Atual - Data_Nascimento
• Número de empregados de um determinado departamento

Banco de Dados FACOM | UFMS 28

Atributos armazenado x derivado
• Notação gráfica:

Rua Número CEP

Nome Código Endereço Telefone

Data
Funcionário nascimento

Idade

Banco de Dados FACOM | UFMS 29

Cardinalidade de atributos
• É possível definir a cardinalidade mínima e máxima Estudante
código
de um determinado atributo no Modelo ER
telefone
• Define a classificação dos atributos: CEP
obrigatório/opcional, monovalorado/multivalorado

• Cardinalidade mínima
• Atributo obrigatório (cardinalidade 1): cada entidade possui no Estudante
mínimo um valor associado naquele atributo
• Atributo opcional (cardinalidade 0): entidade pode conter
valores nulos naquele atributo
telefone (0,n)
• Cardinalidade máxima código
• Atributo monovalorado (cardinalidade 1): cada entidade possui nome
no máximo um valor associado
• Atributo multivalorado (cardinalidade n): as entidades podem Cardinalidade (1,1)
conter vários valores associados ao mesmo atributo
pode ser omitida

Banco de Dados FACOM | UFMS 30

Valores NULOS de atributos
• Algumas vezes pode acontecer de um atributo não possuir valor

• Nesses casos, atribui-se um valor nulo (null) para esse atributo

• Apartamento = null para aqueles funcionários que não residam em
um prédio. (não aplicável)

• O valor null pode ser aplicado também para denotar que o valor é
desconhecido

Banco de Dados FACOM | UFMS 31

Atributo chave
(identificadores de entidade)
• Uma restrição importante sobre enHdades de um Hpo de enHdade é a
restrição de atributo-chave
• Todo Tipo de EnHdade deve ter um atributo chave, seja ele um atributo
simples ou composto
• Os valores de um atributo chave devem ser disHntos. Esta unicidade
deve valer para quaisquer extensões desse Hpo de enHdade
simples composto
Pessoa Pessoa

Código Nome Endereço Código Nome Endereço

Banco de Dados FACOM | UFMS 32

Relacionamento
• Conjunto de associações entre duas ou mais entidades

Trabalha
Funcionário para
Departamento

Banco de Dados FACOM | UFMS 33

Relacionamento
• Notação gráfica:

Funcionário Trabalha para Departamento

Banco de Dados FACOM | UFMS 34

Relacionamento recursivo
A Figura 2.5 apresenta um possível diagrama de ocorrências para o DER
• Não necessariamente um relacionamento associa entidades diferentes
da Figura 2.4. Os papéis (marido e esposa) das ocorrências de entidades em
cada ocorrência de relacionamento foram anotadas nas linhas que ligam os
• Cada entidade que participa de um relacionamento possui um papel específico
círculos representativos das ocorrências de entidades e relacionamentos.

Auto relacionamento
ou relacionamentos
recursivos

Papel

Banco de Dados FACOM | UFMS 35

Relacionamento recursivo
isor
1
Superv
Funcionário Supervisão

No caso de: Subordinad

o n
Um FUNCIONÁRIO supervisor pode
gerenciar diversos funcionários de
um DEPARTAMENTO

O papel de FUNCIONÁRIO é
(1) supervisor ou (2) subordinado do
DEPARTAMENTO.

Banco de Dados FACOM | UFMS 36

Grau do relacionamento
• O Grau de um Tipo de Relacionamento é número de entidades
envolvidas
is or
Superv
Grau: unário
ou recursivo Funcionário Supervisão

Subordinad
o

• Unário (ou recursivo) – relaciona um tipo-entidade com ela mesma –

indicado utilizar nomes de papéis

Banco de Dados FACOM | UFMS 37

Grau do relacionamento
• O Grau de um Tipo de Relacionamento é número de entidades
envolvidas

Grau: binário Funcionário

Trabalha
Projeto
em

• Relaciona duas entidades

• grau de relacionamento mais utilizado

Banco de Dados FACOM | UFMS 38

Grau do relacionamento
• O Grau de um Tipo de Relacionamento é número de entidades envolvidas
Grau: ternário
Fornecedor Fornece Projeto

Peça
• Relaciona três entidades
• grau de relacionamento mais utilizado
• Regra para a determinação das multiplicidades:
• Fixa-se dois elementos (dois tipos-entidade)
• Verifica-se quantos elementos do outro entidade podem surgir com relação a um elemento de
cada entidade fixada
• Se a quantidade for indeterminada ou variável
• então considera-se n
• senão considera-se 1

Banco de Dados FACOM | UFMS 39

Cardinalidade

• Proporção de parHcipação em um relacionamento

Cada projeto está Cada funcionário está

associado a no máximo associado a no máximo
n funcionários 1 projeto

n Trabalha 1
Proporção n:1 Funcionário Projeto
em

FACOM | UFMS 40
Restrição de parEcipação na relação
Notação alternaEva de cardinalidade

n Trabalha 1
Funcionário Projeto
em

Notação min, max (1,1) Trabalha (0,n)

Funcionário Projeto
segundo Ramez Elmasri e em
Shamkant B. Navathe

Notação min, max (0,n) Trabalha (1,1)

Funcionário Projeto
segundo Carlos Alberto em
Heuser (Peter Chen)

FACOM | UFMS 41
Restrição de participação na relação
Notação alternativa de cardinalidade
Notação min, max segundo Carlos Alberto Heuser (Peter Chen)
• Indica a restrição mínima e máxima (min, max) da par;cipação de
cada en;dade no relacionamento

Cada projeto participa do Cada funcionário participa do

relacionamento no mínimo 0 e relacionamento no mínimo 1
no máximo n vezes vez e no máximo 1 vezes

(0,n) Trabalha (1,1)

Proporção n:1 Funcionário Projeto
em

• Um funcionário não pode não trabalhar em projetos (mínimo 1)

• Um funcionário pode trabalhar em no máximo 1 projeto (máximo 1)
• Um projeto pode não ter funcionários trabalhando (mínimo 0)
• Um projeto pode possuir diversos funcionários trabalhando (máximo n)

FACOM | UFMS 42
Restrição de participação na relação
Notação alternativa de cardinalidade
Notação min, max segundo Carlos Alberto Heuser (Peter Chen)
• Indica a restrição mínima e máxima (min,max) da participação de
cada entidade no relacionamento
Participação parcial Participação total

(0,n) Trabalha (1,1)

Proporção 1:n Funcionário Projeto
em

• Um funcionário não pode não trabalhar em projetos (mínimo 1)

• Um funcionário pode trabalhar em no máximo 1 projeto (máximo 1)
• Um projeto pode não ter funcionários trabalhando (mínimo 0)
• Um projeto pode possuir diversos funcionários trabalhando (máximo n)

FACOM | UFMS 43
Cardinalidade dos relacionamentos
• Proporção de participação em um relacionamento

1:1 1 É
1
Departamento gerenciado Funcionário
um-para-um por

1:n Departamento
1 n
Possui Funcionário
um-para-muitos

n:n n Trabalha n
Funcionário Projeto
muitos-para-muitos em

FACOM | UFMS 44
Atributo de relacionamento
• Relacionamentos também podem ter atributos
• Os atributos dos ;pos de relacionamento 1:1 ou 1:n podem ser migrados para um
dos ;pos de en;dade par;cipantes

• Relacionamento 1:1
Data de
início

1 1
Funcionário Gerencia Departamento

Data de início pode ser atributo tanto de FUNCIONÁRIO quando de DEPARTAMENTO (1:1)

45

Banco de Dados FACOM | UFMS

Atributo de relacionamento
• Os atributos dos tipos de relacionamento 1:1 ou 1:n podem ser migrados para um
dos tipos de entidade participantes

• Relacionamento 1:n
• O atributo do relacionamento pode ser migrado apenas para a entidade do lado n

Data de
início

n Trabalha 1
Funcionário para
Departamento

Data de início poderá ser atributo de FUNCIONÁRIO (1:n)

Banco de Dados FACOM | UFMS 46

Atributo de relacionamento
• Para ;pos de relacionamento n:n, alguns atributos podem ser determinados pela
combinação de en;dades par;cipantes em uma instância de relacionamento, e
não por qualquer en;dade isolada
• Esses atributos precisam ser especificados como atributos de relacionamento

Horas

n Trabalha n
Funcionário em
Projeto

Horas é obrigatoriamente atributo do relacionamento (n:n)

Banco de Dados FACOM | UFMS 47

Atributo de relacionamento
• Exemplos
N° de Taxa de
parcelas juros

1 Financia n
Financeira Venda
mento

Código Nome Função Código Título

n n
Engenheiro Atuação Projeto

Banco de Dados FACOM | UFMS 48

Relacionamento idenEficador
EnEdade fraca
• A entidade dependente só existe se houver empregado
• Empregado é um entidade proprietária
• O relacionamento entre empregado de dependente é um relacionamento
identidade

Código Nome IdenHficador Nome

1 n
Funcionário Possui Dependente

Banco de Dados FACOM | UFMS 49

Relacionamento idenEficador
EnEdade fraca
• Notações alternativas para entidade fraca

1 n
Funcionário Possui Dependente

1 n
Funcionário Possui Dependente

Entidade fraca
Relacionamento
de identificação

Banco de Dados FACOM | UFMS 50

 grupo. Finalmente, uma filial é identificada pela empresa a qual está

Relacionamento identificador
vinculada e por um número de filial dentro da empresa. Pela definição acima,
tanto EMPRESA quanto FILIAL são entidades fracas. Entretanto, ao

Entidade fraca
considerarmos que a maior parte das entidades que eventualmente
comporiam o restante do modelo estariam ligadas a EMPRESA ou FILIAL
vemos que o conceito de “fraqueza” introduzido acima não se aplica ao caso
em questão.

identificador de entidade
FACOM | UFMS 51
=
Entidade associativa
• Na modelagem ER não é possível realizar a associação entre
relacionamentos
• Uma enHdade associaHva é a redefinição de um relacionamento que
passa a ser tratado como se fosse também uma enHdade

Banco de Dados FACOM | UFMS 52

Resumo - notação
Conceito Símbolo

Entidade

Atributo

Atributo identificado

Atributo derivado

Atributo multivalorado

Atributo composto

Banco de Dados FACOM | UFMS 53

Resumo - notação
Conceito Símbolo

Relacionamento

ParScipação total de E1 R E2
E2 em R

1 n
Razão de cardinalidade 1:n E1 R E2
de E1:E2 em R

Relacionamento idenSficado ou
/ enSdade fraca

EnSdade associaSva

Banco de Dados FACOM | UFMS 54

Exercício 1:
Precisamos criar um modelo ER de banco de dados para o controle
acadêmico de uma universidade
Deseja-se manter informações sobre alunos, cursos, disciplinas e departamentos.
Cada departamento possuir um código único e um nome.
Cada disciplina possui exatamente um departamento responsável, e um departamento é
responsável por muitas disciplinas, inclusive por nenhuma.
Uma disciplina pode possuir diversos pré-requisitos, inclusive nenhum. Uma disciplina pode ser
pré-requisito de muitas outras disciplinas.
Cada disciplina possui um código único, um nome e uma data de criação.
Uma disciplina pode aparecer no currículo de muitos cursos e um curso pode possuir muitas
disciplinas em seu currículo.
Cada curso possui um nome e uma descrição.
Um aluno está inscrito em exatamente um curso e um curso pode ter nele inscritos muitos
alunos. O aluno possui um RGA único, vários telefones (residencial, comercial, celular, etc),
nome e data de nascimento.

Banco de Dados FACOM | UFMS 55

Modelo ER para controle acadêmico

Pré-requisitos

(0,n) (0,n)
Nome Código
Nome
(0,n) (0,n)
(1,1) (0,n) Data de
Departamento Responsável Disciplina criação

(0,n) (1,1) Código

(0,n) (0,n)

Compõe
Data currículo
nascimento

Nome RGA
(0,n) (0,n)
(0,n)
(1,1) (1,1)
(0,n)
Aluno Inscrito Curso
Notação min, max segundo
Telefone Nome Descrição
Carlos Alberto Heuser
Banco de Dados FACOM | UFMS 62
Exercício 2:

Para o problema a seguir, monte um modelo Entidade Relacionamento

correspondente.
1. Uma pessoa, que possui nome, RG único, data de nascimento
(composta por dia, mês e ano), nome de pai e nome de mãe, casa-se
com outra pessoa.

Banco de Dados FACOM | UFMS 64

 1. Uma pessoa, que possui nome, RG único, data de
nascimento (composta por dia, mês e ano), nome de pai e
nome de mãe, pode se casar com outra pessoa.

Mês
Dia Ano
RG
Nome Nome
Data
Pai

Nome
Pessoa Mãe

1 1
marido esposa
Casa

Banco de Dados FACOM | UFMS 65

Exercício 3:

Dados os 6pos-en6dade curso e disciplina

– atributos de curso: código_curso, nome_curso
– atributos de disciplina: código_disciplina, nome_disciplina, carga_horária

Faça duas diferentes modelagens, de acordo com as especificações a seguir

Modelagem1: uma disciplina é obrigatória ou opta;va, independentemente do curso

Modelagem2: uma disciplina pode ser obrigatória para um curso e opta;va para outro
curso

Banco de Dados FACOM | UFMS 66

– atributos de curso: código_curso, nome_curso
– atributos de disciplina: código_disciplina, nome_disciplina, carga_horária

Modelagem1: uma disciplina é obrigatória ou optaSva, independentemente do curso

Código Nome Código Nome Carga

(0,n) horária
(1,1) (0,n)
n n Tipo
Curso Possui Disciplina

Modelagem2: uma disciplina pode ser obrigatória para um curso e optaSva para outro curso

Código Nome Tipo Código Nome Carga

horária
(0,n)
(1,1) (0,n)
n n
Curso Possui Disciplina

Banco de Dados FACOM | UFMS 67