1 ADMINISTRAÇÃO DE BANCO DE DADOS Dados são usados por diferentes pessoas em diferentes departamentos por diferentes razões. Entretanto, administração de dados deve prover o conceito de dados compartilhados. Usado propriamente, o SGBD facilita:

1. Interpretação e apresentação de dados em formatos úteis, pela transformação de dados brutos em informação.

2. Distribuição de dados e informação para a pessoa certa na hora certa.

3. Preservação do dado e monitoramento do uso do dado por períodos de tempo adequados.

4. Controle sobre duplicação e uso de dados, internamente e externamente.

Qualquer que seja o tipo da organização, o banco de dados deve suportar todas as operações e todos os níveis de tomada de decisão administrativa. De fato, podemos argumentar o seguinte: O papel principal do BD é dar suporte às tomada de decisão administrativa em todos os níveis da organização. A estrutura administrativa de uma organização pode ser dividida em três níveis: principal, central e operacional. O nível da administração principal toma decisões estratégicas, o nível central decisões táticas e o nível operacional toma decisões operacionais diariamente, como ilustra a figura 1.1. O SGBD deve prover ferramentas que dêem a cada nível administrativo uma visão diferente do dado e deve servir de suporte ao nível de tomada de decisão requerido. Usando esta estrutura, podemos melhor ajustar o papel designado ao banco de dados em relação as atividades típicas de cada nível administrativo.

• Nível Principal . O diretor executivo da companhia geralmente foca a formulação de decisões estratégicas sobre o posicionamento de mercado da companhia, a natureza geral das operações da companhia, a política geral interna e externa da companhia e outros usos óbvios que formam o futuro da companhia. Neste nível o BD deve ser capaz de:

1. Prover informação necessária para tomada de decisão estratégica, planejamento estratégico, formulação de políticas e definições de metas.

2. Prover acesso a dados internos e externos para identificar possibilidades de crescimento e desenhar a direção deste crescimento.

3. Prover estrutura para definição e obrigação de políticas organizacionais.

4. Melhorar a possibilidade de um retorno positivo no investimento da cia pela pesquisa de novos meios de reduzir os custos e/ou aumentar a produtividade.

5. Prover feedback para monitorar se a cia está atingindo os objetivos.

• nível intermediário. Tipicamente formula os planos operacionais para possibilitar as metas do nível principal. Supervisiona, monitora e provê o controle geral das operações da cia. Também escalona recursos com propósitos a curto e médio prazo. Neste nível o BD deve ser capaz de:

1. Distribuir os dados necessários para as decisões táticas e planejamento.

2. Monitorar e controlar a alocação e o uso de recursos.

3. Prover estrutura para obrigar e assegurar a segurança e privacidade dos dados no BD. Segurança significa proteger os dados de uso acidental ou intencional por usuários

1

não autorizados. Privacidade trata os direitos das pessoas e organização para determinar quem, o que, quando, onde e como os dados serão usados.

Principal

Central

Operacional

SGBD

Banco de Dados

Nível Administrativo Tipo de Decisão

Estratégica

Tática

Operacional

Figura 1.1 Níveis de tomada de decisão gerencial dentro de uma organização

• Nível Operacional. Os gerentes operacionais tratam as operações diárias da companhia.

A maior parte dos sistemas de informação desenvolvidos suportam esta tarefa. O BD deve então:

1. Representar e suportar as operações da companhia tão corretamente quanto possível. O modelo de dados deve ser flexível a fim de incorporar todas as representações requeridas e os dados futuramente esperados.

2. Produzir resultados de consultas com nível de performance específicos. Respostas rápidas para um grande número de transações no nível operacional.

3. Aumentar a capacidade operacional da cia a curto prazo.

O objetivo principal de um BD é prover um caminho para o fluxo de informação na companhia. Um dos tópicos mais quentes no Gerenciamento de Escritórios é o ambiente de escritório sem papel, no qual todos os dados são armazenados e gerenciados por um sistema de BD capaz de gerenciar diferentes tipos de dados tais como voz, imagem, e outros.

As companhias de BD são também conhecidas como as corporações ou empresas de BD. As empresas de BD devem ser definidas como a representação de dados das companhias que provêem suporte para todas as operações presentes e futuras.

1.1 INTRODUÇÃO DE UM SGBD: CONSIDERAÇÕES ESPECIAIS

Ter um SGBD automatizado não garante que os dados serão utilizados corretamente para prover as melhores soluções requeridas pelos administradores. Um SGBD é somente uma

2

ferramenta para gerenciar dados e deve ser utilizada efetivamente a fim de produzir os resultados desejados. A solução para os problemas da companhia não é a mera existências de um sistema de computador ou seus BD, mas certamente seu uso e gerenciamento efetivo.

A introdução de um BD representa uma grande mudança e desafio; é como ter um profundo impacto sobre a organização. O impacto pode ser negativo ou positivo, depende de como o SGBD introduzido é administrado. Por exemplo, um ponto chave é o SGBD deve se adaptar a organização e não a organização se adaptar ao SGBD. A introdução de um SGBD é um processo que inclui três aspectos importantes:

1. Tecnológico: SGBD como software e hardware. Inclui a seleção, instalação e monitoramento do SGBD para que ele possa ser eficiente no armazenamento, acesso e segurança dos dados.

2. Gerencial: Funções Administrativas. Somente o SGBD não garante o sucesso da empresa é necessário elaborar cuidadosamente os projetos para assegurar o sucesso do banco de dados. É necessário criar uma estrutura de pessoas responsáveis pela administração do SGBD.

3. Cultural: Resistências corporativa às mudanças. O choque cultural causado pela introdução de um SGBD deve ser avaliado cuidadosamente. A existência de SGBD poderá causa efeitos nas pessoas, funções e interações. Normalmente as pessoas devem ser treinadas, novas funções devem ser alocadas para as pessoas e o desempenho das pessoas deve ser avaliado para o novo padrão.

1.2 A EVOLUÇÃO DA FUNÇÃO DE ADMINISTRAÇÃO DE BD

A administração de dados tem suas raízes no velho e descentralizado mundo de sistemas de arquivos sem BD. Cada departamento era o dono dos seus próprios conjuntos de arquivos. Consequentemente, os especialistas em processamento de dados começou a trabalhar dentro dos departamentos. A figura 1.2 ilustra a estrutura organizacional resultante.

O custo dos dados e a duplicação de gerenciamento levou a necessidade de centralização da função de administração de dados conhecida como processamento eletrônico de dados ou Departamento de Processamento de Dados (DPD)

Arquivos

Gerente

Administrativo

Processamento de dados

Departamento A

Arquivos

Gerente

Administrativo

Processamento de dados

Departamento B

3

Figura 1.2 O especialista de processamento de dados nos departamentos

A chegada do SGBD e sua visão compartilhada dos dados produziu um novo nível de

sofisticação de gerenciamento e induziu que os DPD’s evoluíssem Departamento de Sistemas de Informações (DSI), a figura 1.3 mostra com foi funcionalmente dividido este departamento. Este departamento possuía as seguintes responsabilidades:

1. Auxiliar o usuário final no gerenciamento de seus dados.

2. Gerenciar de forma integrada os dados do usuário final na diferentes aplicações.

Desenvolvimento de Aplicação Operações de BD

Sistemas de Informação

Figura 1.3 A organização interna do DSI

Com o crescimento de aplicações de BD e o aumento de complexidade dos trabalhos, surgiu a função de Administração da BD. A pessoal responsável pelo controle do banco de dados centralizado e compartilhado é o Administrador de Banco de Dados (DBA). O tamanho e o papel da função de DBA vária de empresa para empresa, assim como a localização dentro da estrutura organizacional. No organograma da empresa, a função de DBA poderia ser definida como uma assessoria ou um elemento em um nível do organograma. Colocar a função de DBA como assessor freqüentemente cria um ambiente de consultoria, no qual o DBA tem a capacidade de planejar estratégia de administração de dados, porém não tem a autoridade de força-la ou resolver possíveis conflitos.

A função de DBA como um nível no organograma (autoritário) tem a responsabilidade e autoridade para planejar, definir, implementar, e força política, padrões e procedimentos usados na atividade de administração de dados. Na figura 5.4 é ilustrado as duas formas apresentadas anteriormente.

Posição Autoritária

Desenvolvimento de Aplicação Administração de BD Operações de BD

Sistemas de Informação

4

Posição de consultor

Administração de BD

Desenvolvimento de Aplicação Operações de BD

Sistemas de Informação

Figura 1.4 A localização da função de DBA A decisão quanto a localização das funções de DBA dependerá do estilo de gerenciamento da companhia e de fatores tais como o tamanho e complexidade das operações e da distribuição geográfica da companhia. Estes fatores, também, auxiliam da determinação da estrutura interna da área de DBA. Não existe uma estrutura organizacional padrão, porém alguns fatores podem influênciar na estrutura organizacional da empresa. Tais como:

• O desenvolvimento de banco de dados distribuídos pode forçar a organização a descentralizar aspectos funcionais da administração de dados. O banco de dados distribuído requer um DBA central que defina e delegue responsabilidades aos DBA’s locais, conseqüentemente, impõe ao DBA central novas e complexas atividades de coordenação.

• A introdução de SGBDOO, normalmente, adiciona nova maneira de modelagem de dados e atividades, assim expande e diversifica os serviços do DBA.

• A rápida expansão dos microcomputadores e redes locais (LAN) tendem a dispersar o controle operacional dos dados, assim torna-se mais difícil a administração de dados centralizada. O aumento da sofisticação e do poder dos pacotes de SGBD para microcomputadores prover uma plataforma de fácil uso para fornecer informações aos departamentos. Porém, tais ambientes facilitam a duplicação de dados, o que levam os DBA’s a criar novos conjuntos de técnicas e estilos de gerenciar.

Embora não exista um padrão, é uma pratica comum definir as funções de DBA de acordo com as fase de ciclo de vida do Banco de dados, a figura 5.4 mostra a organização funcional do DBA. Se esta abordagem é adotada, então segue esta atividades:

1. Panejamento do banco de dados: inclui a definição de padrões, procedimentos e regras de consistência.

2. Requerimentos do banco de dados: projeto conceitual.

3. Projeto lógico e de transações de banco de dados.

4. Depuração e teste do banco de dados.

5

Planejamento

Conceitual Lógico

Projeto

Física Testes

Implementação Operações Treinamento

Adm. de BD

Figura 15 A organização funcional do DBA

1.3 O PAPEL DO DBA Como um genciador o DBA deve se concentrar em controlar e planejar as dimensões da função da adimnistraçào do BD. O DBA é reponsável por:

1. Coordenar, monitorar a alocar recursos de administraçào da BD: pessoas e dados.

2. Definir metas e formular planos de estratégias para a função de admnistração de BD.

As funções incluem:

• Definição do esquema: a criação do esquema original do banco de dados. Isto é realizado escrevendo-se um conjunto de definições que são traduzidas em DDL ou ODL para um conjunto de tabelas ou classes que são permanentemente armazenadas no dicionário de dados.

• Definição da estrutura de armazenamento e do método de acesso: a criação de estruturas apropriadas de armazenamento e métodos de acesso. É feito escrevendo-se um conjunto de definições que são traduzidas pelo compilador da linguagem de definição de armazenamento de dados.

• Personalização do SGBD: a modificação de parâmetros padrões quase sempre é necessária. A aplicação de correções no ambiente do SGBD.

• Concessão de autorização para acesso a dados: a concessão de diferentes tipos de autorização para o acesso a dados aos vários usuários do banco de dados. Isto permite ao DBA regular que partes do banco de dados os diferentes usuários podem acessar.

• Especificação de restrições de integridade: estas restrições são mantidas em uma estrutura especial do sistema que é consultada pelo SGBD sempre que uma atualização for realizado no banco de dados.

Há uma crescente tendência sobre a especialização da função gerenciamento de dados. Por exemplo, o organograma organizacional usado por algumas companhias grandes faz uma distinção entre um DBA e o administrador de dados (DA). O DA, também conhecido como o gerente do recurso informação (IRM- Information Resource Manager), usualmente se reporta diretamente ao topo gerencial e lhe é dado um alto grau de responsabilidade e autoridade do que ao DBA.

O DA é responsável por controlar a totalidade de recursos de dados da corporação, tanto computadorizados como não. Os serviços de DA envolve um grande área de operações se comparada ao DBA, porque o DA tem o desafio de controlar os dados computadorizados e os que estão fora do escopo do SGBD. Os papeis de DA e DBA tendem a se sobrepor, mas o DA tem uma

