Os artigos dessa edição estão disponíveis somente através do formato HTML.
Clique aqui para ler todos os artigos desta edição
Bancos de dados complexos – Um exemplo prático
Hoje, a maior parte da informação existente em uma organização não está armazenada em linhas de tabelas de um banco de dados. São informações guardadas em documentos, memorandos, e-mails, vídeos e todo o tipo de conteúdo que não é facilmente estruturado em linhas e colunas de uma tabela. Quanto mais complexa for a informação a ser manipulada, mais complexa se torna nossa aplicação, já que temos que, o tempo todo, montar e remontar a informação para que ela seja útil em nosso programa e que possa ao mesmo tempo ser armazenada no banco de dados.
Se sua aplicação está se tornando muito cara porque você precisa de um “algo mais” em termos de armazenamento e recuperação, então você precisa de um servidor de dados que possa manipular dados complexos e é isto que vamos abordar neste artigo.
Um pouco de teoria
Chamamos de “dados complexos” toda a informação que não é bidimensional (linhas e colunas) ou mesmo que não é formada por tipos simples (inteiro, string, etc.). Observe que um dado complexo pode ser desde uma imagem até um documento contendo várias páginas de texto, som e vídeos.
Como a informação é complexa, a “linha” que armazena o registro no banco de dados não é necessariamente um vetor e sim um objeto. O modelo de dados orientado a objeto não está limitado a manter as informações em linhas e colunas. Em vez disso, o desenvolvedor cria uma definição que descreve completamente uma determinada classe de informação. Cada registro (objeto) é uma instância específica daquela classe. Assim, cada objeto contém todos os itens de informação para um, e apenas um, registro. Neste caso, um objeto pode conter, por exemplo, uma nota fiscal e ao mesmo tempo todos os itens associados à nota, coisa que em um banco de dados relacional envolveria pelo menos duas tabelas diferentes.
Existem diferentes tipos de bancos de dados OO, mas já existe um padrão dominante, que foi definido por um consórcio de empresas e instituições de pesquisa, o ODMG – Object Data Managment Group (www.odmg.org) - e é o modelo que vamos usar no exemplo deste artigo. O ODMG define duas linguagens para a manipulação do servidor de banco de dados, o ODL (Object Description Language), que seria o equivalente ao DDL comum e o OQL (Object Query Language) que seria o equivalente ao nosso velho SQL.
Outra informação importante sobre a manipulação de dados complexos é a recuperação textual. Como a informação não é necessariamente uma matriz de linhas e colunas, às vezes pode ficar difícil especificar o que se deseja obter. Com a recuperação textual, tudo fica mais fácil, já que podemos recuperar a informação por qualquer palavra (ou parte dela) que ocorra em qualquer membro de um objeto.
No Brasil é produzido um dos mais populares bancos de dados textuais do mundo, o LightBase (www.lightinfocon.com.br) - que praticamente criou o termo “Banco de dados textual” e já conseguia manipular dados complexos há quase uma década. Agora na versão 5.0, ele adotou o padrão ODMG 3.0 e se tornou um poderoso banco de objetos, com recuperação textual embutida. Além disso, seus novos recursos de colaboração com bancos de dados relacionais tradicionais podem tornar um banco de dados como Oracle ou o SQL Server em poderosos repositórios de objetos.
