Atualmente, podemos dizer que em sua totalidade os sistemas informatizados utilizam algum tipo de armazenamento de dados, e que a grande maioria desses utilizam mecanismos de bancos de dados relacionais, baseados na linguagem SQL (Structured Query Language – Linguagem de Consulta Estruturada), cada SGDB usa um dialeto próprio, e nosso objetivo aqui não é entrar nas questões relacionadas a um SGDB específico, porém, todos usam em comum uma estrutura conhecida como “RELACIONAL” onde cada estrutura se relaciona com outra através de conceitos e relações matemáticas que formam a ÁLGEBRA RELACIONAL e a TEORIA DOS CONJUNTOS, vamos neste artigo falar um pouco sobre estes conceitos e como projetar um banco de dados de maneira eficiente.
Entidades, Tabelas, Tuplas, Linhas, Atributos, Colunas, Chaves, Registros, Índices, Relacionamentos, Relação – O que significa esses conceitos?
Estes conceitos são a base da estrutura de qualquer gerenciador de bancos de dados, vamos explicar cada um deles para que você possa se familiarizar, e apresentar porque conhecer bem essas nomenclaturas faz uma grande diferença principalmente na performance de um banco de dados relacional.
Muitos dos nomes apresentados no tópico, são nada mais que jargões técnicos para representarem conceitos já conhecidos por muitos de nós, desde a época do colégio, quem quiser dar uma refrescada na memória, pode procurar estudar ou rever os conceitos básicos de conjuntos.
Entidades ou Tabelas
Ambos são a mesma coisa, e representam um conjunto de dados dispostos no formato de uma tabela, ou seja, linhas e colunas. Exatamente como um arquivo de uma planilha do excell, do google ou mesmo a tabela periódica, ou a tabela dos times de um campeonato de futebol.
Os conceitos mais importantes neste momento a serem entendidos é que ela deve ter um nome que a represente, como por exemplo os times do campeonato brasileiro, os animais da fauna brasileira, os contatos do whatsapp, ou seja, os dados armazenados dentro dessa tabela, estão de alguma maneira relacionados, exatamente como um conjunto.
Tuplas, Linhas e Registros
Como o nome diz, uma linha corresponde a uma informação única capaz de identificar cada um dos elementos da nossa tabela, por exemplo, em uma tabela de times do campeonato brasileiro, podemos ter uma série de nomes dispostos em diversas linhas, onde cada uma dessas linhas representa um único time.
Para ser simples, imagine uma folha de caderno, que represente a lista de amigos que vou chamar para minha festa de aniversário, cada linha da folha, deve representar um amigo, e ao pegar uma única linha, devo ser capaz de identificar exatamente qual é o amigo e como vou contactar ele para comunicar meu aniversário, que dia será e onde será.
Neste momento, devemos ter em mente que cada registro ou linha deve ser único, e representar somente um individuo do nosso conjunto de dados, por exemplo na lista de amigos, não podemos ter somente o nome, pois poderíamos ter dois amigos diferentes que se chamam José por exemplo, o que nos leva ao próximo conceito
Atributos ou Colunas
O conceito de atributos, também chamados de colunas, representam as partes da informação que queremos ter sobre os dados armazenados na nossa tabela. A união de todos os atributos deve tornar capaz identificar cada um dos elementos do nosso conjunto.
Vamos usar como exemplo a nossa lista de amigos, alguns atributos que precisamos ter são o nome, o sobrenome e o numero do telefone. Veja, podemos ter vários nomes de José na lista, quando armazenamos também o sobrenome, nossa lista vai se reduzir a um numero menor de registros, por exemplo, José da Silva. Mesmo usando o nome e o sobrenome, nosso contato ainda pode ter mais de um número de telefone, porém, se pegar-mos todos os atributos, devemos ser capaz de encontrar somente uma informação – José da Silva (xx)99999-8888
Neste momento, não vamos nos preocupar com mais nada, só com o conceito que cada atributo ou coluna deve fazer com que possa-mos nos lembrar de armazenar aquela parte da informação do conteúdo que faz parte de um registro, e que juntas todas as colunas devem identificar com precisão uma única informação. Resumidamente é uma parcela de toda a informação que queremos ter do conteúdo da tabela, que interessa e está diretamente ligada ao conteúdo total da tabela.
Relacionamento
O conceito de relacionamento é um pouco mais complexo, e envolve a forma como um conjunto ou tabela está intimamente ligado com outro conjunto ou tabela. Vamos usar um exemplo para deixar o conceito mais claro um pouco, vamos usar então 2 tabelas, uma com os registros de compras que fizemos no supermercado, onde temos, a data da compra, o numero do ticket, o mercado onde ela foi feita, o valor total pago, entre outros dados. Em outra tabela, vamos armazenar os dados referentes aos itens comprados, como o código de barras do item, sua descrição e o valor pago.
Para que possamos relacionar essas duas tabelas, vamos registrar em cada um dos itens, a qual ticket ela pertence, ou seja, a coluna ticket nesta relação esta intimamente ligada aos dois registros, ou seja, todos os registros da nossa segunda tabela estão relacionados a compra registrada na primeira tabela, devido ao número do ticket. Para que exista um relacionamento, é necessário que algum dado esteja fortemente vinculado nas duas tabelas, a coluna que armazena esses campos em uma e na outra tabela, recebe uma denominação especial, e diferente em cada uma delas.
Para que exista essa relação, e saber qual é a coluna que deve ser usada para fazer essa interligação em cada uma das tabelas, a esse conceito damos o nome de CARDINALIDADE, para identificar a relação básica de cardinalidade, temos que pensar novamente na teoria dos conjuntos, qual dos conjuntos relacionados possui o maior número de elementos únicos? No nosso caso, é muito simples, uma única compra no supermercado pode ter diversos itens, dai, a relação de cardinalidade inicial é que, 1 única compram tem um mínimo de 1 item, e um máximo de N itens, onde N é um número maior que 1.
Existem algumas regras que nos ajudam a fazer essas identificações e estabelecer uma correta relação entre cada uma das tabelas, e a essas regras, que abordaremos em outro artigo, damos o nome de FORMAS NORMAIS e quando representamos visualmente essas tabelas e relações, criamos um DIAGRAMA ENTIDADE-RELACIONAMENTO que se parece com a imagem abaixo:
De maneira que, cada retângulo da imagem, representa uma tabela e o seu nome na parte superior, cada linha dentro desses retângulos representa uma coluna da nossa tabela, cada linha ligando um retângulo ao outro, identifica um relacionamento.
Os números nessas linhas, indicam a CARDINALIDADE, visualmente na imagem, é possível identificar que as linhas que ligam essas tabelas, partem de uma coluna para outra, pois indicam qual é o campo ou atributo que possui a relação de ligação entre os dados. Recorda-se que disse agora a pouco que esses campos recebem nomes especiais, esses campos são conhecidos como CHAVES, vamos falar deles abaixo.
Campos Chave, Chaves, Chave Primária, Chave Única, Chave Estrangeira
Bem, como o nome já diz, alguns campos ou grupos de campos possuem uma relação especial com os dados que estão na nossa tabela, esses são considerados os CAMPOS CHAVE, ou simplesmente CHAVES, essas podem ser de diversos tipos, a saber:
CHAVE PRIMÁRIA ou CHAVES PRIMÁRIAS, é o nome dado ao campo ou grupo de campos que permitem identificar com precisão um único registro. Para simplificar, vamos considerar que você só faz compras no Supermercado Preço Bom Da Cidade, e que cada ticket é numerado com um número sequencial, a cada vez que fizermos nossas compras, esse número é crescente e não vai se repetir, portanto, na nossa tabela COMPRAS esse número é nossa chave primária, pois ela sozinha vai identificar nosso registro. Nesse caso específico, nossa chave é um identificador chamado de CHAVE PRIMÁRIA SIMPLES, ou seja composto por uma única coluna.
Se por outro lado, estivermos fazendo o registro de diversas compras, de supermercados diferentes, que usam a mesma regra de numeração dos tickets, teríamos que ter uma CHAVE PRIMÁRIA COMPOSTA que recebe este nome, pois é a união de duas ou mais colunas da nossa tabela. Quando ocorre este tipo de junção, alguns mecanismos de bancos de dados relacionais, criam uma terceira chave que é mantida pelo próprio mecanismo, chamada de UID (Unique IDentifier – Identificador Único), que geralmente é um número inteiro sequencial, e tem como finalidade a facilitação da exportação das chaves para os relacionamentos.
CHAVES ESTRANGEIRAS, são as colunas que vieram da tabela que esta relacionada, no nosso exemplo, a tabela que contém o registro dos itens, recebe como um de seus campos, o número do ticket, e é esse campo que recebe o nome de chave estrangeira, lembre-se, caso nossa chave primária da tabela compras seja composta, ambas as colunas devem ser exportadas, criando também uma chave estrangeira composta. Quando uma tabela recebe uma chave estrangeira, esta geralmente faz parte da chave primária da tabela, aqui digo geralmente, pois novamente alguns mecanismos de bancos de dados agregam as partes das chaves primaria mesmo as compostas por chaves estrangeiras, e u utilizam o UID (ou OOID ou UUID conforme o nome dado pelo gerenciador de banco de dados), porém, tecnicamente e conceitualmente as chaves estrangeiras são a chave primária em sua totalidade da tabela PAI (tabela que tem a cardinalidade 1) que é transmitida. Ou seja, a TABELA FILHO que recebe a cardinalidade N obrigatoriamente deve possuir uma CHAVE PRIMARIA COMPOSTA, e um dos componentes dessa chave é também a chave primária.
CHAVE ÚNICA, como seu nome já diz, a chave única é o nome dado a uma informação que não pode de maneira nenhuma se repetir, mais que por algum motivo não faça parte da chave primária, digamos que temos uma tabela com o cadastro de medicamentos da nossa farmácia, e que cada fabricante tem um nome específico para o seu produto, porém, todos devem seguir a nomenclatura dos medicamentos genéricos do governo, a nossa chave primária é o CNPJ DO FABRICANTE + IDENTIFICADOR DO COMPOSTO + DOSAGEM ou seja, o fabricante 12345678-0001-90 + ACIDO X + 10MG é a chave de identificação, porém, comercialmente damos o nome de XPower 10, podemos dizer que XPower 10 é nossa chave única, pois nenhum outro registro vai poder utiliza-lo, porém, sua identificação exclusiva é a usada para digamos os documentos fiscais, e nessas tabelas, o nome XPower 10 não vai aparecer, dai surge o conceito de chave única, mais por ora não vamos nos aprofundar nesses conceitos chamados de restrições, pois vamos aborda-lo mais adiante.
Índices
O conceito de ÍNDICE é muito similar ao que é utilizado nos livros e nos mecanismos de buscadores na internet, ele é um subconjunto muito menor dos dados, que tem como principal objetivo facilitar a localização de uma informação dentro da nossa base de dados, existem muitas técnicas diferentes de indexação, e alguns mecanismos implementam diversas técnicas agrupadas para obterem os melhores resultados.
O uso de índices acelera a pesquisa no conjunto de dados, imagine por exemplo um livro de estudos com algumas centenas de páginas sobre o tema, cada vez que você precisasse buscar algum conteúdo, se você tivesse que folhear todas as páginas, acabaria demorando muito tempo para localizar o que procura. Com um índice basta você procurar o tema principal, e ir direto a um subconjunto de páginas muito menor que o livro inteiro para pegar os conteúdos específicos.
O uso de índices pode trazer grandes melhorias para o desempenho do banco de dados, de maneira global, porém, o seu uso de maneira errônea pode ser um desastre não só em termos de desempenho, mais em organização. Entender o funcionamento deles é um dos pontos mais importantes para um bom funcionamento.
Índices são sempre bem vindos em colunas onde exista grande seletividade, como por exemplo, uma tabela de cadastro de clientes, além da chave primária, que pode ser o CPF, muitas vezes pode acontecer de termos que pesquisar os clientes pelo NOME, ou por qualquer outro identificador único ou não da tabela na sua aplicação, ou seja, você pode ter também um índice para colunas que poderão lhe auxiliar em consultas, sempre que elas aparecem constantemente em clausulas WHERE, precisando ou não usar os operadores. Porém, nem tudo são maravilhas, o uso de um INDEXADOR, causa grande problema em operações de INSERT, DELETE e UPDATE pois, além do SGDB ter que atualizar os dados da tabela, também terá que realizar operações de escrita para atualizar cada um dos índices.
A regra de ouro dos índices, é que a manutenção deles requer tempo e recursos do servidor, portanto, não crie índices que não serão usados efetivamente, nem quando contém grande quantidade de dados duplicados, como colunas do tipo SEXO ou outras que possuem um conjunto limitado de variações, pois nesses casos, eles representam mais custo que benefício.
Alguns mecanismos de bancos de dados possibilitam a criação de um índice chamado CLUSTER que tem como função separar a tabela física (em disco) em pedaços, neste caso, caso uma coluna com poucas variações, pode ser fisicamente alocada e indexada para cada cluster em separado. Por exemplo se nossa tabela de CLIENTES possui um CLUSTER feito pelo SEXO, a um índice de NOME, quando selecionamos uma MULHER de NOME=’ANA LUISA’ primeiro o otimizador de consulta só pega o índice do CLUSTER SEXO=’F’ (FEMININO) e só precisa carregar a parte do índice que usa a coluna NOME de parte dos resultados. Porém a escolha errada de um CLUSTER pode degradar também a performance.
Quando vamos projetar uma base de dados, devemos planejar as consultas que serão amplamente usadas, e um bom planejamento destas consultas pode ser determinante em questões de performance do servidor de dados, por exemplo tabelas que recebem maior volume de insert e delete do que select não devem possuir nenhum índice além da própria chave primária, já tabelas que são mais frequentemente consultadas, podem ou não ter índices o que vai determinar é o plano de consultas. Onde, colunas que geralmente aparecem frequentemente em clausulas WHERE são fortes candidatos a serem indexadas.
Otimização de Consultas e Uso do SGDB
Quando projetamos uma BASE DE DADOS devemos ter em mente qual será a utilização dela, pensar na estrutura dos dados, nos volumes de inserções, atualizações, exclusões e consultas para poder otimizar a performance e o uso de recursos dos servidores de bancos de dados. Portanto, uma boa otimização e performance depende não só das boas práticas e do conhecimento sobre o sistema gerenciador de bancos de dados usados, mais também de como internamente os dados ficam armazenados e até mesmo otimizados em disco.
O ponto mais importante são os resultados, por este motivo, cabe ao administrador do banco de dados, otimizar as tabelas, campos, índices, chaves primárias e chaves estrangeiras e todas as estruturas relacionadas, dai, nem sempre seguir todas as formas normais e regras pode ser a melhor solução, no próximo artigo vamos falar especificamente sobre as FN1, FN2 e FN3 que são as três regras mais básicas para a perfeita organização dos dados, e também, como otimizar e preparar suas consultas e procedures internas para melhorar a performance e os resultados.
