PETIC de Dados – CPD da Universidade Federal de SergipeDanilo M. Rocha, Jéssica C. Andrade, Luana B da Silva, Vinícius A. T. Barreto

Universidade Federal de Sergipe Centro de Ciências Exatas e Tecnologia

Departamento de Computação Cidade Universitária Prof. "José Aloísio de Campos"

Av. Marechal Rondon, s/n Jardim Rosa Elze CEP 49100-000 São Cristóvão – SE

Telefone: +55(79) 2105-6600 / Fax: +55(79) 2105-6474

danilomelorocha@gmail.com, jessica2402@gmail.com, lb.luanab@gmail.com, vin.teles@gmail.com

ABSTRACT The article in question aims to examine the treatment of information from the Center of Data Processing (CPD) of the Federal University of Sergipe (UFS). Initially it was made an analysis of the current situation to be identified and diagnosed possible "failures" in this institution with respect to the data handled by the same. And then drew up possible solutions aiming to optimize the work of the CPD.

RESUMO Este artigo examina o tratamento das informações do Centro de Processamento de Dados (CPD) da Universidade Federal de Sergipe (UFS). Inicialmente foi feita uma análise da situação atual (Estudo de caso) para identificar e diagnosticar as possíveis falhas na instituição no que diz respeito aos dados por ela manipulados. Em seguida pesquisou-se sobre PETICs de algumas instituições que se encontravam em situações semelhantes e que da mesma forma buscaram adequar-se frente às novas tecnologias existentes. Tomando como parâmetro os PETICs destas instituições, foi feita uma pesquisa das tecnologias propostas nos mesmos, como também de outras que pudessem agregar valor a este artigo. E por fim, todo este conhecimento tecnológico pesquisado possibilitou a sugestão de soluções cabíveis que visam modernizar o tratamento das informações da universidade, como também atingir o conhecimento proposto pela disciplina.

Termos gerais Gestão, Documentação, Performance, Economia, confiabilidade, Experimentação, Segurança, Padronização.

Palavras-chave PETIC, dados, tecnologia.

1. INTRODUÇÃO Inicialmente foi feito um estudo de caso da situação atual para serem identificadas e diagnosticadas possíveis falhas existentes nesta instituição com relação aos dados manipulados pela mesma. Estudo este possibilitado por entrevistas com a coordenadora de desenvolvimento de sistemas, Estelamaris e a Administradora de Banco de dados (DBA), Dinorah do CPD. Dessa forma, tivemos acesso ao tratamento feito a todo tipo de informação da Universidade Federal de Sergipe (UFS). Partindo de alguns Planos Estratégicos de Tecnologia da Informação e Comunicação (PETICs) de empresas renomadas como Anvisa, Unifesp e Rede SUAS e de algumas tecnologias pesquisadas tais como: UML, Umbrello, ERP, ERP SAP, Banco de dados Proprietário e Livre e Data Warehouse, elaboramos soluções e um cenário desejado a ser implantado no CPD. Neste cenário

desejado propomos remodelagem dos dados, migração da base de dados, tecnologias de apoio, práticas de manuseio de dados e outras sugestões.

1.1 Trabalhos relacionados Apresentaremos nesta seção alguns trabalhos pesquisados durante o andamento da disciplina relacionados ao tema. Na sua maioria são planos diretores de informática (PDI), dessa forma podemos ter idéia do que outras instituições estão aplicando na área de TIC e tentar inovar com algumas idéias e sugerir o trabalho final ao CPD da Universidade Federal de Sergipe (UFS).

1.1.1. PDI Anvisa Este PDI [1] sugere basicamente a adoção de metodologias de desenvolvimento e planejamento da organização dos dados, visando uma melhor manutenção e integridade das informações gerenciadas pela empresa. São elas:

i) Padronização da documentação de sistemas usando UML e o armazenamento dessas informações no banco de dados. A padronização da documentação de sistemas visa a qualidade da manutenção posterior dos softwares, e a documentação de sistemas como informação da instituição diz respeito ao grupo de dados; ii) Capacitação técnica dos funcionários a fim de conscientizá-los de que as informações que os mesmos gerenciam são de vital importância para a instituição, e dessa forma evitar inconsistências dos dados nos momentos de cadastro das informações; iii) Criação de unidades de cadastro a fim de agrupar as tarefas de inserção dos dados. Com a criação dessas unidades podemos delegar as tarefas de cadastro a um grupo restrito, confiável e competente de pessoas como no item citado acima; iv) Aplicar métodos de segurança das informações, como criptografia de alguns dados pessoais como senhas, e-mails e até endereços residenciais, respeitando assim a privacidade dos indivíduos que compõem a instituição; v) Aplicar metodologias de desenvolvimento de sistemas a fim de gerir o planejamento dos softwares e dados da instituição. A adoção da metodologia RUP de desenvolvimento dos softwares possibilitaria o planejamento da modelagem de dados como também as suas possíveis modificações futuras, tornando o projeto mais consistente e confiável; vi) Planejar estratégias de backup e recovery do banco de dados, aumentando assim a confiabilidade da segurança dos dados da instituição;

