Hi diddy,

You should rather create a simple technical ID, that won't be a source of problems. Have a look at AUTO_INCREMENT or UUID simple custom types, to indentify your entities instances in a unique way.
Setting labels as key lead to this kind of problem, as the value of the key is used to technically name the xml document in the database.

Cyril.

Last edited by csonnefraud (2012-04-16 18:01:06)

Hi diddy,

I've already had the same kind of use case, with this form of entity :

- ID (PK, AUTO_INCREMENT)
- Functional Key (Unique)
- Attributes
- ...

As you may know, it's not possible to set a unique constraint on an attribute of the datamodel. Only the primary key is unique, by definition.
What I did to ensure that my functional key was also unique was to setup a beforeSaving process on the entity, to guarantee that a duplicate on that attribute would throw an error.

This was done using a simple job that checks the functional key, using :

                                 tMDMInput
                                       |
tMDMReceive     -->        tMap**   -->     tUniqueRow   --(Uniques)->  tMap --> tBufferOutput (Validation)
                                                                    |
                                                                    -- (Duplicates) ->   tMap   --> tBufferOutput (Error)     

** But in my opinion, joins using labels almost always lead to matching issues. That's why data quality components that use a fuzzy join logic (tRecordMatching for instance) should be preferred in that case.

To ensure a good coherence between your MDM technical IDs and your other databases, you may build & maintain cross-references then.

Hope that helps,

Cyril.

Last edited by csonnefraud (2012-04-17 10:29:04)

Hi diddy,

Sorry for the late reply. Cross-referencing enable you to store relations between your MDM entities, and the related records from your OLTP applications. Cross-references are crucial in a MDM project, as this is where are consolidated the links to your other applications. This leverages the 'single-version of the truth' in a MDM project.

Let's say you hold products in your MDM. It will answer the question : What is the reference 'product' in Talend MDM related to that 'product' in my SCM app ?

For instance, this is the kind of schema a cross-referencing entity will use, holding only primary keys :

IdMDM (PK), IdApp_1, IdApp_2, IdApp_n

Such an entity enables you to link your MDM entities instances to synonymous information stored elsewhere.
You'll have to lookup this entity to find the reference between the technical Id from MDM, and the technical Id from your app.
No more joins on labels, that may bring data quality issues

Talend Enterprise MDM gives you the ability to store & manage cross-references within a dedicated application.

Regards,

Cyril.