Level 1 Model Building - Design

Star · 2020-03-19T16:45:07+00:00

Hi In the Level 1 Model for Unicorn, Size was defined as a List and the Products file imported shows a 1-to-1 relationship for Product -> Size. Product CodeProduct NameFamily CodeSizeP001Nutzo BarCH100gP002Raising the BarCH200gP015AnapoppersSO500gP016Juicy Lucy gummiesSO100g Assuming, the Product -> Size is a 1-to-many…

Star

In the Level 1 Model for Unicorn, Size was defined as a List and the Products file imported shows a 1-to-1 relationship for Product -> Size.

Product Code	Product Name	Family Code	Size
P001	Nutzo Bar	CH	100g
P002	Raising the Bar	CH	200g
P015	Anapoppers	SO	500g
P016	Juicy Lucy gummies	SO	100g

Assuming, the Product -> Size is a 1-to-many relationship, what would be the guidance in terms of the design and setting?

E.g. Above items having more than one size.

Accepted answers

Misbah

@Star

Assuming you have one to many relationship for Products to Size, there can be two cases

Case 1- If your codes differ for each Product Name

Then You will have to make this as a numbered list and you can work on this list based on the codes

Case 2 - Names & codes are same

Then You will have to think of coming up with the unique code for each combination.

You can also think of creating a hierarchy based on the Size & Products

You can also ponder on reversing the list meaning Keep Size as a list and add Product Codes and Names as a attributes

All this depends on what is your final objective and you design accordingly.

Hope that helps

Misbah

JaredDolich

Hi @Star

I would concur with @Misbah when it comes to deciding if your list should be numbered or regular.

I would add a few more thoughts though.

If EVERY product shared the exact same size list then normally you would not set the "parent" value for size. Just keep size as an independent list. You would be right in that assumption. For L1, however, you're asked to create the Parent / Child relationship.
The biggest advantage of creating a list with a parent is the ability to aggregate the data. You can also use selective access to restrict what list items people can see / work with.
If the product and size are 1:1 for ALL combinations then I would suggest using size as a property in a system module. There's really no advantage in creating a list.
If the product and size are mostly 1:1 and only a small number have one to many you can denormalize the product list: Chocolate Bar - 300g and Chocolate Bar - 250g for example. This would also assume you don't want/need an aggregation.

All comments

Misbah

@Star

Assuming you have one to many relationship for Products to Size, there can be two cases

Case 1- If your codes differ for each Product Name

Then You will have to make this as a numbered list and you can work on this list based on the codes

Case 2 - Names & codes are same

Then You will have to think of coming up with the unique code for each combination.

You can also think of creating a hierarchy based on the Size & Products

You can also ponder on reversing the list meaning Keep Size as a list and add Product Codes and Names as a attributes

All this depends on what is your final objective and you design accordingly.

Hope that helps

Misbah

Star

@Misbah
Thank you.

In Level 1 Model Building, Size is defined as a List (non-numbered) but the Products shared the same Size List. Not sure what is the advantage here.
In a practical situation, my simple thought is that the design should be according to your suggestons in Case 1 or 2 above depending on the assumptions. Any thoughts?

JaredDolich

Hi @Star

I would concur with @Misbah when it comes to deciding if your list should be numbered or regular.

I would add a few more thoughts though.

If EVERY product shared the exact same size list then normally you would not set the "parent" value for size. Just keep size as an independent list. You would be right in that assumption. For L1, however, you're asked to create the Parent / Child relationship.
The biggest advantage of creating a list with a parent is the ability to aggregate the data. You can also use selective access to restrict what list items people can see / work with.
If the product and size are 1:1 for ALL combinations then I would suggest using size as a property in a system module. There's really no advantage in creating a list.
If the product and size are mostly 1:1 and only a small number have one to many you can denormalize the product list: Chocolate Bar - 300g and Chocolate Bar - 250g for example. This would also assume you don't want/need an aggregation.

Quick Links

Can you help?

Unanswered questions

Introducing Anaplan API Python SDK
Hey everyone, I wanted to share the Anaplan Python SDK with you. It's a Python Library that wraps all Anaplan APIs and makes it easier to interact with Anaplan programmatically. It is mostly designed with Data Integration Scenarios in mind, but it does support all APIs including ALM, SCIM, Audit, and Cloud Works. Please…
Batch Script
Hello team, I am logging into Anaplan through SSO. I would like to create a batch script to import a file into Anaplan. For the Spoke model, I would like to run an process via a batch script to import data from the Data Hub. Can anyone provide me script for both the condition.
Cloudworks Big Query Integration Fail
Hello, I am receiving an 'Anaplan Upload Failed' Status Description when testing my integration with a Big Query dataset. The integration imports data from BQ to our Anaplan model. No other details given in the error log. I suspect that Cloudworks is not even picking up the file but am not sure what we did wrong on the set…