Persistência entre. Clodis Boscarioli

Transcrição

1 Persistência entre Modelos de Dados Clodis Boscarioli

2 Agenda: Persistência (Conceitos) Sistemas de Banco de Dados Modelo Relacional; Normalização. Modelo Orientado a Objetos; Modelo Objeto-Relacional. Mapeamento Objeto-Relacional Introdução ao Hibernate.

3 Persistência É um tópico vital para o desenvolvimento de aplicações; Quase todas as aplicações necessitam que dados sejam persistidos; Necessidades: Armazenamento; Busca; Organização; Compartilhamento dos dados.

4 Persistência Necessidades: Integridade dos dados; Controle de concorrência. Desempenho e a escalabilidade são fortemente Desempenho e a escalabilidade são fortemente afetados pela estratégia de acesso a dados escolhida.

5 Sistemas de Banco de Dados Quando falamos Sistemas de BD, entendemos a junção de: Sistema Gerenciador de Banco de Dados; Banco de Dados.

6 Sistema Gerenciador de Banco de Dados Um Sistema Gerenciador de Banco de Dados (SGBD) é uma coleção de programas que habilitam usuários a criar e manter um banco de dados. O grande objetivo de um sistema de BD é oferecer uma visão abstrata dos dados, com disponibilidade eficiente, aos usuários. usuários PROGRAMAS SGBD Mundo real

7 Visão Geral de um SGBD Usuários navegantes Interface com aplicações Programadores de aplicações Programas de aplicações Usuários sofisticados Consultas (queries) Administradores de BD Esquema de Banco de Dados Usuários Processador de consultas Programas de aplicações em código objeto Pré-compilador de comandos DML Compilador DML Interpretador DDL SGBD Componentes de execução de consultas Gerenciador de memória Gerenciador de transações Gerenciador de buffer Gerenciador de arquivos Armazenamento em disco Arquivos de dados Índices Dados estatísticos Dicionário de dados BD

8 Banco de dados e Abstração de Dados Um dos maiores benefícios dos sistemas de banco de dados é proporcionar aos usuários uma visão abstrata dos dados. O sistema é capaz de ocultar alguns detalhes sobre a forma de armazenamento e a manutenção dos dados. A eficiência da recuperação de informações está relacionada à forma como as estruturas de representação são projetadas e, dado a complexidade e importância destas representações, elas devem ser protegidas em níveis de abstrações. Estes níveis facilitam a manutenção do sistema e a interação dos usuários com os sistemas. São eles: Nível de visão: O mais alto nível de abstração. Proporciona uma visão parcial do banco de dados. Diferentes visões são usadas por diferentes usuários. Nível lógico: Implica em definir quais dados serão armazenados e quais são os inter-relacionamentos existentes entre eles. Usado pelos administradores de banco de dados e programadores. Nível de visão Visão 1 Visão 2... Visão n Nível físico: Mais baixo nível de abstração. Implica em como os dados estão, de fato, armazenados (descrição em detalhes das estruturas de dados). Administradores de banco de dados devem ter noções da organização deste nível. Nível lógico Nível físico quais como

9 Modelos de Dados O Modelo de Dados é a principal ferramenta que fornece a abstração a um BD. É um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.

10 Esquema Geral de Modelagem de BD Fonte: Ferreira et. al, 2005

11 Modelagem Conceitual A base do modelo entidade-relacionamento, o modelo E-R (MER), é representar o mundo real por meio de conjuntos de objetos chamados entidades e relacionamentos. A junção ordenada/lógica destes tipos de objetos representa a estrutura/esquema do mundo real, ou seja, deve suportar o armazenamento de dados que reflitam a situação do mundo real. As três noções básicas empregadas pelo MER: Conjunto de entidades; Atributos; Conjunto de relacionamentos; Esse modelo possui recursos de Extensão (generalização, especialização e agregação).

12 O Conjunto de Entidades Segundo (Korth et. al, 2006): uma entidade é uma coisa ou um objeto do mundo real que pode ser identificada(o) de uma forma unívoca em relação a todos os outros objetos. cada entidade tem um conjunto de propriedades que assumem valores e, em alguns casos, assumem valores que devem ser únicos. uma entidade pode ser concreta, como uma pessoa ou um livro, ou pode ser abstrata, como um empréstimo ou uma viagem. um conjunto de entidades é o conjunto que abrange entidades de mesmo tipo e que compartilham as mesmas propriedades: os atributos. os conjuntos de entidades não são, necessariamente, conjuntos separados, ou, sempre disjuntos. Por exemplo: o conjunto de todos os clientes de um banco constituem o conjunto entidade cliente; o conjunto de todos os empregados do banco constituem o conjunto entidade empregado; a entidade pessoa pode pertencer ou ao conjunto cliente, ou ao conjunto entidade ou a ambos ou a nenhum deles.

13 Atributos Uma entidade é representada por um conjunto de atributos. Atributos são propriedades descritivas de cada membro de um conjunto de entidades e cada entidade tem seus próprios valores nos atributos. Para cada atributo existe um conjunto de valores possíveis, chamado domínio. Formalmente, um atributo de um conjunto de entidades é uma função que relaciona o conjunto de entidades a seu domínio. Cada entidade pode ser descrita pelo conjunto formado pelos pares (atributo-valor) referentes a cada atributo do conjunto em questão. Classes de Atributos: Simples; Compostos; Monovalorados; Multivalorados; Nulos; Derivados.

14 Conjuntos de Relacionamentos Um relacionamento é uma associação entre uma ou várias entidades. Exemplo: Um relacionamento que associa o cliente Hayes como empréstimo L-15 especifica que o cliente Hayes é o cliente que realizou o referido empréstimo. Um conjunto de relacionamentos é um conjunto de relacionamentos de mesmo tipo. Formalmente o relacionamento é uma relação matemática com n >= 2 (n = número de conjuntos entidades). Se E 1, E 2,..., E n são conjuntos de entidades, então um conjunto de relacionamentos R é um subconjunto de {(e 1,e 2,...,e 3 ) e 1 E 1, e 2 E 2,..., e n E n } em que (e 1,e 2,...,e 3 ) são relacionamentos. A associação entre os conjuntos de entidades é referida como uma participação: o conjunto de entidades E 1, E 2,..., E m participa do conjunto de relacionamentos R. Uma instância de relacionamento em um esquema E-R representa a existência de uma associação entre essas entidades no mundo real no qual se insere o domínio que está sendo modelado. Grau do relacionamento: o relacionamento binário (envolve dois conjuntos entidades) é um relacionamento de grau 2. E assim por diante.