6

atribuição de responsabilidade e autoridade que o DBA não tem. O localização do DBA dentro da estrutura da organização varia de empresa para empresa. A tabela 5.1 mostra um contraste entre as atividades do DBA e DA.

Administrador de dados (DA) Administrador de Banco de Dados (DBA) Planejamento estratégico Controle e supervisão Elabora metas a longo prazo Executa o plano para atingir as metas Elabora política e padronização Faz cumprir a política e procedimentos Escopo amplo Escopo estreito Longo prazo (futuro) Curto prazo (operações diárias) Orientação gerencial Orientação técnica Independente de SGBD SGBD específico

Tabela 5.1 Contraste das atividades e características entre DA e DBA

Um componente primário do sucesso da estratégia de administração de dados é a insistência contínua do uso correto da política, procedimentos e padrões para a criação, uso, distribuição e remoção de dados dentro do banco de dados. O DBA deve definir, documentar e comunicar a política, os procedimentos e padrões antes de seu uso obrigatório. Basicamente:

• Política: são as regras gerais de direção e ações que deverão ser tomadas.

• Padrões: são regras utilizadas para avaliar a qualidade das atividades. Por exemplo, padrões que definem como os programas de aplicações devem ser estruturados, conversões de nomes a serem usados pelos programadores.

• Procedimentos: são instruções escritas que descrevem uma série de passos a serem seguidos durante a execução de uma dada atividade.

Para ilustrar os conceitos acima vão olhar o seguinte exemplo: Política:

• Todos os usuários deve possuir uma senha para acesso ao sistema.

• A senha deve ser trocada a cada 30 dias. Padrões:

• A senha deve possuir no mínimo 5 caracteres.

• A senha deve possuir no máximo 12 caracteres.

• O seguro social não pode ser usado como senha. Procedimento: Para cria a senha.

1. O usuário envia uma mensagem de solicitação de criação de conta ao DBA.

2. O DBA aprova o pedido e solicita a criação da conta ao suporte.

3. O suporte cria a conta, atribui uma senha temporária e envia a informação ao usuário final. Uma cópia de criação de conta é enviada ao DBA.

4. O usuário final muda a senha de temporária para permanente.

7

2 MODELAGEM DE DADOS Tradicionalmente, os projetistas de banco de dados tem a confiança de desenvolverem um bom projeto. Mas o bom projeto depende das respostas que ele pode dar quanto as indagações do usuário final. O bom projeto pode ser atingido após várias checagem . Felizmente, a arte de projetar banco de dados pode ser reforçada pelo uso de ferramentas de projeto de banco de dados. Por exemplo; ER-WIN (relacional) e Rational Rose (Orientado a objeto.- www.rational.com). De acordo com o dicionário da língua portuguesa modelo significa “Imagem ou desenho que serve para representar em escala pequena o objeto do mundo real”. Em outras palavras o modelo é uma abstração de um objeto complexo do mundo real. Um modelo de dados é uma representação relativamente simples, normalmente, gráfica da complexa estrutura de dados dos objeto do mundo real, no caso de modelo de dados orientado a objeto é, também, representado as operações que manipulam as estruturas de dados. A principal função do modelo é nos ajudar a entender as complexidades do mundo real. Dentro de um ambiente de banco de dados, um modelo de dados representa as estruturas de dados e suas características, relações, restrições e transformações. Usualmente, o projetista de banco de dados usa o modelo de dados como ferramenta de comunicação para facilitar a interação entre o projetista, programadores de aplicação e o usuário final. Se o modelo de dados é bem desenvolvido, ele pode favorecer um melhor entendimento da organização. Esse importante aspecto da modelagem de dados foi resumido por um cliente, que teve a seguinte reação; “Eu criei este negócio, eu tenho trabalhado com este negócio por vários anos, e essa é a primeira vez, realmente, que tenho entendido como todos os pedaços se encaixam”. Um bom projeto de banco de dados é a base para boas aplicações. Contrariamente, indiferentemente da experiência dos programadores e/ou da eficiência do gerador de aplicações, não podemos desenvolver boas aplicações sem um bom projeto de banco de dados. Um bom projeto de banco de dados começa em construir um bom modelo de dados. A importância do modelo de dados dificilmente pode ser desprezada. Os dados constituem a unidade de informação mais básico utilizado por uma sistema. As aplicações são criadas para gerenciar dados e auxiliar na transformação de dados em informações. Portanto, os dados são vistos de diferentes formas por diferentes pessoas. Por exemplo, a diferença de visão da companhia entre gerente e administrativo. Embora o gerente e administrativo trabalhem na mesma empresa o gerente com certeza tem uma visão muito maior da companhia do que o administrativo. 2.1 O GRAU DE ABSTRAÇÃO DE DADOS O comitê de padronização (ANSI/SPARC – The American National Standards Institute/Standards Planning and Requirements Committee) definem três modelos de dados diferentes que são baseados em graus de abstração: conceitual, externo e interno, conforme pode ser visto na figura 2.1. Contudo, porém ao analisar a figura 2.1 tem-se a necessidade de expandir a classificação dos modelos pela adição do modelo de dados físico, que será a implementação do modelo interno para um SGBD específico. 2.1.1 O MODELO CONCEITUAL O modelo conceitual, localizado no ápice da abstração, representa um visão global dos dados. Ele é uma representação dos dados globais da empresa como visto pelo gerente de mais alto nível. O modelo conceitual é a base para identificação e descrição dos principais objetos de dados, evitando-se detalhes. O modelo de dados conceitual mais utilizado é o modelo Entidade-

8

relacionamento (E-R), que ao ser usado produzimos o esquema conceitual do escopo que está sendo modelado.

Figura 2.1 Graus de abstração Para ilustrar o uso de modelos conceituais, vamos examinar o ambiente de dados de um pequeno colégio. Os principais objetos do colégio são: estudante, professores, cursos, classes e sala de aula. Essas entidades são as principais entidades do os dados são coletados e armazenados. Na figura 4.2 temos a representação das entidades e os atributos da entidade estudante.

Figura 2.2 As entidades de um pequeno colégio Com as entidades da figura 4.2 pode-se definir e descrever os relacionamentos entre aquelas entidades (também chamado de associação ou interações). Os relacionamentos podem ser classificados em um-para-um (1:1), um-para-muitos (1:N) ou muitos-para-muitos (N:M)

Independente de hardware e dependentte de software

Modelo Conceitual

Modelo Interno

Modelo Físico

Modelo Externo

Grau de Abstração Características

Independente de hardaware e software Alta

Médio

Modelo Externo

Dependente de hardware e Software baixo

Entidade

Estudante Professor Curso Turma Sala

Matrícula Número_seguro Primeiro_nome Último_nome Nome_meio Sexo Data_nascimento Endereço Telefone

Atributos de Estudante

9

Tendo identificado as entidades, um esquema conceitual é usado para relacionar uma entidade a outra, com pode ser visto na figura 2.3. Note que na figura 2.3 os relacionamentos entre as entidades são descritos através dos verbos: ensinar, conter, gerar e requer. Isto é, um professor ensina uma turma, uma turma contém estudantes e uma turma requer uma sala. E, que, os relacionamentos podem ser descritos de 1:N e de N:M.

1

M

1 N

1

N

M N

gerar

Curso

Sala

Professor Estudante Classe

requer

ensinar contém

Figura 2.3 O esquema conceitual do pequeno colégio O modelo conceitual produz algumas vantagens muito importantes. Primeiro, ele forma a base para o esquema conceitual, no qual prover um entendimento relativamente fácil do ponto de vista do ambiente dos dados. Por exemplo, pode-se ter um resumo detalhado do ambiente de dados do pequeno colégio pelo exame do diagrama do esquema conceitual apresentado na figura 2.3. Segundo, o modelo conceitual é independente de software e hardware. A independência de software significa a não dependência do SGBD para implementar o modelo. A independência do hardware significa que o modelo não depende do hardware usado na implementação do modelo. Portanto, mudanças no hardware ou SGBD não terá qualquer efeito no projeto do banco de dados a nível conceitual. 2.1.2 O MODELO INTERNO Uma vez que o SGBD tenha sido escolhido, o modelo interno adapta o modelo conceitual ao SGBD. Em outras palavras, o modelo interno requer que o projetista faça o mapeamento das características e restrições do modelo conceitual para o modelo do SGBD escolhido. Pelo fato do

10

modelo depender da existência de software de SGBD específico, é dito ser dependente do software. Logo, uma mudança no software de SGBD implica em mudança no modelo interno. No caso do modelo de SGBD ser relacional menos detalhamento será necessário no modelo interno do que se fosse escolhido outro paradigma (hierárquico, rede ou objeto). No caso da figura 2.3, foi implementado o modelo interno pela criação do banco de dados de um pequeno colégio através das tabelas: professor, curso, turma, estudante e sala. Também, deve-se criar uma entidade de composição entre sala e estudante. Esta entidade terá o nome de matrícula, como mostrado na figura 2.4. Em outras palavras, o esquema do banco de dados é o modelo interno. O modelo interno também é independente do hardware, porque ele não é afetado quando da mudança do computador no qual o software SGBD está instalado. Logo, uma mudança no dispositivo de armazenamento ou mesmo uma mudança no sistema operacional não afetará os requerimentos no projeto do modelo interno. 2.1.3 O MODELO EXTERNO O modelo externo, baseando no modelo interno, é a visão do usuário final do ambiente de dados. Entende-se por usuário final aquelas pessoas que usam os programas de aplicação, os projetistas e implementadores do modelo. O usuário final, usualmente, opera em um ambiente no qual uma aplicação tem um foco específico em uma unidade do negócio. O negócio é, geralmente, divido em unidades tais como: vendas, financeiro, propaganda, e outras. Cada unidade de negócio possui requerimentos e restrições específicas, e cada usuário um conjunto de dados. Portanto, os programadores de aplicação trabalham dentro daquelas unidades de negócio vendo o conjunto de dados apropriado de forma separada no modelo externo em relação ao modelo interno, de onde os dados são derivados, essa divisão é mostrada na figura 2.4. 2.1.4 O MODELO FÍSICO O modelo físico opera no mais baixo nível de abstração, descrevendo o modo como os dados estão guardados na mídia de armazenagem, tais como discos e fitas. O modelo físico requer a definição tanto dos dispositivos de armazenagem físico quanto dos métodos de acesso físico necessários para obter os dados dentro daqueles dispositivos. Pelo fato do modelo físico requerer tarefas de armazenamento e recuperação precisas e específica ao dispositivo, ele é dependente do software e hardware. As estruturas de armazenamentos usadas são dependentes do software (SGBD e sistema operacional) e do tipo de dispositivo que o computador pode manipular. A precisão requerida na definição do modelo físico demanda que o projetista de banco de dados que trabalha neste nível tenha um conhecimento detalhado do hardware e software usados para implementar o projeto do banco de dados. Em se tratando de modelo relacional, o projetista não necessita preocupar-se com as características física para o armazenamento dos dados. Contudo, implementação de um modelo relacional pode requerer ajustes finos a nível físico para melhorar a performance. O ajuste fino é especialmente importante quando grandes banco de dados são instalados em ambiente de grande porte.

MODELO

1

N

MN

Curso

gerar

11

Estudante 1 N

contém Classe Professor ensinar

Figura 2.4 Uma divisão do modelo interno em modelos externos que são representados pelo esquema externo

2.2 O MODELO ENTIDADE E RELACIONAMENTO Pelo fato do modelo relacional ter tornado-se dominante em projeto de banco de dados, o enfoque será todo neste modelo. Portanto, será estudado o modelo Entidade Relacionamento (E-R) que vem sendo usado a vários anos e muito aceito. Ele é uma ferramenta normalmente usada para: • Traduzir diferentes visões dos dados entre gerentes, usuários e analistas para amoldar dentro

de uma estrutura comum.

• Definir os requerimentos de processamento de dados e as restrições de integridade para auxiliar o encontro de diferentes visões.

• Auxílio na implementação do banco de dados.

12

