Por Vitor Lopes para o PPLWARE.COM
Apesar de actualmente se poder encontrar muita informação sobre o tema em questão disponível na internet, resume-se no seguinte artigo alguns pontos fulcrais para a estruturação de uma base de dados, contribuindo assim para a resolução de possíveis e eventuais dúvidas que possam surgir relacionadas com o tema.
Durante o desenrolar deste artigo irão ser só abrangidos os pontos que na minha opinião são os principais e os mais importantes, para que qualquer pessoa possa adquirir o mínimo indispensável das bases necessárias para dar os primeiros passos e ir progredindo por si próprio.
Modelo Entidade-Relação
É um modelo que permite representar em forma de diagrama, auxiliando assim a sua visualização, o relacionamento das várias entidades e respectivos atributos de uma base de dados.
- Entidades
Existem várias definições, mas de uma forma geral chega-se a um consenso comum, em que uma entidade pode ser um conjunto de elementos sobre os quais se pretende guardar informação.
Exemplo: Cliente, Fornecedor, Funcionários, Alunos, Professores, etc…
Informação essa que devidamente tratada e organizada, dá origem aos atributos ou campos de uma entidade.
Exemplo: Id, Nome, Morada, Telefone, Telemóvel, Email, etc…
- Relações
Existem 3 tipos de relações:
1.1 para 1
Tal como o nome indica uma relação do tipo 1 para 1, é uma relação em que a uma ocorrência da tabela A, corresponde uma e só uma ocorrência da tabela B e vice-versa.
Exemplo: Uma pessoa só pode ter um número de BI, e um BI só pode pertencer a uma pessoa.
Numa relação do tipo um para um, cabe ao “criador” do modelo entidade-relação a escolha de qual a tabela que irá receber a chave estrangeira.
2. 1 para N (em que N significa vários)
Uma relação do tipo 1 para n, é uma relação de um para vários, ou seja, entre duas tabelas A e B, a uma ocorrência da tabela A podem corresponder várias ocorrências da tabela B, enquanto que a uma ocorrência da tabela B corresponde só uma da tabela A.
Exemplo: Um leitor pode fazer várias requisições, mas uma requisição só pode ser feita por um leitor, quer isto dizer que entre a tabela Leitor e a tabela Requisições existe uma relação do tipo 1 para n.
A chave principal é adicionada ao lado que tem n, transformando-se assim numa chave estrangeira.
3. N para M (em que N e M significam vários)
Uma relação do tipo n para m, é uma relação de vários para vários, ou seja, entre duas tabelas A e B, a várias ocorrências da tabela A podem corresponder várias ocorrências da tabela B, e vice-versa.
Exemplo: Uma moeda pode ser emitida durante vários anos, mas um ano pode emitir várias moedas, quer isto dizer que entre a tabela Moeda e a tabela Ano existe uma relação do tipo n para m.
Para toda e qualquer relação do tipo n para m, há que decompor a relação em duas do tipo 1 para n, ou seja, irá ser necessário criar uma nova tabela, com o nome que o “criador” do modelo entidade-relação bem entender, onde a mesma irá conter as chaves principais das tabelas envolvidas, chaves estas que se irão tornar numa chave composta da nova tabela.
Decomposição final:
Exemplo pratico: Aplicação para gestão de stocks de consumíveis de impressoras
Para o exemplo seguinte irá ser utilizada a ferramenta de desenvolvimento access, pois para além de bastante conhecida, é também bastante utilizada e é na minha opinião ideal para dar os primeiros passos no desenvolvimento e estruturação de uma base de dados.
Como se poderá constatar a aplicação poderá ser “melhorada”, mas por motivos de simplificação, irão ser só utilizados os “requisitos mínimos” para dar início ao desenvolvimento da aplicação, ficando ao critério de cada um como proceder de acordo com as suas necessidades.
A primeira coisa a fazer antes de criar as tabelas, é definir o conjunto de elementos e respectivos atributos para os quais interessa guardar informação, que após o devido tratamento e organização da mesma e já com os critérios das relações devidamente aplicados é:
- Stock (Id_Stock, Referência, Descrição, Quantidade armazenada, Data de actualização)
- A Entidade Stock diz respeito aos produtos em armazém, irá também servir para registar novas entradas e saídas de produtos.
- Saidas (Id_Requisição, Id_Departamento, Id_Stock, Data_Saida, Descrição, Quantidade, Impressora, Recebimento)
- A Entidade Saidas serve para registar as requisições de consumíveis, que á posteriori irá servir como base para alterar/registar saídas de produtos da tabela Stock.
- Departamento (Id_Departamento, Departamento);
- Guias_Remessa (Id_Guia, Nr_Guia, Total, Data_Entrada);
- Linhas Guias Remessa (Id_Linha, Id_Guia, Id_Produto, Referência, Descrição, Quantidade);
Após a conclusão do levantamento da informação necessária, pode-se então passar ao segundo passo que implica a criação das tabelas.
Tabela Departamentos
Como se pode verificar o tipo de dados do campo Id_Departamento está como numeração automática, mas também poderia estar só como número, a diferença entre um e outro é que no tipo numeração automática, não é necessário estar constantemente a preencher o campo Id, enquanto que com o tipo número tem que se ir preenchendo o mesmo.
O campo Departamento está como texto, pois irá só servir para guardar o nome dos departamentos existentes.
Tabela Stock
Como já foi referido anteriormente, a tabela stock irá servir para guardar os registos dos produtos em armazém, onde o campo Referência serve para guardar a referência do produto por exemplo “HP43”, e o campo Descrição serve para registar neste exemplo “tinteiro”.
O campo quantidade irá servir para guardar a informação relativa á quantidade de produtos existentes em armazém, sendo também alterado de acordo com as entradas e saídas de produtos.
O campo Data Actualização serve para registar quando foi a última vez que a tabela Stock foi alterada, seja pela entrada e saída de novos produtos, seja por inventário.
Tabela Saídas
Como também já foi referido anteriormente, a tabela Saídas, serve para registar as requisições ou saídas de consumíveis para os vários departamentos. Tal como o nome indica o campo Data_Saida, serve para registar a data em que foi feita a requisição/ou a data em que um funcionário do departamento “requisitante” foi levantar o consumível, ficando o seu nome no campo Recebimento.
O campo Id_Stock serve para identificar a informação relativa ao consumível requisitado, enquanto que o campo Descrição serve para registar a referência e o tipo de produto requisitado.
O campo Impressora para além de servir para identificar o tipo de consumível caso o funcionário requisitante não o saiba identificar, serve também para se saber quantas e quais são as impressoras existentes por departamento.
Tabela Guias Remessa
Tal como está explicito a tabela Guias Remessa, serve para guardar o número da guia recebida, o valor a pagar (Total), e a data em que a guia foi recebida.
Tabela Linhas Guias Remessa
A tabela Linhas Guias Remessa serve para guardar os detalhes das guias de remessa recebidas.
Após a conclusão da criação das tabelas, dá-se então inicio á criação das relações entre as mesmas.
Relacionamento entre Tabelas
Como se pode verificar o esquema final de um modelo entidade relação deverá ser algo deste género, dependendo do tipo de base de dados a ser desenvolvida, e do número de tabelas que a mesma tiver.
Uma vez que os tipos de relações já foram referidos anteriormente, resta só referir uma breve explicação do raciocínio utilizado para a criação deste modelo:
- Um departamento pode fazer várias requisições, mas uma requisição só diz respeito a um departamento, logo é uma relação do tipo 1 para n;
- Um produto em stock pode ser requisitado várias vezes, mas para uma requisição só pode corresponder um produto, logo é uma relação do tipo 1 para n;
- Entre Guias Remessa e Stocks existia uma relação do tipo n para m, ou seja, uma guia de remessa pode incluir vários produtos, e um produto pode corresponder a várias guias, logo criou-se a tabela Linha Guias Remessa para decompor a relação em duas do tipo 1 para n, ou seja, uma guia de remessa pode ter várias linhas de remessa, e um produto em stock pode ser abastecido por várias linhas de remessa.
Espero que este artigo seja uma mais valia tanto para a comunidade, como para qualquer outro visitante, e que possa contribuir para ajudar a resolver toda, e qualquer possível e eventual dúvida que possa surgir.