Last Updated July 2022

Hakju Oh

Introduction

The purpose of this document is to provide a concise overview of Score database structure in a concise way for better understanding to assist in the contribution to Score development process. As Score has adopted a canonical data model design based on CCTS (Core Component Technical Specification) v3.0, core structural characteristics in tables and columns such as names and data types have followed follow CCTS definitions.

Core Components (CCs) and Business Information Entities (BIEs)

In general, CCTS defines two abstract meta models: Core Components (CCs) and Business Information Entities (BIEs). Each element in business documents . There are various types of CCs and also various types of BIEs.

The definition of each data element in a data exchange specification is represented as a CC, and while a specific specialized definition of a CC in various a particular business contexts context is reflected through a BIE. The relationships between CCs and BIEs are illustrated as follows:in the figure below. For a little deeper overview of CCTS, please visit Core Component in Brief section in Score User Guide.

...

And the relationship is represented in DB as follows (in fact, there are manifest tables between CCs and BIEs for tracking revisions in releases, and it . This will be explained this later):

...

There are two differences between CCTS definition and actual table definitions.

1. ACC table has based_acc_id to support hierarchical type reference. The reason we introduced this is that most business data exchange libraries have defined the base type use the notion of inheritance to maximize reusability and ease of conceptualization. For example, both Customer Party and Supplier Party could have shared common components in the Party base can share a common based ACC Party.

2. Core Data Type (CDT) and Business Data Type (BDT) are both represented in DT table. In practice, standard developers have defined their data types ( BDT ) in as standard definitions based on the UN/CEFACT standard CDTs, and end-users took it use them without further manipulations in BIEs. Therefore, Score provides BDT definitions only for a standard development stepthe functionality to define BDTs only for the standard developer user and BDTs can be used directly with the CCs as no further customization is enabled when defining a BIE.

Core Components (CCs) Naming Rules

Each CC table has naming concept names related columns, such as object_class_term, property_term, representation_term, and data_type_term. All these columns are a part of the CC DEN (dictionary entry name), which is a unique official name of the CC in the dictionary. It is expressed in DB, as follows:

...

• ACC.DEN: consists of object_class_term followed by a dot, a space character, and the term ‘Details’ (e.g., object_class_term: 'Contract' → DEN: 'Contract. Details'.)

• ASCC.DEN: consists of object_class_term of the associating ACC followed by a dot, a space character, and the DEN of the included associated ASCCP​ (e.g., from_acc->object_class_term: ‘Contract’ and to_asccp->DEN: ‘Effective. Period’ → DEN: ‘Contract. Effective. Period’.)

• ASCCP.DEN: consists of property_term followed by a dot, a space character, and the object_class_term of the associated ACC (e.g., property_term: ‘Effective’ and role_of_acc->object_class_term: ‘Period’ → DEN: ‘Effective. Period’.) BCC.DENIt should be noted that words that are consecutively repeated are truncated.

• BCC.DEN: consists of object_class_term of the associating ACC followed by a dot, a space character, and the DEN of the included associated BCCP​ (e.g., from_acc->object_class_term: ‘Contract’ and to_bccp->DEN: ‘Price. Amount’ → DEN: ‘Contract. Price. Amount’.) It should be noted that words that are consecutively repeated are truncated.

• BCCP.DEN: consists of property_term followed by a dot, a space character, and the representation_term of the BDT used (e.g., property_term: ‘Price’ and BDT’s representation_term: ‘Amount’ → DEN: ‘Price. Amount.) In fact, bccp->representation_term is followed by representation_term of the associated DT in Score.

• DT.DEN:

  • (for For CDT) , it consists of data_type_term followed by a dot, a space character, and the term ‘Type’ (e.g., , data_type_term: ‘Date Time’ → DEN: ‘Date Time. Type’.) It should be noted that CDT data are as defined in the CDT catalog 3.1 standard. Each CDT has data_type_term and representation_term: ‘Date Time’ → DEN: ‘Date Time. Type’.)(for BDT) defined.

  • For BDT, it consists of data_type_term and qualifier, if any, followed by a dot, a space character, and the term ‘Type' (e.g., data_type_term: ‘Date Time’ and qualifier: ‘Open’ -> DEN: ‘Open_ Date Time. Type’.) Both data_type_term and representation_term of the BDT is the same as those of CDT on which it is based.

For more information, please read CCTS (Core Component Technical Specification) v3.0 that defines naming rules for each entity.

...

CCTS Data Type Catalog v3.1 defines the rules for developing standard Core Data Types and rules for developing Business Data Types to define value domains for to give the value domain to BCCs and BCCPs including allowed primitive types and supplementary components. The following diagram shows the relationship between DTs, SCs, primitive types, and BIEs.

...

• First of all, 11 allowed primitive types defined in CCTS Data Type Catalog are assigned populated into the cdt_pri table, as follows:

...

• xbt table keeps representations of various data formatsthe mapping between primitives in various syntaxes, such as XML, JSON, and OpenAPI. The following table is a part of xbt rows.

...

the relationships between xbtrows are determined by columns uses XML Schema Data Types, as described as the main type system as shown in the following figure.

...