2.2.1 OS COMPONENTES DO MODELO E-R O modelo E-R é a base do diagrama E-R, o qual representa o banco de dados conceitual como visto pelo usuário final. Esses diagramas representam os três principais componentes do modelo que são: entidade, atributos e relacionamento. Pelo fato da entidade representar um objeto do mundo real, as palavras entidade e objeto são frequentemente utilizadas como sinônimo. Logo, as entidades ou objetos do exemplo da figura 2.3 são: estudantes, sala, professor, e outras. 2.2.1.1 ENTIDADES Uma entidade no modelo refere-se a uma conjunto de objetos ou entidades do mundo real e não a um único objeto. Em outras palavras, a palavra “entidade” no modelo corresponde a uma ou mais tabelas e não a uma linha de algum ambiente relacional. No modelo E-R uma única linha é denominada de ocorrência da entidade. A entidade é representada por um retângulo contendo um nome. 2.2.1.2 ATRIBUTOS Os atributos descrevem as características que foram abstraídas dos objetos do mundo real e representadas no modelo. O atributo é representado por um circulo contendo um nome e fica conectado a entidade por uma linha. Por exemplo, na figura 2.6 a entidade estudante possui os atributos: nome, data de nascimento (dt_nasc) e número do seguro (Nseguro).

13

3 INTRODUÇÃO A BANCO DE DADOS Usualmente, as organizações prosperam quando seus gerentes agem na base das informações relevantes. Para gerar informações relevantes eficientemente, é necessário acessar rapidamente os dados (fatos primários) originais de onde as informações requeridas foram produzidas. O gerenciamento de dados tem como foco principal uma coleção de dados armazenados e que podem ser recuperados. Logo, constitui a atividade central de qualquer organização. Normalmente, o gerenciamento de dados de forma eficiente requer o uso de base de dados em computadores. Uma base de dados é uma estrutura integrada e compartilhada que mantém uma coleção de:

• Dados do usuário final – que são, os fatos primários que interessa o usuário final. • Metadados – “dados sobre dados”, através do qual os dados são integrados.

O metadados prover uma descrição das características e do conjunto de relacionamentos que ligam os dados encontrados dentro do banco de dados. Uma linha de produtos foram estudas e projetadas pela industria de computadores para manter e gerenciar dados, que são os SGBD’s (Sistema Gerenciador de Banco de Dados). Devido ao fato dos dados primários serem a fonte crucial de onde as informações são derivadas, existem boas razões pelas quais os SGBD’s são importantes na nossa sociedade que é baseada em informações. Os seguintes pontos são de extrema importância:

• Se os dados são importantes, devemos ter uma boa maneira de gerenciá-los. Os SGBD’s permitem gerenciar de forma eficiente e eficaz os dados, o que não era possível antes do seu surgimento.

• Os SGBD’s possuem linguagem para consulta que torna possível obter respostas rápidas através de consultas “ad hoc”.

• O SGBD possibilita criar um ambiente para o usuário gerenciar e acessar os dados. A disponibilidade dos dados combinado a ferramentas que transforma os dados em informações úteis, o auxilia na tomada de decisões de forma rápida e segura.

• O total acesso aos dados da empresa de maneira bem gerenciado promove uma visão integrada das operações da organização. Consequentemente, torna-se fácil ver como a ação em um segmento da companhia afeto outro segmento. O ambiente do SGBD prover um visão clara de toda a organização, como um grande diagrama.

• A possibilidade de dados inconsistentes é fortemente reduzida quando a base de dados projetada é armazenada e gerenciada por um SGBD.

Estas são algumas das vantagens do uso de SGBD. Ao longo deste trabalho iremos descobrir várias outras vantagens do uso de SGBD. Um SGBD é uma coleção de programas que gerencia a estrutura do banco de dados e controla o acesso aos dados armazenados, e possibilita o acesso compartilhado aos dados armazenados por diferentes aplicações e usuários. A figura 1.1 mostra que o SGBD encontra-se entre o banco de dados e os usuários. De fato, o SGBD faz as traduções dos pedidos do usuário em códigos complexos afim de responder os pedidos.

14

Usuário

