Modelo Entidade-Relacionamento



Documentos relacionados
MC536 Bancos de Dados: Teoria e Prática

Modelo Entidade-Relacionamento

Projeto de Banco de Dados

Prof.: Clayton Maciel Costa

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc.

Ciclo de vida de um banco de dados relacional

Ciclo de Desenvolvimento de Sistemas de BD

Banco de Dados. Modelagem de Dados com MER. Prof. Walteno Martins Parreira Jr

GBC043 Sistemas de Banco de Dados Modelo de Entidade-Relacionamento (ER)

Modelagem dos dados. entendo. Reino Real. Reino. Representação

Descreve relacionamentos entre objetos de dados; conduz à modelagem de dados; atributos de cada objeto => Descrição de Objetos de Dados;

Bancos de Dados Aula #3 MER Estendido

Funcionários. Funcionários. PrimeiroNome NomesDoMeio ÚltimoNome. CPF Nome Salário. CPF PrimeiroNome NomesDoMeio ÚltimoNome Salário

O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados.

BANCO DE DADOS I AULA 3. Willamys Araújo

ENGENHARIA DA COMPUTAÇÃO

Construir um modelo de dados é: - Identificar, Analisar e Registar a política da organização acerca dos dados

Disciplina: Unidade II: Prof.: Período:

Banco de Dados. MER Estendido. Profa. Flávia Cristina Bernardini

Bases de Dados. Parte II: Os Modelos ER e EER

Modelagem de Dados Usando o Modelo Entidade-Relacionamento

Banco de Dados 1 2º Semestre

BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER )

MODELO ENTIDADE - RELACIONAMENTO

Desenho e Modelação de Esquemas de Bases de Dados

Banco de Dados - Senado

Modelagem de dados usando o modelo BANCO DE DADOS 1º TRIMESTRE PROF. PATRÍCIA LUCAS

Propriedades de entidades

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Aula II Introdução ao Modelo de Entidade-Relacionamento

Bases de Dados. Parte III: O Modelo Relacional

Diagrama de transição de Estados (DTE)

Bases de Dados. Parte II: Os Modelos ER e EER

Curso Superior de Tecnologia em BD

Administração de Bancos de Dados

Modelagem de Dados Usando o Modelo Entidade-Relacionamento

Profa. Daniela Barreiro Claro

Lista de exercícios 01

Fernando Fonseca Ana Carolina

Atributos. Exercício (4.1) Angélica Toffano Seidel Calazans Abordagem Entidade-Relacionamento

Conjunto de objetos da realidade modelada sobre os quais deseja-se. dados.

Roteiro 3 Modelagem relacional

Computadores e Sistemas de Informação. Bases de Dados Relacionais (linguagem SQL)


Modelo de Entidade e Relacionamento (MER) - Parte 07

Processo de Projeto Bottom-Up. esquema conceitual do BD. engenharia reversa do esquema relacional. esquema relacional integrado do BD (esquema global)

Processo de Projeto Bottom-Up. esquema conceitual do BD. engenharia reversa do esquema relacional. esquema relacional integrado do BD (esquema global)

Banco de Dados I. Projeto de Banco de Dados e o Modelo E-R Parte 2. Fabricio Breve

Depois de obtido o diagrama E/A há que estabelecer o esquema relacional correspondente.

Generalização e Especialização Banco de Dados

III. Projeto Conceitual de Banco de Dados. Pg. 1 Parte III (Projeto Conceitual de Banco de Dados)

MIG - Metadados para Informação Geográfica

Modelo Relacional. 2. Modelo Relacional (Lógico)

I Requisitos de um modelo conceitual: - clareza (facilidade de compreensão) - exatidão (formal)

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br. Aula 3. Prof. Rafael Dias Ribeiro.

UML Aspectos de projetos em Diagramas de classes

Prof.: Clayton Maciel Costa

Banco de Dados I. Prof. Bal. Emerson Meneses Inocente

Aula 3 SBD Modelo Entidade Relacionamento Parte 1. Profa. Elaine Faria UFU

