Torre de Babel

Nos últimos dias passei por duas situações que me trouxeram à memória uma frase comum, mas que se aplica perfeitamente: "Quanto melhor conheço o Windows, mais gosto do Linux"...

No primeiro caso, pediram-me ajuda para converter um Windows Vista em Português (pré-instalado num portátil, comprado cá em Portugal) para Alemão... procura daqui, googla dacolá e a conclusão foi rápida e esperada: "Só adquirindo uma nova licença em Alemão ..."

O segundo caso envolve o mecanismo de "Full-Text Search" numa Base de Dados SQL Server 2000, mas onde os dados a pesquisar estão numa língua não suportada, concretamente hebraico. A resposta da Microsoft: "Na versão 2008 já suportamos hebraico no FTS"...

Ora, como se passam as coisas no mundo livre ?

No primeiro caso, depende um pouco do sistema usado mas em Debian seria algo do género: dpkg-reconfigure locales
e, eventualmente, fazer o download e instalação de alguns pacotes de linguagens

No segundo caso, devido à natureza aberta dos sistemas em uso, muitas vezes é possível usar dicionários e definições linguísticas de um dado programa (e.g., ispell) no programa que nos interesse (e.g., postgresql). A maior parte dos sistemas abertos, tem, por outro lado, uma diversidade linguística que faz corar de vergonha qualquer sistema proprietário...

Nesta verdadeira Torre de Babel em que nos encontramos cada vez mais ligados, começa-se a perceber as verdadeiras vantagens dos sistemas abertos...

Códigos de Barras e tal....

Sempre gostei de matemática, ou melhor, da aplicação prática da matemática. Uma das áreas que gosto de "visitar" de vez em quando é a questão dos chek-digits, ou dígitos de controlo, encontrados em quase todos os códigos de produto e afins.

Aqui há tempos tive que criar uma base de dados para gerir códigos EAN, os vulgares códigos de barras que os produtos presentes nos supermercados possuem. Existem vários formatos de códigos EAN, nomeadamente o EAN-8, o EAN-13 e os EAN-13+2 e EAN-13+5.

Nos códigos EAN-13 (o que me interessava para a base de dados), existem 4 campos em que podemos subdividir o código: País, Marca, Produto, Dígito de Controlo.

Por exemplo, se tivermos o código 5601045105306, este subdivide-se em:
- Código do País : 560
- Código da Marca: 1045
- Código do Produto: 10530
- Dígito de Controlo: 6

Ora, os códigos dos diversos países são atribuídos por uma organização internacional, denominada GS1, sendo que a Portugal cabe o 560.

Dentro de cada país, existem organizações que distribuem os códigos pelas marcas, e estas organizam os códigos pelos seus produtos como muito bem entenderem....

Resta o dígito de controlo: Como é calculado ?

Começemos por escrever o código, sem o dígito de controlo:

560104510530

Numeramos as posições da direita para a esquerda :

12 11 10 9 8 7 6 5 4 3 2 1
5 6 0 1 0 4 5 1 0 5 3 0

Multiplicamos todos os algarismos nas posições ímpares (1, 3, 5...) por 3:

12 11 10 9 8 7 6 5 4 3 2 1
5 18 0 3 0 12 5 3 0 15 3 0

Somamos todas as parcelas:

5 + 18 + 0 + 3 + 0 +12 + 5 + 3 + 0 +15 + 3 + 0 = 64

E determinamos qual é o algarismo que é necessário adicionar para que o resto da divisão deste último valor por 10 seja 0 (zero):

70 - 64 = 6

Assim, obtemos o dígito de controlo e podemos agora escrever o código completo:

5601045105306

Existem outros métodos de cálculo de dígitos de controlo, normalmente usados, por exemplo o dos códigos ISBN (dos livros), dos códigos NIB, do número do BI, etc...

SQL e a programação por Objectos

Existe uma grande separação entre as representações de dados baseadas na teoria relacional de Codd e Date, implementadas correntemente nas Bases de Dados Relacionais e as representações dos mesmos dados do ponto de vista da programação orientada a objectos. As modernas frameworks de programação incluem APIs de "persistência" de dados, ou seja, mecanismos que permitem converter a representação baseada nas tabelas relacionais em classes e objectos adequados à manipulação pela linguagem em causa. Esta tradução é, muitas vezes, deixada ao critério da framework usada.

