• Nenhum resultado encontrado

3. PROPOSTA DE SOLUÇÃO

5.1.2 Base de dados

Conforme já foi referido, o SGBD “MySQL” foi desenvolvido para lidar com bases de dados muito grandes de maneira muito rápida e tem sido usado com muito sucesso em ambientes de produção de alto rendimento, desde há vários anos.

Foi necessário definir qual o tipo de motor de armazenamento do “MySQL”. De entre os vários que existem, selecionaram-se os 2 mais relevantes (MyISAM e InnoDB) [34]. Analisadas que foram as características de ambos, optou-se pelo motor “ImnoDB”, por garantir uma utilização mais segura das tabelas, possuir capacidades de

commit, rollback e recuperação de crash’s. Porém, as características mais importantes

que pesaram na escolha para o projeto, foram as suas boas capacidades concorrenciais de multi-utilizador e a sua excelente performance. Além disso, suporta também chaves estrangeiras que reforçam a integridade entre os dados.

O motor “ImnoDB” foi desenhado para tirar o máximo de performance no processamento de grandes bases de dados. É utilizado na manipulação de grandes quantidades de dados, e em sites que requerem alta performance.

Assim, pelas razões referidas e de acordo com um estudo recente da Oracle [45], considerou-se o motor “InnoDB” como o mais indicado para utilizar no projeto.

Modelo de Dados:

A estrutura do modelo de dados é bastante complexa e tem que ser concebida de maneira a garantir o bom funcionamento do sistema. Optou-se por uma solução normalizada, criando-se um conjunto de tabelas relacionais sem dados redundantes, permitindo assim realizar os processos de adição, remoção e alteração sem qualquer efeito colateral.

De modo a facilitar a análise e compreensão da estrutura do modelo de dados, em primeiro lugar serão apresentadas as entidades principais e os seus tipos de relações.

Com base nas análises anteriores é possível identificar as seguintes entidades principais: • Computadores • Utilizadores • Grupos • Departamentos • Classes • Tipos • Cores • Tempos • Utilização • Registos • Produtividade

DESENVOLVIMENTO

______________________________________________________________________

Todas estas entidades estão relacionadas entre si através de diferentes ligações, representadas na figura 6. Existem algumas tabelas auxiliares que, não estão representadas no modelo de dados, por não possuírem relações.

Figura 6: Modelo de dados do sistema

Procura-se com esta estrutura do modelo de dados garantir a sustentabilidade da base de dados, que vai conter todos os registos de atividade e inatividade recolhidos pelo

DESENVOLVIMENTO ______________________________________________________________________ inserção de novas entidades sem mudanças significativas na sua estrutura, garantindo assim um modelo com capacidade de integração.

Estrutura da base de dados:

O desenvolvimento da base de dados, começou com a criação de duas tabelas auxiliares que servirão apenas para receber os dados da aplicação cliente, a tabela “atividade” e a tabela “inatividade”. Foi criado um mecanismo que regularmente limpa essas tabelas de forma a evitar a duplicação de informação e assim melhorar o desempenho da recolha de dados. Ambas as tabelas possuem um trigger, que é ativado sempre que recebem um registo, e executa um procedimento que atualiza os registos das tabelas “pcs” e “users” previamente criadas. Ou seja, sempre que um computador ou utilizador novo é inserido no sistema e as tabelas “atividade” e “inatividade” recebem os seus dados, o trigger atualiza as tabelas “pcs” e “users” com os dados do novo computador ou utilizador. Garante-se assim que é possível fazer consultas ao sistema sobre computadores novos sem haver necessidade de atualização prévia das tabelas “pcs” e “user”.

Todas as tabelas possuem uma chave primária que identifica individualmente cada um dos seus registos, garantindo assim a sua integridade, eliminando a possibilidade de haver registos duplicados.

Foram criadas tabelas para agrupar os computadores e os utilizadores por departamentos. Com isto é possível saber quais os computadores e utilizadores que pertencem a um determinado departamento. Mas o seu grande objetivo é facilitar a análise do gestor em termos comparativos, não só entre computadores do mesmo departamento como entre os próprios departamentos. A figura 7 representa a relação das tabelas “pcs” e “users” com a tabela “depart”.

DESENVOLVIMENTO

______________________________________________________________________

Processamento de dados:

Conforme foi referido em capítulos anteriores, a produtividade é de extrema importância do ponto de vista analítico e pode ser avaliada.

Para isso, começou-se pela classificação do tipo de atividade e criou-se uma tabela “classes” que faz parte de um grupo e possui uma cor, que ajudará na construção e análise dos gráficos. Assim, ao verde atribuímos as atividades (classes) produtivas, ao amarelos as pouco produtivas, e ao vermelhos todos as atividades relacionadas com

softwares, sites e ficheiros que não sejam produtivas.

Na figura 8 está representada a relação entre as três tabelas responsáveis pela classificação dos registos de atividade, recolhidos pelo software cliente.

Figura 8: Tabela de classes

No capítulo 3.1 foi definida uma fórmula que será usada a seguir para o cálculo da produtividade. Assim, os registos da tabela auxiliar “atividade” são copiados para a tabela “registos”. Além disso sempre que é inserido um registo na tabela “atividade” é despoletado um procedimento “Produtividade()” que o classifica e atribui uma pontuação de produtividade, ou seja, multiplica o tempo da atividade pelo valor da classe. Na figura 9 está representada a relação entre as diferentes tabelas.

DESENVOLVIMENTO ______________________________________________________________________

Foi criada uma tabela “utilização” que guarda a hora em que o computador foi ligado e desligado, tendo em conta o primeiro e o último registo de cada dia da tabela “tempos”. Um event de 10 em 10 minutos, executa um procedimento “Utilizacao()” que procura a hora do primeiro e do último registo de cada um dos dias da tabela “tempos”. Faz também o cálculo da diferença entre as duas horas obtidas, para obter o tempo de utilização do computador em cada um dos dias. Na figura 10 está representada a relação entre as tabelas “pcs” e “user” e a tabela “utilizacao”.

Figura 10: Tabela de utilização

Existem outras tabelas (“precisão” e “dia”) necessárias para obter as respostas às consultas que alimentam os gráficos. A tabela “precisao” limita a amostragem de dados de um dos gráficos evitando por exemplo, que sejam processados dados relacionados com atividades com menos de um minuto. A tabela “dia” guarda o dia, comum ao processamento de alguns gráficos.

5.2 Front Office

O Front Office é o conjunto de elementos do sistema que interagem com o utilizador final. Inicia-se no registo do utilizador no website do sistema, segue-se a instalação do

software cliente e termina com a utilização do portal do sistema onde o utilizador

interage com os seus dados.

Documentos relacionados