Modelagem de Dados Aula 4. 2 Implementação de Entidades Não é aconselhável simplesmente transcrever os nomes dos atributos para nomes de colunas. Nomes.

Apresentação em tema: "Modelagem de Dados Aula 4. 2 Implementação de Entidades Não é aconselhável simplesmente transcrever os nomes dos atributos para nomes de colunas. Nomes."— Transcrição da apresentação:

1 Modelagem de Dados Aula 4

2 2 Implementação de Entidades Não é aconselhável simplesmente transcrever os nomes dos atributos para nomes de colunas. Nomes de coluna serão referenciados freqüentemente em programas e outras formas de texto em computador é conveniente manter os nomes de colunas curtos. Além disso, devemos evitar espaços em branco e acentos. E as abreviaturas devem ser padronizadas. código  nome  endereço  data de nascimento PESSOA Modelo ER Pessoa (CodigoPess,Nome,Endereço,DataNasc) Modelo Relacional

3 3 Implementação de Entidades SÓCIO possuir DEPENDENTE (0,n)(1,1) código  nome número seqüência  nome Modelo ER Socio (CodigoSoc,Nome) Dependente (CodigoSoc,NumSeq,Nome) Modelo Relacional

4 4 Implementação de Relacionamentos ENGENHEIRO atuação PROJETO (0,n) código  nome código  título  função Modelo ER Engenheiro (CodEng,Nome) Projeto (CodProj,Titulo) Atuação (CodEng,CodProj,Funcao) CodEng referencia Engenheiro CodProj referencia Projeto Modelo Relacional

5 5 Implementação de Relacionamentos Departamento (CodDept,Nome) Empregado (CodProj,Nome,DataLota,CodDept) CodDept referencia Departamento Modelo Relacional DEPARTAMENTO lotação EMPREGADO (0,n)(0,1) código  nome código  nome  data lotação Modelo ER

6 6 Implementação de Relacionamentos CONFERÊNCIA organização COMISSÃO (1,1) código  nome  endereço  data instalação Modelo ER Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg) Modelo Relacional

7 7 Implementação de Relacionamentos PRODUTO código  nome (0,n) CIDADE código  nome DISTRIBUIDOR código  nome distribuição  data de início Modelo ER (0,1) Produto (CodProd,Nome) Cidade (CodCid,Nome) Distribuidor (CodDistr,Nome) Distribuição (CodProd,CodCid,CodDistr,DataIni) CodProd referencia Produto CodDistr referencia Distribuidor CodCid referencia Cidade Modelo Relacional

8 8 Implementação de Relacionamentos não usar alternativa ideal(1,n) não usar alternativa ideal(0,n) (1,n) não usar alternativa ideal(0,n) Relacionamentos n:n não usaralternativa idealnão usar(1,1) (1,n) não usaralternativa idealnão usar(1,1) (0,n) não usaralternativa idealpode ser usada(0,1) (1,n) não usaralternativa idealpode ser usada(0,1) (0,n) Relacionamentos 1:n alternativa idealnão usar (1,1) alternativa idealpode ser usadanão usar(0,1) (1,1) não usaralternativa idealpode ser usada(0,1) Relacionamentos 1:1 Fusão TabelasAdição de colunaTabela Própria Regras de Implementação Tipo de Relacionamento Regras de Implementação

9 9 Implementação Gen / Especialização DEPARTAMENTO lotação EMPREGADO (0,n)(1,1) código  nome código  nome  tipo de empregado  CPF Modelo ER SECRETÁRIAMOTORISTAENGENHEIRO PROCESSSADOR DE TEXTO RAMO DE ENGENHARIA PROJETO domínio pertence participação código  nome código  nome código  nome  carteira habilitação  CREA (1,n) (0,n) (1,1) (0,n)

10 10 Implementação Gen / Especialização Departamento (CodDept,Nome) ProcessTexto (CodProc,Nome) Projeto (CodProj,Nome) Ramo (CodRamo,Nome) Empregado (CodEmp,Nome Tipo,CPF,CodDept,CartHabil,CREA,CodRamo) CodDept referencia Departamento CodRamo referencia Ramo Domínio (CodEmp,CodProc) CodEmp referencia Empregado CodProc referencia ProcessTexto Participação (CodEmp,CodProj) CodEmp referencia Empregado CodProj referencia Projeto Modelo Relacional Opção 1

11 11 Implementação Gen / Especialização Departamento (CodDept,Nome) ProcessTexto (CodProc,Nome) Projeto (CodProj,Nome) Ramo (CodRamo,Nome) Empregado (CodEmp,Nome Tipo,CPF,CodDept) CodDept referencia Departamento Motorista (CodEmp,CartHabil) CodEmp referencia Empregado Engenheiro (CodEmp,CREA,CodRamo) CodEmp referencia Empregado CodRamo referencia Ramo Domínio (CodEmp,CodProc) CodEmp referencia Empregado CodProc referencia ProcessTexto Participação (CodEmp,CodProj) CodEmp referencia Empregado CodProj referencia Projeto Modelo Relacional Opção 2