vii) Manter a padronização dos dados da instituição a fim de evitar redundâncias e enfraquecimento da integridade das informações armazenadas pela instituição;

viii) Alocar espaço em disco e planejar futuras necessidades de armazenamento.

1.1.2. PDI Unifesp O Plano Diretor da UNIFESP sugere uma remodelagem total dos dados da instituição. Foi aplicado em 1999 e se faz importante neste trabalho porque se trata de um caso real de uma universidade que se encontrava em uma situação parecida com a situação atual da UFS. Suas sugestões são:

i) Reestruturar e remodelar os dados da instituição aplicando a tática de representar o indivíduo na instituição com apenas uma única matrícula durante toda a sua vida acadêmica (incluindo técnicos e docentes); ii) Também visa remodelar os dados de tal forma que eles fiquem flexíveis ao ponto de permitirem a interoperabilidade com os sistemas do Ministério de Educação; iii) Criação de uma Comissão de Alimentação de Dados a fim de realizar as tarefas de migração constantes e validação dos dados para a nova base, tarefa esta que foi feita em paralelo ao uso e alimentação dos dados residentes na antiga base; iv) Divide a modelagem em três bases de dados principais: a) Base de Dados Administrativa – relativa ao setor administrativo e financeiro da instituição; b) Base de Dados Institucional – relativa à parcela acadêmica da instituição (graduação, pós-graduação e pesquisa); c) Base de Dados Referencial de Fontes – diz respeito a toda informação desejável pela instituição, funciona basicamente como uma fonte de pesquisa interna e abrange assuntos como: bibliografia, guias, manuais, notícias, pesquisas estatísticas e etc; v) Adoção de um software gerenciador de banco de dados livre como o PostgreSQL.

1.1.3. Rede SUAS Da mesma forma que os outros PDIs adota padronizações e táticas de planejamento importantes à modelagem dos dados do Ministério de Desenvolvimento Social (MDS). Seguem abaixo as principais idéias:

i) Formalização de um Grupo de Trabalho, que recebeu o nome de Comitê Gestor de Tecnologia de Informação CGTI, com o objetivo de evitar decisões impulsivas da área de tecnologia de informação; ii) Modelagem de uma ferramenta (e base de dados) que gerencia informações estratégicas dos programas, projetos e ações sociais do MDS; iii) Centralização dos dados da Instituição; iv) Elaborar um regimento interno, pauta de debates e política de informação estabelecendo regras de funcionamento do comitê, assuntos a serem abordados e as diretrizes gerais para a implementação da governança de TIC no MDS.

O caso do MDS é interessante, pois dada a situação atual da instituição, a comissão de gerência de tecnologia de informação percebeu que a complexidade e o volume de informações utilizadas pelo MDS careciam de um apoio intenso de tecnologia. Além disso, a demanda de informações das secretarias e setores do MDS exigia um ordenamento radical do fluxo de dados da instituição:

i) Contribuir para divulgar aos cidadãos as ações (dados) do MDS em todos os contextos em que as políticas sociais se

inserem, aumentando assim as probabilidades do seu trabalho resultar em mudanças reais para a população; ii) Criar, agrupar e manter políticas como: manuais de sistemas, diagramas, modelos de dados e sistemas, dicionário de dados e etc.

2. CONCEITOS E TECNOLOGIAS Nas subsessões seguintes abordaremos alguns conceitos de técnicas que podem ser utilizadas na implementação de softwares e também ferramentas que podem ser utilizadas para modelagem de dados.

2.1. Modelagem de dados Esta é a atividade na qual se faz o desenho dos dados. São definidas as modelagens conceitual, lógica e física, com intuito de representar os dados de forma que o cliente entenda (conceitual, com a representação de negócio), a equipe entenda (lógica, com a representação de classes) e o computador entenda (com a definição do banco de dados).

A modelagem de dados é a força motriz da codificação. Após uma modelagem bem feita, não é necessário muito esforço para a codificação, e, com boas ferramentas, de automação, grande parte de seu conteúdo terá sido feita por estas ferramentas.

Abordaremos nas subseções seguintes técnicas, linguagem e ferramentas auxiliares para se fazer a modelagem de dados, além de um conceito de sistema de informação que integra os dados da organização.

