Banco de Dados. Orientado a Objetos

Transcrição

1 UNIVERSIDADE FEDERAL DE SÃO CARLOS DEPARTAMENTO DE COMPUTAÇÃO Banco de Dados Orientado a Objetos Marina Teresa Pires Vieira

2 Conteúdo Conteúdo Conceitos Avançados sobre Modelagem de Dados Introdução Modelos de Dados Abstrações no Projeto Conceitual de Banco de Dados Modelo EER (Extended Entity-Relationship) Atributos compostos: Hierarquia de Generalização Exercícios Modelos de Dados Orientados a Objetos Introdução Conceitos Básicos Objetos e Identidade Valores Estrutura do objeto OIDs x Chaves Primárias Objetos Complexos Encapsulamento Métodos Tipos e Classes Herança Polimorfismo Modelagem de Dados Orientada a Objetos Motivação Desenvolvimento de Sistemas Orientados a Objetos Modelando Objetos Definição de classe Herança Representação gráfica Representação de uma classe de objetos Representação de conjunto, lista e tupla Herança simples Herança múltipla Definição recursiva representação de referências inversas Geração do Esquema Lógico Exemplo: Banco de Dados para Gerenciamento de Projetos Notação adotada X diagrama de classes UML Exercícios Manipulando Objetos Características de Linguagens de Consulta OO (LCOO)

3 Hierarquias de Agregação Hierarquia de Herança Consultando Objetos Hierarquias de Agregação Hierarquia de Herança Definição de Métodos Exercícios Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos Características dos SGBDs Orientados a Objetos Vantagens dos SGBDOOs Alguns SGBDOOs Existentes Padrões para SGBDOOs Padrões para SGBDOOs Padrões para SGBDOOs SQL ODMG Bibliografia

4 1. Conceitos Avançados sobre Modelagem de Dados 1.1. Introdução Bancos de dados são componentes importantes dos sistemas de informação (SIs) e consequentemente, o projeto do banco de dados apresenta-se como uma atividade essencial na fase de desenvolvimento dos SIs. Projetar bancos de dados tem se tornado uma atividade popular, as vezes realizada não somente por profissionais da área de banco de dados, mas também por não especialistas. Freqüentemente, a falta de abordagens adequadas para o projeto de um banco de dados pode incorrer em resultados indesejáveis, como ineficiência em atender a demanda de aplicações e problemas com a manutenção do banco de dados. Geralmente a causa disso é a falta de clareza em entender a natureza exata dos dados em um nível conceitual (abstrato). O projeto de um banco de dados é decomposto em Projeto Conceitual, Projeto Lógico e Projeto Físico, conforme mostrado na figura 1.1. Requisitos de dados Projeto Conceitual Esquema conceitual Projeto Lógico Esquema Lógico Projeto Físico Fig. 1.1 Esquema Físico 3

5 O Projeto Conceitual inicia a partir da especificação dos requisitos e resulta no esquema conceitual do banco de dados. Um esquema conceitual é uma descrição em alto nível da estrutura do banco de dados, independente do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para implementá-lo. Um modelo conceitual é usado para descrever os esquemas conceituais. O propósito do projeto conceitual é descrever o conteúdo de informação do banco de dados ao invés das estruturas de armazenamento que serão necessárias para gerenciar essa informação. O Projeto Lógico inicia a partir do esquema conceitual e resulta no esquema lógico. Um esquema lógico é uma descrição da estrutura do banco de dados que pode ser processada por um SGBD. Um modelo lógico é usado para especificar esquemas lógicos. Os modelos lógicos mais amplamente usados pertencem a três classes: relacional, em redes e hierárquico. O projeto lógico depende da classe do modelo de dados usado pelo SGBD, mas não do SGBD específico usado. O Projeto Físico inicia a partir do esquema lógico e resulta no esquema físico. Um esquema físico é uma descrição da implementação do banco de dados em memória secundária; ele descreve as estruturas de armazenamento e métodos de acesso usados para efetivamente realizar o acesso aos dados. O projeto físico é direcionado para um SGBD específico. Decisões tomadas durante o projeto físico, para melhorar o desempenho, podem afetar a estrutura do esquema lógico. Uma vez que o projeto físico do banco de dados é completado, os esquemas lógico e físico são expressos usando a linguagem de definição de dados do SGBD adotado. O banco de dados é criado e populado e pode ser testado para se tornar operacional. O esquema físico do banco de dados é influenciado pelas fases por que passou a construção do banco de dados. A fase de projeto conceitual é tida como uma das mais (senão a mais) delicadas em todo esse processo, pois depende muito da habilidade do projetista do banco de dados e das qualidades do modelo de dados adotado para a elaboração do esquema conceitual. A meta nessa fase é obter um esquema conceitual do banco de dados que seja tão completo e expressivo quanto possível. Esse esquema deve procurar expressar o máximo da semântica envolvida na informação. Mecanismos de representação de alto nível são empregados, tais como 4

6 representação de hierarquias de subconjunto e de generalização, representação de restrições de cardinalidade e de atributos compostos e multivalorados. O esquema conceitual deve permanecer como uma parte da documentação do processo de projeto, sendo utilizado durante a operação e manutenção do banco de dados, pois facilita o entendimento dos esquemas de dados e das aplicações que os utilizam. Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados existem as abstrações de dados, que apresentam as vantagens: ajudam o projetista a entender, classificar e modelar a realidade, melhoram a eficiência de implementações subsequentes, permitem melhor representar a semântica das novas aplicações de banco de dados, provenientes de áreas não tradicionais Modelos de Dados Modelos de dados são veículos para descrever a realidade. Um modelo de dados é uma coleção de conceitos que podem ser usados para descrever um conjunto de dados e operações para manipular os dados. Os modelos de dados servem de base para o desenvolvimento de Sistemas de Gerenciamento de Banco de Dados (SGBDs). Distinguem-se dois tipos de modelos de dados: Modelos conceituais, que são ferramentas para representar a realidade em alto nível de abstração; Modelos lógicos, que suportam descrições de dados que podem ser processados por um computador (ex: modelos relacional, hierárquico, em redes). Esses modelos são facilmente mapeados para a estrutura física do banco de dados Abstrações no Projeto Conceitual de Banco de Dados Para auxiliar o projetista na tarefa de modelar os dados, existem os mecanismos de abstração de dados que permitem melhor representar a semântica da informação envolvida na aplicação. As abstrações comumente usadas no projeto conceitual são: classificação, agregação e generalização. 5

