All Microsoft Power Platform PL-900 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the PL-900 Microsoft Power Platform Fundamentals practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

The Dataverse (Common Data Service)

1. 18. The Power Apps User Experience

In this video, In the next few videos, we're going to be looking at the dataverse, also known as the Common Data Service or CDs. In November 2020, Microsoft decided to change the name of the common data service, maybe to make it a bit more branded data verse. And it may be to reduce confusion with the Common Data Model, or CDM.

I'd say this because you may see around the internet lots of references to the CD's common data service, and you might be thinking, "What on earth is that?" Well, that's the database. It's exactly the same thing; just some of the terminology has changed. Now, in this video, I'd like to describe the PowerApps user experience with regard to the Common Data service. Well, we have installed a database and installed some sample data. So from here, we can create a new app that is just based on the data. So if I click on the Common Data Service, you will see that it automatically connects behind the scenes to this common data service. I can choose tables, and you can see that various tables have been populated.

So I'll select a context table and click Connect. So the user experience is fairly well connected; it's behind the scenes. And here's an example of this Power App. And as you can see, we have access to people's emails and so on, email addresses. It's all very fluid. The data is behind the scenes, and whenever we need to access it, it's just another source of data that we can use. So the Common Data Service is a database, which is in your environment online. But, as we will see as we progress through this course, it is much more than a passive database, a data holder. You can also add "business rules" that specify what type of data can be stored and how new records inferred can trigger new actions within the database or Power Automate.

So the Power Apps user experience is very much connected with the CDs. It is an integral part. You'll see it being used in Power Automate, and you'll see it being used in the model PowerApps. And because it is a common data service (to use its old name), one database can be used by many different apps and many different programs, and we can even use it with the appropriate security in the PowerBI desktop. So you might need some changes to be made in terms of security. But you can see that we can connect the data first, even through PowerBI desktop. So the Common Data Service, or the database, is a background database that you can use across multiple platforms.

2. 19. Tables

In this video, we're actually going to take a look at one of the tables inside the database. Now I'm saying table, but until November 2020 it wasn't called a table; it was called an entity. So part of this rebranding as "database of us" is, I think, to make some of these terminologies a bit easier. So a table is an entity. Again, I'm using both because you'll see them in a lot of blogs and other places online, and I won't be updating to new terminology.

I imagine it contains records and fields. So records are rows in the new terminology, and fields are columns. So again, you might as well see both. So an entity is akin to a table in a relational database. It can store millions of rows and be extended to four terabytes per instance. So if I click on one, for instance, the account, you can see that here are the columns, which used to be called fields, and you can see quite a lot of them.

We'll explore why there are all of these in a later video. And if you click on the data, you will see some sample roles, which used to be called records. Now there are four types of entities, or tables. There are the standards. So these are the base set of entities created, and if I look at a particular field, you can see I cannot delete any of these fields. The delete column is not enabled. I can certainly add columns, but I can't delete any columns or fields. Then we have some blank tables that are your custom tables. So if I open up one of them, you can see that we actually do have a huge number of columns here, but actually all of these are just the standard background columns.

The actual table is completely blank. So you can see that for every table, you get things like "modified by" or "modified on the organisational name." So this is the equivalent of a blank table. There's also a complex table. So this contains server-side business logic and requires a Dynamics 365 license; it may contain workflow; it may contain plugins; and then we've got restricted. So these again require a Dynamics 365 license. It stores data that's not normally used outside of Dynamics 365. It's internal to Dynamics 365; it maintains data in a specific way, and if you change it, then that could be really bad for Dynamics 365. So you've got "standard," which is a base set of entities, and "custom." So this is your blank table, except we know it's not really blank, complex, and restricted, all of which necessitate Dynamics 365 licenses. Now, if I were to create a new table and go into the mould settings, we can see that there are two different types of ownership for entities: organisation and user or team. So we have organization. If you have this at the organisation level, then when you are deciding who has access, you give access per user. The alternative is "user" or "team." And here we've got the choice. We can give it to people at the organisational level, so everybody in this company has access to this example, or we can give it to the business unit level.

Now, teams are organised in business units, so that's sort of the equivalent of a team level. So, perhaps we have marketing in the organisation and can provide it to everyone at the marketing unit level, but business units can also have child business units, which could be marketing. We have a subsidiary business unit within marketing, so we could be marketing in France and Germany. So I could give it to people in restricted access marketing and in marketing France, for instance, or I could say I want it for everybody who is in marketing or one of the child levels. So you can say, "I want it to be in one level," or "I want it to be in one level and all the levels below it," and then finally, we can give access per user. But this is slightly different because you'll only have access to the user's own records only.So just know that you can give ownership at the organisation level, then you can give access at the user level, or you can give ownership at the user or team level, and then you've got a range of ways you can give access.

Now, do bear in mind that this is not changeable once you have curated the entity; it cannot be changed later. So it is very important to think about who you want to have access to the data in the table and, therefore, who you want to have ownership of. Now just one more thing, I was talking about security. Someone may have read access at one level, while another person has read/write access and yet another has no read access. So there are three different permissions, let's say, and I'm just listing these just for the sake of argument: read, read, write, and noreread, and somebody's got all three because somebody's in a business unit, somebody's own records, and somebody else has them at an organisational level. How did these conflict? Is it the most restrictive, or is it the most liberal?

And it's the most liberal. So if somebody has a read-only computer, they are able to read the records. If someone has no read and read rights, they can read and write the record. Security is cumulative across the database environment. So entities are a logical set of records used to store data. They contain rows and columns, which used to be called records and fields. As a result, they are fond of tables in a relationship database, and they can store millions of items, up to four terabytes per instance.

