1 ADMINISTRAO DE BANCO DE DADOS Dados so usados por diferentes pessoas em diferentes departamentos por diferentes razes.

Entretanto, administrao de dados deve prover o conceito de dados compartilhados. Usado propriamente, o SGBD facilita: 1. Interpretao e apresentao de dados em formatos teis, pela transformao de dados brutos em informao. 2. Distribuio de dados e informao para a pessoa certa na hora certa. 3. Preservao do dado e monitoramento do uso do dado por perodos de tempo adequados. 4. Controle sobre duplicao e uso de dados, internamente e externamente. Qualquer que seja o tipo da organizao, o banco de dados deve suportar todas as operaes e todos os nveis de tomada de deciso administrativa. De fato, podemos argumentar o seguinte: O papel principal do BD dar suporte s tomada de deciso administrativa em todos os nveis da organizao. A estrutura administrativa de uma organizao pode ser dividida em trs nveis: principal, central e operacional. O nvel da administrao principal toma decises estratgicas, o nvel central decises tticas e o nvel operacional toma decises operacionais diariamente, como ilustra a figura 1.1. O SGBD deve prover ferramentas que dem a cada nvel administrativo uma viso diferente do dado e deve servir de suporte ao nvel de tomada de deciso requerido. Usando esta estrutura, podemos melhor ajustar o papel designado ao banco de dados em relao as atividades tpicas de cada nvel administrativo. Nvel Principal . O diretor executivo da companhia geralmente foca a formulao de decises estratgicas sobre o posicionamento de mercado da companhia, a natureza geral das operaes da companhia, a poltica geral interna e externa da companhia e outros usos bvios que formam o futuro da companhia. Neste nvel o BD deve ser capaz de: 1. Prover informao necessria para tomada de deciso estratgica, planejamento estratgico, formulao de polticas e definies de metas. 2. Prover acesso a dados internos e externos para identificar possibilidades de crescimento e desenhar a direo deste crescimento. 3. Prover estrutura para definio e obrigao de polticas 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. nvel intermedirio. Tipicamente formula os planos operacionais para possibilitar as metas do nvel principal. Supervisiona, monitora e prov o controle geral das operaes da cia. Tambm escalona recursos com propsitos a curto e mdio prazo. Neste nvel o BD deve ser capaz de: 1. Distribuir os dados necessrios para as decises tticas e planejamento. 2. Monitorar e controlar a alocao e o uso de recursos. 3. Prover estrutura para obrigar e assegurar a segurana e privacidade dos dados no BD. Segurana significa proteger os dados de uso acidental ou intencional por usurios

no autorizados. Privacidade trata os direitos das pessoas e organizao para determinar quem, o que, quando, onde e como os dados sero usados.
Nvel Administrativo Principal Central Ttica SGBD Operacional Operacional Tipo de Deciso Estratgica

Banco de Dados

Figura 1.1 Nveis de tomada de deciso gerencial dentro de uma organizao Nvel Operacional. Os gerentes operacionais tratam as operaes dirias da companhia. A maior parte dos sistemas de informao desenvolvidos suportam esta tarefa. O BD deve ento: 1. Representar e suportar as operaes da companhia to corretamente quanto possvel. O modelo de dados deve ser flexvel a fim de incorporar todas as representaes requeridas e os dados futuramente esperados. 2. Produzir resultados de consultas com nvel de performance especficos. Respostas rpidas para um grande nmero de transaes no nvel operacional. 3. Aumentar a capacidade operacional da cia a curto prazo. O objetivo principal de um BD prover um caminho para o fluxo de informao na companhia. Um dos tpicos mais quentes no Gerenciamento de Escritrios o ambiente de escritrio sem papel, no qual todos os dados so 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 so tambm conhecidas como as corporaes ou empresas de BD. As empresas de BD devem ser definidas como a representao de dados das companhias que provem suporte para todas as operaes presentes e futuras.

1.1 INTRODUO DE UM SGBD: CONSIDERAES ESPECIAIS Ter um SGBD automatizado no garante que os dados sero utilizados corretamente para prover as melhores solues requeridas pelos administradores. Um SGBD somente uma

ferramenta para gerenciar dados e deve ser utilizada efetivamente a fim de produzir os resultados desejados. A soluo para os problemas da companhia no a mera existncias de um sistema de computador ou seus BD, mas certamente seu uso e gerenciamento efetivo. A introduo de um BD representa uma grande mudana e desafio; como ter um profundo impacto sobre a organizao. 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 organizao e no a organizao se adaptar ao SGBD. A introduo de um SGBD um processo que inclui trs aspectos importantes: 1. Tecnolgico: SGBD como software e hardware. Inclui a seleo, instalao e monitoramento do SGBD para que ele possa ser eficiente no armazenamento, acesso e segurana dos dados. 2. Gerencial: Funes Administrativas. Somente o SGBD no garante o sucesso da empresa necessrio elaborar cuidadosamente os projetos para assegurar o sucesso do banco de dados. necessrio criar uma estrutura de pessoas responsveis pela administrao do SGBD. 3. Cultural: Resistncias corporativa s mudanas. O choque cultural causado pela introduo de um SGBD deve ser avaliado cuidadosamente. A existncia de SGBD poder causa efeitos nas pessoas, funes e interaes. Normalmente as pessoas devem ser treinadas, novas funes devem ser alocadas para as pessoas e o desempenho das pessoas deve ser avaliado para o novo padro.

1.2 A EVOLUO DA FUNO DE ADMINISTRAO DE BD A administrao de dados tem suas razes no velho e descentralizado mundo de sistemas de arquivos sem BD. Cada departamento era o dono dos seus prprios conjuntos de arquivos. Consequentemente, os especialistas em processamento de dados comeou a trabalhar dentro dos departamentos. A figura 1.2 ilustra a estrutura organizacional resultante. O custo dos dados e a duplicao de gerenciamento levou a necessidade de centralizao da funo de administrao de dados conhecida como processamento eletrnico de dados ou Departamento de Processamento de Dados (DPD)
Departamento A Departamento B

Gerente

Gerente

Administrativo

Processamento de dados

Administrativo

Processamento de dados

Arquivos

Arquivos

Figura 1.2 O especialista de processamento de dados nos departamentos A chegada do SGBD e sua viso compartilhada dos dados produziu um novo nvel de sofisticao de gerenciamento e induziu que os DPDs evolussem Departamento de Sistemas de Informaes (DSI), a figura 1.3 mostra com foi funcionalmente dividido este departamento. Este departamento possua as seguintes responsabilidades: 1. Auxiliar o usurio final no gerenciamento de seus dados. 2. Gerenciar de forma integrada os dados do usurio final na diferentes aplicaes.

Sistemas de Informao

Desenvolvimento de Aplicao

Operaes de BD

Figura 1.3 A organizao interna do DSI Com o crescimento de aplicaes de BD e o aumento de complexidade dos trabalhos, surgiu a funo de Administrao da BD. A pessoal responsvel pelo controle do banco de dados centralizado e compartilhado o Administrador de Banco de Dados (DBA). O tamanho e o papel da funo de DBA vria de empresa para empresa, assim como a localizao dentro da estrutura organizacional. No organograma da empresa, a funo de DBA poderia ser definida como uma assessoria ou um elemento em um nvel do organograma. Colocar a funo de DBA como assessor freqentemente cria um ambiente de consultoria, no qual o DBA tem a capacidade de planejar estratgia de administrao de dados, porm no tem a autoridade de fora-la ou resolver possveis conflitos. A funo de DBA como um nvel no organograma (autoritrio) tem a responsabilidade e autoridade para planejar, definir, implementar, e fora poltica, padres e procedimentos usados na atividade de administrao de dados. Na figura 5.4 ilustrado as duas formas apresentadas anteriormente.
Posio Autoritria

Sistemas de Informao

Desenvolvimento de Aplicao

Administrao de BD

Operaes de BD

Posio de consultor

Sistemas de Informao Administrao de BD

Desenvolvimento de Aplicao

Operaes de BD

Figura 1.4 A localizao da funo de DBA

A deciso quanto a localizao das funes de DBA depender do estilo de gerenciamento da companhia e de fatores tais como o tamanho e complexidade das operaes e da distribuio geogrfica da companhia. Estes fatores, tambm, auxiliam da determinao da estrutura interna da rea de DBA. No existe uma estrutura organizacional padro, porm alguns fatores podem influnciar na estrutura organizacional da empresa. Tais como: O desenvolvimento de banco de dados distribudos pode forar a organizao a descentralizar aspectos funcionais da administrao de dados. O banco de dados distribudo requer um DBA central que defina e delegue responsabilidades aos DBAs locais, conseqentemente, impe ao DBA central novas e complexas atividades de coordenao. A introduo de SGBDOO, normalmente, adiciona nova maneira de modelagem de dados e atividades, assim expande e diversifica os servios do DBA. A rpida expanso dos microcomputadores e redes locais (LAN) tendem a dispersar o controle operacional dos dados, assim torna-se mais difcil a administrao de dados centralizada. O aumento da sofisticao e do poder dos pacotes de SGBD para microcomputadores prover uma plataforma de fcil uso para fornecer informaes aos departamentos. Porm, tais ambientes facilitam a duplicao de dados, o que levam os DBAs a criar novos conjuntos de tcnicas e estilos de gerenciar. Embora no exista um padro, uma pratica comum definir as funes de DBA de acordo com as fase de ciclo de vida do Banco de dados, a figura 5.4 mostra a organizao funcional do DBA. Se esta abordagem adotada, ento segue esta atividades: 1. Panejamento do banco de dados: inclui a definio de padres, procedimentos e regras de consistncia. 2. Requerimentos do banco de dados: projeto conceitual. 3. Projeto lgico e de transaes de banco de dados. 4. Depurao e teste do banco de dados.

Adm. de BD

Planejamento

Projeto

Implementao

Operaes

Treinamento

Conceitual

Lgico

Fsica

Testes

Figura 15 A organizao funcional do DBA

