Arquivo da tag: dbdesigner

O modelo de dados do Joomla

Olá pessoal. Neste artigo vou apresentar mais uma análise do modelo de dados utilizado em um CMS (Content Management System). Desta vez apresentarei o modelo de dados do Joomla, um dos CMSs mais populares.

Há algum tempo atrás escrevi um artigo sobre o modelo de dados do WordPress aqui no iMasters. Desta vez vou analisar e comentar o modelo de dados do Joomla, outro CMS que está se tornando muito popular aqui no Brasil não apenas para a construção de blogs, mas também para a criação de web sites inteiros e complexos.

Assim como o WordPress, o Joomla pode ser utilizado basicamente de duas formas:

Através da contratação e utilização de um hosting especializado que hospedará o site;

Através do download e instalação do Joomla disponível no site oficial do Joomla. Há também uma forte comunidade de usuários brasileiros representados no site oficial do Joomla no Brasil.

A utilização do Joomla através da contratação de um hosting vai depender das configurações que o serviço de hospedagem fornece.

É comum encontrar painéis de controle e outras interfaces que facilitam tanto a administração como a criação de conteúdo. Contudo, nestas situações geralmente o ambiente está montado e não é preciso interagir diretamente com o banco de dados.

Já a segunda forma de utilização envolve o download, instalação e configuração do Joomla. Neste contexto é preciso conhecimento técnico da instalação do Joomla e suas dependências, como o servidor de banco de dados MySQL, o PHP e o servidor Web escolhido.

Este artigo se concentra nos detalhes técnicos envolvidos no banco de dados. O público alvo deste artigo são profissionais que precisam lidar com instalação, configuração e manutenção do Joomla e não para quem apenas o usa para gerenciar conteúdo.

É razoável admitir que a maioria dos usuários não precise conhecer o modelo de dados devido à facilidade do uso de painéis administrativo e outras interfaces que permitem a publicação de conteúdo neste CMS. Porém, administradores, DBAs, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o Joomla devem conhecer bem seu modelo de dados.

Uma vez que já foram explicadas as duas formas de se utilizar o Joomla vamos ao modelo de dados que este CMS utiliza.

A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo Joomla 1.6 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.

Figura 1. Modelo de dados do Joomla 1.6 no DBDesigner

Já a Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.

Figura 2. Modelo de dados do Joomla 1.6 no MySQL Workbench.

Os modelos da Figura 1 e da Figura 2 não foram produzidos por mim. O crédito vai para Torkil Johnse, que disponibilizou estes modelos gratuitamente no seu blog nos formatos do MySQL Workbench(MWB), PNG, PDF e SVG.

Nota: as figuras representam um modelo de dados levemente modificado em relação ao modelo original, como o próprio Torkil comenta em seu blog. As principais diferenças são a mudanças de alguns tipos de dados e a colocação de relacionamentos, uma vez que o MySQL com MyISAM não os suporta. Também destaco que o modelo da Figura 2 não apresenta nenhuma informação sobre os índices das tabelas.

Oficialmente não encontrei nenhuma página que contém informações sobre este modelo inclusive com detalhes das tabelas e suas colunas. Mas encontrei uma página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. Acesse a página que contém este dicionário de dados simplificado para a versão 1.5.

Assim como o WordPress, o Joomla não possui um arquivo contendo todos os comandos SQL necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo.

Antes de começar a análise do modelo é preciso dizer que oficialmente o Joomla só pode ser instalado no MySQL e/ou a extensão MySQLi. Isso quer dizer que se a empresa já possui outro banco de dados, como o PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores.

Existem alguns esforços da comunidade para permitir que o Joomla suporte outros bancos de dados, porém estes esforços ainda não foram integrados oficialmente ao projeto. Para mais informações sobre o suporte a outros bancos de dados no Joomla recomendo os seguintes links:


De forma similar ao que acontece no WordPress, o modelo de dados do Joomla também não contém chaves estrangeiras. O motivo pela ausência de chaves estrangeiras provavelmente é por que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB. Aqui repito o que já havia falado quando analisei o modelo de dados do WordPress:

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma desempenho aceitável.

Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor desempenho que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que hajam dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado.

Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pela opção de criação de conteúdo, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Existem várias características e pontos do modelo do Joomla que podem ser analisados. O próprio Torkil Johnsen já apresentou diversos aspectos do modelo que ele crê que podem ser melhorados no artigo chamado The Joomla database schema smells.