15 Conjuntos de Relacionamentos Exemplo: Considere os conjuntos entidades cliente e empréstimo. Definimos o conjunto de relacionamentos devedor para denotar a associação entre clientes e empréstimos bancários contraídos pelos clientes. Jones Main Harrison Smith North Rye Hayes Main Harrison Jackson Dupont Woodside Curry North Rye Williams Nassau Princeton Adams Spring Pittsfield L L L L L L L

16 Conjuntos de Relacionamentos A função que uma entidade desempenha em um relacionamento é chamada papel. Algumas vezes o conjunto entidade pode participar de um conjunto relacionamento mais de uma vez em papéis diferentes e, nessas situações, o papel é importante para interpretação do modelo. Exemplo: Em relacionamentos recursivos, nomes explícitos de papéis são necessários para especificar como uma entidade participa de uma instância de relacionamento. Considere o conjunto de entidades empregado. Podemos ter um conjunto de relacionamentos trabalha_para que é modelado para ordenar os pares de entidades de empregado numa relação de hierarquia de cargos. Neste exemplo, os relacionamentos de trabalha-para são caracterizados pelos pares (gerente,empregado). Atributos descritivos em relacionamentos: atributos podem fazer parte de conjuntos relacionamentos para melhor descrever o mundo real. Exemplo: a data de último acesso em um conta bancária.

17 Mapeamento de Restrições Mapeamento das cardinalidades expressa o número de entidade às quais outra entidade pode estar associada via um conjunto de relacionamentos. Um para um: uma entidade em A está associada no máximo a uma entidade em B, e uma entidade em B está associada a no máximo uma entidade em A. Um para muitos: Uma entidade em A está associada a várias entidades em B. Uma entidade em B deve estar associada no máximo a uma entidade em A. Muitos para um: Uma entidade em A está associada a no máximo uma entidade em B. Uma entidade em B, pode estar associada a um número qualquer de entidades em A. Muitos para muitos: Uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A.

18 Interpretação: Aluno 1 1 Curso Aluno 1 N Curso Aluno N 1 Curso Aluno N M Curso Conjunto relacionamento: Participa

19 Mapeamento de Restrições Dependência de Existência Se a existência da entidade X depende da existência da entidade Y, então X é dito dependente da existência de Y. Operacionalmente, se Y deixar de existir, conseqüentemente, X deve deixar de existir. Exemplo: Considere o conjunto de entidades empréstimo e o conjunto de entidades pagamento (que mantém todas as informações sobre os pagamentos realizados para um determinado empréstimo). O conjunto de entidades empréstimo é considerado dominante e o conjunto de entidades pagamento é considerado subordinado. Se todas as entidades de um conjunto participam de pelo menos um relacionamento R, este é dito total, se apenas algumas das entidades do conjunto participam do relacionamento, então este é dito parcial. A participação total está estreitamente relacionada à existência de dependência. Para haver dependência de existência, a participação da entidade subordinada ao relacionamento correspondente deve ser total.

20 Chaves Por meio de chaves podemos diferenciar as diversas entidades pertencentes a um conjunto de entidades, e os diversos relacionamentos pertencentes a um conjunto de relacionamentos. Conjuntos de Entidades Superchave: conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira unívoca uma entidade em um conjunto de entidades. Chaves candidatas: Superchaves para as quais nenhum subconjunto possa ser uma superchave. Chave primária: chave candidata escolhida pelo projetista de banco de dados como a chave de significado principal para a identificação de entidades dentro de um conjunto de entidades. Uma chave é uma propriedade do conjunto de entidades e não de uma entidade individualmente. Quaisquer duas entidades individuais em um conjunto não podem ter, simultaneamente, mesmos valores em seus atributos-chave. A especificação de uma chave representa uma restrição ao mundo real do domínio que está sendo modelada.

21 Chaves Conjuntos de relacionamentos: A composição da chave primária para um conjunto de relacionamentos depende de uma estrutura de atributos associada ao conjunto de relacionamentos de R. Se o conjunto de relacionamentos não possui atributos então uma superchave deve ser formada pelas chaves de cada entidade participante do relacionamento. Se o conjunto de relacionamentos possui atributos então uma superchave deve ser formada pelas chaves de cada entidade participante do relacionamento mais o conjunto de atributos deste. A estrutura da chave primária para o conjunto de relacionamentos depende do mapeamento da cardinalidade do conjunto. Muitos para muitos: união das chaves da entidade + atributos descritivos; Muitos para um ou um para muitos: chave da entidade do lado do muitos + atributos descritivos Um para um: qualquer umas das chaves primárias pode ser usada.

22 Projeto de um Esquema de BD Fases do projeto: Levantamento de requisitos: quais são as necessidades dos usuários do BD e como este BD será estruturado; Construção do projeto conceitual: transcrever as necessidades especificadas para um esquema conceitual de BD (MER); Especificação das necessidades funcionais: descrever as transações que serão realizadas sobre os dados; Projeto lógico e físico: mapeamento do projeto conceitual para o modelo de implementação de dados no SGBD.

23 Modelo de Dados Relacional O Modelo Relacional (MR) é considerado o primeiro modelo de dados efetivamente usado em aplicações comerciais. Foi introduzido por Codd em É o modelo que possui a base mais formal entre os modelos de dados, entretanto, é o mais simples e com estrutura de dados mais uniforme.

24 MR - Estrutura Básica Um banco de dados relacional consiste de uma coleção de tabelas de nomes únicos. Cada tabela possui um conjunto de linhas que representa um relacionamento entre um conjunto de valores. O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática de onde se origina o nome deste modelo. Uma tabela é formada por um conjunto de colunas denominadas de atributos e por um conjunto de linhas denominadas de tuplas. Para cada atributo existe um conjunto de valores permitidos, chamado de domínio.

