Construindo modelos ER. Capítulo 3

Transcrição

1 Construindo modelos ER Capítulo 3

2 Construindo modelos ER - Temário 1. Conselhos práticos 2. Heurísticas 3. Notações alternativas 4. Processo de modelagem e alternativas 2

3 Propriedades de modelos ER Modelo ER é um modelo formal Poder de expressão é limitado Equivalência entre modelos 3

4 Modelo ER é um modelo formal Modelo preciso, não ambíguo. Diferentes leitores de um mesmo modelo ER devem sempre entender exatamente o mesmo. DER pode ser usado como entrada a uma ferramenta CASE. Fundamental: todos os envolvidos devem estar treinados na sua perfeita compreensão. Risco: sub-utilização. 4

5 Poder de expressão limitado Modelo ER apresenta apenas algumas propriedades de um banco de dados: Foi concebido para o projeto da estrutura de um BD relacional. Poder de expressão limitado para expressar restrições de integridade genéricas (regras de negócio). 5

6 Poder de expressão limitado - exemplo p1 p3 p7 PESSOA p2 p4 p6 p5 p8 1 1 e marido esposa m m e m m e e CASAMENTO p1,p3 p5,p5 p3,p6 p6,p8 6

7 Poder de expressão limitado - exemplo e1 e2 e3 e6 e4 e7 e5 e8 supervisor supervisionado 1 n supervisor supervisor supervisionado supervisionado supervisor SUPERVISÃO e1,e2 e3,e4 supervisionado e1,e3 e3,e5 e5,e1 7

8 Eqüivalência entre modelos Dois modelos ER diferentes podem ser equivalentes. Modelos equivalentes: expressam o mesmo, modelam a mesma realidade. Para fins de projeto de BD, dois modelos ER são equivalentes quando: geram o mesmo esquema de BD. Considerar um conjunto de regras de tradução de modelos ER para modelos lógicos de BD. 8

9 Exemplo de eqüivalência entre modelos a) CONSULTA como relacionamento n:n (1,n) MÉDICO CONSULTA PACIENTE código data/hora código 9

10 Modelo equivalente b) CONSULTA como entidade MÉDICO código (1,1) (1,1) (1,n) CONSULTA PACIENTE código data/hora 10

11 Transformação de relacionamento n:n em entidade (1) 1. O relacionamento n:n é representado como uma entidade. 2. A entidade criada é relacionada às entidades que originalmente participavam do relacionamento. 3. A entidade criada tem como identificador: as entidades que originalmente participavam do relacionamento, os atributos que eram identificadores do relacionamento original (caso o relacionamento original tivesse atributos identificadores). 11

12 Transformação de relacionamento n:n em entidade (2) 4. Nos relacionamentos de que participa, a cardinalidade da entidade criada é sempre (1,1). 5. As cardinalidades das entidades que eram originalmente associadas pelo relacionamento são transcritas ao novo modelo conforme mostrado na figura. 12

13 Modelo ER sem relacionamento n:n Relacionamento n:n pode ser transformado em entidade. É possível construir modelos sem relacionamentos n:n. Há variantes da abordagem ER, que excluem o uso de relacionamentos n:n, ou excluem apenas o uso de relacionamentos n:n com atributos Exemplo: várias abordagens baseadas na Engenharia de Informações (ver adiante) 13

14 Identificando construções Determinação da construção da abordagem ER (entidade, relacionamento,...) que será usada para modelar um objeto de uma realidade: Não pode ser feita através da observação do objeto isoladamente. É necessário conhecer o contexto (modelo dentro do qual o objeto aparece). 14

15 Identificando construções Recomendação geral Decisão por uma construção para a modelagem de um objeto está sujeita a alteração durante a modelagem. Não despender um tempo excessivo em longas discussões sobre como modelar um objeto. Desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e aperfeiçoando o modelo. 15

16 Atributo versus entidade relacionada Como deve ser modelada a cor de um automóvel? AUTOMÓVEL cor atributo? 16

17 Atributo versus entidade relacionada AUTOMÓVEL cor AUTOMÓVEL (1,1) COR ou entidade relacionada? 17

18 Atributo versus entidade relacionada critérios (1) Objeto está relacionado com outros objetos: deve ser modelado como entidade. Caso contrário: pode ser modelado como atributo. 18

19 Atributo versus entidade relacionada critérios (2) Conjunto de valores de um determinado objeto é fixo (domínio fixo): pode ser modelado como atributo. Existem transações no sistema que alteram o conjunto de valores do objeto (domínio variável): não deve ser modelado como atributo. 19

