Comment éviter les conflits ou les doublons lors de l’utilisation de clés naturelles sur différentes sources de données ou systèmes ?

Because of variety of data formats, managin data from different credit card provides can be difficult. We addressed this by developing a common data model that all banks could use. This streamlined the process and all raw data complied with production tables. This helped create a unique data structure for all banks which made easier to donduct industry analysis.

Benefits of a Common Data Model There are many benefits to using a common data model, including: Reduced data integration costs: A CDM can help to reduce the costs of data integration by providing a standardized format for data exchange. This can make it easier to connect different data sources and applications, and to automate the process of data integration. Improved data quality: A CDM can help to improve data quality by providing a common definition for data elements. This can help to reduce the number of data errors and inconsistencies, and to ensure that data is interpreted correctly by different systems. Increased data accessibility: A CDM can make it easier to access and analyze data by providing a centralized view of the data.

In atmospheric modeling, tools like WRF and WRF-Chem are widely used to simulate weather patterns and impact of aerosols and chemical processes on the atmosphere. However, integrating data from various source regions for these models can be challenging due to potential conflicts or duplicates when using natural keys. Defining a common data model helps overcome these challenges by standardizing entities, attributes, and relationships across datasets utilized in WRF and WRF-Chem simulations. This ensures consistency, whether dealing with meteorological data, emissions inventories, or atmospheric chemistry inputs, ultimately enhancing the accuracy and reliability of model outputs.

In the field of atmospheric modeling, avoiding conflicts or duplicates when using natural keys across different data sources or systems is crucial for ensuring consistency in simulations and analyses. Common data model (CDM) helps standardize natural keys by aligning data from diverse sources, such as satellite observations, ground-based measurements, as well as reanalysis datasets. For example, in integrating wind speed data from multiple sources, defining CDM allows for harmonizing units, time intervals, and spatial grids. The minimizes errors, resolves inconsistencies, and enhances the accuracy of model outputs, particularly in complex systems like WRF or WRF-Chem.

While using composite keys especially using source identifiers may help resolve duplicate keys issue, it poses another challenge in master data management. For example, same customer John Doe data comes from 2 different sources and we keep the composite key of data source, now Joe Doe is counted as 2 customers. This can pose challenge for down stream data analytics and any marketing campaign that aimed to end customers.

Use following elements to compose your key for entities: - Timestamp of loading (moment when is part of our system) - Version of register (for control of register status) - Business keys (to preserve relation with source) - ID original source (to know what source gave it) - Surrugate key (to map unified entity - optional but recommend) This fields support in several topics to select, modify and track.

“Collisions” in, say, Account_Number, occur during: 1. Mergers & Acquisitions; 2. Systems/Vendors migrations; 3. Over “time”. 4. Customer/Client “on requests” 3. A data warehouse may easily retain data 5 or 10 years, while source system “recycles” or “reuses” their “natural key” after only a couple of years. Rightfully, these would get a new “surrogate” key value. Customers “by request” do ask for renumbering of “natural key” if value is compromised or charge card lost, or for their own bookkeeping reasons. For continuity analytics, many may want same surrogate, so it doesn’t appear you “lost” an account, or pay “incentives” for newly acquired accounts.

“Context” for “natural key” makes sense as “Source System Identifier”, allowing you to rapidly accommodate M&As and insulates you from “future collisions” across distributed non-coordinated systems.

Composite keys and concatenated keys are two different methods for creating unique identifiers for data records. Both methods are used to avoid conflicts or duplicates when using natural keys. Composite keys are formed by combining two or more attributes that together form a unique identifier. For example, a composite key for a customer record might be created by combining the customer's first name, last name, and date of birth. Concatenated keys are created by joining two or more attributes together into a single string. For example, a concatenated key for a customer record might be created by joining the customer's first name, last name, and date of birth together with a delimiter, such as a hyphen or an underscore.

Whatever you do, be consistent! Make sure you have naming conventions established at a company level. You want anyone to be able to jump into your data and figure out what's going on. If you are pulling in usernames from 3 different systems, you can identify them with three different columns in one table: table_name - username_source1 - username_source2 - username_source3 ... or you can break it apart into a fact and dimension table: fact_table - username - username_source_id dim_table - username_source_id - username_source_context

This point can help surrogate keys to be unique when you have several origin sources and need repeat those keys; or you wanna stored surrogate keys fromexternal data models into field in your data model you are using. Those way can avoid key duplication too.

Converting to standard format is a good strategy for numerical, date and time data . Standardizing the order of fields such as First name, MI, Last name can help to certain extent with text data .

Some tips will help me: - Be care with timezone in timestamp field - Be care with coding format in text. Ones help me to agyle supporting operations when i check duplicate data from transformed data.

One aspect to consider when generating surrogate keys is to ensure the keys are generated unique across multiple internal database. For example, If your systems use 2 or more databases (ex. one for each market/region), ensuring the surrogate keys are unique across multiple databases helps with downstream data warehousing, or any future data consolidations across databases.

This is one good way. Use surrogate keys tied to the underlying database and other keys (customer ID) to tie the data models together.

Surrogate keys enable your systems to keep running even with duplicate data in natural keys. Often it is preferable to permit duplicate or questionable data to enter your systems where it can be seen, evaluated, and analyzed by experts rather than preserving the integrity of the data and forcing a harried front-end user to read cryptic error messages to confused help desk personnel. A conversation with the developers starting with the words “Your application is allowing duplicate data, see example in attached Excel”, is more much more productive than “users are complaining the application won’t let them …”

We would advise against joining or building relationships using only the natural key. Treat all source data within the model as non-unique and independently apply physical keys for relationship, version controls, and test for uniqueness. We often see membership numbers, email addresses etc. stored differently from different source systems with no guarantee of being able to match between systems within a model. Analysis to create e.g. a single customer view, qualifies how the matches and duplicates are identified when using natural keys.

Implement data governance: Establish data governance policies and procedures to ensure that natural keys are consistently defined and used across all systems. This includes defining rules for generating natural keys, validating the uniqueness of keys, and resolving any conflicts. Use a master data management system: Implement a master data management system to manage and maintain the natural keys across all systems. This ensures that the keys are consistent and up-to-date, and reduces the chance of conflicts and duplicates.

When using surrogate keys I always define a secondary unique index. Surrogate keys don’t really guarantee that the same data is not inserted twice.

In my previous company we were using data vault modelling which applied the concept of surrogate key, however the key is #hashkey auto generated based on the identified unique value(natural keys), the principle follows a very sophisticated way of handling natural key conflicts however the designs explodes the database significantly where you can never do it without a data automation tool.

In my experience SCD-4 can be one of the solutions when natural key is primary key and also history needs to be captured. Ex. Customer/account information, where account number is natural key and primary key.