INTRODUÇÃO AO PROJETO DE BANCO DE DADOS ORIENTADO A OBJETOS

Transcrição

1 UNIDADEA INTRODUÇÃO AO PROJETO DE BANCO DE DADOS ORIENTADO A OBJETOS 1. Algumas Palavras Iniciais Antes de começar o estudo sobre o projeto de Banco de Dados Orientados a Objetos (BDOO), devemos relembrar dois assuntos importantes estudados em outros módulos do curso, os quais são Projeto de Banco de Dados Relacional e Análise Orientada a Objetos. Nesses módulos, estudamos como fazer projetos de banco de dados relacionais e conhecemos a metodologia orientada a objetos para o desenvolvimento de sistemas, respectivamente. No módulo que estamos começando agora, estudaremos como fazer projeto de banco de dados que utilizam a metodologia orientada a objetos, e não mais a metodologia relacional. Devido a isso, nesta unidade serão resgatados os principais conceitos estudados relacionados aos dois assuntos mencionados acima, buscando, na próxima unidade, sua integração para que você compreenda a utilização de banco de dados orientados a objetos e seja capaz de projetá-los. Além disso, no final deste módulo, na sua última unidade, estudaremos como utilizar um banco de dados relacional para armazenar objetos. Faremos isso como uma alternativa ao uso de BDOOs, por uma eventual necessidade prática de se manter o SGBDR. 2. Bancos de Dados Devemos começar este módulo lembrando da diferença simples entre um Banco de Dados e um Sistema Gerenciador de Banco de Dados. BD (Banco de Dados): é uma coleção de dados interligados, representando informações sobre um domínio específico. Exemplos: lista telefônica, acervo de uma biblioteca. SGBD (Sistema Gerenciador de Banco de Dados): é um software com recursos específicos para facilitar a manipulação das informações de um BD e o desenvolvimento de programas aplicativos. Exemplos: PostgreSQL, MySQL, Oracle, SQLServer. Não podemos misturar estes conceitos, pois corremos o risco de não compreendermos aspectos importantes do que será estudado adiante. Um SGBD deve necessariamente trazer: Rapidez na manipulação e no acesso aos dados; Redução do esforço humano no desenvolvimento e utilização das aplicações; Disponibilização da informação no tempo necessário; Controle integrado de informações distribuídas fisicamente; Redução da redundância e de inconsistência de informações; Compartilhamento de dados; Aplicação automática de restrições de segurança; Redução de problemas de integridade de dados. 4

2 Um sistema atual de médio ou grande porte precisa das características recém mencionadas acima para seu funcionamento minimamente adequado. Não se consegue conceber sistemas em uso hoje em dia, como sistemas bancários, de gestão de negócios, etc., sem o uso de SGBDs 3. Princípios dos Bancos de Dados Vamos lembrar agora de alguns princípios que um SGBD deve seguir estritamente para que as características citadas na seção anterior sejam de fato garantidas. 3.1 Autocontenção Um SGBD não contém apenas os dados em si, mas armazena completamente toda a descrição dos dados, seus relacionamentos e formas de acesso. 3.2 Independência dos Dados Quando as aplicações estiverem realmente imunes as mudanças na estrutura de armazenamento ou na estratégia de acesso aos dados, pode-se dizer que esta regra foi atingida. Portanto, nenhuma definição dos dados deverá estar contida nos programas da aplicação. 3.3 Abstração dos Dados Em um SGBD real, é fornecida ao usuário somente uma representação conceitual dos dados, o que não inclui maiores detalhes sobre sua forma de armazenamento real. O chamado Modelo de Dados é um tipo de abstração utilizada para fornecer esta representação conceitual. Neste modelo, um esquema das tabelas, seus relacionamentos e suas chaves de acesso, é exibido ao usuário. 3.4 Visões Um SGBD deve permitir que cada usuário visualize os dados de forma diferente daquela existente previamente no BD. Uma visão consiste de um subconjunto de dados do BD, mas não necessariamente estes deverão estar armazenados no BD. 3.5 Transações Um SGBD deve gerenciar completamente a integridade referencial definida em seu esquema, sem precisar, em tempo algum, do auxílio do programa aplicativo. Desta forma exige-se que o BD tenha ao menos instruções que permitam a gravação e o cancelamento de uma série de modificações simultâneas. Por exemplo: um cadastro de pedido a um cliente o qual deseja reservar cinco itens do estoque. Se existir algum bloqueio financeiro deste cliente (duplicatas em atraso) que impeçam a venda, a transação deverá ser desfeita com apenas uma instrução ao BD, sem quaisquer modificações suplementares nos dados. Transações são caracterizadas pelos seguintes termos (ACID): Atomicidade, Consistência, Isolamento e Durabilidade. Atomicidade: A transação, bloco de instruções, deve ser executada como um único comando. Ou o bloco é integralmente executado, ou nenhuma das instruções é efetivada. Voltando o banco de dados e seus registros, ao estado inicial. Consistência: A transação deve garantir que os dados manipulados mantenham-se consistentes, preservando as regras de integridade definidas para o conjunto de dados. Isolamento: Uma transação deve ser executada como se esta fosse o único processo em execução no sistema, não identificando interrupções e acesso concorrente a registros. Desta forma, para um transação A, uma transação B só inicia-se com o seu término. Durabilidade: Uma transação só é efetivada quando do registro físico (durável) dos dados manipulados. 5