20 Atributo versus generalização/especialização Questão: modelar um determinado objeto (exemplo, a categoria funcional de cada empregado de uma empresa): como atributo? (categoria funcional como atributo da entidade ) ou como uma especialização? (cada categoria funcional corresponde a uma especialização da entidade empregado) 20

21 Atributo versus generalização/especialização Especialização deve ser usada quando as classes especializadas de entidades possuem propriedades particulares: atributos relacionamentos generalizações/especializações 21

22 Atributo versus generalização/especialização código categoria funcional categoria funcional é um atributo? 22

23 Atributo versus generalização/especialização código código ou é uma especialização? xt categoria funcional MOTORISTA ENGENHEIRO número da carteira de habilitação data de expiração da carteira de habilitação CREA 23

24 Entidade versus especialização Questão: Deve-se modelar um determinado objeto como: uma entidade relacionada a outra? ou como uma especialização? Observar o identificador do objeto em questão: Lembrar que uma entidade especializada herda o identificador de sua entidade genérica. 24

25 Entidade versus especialização número do cartão PESSOA data de nascimento endereço ct SERVIDOR cargo ALUNO escola secundária data de ingresso 25

26 Entidade versus especialização data de nascimento número do cartão PESSOA endereço ct SERVIDOR cargo escola Dados da pessoa secundária como servidor ALUNO Uma pessoa é data de ingresso somente uma vez servidor 26

27 Entidade versus especialização número do cartão 1 PESSOA data de nascimento p endereço número data início n SERVIDOR CARGO data fim cargo escola Pessoa pode ter secundária vários cargos Uma instância ALUNO por cargo do servidor data de ingresso 27

28 Entidade versus especialização número do cartão PESSOA data de nascimento endereço p Dados da pessoa como SERVIDOR aluno uma cargo instância por pessoa ALUNO escola secundária data de ingresso 28

29 Entidade versus especialização número do cartão PESSOA data de nascimento endereço ct Dados da pessoa como SERVIDOR aluno uma cargo instância por pessoa escola secundária ALUNO 1 n INGRESSO data de ingresso 29

30 Entidade versus especialização número do cartão PESSOA data de nascimento endereço ct SERVIDOR Dados de cada cargo ingresso do aluno escola secundária ALUNO 1 n INGRESSO data de ingresso 30

31 Atributo opcional Atributo opcional: Pode indicar subconjunto de entidade, que pode ser modelado mais corretamente através de especialização. tipo de empregado código data de expiração da carteira de habilitação (0,1) CREA (0,1) CRM (0,1) número da carteira de habilitação (0,1) 31

32 Atributo opcional tipo de empregado código CREA (0,1) CRM (0,1) data de expiração da carteira de habilitação (0,1) número da carteira de habilitação (0,1) código t MOTORISTA MÉDICO ENGENHEIRO número da carteira de habilitação data de expiração da carteira de habilitação CRM CREA 32

36 Atributo multivalorado é indesejável SGBD relacional que segue o padrão SQL/2: Atributo multivalorado não possui implementação direta. SGBD OO ou objeto/relacional: Atributo multi-valorado normalmente é modelado como classe separada. Atributos multivalorados podem induzir a um erro de modelagem Ocultar entidades e relacionamentos em atributos multivalorados 36

37 Atributo multivalorado lançamento pagamento dependente 37

38 Atributo multivalorado eliminação lançamento pagamento dependente (1,1) (1,1) LANÇAMENTO PAGAMENTO (1,1) TIPO LANÇAMENTO descrição valor código DEPENDENTE data de nascimento 38

39 Atributo multivalorado eliminação lançamento pagamento dependente (1,1) (1,1) LANÇAMENTO PAGAMENTO (1,1) TIPO LANÇAMENTO descrição valor código DEPENDENTE data de nascimento 39

40 Verificação do modelo Modelo deve ser correto Modelo deve ser completo Modelo deve ser livre de redundâncias 40

41 Modelo deve ser correto Erros: sintáticos semânticos Erros semânticos mais difíceis de verificar. Regras de normalização auxiliam na validação. 41

42 Exemplos de erros semânticos Estabelecer associações incorretas: associar a uma entidade um atributo que na realidade pertence a outra entidade. Usar uma entidade como atributo de outra entidade. Usar o número incorreto de entidades em um relacionamento. fundir em um único relacionamento ternário dois relacionamentos binários independentes 42

43 Modelo deve ser completo Deve fixar todas propriedades desejáveis do banco de dados. Somente pode ser verificado por alguém que conhece profundamente o sistema a ser implementado: Envolvimento de especialista no domínio da aplicação ( usuário ). 43

