Desenhe as relações
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 sustenta-se 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. É nas relações que mora boa parte do significado. Um Parceiro retalhista opera centros de distribuição. Um manifesto lista entregas. Uma entrega vai para um Destinatário. Uma equipa opera um camião. Cada uma destas frases diz-me algo sobre o negócio, e cada uma me dá mais uma pergunta a 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 a perguntar se isto deve ser uma relação de pesquisa ou mestre-detalhe, a pensar em objetos de junção do Salesforce (Salesforce Junction Objects), nem a decidir o que acontece quando um registo pai é eliminado. Estou a tentar entender a relação de negócio.
Pegue em «um Parceiro retalhista opera centros de distribuição». Parece simples. Mas um Parceiro retalhista pode ter um CD ou muitos? Na Steve Trucking, cada Parceiro retalhista opera um centro de distribuição regional em cada região que a Steve Trucking serve, portanto muitos. Um CD pode pertencer a mais do que um Parceiro retalhista? Um CD importa por si só, com a sua própria equipa e histórico, ou é só uma morada? Se um Parceiro retalhista se vai embora, ainda nos importamos com os seus CD?
Estas 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 a fundo, quero dar-lhe a linguagem que vamos usar em todos os diagramas 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 estes dois substantivos estão relacionados, só ainda não perguntei como. Depois as pontas ganham marcas. Uma barra a cruzar a linha significa um. O pé de galinha (crow’s foot), a ponta que se abre em três como a pata de um pássaro, significa muitos. Mais adiante neste módulo vai ver aparecer uma segunda marca ao lado da primeira, uma barra ou um círculo, e essa responde a outra pergunta: pode não haver nenhum?
A única regra a lembrar: cada marca lê-se na caixa em que toca. A marca mais perto da caixa é o máximo que pode haver; a marca seguinte, para fora, é o mínimo.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”Antes da Steve Trucking, de volta aos cães do módulo 1. Tínhamos cinco caixas: Dono, Criador, Cão, Raça e Truque. Agora pergunto sobre as linhas entre elas.
Um ou muitos? Um dono pode ter mais do que um cão; a Ana tem dois. Um cão tem um dono, pelo menos no nosso modelo. Isso é um-para-muitos: uma barra no Dono, um pé de galinha no Cão. O criador tem a mesma forma: um criador cria muitos cães.
Pode não haver nenhum? O Max veio do canil municipal, por isso não tem criador nenhum. A ponta do Criador ganha um círculo: um cão tem zero ou um criador. Mas todos os cães têm um dono, por isso essa ponta ganha uma segunda barra: exatamente um.
Muitos-para-muitos? Um cão sabe muitos truques, e um truque, digamos Senta, é conhecido por muitos cães. Isso é muitos-para-muitos, e é exatamente aí que vou procurar um conceito escondido. Há alguma coisa sobre este cão saber este truque? Quão bem o faz, e quando o aprendeu. A relação tem factos próprios, por isso torna-se uma coisa própria: o Truque do cão (em inglês, Dog Trick, com o nome do cão primeiro, porque é o cão que o conduz).
O que significa cada linha? Um dono é dono de um cão. Um criador cria o cão. Um cão sabe os seus truques. Dê nome às linhas, e qualquer pessoa consegue ler-lhe o modelo de volta.
Agora, ou ao longo do tempo? Alguém se importa com quão boa a Bella é no Senta hoje, ou com a forma como lá chegou? Se um treinador a avalia de poucos em poucos meses, cada avaliação é um registo 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 cão a que pertence. Até uma relação que se tornou coisa pode ter histórico próprio.
A Raça, deixo-a sem ligação por agora. Ainda é a pergunta do módulo 1, uma caixa própria ou uma palavra no cão, e o módulo 4 resolve isso.
Cada uma destas perguntas funciona da mesma maneira num negócio a sério. 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 uma relação é a sua cardinalidade. É o termo de bases de dados; a pergunta é bem mais simples: quantos destes se podem relacionar com quantos daqueles? No nível conceitual há três padrões básicos.
Este é um passo importante do processo: pegar em dois substantivos diferentes e entender a relação entre eles. Na maioria das situações é um-para-muitos, ou muitos-para-um. Só em raras circunstâncias vai encontrar um um-para-um.
Um-para-muitos está em todo o lado. Um Parceiro retalhista tem muitos centros de distribuição. Um manifesto lista muitas entregas. Uma rota tem umas dez paragens. Quando ouço linguagem assim, começo a desenhar a linha.
E agora a linha ganha as suas marcas. Cada ponta diz quantos da caixa em que toca: a barra para um, o pé de galinha para muitos. Leia a partir de cada caixa: um Parceiro retalhista tem muitos Centros de distribuição.
As relações um-para-um existem, mas são raras, e quando encontro uma faço algumas perguntas. São mesmo dois substantivos diferentes, ou o mesmo? Se são diferentes, qual é a relação um-para-um entre eles? E vai ser sempre um-para-um, ou só um-para-um agora? Estas são perguntas-chave no design do modelo de dados. Uma equipa e um camião parecem um-para-um em qualquer manhã: duas pessoas, um camião, uma rota. Ao longo de um mês não são, e é aí que se esconde a relação mais interessante deste modelo.
As relações muitos-para-muitos são especialmente interessantes, porque muitas vezes nos dizem que há outro conceito no negócio. Uma equipa pode conduzir mais do que um camião ao longo do tempo? Sim. Um camião pode ser conduzido por mais do que uma equipa? Ao longo da sua vida, com certeza. Então equipas e camiões têm uma relação muitos-para-muitos. Mas agora quero saber mais. O negócio importa-se com quando uma equipa teve um camião? Para que rota, em que dia? Quem fez a atribuição? Se a própria relação carrega informação que nos importa, descobrimos outro conceito de negócio: a Atribuição de equipa (Crew Assignment).
Este é um hábito de modelação importante. Às vezes a coisa mais interessante não é um dos substantivos que ouvimos no início. Está escondida na relação entre dois substantivos.
As relações podem tornar-se coisas
Seção intitulada “As relações podem tornar-se coisas ”Este é um dos lugares em que quero que os administradores comecem a pensar de forma diferente. No Salesforce estamos habituados a falar de objetos e campos, por isso é fácil tratar as caixas como a parte importante e as linhas como canalização. Mas a própria relação pode ter significado de negócio.
Considere uma entrega e os produtos que leva. Uma entrega pode levar vários produtos, uma máquina de lavar e uma máquina de secar, digamos. Um produto, o mesmo modelo de frigorífico, aparece em milhares de entregas. Até aqui, fácil. Mas e se eu precisar de saber quantas unidades daquele produto estão nesta entrega, se vai ser instalado, ou se o antigo vai ser recolhido? Já não me interessa só uma relação entre Entrega e Produto. Interessa-me um Item de entrega (Delivery Item), e esse conceito merece uma entidade própria.
Se vem do Salesforce, talvez já esteja a pensar: «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 estas entidades de relação, onde quer que acabem por ser construídas.
Dê-lhe um nome. Se o negócio já tem uma palavra para isso, use a dele. Se não tem, pegue nos nomes dos dois pais e junte-os. Pense numa encomenda e num produto. A coisa entre eles é o Order Item (item da encomenda): a encomenda, e o item na encomenda. É filho dos dois pais, e no Salesforce pode acabar como um objeto de junção do Salesforce. Mas, em inglês, que nome vem primeiro: Item Order ou Order Item? Veja que tipo de dado é cada pai. O produto é dado de referência; a encomenda é transacional, e é a encomenda que conduz. Por isso é Order Item, ou Order Product, tal como 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 registo fica ordenado ao lado do seu dono em todas as listas que alguma vez for ver.
Dê-lhe a sua própria chave. É tentador dizer que um Item de entrega é identificado por Entrega mais Produto e ficar por aí. Isso é uma chave composta, e as chaves compostas são muito mais difíceis de gerir: cada sistema que aponta para o registo precisa de carregar as duas metades. Dê à entidade de relação o seu próprio identificador, e mantenha Entrega mais Produto como uma regra de unicidade, não como a identidade.
Repare no que lá não está: um número de série. Uma quantidade e um número de série não pertencem ao mesmo registo. 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 passa a ser um registo próprio, e cinco frigoríficos são cinco registos. Não vejo razão para um Item de entrega com um Detalhe do item de entrega por baixo. É um ou outro: um agregado com quantidade, ou um registo por unidade. Aqui, é a quantidade.
Esteja atento aos atributos que querem histórico. Algumas entidades de relação ficam resolvidas assim que são criadas: a máquina de lavar nesta entrega continua a ser a máquina de lavar nesta entrega. Outras continuam a mudar. Uma equipa está com o camião 117 esta semana, e na próxima semana o camião vai para outra equipa. Quando a relação muda e o negócio se importa com o que ela era, a entidade de relação precisa de datas, e a Atribuição de equipa é 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.
As relações têm significado para além da cardinalidade
Seção intitulada “As relações têm significado para além da cardinalidade ”«Um-para-muitos» não basta para entender uma relação. Também quero saber o que a relação significa.
Uma entrega tem um local. Qual? O centro de distribuição de onde sai? A casa do Destinatário para onde vai? 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 o meu diagrama a outro arquiteto, ele não deveria ter de adivinhar o que uma relação significa, e se o estou a mostrar ao negócio, 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?»: a relação é obrigatória? Uma entrega pode existir antes de ser posta numa rota? Tem de poder: 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 retalhista? Não; cada entrega vem do manifesto de um parceiro. Isso é opcionalidade.
Mais uma vez, não salte diretamente para uma caixa de verificação Obrigatório do Salesforce. Há uma diferença entre dizer «cada entrega tem de ter um Parceiro retalhista» e dizer «o Salesforce deve exigir o campo Parceiro retalhista quando o registo for criado». Podem acabar por ser 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 a aplicar. 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 marca seguinte, para fora, é o mínimo: outra barra significa pelo menos um, um círculo significa que pode ser zero. Então cada Entrega está em exatamente um Manifesto, e um Manifesto lista uma ou muitas Entregas. Uma Entrega está em zero ou uma Paragem, nenhuma até ter rota, e uma Paragem deixa zero ou muitas Entregas.
O tempo muda as relações
Seção intitulada “O tempo muda as relações ”Eis uma pergunta que faço muitas vezes: quer dizer agora, ou ao longo do tempo?
Uma equipa opera um camião. Agora? Para a rota de hoje? Enquanto estas duas pessoas trabalharem juntas? Isso produz modelos diferentes. Se o negócio só se importa com o camião que uma equipa tem hoje, o modelo pode continuar simples. Se precisa de todos os camiões que uma equipa conduziu, quando e em que rota, precisamos de histórico, e aquela Atribuição de equipa que descobrimos de repente importa muito.
Esta é uma fonte comum de erros de modelação. Modelamos o estado atual porque é o que conseguimos ver no ecrã. Depois, semanas mais tarde, um Parceiro retalhista apresenta uma reclamação por danos e alguém pergunta: «Que equipa estava com o camião 117 a 17 de março?» E descobrimos que andávamos a sobrescrever a resposta sempre que a atribuição mudava.
Uma forma de guardar esse histórico é fazer da atribuição um registo próprio. Quando uma equipa é atribuída, criamos uma Atribuição de equipa com uma data de início. Quando a atribuição muda, pomos uma data de fim no registo antigo e criamos um novo com a sua própria data de início. Agora «quem tinha esta atribuição há seis meses?» é uma pergunta simples de responder, em vez de uma escavação no histórico de campos ou num registo de alterações de dados. E, depois de uma equipa ter tido muitas atribuições, alguém vai perguntar qual é a atual, por isso eu acrescentaria também um indicador Ativo.
Por isso, quando alguém me fala de uma relação, não pergunto só como as coisas se relacionam. Pergunto: esta relação muda, e importamo-nos com o seu histórico?
Desenhe antes de configurar
Seção intitulada “Desenhe antes de configurar ”O nosso modelo da Steve Trucking está a ficar útil. Sabemos que relações são um-para-muitos, onde um muitos-para-muitos esconde outro conceito, que relações são opcionais e quais mudam ao longo do tempo. E ainda não criámos nenhum objeto Salesforce. Isso é intencional.
Este diagrama deveria ser algo que posso pôr diante do negócio, e as pessoas não deveriam precisar de conhecer o Salesforce para me dizer se está certo. Se não o conseguem validar porque está cheio de terminologia do Salesforce, entrei depressa demais no design físico.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Quando trabalho as relações num modelo conceitual, estou a decidir:
- Como as principais entidades de negócio se relacionam entre si.
- Se cada relação é um-para-um, um-para-muitos ou muitos-para-muitos, agora e ao longo do tempo.
- Se cada relação é obrigatória ou opcional.
- Se uma relação muitos-para-muitos esconde um conceito de negócio com significado.
- Se a relação muda ao longo do tempo, e se precisamos do seu histórico.
Relação de pesquisa ou mestre-detalhe, configuração de junção, comportamento em cascata e partilha são decisões físicas; vamos lá chegar. Agora ainda estamos a responder à pergunta mais importante: como funciona realmente este negócio? Depois de entender as entidades e as relações entre elas, podemos começar a acrescentar os pormenores que as descrevem. É aí que o nosso modelo conceitual começa a tornar-se um modelo de dados lógico.