1.3 O PAPEL DO DBA Como um genciador o DBA deve se concentrar em controlar e planejar as dimenses da funo da adimnistrao do BD. O DBA reponsvel por: 1. Coordenar, monitorar a alocar recursos de administrao da BD: pessoas e dados. 2. Definir metas e formular planos de estratgias para a funo de admnistrao de BD. As funes incluem: Definio do esquema: a criao do esquema original do banco de dados. Isto realizado escrevendo-se um conjunto de definies que so traduzidas em DDL ou ODL para um conjunto de tabelas ou classes que so permanentemente armazenadas no dicionrio de dados. Definio da estrutura de armazenamento e do mtodo de acesso: a criao de estruturas apropriadas de armazenamento e mtodos de acesso. feito escrevendo-se um conjunto de definies que so traduzidas pelo compilador da linguagem de definio de armazenamento de dados. Personalizao do SGBD: a modificao de parmetros padres quase sempre necessria. A aplicao de correes no ambiente do SGBD. Concesso de autorizao para acesso a dados: a concesso de diferentes tipos de autorizao para o acesso a dados aos vrios usurios do banco de dados. Isto permite ao DBA regular que partes do banco de dados os diferentes usurios podem acessar. Especificao de restries de integridade: estas restries so mantidas em uma estrutura especial do sistema que consultada pelo SGBD sempre que uma atualizao for realizado no banco de dados. H uma crescente tendncia sobre a especializao da funo gerenciamento de dados. Por exemplo, o organograma organizacional usado por algumas companhias grandes faz uma distino entre um DBA e o administrador de dados (DA). O DA, tambm conhecido como o gerente do recurso informao (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 responsvel por controlar a totalidade de recursos de dados da corporao, tanto computadorizados como no. Os servios de DA envolve um grande rea de operaes se comparada ao DBA, porque o DA tem o desafio de controlar os dados computadorizados e os que esto fora do escopo do SGBD. Os papeis de DA e DBA tendem a se sobrepor, mas o DA tem uma

atribuio de responsabilidade e autoridade que o DBA no tem. O localizao do DBA dentro da estrutura da organizao varia de empresa para empresa. A tabela 5.1 mostra um contraste entre as atividades do DBA e DA. Administrador de dados (DA) Planejamento estratgico Elabora metas a longo prazo Elabora poltica e padronizao Escopo amplo Longo prazo (futuro) Orientao gerencial Independente de SGBD Administrador de Banco de Dados (DBA) Controle e superviso Executa o plano para atingir as metas Faz cumprir a poltica e procedimentos Escopo estreito Curto prazo (operaes dirias) Orientao tcnica SGBD especfico

Tabela 5.1 Contraste das atividades e caractersticas entre DA e DBA Um componente primrio do sucesso da estratgia de administrao de dados a insistncia contnua do uso correto da poltica, procedimentos e padres para a criao, uso, distribuio e remoo de dados dentro do banco de dados. O DBA deve definir, documentar e comunicar a poltica, os procedimentos e padres antes de seu uso obrigatrio. Basicamente: Poltica: so as regras gerais de direo e aes que devero ser tomadas. Padres: so regras utilizadas para avaliar a qualidade das atividades. Por exemplo, padres que definem como os programas de aplicaes devem ser estruturados, converses de nomes a serem usados pelos programadores. Procedimentos: so instrues escritas que descrevem uma srie de passos a serem seguidos durante a execuo de uma dada atividade. Para ilustrar os conceitos acima vo olhar o seguinte exemplo: Poltica: Todos os usurios deve possuir uma senha para acesso ao sistema. A senha deve ser trocada a cada 30 dias.

Padres: A senha deve possuir no mnimo 5 caracteres. A senha deve possuir no mximo 12 caracteres. O seguro social no pode ser usado como senha.

Procedimento: Para cria a senha. 1. O usurio envia uma mensagem de solicitao de criao de conta ao DBA. 2. O DBA aprova o pedido e solicita a criao da conta ao suporte. 3. O suporte cria a conta, atribui uma senha temporria e envia a informao ao usurio final. Uma cpia de criao de conta enviada ao DBA. 4. O usurio final muda a senha de temporria para permanente.

2 MODELAGEM DE DADOS Tradicionalmente, os projetistas de banco de dados tem a confiana de desenvolverem um bom projeto. Mas o bom projeto depende das respostas que ele pode dar quanto as indagaes do usurio final. O bom projeto pode ser atingido aps vrias checagem . Felizmente, a arte de projetar banco de dados pode ser reforada 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 dicionrio da lngua portuguesa modelo significa Imagem ou desenho que serve para representar em escala pequena o objeto do mundo real. Em outras palavras o modelo uma abstrao de um objeto complexo do mundo real. Um modelo de dados uma representao relativamente simples, normalmente, grfica da complexa estrutura de dados dos objeto do mundo real, no caso de modelo de dados orientado a objeto , tambm, representado as operaes que manipulam as estruturas de dados. A principal funo 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 caractersticas, relaes, restries e transformaes. Usualmente, o projetista de banco de dados usa o modelo de dados como ferramenta de comunicao para facilitar a interao entre o projetista, programadores de aplicao e o usurio final. Se o modelo de dados bem desenvolvido, ele pode favorecer um melhor entendimento da organizao. Esse importante aspecto da modelagem de dados foi resumido por um cliente, que teve a seguinte reao; Eu criei este negcio, eu tenho trabalhado com este negcio por vrios anos, e essa a primeira vez, realmente, que tenho entendido como todos os pedaos se encaixam. Um bom projeto de banco de dados a base para boas aplicaes. Contrariamente, indiferentemente da experincia dos programadores e/ou da eficincia do gerador de aplicaes, no podemos desenvolver boas aplicaes sem um bom projeto de banco de dados. Um bom projeto de banco de dados comea em construir um bom modelo de dados. A importncia do modelo de dados dificilmente pode ser desprezada. Os dados constituem a unidade de informao mais bsico utilizado por uma sistema. As aplicaes so criadas para gerenciar dados e auxiliar na transformao de dados em informaes. Portanto, os dados so vistos de diferentes formas por diferentes pessoas. Por exemplo, a diferena de viso da companhia entre gerente e administrativo. Embora o gerente e administrativo trabalhem na mesma empresa o gerente com certeza tem uma viso muito maior da companhia do que o administrativo.
2.1 O GRAU DE ABSTRAO DE DADOS

O comit de padronizao (ANSI/SPARC The American National Standards Institute/Standards Planning and Requirements Committee) definem trs modelos de dados diferentes que so baseados em graus de abstrao: conceitual, externo e interno, conforme pode ser visto na figura 2.1. Contudo, porm ao analisar a figura 2.1 tem-se a necessidade de expandir a classificao dos modelos pela adio do modelo de dados fsico, que ser a implementao do modelo interno para um SGBD especfico.
2.1.1 O MODELO CONCEITUAL

O modelo conceitual, localizado no pice da abstrao, representa um viso global dos dados. Ele uma representao dos dados globais da empresa como visto pelo gerente de mais alto nvel. O modelo conceitual a base para identificao e descrio dos principais objetos de dados, evitando-se detalhes. O modelo de dados conceitual mais utilizado o modelo Entidade-

relacionamento (E-R), que ao ser usado produzimos o esquema conceitual do escopo que est sendo modelado.
Grau de Abstrao Modelo Conceitual Modelo Externo Modelo Interno Modelo Externo Modelo Fsico baixo Mdio Independente de hardware e dependentte de software Alta Caractersticas Independente de hardaware e software

Dependente de hardware e Software

Figura 2.1 Graus de abstrao

Para ilustrar o uso de modelos conceituais, vamos examinar o ambiente de dados de um pequeno colgio. Os principais objetos do colgio so: estudante, professores, cursos, classes e sala de aula. Essas entidades so as principais entidades do os dados so coletados e armazenados. Na figura 4.2 temos a representao das entidades e os atributos da entidade estudante.
Entidade

Estudante

Professor

Curso

Turma

Sala

Matrcula Nmero_seguro Primeiro_nome ltimo_nome Nome_meio Sexo Data_nascimento Endereo Telefone

Atributos de Estudante

Figura 2.2 As entidades de um pequeno colgio Com as entidades da figura 4.2 pode-se definir e descrever os relacionamentos entre aquelas entidades (tambm chamado de associao ou interaes). Os relacionamentos podem ser classificados em um-para-um (1:1), um-para-muitos (1:N) ou muitos-para-muitos (N:M)
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 so descritos atravs dos verbos: ensinar, conter, gerar e requer. Isto , um professor ensina uma turma, uma turma contm estudantes e uma turma requer uma sala. E, que, os relacionamentos podem ser descritos de 1:N e de N:M.

Curso 1

gerar N 1 Professor ensinar N Classe N M requer contm Estudante M

1 Sala

Figura 2.3 O esquema conceitual do pequeno colgio O modelo conceitual produz algumas vantagens muito importantes. Primeiro, ele forma a base para o esquema conceitual, no qual prover um entendimento relativamente fcil do ponto de vista do ambiente dos dados. Por exemplo, pode-se ter um resumo detalhado do ambiente de dados do pequeno colgio pelo exame do diagrama do esquema conceitual apresentado na figura 2.3. Segundo, o modelo conceitual independente de software e hardware. A independncia de software significa a no dependncia do SGBD para implementar o modelo. A independncia do hardware significa que o modelo no depende do hardware usado na implementao do modelo. Portanto, mudanas no hardware ou SGBD no ter qualquer efeito no projeto do banco de dados a nvel 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 faa o mapeamento das caractersticas e restries do modelo conceitual para o modelo do SGBD escolhido. Pelo fato do
10

modelo depender da existncia de software de SGBD especfico, dito ser dependente do software. Logo, uma mudana no software de SGBD implica em mudana no modelo interno. No caso do modelo de SGBD ser relacional menos detalhamento ser necessrio no modelo interno do que se fosse escolhido outro paradigma (hierrquico, rede ou objeto). No caso da figura 2.3, foi implementado o modelo interno pela criao do banco de dados de um pequeno colgio atravs das tabelas: professor, curso, turma, estudante e sala. Tambm, devese criar uma entidade de composio entre sala e estudante. Esta entidade ter o nome de matrcula, como mostrado na figura 2.4. Em outras palavras, o esquema do banco de dados o modelo interno. O modelo interno tambm independente do hardware, porque ele no afetado quando da mudana do computador no qual o software SGBD est instalado. Logo, uma mudana no dispositivo de armazenamento ou mesmo uma mudana no sistema operacional no afetar os requerimentos no projeto do modelo interno.

2.1.3 O MODELO EXTERNO O modelo externo, baseando no modelo interno, a viso do usurio final do ambiente de dados. Entende-se por usurio final aquelas pessoas que usam os programas de aplicao, os projetistas e implementadores do modelo. O usurio final, usualmente, opera em um ambiente no qual uma aplicao tem um foco especfico em uma unidade do negcio. O negcio , geralmente, divido em unidades tais como: vendas, financeiro, propaganda, e outras. Cada unidade de negcio possui requerimentos e restries especficas, e cada usurio um conjunto de dados. Portanto, os programadores de aplicao trabalham dentro daquelas unidades de negcio vendo o conjunto de dados apropriado de forma separada no modelo externo em relao ao modelo interno, de onde os dados so derivados, essa diviso mostrada na figura 2.4.

2.1.4 O MODELO FSICO O modelo fsico opera no mais baixo nvel de abstrao, descrevendo o modo como os dados esto guardados na mdia de armazenagem, tais como discos e fitas. O modelo fsico requer a definio tanto dos dispositivos de armazenagem fsico quanto dos mtodos de acesso fsico necessrios para obter os dados dentro daqueles dispositivos. Pelo fato do modelo fsico requerer tarefas de armazenamento e recuperao precisas e especfica ao dispositivo, ele dependente do software e hardware. As estruturas de armazenamentos usadas so dependentes do software (SGBD e sistema operacional) e do tipo de dispositivo que o computador pode manipular. A preciso requerida na definio do modelo fsico demanda que o projetista de banco de dados que trabalha neste nvel 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 no necessita preocupar-se com as caractersticas fsica para o armazenamento dos dados. Contudo, implementao de um modelo relacional pode requerer ajustes finos a nvel fsico para melhorar a performance. O ajuste fino especialmente importante quando grandes banco de dados so instalados em ambiente de grande porte.
Curso 1
gerar

11
MODELO Professor

N Classe
contm Estudante

1
ensinar

Figura 2.4 Uma diviso do modelo interno em modelos externos que so 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 vrios anos e muito aceito. Ele uma ferramenta normalmente usada para: Traduzir diferentes vises dos dados entre gerentes, usurios e analistas para amoldar dentro de uma estrutura comum. Definir os requerimentos de processamento de dados e as restries de integridade para auxiliar o encontro de diferentes vises. Auxlio na implementao 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 usurio final. Esses diagramas representam os trs principais componentes do modelo que so: entidade, atributos e relacionamento. Pelo fato da entidade representar um objeto do mundo real, as palavras entidade e objeto so frequentemente utilizadas como sinnimo. Logo, as entidades ou objetos do exemplo da figura 2.3 so: 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 no a um nico objeto. Em outras palavras, a palavra entidade no modelo corresponde a uma ou mais tabelas e no a uma linha de algum ambiente relacional. No modelo E-R uma nica linha denominada de ocorrncia da entidade. A entidade representada por um retngulo contendo um nome.

2.2.1.2 ATRIBUTOS Os atributos descrevem as caractersticas que foram abstradas 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 nmero do seguro (Nseguro).

13

3 INTRODUO A BANCO DE DADOS Usualmente, as organizaes prosperam quando seus gerentes agem na base das informaes relevantes. Para gerar informaes relevantes eficientemente, necessrio acessar rapidamente os dados (fatos primrios) originais de onde as informaes requeridas foram produzidas. O gerenciamento de dados tem como foco principal uma coleo de dados armazenados e que podem ser recuperados. Logo, constitui a atividade central de qualquer organizao. 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 mantm uma coleo de: Dados do usurio final que so, os fatos primrios que interessa o usurio final. Metadados dados sobre dados, atravs do qual os dados so integrados. O metadados prover uma descrio das caractersticas 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 so os SGBDs (Sistema Gerenciador de Banco de Dados). Devido ao fato dos dados primrios serem a fonte crucial de onde as informaes so derivadas, existem boas razes pelas quais os SGBDs so importantes na nossa sociedade que baseada em informaes. Os seguintes pontos so de extrema importncia: Se os dados so importantes, devemos ter uma boa maneira de gerenci-los. Os SGBDs permitem gerenciar de forma eficiente e eficaz os dados, o que no era possvel antes do seu surgimento. Os SGBDs possuem linguagem para consulta que torna possvel obter respostas rpidas atravs de consultas ad hoc. O SGBD possibilita criar um ambiente para o usurio gerenciar e acessar os dados. A disponibilidade dos dados combinado a ferramentas que transforma os dados em informaes teis, o auxilia na tomada de decises de forma rpida e segura. O total acesso aos dados da empresa de maneira bem gerenciado promove uma viso integrada das operaes da organizao. Consequentemente, torna-se fcil ver como a ao em um segmento da companhia afeto outro segmento. O ambiente do SGBD prover um viso clara de toda a organizao, como um grande diagrama. A possibilidade de dados inconsistentes fortemente reduzida quando a base de dados projetada armazenada e gerenciada por um SGBD. Estas so algumas das vantagens do uso de SGBD. Ao longo deste trabalho iremos descobrir vrias outras vantagens do uso de SGBD. Um SGBD uma coleo 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 aplicaes e usurios. A figura 1.1 mostra que o SGBD encontra-se entre o banco de dados e os usurios. De fato, o SGBD faz as tradues dos pedidos do usurio em cdigos complexos afim de responder os pedidos.

14

Usurio Solicitao da Aplicao

Estrutura do banco de Dados

Dados

Metadados

SGBD

Cliente

Usurio

Dados Produto

Dados do usurio

Solicitao da Aplicao

Fornecedor

Figura 1.1 O SGBD gerencia a interao entre o usurio e o banco de dados

3.1 PORQUE O PROJETO DE BANCO DE DADOS IMPORTANTE Um bom banco de dados no acontece por acaso; a estrutura de seu contedo 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 informaes. 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 redundncia descontrolada so freqentemente a fonte de dificuldades para tratar informaes erradas. Um banco de dados contm informaes redundantes quando o mesmo dado mantido em localizaes diferentes para a mesma entidade. Por exemplo, quando o nmero de telefone do cliente armazenada em um arquivo de cliente, arquivo de agentes de vendas e um arquivo de mala direta. Se o nmero mudar a correo deve ser feitas em todos os locais ela ocorrer. Entretanto, a existncia de dados redundantes pode produzir entradas de dados incorretas e dificilmente ser possvel determinar qual dado est correto. Um projeto de banco de dados pobre tende a gerar erros que levam a tomar decises erradas. As organizaes que utilizam banco de dados maus projetados freqentemente falham porque os seus gerentes no tem acesso a informaes 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 informaes geradas, seus projetos so objetos de estudo detalhado em ambientes modernos. O projeto de banco de dados extremamente importante.

15

3.2 ORIGEM HISTRICA DE BANCO DE DADOS: ARQUIVOS E SISTEMAS DE ARQUIVOS Historicamente, as primeiras aplicaes em computador eram tarefas de escritrios: processamento de pedidos, folha de pagamento e outras. Tais aplicaes acessavam dados armazenados em arquivos no computador. As solicitaes por informaes eram rapidamente atendidas; relatrios eram gerados para transformar dados armazenados em informaes teis para a tomada de decises. Embora os sistemas de arquivos sejam, hoje, obsoletos, existem boas razes para estud-los sobre alguns aspectos: Os sistemas de arquivos provem uma perspectiva histrica til sobre como manipular dados. A existncia 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 fcil compreenso uma vez que o entendimento das caractersticas do sistema de arquivo so relativamente simples. Se existe a inteno em converter um sistema de arquivos obsoleto em um sistema de banco de dados, as limitaes bsicas do sistema de arquivos torna-se teis. Em um passado recente, o gerente de quase todas as organizaes pequenas eram capazes de manter os dados necessrios com o uso de sistema de arquivo manuais. Desta maneira, um sistema de arquivo era, tradicionalmente, composto de uma coleo de fichas e eram mantidas em um fichrio. A organizao dos dados dentro do fichrio era determinada de acordo com o uso do dados. O contedo de cada conjunto de fichas era logicamente relacionado. Por exemplo, o conjunto de fichas de um consultrio deveria conter dados de pacientes, uma ficha para cada paciente. A figura 1.2 mostra um sistema de arquivos simples.

Dept. Vendas

Dept. Pessoal

Arquivo de vendas

Arquivo de clientes

Arquivo de funcionrio

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 desejvel. Ao contrrio dos sistemas de arquivos, com seus vrios arquivos

16

separados e no relacionados, o banco de dados consiste de dados relacionados logicamente e armazenados em um nico repositrio de dados. Portanto, o banco de dados representa uma mudana na forma como os dados do usurio so armazenados, acessados e gerenciados. O SGBD, mostrado na figura 1.3, prover numerosas vantagens sobre o gerenciamento do sistema de arquivos por facilitar a eliminao de dados inconsistentes, dados anormais e dependncia estrutural dos dados. Melhor ainda, a gerao atual de SGBD alm de armazenar a estrutura dos dados em locais centrais, como tambm armazena o relacionamento entre os componentes. O SGBD prover todas formas necessrias para o usurio acessar os dados.
O SISTEMA DE BANCO DE DADOS

Banco de dados Dept. pessoal SGDB Pessoal

Vendas

Dept. de Vendas

O SISTEMA DE ARQUIVOS

Dept. pessoal

Dept. de Vendas

Pessoal

Cliente

Contas

Estoque

Figura 1.3 Contraste entre banco de dados e sistema de arquivos

17

No podemos esquecer que o SGBD apenas um dos vrios componentes essenciais de um sistema de banco de dados. O SGBD o corao deste ambiente, mas como o corao no funciona sozinho, assim outros componentes so necessrios.

3.3.1 O AMBIENTE DO SISTEMA DE BANCO DE DADOS O sistema de banco de dados refere-se a organizao dos componentes que define e regulamenta a coleo, 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.

Procedimentos e Padres

Escreve e fora Analistas Projetista do banco de dados Administrador do banco de dados gerencia Hardware Programadores escrevem Administrador do sistema

Usurios

Programas de Aplicaes usam acessam

Utilitrios do SGBD SGBD

Dados

Figura 1.4 O ambiente do sistema de banco de dados

1. Hardware. Identifica todos os dispositivos fsicos. O principal e mais fcil 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 perifricos acoplados ao equipamento em questo.

18

2. Software. Refere-se a coleo de programas que so utilizados pelo computador dentro do sistema de banco de dados. So trs os principais tipos de software componentes: o sistema operacional, o prprio SGBD e os programas de aplicaes. 3. Pessoas. Este componentes inclui todos os usurios do banco de dados. Baseado em funes primrias de servios, podemos identificar 5 tipos de usurios em um sistema de banco de dados: Administrador do sistema: supervisiona as operaes gerais do sistema de banco de dados. Administrador de banco de dados: conhecido como DBA, gerencia usurios 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 funo de um bom projeto. Analista de sistemas e programadores: projeta e implementa os programas de aplicaes. Eles projetam e criam as telas de captao de dados, relatrios e procedimentos que so utilizados pelos usurios para acessarem e manipularem dados do banco de dados. Usurio final: os usurios que utilizam as aplicaes para executar as operaes dirias da empresa. 4. Procedimentos: so instrues e regras que governam o projeto e os usurios do banco de dados. Eles so componentes cruciais no sistema de banco de dados. 5. Dados: a palavra dados engloba a coleo de fatos armazenados no banco de dados. Devido ao fato do dado ser a matria-prima para gerar informaes, a determinao de quais dados devem alimentar o banco de dados e como tais dados sero organizados a parte vital do servio 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 nmero de usurios e a localizao do banco de dados. 1. O nmero de usurios determina se o SGBD classificado como usurio nico (single-user) ou mltiplos usurios (multi-user). Um SGBD single-user suportar somente um usurio por vez. Em outras palavras, se o usurio A est usando o banco de dados, usurios B e C devem ficar esperando at que o usurio A conclua seu trabalho no banco de dados. Se o banco de dados single-user executar sobre um computador pessoal, ele , tambm, chamado de banco de dados desktop. 2. A localizao 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 distribuio do banco de dados em diversas localidades denominado de distribudo.

19

3.3.3 AS FUNES DE UM SGBD Um SGBD executa vrias funes importantes que garantem a integridade e consistncia dos dados no banco de dados. A maioria desta funes so transparentes ao usurio final. E a maioria desta funes s podem ser alcanadas atravs do uso de um SGBD. Essas funes incluem gerenciamento de dicionrio de dados, gerenciamento de dados armazenados, transformao e apresentao de dados, gerenciamento de segurana, controle de acesso a mltiplos usurios, gerenciamento de backup e recovery, gerenciamento de integridade de dados, linguagem de acesso a dados, interface com programas de aplicaes e interface de comunicao do banco de dados. 1. Gerenciamento de dicionrio de dados: o SGBD requer que a definio dos elementos de dados e seus relacionamentos (metadados) fiquem armazenados em um dicionrio de dados. O SGBD utiliza o dicionrio de dados para verificar a estrutura dos dados e seus relacionamentos, assim evitasse a necessidade de se colocar cdigos complexo nos programas de aplicao para acessar os dados. 2. Gerenciamento do dado armazenado: O SGBD cria estruturas complexas necessrias ao armazenamento dos dados, consequentemente livra os programas da complexa tarefa de tratar as caractersticas fsicas dos dados. Os atuais SGBD prove alm do armazenamento dos dados, armazena: os formulrios de entrada de dados ou definies de telas, definies de relatrios, regras de validao de dados, cdigo de procedimentos, estruturas para manipular com sons e imagens, e mais. 3. Transformao e apresentao de dados: O SGBD transforma os dados de entrada conforme as estruturas de dados que so requeridas para armazen-los. Assim, o SGBD evita que os programas faa a distino entre formato de dados lgico e fsico. Para manter a independncia de dados, o SGBD traduz os requerimentos lgicos em comandos que localiza fisicamente os dados e os recupera. Em outras palavras, o SGBD prover aos programas de aplicaes com independncia de software e abstrao de dados. 4. Gerenciamento de segurana: O SGBD cria um sistema de segurana que obriga a todos a passar por este sistema e mantm a privacidade dos dados. As regras de segurana determinam quais usurios podem acessar o banco de dados, quais itens de dados os usurios podem acessar e que operaes de manipular dados o usurio pode executar (leitura, adicionar, apagar e modificar). Isto especialmente importante em sistemas de banco de dados multi-usurios onde vrios usurios podem acessar o banco de dados simultaneamente. 5. Controle de acesso a mltiplos usurios: O SGBD cria estruturas complexas que permite muitos usurios acessarem os dados. Com objetivo de prover integridade e consistncia de dados, o SGBD utiliza algoritmos sofisticados para assegurar que vrios usurios 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 recuperao do banco de dados de forma segura e integra. Os atuais SGBD provem utilitrios que permite ao DBA executar procedimento de becape e recuperao. A recuperao do banco de dados necessria aps uma falha e as vezes preciso lanar mo do becape para restaurar o banco de dados a um estado consistente. 7. Gerenciamento de integridade de dados: O SGBD aplica e fora as regras de integridade de dados para eliminar problemas de integridade de dados, consequentemente minimiza a redundncia e maximiza a consistncia dos dados. Os relacionamentos de dados

20

armazenados no dicionrio de dados so usados para fora a integridade de dados. Assegurar integridade de dados especialmente importante em sistemas de banco de dados orientados a transaes. 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 no procedural, isto ela permite que o usurio especifique o que deve ser feito sem ter que especificar como ser feito. As linguagens de consulta do SGBD contm dois componentes: um a linguagem de definio de dados (DDL) e o outro a linguagem de manipulao de dados (DML). A DDL define as estruturas na qual os dados sero criados e a DML permite o usurio final extrair dados do banco de dados. O SGBD, tambm, permite acesso aos dados atravs de linguagens procedurais (3GL), tais como COBOL, C, PASCAL, Visual Basic e outras. O SGBD, tambm, prover utilitrios administrativos que so usados pelos DBAs e projetistas de banco de dados para criar, implementar, monitorar e manter o banco de dados. 9. Interface de comunicao do banco de dados: A atual gerao de SGBD prover rotinas de comunicao especiais projetadas para permitir que o banco de dados atenda solicitaes dos usurios dentro de um ambiente de rede de computadores. De fato, a capacidade de comunicao dos SGBDs o aspecto essencial dos modernos SGBDs. Por exemplo, o SGDB poderia prover funes de comunicao para acessar o banco de dados atravs da internet, usando browsers internet como o netscape ou o explorer como front end. Neste ambiente, a comunicao pode ser feita de vrias maneiras: O usurio final pode gerar consultas, atravs de filtragens em formulrios, para serem tratadas pelo World Wide Web. O SGBD pode, automaticamente, publicar relatrios pr-definidos na internet, usando o formato Web atravs de browser. O SGBD pode conectar-se a um terceiro system para distribuir informaes via Email ou outras aplicaes 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 orientao a objeto. Por um lado, a necessidade de realizar manipulaes complexas em bancos de dados existentes as novas geraes de aplicaes de bancos de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicaes de linguagens orientadas a objeto e sistemas esto exigindo capacidades de bancos de dados, tais como continuidade, simultaneidade e transaes, dos seus ambientes. Estas necessidades esto levando criao de sistemas poderosos, chamados de dados orientados a objeto, como mostrado na figura 2.1. As grandes setas representam herana, e bancos de dados orientados a objeto combinam (herdam) caractersticas e aptides 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 comearam a se tornar produtos comercialmente viveis. Hoje, eles so mais de 25 produtos no mercado que podem ser caraterizados como produtos de bancos de dados orientados a objeto. Alm disso, os comerciantes de bancos de dados relacionais esto comeando a incorporar caractersticas de orientao a objeto em seus produtos de prxima gerao baseados em SQL.

21

Tipo abstrato de dados

Herana

Identidade do objeto

Orientao a objeto

Recuperao Transao Consulta Verso

Persistncia

Integridade Continuidade

Aptides de Banco de Dados

Segurana

Desempenho

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 comeando a se formar sobre o que orientao a objeto e o que so bancos de dados orientados a objeto, ainda h alguma confuso. Mas, existem grupos que esto trabalhando a padronizao de um ambiente orientado a objeto, como o OMG (Object Management Group). Como j mencionado, os bancos de dados orientados a objeto integram a orientao a objeto com aptides de bancos de dados. Atravs de construes orientadas a objeto, os usurios podem esconder os detalhes da implementao de seus mdulos, compartilhar a referncia a objetos e expandir seus sistemas atravs de mdulos existentes. A funcionalidade de banco de dados necessria para assegurar o compartilhamento concomitante e a continuidade das informaes nas aplicaes. Atravs dos bancos de dados, os usurios podem obter o estado em que os objetos se encontram, e estar atualizados entre as vrias solicitaes de programa, e vrios usurios podem ao mesmo tempo compartilhar a mesma informao. Os bancos de dados orientados a objeto combinam os benefcios e conceitos da orientao a objeto com a funcionalidade dos bancos de dados. Nesta apostila, as seguintes definies sero usadas como referncia para caracterizar bancos de dados orientados a objeto: A orientao a objeto definida como: Orientao a objeto = tipagem de dados abstratos + herana + identidade do objeto

22

Aptides de bancos de dados so definidas assim: Aptides de bancos de dados = continuidade + concomitncia + transaes + recuperao + filtragem + atualizao + integridade + segurana + desempenho Bancos de dados orientados a objeto = orientao a objeto + aptides de banco de dados.

4.2 ORIENTAO A OBJETO uma disciplina abrangente, que tem permeado muitas reas em computao, incluindo: linguagens, interfaces com usurio, inteligncia artificial, sistemas operacionais e banco de dados. Pode ser definida como as disciplinas de modelagem de Software que tornam fcil construir sistemas complexos a partir de componentes individuais. Que proporciona conceitos e ferramentas para modelar e representar o mundo real. As vantagens da orientao a objeto na programao e modelagem de dados so muitas. Como: Permite representao mais direta do modelo de mundo real. As transformaes das requisies do sistema (definidas em termos de usurios) para a especificao do sistema (definida em termos de computador) so fortemente reduzida. Possui a habilidade de construir grandes programas a partir de outros pequenos, prfabricados.

4.3 SUMRIO DOS CONCEITOS DE ORIENTAO A OBJETO Os trs aspectos mais fundamentais do paradigma orientado a objeto so tipos de dados abstratos, herana 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 so usados para descrever um conjunto de objetos com a mesma representao. Vrias operaes so associadas com cada tipo de dados. Tipos de dado abstratos estendem a noo de um tipo de dados escondendo a implementao das operaes definidas pelo usurio (mensagens) associadas com o tipo de dados. Linguagens que suportam tipos de dados abstratos provm construes para definir estruturas e as operaes usadas para manipular ocorrncias (instncias) das estruturas de dados diretamente. Alm disso, todas as manipulaes de instncias dos tipos de dados so feitas exclusivamente atravs de operaes 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 operaes definidas: AdicionaNovaConta, DarPromoo e MudaCota. O importante a considerar sobre a classe vendedor que de maneira a inteirar com as instncias desta classe, estas operaes so suficientes. Um procedimento que venha utilizar esta classe no precisa se preocupar em como cada operao foi implementada, o que precisa fazer utilizar as operaes para extrair as informaes ou atualizar o estado do pessoal de vendas. Uma linguagem que permita tipos de dados abstrato permitir que instncias de tipos de dados sejam manipuladas somente atravs de uma coleo de operaes associadas com o tipo.

N om e Id a de C on ta O rdem V a ri v eis de inst ncia

A dicion a N ov a C on ta D a rP rom o o M u d a C ota O pera es

C la sse V endedor

Figura 2.2 A classe vendedor.

4.3.2 HERANA O segundo conceito orientado a objeto poderoso herana. Atravs da herana, mdulos de Software (classes) podem ser construdos no topo de uma hierarquia de mdulos existente. O comportamento da herana capacita o compartilhamento de cdigo (e da a reusabilidade) entre mdulos de Software. Considere a hierarquia de pessoas ilustrada na figura 2.3. Aqui cada trabalhador de escritrio uma Pessoa. Semelhantemente, cada estudante uma Pessoa. Pessoal de vendas, engenheiros e secretrias so Pessoa.
Pessoa

Funcionrio

Estudante

Vendedor

Secretria

Graduado

No-graduado

Engenheiro

Figura 2.3 Hierarquia de classes

24

A relao de herana indica que alm dos atributos ou operaes particulares a uma subclasse, todas as operaes e atributos da superclasse so herdados pelas subclasses. Esta a essncia das hierarquias de heranas. Tipos de objetos herdam a maioria dos seus atributos de tipos genricos 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 orientao a objeto uma metodologia de modelagem e desenvolvimento baseada nos conceitos de orientao a objeto. Que pode ser definida mais precisamente como:
Orientao a objeto Um conjunto de esquemas e princpios de desenvolvimento baseados em estruturas de computao independentes conceitualmente conhecidas com objeto. Cada objeto representa uma entidade do mundo real com a habilidade de interagir consigo e com outros objetos.

Como podemos ver na definio, o uso de objetos torna a modularidade quase inevitvel. Os conceitos de orientao a objeto tem sido largamente aplicada em vrias disciplinas relacionadas com computao, especialmente aquelas que envolve programao complexas e problemas de projeto. A tabela 2.1 resume algumas das contribuies para a orientao a objeto das vrias disciplinas relacionadas com computao.
rea relacionada a Computao Linguagem de programao Contribuies para a Orientao a Objeto Reduo do nmero de linhas de cdigo Diminuio do tempo de desenvolvimento Aumento da reusabilidade de cdigo Mais fcil a manuteno do cdigo Aumento da produtividade do programador Aumento na habilidade de criar interface easy-touse Sistemas mais amigveis para usurio final Facilita a definio de padres Suporta tipo abstratos de dados Suporta objetos complexos Suporta a multimdia Captura mais a semntica dos modelos de dados Representa melhor o mundo real Aumento da portabilidade do sistema, consequentemente melhora a interoperabilidade do sistema

Interface de usurio grfica (GUI)

Banco de dados

Projeto Sistema Operacional

Tabela 2.1 Resumo da contribuio das vrias disciplinas 4.4.1 A EVOLUO DOS CONCEITOS DE ORIENTAO A OBJETO

25

Os conceitos de orientao a objeto tem como base a programao orientada a objeto (POO), que foi desenvolvida como forma alternativa de programao em relao aos mtodos 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 relaes e restries, e escrever procedimentos necessrios para produzir certos resultados. Logo, no ambiente de programao os dados so os componentes passivos, enquanto que os procedimentos que manipulam os dados so os componentes ativos. A rgida distino entre dados e procedimento fortemente visto em linguagens procedurais, como exemplo a linguagem COBOL. Utilizando um linguagem procedural, o programador invoca uma aplicao, que manipula os dados para prover informaes. E de forma contrria, em ambientes de POO o programador solicita aos objetos que execute operaes sobre eles. Os primeiros conceitos de OO apareceram em linguagens de programao tais como: Ada, Algol, LISP, e SIMULA. Cada uma destas linguagens de programao fixa o estgio da introduo dos conceitos de OO, que foram expandidos pelas linguagens sucessoras. Atualmente, O Smalltalk e C++ so as linguagens de programao OO que dominam o mercado. Elas diferem substancialmente no nvel de incluso da orientao a objeto. O Smalltalk representa um ambiente puro de OO, enquanto que C++ essencialmente uma extenso da linguagem C que suporta OO. As LPOO foram desenvolvidas para prover um ambiente o mais natural possvel aos programadores de Software. Os principais objetivos foram: Prover um ambiente de desenvolvimento de Software de fcil uso. Prover uma poderosa ferramenta para modelagem de Software atravs de prototipao. Diminuio da equipe de desenvolvimento pela reduo da quantidade de cdigo. Melhoria da produtividade do programador em funo da reusabilidade de cdigo. A adoo de POO muda no somente o modo pelo qual os programas so escritos como tambm 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 vrios atributos importantes: 1. O conjunto de dados no so passivos, isto no so tratados de forma isolada. 2. Dados e procedimentos so 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 cdigo torna-se fcil e mais natural produzir mdulos de sistemas reusveis.

4.4.2. CONCEITOS DE ORIENTAO A OBJETO A orientao a objeto tem seus conceitos baseado em LPOOs, que freqentemente so consideradas como linguagens criadas, principalmente, por programadores para programadores, que tende programar a seu modo no seu prprio mundo.

4.4.2.1 OBJETOS: COMPONENTES E CARACTERSTICAS

26

Em sistemas orientados a objeto tudo tratado como sendo objetos, como: um estudante, uma fatura, um avio, um empregado, um servio, um painel de menu, um relatrio, e outros. Alguns objetos so palpveis (real) e outros no (abstrato). Podemos definir um objeto dentro do ambiente de orientao a objeto da seguinte forma:
OBJETO Um objeto uma representao abstrata das entidades do mundo real que tem um identificador nico, propriedades embutidas, e a habilidade de interagir com outros objetos e consigo mesmo.

Note a diferena entre entidade e objeto. A descrio de uma entidade baseada nos dados componentes e nos relacionamentos com outras entidade, porm falta a habilidade para manipullos. Posteriormente, outras diferenas sero apresentadas. O ponto forte da definio de objetos a identidade nica. Para enfatizar este ponto, examinemos os objetos do mundo mostrados na figura 2.4. Observe que, embora eles possuam caractersticas comuns como: nome, seguro social, endereo, data de nascimento, e outras, cada objeto tem existncia independente no tempo e no espao.
Joo 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 no podem compartilhar o mesmo OID. O OID atribudo pelo sistema no momento que o objeto criado e no pode ser mudado sob qualquer circunstncia. No podemos confundir a chave primrio do modelo relacional com o OID. Em contraste com o OID, a chave primria baseada em valores fornecidos pelo usurio para selecionar atributos e pode ser mudada a qualquer momento. O OID atribudo pelo sistema, e no depende dos valores dos atributos do objeto, e no pode ser mudado. O OID pode ser apagado somente se o objeto for apagado, e aquele OID no poder ser reutilizado. Alm disso, o OID nico no a ligado ao

27

endereo fsico na memria permanente (disco rgido). Esta caracterstica, permite aos sistemas orientados a objetos a manter um independncia de dados fsica.

4.4.2.3 ATRIBUTOS (VARIVEIS DE INSTNCIAS) Os objetos so descritos atravs de seus atributos, conhecidos como variveis de instncia em um ambiente orientado a objeto. Por exemplo, o estudante Joo B. Santos mostrados na tabela 2.2. Cada atributo tem um nome nico e um tipo de dados associado. Por exemplo, o nmero_seguro, o primeiro_nome, e outros. Tipos de dados tradicionais, tambm conhecidos como tipos de dados bsicos, so utilizados na maioria das linguagens de programao e inclui tipos como: real, int, string e outros.

Variveis de Instncia Nmero_seguro Primeiro_nome Nome_meio ltimo_nome Data_nascimento MGA_Semestre MGA_Total Disciplinas

Valorao 45.758.999 Joo B. Santos 27/02/1976 2.89 3.23 Matemtica, ingls, outras

Tabela 2.2 Os atributos do objeto estudante Os atributos, tambm, possuem domnios. O domnio descreve o conjunto de todos os possveis valores que um atributo possa ter. Por exemplo, a mdia 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 mantm-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 mtodo.

4.4.2.4 MENSAGENS E MTODOS Para entender mensagens e mtodos, vamos imaginar um objeto como sendo uma noz. O ncleo da noz representa as estruturas de dados do objeto, e a casca seus mtodos, conforme a figura 2.5.

28

Mtodo 1

Mtodo 2

Dados
Mtodo 3 Mtodo 4

Objeto X Figura 2.5 A representao de um objeto

Toda operao executada sobre um objeto deve ser implementada por mtodo. Os mtodos so usados para mudar os valores dos atributos do objeto ou retornar valores de atributos de objetos selecionados. Os mtodos representam as aes do mundo real, tais como o nmero do seguro do estudante, adicionar um estudante a um curso, ou imprimir o nome e endereo de algum estudante. Fazendo-se uma analogia mtodos so equivalentes as funes em linguagens tradicionais. Em se tratando de orientao a objetos, mtodos representam os comportamentos dos objetos. Todo mtodo identificado por um nome e possui um corpo. O corpo composto de instrues de computao escritas em alguma linguagem de programao para representar as aes do mundo real. Com base na tabela 2.2 podemos definir um mtodo que retornar a mdia das notas acumuladas total e no semestre para estudante, como segue:
Nome do mtodo

Mtodo MdiaMGA: xmga = 0;

Nome das variveis de instncia

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

Corpo do mtodo Retorna a mdia

Para invocar um mtodo uma mensagem tem que ser enviada o objeto. Uma mensagem enviada com a especificao do objeto receptor, o nome do mtodo e todos os parmetros necessrios. A estrutura interna do objeto no 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 implementao. A habilidade de esconder os detalhes internos do objeto (atributos e mtodos) 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 variveis de instncia do outro objeto. Para permitir executar acesso a outro objeto, o como do objeto deve conter referncias aos mtodos do outro objeto). Na figura 2.6, podemos ver o esquema de envio de mensagens entre objetos.