44 Verificação de completitude Forma de verificar: dados que devem ser obtidos do banco de dados estão presentes? todas as transações de modificação do banco de dados podem ser executadas sobre o modelo? Requisito é aparentemente conflitante com a falta de poder de expressão de modelos ER. 44

45 Modelo deve ser livre de redundâncias Modelo deve ser mínimo, isto é não deve conter conceitos redundantes. Tipos de redundância: Relacionamentos redundantes Atributos redundantes 45

46 O que fazer com construções redundantes? Alternativas não devem aparecer no modelo ou devem aparecer indicadas como redundantes Implementação pode conter redundância controlada de dados (desempenho, tolerância a falhas) 46

47 Exemplo de modelo FÁBRICA F-D DEPTO (1,1) (1,1) LOCALIZAÇÃO DEPTO D-E (1,1) TRABALHO MÁQUINA ASSOCIAÇÃO (0,1) SINDICATO 47

48 Relacionamentos redundantes FÁBRICA F-D DEPTO (1,1) (1,1) (1,1) LOCALIZAÇÃO DEPTO LOCALIZAÇÃO FÁBR D-E (1,1) TRABALHO MÁQUINA relacionamento redundante ASSOCIAÇÃO (0,1) SINDICATO 48

49 Relacionamentos redundantes FÁBRICA F-D DEPTO (1,1) (1,1) (1,1) LOCALIZAÇÃO DEPTO LOCALIZAÇÃO FÁBR D-E (1,1) TRABALHO MÁQUINA redundante com: ASSOCIAÇÃO (0,1) SINDICATO 49

50 Relacionamentos redundantes FÁBRICA F-D DEPTO (1,1) (1,1) LOCALIZAÇÃO DEPTO D-E (1,1) TRABALHO MÁQUINA ATUAÇÃO relacionamento redundante ASSOCIAÇÃO (0,1) SINDICATO 50

51 Relacionamentos redundantes FÁBRICA F-D DEPTO (1,1) (1,1) LOCALIZAÇÃO DEPTO D-E (1,1) TRABALHO MÁQUINA ATUAÇÃO ASSOCIAÇÃO (0,1) SINDICATO redundante com: 51

52 Relacionamentos redundantes FÁBRICA F-D (1,1) este relacionamento é redundante? DEPTO (1,1) LOCALIZAÇÃO DEPTO D-E (1,1) TRABALHO MÁQUINA ASSOCIAÇÃO (0,1) SINDICATO 52

53 Atributos redundantes ou deriváveis código (1,1) n DEPARTAMENTO LOTAÇÃO nº de empregados código do departamento 53

54 Atributos redundantes ou deriváveis código (1,1) n DEPARTAMENTO LOTAÇÃO nº de empregados código do departamento atributo redundante 54

55 Atributos redundantes ou deriváveis código (1,1) n DEPARTAMENTO LOTAÇÃO nº de empregados código do departamento atributo derivável 55

56 Modelo deve refletir o aspecto temporal Dados temporais: dados que mudam ao longo do tempo e para as quais BD mantém histórico. Tipos de dados temporais: Atributos cujos valores modificam ao longo do tempo; Relacionamentos que modificam ao longo do tempo. 56

57 Atributos temporais salário cada empregado tem um único salário (salário atual) 57

58 Atributos temporais salário (1,1) SALÁRIO data valor (a) Banco de dados contém apenas o salário atual (b) Banco de dados contém a história dos salários 58

59 Atributos temporais salário (1,1) SALÁRIO ponto no tempo ou faixa (intervalo) de tempo (a) Banco de dados contém apenas o salário atual data (b) valor Banco de dados contém a história dos salários 59

60 Relacionamento 1:1 temporal 1 ALOCAÇÃO 1 MESA (a) Base de dados contém apenas a alocação atual 60

61 Relacionamento 1:1 temporal 1 ALOCAÇÃO 1 MESA (a) Base de dados contém apenas a alocação atual n ALOCAÇÃO n MESA data (b) Base de dados contém a história das alocações 61

62 Relacionamento 1:1 temporal relacionamento 1 com ALOCAÇÃO identificador (ponto no tempo ou 1 faixa de tempo) MESA (a) Base de dados contém apenas a alocação atual n ALOCAÇÃO n MESA data (b) Base de dados contém a história das alocações 62

63 Relacionamento 1:n temporal nº documento de lotação n LOTAÇÃO 1 DEPARTAMENTO (a) Base de dados contém apenas a lotação atual 63

