The only way we can capture those extra in-context attributes is by designing for a junction object. To reiterate, this would be like the ingredient butter always having an amount of “2 tablespoons,” regardless of the recipe. Notice that the amount metadata is under INGREDIENT here, implying that the field value will be unchanged wherever you see that INGREDIENT instance across the platform. The objects are mentioned at the top of each column in the blue “sticky notes”, and their attributes are below in yellow and pink with their nested objects in blue. Here’s what a starter object map would look like for our Culinary Training app. Feel free to read those last couple sentences again!) Sometimes, if you are lucky, it’s 2 cups. That leaves our metadata value static for the INGREDIENT instance throughout the system, and butter is not always 2 tablespoons. What if we want specific amount metadata on our INGREDIENT depending on which RECIPE it’s nested within? We can’t just plop the amount metadata under INGREDIENT and call it a day. In this example:Īnd an INGREDIENT has many RECIPES (hundreds?). Let’s take a meal-delivery service that teaches cooking. I would even estimate that, more often than not, the relationship between any two given objects is a many-to-many.Īn ORDER has many PRODUCTS being ordered.īut what if we want extra attributes applied to an object while it’s in the context of another object? Let’s look at an example where designing for a junction object untangles that complexity.
#Sparkbox power how to#
Before we get into how to incorporate junction objects into an object map, we need to step away from colorful sticky notes and talk about databases.ĭuring the R of the ORCA process (relationships!), we OOUXers create more many-to-many relationships than we’d like to admit.
Object mapping is the heart of OOUX a foundational knowledge of OOUX will help you understand junction objects.
0 kommentar(er)
