Sistemas de Base de Dados Michel Ferreira Email: michel@ncc.up.pt (melhor contacto!) Gabinete: CIUP, Gab. 213, 22 6078830 Página da disciplina: http://www.ncc.up.pt/~michel/MI/SBD/ MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Bibliografia Livro principal: Fundamentals of Database Systems, por Elmasri e Navathe (3rd edition), Addison Wesley, 1999. Recomendados: Database Systems: The Complete Book, by Garcia-Molina, Ullman, and Widom (first edition), Prentice Hall, 2002. A Guide to the SQL Standard: A User's Guide to the Standard Database Language SQL, (fourth edition), by C.J. Date and Hugh Darwen, Addison-Wesley, 2000. PostgreSQL: Introduction and Concepts, Bruce Momjian, Addison-Wesley, 2001. Podem ser utéis também: Livros sobre Unix, Perl, PHP e CGI. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Avaliação Um trabalho (a definir na 3ª aula): 30% da nota. Um exame final: 70% da nota. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Programa O Modelo Relacional de Bases de Dados Bases de Dados Orientadas por Objectos, Bases de Dados “object-relational”, Bases de Dados semi-estruturadas e Bases de Dados XML. Bases de Dados Lógicas (dedutivas). “Online Analytical Processing” (OLAP) e “Datawarehousing” MI, MIAC 2002 Michel Ferreira, DCC - FCUP