64 Relacionamento 1:n temporal nº documento de lotação n LOTAÇÃO 1 DEPARTAMENTO n nº documento de lotação LOTAÇÃO data n DEPARTAMENTO (a) Base de dados contém apenas a lotação atual (b) Base de dados contém a história das lotações 64

65 Relacionamento 1:n temporal nº documento de lotação n relacionamento LOTAÇÃO com identificador (ponto 1no tempo ou DEPARTAMENTO faixa de tempo) n nº documento de lotação LOTAÇÃO data n DEPARTAMENTO (a) Base de dados contém apenas a lotação atual (b) Base de dados contém a história das lotações 65

68 Relacionamento n:n temporal PARTICIPANTE n INSCRIÇÃO data n CURSO (a) Base de dados contém apenas a inscrição atual 68

69 Relacionamento n:n temporal PARTICIPANTE n INSCRIÇÃO data n CURSO PARTICIPANTE n INSCRIÇÃO data n CURSO (a) Base de dados contém apenas a inscrição atual (b) Base de dados contém a história das inscrições 69

70 Consultas a dados referentes ao passado Muitas vezes, informações referentes ao passado são eliminadas da base de dados (arquivamento). Podem ser necessárias no futuro: por motivos legais para realização de auditorias para tomada de decisões 70

71 Dados referentes ao passado planejar arquivamento Solução que poderia ser considerada: reincluir as informações no banco de dados, quando elas forem necessárias. Problema: restrições de integridade referencial. Planejar informações estatísticas: Quando informações antigas são necessárias apenas para tomada de decisões. Pode ser conveniente manter no banco de dados informações compiladas e eliminar as informações usadas na compilação. 71

72 Entidade isolada Entidade isolada Entidade que não apresenta relacionamento com outras entidades. 72

73 Entidade isolada Analisar: Caso raro, mas não incorreto. Caso típico: Entidade que modela a organização na qual o sistema implementado pelo BD está embutida. 73

74 Entidade isolada exemplo Exemplo: BD de uma universidade. A entidade UNIVERSIDADE pode ser necessária, caso se deseje manter no BD alguns atributos da universidade. O modelo não deveria conter o relacionamento desta entidade com outras, como ALUNO ou CURSO: BD modela uma única universidade; Não é necessário informar no BD em que universidade o aluno está inscrito ou a qual universidade o curso pertence. 74

75 Estabelecimento de padrões Modelos de dados são usados para comunicação: com pessoas da organização, com programas (ferramentas CASE, geradores de código, ). É necessário estabelecer padrões de confecção de modelos. Na prática e na literatura: Muitas variantes de modelo ER. Variantes em: sintaxe, semântica. 75

76 Variantes de modelos ER Peter Chen (acadêmica) Engenharia de Informações UML Merise (notação Européia) 76

77 Notação acadêmica (P. Chen) código identificador DEPARTAMENTO LOTAÇÃO (1,1) 77

78 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código notação para atributos tem lotado está lotado em identificador 78

79 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código cardinalidade máxima 1 tem lotado está lotado em identificador 79

80 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código cardinalidade mínima 1 tem lotado está lotado em identificador 80

81 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código tem lotado está lotado em identificador cardinalidade mínima 0 81

82 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código tem lotado está lotado em identificador cardinalidade máxima n 82

83 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código tem lotado está lotado em identificador Notação para cardinalidade máxima e mínima: Cardinalidade (mínima, máxima) 1 Cardinalidade mínima 0 Cardinalidade máxima n 83

84 Notação Engenharia de Informações código identificador DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO código tem lotado está lotado em relacionamentos binários somente: sem atributos identificador 84

85 Engenharia de informações especialização: subtipos de entidades domina é dominado por GERENTE SECRETÁRIA ENGENHEIRO tem alocado está alocado em está lotado em tem lotado gerencia é gerenciado por DEPARTAMENTO PROCESSADOR DE TEXTOS PROJETO 85

86 UML UML ( unified modeling language ): Conjunto de modelos diagramáticos para modelagem de software. Diagrama de classes pode ser usado como modelo conceitual. Terminologia é diferente: ER Entidade Relacionamento Cardinalidade Generalização/especialização UML Classe Associação Multiplicidade Generalização 86

87 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO 1..* GERÊNCIA 0..1 GERENTE SECRETÁRIA ENGENHEIRO 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS CREA 0..* PROJETO PARTICIPAÇÃO 0..* 87

88 UML - notação CIC tipo empregado 1..* 0..* atributos como na LOTAÇÃO engenharia de informação 1 DEPARTAMENTO GERÊNCIA 0..1 GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS ENGENHEIRO CREA 0..* PROJETO PARTICIPAÇÃO 0..* 88

