Banco de Dados I 2007 Módulo VIII: Banco de Dados Orientado a Objetos e Relacional-Objeto (Aula 1) Clodis Boscarioli
Agenda: Banco de Dados Orientado a Objetos Introdução e Motivações; Conceitos principais; Exemplos; Principais SGBDOOs; Considerações Finais.
Introdução e 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.
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.
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.
Modelagem de BDOOs Isso: Diagrama de Classes Classe1 0..1 Classe2 Desenvolvedor Analista * * Classe3 * Classe4 Banco de Dados
Modelagem de BDOOs Ao invés disso: Diagrama de Classes Classe1 0..1 Classe2 Diagrama Entidade Relacionamento Desenvolvedor * * Tabela 6 Tabela 3 Tabela4 Analista Classe3 * Classe4 Tabela2 Tabela1 Tabela5 Banco de Dados
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.
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.
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.
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(); }
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.
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.
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 { int número_escriturário; int número_conta_despesa; }; class caixa isa empregado { int horas_por_semana; int número_estação; }; class secretária isa empregado { int horas_por_semana; string gerente; };
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.
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
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.
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?
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 100.000 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 20.000, contendo um salário anual; Secretária: pagamento é um inteiro de 0 a 25.000, 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.
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.
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.
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.
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.
Modelagem de BDOOs Automóvel Renavan Modelo Cor Preco Fabricante Peças[ ] Fabricante Nome Presidente Fábricas[ ] Classes Peça Nome Motor Produção [ ] Motor Nome Fabricante Potência Fabrica Nome Cidade Funcionarios
Modelagem de BDOOs Automóvel{OID12} 736194174 Ka Preto 20000 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 1000 16V 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
Modelagem de BDOOs Automóvel{OID12} 736194174 Ka Preto 20000 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 1000 16V 120 CV
Modelagem Padrão ODMG ODL
Especificação ODL class Pessoa (extent pessoas key nss) { attribute struct Nomep{string sobrenome, string primeiro_nome} nome; attribute string nss; attribute date data_nascimento; attribute enum Genero{M,F} sexo; attribute struct Endereço {short num, string logradouro, sort numapto, string cidade, string estado, short cpe} endereço; short idade(); };
Especificação ODL class Professor extends Pessoa ( extent professores ) { attribute string classificação; attribute float salário; attribute string escritório; attribute string telefone; relationship Departamento trabalha_em inverse Departamento::possui_professor; relationship set<aluno_grad> dá_assistência inverse AlunoGrad::assistente; relationship set<aluno_grad> no_comitê_de inverse AlunoGrad::comitê; void dar_aumento(in float aumento); void promove(in string nova_classificação); };
Especificação ODL class Grau ( extent graus) { attribute enum GrauValores{A,B,C,D,F,I,P} grau; relationship Disciplina disciplina inverse Disciplina::alunos; relationship Aluno aluno inverse Alunos::disciplinas_completadas; };
Especificação ODL class Aluno extends Pessoa ( extent alunos) { attribute string classe; attribute Departamento cursa_eletiva_em; relationship Departamento especializa_em inverse Departamento::possui_especializações; relationship set <grau> disciplinas_completadas inverse Grau::alunos; relationship set <DisciplinaCorrente> registrado_em inverse DisciplinaCorrente::alunos_registrados; void alterar_especialização (in string nomed) raises disciplina_inválida); float mg(); void registrado(in short nomseção; in ValorGrau grau) raise (disciplina_inválida,grau_invalido); };
Especificação OQL select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome) from s in departamentocc.possui_especializações where s.classe = Superior order by sobrenome asc; select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome) from s in alunos where s.especializa_em.nomed = Ciência da Computação order by sobrenome asc;
Linguagens Orientadas a Objeto Para que estes conceitos básicos de orientação a objetos sejam usados na prática em um sistemas de banco de dados, eles devem ser expressos em alguma linguagem. Esta representação pode ser feita de duas formas: Os conceitos são usados puramente como uma ferramenta de projeto e são codificados, por exemplo, em um banco de dados relacional; Os conceitos de orientação a objetos são incorporados em uma linguagem que é usada para manipular o banco de dados. Extensão de uma linguagem de manipulação de dados, como a SQL, pela adição de tipos complexos e orientação a objetos. Tomar uma linguagem de programação orientada a objeto e estendê-la para tratar banco de dados (são as linguagens de programação persistentes).
Linguagens de Programação Persistentes Linguagens de bancos de dados diferem das linguagens de programação tradicionais pelo fato de que elas manipulam diretamente os dados que são persistentes, ou seja, dados que continuam a existir mesmo depois que o programa que os criou tenha terminado. Uma linguagem de programação persistente é uma linguagem de programação estendida com estruturas para tratar dados persistentes. Versões persistentes de linguagens de programação como C++ ou Smalltalk estão entre as mais importantes. Elas permitem que o programador manipule os dados do banco de dados sem passar por uma linguagem de manipulação de dados como a SQL. Essas linguagens são poderosas e é relativamente fácil cometer erros de programação que danifiquem o banco de dados.
Persistência de Objetos Persistência por classe: Declarar que uma classe é persistente. Assim, todos os objetos da classe são, por default, persistentes. Os objetos de classes não persistentes são transientes. Persistência por criação: Um objeto é persistente ou transiente, dependendo de como ele foi criado. Persistência por marcação: Todos os objetos são criados como transientes mas, se um objeto deve persistir alem da execução do programa, ele deve ser marcado explicitamente como persistente antes do programa terminar. Persistência por referência: Um ou mais objetos são explicitamente declarados como objetos persistentes (raiz). Todos os outros objetos são persistentes se (e somente se) forem referidos diretamente, ou indiretamente, a partir do objeto persistente raiz.
Sistemas Persistentes C++ O grupo de gerenciamento de banco de dados objeto (ODMG) tem trabalhado para padronizar extensões de linguagem ao C++ (e ao Smalltalk) a fim de aceitar persistência e definir bibliotecas de classe para aceitar persistência. Exemplos: o operador new deve ser estendido para alocar um novo objeto no banco de dados, em meio estável; tipos para criação de referências (ponteiros persistentes) precisam se criados. Ref<Objeto>: referência persistente para o objeto do tipo Objeto; Notações para especificar restrições de integridade referencial também são incorporadas. Inverse deve ser usado nas definições das classes sobre as quais as restrições de integridade referencial serão necessárias. Existem duas partes: Linguagem de Definição de Objeto (ODL); Linguagem de Manipulação de Objeto (OML).
Principais SGBDOOs Produto Critério Objectivity/DB Objectivity, Inc. www.poet.com GemStone (*) GemStone Systems www.gemstone.com Jasmine Computer Associates www.cai.com Definição de dados pelo usuário SIM SIM SIM Herança Múltipla SIM Smalltalk - NÃO Java - SIM SIM Valida cardinalidade entre objetos SIM NÃO SIM (1) Suporta transações longas SIM NÃO NÃO Linguagem de definição de atributos C++, Java, Smalltalk, SQL Java, Smalltalk C C++ ODQL Java Armazena os métodos dos objetos no BD NÃO, os métodos são armazenados no cliente. SIM SIM Suporta ODL (Object Definition Language) SIM SIM NÃO Suporta OQL (Object Query Language) SIM NÃO SIM Suporta SQL SIM Smalltalk - SIM Java - NÃO SIM via ODBC Suporta consultas através de interface gráfica SIM SIM SIM
Principais SGBDOOs Objectivity/DB Integrado diretamente com a aplicação Não é necessário um processo separado; APIs (Application Programming Interfaces): C++; SmallTalk; Java: Integração com IDE Eclipse; Ferramentas de Administração e Projeto. Suporta SQL; Suporta XML;
Principais SGBDOOs GemStone Armazena métodos dos objetos no banco APIs: C++; SmallTalk; Java. Suporta SQL apenas através da interface SmallTalk; Suporta XML, com ambiente de gerenciamento otimizado; Compatível com.net.
Principais SGBDOOs Jasmine Desenvolvido pela Computer Associates APIs: C++; SmallTalk; Java; Oferece todas as funcionalidades de um BD relacional, além das capacidades da OO; Suporta OQL; Suporta SQL; Possui integração com ferramentas CASE.
Considerações Finais Principais Barreiras: Culturais Pra que mexer em time que está ganhando? ; Falta de familiaridade com OO; MID (medo, incerteza e dúvida); Grande parte dos SGBDOOs são desenvolvidos por empresas pequenas; Risco de ficar sem suporte ; Financeiras Alto custo de migração; Tempo para migração; Treinamento de pessoal; Necessidade de profissionais mais qualificados;
Considerações Finais SGBDOOs: União de duas tecnologias Bancos de Dados; Orientação a Objetos. Objetivos semelhantes Persistir dados; Recuperação; Comparação; Tratamento / Gerenciamento. Vantagem: Utilização da tecnologia OO. Desvantagem: Ainda pouco popular.
Tendências SGBDO-R (Objeto-relacional) Armazenamento em memória Prevayler (www.prevayler.org) Repositório de objetos Desempenho de acesso bastante superior Limitações ligadas à recuperação em caso de falhas ainda existem Interfaces Objeto-Relacionais Hibernate (www.hibernate.org) Camada que provê interface para a aplicação Persistência de forma transparente A aplicação trabalha como se estivesse conectada a um BDOO
Referências Bibliográficas Sistemas de Banco de Dados. (Cap. 9) Abraham Silberchatz, Henry F. Korth e S. Sudarshan. 5ª Edição. Makron Books, 2006. Sistemas de Banco de Dados. (Cap. 20-21) Ramez Elsmari, Shamkant B. Navathe. 4ª Edição. Pearson Addison Wesley, 2005. Fundamentals of Database Systems. (Cap. 11-12) Ramez Elsmari, Shamkant B. Navathe. Addison Wesley Longman, 2000. Uma Reflexão sobre Banco de Dados Orientados a Objetos. Boscarioli, et. al. CONGED, 2006. The Object-Oriented Database System Manifesto. Atkinson, et al. Agosto, 1989.