Sistemas de Informação e Bases de Dados 2012/2013 Modelo Entidade-Associação (EA) Alberto Sardinha
Bibliografia Raghu Ramakrishnan, Database Management Systems, Cap. 2 1"
Sumário Modelo Entidade-Associação (EA) Conjunto de entidades, atributos, chave Conjunto de associações Restrição de chave Participação total Entidade fraca, chave parcial Generalizações/especializações, restrição de sobreposição e restrição de cobertura Agregação! Concepção/Desenho de Bases de Dados revisitada 2"
Processo de Desenho I 1. Análise de Requisitos Que dados devem ser armazenados? Que aplicações vão aceder aos dados? Que operações vão ser mais frequentes? Requisitos de desempenho 2. Desenho Conceptual Descrição de alto-nível dos dados e as suas restrições Uso de diagramas EA ou UML 3. Desenho Lógico Dependente do SGBD usado Exemplo: modelo relacional
Processo de Desenho II Refinamento do esquema Normalização Desenho Físico Melhorar desempenho Indexes, clustering Desenho de Aplicações e Segurança Considerar aspectos aplicacionais
Desenho Conceptual Um conceito deverá ser modelado como entidade ou como atributo? Um conceito deverá ser modelado como entidade ou como associação?
Desenho Conceptual Devemos usar associações binárias ou ternárias? Devemos usar agregações?
Entidade vs. Atributo Criar um conjunto de entidades a partir de um atributo quando: Existe mais de um valor por cada entidade (podemos utilizar também atributos de valor múltiplo) O atributo tem a sua própria estrutura (podemos utilizar também atributos compostos) Partilhado por vários conjuntos de entidades
Entidade vs. Atributo Exemplo: endereço como atributo Empregados têm mais de um endereço Um endereço é composto pelos atributos: Rua, cidade, país Alguns Empregados partilham o mesmo endereço
Entidade vs. Atributo Descritivo ssn name lot from to did dname budget Employees Works_In4 Departments ssn name lot did dname budget Employees Works_In4 Departments from Duration to
Relação para Entidade ssn name lot since dbudget did dname budget Employees Manages2 Departments ssn name lot Employees since did dname budget ISA Manages2 Departments Managers dbudget Isto"resolve"o"problema!"
Binária vs. Ternária ssn name lot pname age Employees Covers Dependents Policies Requisitos)adicionais:) policyid cost 1. Uma"apólice"NÃO"pode"ter"como"donos"dois"ou"mais" empregados" 2. Cada"apólice"tem"que"ter"pelo"menos"um"dono" 3. Os"dependentes"são"enEdades"fracas"de"empregados." "
Binária vs. Ternária ssn name lot pname age Employees Dependents Purchaser Beneficiary Policies policyid cost
Agregação vs. Ternária ssn name Employees lot Neste"caso,"precisamos" do"atributo" unel " Monitors until pid started_on pbudget since did dname budget Projects Sponsors Departments
Agregação vs. Ternária ssn name lot Employees pid started_on pbudget did dname budget Projects Sponsors Departments Neste"caso,"NÃO"precisamos"do"atributo" unel "
Agregação vs. Ternária ssn name lot Employees Monitors until Cada"projeto"financiado" é"monitorado"por" apenas"um"empregado" pid started_on pbudget since did dname budget Projects Sponsors Departments
Agregação vs. Ternária Numa associação ternária é obrigatório ter três entidades: (a,b,c) Numa agregação as associações são independentes: ((a,b),c)
Projectos Complexos Gerar uma lista única de requisitos é difícil Separar em várias partes (diagramas conceptuais) Para diferentes utilizadores E depois integrar os diagramas num só É necessário encontrar correspondências entre as entidades, associações, atributos, e resolver os conflitos
Erros Comuns I Entidades sem atributos Entidades sem chave primária Idade em vez de data de nascimento Entidades modeladas como atributo Usada para associação implícita
Erros Comuns II RIs que podem ser mapeadas no EA Entidades fracas sem: Entidade de que dependem Restrições de chave e participação Ternárias que deveriam ou podiam ser mapeadas em entidades binárias
Erros Comuns III Agregações mal representadas Generalizações que podiam ser mapeadas em atributos sem restrições de cobertura e disjunção
Verificação do Esquema I Conseguimos obter: O departamento de uma seção O departamento de um empregado As seções de um departamento Os empregados de um departamento Section Department Mas)não:) Employee Os"empregados"de" uma"seção"" A"seção"de"um" empregado""
Verificação do Esquema II Agora conseguimos: A seção de um empregado Os empregados de uma seção Department Section Mas)não:) Employee Empregados"que" trabalham"diretamente" para"um"departamento" (sem"seção)"
Verificação do Esquema III Agora conseguimos: Empregados que trabalham diretamente para um departamento (sem seção) Department Employee Mas)não:) Section O"departamento"de" uma"seção"que"não" tem"empregados"
Verificação do Esquema IV A solução mais geral Employee Department Section Mas pode conter RI associadas à malha
EXERCÍCIO Na despensa são armazenados alimentos. Os alimentos têm uma designação (e.g., bananas, tremoços, iogurte, etc.) e um tipo (e.g., leguminosa, lacticínio, etc.). É necessário saber a data em que foram comprados e, opcionalmente, o prazo de validade. É também importante saber a quantidade existente na despensa e em que tipo de unidades esta quantidade é medida ( gramas, mililitros, etc.). 25"
Sumário Modelo Entidade-Associação (EA) Concepção de Bases de Dados revisitada Próxima aula: Modelo Relacional e Conversão Modelo EA para Modelo Relacional 31"