25 MR - Formalmente... Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio do atributo A2 e... Dn denote o domínio do atributo Na da tabela T1. Qualquer linha da tabela que possui estes atributos é denotada pela tupla (d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn. Em geral, uma instância de T1 é um subconjunto de D1 X D2 X... X Dn. Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios.

26 As 12 Regras de Codd Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o quanto um banco de dados é relacional. Algumas vezes as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas.

27 As 12 Regras de Codd 1. Regra das informações em tabelas: As informações a serem armazenadas no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns. Isso se aplica tanto aos dados quanto aos metadados (que são descrições dos objetos do banco de dados).

28 As 12 Regras de Codd 2. Regra de acesso garantido: Para que o usuário possa acessar as informações contidas no banco de dados, o método de referência deve ser o nome da tabela, o valor da chave primária e o nome do campo/coluna.

29 As 12 Regras de Codd 3. Regra de tratamento sistemático de valores nulos: O SGBD deve ser capaz de tratar valores que não são fornecidos pelos usuários, de maneira que permita a distinção de dados reais. Valores nulos devem ter um tratamento diferente de valores em branco.

30 As 12 Regras de Codd 4. Regra do catálogo relacional ativo: Toda a estrutura do banco de dados (domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em tabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de linguagens específicas. Essas tabelas são, geralmente, manipuladas pelo próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de dados.

31 As 12 Regras de Codd 5. Regras de atualização de alto-nível: Essa regra diz que o usuário deve ter capacidade de manipular as informações do banco de dados em grupos de tuplas (registros), ou seja, ser capaz de inserir, alterar e excluir várias tuplas ao mesmo tempo.

32 As 12 Regras de Codd 6. Regra de sub-linguagem de dados abrangente: Pelo menos uma linguagem deve ser suportada, para que o usuário possa manipular a estrutura do banco de dados (como criação e alteração de tabelas), bem como extrair, inserir, atualizar ou excluir dados, definir restrições de acesso e controle de transações (commit e rollback, por exemplo). Deve ser possível ainda a manipulação dos dados por meio de programas aplicativos.

33 As 12 Regras de Codd 7. Regra de independência física: Quando for necessária alguma modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser necessária nas aplicações que fazem uso do banco de dados. Também devem permanecer inalterados os mecanismos de consulta e manipulação de dados utilizados pelos usuários finais.

34 As 12 Regras de Codd 8. Regra de independência lógica: Qualquer alteração efetuada na estrutura do banco de dados como inclusão ou exclusão de atributos de uma tabela ou alteração no relacionamento entre tabelas não deve afetar o aplicativo que o usa. Da mesma forma, o aplicativo somente deve manipular visões dessas tabelas.

35 As 12 Regras de Codd 9. Regra de atualização de visões: Uma vez que as visões dos dados de uma ou mais tabelas são, teoricamente suscetíveis atualizações, um aplicativo que faz uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões. Essas atualizações, no entanto, devem ser repassadas automaticamente às tabelas originais.

36 As 12 Regras de Codd 10. Regra de independência de integridade: As várias formas de integridade de banco de dados (integridade de entidade, integridade referencial, restrições, obrigatoriedade de valores, etc) precisam ser estabelecidas dentro do catálogo do sistema ou dicionário de dados, e ser totalmente independentes da lógica dos aplicativos.

37 As 12 Regras de Codd 11. Regra de independência de distribuição: Alguns SGBDs, notadamente os que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentos que se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados.

38 As 12 Regras de Codd 12. Regra não-subversiva: O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema.

39 Estrutura Básica Um banco de dados relacional consiste de uma coleção de relações (tabelas) de nomes únicos. Cada tabela possui um conjunto de linhas que representa um relacionamento entre um conjunto de valores. O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática de onde se origina o nome deste modelo. Uma tabela é formada por um conjunto de colunas denominadas de atributos e por um conjunto de linhas denominadas de tuplas. Para cada atributo existe um conjunto de valores permitidos, chamado de domínio.

40 Relação Suponha que D1 denote o domínio do atributo A1, D2 denote o domínio do atributo A2 e... Dn denote o domínio do atributo N da tabela T1. Qualquer linha da tabela que possui estes atributos é denotada pela tupla (d1,d2,...,dn) em que d1, d2 e dn estão, respectivamente em D1, D2 e Dn. Em geral, uma instância de T1 é um subconjunto de D1 X D2 X... X Dn. Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios. O grau de uma relação é o número de atributos que a compõe.

41 Particularidades Atomicidade de atributo = primeira forma normal. Modelo relacional plano. O valor null. As relações interpretam/representam fatos sobre entidades e fatos sobre relacionamentos. Linguagem de consulta SQL.

42 Exercício: Interprete o MER e crie um MR correspondente.

43 Representação Tabular de Atributos Multivalorados Para um atributo multivalorado M, cria-se uma tabela T com uma coluna C que corresponde a M e as colunas correspondentes à chave primária do conjunto de entidades ou do conjunto relacionamento do qual M é atributo. No exemplo da localização de departamento: cada elemento da nova tabela é uma localização de um departamento.

44 Representação Tabular da Generalização Para a situação: num_conta saldo conta tx_juros ISA limite conta_poup conta_mov

45 Representação Tabular da Generalização Criar uma tabela para o conjunto de entidades de nível superior. Para cada conjunto de entidades de nível inferior, criar uma tabela que inclua: Uma coluna para cada um dos atributos daquele conjunto de entidades Uma coluna para cada atributo da chave primária do conjunto entidades de nível superior. Assim: conta, com os atributos número_conta e saldo conta_poupança, com os atributos número_conta e taxa_juros conta_movimento, com os atributos número_conta e limite_cheque_especial

46 Representação Tabular da Generalização Se a generalização é mutuamente exclusiva: nenhuma entidade é membro de mais de um conjunto de entidades de nível imediatamente inferior ao conjunto de entidades de nível superior; e todas as entidades do conjunto de entidades de nível superior são membro também de um dos conjuntos de entidades de nível inferior. Para cada conjunto de entidades de nível inferior, cria-se uma tabela que inclua uma coluna para cada um dos atributos deste conjunto de entidades mais uma coluna para cada atributo do conjunto de entidades de nível superior Assim: conta_poupança, com atributos número_conta, saldo e taxas_juros; conta_movimento, com os atributos número_conta, saldo e limite_cheque_especial

47 Representação Tabular da Agregação Relembrando... nome seguro rua cidade número saldo cliente devedor empréstimo Agente_ emp empregado seguro nome telefone

48 Representação Tabular da Agregação A tabela para o conjunto de relacionamentos agente_empréstimo inclui uma coluna para cada atributo, uma para chave primária do conjunto de entidades empregado e uma para o conjunto de relacionamentos devedor. Poderia também incluir uma coluna para cada um dos atributos descritivos descritivos do conjunto de relacionamentos agente_empréstimo, se eles existirem. Assim: cliente, com os atributos nome_cliente, seguro_cliente, rua, cidade; empréstimo, com os atributos número_empréstimo, total; devedor, com os atributos seguro_cliente, número_empréstimo; empregado, com os atributos seguro_empregado, nome_empregado, número_telefone; agente_empréstimo, com os atributos seguro_empregado, número empréstimo e seguro_cliente.

49 Diretriz de Projeto nº 1: Modelar um esquema de relação de modo que seja fácil explicar seu significado. Se uma relação corresponde a uma mistura de entidades e relacionamentos, resultarão em ambigüidades semânticas e a relação não poderá se explicada facilmente. Esquemas pobres porque violam a Diretriz 1: Emp_dept: enome, ssn, datanasc, endereco, dnumero, dnome, dgerssn. Emp_proj: ssn, pnumero, horas, enome, pnome, plocalização.

50 Redução de Valores Redundantes nas Tuplas Deve-se minimizar o espaço de armazenamento utilizado pelas relações básicas: Agrupe atributos em esquemas de relações; Deve-se evitar situações que caiam em problemas de Anomalias na Atualização.

51 Diretriz Projeto nº 2: Modelar esquemas de relações básicas de forma que nenhuma anomalia de atualização possa ocorrer nas relações. Se houver a possibilidade de ocorrer alguma anomalia, registre-a claramente e tenha certeza de que os programas que atualizam o banco de dados operarão corretamente. Pode-se violar uma diretriz em prol do desempenho de uma consulta, entretanto, as medidas cabíveis devem ser tomadas para que os dados estejam sempre consistentes e íntegros.

52 Redução de Valores null nas Tuplas A existência de muitas possibilidades de uso do valor null causa desperdício de espaço no armazenamento e gera problema de entendimento do significado do atributos e da especificações de joins, e funções agregadas. Motivos para uso do null: O atributo não se aplica à tupla; O valor do atributo para a tupla é desconhecido; O valor do atributo para a tupla é conhecido, mas ausente, ou seja, ainda não foi registrado.

53 Diretriz Projeto nº 3: Até onde for possível, evite colocar os atributos em uma relação básica cujos valores freqüentemente possam ser nulos. Se os nulls forem inevitáveis, tenha certeza de que eles se aplicam somente em casos excepcionais e não na maioria das tuplas da relação. Ex: se só 10% dos empregados tiverem escritórios particulares, há pouca justificativa para incluir um atributo ESCRITORIO-NRO na relação EMPREGADO; pode ser criada uma relação EMP_ESCRITÖRIOS (ESSN, ESCRITORIO_NRO) que contenha apenas as tuplas dos empregados que possuírem escritórios particulares.

54 Impedimento para a Geração de Valores Ilegítimos nas Tuplas Considere os esquemas: Esquema 1: Emp_locs (enome, plocalização) Emp_proj1 (ssn, pnumero, horas, pnome, plocalização) Esquema 2: Emp_proj: (ssn, pnumero, horas, enome, pnome, plocalização) A partir do esquema 1 é possível conseguir as mesmas informações que temos no esquema 2? Não, usando um JOIN conseguiremos tuplas ilegítimas.

55 Diretriz Projeto nº 4: Projete os esquemas de relações de forma que possam ser unidos (join) com igualdade de condições sobre os atributos que sejam chaves primárias ou chaves estrangeiras, de modo a garantir que nenhuma tupla ilegítima seja gerada.

56 Normalização A normalização de dados pode ser vista como o processo de análise de determinados esquemas de relações com base em suas dependências funcionais e chaves primárias para alcançar as propriedades desejáveis: Minimização de redundâncias; Minimização de modificações. O esquemas de relações insatisfatórias, que não alcançam certas condições os testes de forma normal -, são decompostas em esquemas de relações menores que passam nos testes e, conseqüentemente, possuem as propriedades desejadas.

57 Conceitos A forma normal de uma relação refere-se à condição da mais alta forma normal alcançada e, conseqüentemente, indica o grau no qual foi normalizada. A normalização sempre deve estar acompanhada da garantia de duas propriedades: Junção sem perdas: Garante que o problema de geração de tuplas ilegítimas não ocorra (propriedade crítica que deve sempre ser garantida); Preservação de dependências: Garante que cada dependência funcional será representada em alguma relação individual resultante da decomposição.

58 Primeira Forma Normal (1NF) Impedimento para a criação de atributos multivalorados, atributos compostos e combinações entre eles. Estabelece-se que o domínio de um atributo só deva incluir os valores atômicos e que o valor de qualquer atributo em uma tupla deve ter um único valor no domínio daquele atributo. A 1NF impede as relações dentro de relações ou relações como valores de atributos dentro de tuplas.

59 Primeira Forma Normal Considerando o departamento que possui um atributo multivalorado: localizações. Há três técnicas básicas para alcançar a primeira forma normal: 1. Remover o atributo DLocalizações que viola a 1NF e colocá-lo em uma 1. Remover o atributo DLocalizações que viola a 1NF e colocá-lo em uma relação separada, junto com a chave primária que identifica a entidade departamento. 2. Ampliar as chaves de forma a separar as tuplas da relação original DEPARTAMENTO, criando uma para cada localização de departamento. 3. Se um número máximo de valores puder ser estabelecido para o atributos, por exemplo, se é sabido que há no máximo três locais para cada departamento, substituir o atributo Dlocalizações por três atributos atômicos.

60 Segunda Forma Normal (2NF) Baseada no conceito de dependência funcional total. Uma dependência funcional X Y será uma dependência funcional total se a remoção de qualquer atributo A de X implicar que a dependência não mais será assegurada, isto é, para qualquer atributo A X, (X {A}) não determina funcionalmente Y. Uma dependência funcional X Y é uma dependência parcial se um atributo A X puder ser removido de X e a dependência mesmo assim continuar existindo, ou seja, para algum A X, (X {A}) Y.

61 Segunda Forma Normal Exemplo de dependências funcionais totais e parciais: Considere o esquema: SSN, PNumero, Horas, Enome, Pnome, Plocalização {SSN, PNumero} Horas: é uma dependência funcional total (não são asseguradas nem SSN Horas nem PNumero Horas). {SSN, PNumero} Enome: é uma dependência funcional parcial porque SSN Enome é assegurada.

62 Segunda Forma Normal Um esquema de relação R está na 2NF se todo atributo não primário A em R tem dependência funcional total da chave primária de R. O teste para a 2NF envolve verificar se os atributos do lado esquerdo das dependência funcionais fazem parte da chave primária. Se a chave primária contiver um único atributo, a necessidade do teste não se aplica. A relação do slide anterior está na 1NF mas não está na 2NF. O atributo não primário enome viola a 2NF em razão da dependência funcional SSN Enome. Enome é parcialmente dependente da chave primária (já que depende de SSN).

63 Segunda Forma Normal Um esquema pode ser normalizado na 2NF por meio da criação de várias relações na 2NF nas quais os atributos não primários só estarão associados a dependências funcionais total. Considere o esquema abaixo e suas dependências funcionais: SSN, PNumero, Horas, Enome, Pnome, Plocalização SSN, PNumero Horas SSN Enome PNumero Pnome, Plocalização

64 Segunda Forma Normal Normalizando, cria-se três esquemas: Esquema1: SSN, Pnumero, Horas com a dependência funcional: SSN, PNumero Horas Esquema 2: SSN, Enome com a dependênia funcional: SSN Enome Esquema 3: PNumero, Pnome, Plocalização com a dependência funcional: PNumero Pnome, Plocalização

65 Terceira Forma Normal (3NF) De acordo com a definição original de Codd, um esquema de relação R está na 3NF se satisfizer a 2NF e se nenhum atributo não primário de R for transitivamente dependente da chave primária. Está baseada no conceito de dependência transitiva. Uma dependência funcional X Y, em um esquema de relação R, será uma dependência transitiva se existir um conjunto de atributos Z que não é nem uma chave candidata nem um subconjunto de qualquer chave de R, e ambas X Z e Z Y forem asseguradas.

66 Terceira Forma Normal Como exemplo, considere o seguinte esquema com sua dependências funcionais: Enome, SSN, DataNasc, Endereço, Dnumero, Dnome, DgerSSN SSN Enome, DataNasc, Endereco, DNumero DNumero Dnome, DgerSSN A dependência funcional SSN DgerSSN é transitiva para Dnumero, pois ambas as dependências SSN Dnumero e Dnumero DgerSSN são asseguradas e Dnumero não é nem chave primária nem um subconjunto da chave da relação.

67 Terceira Forma Normal A normalização na 3NF para o exemplo se dá por meio da decomposição: Esquema 1: Enome, SSN, DataNasc, Endereço, Dnumero com a dependência funcional: SSN Enome, DataNasc, Endereco, DNumero Esquema 2: Dnumero, Dnome, DgerSSN com a dependência funcional: DNumero Dnome, DgerSSN

68 Generalização As definições tratadas até aqui dizem respeito a parcialidade e transitividade de dependencias funcionais com respeito à chave primária da relação. Estas definições devem ser expandidas para a consideração de todas as chaves candidatas. 2NF: um esquema de relação R está na segunda forma normal se cada atributo não primário A de R não forem parcialmente dependente de nenhuma chave de R. 3NF: um esquema de relação R está na terceira forma normal se sempre que uma depependência funcional não trivial X A for determinada em R, então: (A) qualquer X é uma superchave de R; ou (B) A é um atributo primário de R.

69 Mais um exemplo: Esquema Lotes: Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preço, Imposto Dependências funcionais: DF 1: Num_ID_Propriedade Municipio_nome, Num_lote, Area, Preço, Imposto DF 2: Municipio_nome, Num_lote Num_ID_Propriedade, Area, Preço, Imposto DF 3: Municipio_nome Imposto DF 4: Area Preço

70 Colocando na 2NF: O esquema de relação Lotes viola a definição GERAL da 2NF porque Imposto é parcialmente dependente da chave candidata {Municipio_nome, Num_lote} em razão da terceira dependência funcional. Construímos então o esquema Lotes 1 removendo o atributo Imposto que viola a 2NF de Lotes, para colocá-lo com Municipio_nome em outro esquema: Lotes 2. Lotes1 : Num_ID_Propriedade, Municipio_nome, Num_lote, Area, Preço Com as DFs 1, 2 e 4 Lotes2: Municipio_nome, Imposto Com a DF 3. Note que a DF 4 não viola a 2NF.

71 Colocando na 3NF: Lotes2 está na 3NF. Lotes1 não está pois a dependência funcional 4 viola a definição GERAL. Área não é uma superchave; Preço não é um atributo primário em Lotes1. Construímos: Lotes1a: Num_ID_Propriedade, Municipio_nome, Num_lote, Area Com as DFs 1 e 2. Lotes1b: Area, Preço Com a DF 4.

72 Forma Normal de Boyce-Codd (BCNF) Foi proposta como uma forma normal mais simples de 3NF, mas é considerada mas rígida que a 3NF. Toda relação BCNF está também em 3NF, mas o contrário pode não ser verdadeiro. Definição: Um esquema de relação R está na BCNF sempre que uma dependência funcional não trivial X A for mantida em R, então X será uma superchave de R.

73 BCNF Suponha a seguinte situação para o último exemplo modelado: Existem milhares de lotes cadastrados mas eles estão localizados em apenas duas cidades. E as áreas dos lotes nas duas cidades são definidas de formas diferentes. Assim, a dependência funcional Area Municipio_nome deveria valer. Ainda assim, Lotes1a estaria na 3NF, pois Municipio_nome é um atributo primário.

74 BCNF Mas existe redundância de informação, pois a área que determina o município, como dito pela nova dependência funcional, pode ser representada uma única vez, em uma relação a parte. A BCNF sugere a decomposição do esquema Lotes1a em: Lotes1ax : Num_ID_propriedade, Area, Num_lote com as DFs 1 e 2. Lotes1ay : Area, Municipio_nome com a DF 5. Cuidado com a decomposição com perdas na junção!

75 BCNF - Exemplos Relembrando: Uma relação R está na BCNF sse R está na 3NF e nenhum atributo possua dependência transitiva em relação à chave primária. Exemplo: Relação CURSA ALUNO DISCIPLINA TUTOR Nagiza Banco de Dados I Korth Silvio Banco de Dados I Navathe Silvio Banco de Dados II Setzer Silvio Data Mining Duhran William Banco de Dados I Korth William Banco de Dados II Elmasri Zélia Banco de Dados I Date Camila Banco de Dados I Navathe

76 BCNF - Exemplo Primeiro, têm-se que identificar as DF envolvendo atributos que pertençam a chave primária. Tutor Disciplina Aluno, Disciplina Tutor Há dependência transitiva da chave primária! Relação CURSA ALUNO DISCIPLINA TUTOR A relação acima está na 3NF e na BCNF?

77 BCNF - Exemplo A relação está na 3NF pois possui somente atributos atômicos, não apresenta dependência parcial da chave primária e não existem DFs de um atributo não pertencente a chave primária em relação a atributos não pertencentes à chave primária. Porém, não está na BCNF pois possui dependência transitiva de um atributo chave com relação à chave primária. A solução seria separar a relação em duas ou mais relações, de forma a eliminar a dependência transitiva: Tutoria (Tutor, Disciplina) Cursa(Tutor, Aluno)

78 BCNF Outro Exemplo Considere a relação orientador abaixo. Suponha que as exigências básicas dessa relação sejam: Um aluno (IDAL) pode ter mais que uma especialização, uma especialização pode ter vários membros do corpo docente (Fnome) como orientadores e um professor orienta somente em uma área de especialização.

79 BCNF Outro Exemplo Relação Orientador IDAL Especialização Fnome 100 Matemática Caughy 150 Psicologia Jung 200 Matemática Riemann 250 Matemática Caughy 300 Psicologia Perls 300 Matemática Riemann DF: Fnome Especialização

80 BCNF Outro Exemplo Há nessa relação uma anomalia de eliminação (por exemplo, se o aluno 300 sair da escola e se seus registros forem apagados, perde-se o fato de que Perls orienta em psicologia) e existe também uma anomalia de inserção (Não se pode armazenar um orientador em uma área, a não ser que um aluno se especialize na cadeira).

81 BCNF Outro Exemplo Relação Al_Orient Relação Orient_Discip IDAL Fnome Fnome Especialização 100 Caughy 150 Jung 200 Riemann 250 Caughy Caughy Jung Riemann Perls Matemática Psicologia Matemática Psicologia 300 Perls 300 Riemann Agora sim, está na BCNF.

82 Dependência Multivalorada Dada uma relação qualquer com três atributos x, y e z, dizse que y depende de forma multivalorada de x sse sempre que existirem duas tuplas (x1,y1,z1) e (x1,y2,z2) existirão também duas tuplas (x1,y1,z2) e (x1,y2,z1). Refere-se à combinação de valores de atributos multivalorados disjuntos (y e z). x na verdade, relaciona-se com y e com z de forma independente.

83 4ª Forma Normal (4NF) Uma tabela está na 4FN sse estiver na 3FN e não existirem dependências multivaloradas. Exemplo: Dados sobre livros Relação não normalizada: Livros(nrol, (autor), título, (assunto), editora, cid_edit, ano_public) 1FN: Livros(nrol, autor, assunto, título, editora, cid_edit, ano_public) 2FN: Livros(nrol,título, editora, cid-edit, ano_public) AutAssLiv(nrol, autor, assunto) 3FN: Livros(nrol, título, editora, ano_public) Editoras(editora, cid-edit) AutAssLiv(nrol, autor, assunto)

84 4ª Forma Normal (4NF) Nrol Autor Assunto 1 aut1 ass1 1 aut1 ass2 1 aut2 ass1 1 aut2 ass2 2 aut1 ass3 2 aut1 ass4 2 aut1 ass1 2 aut3 ass3 2 aut3 ass4 2 aut3 ass1 Redundância para representar todas as informações; Evitar todas as combinações: representação não-uniforme (repete alguns elementos ou posições nulas).

85 Passagem à 4FN Geração de novas tabelas, eliminando Dependências Multivaloradas Análise de Dependências Multivaloradas entre atributos: autor, assunto Dependência multivalorada de nrol Resultado: 4FN: Livros(nrol, título, editora, ano_public) Editoras(editora, cid-edit) AutLiv(nrol, autor) AssLiv(nrol, assunto)

86 4ª Forma Normal Outro Exemplo Relação Aluno IDAL Especialização Atividade 100 Música Natação 100 Contabilidade Natação DF múltiplas: IDAL Especialização IDAL Atividade 100 Música Tênis 100 Contabilidade Tênis 150 Matemática Jogging

87 4ª Forma Normal Outro Exemplo IDAL Relação Aluno Especializaçã o Atividade 100 Música Natação 100 Contabilidade Natação 100 Música Tênis 100 Contabilidade Tênis 150 Matemática Jogging 100 Música Esqui IDAL Relação Aluno Especializaçã o Atividade 100 Música Natação 100 Contabilidade Natação 100 Música Tênis 100 Contabilidade Tênis 150 Matemática Jogging 100 Música Esqui 100 Contabilidade Esqui Ao inserir nova atividade ao aluno 100 com a especialização música, deve-se inserir também outra tupla, o que mostra uma anomalia de atualização.

88 4ª Forma Normal Outro Exemplo Relação Al_Espec Relação Al_Ativ IDAL Especialização IDAL Atividade 100 Música 100 Contabilidade 150 Matemática 100 Esqui 100 Natação 100 Tênis 150 Jogging Agora sim, está na BCNF, sem dependências multivaloradas!

89 5ª Forma Normal (5NF) Uma tabela está na 5FN sse estiver na 4FN e um relacionamento triplo não puder ser decomposto em relacionamentos binários sem geração de informação incorreta. Caso especial: Relacionamento envolvendo Chaves primárias de 3 tabelas, que nem sempre é possível decomposição correta. Exemplo: relacionamento Agente-Companhia-Produto Agente Companhia Produto João Ford Carro João GM Caminhão

90 5ª Forma Normal Formato necessário quando existem apenas algumas combinações entre os 3 atributos (tabela c/ tripla). Situação: Se um agente vende um certo produto e ele Situação: Se um agente vende um certo produto e ele representa uma companhia, então ele vende um produto fabricado por esta companhia Todos os pares se combinam!

91 5ª Forma Normal Agente Companhia Produto João Ford Carro João Ford Caminhão João GM Carro João GM Caminhão Carlos Ford Carro Neste caso, é possível decompor uma tripla em três relações binárias com eliminação de certas redundâncias.

92 5ª Forma Normal As três relações abaixo estão na 5FN: Agente Companhia Agente Produto Companhia Produto João Ford João Carro Ford Carro João Carlos GM Ford João Carlos Caminhão Carro Ford GM GM Caminhão Carro Caminhão Eliminação de certas redundâncias: - Apenas uma vez está dito que Ford produz carros; - Apenas uma vez está dito que João é agente da GM. Apesar do aumento no número de tabelas, o número total de tuplas na forma normalizada é menor.

93 Banco de Dados Orientado a Objetos - Motivações Novas aplicações ficaram limitadas por restrições impostas pelo modelo relacional. As aplicações convencionais possuem características comuns que as tornam passíveis de serem tratadas por bancos de dados relacionais: Uniformidade: as informações a serem armazenadas podem ser estruturadas de maneira similar. Orientação a registros: registros de tamanho fixo são adequados para a representação desta informação. Itens de dados pequenos: as informações são estruturadas em registros pequenos. Campos atômicos: os campos dentro de um registro são pequenos e de comprimento fixo. Não há estruturas dentro dos campos, ou seja, a primeira forma normal pode ser mantida. O modelo de banco de dados orientado a objetos está baseado no paradigma de programação orientada a objeto.

94 Introdução e Motivações As aplicações mais novas, em geral, não possuem, no mínimo, uma das características já citadas. Exemplos dessas aplicações: Computer-aided design (CAD) projeto auxiliado por computador: É necessário armazenar os dados pertencentes a um projeto de engenharia, incluindo os componentes do item que está sendo projetado, o inter-relacionamento dos componentes, as versões antigas do projeto. Computer-aided software engineering (CASE) engenharia de software auxiliada por computador: É necessário armazenar os dados necessários para apoiar os desenvolvedores de software, incluindo o código-fonte, as dependências entre os módulos de software, as definições e o uso de variáveis e o histórico de desenvolvimento do sistema de software.

95 Introdução e Motivações Bancos de dados multimídia: Contém imagens, dados espaciais, dados de áudio, dados de vídeo e afins (envolvem principalmente o armazenamento de fotografias e dados geográficos, voz e vídeo). Office information system (OIS) sistemas de informação de escritório: Necessidade de suportar dados para ferramentas para criação e recuperação de documentos e ferramentas para manutenção de calendários, permitindo solicitações pertencentes a agendas, documentos e conteúdos de documentos. Bancos de dados de hipertexto: Necessidade de suportar o armazenamento/gerenciamento das estruturas específicas e indexação de textos enriquecidos com links que apontam para outros documentos, permitindo a recuperação de documentos baseados em sua estrutura.

96 Modelagem de BDOOs Isso:

97 Modelagem de BDOOs Ao invés disso:

98 O Modelo de Dados Orientado a Objeto A estrutura objeto: Superficialmente, um objeto corresponde a uma entidade no modelo E-R. Este paradigma se baseia no encapsulamento de dados e em código relacionado a um objeto dentro de uma única unidade. As interações entre um objeto e o resto do sistema deve ser via mensagens. Uma interface entre um objeto e o resto do sistema deve ser definida por um conjunto de mensagens permitidas. Em geral, um objeto tem associado a ele: Um conjunto de variáveis que contém os dados para o objeto; as variáveis correspondem aos atributos no modelo E-R; Um conjunto de mensagens ao qual o objeto responde; cada mensagem pode ter zero, um ou mais parâmetros; Um conjunto de métodos, cada qual sendo um corpo de código para implementar a mensagem; um método retorna um valor como resposta à mensagem.

99 O Modelo de Dados Orientado a Objeto O termo mensagem em um contexto orientado a objeto se refere à passagem de pedidos entre os objetos sem considerar detalhes específicos de implementação. O termo chamar um método algumas vezes é usado para representar o ato de enviar uma mensagem a um objeto e a execução do método correspondente. Exemplo: Considerando a entidade empregado em um banco de dados. Suponha que o salário anual de um empregado seja calculado de maneiras diferentes para diferentes empregados. Por exemplo, os gerentes podem ter um bônus dependendo do desempenho do banco, enquanto os caixas podem obter um bônus dependendo de quantas horas eles trabalharam. É possível encapsular o código para calcular o salário para cada empregado como um método que é executado em resposta a uma mensagem salário_anual. Todos os objetos empregado respondem à mensagem salário_anual, mas fazem isso de diferentes maneiras. Pelo encapsulamento da informação sobre como calcular o salário anual dentro do objeto empregado, todos os objetos empregados apresentam a mesma interface. É possível modificar a definição de um objeto sem afetar o resto do sistema. Esta é uma das habilidades considerada como uma das maiores vantagens do paradigma de programação orientado a objetos.

100 O Modelo de Dados Orientado a Objeto Os métodos de um objeto podem ser: Somente leitura: não afeta os valores das variáveis em um objeto; De atualização: pode mudar os valores das variáveis. As mensagens às quais um objeto responde podem ser, de maneira similar, classificadas como somente leitura ou de atualização, em função do método que implementa a mensagem. Cada atributo de uma entidade deve ser expresso como uma variável e um par de mensagens do objeto no modelo orientado a objeto. A variável é usada para armazenar o valor do atributo, uma mensagem é usada para ler o valor do atributo e o outro método é usado para atualizar o valor. Por exemplo: O atributo endereço da entidade empregado pode ser representado por: Uma variável endereço; Uma mensagem obter_endereço cuja resposta é o endereço; Uma mensagem ajustar_endereço, que possui um parâmetro novo_endereço, para atualizar o endereço. Por simplicidade muitos modelos orientados a objeto permitem que as variáveis sejam lidas ou atualizadas diretamente, sem ter de definir mensagens para isso.

101 Classes de Objetos Objetos similares são aqueles que respondem às mesmas mensagens, usam os mesmos métodos e têm variáveis de mesmo nome e tipo. Objetos similares são agrupados formando uma classes. Cada um desses objetos é chamada de uma instância de sua classe. A noção de uma classe no modelo de dados orientado a objeto corresponde à noção de um conjunto entidade do modelo E-R. Exemplo de definição de uma classe: Class empregado { /* variáveis */ string nome; string endereço; date data_início; int salário; /* mensagen */ int salário_anual(); string obter_nome(); string obter_endereço(); int ajustar_endereço (string novo_endereço); int tempo_emprego(); }

102 Classes de Objetos Cada classe é um objeto em si e inclui uma variável contendo o conjunto de todas as instâncias da classe. Uma classe objeto inclui: Uma variável conjunto valorada cujo valor é o conjunto de todos os objetos que são instâncias da classe; A implementação de um método para a mensagem new, que cria uma nova instância da classe.

103 Herança Considerando um banco de dados orientado a objetos para a aplicação bancária (exemplo Korth), a classe clientes é similar à classe empregados, pois ambas definem variáveis para nome, endereço e assim por diante. No entanto, há variáveis específicas para empregados (salário) e variáveis específicas para clientes (classificação_crédito). Neste caso é desejável definir uma representação para as variáveis comuns em um único local. Para isso, combina-se empregados e clientes dentro de uma classe. Para permitir a representação direta de similaridades entre classes, necessita-se colocar as classes em uma hierarquia de especialização. Empregado e cliente são especializações de pessoa. Este conceito é similar ao conceito de especialização no modelo E-R. Empregados e clientes podem ser representados por classes que são especializações de uma classe pessoa. Variáveis e métodos específicos a empregados são associados à classe empregados. Variáveis e métodos específicos a clientes são associados à classe cliente. Variáveis e métodos que se aplicam tanto a empregados como a clientes são associados à classe pessoa.

104 class pessoa { }; class cliente isa pessoa { string nome; string endereço; int classificação_crédito }; class empregado isa pessoa { date data_início; int salário; }; class escriturário isa empregado { }; class caixa isa empregado { int número_escriturário; int número_conta_despesa; int horas_por_semana; int número_estação; }; class secretária isa empregado { int horas_por_semana; string gerente; };

105 Herança Um benefício importante da herança em sistemas orientados a objeto é a noção de reusabilidade. Qualquer método de uma classe pode ser invocado por qualquer objeto pertencente a qualquer subclasse desta classe. Para tratar a hierarquia de classes tem-se duas opções: Associar à classe empregado todos os objetos empregado, incluindo aqueles que são instâncias de escriturário, caixa e secretária. Associar à classe empregado somente aqueles objetos empregado que não são instâncias nem de escriturário, nem de caixa, nem de secretária. É possível determinar o conjunto de todos os objetos empregado, nesse caso, tomando-se a união daqueles objetos associados a todas as subclasses de empregado.

106 Herança Múltipla Suponha que precisemos distinguir entre escriturários, caixas e secretárias de tempo integral e tempo parcial. Além disso, assuma que são necessárias diferentes variáveis e métodos para representar empregados de tempo parcial e tempo integral. Então cada um desses empregados são classificados de duas maneiras diferentes. pessoa empregado cliente escriturário caixa secretária escrit_ti escrit_tp caixa_ti caixa_tp secretária_ti secretária_tp

107 Herança Múltipla Existem certas variáveis e métodos específicos para empregado em tempo integral e outros específicos para empregado em tempo parcial. Assim, na hierarquia em análise, as variáveis e métodos para empregados de tempo integral devem ser definidos três vezes: uma vez para escriturário_ti, uma vez para secretária_ti e uma vez para caixa_ti. Redundâncias deste tipo são indesejáveis mediante alterações nas propriedades dos empregados de tempo integral (e parcial), que deverão ser feitas em dois lugares diferentes. Existe falha na exploração da reutilização de código. Nesta hierarquia também não se consegue representar os empregados que não são escriturários, caixas ou secretárias, mas que possuem características de serem ou de tempo parcial ou integral. Se existissem várias classificações de emprego, em vez de duas limitações neste exemplo, as limitações do modelo se tornariam muito mais aparentes.

108 Herança Múltipla Herança múltipla é a habilidade de uma classe herdar variáveis e métodos a partir de múltiplas superclasses. pessoa empregado cliente tempo_integral tempo_parcial escriturário caixa secretária escrit_ti escrit_tp caixa_ti caixa_tp secretária_ti secretária_tp Pode haver algum problema?

109 Herança Múltipla Assuma que, em vez de definir salário para a classe empregado, defina-se uma variável chamada pagamento para cada classe: tempo_integral, tempo_parcial, escriturário, caixa e secretária, como a seguir: Tempo_integral: pagamento é um inteiro de 0 a contendo um salário anual; Tempo_parcial: pagamento é um inteiro de 0 a 20, contendo uma taxa horária de pagamento. Caixa e escriturário: pagamento é um inteiro de 0 a , contendo um salário anual; Secretária: pagamento é um inteiro de 0 a , contendo um salário anual. Considere a classe secretária_tp. Ela pode herdar a definição de pagamento tanto de tempo_parcial como de secretária. O resultado é diferente, dependendo da escolha feita. Opções: Incluir ambas as variáveis, renomenado-as como tempo_parcial.pagamento e secretária.pagamento; Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e secretária foram criadas; Forçar o usuário a fazer a escolha; Tratar a situação como um erro.

110 Identidade de Objeto Os objetos em um banco de dados orientado a objeto correspondem a uma entidade na empresa que está sendo modelada. Uma entidade mantém sua identidade mesmo se algumas de suas propriedades mudam com o tempo. Um objeto mantém sua identidade mesmo se alguns ou todos os seus valores de variáveis ou definições de métodos mudarem com o tempo. Diferente do modelo relacional onde as tuplas de uma relação são diferenciadas somente pelos valores que elas contêm.

111 Identidade de Objeto Formas de identidade: Valor: usado em modelos relacionais um valor de dado é usado para identidade da tupla; Nome: usado em sistemas de arquivos um nome fornecido pelo usuário é usado para identidade dos arquivos; Embutido: usado em sistemas orientados a objetos a cada objeto é atribuído automaticamente um identificador pelo sistema quando aquele objeto é criado. Identificadores de objetos são únicos. Exemplo de uso do identificador: Um dos atributos de um objeto pessoa pode ser o atributo cônjuge, que é realmente um identificador do objeto pessoa correspondendo ao cônjuge da primeira pessoa. Assim, o objeto pessoa pode armazenar uma referência ao objeto que representa o cônjuge de pessoa.

112 Objetos Compostos As referências entre os objetos podem ser usadas para modelar diferentes conceitos do mundo real. Um desses conceitos é o de objetos compostos. bicicleta É parte de roda freio marcha quadro aro raio pneu pedal bloco cabo O conceito de composição permite que os dados sejam vistos em diferentes granularidades por diferentes usuários.

113 Modelagem de BDOOs Representação no BDOO: Um BDOO armazena objetos integralmente; É possível recuperar um objeto a qualquer momento, inclusive todas as referências. Linguagem de definição: ODL (Object Definition Language); Utilizada para criar definições de objetos. Linguagem de consulta: OQL (Object Query Language); Utilizada para recuperar objetos do banco.

114 Modelagem de BDOOs Classes

115 Modelagem de BDOOs Automóvel{OID12} Ka Preto OID1 [OID5123] Objetos Fabricante{OID1} Ford João da Silva [OID1125, OID1127, OID1128] Peça{OID5123} Correia Dentada Ford OID154 [OID1125, OID1127, OID1128] Motor{OID154} Rocam V OID1 120CV Fábrica {OID1125} Central Camaçari 320 Fábrica {OID1127} Filial São Bernardo I São Bernardo 250 Fábrica {OID1128} Filial São Bernardo II São Bernardo 130

116 Modelagem de BDOOs Automóvel{OID12} Ka Preto Objeto Complexo Fabricante{OID1} Ford João da Silva Fábrica {OID1125} Central Camaçari 320 Fábrica {OID1127} Filial São Bernardo I São Bernardo 250 Fábrica {OID1128} Filial São Bernardo II São Bernardo 130 Motor{OID154} Rocam V 120 CV

117 Modelagem Padrão ODMG ODL