Os principais pontos que ele destaca são a falta de padronização e problemas de nomenclatura, tipos de dados, normalização e falta de completude do modelo. Concordo com muitos dos pontos levantados pelo Torkil e aqui vou colocar algumas considerações minhas e, quando possível, realizar pequenas comparações com o modelo de dados do WordPress.

O modelo do Joomla possui mais de 30 tabelas divididas em grupos como publicação de conteúdo, componentes, menus, templates e outros. Essas divisões foram destacadas em retângulos com nomes na Figura 1.

Já o WordPress é mais enxuto e contém 11 tabelas. Existe uma correlação entre a quantidade de tabelas e colunas de um modelo e a sua complexidade, especialmente em aplicações simples que não estão associadas a toneladas e toneladas de requisitos e casos de uso com diferentes tipos de usuários.

Ou seja, quanto mais tabelas/colunas em um modelo de dados provavelmente ele vai ser mais complexo de ser compreendido, vai dificultar tarefas de importação/exportação e possui e tendência de introduzir complexidade desnecessária.

A principal tabela do modelo do Joomla possui o sufixo _content e é responsável pelo armazenamento de informações sobre o conteúdo (como posts em um blog). Esta tabela concentra muita informação nela mesma e possui quase 30 colunas. Obviamente, nem todas as colunas são preenchidas quando se cria um novo post e muitas destas colunas possuem valores que claramente poderiam ser mais bem aproveitados se estiverem em outra tabela.

Por exemplo, a dupla de colunas publish_up e publish_down, ambas do tipo DATETIME, armazenam a data que o post foi publicado e a data em que ele foi retirado do ar. Porém somente duas datas são armazenadas e não há como armazenar o histórico de mais de uma data de publicação e retirada do post. Esta característica se repete ao longo de diversas outras tabelas do modelo.

Outro ponto que me chamou a atenção foi a falta de tipos de dados booleanos, que armazenam valores 0/1 ou VERDADEIRO/FALSE ou TRUE/FALSE. Em muitas tabelas existem colunas que, aparentemente, poderiam se beneficiar do tipo de dados booleano como, por exemplo, a tabela _contact_details, que contém uma coluna chamada published do tipo de dados TINYINT(1).

Além disso, destaca-se também o uso em excesso de colunas com o tipo de dados TEXT, algo que permite o armazenamento de dados limitado apenas pelos recursos do servidor e não por um número fixo de caracteres.

O uso em excesso de colunas do tipo TEXT pode eventualmente se tornar um problema devido à grande quantidade de caracteres armazenados e à necessidade de backups específicos por tabelas. Sem contar que a indexação e pesquisa para este tipo de dados devem ser especiais, algo que não é tratado no Joomla diretamente.

Do ponto de vista de modelagem, em algumas situações o modelo atende a certos requisitos relativamente bem, como é o caso do gerenciamento de usuários, grupos e permissões.

Por outro lado, algumas tabelas deveriam ser implementadas como plug-ins ou extensões e não diretamente no modelo padrão, como é o caso do gerenciamento de avaliação (rating) de um post cujos dados são armazenados na entidade _content_rating.

Outro exemplo de tabelas que seriam mais bem aproveitadas em plug-ins ou extensões está relacionado com a criação de enquetes (polls) cujos dados são armazenados nas tabelas_polls, _polls_menu e _polls_data.

Outro aspecto que me chamou à atenção no modelo foram as tabelas responsáveis pelo armazenamento de informações de propaganda (_banner, _bannerclient e _bannerfinish) que provavelmente vieram como resquício do modelo do banco de dados do Mambo, projeto na qual o Joomla se originou.

Atualmente o modelo de patrocínio em sites evoluiu muito em relação aos antigos banners e creio que estas tabelas acabaram ficando no esquecimento devido à funcionalidades e requisitos de campanhas com links patrocinados e integração com programas de afiliados.

Apesar de não ser difícil compreender o modelo uma vez que se acostume a ele, em algumas situações fica estranho não contar com a nomenclatura e termos já tradicionais.

Por exemplo, em nenhuma tabela/coluna existe o termo comentário. No modelo de dados esta forma de interação do usuário com o post é chamada de mensagens. Já a tradicional forma de taxonomia apresentada por tags é representada por seções e categoria em um post. Já template é utilizado estritamente para menus e não faz referência direta à forma de customização do layout do site.

Novamente, assim como no WordPress, o modelo de dados do Joomla não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar disso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais.

Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna count da tabela _categories. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação.

