Difference between revisions of "Capability/Data Quality Checks"
Capability/Data Quality Checks
Jump to navigation
Jump to search
| Line 3: | Line 3: | ||
| short description = Data quality checks by managed and continuously updated data quality rules. | | short description = Data quality checks by managed and continuously updated data quality rules. | ||
| description = Transformation of human-documented data requirements into executable data quality rules is mostly a manual IT effort. Changing requirements cause IT efforts again and again. Some checks, e.g. tax number validity (not just format!), require external services. Other checks, e.g. validity of legal forms, require managed reference data (e.g. legal forms by country, plus abbreviations). Continuous data quality assurance (i.e. batch analyses) and real-time checks in workflows often use different rule sets. Data requirements and related reference data are collected and updated collaboratively by the Data Sharing Community. Data quality rules are derived from these requirements automatically, auditor approved. All data quality rules are executed behind 1 interface, in real-time, 1’000+ rules in < 1s. Batch jobs and single-record checks use the same rule set and can be integrated by APIs. If reference data (e.g. correct tax numbers) is available, fix proposals are provided for incorrect records. | | description = Transformation of human-documented data requirements into executable data quality rules is mostly a manual IT effort. Changing requirements cause IT efforts again and again. Some checks, e.g. tax number validity (not just format!), require external services. Other checks, e.g. validity of legal forms, require managed reference data (e.g. legal forms by country, plus abbreviations). Continuous data quality assurance (i.e. batch analyses) and real-time checks in workflows often use different rule sets. Data requirements and related reference data are collected and updated collaboratively by the Data Sharing Community. Data quality rules are derived from these requirements automatically, auditor approved. All data quality rules are executed behind 1 interface, in real-time, 1’000+ rules in < 1s. Batch jobs and single-record checks use the same rule set and can be integrated by APIs. If reference data (e.g. correct tax numbers) is available, fix proposals are provided for incorrect records. | ||
| − | |||
| sort rank = 120 | | sort rank = 120 | ||
| product = Product/Data Quality Services | | product = Product/Data Quality Services | ||
Revision as of 10:32, 12 July 2021
| Name Name of a concept, e.g. a data model concept. In contrast to terms, the name does not depend on a given context, e.g. a country-specific language. | Data Quality Checks (category: , sort rank: 120, product: Product/Data Quality Services) |
|---|---|
| Short description Informal and short human-readable definition of a concept. | Data quality checks by managed and continuously updated data quality rules. |
| Description Informal and comprehensive human-readable definition of a concept. | Transformation of human-documented data requirements into executable data quality rules is mostly a manual IT effort. Changing requirements cause IT efforts again and again. Some checks, e.g. tax number validity (not just format!), require external services. Other checks, e.g. validity of legal forms, require managed reference data (e.g. legal forms by country, plus abbreviations). Continuous data quality assurance (i.e. batch analyses) and real-time checks in workflows often use different rule sets. Data requirements and related reference data are collected and updated collaboratively by the Data Sharing Community. Data quality rules are derived from these requirements automatically, auditor approved. All data quality rules are executed behind 1 interface, in real-time, 1’000+ rules in < 1s. Batch jobs and single-record checks use the same rule set and can be integrated by APIs. If reference data (e.g. correct tax numbers) is available, fix proposals are provided for incorrect records. |
| Release status The release status in terms of development progress or maturity of a product feature or a business capability.<br/><code>EMPTY</code> (0): No feature considered yet, just rough idea for capability.<br/><code>IDEA</code> (1): Just an idea, not yet designed in detail.<br/><code>DESIGN</code> (2): Software design ready, development not yet started.<br/><code>DEVELOPMENT</code> (3): Software development in progress.<br/><code>ALPHA</code> (4): First functional release, in terms of a Minimal Viable Product (MVP).<br/><code>BETA</code> (5): Tested by selected users.<br/><code>RC</code> (6): Release candidate, fully tested, not yet used in production by many customers.<br/><code>LIVE</code> (7): Used in production by customers, fully monitored and supported.<br/><code>DEPRECATED</code> (-1): End of life planned, but still available.<br/><code>EOL</code> (-2): End of life, historic service, no longer available.<br/><code>BROKEN</code> (-3): Service was used in production but is currently not available. However, CDQ tries to repair or reactivate it.<br/><code>DISCONTINUED</code> (-4): The data source has ceased providing updates; nonetheless, we continue to offer the most recent available data. | EMPTY
|
| Use cases | Not used in any use case |
| Apps | No app provides this capability |
| APIs | No API provides this capability |
Features
No features yet available