O que é um sistema de gestão de BD? Gere uma grande quantidade de dados. 2. Permite um acesso eficiente a uma grande quantidade de dados. 3. Permite acesso concorrente a uma grande quantidade de dados. Exemplo: banco e as caixas Multibanco. 4. Permite acesso seguro (atómico) a uma grande quantidade de dados. Imaginem duas pessoas a editar o mesmo ficheiro UNIX – a última a gravar «ganha» - com o problema de duas pessoas levantarem dinheiro da mesma conta via Multibanco ao mesmo tempo – o novo saldo fica errado, qualquer que seja a pessoa a gravar em último lugar. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Modelo Relacional Baseado em tabelas, como: conta # nome saldo 12345 Sandra 1000.21 34567 Alice 285.48 … … … É usado na maioria dos SGBD’s actuais. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP O Mercado dos SGBD’s Empresas de SGBD’s Relacionais – Oracle, Sybase – estão entre as maiores empresas de software do mundo. IBM fornece o seu sistema relacional DB2. A Microsoft fornece o SQL-Server, mais o Microsoft Access para SGBD’s baratos sobre computadores pessoais, respondidos por sistemas “lite” da concorrência. As empresas de BD relacionais também começam a sofrer a concorrência de empresas de “BD orientadas-a-objectos”. Muitos sistemas começam a ser “object-relational”, mantendo o núcleo relacional e permitindo extensões baseadas em sistemas OO. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Três aspectos no estudo de SGBD’s 1. Modelação e desenho de Bases de Dados. Permite a análise de questões antes de passar a uma fase de implementação. Programação: consultas e operações à BD como actualização (update). SQL = “intergalactic dataspeak.” 3. Implementação de SGBD’s. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Linguagens de Consulta Empregado Departamento Nome Dept Dept Director SQL SELECT Director FROM Empregado, Departamento WHERE Empregado.nome = "Clark Kent” AND Empregado.Dept = Departamento.Dept Linguagem de Consulta Data definition language (DDL) ~ semelhante a type defs em C ou Pascal Data Manipulation Language (DML) Consulta (SELECT) UPDATE < nome da relação> SET <atributo> = < novo-valor> WHERE <condição> MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Linguagens “Host” C, C++, Fortran, Lisp, COBOL Progr. Aplicação SGBD Chamadas à BD Variáveis locais (Memória) (Armaz.) Linguagem “host” é completamente geral (Turing complete) mas não fornece suporte primitivo a BD’s. Linguagem de consulta — menos geral “não procedimental”, e optimizável MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP O modelo relacional é bom para: Grande quantidade de dados —> operações simples Navegar dentro de um número pequeno de relações Aplicações difíceis para o modelo relacional: Desenho de circuitos VLSI (CAD em geral) CASE • Informação gráfica ALU ADDER CPU A FA Adder ALU ADDER MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Onde o número de “relações” é grande, relacionamentos são complexos Modelo de Dados Orientado a Objectos Modelo de Dados Lógico 1. Objectos Complexos – Estrutura embricada (apontadores ou referências) Encapsulamento, conjunto de funções de Acesso/Métodos 3. Identidade de Objecto Herança – Definição de novas classes com base em classes antigas Modelo de Objectos: normalmente a procura de objectos é por navegação explicita Existe também uma linguagem de consulta em alguns sistemas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Modelo de Dados Lógico (Horn Clause) • Prolog, Datalog Se A1 e A2 então B prolog B:- A1 and A2 Funções s(5) = 6 (sucessor) Predicados com Argumentos sum(X,Y,Z) X + Y = Z sum(X,0,X) significa X + 0 = X (verdadeiro para todo X) sum(X,s(Y),s(Z)):-sum(X,Y,Z) significa X+(Y+1) = (Z+1) se X + Y = Z Mais poderoso que o relacional Pode calcular o fecho transitivo edge(X,Y) path(X,Y) :- edge(X,Y) path(X,Z) :- path(X,Y) & edge(Y,Z) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP 60’s 70's 80's 90’s agora Hierárquico Rede Relacional Escolha da maioria das aplicações BD OO BD Dedutivas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Modelo Entidade-Relacionamento Entidades: objecto ou conceito do mundo real com uma existência independente com existência física, e.g. carro, empregado, produto, aluno, etc. com existência conceptual: uma empresa, uma profissão, um curso, etc. Atributos: propriedades que caracterizam (e estão associadas) uma entidade atributos de Pessoa: nome, sexo, data nascimento, morada, etc. Relacionamentos representam interacções entre 2 ou mais entidades trabalha(empregado, departamento) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Modelo ER: Atributos Valores dos atributos = Informação da BD Domínios de atributos conj. de valores que podem ser atribuídos a um atributo de uma entidade. Tipos de atributos: atributo simples ou atómico: não é divisível. atributo composto: divisível em atributos simples com significado independente o atributo Endereço da entidade PESSOA pode ser decomposto em: Rua, Cidade e CódigoPostal. atributo de valor único: têm apenas um valor para uma determinada entidade atributo de valores-múltiplos: pode tomar 1 ou mais valores de um conjunto de valores para a mesma entidade. entidade CARRO, atributo Cor-do-carro (vermelho, branco, cinza, …) entidade PESSOA, atributo TítuloAcadémico (licenciado, mestre, doutor,…) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Modelo ER: Atributos (cont.) Tipos de atributos: atributo derivado: pode ser derivado de outro atributo. Idade pode ser derivado de DataNascimento atributo com valor nulo (NULL) quando o atributo não é aplicável a uma determinada entidade. Ex: o atributo TítulosAcadémicos só se aplica a pessoas com curso superior, sendo nulo para as restantes. Interpretações para o valor NULL: o atributo não se aplica; o valor do atributo não é conhecido ou está em falta. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Modelo ER: Entidade Tipo determina o esquema para um conjunto de entidades que partilham a mesma estrutura (atributos). caracteriza-se por um nome e uma lista de atributos. Esquema da entidade-tipo EMPREGADO: Atributo chave de uma entidade-tipo: é o atributo que identifica de forma únivoca cada entidade. deve aparecer sublinhado. Ex: EMPRESA( Nome, Endereço, Presidente) PESSOA( Nome, NumBI, DataNasc, Endereço, …) pode ser constituído por mais do que um atributo simples. EMPREGADO(Nome, Idade, Salário) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Requisitos de uma BDs de uma Empresa Uma empresa está dividida em departamentos. Cada departamento tem um nome, um número e um gerente. Inclui ainda a data em que o gerente começou a gerir o departamento. O departamento pode ter várias localizações. Um departamento controla um determinado número de projectos. Cada projecto tem um nome, um número e uma localização única. Para cada empregado, guardar o nome, o número do BI, endereç, salário, sexo e data de nascimento. Um empregado pertence a um departamento, mas pode trabalhar em vários projectos, que não são necessáriamente controlados pelo mesmo departamento. Tomar nota do número de horas por semana que um empregado trabalha num dado projecto. Tomar nota do supervisor directo de cada empregado. Tomar nota do número de dependentes de cada empregado para efeitos de seguro. Para cada dependente, guardar o nome, sexo, data de nascimento e grau de parentesco para o empregado. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Construção do modelo ER para a BD-Empresa Identificar entidades-tipo e atributos: 1. DEPARTAMENTO( Nome, Num, {Local}, Gerente, GerData) atributos com valores múltiplos: Local 2. PROJECTO( Nome, Num, {Localização}, DepCtl) 3. EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço,Salário,Dnasc, Dept, Super) 4. DEPENDENTE( Empregado, DNome, Sexo, Dnasc, GrauPar) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Construção do modelo ER para a BD-Empresa Falta representar: 1 empregado trabalha em N projectos num. de horas que cada empregado trabalha em cada projecto Identificar entidades-tipo e atributos: Podemos representar esta info como: atributo-composto-multivalor da entidade Empregado TrabalhaEm( Projecto, Horas) atributo-composto-multivalor da entidade Projecto: Trabalhadores( Empregado, Horas) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Relacionamentos Falta representar (entre outros): “um Departamento tem um Director que o dirige; um Director é um empregado” Dirige( Departamento, Empregado) O esquema Dirige traduz um relacionamento entre 2 entidades, Departamento e Empregado. No modelo ER, uma entidade não pode referenciar directamente outra entidade; tal necessidade traduz-se na definição de um relacionamento. Outros relacionamentos: TrabalhaPara(Empregado,Departamento) Controla(Departamento,Projecto) DependeDe(Dependente,Empregado) Supervisiona(Empregado,Empregado) TrabalhaEm(Empregado,Projecto,Horas) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Esquema da BDs Com a definição dos relacionamentos, algunds dos atributos são redundantes pelo que não devem ser incluídos no esquema. O esquema consiste: Entidades: DEPARTAMENTO( Nome, Num, {Local}, ) PROJECTO( Nome, Num, {Localização} ) EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço,Salário,Dnasc) DEPENDENTE( DNome, Sexo, Dnasc, GrauPar) Relacionamentos: trabalhaPara(Empregado,Departamento) dependeDe(Dependente,Empregado) controla(Departamento,Projecto) dirige(Empregado,Departamento, GerData) supervisiona(Empregado,Empregado) trabalhaEm(Empregado,Projecto,Horas) Falta analisar o tipo de participação das entidades no relacionamentos. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos (Grau e Atributos) Grau de um relacionamento: número de entidades no relacionamento. Ex. de um relacionamento ternário: fornece(Fornecedor, Produto, Projecto) Relacionamentos com atributos. Horas é um atributo do relacionamento trabalhaEm(Empregado, Projecto, Horas) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos (Restrições) Restrições nos relacionamentos: permitem limitar as combinações possíveis entre entidades participantes Ex: um empregado trabalha para apenas um departamento. Tipos de Restrições: Cardinalidade dos Relacionamenos: tipo de participação das entidades no relacionamento 1 : N -- um para-muitos trabalhaPara(Empregado, Departamento) M : N -- muitos-para -muitos trabalhaEm(Empregado, Projecto, Horas) 1 : 1 -- um-para-muitos dirige(Empregado, Departamento) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Restrições nos Relacionamentos (cont.) Tipo de participação: especifica se a existência de uma instância de entidade depende do seu relacionamento com outra entidade, via esse relacionamento. Participação total (dependência existêncial) quando todas as instâncias de uma entidade estão relacionadas com alguma instância de uma outra entidade participante no relacionamento. trabalhaPara(Empregado, Departamento) Participação parcial quando não se espera que todas as instâncias de uma entidade participem no relacionamento. dirige(Empregado, Departamento) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Entidades Fracas Entidade Fraca: é identificada pelo seu relacionamento (relacionamento identificador) com determinadas entidades (entidade identificadora) tem sempre participação total (dependência existêncial) em relação ao relacionamento-identificador. Possui uma chave-parcial, que é o conjunto de atributos que univocamente determinam a entidade fraca relacionada com a mesma entidade-identificadora. Ex: dependenDe(Dependente, Empregado) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Modelo ER para a BDs sobre uma Empresa Entidades-tipo: DEPARTAMENTO( Nome, Num, {Local}, ) PROJECTO( Nome, Num, Local ) EMPREGADO( Nome(P,U), NumBI, Sexo, Endereço, Salário, Dnasc ) DEPENDENTE( DNome, Sexo, Dnasc, GrauPar ) Relacionamentos: trabalhaPara(Empregado,Departamento) N:1 total/total dependeDe(Dependente,Empregado) N:1 total/parcial controla(Departamento,Projecto) 1:N parcial/total dirige(Empregado,Departamento, GerData) 1:1 parcial/parcial supervisiona(Empregado,Empregado) 1:N parcial/parcial Supervisor Supervisionado trabalhaEm(Empregado,Projecto,Horas) M:N total/total MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Diagramas ER Ênfase na representação dos esquemas em vez de instâncias de entidades e relacionamentos. Notação para os diagramas: Atributo Atributo-Chave Entidade-Tipo Entidade-Fraca Atributo-Multivalor Atributo-Derivado Relacionamento Atributo-Composto Relacionamento- identificador MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Diagramas ER (cont.) E1 E2 R Participação-total de E2 em R 1 N E1 R E2 1:N Restrição-estrutural da participaçaõ de E em R R E (min,max) Uma entidade E participa num relacionamento R com restrição (min,max) em que 0 >= min <= max e max >= 0, se para cada entidade e de E, e participa pelo menos min e no máximo max instâncias do relacionamento R. min = 0 -- participação parcial MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Exemplo Restrição-Estrutural No diagrama: um empregado trabalha para um departamento Num departamento trabalham pelo menos 4 empregados Nomes para as entidades-tipo, atributos e relacionamentos deve ser feita com critério: entidades - nomes singular atributos - nomes relacionamentos - nomes ou verbos de forma a facilitar a leitura da esquerda para a direita (1,1) (4,N) Empregado Departamento trabalhaPara MI, MIAC 2002 Michel Ferreira, DCC - FCUP