Enquanto alguns podem argumentar que isso é responsabilidade da aplicação não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.

Em resumo pode-se dizer que o modelo do Joomla é robusto e atende à sua necessidade, porém é um modelo que carrega muito do projeto Mambo. O destaque vai para o foco de armazenar no banco de dados informações tanto de conteúdo como de usuários, configurações, comentários, avaliações, menus, etc.

Com certeza este modelo pode ser melhorado nos aspectos de nomenclatura, padronização, tipagem, normalização e outros. E esta melhoria é responsabilidade da comunidade de desenvolvedores e usuários do Joomla. Infelizmente, melhorias profundas no banco de dados requerem tempo conforme o projeto vai ficando cada vez mais maduro.

Apesar destas ressalvas, o Joomla é um bom CMS que pode ser utilizada para montar muitos projetos e sites interessantes. Obviamente, ele precisa evoluir e continuar a inovar no aspecto de funcionalidades, customização e usabilidade.

Sugiro aos desenvolvedores e à comunidade que procurem também aprimorar o seu modelo de dados, o que pode trazer inúmeros benefícios à ferramenta tornando-a cada vez melhor.

Um grande abraço e até a próxima.

Fonte: Mauro Pichiliani/joomlaclube

O modelo de dados do WordPress

Cometário SWX: O artigo é um pouco antigo (01/03/2010), mas não deixa de ser interessante. A versão do WordPress na data desta publicação é a 3.x.

Olá, pessoal. Neste artigo vou apresentar uma análise do modelo de dados utilizado no WordPress – o CMS (Content Management System), mais popular nos dias atuais. Além de analisar o modelo de dados, vou disponibilizar scripts, imagens, e o próprio modelo de dados em outros formatos para aqueles que precisem saber como os dados são armazenados no MySQL quando se utiliza o WordPress.

O WordPress pode ser utilizado basicamente de duas formas: 1) Através do domínio wordpress.com, onde é possível criar um blog gratuitamente e sem muito conhecimento técnico de seu funcionamento interno; e 2) Através do download e da instalação do WordPress disponível no site oficial http://wordpress.org/.

Vamos nos concentrar nos detalhes técnicos envolvidos no banco de dados e nosso foco é para aqueles que têm que lidar com este tipo de trabalho, e não para quem apenas usa o WordPress para gerenciar conteúdo. É razoável admitir que a maioria dos usuários não precisa conhecer o modelo de dados devido à facilidade do uso do painel administrativo do WordPress. Porém os administradores, desenvolvedores de plug-ins e quem resolve problemas de desempenho ou integração com o WordPress devem conhecer este modelo bem.

Vejamos o modelo de dados que este CMS utiliza. A Figura 1 apresenta o modelo de dados (isto é, as tabelas e seus tipos de dados) utilizados pelo WordPress 2.9 e modelados na ferramenta de código aberta DBDesigner disponível em diversas plataformas.

Figura 1. Modelo de dados do WordPress 2.9 no DBDesigner

Oficialmente há uma página que contém informações sobre este modelo, inclusive com detalhes das tabelas e suas colunas. Porém esta página apresenta um fraco dicionário de dados sem muitas informações detalhadas a respeito de certas características do modelo como, por exemplo, justificativas a respeito dos tipos de dados. A página oficial que traz a descrição do modelo de dados do WordPress é http://codex.wordpress.org/Database_Description. Aconselho a todos que desejam conhecer mais sobre este modelo visitar esta página regularmente devido às modificações implementadas a cada nova versão do WordPress. Aliás, a figura que contém o modelo de dados desta página oficial não contém a nova tabela wp_commentmeta.

Outro detalhe importante é que durante a instalação do WordPress pode-se escolher qual será o prefixo da tabela, ou seja, o prefixo wp_ é apenas uma sugestão. Um outro detalhe interessante da instalação do WordPress é que não existe um arquivo sql contendo todos os comandos necessários para a criação do banco de dados, ou seja, é preciso fazer uma chamada a um arquivo .php após as configurações de acesso a banco de dados no painel administrativo do WordPress. Devido a isso, neste artigo vou disponibilizar alguns scripts com a estrutura e os comandos de criação do modelo do WordPress 2.9.

A Figura 2 apresenta o mesmo modelo de dados da Figura 1, porém modelado utilizando a ferramenta livre de modelagem e administração chamada MySQL Workbench.

Figura 2. Modelo de dados do WordPress 2.9 no MySQL Workbench.