Figura 1.1 O SGBD gerencia a interação entre o usuário e o banco de dados 3.1 PORQUE O PROJETO DE BANCO DE DADOS É IMPORTANTE Um bom banco de dados não acontece por acaso; a estrutura de seu conteúdo deve ser projetada cuidadosamente. Projeto de banco de dados é um aspecto crucial e se mau projetado pode tornar o SGBD com baixa performance. Um banco de dados bem projetado facilita o gerenciamento de dados e torna-se um precioso gerador de informações. Mas, um projeto de banco de dados mau formulado abre a possibilidade de se ter dados redundantes no banco de dados de forma descontrolada. A redundância descontrolada são freqüentemente a fonte de dificuldades para tratar informações erradas. Um banco de dados contém informações redundantes quando o mesmo dado é mantido em localizações diferentes para a mesma entidade. Por exemplo, quando o número de telefone do cliente é armazenada em um arquivo de cliente, arquivo de agentes de vendas e um arquivo de mala direta. Se o número mudar a correção deve ser feitas em todos os locais ela ocorrer. Entretanto, a existência de dados redundantes pode produzir entradas de dados incorretas e dificilmente será possível determinar qual dado está correto. Um projeto de banco de dados pobre tende a gerar erros que levam a tomar decisões erradas. As organizações que utilizam banco de dados maus projetados freqüentemente falham porque os seus gerentes não tem acesso a informações em tempo (ou mesmo corretas. Logo, os maus projetos de banco de dados devem ser eliminados. Devido ao fato dos bancos de dados serem a fonte de informações geradas, seus projetos são objetos de estudo detalhado em ambientes modernos. O projeto de banco de dados é extremamente importante.

SGBD

Dados

Estrutura do banco de Dados Solicitação da Aplicação

Dados

Solicitação da Aplicação

Metadados

Cliente

Produto

Fornecedor

Usuário Dados do usuário

15

3.2 ORIGEM HISTÓRICA DE BANCO DE DADOS: ARQUIVOS E SISTEMAS DE ARQUIVOS Historicamente, as primeiras aplicações em computador eram tarefas de escritórios: processamento de pedidos, folha de pagamento e outras. Tais aplicações acessavam dados armazenados em arquivos no computador. As solicitações por informações eram rapidamente atendidas; relatórios eram gerados para transformar dados armazenados em informações úteis para a tomada de decisões. Embora os sistemas de arquivos sejam, hoje, obsoletos, existem boas razões para estudá-los sobre alguns aspectos:

• Os sistemas de arquivos provêem uma perspectiva histórica útil sobre como manipular dados.

• A existência de alguns problemas relacionados ao fato do sistema de arquivo ser duplicado no banco de dado do software que o utiliza, dificultando o gerenciamento de dados.

• A complexidade do projeto de banco de dados é de fácil compreensão uma vez que o entendimento das características do sistema de arquivo são relativamente simples.

• Se existe a intenção em converter um sistema de arquivos obsoleto em um sistema de banco de dados, as limitações básicas do sistema de arquivos torna-se úteis.

Em um passado recente, o gerente de quase todas as organizações pequenas eram capazes de manter os dados necessários com o uso de sistema de arquivo manuais. Desta maneira, um sistema de arquivo era, tradicionalmente, composto de uma coleção de fichas e eram mantidas em um fichário. A organização dos dados dentro do fichário era determinada de acordo com o uso do dados. O conteúdo de cada conjunto de fichas era logicamente relacionado. Por exemplo, o conjunto de fichas de um consultório deveria conter dados de pacientes, uma ficha para cada paciente. A figura 1.2 mostra um sistema de arquivos simples.

Arquivo de vendas

Arquivo de clientes

Arquivo de funcionário

Dept. Vendas Dept. Pessoal Figura 1.2 Um sistema de arquivo simples

3.3 SISTEMAS DE BANCO DE DADOS Os problemas inerentes a sistema de arquivos tornou o uso do sistema de banco de dados bastante desejável. Ao contrário dos sistemas de arquivos, com seus vários arquivos

16

separados e não relacionados, o banco de dados consiste de dados relacionados logicamente e armazenados em um único repositório de dados. Portanto, o banco de dados representa uma mudança na forma como os dados do usuário são armazenados, acessados e gerenciados. O SGBD, mostrado na figura 1.3, prover numerosas vantagens sobre o gerenciamento do sistema de arquivos por facilitar a eliminação de dados inconsistentes, dados anormais e dependência estrutural dos dados. Melhor ainda, a geração atual de SGBD além de armazenar a estrutura dos dados em locais centrais, como também armazena o relacionamento entre os componentes. O SGBD prover todas formas necessárias para o usuário acessar os dados.

SGDB Dept. pessoal

Dept. de Vendas

O SISTEMA DE BANCO DE DADOS

Banco de dados

Pessoal

Vendas

Dept. pessoal Dept. de Vendas

O SISTEMA DE ARQUIVOS

Pessoal Estoque Contas Cliente

Figura 1.3 Contraste entre banco de dados e sistema de arquivos

17

Não podemos esquecer que o SGBD é apenas um dos vários componentes essenciais de um sistema de banco de dados. O SGBD é o “coração” deste ambiente, mas como o “coração” não funciona sozinho, assim outros componentes são necessários. 3.3.1 O AMBIENTE DO SISTEMA DE BANCO DE DADOS O sistema de banco de dados refere-se a organização dos componentes que define e regulamenta a coleção, o armazenamento, o gerenciamento e uso dos dados dentro de um ambiente de banco de dados. De um ponto de vista de gerenciamento geral, o sistema de banco de dados é composto de 5 partes principais mostrados na figura 1.4: hardware, software, pessoas, procedimentos e dados.

acessam usam

escrevem

Programadores

Procedimentos e Padrões

Programas de Aplicações

Usuários

SGBD

Dados

Hardware

Administrador do sistema

Administrador do banco de dados

gerencia Projetista do banco de dados

Analistas

Escreve e força

Utilitários do SGBD

Figura 1.4 O ambiente do sistema de banco de dados

1. Hardware. Identifica todos os dispositivos físicos. O principal e mais fácil componente de hardware a ser identificado é o computador. O computador poderia ser um microcomputador, um minicomputador ou um computador de grande porte e mais todos os periféricos acoplados ao equipamento em questão.

18

2. Software. Refere-se a coleção de programas que são utilizados pelo computador dentro do sistema de banco de dados. São três os principais tipos de software componentes: o sistema operacional, o próprio SGBD e os programas de aplicações.

3. Pessoas. Este componentes inclui todos os usuários do banco de dados. Baseado em funções primárias de serviços, podemos identificar 5 tipos de usuários em um sistema de banco de dados:

• Administrador do sistema: supervisiona as operações gerais do sistema de banco de dados.

• Administrador de banco de dados: conhecido como DBA, gerencia usuários do SGBD e assegura que o banco de dados fique, sempre, em funcionamento.

• Projetista de banco de dados: projeta a estrutura do banco de dados, e o sucesso do banco de dados se dará em função de um bom projeto.

• Analista de sistemas e programadores: projeta e implementa os programas de aplicações. Eles projetam e criam as telas de captação de dados, relatórios e procedimentos que são utilizados pelos usuários para acessarem e manipularem dados do banco de dados.

• Usuário final: os usuários que utilizam as aplicações para executar as operações diárias da empresa.

4. Procedimentos: são instruções e regras que governam o projeto e os usuários do banco de dados. Eles são componentes cruciais no sistema de banco de dados.

5. Dados: a palavra dados engloba a coleção de fatos armazenados no banco de dados. Devido ao fato do dado ser a matéria-prima para gerar informações, a determinação de quais dados devem alimentar o banco de dados e como tais dados serão organizados é a parte vital do serviço de um projetista de banco de dados.

3.3.2 TIPOS DE SISTEMAS DE BANCO DE DADOS O SGBD, ao qual o sistema de banco de dados é baseado, pode ser classificado de acordo com número de usuários e a localização do banco de dados.

1. O número de usuários determina se o SGBD é classificado como “usuário único” (single-user) ou “múltiplos usuários” (multi-user). Um SGBD single-user suportar somente um usuário por vez. Em outras palavras, se o usuário A está usando o banco de dados, usuários B e C devem ficar esperando até que o usuário A conclua seu trabalho no banco de dados. Se o banco de dados single-user executar sobre um computador pessoal, ele é, também, chamado de banco de dados “desktop”.

2. A localização do banco de dados é usada para classificar o SGBD. Por exemplo, o SGBD que suporta o banco de dados localizado em um único local é denominado de centralizado. Mas, se o SGBD suportar a distribuição do banco de dados em diversas localidades é denominado de distribuído.

19

3.3.3 AS FUNÇÕES DE UM SGBD Um SGBD executa várias funções importantes que garantem a integridade e consistência dos dados no banco de dados. A maioria desta funções são transparentes ao usuário final. E a maioria desta funções só podem ser alcançadas através do uso de um SGBD. Essas funções incluem gerenciamento de dicionário de dados, gerenciamento de dados armazenados, transformação e apresentação de dados, gerenciamento de segurança, controle de acesso a múltiplos usuários, gerenciamento de “backup” e “recovery”, gerenciamento de integridade de dados, linguagem de acesso a dados, interface com programas de aplicações e interface de comunicação do banco de dados.

1. Gerenciamento de dicionário de dados: o SGBD requer que a definição dos elementos de dados e seus relacionamentos (metadados) fiquem armazenados em um dicionário de dados. O SGBD utiliza o dicionário de dados para verificar a estrutura dos dados e seus relacionamentos, assim evitasse a necessidade de se colocar códigos complexo nos programas de aplicação para acessar os dados.

2. Gerenciamento do dado armazenado: O SGBD cria estruturas complexas necessárias ao armazenamento dos dados, consequentemente livra os programas da complexa tarefa de tratar as características físicas dos dados. Os atuais SGBD prove além do armazenamento dos dados, armazena: os formulários de entrada de dados ou definições de telas, definições de relatórios, regras de validação de dados, código de procedimentos, estruturas para manipular com sons e imagens, e mais.

3. Transformação e apresentação de dados: O SGBD transforma os dados de entrada conforme as estruturas de dados que são requeridas para armazená-los. Assim, o SGBD evita que os programas faça a distinção entre formato de dados lógico e físico. Para manter a independência de dados, o SGBD traduz os requerimentos lógicos em comandos que localiza fisicamente os dados e os recupera. Em outras palavras, o SGBD prover aos programas de aplicações com independência de software e abstração de dados.

4. Gerenciamento de segurança: O SGBD cria um sistema de segurança que obriga a todos a passar por este sistema e mantém a privacidade dos dados. As regras de segurança determinam quais usuários podem acessar o banco de dados, quais itens de dados os usuários podem acessar e que operações de manipular dados o usuário pode executar (leitura, adicionar, apagar e modificar). Isto é especialmente importante em sistemas de banco de dados multi-usuários onde vários usuários podem acessar o banco de dados simultaneamente.

5. Controle de acesso a múltiplos usuários: O SGBD cria estruturas complexas que permite muitos usuários acessarem os dados. Com objetivo de prover integridade e consistência de dados, o SGBD utiliza algoritmos sofisticados para assegurar que vários usuários possam acessar o banco de dados concorrentemente e garantir a integridade do banco de dados.

6. Gerenciamento de “backup” e “recovery”: O SGBD prover procedimentos para realizar becape e recuperação do banco de dados de forma segura e integra. Os atuais SGBD provêem utilitários que permite ao DBA executar procedimento de becape e recuperação. A recuperação do banco de dados é necessária após uma falha e as vezes é preciso lançar mão do becape para restaurar o banco de dados a um estado consistente.

7. Gerenciamento de integridade de dados: O SGBD aplica e força as regras de integridade de dados para eliminar problemas de integridade de dados, consequentemente minimiza a redundância e maximiza a consistência dos dados. Os relacionamentos de dados

20

armazenados no dicionário de dados são usados para força a integridade de dados. Assegurar integridade de dados é especialmente importante em sistemas de banco de dados orientados a transações.

8. Linguagem de acesso a dados: O SGBD prover acesso aos dados no banco de dados via linguagem de consulta. Uma linguagem de consulta é uma linguagem não procedural, isto é ela permite que o usuário especifique o que deve ser feito sem ter que especificar como ser feito. As linguagens de consulta do SGBD contém dois componentes: um a linguagem de definição de dados (DDL) e o outro a linguagem de manipulação de dados (DML). A DDL define as estruturas na qual os dados serão criados e a DML permite o usuário final extrair dados do banco de dados. O SGBD, também, permite acesso aos dados através de linguagens procedurais (3GL), tais como COBOL, C, PASCAL, Visual Basic e outras. O SGBD, também, prover utilitários administrativos que são usados pelos DBA’s e projetistas de banco de dados para criar, implementar, monitorar e manter o banco de dados.

9. Interface de comunicação do banco de dados: A atual geração de SGBD prover rotinas de comunicação especiais projetadas para permitir que o banco de dados atenda solicitações dos usuários dentro de um ambiente de rede de computadores. De fato, a capacidade de comunicação dos SGBD’s é o aspecto essencial dos modernos SGBD’s. Por exemplo, o SGDB poderia prover funções de comunicação para acessar o banco de dados através da internet, usando “browsers internet” como o netscape ou o explorer como “front end”. Neste ambiente, a comunicação pode ser feita de várias maneiras:

• O usuário final pode gerar consultas, através de filtragens em formulários, para serem tratadas pelo World Wide Web.

• O SGBD pode, automaticamente, publicar relatórios pré-definidos na internet, usando o formato Web através de browser.

• O SGBD pode conectar-se a um terceiro system para distribuir informações via Email ou outras aplicações tais como Lotus notes.

4 BANCO DE DADOS ORIENTADO A OBJETO O uso de bancos de dados orientados a objeto é um fator emergente que integra bancos de dados e tecnologia de orientação a objeto. Por um lado, a necessidade de realizar manipulações complexas em bancos de dados existentes as novas gerações de aplicações de bancos de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicações de linguagens orientadas a objeto e sistemas estão exigindo capacidades de bancos de dados, tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas necessidades estão levando à criação de sistemas poderosos, chamados de dados orientados a objeto, como mostrado na figura 2.1. As grandes setas representam “herança”, e bancos de dados orientados a objeto combinam (herdam) características e aptidões de bancos de dados. Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa nas universidades e centros de pesquisa. Em meados dos anos 80, eles começaram a se tornar produtos comercialmente viáveis. Hoje, eles são mais de 25 produtos no mercado que podem ser caraterizados como produtos de “bancos de dados orientados a objeto”. Além disso, os comerciantes de bancos de dados relacionais estão começando a incorporar características de orientação a objeto em seus produtos de próxima geração baseados em SQL.

21

Continuidade

Persistência

TransaçãoVersão

Recuperação

Consulta

Desempenho

Segurança

Integridade

Aptidões de Banco deDados

Tipo abstratode dados Herança

Identidade doobjeto

Orientação a objeto

Banco de dados orientado a objeto

Figura 2.1 Banco de dados orientado a objeto 4.1 O QUE É UM BANCO DE DADOS ORIENTADO A OBJETO Ainda que um consenso esteja começando a se formar sobre o que é orientação a objeto e o que são bancos de dados orientados a objeto, ainda há alguma confusão. Mas, existem grupos que estão trabalhando a padronização de um ambiente orientado a objeto, como o OMG (Object Management Group). Como já mencionado, os bancos de dados orientados a objeto integram a orientação a objeto com aptidões de bancos de dados. Através de construções orientadas a objeto, os usuários podem esconder os detalhes da implementação de seus módulos, compartilhar a referência a objetos e expandir seus sistemas através de módulos existentes. A funcionalidade de banco de dados é necessária para assegurar o compartilhamento concomitante e a continuidade das informações nas aplicações. Através dos bancos de dados, os usuários podem obter o estado em que os objetos se encontram, e estar atualizados entre as várias solicitações de programa, e vários usuários podem ao mesmo tempo compartilhar a mesma informação. Os bancos de dados orientados a objeto combinam os benefícios e conceitos da orientação a objeto com a funcionalidade dos bancos de dados. Nesta apostila, as seguintes definições serão usadas como referência para caracterizar bancos de dados orientados a objeto: A orientação a objeto é definida como:

Orientação a objeto = tipagem de dados abstratos + herança + identidade do objeto

22

Aptidões de bancos de dados são definidas assim: Aptidões de bancos de dados = continuidade

+ concomitância + transações + recuperação + filtragem + atualização + integridade + segurança + desempenho

Bancos de dados orientados a objeto = orientação a objeto + aptidões de banco de dados. 4.2 ORIENTAÇÃO A OBJETO É uma disciplina abrangente, que tem permeado muitas áreas em computação, incluindo: linguagens, interfaces com usuário, inteligência artificial, sistemas operacionais e banco de dados. Pode ser definida como as disciplinas de modelagem de Software que tornam fácil construir sistemas complexos a partir de componentes individuais. Que proporciona conceitos e ferramentas para modelar e representar o mundo real. As vantagens da orientação a objeto na programação e modelagem de dados são muitas. Como:

• Permite representação mais direta do modelo de mundo real. • As transformações das requisições do sistema (definidas em termos de usuários) para a

especificação do sistema (definida em termos de computador) são fortemente reduzida. • Possui a habilidade de construir grandes programas a partir de outros pequenos, pré-

fabricados. 4.3 SUMÁRIO DOS CONCEITOS DE ORIENTAÇÃO A OBJETO Os três aspectos mais fundamentais do paradigma orientado a objeto são tipos de dados abstratos, herança e identidade do objeto. Cada um destes conceitos contribui para a engenharia do Software e para modelar as propriedades dos sistemas orientados a objeto. 4.3.1 TIPOS DE DADOS ABSTRATO Tipos de dados são usados para descrever um conjunto de objetos com a mesma representação. Várias operações são associadas com cada tipo de dados. Tipos de dado abstratos estendem a noção de um tipo de dados “escondendo” a implementação das operações definidas pelo usuário (“mensagens”) associadas com o tipo de dados. Linguagens que suportam tipos de dados abstratos provêm construções para definir estruturas e as operações usadas para manipular ocorrências (“instâncias”) das estruturas de dados diretamente. Além disso, todas as manipulações de instâncias dos tipos de dados são feitas exclusivamente através de operações associadas com o tipo de dados.

23

Como exemplo, considere um vendedor como representado na figura 2.2. A classe vendedor tem uma interface com as operações definidas: AdicionaNovaConta, DarPromoção e MudaCota. O importante a considerar sobre a classe vendedor é que de maneira a inteirar com as instâncias desta classe, estas operações são suficientes. Um procedimento que venha utilizar esta classe não precisa se preocupar em como cada operação foi implementada, o que precisa fazer é utilizar as operações para extrair as informações ou atualizar o estado do pessoal de vendas. Uma linguagem que permita tipos de dados abstrato permitirá que instâncias de tipos de dados sejam manipuladas somente através de uma coleção de operações associadas com o tipo.

N om eIdadeC ontaO rdem

V ariáveis de instância

A dicionaN ovaC ontaD arProm oção

M u daC ota

O perações

C la sse V endedor

Figura 2.2 A classe vendedor.

4.3.2 HERANÇA O segundo conceito orientado a objeto poderoso é herança. Através da herança, módulos de Software (classes) podem ser construídos no topo de uma hierarquia de módulos existente. O comportamento da herança capacita o compartilhamento de código (e daí a reusabilidade) entre módulos de Software. Considere a hierarquia de pessoas ilustrada na figura 2.3. Aqui cada trabalhador de escritório é uma Pessoa. Semelhantemente, cada estudante é uma Pessoa. Pessoal de vendas, engenheiros e secretárias são Pessoa.

Pessoa

Funcionário Estudante

Vendedor Secretária Graduado Não-graduado

Engenheiro

Figura 2.3 Hierarquia de classes

24

A relação de “herança” indica que além dos atributos ou operações particulares a uma subclasse, todas as operações e atributos da superclasse são herdados pelas subclasses. Esta é a essência das hierarquias de heranças. Tipos de objetos herdam a maioria dos seus atributos de tipos genéricos ou menos especializados. 4.3.3 IDENTIDADE DE OBJETO O terceiro conceito poderoso orientado a objeto é a identidade de objeto. Identidade é aquela propriedade de um objeto que distingue cada objeto dos outros. Com a identidade de objeto os objetos podem conter ou se referir a outros objetos. 4.4 CONCEITOS ORIENTADOS A OBJETO A orientação a objeto é uma metodologia de modelagem e desenvolvimento baseada nos conceitos de orientação a objeto. Que pode ser definida mais precisamente como:

Orientação a objetoUm conjunto de esquemas e princípios de desenvolvimento baseados emestruturas de computação independentes conceitualmente conhecidas comobjeto. Cada objeto representa uma entidade do mundo real com ahabilidade de interagir consigo e com outros objetos.

Como podemos ver na definição, o uso de objetos torna a modularidade quase inevitável. Os conceitos de orientação a objeto tem sido largamente aplicada em várias disciplinas relacionadas com computação, especialmente aquelas que envolve programação complexas e problemas de projeto. A tabela 2.1 resume algumas das contribuições para a orientação a objeto das várias disciplinas relacionadas com computação.

Área relacionada a Computação Contribuições para a Orientação a Objeto Linguagem de programação Redução do número de linhas de código

Diminuição do tempo de desenvolvimento Aumento da reusabilidade de código Mais fácil a manutenção do código Aumento da produtividade do programador

Interface de usuário gráfica (GUI) Aumento na habilidade de criar interface “easy-to-use” Sistemas mais amigáveis para usuário final Facilita a definição de padrões

Banco de dados Suporta tipo abstratos de dados Suporta objetos complexos Suporta a multimídia

Projeto Captura mais a semântica dos modelos de dados Representa melhor o mundo real

Sistema Operacional Aumento da portabilidade do sistema, consequentemente melhora a interoperabilidade do sistema

Tabela 2.1 Resumo da contribuição das várias disciplinas

4.4.1 A EVOLUÇÃO DOS CONCEITOS DE ORIENTAÇÃO A OBJETO

25

Os conceitos de orientação a objeto tem como base a programação orientada a objeto (POO), que foi desenvolvida como forma alternativa de programação em relação aos métodos tradicionais. Antes da POO, dados e procedimentos eram isolados um do outro. Programadores foram treinados para identificar as fontes de dados, agrupá-los em arquivos e tabelas, para estabelecer relações e restrições, e escrever procedimentos necessários para produzir certos resultados. Logo, no ambiente de programação os dados são os componentes passivos, enquanto que os procedimentos que manipulam os dados são os componentes ativos. A rígida distinção entre dados e procedimento é fortemente visto em linguagens procedurais, como exemplo a linguagem COBOL. Utilizando um linguagem procedural, o programador invoca uma aplicação, que manipula os dados para prover informações. E de forma contrária, em ambientes de POO o programador solicita aos objetos que execute operações sobre eles. Os primeiros conceitos de OO apareceram em linguagens de programação tais como: Ada, Algol, LISP, e SIMULA. Cada uma destas linguagens de programação fixa o estágio da introdução dos conceitos de OO, que foram expandidos pelas linguagens sucessoras. Atualmente, O Smalltalk e C++ são as linguagens de programação OO que dominam o mercado. Elas diferem substancialmente no nível de inclusão da orientação a objeto. O Smalltalk representa um ambiente puro de OO, enquanto que C++ é essencialmente uma extensão da linguagem C que suporta OO. As LPOO foram desenvolvidas para prover um ambiente o mais natural possível aos programadores de Software. Os principais objetivos foram:

• Prover um ambiente de desenvolvimento de Software de fácil uso.

• Prover uma poderosa ferramenta para modelagem de Software através de prototipação.

• Diminuição da equipe de desenvolvimento pela redução da quantidade de código. Melhoria da produtividade do programador em função da reusabilidade de código.

A adoção de POO muda não somente o modo pelo qual os programas são escritos como também a forma de agir dos mesmos. Manter em mente como a OO vê os dados do mundo real com a habilidade de manipulá-los. Consequentemente, o ambiente de OO tem vários atributos importantes:

1. O conjunto de dados não são passivos, isto é não são tratados de forma isolada.

2. Dados e procedimentos são agrupados, criando um objeto.

3. O objeto tem uma habilidade natural de agir consigo mesmo.

De fato, um objeto pode interagir com outros objetos para criar um sistema. Como tais objetos carregam consigo os dados e os código torna-se fácil e mais natural produzir módulos de sistemas reusáveis. 4.4.2. CONCEITOS DE ORIENTAÇÃO A OBJETO A orientação a objeto tem seus conceitos baseado em LPOO’s, que freqüentemente são consideradas como linguagens criadas, principalmente, por programadores para programadores, que tende programar a seu modo no seu próprio mundo.

4.4.2.1 OBJETOS: COMPONENTES E CARACTERÍSTICAS

26

Em sistemas orientados a objeto tudo é tratado como sendo objetos, como: um estudante, uma fatura, um avião, um empregado, um serviço, um painel de menu, um relatório, e outros. Alguns objetos são palpáveis (real) e outros não (abstrato). Podemos definir um objeto dentro do ambiente de orientação a objeto da seguinte forma:

OBJETOUm objeto é uma representação abstrata das entidades domundo real que tem um identificador único, propriedadesembutidas, e a habilidade de interagir com outros objetos econsigo mesmo.

Note a diferença entre entidade e objeto. A descrição de uma entidade é baseada nos dados componentes e nos relacionamentos com outras entidade, porém falta a habilidade para manipulá-los. Posteriormente, outras diferenças serão apresentadas. O ponto forte da definição de objetos é a identidade única. Para enfatizar este ponto, examinemos os objetos do mundo mostrados na figura 2.4. Observe que, embora eles possuam características comuns como: nome, seguro social, endereço, data de nascimento, e outras, cada objeto tem existência independente no tempo e no espaço.

João B. Santos Maria A. Silva Pedro P. Alves

Objetos

Figura 2.4 Objetos estudantes do mundo real

4.4.2.2 IDENTIDADE DE OBJETO A parte mais relevante de um objeto é sua identidade. A identidade do objeto é representada por um Object ID (OID), o qual o é único para aquele objeto, e dois objetos distintos não podem compartilhar o mesmo OID. O OID é atribuído pelo sistema no momento que o objeto é criado e não pode ser mudado sob qualquer circunstância. Não podemos confundir a chave primário do modelo relacional com o OID. Em contraste com o OID, a chave primária é baseada em valores fornecidos pelo usuário para selecionar atributos e pode ser mudada a qualquer momento. O OID é atribuído pelo sistema, e não depende dos valores dos atributos do objeto, e não pode ser mudado. O OID pode ser apagado somente se o objeto for apagado, e aquele OID não poderá ser reutilizado. Além disso, o OID único não é a ligado ao

27

endereço físico na memória permanente (disco rígido). Esta característica, permite aos sistemas orientados a objetos a manter um independência de dados física.

4.4.2.3 ATRIBUTOS (VARIÁVEIS DE INSTÂNCIAS) Os objetos são descritos através de seus atributos, conhecidos como variáveis de instância em um ambiente orientado a objeto. Por exemplo, o estudante João B. Santos mostrados na tabela 2.2. Cada atributo tem um nome único e um tipo de dados associado. Por exemplo, o número_seguro, o primeiro_nome, e outros. Tipos de dados tradicionais, também conhecidos como tipos de dados básicos, são utilizados na maioria das linguagens de programação e inclui tipos como: real, int, string e outros.

Variáveis de Instância Valoração Número_seguro 45.758.999 Primeiro_nome João Nome_meio B. Último_nome Santos Data_nascimento 27/02/1976 MGA_Semestre 2.89 MGA_Total 3.23 Disciplinas Matemática, inglês, outras

Tabela 2.2 Os atributos do objeto estudante

Os atributos, também, possuem domínios. O domínio descreve o conjunto de todos os possíveis valores que um atributo possa ter. Por exemplo, a média geral acumulada no semestres das notas de determinado aluno poderia ser representada como sendo o conjunto dos valores reais entre 0 e 5, com duas casas decimais. O estado do objeto é um conjunto de valores que os atributos do objeto possa ter em um determinado instante do tempo. Embora o estado do objeto possa variar, o seu OID mantém-se o mesmo. Se desejarmos mudar o estado do objeto, devemos mudar os valores de seus atributos. Para mudar os valores dos atributos de um objeto devemos enviar uma mensagem ao objeto. Essa mensagem chamará um método.

4.4.2.4 MENSAGENS E MÉTODOS Para entender mensagens e métodos, vamos imaginar um objeto como sendo uma noz. O núcleo da noz representa as estruturas de dados do objeto, e a casca seus métodos, conforme a figura 2.5.

28

4Método 1 Método 2

Método 3 Método 4

Dados

Objeto X

Figura 2.5 A representação de um objeto

Toda operação executada sobre um objeto deve ser implementada por método. Os métodos são usados para mudar os valores dos atributos do objeto ou retornar valores de atributos de objetos selecionados. Os métodos representam as ações do mundo real, tais como o número do seguro do estudante, adicionar um estudante a um curso, ou imprimir o nome e endereço de algum estudante. Fazendo-se uma analogia métodos são equivalentes as funções em linguagens tradicionais. Em se tratando de orientação a objetos, métodos representam os comportamentos dos objetos. Todo método é identificado por um nome e possui um corpo. O corpo é composto de instruções de computação escritas em alguma linguagem de programação para representar as ações do mundo real. Com base na tabela 2.2 podemos definir um método que retornará a média das notas acumuladas total e no semestre para estudante, como segue:

Método MédiaMGA:xmga = 0;

Xmga = (MGA_semestre + MGA_total ) / 2;return (xmga);

Nome do método

Nome das variáveis de instância

Corpo do métodoRetorna a média

Para invocar um método uma mensagem tem que ser enviada o objeto. Uma mensagem enviada com a especificação do objeto receptor, o nome do método e todos os parâmetros necessários. A estrutura interna do objeto não pode ser acessada diretamente pelo provedor da mensagem, no qual é outro objeto. Negar acesso a estrutura garante a integridade do estado do objeto e esconde os detalhes de implementação. A habilidade de esconder os detalhes internos do objeto (atributos e métodos) é conhecido como encapsulamento. Um objeto pode enviar mensagens para mudar ou interrogar sobre o estado de outros objetos (interrogar significa perguntar sobre os valores das variáveis de instância do outro objeto. Para permitir executar acesso a outro objeto, o como do objeto deve conter referências aos métodos do outro objeto). Na figura 2.6, podemos ver o esquema de envio de mensagens entre objetos.

29

Dado

Método X

Método T

Objeto A

Dado

Método Z

Método V

Objeto C

Dado

Método Y

Método U

Objeto B

Eventos domundo real

Mensagens

Figura 2.6 Envio de mensagens entre objetos

4.4.2.5 CLASSE Os sistemas orientados a objetos classificam objetos de acordo com suas similaridade e diferenças. Objetos que compartilham características comuns são agrupados em classes. Em outras palavras, a classe é uma coleção de objetos similares com estrutura compartilhada (atributos) e procedimentos (métodos). Uma classe contém a descrição da estrutura de dados e os detalhes de implementação dos métodos para os objetos daquela classe. Consequentemente, todos os objetos na classe compartilham a mesma estrutura e responde as mesmas mensagens. Cada objeto da classe é conhecido como uma instância da classe ou instância objeto. Na figura 2.7. podemos ver a representação de uma classe.

Método1

Método2

Método3

Método4

Objeto 1 Objeto 2 Objeto 3

Objeto 4 objeto 5 Objeto 6

A classe contéma descrição dosmétodo querepresenta ocomportamentodos objetos naclasse.

Uma classe écomposta deuma coleção deobjetos.

As instâncias objeto (1,2,3,4,5 e 6) compartilham a estrutura e os métodos da classe.

Figura 2.7 Ilustração da classe

Usando o exemplo mostrado na tabela 2.2, podemos definir uma classe denominada Estudante para armazenar os objetos estudantes. Todos os objetos da classe Estudante, mostrado na figura 2.8, compartilham a mesma estrutura (atributos) e respondem as mesmas mensagens (implementado pelos métodos). Vamos considera os métodos: média_mga, disciplinas_cursando e grade_horária. Cada instância de uma classe é um objeto com um único OID, e cada objeto sabe a qual classe pertence.

30

média_mga disciplinas_cursando grade_horáriamétodos

Número_seguroPrimeiro_nomeNome_meioData_nascimentoMGA_semestreMGA_totalDisciplinas

Variavéisdeinstância

João B. SantosMaria A. Silva

Pedro P. Alves

Objetos

Figura 2.8 Representação da classe estudante

4.4.2.6 PROTOCOLO A coleção de mensagens da classe, cada uma identificada por um nome, estabelece o objeto ou protocolo da classe. O protocolo representa os aspectos públicos dos objetos, isto é, os aspectos são conhecidos por outros objetos como também pelo usuário final. Em contrapartida, a implementação dos métodos e da estrutura constitui os aspectos privados do objeto, na figura 2.9 são ilustrados tais aspectos.

Método 1 Método 2

Método 3 Método 4

Dados

Protocolo

Mensagem 1

Mensagem 2

Mensagem 3

Mensagem 4

Interfacepública

Implementaçãoprivada

Figura 2.9 Os aspectos privados e públicos do objeto

Usualmente, uma mensagem é enviada para uma instância da classe (objeto). Quando o objeto receptor é uma classe, a mensagem invocará um método da classe. Um exemplo de método da classe é o método new da linguagem smalltalk. Usando-se smalltalk , o método de classe new é um gatilho (“trigger”) para criar novos instâncias na classe (objeto com OID único) receptora. Devido ao fato do objeto ainda não existe, a mensagem new é enviada para a classe e não para o objeto.

31

Variáveis deinstância

Métodos Mensagens

Protocolo

Definição da classe

Aspecto Privado Aspecto Público

são nomesde

é uma coleção de

que dispara um

Estado OID(único)

Procedimento

Objeto

tem

define um conjuntode valores para

suas

é implementadopor conjunto um

de

pertence a uma

Figura 2.10 Sumário da características de orientação a objeto

Para entender melhor os conceitos que foram discutidos anterior a figura 2.10 resume as características de objeto.

4.4.2.7 SUPERCLASSE, SUBCLASSE E HERANÇA Classes são organizadas em hierarquia de classes. Uma hierarquia de classe assemelha-se a uma árvore de cabeça para baixo na qual cada classe possui somente uma classe-pai. Uma hierarquia de classe é conhecido como uma “class lattice” se suas classes puderem ter mais de um pai. O termo classe é usado para categorizar objetos em grupos de objetos que possuem características comuns. Por exemplo, uma classe automóvel inclui carros de luxos e, também, carros populares. A figura 2.11 ilustra a generalização instrumentos musicais que inclui as especialização instrumento de cordas e instrumentos de sobro. A hierarquia de classe introduz um poderoso conceito da orientação a objeto conhecido com herança. Herança é a habilidade de um objeto dentro de uma hierarquia herdar a estrutura de dados e procedimentos (métodos) de uma acima na hierarquia. Na figura 2.11 a classe piano herda a estrutura de dados e os métodos da superclasse instrumentos de corda e de instrumentos musicais. E é através da herança que sistemas de orientação a objeto permite a reusabilidade de código. Existem duas variações de herança: a simples e a múltipla.

32

Instrumentos musicais

Instrumentos de corda

guitarraviolinopiano

Instrumentos de sobro

corneta flauta

superclasse

superclasse/subclasse

subclasse

Figura 2.11 A hierarquia de classe instrumentos musicais

4.4.2.7.1 HERANÇA SIMPLES A herança simples existe quando uma classe tem somente um pai imediato. Na hierarquia de instrumentos musicais as heranças ilustradas na figura 2.11 são do tipo simples. A maioria dos sistemas suportam herança simples. Quando o sistema envia uma mensagem para um objeto da classe, a hierarquia inteira é pesquisada para comparar o método, usando a seguinte seqüência:

1 - Busca a classe a qual o objeto pertence. 2 - Se o método não é encontrado, então busca na superclasse.

O processo de busca é repetido até que uma das situações abaixo ocorra: 1 - O método é encontrado. 2 - O topo da hierarquia é encontrado. O sistema gera uma mensagem indicativa de que o método não foi encontrado.

4.4.2.7.2 HERANÇA MÚLTIPLA A herança múltipla existe quando uma classe possui dois ou mais pais. Os objetos da classe herda as características de suas superclasses. A figura 2.12 ilustra que uma classe pode ser derivada de várias superclasses localizadas um nível acima na hierarquia de classes.

Veículo motorizado Bicicleta

motocicleta

superclasses

subclasse

Figura 2.12 Herança múltipla

33

4.4.2.8 SOBREPOSIÇÃO DE MÉTODOS E POLIMORFISMO Podemos sobrepor a definição de métodos da superclasse pela definição de métodos a nível da classe. Para ilustra a sobreposição de métodos, vamos utilizar a hierarquia de classes empregados descrita na figura 2.13.

Variável de instância: salárioMétodo: bonus = salário * 0.05

Variável de instância: Pago_vôo_acumuladoMétodo: bonus = pago_vôo_acumulado * 0.05

empregado

piloto mecânico

Figura 2.13 Sobreposição de método na hierarquia de classe empregado

Vamos examinar o exemplo apresentado na figura 2.13, note que definimos um método denominado bônus para calcular a gratificação de natal para todos os empregados. A computação do bônus é especifica para cada categoria de empregado. No caso apresentado, com exceção de piloto, um empregado recebe uma gratificação de salário igual a 5 porcento de seu salário. Pilotos recebem de gratificação de natal o acumulado pago por vôo que é muito melhor do que o salário anual. Por definição o método bônus da classe de piloto substituirá o método herdado na classe empregado, e o método bônus será sobreposto na classe piloto pelo seu método local e será aplicado a todos os objetos da classe. Contudo, a redefinição do método bônus na classe piloto não afetará o cálculo da gratificação dos demais empregados. De forma contrária a sobreposição de métodos, polimorfismo permite que diferentes objetos respondam a mesma mensagem de forma diferente. Polimorfismo é um aspecto muito importante no ambiente de orientação a objetos porque ele permite que objetos comporte-se de acordo com suas características específicas. Em termos de orientação a objeto, polimorfismo significa:

1 - Que podemos usar o mesmo nome para definir um método em diferentes classes na hierarquia de classes.

2 - O usuário pode enviar uma mesma mensagem para diferentes objetos que pertence a diferentes classes e sempre gerar uma resposta correta.

4.5 - IDENTIDADE DE OBJETO É a propriedade que o objeto tem que o distingue dos demais. O tipo mais comum de identidade de objeto nas linguagens de programação, nos bancos de dados e nos sistemas operacionais são os nomes de objetos definidos pelo usuário final. Utilizando a identidade do objeto, os objetos podem conter outros objetos ou se referir a eles. Isso elimina a necessidade de utilizar nomes de variáveis que não tenham suporte de identidade de objeto, mas apresenta algumas limitações práticas. Uma limitação é que um único objeto pode ser acessado de várias maneiras: assim, um objeto pode ser relacionado a diferentes variáveis o que torna difícil saber se se refere ao mesmo objeto. 4.5.1 NOME DE CAMINHO DO SISTEMA OPERACIONAL

34

Um método utilizado para a identificação de objetos são os nomes de caminhos do Sistema Operacional como o UNIX e DOS. Esses SO possuem estruturas de diretórios hierárquicas nas quais cada diretório contém um grupo de arquivos e possivelmente outros diretórios. O nome do arquivo deve ser único no diretório e cada arquivo é acessível por um caminho. 4.5.2 CHAVES IDENTIFICADORAS Um outro método de identificação de objetos é utilizar chaves exclusivas ou chaves identificadoras. Esse mecanismo é normalmente utilizado em SGBD’s. P.ex: para um armazenamento de tabela de banco de dados de funcionário a chave identificadora poderia ser o nome completo. Para itens de armazenamento em tabelas no banco de dados, a chave identificadora será o número do item. Há três problemas principais relacionados com o uso de chaves identificadoras para a identidade do objeto.

1 - Modificação das chaves identificadoras: a chave identificadora não pode (ou não deve) mudar, embora sejam dados descritos pelo usuário final.

P.ex: o nome de um gerente de vendas é chave identificadora de gerente de vendas e pode estar duplicado no objeto vendedor como um atributo.

Problema: ao mudar o gerente de vendas deve ter o cuidado de alterar suas referências.

2 - Não-uniformidade: é que as chaves identificadoras de diferentes tabelas possuem diferentes tipos (inteiro, ponto flutuante e string de caracteres).

P. Ex: A companhia X utiliza números da previdência para identificar empregado. Enquanto a companhia Y utiliza uma combinação de caracteres alfanumérico.

Problema: Uma fusão dessas duas empresas exigiria uma mudança em uma das chaves.

3 - Junções Antinaturais : recuperação de informações através do cruzamento de tabelas distinta para recuperar informações. A quebra em tabelas é resultante do processo de normalização que foge a realidade (na maioria dos casos).

4.6 - RESTRIÇÕES DE INTEGRIDADE DE BANCO DE DADOS ORIENTADO A OBJETO Por meio de transações, os sistemas de gerenciamento de bancos de dados mapeam um estado de banco de dados coerente (correto) em outro. A coerência do banco de dados é normalmente expressa por predicados, ou condições, no estado corrente do banco de dados. Os predicados podem também se aplicar a objetos ou valores de atributo no banco de dados. Os predicados que capturam a coerência de um banco de dados são chamados restrições de integridade. Geralmente, várias restrições de integridade devem ser forçosas em um estado de banco de dados para garantir sua coerência. Veja alguns exemplos:

• A idade de uma pessoa não pode ser um número negativo. • Um balancete deve ser inferior ou igual à soma dos depósitos. • Se um empregado trabalha para um departamento, deve haver um registro desse

departamento no banco de dados.

35

• O número da previdência social de cada empregado deve ser exclusivo no conjunto de todos os empregados.

• Uma pessoa deve ter um nome, e este atributo não pode ficar vazio ou nulo. Como todos esses exemplos sugerem, muitos tipos de restrições de integridade devem ser impostos a um banco de dados para manter sua coerência. Sistemas de bancos de dados relacionais possuem diversas categorias de restrições de integridade, como restrições de integridade referenciais, domínios e restrições não-nulas (NOT NULL). A maiorias dessas restrições valem também em bancos de dados orientados a objeto, embora, devido às construções orientadas a objeto e ao expressivo poder do modelo de objetos, algumas restrições não sejam mais relevantes (como as restrições referencias) ou tomem uma forma diferente (como os domínios). Na verdade, os conceitos orientados a objeto dos bancos de dados orientados a objeto introduzem outros tipos de restrição de integridade ou especificações de restrição de integridade. Entre as restrições de integridade dos bancos de dados orientados a objeto discutiremos as seguintes:

1. Restrições de chave exclusiva/primária.

2. Restrições referenciais a existenciais.

3. Restrições NOT NULL.

4. Restrições de integridade de domínio.

5. Gatilhos (triggers).

4.6.1 - RESTRIÇÕES DE CHAVE Nos bancos de dados relacionais, é comum a especificação de chaves, onde uma ou mais chaves são especificadas para várias tabelas de bancos de dados. Nos bancos de dados orientados a objeto, as chaves também são relevantes para todo tipo de grupo de tuplas ou instâncias da classe. Conjunto de instâncias de uma classe podem ser a extensão da classe ou um objeto do conjunto cujos elementos são especificados para serem instâncias da classe. Em ambos os casos, será útil identificar um ou mais atributos como chaves, ambos como uma restrição e como uma dica para fornecer pesquisas mais rápidas quando valores de chave forem fornecidos. Portanto, uma chave é um ou mais atributos de uma classe que identifica exclusivamente uma instância da classe em um grupo. Se uma chave consiste em mais de um atributo (coluna), ela é chamada chave composta. A figura 2.14 ilustra duas chaves candidatas: o número do seguro social e o nome do funcionário.

funcionario

nome dofuncionariointeiro

caracter caractercomposiçaode chavecandidata

nome

primeiro último

número doseguro social

chavecandidata

36

Figura 2.14 Chaves candidatas para a classe funcionário

4.6.2 RESTRIÇÃO REFERENCIAL EXISTENCIAL Há um outro tipo de restrição para modelos baseados na identidade , que está relacionado a restrições de integridade referencial: a restrição de identidade existencial. O objetivo de restrições existenciais é indicar que, se um objeto é compartilhado referencialmente, então ele possui um domínio “ativo”, ou seja, um grupo específico de objetos da mesma classe que no momento existem. A restrição existencial indica que o objeto deve sempre existir em seu domínio ativo. A figura 2.15 ilustra esta restrição para um objeto funcionário e número_telefone_serviço. Este número é associado ao telefone de uma classe escritório, a existência da numero_telefone_serviço esta vinculada a existência do telefone no escritório.

funcionário escritório

string

núm ero do telefonede servico

núm ero dotelefone

R E

Figura 2.15 Restrição existencial – RE

4.6.3 RESTRIÇÃO NOT NULL Os conceitos de um valor nulo(NULL) e uma restrição não-nula (NOT NULL) são úteis em bancos de dados orientados a objeto. Para suportar a restrição não-nulo, o banco de dados orientado a objeto deve suportar valores nulos. Um valor nulo representa um valor de atributo ausente. Em muitas aplicações, valores nulos são essenciais para suportar análise estatística. Por exemplo, suponha que desejemos obter a pontuação média em teste de todos os alunos de uma classe. Algumas pontuações serão nulas, isto é, estarão ausentes ou indisponíveis por razões diversas e não poderão ser consideradas. Em geral, quando um atributo ou uma coluna é declarado como do tipo T, os valores de atributo da classe podem ser valores T ou nulos. Por exemplo, se a idade for do tipo inteiro, então a idade de uma pessoa poderá ser um valor maior ou igual a zero ou nulo. O nulo representa ausência de informações ou desconhecida. 4.6.4 REGRAS DE INTEGRIDADE DE DOMÍNIO São regras declaradas como predicados que não devem ser violados. Esta associada ao domínio do estado do objeto. Ou seja, que valores são possíveis para as variáveis de instância dos objetos valorados na classe. Exemplo: Os valores válidos para dias da semanas são entre 0-6, onde 0 é domingo e 6 é sábado.

37

4.6.5 GATILHOS (TRIGGERS) São procedimentos ou ações no banco de dados que são ativadas quando determinadas condições são satisfeitas. Um gatilho, conceitualmente, consiste em um componente condição e um componente ação. Exemplo:

Trigger Condição Ação Abort_limit Atingir 75% do log file remover as transações mais

antigas não efetivadas. idle_time_limit Ocioso durante 15 minutos remover a sessão ociosa

4.7 - TRANSAÇÕES, CONCORRÊNCIA, RECUPERAÇÃO, VERSIONAMENTO DE BANCO DE DADOS ORIENTADO A OBJETO Um dos mais importantes recursos dos sistemas de gerenciamento de banco de dados é o compartilhamento concorrente dos recursos, conforme figura 2.16. Os SGBDOO’s permitem que objetos e definições de objetos possam ser utilizados por vários usuários ao mesmo tempo. Para controlar os acessos concorrentes, os SGBDOO’s utilizam várias técnicas de controle de concorrência e gerenciamento de transações. Algumas questões precisam ser consideradas no que diz respeito ao acesso concorrente a objetos.

1) Em algumas situações, diferentes usuários podem tentar atualizar o mesmo objeto ao mesmo tempo;