29

Objeto A
Eventos do mundo real Mtodo X

Objeto B
Mtodo Y

Objeto C
Mtodo Z

Dado
Mtodo T

Dado
Mtodo U

Dado
Mtodo V

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 diferenas. Objetos que compartilham caractersticas comuns so agrupados em classes. Em outras palavras, a classe uma coleo de objetos similares com estrutura compartilhada (atributos) e procedimentos (mtodos). Uma classe contm a descrio da estrutura de dados e os detalhes de implementao dos mtodos 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 instncia da classe ou instncia objeto. Na figura 2.7. podemos ver a representao de uma classe.
Mtodo 1 Objeto 1 Mtodo 2 Mtodo 3 Objeto 2 Mtodo 4 Objeto 3

A classe contm a descrio dos mtodo que representa o comportamento dos objetos na classe.

Uma classe composta de uma coleo de objetos.

Objeto 4

objeto 5

Objeto 6

As instncias objeto (1,2,3,4,5 e 6) compartilham a estrutura e os mtodos da classe.

Figura 2.7 Ilustrao 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 mtodos). Vamos considera os mtodos: mdia_mga, disciplinas_cursando e grade_horria. Cada instncia de uma classe um objeto com um nico OID, e cada objeto sabe a qual classe pertence.

30

mtodos

