http://repositorio.febab.libertar.org/files/original/27/3584/SNBU1989_022.pdf 6c82af75e8c2e7b90f160a9266d5b9c4 PDF Text Text 1» RELATÓRIO - projeto "AVALIAÇÃO DOS PROCESSOS DE AUTOMAÇÃO EM BIBLIOTECAS UNIVERSITÁRIAS" LUIZ FERNANDO SAYÃO IBICT/UFRJ CARLOS HENRIQUE MARCONDES IBICT/UFRJ CARLOS CÉSAR FERNANDES CIN-CNEN LíGIA POLYCARPO M. MEDEIROS PRÓ-INFO Apresenta-se análise dos resultados do projeto "Avaliação de Processos de Automação em Bibliotecas Universitárias Brasileiras" (PNBU/CNPq). A análise diz respeito ao perfil dos softwares desenvolvidos e/ou utilizados pelas IESs brasileiras nos processos de automação de suas bibliotecas. Analizam-se os resultados principalmente sob dois aspectos: a) adequação das ferramentas de software utilizadas para o desenvolvimento de sistemas de automação de bibliotecas; b) porte/complexidade de um projeto de desenvolvimento de um software bibliográfico. Relacionam-se os requisitos técnicos desejáveis em um software bibliográfico e avalia-se até que ponto as ferramentas de software utilizados nos casos analisados podem atender estes requisitos. Apresentam-se também estatísticas dos dados apurados. Finalmente propõe-se o desenvolvimento de um software padrão para a automação das bibliotecas das IESs brasileiras. 1 INTRODUÇÃO Este é o 1° Relatório do Projeto de Pesquisa "Avaliação dos Processos de Automação em Bibliotecas Universitárias Brasileiras", do PNBU/SESu, com o apoio do CNPq/CAPES/FINEP. O Relatório se concentra exclusivamente na parte relativa aos softwares existentes nas IESs, tendo como alvo a busca de softwares "portáveis", que pudessem ser repassados a outras IESs e, eventualmente, tomarem-se um padrão nacional. O instrumento da pesquisa foi um questionário, distribuido a quase totalidade das bibliotecas das IESs brasileiras no segundo semestre de 1988, onde se procurava coletar dados que permitissem uma avaliação global dos processos de automação das bibliotecas universitárias brasileiras, concluidos, em andamento ou 223 �simplesmente em planejamento. Como subproduto deste trabalho, uma parte do questionário, denominada "Formulário de Descrição de Software", procurava coletar dados sobre os softwares existentes, suas características técnicas, sua funcionalidade, a possibilidade de serem repassadas a outras IESs, etc. Estes dados vieram a constituir a Base de Dados "Guia de Software de Automação de Bibliotecas", do PNBU, no sentido de disseminar o parque de softwares da IESs e permitir sua reutilização. São estes os dados o objeto destes relatório. Os resultados da pesquisa mostram um esforço significativo de várias bibliotecas de IESs no sentido de desenvolverem softwares bibliográficos visando automatizar o registro e processamento de informações bibliográficas. No nosso entender, no entanto, estas iniciativas podem e devem ser criticadas, já que, por um lado, o esforço de automatizar os acervos das bibliotecas universitárias do país necessariamente resultaré em maiores facilidades de acesso e intercâmbio de informações bibliográficas, com reflexos imediatos no desenvolvimento da ciência e tecnologia no Brasil, e, por outro lado, este é um processo recém iniciado, o que permite redirecionar as iniciativas e evitar alguns equívocos. Nossas críticas se desdobram em dois aspectos: as ferramentas de software utilizadas e a noção de porte/complexidade de um projeto como este. O Relatório está organizado da seguinte maneira: a parte 1 apresenta uma estatística dos resultados do questionário destacando alguns pontos importantes para a portabilidade do sotfware, tais como a linguagem com a qual foi desenvolvido, se o software dispõe ou não de uma interface em formato de intercâmbio bibliográfico, quais os pacotes customizados (especiais para aplicações bibliográficas). A parte 2 é uma avaliação destes resultados à luz de dois parâmetros: as ferramentas de software (linguagens, pacotes) utilizadas no seu desenvolvimento e as dimensões de um projeto de desenvolvimento de um software bibliográfico para uma biblioteca de uma IES. A parte 3 apresenta algumas conclusões e a parte 4 procura delinear algumas propostas. Seguem-se Notas, Bibliografia e um Anexo onde está delineada a proposta de um software bibliográfico padrão para as bibliotecas das IESs brasileiras. 1.1 DADOS APURADOS A PARTIR DO QUESTIONÁRIO A maioria dos softwares pesquisados (48,21 %) estavam desenvolvidos utili- zando ferramentas do tipo SISTEMAS GERENCIADORES DE BANCOS DE DADOS (SGBD)/LlNGUAGENS DE 4a GERAÇÃO (L4G) comerciais (FIG. 1). Uma percentagem de 28,57% utiliza linguagens de 3a Geração; 16,10% utilizam pacotes (a grande maioria deste grupo usa o ISIS - micro e mini, e 1 o STAIRS). 224 �Dos softwares pesquisados, somente 7 diferentes do ISIS possuem algum tipo de interface padrão e destes apenas 4 possuem interface em formato de intercâmbio bibliográfico - 3 com IBICIT, sendo 1 ainda em desenvolvimento, e 1 com MARC (FIG. 2). 2 AVALIAÇÃO 2.1 FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO DESTES SOFTWARES É significativo o fato de que a maioria dos softwares de automação identifi- cados pela pesquisa esteja desenvolvido utilizando as facilidades providas por Sistemas Gerenciadores de Bancos de Dados I Linguagens de 4- Geração comerciais: os exemplos vão desde o SUPRA, passando pelo DMS M/LlNK, até o DBASE HI/CLlPPER. Parece claro que a matriz de automação de bibliotecas de IESs passa pelo uso destas ferramentas; este fato tem implicações importantes, tanto do ponto de vista do software em si, das características técnicaslfuncionalidades desejáveis em um software bibliográfico, como do ponto de vista de uma integração sistêmica das bibliotecas das IESs brasileiras. Com o objetivo de compreender melhor esta situação, neste item passaremos a discutir a) as características gerais destas ferramentas e b) sua adequação ao desenvolvimento de software bibliográfico. A maioria dos SGBDs/L4Gs está baseada no famoso MODELO RELACIONAL, desenvolvido por E. F. Codd nos laboratórios da IBM em Santa Mônica, California, no início da década de 70. Um modelo de dados, como o MODELO RELACIONAL, é uma forma de estruturar informações e seus relacionamentos para armazená-Ias em computador. Uma das motivações mais fortes para o desenvolvimento do MODELO RELACIONAL era implementar o conceito de "independência de dado", visando prover o usuário de Banco de Dados de um formalismo de estruturação dos dados que o liberasse de preocupações acerca da forma e dos mecanismos de como os dados eram armazenados e relacionados fisicamente na memória de massa do computador, ou seja, que separasse a estrutura lógica dos dados, a maneira como o usuário os enxergava, da sua estruturação física no computador. Isso representava um grande avanço na tecnologia dos sistemas de Bancos de Dados, já que nos sistemas anteriores o usuário, fosse ele um programador ou um usuário final que estivesse interessado somente em fazer consultas esporádicas ao BD, tinha que conhecer detalhes da estruturação física dos dados, como apontadores, hierarquias, disposição dos dados no meio de armazenamento, etc, para poder manipulá-los; a manipulação dos dados ficava condicionada por 2251 �características do seu armazenamento físico, o que obrigava o usuário a levar em conta detalhes de implementação totalmente irrelevantes para a sua aplicação. No MODELO RELACIONAL proposto por Codd, um Banco de Dados é representado simplesmente por uma RELAÇÃO, que pode ser visualizada como uma TABELA em que cada linha constitui uma entidade ou registro (chamada "tupia") e cujas colunas respresentam atributos ou campos destas entidades. A representação em forma de tabela implicava em que todos os registros tivessem os mesmos campos, com os mesmos tamanhos, ou seja, um lay-out fixo (Fig. 3). Esta característica vai ter sérias implicações quando utilizada para o desenvolvimento de sistemas bibliográficos, como veremos adiante, (para uma definição formai do MODELO RELACIONAL,veja NOTA 1). O MODELO RELACIONAL prove ainda o usuário de formalismos matemáticos de manipulação, a ÁLGEBRA RELACIONAL e o CÁLCULO RELACIONAL, baseados na teoria dos conjuntos e na teoria das relações, através dos quais o usuário simplesmente especifica operações com tabelas cujos resultados também são tabelas, ou especifica as características de tabela desejada, sem se preocupar em especificar um procedimento ou algoritmo para efetuar as operações ou obter as tabelas desejadas. Este tipo de manipulação chama-se "não-procedural", em oposição às linguagens de manipulação algorítmicas, também chamadas linguagens de 3- Geração, como COBOL, PASCAL, "C", etc., em que tem-se que especificar o procedimento (algoritmo) para realizar a função desejada, em oposição a especificar-se somente o "resultado" desejado. O CÁLCULO RELACIONAL e a ÁLGEBRA RELACIONAL foram o ponto de partida do desenvolvimento das chamadas Linguagens de 4- Geração, chamadas também "Linguagens Não-Procedurais". É como se o usuário estivesse um nível "acima" do nível de interação com o sistema de um programador que estivesse desenvolvendo uma aplicação utilizando uma linguagem de 3- Geração. Isto retrata uma tendência geral no desenvolvimento de linguagens de programação, desde o ASSEMBLER (interagindo diretamente com o hardware), passando pelas linguagens de 3a Geração (algorítmicas, procedurais), até as Linguagens de 4 a Geração (não-procedurais), de afastar o usuário de detalhes de máquina, e como realizar suas aplicações, permitindo-lhe preocupar-se somente em "declarar" suas aplicações e concentrar-se em especificar "o que" o sistema deve fazer (FIG. 4). Embutido no MODELO RELACIONAL vinha também uma chamada "teoria de normalização", ou seja, de como projetar relações ditas "normalizadas", de modo a garantir ao máximo a independência de dados. As operações de normalização visavam produzir lay-outs de registros que, em última instância, gerantissem que cada relação representasse uma e somente uma entidade do mundo real. O 2261 �objetivo com isto era evitar custosas atualizações, tão freqüentes em um ambiente de aplicações comerciais, de diversos registros (tupias) onde uma mesma entidade estava representada, como no caso de se representar um periódico e seu fornecedor em uma mesma relação; se o endereço do fornecedor for alterado, vão ter que ser alterados todos os registros correspondentes a periódicos fornecidos por este fornecedor; dependendo do número de periódicos fornecidos pelo fornecedor que teve seu endereço alterado, esta operação pode se tornar bastante cara em termos de custo de processamento; a teoria de normalização manda que "se removam as dependências funcionais", ou seja, que se represente cada entidade em uma relação distinta: uma relação para periódicos e outra relação distinta para fornecedores (FIG.5). O uso de relações não normalizadas pode acarretar também as chamadas "anomalias" de inserção ou remoção de registros: se os dados de um fornecedor estão representados na mesma relação que os pedidos de fornecimento de um periódico, só se pode registrar os dados de um fornecedor quando houver um pedido de fornecimento ao mesmo. Da mesma forma, ao se remover do Banco de Dados um pedido de fornecimento, se só houver este pedido a um dado fornecedor, perdem-se os dados desteifomecedor ao se removerem os dados do pedido. Tudo isto porque fornecedor constitue uma entidade e tem existência independente de seus pedidos de fornecimento. Os conceitos embutidos no MODELO RELACIONAL, como "independência de dados", formalismos de manipulação do tipo "Linguagens não-procedurais", ênfase no projeto prévio de relações visando otimizar as freqüentes atualizações, tão comuns em um ambiente de aplicações comerciais (normalização), significaram um grande avanço em termos de tecnologia de Bancos de Dados, tornando esta tecnologia mais fácil de ser operada tanto pelo usuário especializado, o programador que vai desenvolver uma aplicação usando as facilidades providas pelo SGBD/L4G, como para o usuário final, aquele que vai consultar ou atualizar o BD sem precisar construir um programa para isso, que pode, através destes formalismos, manipular diretamente o BD, sem se preocupar em "COMO" (procedimento computacionais, algoritmos) o sistema fará para realizá-los. Além disso, o MODELO RELACIONAL permitiu que o tempo gasto no desenvolvimento de novas aplicações fosse consideravelmente reduzido, provendo um ganho de produtividade para analistas e programadores. O MODELO RELACIONAL influenciou o desenvolvimento de toda uma geração de produtos de software, que vão desde o DBASE 111, o DATAFLEX, o PARADOX, para micros, até o DB2 (IBM), SUPRA (CINCON), ORACLE, etc., para mainframes. No entanto, estas caracleristicas, tão importantes num ambiente de BD comercial, não contemplam facilidades que seriam 227 �desejáveis num ambiente de aplicações bibiográficas. Em primeiro lugar, num ambiente de BD comercial os dados são muito mais voláteis, ou seja, sofrem atualizações constantes, daí as técnicas de normalização visando justamente otimizar as atualizações. Num ambiente bibliográfico os dados são muito menos voláteis, sofrendo nenhuma ou pouquíssimas atualizações: os dados de uma referência bibliográfica como DATA DE EDiÇÃO, EDITOR, TITULO, AUTOR, etc, não sofrem atualizações durante a vida desta referência. Numa Base de Dados bibliográfica os dados têm características "cumulativas". Outra caracteristica intrínseca ao MODELO RELACIONAL é o lay-out fixo dos registros (relações). A localização de uma informação pelo SGBD, tanto num arquivo em disco como dentro de um registro que foi trazido para a memória, é posicionai: supondo que se queira o campo NOME do 39 funcionário de um cadastro; se um registro de funcionário tem 100 bytes (caracteres) de tamanho, o registro dó 30 funcionário se iniciará no caracter 201 a partir do início do arquivo; se o lay-out do registro constar de, por exemplo, MATRíCULA (com 5 caracteres), DEPARTAMENTO (com 20 caracteres), NOME do funcionário (com 30 caracteres), etc, o valor do campo NOME do 30 funcionário se iniciará no caracter 26 do registro correspondente (ou do caracter 226 a partir do início do arquivo) - FIG. 6. Outra caracteristica do MODELO RELACIONAL é que se houver um campo para o projeto em que um funcionário esteja alocado e momentaneamente este funcionário não esteja alocado a nenhum projeto, mesmo assim o campo PROJETO fica previsto no lay-out do registro do funcionário e é previsto espaço de armazenamento para o mesmo; neste caso este espaço tem que ser preenchido com um valor igual a "brancos" ou "zeros", significando um projeto inexistente, ou que este funcionário não está alocado a nenhum projeto; ou seja, somos obrigados a usar uma convenção extra MODELO RELACIONAL, porque para este, estritamente, neste caso feriamos um funcionário alocado ao projeto identificado por "brancos" ou "zeros". Existe além disso, uma separação rigorosa no MODELO RELACIONAL e, ademais, em todos os sistemas que manipulam arquivos de lay-out fixo, entre os dados propriamente ditos e a descrição dos mesmos. Esta, ou está embutida no próprio texto dos programas, como em programas escritos em COBOL, PASCAL, etc., ou é mantida em um depositório centralizado chamado DicionáriolDiretório de Dados, no caso de um SGBD, de modo que tanto os programas quanto o SGBD "conheçam" este lay-out e desta forma possam manipular os dados. Numa aplicação bibliográfica, as necessidades de armazenamento e manipulação de dados são totalmente distintas. Tipicamente, uma referência bibiográfica tem campos de tamanho variável, como título, resumos, notas, etc; não seria 228 �razoável ter que armazená-los num campo de tamanho fixo, que teria que ser dimensionado pelo tamanho do maior tflulo esperado, o que acarretaria desperdício no espaço de armazenamento de todas as outras referências cujos títulos fossem menores ou perda de informações por se ter que abreviar um título em função de um dimensionamento mai feito. Outro fenômeno típico em registros bibliográficos é a existência de campos múltiplos, com um número indefinido de ocorrências, como o campo de autor: deveríamos prever espaço para um, dois, três, ou mais autores? Outra característica típica de aplicações bibliográficas é a existência de campos opcionais, aqueles cuja existência na descrição de uma referência não é obrigatória, como por exemplo, tradutor (nem todas as referências são traduzidas), ilustrador, notas para casos especiais, dados de uma conferência, etc. Na verdade, em uma aplicação bibliográfica temos tipicamente campos de tamanho variável, campos múltiplos, campos opcionais, o que implica em praticamente em lay-out único e individual para cada referência. Daí a impossibilidade de manter este lay-out (que não é comum) centralizado. Um lay-out de um registro bibliográfico contém, além dos dados propriamente ditos, informações que permitem processar os próprios dados de cada registro de uma referência bibliográfica, como identificadores de campos (conhecidos como "parágrafos" ou "etiquetas"), tamanhos de cada campo, número de ocorrência de campos múltiplos, indicadores, separadores de subcampos, etc. (FIG. 7). Isso não é nenhuma novidade, basta consultar o manual de um formato bibliográfico típico. Todas estas características não são praticamente atendidas por um SGBD/L4G comercial, embora sejam essenciais para o tratamento de registros bibliográficos. Vinculado também às características e limitações dos SGBDs/L4Gs comerciais, em que um grande número de aplicações em bibliotecas das IESs brasilerias foi desenvolvido, está o fato significativo de que todos os sistemas que empregaram esta tecnologia não disporem de facilidades de importação/exportação de dados em formato de intercâmbio. Esta tarefa se torna bastante complexa se os dados já se encontram estruturados segundo o MODELO RELACIONAL. Os SGBDs/L4Gs comerciais não oferecem nenhuma facilidade a este respeito. Para conseguir-se converter os dados do formato de armazenamento interno do SGBD para um formato de intercâmbio bibliográfico, necessariamente ter-se-ia que empregar um linguagem de 3a Geração algorítmica a além disso conhecer a estrutura física de armazenamento interno dos SGBDs/L4Gs, o que via de regra não é colocado disponível aos seus usuários porque se constitui num segredo comerciai. No entanto, esta é uma característica praticamente essencial em um software bibliográfico destinado a uma universidade, em que aumentam as demandas para um crescente intercâmbio de dados bibliográficos. Observamos que, dos softwares 229 �desenvolvidos em linguagens algorítmicas, que, pelos fatores citados acima facilitariam a implementação desta característica, somente 1 deles declarou dispor de facilidades de intercâmbio de dados em formato bibliográfico. Outro dado significativo é que os grandes fornecedores de software não confundem SGBOs comerciais com Sistemas de Recuperação de Informações Bibliográficas; cada qual desenvolve produtos distintos para aplicações comerciais e para aplicações bibliográficas. Por exemplo: A IBM possui um produto, o STAIRS, para aplicações bibliográficas e o OB2 e o SQl para aplicações comerciais; a BUll possui o MISTRAl para aplicações bibliográficas e o lOS-li para aplicações comerciais. Os grandes sistemas de informações bibliográficas internacionais como OClC, ORBIT, OIAlOG, estão baseados em softwares desenvolvidos especialmente para aplicações bibliográficas. E mais, a UNESCO desenvolveu o conhecimento MICROISIS, ao invés de optar por utilizar um OBASE 111, ou outro SGBO comercial qualquer. 2.2 A NOÇÃO DE PORTE/COMPLEXIDADE DO DESENVOLVIMENTO DE SOFTWARE BIBLIOGRÁFICO PARA AS UNIVERSIDADES BRASILEIRAS Um software bibliográfico, para atender às bibliotecas das universidades brasileiras deveria ter como requisito essencial a capacidade de importar e exportar dados bibliográficos no formato de intercâmbio padrão nacional, o formato IBICT. Uma caracteristica não essencial, mas também altamente desejável por suas implicações em termos de economia de espaço de armazenamento, seria a capacidade de armazenar e manipular registros de tamanho variável, campos de tamanho variável, campos múltiplos com número de ocorrência variável e campos opcionais. Deveria também permitir que uma série de produtos pudessem ser gerados a partir dos dados armazenados, como catálogos (impressos e on-line), fichas, etiquetas, serviços de OSI, BR, etc. O uso de ferramentas de software tipo SGBO/l4G realmente simplifica e barateia o processo de desenvolvimento de software, mas traz consigo os prejuízos citados anteriormente; estas ferramentas são adequadas para o desenvolvimento de aplicações comerciais típicas, como Folha de Pagamento, Controle de Estoque, etc, mas não para um software bibliográfico. Um software bibliográfico tem então que implementar seu próprio método de armazenamento e manipulação capaz de suportar as características acima. A nivel dos métodos de acesso/busca são desejáveis facilidades como índices que utilizam listas invertidas de modo a suportar consultas formuladas sob forma de expressões em lógicas Booleana, busca em texto, busca através de operadores de proximidade, indices multicampos, lógica de patamar, ordenação de referências segundo um critério de relevância, técnicas de �compressão de dados, etc.. No desenvolvimento de um software com estas características, torna-se da maior importância o domínio das técnicas e dos algoritmos que possam implementar estas estruturas, que, dado o seu nivel de detalhe e complexidade teriam que ser desenvolvidas em uma linguagem que permitisse especificar algoritmos e estruturas de dados complexas, uma linguagem de 3§ Geração como PASCAL, "C", ALGOL, Pl-1 ou mesmo COBOl. Um projeto como este compara-se em complexidade praticamente ao desenvolvimento de qualquer software básico, cama são os Sistemas Operacionais, Compiladores, Editores de Texto e mesmo SGBDs comerciais (FIG. 8), ou seja, trata-se de um projeto de grande porte, caro, demorado, que exige pessoal altamente especializado. 3 CONCLUSÕES Não negamos as facilidades providas pela tecnologia de SGBD/l4G comerciais no desenvolvimento de uma série de pequenas aplicações bibliográficas realmente úteis e interessantes em várias bibliotecas de IESs pelo Brasil afora. Só queremos deixar claro os limites desta tecnologia, quando se pretende produtos mais ambiciosos. Neste sentido, muitos dos softwares analisados na pesquisa e constantes da base de dados "GUIA DE SOFTWARE DE AUTOMAÇÃO DE BIBLIOTECAS", não podem ser enquadrado comov softwares bibliográficos completos, por não abrangerem as funções básicas de uma biblioteca. Um indicativo deste fato é que muitos deles rodam em micros, com pequena capacidade de disco para conter todo o acervo de uma biblioteca; um número significativo deles dá suporte a funções administrativas; neste caso, é razoável que eles tenham sido desenvolvidos utilizando-se a tecnologia dos SGBSs/l4Gs comerciais, devido aos ganhos de produtividade e facilidades providas por estas ferramentas. No entanto, o desenvolvimento de um software bibliográfico completo, que de suporte às funções básicas de catalogação e recuperação de dados bibliográficos e que permita ainda o intecâmbio destes dados em formato padrão, é uma questão ainda por ser resolvida. 4 PROPOSTAS - Desestimular as iniciativas isoladas e promover gestões no sentido de viabilizar institucionalmente um esforço nacional objetivando constituir um consórcio de IESs que desenvolva um software bibliográfico padrão, "portável" e compatível com diferentes ambientes operacionais, que contemple as características ressaltadas acima. Esta forma institucional é a única capaz de viabilizar técnica e 231 �economicamente um projeto como este. O ANEXO 1 contém o esboço do que entendemos por um software bibliográfico padrão. - Identificar os profissionais/instruções de reconhecida competência no desenvolvimento de software bibliográfico e procurar incorporá-los ao projeto de software bibliográfico padrão nacional. - Apoiar a criação de linhas de pesquisa em sistemas bibliográficos a nível de pós-graduação - Mestrado/Doutorado, em Informática, a exempta do que existia no Programa de pós-graduação em Engenharia de Sistemas do Instituto Militar de Engenharia - IME/RJ. - Promover cursos de aperfeiçoamento para profissionais de informática em desenvolvimento de sistemas bibliográficos e cursos de gerência de processos de automação para profissionais bibliotecários. NOTAS [01] O MODELO RELACIONAL baseia-se no conceito matemático de "relação": toma-se uma coleção de conjuntos, não necessariamente distintos D1, D2, D3, etc, e seu produto cartesiano C ;;; D1 X D2 X D3, etc. Formam-se desta maneira todos os possiveis conjuntos R formados por elementos d1, d2, d3, etc, tais que d1 pertence ao domínio D1, d2 a D2, d3 a D3, e assim por diante; a função que seleciona elementos dn de um domínio Dn para formar a relação R chama-se ATRIBUTO e representa o "uso" dos elementos do domínio Dn na relação R. Qualquer subconjunto de C com estas características é uma Relação. BIBLIOGRAFIA CASWELL, Jerry V. Normalization: a method for structured file designo Information Technology and Libraries. 3(3): 293-6, September 1984. CRAWFORD, Richard. The Relational Model in Information Retrievel. JASIS. 32(1): 51-64, January 1981. DATAPRO Reserch Corpo Linguagens de Quarta Geração - Um Modelo Funcional. MIS;;; Relatório de Gerenciamento da Informação. 10: 5-24, novembro 1988. DATE, O J. Introdução a sistemas de Banco de Dados. Ed. Campus, 1986. 513P. INSTITUTO BRASILEIRO DE INFORMAÇÃO EM CIÊNCIA E TECNOLOGIA. Formato IBICT: formato de intercâmbio bibliográfico e catalogràfico. Brasília, IBICT, 1987.400 p. KOENIG, M. E. D. Data relantionships: bibliografie information Retrieval Systems and Database Management Systems. Information Technology and Libraries. 4(3): 247-72, September 1985. POLLARD, Richard. Bibliografie Data Management with Dbase: a Study of Secondary Key Retrieval, on Multivalued Data Items. Information Technology and Libraries, 7(1): 56-66, March 1988. 232 �f'ig.:1 Linguagens x! utilizad.§ 12,50 48,21 28,57 1.80 8,92 LINGUAGEM DE 4~ GERAÇÃO - LINGUAGEM DE 3~ GERACÃO 16 l! ? 6 4 rrrrrrr, rrrrrr, 1 11 C l p 8 M A o o o w o o N I S o P A A T S A N S S 8 A I A C A I o 2 T S C S 5 E 3 A T A M S 8 A l S l G S 8 U M P o l C L F L E X 5 E S n, 5 S o A E S N T -- • �f';o- ') Tntc> ..f'""c> X N· P"rl1"<>n. :',1 4 . ~ ~,,, 1 1.$ 1.~ 1 , ,~ ! ! . ~ ,~ ~ """"~ .... ~ 4 73, l 41 bJ ~ ~ .. -,F~M LINI-RI:J '.lER"! UFR~l FURfi ':EF E1IMB UFPB UFRGS IEleT IJFfL' I PUUPR 11 I PUUMGI I I PUC/llJI I I UFRGS 11 eCL NARe eCN LINCE UFtI(; Ef'tI ISO 2709 S/INTER. (SOMENTE 1$151 FADRAO �-F"; ". ":I +- "" 'h "", "" "'I21i!H'1i!'I21i!l\TI"'T li. ~" HEFERENCIAS I S SN ~ <n I TITULO AUTOR VOL NUM 1 PRQ.lNFO RIO J.CABRAl 5 15 2 UFF NITEROI BIB CENTHAl CNENICIN RIO OSB IBM S.PAUlO PAlAOIUM i 23032 MICROISIS NA SBLlOTECA MACEDO. L.F. .a 54C9357 CONSTRuçÁO DE TESAURO ESPANHA, H. 111 3 3 348494 LINCE: PADRÃO NACIONAL FERNANDES, C.C. 12 4 997968 POllTICA DE AQUISiÇÃO QUEIROZ,G. 3 ED I T OR ENDED FORNEC .- ------ -_ .. ._- ------_. Algebra Relacional SELECIONE referencias tal que ENDED=RIO DE JAHEIRO EHDED=RIO fi9.4 - ISSN Operacac eM TITULO AUTOR VOL NUM 1 1. 23032 MICROSIS NA BIBLIOTECA MACEDO, L.F. 111 2 348494 LINCE: PADRÃO NACIONAL FERNANOES, C.C. 12 15 - -- ED I T OR ENDED FORNEC PRQ-INFO RIO .... CABRAl CNENlCIN RIO DSB --- -- �figo 5 - Normalização da -tabela ISSN I TI TULOI AUTOR I VOL I NUM IED I T OR FA sel1 eULO ISSN I UOL I NUM I t3 (J) ED ITOR + I EDITORI EDICAOI FO RNECEDOR "REFERENCIAS" 1 FORNECED;RII IED I CAO IF ORN IE ND-F ORNE C �• C:• "" I 11: : O O : U E fi) E : rn : "" : A I I I I I I I I~I I I I I I , I I I I I I r CSII CSiII <"'> <"'> - CSII I I I I (SI! O"l , I ,I ,I I - - ..... <".I · I I I I I I I · I I I I I I I I ...11C , s: I I I I I I I I I I I I I I I I I I ,.c. n: E n: + Q 't C I- •• + ··· ·•• ... t I Q I- s: ,• • • ,,• •• I rr- I n: n: I I l- ,, f: + r- é I ~ n: ...: ...11-t 237 cz: :::> ...:I ...... Cf) cz: Q O: cz: .., Q r ..... 11") - ('I') N CSII (SI! CSII -- I~I ..... �..---- •, •, ••, ~ <I: a::: CN til f.. ....a ... ~ .... G: cn o ~ => • ::E: ct G: ~ E-e ~ (I) a D.. f.. -tl ....1ft ti • ~ !; ~ til ~ til Q. .., ,•, ,, => o .... o 111 , L&J - o ~ a::: - , g:: LLJ ~ ..... .qJ:;,...O ...... _~J li L&J Q 41 ...t o ü <I g:: ........ .::z: .... "'" li: ._..__ ._. ---- ... <:- ollO-..... à e . . . - ~ Q o o ... ~ :r .. z v, c- ..... lt'" C 101 l' ....Dt .. - footGE4Z%~ c- o .- .... OVII- ...... ·"1" 'O "'o 1 I o j I ~ •, , o f--4 .- ]- G: U - I s 238 I �fis. 8 - N iv eis de softwa re alI icacao aplicacao BI LIOGRAFICA SGBD COMere i a1 ~ING. DE 40. GERACAO SRI , .' LING. de 30. GERACAO i: SIST. OPERACIONAL ., I , ~ LING. de MAQUINA I HARDIIARE I ~': 239 �ANEXO 1. Proposta de um Software padrão de manipulação de registros bibliogra ficos. INTRODUÇÃO A padronização de software bibliográfico no Brasil se insere na questão mais ampla de racionalização e otimização dos parcos recursos disponiveis no pais para que o mes mo consiga superar a barreira do subdesenvolvimento. A automação das bibliotecas universitárias é um meio de tornar disponíveis a comunidade de C&T do pais mais rapidamente informações essenciais a este esforço. Ela trará também benefícios paralelos que se inserem na mesma prioridade, como a melhor utilização do acervo, a racionalização das aquisições e a otimização do uso do material bibliográfico. No entanto, a questão é bastante complicada. O que significa um software "padrão"? Será que existe um padrão de funcionamento nas diferentes bibliotecas das IES brasileiras? Será que um software "padrão" não incorporará características que são específicas de uma biblioteca universitária, tornando-se uma camisa de força para outras instituições que venham a utilizá-lo,? É indiscutível a necessidade de um software portável e reutilizável, já que as bibliotecas universitárias dispõe de poucos recursos para desenvolverem softwares customizados para suas necessidades. Nossa proposta, ainda um esboço bastante superficial, restrito as características funcionais do software, sem entrar em detalhes de algoritmos, mecanismos de armazenamento e demais características técnicas, etc, tenta incorporar estas preocupações, no sentido de produzir um software que seja portável para vários equipamentos e ambientes operacionais e, ao mesmo tempo, não seja uma camisa de força para as instituições que venham a utiliza-lo, dando margem que elas possam customizar aplicações específicas, de acordo com suas caracterísiticas e necessidades, tendo como suporte o software padrão. 2 CONCEPÇÃO. O software padrão seria composto de dois subsistemas distintos e autocontidos: um sub-sistema de entrada de dados rodando em microcomputador PCcompatível sob sistema operacioanl DOS, que geraria os dados bibliográficos em formato de intercâmbio. Além de entrada de dados, tal programa permitiria também a verificação e correção dos dados digitados. O outro componente do sistema seria um sub-sistema de armazenamento e 240 �manipulação de registros bibliográficos, que permitiria a leitura de dados em formato de intercâmbio em disquetes gerados pelo primeiro sub-sistema e seu armazenamento em dispositivo de acesso direto (disco magnético), bem como a recuperação dos registros bibliográficos e sua manipulação. Este sub-sistema teria a forma de uma biblioteca de rotinas de manipulação de registros bibliográficos, que estariam disponíveis para que se desenvolvessem aplicações mais ou menos sofisticadas em cima deste suporte básico. Desta forma, o sub-sistema de manipulaçâo de registros bibliográficos ficaria livre de incorporar características específicas, políticas, normas, etc, que estariam embutidas nas aplicações construídas sobre o sub-sistema. Tal partido garantiria as especificidades das diferentes aplicações e forneceria um suporte básico à parte mais complexa de um software bibliográfico, que e a manipulação de registros/campos de tamanho variável, a manipulação de campos opcionais, a manipulação de campos múltiplos, compressão de dados, etc. Para garantir maior independência das aplicações a serem desenvolvidas do sub-sistema de manipulação de registros bibliográficos, a cada referência armazenada, o sistema atribuiria um número de referência (NREF) e proveria um índice que relacionaria os NREFs com os endereços fisicos em disco de armazenamento dos registros bibliográficos. Desta forma, os registros bibliográficos seriam acessados através de um endereço simbólico, podendo ser reorganizados fisicamente sem que tal fato afete as aplicações construidas sobre o sub-sistema. Como garantia maior de portabilidade, o sub-sistema de manipulação de registros bibliográficos seria escrito em linguagem de alto nível (possivelmente em "C") e, uma vez compilado, poderia rodar em qualquer ambiente operacional que dispusesse desta linguagem, como micros PC-DOS, supermicros PS/OS 11, supermicros UNIX, superminis UNIX. 3 BIBLIOTECA DE ROTINAS DE MANIPULAçAO DE REGISTROS BIBLIOGRÁFICOS - DESCRiÇÃO. 3.1 ARMAZENAMENTO. Os registros bibliográficos, de tamanho variável, serão armazenados em blocos físicos de um arquivo de acesso direto em disco magnético, provido de um único índice que associaria NREFs a endereços fisicos em disco dos registros. 3.2 ROTINA DE LEITURA DE DISQUETES EM FORMATO DE INTERCÂMBIO. Lê um registro bibliográfico armazenado em disquete. �3.3 ROTINA DE INCLUSÃO DE REGISTROS BIBLIOGRÁFICO. Recebe um registro bibliográfico e o armazena no arquivo em disco, devolvendo seu NREF, através do quai o registro pode ser acessado. 3.4 ROTINA DE EXCLUSÃO DE REGISTROS BIBLIOGRÁFICOS. Recebe um NREF e exclui o registro bibliográfico correspondente. 3.5 ROTINA DE ALTERAÇÃO DE REGISTROS BIBLIOGRÁFICOS. Recebe um NREF correspondente a um registro bibliográfico, uma tabela com os parágrafos a serem alterados e os novos valores a serem assumidos, e altera o registro bibliográfico correspondente ao NREF, substituindo os valores dos parágrafos especificados. 3.6. ROTINA DE RECUPERAÇÃO DE REGISTROS BIBLIOGRÁFICOS. Recebe um NREF correspondente a um registro bibliográfico e opcionalmente, uma tabela com parágrafos do registro especificados e recupera toda a referência ou simplesmente os parágrafos especificados. 3.7 ROTINA DE ADMINISTRAÇÃO DO SISTEMA. Permite definir os parágrafos de um formato que vão ser lidos e os parágrafos que vão ser armazenados, além de monitorar o funcionamento do sistema. 3.8 ROTINAS UTILITÁRIAS. Realizam funções diversas, como estatísticas de disponibilidade de espaço no arquivo de referências bibliográficas, reorganização deste arquivo, co'pia/back up do arquivo de referências bibliográficas, etc ... OBSERVAÇÃO. A figura 1 procura ilustrar os elementos do Sistema de Manipulação de registros Bibliográficos: o sub-sistema de entrada de dados e a biblioteca de rotinas bibliográficas. As figuras 2 e 3 procuram ilustrar exemplos de aplicações bibliográficas que poderiam ser desenvolvidas sobre a biblioteca de rotinas bibliográficas, no caso a emissão de catálogos ou fichas (figura 2) e um sistema disseminação seletiva de informações (figura 3). Esperamos que a nossa proposta ajude a esclarecer dúvidas e auxilie o PNBU na formulação de políticas para a automação das bibliotecas universitárias brasileiras. 242 �ENTRADA DE DADOS IHGIrIlCIIO PLIIHIUlII RDIIJORIO 1- CottJlJtDiCJ 11 IIJllBIEHU NICRO PC - DOS BIBLIOTECA DE B O TI NAS BIBLIOGRÁFICAS BIB .. BIBL I IftERCIIMlI O m.FOJlllAtO BIB1IOG11f1r. IlAIIJ JDtCAO IHCLUSIIO I EXCWSIIO ROJ.IIDtlIHIS I Rtttl PElltlCA O UJI LI JIIRI OS , ~-------I--H-D--I~ck--p-/---N-R--E-F----------~ ~------------~.----------------------~ fOM,II8I. O n REGISTROS BIBLIOORAFICOS AMBIEl\'TE MICRO PC-DOS/SLPERMICRO, SUPERMI'\I - UNIX FIO.1 - B I B L I O T E C A DE ROTINAS 2431 B IBLIOGRAFICAS �UUlnMCIIO K r (')J I I MilitO' CUlSSIr . '1t1tbLO f---t MQI,WCllOI r----- ',..,9*0 r CIIIIILOOH ~ r BIBLIOTECA DE ROTINAS BIBLIOGRAFICAS FIG.2 - APLICAÇÃO E M ISS à o DE CATÁLOGOS ( rum ) I l uaJPDlCIIO ----f1.Ml.S.atMll~ CLtSSIf. r---------- I uaJPIRrICIIOI DlISS.O r ~ ------I> f BIBLIOTECA DE ROT U'AS BIBLJOGRAFICAS FIO.3 - APLICAÇÃO 244 EMISSÃO DE DSI t.S .1. ~ � Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource SNBU - Edição: 06 - Ano: 1989 (UFPA - Belém/PA) Subject The topic of the resource Biblioteconomia Documentação Ciência da Informação Bibliotecas Universitárias Description An account of the resource Tema: Automação de bibliotecas e serviços aos usuários. Creator An entity primarily responsible for making the resource SNBU - Seminário Nacional de Bibliotecas Universitárias Publisher An entity responsible for making the resource available UFPA Language A language of the resource Português Type The nature or genre of the resource Evento Coverage The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant Belém (Pará) Event A non-persistent, time-based occurrence. Metadata for an event provides descriptive information that is the basis for discovery of the purpose, location, duration, and responsible agents associated with an event. Examples include an exhibition, webcast, conference, workshop, open day, performance, battle, trial, wedding, tea party, conflagration. Dublin Core The Dublin Core metadata element set is common to all Omeka records, including items, files, and collections. For more information see, http://dublincore.org/documents/dces/. Title A name given to the resource Relatório do Projeto "Avaliação dos processos de automação em Bibliotecas Universitárias". Creator An entity primarily responsible for making the resource Sayão, Luis Fernando Marcondes, Carlos Henrique Fernandes, Carlos Cesar Medeiros, Ligia Polycarpo M Coverage The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant Belém (Pará) Publisher An entity responsible for making the resource available UFPA Date A point or period of time associated with an event in the lifecycle of the resource 1989 Type The nature or genre of the resource Evento Description An account of the resource Apresenta-se análise dos resultados do projeto "Avaliação de Processos de Automação em Bibliotecas Universitárias Brasileiras" (PNBU/CNPq). A análise diz respeito ao perfil dos softwares desenvolvidos e/ou utilizados pelas lESs brasileiras nos processos de automação de suas bibliotecas. Analizam-se os resultados principalmente sob dois aspectos: a) adequação das ferramentas de software utilizadas para o desenvolvimento de sistemas de automação de bibliotecas; b) por te/complexidade de um projeto de desenvolvimento de um software bibliográfico.Relacionam-se os requisitos técnicos desejáveis em um software bibliográfico e avalia-se até que ponto as ferramentas de software utilizados nos casos analisados podem atender estes requisitos. Apresentam-se também estatísticas dos dados apurados. Finalmente propõe-se o desenvolvimento de um software padrão para a automação das bibliotecas das lESs brasileiras. Language A language of the resource pt snbu1989