O Modelo EER (ER Extendido) BDs recentes (Multimédia, GIS, CAD/CAM,…) requerem novos conceitos semânticos de modelação: subclasse, superclasse, especialização e generalização, herança de atributos, etc. Subclasses e Superclasses uma subclasse corresponde a um sub-conjunto de entidades com alguma característica comum e pertencentes à mesma entidade-tipo superclasse corresponde à entidade-tipo que aglutina os vários sub-conjuntos de entidades, i.e. subclasses. Ex: Empregado superclasse Secretárias Engenheiros Técnicos Directores subclasses MI, MIAC 2002 Michel Ferreira, DCC - FCUP

O Modelo EER (Relacionamento ISA) O relacionamento ISA (ou superclasse/subclasse) caracteriza a ligação entre as subclasses e a respectiva superclasse uma entidade membro de uma subclasse representa a mesma entidade-física de um membro da superclasse, apenas os “papeis” são diferentes. Ex. A entidade Director de nome X é a mesma entidade X de Empregado; Empregado Director isa Empregado Secretária isa Técnico Empregado isa MI, MIAC 2002 Michel Ferreira, DCC - FCUP

EER: Herança de Atributos As subclasses herdam todos os atributos da sua superclasse uma subclasse com todos os atributos que herda da superclasse, é uma entidade-tipo. Porquê a divisão em subclasses? Certos atributos aplicam-se a apenas algumas instâncias da superclasse Alguns relacionamentos podem ter participação de apenas alguns membros de uma subclasse MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP EER: Especialização Especialização é o processo de de definição do conjunto das subclasses de uma entidade-tipo (superclasse da especialização) e.g. {Secretária, Engenheiro, Técnico} especializa Empregado com base no tipo de trabalho. podemos ter várias especializações da mesma entidade-tipo com base em diferentes características. Podemos associar atributos específicos (extra) a cada subclasse estabelecer relacionamentos-tipo específicos entre uma subclasse e outras entidades-tipo ou outras subclasses MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Diagrama EER Empregado EmpEfectivo EmpPrazo Escalão Nome 3 especializações de Empregado NumBI d d d Director Secretária Técnico Engenheiro Salário Salário Efiliado dirige EngTipo Qualificação VelEscrita Sindicato Projecto MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP EER: Generalização Generalização: processo funcionalmente inverso da especialização. eliminam-se as diferenças entre várias entidades-tipo, identificam-se as caracteristicas comuns que passarão a caracterizar uma nova superclasse da qual as entidades-tipo originais são subclasses especiais. Carro(Matricula, Nreg, Npass, VelMax, Preço) Camião(Matricula, Nreg, Neixos, Tonelagem, Preço) generalizando temos: Nreg Veículo Matricula Preço d Carro Camião Tonelagem Npass Neixos VelMax MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Tipos de Especialização/Generalização Especialização definida-por-atributo quando a divisão em subclasses se basei numa condição de membro e.g. condição tipoTrabalho=“secretária” determina quais dos empregados vão pertencer à subclasse Secretária. Especialização definida-por-utilizador quando não existe a condição. Especialização disjunta quando as subclasses são disjuntas, i.e. cada entidade pode ser membro de no máximo uma subclasse de especialização. Especialização com sobreposição quando a mesma entidade pode pertencer a mais do que uma subclasse, e.g. a superclasse Pessoa pode decompor-se em subclasses Empregado, Estudante, Licenciado (e.g. um assistente é um empregado da universidade, é licenciado e é aluno de doutoramento) d o MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Tipos de Especialização/Generalização (cont.) Especialização Total (linhas duplas nos diagramas) quando toda a entidade de uma superclasse tem de ser membro de alguma sub-classe. e.g. especialização {EmpEfectivo, EmpPrazo} de Empregado. Todos empregados estão numa das subclasses. Especialização Parcial (linha simples nos diagramas) permite que uma entidade não pertença a qualquer das subclasses. Temos assim 4 tipos de especialização: disjunta total; disjunta parcial; sobreposição total; sobreposiçaõ parcial o tipo de especialização é determinado a partir do significado na vida real A generalização de uma superclasse é habitualmente total contém as entidades das subclasses de onde foi derivada. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Filme (Título, Ano, Duração, Tipo) Modelo Relacional Introduzido por Codd (1970) Base de Dados = Conjunto de relações Relação <==> Tabela Filme Título Ano Duração Tipo Zorro 1998 cor 120 Filme (Título, Ano, Duração, Tipo) Esquema Guerra das Estrelas 124 Mighty Ducks 1991 104 atributos tabela tuplo 1977 MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Esquema Relacional de uma BDs Empregado(Pnome,Unome,EBI,Dnasc,Morada,Sexo,Salário,SuperBI,Ndep) Departamento(Dnome,Dnum, DirBI, DirData) Locais_Dep(Dnum,Dlocal) Projecto(Pnome,Pnum,Plocal) TrabalhaEm(EBI,Pnum,Horas) Dependente(EBI,Nome,Sexo,Dnasc,GrauParentesco) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Modelo Relacional: conceitos Domínio: conjunto de valores de um dado tipo que caracterizam um atributo Tuplos: sequência ordenada de valores (ordem da sequência é importante) tuplos de uma relação (ou tabela) não têm ordem os valores das componentes de um tuplo são atómicos no relacional não pode haver atributos compostos ou multivalor Chave de uma relação R identifica de forma única os tuplos de R conjunto mínimo de atributos de R, t.q. não existem 2 tuplos distintos de R com valores iguais nesses atributos. Uma relação pode ter várias chaves candidatas chave primária; chaves alternativas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Restrições Intrínsecas do Relacional Integridade de entidade os valores da chave-primária não podem ser nulos Unicidade da chave não podem existir 2 tuplos diferentes com valores iguais na chave Chave externa conjunto de atributos de uma relação que referenciam a chave de outra relação Integridade referêncial um tuplo de uma relação que se refira a uma outra relação, tem de se referir a um tuplo existente nessa relação garante consistência entre tuplos de 2 relações e.g. os tuplos correspondentes ao empregado-supervisor com EBI 3456789 e ao departamento número 5 têm de existir, dado o seguinte empregado: Empregado(João,Pinto,7654321,19975-03-04,R. das Fontainhas,M,250000,3456789,5) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Interpretação de uma relação Relações uniformizam a representação de factos sobre entidades e relacionamentos Um esquema de uma relação deve ser visto como uma declaração Esquema de BD relacional = conjunto de esquemas relacionais + conjunto de restrições de integridade Operações no modelo relacional: actualizações: inserir, remover e modificar consultas: álgebra relacional MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Operação inserir Permite inserir um ou mais tuplos numa tabela pode violar qualquer dos 4 tipos de restrições: domínio: se um dos valores não pertencer ao domínio chave: o valor da chave do novo tuplo já existe num outro tuplo da tabela integridade de entidade: se o valor da chave do novo tuplo for null integridade referêncial: se o valor de uma chave externa referir um tuplo não existente. Se uma das restrições for violada, opta-se por: rejeitar a inserção (com aviso ao utilizador) ou, tentar corrigir a razão para a rejeição ocorrer. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Operação remover remove tuplos de valores de uma tabela pode violar apenas a integridade referêncial: no caso de o tuplo a remover for referenciado por uma das chaves-externas de outro tuplo naBDs. Requer uma condição sobre os atributos de forma a selecionar o tuplo ou tuplos a serem removidos remover todos os empregados do departamento 10. Caso ocorra violação, opta-se por: rejeitar a operação, ou procurar propagar a operação e remover todos os tuplos que referenciam o que está a ser removido, ou alterar para null os valores dos atributos dos tuplos que referenciam o que está a ser removido Operação modificar = remover+inserir (regras destas operações) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Conversão do Modelo ER para o Modelo Relacional Passo 1: entidade-tipo relação atributos simples da entidade atributos da relação atributos compostos atributos individuais na relação chave da entidade chave da relação Sexo ... Pnome EBI Nome Empregado Unome Empregado Pnome Unome EBI Sexo ... MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Dependente EBI Nome Sexo ... ER Relacional Passo 2: entidade-fraca relação Seja W uma entidade-fraca e E a entidade-identificadora de W: Criar uma relação R em que: atributos simples de W atributos de R chave-principal de E e chave-parcial de W chave-principal de R Nome Empregado Dependente EBI dependeDe ... ... Chave-externa Dependente EBI Nome Sexo ... MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Departamento Dnome Dnum DirBI DirData ER Relacional Passo 3: relacionamento binário 1:1 R(E1,E2) Sejam S e T as relações correspondentes às entidade E1 e E2, respectivamente. Escolhes-se uma das relações, e.g. S (a que corresponde à entidade com participação total em R) e: incluir como chave externa em S a chave-principal de T incluir todos atributos simples do relacionamento R na relação S Dnum Empregado EBI Departamento dirige (0,1) (1,1) ... DirData Chave-externa Departamento Dnome Dnum DirBI DirData MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Empregado Pnome ... EBI ... DNum ER Relacional Passo 4: relacionamento binário 1:N R(E1,E2) Sejam S e T as relações correspondentes às entidade E1 e E2, respectivamente. Escolhes-se a relação que corresponde à entidade participante do lado N em R, suponha-se que é S: incluir como chave externa em S a chave-principal de T incluir todos atributos simples do relacionamento R na relação S Dnum Departamento EBI Empregado trabalhaPara N 1 ... Chave-externa Empregado Pnome ... EBI ... DNum MI, MIAC 2002 Michel Ferreira, DCC - FCUP