2.1.1. UML - Unified Modeling Language É uma linguagem de modelagem de dados não proprietária de terceira geração, que surgiu no final dos anos 80 e início dos anos 90, segue o padrão OMG (Object Management Group) e que tem por finalidade auxiliar o trabalho de documentação de sistemas orientados a objetos.

UML é uma linguagem de diagramação ou notação destinada à especificação, à construção, à visualização e à documentação de sistemas complexos de software. Permitindo aos desenvolvedores não só visualizarem os produtos de seu trabalho, mas permitir uma padronização quanto à de modelação de dados.

Deve-se distinguir entre um modelo UML e um diagrama de UML, o último é uma representação da informação do primeiro, mas o primeiro pode existir independentemente.

A linguagem UML é consistente, dinâmica, fácil de comunicar-se com outras aplicações, simples de ser ajustada e atualizada e compreensível. Está totalmente baseada em conceitos e padrões extensivamente testados provenientes das metodologias existentes anteriormente, e também é muito bem documentada com toda a especificação da semântica da linguagem representada em meta-modelos. [7]

2.1.2. Umbrello O Umbrello é uma ferramenta livre de modelagem de dados, de fácil utilização bastante divulgada nas distribuições KDE Linux. Dentre as ferramentas livres, o Umbrello é a que oferece suporte a um maior número de diagramas, pois conta com 8 dos 13 diagramas da UML 2.0.

O Umbrello é capaz de desenhar e imprimir diagramas UML, gerar declarações de classes Java, PHP, javaScript, ActionScript, C++, SQL, Ada, IDL, XMLSchema, Python, Perl e Ruby, gerar arquivos gráficos (png), engenharia reversa de classes, e refatoração.

Os diagramas suportados pelo Umbrello UML Modeller são:

i) Diagrama de Caso de Uso. Mostra atores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos; ii) Diagrama de Classe. Mostra classes e os relacionamentos entre elas; iii) Diagrama de Seqüência. Mostra objetos e uma seqüência das chamadas do método feitas para outros objetos; iv) Diagrama de Colaboração. Mostra objetos e seus relacionamentos, colocando ênfase nos objetos que participam na troca de mensagens; v) Diagrama de Estado. Mostra estados, mudanças de estado e eventos num objeto ou uma parte do sistema; vi) Diagrama de Atividade. Mostra atividades e as mudanças de uma atividade para outra com os eventos ocorridos em alguma parte do sistema; vii) Diagrama de Componente. Mostra os componentes de programação de alto nível (como KParts ou Java Beans); viii) Diagrama de Distribuição. Mostra as instâncias dos componentes e seus relacionamentos. [8]

2.2. ERP - Enterprise Resource Planning ERP (Enterprise Resource Planning), também conhecido como SIGE (Sistemas Integrados de Gestão Empresarial), é um termo utilizado para designar sistemas de informações que integram num único sistema os mais importantes dados e processos de uma organização.

O ERP propõe uma mudança sensível na organização. Com o intuito de disponibilizar todas as informações de negócio e de gerência, ele aborda as perspectivas funcional (finanças, contabilidade, recursos humanos, fabricação, marketing, vendas, compras) e sistêmica (sistema de processamento de transações, sistemas de informações gerenciais, sistemas de apoio à decisão).

Sob a perspectiva funcional ele se dispõe a poupar o re-trabalho, garantir a confiabilidade dos dados, otimizar o fluxo da informação e reduzir os custos, já que existe integração de todos processos, centralização dos dados e não há redundância de atividades. Sob a perspectiva sistêmica ele auxilia a tomada de decisões e alterações de processos em transações, devido à integração de sistemas gerenciais e de transações.

À medida que temos uma solução integrada e automatizada, o ERP elimina toda burocracia existente nos processos, diminuindo assim o tempo que uma atividade demora a ser iniciada e finalizada (lead time). Com isso, temos a maximização da produção e a minimização do tempo utilizado e dos custos.

No entanto, a utilização de um sistema ERP não significa integração da organização. Alguns fatores como planejamento, definição de objetivos, comprometimento dos funcionários e supervisão dos gerentes são essenciais para o sucesso. Também é preciso ser feito um levantamento de quanto seria gasto para implementar uma solução integrada, porque ela soma tanto a complexidade dos sistemas que a integram quanto seus preços para serem desenvolvidos.

Assim, a aplicação do ERP se predispõe tornar uma organização otimizada em seu fluxo de produção, mais dinâmica e ágil às mudanças de mercado. [12]

2.2.1. ERP SAP Tendo como base a aplicação dos conceitos de ERP no desenvolvimento de softwares integrados, a empresa multinacional alemã SAP (Systems Applications and Products in Data Processing ou Sistemas, Aplicativos e Produtos para

Processamento de Dados) é líder mundial no ramo de soluções colaborativas.