• cdt_awd_pri_xps_type_map and cdt_sc_awd_pri_xps_type_map tables contain mapping data indicating xbt for each CDT and SC to express CCTS primitive types using specific data formats. Amount. Type CDT and Amount. Currency. Code SC used in previous examples could be mapped, as follows:

...

A top-level ASBIEP is a concept BIE to indicate the root of the BIE hierarachy tree. The following diagram describes the relationship between top_level_asbiep and BIE tablesBIE tables. When the Create BIE menu is invoked on the UI, a is created and also its descendant BIEs including the ABIEP, ABIE, BBIE, etc.

...

top_level_asbiep.asbiep_id indicates a root ASBIEP node of the BIE tree, and each BIE table has owner_top_level_asbiep_id column to indicate where this BIE belongs to. In fact, Score has used owner_top_level_asbiep_id column in queries when it needs the entire BIE data.

SELECT * FROM `asbiep` WHERE `owner_top_level_asbiep_id` = ?;
SELECT * FROM `abie` WHERE `owner_top_level_asbiep_id` = ?;
SELECT * FROM `asbie` WHERE `owner_top_level_asbiep_id` = ?;
SELECT * FROM `bbie` WHERE `owner_top_level_asbiep_id` = ?;
SELECT * FROM `bbiep` WHERE `owner_top_level_asbiep_id` = ?;
SELECT * FROM `bbie_sc` WHERE `owner_top_level_asbiep_id` = ?;

All retrieved data will be organized within Retrieved data from SQLs above are used within the Score application logics for various purposes, such as the BIE expression.

In addition, it operates for ‘Reused BIE’ which is a function another example, such query is utilized in the ‘Reused BIE’ function. The purpose of the function is to embed pre-profiled BIEs into the current BIE. It can be checked another BIE. In this function, it is necessary to check if the value of asbie.owner_top_level_asbiep_id is different with asbie->to_asbiep.owner_top_level_asbiep_id. The following is a query to retrieve all ASBIEs reusing other BIEs in the current BIE.

...

In Score, each release of the a data exchange library consists of a group of components in different sets. In order to conceptualize enable this grouping mechanism, we introduced ‘manifest’ tables are introduced between release and CC tables. The following diagram illustrates release-CCs table relationships.

...

Each CC table (ACC, ASCC, BCC, ASCCP, BCCP, DT, and DTcode list) has an associated manifest table (ACC_MANIFEST, ASCC_MANIFEST, BCC_MANIFEST, ASCCP_MANIFEST, BCCP_MANIFEST, and DT_MANIFEST.) And every manifest table has a reference to a release table.

...

If it planned there were to be a change to ‘Location’ ACC to have a ‘Location Base’ ACC as a base type in the next release ‘10.1’, it would look like below.

...

Moreover, each BIE table is associated with these manifest tables, not directly with CC tables, because BIEs are related to a specific release. Thus, the relationship between CCs and BIEs can be specified, as follows:

...

Module

Module is an entity of the component representing a directory and file structure that Score uses to express schemas into the a file system. From this definition, each module has two types: ‘File’ and ‘Directory’, and only ‘File’ type modules can contain components, and ‘Directory’ type modules can contain ‘File’ modules. A set of modules is composed of a set of components for a specific release, and can be used in one or more releases, so each module set is associated with release manifests. The following diagram shows these relationships.

...

Every module-manifest relational table module-manifest relational table on the right (such as module_ASCCP_manifest)has the same pattern, that it has module_id and module_set_release_id to indicate which module entities and sets are associated with specific manifest components for releases.

...

In this case, ‘Component’ module should have a reference to ‘Field’ module to refer reference the ‘Name’ BCCP for the ‘Party’ ACC. In XML schema, for example, ‘Component’ schema has to use ‘include’ or ‘import’ element (by equivalent of the target namespaces between the two schemas) to refer to the ‘Field’ schema. The algorithm detects cyclical dependency when the CCs are exported and report such issue at that stage.

Sequencing Keys

ASCC and BCC associations should be assigned a unique sequencing key within the ACC. The straight-forward approach is to assign a unique numeric number to each association in order. The drawback of this approach is that it may need many operations to add, change, or delete an association from the sequence, especially if the ACC has a large number of associations. Assuming that the ACC has 100 associations, so each association has assigned numbers from 1 to 100. If it attempts to add a new association at the beginning of the sequence, it should increase assigned numbers by 1 for all associations, which needs 100 operations. In order to enhance operation reduction for sequencing keys, Score has seq_key tablereduce computational need for sequencing key updates, Score has seq_key table that does not rely on the numerical order of the sequence key but instead it captures the order of the key as a linked list.

...

seq_key table maintains the sequence of associations using doubly linked list structure with prev_seq_key_id and next_seq_key_id columns. We can rewrite the previous example using the seq_key table. Suppose that ‘Party’ ACC had the following ASCCs with unique numeric numbers for sequencing keys.

...

Now, all (traverse/insert/remove) operations in seq_key follow the same logic in doubly linked list. For example, if a new ASCC is inserted before the Party. Employee Contract. Contract, it can have 101 seq_key column but the actual order is kept in the seq_key table..

Business Contexts

Business context is a discriminator for categorizing CCs BIEs according to their use in business circumstances. In CCTS, business contexts could be described for the BIE by assigning context categories and its schemesscheme values. The following diagram illustrates the relationship between BIEs and business contexts.

...