Projeto Conceitual Usando o Modelo-Entidade Relacionto 5-1
Visão Avançada do Projeto de Banco de Dados Projeto conceitual : (MER é usado neste estágio) O que são as entidades e relaciontos no cenário? Que informações sobre estas entidades e relaciontos deveríamos armazenar no banco de dados? O que são as restrições de integridade ou regras de negócio? Um projeto de um MER pode ser visualizado (diagrama ER) e mapedo em um esquema relacional. Refinto do Esquema: (Normalização) Verifica esquema relacional para redundâncias e anomalias. Desenho e Ajuste Físico: Considera carga típica e refina ainda mais o desenho do BD. 5-2
Fundamentos do MER Entidade: Objeto do mundo real distinto de outros objetos. Uma entidade é descrita (em DB) usando um conjunto de atributos. Conj. de entidades: Todas entidades num conjunto de entidades tem o mesmo conjunto de atributos. (Pelo menos até considerarmos hieraquias ISA) Cada conjunto de entidades tem uma chave. Cada atributo tem um domínio. Pode-se facilmente mapear conjunto de entidades para uma relação. 123-22-3666 Attishoo 48 231-31-5368 Smiley 22 131-24-3650 Smethurst 35 CREATE TABLE ( CHAR(11), CHAR(20), INTEGER, PRIMARY KEY ()) 5-3
Fundamentos do MER (cont.) since did d budget Works_In Departments Relacionto: Associação entre 2 ou mais entidades. supervisodinate subor- Reports_To Conjunto de Relaciontos: Coleção de relaciontos similares. Um conjunto de relaciontos R pode relacionar N conjuntos de entidades E1 EN distintas. Alguns conjuntos de entidades poderiam participar em diferentes conjuntos de relacionto, ou em diferentes papéis no mesmo conjunto. 5-4
Fundamentos do MER (cont.) Conjunto de relaciontos podem também ter atributos descritivos (p.ex., since ao lado) Traduzindo um conjunto de relaciontos para uma relação, os atributos da relação tem que incluir: Chave para cada conjunto de entidades participante (como chaves estrangeiras). Este conj. de atributos forma superchave para a relação. E os atributos descritivos. CREATE TABLE Works_In( CHAR(1), did INTEGER, since DATE, PRIMARY KEY (, did), FOREIGN KEY () REFERENCES, FOREIGN KEY (did) REFERENCES Departments) did since 123-22-3666 51 1/1/91 123-22-3666 56 3/3/93 231-31-5368 51 2/2/92 5-5
Restrição de Chaves Um empregado pode estar alocado a vários deptos e um depto pode ter vários empregados. since Manages d did budget Departments Por outro lado, cada depto tem no máximo um gerente conforme key constraint em manages. tradução p/ o modelo relacional? 1-to-1 1-to Many Many-to-1 Many-to-Many 5-6
Tradução de Diagramas ER c/ Restrições de Chave Mapeia-se um relacionto para uma tabela: Note que did é a chave agora! Separe tabelas para e Depts. Desde que cada dept tem um único gerente, podemos ter administração e departamentos. CREATE TABLE Manages( CHAR(11), did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY () REFERENCES, FOREIGN KEY (did) REFERENCES Departments) CREATE TABLE Dept_Mgr( did INTEGER, d CHAR(20), budget REAL, CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY () REFERENCES ) 5-7
Restrições de Participação Todo departamento tem um gerente? Se sim, isto é um restrição de participação: A participação do Depto em Administração é dito para ser total (vs. parcial). Todo valor did na tabela de Departamentos tem aparecer na fileira da tabela de administração (com um valor não nulo!) since did d budget Manages Departments Works_In since 5-8
Restrições de Participação em SQL Podemos capturar restrições de participação envolvendo um conjunto de entidades em um relacionto binário, mas pouco além disso (sem recorrer a um restrições do tipo CHECK). CREATE TABLE Dept_Mgr( did INTEGER, d CHAR(20), budget REAL, CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY () REFERENCES, ON DELETE NO ACTION) 5-9
Entidades Fracas Uma entidade fraca pode ser identificada considerando a chave primaria de outra entidade (proprietária). Conjuntos de entidades proprietárias e conjuntos de entidades fracas tem que participar em conjunto de relaciontos um-para-muitos. Conjuntos de entidades fracas tem que ter participação total neste conjunto de relacionto identificadores. cost p age Policy Dependents 5-10
Traduzindo Conjunto de Entidades Fracas Conjunto de entidades fracas e conjuntos de relaciontos identificadores são traduzidos para uma tabela simples. Quando um proprietário de entidade é removido, todos entidades fracas possuídas tem que ser removidas também. CREATE TABLE Dep_Policy ( p CHAR(20), age INTEGER, cost REAL, CHAR(11) NOT NULL, PRIMARY KEY (p, ), FOREIGN KEY () REFERENCES, ON DELETE CASCADE) 5-11
Hierarquias ISA (`is a ) Como em OO atributos são herdados. Se declaramos A ISA B, toda entidade A é também considerada uma entidade B. hourly_wages hours_worked ISA contractid Restrições de sobreposições: Pode Joe ser um Hourly_Emps assim como uma entidade em Contract_Emps? Restrições de Cobertura : Todos os empregados tem também que ser um Hourly_Emps ou uma entidade Contract_Emps? Razões para se usar ISA: Para adicionar atributos descritivos para uma sub-classe. Para identificar entidades que participam de um relacionto. Hourly_Emps Contract_Emps 5-12
Traduzindo Hierarquias ISA para Relações Estratégia Geral: 3 relações,, Hourly_Emps and Contract_Emps. Hourly_Emps: Todo empregado é registrado em. Para horistas informação extra é registrada em Hourly_Emps (hourly_wages, hours_worked, ); deve-se remover tupla de Hourly_Emps se a tupla referenciada de for removida. Consultas envolvendo todos empregados são fáceis, aquelas envolvendo apenas Hourly_Emps requerem um join para obter alguns atributos. Alternativa: Apenas Hourly_Emps e Contract_Emps. Hourly_Emps:,,, hourly_wages, hours_worked. Cada empregado deve pertencer a uma dessas subclasses. 5-13
Agregação Usado quando temos que modelar relacionto envolvendo conj. de entidades e um conj. relaciontos Agregação nos permite considerar um conjunto de relacionto como um conjunto de entidades com objetivo de participação em (outros) relaciontos. Monitors é mapeado para tabela normalmente. pid started_on pbudget Projects Monitors Sponsors did until d Departments budget Agregação vs. relacionto ternário: Monitors é um relacionto com, atributo descritivo. Pode-se dizer que cada sponsorship é monitorada por apenas 1 empregado 5-14
Projeto conceitual usando o MER Escolhas de Projeto: Um conceito deve ser modelado como uma entidade ou um atributo? Ou um relacionto? E os relaciontos? Binários ou ternários? Agregação? Restrições no MER: Muita semântica de dados pode (e deve) ser capturada. Porém algumas restrições não podem ser descritas no diagrama Necessidade de refinto no esquema: Esquema relacional obtido do diagrama de ER é um bom passo inicial, mas por não expressar algumas restrições o mesmo pode necessitar refintos. 5-15
Entidade vs. Attributo Address deve ser um atributo de ou uma entidade (ligada a por relacionto)? Depende do uso que queremos fazer da informação, e da semântica do dado: Se temos vários endereços por empregado, address tem que ser uma entidade (porque?). Idem se a estrutura do address é importante. Data de nascimento, p.ex., é um exemplo clássico onde é mais adequado se usado como atributo e não uma entidade por si só. 5-16
Entidade vs. Attributo (Cont.) Works_In2 não permite a um empregado trabalhar em um depto por mais de um período. from to Works_In2 did dbudget Departments Works_In3 resolve este problema criando uma entidade e usando um relacionto ternário (note o uso da semântica do modelo). from Works_In3 Duration did to d budget Departments 5-17
Entidade vs. Relacionto (Cont.) 1o diagrama OK se o manager tem um budget distinto para para depto. E se o manager tem um budget para todos os deptos gerenciados? 1a opção é redundante. dbudget, é armazenado para cada depto. 2a opção soluciona o problema apptnum since dbudget Manages2 Manages3 Mgr_Appts did did d budget Departments d since budget Departments dbudget 5-18
Relacionto binários vs ternários Se cada policy é propriedade de apenas um empregado: Restrição de chaves em policies implicaria que policy pode cobrir apenas um dependente. Quais são as restrições adicionais no 2o diagrama? Bad design policyid Purchaser Better design policyid Covers Policies Policies cost Beneficiary cost p p age Dependents age Dependents 5-19
Relaciontos binários vs ternários (Cont.) As restrições de chave permitem combinar Purchaser com Policies e Beneficiary com Dependents. Restrição de CREATE TABLE Dependents ( participação leva a restrição do tipo NOT NULL. E se policies fosse uma entidade fraca? CREATE TABLE Policies ( policyid INTEGER, cost REAL, CHAR(11) NOT NULL, PRIMARY KEY (policyid). FOREIGN KEY () REFERENCES, ON DELETE CASCADE) p CHAR(20), age INTEGER, policyid INTEGER, PRIMARY KEY (p, policyid). FOREIGN KEY (policyid) REFERENCES Policies, ON DELETE CASCADE) 5-20
Relacionto binários vs ternários (Cont.) Exemplo anterior ilustra um caso onde 2 relaciontos binários são melhores que um relacionto ternário. Um exemplo contrário: uma relação ternário Contracts relaciona entidades Parts, Departments e Suppliers, and tem atributos descritivo quantidade. Não há combinação de relaciontos binários adequados: S ``pode fornecer P, D ``precisa P, and D ``negocia com S não significa que D concorda em comprar P de S! Como registra-se quantidade? 5-21
Restrições além do MER Dependências funcionais (DFs): P.ex., um depto não pode comprar duas partes distintas de um mesmo fornecedor. Não pode ser expressa com o relacionto Contracts. Normalização refina o diagrama ER considerando DFs. Dependencia de Inclusão: Caso especial: Chave estrangeiras (MER é suficiente). P.ex., pelo menos 1 pessoa deve-se reportar a cada gerente. (Conj. de valores em Manages deve ser um subconj. de supervisor_ em Reports_To.) Chave estrangeira? Como expressar isso no MER? Retrições gerais: P.ex. e.g., Budget do Manager por depto é menos que 10% do que o budget total que ele gerencia. 5-22
Resumo do projeto conceitual Projeto Conceitual segue Análise de Requisitos, Fornece descrição de alto nível do dados armazenados. MER é popular para projeto conceitual Construções são expressivas, próximas da intuição sobre as aplicações. Construtores básicos: entidades, relaciontos e attributos. Alguns construtores adicionais: entidades fracas, hierarquias ISA e agregação. Nota: há muitas variações do MER. 5-23
Resumo do projeto conceitual (Cont.) Vários tipos de restrições de integridade podem ser expressas em um MER: restrições de chaves, de participações, etc. Algumas restrições de chave estrangeira estão implicitas na definição de um conjunto de relaciontos. Algumas dessas restrições podem ser expressas em SQL apenas se usarms CHECK ou similar (assert). Algumas restrições (especialmente DFs) não podem ser expressadas em um MER. Restrições tem um papel importante na determinação do melhor projeto para um dado cenário. 5-24
Resumo do projeto conceitual (Cont.) Projeto ER é subjetivo. A análise de alternativas pode ser delicada, especialmente para grandes cenários. Alternativas podem incluir: Entidade vs atributo, entidade vs. relacionto, relacionto binário ou ternário, quando usar hierarquias ISA, quando usar agregação, etc. Garantia de um projeto de banco de dados: o esquema relacional deve ser analisado em refinado. Informação sobre DFs e técnicas de normalização são especialmente úteis. 5-25