Esta empresa desenvolve aplicativos para grandes organizações de todo o mundo, mas até agora não conta com nenhum caso de sucesso na área educacional. São grandes setores nos quais possuem soluções: financeiro e setor público; manufatura; serviços.

Seria uma inovação tal investimento na área de educação, pois a SAP tem como proposta de seus aplicativos reduzir custos, melhorar o desempenho e ganhar agilidade para reagir às necessidades de negócios em transformação. [13]

2.3. Banco de Dados Proprietário X Livre SGBD é um software que permite a definição de estruturas para armazenamento de informações e fornecimento de mecanismos para manipulá-las. Ele é responsável em manter a integridades dos dados onde o programador pode definir algumas regras e outras já possuem definição default e garantir a segurança das informações.

Ao contrário dos demais softwares, os Sistemas de Gerenciamento de Banco de Dados (SGBDs) são de pouco interesse no meio acadêmico. Isto acontece porque os servidores de banco de dados são mais complexos do que outros tipos de servidores de rede, por esse motivo os bancos proprietários conseguiram tomar a frente na evolução tecnológica. Com o avanço da Internet essa histórica mudou de contexto. Os softwares livres passaram a ganhar força e os bancos de dados proprietários se mostraram inadequados com seus protocolos de comunicação pesados.

As principais características que um SGBD deve prover são: Independência de Dados; Restrições de Acesso; Controle de Redundância; Restrições de Integridade; Compartilhamento de Dados; Mecanismos de Backup e Recuperação; Múltiplas Interfaces; Representação de Relacionamentos Complexos entre Dados; e Tolerância a Falhas.

Ao fazer a escolha de um SGBD, deve considerar alguns pontos, tais como: Número de Usuários; Crescimento da base de dados; Estabilidade; Robustez; Desempenho; Segurança; Devem-se observar principalmente características mais técnicas, que impactarão diretamente na administração dos dados; A escolha da ferramenta deve ser discutida entre toda a equipe; A ferramenta deve ir de encontro à filosofia da empresa e às expectativas de crescimento. [9]

Segue algumas tabelas (extraídas de [4]) de comparação entre 3 SGBDs, bastante conhecidos no mercado, explorando algumas características relevantes para o gerenciamento de banco de dados relacionais:

Tabela 1. Funcionalidades Fundamentais

Tabela 2. Tabelas e Visões

Tabela 3. Índices

Tabela 4. Operadores de Conjunto

Tabela 5. Outros Objetos Nativos

Comparando os parâmetros citados acima, basicamente não houve diferenças significantes entre os demais. Quanto à robustez, desempenho e estabilidade, todos os SGBD’s apresentam melhor desempenho no Linux ou em algum UNIX-like. E todos eles, possuem implementações para o SO citado. As diferenças surgem quando se pensa em montar um Data Warehouse, pois o PostgreSQL ainda é deficiente neste campo. Porém, o PostgreSQL otimiza operações de consulta, tornando trabalhos de acesso ao banco mais eficientes.

Em termos de suporte, além de existirem várias comunidades na internet para tal, os SGBDs Livre possui uma gama de empresas especializadas nestes serviços, como referências podemos citar Dextra Sistemas (Campinas/SP) e dbExpress (São Paulo/SP).

A escolha deve ser feita em cima das seguintes perguntas: “Qual a real necessidade da instituição? A quem ela se dirige?” [10]

2.4. Data Warehouse (Armazém de Dados) Consiste em um ambiente paralelo ao operacional e dependente do mesmo, em outras palavras, é um repositório de informações que provê dados para processamento analítico e tomada de decisões. É mantido separado dos bancos de dados operacionais e trabalha com metadados (dados sobre dados). Um data warehouse deve suportar o processamento de informações através de uma plataforma sólida de dados históricos e consolidados para análise.

A idéia básica é: i) Extrair os dados da base; ii) Filtrar os dados desejados; iii) Integrar dados internos e externos em uma estrutura única; iv) Apresentar os dados de maneira amigável e eficiente.

Os objetivos são: i) Fornecer uma única imagem da realidade dos negócios para toda empresa; ii) Melhorar a qualidade dos dados e o seu tempo de acesso; iii) Ser flexível, pois qualquer negócio está sujeito a mudanças inevitáveis;

iv) Conter informações preciosas e deve ser visto como as “jóias da coroa” do Reitor; v) Servir de suporte nas decisões da instituição, portanto não deve haver inconsistências; vi) A instituição na sua totalidade deve aceitar o DW, caso contrário a estratégia de usá-lo estará fadada ao fracasso.

Abaixo temos uma ilustração (Ver Figura 1) do funcionamento do Data Warehouse: [5]

Figura 1. Funcionamento do DW