2) Em outras situações, diferentes grupos de usuários podem querer cooperar para a construção de vários objetos.

3) Em alguns casos, os usuários desejam realizar várias atualizações no objeto e tornar visíveis os resultados das atualizações somente depois que todas as operações se concluírem.

U s u á r io 1 U s u á r io 2

Figura 2.16 Acesso concorrente a objetos

38

Dadas as situações, o sistema de banco de dados em questão deve garantir que o banco de dados seja mantido em um estado coerente na presença de manipulações de objetos conflitantes e em conjunto. A manipulação de objetos é via transações no BD. Tradicionalmente, uma transação é uma seqüência de ações sobre os objetos persistentes e satisfaz as propriedades: atomicidade, coerência, isolamento e durabilidade (ACID).

1) Atomicidade: Uma transação é um bloco de operações executado inteiramente ou nada é executado. Em outras palavras, ou toda a seqüência de operações é aplicada ao BD ou nada é feito.

2) Coerência: é a preservação de todas as restrições semânticas do BD. Um banco de dados é considerado coerente se todas as restrições de integridade do estado do BD forem satisfeitas. Supõe-se que a execução de uma transação na ausência de interferência de outras transações concorrentes leve o banco de dados de um estado coerente a outro. Na figura 2.17 é ilustrado esta coerência.