7 Abstração de Classificação: é usada para alocar objetos similares, caracterizados por propriedades comuns, em classes de objetos. A classificação estabelece um relacionamento É-INSTANCIA-DE entre cada elemento da classe e a classe. Ex: classe EMPREGADO - instancias : (João, Pedro,..., José). Abstração de Agregação: é um conceito de abstração para construir objetos compostos a partir de seus objetos componentes. Essa abstração estabelece um relacionamento É-PARTE-DE entre os componentes e a classe. Ex: - Uma entidade é uma agregação de atributos: PESSOA, composta por Nome, Sexo, Profissão; - Um relacionamento é uma agregação de entidades e atributos; - Um atributo composto é uma agregação de atributos; - Pode-se agregar entidades relacionadas entre si, compondo uma entidade de nível mais alto. Abstração de Generalização: define um relacionamento de subconjunto entre os elementos de duas ou mais classes. Essa abstração estabelece um relacionamento É-UM entre a classe pai (chamada superclasse) e cada classe filha (subclasse). Ex: classes CARRO e BICICLETA são subconjuntos da classe VEÍCULO. As subclasses são definidas com base em alguma característica da superclasse. No exemplo dado, essa característica é tipo de veículo (Carro, Bicicleta). Propriedade Fundamental da Generalização: Todas as abstrações definidas para a classe genérica são herdadas por todas as classes que são subconjunto Modelo EER (Extended Entity-Relationship) Devido à popularidade e ampla utilização do modelo Entidade-Relacionamento (ER) para o projeto conceitual de bancos de dados, várias extensões desse modelo foram propostas, visando sua utilização para a modelagem de informações mais complexas. 6

8 O modelo ER foi proposto por Peter Chen em 1976, sendo que originalmente o modelo incluia somente os conceitos de entidade, relacionamento e atributos; posteriormente outros conceitos foram introduzidos no modelo, tais como atributos compostos e hierarquias de generalização Atributos compostos: Um atributo composto representa um grupo de atributos que possuem uma afinidade em significado ou uso. Como exemplo, considere o atributo endereço na figura 1.2, que é composto por Rua, Cidade, Estado, País e CEP. Professor endereço Rua Cidade Estado País CEP Fig atributo composto Hierarquia de Generalização Uma classe E é uma generalização de um grupo de classes E1, E2,..., En se cada objeto das classes E1, E2,..., En é também um objeto da classe E. Uma forma de representar uma hierarquia de generalização é dada na figura 1.3. E E1 E2 En... Fig Hierarquia de generalização 7

9 Propriedades de Cobertura da generalização Cobertura TOTAL ou PARCIAL A cobertura de uma generalização é total (t) se cada elemento da classe genérica é mapeada para pelo menos um elemento das classes especializadas. Ex: A generalização formada pela classe PESSOA e as subclasses HOMEM e MULHER (figura 1.4) possui cobertura total. A cobertura é parcial (p) se existe algum elemento da classe genérica que não é mapeado para nenhum elemento das subclasses. Exemplo: Suponha que VEÍCULO é uma classe cujos elementos são todos os possíveis tipos de veículos. A generalização da figura 1.5 é parcial. Pessoa Veículo Homem Mulher Carro Bicicleta Fig cobertura total Fig cobertura parcial Cobertura EXCLUSIVA ou de SOBREPOSIÇÃO: A cobertura de uma generalização é exclusiva (e) se cada elemento da classe genérica possui no máximo um elemento correspondente em uma das subclasses. Ex: A figura 1.6 representa uma cobertura exclusiva. A cobertura é de sobreposição (s) se existe algum elemento da classe genérica que possui elementos correspondentes em duas ou mais subclasses. Ex: Na figura 1.6, suponha que pode existir aluno que cursa a graduação e a pósgraduação ao mesmo tempo. 8

10 Aluno Aluno- Graduaçao Aluno-Pós- Graduação Fig cobertura de overlapping Notação: Para denotar o tipo de cobertura de uma hierarquia de generalização será usada a seguinte notação: (t,e), (t,s), (p,e), (p,s), como exemplificado na figura 1.7. Quando numa generalização a cobertura não está especificada, admite-se que é (t,e). Veículo (p,e) Carro Bicicleta Fig cobertura parcial e exclusiva Hierarquia de Subconjunto Uma entidade E1 é um subconjunto de outra entidade E2 se toda ocorrência de E1 for também uma ocorrência de E2. É um caso particular da hierarquia de generalização. Numa hierarquia de subconjunto o tipo de cobertura é (p,e) sempre, não sendo necessária sua representação no esquema conceitual. A figura 1.8 é um exemplo de hierarquia de subconjunto. Cliente nro-cli nome-cli endereço Cliente Especial taxa-desconto Fig hierarquia de subconjunto Observações: 1. O identificador da entidade genérica é também um identificador para as entidades da especialização. 9

11 2. Entidades da especialização podem ter outros identificadores, como mostrado na figura 1.9. Pessoa RG nome título situaçãoserv-mil Homem Mulher Empr Chefe Gerente Militar nome- nro-emp nome-divisão categoria posição solteira Fig. 1.9 divisão ident-nadivisão 1.4. Exercícios 1. Indique na figura 1.4 se a cobertura é exclusiva ou de sobreposição. 2. Indique na figura 1.6 se a cobertura é total ou parcial. 3. Indique as propriedades de cobertura da generalização na figura Suposições: - só existem jogadores de futebol e de tênis; - pode ter jogadores que jogam os dois esportes. Jogador Futebol Tênis Fig Verifique como as propriedades de cobertura da hierarquia de generalização se relacionam com as restrições de cardinalidade de relacionamento. (Sugestão: interprete hierarquias de generalização como tipos especiais de relacionamento entre classes). 5. Transforme as hierarquias do exerc.4 em relacionamentos entre a classe genérica e as subclasses. 6. Considerando a propriedade fundamental de hierarquias de generalização, simplifique o esquema da figura

