Guia da Modelagem de Dados: 5 passos para criação do modelo conceitual (parte 2)
Será demonstrado neste artigo como se faz o reconhecimento de relacionamentos entre entidades por meio do ambiente de uma pizzaria fictícia.
Este artigo é parte de uma série de artigos que trata da modelagem de bancos de dados para o desenvolvimento de aplicações. É fortemente recomendada a leitura dos textos anteriores antes de prosseguir:
Contexto
Foram identificadas por meio dos passos anteriores as seguintes entidades com os respectivos atributos:
- Cliente (nome, e-mail, telefone, telefone alternativo e endereço);
- Pedido (valor total, forma de pagamento, observação, data e hora);
- Produto (nome e preço); e
- ProdutoEstocavel (nome, preço, quantidade no estoque, peso, unidade de medida e data de vencimento).
Permanecem desconhecidos os relacionamentos (assunto de hoje!) e as suas devidas cardinalidades e condicionalidades.
Passo #3: mapeie os relacionamentos
A pergunta da vez é: quais eventos ou fenômenos significativos ocorrem entre as instâncias das entidades listadas por nós?
Podemos descobrí-los ao imaginar o tipo de atendimento geralmente realizado pelas pizzarias, por exemplo:
— Boa noite, é da pizzaria xyz?
— Boa noite. É sim!
— Ah tá, é que eu gostaria de fazer um pedido.
— Qual seu nome?
— Joana D’Arc.
— Telefone pra contato?
— +33 08 2033–2424.
— Ok. Pois não?
— Eu quero duas pizzas de muçarela e uma Pepsi de 2 L.
— Para qual endereço?
— É na rua ABC, casa número 123 na Vila Rochosa.
— Deu R$ 65. Precisa de troco?
— Troco pra R$ 100, por favor.
— Certo. Vai levar 40 minutos, tá?
— Tudo bem.
— Seu pedido já está sendo feito.
— Ok. Obrigada! 😁
Perceberam uma interação logo no início da conversa envolvendo duas entidades? Vamos pensar um pouco: a cliente ligou pra pizzaria para fazer um pedido. Já sabemos que Cliente e Pedido são entidades nossas, mas a novidade está na ação de fazer um pedido: é um evento significativo entre elas, portanto, é um relacionamento!
São expostos pela nossa cliente os produtos que deseja logo após a solicitação de seus dados pessoais. Analisemos: o que a pessoa atendente faz depois de ouví-los? Ela inclui os produtos como itens do pedido, não é? É nesse momento que é efetivada outra relação — entre as entidades Pedido e Produto do nosso modelo!
É recomendável definir um verbo e formar uma sentença com as entidades afim de formalizar qualquer relacionamento que apareça na nossa frente. Optemos pelo simples, “Cliente faz Pedido” e “Pedido inclui Produto”.
De boa, né? 😙
Lembram-se do artigo passado quando foi dito que existiam dois tipos de produtos nessa pizzaria? Produto e ProdutoEstocavel são entidades que possuem atributos em comum e, para quem está começando, um fato não é nada óbvio: existe um relacionamento entre elas por causa disso. 😱
Quando atributos repetem-se em mais de uma entidade, deve ser criada uma super-entidade genérica que reúna todos eles para que outras entidades sejam capazes de herdar esses atributos através de um relacionamento especial chamado “e” (leia-se “é”).
Produto é a super-entidade de ProdutoEstocavel, em nosso caso, e compartilham os atributos “Nome” e “Preco” por meio de uma relação “Produto e ProdutoEstocavel”!
Estes, enfim, foram os relacionamentos mapeados por nós:
- “Cliente faz Pedido”;
- “Pedido inclui Produto”; e
- “Produto e ProdutoEstocavel”.
Vale lembrar: não é porque o relacionamento significa “e” que obrigatoriamente toda instância da entidade x é uma instância da entidade y. Seu uso expressa a possibilidade de ser. Passa mais sensação de certeza na hora da modelagem uma relação escrita “e” do que uma “pode ser”, entretanto.
Belezinha? ✌️
