Transcription
O Modelo ERBases de Dados (CC2005)Departamento de Ciência de ComputadoresFaculdade de Ciências da Universidade do PortoEduardo R. B. Marques — DCC/FCUP
Fonte: Geek and Poke, “Future-proof your data model”Bases de DadosO Modelo ER2
Modelação conceptual de BDsDe requisitos a modelo conceptual Tendo identificado os requisitos do universo de uma BDtorna-se útil a sua modelação conceptual.A modelação conceptual tem por propósito definir um modelopara a BD independente do tipo de base de dados e SGBDespecífico que depois se empregue na fase de implementação.Modelo Entidade-Relacionamento (ER)Modelo usado para desenho conceptual de uma BD,empregando os conceitos deentidades, atributos erelacionamentos.Tem associada uma sintaxe textual e também uma sintaxevisual na forma de diagramas.Bases de DadosO Modelo ER3
Conceitos do modelo EREntidadesObjetos ou conceitos do mundo real com uma existênciaindependente.ALUNO PESSOA CURSO CARRO EMPRESA FACULDADE PRODUTO AtributosPropriedades que caracterizam as entidades.Atributos exemplo para um ALUNO: NumMec Nome SexoDataNascRelacionamentosRepresentam ligações entre duas ou mais entidades.Relacionamento exemplo ESTUDA: um ALUNO estuda em umaFACULDADE.Bases de DadosO Modelo ER4
Entidades e atributosBases de DadosO Modelo ER5
Entidade-tipoEntidade-tipo: Modelo para um conjunto de entidades quepartilham a mesma estrutura, definido por um nome e umalista de atributos.ALUNO(NumMec, Nome, Sexo, DataNasc)Nome: ALUNOAtributos: NumMec, Nome, Sexo, DataNascEntidade-tipo modelando o universo de alunos com os seguintesatributos: nº mecanográfico, nome, sexo e data de nascimento.ConvençõesNOME em maiúsculas e singular.Atributos: PrimeiraLetraDeCadaPalavra maiúscula. Abreviaturas sãocomuns (como em NumCC ou DataNasc).Bases de DadosO Modelo ER6
EntidadeUma entidade é uma instância concreta do esquemamodelado por uma entidade-tipo.Para ALUNO(NumMec, Nome, Sexo, DataNasc) podemos terpor exemplo as seguintes entidades:ALUNO1(193942, ‘José Silva’, M, 17-11-2000)ALUNO2(212334, ‘Maria Carvalho’, F, 08-02-1976)ALUNO3(112345, ‘Rita Assunção’, F, 09-02-1987)ALUNO4(244556, ‘Rita Assunção’, F, 08-02-1987)Dois alunos podem ter o mesmo nome, sexo, e (ainda menosprovável mas possível) até a mesma data de nascimento O número mecanográfico - NumMec - identifica de formauma entidade ALUNO.Bases de DadosO Modelo ERúnica7
Atributo chaveAtributo chave: atributos que identifica de formaúnica cada entidade.ALUNO(NumMec, Nome, Sexo, DataNasc) tem apenas umatributo-chave: NumMec.A convenção sintáctica é que um atributo chaveapareça sublinhado.Supondo que um aluno era adicionalmentecaracterizado por um nº de cartão de cidadão NumCCentão teríamos dois atributos chave: ALUNO(NumMec,NumCC, Nome, Sexo, DataNasc).Bases de DadosO Modelo ER8
Entidades-tipo — diagrama ERALUNONumMecNomeSexoDataNascAlém da representação textual o modelo ER empregauma notação visual na forma de diagrama.Sintaxe visual:ENTIDADEBases de DadosAtributoChaveAtributonormalO Modelo ER9
Domínios de atributosO domínio de um atributo é o conjunto de valores queum atributo pode tomar.Dependendo do domínio em causa o valor de umatributo pode ser:Definido por valor concreto OU possivelmente indefinido seopcional para a entidade, designado nesse caso por NULL.Simples OU composto por vários sub-atributos.Derivado se derivado do valor de outros atributos ouinformação no modelo.De valor único OU multi-valor (conjunto de valores)Complexo se formado pela combinação de vários atributosmulti-valor e/ou compostos.Bases de DadosO Modelo ER10
Entidades-tipo — sintaxe adicionalSintaxe visualENTIDADEChaveSimplesComposto DerivadoMultivalorOpcional ? Sintaxe textualENTIDADE(Chave, Simples, Composto( Sub-atributos),{ Multivalor }, Opcional?, [Derivado])Bases de DadosO Modelo ER11
ExemploParaALUNO(NumMec, Nome, Sexo, DataNasc, [Idade],M o r a d a ( R u a , N u m , A n d a r ? , L o c a l i d a d e , C o d P o s t a l ) , { N u m Te l e f o n e } ,{Habilitação(Grau,Ano, Instituição)})Idade é um atributo derivado de DataNascMorada é um atributo composto por sub-atributos Rua, Num, Andar, Localidade,CodPostal. Numa modelação alternativa poderíamos também decompor DataNascem dia, mês e ano (usualmente datas são no entanto tratadas como valoressimples) ou Nome em nome principal e apelidos.Andar é um sub-atributo opcional de Morada.{NumTelefone} é multi-valor: considera-se que um aluno pode ter mais do queum nº de telefone (ex. nº telefone fixo, nº } é um atributo complexo, pois trata-se de umatributo multi-valor em que cada valor é por sua vez composto. Um aluno podeter várias habilitações académicas, cada uma caracterizado por um grau, ano einstituição.Bases de DadosO Modelo ER12
Exemplo dPostalLocalidade ChaveMulti-valorCompostoOpcional?Derivado Bases de DadosO Modelo ER13
Domínios de atributos (cont.)ParaAluno(NumMeC, Nome, Sexo, DataNasc, ), {NumTelefone},{Habilitação(Grau, Ano, Instituição)})podemos ter os seguintes exemplos de entidades (nota — assume-seque os valores de idades refletem uma BD à data de 1 Março de2019):ALUNO1(19428771, ‘José Silva’, M, 17-11-2000, [18], (‘Rua Fim do Mundo’, 783, ‘R/C’,‘Finisterra’, ’4444-555’), {987654321, 222333444}, { (‘Ens. Secundário’, 2017, ‘Escola Sec.Dr. Estranho-Amor’) } }ALUNO2(10447777, ‘Maria Carvalho’, F, 08-02-1976, [43], (‘Rua das Bases de Dados’, 1555,NULL, ’Vila Nova de Informática’, ‘4000-123’), {933933933}, { (‘Ens. Secundário’, 1994,‘Escola Sec. Vila Nova de Informática’), (‘Lic. Física’, 1998, ‘Fac. de Ciências Univ. Porto’)}Bases de DadosO Modelo ER14
Domínios de atributos (cont.)ALUNO1(19428771, ‘José Silva’, M, 17-11-2000, [18], (‘Rua Fim do Mundo’,783, ‘R/C’, ‘Finisterra’, ’4444-555’), {987654321, 222333444},{ (‘Ens. Secundário’, 2017, ‘Escola Sec. Dr. Estranho-Amor’) } }- sub-atributo Andar definido- mais do que um nº de telefone- uma só habilitação- sub-atributo Andar NULL- um só nº de telefone- mais do que uma habilitaçãoALUNO2(10447777, ‘Maria Carvalho’, F, 08-02-1976, [43], (‘Rua das Bases deDados’, 1555, NULL, ’Vila Nova de Informática’, ‘4000-123’), {933933933},{ (‘Ens. Secundário’, 1994, ‘Escola Sec. Vila Nova de Informática’),('Lic. Física’, 1998, ‘Fac. de Ciências Univ. Porto’)}Bases de DadosO Modelo ER15
RelacionamentosBases de DadosO Modelo ER16
Relacionamento — forma geralUm relacionamento exprime uma interação conceptual entreentidades.Forma geral:NOME(ENTIDADE-TIPO1, , ENTIDADE-TIPON, Atributo1, , Atributok)NOMEé o nome do relacionamento (ex. FILHO DE,TRABALHA PARA).ENTIDADE-TIPO1, , ENTIDADE-TIPONparticipantes.são as entidades-tipoN : grau do relacionamento (número de participantes)Um relacionamento pode (opcionalmente) ter tambémassociados atributos Atributo1, , AtributokBases de DadosO Modelo ER17
Relacionamentos — exemplo simplesNo universo (simplificado) de uma faculdade considerem-se as entidades-tipoALUNO(NumMec, Nome, Sexo, DataNasc, )CURSO(IdCurso, Nome, )DEPARTAMENTO(IdDep, Nome, )PROFESSOR(NumFunc, Nome, )que podem relacionar-se de várias formas, por ex. (entre várias outraspossíveis):RESPONSAVEL POR(DEPARTAMENTO, CURSO)DIRECTOR DE(PROFESSOR, DEPARTAMENTO)TRABALHA EM(PROFESSOR, DEPARTAMENTO)INSCRITO EM(ALUNO, CURSO, AnoInsc, AnoConcl?)Os relacionamentos acima dizem-se binários porque associam duasentidades (têm grau 2). INSCRITO EM tem também os atributos AnoInsc eAnoConcl? .Relacionamentos binários são normalmente suficientes para a modelação deuma BD, veremos depois exemplos de relacionamentos de grau superior a 2.Bases de DadosO Modelo ER18
Restrições de cardinalidadeABAR1:1BABRRN:1M:NA um relacionamento binário podemos ter associadasrestrições de cardinalidade:1:1 — um-para-um1:N N:1 — um-para-muitos, muitos-para-umM:N — muitos-para-muitosBases de DadosO Modelo ER19
Restrições de cardinalidade (cont.)ABR1:1ABABRRN:1M:NNos exemplos anteriores:DIRECTOR DE(PROFESSOR, DEPARTAMENTO) 1:1TRABALHA EM(PROFESSOR, DEPARTAMENTO) N:1RESPONSAVEL POR(DEPARTAMENTO, CURSO) M:NINSCRITO EM(ALUNO, CURSO, AnoInscrição, AnoConclusão?) M:N(obs.: um aluno pode fazer vários cursos: Lic. CC, Mestrado DS, )Bases de DadosO Modelo ER20
Restrições de participaçãoTotaltodasas entidadesde tipo AparticipamABRParcialnem todasas entidadesde tipo BparticipamA um relacionamento podemos ter tambémassociadas restrições de participação. Aparticipação é total para uma entidade-tipo se aexistência de uma entidade desse tipo obriga que aque participe no relacionamento, e parcial casocontrário.Bases de DadosO Modelo ER21
ExemplosPROFESSORDEPARTAMENTODIRECTOR DE1:1parcialSó algunsprofessoressão directoresde curso.Bases de DadostotalTodo odepartamentotem umdirector.O Modelo ER22
ExemplosDIRECTOR DE(PROFESSOR, DEPARTAMENTO) — parcial para PROFESSOR(nem todos os professores são directores de curso), total paraDEPARTAMENTO (todo o departamento tem um director).TRABALHA EM(PROFESSOR, DEPARTAMENTO) — total para as 2 entidadesassumindo que todo o professor está associado a um departamento eque um departamento tem necessariamente professores associados.RESPONSAVEL POR(DEPARTAMENTO, CURSO) — total para as 2 entidadesanalogamente ao caso anterior (assumindo de forma razoável quecada departamento é responsável por pelo menos um curso).INSCRITO EM(ALUNO, CURSO, AnoInscrição, AnoConclusão?) — total paraALUNO, parcial para CURSO assumindo que todo o alunos está inscritonum curso e que um curso pode (ainda) não ter tido alunos (ex.cursos novos).Bases de DadosO Modelo ER23
Relacionamentos — diagramas ERpossíveis atributosdo relacionamento A BRXYcardinalidadepara Acardinalidadepara Bparticipação totalBases de Dados participação parcialO Modelo ER24
Exemplos anteriores — diagrama ERPROFESSOR11DEPARTAMENTODIRECTOR DEN1TRABALHA EMAnoInscALUNOMRESPONSAVEL PORAnoConcl?MNINSCRITO EMNCURSONota: para um diagrama mais simples omitimos neste exemplo os atributos dasentidades-tipo.Bases de DadosO Modelo ER25
BD empresaBases de DadosO Modelo ER26
De requisitos a modelo ERA modelação de uma BD é o resultado da análise derequisitos para o universo em causa.Requisitos Modelo EROs requisitos devem ser identificados para o universo emcausa, de forma tão clara quanto possívelO modelo ER resulta da interpretação (correcta) dosrequisitos.Caso-de-estudo a seguir:BD para uma empresa, com algumas semelhanças ao exemploda faculdade que temos vindo a considerar.Adaptado de “Fundamentals of Database Systems, 7th ed”,capítulo 3.Bases de DadosO Modelo ER27
BD empresaConsideremos o universo de uma empresa em que temos as seguintesentidades-tipo, respectivos atributos e relacionamentos implícitos:FUNCIONÁRIO com os seguintes atributos: nº de CC, nome, email opcional, data denascimento, salário, horas semanais de dedicação a projectos, funcionáriosupervisor opcional, e departamento definido a que pertence.DEPARTAMENTO: com nome único, várias localizações possíveis associadas(moradas como anteriormente),um funcionário gestor, e um ou maisfuncionários que trabalham para o departamento. Um funcionário pode sergestor de apenas um departamento.PROJECTO: com nome único, data de início, data de conclusão, departamentodefinido que controla o projecto, e funcionário definido para director doprojecto. Poderão haver departamentos sem projectos associados.Um funcionário trabalha em um ou mais projectos, sendo necessárioidentificar o número de horas semanais que cada funcionário dedica a cadaprojecto. Um projecto tem sempre funcionários que trabalham nele (além dodirector).Bases de DadosO Modelo ER28
BD empresa — apenas entidades-tipo ?Podemos tentar exprimir o universo anterior usando apenasentidades-tipo (de forma lário,,HorasProj,Supervisor?, Departamento)D E P A R T A M E N T O ( N o m e , G e r e n t e ,{ } )PROJECTO(Nome, DataInício, DataFim, Departamento, Director,{ Trabalho(Funcionário, Horas) })Ao termos “referências” entre entidades, compreendemos quea modelação usando apenas entidade-tipos não é adequada.Devemos usar ao invés relacionamentos. Que relacionamentosestão implícitos?Bases de DadosO Modelo ER29
BD empresa — reformulaçãoReformulando, podemos ter como asc,Salário,[HorasProj])DEPARTAMENTO(Nome, })PROJECTO(Nome, DataInício, DataFim)e os seguintes relacionamentosSUPERVISIONA(FUNCIONÁRIO, FUNCIONÁRIO)TRABALHA PARA(FUNCIONÁRIO,DEPARTAMENTO)GERE(FUNCIONÁRIO, DEPARTAMENTO)CONTROLA(DEPARTAMENTO, PROJECTO)DIRIGE(FUNCIONÁRIO, PROJECTO)TRABALHA EM(FUNCIONÁRIO,PROJECTO, Horas)Bases de DadosO Modelo ER30
BD empresa — cardinalidade e ÁRIO, FUNCIONÁRIO)1 Nparcial parcialTRABALHA PARA(FUNCIONÁRIO,DEPARTAMENTO)N 1total totalGERE(FUNCIONÁRIO, DEPARTAMENTO)1 1parcial totalCONTROLA(DEPARTAMENTO, PROJECTO)1 Nparcial totalDIRIGE(FUNCIONÁRIO, PROJECTO)1 Nparcial totalTRABALHA EM(FUNCIONÁRIO,PROJECTO, Horas)M Ntotal totalBases de DadosO Modelo ER31
BD empresa — diagrama IO1DEPARTAMENTOTRABALHA ERVISIONANMNTRABALHA EMPROJECTOHorasBases de DadosNomeO Modelo ERDataInícioDataFim
Aspectos complementaresBases de DadosO Modelo ER33
Entidades-tipo fracasNET FRACAChaveParcialREL.IDENTIFICADOR1ET IDENTIFICADORA são assim chamadas as entidades-tipo sem chavedependência existencial: uma entidade fraca — instância de entidadetipo fraca — está necessariamente ligada a uma única instância deuma entidade-tipo identificadora, por meio de um relacionamentoidentificador N:1com participação total da entidade-tipo fraca(entidade-tipo identificadora pode ter participação total ou parcial).entidades fracas podem ter uma chave parcial, que permita distinguir asinstâncias da entidade-tipo fraca apenas no contexto da entidadeidentificadoraBases de DadosO Modelo ER34
Entidades-tipo fracas — exemplo caNDEPENDENTENomeParentescochave parcial1FUNCIONÁRIODEPENDE DESexoDataNascrelacionamentoidentificadorNo contexto da BD empresa poderíamos considerar a noção depessoa dependente (parte do núcleo familiar) de um funcionário.Nome é a chave parcial de DEPENDENTE: os dependentes de umfuncionário distinguem-se entre si pelo nome. Podem existirdependentes com o mesmo nome para funcionários distintos.Bases de DadosO Modelo ER35
Entitidades-tipo fracas (cont.)NomeN1DEPENDENTEFUNCIONÁRIODEPENDE DE1NCOBERTO POR1TEM PLANO1ApólicePLANO SAÚDETIpoEntidades-tipo fraca podem envolver-se em outrosrelacionamentos para além do relacionamento identificador.Bases de DadosO Modelo ER36
Relacionamentos de grau superior a 2Até agora vimos apenas relacionamentos de grau 2(binários), os mais comuns, o nosso foco durante o semestre.Fica no entanto a nota que podemos ter relacionamentos degrau superior.No exemplo de um empresa considere o fornecimento deprodutos no contexto de um projecto em que:estão envolvidas 3 entidades: o projecto, o produto fornecido, e ofornecedor dos produtoscada fornecimento é caracterizado por uma certa quantidade doproduto em causasuponha que o mesmo produto a um projecto pode ser fornecido porvários fornecedores diferentesBases de DadosO Modelo ER37
Relacionamentos de grau superior a 2 (cont.)Para o exemplo anterior, assumindo que temos então as entidade-tiposadicionais no modelo da empresa:PRODUTO(IdProduto, )FORNECEDOR(IdFornecedor, )podemos ter a relação ternária muitos-para-muitos-para-muitos:FORNECE(FORNECEDOR, PRODUTO, PROJECTO, CEPROJECTONomePPRODUTOBases de DadosNIdProdutoO Modelo ER38
Relacionamentos de grau superior a 2 (cont.)A modelação é mais simples se a BD tiver requisitos ligeiramentediferentes: 1) não for preciso expressar directamente o relacionamentoentre um fornecedor e um projecto e 2) as quantidades de um produtofornecidas por fornecedores e de produtos a projectos possam/devamser atributos representados de forma independente.FORNECE(FORNECEDOR, PRODUTO, Quant)USADO POR(PRODUTO, PROJECTO, Quant)MNMAIS SIMPLESDE ENTENDER!MNFORNECEDORFORNECEPRODUTOUSADO s de DadosO Modelo ER39
Relacionamentos de grau superior a 2 ROJECTO11F2NF11NNF3FORNECIMENTOQuantAlternativa (mais complicada): podemos modelar o equivalente aorelacionamento de grau 3 (ou superior) recorrendo a uma entidades-tipofraca para fornecimento com mais de uma entidade-tipo identificadora (noexemplo 3). Tecnicamente temos só relacionamentos binários, mas étambém uma solução de modelação algo complicada.Bases de DadosO Modelo ER40
Bases de Dados O Modelo ER De requisitos a modelo conceptual Tendo identificado os requisitos do universo de uma BD torna-se útil a sua modelação conceptual. A modelação conceptual tem por propósito definir um modelo para a BD independente do tipo de base de dados e SGBD específico que depois se empregue na fase de implementação. .