3) Isolamento: A execução de transações concorrentes que manipulam os mesmos objetos compartilhados pode causar anomalias se as operações de intercalação não forem protegidas umas das outras. O isolamento trata da segurança fornecida pelo sistema de banco de dados em relação aos conflitos entre transações concorrentes. Há uma relação inversa entre o nível de isolamento e a capacidade de processamento de transações concorrentes. Mais especificamente, quanto mais as transações ficarem isoladas umas das outras, maior a probabilidade de conflitos e, daí, abortos de transações. As transações abordadas consomem recursos, elas devem ser tentadas novamente.

Pastas

Funcionarios

Documentos

Estado S1

Pastas

Funcionarios

Documentos

Estado S2

transação

Toda regra de integridade ésatisfeita

Figura 2.17 As transações mantêm o BD coerente

Os níveis de isolamento. a) capacidade de serialização: é o maior nível de isolamento possível sem comprometer a coerência do BD. As transações são serializáveis se a execução intercalada de suas operações produzir os mesmos efeitos no BD que sua execução em ordem serial. A figura 2.18 ilustra as transações de T1 a T5.

39

T1

T2

T5

T3T4

Execução concorrentede T1, ..., T5

T1 T2 T3 T4

T1

T5

T3 T2 T5 T4

Figura 2.18 Serialização da execução de transações