DEMONSTRAÇÕES FINANCEIRAS COMBINADAS

Herança. Herança. Especialização. Especialização

Polimorfismo. Prof. Leonardo Barreto Campos 1

EXERCÍCIOS SOBRE ORIENTAÇÃO A OBJETOS

UML (Unified Modelling Language) Diagrama de Classes

Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes

Prof. Alexandre Unterstell Banco de Dados I

Sumário. Uma visão mais clara da UML

Projeto Conceitual (geralmente no modelo E-R):

Modelo Entidade - Relacionamento (ER ou MER) Parte 2

MODELO DE DADOS. É uma imagem gráfica de toda a base de informações necessárias para um determinado empreendimento.

Curso de Gestão em SI MODELAGEM DE DADOS. Rodrigo da Silva Gomes. (Extraído do material do prof. Ronaldo Melo - UFSC)

Curso Superior de Tecnologia em BD Curso Superior de Tecnologia em DAI

Faculdade Lourenço Filho - ENADE

4.2. UML Diagramas de classes

O modelo Entidade-Relacionamento. Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento

EXERCÍCIOS EXERCÍCIOS. Definições Básicas. Definições Básicas. Definições Básicas. Introdução à Estatística. Dados: valores de variáveis observadas.

Conceitos Básicos de Banco de Dados

Sistemas de Informação

MODELAGEM DE DADOS. Unidade II Arquiteturas do SGBD

Modelagem de Dados com UML. Modelagem de Dados com UML. Modelagem de Dados com UML. Modelagem de Dados com UML. ! Generalização/Especialização

Serviço a Pedido ( On Demand ) da CA - Termos e Política de Manutenção Em vigor a partir de 1 de Setembro de 2010

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Análise e Projeto de Sistemas

Ferramentas Estruturadas de Análise. Dicionário de Dados Diagramas Entidade-Relacionamento. Resumo. Elementos da Análise Estruturada

Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr.

IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1

Tecnologias e Linguagens para Banco de Dados I

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO As Normas da família ISO 9000

Tarefa Orientada 16 Vistas

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Engenharia de Software III

EXERÍCIOS DE MODELAGEM DE BANCO DE DADOS

Persistência e Banco de Dados em Jogos Digitais

Capítulo 11. Conceitos de Orientação a Objetos. Rui Rossi dos Santos Programação de Computadores em Java Editora NovaTerra

Trabalhos Práticos. Programação II Curso: Engª Electrotécnica - Electrónica e Computadores

Transcrição:

Modelo Entidade-Relacionamento ome Designação Doc... #Disc... Docente Ensina Disciplina Abordagem proposta por Peter P. Chen (década de 70) para o processo de modelação de dados com ampla aceitação; Trabalho publicado é considerado um referencial definitivo; A proposta inicial mantém-se actualizada e tem evoluído pela agregação de novos elementos; Abordagem composta por técnica de diagramação e um conjunto de conceitos. Conceitos da abordagem E-R Conceito Instância Entidade Atributo Relacionamento Descrição Individualização de objecto ou conceito; Conjunto formado pela agregação de objectos ou conceitos semelhantes; Abstracção de objectos ou conceitos do mundo real acerca dos quais queremos guardar informação; Características próprias das instâncias dos conjuntos; Envolvimento ou associação entre as instâncias dos conjuntos. 2.2-TM Dados Modelação conceptual de dados 1

Relacionamento As entidades não estão isoladas, sendo necessário identificar relacionamentos para representar correctamente o ambiente observado. Principais elementos de caracterização de um relacionamento: Semântica do relacionamento; Grau ou cardinalidade do relacionamento; Condições de participação das entidades no relacionamento; úmero de entidades que participam no relacionamento (binário ou n-ário); Semântica do relacionamento Especificada através de uma denominação (construção verbal) representativa do conceito observado, que deve ser lida da esquerda p/ direita e de cima p/ baixo. Grau ou cardinalidade do relacionamento O número de ocorrências de uma entidade, que podem estar associadas a uma ocorrência de outra entidade num relacionamento, permitem distinguir 3 tipos de relacionamentos: Grau 1:1 Cédula_nascimento 1 Emitida 1 Pessoa Grau 1: Departamento 1 Constituído Funcionário Grau :M Funcionário Trabalha M Projecto 2.2-TM Dados Modelação conceptual de dados 2