12 (1,n) Cidade (1,n) mora nascida (1,1) Pessoa nome (0,n) trabalha (1,n) (1,1) (1,1) reside Masculino Feminino idade Soldado Empregado (0,1) idade Fig Considere o esquema da figura Como você pode mudá-lo para representar no esquema todos os empregados, homens e mulheres? 8. Faça o esquema conceitual usando o modelo Entidade-RelacionamentoEstendido, do seguinte problema: Uma companhia mantém informações sobre as pessoas que, de alguma forma, possuem com ela algum vínculo, dentre essas seus funcionários. Os seguintes requisitos foram levantados junto aos usuários: a. De cada pessoa mantém-se um código, o nome, endereço. b. De cada funcionário guarda-se também seu salário e o departamento a que ele pertence. Desses funcionários, alguns são gerentes e para cada um destes guarda-se os nomes dos projetos que eles gerenciam. c. Dos demais funcionários que são operários, guarda-se suas habilidades (um operário pode ter várias habilidades). d. Mantém-se também os trabalhos executados na Companhia (código e característica) e os operários que executaram cada trabalho, juntamente com o período que isto se deu. Sabe-se também que pode haver operários que não exercem nenhum tipo de trabalho dentre os cadastrados. e. Deve-se também manter os dependentes de cada funcionário (nome, sexo e data de nascimento). 11

13 2. Modelos de Dados Orientados a Objetos 2.1. Introdução A técnica da orientação a objetos está cada vez mais popular para projetar e implementar sistemas de natureza variada. Com relação a bancos de dados, essa técnica tem sido empregada, com predominância, nos casos aonde os dados envolvidos na aplicação considerada apresentam estrutura complexa. A diferença existente entre os modelos de dados tradicionais (relacional, hierárquico e em redes) e os modelos de dados orientados a objetos está na maneira como eles vêem os dados. Os modelos de dados tradicionais vêem os dados como uma coleção de tipos de registros ou relações, cada um tendo uma coleção de registros ou tuplas armazenadas em um arquivo. Já num modelo de dados orientado a objetos um banco de dados é considerado como uma coleção de objetos do mundo real. Embora a informação sobre objetos complexos do mundo real possa ser espalhada em tabelas relacionais, a meta dos bancos de dados orientados a objetos é manter uma correspondência direta entre os objetos do mundo real e os do banco de dados, podendo estes serem identificados e manipulados como um todo. Representar um objeto complexo no modelo relacional significa que o objeto tem que ser subdividido em um grande número de tuplas, o que leva à necessidade de realizar um considerável número de operações de junção para recuperar o objeto. Os conceitos da orientação a objetos formam uma boa base para aplicações de banco de dados mais avançadas, como por exemplo: aplicações de engenharia tais como CAD/CAM (Computer Aided Design/Computer Aided Manufacturation), CASE (Computer Aided Software Engineering), sistemas de informação geográfica, sistemas de informação multimídia, sistemas de interface de usuário avançadas, etc. Essas aplicações tem requisitos e características que diferem das aplicações comerciais tradicionais, tais como estruturas de dados mais complexas, transações de duração mais longa, novos tipos de dados para armazenar imagens ou textos longos e a necessidade de definição de operações não padrões específicas da aplicação. Os bancos de dados orientados a objetos foram propostos para dar suporte às necessidades dessas aplicações mais complexas. 12

