Banco de dados: diagrama ER + cardinalidade + universo de discurso
Quando você vai modelar seu sistema ou sua aplicação, uma das primeiras coisas que você precisa projetar é o seu banco de dados. E você pensa no número de tabelas que você precisará criar, nos atributos que cada uma terá. Mas, as tabelas, entre elas, se relacionam, conforme a necessidade do sistema e, para isso, existe a cardinalidade, que denomina o grau de relação que duas ou mais tabelas possam ter.
Existem três categorias de relacionamento mais utilizados atualmente:
- N:N (muitos para muitos);
- 1:N (um para muitos);
- 1:1 (um para um).
Para demonstrar os exemplos de cada relacionamento, irá ser utilizado um banco de dados de um pet shop, direcionado a venda de produtos de uso animal.
Relacionamento um para muitos
– Um cliente pode ter vários animais, mas os animais possuem somente um
dono, conforme relacionamento na tabela a seguir, com os atributos de cada uma.
Relacionamento muitos para muitos
Entre a tabela de produtos e vendas, há um relacionamento entre muitos para muitos entre a tabela produtos e vendas, pois, entre as mercadorias que um pet shop possui, caso o cliente compre muitas coisas (coleira, osso, brinquedos em geral) e solicite muitos serviços, o pet shop precisa armazenar mais coisas na compra do cliente. Para isso, é necessário criar “itens” para armazenar a sua quantidade e o valor total, além de terem o id da venda e dos produtos/serviços.
Ou seja, para essa categoria de relacionamento (muitos-para-muitos), há uma criação de uma nova tabela, no caso a tabela item, conforme mostrado nas tabelas a seguir, além dos atributos das mesmas, conforme foto a seguir.
Relacionamento um para um
Neste caso, um cliente possui um único endereço, assim como o endereço só pode pertencer a um único cliente, ou seja, esse caso se enquadra em um relacionamento um para um, conforme é mostrado na figura.
Os mais utilizados são esses tipos de cardinalidade, pois, existem outras além dessas.
Universo de discurso
Para finalizar este artigo, deixo algumas dicas de elaboração de um universo de discurso de um banco de dados, ou seja, uma espécie de documentação do seu banco de dados de forma escrita, sem tabelas. São elas:
- Começar descrevendo para qual domínio é o banco de dados (sorveteria, lanchonete, etc);
- Descreva os principais atributos que as tabelas principais do sistema possuem;
- Descreva as outras tabelas em sequência, como as mesmas funcionam;
- Por fim, fale as observações de cardinalidade que cada tabela possui uma com a outra.
Para o modelo acima, sobre pet shop, eis um modelo de universo de discurso feito para este fim:
Um pet shop deseja controlar as vendas de produtos e serviços que o mesmo oferece. Para isso, é necessário um cadastro do cliente e do seu respectivo animal. O cliente, para solicitar um serviço ou fazer uma compra, necessita de um código de identificação (fornecido pelo pet shop), seu nome, CPF, telefone e para o cadastro do seu animal, será necessário saber o código de controle do pet shop, o nome dele, a espécie, a raça, o peso e a data de nascimento.
Para comprar produtos ou solicitar um serviço, é necessário informar o nome, sua descrição, valor, fornecedor e tipo (produto ou serviço). Desse modo, o controle de vendas é feito através do código de barras do produto, da quantidade do produto ou serviço, da data da venda e o valor total a ser pago.
Entretanto, caso o cliente compre muitas coisas (coleira, osso, brinquedos em geral) e solicite muitos serviços, o pet shop precisa armazenar mais coisas na compra do cliente. Para isso, é necessário criar “itens” para armazenar a sua quantidade e o valor total, além de terem o id da venda e dos produtos/serviços.
Observações:
– Um cliente pode ter vários animais, mas os animais possuem somente um dono.
– Um cliente pode realizar várias compras, mas as vendas são feitas somente por um cliente.
– Um produto pode gerar vários itens, mas os itens são gerados por somente uma compra de produtos/serviços.
– Uma venda pode ter vários itens, mas um item só é realizado com somente uma venda por cliente.