Condições de participação das entidades no relacionamento Conceito de participação obrigatória - Uma entidade é de participação obrigatória num relacionamento, se todas as instâncias dessa entidade estão relacionadas com pelo menos uma instância da outra entidade. alguns casos a participação no relacionamento será obrigatória e para outros será opcional depende das particularidades do ambiente observado e das regras estabelecidas; Este conceito contribui para o enriquecimento do MD, evitando ambiguidade. Exemplo 1 Todas as disciplinas têm de ser asseguradas, sendo leccionadas por um ou mais docentes; Os docentes podem estar dispensados de serviço docente ou podem leccionar várias disciplinas. ome Designação Doc... #Disc... Docente Ensina M Disciplina Exemplo 2 Algumas disciplinas não são leccionadas pelo facto de terem sido retiradas do plano de estudos; Todos os docentes leccionam, pelo menos uma disciplina. ome Designação Doc... #Disc... Docente Ensina M Disciplina 2.2-TM Dados Modelação conceptual de dados 3

úmero de entidades que participam no relacionamento Um relacionamento pode envolver mais do que 2 entidades; As associações binárias entre as entidades podem não mapear de forma correcta a informação desejada. Exemplo de relacionamento ternário: Os funcionários de uma empresa de prestação de serviços podem ser alocados a diferentes projectos e exercer funções distintas. Funcionário Projecto Função P. Costa P1 Analista de Sistemas P. Costa P2 Consultor X. Lima P2 Analista de Sistemas X. Lima P3 Programador Relacionamentos binários múltiplos Função Utilizada M Projecto Envolve M Funcionário Desempenha M Func. Proj. Proj. Função Func. Função P. Costa P1 P1 Analista de Sist. P.Costa Analista de Sist. P. Costa P2 P2 Analista de Sist. P.Costa Consultor X. Lima P2 P2 Consultor X. Lima Analista de Sist. X. Lima P3 P3 Programador X. Lima Programador 2.2-TM Dados Modelação conceptual de dados 4

Quem é o Analista de Sistemas do projecto P2? A estrutura necessária para a derivação de um relacionamento ternário (ou n- ário) é uma agregação; A agregação é requerida para expressar a função de um funcionário em determinado projecto. É necessário ter as 3 entidades associadas simultaneamente, através de um relacionamento ternário. Relacionamento Ternário Funcionário M Função Alocação P Projecto Agregação resultante Funcionário Projecto Função P. Costa P1 Analista de Sistemas P. Costa P2 Consultor X. Lima P2 Analista de Sistemas X. Lima P3 Programador 2.2-TM Dados Modelação conceptual de dados 5

Relacionamentos Recursivos Caso especial de um relacionamento que ocorre entre instâncias de um mesmo tipo de objecto. ome Morada BI Salário 1 Empregado Supervisa Relacionamentos com atributos Atributos a preservar que não pertencem aos objectos observados, mas sim à associação desse objectos; Estes atributos denotam a existência de informação que só pode ser estabelecida ou considerada quando na presença de um relacionamento entre entidades; estas circunstancias os atributos devem ser representados no relacionamento. BI ome Morada Data_nascimento Departamento Carga_horária ome_curso Aluno M Frequenta Curso Data_inscrição Média 2.2-TM Dados Modelação conceptual de dados 6