b) Leitura “sujas” (Dirty page) : é o nível mais restrito de isolamento do que a capacidade de serialização é permitir leituras “sujas”. Significa: que uma transação T1 leia os estados do objeto O1 modificados pela transação T2 antes de T2 terminar.

4) Durabilidade : é garantir que as atualizações de transações efetivadas nunca se percam. Isto significa, que as transações efetivadas podem ser recuperadas no caso de o sistema ou o meio apresentarem falhas. Uma vez que se informe ao usuário ou à aplicação que a transação se efetivou, o sistema de banco de dados deverá fornecer redundância suficiente para garantir que as atualizações serão preservadas apesar das falhas do sistema.

4.7.1 TRANSAÇÕES DE APLICAÇÕES OODB As propriedades ACID são aplicáveis tanto para aplicações de banco de dados convencional (relacional) como para aplicações de BDOO. Vários recursos são, no entanto, mais característicos de aplicações de banco de dados avançadas, como o CAD, o CAM, CASE e escritórios inteligentes.

4.7.1.1 TRANSAÇÕES DEMORADAS Transações que envolvem o acesso a vários objetos e consume um tempo relativamente longo (horas ou dias) para serem concluídas. A essas transações estão associados os conceitos de check-in e check-out. Check-out: quando inúmeras operações necessitam ser realizadas em um objeto complexo por um período longo de tempo. Check-in: processo inverso ao check-out, quando as operações são concluídas o objeto é disponibilizado para ser acessado de maneira concorrente.

4.7.1.2 TRANSAÇÕES ANINHADAS É um modelo utilizado para tratar transações longas. Consiste de um conjunto de subtransações, chamadas de transações-filhas, que são componentes de uma transação maior,

40

denominada transação-pai. As subtransações são isoladas umas das outras e satisfazem as propriedades. ACID. A figura 2.19 ilustra um transação aninhada.

Transação concluída

Transação longa

Figura 2.19 Transação demorada com subtransações aninhadas

41

4.7.2 CONTROLE DE CONCORRÊNCIA São utilizadas estratégias para a sincronização de operações de acesso e atualização intercaladas em transações concorrentes. Os níveis de isolamento das transações são capturados no mecanismo de controle de concorrência do SGBD. Tradicionalmente, três estratégias principais de controle de concorrência têm sido utilizadas:

1) Os algoritmos pessimistas: pressupõem que transações concorrentes provavelmente conflitarão e portanto adquirem bloqueios antes das operações de acesso e atualização.

2) Os algoritmos otimistas: pressupõem que as transações provavelmente operarão sem conflitos e somente na hora de efetivação são feitas conferências para garantir o isolamento das transações.

3) Versionamento: é criado uma nova versão de um objeto para a atualização. As transações que só lêem objetos sempre poderão acessar um posição anterior e coerente do BD.

Há muitas variações e combinações dessas três estratégias fundamentais. Estratégias baseadas no bloqueio são de longe os algoritmos mais utilizados nos SGBD’s. Os SGBDOO’s normalmente permitirão que o usuário ou o programa de aplicação bloqueie ou faça o check-out explícito dos objetos.

4.7.2.1 ESTRATÉGIAS DE BLOQUEIO A maioria dos algoritmos de controle de concorrência utiliza o bloqueio para sincronizar a execução de transações concorrentes. Cada objeto persistente pode ser bloqueado. Isto normalmente é feito por meio de uma tabela de bloqueio, que contém os identificadores de objeto dos objetos bloqueados. Antes que uma transação possa acessar um objeto, ela deve solicitar um bloqueio. Se pelo menos uma outra transação estiver mantendo um bloqueio no momento, a transação terá de aguardar até que o bloqueio seja liberado.

1) Bloqueio de duas fases: é normalmente utilizado para garantir que as transações sejam serializáveis. Esse protocolo separa claramente uma transação em uma fase de crescimento e outra de redução. Durante a fase de crescimento, todos os bloqueios devem ser adquiridos, possivelmente de forma incremental. Durante a fase de redução, todos os bloqueios são liberados, possivelmente de forma incremental. O seguinte protocolo de bloqueio satisfaz ao protocolo de bloqueio de duas fases:

a) antes de realizar uma operação de leitura em um objeto, a transação deve adquirir um modo de bloqueio compartilhado para esse objeto.

b) antes de realizar uma operação de gravação em um objeto, a transação deve adquirir um modo de bloqueio exclusivo para esse objeto.

c) depois de liberar um bloqueio, a transação não deve mais adquirir bloqueios.

2) Bloqueio de multigranularidade: é a existência de diferentes níveis de bloqueio (“granulo”). Permite que diferentes transações estabeleçam bloqueios em diferentes níveis. O objetivo é minimizar o número de bloqueios a serem estabelecidos ao acessar o BD. Exemplo: quando a maioria das instâncias da classe é acessada, é mais interessante bloquear a classe toda do que uma instância por vez. O objetivo fundamental do protocolo

42

de bloqueio de multigranularidade é minimizar o número de bloqueios a serem estabelecidos ao acessar o banco de dados.

3) Bloqueio de hierarquia de classe: as classes em um BDOO são organizadas em hierarquias. O bloqueio em uma superclasse bloqueia implicitamente todas as suas subclasses no mesmo modo de bloqueio.

4) Bloqueio de intenção: é estabelecer intenção de bloqueio na classe antes de estabelecer operação de bloqueio nas instâncias. Assim, uma transação deve estabelecer um bloqueio com intenção de leitura (intention-read : IR) em uma classe antes de estabelecer bloqueios de leitura em instâncias da classe. Da mesma forma, uma transação deve estabelecer um bloqueio com intenção de gravação (intention-write: IW) em uma classe antes de estabelecer bloqueios de gravação nas instâncias da classe.

Às vezes, uma transação pode querer ler muitas instâncias de uma classe e modificar somente um número pequeno dessas instâncias. Isto pode ser feito pelo estabelecimento de um bloqueio de leitura com intenção de gravação (RIW) na classe e, somente na hora de realizar a gravação o bloqueio é estabelecendo. Na tabela 2.3 é mostrada uma matriz de compatibilidade para diferentes tipos de bloqueios em uma esquema de bloqueio de multigranularidade.

Observações importantes: 1 - Os BDOO possuem dois grânulo de bloqueios: classes e instâncias. Cada classe ou

instância pode ser bloqueada no modo compartilhado ou no modo exclusivo. 2 - Quanto mais “grosso” o nível de bloqueio menor concorrência e maior “overhead” do

sistema.

RIWIWIRWR

NNSNSR

NNNNNW

SSSNSIR

NSSNNIW

NNSNNRIW

Tabela 2.3 Matriz de compatibilidade para bloqueio de multigranularidade 4.8. VERSIONAMENTO O gerenciamento de versão em um banco de dados orientado a objeto consiste em ferramentas e construções que automatizam ou simplificam a construção e a organização de versões ou configurações. Sem essas ferramentas, caberia ao usuário organizar e manter as versões. Uma maneira de fazer isso seria utilizar uma convenção de nome que controlasse as várias versões do

43

mesmo objeto e a relação das versões entre si (a árvore de derivação). Esse procedimento é muito trabalhoso e predisposto a erro. Assim, em aplicações de projeto complexas, o gerenciamento de versão é um utilitário extremamente útil e poderoso. Muitas aplicações de engenharia e de projeto utilizam o versionamento para criar progressivamente mais versões aperfeiçoadas do objeto de projeto. Em aplicações de engenharia de projeto, os objetos são normalmente armazenados em um repositório central (persistente). Os projetistas fazem o check-out do objeto persistente a partir do banco de dados, trabalham nele e, quando acharem que possuem a melhor implementação, fazem o check-in do objeto como uma versão diferente. Depois que o objeto versionado é criado, novas versões do objeto podem ser criadas de forma linear ou em grafo. A principal propriedade comum a todas as versões do mesmo objeto é a identidade do objeto. Por toda a história versionada, um objeto pode passar por muitos estados e até por modificações estruturais. Se todas as versões de um objeto forem criadas seqüencialmente, obteremos um conjunto de versões lineares. No versionamento geral, no entanto, vários projetistas podem criar versões alternativas de um objeto. Na figura 2.20 é ilustrado o conjunto de versões de um objeto O1. Onde cada versão possui sucessores e predecessores.