mdia_mga

disciplinas_cursando

grade_horria

Objetos
Joo B. Santos Maria A. Silva Pedro P. Alves

Variavis de instncia

Nmero_seguro Primeiro_nome Nome_meio Data_nascimento MGA_semestre MGA_total Disciplinas

Figura 2.8 Representao da classe estudante

4.4.2.6 PROTOCOLO A coleo de mensagens da classe, cada uma identificada por um nome, estabelece o objeto ou protocolo da classe. O protocolo representa os aspectos pblicos dos objetos, isto , os aspectos so conhecidos por outros objetos como tambm pelo usurio final. Em contrapartida, a implementao dos mtodos e da estrutura constitui os aspectos privados do objeto, na figura 2.9 so ilustrados tais aspectos.
Protocolo Mensagem 1 Interface pblica Mensagem 2 Mensagem 3 Mensagem 4
Mtodo 3 Mtodo 1 Mtodo 2

Dados
Mtodo 4

Implementao privada

Figura 2.9 Os aspectos privados e pblicos do objeto Usualmente, uma mensagem enviada para uma instncia da classe (objeto). Quando o objeto receptor uma classe, a mensagem invocar um mtodo da classe. Um exemplo de mtodo da classe o mtodo new da linguagem smalltalk. Usando-se smalltalk , o mtodo de classe new um gatilho (trigger) para criar novos instncias na classe (objeto com OID nico) receptora. Devido ao fato do objeto ainda no existe, a mensagem new enviada para a classe e no para o objeto.

