Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Thursday, June 16, 2011

Microsoft Dynamics AX 2012 - Type Hierarchy



With the upcoming release of Microsoft Dynamics AX 2012, one of the rather interesting new elements about this release, is the introduction of table type hierarchies.

When you glance at this, just from a data layer level, it seems to be super normalization. That is actually correct, however, you must look at the total picture. That means, you must take and look at this from the data + application layers, together.

That is the only way, that this concept then actually works. In order to help understand this concept, and how the new data structures live within Microsoft Dynamics AX 2012, there is a new tool called the Type hierarchy browser.

You can get to this tool, from any object within AX actually. Classes, tables, etc. For this post, we will focus on tables, and how the tool can help us better understand the data structure.

Lets pick a new structure in Microsoft Dynamics AX 2012, EcoResProduct. This is part of the new Master Data Management (MDM) / Product Data Management (PDM), that will exists out of the box for this release of AX.

Once we have selected the EcoResProduct table, within the AOT, simply right click, add-ins, and then click on the 'Type hierarchy browser' menu item.



Once we do this, we then see the hierarchy that exists for the EcoResProduct table, which extends from the Common table object.



You will notice, that both Common and the EcoResProduct tables have RecId, revVersions & relationType. You will also notice that, DataAreaId is no longer listed. We will save that for another post.

In here we can see as well that the EcoResProduct table inherits methods, from the Common table object. Fields that exists at the EcoResProduct table, are marked with blue blocks, that exist beyond the Common table. We can also see that, in the tree view on the right hand side of the screen, that the hierarchy make up, that EcoResProduct is a part of.

Extending from the EcoResProduct table object, is the EcoResDistinctProduct, and the EcoResProductMaster. Extending from the EcoResDistinctProduct, is the EcoResDistinctProductVariant table object.

Now, if we step forward in the tree, and select the EcoResDistinctProduct, in the tree view, we should see something that looks like the following.



Now you will notice, that for the EcoResDistinctProduct table, the only fields it has, is the three system fields that we listed above. If you look at the data for this table, sure enough that's all that is there, from the data layer perspective.

What this suggests then, and shows, is that the actual field data that lives for a Distinct Product, vs. a Product, still lives within the EcoResProduct table. The EcoResDistinctProduct table inherits the fields for: SearchName, ProductType, InstanceRelationType, and DisplayProductNumber.

When the table is referenced within a form, or code, the EcoResDistinctProduct table has these fields as possible uses, becomes of the new way AX handles, allowing table structure hierarchy.

This does a lot of things for such structures, it cuts down, big time, on the amount of repeat data, size of databases, and enables the application layer, to be the only true way, of working with the data that lives within a Microsoft Dynamics AX 2012 instance.

With using the Type hierarchy browser, provided out-of-the-box for Microsoft Dynamics AX 2012, one can better understand the new data structures, and be able to connect all the new dots, that will exists with this release.

This is very powerful, and through the use of the application layer, the statement of Powerfully Simple, which is the tag term being used to describe Microsoft Dynamics AX 2012, is true!

That's all for now, but check back soon as more to come!



"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , ,

Wednesday, January 26, 2011

Dynamics AX 2012 - Table & Type Hierarchies

One of the huge, underlying changes from a architecture, and really database design point of view for Microsoft Dynamics AX 2012 is the use of Type or Table Hierarchies.

This is actually extending upon the type hierarchy system that already existed within Dynamics AX, however to a whole new level!


[Image Source: techmaniac1, Rodrigo Fraga while attending #DAXCONF 11]


As you can see from above, thanks to Techmaniac1, the screen shot shows off the Type Hierarchy of a given table. This is actually showing from within the Dev workspace, looking at the AOT as a new add-in for Microsoft Dynamics AX 2012.

With this concept, OO Design is being forced onto Relational data. I know, I know, that statement seems like it would be an oxymoron. I mean how can relation data truly be and live with OO attributes, design concepts, and adhere to such rules that govern things like: inheritance & polymorphism?

The answer to that is super normalization! That is what is taking place with Microsoft Dynamics AX 2012 and type hierarchies for Table objects.

Because Microsoft Dynamics AX 2012 manages it's relation database, through a meta layer, then through the combining of these two concepts, such things as inheritance and polymorphism can be applied.

So with this, we now have new attributes of tables, called: concrete or abstract, as well as if a table inherts from another table or not.

In doing this 'extending from' at a table level, the table that extends from an abstract table, inherits the fields and methods of the super or base table being inherited from.

This new approach along, plus just adhereing to BP, means that you should *never* access to the database of an Microsoft Dynamics AX 2012 instance directly. So many reasons why, and with Microsoft Dynamics AX 2012, so many more reasons will exists.

And this is true today actually, should not have direct access to the DB of an AX instance, however it's still done today in certain cases.

That's all for now on the continued coverage from the #DAXCONF 11. I hope that I have your wheels turning, and thinking about the possibilities this means, and doors this opens from an Architecture and Design POV. Also, what this means for outside development that may directly access the database of an AX instance today.

This leads me into my next focus, which is OData Feeds and EDM, and how they will enable secure, easy access to Microsoft Dynamics AX 2012 data and business logic, without ever needing direct access to the DB again!

See you next post!

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , , ,


Copyright 2005-2011, J. Brandon George - All rights Reserved