3 3.6 Acesso Automático Deadlocks não podem oorrer. Nesta situação, um conjunto de transações ou processo em um SGBD ficam bloqueados por dependência mútua. Esta situação indesejável pode ocorrer toda vez que um usuário travou um registro em uma tabela e, seu próximo passo, será travar um registro em uma tabela relacionada à primeira. Porém, se este registro estiver previamente travado por outro usuário, o primeiro usuário ficará paralisado, pois, estará esperando o segundo usuário liberar o registro em uso, para que então possa travá-lo e prosseguir sua tarefa. Se, por hipótese, o segundo usuário necessitar travar o registro travado pelo primeiro usuário, diz-se que ocorreu um deadlock, pois cada usuário travou um registro e precisa travar um outro, justamente o registro anteriormente travado pelo outro. Por exemplo: a pessoa responsável pelos pedidos acabou de travar o registro Item de Pedido, e necessita travar um registro no Cadastro de Produtos, para indicar uma nova reserva. Se, concomitantemente, estiver sendo realizada uma tarefa de atualização de pendências na tabela de Itens, e para tanto, previamente este segundo usuário travou a tabela de Produtos, ocorre o deadlock. 4. Projeto de Banco de Dados Projetar adequadamente um Banco de Dados (BD) é crucial para que a aplicação que se vale dos dados nele armazenados tenha seu desempenho garantido. A atividade de projeto de um BD está essencialmente centrada na construção de modelos de bancos de dados. Devemos lembrar que um modelo de banco de dados é uma descrição formal da estrutura de um banco de dados. De acordo com a intenção do modelador, um banco de dados pode ser modelado em vários níveis de abstração. No projeto de banco de dados, normalmente são considerados dois níveis de abstração de modelo de dados, o do modelo conceitual e o do modelo lógico. O modelo conceitual é um modelo de dados abstrato, que descreve a estrutura de um banco de dados de forma independente de um SGBD particular. Neste curso estudamos o modelo Entidade-Relacionamento (ER), ilustrado na Figura 1 por um diagrama ER simples. Devemos refrescar nossa memória quanto as seguintes conceitos do modelo ER: Entidade: é uma coisa ou objeto do mundo real que pode ser identificada de forma unívoca em relação aos outros objetos. Ex: pessoa, empresa, conta de banco, etc. Conjunto de entidades: conjunto que abrange entidades do mesmo tipo que compartilham as mesmas propriedades (atributos). Ex: clientes de um banco, bancos de um país, etc. Atributos: são propriedades que descrevem cada membro de um conjunto de entidades. As entidades possuem valores similares para os atributos, mas cada entidade pode ter seu próprio valor. Ex: para a entidade Livro atributos: título, autor, editora, ano, ISBN, etc.; para a entidade Autor atributos: nome, data de nascimento, nacionalidade, gênero, etc. 6