14 Os modelos de dados orientados a objetos usam os conceitos de abstração de dados dos modelos semânticos (classificação, generalização e agregação) e incorporam outros conceitos Conceitos Básicos Alguns conceitos encontrados nas linguagens de programação orientadas a objetos (LPOO) são também aplicados nos modelos de dados orientados a objetos, porém bancos de dados requerem alguns conceitos próprios. 13 Os objetos, em uma LPOO, existem somente durante a execução do programa e são por isso chamados de transitórios. Um banco de dados orientado a objetos pode estender a existência dos objetos de modo que eles sejam armazenados permanentemente, isto é, os objetos são persistentes (eles persistem após o término do programa e podem ser recuperados posteriormente e compartilhados por outros programas. A seguir são apresentados os principais conceitos envolvidos em bancos de dados orientados a objetos Objetos e Identidade Cada entidade do mundo real é modelada como um objeto. A cada objeto é associado um estado e um comportamento: o estado é representado pelos valores dos atributos do objeto; o comportamento é definido pelos métodos que agem sobre o estado do objeto pela invocação de operações. A cada objeto armazenado no banco de dados é associado um identificador único (OID: Object Identifier), que é gerado pelo SGBDOO (sistema de gerenciamento de banco de dados orientado a objetos). O valor do OID não e visível ao usuário, mas é usado internamente pelo sistema para identificar cada objeto de forma única e criar e gerenciar referências entre objetos. A principal propriedade de um OID é que ele é imutável, isto é, o valor do OID de um particular objeto não deve mudar. O SGBDOO deve ter algum mecanismo para gerenciar OIDs e preservar a propriedade de imutabilidade. É também desejável que cada OID seja usado somente uma vez, isto é, os OIDs dos objetos que são removidos do banco de dados não são reaproveitados. As duas propriedades acima implicam que o OID não deve depender de nenhum valor de atributo do objeto. Geralmente é considerado não apropriado basear o OID no endereço físico do objeto no meio de armazenamento, uma vez que o endereço físico

15 pode mudar após a reorganização do banco de dados. Entretanto, alguns sistemas usam o endereço físico como OID, para aumentar a eficiência de recuperação do objeto. Nesse caso, se o endereço físico do objeto muda, pode ser colocado um ponteiro indireto no primeiro endereço, indicando a nova localização física do mesmo. É mais comum usar inteiros longos como OIDs e uma função hash para mapear o valor do OID para o endereço físico do objeto Valores A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou caracteres, por valores (não possuem OIDs), enquanto as entidades não primitivas são representadas como objetos. Já outros sistemas, como o O2, permitem a definição de valores complexos que não podem ser compartilhados por outros objetos, uma vez que valores não possuem OIDs Estrutura do objeto O valor de cada atributo de um objeto pode ser: - atômico: integer, real, character, booleano, etc. - complexo: definido através de construtores: tuple, set, list, bag e array. O construtor de tipo tuple serve para agregar informações afins. É freqüentemente chamado de tipo estruturado, pois corresponde ao construtor struct nas linguagens de programação C e C ++. Os construtores de tipo set, list, array e bag são chamados de tipos de coleção e servem para definir atributos multivalorados. Podem ser não ordenados (set e bag) ou ordenados (list e array). Em um set não pode haver dois elementos com o mesmo valor, enquanto que na bag isso é possível OIDs x Chaves Primárias Nos modelos orientados a objetos não existe o conceito de chave primária como acontece no modelo relacional. Ao invés disso, existem os OIDs dos objetos que, como já dito, são criados e mantidos pelo sistema de gerenciamento de banco de dados e não são de acesso do usuário. As vantagens do uso de OIDs com relação às chaves são: - os programadores de aplicações não precisam se preocupar com a seleção de chaves para as várias classes de objetos; 14

16 - obtém-se melhor desempenho, pois os OIDs são implementados em baixo nível pelo sistema; - embora as chaves sejam mais significativas ao usuário, muitas vezes o usuário precisa usar códigos artificiais, sem significado semântico, para poder identificar as tuplas de uma relação Objetos Complexos A composição estrutural de um objeto é definida através de um conjunto de atributos. O valor de cada atributo pode ser primitivo, um objeto ou uma combinação dos construtores tupla, lista, array, conjunto ou bag, envolvendo outros objetos ou não. Objetos complexos são definidos através de construtores envolvendo outros objetos. Quando o valor de um atributo de um objeto O é um objeto O, o sistema armazena o identificador de O em O ou todo o valor complexo é armazenado no atributo do objeto Encapsulamento A cada objeto está associada sua estrutura e seu comportamento (os métodos ou operações). O comportamento é armazenado no banco de dados junto com a estrutura do objeto. O conceito real de encapsulamento determina que somente as operações sobre os objetos são visíveis e sua estrutura é escondida. Em banco de dados a noção de invisibilidade da estrutura do objeto é afrouxada. É desejável, por exemplo, poder consultar os atributos do objeto através de uma linguagem de consulta. Assim, a maioria dos SGBDOOs permitem acesso direto aos atributos fornecendo operações definidas pelo sistema para a leitura e modificação dos atributos, o que livra o usuário da incumbência de implementar uma considerável quantidade de métodos cujo único propósito é ler e escrever os valores dos vários atributos dos objetos. Isso é um exemplo de violação do encapsulamento permitida pelos SGBDOOs. Esses sistemas, porém, possuem mecanismos para que o usuário possa proteger o acesso aos atributos dos objetos, caso desejável. O sistema O2, por exemplo, permite o usuário estabelecer quais atributos e métodos são visíveis na interface do usuário, através da declaração public, o que permite serem invocados por qualquer outro objeto. Os não visíveis são referidos como private. 15

17 Métodos Os objetos nos SGBDOOs são manipulados através de métodos. Em geral, a definição de um método consiste de assinatura e corpo. A assinatura especifica o nome do método, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo representa a implementação do método e consiste de um conjunto de instruções expressas em uma dada linguagem de programação Tipos e Classes Um tipo modela as características comuns de um conjunto de objetos e corresponde à noção de tipos abstratos de dados. Uma classe é um conjunto de objetos que tem exatamente a mesma estrutura interna, i.é, os mesmos atributos e mesmos métodos. Os modelos de dados orientados a objetos usam o conceito de classe como uma base para instanciação Herança É um mecanismo de reusabilidade muito poderoso. Com herança, uma classe chamada uma subclasse pode ser definida com base na definição de outra classe chamada a superclasse. A subclasse herda os atributos, métodos e mensagens de sua superclasse e pode ter atributos específicos, métodos e mensagens adicionais. Exemplo: Considere duas classes com informações sobre um conjunto de ônibus e caminhões. As características das duas classes são mostradas na figura 2.1 cuja notação gráfica utilizada representa cada classe por um retângulo dividido em 3 partes. A parte superior contém o nome da classe; a do meio contém os atributos e a inferior contém os métodos definidos pelo usuário. Como as duas classes possuem algumas características em comum, pode-se criar a classe Veículo para conter essas características, como na figura 2.2. Somente as características próprias de cada subclasse são mantidas na mesma. 16

18 Caminhão nro-placa:string modelo:string licença:number data_última_revisão:date valor_estimado:number próxima_revisão:date Ônibus nro-placa:string modelo:string lugares:number data_última_revisão:date próxima_revisão:date Fig.2.1 Veículo nro-placa:string modelo:string data_última_revisão:date próxima_revisão:date Caminhão licença:number valor_estimado:number Ônibus lugares:number Fig Hierarquia de herança Vantagens da utilização de hierarquias de classe: - diminui a quantidade de código a ser escrito; - propicia uma descrição mais precisa e concisa da realidade. Em certos sistemas, uma classe pode ter várias superclasses, em cujo caso diz-se que ocorre herança múltipla (fig.2.3), enquanto outros impõem a restrição de uma única superclasse, dita herança simples. 17

19 Veículo nro-placa:string modelo:string data_última_revisão:date próxima_revisão:date Veículo_Passageiro rota: STRING preço:number horário_saída:number Caminhão licença:number valor_estimado:number Ônibus lugares:number Fig Herança múltipla A herança múltipla pode provocar problemas de conflitos, como por exemplo, duas ou mais superclasses podem ter um atributo com o mesmo nome, mas com diferentes domínios. Esses conflitos precisam ser tratados pelo sistema. Se existe uma relação de inclusão entre os domínios, então o domínio mais específico será escolhido como o domínio para a subclasse. Por exemplo, se na classe Veículo existir o atributo combustível cujo domínio é: (gasolina, álcool, diesel) e em Veículo_Passageiro existir também o atributo combustível cujo domínio é (diesel), a classe Ônibus herdará o atributo combustível cujo domínio será (diesel) (figura 2.4), isto é, o domínio mais restrito. Se essa relação não existe, uma solução adotada é a escolha do domínio com base na ordem de precedência entre as superclasses. Outros sistemas deixam por conta do usuário a resolução do conflito. Em um esquema de bd, as classes podem ser organizadas em uma hierarquia de herança, formando um grafo acíclico dirigido. 18

20 Veículo nro-placa:string modelo:string data_última_revisão:date combustível:(gasolina, álcool,diesel) próxima_revisão:date Veículo_Passageiro rota: STRING preço:number horário_saída:number combustível:(diesel) Ônibus lugares:number combustível:(diesel) Fig Herança múltipla Polimorfismo Os SGBDOOs oferecem o recurso de polimorfismo de operações, também conhecido como sobrecarga de operador (overloading). Outros conceitos relacionados com o polimorfismo são os de late binding (ligação tardia) e overriding (redefinição de operação). Para melhor expor esses conceitos, considere uma operação display que recebe um objeto como entrada e apresenta o objeto na tela. Se o objeto for: - uma imagem: deseja-se apresentar a imagem; - uma pessoa: deseja-se apresentar os dados sobre a pessoa (nome, endereço, etc); - um gráfico: deseja-se apresentar uma representação gráfica. Usando um sistema convencional, seriam necessárias 3 operaçoes: display_pessoa, display_figura e display_gráfico, como mostrado a seguir: for x in X do begin case of type(x) pessoa: display_pessoa(x); figura: display_figura(x); gráfico: display_gráfico(x); end; end; 19

21 Em um sistema orientado a objetos, a operação display pode ser definida em uma classe mais geral. A operação tem um único nome e pode ser chamada indiscriminadamente por vários objetos. A implementação da operação é redefinida para cada uma das subclasses. Essa redefinição é chamada overriding. O sistema decide qual implementacão usar para execução. Assim, o código dado é simplificado para: for x in X do display(x) A ligação do nome da operação com a correspondente implementação é realizada em tempo de execução. Essa ligação retardada é dita late binding. A sobrecarga (overloading) de operador refere-se ao uso do mesmo símbolo de operador para denotar operações distintas sobre diferentes tipos de dados. 20

22 3. Modelagem de Dados Orientada a Objetos 3.1. Motivação A motivação mais imediata para a adoção dos princípios da orientação a objetos para a modelagem de dados é que o mundo real pode ser visto como uma variedade de objetos inter-relacionados. Os objetos podem ser vistos em diferentes níveis de detalhe. Por exemplo, para um observador, uma árvore pode ser vista como um objeto indivisível, sem levar em consideração sua composição em folhas, troncos, raiz, etc. Outro observador pode estar interessado em analisá-la com mais detalhe, por exemplo, considerando a cor, textura e forma das folhas. Neste caso, as folhas são consideradas objetos que fazem parte da composição do objeto árvore. Essa maneira natural de ver a composição dos objetos deve ser conservada na modelagem dos objetos e é o objetivo dos modelos de dados orientados a objetos, fornecendo uma representação mais natural do mundo real. Assim como na modelagem de dados convencional, a modelagem de dados orientada a objetos aqui abordada será realizada em 2 fases: 1. Projeto conceitual: Essa fase visa o projeto de um esquema conceitual que apresente uma abstração do problema do mundo real. Uma diferença quando se trata de projeto conceitual do banco de dados orientado a objetos é que, além da definição da estrutura dos objetos, também são definidos os métodos que manipulam esses objetos. Assim, toda a funcionalidade do sistema é definida juntamente com a estrutura dos objetos. 2. Projeto lógico: projeto de uma estrutura lógica, representando o esquema lógico do banco de dados orientado a objetos, com base no esquema conceitual Desenvolvimento de Sistemas Orientados a Objetos O desenvolvimento de sistemas orientados a objetos usa uma abordagem diferenciada daquela utilizada para o desenvolvimento de sistemas de informação tradicionais. 21

23 Desenvolvimento de sistemas tradicionais: O desenvolvimento de sistemas de informação nos moldes convencionais é realizando com base na perspectiva dos dados e na dos processos. Do ponto de vista da perspectiva dos dados, o desenvolvimento do sistema envolve a modelagem E-R dos dados, a análise relacional, a geração do esquema lógico e a implementação física do bd. Sob a perspectiva dos processos, o desenvolvimento do sistema trata os requisitos funcionais do sistema envolvendo a construção de DFDs (diagramas de fluxos de dados), especificação das funções do sistema e dos módulos de programa. Desenvolvimento orientado a objetos: O desenvolvimento orientado a objetos usa o princípio de abstração de dados, aonde as funcionalidades do sistema são associadas com os objetos (objetos encapsulam dados e comportamento) Modelando Objetos Na modelagem da estrutura dos objetos, dois tipos de hierarquias são utilizadas: a hierarquia de agregação (relacionamento É-PARTE-DE) e a hierarquia de generalização/especialização (relacionamento É-UM). No esquema lógico do banco de dados o.o., hierarquia de agregação é estabelecida através de referências. A hierarquia de generalização/especialização é estabelecida através de declarações próprias. A seguir apresenta-se, através de exemplos usando uma linguagem de definição de objetos fictícia, como é realizada a definição das classes e a definição de hierarquias de generalização/especialização Definição de classe A definição de classe é uma especificação abstrata. Por exemplo: classe Conta_Corrente com as propriedades: nro_conta, proprietário, saldo_corrente (veja especificação abaixo). As propriedades podem ser definidas em termos de outras classes: o proprietário de uma conta é uma instância de uma classe Cliente. As propriedades de proprietário representam objetos inteiros, não valores de chaves ou ponteiros. class Conta_Corrente properties 22

24 nro_conta: Integer; proprietário: Cliente; saldo_corrente: Money; operations deposito(quantia: Money); retirada(quantia: Money); end Conta_Corrente. class Cliente properties nome: String;... operations... end Cliente Herança Para especificar a hierarquia de classe e subclasse será utilizada a declaração inherits. No exemplo a seguir tem-se que a classe Carro herda todas as propriedades e operações da classe Veículo. class Veículo properties nro_reg, marca, modelo: String; cor: String; milhas: Integer; tipo_combustível: (álcool, gasolina, dísel); ano: Integer; operations... end Veículo. class Carro inherits Veículo properties tipo_combustível: (álcool, gasolina); {redefinido} {propriedades adicionais de carro} tamanho: (compacto, médio, grande); extras: set(string); end Carro Representação gráfica A seguir será apresentada uma notação gráfica para representação conceitual de objetos, que tem como objetivo oferecer uma forma simplificada para a modelagem de um banco de dados orientado a objetos. Várias notações existem na 23

25 literatura, entre elas a UML, que podem ser adotadas para essa fase do projeto do banco de dados o.o. A adoção dessa notação visa simplicidade e utilização dos recursos dos construtores tuple, list e set, que são bastante expressivos para uma variedade de aplicações de bdoo Representação de uma classe de objetos nome da classe nome_método(param);... atributo 1 atributo 2... atributo n Representação de conjunto, lista e tupla Conjunto (SET): Lista (LIST): Tupla (TUPLE): Exemplo: Pessoa nome endereço telefone filhos rua bairro Dependente nome-rua número nome sexo datanasc Fig. 3.1 Na figura 3.1 está representado que uma pessoa pode ter vários telefones, sendo que os mesmos devem ser armazenados segundo uma ordem. Essa ordem é definida de acordo com a semântica da aplicação; por exemplo, a lista de telefones 24

26 pode estar representando a ordem de preferência a ser usado para se entrar em contato com a pessoa. Cada pessoa pode possuir vários filhos, que estão representados por um conjunto de objetos do tipo Dependente. ATENÇÃO: Quando um atributo possui tipo simples e envolve o construtor SET ou LIST, a indicação desse construtor é inserida na seta de definição do atributo Herança simples a) uma só subclasse b) várias subclasses Pessoa nome endereço telefone Pessoa nome endereço telefone Cliente nro-cliente ender-comercial Cliente- Casual renda limitecred Cliente- Frequente nro-cliente débito Fig. 3.2 a e b - Herança Simples Herança múltipla * : indica o atributo a ser herdado no caso de conflito. 25