31

Aspecto Privado

Aspecto Pblico

Protocolo

Definio da classe
Variveis de instncia so nomes de

uma coleo de

Mtodos

Mensagens

pertence a uma define um conjunto de valores para suas implementado por conjunto um de

Objeto

que dispara um

tem

Estado

OID (nico)

Procedimento

Figura 2.10 Sumrio da caractersticas de orientao a objeto Para entender melhor os conceitos que foram discutidos anterior a figura 2.10 resume as caractersticas de objeto.

4.4.2.7 SUPERCLASSE, SUBCLASSE E HERANA Classes so organizadas em hierarquia de classes. Uma hierarquia de classe assemelha-se a uma rvore de cabea 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 caractersticas comuns. Por exemplo, uma classe automvel inclui carros de luxos e, tambm, carros populares. A figura 2.11 ilustra a generalizao instrumentos musicais que inclui as especializao instrumento de cordas e instrumentos de sobro. A hierarquia de classe introduz um poderoso conceito da orientao a objeto conhecido com herana. Herana a habilidade de um objeto dentro de uma hierarquia herdar a estrutura de dados e procedimentos (mtodos) de uma acima na hierarquia. Na figura 2.11 a classe piano herda a estrutura de dados e os mtodos da superclasse instrumentos de corda e de instrumentos musicais. E atravs da herana que sistemas de orientao a objeto permite a reusabilidade de cdigo. Existem duas variaes de herana: a simples e a mltipla.

