PL-200 · Question #333
Case Study 4 - Contoso Suites Background Contoso Suites is an animal shelter that specializes in finding homes for dogs that have been given up by their owners. The shelter can house up to 20 dogs. Th
This drag-and-drop question assesses the understanding of different Dataverse table types and their appropriate use cases based on provided business requirements.
Question
Exhibit
Explanation
This drag-and-drop question assesses the understanding of different Dataverse table types and their appropriate use cases based on provided business requirements.
Approach. The correct approach is to drag 'Standard' to 'Adopters' and 'Dogs', and 'Activity' to 'Exercise' and 'Feeding'.
- Adopters: Adopter information, conceptually representing individuals, is stored in a Contact table. Contacts are primary entities in Dataverse. Even if a custom 'Adopters' table is created, it would serve as a core data store for individuals, making 'Standard' the appropriate table type.
- Dogs: Dog information is stored in a 'Dog' table, which is a central entity storing attributes like breed, size, and weight. This represents a primary record for an animal, fitting the 'Standard' table type.
- Exercise: An 'Exercise' record would track an event or interaction (e.g., a dog was walked, when, for how long). Dataverse 'Activity' tables are designed for tracking such interactions, which can be completed, assigned, and shown on a timeline. Therefore, 'Activity' is the correct type.
- Feeding: The case study states 'The food type and amount are logged on each resident record.' This describes an event or action-a dog being fed. Similar to 'Exercise', this fits the definition of an 'Activity' table, which tracks interactions or events related to other entities. Thus, 'Activity' is the correct type.
The case study explicitly mentions 'All tables are stored in Dataverse and do not require rapid scaling,' which rules out 'Elastic' (for high-volume, rapid-scaling scenarios) and 'Virtual' (for external data sources).
Common mistakes.
-
common_mistake. Common mistakes include incorrectly assigning 'Elastic' or 'Virtual' to tables, or confusing 'Standard' with 'Activity'.
-
Elastic: Selecting 'Elastic' for any table is incorrect because the case study explicitly states that tables 'do not require rapid scaling'. Elastic tables are specifically designed for very high-volume, rapidly changing data that needs extreme scalability and might not require full relational features.
-
Virtual: Selecting 'Virtual' for any table is incorrect because the case study states 'All tables are stored in Dataverse'. Virtual tables are used to bring data from external sources into Dataverse without replicating it.
-
Standard for Exercise/Feeding: Assigning 'Standard' to 'Exercise' or 'Feeding' is incorrect because these tables track events or interactions (what happened, when) related to a dog's residency, rather than being core static entities themselves. Activity tables are purpose-built for this type of transactional, timeline-based data.
-
Activity for Adopters/Dogs: Assigning 'Activity' to 'Adopters' or 'Dogs' is incorrect because these are primary entities (people and animals), not events or interactions. They are typically the 'regarding' entities for activities, meaning activities are performed 'about' them.
Concept tested. Dataverse table types (Standard, Activity, Elastic, Virtual) and their appropriate use cases in a model-driven Power Apps application.
Topics
Community Discussion
No community discussion yet for this question.