Nota-se que na Figura 2 é possível observar também os índices de cada uma das tabelas. Para fazer o download dos modelos do WordPress 2.9 no DB Designer e no MySQL Workbench basta clicar aqui. O arquivo compactado também contém as imagens no formato png e svg, os scripts sql de criação gerados pelo DBDesigner e pelo comando dump do MySQL, além de arquivos .pdf com as imagens. Estes recursos são ótimos para serem impressos e pendurados na parede, dando aquele toque de decoração geek especial para os ambientes de desenvolvimento.

Antes de começar a análise do modelo é preciso dizer que oficialmente o WordPress só pode ser instalado no MySQL. Isso quer dizer que se a empresa já possui outro banco de dados, como PostgreSQL, SQL Server ou Oracle por exemplo, é preciso configurar um ambiente multi-banco, o que possui implicações para quem administra os servidores. Na página oficial do WordPress há uma descrição dos motivos que levaram a equipe de desenvolvimento do WordPress a escolher apenas o MySQL como banco de dados e também quais são as possíveis abordagens para tornar este CMS mult-banco destacadas com argumentos a favor e contra cada uma das abordagens. De qualquer forma, existem projetos que se propõem a suportar o WordPress no PostgreSQL (http://wordpress-pg.sourceforge.net/ e http://sourceforge.net/projects/postgresqlword/files/), no SQL Server (http://www.ixalon.net/2008/10/wordpress-and-microsoft-sql-server/ e http://www.forestpointtechnologies.com/blog/wordpress-on-sql-server/) e em outros bancos de dados (http://wordpress.org/extend/plugins/pdo-for-wordpress/ e http://wordpress.org/extend/plugins/external-database-authentication/).

Mais um pequeno detalhe antes da análise do modelo: o próprio criador do WordPress, Matt Mullenweg, afirmou recentemente no evento CMS Brasil 2009, realizado pelo iMasters, que inicialmente todas as configurações e dados eram armazenadas em arquivos de configuração separadas, seguindo a tradição do ambiente Unix. Conforme o projeto foi crescendo, estas configurações foram inseridas no banco de dados, o que tornou a ferramenta dinâmica o suficiente para se tornar um CMS robusto. Contudo, esta inserção não foi algo muito planejado do ponto de vista formal de modelagem de banco de dados como veremos a seguir.

O primeiro ponto que chama a atenção no modelo do WordPress é a falta de chaves estrangeiras. Este modelo de dados não possui nenhuma chave estrangeira, provavelmente devido ao fato de que ele foi criado utilizando o engine MyISAM do MySQL ao invés do engine InnoDB.

O MySQL apresenta a criação de chaves estrangeiras com o engine InnoDB a partir da versão 3.23.43b. O MySQL já está na versão 6, porém há o famoso problema de compatibilidade com as base legada. Provavelmente escolheu-se o MyISAM por facilidade e por motivos de desempenho, o que NÃO quer dizer que um banco de dados com o InnoDB não possa ser ajustado para ter uma performance aceitável. Sem entrar em uma discussão mais profunda, em geral muitas pessoas advogam que o engine MyISAM possui melhor performance que o InnoDB, porém este último possui suporte a transações, integridade e outros recursos que o MyISAM não possui.

Mais uma vez, sem entrar em detalhes, existem diversas técnicas para otimizar um banco de dados do WordPress como configuração do cache do MySQL, reescrita de consultas, tipagem e outras. Os detalhes destas técnicas ficam como assunto para um outro artigo, pois neste me concentro apenas na análise do modelo, o que também pode afetar positivamente ou negativamente o desempenho

A falta de chaves estrangeiras quer dizer que o relacionamento entre algumas tabelas não é mantido pelo banco de dados e sim pela aplicação. Isso permite que haja dados inconsistentes no banco de dados como, por exemplo, um comentário de um blog que não tem nenhum post associado. Apesar deste cenário ser fictício e ocorrer apenas quando alguém altera os dados diretamente pelo banco de dados e não pelo painel de administração do WordPress, esta possibilidade de inconsistência pode gerar problemas, principalmente quando se fala em migração de dados e segurança.

Aqui temos outra característica da aplicação: caso haja necessidade de se programar algo no WordPress, deve-se utilizar a linguagem PHP e fazer uso de uma camada de abstração de dados implementada pela biblioteca ezSQL, responsável por criar classes que permitem o acesso aos dados. Se o desenvolvedor quiser, ele também pode enviar instruções SQL diretamente para o banco de dados, como estas 13 consultas SQL úteis para quem trabalha com blogs no WordPress.

Outro aspecto que pode afetar muito o desempenho do WordPress é a tipagem de dados. Já abordei este assunto em uma coluna anterior aqui do iMasters chamada Desperdiçando espaço em disco, porém basta dizer que os tipos de dados utilizados neste modelo são demasiadamente exagerados, o que pode gerar vários problemas de desempenho quando a base se torna carregada. Destaque especial vai par o tipo unsigned BIGINT(20) utilizado nas chaves primárias e nos índices: este tipo de dados armazena valores de 0 a 18.446.744.073.709.551.615 ou 18 quintilhões 446 quatrilhões 744 trilhões 73 bilhões 709 milhões 551 mil e 615 ou aproximadamente 10 elevada à 18 potência em 20 bytes. Suponho que raramente um blog ou outro tipo de aplicação chegue a este número de posts ou comentários. Isso implica em mais sobrecarga nas páginas de dados e de índices, uma vez que todas as tabelas do modelo contém uma chave primária com o tipo de dados BIGINT(20).

Além da tipagem exagerada, há também redundância de informação: praticamente toda a informação relacionada à data é armazenada em duas colunas com tipos de dados diferentes. Por exemplo, a tabela wp_comments que armazena os comentários dos posts contém as colunas comment_date e comment_date_gmt, ambas do tipo DATETIME. Se o objetivo é armazenar a data, bastaria apenas a coluna que armazena a data no formato GMT. Mais uma vez, provavelmente existem duas colunas devido à compatibilidade com o legado: é possível que inicialmente existisse apenas uma coluna e posteriormente adicionou-se a segunda. Porém remover a primeira coluna faria páginas anteriores do WordPress pararem de funcionar.

Outro aspecto do modelo é a falta de normalização. Isso mesmo, o modelo de dados do WordPress não está normalizado até a terceira forma normal. Isso se deve porque existem colunas que trazem dados agregados e repetidos como, por exemplo, a coluna comment_count da tabela wp_posts. Esta coluna armazena a quantidade de comentários do post, valor este que pode ser calculado contando-se as linhas da tabela wp_comments em uma instrução SQL. O motivo de armazenar esta informação que pode ser derivada do modelo provavelmente é o desempenho. Esta técnica é similar a modelos dimensionais utilizados em sistemas OLAP.

Outro detalhe interessante é que o modelo de dados não possui nenhuma outra integridade de domínio ou stored procedure que faça restrição ao que é inserido no banco. Apesar de isso não ser obrigatório, esta prática abre margem para problemas como SQL Injection onde um usuário malicioso pode tentar invadir o site por meio de caracteres especiais. Além disso, a falta desta integridade pode permitir dados que invalidem a aplicação como, por exemplo, colocar o valor -2 na coluna menu_order da tabela wp_posts. Há também algumas colunas de tabelas onde o valor NULL é permitido, tornando necessária uma checagem adicional na aplicação. Enquanto alguns podem argumentar que isso é responsabilidade da aplicação, não é raro encontrar bancos de dados com este tipo de integridade de domínio implementada, fornecendo assim mais uma camada de segurança e consistência de dados.

Outro aspecto a ser mencionado no modelo é o armazenamento de arquivo atachado em um post. De acordo com o modelo, os tipos de arquivos são armazenados na coluna post_mine_type da tabela wp_posts, a principal tabela do modelo. Contudo os arquivos em si são colocados em um diretório da instalação do WordPress. Enquanto existem vantagens e desvantagens de se colocar arquivos armazenados internamente no banco de dados, existem também questões de segurança, espaço em disco, acesso concorrente e atualização do conteúdo destes arquivos que ficam fora do banco de dados, gerando assim uma tarefa adicional para o administrador. Esta técnica de armazenar apenas o local de um arquivo no banco de dados ao invés de seu conteúdo é tão comum que foi classificada como um dos database anti-patters, que podem ser vistos nesta apresentação.

Em resumo, pode-se dizer que o modelo do WordPress atende a sua necessidade, porém não é um modelo ideal do ponto de vista da modelagem formal. Em diversas situações, como em uma consultoria de banco de dados recente, tive que efetuar mudanças no modelo de banco de dados visando resolver problemas de desempenho, especialmente em sites cujo volume de acesso é grande. Porém o WordPress ainda é uma aplicação relativamente nova e com o apoio da comunidade pode se tornar cada vez melhor, particularmente em relação ao seu banco de dados.

Fonte: Mauro Pichiliani/IMasters