89 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO 1..* GERÊNCIA 0..1 GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS ENGENHEIRO CREA relacionamentos 0..* como na PARTICIPAÇÃO engenharia de informação 0..* PROJETO 89

90 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO GERÊNCIA * GERENTE SECRETÁRIA DOMÍNIO PROCESSADOR DE TEXTOS especialização como na notação acadêmica 1..* 0..* ENGENHEIRO CREA 0..* PROJETO PARTICIPAÇÃO 0..* 90

91 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO 1..* GERÊNCIA 0..1 GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS ENGENHEIRO notação de cardinalidade CREA 0..* (* = n) PARTICIPAÇÃO 0..* PROJETO 91

92 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 exatamente 1 DEPARTAMENTO 1..* GERÊNCIA 0..1 GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS ENGENHEIRO CREA 0..* PARTICIPAÇÃO 0..* PROJETO 92

93 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO GERÊNCIA * GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS não há conceito de identificador ENGENHEIRO CREA 0..* PROJETO PARTICIPAÇÃO 0..* 93

94 UML - notação CIC tipo empregado 0..* LOTAÇÃO 1 DEPARTAMENTO GERÊNCIA * GERENTE SECRETÁRIA 1..* DOMÍNIO 0..* PROCESSADOR DE TEXTOS há outros conceitos (métodos,...) ENGENHEIRO CREA 0..* PROJETO PARTICIPAÇÃO 0..* 94

95 Notação Européia (MERISE, DBMain,...) DEPARTAMENTO LOTAÇÃO (1,1) DEPARTAMENTO 0,n 1,1 LOTAÇÃO 95

96 Notação Européia (MERISE, DBMain,...) semântica participativa: cardinalidade diz quantas vezes uma instância de entidade participa de um relacionamento DEPARTAMENTO 0,n 1,1 LOTAÇÃO 96

97 Uso de ferramentas de modelagem Diagrama ER não deve ser confeccionado manualmente: muito trabalhoso, revisões são freqüentes, diagramas feitos à mão não são atualizados, quando de alterações do esquema. Recomendável que seja usada uma ferramenta em computador para apoio à modelagem. Alternativas: Uso de uma ferramenta CASE. Uso de programas de propósito geral. 97

98 Estratégias de modelagem Estratégia de modelagem ER: uma seqüência de passos (uma receita-de-bolo ) de transformação de modelos, desde o modelo inicial de modelagem, até o final. Diferentes estratégias: Bottom-up Top-down Inside-out 98

99 Definição da estratégia de modelagem Na prática: Nenhuma das estratégias propostas na literatura é universalmente aceita. Normal é: Combinação das diversas estratégias de modelagem. Compreensível, pois: Processo de modelagem é um processo de aprendizagem. 99

100 Definição da estratégia de modelagem Identificar qual a fonte de informações principal para o processo de modelagem: Descrições de dados existentes: estratégia bottom-up. Conhecimento de pessoas sobre o sistema : estratégia top-down (ou inside-out). 100

101 Estratégia top-down Partir de conceitos mais abstratos ( de cima ). Ir gradativamente refinando estes conceitos em conceitos mais detalhados. 101

102 1. Modelagem superficial: Estratégia top-down processo (1) a) Enumeração das entidades. b) Identificação dos relacionamentos (cardinalidade máxima) e hierarquias de generalização/especialização entre as entidades. c) Determinação dos atributos de entidades e relacionamentos. d) Determinação dos identificadores de entidades e relacionamentos. e) O banco de dados é verificado quanto ao aspecto temporal. 102

103 2. Modelagem detalhada: Estratégia top-down processo (2) a) Domínios dos atributos b) Cardinalidades mínimas. c) Demais restrições de integridade. 3. Validação do modelo: a) Construções redundantes ou deriváveis a partir de outras no modelo. b) Validação com o usuário. 103

104 Estratégia inside-out Exemplo passo #1 104

105 Estratégia inside-out Exemplo passo #2 LOTAÇÃO (1,1) DEPARTAMENTO 105

106 Estratégia inside-out Exemplo passo #3 tipo de empregado CIC LOTAÇÃO (1,1) DEPARTAMENTO px CREA GERENTE SECRETÁRIA ENGENHEIRO 106

107 Estratégia inside-out Exemplo passo #4 tipo de empregado CIC LOTAÇÃO (1,1) DEPARTAMENTO (1,n) GERÊNCIA px (0,1) CREA GERENTE SECRETÁRIA ENGENHEIRO (1,n) DOMÍNIO PARTICIPAÇÃO PROCESSADOR DE TEXTOS PROJETO 107