Um DW não deve ser confundido com um Banco de Dados comum, ele tem características bem peculiares, são elas:

i) Orientado por assunto: Um DW é organizado em torno de assuntos principais como clientes, vendas, distribuição, marketing, entre outros. Dessa maneira, focam na modelagem e análise de dados para a tomada de decisões e não nas operações diárias do negócio. Além disso, provêem uma visão simples e consistente de um assunto através da exclusão de dados não-relevantes à operação de análise e/ou processo de tomada de decisões; ii) Normalmente, é construído a partir de diversas fontes heterogêneas ou de diversas fontes de uma só base de dados, constituindo dessa forma uma estrutura de integração; iii) Um Data Warehouse deve ser atualizado constantemente, por isso, é variante no tempo, dessa forma toda chave estrutural do DW contém um elemento de tempo; iv) Atualizações operacionais que ocorrem normalmente num BD operacional, não ocorrem no DW, suas atualizações são sempre incrementais; v) Modelos multidimensionais requerem organização dos dados, métodos de acesso, e métodos de implementação especiais, por isso, são geralmente implantados em servidores chamados de Servidores relacionais OLAP, separados do SGBD’s comerciais. Além disso, o crescimento acelerado do DW pode criar problemas de espaço para o Banco de Dados operacional; vi) Um DW trabalha em cima de metadados (dados sobre dados).

Abaixo temos um exemplo ilustrativo de um Data Warehouse comercial. A figura 2 (extraída de [6]) ilustra um sistema de produtos X por cidade X Tempo, e a partir dela podemos entender porque um Data Warehouse é chamado de modelo multidimensional:

Figura 2. Modelo ilustrativo do DW Os componentes de um Data Warehouse são:

i) Sistemas de Fontes Operacionais (Busca): Nesta fase é onde decidimos o que buscar e onde buscar e pode envolver operações de mineração de dados; ii) Data Staging Area (Adaptação): Com os dados escolhidos, precisamos adaptá-los à realidade da empresa e para isso é necessário um refinamento das informações escolhidas; iii) Data Presentation Area (Apresentação): Etapa de decisão de como os dados selecionados serão apresentados ao público alvo; iv) Ferramentas de Acesso. [11]

3. SOLUÇÕES PROPOSTAS AO CPD Nesta sessão abordaremos possíveis soluções às deficiências encontradas na gestão de dados do CPD e melhorias encontradas em outras organizações.

Nas subseções seguintes apresentaremos o cenário atual do estudo de caso do CPD, um possível cenário desejado e soluções que podem ser aplicadas para a obtenção desse cenário desejado.

3.1. Estudo de Caso O Estudo de Caso em questão tem como objetivo analisar o tratamento das informações do Centro de Processamento de Dados (CPD) da Universidade Federal de Sergipe (UFS). Inicialmente foi feita uma análise da situação atual para serem identificadas e diagnosticadas possíveis falhas existentes nesta instituição, com relação aos dados manipulados pela mesma. E, posteriormente, elaborarmos um cenário desejado com possíveis soluções.

De início foi feita uma entrevista com a coordenadora de desenvolvimento de sistemas, Estelamaris e a Administradora de Banco de dados – DBA, Dinorá. Foi a partir desta entrevista que tivemos acesso ao tratamento feito a todo tipo de dado da Universidade Federal de Sergipe.

O Sistema de Gerenciamento de Banco de Dados utilizado é o DB2 – IBM, sem a cogitação de mudança do mesmo. Os principais motivos alegados para tal foram disponibilidade de suporte e segurança, pelo fato de ser um SGBD privado.

O backup é feito diariamente através de fitas e dispõem de espaço de armazenamento suficiente para atender a demanda.

Apesar de possuir diversos sistemas para atender as demandas de usuários, entre esses não possui uma interoperabilidade eficaz. Muitas das informações geradas acabam sendo multiplicadas, causando um sério problema na base de dados: a redundância de informações. E uma das principais redundâncias existentes é o cadastro de informações de cada indivíduo vinculado à universidade. Indivíduo esse que pode ser aluno do Codap (Colégio de Aplicação), graduando, pós graduando, funcionário, etc. Digamos que um aluno do Codap que passe pela graduação, pós graduação e retorne como docente, este será portador de quatro matrículas da instituição,

ou seja, o banco de dados terá quatro vezes a mesma informação pessoal deste indivíduo. Tal fato gera inconvenientes do tipo: se um indivíduo é pós-graduando e funcionário técnico ou docente, que número de matrícula ele deve utilizar? Esse problema ocorre, pois a informatização da UFS foi elaborada a fim de atender às necessidades individuais dos setores da universidade.

A validação de dados, criptografia e geração de relatórios são feitas em nível de sistema. Cada sistema possui sua maneira de tratar os dados, com relação a esses aspectos.