Considerações sobre entidades Fortes e Fracas A classificação de entidades como fortes ou fracas depende da ocorrência de uma dependência de existência ou de identificação entre entidades. Dependência de Existência - Denota o estabelecimento de um vínculo de existência entre entidades. Dívida 1 É paga Refere-se Prestação de pagamento Uma prestação de pagamento só possui existência quando existe uma dívida. Dependência de identificação - Denota que uma entidade não possui os atributos requeridos para identificar (distinguir) as suas instâncias. Contribuinte 1 Entrega é entregue por Declaração de imposto Uma declaração de imposto (com atributos ano_exercício, ano_base,...) é uma entidade fraca, que depende da entidade contribuinte (entidade identificadora), pois não possui atributos identificadores próprios; Considerando que a entidade possui um atributo º sequencial da declaração, passaria a ser considerada entidade forte. Critério com importância reconhecida sob o ponto de vista do projecto lógico, mas dispensável e subjectivo ao nível do projecto conceptual; o entanto, permite representar entidades que não se pretende dotar com identificação independente. 2.2-TM Dados Modelação conceptual de dados 7

Tipos de atributos Próprio Apelido Localizações Tempo_Actividade BI ome Sexo úmero Data_ínicio_activ Funcionário Departamento Atributos Simples (Exemplo: BI) Atributos Compostos (Exemplo: ome) - Um atributo composto pode ser considerado simples, dependendo da situação a tratar; - Quando os atributos básicos são tratados separadamente, um atributo composto entra na entidade com todos os seus atributos básicos (Funcionário: BI, próprio, Apelido, Sexo). Atributos Derivados (Exemplo: Tempo_actividade) - Estes atributos devem ser identificados na análise e podem ser representados no modelo conceptual de dados, mas não devem fazer parte da entidade pois podem ser calculados. Atributos Multivalor (Exemplo: Localizações) - Estes atributos possuem múltiplos valores e são representados no DER com traço duplo. 2.2-TM Dados Modelação conceptual de dados 8

Que atributos considerar na descrição de uma entidade? Entidades CÃO e DOO_DO CÃO vistas pelo veterinário: CÃO nome_do_cão raça sexo nome_do_dono data_nasc peso DOO_DO_CÃO nome_do_dono endereço saldo_da_conta Entidades CÃO e DOO_DO CÃO vistas pela administração municipal: CÃO nome_do_cão raça nome_do_dono data_licen. peso DOO_DO_CÃO nome_do_dono endereço O atributo endereço deveria ser subdividido? É possível determinar o número de cães por freguesia? endereço é um atributo composto que neste caso deveria ser subdividido. 2.2-TM Dados Modelação conceptual de dados 9

Extensões ao modelo Entidade-Relacionamento O modelo E-R tem evoluído pela agregação de novos elementos que tornam a técnica mais rica em semântica e alargam o âmbito da sua aplicação. Justificação da necessidade de extensão do modelo E-R O principal objectivo do processo de abstracção e identificação de entidades é reconhecer agrupamentos distintos entre conjuntos de objectos relevantes. o entanto, existem dificuldades neste processo. Principais dificuldades na definição de entidades: em sempre a separação de instâncias desses objectos se dará por conjuntos estritamente distintos. Como proceder no caso da identificação de subconjuntos distintos dentro de conjuntos únicos? Existem relacionamentos que só se aplicam a um subconjunto das instâncias de uma entidade e não a todas. Como proceder para estabelecer relacionamentos para subconjuntos de instâncias que não possuem sentido para as outras? 2.2-TM Dados Modelação conceptual de dados 10

Exemplo: Empresa de montagem de peças de automóvel com dois tipos de empregados: supervisores (assalariados) e montadores (pagos à hora). Corresponde ao que é designado por representação de papéis. Supervisor 1 Supervisa Montador Lista de atributos: contrib ome Telef_casa Morada Telef_trab Pagam_hora Salário #Taref Área º de contribuinte do empregado ome do empregado º de Telefone da casa do empregado Morada do empregado º de telefone do local de trabalho do supervisor Pagamento horário do montador Salário do supervisor Código de tarefa do montador Área de competência do supervisor Outros relacionamentos a estabelecer: Falta Refere-se 1 Empregado Montador Trabalha 1 Tipo_peça 2.2-TM Dados Modelação conceptual de dados 11