3. 19, 23. Columns and Relationships, and describing people, places, things

In this video, I just want to take a step back and look at the concept of entities. To begin with, they have rows and columns, or records and fields in order terminology. So a field is a discrete piece of information about a record. It's got a specific data type, and the number of fields in an entity is variable, so it can be over 100 if necessary. So you can see some of the different types of data type. We have text selection, multiline text, floating numbers, phone numbers, time zones, and probably close to a hundred or more in this single default table.

Now, tables can be connected to each other. For example, suppose I had a contact table and I wanted to link it with a phone call. Well, I could have such a relationship. So if I click on the relationships tab, you can see that currently we have got default relationships, and there are three different types of relationships. Really? This is also listed, but it's three heremany to one, onetomany, and many to many. So what's this all about? Well, let's take this example. I'm currently in the contacts table, or entity. So let's talk about the contacts table and the phone table or entity. So we have a contact who can make a phone call. Now, can you only make one phone call? Hopefully not. He'll be making multiple phone calls, maybe even on the same day. Now, at the moment, there is no relationship between these two entities or tables, but we can create one. So if I insert an arrow here, we can now see that they are joined together.

But how are they joined together? So we made contact. Let's call this contact John. He is making a phone call. As a result, he makes three phone calls: one call, two calls, and three calls. So therefore, we have one contact making multiple phone calls. So therefore, we have a one-to-many relationship. We'd be looking for a mini-relationship if we started on the phone and then made contact. So you can see that they're in the same sort of relationship. It just depends on where you start. I'm in the contact table. So if I was creating a new relationship with the phone table and there was a phone call, then I would be having one too many relationships. And you can see that the database does a lot of the work for you. We don't need to go into the specifics of how it works; all you need to know is that there is a one-to-many relationship. But I've got another question for you. Is it possible for there to be a conference call?

So, for instance, maybe phone number four involves John and Mary. So now we have one phone call with multiple contacts, and maybe they make another phone call and another phone call. They jointly make a phone call on a conference call. So now we don't have a one-to-many relationship if that's the case. We have a many-to-many relationship. So one to many or many to one is much preferred. But the one-to-many rule can only be used when there is actually one person, object, or thing on the one side that can be used multiple times. Now let's just take another example, just to clarify something. Suppose we have another contact, Susan, and this is the number of phone calls she has made, not one. Can this still be described as a one-to-many relationship? and the answer is yes. Many can be zero, one, two, and more. All of those count as many. So it's not actually required for there to be many, just the possibility of many in a particular example, whether zero, one, two, or more.

That's absolutely fine; that is still a one-to-many relationship. Now let's just take another look at the sources of things that can be represented by tables or entities. So we have, for instance, contacts; contacts are people; we have phone calls; we have tasks; we have addresses; these are places. So common standard entities can be used to describe people, places, and things, and it would probably be good for you just at the moment to pause this video and have a look at all of the different varieties of tables that are here. So you have an idea of the kinds of things they can describe. So entities can describe people, places, and things. They are made up of rows and columns, or records and fields, and you can have relationships between them: one to many, many to one, or many too many.

4. 22. The Common Data Model (CDM)

Now, when we created this sample data, we got all of these tables. But the sort of format that we've got is interesting. We've got a huge number of fields, and you can see that we've got fairly standard internal names. These are the public names, the names that the end user would see, and these are the internal names. And Microsoft is trying to have some standard tables with standard names, which they call the "common data model." Now, I think this is one reason why Microsoft renamed the common data service CDs. They didn't want CDs to be misinterpreted as CDM. There is some potential confusion there potentially. So that's why CDs became the data format, in my opinion.

So what Microsoft is trying to do is say, "Okay, when you create tables, here are some standard names that we'd like you to use." Now why would it be good for you to use standard names? Well, suppose I create a database, and then I create a second database and use completely different terminology. That makes it much more difficult to link them together. If someone else walks into this table and sees that I'm using standard names and they recognise the standard names, they'll have a good idea of what everything means. Now notice this is called "Address One Composite." I'm not just calling it that.

Address composite. So this allows for certain things; it's called disambiguity. It means I'm not going to ask, "Is this an address, or is this address one of this particular account in this case?" Then there's the issue of address, because we could have had address in another table and had an account with multiple addresses. So if you are using this particular naming system for the fields or columns and other people are using it, then you'll be able to hopefully eventually pull in data from lots of different resources and have them match more easily. So this is what is intended with the common data model. So you can see, for instance, that in Dynamics 365 the common data model is also used; in fact, the data verse is also used in some aspects of Dynamics 365 as well. So it is a set of standardised data schemas.

So the schemas are the tables and the columns, especially the columns with the data types that are extendable. So in other words, you can add additional columns to it, you can add additional entities or tables, and it's there to try and give a unification, a unifying feel, to not just your data but other people's data. As a result, the common data model is not limited to these specific tables. What Microsoft can do is give you a core. For instance, in Dynamics 365, you can have sales, service, and marketing. But then, if you're in a particular industry, you might have a set of tables or entities for the automotive industry, for banking, for medical records, for higher education, and so forth. So this is really just a small subset of what we're seeing, the core, and then it gets added onto whatever is needed for your particular situation.

Microsoft Power Platform PL-900 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass PL-900 Microsoft Power Platform Fundamentals certification exam dumps & practice test questions and answers are to help students.