HOTSPOT - You need to create a relationship in the dataset for RLS. What should you do? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Hot Area:
Suggested Answer:
Box 1: many-to-many - Users in the sales department must be able to access only the data of the sales region to which they are assigned in the Sales Employees table. With composite models, you can establish a many-to-many relationship between tables, which removes requirements for unique values in tables. It also removes previous workarounds, such as introducing new tables only to establish relationships.
Box 2: Orders table - The Orders table has a ShipRegion column. Reference: https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-create-and-manage-relationships
Many-to-Many
Customer details
Sales employees should see the sales of their region only, so all sales ordered by customers whose billing address belongs to the sales employee's region.
Therefore, the relationship between sales employees (region) and customer details (region) should be many-to-many (a sales employee has many customers in his region and a customer in a region can have many sales employees for that region).
In this case, as the customer table is related to the order table, the sales employees will only be able to see the orders of the customers in their region.
I agree Many-to-Many, but where are we able to see that Order table is related to the Customer table? They do not have a shared data type between their ID columns, unless the pictures have a typo. For me it would be Order Details because I don't see where the relationship is declared between Customer Details (one) and Order Details (many).
The billing address is in the customer details, therefore, when assigning and working out commission etc for sales employees, the billing address in customer details will be counted not the shipping address which is in the orders table. Although the case study should have made it clear.
Many to many link with customer details worksheet
The billing address is in the customer details, therefore, when assigning and working out commission etc for sales employees, the billing address in customer details will be counted not the shipping address which is in the orders table. Although the case study should have made it clear.
Many to many link with customer details worksheet
Agreed as "Each employee in the Sales Employees table is assigned to one sales region. Multiple employees can be assigned to each region."
In a good operations and real life model, customers will be assigned to Sales employees ID for performance tracking and bonuses.
But we are not connecting to a region entity but to a customer entity. There'll be more than one customer in a region. There are also more than one sales employee assigned to one region.
So it should be many-to-many.
Agree with the answer given actually....In a star schema with Orders as the fact table, we would want to use Sales employees as the dimension to relate to the fact. We can use the Sales Employees(Region) and Orders(ShippingRegion) as the key for a many to many relationship. The tricky bit in these questions is the keys in the tables don't have the same name.
Passed with 917/1000
Question and answers were exactly the same but different order with the options!
Answer given:
- Many-to-Many
- Customer details worksheet
One to many
order table
Orders are made of order header one record per order. A given order can only have one sales employee. Otherwise, they will have duplicates. Realistically, we do have a One to many relationship between sales employee and orders table. The order table already has the customer. We don't need to associate customers to sales employee. By adding sales employee relationship to the order table, the report requirement is satisfied.
De uno a varios. Recordemos que es un filtro de seguridad. El empleado solo podra ver los datos de su región y de los clientes de su región, con sus pedidos y detalles de pedidos.
I don't agree with customer details.
If you are a customer from eg France and you order a product from the US, the customer detail page will make this sale visble for the sales department in France, breaking this rule:
Users in the sales department must be able to access only the data of the sales region to which they are assigned in the Sales Employees table.
Many to Many
Customer Details
For those who may have confused using one to many, think of it like this.
There are many sales people in a region
the same customer can buy from many sales people
but since there are multiple customers and they can do the same thing its many to many
I'm getting confused by this question. Can anyone explain to me how to make a relationship between customer details and Sales Employees? I don't see any common data type to make a relationship.
Many to many relationship between Sales employee and Orders table. And some more general question on the test case: How a sales employee is related to a particular order? Who has created that order? I assume all the orders should be created by a sales agent, right?!
One to Many
Customer Details
It doesn't make sense to me that an order could be placed by more than one sales person. So One-to-Many and not Many-to-Many.
I think many-to-many is right
Region in employee table is nullable.
So you can have a one-to-many relationship if one value of region is null
upvoted 4 times
...
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Fer079
Highly Voted 2 years, 2 months agoLucasCovey
1 year, 11 months agoBabaJee
1 year, 11 months agocharles879987
1 year, 11 months agoBabaJee
1 year, 11 months agoPinkZebra
2 years, 1 month agofdsdfgxcvbdsfhshfg
Highly Voted 2 years, 2 months agofred92
2 years, 1 month ago539d541
Most Recent 2 months, 1 week agoMoneyStacking
7 months agoAna_L
7 months, 2 weeks agoEnrique67
11 months, 1 week agoAldeus
11 months, 3 weeks agothomas_90
1 year, 2 months agoGrootPiemel
1 year, 2 months agoMEG_Florida
1 year, 4 months agoyooshua
1 year, 5 months agohalofrosty
1 year, 5 months agodarkfairy
1 year, 10 months agoHoeishetmogelijk
1 year, 12 months agoHoeishetmogelijk
1 year, 11 months agonmosq
1 year, 10 months agoBarb
2 years, 2 months ago