A respeito da modelagem de dados e da documentação ainda é muito deficiente. Não existe nenhum tipo de padronização, não é feita uma análise dos projetos e sistemas a serem desenvolvidos o que pode gerar uma forte gama de problemas no decorrer do desenvolvimento, dificultando e retardando a sua execução.

Foi detectada também a ausência de ferramentas que auxilie na indicação de dados estatísticos para avaliar o desempenho dos vários setores da universidade, inclusive o próprio CPD.

Esse foi o quadro atual de como se encontra o CPD da UFS, o qual nos mostra falhas e ausências, onde buscaremos soluções que serão avaliadas pelos membros da equipe de TIC do CPD.

3.2. Cenário Desejado Identificados os problemas, apresentaremos algumas possíveis soluções ao estudo de caso da UFS. É importante ressaltar que as TICs surgem para auxiliar no serviço das empresas automatizando ou facilitando algumas tarefas, o que não significa que elas necessariamente o farão. Esta é uma questão que depende muito da real necessidade que se tem, e pode variar de instituição para instituição.

3.2.1. Remodelagem dos dados A redundância das informações diminui a confiabilidade dos dados contidos na base e nossa sugestão é utilizar o sistema de matrícula única contido no PDI da UNIFESP, modelando assim corretamente o indivíduo na instituição e abrangendo toda a sua vida acadêmica. Se necessário, terceirizando o serviço de migração (utilizando o padrão UML e a ferramenta livre Umbrello para modelagem), dessa forma uma equipe manteria a base de dados atual enquanto a outra equipe faria o trabalho de projeto e migração dos mesmos. Com isso reduzimos os problemas de redundância de dados e aumentamos a confiabilidade e integridade destes, pois o cadastro institucional do indivíduo será feito apenas uma vez.

3.2.2. Migração da base de dados De software de gerenciamento pago (IBM/DB2) para um SGBD de código aberto e livre como o PostgreSQL. Dessa forma haveria uma redução do custo na aquisição de licenças. O PostgreSQL é um SGBD robusto e seguro, ao contrário do que pregam os puristas e inimigos do software livre. Ele concorre tranqüilamente com SGBDs antigos e de nome no mercado como Oracle, IBM/DB2 e SQLServer. Além do mais, possui uma gama de informações e documentação de suporte na internet, e até mesmo no site do PostgreSQL ou no seu fórum de suporte. Existe também uma lista de empresas e profissionais individuais que oferecem serviços de consultoria e manutenção no PostgreSQL espalhados pelo mundo inteiro, dentre elas a própria Sun e a LocaData (com sede em MG). Da mesma forma existe uma lista de empresas renomadas que patrocinam o desenvolvimento do PostgreSQL, dentre elas estão a própria Sun, a RedHat e a Skype. E, atualmente, a IBM também patrocina, com um investimento de US$ 10 milhões. Podemos citar como caso de exemplo, aqui no país, o

Banco do Brasil que é considerada a maior instituição financeira da América Latina e atua em 21 países, e desde o ano 2000 possui um plano de implantação ativo de software livre nas suas agências, escritórios e Complexos Centrais de Tecnologia (CCT) e este plano envolve os seus SGBDs que abrigam informações importantes de clientes. Estima-se que até o final do ano praticamente todas as suas agências no país já rodarão SL em sua totalidade nas máquinas e servidores.

3.2.3. Tecnologias de apoio Uso do Data Warehouse a fim de avaliar o desempenho dos vários setores da universidade. DW é uma robusta ferramenta ao passo que serve como indicador de qualidade na instituição. Bem utilizada, indicaria com qualidade e rapidez, por exemplo:

i) Estatísticas sobre os cursos; ii) Quais os departamentos ou centros que produzem mais pesquisas científicas (ou mais pesquisas científicas relevantes à comunidade acadêmica); iii) Informações financeiras, e dessa forma, fraudes seriam evitadas; iv) Poderiam rastrear atividades com datas e prazos; v) Documentos requisitados, enviados e recebidos.

A regra diz que ao planejarmos um DW, o uso de um SGBD mais maduro se faz necessário, porém depende muito da necessidade da instituição. Quando trabalhamos com metadados, há uma necessidade em buscas otimizadas e operações pré-definidas para um data warehouse e dessa forma o uso de um SGBD maduro é praticamente uma obrigação. Porém ao avaliarmos o caso da UFS podemos ver que essa não é a real necessidade da instituição e que nesse caso o uso de um DW em cima de um SGBD como o PostgreSQL seria suficiente, pois é um SGBD leve e com otimizações de busca. Em outro momento de avaliação se o DW crescesse estupidamente ao ponto do PostgreSQL não suportar o grande volume de dados, aí sim projetaríamos um DW em cima de um SGBD de porte como o IBM/DB2.

