Talvez uma das matérias mais difíceis de um curso de engenharia de sistemas de informação seja a que trata de design de bancos de dados.
Pouca gente entende e usa as técnicas ensinadas, primeiro porque não entende, depois porque, só vale a pena se preocupar com um bom desenho, se seu banco de dados tem uma quantidade muito grande de células (cruzamentos de linhas com colunas). Imagine um banco de dados do Bradesco, por exemplo, que têm milhões de clientes. Qualquer pequena área economizada se propagará não só como economia de espaço de armazenamento mas tráfego na rede etc.
No caso do XO temos outra motivação importante: a área de armazenamento é muito pequena. Donde espaço é recurso crítico. Temos que economizar!
Vamos, nessa lição, dar uma idéia de como desenhar um banco de dados para economizar espaço.
Para um designer de banco de dados, no mundo existem:
É sobre relações que vamos falar:
As relações entre entidades e atributos podem ser de vários tipos.
Nas relações 1:1 (diz-se: um para um) temos, por exemplo: um aluno tem apenas um Número de Matrícula e, para cada Número de Matrícula temos apenas um aluno.
Já, nas relações 1:N (um para muitos) temos, por exemplo: um conselheiro tem vários alunos aconselhados e vários alunos têm apenas um conselheiro.
Finalmente temos as relações M:N (muitos para muitos) quando, por exemplo: um aluno tem vários professores e um professor tem vários alunos.
Na realidade a determinação do tipo de relação entre entidades não é uma ciência exata: depende da escolha do designer do sistema. E conforme o sentido em que olhemos a relação. Um dado carro, por exemplo, tem vários "números de série de peças" - cada peça tem um número de série único. A relação entre a entidade: carro e o atributo número de série de peça é 1:N. Tudo bem?
Mas um determinado número de série de peça pertence apenas a um dado carro. Donde a relação entre número de série de peça e carro é 1:1.
Mas, vamos agora para algo mais prático:
Começamos o design de um DB montando uma matriz que liga entidades e atributos. Digamos que queremos montar um banco de dados com informações sobre o aproveitamento dos alunos. Criamos uma amostra de uma tabela, com o que pensamos ser relevante (podemos estar equivocados, claro):
MATRIC NOME IDADE COD.NIVEL NIVEL COD.MAT MATÉRIA AVALIAÇÂO S1 JOSÉ 15 1 PRIM GRAU C1 CANTO 8 S1 JOSÉ 15 1 PRIM GRAU C2 DESENHO 5 S1 JOSÉ 15 1 PRIM GRAU C3 INGLÊS 5 S2 CARLOS 18 2 SEG GRAU C2 DESENHO 8 S2 CARLOS 18 2 SEG GRAU C3 INGLÊS 2 S3 MARIA 15 1 PRIM GRAU C4 QUÍMICA 8 S3 MARIA 15 1 PRIM GRAU C3 INGLÊS 5 S4 JOSÉ* 18 2 SEG GRAU C1 CANTO 2 S5 MARIA* 20 2 SEG GRAU C2 DESENHO 8
Repare que temos quatro alunos com nomes iguais (dois a dois).
Nossa missão, como designers, é tentar reduzir ao menor número a quantidade de células pois elas ocupam espaço. Se você contar vai ver que temos 72 células. O recurso que temos é que podemos montar várias matrizes. O computador sabe fazer a ligação entre elas.
A primeira regra do nosso método para conseguir reduzir as células é:
1 - Descobrir, para cada linha, um ou mais campos que caracterizam essa linha como única. É obrigatório que cada linha tenha isso ou sua matriz tem que ser reestudada, provavelmente acrescentando outras informações.
Na matriz acima, essa unicidade acontece com o conjunto: MATRIC + COD. MAT. Não existem duas linhas em que isso seja igual! Repare. Para os outros conjuntos existem.
Esse conjunto descoberto é chamado de: chave.
Agora vem a primeira mágica:
Se a matriz tiver chave composta (é o nosso caso), você tem que dividí-la em outras matrizes de tal forma que: a informação de um campo qualquer, não pode estar caracterizada apenas por um dos campos da dita chave.
Por exemplo: repare na matriz que a informação CANTO está caracterizada por apenas um dos campos da chave (C1) , o que não é considerado adequado.
Já um valor do campo AVALIAÇÃO não está caracterizado apenas por um dos campos da chave. Temos o B de S1+C1 e o B de S3+C4.
Vai depender de sua criatividade criar novas matrizes que satisfaçam a essa regra e, ao mesmo tempo possibilitem que, vendo todas as matrizes (o que o computador também sabe fazer) você seja capaz de reconstruir a matriz inicial.
Veja, por exemplo, esse conjunto de matrizes. Serão elas adequadas?
MATRIC NOME IDADE COD.NIVEL NIVEL S1 JOSÉ 15 1 PRIM GRAU S2 CARLOS 18 2 SEG GRAU S3 MARIA 15 1 PRIM GRAU S4 JOSÉ* 18 2 SEG GRAU S5 MARIA* 20 2 SEG GRAU
A chave dessa tabela é: MATRIC. Temos 25 células.
COD.MAT MATÉRIA C1 CANTO C2 DESENHO C3 INGLÊS C4 QUÍMICA
A chave dessa tabela é COD.MAT. Temos 8 células.
MATRIC COD.MAT AVALIAÇÂO S1 C1 8 S1 C2 5 S1 C3 5 S2 C2 8 S2 C3 2 S3 C4 8 S3 C3 5 S4 C1 2 S5 C2 8
A chave é MATRIC + COD. MAT. que é composta! Então existe aquela regrinha: se a matriz tiver chave composta (é o nosso caso), você tem que dividí-la em outras matrizes de tal forma que: a informação de um campo qualquer, não pode estar caracterizada apenas por um dos campos da dita chave. Isso não acontece aqui. Essa matriz está OK.
Essa última tabela tem 27 células. Somando todas as células de nossa matrizes temos: 60 que é melhor que os 72 que tínhamos.
Vamos então a uma última mágica para tentar reduzir isso mais ainda. Vamos: redividir uma tabela na qual um campo não-chave possa ser chave para outro campo não-chave.
Isso parece muito complicado mas repare que, na primeira das tabelas anteriores, temos:
COD.NIVEL NIVEL 1 PRIM GRAU 2 SEG GRAU 1 PRIM GRAU 2 SEG GRAU 2 SEG GRAU
Podemos criar uma matriz apenas com:
COD.NIVEL NIVEL 1 PRIM GRAU 2 SEG GRAU
A chave será: COD.NIVEL. E a outra tabela fica sendo:
MATRIC NOME IDADE COD.NIVEL S1 JOSÉ 15 1 S2 CARLOS 18 2 S3 MARIA 15 1 S4 JOSÉ* 18 2 S5 MARIA* 20 2
A chave é MATRIC.
Ficamos então com 4 tabelas. Somando as células temos agora: 59. Ganhamos uma!
Tudo isso parece muito trabalho para pouco mas, como dissemos, no caso de uma tabela com centenas de milhões de células a economia pode ser significativa e representar milhões de reais de economia de espaço e tráfego na rede.
É claro que o processamento aumenta, pois o computador terá que ligar essas 4 tabelas. Então, o desenho ideal de um banco de dados depende de se ponderar o que se ganha e o que se perde. Fragmentar demais um banco de dados pode não ser uma boa coisa. Mas se espaço é muito importante (caso do XO), geralmente compensa.
Note que a existência de alunos homônimos não trouxe nenhum problema, pois o nome não é chave de nada.
LIÇÂO ANTERIOR PRÓXIMA LIÇÂO ÍNDICE HOMEPAGE