trabalhaEm EBI Pnum Horas ER Relacional Passo 5: relacionamento binário M:N R(E1,E2) Criar uma nova relação S para representar o relacionamento R. incluir como chave externa em S as chaves-principais das relações que representam as entidades E1 e E2 participantes em R o conjunto das chaves-externas formará a chave-principal de S incluir todos atributos simples do relacionamento R na relação S Pnum EBI Empregado Projecto trabalhaEm M N ... Horas chaves-externas e chave-principal trabalhaEm EBI Pnum Horas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

trabalhaEm EBI Pnum Horas ER Relacional Passo 5: relacionamento binário M:N R(E1,E2) Criar uma nova relação S para representar o relacionamento R. incluir como chave externa em S as chaves-principais das relações que representam as entidades E1 e E2 participantes em R o conjunto das chaves-externas formará a chave-principal de S incluir todos atributos simples do relacionamento R na relação S Pnum EBI Empregado Projecto trabalhaEm M N ... Horas chaves-externas e chave-principal Nota: os relacionamentos 1:1 e 1:N também podem ser transformados de acordo com o passo 5. trabalhaEm EBI Pnum Horas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Locais_Dep Dnum Dlocal ER Relacional Passo 6: atributos-multivalor Para cada atributo A multivalor, cria-se uma nova relação S que inclui o atributo de A mais a chave-principal, K, da relação que representa a entidade ou relacionamento que tem A como atributo multivalor. A chave-principal de S será acombinação de A e K. Dlocal Dnum Departamento Ex: um departamento pode ter várias localizações. ... Locais_Dep Dnum Dlocal Nota: os passos de 1 a 6 seriam suficientes para converter o esquema-ER no esquema-relacional para a BDs Empresa. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Fornecimento Fnome Pnome Pnum Qtd ER Relacional Passo 7: relacionamentos com aridade superior a 2 (mais de 2 entidades) Para cada relacionamento R com aridade n>2, criar uma nova relação S: incluir como chaves-externas em S, as chaves-principais das relações que representam as entidades participantes. A chave-principal de S será o conjunto de todas as chaves-externas. Incluir como atributos de S, todos os atributos do relacionamento R. Fornecedor Fnome Pnome Pnum Projecto Produto fornecimento Qtd Fornecimento Fnome Pnome Pnum Qtd MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP EER Relacional Passo 8: Converter cada especializaçao com m subclasses (S1,…,Sm) e superclasse (generalizada) C, onde os atributos de C sao (k,a1,…,an) em que k é a chave primária, para relaçoes usando uma das seguintes 4 opçoes: 8a – Criar uma relaçao L para C com atributos atrib(L) = (k, a1,…,an) e cp(L) = k. Criar uma relaçao Li para cada subclasse Si, 1<=i<=m, com atributos atrib(Li)=(k) + (atributos de Si) e cp(Li) = k. 8b - Criar uma relaçao Li para cada subclasse Si, 1<=i<=m, com atributos atrib(Li)=(atributos de Si) + (k,a1,…,an) e cp(Li) = k. 8 c - Criar uma única relaçao L com atributos atrib(L) = (k, a1,…,an) + (atributos de S1) + … + (atributos de Sm) + (t) e cp(L) = k. Esta opçao é para uma especializaçao com subclasses disjuntas, e t é um atributo de tipo que indica a subclasse a que cada tuplo pertence, se alguma. 8d - Criar uma única relaçao L com atributos atrib(L) = (k, a1,…,an) + (atributos de S1) + … + (atributos de Sm) + (t1, …, tm) e cp(L) = k. Esta opçao é para uma especializaçao com subclasses sobrepostas, e cada ti, 1<=i<=m, é um atributo booleano que indica se um tuplo pertence à subclasse Si. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Exercício de modelação Os STCP pretendem construir uma base de dados sobre os percursos dos seus autocarros. A base de dados deve guardar informação relativa aos autocarros, como sejam a matrícula, a data de entrada em serviço, o número de quilómetros, a data da próxima revisão e o tipo (marca/modelo) de autocarro. Cada tipo de autocarro tem uma marca, um modelo, um número de lugares sentados e um número de lugares de pé. A base de dados deve guardar também informação relativa aos percursos. Um percurso é identificado por um número (e.g. 78, 35) e tem uma distância total em quilómetros. Os percursos percorrem paragens. As paragens têm um número identificador, um nome, e uma localização decomposta em local, rua e número. Existem limitações aos percursos que um determinado tipo de autocarro pode fazer, inerentes às suas dimensões. Estas limitações devem ficar registadas na base de dados. Existe um percurso especial para quando um autocarro mais o respectivo condutor são alugados, e este percurso não percorre paragens. Deve ser guardada também informação relativa aos condutores, como sejam o número de BI, o nome, a morada, a data de entrada em serviço e os percursos que cada condutor está habilitado a fazer (um condutor pode estar habilitado a fazer vários percursos). Na base de dados deve ficar registada também informação operacional diária, correspondente ao registo de saídas. Existem três turnos de saída, 6h, 14h e 22h. Um autocarro e um condutor fazem no máximo uma saída por dia, podendo não fazer nenhuma. A informação do registo de saída inclui a data, o turno, o condutor, o autocarro e o percurso atribuído. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Exercício de modelação (cont.) Desenhe um diagrama-ER ou EER para a base de dados descrita acima indicando as chaves das entidades, a cardinalidade dos relacionamentos e o tipo de participações. Converta o diagrama da alínea anterior para o modelo relacional justificando os passos que efectua na conversão. Diga se o seu modelo relacional consegue responder à questão ``Na data 24/12/00 no turno das 22h quantos autocarros fizeram o percurso 78?''. Justifique. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP “Boas” relações: como? o significado do esquema da relação deve ser simples de explicar não combinar os atributos de várias entidades e relacionamentos numa única relação evitar relações que permitam o aparecimento de anomalias de inserção: Emp_Dep(Enome, EBI, Dnasc, Morada, Dnum, Dnome, DirDep) inserir um tuplo de um novo empregado, teremos de incluir valores sobre o departamento onde trabalha. Quando adicionamos info sobre o departamento, temos de ser consistentes com os valores adicionados sobre o mesmo departamento para outros empregados evitar ter atributos numa relação cujo valor pode ser nulo, pois nem sempre se sabe qual a interpretação a aplicar. conceber relações que possam ser combinadas por uma operação de junção com base numa condição de igualdade em atributos que são chaves-principais ou chaves-externas (evita-se gerar tuplos que não deviam existir -- spurious tuples) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Desenho de BDs SGBD O-O ODL (object definition lang.) Relações Ideias (info a modelar) ER/EER (entidade/relacionamento) SGBD Relacional Conceptualização Implementação A modelação visa definir a estrutura da BDs antes da sua implementação, de forma a permitir a sua compreensão por parte dos utilizadores. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Bases de Dados orientadas a objectos Os modelos de BD relacionais, hierárquicos e de rede tem sido bem sucedidos nas aplicaçoes tradicionais que requerem recurso a BD’s. Aplicacoes mais complexas revelaram algumas falhas destes modelos: Telecomunicacoes Sistemas de Informaçao Geográfica Multimédia Problemas: Estruturas de objectos do mundo real mais complexas Transacçoes de longa duraçao Novos tipos de dados para representar imagens e outros objectos binários de grande dimensao (BLOB’s) Definiçao de operaçoes nao-standard para aplicaçoes específicas MI, MIAC 2002 Michel Ferreira, DCC - FCUP

