Allow 0 dimensions for a DSD

[brainwasher]

Data is designed using different layers covering different concerns (e.g. logical, technical, implementation related). Designing a high-level Conceptual model capturing the main aspects of the problem domain helps people involved in the design of the data to narrow down its scope. Based on such a Conceptual model subject matter experts in cooperation with data modelling experts may design a Logical Data Model (LDM) capturing the exact business logic of the problem domain in a highly normalised structure. During the design of the LDM no technical considerations are taken into account (“separation of concerns” principle). Because of its highly normalised design the LDM allows to design (forward engineer) different technical or physical data models fulfilling different needs. Examples for such technical or physical data models by their purpose in the data production chain are highly normalised validation models (enforcing referential integrity constraints) and data analysis models for business users to query the data (e.g. models applying a star schema). Another application of the forward engineering procedure of LDMs into physical models concerns the underlying technology. Based on an LDM it is possible to forward engineer physical models for different data base management systems, e.g. relational, graph or file-based data base management systems. Optimally a Metadata repository is capable to storing logical and technical models. In theory SDMX 3.0 can store most of the relevant aspects of these data models, however it is not capable of storing so called generalizations without primary keys, i.e. Entities that do not have a primary key. Especially in logical data models this modelling construct is used to create abstract Entity types which hold information applicable to different implementation types (having different primary keys). For example, assume that ECB employees and EUROSTAT employees are identified by different identifiers – we may say that they are different objects because they are identified by different primary keys. Both of them are employees and therefore they will have a lot of things in common, e.g. first name, last name, salary. All the things that they have in common may be modelled in an Entity (let’s call it Employee) having no primary key but holding only these Attributes that are common to the two different types. ECB employee and EUROSTAT employee may then inherit from the Entity Employee. For SDMX 3.0 to be capable of storing logical data models using such a modelling construct the following change request needs to be approved / implemented: • Enable Data Structure Definitions (DSDs) without Dimensions • Enable Structure maps without Component maps

[sdmx3mdt]

Thank you for your comment. However, the consultation period closed on 30 July 2021.