Hi Madhan... ...a follow-up to Mandy's question, which may be more historical in nature (just to provide some additional insight as we all think about "common" models)........for each of the types that exist today, is there any particular pattern that they followed, or was it mostly that each mini-model evolved on its own, based on the original "author" of a particular "hook" and the needs of that selected hook and its base technology?
Thank you. Ernie Ernie Ostic Worldwide Technical Sales InfoSphere Information Server IBM Analytics Cell: (617) 331 8238 --------------------------------------------------------------- Open IGC is here! Extend the Catalog with custom objects and lineage definitions! https://dsrealtime.wordpress.com/2015/07/29/open-igc-is-here/ From: Mandy Chessell <mandy_chess...@uk.ibm.com> To: "Madhan Neethiraj" <mad...@apache.org> Cc: David Radley <david_rad...@uk.ibm.com>, dev@atlas.incubator.apache.org Date: 05/18/2017 04:57 AM Subject: Composition relationships Hello Madhan, I am working my way through the open metadata model and working out how to stitch it to the existing structures. I wanted to be sure I am understanding the JSON properly I am looking in addons/models/0030-hive_model.json at the relationships between hive_table and hive_column, hive_db. All of these are entities. Firstly, hive_table declares an attribute called db of type hive_db: There is no ownedRef entry nor a matching entry in the hive_db definition so I am assuming that db is just a complex atribute and there is no navigation from hive_db to hive_table? What is the difference between defining hive_db as an entity rather than a struct? { "name": "hive_table", "superTypes": [ "DataSet" ], "typeVersion": "1.0", "attributeDefs": [ { "name": "db", "typeName": "hive_db", "cardinality": "SINGLE", "isIndexable": false, "isOptional": false, "isUnique": false }, : } Next, hive_table seems to have a 2 way composition relationships between itself and hive_column called columns<->table. These are definitions for the relationship in these entities: { "name": "hive_table", "superTypes": [ "DataSet" ], "typeVersion": "1.0", "attributeDefs": [ : { "name": "columns", "typeName": "array<hive_column>", "cardinality": "SINGLE", "constraints": [ { "type": "ownedRef" } ], "isIndexable": false, "isOptional": true, "isUnique": false }, : : ] }, { "name": "hive_column", "superTypes": [ "DataSet" ], "typeVersion": "1.0", "attributeDefs": [ : { "name": "table", "typeName": "hive_table", "cardinality": "SINGLE", "constraints": [ { "type": "inverseRef", "params": { "attribute": "columns" } } ], "isIndexable": false, "isOptional": true, "isUnique": false } ] }, However, a similar definition in hive_table for partitionKeys does not have an inverseRef entry in hive_column - does that make it one way? What does the "OwnedRef" declaration do in this case? { "name": "hive_table", "superTypes": [ "DataSet" ], "typeVersion": "1.0", "attributeDefs": [ : : { "name": "partitionKeys", "typeName": "array<hive_column>", "cardinality": "SINGLE", "constraints": [ { "type": "ownedRef" } ], "isIndexable": false, "isOptional": true, "isUnique": false }, : : ] }, Is there any difference in the behaviour of the relationship called db (to hive_db) and the one called partitionKeys? This is the UML I have derived Also, do you have example JSON structures for classifications? Many thanks for your help All the best Mandy ___________________________________________ Mandy Chessell CBE FREng CEng FBCS IBM Distinguished Engineer Master Inventor Member of the IBM Academy of Technology Visiting Professor, Department of Computer Science, University of Sheffield Email: mandy_chess...@uk.ibm.com LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49 Assistant: Janet Brooks - jsbrook...@uk.ibm.com
