6. User & Data Driven Design
The data first is the process that works for us. We understand that Data is the most important part of the platform
and has the most risk associated to it, therefore we treat it with respect.
What data do you need? And Where?
User Story – The Journey – Wire Frames
Intelligence – Back end (Table / Entity side) – Power Automate
Theming / Look & Feel
Data
Before
pretty
Screens
Interaction Layer – App Type / Automation / Bot
Use Case – What is the problem we need to solve?
What’s the story?
Data Model - ERD
WHO (User Personas) will access the Data
Security Design
Interaction Layer – Screens/Pages /Process
Interaction Layer – Forms and Views (Galleries)
Intelligence – Front End (Power FX)
The Look & Feel, Theming and presentation is ultimately refined and groomed
at this point. The use of the custom components and controls in the app layer
will assist and aid this process.
Interviews and requirements gathering of what is needed by the business. Its
important to work with the people closest to the challenge.
Data is the next part of the process. If you understand the type of data that
needs to be stored and WHO will need access to this data, you can start
building your ERD and security model.
Design your security layers before your ERD. Security should inform your ERD.
You may need to work on these both together as they work hand in hand. You
should not retrofit security later.
Design your story. What is the journey for the user? Design Thinking
Often the journey of the user will dictate the application type. Leveraging
Dataverse, you have a choice between Model-Driven apps and Canvas apps.
This is an integral part of the process as it will ultimately define User
Experience and the more detailed Screens / Pages, forms and views required.
Predefined components should be leveraged to assist Look and feel where
possible.
The UX and base app are great but typically forms over data; the real
intelligence comes from the configuration of controls added to forms, views /
Galleries, buttons etc… How will the app behave?
Accessibility
7. Why do we data model?
Data is vial to solution development and is often a digital representation of the physical
world. We do not spend our lives as a flat structure and in fact there is ONLY 1 of you, 1 of
me. This type of approach maximises the use of a single point of data multiple times.
AN EXAMPLE :
9. What is Normalised data?
A normalized database is one that's structured to reduce redundancy and improve data
integrity. It follows the principles of database normalization, which involves decomposing
tables and eliminating functional dependencies to create a more efficient database design.
10. Why do we data model
Fantasy Fields Moonlit Grove Misty Unic orn, Herbivore, Misty A ura Ella
Fantasy Fields Cretac eous Cliffs Sky Pterodac tyl, Carnivore, Winged Sophia
Fantasy Fields Jungle Mirage Whisper V eloc iraptor, Carnivore, Intelligent Ethan
Mystic Haven V olc ano V iew Blaze T-Rex, Carnivore, Fire-Breathing (Modified) Jac k
Mystic Haven Northern Plains Boulder Tric eratops, Herbivore, Thic k Skin Emma
Mystic Haven V olc ano V iew Gator Spinosaurus, Carnivore, Long Snout Jac k
Mystic Haven Celestial Summit Glitter Unic orn, Herbivore, Glittering Hooves Sarah
Mystic Haven Celestial Summit Pegasus Unic orn, Herbivore, Feathered Wings Sarah
Mystic Haven Northern Plains Spike Tric eratops, Herbivore, Friendly Emma
Mystic Haven Celestial Summit Starbeam Unic orn, Herbivore, Iridesc ent Mane Sarah
Mystic Haven Celestial Summit Willow Unic orn, Herbivore, Willow-like Mane Sarah
MythoRealm Carnivore Cove A qua Ic hthyosaurus, Carnivore, A quatic Mike
MythoRealm Herbivore Heights Leaf Stegosaurus, Herbivore, Spiked Tail Kevin
MythoRealm Crystal Springs Moonshine Unic orn, Herbivore, Luminesc ent Horn Olivia
MythoRealm Carnivore Cove Rex T-Rex, Carnivore, A ggressive Mike
MythoRealm Crystal Springs Starlite Unic orn, Herbivore, Star-shaped Markings Olivia
MythoRealm Herbivore Heights Thunder Brac hiosaurus, Herbivore, Long Nec k Kevin
11. This means
Sanctuary Area Animal Characteristics Care T
aker
Fantasy Fields M oonlit Grov e Dazzle Unic orn, Herbiv ore, Rainbow T
ail Ella
Fantasy Fields Jungle M irage Fred Allosaurus, Carniv ore, S
harp Claw s Ethan
Fantasy Fields M oonlit Grov e M idnight Unic orn, Herbiv ore, Dark Fur Ella
Fantasy Fields M oonlit Grov e M isty Unic orn, Herbiv ore, M isty Aura Ella
Fantasy Fields Cretac eous Cliffs S
ky Pterodac tyl, Carniv ore, Winged S
ophia
Fantasy Fields Jungle M irage Whisper Veloc iraptor, Carniv ore, Intelligent Ethan
M ystic Hav en Volc ano View Blaze
T
-Rex, Carniv ore, Fire-Breathing
(M odified) Jac k
M ystic Hav en Northern Plains Boulder T
ric eratops, Herbiv ore, T
hic k S
kin Emma
M ystic Hav en Volc ano View Gator S
pinosaurus, Carniv ore, Long S
nout Jac k
M ystic Hav en Celestial S
ummit Glitter Unic orn, Herbiv ore, Glittering Hoov es S
arah
M ystic Hav en Celestial S
ummit Pegasus Unic orn, Herbiv ore, Feathered Wings S
arah
M ystic Hav en Northern Plains S
pike T
ric eratops, Herbiv ore, Friendly Emma
M ystic Hav en Celestial S
ummit S
tarbeam Unic orn, Herbiv ore, Iridesc ent M ane S
arah
M ystic Hav en Celestial S
ummit Willow Unic orn, Herbiv ore, Willow -like M ane S
arah
M ythoRealm Carniv ore Cov e Aqua Ic hthyosaurus, Carniv ore, Aquatic M ike
M ythoRealm Herbiv ore Heights Leaf S
tegosaurus, Herbiv ore, S
piked T
ail Kev in
M ythoRealm Crystal S
prings M oonshine Unic orn, Herbiv ore, Luminesc ent Horn Oliv ia
M ythoRealm Carniv ore Cov e Rex T
-Rex, Carniv ore, Aggressiv e M ike
M ythoRealm Crystal S
prings S
tarlite Unic orn, Herbiv ore, S
tar-shaped M arkings Oliv ia
M ythoRealm Herbiv ore Heights T
hunder Brac hiosaurus, Herbiv ore, Long Nec k Kev in
GETTING RID OF
REPEATING
GROUPS
ELIMINATING
REDUNDANCIES
12. Data modeling results – Micro
servicing Your Data
• Promote reuse of data
• Focus on capture once, re-use many
• Promote data accuracy
• Minimise the risk on data being inaccurate
• Drive hierarchical and more defined security.
• Layer security across a model and protect certain parts of your data.
16. Terminology
• Table: A structured set of data held in rows and columns.
• Columns: A vertical set of data within a table that holds a specific attribute.
• Rows: A horizontal set of data that represents a single record within a table.
Sanctuary Area Animal Characteristics Care Taker
Fantasy Fields M oonlit Grove Dazzle Unicorn, Herbivore, Rainbow Tail Ella
Fantasy Fields Jungle M irage Fred Allosaurus, Carnivore, Sharp Claw s Ethan
Fantasy Fields M oonlit Grove M idnight Unicorn, Herbivore, Dark Fur Ella
Fantasy Fields M oonlit Grove M isty Unicorn, Herbivore, M isty Aura Ella
Fantasy Fields Cretaceous Cliffs Sky Pterodactyl, Carnivore, Winged Sophia
Fantasy Fields Jungle M irage Whisper Velociraptor, Carnivore, Intelligent Ethan
M ystic Haven Volcano View Blaze T-Rex, Carnivore, Fire-Breathing (M odified) Jack
M ystic Haven Northern Plains Boulder Triceratops, Herbivore, Thick Skin Emma
M ystic Haven Volcano View Gator Spinosaurus, Carnivore, Long Snout Jack
M ystic Haven Celestial Summit Glitter Unicorn, Herbivore, Glittering Hooves Sarah
M ystic Haven Celestial Summit Pegasus Unicorn, Herbivore, Feathered Wings Sarah
M ystic Haven Northern Plains Spike Triceratops, Herbivore, Friendly Emma
M ystic Haven Celestial Summit Starbeam Unicorn, Herbivore, Iridescent M ane Sarah
M ystic Haven Celestial Summit Willow Unicorn, Herbivore, Willow -like M ane Sarah
M ythoRealm Carnivore Cove Aqua Ichthyosaurus, Carnivore, Aquatic M ike
M ythoRealm Herbivore Heights Leaf Stegosaurus, Herbivore, Spiked Tail Kevin
M ythoRealm Crystal Springs M oonshine Unicorn, Herbivore, Luminescent Horn Olivia
M ythoRealm Carnivore Cove Rex T-Rex, Carnivore, Aggressive M ike
M ythoRealm Crystal Springs Starlite Unicorn, Herbivore, Star-shaped M arkings Olivia
M ythoRealm Herbivore Heights Thunder Brachiosaurus, Herbivore, Long Neck Kevin
Table
Column
Row
17. Relationships
Dataverse Types:
• 1:N – 1 row from table A can be related to
multiple rows from table B
• N:1 – multiple rows from table A can be
related to 1 row from table B
• N:N – multiple rows from table A can be
related to multiple rows from table B
• Manual N:N – multiple rows from table A
can be related to multiple rows from table
B via a custom intersection table C.
A –1:N– C –N:1– B
1
1
1
N
1
1
1
N
N
N
N
N
N
N
1 1
N
N
N
N
1 1
N
N
N
N
18. Relationships
Types available in other relational DBs – means extra work in Dataverse
• 1:0-1 – 1 row from table A can be related to 0 or 1 row from table B
• 1:1 – 1 row from table A is related to 1 row from table B
• 1:N+ – 1 row from table A is related to 1 or more rows from table B
• N+:1 – 1 or more rows from table A are related to 1 row from table B
20. Referential integrity
• Restrict delete – aka Block killing of parents!
• Cascading delete – aka Kill the children along with the parent
Purpose: reduction of orphaned data.
Out of scope for this session:
• Restrict update
• Cascading update
21. Visualization of referential integrity
Table A
Table B
Table A
Table B
Table A
Table B
1
N
1
*
Table A
Table B
R
D
C
D
22.
23. IoDaU - Internet of Dinosaurs and
Unicorns
1. We love dinosaurs and unicorns! They are awesome!
2. Our goal is to create a sanctuary where we can look after Dinosaurs and Unicorns
together.
3. Unicorns are majestic creatures and require a lot of space to flounce about.
4. Dinosaurs are morons and pretty gross! (but are hilarious)
5. Carniverous dinosaurs absolutely CANNOT share flouncing areas (enclosures) with
unicorns. They will just eat them all and extinct the species.
6. Caretakers require a particular set of skills to look after each animal.
24. SO what do we know?
1. We need a table to store Animals
2. We will classify the animals in a single table.
3. A hierarchy of enclosures will be required in each sanctuary.
4. Animals will be assigned to enclosures.
5. Caretakers will be assigned to enclosures based on skills.
6. Animals will be assigned Characteristics
26. What do we know?
1. We need a table to store Animals
2. We will classify the animals in a single table.
3. A hierarchy of enclosures will be required in each sanctuary.
4. Animals will be assigned to enclosures.
5. Caretakers will be assigned to enclosures based on skills.
6. Animals will be assigned Characteristics
27. We need a table to store Animals
+ We will classify the animals in a single table.
28. A hierarchy of enclosures will be
required in each sanctuary.
29. A hierarchy of enclosures will be
required in each sanctuary.
42. Wrap-up and Summarise
• Data First!! Yes, you may make a pretty thing but Data is paramount to the success of
your solution.
• Think about your data! Can you microservice ANY of it? Can it be made “reusable”. The
power of Normalised data is a well thought out data model.
• Go and read about this! Get some more info! Study up! Data modeling is an art form:
Get started using Microsoft Dataverse - Training | Microsoft Learn
Data Modeling 101 - The Agile Data (AD) Method
Mandatory slide. Please ensure you refer to our sponsors –
“Without their sponsorship, the event couldn’t happen. Please check them out in the Expo Hall”.
Chris
Chris
Chris
Chris
Chris
(Repetition lf data)
Non-normalized Data with multiple repetitions
Chris
(Repetition lf data)
Non-normalized Data with multiple repetitions
Chris
Chris
Chris
Security Requirements – always push for simplification, but these can drive requirements onto the data model
User Experience – it’s easy to forget that as we add normalization and relationships we create new constructs users need to navigate to be successful
Data Location / Retention - Not all data is allowed to be stored, often times data from services can’t be cached, companies have internal policies that govern use of data, some data is protected by government laws and also has specific requirements for storage e.g. PII, credit card numbers etc.
Self Service Reporting – if it takes a data architect to navigate the data model, chances are many of the tools from Power BI and Export to Excel will be less valuable to the user. Most self service features of CDS allow navigation of one level of relationships
Existing systems (legacy or not) - data?
Existing systems - UX?
Multi-region, multi-lingual, multi-currency requirements?
Rebekka
Rebekka
Rebekka
Rebekka
Rebekka
Rebekka
Chris
Chris
Chris
Rebekka
Sanctuary
Zones (Carnivors & vegetarians)
Enclosures
Creatures
Care Taker
Skills
Let’s go over these items 1 by 1.
The first thing we see is that we need a table to store the animals.
Let’s add that table.
Next up: a table for Sanctuaries and a table for Enclosures.
They have to be a hierarchy. But what makes sense?
In general you would say a Sanctuary has multiple enclosures. And an enclosure belongs to a single sanctuary.
In other words, a 1:N relationship between the Sanctuary and Enclosure table.
Which means the Enclosure table should have a lookup field to the Sanctuary table.
Next up, we need a way to assign animals to enclosures.
An enclosure could contain multiple animals.
Ok, that works. But how would you deal with movements of animals if you model it like this?
You loose any historic data. What is another way of modelling this?
With an N:N relationship you’re able to relate multiple animals to an enclosure and an animal to multiple enclosures.
You’re able to at least show some historic data, but understanding which enclosure is the current one gets hard this way.
Instead, let’s introduce a custom intersection table, where we can not only register the relationship between an Animal and Enclosure. But also when the animal stayed in an enclosure. Allowing us to see historic data.
We modelled animals and enclosures. Lets have a look at the caretakers, because if we let the animals fend for themselves they might get extinct again.
First we need two more tables to store caretakers and skills.
If caretakers are assigned to enclosure based on skills, there has to be a relationship between these two tables.
But that’s not enough. There also should be a relationship between a certain enclosure and the skills needed to be a caretaker for the animals in that enclosure.
I modelled it using a N:N. If you are not interested in historic information and no additional attributes need to be added to the relationship definitions between the tables, this might work. I don’t think it’s needed in this case. But in real life think very carefully before you implement an N:N relationship. It has some benefits in Model Driven Apps, but is harder to use in Canvas Apps. And an N:N cannot be updated to a 1:N-N:1 relationship. Changing it at this stage is easy. Changing it when you have using the model in production for some time it gets hard.
We now have the relationship between the Skills table and Caretaker and Enclosure tables.
But there is no direct relationship between Caretaker and Enclosure. With the current model I can figure out who might be eligible to work at a certain enclosure, but I can’t register who is actually working there.
We can model this similarly to how the relationship between Animals and Enclosures is modelled. Adding a custom intersection table to relate caretaker and enclosure for a specific timespan. We would need some additional business logic to let the skills relationships work as a filter to select an eligible caretaker, but that goes beyond the topic of data modelling.
We have registered the skills for caretakers. Lets now have a look at the Animal characteristics.
First we obviously need a characteristics table. Now we need to tie this table into the model we have so far.
Adding a N:N relationship (remember the warning) between Animal and Characteristic.
This model is starting to look like something we can implement.
We only need to add the necessary attributes and maybe an additional relationship here and there.
Added:
A relationship between enclosure and characteristic, to understand what sort of animals can live in the enclosure.
A relationship between skill and characteristic, to understand what skill allows someone to take care of what sort of animal.
An option set for animal type (dinosaur, unicorn – singe or multi select depending on the table)
A bunch of attributes per table.
Any suggestions on improvements?
What would you have done differently?
Chris
Rebekka to lead
Make sure we run over Everything we just said! Fundamentals
Rules
Define the outcome with homework!
Links and Shiz
MANDATORY SLIDE – “Please use the QR code to provide session feedback.”