Análise do uso de um ERP na universidade. Devido ao fato de organizar todo o conjunto de dados referente ao negócio sob as perspectivas funcional e sistêmica (gerencial) da organização, a utilização de um sistema ERP solucionaria existentes problemas de consistência de dados, garantindo assim a confiabilidade nas informações, diminuindo a redundância de dados, o lead time e o retrabalho. Uma solução ERP não é uma solução barata. Antes de tentar se adquirir um sistema integrado, é necessário fazer uma avaliação de custo-benefício e avaliar também se a sua utilização consiste numa eficiência maior do trabalho, gerando assim lucro para a organização. Para implantar um sistema ERP, primeiro deve ser necessário decidir se a própria equipe de desenvolvimento da organização implementaria um solução ou se seriam contratados os serviços prontos de um sistema único. Caso a própria equipe desenvolva uma solução, ela deverá ser dividida numa sub-equipe que mantenha os sistemas antigos e uma que desenvolva o novo sistema; caso sejam contratados os serviços de um sistema pronto, qualquer alteração desejada deve ser bem documentada, pois a cada nova distribuição recebida, qualquer possível alteração feita pela própria equipe será perdida. É preciso ter em mente também que a obtenção de um sistema ERP não significa integração da organização, é preciso ter também uma política de incentivo ao bom uso do sistema integrado por parte dos funcionários, estes que podem se recusarem a utilizar o novo sistema ou mal utilizá-lo. Assim, com a aplicação do ERP se predispõe uma organização

otimizada em seu fluxo de produção, mais dinâmica e ágil às mudanças de mercado.

3.2.4. Outras sugestões e práticas de manuseio dos Dados. Mudanças na base de dados devem ser planejadas e aprovadas, pois apenas dessa forma podemos aumentar a integridade e diminuir a redundância dos dados da instituição. Mudanças na base de dados não devem ser tomadas por apenas um DBA e sim por um grupo, todos eles podem e devem questionar as mudanças. Validar e criptografar os dados abrigados pelo SGBD a fim de respeitar a privacidade dos indivíduos que compõem a instituição. Em organizações de grande porte, podemos ver um cuidado especial com as informações pessoais dos seus clientes, e aqui na Universidade não deve ser diferente. Basta um mínimo de bom senso e podemos perceber que informações pessoais como senhas, e-mails e endereços residenciais são de caráter restrito, e só podem ser cedidas a terceiros apenas com autorização do indivíduo.

Planejar futuras necessidades de armazenamento e reforçar estratégias de backup. A base de dados abriga informações importantes e talvez irrecuperáveis em caso de pane dos servidores. Dessa forma, a fim de garantir a integridade e a recuperação dos dados, estratégias como espelhamento de discos e RAID poderiam ser aplicadas.

Convocar comissões de auditoria em caso de necessidade urgente. Numa situação delicada, como fraude administrativa, por exemplo, como poderíamos punir os responsáveis? O CPD da Universidade exerce um papel de altíssima responsabilidade neste caso, pois as informações cadastradas deveriam ser facilmente rastreáveis numa situação como esta.

Criar comissões de planejamento estratégico, a fim de auxiliar na tomada de decisões relativas à área de TIC da UFS. Criadas as comissões, a primeira tarefa é alocar recursos convencendo os auto-escalões da universidade que a área de TIC é de vital importância ao desenvolvimento da instituição, portanto, merece os devidos investimentos e apoio financeiro nesta área.

4. CONCLUSÕES As informações sobre o cenário dos dados que alimentam os sistemas utilizados na UFS foram obtidos através de entrevistas com Estela, coordenadora do setor de desenvolvimento de sistemas do CPD. Mantivemos também conversas informais com Dinorah, administradora de banco de dados. A partir dessa coleta de informações sobre os dados, sobre como eles são modelados, sobre a forma como eles são armazenados e sobre como os sistemas interagem com esses dados, buscamos analisá-los com a finalidade de propor melhorias caso encontrássemos deficiências e/ou ineficiências, além de pesquisar novas soluções atuais na área de dados. Sendo assim, propomos uma reestruturação na área de dados que, juntamente integradas às outras áreas (software, pessoas, hardware e redes e telecomunicações), comporá o Planejamento Estratégico de Tecnologia da Informação e Comunicação (PETIC).

Atualmente, como principais problemas na área de dados, encontramos a redundância e a inconsistência de dados. Os sistemas utilizados na UFS não foram projetados de forma integrada, sendo assim, para cada necessidade local, foram desenvolvidas ou compradas soluções locais. Diferentes soluções, geralmente, têm suas bases de dados, e essa falha na modelagem de dados gera problemas, como desconfiança na