BD’s orientadas a objectos (cont.) As BDOO permitem especificar num único processo de modelaçao a estrutura de objectos complexos bem como as operaçoes específicas aplicáveis a esses objectos. O crescente uso de linguagens de programaçao genéricas OO torna útil a existencia de SGBOO onde a integraçao de código seja facilitada. Os sistemas relacionais começam a incluir também conceitos OO – sistemas “object-relational” – extendendo-se ao SQL – SQL3. Alguns protótipos de SGBDOO: OPENOODB – Texas Instruments ODE – AT & T Bell Labs MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Conceitos de BDOO’s Identidade de objecto Identidade única de cada objecto do mundo real Identificador único (gerado pelo sistema) Imutável Usado uma única vez Independente de atributos Por vezes baseado no endereço físico Os primeiros modelos OO requeriam que tudo – desde um simples valor a um objecto complexo – fosse representado como um objecto: Inteiros, strings, valores Booleanos – tem um identificador de objecto. Nao é eficiente e os SBDOO distinguem entre objecto e valor. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Conceitos de BDOO’s (cont.) Estrutura de objecto O estado (valor actual) de um objecto complexo pode ser construído a partir de outros objectos (ou outros valores) usando construtores de tipo. Um objecto é formalmente representado por trio (i, c, v), onde i é um idenficador de objecto único, c é um construtor de tipo e v é o estado do objecto (ou valor corrente). Existem vários construtores de tipo: Atom Tuple Set List Bag Array O estado de um objecto, v, (i,c,v), é interpretado com base no construtor. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Estrutura de objecto Se o construtor c é atom o estado (valor) v é um valor atómico do domínio de valores básicos suportados pelo sistema (inteiros, strings, etc.). Se c = set, o estado v é um conjunto de identificadores de objecto, referenciando objectos que, tipicamente, sao do mesmo tipo. Se c = tuple, v é um tuplo da forma <a1:i1,a2:i2,...,an:in> onde cada ai é um nome de atributo e cada ii é um IDO. Se c = list, v é uma lista ordenada [i1,i2,...,in] de IDO’s do mesmo tipo. Os objectos podem ser estruturados arbitrariamente aplicando vários tipos de construtores. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Exemplos de objectos O1 = (i1, atom, ‘Houston’) O2 = (i2, atom, ‘Bellaire’) O3 = (i3, atom, ‘Sugarland’) O4 = (i4, atom, 5) O5 = (i5, atom, ‘Research’) O6 = (i6, atom, ‘1988-05-22’) O7 = (i7, set, {i1,i2,i3}) O8 = (i8, tuple, <DNAME:i5,DNUMBER:i4,MGR:i9,LOCATIONS:i7,EMPLOYEES:i10, PROJECTS:i11>) O9 = (i9, tuple, <MANAGER:i12,MANAGER_START_DATE:i6>) O10 = (i10, set, {i12,i13,i14}) O11 = (i11, set, {i15,i16,i17}) O12 = (i12, tuple, <FNAME:i18,MINIT:i19,LNAME:i20,SSN:i21,...,SALARY:i26, SUPERVISOR:i27,DEPT:i8>) ... MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Representaçao de um objecto complexo como um grafo MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Objectos identicos vs. iguais Dois objectos tem estados identicos (deep equality) se os grafos representando os seus estados sao identicos em todos os aspectos, incluindo os IDO’s em todos os níveis. Dois objectos tem estados iguais (shalow equality) se a estrutura dos seus grafos é a mesma e todos os valores atómicos no grafo sao também os mesmos. Exemplo: O1 = (i1, tuple, <a1:i4,a2:i6>) O2 = (i2, tuple, <a1:i5,a2:i6>) O3 = (i3, tuple, <a1:i4,a2:i6>) O4 = (i4, atom, 10) O5 = (i5, atom, 10) O6 = (i6, atom, 20) Os objectos O1 e O2 tem estados iguais, enquanto O1 e O3 tem estados identicos. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Linguagem de definiçao de objectos (ODL) Uma linguagem de definiçao de objectos que inclua os construtores de tipo descritos pode ser usada para definir os tipos de objectos de uma determinada aplicaçao de BD. Exemplo: Definiçao de estruturas de dados de um esquema de BD OO: define type Employee: tuple ( fname: string; minit: char; lname: string; ssn: string; birthdate: Date; address: string; sex: char; salary: float; supervisor: Employee; dept: Department; ); MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Encapsulamento Na declaraçao dos objectos é possível incluir a definiçao dos métodos aplicáveis sobre os objectos. Em BD relacionais um conjunto de operaçoes standard sao aplicáveis sobre todos os objectos (selecçao, inserçao, etc.). Exemplo: define class Employee: type tuple ( fname: string; minit: char; lname: string; ssn: string; birthdate: Date; address: string; sex: char; salary: float; supervisor: Employee; dept: Department; ); operations age: integer; create_emp: Employee; destroy_emp: boolean; end Employee; MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Object Definition Language Um standard definido pelo ODMG (bem como o OQL (questões)). Permite especificar a estrutura (esquema) da BDs. Não permite interrogar ou manipular a BDs Parece-se com C++ (e Smalltalk). O paradigma subjacente ao ODL é: Modelar objectos e suas propriedades. Objectos são identificados de forma única (OID), distinguindo-se de qualquer outro objecto. Para se atingir algum nível de abstracção: Agrupam-se os objectos em classes. O que é que determina uma boa classe? Os objectos devem ter propriedades comuns (e.g. clientes de um banco) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Declaração de Classes em ODL class <nome> { atributos: <tipo> <nome>; relacionamentos <intervalo-tipo> <nome>; métodos; } Classes definem um tipo abstracto de dados com: - atributos: propriedades que descrevem aspectos de um objecto por atribução de valores ou referencia a outro objecto; - relacionamentos: propriedades que correspondem a uma interacçao mútua entre objectos; - métodos (ou funções): que podem ser executados sobre objectos de uma classe. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Classes/Objectos em ODL class Filme { attribute string titulo; attribute integer ano; attribute integer duração; attribute enum Tfilme {cor, preto-e-branco} tipoFilme; }; um objecto da classe Filme é o tuplo: (“Hercules - Disney”, 1998, 94, cor) Os atributos podem não ser atómicos: class Actor { attribute string nome; attribute Struct End {string rua, string cidade} endereço; MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP ODL - exemplo ano duração título Filme tipo Actor rua endereço cidade nome MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos em ODL É natural que alguns atributos de objectos sejam referências para outros objectos da mesma ou de outras classes. Como representar num objecto da classe Filme, o conjunto de Actor(es) de um filme? Adiciona-se à classe Filme: relationship Set<Actor> actuam; Relacionamentos-inversos: representamos os actores de um dado filme, mas podemos estar também interessados nos filmes onde participa um dado actor. Adicionar à classe Actor: relationship Set<Filme> participa inverse Filme::actuam; Em ODL é necessário que os relacionamentos tenham inversa. Para cada objecto da classe Filme existe um conjunto de referências a objectos da classe Actor Se S  actuam para o filme F, Então F  participa para o Actor S MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Multiplicidade dos relacionamentos Para efeitos de relacionamento inverso, é importante saber a multiplicidade do relacionamento, i.e. se um dado objecto se relaciona com um único objecto, ou se se relaciona com muitos outros. Multiplicidades mais comuns: muitos-muitos (de C para D). Conjunto de D´s associado a cada C, e para a inversa tem-se um conjunto de C´s associado a cada D. muitos-um (de C para D). Para cada C existe um único D, e para a inversa tem-se que para cada D existe um conjunto de C´s. um-um (de C para D). Cada C está relacionado com um D e para a inversa, cada D relaciona-se com um único C. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP ODL - exemplo 2 ano duração título Filme tipo actuam participa Actor rua endereço cidade nome MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP ODL - exemplo ano duração tipo título Filme actuam pertence participa possui Actor tem Estúdio Presidente preside nome endereço nome endereço anoInic nome rua cidade MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Classes do exemplo class Filme { attribute string titulo; Arthur Keller – CS 180 Winter 2002 Classes do exemplo class Filme { attribute string titulo; attribute integer ano; attribute integer duração; attribute enum Tfilme {cor, preto-e-branco} tipo; relationship Set<Actor> actuam inverse Actor::participa; relationship Estúdio pertence inverse Estúdio::possui; }; class Actor { attribute string nome; attribute Struct End {string rua, string cidade} endereço; relationship Set<Filme> participa inverse Filme::actuam; class Estúdio { attribute string nome; attribute string endereço; relationship Set<Filme> possui inverse Filme::pertence; relationship Presidente tem inverse Presidente::preside; }; class Presidente { attribute string anoInic; relationship Estúdio preside inverse Estúdio::tem; MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Arthur Keller – CS 180 Winter 2002 Tipos em ODL Tipos básicos: tipos atómicos (string, integer, float, character, boolean,...) tipos interface (e.g., Filme, Actor), representam tipos mais complexos definidos como estruturas com base em constructores tipo. Constructors: Set: (1, 5, 6) Se T é um tipo, então Set<T> é o tipo cujos valores são todos conjuntos finitos de elementos do tipo T. Bag: (1, 1, 5, 6, 6 ) Admite elementos repetidos. List: (1, 5, 6, 1, 6 ) string  List<char> Array: Array<T,i> (T tipo, i inteiro) denota o tipo cujos elementos são vectores com i elementos do tipo T. Struct: Struct Morada {string rua, string cidade, integer código_postal} Tipo-conjunto MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Tipos admissíveis em ODL Arthur Keller – CS 180 Winter 2002 Tipos admissíveis em ODL Atributos: pode ser um tipo atómico ou struct; pode-se depois aplicar um tipo-conjunto ao tipo atómico ou struct. SIM: string, set of integer, bag of Actor NÃO: Filme, set of set of integer Um atributo não pode ser do tipo interface. Relacionamentos: pode ser um tipo interface ou um tipo-conjunto aplicado a um tipo interface. SIM: Filme, set of Filme, list of Filme NÃO: struct {Filme f, Actor a}, set of bag of Filme, set<integer>, integer Um relacionamento não pode ser do tipo atómico. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Correspondência entre ODL e ER Entidades tipo Classes Atributos Atributos Relacionamentos Relacionamentos No modelo ER, os relacionamentos tem apenas um nome nas duas direcções e podem envolver mais do que 2 entidades (no modelo ODL, não!). MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Subclasses Alguns objectos numa classe poderão ter propriedades não partilhadas por outros membros: Em ODL: interface Cartoon: Filme { relationship Set<Actor> vozes inverse ...; }; esta nova classe, além da propriedade vozes, herda ainda as propriedades da classe Filme; Filme Cartoons Policial MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Herança múltipla Filme Cartoon Policial Cartoon-Policial Quem tramou o Roger Rabit? uma subclasse herda todas as propriedades das suas superclasses. as subclasses de uma classe podem dar origem a novas subclasses, constituindo uma hierarquia de classes. uma classe pode ter mais do que uma superclasse. Interface Cartoon-Policial: Cartoon, Policial {}; MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Herança múltipla em ER Cartoon Policial Filme isa arma vozes Actor titulo ano duração tipo as hierarquias são representadas por relacionamentos ISA. A isa B - A é um caso especial de B; A é uma especialização de B; B é uma generalização de A. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Restrições para além das restrições de estrutura e de tipos de valores, modelada pelas classes (entidades), atributos e relacionamentos é necessário considerar outras restrições: chave conjunto de atributos que identificam de forma única um objecto ou entidade restrições de valor único e.g. especificar que uma pessoa pode apenas ter um pai restrições de integridade referencial um valor referenciado por um objecto tem de existir. restrições de domínio o valor de um atributo tem de pertencer a um conjunto de valores. e.g. idade de pessoas estão entre 0 e 150. restrições gerais asserções arbitrárias que têm de se verificar. e.g. podíamos querer não registar mais do que 10 actores por filme. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Chaves em ODL um objecto pode ter várias chaves. Exemplos: Interface Pessoa (key ncontrib) { propriedades... }; Interface Filme (key (titulo, ano)) {...}; Interface Empregado (key empID, empBI) {...}; Chave é atributo simples Chave é atributo composto 2 chaves MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Princípios para boa modelação fidelidade o modelo deve ser fiel ao mundo real os objectos (entidades) devem reflectir a realidade. Relacionamentos devem fazer sentido na parte do mundo em modelação evitar redundância usa mais espaço; sujeito a inconsistências. simplicidade conta evitar mais elementos do que é necessário. escolher o tipo de elemento certo por vezes pode usar-se um atributo ou uma entidade para representar um conceito se uma entidade possui apenas o nome, pode ser um atributo. Se possui mais informação deve ser entidade. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Exemplo Empregado-Departamento em ODL class Department (key numD) { attribute integer numD; attribute string name; attribute set <string> location; atribute struct Dep_Mgr{Employee manager, date start_date}; relationship Set<Employee> has_emps inverse Employee::works for; void add_emp(in_string new_ename) raises(ename_not_valid); } class Employee (key ssn) { attribute string name; attribute string ssn; ... attribute float salary; relationship Department works_for inverse Department::has_emps; void reassign_emp(in string new_dname) raises(dname_not_valid); }; Complete o modelo com as classes Projecto e Dependente. MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP O Modelo Relacional Modelo da Base de dados (ODL, ER) Esquema Relacional Espaço em Disco Tabelas: colunas: atributos linhas: tuplos Complexa organização em ficheiro e estruturas de índice Definições ODL Diagramas ER MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Do ODL para o Relacional As relações aproximam-se mais da implementação, pelo que: (ER, ODL) Caso simples: ODL classe com atributos de valor único. interface Filme { attribute string titulo; attribute integer ano; attribute integer duração; attribute enum {cor, preto-e-branco} tipo; }; Criar uma relação com o mesmo nome e atributos da classe. Filme( título, ano, duração, tipo) ou como tabela: ginástica mental Relacional Filme Título Ano Duração Tipo Zorro 1998 cor 120 MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Classes sem relacionamentos O ODL permite atributos que podem ser estruturas ou conjuntos Estruturas: criar um atributo para campo das estrutura. interface Actor { attribute string nome; Actor( Nome, Rua, Cidade) attribute Struct {string rua, string cidade} endereço; }; Conjuntos: criar um tuplo para cada valor do conjunto? attribute string nome; attribute Set< Struct {string rua, string cidade} > endereço; Nome Rua Cidade Harrison Ford 789 Palm Dr. Beverly Hills Harrison Ford 5th Avenue New York Problemas: mais do que um atributo-conjunto? Criar tuplos para todas as combinações. A classe pode não ter chave, mas a relação tem de ter! MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Michel Ferreira, DCC - FCUP Exemplo interface Actor { attribute string nome; attribute Set< Struct {string rua, string cidade} > endereço; attribute Date dataNasc; }; Nome Rua Cidade DataNasc Harrison Ford 789 Palm Dr. Beverly Hills 10/5/50 Harrison Ford 5th Avenue New York 10/5/50 Judy Foster 300 Stars Av. Beverly Hills 18/7/62 Redundância. Será grave? Vêr para N atributos do tipo Set e cada com M valores. Como modelar bags, lists, ou arrays? Bag<Struct {string rua, string cidade}> endereço; Actor(Nome,Rua,Cidade,NumVezes) List<Struct {string rua, string cidade}> endereço; Actor(Nome,Rua,Cidade,PosLista) Array< Struct {string rua, string cidade},2> endereço; Actor(Nome,Rua1,Cidade1,Rua2,Cidade2) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos de valor único interface Filme { attribute string titulo; attribute integer ano; attribute integer duração; attribute enumeration {cor, preto-e-branco} tipo; relationship Set<Actor> actuam inverse Actor::participa; relationship Estúdio pertence inverse Estúdio::possui; }; Como tratar o relacionamento pertence? Incluir na relação Filme os atributos da relação Estúdio? E como seria tratado o relacionamento inverso? Não. Proceder como com os relacionamentos um-um no modelo ER, i.e. incluir em Filme os atributos chave de Estúdio. interface Estúdio { attribute string nome; attribute string endereço; relationship Set<Filme> possui inverse Filme::pertence; }; MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos de valor múltiplo Como tratar o relacionamento actuam? Proceder como com os relacionamentos um-muitos ou muitos-muitos no ER... Seja A  B um relacionamento multivalor: 1. Determinar as chaves de A e de B. 2. Pegar na relação correspondente à classe do lado “muitos”, seja A, e pegar na chave de B e adicionar em A como atributos. 3. Se for muitos-muitos é necessário duplicar tuplos de A (como no ER); Pare evitar redundância, cria-se uma nova tabela com as chaves de A e de B. A relação Filme ficaria: filme(Título, Ano, Duração, Tipo, NomeEstúdio, NomeActor) (Um filme fica representado por tantos tuplos quantos os actores do filme! Redundância) evitando redundância: filme(Título, Ano, Duração, Tipo, NomeEstúdio) + filem-actor(Título,Ano,NomeActor) MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Subclasses  Relações Em ODL, um objecto pertence exactamente a uma classe (que herda as propriedades de todas as superclasses) criar uma relação para cada classe (subclasse) com todos atributos (incluindo os de herança) dessa classe. titulo ano duração Actor tipo Filme Cartoon(titlo, ano, duração, tipoF, NomesEst, NomeActor, voz) vozes isa Filme(título, ano, duração, tipoF NomesEst, NomeActor), isa arma Cartoon Policial MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos de Grau Superior a 2 (ER) envolve mais de duas entidades em geral, um relacionamento ternário representa mais informação do que 3 relacinamentos binários: Pnum Qtd Fornecedor Fnome Pnome Projecto Produto fornecimento Pnum Fnome Fornecedor M N fornece Projecto M M N pode_fornecer N usa Produto Pnome MI, MIAC 2002 Michel Ferreira, DCC - FCUP

Relacionamentos ternários --> binários fornecimento(f,p,j) tem significado diferente de fornece(f,j), pode_fornecer(f,p), usa(j,p) podemos converter um relacionamento-ternário em relacionamentos binários, sem perda de informção, representando o relacionamento-ternário como uma entidade-fraca. Fnome Qtd Pnum 1 N N 1 Fornecedor ff fornecimento fpj Projecto N fpr 1 Produto Pnome MI, MIAC 2002 Michel Ferreira, DCC - FCUP