Over the past several years I've gotten a lot of questions from people about what WMI class is the source of data for a particular hardware inventory view ("v_GS_..."). This past week I created a couple queries to provide a team who has generally been the source of 95% of these questions and I figured I'd blog about it.
Query 1
This query can be used to determine what WMI class is being used for a given hardware inventory view name. (Obviously, if you change the WHERE clause you could use it to determine if we collect a particular WMI class as well).
SELECT map.InvClassName AS [ViewName]
,cls.Namespace AS [WMI_Namespace]
,cls.ClassName AS [WMI_Class]
FROM dbo.v_InventoryClass cls
INNER JOIN dbo.DataItem itm
ON cls.ClassID = itm.ClassID
INNER JOIN dbo.v_GroupMap map
ON cls.SMSClassID = map.MIFClass
WHERE map.InvClassName = N'v_GS_SomeViewNameHere';
--or...cls.ClassName = N'Win32_SomeClassNameHere';
Query 1 Example
In my environment, the most recent ask was regarding two views - "v_GS_BATTERY" and "v_GS_HWINV_DeviceGuard". If I plug these two views into the query I get the following output:
You'll notice that although we asked about two views, only one record was returned. Why? Because even though that view (v_GS_BATTERY) exists and we may have collected data for it at one point in time, this query will only return views/classes that are currently defined in the "MOF" or in other words the class is currently defined as a class to report on in the MOF Editor. Thus, we know from this result set that we no longer collect data for "v_GS_BATTERY". For the other view, we see that the data in this view is coming from the class "Win32_DeviceGuard".
Note: all my custom inventory extensions start with "HWINV_" so it's expected for you not to have it in your environment unless you have the same genius design. 
So, just to recap, if something is returned in the query then you are currently collecting data from the class into the view.
Query 2
This query is really just an extension of the first. It can be used to determine what properties the system knows exists in a given class and which of those properties are being collected (to report back to CM).
SELECT map.InvClassName AS [ViewName]
,cls.Namespace AS [WMI_Namespace]
,cls.ClassName AS [WMI_Class]
,icp.PropertyName
,CASE WHEN dip.PropertyID IS NOT NULL THEN 'Yes' ELSE 'No' END AS [IsPropertyCollected]
FROM dbo.v_InventoryClass cls
INNER JOIN dbo.DataItem itm
ON cls.ClassID = itm.ClassID
INNER JOIN dbo.v_GroupMap map
ON cls.SMSClassID = map.MIFClass
LEFT OUTER JOIN dbo.InventoryClassProperty icp
ON cls.ClassID = icp.ClassID
LEFT OUTER JOIN dbo.DataItemProperty dip
ON icp.ClassID = dip.ClassID
AND icp.PropertyID = dip.PropertyID
WHERE map.InvClassName = N'SomeViewNameHere'
--Or cls.ClassName = N'SomeClassNameHere'
ORDER BY cls.ClassID
,icp.PropertyName;
Query 2 Example
Let's use "v_GS_COMPUTER_SYSTEM" in this example. So, let's plug it in the query and look at the results:
You can see that it returns a list of properties and a "No" or "Yes" next to each property to designate whether the "MOF" or "MOF Editor" says to query the systems for the property and report back. This is useful to determine if a particular property is currently being collected; just because the column exists in the table doesn't mean the data is being collected for it. ConfigMgr knows about the property (from the MOF) but the property can either be "reported" or "not reported" (in the MOF you'll see "SMS_Report (TRUE)" or "SMS_Report (FALSE)" to indicate this). So, we see in this result set that we are only collecting some of the properties in this class rather than all of them.
To look a little deeper in this example, there are 50 properties (matching the number of columns in the view) but not all of them will be collected from the systems:
So, the view has 55 columns (the second result set). From the first result set we can see that we collect 13 properties and don't collect 37 which is a total of 50. So why the discrepancy? Those are the ConfigMgr internal columns of course - there will be 5 in every hardware inventory table/view.
So there you have it, a couple of queries that should come in useful if ever you want to know what class a view is populated from!