32

Instrumentos musicais

superclasse

superclasse/ Instrumentos de corda Instrumentos de sobro subclasse

piano

violino

guitarra

corneta

flauta

subclasse

Figura 2.11 A hierarquia de classe instrumentos musicais

4.4.2.7.1 HERANA SIMPLES

A herana simples existe quando uma classe tem somente um pai imediato. Na hierarquia de instrumentos musicais as heranas ilustradas na figura 2.11 so do tipo simples. A maioria dos sistemas suportam herana simples. Quando o sistema envia uma mensagem para um objeto da classe, a hierarquia inteira pesquisada para comparar o mtodo, usando a seguinte seqncia: 1 - Busca a classe a qual o objeto pertence. 2 - Se o mtodo no encontrado, ento busca na superclasse. O processo de busca repetido at que uma das situaes abaixo ocorra: 1 - O mtodo encontrado. 2 - O topo da hierarquia encontrado. O sistema gera uma mensagem indicativa de que o mtodo no foi encontrado.

4.4.2.7.2 HERANA MLTIPLA

A herana mltipla existe quando uma classe possui dois ou mais pais. Os objetos da classe herda as caractersticas de suas superclasses. A figura 2.12 ilustra que uma classe pode ser derivada de vrias superclasses localizadas um nvel acima na hierarquia de classes.

Veculo motorizado

Bicicleta

superclasses

motocicleta

subclasse

Figura 2.12 Herana mltipla

33

4.4.2.8 SOBREPOSIO DE MTODOS E POLIMORFISMO

Podemos sobrepor a definio de mtodos da superclasse pela definio de mtodos a nvel da classe. Para ilustra a sobreposio de mtodos, vamos utilizar a hierarquia de classes empregados descrita na figura 2.13.
empregado Varivel de instncia: salrio Mtodo: bonus = salrio * 0.05 Varivel de instncia: Pago_vo_acumulado Mtodo: bonus = pago_vo_acumulado * 0.05

piloto

mecnico

Figura 2.13 Sobreposio de mtodo na hierarquia de classe empregado Vamos examinar o exemplo apresentado na figura 2.13, note que definimos um mtodo denominado bnus para calcular a gratificao de natal para todos os empregados. A computao do bnus especifica para cada categoria de empregado. No caso apresentado, com exceo de piloto, um empregado recebe uma gratificao de salrio igual a 5 porcento de seu salrio. Pilotos recebem de gratificao de natal o acumulado pago por vo que muito melhor do que o salrio anual. Por definio o mtodo bnus da classe de piloto substituir o mtodo herdado na classe empregado, e o mtodo bnus ser sobreposto na classe piloto pelo seu mtodo local e ser aplicado a todos os objetos da classe. Contudo, a redefinio do mtodo bnus na classe piloto no afetar o clculo da gratificao dos demais empregados. De forma contrria a sobreposio de mtodos, polimorfismo permite que diferentes objetos respondam a mesma mensagem de forma diferente. Polimorfismo um aspecto muito importante no ambiente de orientao a objetos porque ele permite que objetos comporte-se de acordo com suas caractersticas especficas. Em termos de orientao a objeto, polimorfismo significa: 1 - Que podemos usar o mesmo nome para definir um mtodo em diferentes classes na hierarquia de classes. 2 - O usurio 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 programao, nos bancos de dados e nos sistemas operacionais so os nomes de objetos definidos pelo usurio 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 variveis que no tenham suporte de identidade de objeto, mas apresenta algumas limitaes prticas. Uma limitao que um nico objeto pode ser acessado de vrias maneiras: assim, um objeto pode ser relacionado a diferentes variveis o que torna difcil saber se se refere ao mesmo objeto.

4.5.1 NOME DE CAMINHO DO SISTEMA OPERACIONAL

34

Um mtodo utilizado para a identificao de objetos so os nomes de caminhos do Sistema Operacional como o UNIX e DOS. Esses SO possuem estruturas de diretrios hierrquicas nas quais cada diretrio contm um grupo de arquivos e possivelmente outros diretrios. O nome do arquivo deve ser nico no diretrio e cada arquivo acessvel por um caminho.

4.5.2 CHAVES IDENTIFICADORAS

Um outro mtodo de identificao de objetos utilizar chaves exclusivas ou chaves identificadoras. Esse mecanismo normalmente utilizado em SGBDs. P.ex: para um armazenamento de tabela de banco de dados de funcionrio a chave identificadora poderia ser o nome completo. Para itens de armazenamento em tabelas no banco de dados, a chave identificadora ser o nmero do item. H trs problemas principais relacionados com o uso de chaves identificadoras para a identidade do objeto. 1 - Modificao das chaves identificadoras: a chave identificadora no pode (ou no deve) mudar, embora sejam dados descritos pelo usurio 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 referncias.
2 - No-uniformidade: que as chaves identificadoras de diferentes tabelas possuem diferentes tipos (inteiro, ponto flutuante e string de caracteres).

P. Ex: A companhia X utiliza nmeros da previdncia para identificar empregado. Enquanto a companhia Y utiliza uma combinao de caracteres alfanumrico. Problema: Uma fuso dessas duas empresas exigiria uma mudana em uma das chaves.
3 - Junes Antinaturais : recuperao de informaes atravs do cruzamento de tabelas distinta para recuperar informaes. A quebra em tabelas resultante do processo de normalizao que foge a realidade (na maioria dos casos).

4.6 - RESTRIES DE INTEGRIDADE DE BANCO DE DADOS ORIENTADO A OBJETO

Por meio de transaes, os sistemas de gerenciamento de bancos de dados mapeam um estado de banco de dados coerente (correto) em outro. A coerncia do banco de dados normalmente expressa por predicados, ou condies, no estado corrente do banco de dados. Os predicados podem tambm se aplicar a objetos ou valores de atributo no banco de dados. Os predicados que capturam a coerncia de um banco de dados so chamados restries de integridade. Geralmente, vrias restries de integridade devem ser forosas em um estado de banco de dados para garantir sua coerncia. Veja alguns exemplos: A idade de uma pessoa no pode ser um nmero negativo. Um balancete deve ser inferior ou igual soma dos depsitos. Se um empregado trabalha para um departamento, deve haver um registro desse departamento no banco de dados.

35

 O nmero da previdncia social de cada empregado deve ser exclusivo no conjunto de todos os empregados. Uma pessoa deve ter um nome, e este atributo no pode ficar vazio ou nulo. Como todos esses exemplos sugerem, muitos tipos de restries de integridade devem ser impostos a um banco de dados para manter sua coerncia. Sistemas de bancos de dados relacionais possuem diversas categorias de restries de integridade, como restries de integridade referenciais, domnios e restries no-nulas (NOT NULL). A maiorias dessas restries valem tambm em bancos de dados orientados a objeto, embora, devido s construes orientadas a objeto e ao expressivo poder do modelo de objetos, algumas restries no sejam mais relevantes (como as restries referencias) ou tomem uma forma diferente (como os domnios). Na verdade, os conceitos orientados a objeto dos bancos de dados orientados a objeto introduzem outros tipos de restrio de integridade ou especificaes de restrio de integridade. Entre as restries de integridade dos bancos de dados orientados a objeto discutiremos as seguintes: 1. Restries de chave exclusiva/primria. 2. Restries referenciais a existenciais. 3. Restries NOT NULL. 4. Restries de integridade de domnio. 5. Gatilhos (triggers).

4.6.1 - RESTRIES DE CHAVE

Nos bancos de dados relacionais, comum a especificao de chaves, onde uma ou mais chaves so especificadas para vrias tabelas de bancos de dados. Nos bancos de dados orientados a objeto, as chaves tambm so relevantes para todo tipo de grupo de tuplas ou instncias da classe. Conjunto de instncias de uma classe podem ser a extenso da classe ou um objeto do conjunto cujos elementos so especificados para serem instncias da classe. Em ambos os casos, ser til identificar um ou mais atributos como chaves, ambos como uma restrio e como uma dica para fornecer pesquisas mais rpidas quando valores de chave forem fornecidos. Portanto, uma chave um ou mais atributos de uma classe que identifica exclusivamente uma instncia 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 nmero do seguro social e o nome do funcionrio.
funcionario
chave candidata nmero do seguro social nome

inteiro
primeiro

nome do funcionario
ltimo composiao de chave candidata

caracter

caracter

36

Figura 2.14 Chaves candidatas para a classe funcionrio

4.6.2 RESTRIO REFERENCIAL EXISTENCIAL

H um outro tipo de restrio para modelos baseados na identidade , que est relacionado a restries de integridade referencial: a restrio de identidade existencial. O objetivo de restries existenciais indicar que, se um objeto compartilhado referencialmente, ento ele possui um domnio ativo, ou seja, um grupo especfico de objetos da mesma classe que no momento existem. A restrio existencial indica que o objeto deve sempre existir em seu domnio ativo. A figura 2.15 ilustra esta restrio para um objeto funcionrio e nmero_telefone_servio. Este nmero associado ao telefone de uma classe escritrio, a existncia da numero_telefone_servio esta vinculada a existncia do telefone no escritrio.
funcionrio
n m ero do telefon e de servico

escritrio
n m ero do telefon e

string RE

Figura 2.15 Restrio existencial RE

4.6.3 RESTRIO NOT NULL