27 nome endereço cpf Cliente Funcionário nome* nro-carteira-trab endereço* salário Cliente Interno débito Fig Herança Múltipla Definição recursiva Pessoa nome endereço filhos Fig Definição Recursiva representação de referências inversas Quando a referência entre duas classes é nos dois sentidos, usa-se a notação da figura 3.5, aonde está representado que cada projeto possui um conjunto de empregados (através do atributo empregs) e cada empregado atua em um projeto. Projeto empregs proj Empregado Fig referências inversas 3.5. Geração do Esquema Lógico Para a geração do esquema lógico será adotada a linguagem utilizada na seção 3.3, cuja forma geral é dada seguir: 26

28 class nome_da_classe inherits nome_superclasse1,..., nome_superclassej properties nome_atrib1: tipo; nome_atrib2: tipo;... nome_atribj: tipo; operations nome_método(parâmetros);... ; end nome_da_classe A definição do tipo segue a seguinte regra de sintaxe: tipo :: = tipo-básico / nome-classe /tipos_inversos tuple (nome-atributo: tipo [, nome-atributo:tipo]...) / set(tipo) / list(tipo) tipo-básico :: = Integer / Real / String / Boolean /... nome-classe : nome de uma classe existente (um identificador) nome-atributo : identificador tipos_inversos: nome_classe_inversa inverse is nome_classe_inversa. atrib_inverso/ set(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/ list(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/ Por convenção, nos esquemas conceitual e lógico, os nomes dos atributos são escritos com letras minúsculas e os nomes das classes iniciam com letra maiúscula. Exemplo : O esquema da figura 3.1 é expresso como: class Pessoa properties nome : String; endereço: tuple ( rua: tuple ( nome_rua: String, número: Integer), bairro:string); telefone: list (Integer); filhos: set (Dependente); end Pessoa class Dependente properties nome: String; sexo: String; data_nasc: Date; 27

29 end Dependente A especificação das classes da figura 3.5 é dada a seguir: class Projeto properties empregs: set(empregado) inverse is Empregado.proj; end Projeto; class Empregado properties proj: Projeto inverse is Projeto.empregs; end Empregado; 3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos Suponha que deseja-se manter um banco de dados com informações sobre os projetos desenvolvidos pelos grupos de pesquisa de uma instituição. As informações a serem armazenadas referem-se aquelas sobre projetos, especificando as tarefas que compõem cada projeto, os grupos de pesquisa que desenvolvem as tarefas do projeto, os pesquisadores que fazem parte dos grupos e os documentos produzidos relativos aos projetos. O esquema conceitual orientado a objetos desse banco de dados é mostrado na figura 3.6, aonde se tem que: - Um projeto pode ser organizado na forma de vários sub-projetos e a classe Projeto é definida recursivamente em termos dela mesma. - Um plano de trabalho, consistindo de várias tarefas, é associado a cada projeto. - Cada tarefa é atribuída a um grupo de pesquisa que consiste de vários pesquisadores e tem um coordenador. Note-se que o coordenador de uma tarefa não é necessariamente o coordenador do grupo de pesquisa atribuído para a tarefa. Para cada tarefa são identificadas as tarefas que a antecedem. 28

30 - Para cada projeto há vários documentos produzidos, que podem ser artigos publicados em jornais ou conferências ( cujos autores são pesquisadores que atuam no projeto), ou relatórios técnicos internos do projeto. Os seguintes métodos devem ser definidos: - Calcular_esforço, para a classe Tarefa, que calcula o esforço dedicado pelos pesquisadores para desenvolvimento da tarefa, em termos do tempo dedicado. - Associar_membro, para a classe Grupo, que insere um novo pesquisador num determinado grupo de pesquisadores. - Analisar_documento, que recupera documentos de uma determinada classificação. - Calcular_bônus, que calcula o valor total dos bônus recebidos pelos pesquisadores. A figura 3.6 mostra o esquema conceitual do banco de dados o.o. desse exemplo, usando a notação dada. Para permitir uma comparação com a UML, uma versão desse esquema, usando sua notação, é também fornecida na figura

31 Projeto nome_ proj objetivo documento plano_trabalho sub_projeto Documento analisar_doc(classif:string) código_doc nome classificação tópicos início_validade fim_validade evolução Relatório_ Técnico Artigo autor tipo_publ local_publ data_publ Tarefa calcular_esforço() data_início data_fim descrição_tarefa coordenador anos_homem participante precede Pesquisador calcular_bonus() nome especialização salário bônus_produção Grupo associar_membro() nome_grupo membro coordenador Fig.3.6 Banco de Dados para Gerenciamento de Projetos 30

32 3.7. Notação adotada X diagrama de classes UML UML (Universal Modeling Language) é uma linguagem de modelagem de objetos, desenvolvida principalmente para projeto de software. Os diagramas de classes, que fazem parte de UML, possuem alguma semelhança com os diagramas EER. Para acompanhar a discussão a seguir, considere o esquema de banco de dados EER de uma companhia, da figura 3.7, e sua representação na notação UML na figura 3.8 (apresentados no livro de Elmasri & Navathe, 2000). Os tipos de entidades da figura 3.7 são modelados como classes na figura 3.8. Na notação UML, uma classe é representada por uma caixa com 3 seções: a do topo contém o nome da classe; a seção do meio contém os atributos dos objetos da classe e a última seção contém as operações que podem se aplicadas sobre esses objetos. Opcionalmente pode-se especificar o domínio dos atributos (por exemplo: datanasc: date), como mostrado na figura 3.8. Um atributo composto é modelado como um domínio estruturado, como ilustrado pelo atributo Nome da classe Empregado. Um atributo multivalorado é geralmente modelado como uma classe separada, conforme ilustrado pela classe Localização. Na terminologia UML, tipos de relacionamentos são chamados associações e instâncias de relacionamentos são chamados links. Uma associação binária (correspondendo a um tipo de relacionamento binário do modelo EER) é representada através de uma linha conectando as classes participantes e podem opcionalmente Ter um nome. Um atributo de relacionamento, chamado de atributo de ligação (link attribute) é colocado em uma caixa que é conectada à linha da associação por uma linha pontilhada. A notação (min, max) usada para especificar restrições de relacionamento no modelo EER, é chamada de multiplicidade em UML. Multiplicidades são representadas na forma min.. max, e o asterisco (*) indica que não há limite máximo na participação. Note-se que as multiplicidades são colocadas nos lados opostos do relacionamento quando comparadas à notação do modelo EER. Em UML, um asterisco sozinho indica uma multiplicidade de 0..*, e 1 sozinho indica uma multiplicidade de Um relacionamento recursivo (relacionamento unário) é chamado uma associação reflexiva em UML e os nomes dos papéis, da mesma forma que as multiplicidades, são colocados nos lados opostos quando comparados ao diagrama EER. 31

33 Em UML há dois tipos de relacionamentos: associação e agregação. Uma agregação representa um relacionamento entre um objeto e suas partes componentes. Na figura 3.8 as localizações de um departamento e a localização de um projeto foram modelados como agregações. Associações e agregações não possuem propriedades estruturais diferentes, elas diferem apenas no significado semântico. No modelo EER, ambas são representadas como relacionamentos. Associações ou agregações unidirecionais, em UML, são mostradas com uma seta para indicar que somente é necessária uma direção para acessar os objetos. Instancias de relacionamento podem ser especificadas como sendo ordenadas. (0,n) nroe Supervisiona nome Empregado (0,1) sexo Supervisiona prim_nome sobrenome endereço salário data nasc (1,1) Trabalha é supervisionado (0,1) (0,n) (1,n) data-início Gerência Atua horas nrod (4,n) (1,1) (1,n) nro-empregados nome localização (1,n) Departamento (0,n) Controla (1,1) Possui (1,1) Projeto nro nome localização Dependente nome sexo Data_nasc grau-parentesco Figura 3.7- Esquema EER - BD Companhia 32

34 Empregado nroe nome prim_nome sobrenome sexo: { M,F} endereço salário data_nasc: Date idade muda-depto... Nome Dependente 4..* Trabalha Gerência Data_Inicio Departamento nrod nome Adiciona-empr Nro-empregados Muda-gerente * controla Projeto Nome Nro * Adiciona_empr Adiciona_projeto... Localização Nome Atua é supervisionado Horas 1..* * 1..1 * 0..1 supervisiona 0..* 0..* Dependente Sexo: {M,F} Data nasc: Date Grau-parentesco... Figura 3.8 Diagrama de classes UML BD Companhia As operações dadas em cada classe podem ser acompanhadas pelos parâmetros. Entidades fracas podem ser modeladas usando o construtor chamado associação qualificada (ou agregação qualificada). A chave parcial é colocada em uma caixa anexada à classe proprietária. 33

35 A notação UML para generalização/especialização é mostrada na figura 3.9. O triângulo vazio indica cobertura exclusiva e o triângulo cheio indica cobertura de sobreposição. Pessoa nro nome endereço RG Empregado Salário Cliente tipo cliente porcent-desconto Pessoa fisíca CPF Pessoa Juridíca CGC Figura 3.9 Generalização/especialização em UML Na Figura 3.10 tem-se o BD Companhia modelado segundo a notação de objetos considerada nesta apostila e a figura 3.11 mostra o BD de Projeto modelado segundo a notação UML, usando a ferramenta Rational Rose. 34

36 nroe nome sexo Empregado idade muda-depto... prim_nome sobrenome endereço salário data_nasc depto-trab emprs ger data-início gerente Departamento Adiciona-empr Nro-empregados Muda-gerente... nrod nome supervisor depends atua horas projs Dependente... proj. emps Projeto adiciona-empr adiciona-proj grau_parentesco nome sexo data_nas nome nro localização Figura 3.10 Esquema de Objetos - BD companhia 35

37 +compõe 0..1 Projeto nome_proj : string objetivo : string 0..* +é_composto 1 possui +é_precedida 0..* 0..* +precede 1..* 1 Tarefa data_inicio : date data_fim : date descrição_tarefa : string anos_homem : float calcular_esforço() 1..* participa 1 Grupo nome_grupo : string associar_membro() gera 0..* 0..* Documento codigo_doc : int nome : string classificação : string analisar_documento() Relatório_Técnico tópicos : string início_validade : date fim_validade : date coordena 1 é membro 1..* 1..* 0..1 coordena 1 Artigo tipo_publ : string local_publ : string data : date escreve 0..* 1..* Pesquisador nome : string especialização : string salário : float bônus_produção : float calcular_bônus() Fig BD de Projeto- notação UML Legenda Class ClassName attributes operations() Agregation Association Multiplicity * 1..* * zero one zero or one zero or more one or more n 36

38 3.8. Exercícios 1. Mapeie o esquema da figura 3.6 para a linguagem de especificação de objetos dada na seção Desenvolva o esquema conceitual orientado a objetos do problema do exercício 8 do capítulo 1 e faça o mapeamento para a linguagem de especificação de objetos dada. 3. Desenvolva o esquema conceitual orientado a objetos da aplicação a seguir, referente ao cadastro imobiliário de uma cidade. Faça o mapeamento para a linguagem de especificação de objetos dada. Nessa aplicação estão envolvidas informações relativas a bairros, ruas, quadras, segmentos de quadras e imóveis. As informações a serem mantidas sobre cada bairro são: Nome do bairro, delimitação (região que delimita o bairro) e composição (quadras que compõem o bairro). Sobre cada quadra, é necessário armazenar: código da quadra e composição (imóveis que compõem a quadra). Com relação às ruas, deve-se guardar o código da rua, nome, o início da rua (ponto de coordenadas (x,y)) e a composição (segmentos de quadra que compõem a rua). Os segmentos de quadra devem possuir um código, número inicial, número final e composição (uma seqüência ordenada de pontos (x,y)). Quanto aos imóveis, as informações a serem mantidas são: código de inscrição, proprietário (nome e categoria: particular, municipal,etc), localização (rua, número, bairro). No caso de haver construção no imóvel, deve-se guardar também informações sobre: utilização (residencial, comercial,...) e delimitação da construção. 37

39 4. Deseja-se desenvolver um banco de dados que armazene informações sobre um acervo de CDs e Livro. O banco de dados deve conter informações sobre os CDs, como a nacionalidade, o tipo de CD, se musical ou multimídia, não permitindo para um mesmo CD, ser de ambos os tipos. Se for CD de música, as informações consistem no nome do CD, cantores e compositores, gênero, número de músicas e tempo total gravado; caso seja multimídia, o tipo de software e a empresa responsável. Para os Livros deseja-se informações como nome, autores, editora, gênero, edição e encadernação. A base de dados também armazena informações sobre empréstimo de CDs e Livros a pessoas físicas, armazenando o nome da pessoa, telefone, e a data de empréstimo, permitindo assim, o controle do acervo. Suponha que as seguintes atividades devem ser realizadas: a) Dado um título (referente a um nome de Cd ou de Livro), recuperar: - gênero e compositores, se for CD de música; - empresa responsável, se for CD Multimídia; ou - nomes dos autores, se for livro. a) Dado o nome de um CD, recuperar nome e telefone da pessoa que emprestou o CD. b) Dado o nome de uma Pessoa Física, mostrar seu telefone e o nome dos CDs que ela emprestou. Faça um esquema conceitual e o esquema lógico correspondente. 38

