Dibuja las relaciones
También en 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)
Módulo 2 de 6 del capítulo Modelar los datos con sentido, capítulo 2 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Escucha los sustantivos · Siguiente: Construye el modelo lógico
La pregunta que responde este módulo: ¿Cómo convierto las entidades candidatas en un modelo de datos conceptual?
Tenemos sustantivos en el pizarrón. Ahora quiero saber de las líneas entre las cajas, porque una colección de entidades todavía no es realmente un modelo de datos. En las relaciones vive gran parte del significado. Un socio minorista opera centros de distribución. Un manifiesto enumera entregas. Una entrega va a un destinatario. Un equipo maneja un camión. Cada una de esas afirmaciones me dice algo sobre el negocio, y cada una me da otra pregunta que hacer.
Empieza con el lenguaje del negocio
Sección titulada «Empieza con el lenguaje del negocio »Todavía no quiero hablar de Salesforce. No estoy preguntando si esto debería ser una relación de búsqueda o principal-detalle, ni pensando en objetos de unión de Salesforce (Salesforce Junction Objects), ni decidiendo qué pasa cuando se elimina un registro principal. Intento entender la relación de negocio.
Toma “un socio minorista opera centros de distribución”. Suena simple. Pero ¿un socio minorista puede tener un centro de distribución o muchos? En Steve Trucking, cada socio minorista opera un centro de distribución regional en cada región que atiende Steve Trucking, así que muchos. ¿Un centro de distribución puede pertenecer a más de un socio minorista? ¿Un centro de distribución importa por sí mismo, con su propio personal e historial, o es solo una dirección? Si un socio minorista se va, ¿nos siguen importando sus centros de distribución?
No son preguntas de Salesforce. Son preguntas de negocio, y las respuestas pueden cambiar por completo el modelo.
Lee las líneas
Sección titulada «Lee las líneas »Antes de profundizar, quiero darte el lenguaje que usaremos en cada diagrama de aquí en adelante. Es pequeño. Una línea entre dos cajas dice que las dos cosas están relacionadas, y las marcas en sus extremos dicen cuántos.
Empieza con una línea simple, sin ninguna marca. Así empiezo yo en el pizarrón: sé que estos dos sustantivos están relacionados, solo que todavía no he preguntado cómo. Luego los extremos reciben marcas. Una sola barra que atraviesa la línea, la cruz, significa uno. La pata de gallo, el extremo que se abre en tres como la pata de un ave, significa muchos. Más adelante en este módulo verás aparecer una segunda marca junto a la primera, una barra o un círculo, y esa responde otra pregunta: ¿puede no haber ninguno?
La única regla que hay que recordar: cada marca se lee en la caja que toca. La marca más cercana a la caja es el máximo que puede haber; la siguiente hacia afuera es el mínimo.
Sentado, quieto, modelo
Sección titulada «Sentado, quieto, modelo »Antes de Steve Trucking, volvamos a los perros del módulo 1. Teníamos cinco cajas: Dueño, Criador, Perro, Raza y Truco. Ahora pregunto por las líneas entre ellas.
¿Uno o muchos? Un dueño puede tener más de un perro; Ana tiene dos. Un perro tiene un dueño, al menos en nuestro modelo. Eso es de uno a muchos: una barra en el Dueño, una pata de gallo en el Perro. El criador tiene la misma forma: un criador cría muchos perros.
¿Puede no haber ninguno? Max salió de la perrera, así que no tiene criador. El extremo del Criador lleva un círculo: un perro tiene cero o un criador. Pero todo perro tiene dueño, así que ese extremo lleva una segunda barra: exactamente uno.
¿Muchos a muchos? Un perro sabe muchos trucos, y un truco, digamos Sentado, lo saben muchos perros. Eso es de muchos a muchos, y ahí es exactamente donde voy a buscar un concepto escondido. ¿Hay algo sobre que este perro sepa este truco? Qué tan bien lo hace y cuándo lo aprendió. La relación tiene hechos propios, así que se convierte en una cosa propia: el Truco del perro (Dog Trick, con el perro primero en el nombre en inglés), porque es el perro el que lo impulsa.
¿Qué significa cada línea? Un dueño es dueño de un perro. Un criador lo cría. Un perro sabe sus trucos. Ponles nombre a las líneas y cualquiera puede leerte el modelo de vuelta.
¿Ahora, o a lo largo del tiempo? ¿A alguien le importa qué tan bien hace Bella Sentado hoy, o cómo llegó ahí? Si un entrenador la evalúa cada pocos meses, cada evaluación es un registro propio: una Evaluación del truco (Trick Assessment), con la fecha, el nivel de habilidad y quién hizo la evaluación, debajo del Truco del perro al que pertenece. Incluso una relación que se convirtió en cosa puede tener su propio historial.
La Raza la dejo sin conectar por ahora. Sigue siendo la pregunta del módulo 1, una caja propia o una palabra sobre el perro, y el módulo 4 la resuelve.
Cada una de esas preguntas funciona igual en un negocio real. Ahora hagámoselas a Steve Trucking.
Pregunta “¿uno o muchos?”
Sección titulada «Pregunta “¿uno o muchos?” »Una de las primeras cosas que quiero entender de una relación es su cardinalidad. Ese es el término de bases de datos; la pregunta es mucho más simple: ¿cuántos de estos pueden relacionarse con cuántos de aquellos? A nivel conceptual hay tres patrones básicos.
Este es un paso importante del proceso: tomar dos sustantivos distintos y entender su relación. En la mayoría de las situaciones es de uno a muchos, o de muchos a uno. Solo en circunstancias excepcionales te toparás con una de uno a uno.
Las relaciones de uno a muchos están en todas partes. Un socio minorista tiene muchos centros de distribución. Un manifiesto enumera muchas entregas. Una ruta tiene unas diez paradas. Cuando escucho un lenguaje así, empiezo a dibujar la línea.
Y ahora la línea recibe sus marcas. Cada extremo te dice cuántos hay de la caja que toca: la barra para uno, la pata de gallo para muchos. Léela desde cada caja: un socio minorista tiene muchos centros de distribución.
Las relaciones de uno a uno existen, pero son raras, y cuando encuentro una hago algunas preguntas. ¿Son de verdad dos sustantivos distintos, o el mismo? Si son distintos, ¿cuál es la relación de uno a uno entre ellos? ¿Y será siempre de uno a uno, o solo de uno a uno ahora mismo? Son preguntas clave para diseñar el modelo de datos. Un equipo y un camión parecen de uno a uno cualquier mañana: dos personas, un camión, una ruta. A lo largo de un mes no lo son, y ahí se esconde la relación más interesante de este modelo.
Las relaciones de muchos a muchos son especialmente interesantes, porque a menudo nos dicen que hay otro concepto en el negocio. ¿Un equipo puede manejar más de un camión con el tiempo? Sí. ¿Un camión puede ser manejado por más de un equipo? A lo largo de su vida, sin duda. Así que equipos y camiones tienen una relación de muchos a muchos. Pero ahora quiero saber más. ¿Le importa al negocio cuándo tuvo un equipo un camión? ¿Para qué ruta, qué día? ¿Quién hizo la asignación? Si la relación en sí lleva información que nos importa, hemos descubierto otro concepto de negocio: la Asignación de equipo (Crew Assignment).
Es un hábito de modelado importante. A veces lo más interesante no es uno de los sustantivos que oímos al principio. Se esconde en la relación entre dos sustantivos.
Las relaciones pueden convertirse en cosas
Sección titulada «Las relaciones pueden convertirse en cosas »Este es uno de los lugares donde quiero que los administradores empiecen a pensar distinto. En Salesforce estamos acostumbrados a hablar de objetos y campos, así que es fácil tratar las cajas como la parte importante y las líneas como fontanería. Pero la relación en sí puede tener significado de negocio.
Piensa en una entrega y los productos que lleva. Una entrega puede llevar varios productos, una lavadora y una secadora, por ejemplo. Un producto, el mismo modelo de refrigerador, aparece en miles de entregas. Hasta ahí, fácil. Pero ¿y si necesito saber cuántas unidades de ese producto van en esta entrega, si se va a instalar o si se retira el aparato viejo? Ya no me interesa solo una relación entre Entrega y Producto. Me interesa un Artículo de entrega (Delivery Item), y ese concepto merece una entidad propia.
Si vienes de Salesforce, quizá ya estés pensando: “Eso es un objeto de unión”. No te equivocas. Pero no quiero empezar por ahí. Un Artículo de entrega es un concepto de negocio antes de ser un objeto de unión de Salesforce (Salesforce Junction Object). Primero el negocio, después la implementación.
Algunos hábitos míos para estas entidades de relación, se terminen construyendo donde se terminen construyendo.
Ponle nombre. Si el negocio ya tiene una palabra para ello, usa la suya. Si no la tiene, toma los nombres de los dos padres y júntalos. Piensa en un pedido y un producto. Lo que hay entre ellos es el Artículo de pedido (Order Item): el pedido, y el artículo en el pedido. Es hijo de ambos padres, y en Salesforce puede terminar siendo un objeto de unión de Salesforce. Pero ¿qué nombre va primero? En inglés la duda es entre “Item Order” y “Order Item”. Fíjate en qué tipo de datos es cada padre. El producto son datos de referencia; el pedido es transaccional, y es el pedido el que lo impulsa. Así que es Order Item, u Order Product, igual que Salesforce tiene Opportunity Product (producto de oportunidad). En Steve Trucking es el Artículo de entrega (Delivery Item). El nombre que impulsa va primero, y el registro se ordena junto a su dueño en cualquier lista que vayas a mirar.
Dale su propia clave. Es tentador decir que un Artículo de entrega se identifica por Entrega más Producto y quedarse ahí. Eso es una clave compuesta, y las claves compuestas son mucho más difíciles de manejar: cada sistema que apunta al registro tiene que llevar las dos mitades. Dale a la entidad de relación su propio identificador, y deja Entrega más Producto como una regla de unicidad, no como su identidad.
Fíjate en lo que no aparece: un número de serie. Una cantidad y un número de serie no pertenecen al mismo registro. Una cantidad cuenta varias unidades de algo; un número de serie identifica una cosa concreta. Si el negocio necesita números de serie, cada unidad se convierte en su propio registro, y cinco refrigeradores son cinco registros. No veo un caso para un Artículo de entrega con un Detalle de artículo de entrega debajo. Es una cosa o la otra: un agregado con una cantidad, o un registro por unidad. Aquí, es la cantidad.
Vigila los atributos que piden historial. Algunas entidades de relación quedan fijas una vez creadas: la lavadora de esta entrega sigue siendo la lavadora de esta entrega. Otras no dejan de cambiar. Un equipo tiene el camión 117 esta semana, y la semana que viene el camión pasa a otro equipo. Cuando la relación cambia y al negocio le importa lo que fue, la entidad de relación necesita fechas, y la Asignación de equipo es la que hay que vigilar. Pregunta pronto si al negocio le importa el ahora o a lo largo del tiempo; volveremos a ello en un momento.
Las relaciones tienen un significado más allá de la cardinalidad
Sección titulada «Las relaciones tienen un significado más allá de la cardinalidad »“De uno a muchos” no basta para entender una relación. También quiero saber qué significa la relación.
Una entrega tiene una ubicación. ¿Cuál? ¿El centro de distribución del que sale? ¿La casa del destinatario a la que va? No son intercambiables. Dos modelos pueden tener exactamente las mismas cajas y la misma cardinalidad, y las líneas pueden significar cosas completamente distintas. Por eso un buen modelo no son solo cajas unidas por líneas. Las líneas necesitan nombres. Si le paso mi diagrama a otro arquitecto, no debería tener que adivinar qué significa una relación, y si se lo muestro al negocio, debería usar un lenguaje que reconozca.
La opcionalidad también importa
Sección titulada «La opcionalidad también importa »Hay otra pregunta escondida dentro de “¿cuántos?”: ¿la relación es obligatoria? ¿Puede existir una entrega antes de que se le asigne una ruta? Tiene que poder: el manifiesto llega uno o dos días antes de la entrega, y las rutas se cierran la tarde anterior. ¿Puede existir una entrega sin un socio minorista? No; cada entrega viene del manifiesto de un socio. Eso es la opcionalidad.
Otra vez, no saltes directamente a la casilla Obligatorio de Salesforce. Hay una diferencia entre decir “cada entrega debe tener un socio minorista” y decir “Salesforce debería exigir el campo Socio minorista cuando se crea el registro”. Pueden acabar siendo la misma implementación, pero no son la misma afirmación. La primera es una regla de negocio; la segunda es una forma de hacerla cumplir. Como arquitectos, queremos entender la primera antes de decidir la segunda.
En el diagrama, la opcionalidad es la segunda marca en cada extremo. La marca más cercana a la caja es el máximo que puede haber: la barra para uno, la pata de gallo para muchos. La siguiente hacia afuera es el mínimo: otra barra significa al menos uno, un círculo significa que puede ser cero. Así que cada entrega está exactamente en un manifiesto, y un manifiesto enumera una o muchas entregas. Una entrega está en cero o una parada, en ninguna hasta que se le asigna una ruta, y una parada deja cero o muchas entregas.
El tiempo cambia las relaciones
Sección titulada «El tiempo cambia las relaciones »Esta es una pregunta que hago mucho: ¿te refieres a ahora o a lo largo del tiempo?
Un equipo maneja un camión. ¿Ahora mismo? ¿Para la ruta de hoy? ¿Mientras esas dos personas trabajen juntas? Producen modelos distintos. Si al negocio solo le importa qué camión tiene hoy un equipo, el modelo puede quedarse simple. Si necesita cada camión que manejó un equipo, cuándo y en qué ruta, necesitamos historial, y esa Asignación de equipo que descubrimos de pronto importa mucho.
Esta es una fuente habitual de errores de modelado. Modelamos el estado actual porque es lo que vemos en la pantalla. Luego, semanas después, un socio minorista presenta un reclamo por daños y alguien pregunta: “¿Qué equipo tenía el camión 117 el 17 de marzo?”. Y descubrimos que hemos estado sobrescribiendo la respuesta cada vez que cambiaba la asignación.
Una forma de conservar ese historial es hacer de la asignación un registro propio. Cuando se asigna un equipo, creamos una Asignación de equipo con una fecha de inicio. Cuando la asignación cambia, ponemos una fecha de fin en el registro antiguo y creamos uno nuevo con su propia fecha de inicio. Ahora “¿quién tenía esa asignación hace seis meses?” es una pregunta sencilla de responder, en lugar de escarbar en el historial de campos o en un registro de cambios de datos. Y una vez que un equipo ha tenido muchas asignaciones, alguien preguntará cuál es la actual, así que también agregaría un indicador Activa.
Así que cuando alguien me habla de una relación, no solo pregunto cómo se relacionan las cosas. Pregunto: ¿esa relación cambia, y nos importa su historial?
Dibuja antes de configurar
Sección titulada «Dibuja antes de configurar »Nuestro modelo de Steve Trucking se está volviendo útil. Sabemos qué relaciones son de uno a muchos, dónde una de muchos a muchos esconde otro concepto, qué relaciones son opcionales y cuáles cambian con el tiempo. Y todavía no hemos creado un objeto de Salesforce. Es intencional.
Este diagrama debería ser algo que pueda poner delante del negocio, y no deberían necesitar saber de Salesforce para decirme si está bien. Si no pueden validarlo porque está lleno de terminología de Salesforce, me he pasado demasiado rápido al diseño físico.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »Cuando trabajo las relaciones de un modelo conceptual, estoy decidiendo:
- Cómo se relacionan entre sí las principales entidades del negocio.
- Si cada relación es de uno a uno, de uno a muchos o de muchos a muchos, ahora y a lo largo del tiempo.
- Si cada relación es obligatoria u opcional.
- Si una relación de muchos a muchos esconde un concepto de negocio con sentido.
- Si la relación cambia con el tiempo, y si necesitamos su historial.
Búsqueda o principal-detalle, la configuración del objeto de unión, el comportamiento en cascada y el uso compartido son decisiones físicas; llegaremos a ellas. Ahora mismo seguimos respondiendo la pregunta más importante: ¿cómo funciona realmente este negocio? Una vez que entendemos las entidades y las relaciones entre ellas, podemos empezar a agregar los detalles que las describen. Ahí es cuando nuestro modelo conceptual empieza a convertirse en un modelo de datos lógico.