Correntemente não se pode prescindir de uma ou de outra forma de representar os dados e há necessidade de recorrer a uma qualquer espécie de mapeamento ou tradução de variáveis "relacionais" (os registos das bases de dados) para variáveis "Objecto" (os elementos do código da aplicação). Esta diferença de representações e os problemas a ela associados são normalmente chamados de "Object-Raltonal Impedance Mismatch".

Num artigo muito interessante, Ted Neward fala deste problema como o Vietname da Informática, ou seja um problema cuja solução mais óbvia (o mapeamento Objecto-Relacional) está condenada ao fracasso.

A qualidade

Ontem, conversava com alguém acerca da pouca qualidade dos sistemas informáticos, especialmente do software existente.

Dizia o meu interlocutor que é pena que "o mercado" tenha aceite esta fraca qualidade, especialmente a nível dos sistemas cliente, i.e., dos PC caseiros e semelhantes. O mesmo cenário não é tão comum nos servidores e sistemas de suporte a infraestruturas de rede e outros.

Eu penso que o mercado ficou refém de uma situação de "nivelamento por baixo", ou seja, para que fosse possível divulgar largamente a informática pessoal (especialmente na sua vertente lúdica, que é a que de facto representa os maiores lucros), as empresas envolvidas não quiseram lutar pelo melhor produto mas aceitaram uma lógica de usar o já existente de modo mais ou menos acrítico, "encaixando" os seus defeitos como características e não como verdadeiros defeitos. Deste modo, vulgarizou-se uma relação de acomodação com o software que hoje se pode resumir a: "Bolas, lá voltou a encravar outra vez, paciência".

Ao tolerar esta situação temos cumplicidade no seu prolongamento, pois não nos podemos esquecer que uma empresa existe essencialmente para dar dinheiro a ganhar aos seus accionistas. Ora, ao aceitar os defeitos e falhas de um produto como se fossem normalidades estamos inconscientemente a dizer à empresa que o produz: "Estão no bom caminho!" quando a mensagem que devia passar seria "Atenção! Este produto tem defeito, não presta! Exijo ser bem servido !".

É responsabilidade nossa, como consumidores, exigir aos fornecedores de produtos e serviços um determinado nível de qualidade e ter a coragem para assumir alguns eventuais transtornos e até custos de mudança, pois só assim poderemos progredir. No final, sairemos todos a ganhar.

O cenário na gama de servidores e outros equipamentos é diferente porque desde há muito que os consumidores desses produtos (na sua maioria empresas)tem como norma fazer valer os seus direitos de consumidor. Esta pressão dos consumidores sobre os fornecedores levou a que existam hoje equipamentos capazes de trabalhar meses a fio com poucos ou nenhuns problemas.

Optimizações

Ao fazer a análise a uma Base de Dados para resolver problemas de performance ou optimizar as queries que são realizadas, começamos, normalmente, por verificar quais as queries mais lentas, que levam mais tempo a executar, de modo a actuar nessas queries.

Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.

Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!

Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;


Até breve !

SQL - Standards e Implementações

Hoje, ao deambular pela net, encontrei um site muito interessante, pelo menos para quem gosta destas coisas de Bases de Dados, que faz a comparação entre as implementações de SQL de alguns dos mais comums SGBD, nomeadamente PostgreSQL 8.2.0, IBM DB2 Express-C v9.1 LUW, Microsoft SQL Server 2005, MySQL 5.0.18 e Oracle 10g R2. Outras comparações podem ser encontradas na wikipédia, em http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems e nas referências do primeiro artigo.

Da leitura destes artigos vê-se que existem grandes diferenças de implemtação do standard SQL:2003 e até características aparentemente tão simples como o tipo de dados CHAR pode ter comportamentos diferentes entre os vários sistemas. Daqui se conclui que é muito difícil escrever uma aplicação em que a camada de acesso a dados seja genérica, o que leva a que as aplicações estejam muitas vezes ligadas a,e dependentes de, um SGBD particular. Por vezes, existem diferenças comportamentais até entre versões diferentes do mesmo SGBD.