Questões: Utilização de duas entidades Supervisor 1 Supervisa Montador - Para efectuar uma pesquisa a um empregado é necessário saber, previamente, se este é montador ou supervisor (D); - O relacionamento com o subconjunto de instâncias montador pode ser estabelecido adequadamente (V); - O problema do relacionamento com o conjunto global de instâncias não é resolvido (D). Utilização de uma só entidade agregadora Empregado - A simples agregação destas entidades obrigaria à inserção de valores nulos em alguns atributos, pois existem atributos que não se aplicam a todas as instâncias (D); - O relacionamento com o subconjunto montador não pode ser estabelecido correctamente (D); - O relacionamento com o conjunto global pode ser estabelecido adequadamente (V). 2.2-TM Dados Modelação conceptual de dados 12

Utilização de três entidades Empregado 1 1 Pode ser Pode ser 1 1 1 Supervisor Supervisa Montador - Resolve problemas do relacionamentos com os subconjuntos e conjunto global (V V); - Contudo, é uma solução limitada na representação de factos observados (D). Limitações na representação de papéis Como representar as seguintes situações alternativas: Todos os empregados são obrigatoriamente supervisores ou montadores; Um empregado pode ser simultaneamente supervisor e montador. O modelo E-R sem extensões não reflecte estes factos. Preocupações subjacentes: Fidelidade do modelo conceptual de dados; Adequação de futuras estruturas de dados a serem implementadas. 2.2-TM Dados Modelação conceptual de dados 13

Hierarquia de Especialização/Generalização, Superclasses e Subclasses As hierarquias de Generalização/Especialização (E/G) procuram representar os seguintes factos: Dado um conjunto de instâncias pertencentes a subconjuntos de um conjunto maior, cada um deles deve ser capaz de ser visto como um elemento tanto pertencente aos subconjuntos distintos como ao conjunto completo. As características (atributos e relacionamentos) que sejam comuns a todas as instâncias devem ser alocadas numa entidade generalizadora e são herdadas pelos subconjuntos; As características que sejam específicas de um subconjunto devem ser alocadas a este. Representação de hierarquias de Especialização/Generalização Superclasse Empregado Subclasses Supervisor Montador Superclasse entidade generalizadora definida Subclasses subconjuntos específicos de uma superclasse 2.2-TM Dados Modelação conceptual de dados 14

Especialização Representação dos subconjuntos; Processo de definição de Subclasses com características distintas. Exemplo: Parte da entidade Empregado e define as subclasses Montador e Supervisor, bem como a superclasse Empregado. Generalização Representação do conjunto global; Processo de análise inverso da especialização, que define uma Superclasse com características comuns. Exemplo: Parte das entidades Supervisor e Montador e define a superclasse Empregado e as subclasses Montador e Supervisor. Solução resultante Empregado 1 Possui Falta Especialização Supervisor Montador Trabalha 1 Tipo_peça 1 Supervisa Considerações: Há um relacionamento entre uma superclasse e as suas subclasses; A especialização deve ser considerada como uma entidade que se subdivide em duas (ou mais) outras e não como várias entidades diferentes; Os relacionamentos podem ser estabelecidos directamente e normalmente com a superclasse e subclasses. 2.2-TM Dados Modelação conceptual de dados 15

Tipos de Especializações/Generalizações Existem dois tipos de especializações/generalizações: E/G mutuamente exclusiva (disjunção) Uma instância do conjunto global que pertence a uma subclasse não poderá pertencer simultaneamente a outra. Exemplo: Cada empregado é supervisor ou montador; Disjunção Supervisor Empregado d Montador E/G não mutuamente exclusiva (sobreposição) Uma instância do conjunto global pode pertencer a um ou mais subconjuntos simultaneamente. Exemplo: Um empregado pode ser simultaneamente supervisor e montador. Sobreposição Supervisor Empregado o Montador 2.2-TM Dados Modelação conceptual de dados 16