Os conceitos de um valor nulo(NULL) e uma restrio no-nula (NOT NULL) so teis em bancos de dados orientados a objeto. Para suportar a restrio no-nulo, o banco de dados orientado a objeto deve suportar valores nulos. Um valor nulo representa um valor de atributo ausente. Em muitas aplicaes, valores nulos so essenciais para suportar anlise estatstica. Por exemplo, suponha que desejemos obter a pontuao mdia em teste de todos os alunos de uma classe. Algumas pontuaes sero nulas, isto , estaro ausentes ou indisponveis por razes diversas e no podero 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, ento a idade de uma pessoa poder ser um valor maior ou igual a zero ou nulo. O nulo representa ausncia de informaes ou desconhecida.

4.6.4 REGRAS DE INTEGRIDADE DE DOMNIO

So regras declaradas como predicados que no devem ser violados. Esta associada ao domnio do estado do objeto. Ou seja, que valores so possveis para as variveis de instncia dos objetos valorados na classe. Exemplo: Os valores vlidos para dias da semanas so entre 0-6, onde 0 domingo e 6 sbado.

37

4.6.5 GATILHOS (TRIGGERS)

So procedimentos ou aes no banco de dados que so ativadas quando determinadas condies so satisfeitas. Um gatilho, conceitualmente, consiste em um componente condio e um componente ao. Exemplo: Trigger Abort_limit idle_time_limit Ao remover as transaes mais antigas no efetivadas. Ocioso durante 15 minutos remover a sesso ociosa Condio Atingir 75% do log file

4.7 - TRANSAES, CONCORRNCIA, RECUPERAO, 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 SGBDOOs permitem que objetos e definies de objetos possam ser utilizados por vrios usurios ao mesmo tempo. Para controlar os acessos concorrentes, os SGBDOOs utilizam vrias tcnicas de controle de concorrncia e gerenciamento de transaes. Algumas questes precisam ser consideradas no que diz respeito ao acesso concorrente a objetos. 1) Em algumas situaes, diferentes usurios podem tentar atualizar o mesmo objeto ao mesmo tempo; 2) Em outras situaes, diferentes grupos de usurios podem querer cooperar para a construo de vrios objetos. 3) Em alguns casos, os usurios desejam realizar vrias atualizaes no objeto e tornar visveis os resultados das atualizaes somente depois que todas as operaes se conclurem.

U s u r io 1

U s u r io 2

Figura 2.16 Acesso concorrente a objetos

38

Dadas as situaes, o sistema de banco de dados em questo deve garantir que o banco de dados seja mantido em um estado coerente na presena de manipulaes de objetos conflitantes e em conjunto. A manipulao de objetos via transaes no BD. Tradicionalmente, uma transao uma seqncia de aes sobre os objetos persistentes e satisfaz as propriedades: atomicidade, coerncia, isolamento e durabilidade (ACID). 1) Atomicidade: Uma transao um bloco de operaes executado inteiramente ou nada executado. Em outras palavras, ou toda a seqncia de operaes aplicada ao BD ou nada feito. 2) Coerncia: a preservao de todas as restries semnticas do BD. Um banco de dados considerado coerente se todas as restries de integridade do estado do BD forem satisfeitas. Supe-se que a execuo de uma transao na ausncia de interferncia de outras transaes concorrentes leve o banco de dados de um estado coerente a outro. Na figura 2.17 ilustrado esta coerncia. 3) Isolamento: A execuo de transaes concorrentes que manipulam os mesmos objetos compartilhados pode causar anomalias se as operaes de intercalao no forem protegidas umas das outras. O isolamento trata da segurana fornecida pelo sistema de banco de dados em relao aos conflitos entre transaes concorrentes. H uma relao inversa entre o nvel de isolamento e a capacidade de processamento de transaes concorrentes. Mais especificamente, quanto mais as transaes ficarem isoladas umas das outras, maior a probabilidade de conflitos e, da, abortos de transaes. As transaes abordadas consomem recursos, elas devem ser tentadas novamente.

Estado S1

Estado S2

Pastas

Pastas

Documentos

transao

Documentos

Funcionarios

Funcionarios

Toda regra de integridade satisfeita

Figura 2.17 As transaes mantm o BD coerente Os nveis de isolamento. a) capacidade de serializao: o maior nvel de isolamento possvel sem comprometer a coerncia do BD. As transaes so serializveis se a execuo intercalada de suas operaes produzir os mesmos efeitos no BD que sua execuo em ordem serial. A figura 2.18 ilustra as transaes de T1 a T5.

39

T1 T2 T3 T4 T5 Execuo concorrente de T1, ..., T5

T1 T1

T2 T3

T3 T2

T4 T5

T5 T4

Figura 2.18 Serializao da execuo de transaes b) Leitura sujas (Dirty page) : o nvel mais restrito de isolamento do que a capacidade de serializao permitir leituras sujas. Significa: que uma transao T1 leia os estados do objeto O1 modificados pela transao T2 antes de T2 terminar. 4) Durabilidade : garantir que as atualizaes de transaes efetivadas nunca se percam. Isto significa, que as transaes efetivadas podem ser recuperadas no caso de o sistema ou o meio apresentarem falhas. Uma vez que se informe ao usurio ou aplicao que a transao se efetivou, o sistema de banco de dados dever fornecer redundncia suficiente para garantir que as atualizaes sero preservadas apesar das falhas do sistema. 4.7.1 TRANSAES DE APLICAES OODB As propriedades ACID so aplicveis tanto para aplicaes de banco de dados convencional (relacional) como para aplicaes de BDOO. Vrios recursos so, no entanto, mais caractersticos de aplicaes de banco de dados avanadas, como o CAD, o CAM, CASE e escritrios inteligentes.

4.7.1.1 TRANSAES DEMORADAS

Transaes que envolvem o acesso a vrios objetos e consume um tempo relativamente longo (horas ou dias) para serem concludas. A essas transaes esto associados os conceitos de check-in e check-out. Check-out: quando inmeras operaes necessitam ser realizadas em um objeto complexo por um perodo longo de tempo. Check-in: processo inverso ao check-out, quando as operaes so concludas o objeto disponibilizado para ser acessado de maneira concorrente.

4.7.1.2 TRANSAES ANINHADAS

um modelo utilizado para tratar transaes longas. Consiste de um conjunto de subtransaes, chamadas de transaes-filhas, que so componentes de uma transao maior,
40

denominada transao-pai. As subtransaes so isoladas umas das outras e satisfazem as propriedades. ACID. A figura 2.19 ilustra um transao aninhada.
Transao longa

Transao concluda

Figura 2.19 Transao demorada com subtransaes aninhadas

41

4.7.2 CONTROLE DE CONCORRNCIA

So utilizadas estratgias para a sincronizao de operaes de acesso e atualizao intercaladas em transaes concorrentes. Os nveis de isolamento das transaes so capturados no mecanismo de controle de concorrncia do SGBD. Tradicionalmente, trs estratgias principais de controle de concorrncia tm sido utilizadas: 1) Os algoritmos pessimistas: pressupem que transaes concorrentes provavelmente conflitaro e portanto adquirem bloqueios antes das operaes de acesso e atualizao. 2) Os algoritmos otimistas: pressupem que as transaes provavelmente operaro sem conflitos e somente na hora de efetivao so feitas conferncias para garantir o isolamento das transaes. 3) Versionamento: criado uma nova verso de um objeto para a atualizao. As transaes que s lem objetos sempre podero acessar um posio anterior e coerente do BD. H muitas variaes e combinaes dessas trs estratgias fundamentais. Estratgias baseadas no bloqueio so de longe os algoritmos mais utilizados nos SGBDs. Os SGBDOOs normalmente permitiro que o usurio ou o programa de aplicao bloqueie ou faa o check-out explcito dos objetos.

4.7.2.1 ESTRATGIAS DE BLOQUEIO

A maioria dos algoritmos de controle de concorrncia utiliza o bloqueio para sincronizar a execuo de transaes concorrentes. Cada objeto persistente pode ser bloqueado. Isto normalmente feito por meio de uma tabela de bloqueio, que contm os identificadores de objeto dos objetos bloqueados. Antes que uma transao possa acessar um objeto, ela deve solicitar um bloqueio. Se pelo menos uma outra transao estiver mantendo um bloqueio no momento, a transao ter de aguardar at que o bloqueio seja liberado. 1) Bloqueio de duas fases: normalmente utilizado para garantir que as transaes sejam serializveis. Esse protocolo separa claramente uma transao em uma fase de crescimento e outra de reduo. Durante a fase de crescimento, todos os bloqueios devem ser adquiridos, possivelmente de forma incremental. Durante a fase de reduo, todos os bloqueios so liberados, possivelmente de forma incremental. O seguinte protocolo de bloqueio satisfaz ao protocolo de bloqueio de duas fases: a) antes de realizar uma operao de leitura em um objeto, a transao deve adquirir um modo de bloqueio compartilhado para esse objeto. b) antes de realizar uma operao de gravao em um objeto, a transao deve adquirir um modo de bloqueio exclusivo para esse objeto. c) depois de liberar um bloqueio, a transao no deve mais adquirir bloqueios. 2) Bloqueio de multigranularidade: a existncia de diferentes nveis de bloqueio (granulo). Permite que diferentes transaes estabeleam bloqueios em diferentes nveis. O objetivo minimizar o nmero de bloqueios a serem estabelecidos ao acessar o BD. Exemplo: quando a maioria das instncias da classe acessada, mais interessante bloquear a classe toda do que uma instncia por vez. O objetivo fundamental do protocolo

42

de bloqueio de multigranularidade minimizar o nmero de bloqueios a serem estabelecidos ao acessar o banco de dados. 3) Bloqueio de hierarquia de classe: as classes em um BDOO so organizadas em hierarquias. O bloqueio em uma superclasse bloqueia implicitamente todas as suas subclasses no mesmo modo de bloqueio. 4) Bloqueio de inteno: estabelecer inteno de bloqueio na classe antes de estabelecer operao de bloqueio nas instncias. Assim, uma transao deve estabelecer um bloqueio com inteno de leitura (intention-read : IR) em uma classe antes de estabelecer bloqueios de leitura em instncias da classe. Da mesma forma, uma transao deve estabelecer um bloqueio com inteno de gravao (intention-write: IW) em uma classe antes de estabelecer bloqueios de gravao nas instncias da classe. s vezes, uma transao pode querer ler muitas instncias de uma classe e modificar somente um nmero pequeno dessas instncias. Isto pode ser feito pelo estabelecimento de um bloqueio de leitura com inteno de gravao (RIW) na classe e, somente na hora de realizar a gravao o bloqueio estabelecendo. Na tabela 2.3 mostrada uma matriz de compatibilidade para diferentes tipos de bloqueios em uma esquema de bloqueio de multigranularidade.

Observaes importantes: 1 - Os BDOO possuem dois grnulo de bloqueios: classes e instncias. Cada classe ou instncia pode ser bloqueada no modo compartilhado ou no modo exclusivo. 2 - Quanto mais grosso o nvel de bloqueio menor concorrncia e maior overhead do sistema.

R R W IR IW RIW S N S N N

W N N N N N

IR S N S S S

IW N N S S N

RIW N N S N N

Tabela 2.3 Matriz de compatibilidade para bloqueio de multigranularidade