V2

V4 V5

V7: Versão final

V6

V3

V1: Versão original

Versões alternativas

Figura 2.20 Conjunto de versões de O1

Por exemplo, para criar uma versão no SGBD Iris, um usuário deve primeiro nomear e fazer um check-out dos sucessores e predecessores de uma versão. Usando a figura 6.1, temos: O sucessor(v2) retornará todos os sucessores de v2:{v4, v5, v7} e o predecessor (v6) retornará os predecessores de v6:{v3, v1}. 5 BANCO DE DADOS DISTRIBUÍDO Banco de dados distribuído é um banco de dados único que pode ser compartilhado por múltiplos computadores em uma rede. As aplicações acessam o banco de dados local e remoto por processamento distribuído, e com transações em tempo real. As aplicações de banco de dados distribuídos podem ser caracterizadas como aplicações de banco de dados distribuído. A complexidade do sistema de banco de dados distribuído é transparente ao usuário final, porque ele é tratado como um banco de dados lógico único pelo SGBDD – Sistema de Gerenciamento de Banco de Dados Distribuído.

44

5.1 EVOLUÇÃO PARA SGBDD A idéia de banco de dados distribuído surgiu da necessidade de acesso a dados corporativos de forma rápida. Os fatores que contribuíram para a implementação de um ambiente descentralizado foram: as operações de negócios tornaram-se descentralizada, a competitividade crescente em um nível global , a demanda do cliente favorecendo a descentralização dos dados, o surgimento do microcomputador com baixo custo substituindo o computador de grande porte (“mainframes”), a adoção de redes locais e alto número de aplicações com compartilhamento de dados. O banco de dados centralizado quanto acessado por múltiplos usuários simultaneamente fica comprometido em seu tempo de resposta (“performance”). Em função das variáveis relacionadas houve o surgimento do SGBDD. 5.1.1 VANTAGENS DO SGBDD

• Dados localizados mais próximos da demanda – os dados são distribuídos de acordo com a requisição do negócio;

• Acesso mais rápido – os dados são distribuídos em vários locais; • Processamento mais rápido – o processamento dos dados em diferentes locais não

sobrecarrega o sistema; • Facilidades de ampliações – novos pontos de dados distribuídos podem ser adicionados à

rede sem afetar as operações normais; • Melhora na comunicação – comunicação mais rápida e melhor entre as unidades de

negócios e os clientes, favorecendo a independência de informações locais necessárias aos negócios;

• Redução nos custos de operações – os custos com as linhas de comunicação entre micros ficam menores devido a distribuição dos dados.

• Menor falha – no caso de falha de alguma localidade, não afeta o sistema como um todo (na maioria das vezes).

5.1.2 DESVANTAGENS DO SGBDD

• Complexidade de gerenciamento e controle – é mais complexo que o gerenciamento centralizado, porque os dados são tratados diferentemente nas localidades. O administrador de banco de dados tem que ter a habilidade para coordenar todas as atividades do banco, como: controle de concorrência, segurança, becape, recuperação, otimização de consultas e seleção de caminhos de acesso.

• Segurança – os problemas de segurança dos dados é proporcional a quantidade de servidores, e a responsabilidade de gerenciamento dos dados é dividida para mais de uma pessoa nas localidades. Em função das LAN’s e internet exigi-se procedimentos de segurança, como firewalls;

3.2 PROCESSAMENTO DISTRIBUÍDO E BANCO DE DADOS DISTRIBUÍDO Um banco de dados pode possuir processamento e dados distribuído. Um SGBD pode armazenar dados em um único local (banco de dados centralizado) ou em diversos locais (banco de dados distribuído) e pode suportar processamento em um local ou em vários locais.

45

5.2.1 PROCESSAMENTO DISTRIBUÍDO Consiste em separar o processamento lógico do banco de dados entre dois ou mais computadores independentes conectados na rede. Por exemplo, o controle de vendas de uma empresa que possua mais de uma filial, mais com controle de entrada e saída de produtos centralizado. Neste caso, o processamento da venda é local a cada filial e banco de dados centralizado. Na figura 3.1 é ilustrado este ambiente.

Computador C

SGBD

Banco de dados de vendas

Computador A

Brasília

São Paulo Taguatinga

Rede de Comunicação

Computador B

Figura 3.1 Processamento distribuído 5.2.2 BANCO DE DADOS DISTRIBUÍDO Um banco de dados distribuído é um banco de dados armazenado em múltiplos computadores, porém em termos de visão da aplicação aparece como sendo um único banco de dados. Na figura 3.2 é ilustrado um ambiente de banco de dados distribuído. Os banco de dados distribuídos não estão sendo usados em todo o seu potencial, pois há muitos pontos a serem definidos antes de se obter toda a flexibilidade e capacidade dos SGBDD’s. 5.3 CARACTERÍSTICAS DE UM BANCO DE DADOS DISTRIBUÍDO Um sistema de banco de dados distribuído requer algumas características funcionais que podem ser agrupadas e descritas como um conjunto de características transparentes, que dar ao usuário a sensação de estar utilizando o sistema sozinho. Isto é, o usuário pensa que estar

46

trabalhando em um SGBD centralizando escondendo toda a complexidade de um SBDB distribuído com total transparência. Segue as características transparentes:

• Distribuição transparente – permite que os vários segmentos de banco de dados seja tratado como um único banco de dados lógico. O usuário não precisa saber que os dados estão particionados em diferentes localidades.

• Transação transparente – permite a atualização dos dados em diversas localidades na rede, garantindo que a transação seja completada ou abortada para manter a integridade dos dados.

• Falha transparente – garante o funcionamento do sistema caso ocorra falha em um determinada localidade.

• Performance transparente – permite que o sistema tenha a performance de um SGBD centralizado, minimizando ao máximo a degradação pelo uso da rede, buscando sempre o melhor caminho para os acessos remotos.

• Heterogeneidade transparente – permite a integração de diferentes SGBD’s locais (relacional, híbridos, objeto e outros) em um esquema global, transferindo as requisições do esquema global para o esquema do SGBD alvo.

SGBD

Banco de dados de vendas

SGBD

Banco de dados de vendas

SGBD

Banco de dados de vendas

Computador B Computador C

Computador A

Brasília

São Paulo Taguatinga

Rede de Comunicação

Figura 3.2 Banco de dados distribuído

47

6 A ARQUITETURA CLIENTE-SERVIDOR PADRÃO CORBA A arquitetura comum para atender solicitações de objetos (Common object request broker architecture – CORBA) é o mais importante e ambicioso projeto de “middleware” (servidor de regras de negócio) já empreendido pela industria de computadores. O corba é produto de um consórcio, denominado OMG (Object Management Group), que inclui em torno de 800 companhias, representado o espectro completo de industrias de computadores. A notável exceção é a MICROSOFT, que possui seu próprio padrão de objetos distribuídos, denominado DCOM (Distributed Component Object Model). Para os demais fabricantes de computadores o corba é a próxima geração de middleware. O barramento de objetos corba – ORB (Object Request Broker) define a forma de seus componentes e como eles operam. Consequentemente, pela escolha de um barramento de objetos aberto, a industria está, também, escolhendo criar campo de execução aberto para seus componentes. O que faz o corba ser tão importante é que ele define “middleware” com o potencial de incorporar todas as outras formas de “middleware” existentes no mercado. O middleware é um termo vago que engloba todos os software de distribuição necessário para suportar as interações entre o cliente e o servidor, ele é o bloco intermediário na arquitetura cliente/servidor conforme pode ser visto na figura 4.1. Corba utiliza objetos padrões para tratar as aplicações existente no barramento, e prover uma base sólida para os novos componentes. Ele especifica um conjunto extenso de serviços relativos ao barramento para criar e apagar objetos, acessá-los por nome, armazená-los em repositórios persistentes, externalizando seus estados, e definindo relacionamentos aleatórios “ad hoc” entre eles.

Cliente Middleware Servidor

Figura 4.1 Os três blocos básicos da arquitetura cliente/servidor 6.1 OBJETOS DISTRIBUÍDOS Talvez o segredo do sucesso da OMG seja criar especificações de interface e não código. As especificações são escritas em Linguagem de Definição de Interface (IDL) que define os limites dos componentes. Os componentes escritos em IDL deveriam ser portáveis através de linguagens, ferramentas, sistema operacional e rede. E com a adoção da especificação em dezembro de 1994, estes componentes passaria a interoperar com os agentes de objetos padrão CORBA. 6.2 O QUE É UM OBJETO CORBA DISTRIBUÍDO? Objetos corba são “porções inteligentes” que podem viver em qualquer lugar na rede. Eles são empacotados como componentes binários que os clientes remotos passam a acessar via invocação de métodos. A linguagem e o sistema operacional usados para criar os objetos nos servidores são totalmente transparentes ao cliente. Os clientes não necessitam saber onde os objetos distribuídos residem ou qual sistema operacional o executa. Os objetos podem estar no mesmo

48

processo do cliente ou em qualquer maquina da rede intergalática. Os clientes não necessitam saber como os objetos do servidor estão implementados. Por exemplo, um objeto servidor poderia estar implementado como um conjunto de classes C++, ou o poderia ser implementado como milhares de linhas de código COBOL, o cliente não sabe a diferença. O que o cliente necessita conhecer é a interface pública dos objetos servidores. A interface é a ligação entre cliente e servidor. 6.3 TUDO ESTÁ NA IDL Corba usa um padrão de IDL comprometida em especificar os limites dos componentes. A interface, também, é comprometida com os potenciais clientes. Isto significa que o corba não prover detalhes de implementação, a IDL pode ser utilizada para definir API’s (Application Program Interface). Os métodos especificados na IDL podem ser escritos ou invocados por qualquer linguagem que esteja preparada com o padrão corba – atualmente são C, C++, ADA, SMALLTALK, COBOL e JAVA. Os programadores utilizam os objetos corba através de construções nativas da linguagem. A IDL prover uma interface independente do Sistema Operacional e das linguagens para todos os serviços e componentes que residem no barramento do corba. A IDL permite que objetos clientes e servidores, escritos em linguagens diferentes, possam operar entre si. Na figura 4.2 é ilustra a arquitetura da IDL corba.

C Java C Java

CORBA IIOP ORB

Server Skeleton Client Stub

Figura 4.2 A IDL do corba prover ligação entre linguagens na arquitetura Cliente/Servidor

A ambição do corba é padronizar em IDL todos os “middleware” cliente-servidor e todos os componentes que são manipulados pelo ORB (Object request broker). “Torna tudo prego e é dado o martelo”. g O “prego” é a IDL corba. A IDL permite provedores de componentes especificar, na

linguagem de definição padrão, a interface e estrutura de objetos que ela suporta.

49

⎢ Para algum objeto requerer alguma coisa de outro objeto, ele deve conhecer a interface do objeto alvo.

⎢ O repositório de interface corba contém a definição de todas essas interfaces. Ele contém metadados que permite componentes descobrir outro objeto dinamicamente em tempo de execução.

g O “martelo” inclui o conjunto de serviços distribuídos que os provedores OMG fornecem. Estes serviços determinam quais objetos estão na rede, quais métodos eles provêem e quais os adaptadores de interface eles suportam.

7 BIBLIOGRAFIA 1 – [COR 97] Coronel, Carlos & Rob, Peter. DATABASE SYSTEMS:design, implementation, and

management. 3ª edição, Course Technology, 1997, Canada. 2- [ORF 97] Orfali, Robert & at.all. The Essential Client/Server Survival Guide. 2ª edição, Wiley,

1997, New York. 3 – [ORF 98] Orfali, Robert & Harley, Dan. Client/Server Programming with Java and Corba. 2ª

edição, Wiley, 1998, New York. 4 – [KHO 94] Khoshafian, Setrag. Banco de dados orientado a objeto. IBPI Press, 1994, Rio de

Janeiro. 5 – [KOR 89] Korth, Henry F. Sistema de banco de dados. McGrall-Hill, 1989, São Paulo.

50