12 12 Refinamento do Modelo Relacional Em todo o processo de engenharia, está envolvido um compromisso entre o ideal e o realizável dentro das restrições de recursos impostas pela prática. No processo de engenharia de banco de dados, particularmente na implementação de modelos conceituais, às vezes também é necessário traçar um compromisso entre o ideal, representado pelas regras de implementação apresentadas, e o alcançável frente as limitações de performance. Algumas vezes, o esquema de BD criado através do uso das regras acima não atende plenamente os requisitos de performance impostos ao sistema. Neste caso, é necessário buscar uma alternativa de implementação que resulte em melhor performance do sistema.

13 13 Refinamento do Modelo Relacional Cabe, salientar, que estas alternativas somente deveriam ser tentadas em último caso, pois, do ponto de vista do desenvolvimento de programas sobre o banco de dados, são sempre piores que as alternativas que haviam sido apresentadas anteriormente. Engenharia Reversa de Modelo Relacional De forma geral, um processo de engenharia reversa pode ser definido como um processo de abstração, que parte de um modelo de implementação e resulta num modelo conceitual que descreve abstratamente a implementação em questão.

14 14 Engenharia Reversa de Modelo Relacional Na engenharia reversa de modelos relacionais, tem- se, como ponto de partida, um modelo lógico de um banco de dados relacional e, como resultado, um modelo conceitual, neste caso a abordagem ER. Este é o processo inverso ao do projeto lógico. A engenharia reversa de modelos relacionais pode ser útil quando não se tem um modelo conceitual para um banco de dados existente. Isso pode acontecer quando o banco de dados foi desenvolvida de forma empírica, sem o uso de uma metodologia de desenvolvimento, ou quando o esquema do banco de dados sofreu modificações ao longo do tempo, sem que as mesmas tenham sido registradas no modelo conceitual.

15 15 O processo de engenharia reversa de um modelo relacional consta dos seguintes passos: 1. Identificação de construção ER correspondente a cada tabela; 2. Definição de relacionamentos 1:n e 1:1; 3. Definição de atributos; 4. Definição de identificadores de entidades e relacionamentos. Na primeira etapa da engenharia reversa de um banco de dados relacional, define-se, para cada tabela do modelo relacional qual a construção que lhe corresponde a nível de modelo ER. Uma tabela pode corresponder a: uma entidade, um relacionamento n:n ou uma entidade especializada. Identificação de cada Tabela Engenharia Reversa de Modelo Relacional

16 16 O fator determinante da construção ER que corresponde a uma tabela é a composição de sua chave primária. A tabela que possui uma chave primária composta de múltiplas chaves primárias implementa um relacionamento n:n entre as as entidades correspondentes às tabelas referenciadas pelas chaves estrangeiras. A tabela cuja chave primária é toda ela uma chave estrangeira representa uma entidade que forma uma especialização da entidade correspondente à tabela referenciada pela chave estrangeira. Quando a chave primária da tabela não for composta de múltiplas chaves primárias, nem for toda uma chave estrangeira, a tabela representa uma entidade. Identificação de cada Tabela

17 17 Toda chave estrangeira que não corresponde a um relacionamento n:n, nem uma entidade relacionada representa um relacionamento 1:n ou 1:1. A regra não permite definir-se a cardinalidade do relacionamento é 1:n ou 1:1. Para definir qual dos dois tipos de relacionamentos está sendo representado pela chave estrangeira, é necessário verificar os possíveis conteúdos do banco de dados. Definição de Relacionamentos 1:1ou1:n Definição de Atributos Para cada coluna de uma tabela, que não seja chave estrangeira, é definido um atributo na entidade/relacionamento correspondente à tabela. Observe-se que colunas chave estrangeiras não correspondem a atributos no diagrama ER, mas sim relacionamentos, e por isso já forma tratadas nas etapas anteriores.

18 18 Definição de Identificadores No último passo da engenharia reversa, são definidos os identificadores das entidades e dos relacionamentos. A regra para definição dos identificadores é a seguinte:  toda coluna que faz parte da chave primária e que não é chave estrangeira corresponde a um atributo identificador da entidade ou relacionamento.  toda coluna que faz parte da chave primária e que é chave estrangeira corresponde a um identificador externo da entidade. O processo de engenharia reversa será exemplificado sobre um sistema acadêmico.

19 19 Sistema Acadêmico Disciplina (CodDisc,NomeDisc) Curso (CodCr,NomeCr) Curric(CodCR,CodDisc,Obr/Opc) CodCr referencia Curso CodDisc referencia Disciplina Sala (CodPr,CodSl,Capacidade) CodPr referencia Prédio Prédio (CodPr,Endereço) Turma (Anosem,CodDisc,SiglaTur,CodPr,CodSl,Capacidade) CodDisc referencia Disciplina (CodPr,CodSL) referencia Sala Laboratório (CodPr,CodSl, Equipam) (CodPr,CodSL) referencia Sala Modelo Relacional

20 20 Sistema Acadêmico código  endereço Modelo ER (1,1) SALA código  capacidade código  nome DISCIPLINA código  nome CURSO currículo (1,n)  obr/opc (1,n) PRÉDIO LABORATÓRIO  equipamento TURMA ano semestre sigla  capacidade pertence (1,n) localização (1,n)(1,1) localização (1,1) (1,n)