DQS: When composite domain is used for cleansing, the natural domains are still used to determine correct/new - by Tim Mitchell

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 740427 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 5/3/2012 1:10:56 PM
Access Restriction Public

Description

When performing a cleansing operation using the DQS client, I found that even when a composite domain is engaged for the project, the status of New or Correct is determined by the individual domains within the composite, not the composite combination itself. 

Here's the scenario.  I create a new knowledge base using a list of valid automobiles, including make, model, type, and seating capacity.  I create a composite domain based on Make + Model.  In my base data I include the Chevrolet Camaro and several Ford automobiles

I then create a DQS cleansing project to cleanse a second set of data.  In this data to be cleansed, I include the fictitious make/model combination of Ford Camaro, which does not exist in real life nor in my original set of data I used to populate the knowledge base.  Theoretically (at least as I understand it), this is exactly the kind of thing that the composite domain is designed to catch - even though Ford is a valid make and Camaro is a valid model, the combination is not part of the knowledge base and therefore should be identified as a "New" record rather than a "Correct" record when the composite domain is engaged in a cleansing operation.

However, I find that the Ford Camaro is passed through as part of the "Correct" data, even though I've confirmed that the composite domain is used for the cleansing operation.  I've tinkered with the Parsing Method settings for the composite domains, but the result remains the same.  I tried this operation on a DQS instance using RTM and another with CU1, both with the same result.
Sign in to post a comment.
Posted by Russ Manning on 3/21/2014 at 12:24 PM
I agree strongly with Tim - it's fine if this is not the intended functionality of composite domains, but without it there is no passive way to filter out invalid combinations of domains. For example, New York City is a valid city and Pennsylvania is a valid state, but New York City, Pennsylvania is not a valid city/state.

Unless you are suggesting that we create a manual validation rule for every combination of make/model or city/state, this nearly ensures that with large enough sets of data entering a system, someone will miss these values that are only invalid in the context of a combination.

I would recommend that you re-look at providing some way to accomplish this goal, even if it is not through composite domains (though that seems like a logical place for it).

Posted by Matthew [MSFT] on 5/8/2012 at 3:38 PM
Hi Tim,

We’re closing this issue as “By Design.” To achieve the functionality you’re looking for, you should be able to use a validation rule, but composite domains are not designed to deliver this functionality.

Matthew