integridade dos dados, retrabalho, redundância, etc. Em nível de exemplo podemos citar o caso do PINGIFES, que é um sistema desenvolvido pelo governo, e o CPD deve alimentá-lo com os dados da instituição, anualmente, a fim de repassar informações importantes ao MEC. Nesse cruzamento são eliminadas redundâncias e informações desnecessárias, mas, pior é a busca pelos dados que não são registrados. Este fato só vem a reforçar a importância de uma base de dados sólida e confiável. O problema da redundância e inconsistência existirá sempre, se o CPD não atacá-lo urgentemente. Ao analisarmos com cuidado, podemos ver claramente que a situação é pior, pois a tendência é aumentar a inconsistência, já que novos cursos serão criados e aumentarão o número de alunos na instituição. Dessa forma fica difícil gerenciar a gama de informações que transitam pela base de dados todos os dias.

Não só os dados e a sua geração na base de dados estão deficientes, mas também a maneira como eles são obtidos. Não existe uma cultura de geração de atas de reuniões e levantamento de dados.

Por fim, com o objetivo de atacarmos o grande mal da inconsistência, os gerenciadores da instituição devem abrir os seus horizontes e enxergar o CPD não como uma simples "fábrica de software" ou "arquivo da instituição", mas como uma importante engrenagem, talvez a mais importante delas. Para esse fim, uma boa verba deve ser investida, não porque lidam com equipamentos caros, mas sim porque lidam com informações importantes, e a manutenção destas sim, custa caro.

As nossas propostas de reestruturação de dados terão como base necessidades elicitadas pela coordenadora do CPD, Estela, soluções que obtiveram êxito e propostas definidas por outros planos estratégicos encontrados.

5. REFERÊNCIAS [1] Said, Dulcelina. Et Al. Plano Diretor de

Tecnologia da Informação: ANVISA. [s.l]: 2007. Disponível em <http://www.anvisa.gov.br/layout_ sistema/cd/pdti_mar2007.pdf> Acesso em 28 mai. 2008.

[2] Plano Diretor de Informática - Unifesp/EPM. Botucatu: 2008. Disponível em <http://www.unifesp.br/reitoria/ orgaos/comissoes/informatica/pdi.htm> Acesso em 2 jun. 2008.

[3] Tapajós, Luziele. Et. Al. Rede SUAS MDS. Brasília: 2007. Disponível em <http://www.mds.gov.br/sites/ conferencias-1/arquivos/rede-suas-mds-atualizado.pdf> Acesso em 28 de mai. de 2008.

[4] Boscarioli, Clodis. Comparação entre SGBDs. Universidade do Oeste do Paraná. Paraná: 2006. Disponível em: <http://www.inf.unioeste.br/~clodis /BDI/BDI_2007_Modulo7.pdf> Acesso em 25 mai. 08.

[5] SOWEK, Carlos Alberto. O que é Data Warehouse? Curitiba: 2003. Disponível em <http://www.pr.gov.br/ batebyte/edicoes/1997/bb62/warehouse> Acesso em 18 jul. 2008.

[6] KIMBALL, Ralph. Dimensional Modeling Primer. In:___. The Data Warehouse Toolkit. EUA: Wiley Computer Publishing, 2002. pg 01~27.

[7] ESMIN, Ahmed. Modelando com UML. Disponível em <http://www.dcc.ufla.br/infocomp/artigos/v1.1/tutorialUML.pdf>. Ji-Paraná: [s.a.]. Acesso em 15 jul. 2008.

[8] Manual do Umbrello UML Modeller. 2003. Disponível em <http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/> Acesso em 17 jul. 2008.

[9] MySQL X PostgreSQL: Quando usar cada um. Disponível em <http://www.lozano.eti.br/palestras/pgsql-mysql.pdf> Acesso em 22 jul. 2008.

[10] Marchi, Késsia. Conceitos de Sistemas de Banco de Dados. Unipar. Disponível em <http://kessia.blogs.unipar.br/files/2008/04/bdi-conceitos-de-sistemas-de-bd-modo-de-compatibilidade.pdf> Acesso em 22 jul. 2008.

[11] KIMBALL, Ralph. Education. In:___. The Data Warehouse Toolkit. EUA: Wiley Computer Publishing, 2002. pg 243~254.

[12] MORAES, Anderson. Trabalho sobre ERP: Enterprise Resource Planning. Curitiba: 2004. Disponível em <http://pessoal.cefetpr.br/lapeplow/Paginas/ERP0104.pdf> Acesso em 18 jul. 2008.

[13] ERP. Disponível em <http://pt.wikipedia.org/ERP> [s.l]: 2008. Acesso em 18 jul. 2008.