O melhor que se pode tentar conseguir é usar as potencialidades de cada sistema através de procedimentos e linguagens embebidas nos SGBD (tais como PL/SQL em Oracle ou pgPlSql em PostgresSQL) e criar uma camada de acesso via esses procedimentos, para que se afastem as especificidades do armazenamento de dados o mais possível da lógica da aplicação. Com este processo ganha-se em versatilidade, segurança e clareza da arquitectura da aplicação.

Rapidinha

Uma pergunta rápida, que me "assaltou" o espírito...

Será que um ERP baseado em Web Services pode ter algum interesse ??

SAN - NAS

Ao dimensionar um Sistema de Informação existem vários pontos a ter em conta, um dos quais é o espaço necessário para armazenar a informação pretendida.

Ora, visto que um Sistema de Informação não é uma entidade estática mas irá sofrer evoluções, é necessário contar também com as necessidades futuras que possam vir a exigir mais espaço de armazenamento.

Nesta área há duas tecnologias principais que permitem maior flexibilidade do nosso armazém de dados: NAS e SAN, ou seja "Netwok Attached Storage" e "Storage Area Network". Embora os nomes sejam parecidos e o fim seja o mesmo, os conceitos que estão por detrás de cada uma delas são muito diferentes e assentam em pressupostos também diferentes. Uma SAN é constituída por um conjunto de discos (o armazenamento propriamente dito) que se liga a um computador através de uma rede dedicada, normalmente de fibra óptica. Um sistema NAS é um conjunto de discos que está ligado à rede local (LAN) através de Ethernet. Dito assim, até parece que não existe grande diferença entre os dois, a não ser a tecnologia de rede usada. A outra (maior) diferença entre as duas opções é o tipo de informação que fornecem aos sistemas a eles ligados.

Uma SAN fornece os dados que tem armazenados sob a forma de "blocos" tal como se fosse mais um disco interno de um servidor. Deste ponto de vista a SAN serve para "esticar" o espaço disponível para armazenar ficheiros num servidor.

Um sistema NAS fornece os dados sob a forma de ficheiros, ou seja, comporta-se como um servidor de ficheiros independente do resto dos servidores da rede.

Apresentado um exemplo:
Temos um computador na rede, que precisa de aceder ao ficheiro "Projecto1.odt" armazenado num sistema NAS. O caminho para esse ficheiros será do género [Usando caminhos SAMBA/CIFS]:

\\SistemaNAS\Partilha\Projecto1.odt

Se, pelo contrário, o mesmo ficheiro estiver numa SAN, gerida pelo servidor Server1:

\\Server1\Partilha\Projecto1.odt

Portanto, do ponto de vista dos clientes, nada a assinalar. Então porquê esta "questão" à volta da tecnologia a implementar ? Porque não escolher uma delas e seguir em frente ??
Essencialmente porque as Bases de Dados não gostam de NAS, i.e., se tivermos que alojar uma Base de Dados de alguma dimensão torna-se incomportável transferir um ficheiro "pela rede".

Vendo outro exemplo:

Supomos que existe uma Base de Dados de suporte ao nosso Sistema de Informação que irá ter cerca de 10 GiB.
Ao alojar este ficheiro no NAS, teremos que configurar o SGBD para o usar e, uma vez que os SGBD requerem acesso exclusivo a todo o ficheiro da BD, este teria que ser transferido na totalidade para o sistema que corre o SGBD sempre que houvesse necessidade de leitura/escrita na BD. Mesmo com FastEthernet de 1Gb/s, a transferência do ficheiro demoraria cerca de 2 minutos. Claro que este tempo de espera ao abrir o ficheiro será incomportável para as aplicações, já para não falar em recursos de memória que seria necessários do lado do SGBD.
Se o alojarmos numa SAN, podemos atribuir essa área da SAN ao servidor do SGBD e comportar-se-á como armazenamento local. Quer isto dizer que nunca haverá necessidade de transferir todo o ficheiro, pois em caso de acesso a ficheiros locais só os blocos envolvidos são transferidos.

Para além das razões "técnicas" de acesso a ficheiros, ecistem também diferenças significativas na instalação, configuração e administração dos dois tipos de armazenamento, o que leva a que muitas vezes o NAS seja preferido pelo seu menor custo e maior facilidade de implementação. Pelo contrário, quando o que está em causa é a velocidade de acesso e facilidade de expansão (e o dinheiro chega) prefere-se implementar uma SAN.

