Desenhe os relacionamentos
Também em 28 idiomas
English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 2 de 6 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Ouça os substantivos · Próximo: Construa o modelo lógico
A pergunta que este módulo responde: Como transformo possíveis entidades num modelo de dados conceitual?
Temos substantivos no quadro. Agora quero saber das linhas entre as caixas, porque um conjunto de entidades ainda não é bem um modelo de dados. É nos relacionamentos que mora boa parte do significado. Um Parceiro varejista opera centros de distribuição. Um manifesto lista entregas. Uma entrega vai para um Destinatário. Uma equipe opera um caminhão. Cada uma dessas frases me diz algo sobre o negócio, e cada uma me dá mais uma pergunta para fazer.
Comece pela linguagem do negócio
Seção intitulada “Comece pela linguagem do negócio ”Ainda não quero falar de Salesforce. Não estou perguntando se isto deve ser um relacionamento de pesquisa ou mestre-detalhes, pensando em objetos de junção do Salesforce (Salesforce Junction Objects), nem decidindo o que acontece quando um registro pai é excluído. Estou tentando entender o relacionamento de negócio.
Pegue “um Parceiro varejista opera centros de distribuição”. Parece simples. Mas um Parceiro varejista pode ter um CD ou muitos? Na Steve Trucking, cada Parceiro varejista opera um centro de distribuição regional em cada região que a Steve Trucking atende, então muitos. Um CD pode pertencer a mais de um Parceiro varejista? Um CD importa por si só, com sua própria equipe e histórico, ou é só um endereço? Se um Parceiro varejista vai embora, ainda nos importamos com os CDs dele?
Essas não são perguntas sobre o Salesforce. São perguntas de negócio, e as respostas podem mudar completamente o modelo.
Leia as linhas
Seção intitulada “Leia as linhas ”Antes de ir mais fundo, quero lhe dar a linguagem que vamos usar em todo diagrama daqui em diante. É uma linguagem pequena. Uma linha entre duas caixas diz que as duas coisas estão relacionadas, e as marcas nas pontas dizem quantas.
Comece com uma linha simples, sem marca nenhuma. É por aí que começo no quadro branco: sei que esses dois substantivos estão relacionados, só ainda não perguntei como. Depois as pontas ganham marcas. Uma barra cruzando a linha significa um. O pé de galinha (crow’s foot), a ponta que se abre em três como o pé de um pássaro, significa muitos. Mais adiante neste módulo você vai ver uma segunda marca aparecer ao lado da primeira, uma barra ou um círculo, e essa responde a outra pergunta: pode não haver nenhum?
A única regra para lembrar: você lê cada marca na caixa que ela toca. A marca mais perto da caixa é o máximo que pode haver; a próxima marca para fora é o mínimo.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”Antes da Steve Trucking, de volta aos cachorros do módulo 1. Tínhamos cinco caixas: Dono, Criador, Cachorro, Raça e Truque. Agora pergunto sobre as linhas entre elas.
Um ou muitos? Um dono pode ter mais de um cachorro; a Ana tem dois. Um cachorro tem um dono, pelo menos no nosso modelo. Isso é um-para-muitos: uma barra no Dono, um pé de galinha no Cachorro. O criador tem a mesma forma: um criador cria muitos cachorros.
Pode não haver nenhum? O Max veio do canil municipal, então não tem criador nenhum. A ponta do Criador ganha um círculo: um cachorro tem zero ou um criador. Mas todo cachorro tem um dono, então essa ponta ganha uma segunda barra: exatamente um.
Muitos-para-muitos? Um cachorro sabe muitos truques, e um truque, digamos Senta, é conhecido por muitos cachorros. Isso é muitos-para-muitos, e é exatamente aí que vou procurar um conceito escondido. Há alguma coisa sobre este cachorro saber este truque? O quão bem ele o faz, e quando o aprendeu. O relacionamento tem fatos próprios, então vira uma coisa própria: o Truque do cachorro (em inglês, Dog Trick, com o nome do cachorro primeiro, porque é o cachorro que o conduz).
O que cada linha significa? Um dono é dono de um cachorro. Um criador cria o cachorro. Um cachorro sabe seus truques. Dê nome às linhas, e qualquer pessoa consegue ler o modelo de volta para você.
Agora, ou ao longo do tempo? Alguém se importa com o quão boa a Bella é no Senta hoje, ou com como ela chegou lá? Se um adestrador a avalia a cada poucos meses, cada avaliação é um registro próprio: uma Avaliação do truque (Trick Assessment), com a data, o nível de habilidade e quem fez a avaliação, abaixo do Truque do cachorro a que pertence. Até um relacionamento que virou coisa pode ter histórico próprio.
A Raça eu deixo sem ligação por enquanto. Ela ainda é a pergunta do módulo 1, uma caixa própria ou uma palavra no cachorro, e o módulo 4 resolve isso.
Cada uma dessas perguntas funciona do mesmo jeito num negócio de verdade. Agora vamos fazê-las à Steve Trucking.
Pergunte “um ou muitos?”
Seção intitulada “Pergunte “um ou muitos?” ”Uma das primeiras coisas que quero entender sobre um relacionamento é sua cardinalidade. Esse é o termo de banco de dados; a pergunta é bem mais simples: quantos destes podem se relacionar com quantos daqueles? No nível conceitual há três padrões básicos.
Este é um passo importante do processo: pegar dois substantivos diferentes e entender o relacionamento entre eles. Na maioria das situações é um-para-muitos, ou muitos-para-um. Só em raras circunstâncias você vai encontrar um um-para-um.
Um-para-muitos está em toda parte. Um Parceiro varejista tem muitos centros de distribuição. Um manifesto lista muitas entregas. Uma rota tem umas dez paradas. Quando ouço linguagem assim, começo a desenhar a linha.
E agora a linha ganha suas marcas. Cada ponta diz quantos da caixa que ela toca: a barra para um, o pé de galinha para muitos. Leia a partir de cada caixa: um Parceiro varejista tem muitos Centros de distribuição.
Relacionamentos um-para-um existem, mas são raros, e quando encontro um faço algumas perguntas. São mesmo dois substantivos diferentes, ou o mesmo? Se são diferentes, qual é o relacionamento um-para-um entre eles? E ele vai ser sempre um-para-um, ou só um-para-um agora? Essas são perguntas-chave no design do modelo de dados. Uma equipe e um caminhão parecem um-para-um em qualquer manhã: duas pessoas, um caminhão, uma rota. Ao longo de um mês não são, e é aí que se esconde o relacionamento mais interessante deste modelo.
Relacionamentos muitos-para-muitos são especialmente interessantes, porque muitas vezes nos dizem que há outro conceito no negócio. Uma equipe pode dirigir mais de um caminhão ao longo do tempo? Sim. Um caminhão pode ser dirigido por mais de uma equipe? Ao longo da vida dele, com certeza. Então equipes e caminhões têm um relacionamento muitos-para-muitos. Mas agora quero saber mais. O negócio se importa com quando uma equipe teve um caminhão? Para qual rota, em qual dia? Quem fez a atribuição? Se o próprio relacionamento carrega informação que nos importa, descobrimos outro conceito de negócio: a Atribuição de equipe (Crew Assignment).
Esse é um hábito de modelagem importante. Às vezes a coisa mais interessante não é um dos substantivos que ouvimos no início. Ela está escondida no relacionamento entre dois substantivos.
Relacionamentos podem virar coisas
Seção intitulada “Relacionamentos podem virar coisas ”Este é um dos lugares em que quero que os administradores comecem a pensar diferente. No Salesforce estamos acostumados a falar de objetos e campos, então é fácil tratar as caixas como a parte importante e as linhas como encanamento. Mas o próprio relacionamento pode ter significado de negócio.
Considere uma entrega e os produtos nela. Uma entrega pode levar vários produtos, uma lavadora e uma secadora, digamos. Um produto, o mesmo modelo de geladeira, aparece em milhares de entregas. Até aqui, fácil. Mas e se eu precisar saber quantas unidades daquele produto estão nesta entrega, se ele vai ser instalado, ou se o antigo vai ser recolhido? Não me interessa mais só um relacionamento entre Entrega e Produto. Me interessa um Item de entrega (Delivery Item), e esse conceito merece uma entidade própria.
Se você vem do Salesforce, talvez já esteja pensando: “Isso é um objeto de junção.” Não está errado. Mas não quero começar por aí. Um Item de entrega é um conceito de negócio antes de ser um objeto de junção do Salesforce (Salesforce Junction Object). Primeiro o negócio, depois a implementação.
Alguns hábitos meus para essas entidades de relacionamento, onde quer que acabem sendo construídas.
Dê um nome. Se o negócio já tem uma palavra para isso, use a dele. Se não tem, pegue os nomes dos dois pais e junte-os. Pense num pedido e num produto. A coisa entre eles é o Order Item (item do pedido): o pedido, e o item no pedido. É filho dos dois pais, e no Salesforce pode acabar como um objeto de junção do Salesforce. Mas, em inglês, qual nome vem primeiro: Item Order ou Order Item? Olhe que tipo de dado é cada pai. O produto é dado de referência; o pedido é transacional, e é o pedido que conduz. Então é Order Item, ou Order Product, do mesmo jeito que o Salesforce tem Opportunity Product (produto da oportunidade). Na Steve Trucking é o Delivery Item (Item de entrega). O nome que conduz vem primeiro, e o registro fica ordenado ao lado do seu dono em toda lista que você for olhar.
Dê a ele sua própria chave. É tentador dizer que um Item de entrega é identificado por Entrega mais Produto e parar por aí. Isso é uma chave composta, e chaves compostas são muito mais difíceis de lidar: todo sistema que aponta para o registro precisa carregar as duas metades. Dê à entidade de relacionamento seu próprio identificador, e mantenha Entrega mais Produto como uma regra de unicidade, não como a identidade.
Repare no que não está nele: um número de série. Uma quantidade e um número de série não pertencem ao mesmo registro. Uma quantidade conta várias unidades de uma coisa; um número de série identifica uma coisa específica. Se o negócio precisa de números de série, cada unidade vira um registro próprio, e cinco geladeiras são cinco registros. Não vejo caso para um Item de entrega com um Detalhe do item de entrega embaixo. É um ou outro: um agregado com quantidade, ou um registro por unidade. Aqui, é a quantidade.
Fique de olho nos atributos que querem histórico. Algumas entidades de relacionamento ficam resolvidas assim que são criadas: a lavadora nesta entrega continua sendo a lavadora nesta entrega. Outras continuam mudando. Uma equipe está com o caminhão 117 esta semana, e na semana que vem o caminhão vai para outra equipe. Quando o relacionamento muda e o negócio se importa com o que ele era, a entidade de relacionamento precisa de datas, e a Atribuição de equipe é a que merece atenção. Pergunte cedo se o negócio se importa com o agora ou com o ao longo do tempo; vamos voltar a isso daqui a pouco.
Relacionamentos têm significado além da cardinalidade
Seção intitulada “Relacionamentos têm significado além da cardinalidade ”“Um-para-muitos” não basta para entender um relacionamento. Também quero saber o que o relacionamento significa.
Uma entrega tem um local. Qual? O centro de distribuição de onde ela sai? A casa do Destinatário para onde ela vai? Eles não são intercambiáveis. Dois modelos podem ter exatamente as mesmas caixas e a mesma cardinalidade, e as linhas podem significar coisas completamente diferentes. É por isso que um bom modelo não é só caixas ligadas por linhas. As linhas precisam de nomes. Se entrego meu diagrama a outro arquiteto, ele não deveria precisar adivinhar o que um relacionamento significa, e se o estou mostrando ao negócio, ele deve usar uma linguagem que as pessoas reconheçam.
A opcionalidade também importa
Seção intitulada “A opcionalidade também importa ”Há outra pergunta escondida dentro de “quantos?”: o relacionamento é obrigatório? Uma entrega pode existir antes de ser colocada numa rota? Precisa: o manifesto chega um ou dois dias antes da entrega, e as rotas são fechadas na noite anterior. Uma entrega pode existir sem um Parceiro varejista? Não; toda entrega vem do manifesto de um parceiro. Isso é opcionalidade.
De novo, não pule direto para uma caixa de seleção Obrigatório do Salesforce. Há uma diferença entre dizer “toda entrega precisa ter um Parceiro varejista” e dizer “o Salesforce deve exigir o campo Parceiro varejista quando o registro for criado”. Podem acabar sendo a mesma implementação, mas não são a mesma afirmação. A primeira é uma regra de negócio; a segunda é uma forma de aplicá-la. Como arquitetos, queremos entender a primeira antes de decidir a segunda.
No diagrama, a opcionalidade é a segunda marca em cada ponta. A marca mais perto da caixa é o máximo que pode haver: a barra para um, o pé de galinha para muitos. A próxima marca para fora é o mínimo: outra barra significa pelo menos um, um círculo significa que pode ser zero. Então toda Entrega está em exatamente um Manifesto, e um Manifesto lista uma ou muitas Entregas. Uma Entrega está em zero ou uma Parada, nenhuma até ser roteirizada, e uma Parada deixa zero ou muitas Entregas.
O tempo muda os relacionamentos
Seção intitulada “O tempo muda os relacionamentos ”Eis uma pergunta que faço muito: você quer dizer agora, ou ao longo do tempo?
Uma equipe opera um caminhão. Agora? Para a rota de hoje? Enquanto essas duas pessoas trabalharem juntas? Isso produz modelos diferentes. Se o negócio só se importa com qual caminhão uma equipe tem hoje, o modelo pode continuar simples. Se ele precisa de todo caminhão que uma equipe dirigiu, quando e em qual rota, precisamos de histórico, e aquela Atribuição de equipe que descobrimos de repente importa muito.
Essa é uma fonte comum de erros de modelagem. Modelamos o estado atual porque é o que conseguimos ver na tela. Aí, semanas depois, um Parceiro varejista abre uma reclamação de avaria e alguém pergunta: “Qual equipe estava com o caminhão 117 em 17 de março?” E descobrimos que vínhamos sobrescrevendo a resposta toda vez que a atribuição mudava.
Uma forma de guardar esse histórico é fazer da atribuição um registro próprio. Quando uma equipe é atribuída, criamos uma Atribuição de equipe com uma data de início. Quando a atribuição muda, colocamos uma data de fim no registro antigo e criamos um novo com sua própria data de início. Agora “quem tinha essa atribuição seis meses atrás?” é uma pergunta simples de responder, em vez de uma escavação no histórico de campos ou num log de alterações de dados. E, depois que uma equipe teve muitas atribuições, alguém vai perguntar qual é a atual, então eu acrescentaria também um sinalizador Ativo.
Então, quando alguém me fala de um relacionamento, não pergunto só como as coisas se relacionam. Pergunto: esse relacionamento muda, e nos importamos com o histórico dele?
Desenhe antes de configurar
Seção intitulada “Desenhe antes de configurar ”Nosso modelo da Steve Trucking está ficando útil. Sabemos quais relacionamentos são um-para-muitos, onde um muitos-para-muitos esconde outro conceito, quais relacionamentos são opcionais e quais mudam ao longo do tempo. E ainda não criamos nenhum objeto Salesforce. Isso é intencional.
Este diagrama deveria ser algo que posso colocar diante do negócio, e as pessoas não deveriam precisar conhecer o Salesforce para me dizer se está certo. Se não conseguem validá-lo porque está cheio de terminologia do Salesforce, entrei rápido demais no design físico.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Quando trabalho os relacionamentos num modelo conceitual, estou decidindo:
- Como as principais entidades de negócio se relacionam entre si.
- Se cada relacionamento é um-para-um, um-para-muitos ou muitos-para-muitos, agora e ao longo do tempo.
- Se cada relacionamento é obrigatório ou opcional.
- Se um relacionamento muitos-para-muitos esconde um conceito de negócio com significado.
- Se o relacionamento muda ao longo do tempo, e se precisamos do histórico dele.
Relacionamento de pesquisa ou mestre-detalhes, configuração de junção, comportamento em cascata e compartilhamento são decisões físicas; vamos chegar lá. Agora ainda estamos respondendo à pergunta mais importante: como este negócio realmente funciona? Depois de entender as entidades e os relacionamentos entre elas, podemos começar a acrescentar os detalhes que as descrevem. É aí que nosso modelo conceitual começa a se tornar um modelo de dados lógico.