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!"
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!
Labels: Architects, AX 2012, DAXCONF, Dynamics AX, Dynamics AX 2012, Dynamics AX 6.0, hierarchy, Microsoft, OOP, polymorphism, type hierarchies
posted by brandon | 9:46 AM
1 Comments:
I guess this will enforce all the partners and the clients who use Crystal report or any other reporting tools other than SSRS to re-develop all their reports to cope with the new release, I've advised many times all the reports' developers to concentrate only on MS tools for report developing as it will be the right way to ensure the easiness of the Upgrade and also the continues support.
Thanks Brandon for your insightful posts.
Mahmoud Anass
Post a Comment
<< Home