40 4. Manipulando Objetos A manipulação de objetos é feita através de uma linguagem de consulta a objetos. Uma linguagem de consulta oferece uma forma de recuperar informações do banco de dados de uma maneira declarativa e formulada em alto nível. Muitos Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos utilizam uma extensão da linguagem de consulta SQL (Structured Query Language), uma das mais utilizadas para SGBDs relacionais, incorporando nesta mecanismos para manipulação da estrutura complexa dos objetos. A formulação de consultas podem ser feitas interativamente para recuperar objetos do banco de dados ou podem ser embutidas em uma linguagem de programação, na definição de métodos Características de Linguagens de Consulta OO (LCOO) Hierarquias de Agregação No modelo relacional, para consultar informações envolvendo mais do que uma tabela, usa-se a operação de junção sobre seus atributos chaves (primárias / estrangeiras). tabelas: Como exemplo, suponha as tabelas abaixo e, a seguir, uma consulta sobre essas Projeto (codproj, nome_proj, objetivo,...) Tarefa (codtarefa, data-início, data-fim,...,codproj, codpesq) Pesquisador(codpesq, nome, especialização,salário) Encontre todos os nomes de projetos que têm pelo menos uma tarefa possuindo, como seu coordenador, um pesquisador especializado em banco de dados. Essa consulta pode ser expressa em SQL como dado a seguir, aonde se nota a utilização de dois predicados de junção : SELECT DISTINCT Projeto.nome_proj FROM Projeto, Tarefa, Pesquisador WHERE Projeto.codproj = Tarefa.codproj and Tarefa.codpesq = Pesquisador.codpesq and Pesquisador.especialização = BD 39