íveis de especialização As hierarquias podem possuir vários níveis de agrupamento, do mesmo ou de diferentes tipos de E/G. Exemplo: Aluno (BI, Sexo, Morada, ome, Data_ingresso, _aluno) Docente (BI, Sexo, Morada, ome, Data_admissão, _funcionário, Departamento, Gabinete) Funcionário_não_docente (BI, Sexo, Morada, ome, Data_admissão, _funcionário, função, horário) Aspectos a ter em conta neste exemplo: Uma pessoa pode ser simultaneamente funcionário e aluno (Sobreposição); Um funcionário ou é docente ou não docente (Disjunção). Pessoa BI ome Sexo Morada Sobreposta O _funcionário Data_admissão Funcionário Aluno Data_ingresso _aluno Disjunta d Função Horário ão docente Docente Departamento Gabinete 2.2-TM Dados Modelação conceptual de dados 17

Abrangência das subclasses As subclasses devem subdividir todas as instâncias do conjunto global. Como proceder se só é necessário explicitar características de alguns tipos de subconjuntos? Representar somente esses tipos de subclasses Induz uma interpretação errada de que só existem esses tipos de subclasses; Representação de todas as subclasses Gera uma representação correcta, mas que pode ser extensa e não apropriada se surgirem novas subclasses (nomeadamente, outras que também não interessa detalhar); Solução Uso de artifício para manter a semântica do modelo correcta e que evita individualizações de subconjuntos que não interessa detalhar. Criação de especialização representativa de todas as especialidades que não interessa representar, que recebe o nome de Outras. Exemplo: Supondo que existem outros tipos de empregados, para além dos montadores e supervisores. Empregado Supervisor Outros_empregados Montador 2.2-TM Dados Modelação conceptual de dados 18

Malha de especialização/generalização, subclasse partilhada e herança múltipla Hierarquia de E/G: cada subclasse participa num só relacionamento superclasse/subclasse; cada subclasse possui uma só superclasse. Malha de E/G: Uma subclasse pode participar em mais do que um relacionamento superclasse/subclasse => Subclasse partilhada - subclasse que possui várias superclasses; Herança múltipla - a subclasse partilhada herda todas as características das suas superclasses. Exemplo: Um aluno pode ser assistente Pessoa BI ome Sexo Morada O _funcionário Data_admissão Funcionário Aluno Data_ingresso _aluno d Subclasse partilhada d ão docente Docente Aluno_assistente Aluno_n_assistente Função Horário Gabinete Departamento percentagem_horas... 2.2-TM Dados Modelação conceptual de dados 19

Categorias e herança selectiva as hierarquias e malhas de E/G uma superclasse e as suas subclasses representam a mesma entidade do mundo real. As categorias têm origem na necessidade de modelar relacionamentos superclasse/subclasse com várias subclasses que representam entidades distintas. A subclasse é denominada categoria. Características que distinguem as categorias: Malha de E/G Categorias Existe sempre uma superclasse única Existem várias superclasses que (no topo); representam entidades distintas; Um membro de uma subclasse partilhada tem de existir em todas as superclasses; Um membro da categoria tem de existir, pelo menos, numa das superclasses (usualmente uma), mas não tem de ser membro de todas; Uma subclasses partilhada é um subconjunto da intersecção das suas superclasses; Uma categoria é um subconjunto da união das suas superclasses; A herança é múltipla: Uma subclasse partilhada herda todas as características das suas superclasses. A herança é selectiva: A herança de características numa categoria não é total, dependendo da superclasse a que a instância pertence. 2.2-TM Dados Modelação conceptual de dados 20

Exemplo: Modelo de dados para o registo de veículos (carros e camiões). O proprietário de um veículo pode ser uma pessoa, uma empresa ou um banco. É necessário criar: uma entidade que inclua objectos de três tipos para registar informação relativa a proprietários de veículos; uma entidade que inclua objectos de dois tipos para manter os veículos registados. Morada _pessoa _banco ome_b Endereço_b _empresa Endereço_a BI Pessoa Banco Empresa ome IF U IF ome_e União Proprietário M Possui Veículo_registado Data_compra _registo Distrito Id_veículo U Id_veículo... Carro Camião Capacidade Ano... Dimensões Categorias: proprietário e veículo_registado 2.2-TM Dados Modelação conceptual de dados 21