4.8. VERSIONAMENTO
O gerenciamento de verso em um banco de dados orientado a objeto consiste em ferramentas e construes que automatizam ou simplificam a construo e a organizao de verses ou configuraes. Sem essas ferramentas, caberia ao usurio organizar e manter as verses. Uma maneira de fazer isso seria utilizar uma conveno de nome que controlasse as vrias verses do
43

mesmo objeto e a relao das verses entre si (a rvore de derivao). Esse procedimento muito trabalhoso e predisposto a erro. Assim, em aplicaes de projeto complexas, o gerenciamento de verso um utilitrio extremamente til e poderoso. Muitas aplicaes de engenharia e de projeto utilizam o versionamento para criar progressivamente mais verses aperfeioadas do objeto de projeto. Em aplicaes de engenharia de projeto, os objetos so normalmente armazenados em um repositrio 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 implementao, fazem o check-in do objeto como uma verso diferente. Depois que o objeto versionado criado, novas verses do objeto podem ser criadas de forma linear ou em grafo. A principal propriedade comum a todas as verses do mesmo objeto a identidade do objeto. Por toda a histria versionada, um objeto pode passar por muitos estados e at por modificaes estruturais. Se todas as verses de um objeto forem criadas seqencialmente, obteremos um conjunto de verses lineares. No versionamento geral, no entanto, vrios projetistas podem criar verses alternativas de um objeto. Na figura 2.20 ilustrado o conjunto de verses de um objeto O1. Onde cada verso possui sucessores e predecessores.
V1: Verso original Verses alternativas V2 V3

V4

V5

V6

V7: Verso final

Figura 2.20 Conjunto de verses de O1 Por exemplo, para criar uma verso no SGBD Iris, um usurio deve primeiro nomear e fazer um check-out dos sucessores e predecessores de uma verso. 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 DISTRIBUDO

Banco de dados distribudo um banco de dados nico que pode ser compartilhado por mltiplos computadores em uma rede. As aplicaes acessam o banco de dados local e remoto por processamento distribudo, e com transaes em tempo real. As aplicaes de banco de dados distribudos podem ser caracterizadas como aplicaes de banco de dados distribudo. A complexidade do sistema de banco de dados distribudo transparente ao usurio final, porque ele tratado como um banco de dados lgico nico pelo SGBDD Sistema de Gerenciamento de Banco de Dados Distribudo.

44

5.1 EVOLUO PARA SGBDD

A idia de banco de dados distribudo surgiu da necessidade de acesso a dados corporativos de forma rpida. Os fatores que contriburam para a implementao de um ambiente descentralizado foram: as operaes de negcios tornaram-se descentralizada, a competitividade crescente em um nvel global , a demanda do cliente favorecendo a descentralizao dos dados, o surgimento do microcomputador com baixo custo substituindo o computador de grande porte (mainframes), a adoo de redes locais e alto nmero de aplicaes com compartilhamento de dados. O banco de dados centralizado quanto acessado por mltiplos usurios simultaneamente fica comprometido em seu tempo de resposta (performance). Em funo das variveis relacionadas houve o surgimento do SGBDD.

5.1.1 VANTAGENS DO SGBDD

Dados localizados mais prximos da demanda os dados so distribudos de acordo com a requisio do negcio; Acesso mais rpido os dados so distribudos em vrios locais; Processamento mais rpido o processamento dos dados em diferentes locais no sobrecarrega o sistema; Facilidades de ampliaes novos pontos de dados distribudos podem ser adicionados rede sem afetar as operaes normais; Melhora na comunicao comunicao mais rpida e melhor entre as unidades de negcios e os clientes, favorecendo a independncia de informaes locais necessrias aos negcios; Reduo nos custos de operaes os custos com as linhas de comunicao entre micros ficam menores devido a distribuio dos dados. Menor falha no caso de falha de alguma localidade, no 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 so 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 concorrncia, segurana, becape, recuperao, otimizao de consultas e seleo de caminhos de acesso. Segurana os problemas de segurana dos dados proporcional a quantidade de servidores, e a responsabilidade de gerenciamento dos dados dividida para mais de uma pessoa nas localidades. Em funo das LANs e internet exigi-se procedimentos de segurana, como firewalls;

3.2 PROCESSAMENTO DISTRIBUDO E BANCO DE DADOS DISTRIBUDO

Um banco de dados pode possuir processamento e dados distribudo. Um SGBD pode armazenar dados em um nico local (banco de dados centralizado) ou em diversos locais (banco de dados distribudo) e pode suportar processamento em um local ou em vrios locais.

45

5.2.1 PROCESSAMENTO DISTRIBUDO

Consiste em separar o processamento lgico 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 sada 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 A

SGBD Banco de dados de vendas Braslia Rede de Comunicao Computador B Computador C

So Paulo

Taguatinga

Figura 3.1 Processamento distribudo

5.2.2 BANCO DE DADOS DISTRIBUDO

Um banco de dados distribudo um banco de dados armazenado em mltiplos computadores, porm em termos de viso da aplicao aparece como sendo um nico banco de dados. Na figura 3.2 ilustrado um ambiente de banco de dados distribudo. Os banco de dados distribudos no esto sendo usados em todo o seu potencial, pois h muitos pontos a serem definidos antes de se obter toda a flexibilidade e capacidade dos SGBDDs.

5.3 CARACTERSTICAS DE UM BANCO DE DADOS DISTRIBUDO

Um sistema de banco de dados distribudo requer algumas caractersticas funcionais que podem ser agrupadas e descritas como um conjunto de caractersticas transparentes, que dar ao usurio a sensao de estar utilizando o sistema sozinho. Isto , o usurio pensa que estar

46

trabalhando em um SGBD centralizando escondendo toda a complexidade de um SBDB distribudo com total transparncia. Segue as caractersticas transparentes: Distribuio transparente permite que os vrios segmentos de banco de dados seja tratado como um nico banco de dados lgico. O usurio no precisa saber que os dados esto particionados em diferentes localidades. Transao transparente permite a atualizao dos dados em diversas localidades na rede, garantindo que a transao 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 mximo a degradao pelo uso da rede, buscando sempre o melhor caminho para os acessos remotos. Heterogeneidade transparente permite a integrao de diferentes SGBDs locais (relacional, hbridos, objeto e outros) em um esquema global, transferindo as requisies do esquema global para o esquema do SGBD alvo.
Computador A

SGBD Banco de dados de vendas Braslia

Computador B

Rede de Comunicao

Computador C

SGBD Banco de dados de vendas So Paulo Taguatinga

SGBD Banco de dados de vendas

Figura 3.2 Banco de dados distribudo

47

6 A ARQUITETURA CLIENTE-SERVIDOR PADRO CORBA

A arquitetura comum para atender solicitaes de objetos (Common object request broker architecture CORBA) o mais importante e ambicioso projeto de middleware (servidor de regras de negcio) j empreendido pela industria de computadores. O corba produto de um consrcio, denominado OMG (Object Management Group), que inclui em torno de 800 companhias, representado o espectro completo de industrias de computadores. A notvel exceo a MICROSOFT, que possui seu prprio padro de objetos distribudos, denominado DCOM (Distributed Component Object Model). Para os demais fabricantes de computadores o corba a prxima gerao 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, tambm, escolhendo criar campo de execuo aberto para seus componentes. O que faz o corba ser to 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 distribuio necessrio para suportar as interaes entre o cliente e o servidor, ele o bloco intermedirio na arquitetura cliente/servidor conforme pode ser visto na figura 4.1. Corba utiliza objetos padres para tratar as aplicaes existente no barramento, e prover uma base slida para os novos componentes. Ele especifica um conjunto extenso de servios relativos ao barramento para criar e apagar objetos, acess-los por nome, armazen-los em repositrios persistentes, externalizando seus estados, e definindo relacionamentos aleatrios ad hoc entre eles.

Cliente

Middleware

Servidor

Figura 4.1 Os trs blocos bsicos da arquitetura cliente/servidor

6.1 OBJETOS DISTRIBUDOS

Talvez o segredo do sucesso da OMG seja criar especificaes de interface e no cdigo. As especificaes so escritas em Linguagem de Definio de Interface (IDL) que define os limites dos componentes. Os componentes escritos em IDL deveriam ser portveis atravs de linguagens, ferramentas, sistema operacional e rede. E com a adoo da especificao em dezembro de 1994, estes componentes passaria a interoperar com os agentes de objetos padro CORBA.

6.2 O QUE UM OBJETO CORBA DISTRIBUDO?

Objetos corba so pores inteligentes que podem viver em qualquer lugar na rede. Eles so empacotados como componentes binrios que os clientes remotos passam a acessar via invocao de mtodos. A linguagem e o sistema operacional usados para criar os objetos nos servidores so totalmente transparentes ao cliente. Os clientes no necessitam saber onde os objetos distribudos residem ou qual sistema operacional o executa. Os objetos podem estar no mesmo
48

processo do cliente ou em qualquer maquina da rede intergaltica. Os clientes no necessitam saber como os objetos do servidor esto 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 cdigo COBOL, o cliente no sabe a diferena. O que o cliente necessita conhecer a interface pblica dos objetos servidores. A interface a ligao entre cliente e servidor.

6.3 TUDO EST NA IDL

Corba usa um padro de IDL comprometida em especificar os limites dos componentes. A interface, tambm, comprometida com os potenciais clientes. Isto significa que o corba no prover detalhes de implementao, a IDL pode ser utilizada para definir APIs (Application Program Interface). Os mtodos especificados na IDL podem ser escritos ou invocados por qualquer linguagem que esteja preparada com o padro corba atualmente so C, C++, ADA, SMALLTALK, COBOL e JAVA. Os programadores utilizam os objetos corba atravs de construes nativas da linguagem. A IDL prover uma interface independente do Sistema Operacional e das linguagens para todos os servios 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.

Java

Java

Client Stub

Server Skeleton

CORBA IIOP ORB

Figura 4.2 A IDL do corba prover ligao entre linguagens na arquitetura Cliente/Servidor

A ambio do corba padronizar em IDL todos os middleware cliente-servidor e todos os componentes que so 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 definio padro, 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 repositrio de interface corba contm a definio de todas essas interfaces. Ele contm metadados que permite componentes descobrir outro objeto dinamicamente em tempo de execuo. g O martelo inclui o conjunto de servios distribudos que os provedores OMG fornecem. Estes servios determinam quais objetos esto na rede, quais mtodos eles provem e quais os adaptadores de interface eles suportam.

7 BIBLIOGRAFIA
1 [COR 97] Coronel, Carlos & Rob, Peter. DATABASE SYSTEMS:design, implementation, and management. 3 edio, Course Technology, 1997, Canada. 2- [ORF 97] Orfali, Robert & at.all. The Essential Client/Server Survival Guide. 2 edio, Wiley, 1997, New York. 3 [ORF 98] Orfali, Robert & Harley, Dan. Client/Server Programming with Java and Corba. 2 edio, 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, So Paulo.

50