4 Chave primária: é a chave candidata escolhida que melhor identifica uma entidade dentro do seu conjunto de entidades, lembrando que quaisquer duas entidades individuais em um conjunto não podem ter, simultaneamente, mesmos valores em seus atributos chaves. Ex: matrícula. Domínio: conjunto de valores possíveis para um atributo. Ex: domínio de título conjunto de textos (string) de um certo tamanho; domínio de ano conjunto dos inteiros de 1900 a Relacionamento: é uma associação entre uma ou várias entidades. Ex: associação entre a entidade Livro e a entidade Autor. Diz-se que o Livro Memórias Póstumas de Brás Cubas foi escrito pelo Autor Machado de Assis. Cardinalidade: expressa o número de entidades às quais outra entidade pode estar associada via um conjunto de relacionamentos. Ex: Uma entidade cliente pode estar associada a quantas entidades agências? O modelo lógico é um modelo de dados que representa a estrutura de um banco de dados conforme vista pelo usuário do SGBD, menos abstrato que o modelo conceitual mencionado acima. Neste curso, estudamos o Modelo Relacional. Conceitos que precisamos lembrar a cerca do Modela Relacional: Um banco de dados relacional é composto por tabelas ou relações; Uma tabela é conjunto não ordenado de linhas (tuplas); Cada linha é composta por uma série de campos (atributo); Cada campo é identificado por um nome de campo (nome de atributo); O conjunto de todas as linhas, de campos homônimos, de uma tabela, forma uma coluna. A Figura 2 abaixo ilustra os conceitos enumerados acima: É importante lembrar que, no projeto de banco de dados, faz-se primeiro o modelo ER e depois, através de técnicas de mapeamento, cria-se o modelo Relacional. Ao fazer este mapeamento, temos de considerar os seguintes objetivos: bom desempenho; simplificação do desenvolvimento e manutenção das aplicações; ocupação de pouco espaço em disco. Além disso, temos de tomar algumas precauções: evitar junções: ter os dados necessários a uma consulta em uma única linha; diminuir o número de chaves: evitar a criação de índices sem necessidade; evitar campos opcionais: evitar que os campos opcionais sejam controlados pela aplicação. 7

5 5. Conceitos básicos de Orientação a Objetos Aqui vamos recordar os conceitos básicos da Orientação a Objetos que serão empregados neste módulo. 5.1 Classe Uma classe é uma estrutura que abstrai um conjunto de objetos com características similares. Portanto, uma classe de objetos descreve um grupo de objetos com propriedades semelhantes (atributos), com o mesmo comportamento (operações ou métodos), os mesmos relacionamentos com outros objetos e a mesma semântica. 5.2 Objeto Cada objeto é dito ser uma instância de sua classe. No contexto da orientação ao objetos, instância significa a concretização de uma classe. Cada instância tem seu próprio valor para cada atributo, mas compartilha os mesmos atributos e operações com outras instâncias da mesma classe. Um objeto contém uma referência implícita à sua própria classe, ou seja, ele sabe a que classe pertence. 5.3 Atributos Os atributos indicam as possíveis informações armazenadas por um objeto de uma classe, representando o estado de cada objeto. As operações são procedimentos que formam os comportamentos e serviços oferecidos por objetos de uma classe. 5.4 Operações Além dos atributos, as classes definem as operações que são usadas para manipular os dados dos objetos daquela classe e assim, definem o comportamento de um determinado tipo de objeto. A implementação de uma operação usando uma linguagem de programação é conhecida como método. Porém, muitas vezes método e operação acabam sendo usados como sinônimos. Herança (Generalização/Especialização) A herança é um relacionamento entre um elemento geral e outro mais específico. Através do mecanismo de herança é possível definir classes genéricas que agreguem um conjunto de definições comuns a um grande número de objetos (Generalização). A partir destas especificações genéricas, podemos construir novas classes, mais específicas, que herdem características da classe genérica e que acrescentem novas características e comportamentos aos já existentes (Especialização). Desta forma, a herança permite a criação de elementos especializados em outros. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. Relacionamentos entre Classes O relacionamento mais comum entre classes é a associação, através do qual ligamos duas classes. A associação é o mecanismo através do qual os objetos se comunicam, ou seja, é necessário que haja uma associação entre duas classes para que os objetos destas classes possam trocar mensagens e interagir para a realização de alguma tarefa. A composição é uma forma mais forte de agregação, onde o objeto-parte pertence a um único objeto- -todo. É uma agregação onde o objeto parte pode pertencer somente a um todo e espera-se que as partes vivam e morram com o todo. Se o objeto da classe que contém (classe composta) for destruído, as classes da composição serão destruídas juntamente, já que as mesmas fazem parte da outra. Multiplicidade Multiplicidade é um número ou um intervalo que indica quantas instâncias de uma classe conectada pode estar 8

6 envolvido naquela relação. Agora que já relembramos todos os fundamentos do que estudaremos nesse módulo, passaremos, na sequência, a conhecer melhor os Bancos de Dados Orientados a Objetos. 9