Ultimamente tem-se vindo a aproximar as duas filosofias pela junção de um NAS na interface da SAN com a rede, o que cria, na prática, um NAS muito escalável e bastante rápido.

Tanto num NAS como numa SAN, são aplicáveis outros conceitos relativos ao armazenamento, nomeadamente níveis de RAID e tecnologias de Discos, que fiarão ar uma próxima ocasião.

Sistemas de Informação - parte III

Tal como prometi no artigo sobre documentos dispersos e a sua relação com os sistemas de informação, este artigo aborda o terceiro componente que, na minha opinião, deve ser considerado parte dum sistema de informação bem estruturado e desenvolvido: o e-mail.

O e-mail é, dos serviços da Internet, um dos mais antigos e um dos mais usados. Embora criado há já muitos anos o protocolo POP sofreu várias revisões, sendo a última e mais recente a chamada versão 3, constituindo assim o protocolo POP3, descrito no RFC 1939, de Maio de 1996.

Uma vez que as condições das redes informáticas são agora muito diferentes de há dez anos atrás, nomeadamente na disponibilidade de acesso à informação por parte dos utilizadores, a quantidade de dados que é necessário manter na forma de mensagens de e-mail é cada vez maior. A existência de regulamentação legal para tornar obrigatória a manutenção de um arquivo de mensagens de e-mail, tal como os existentes para correio em papel, aumenta ainda mais essa necessidade.

O que fazer então para arquivar os milhares de mensagens que nos chegam por ano às caixas de correio, e, mais ainda, como fazer para que os utilizadores tenham acesso a tais quantidades de e-mail sem prejudicar o desempenho da rede ou do sistema onde estão a trabalhar ??

Deixo esta pergunta no ar, para reflectirem durante este mês de férias... Daqui a algum tempo voltaremos a este tema...

Sistemas de Informação - parte II

Boas,

No seguimento do post anterior sobre o que constitui um Sistema de Informação, interessa saber como fazer a integração da informação presente em conteúdo não estruturado (nos tais ficheiros de aplicações diversas) com a informação presente de forma estruturada na Base de Dados que suporta o Sistema de Informação.

Um método cada vez mais comum é transformar os ficheiros em documentos XML que depois podem ser integrados nas Bases de Dados, pois os principais fabricantes de Bases de Dados já incluem esta funcionalidade há algum tempo. Uma vantagem deste método é que pode permitir a pesquisa de informação dentro do documento original usando a linguagem XPath o uoutra semelhante. A principal desvantagem é a necessidade de conversão de documentos, que podem ser milhares ou mais, tornando este processo num processo moroso e sujeito a erros.

Podemos também admitir que os documentos existem fora da Base de Dados e criar um repositório, eventualmente com controlo de versões ou mantido por uma ferramenta de trabalho colaborativo. Esta segunda hipótese resulta normalmente da necessidade de rever ou alterar documentos a posteriori.

Ambos os métodos têm as suas vantagens e o seus pontos fracos, que devem ser avaliados antes da implementação.

Para um próximo artigo, fica o grande problema do e-mail...

Sistemas de Informação

Nestes últimos posts tenho-me debruçado principalmente sobre a performance e questões
relacionadas com as Bases de Dados que, geralmente, suportam um Sistema de Informação. No entanto, um Sistema de Informação não se esgota na Base de Dados. O que deve, afinal, constituir um Sistema de Informação (SI)?

No meu ponto de vista, o SI de uma qualquer organização deve incluir toda a informação relevante para o negócio/actividade da dita organização, esteja esta informação numa BD ou dispersa por documentos diversos de aplicações várias, tais como processadores de texto, folhas de cálculo, etc.

Um SI bem conseguido deve ainda ser capaz de apresentar a informação desejada aos
vários utilizadores, independentemente do tipo de acesso que estes possuam no momento, por exemplo, um vendedor de uma empresa que esteja numa visita a um cliente deve poder aceder aos dados relevantes sobre esse cliente mesmo que tenha apenas um telemóvel com internet.

Mas como conseguir esta característica? Será tema para um próximo post...

Fiquem bem.