Last Updated July 2022

Hakju Oh

Introduction

The purpose of this document is to provide Score database structure in a concise way for better understanding Score development process. As Score has adopted a canonical 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 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 is represented as a CC, and a specific definition in various business contexts is reflected through a BIE. The relationships between CCs and BIEs are illustrated as follows:

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 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 libraries have defined the base type to maximize reusability. For example, both Customer Party and Supplier Party could have shared common components in the Party base.

2. Core Data Type (CDT) and Business Data Type (BDT) are represented in DT table. In practice, standard developers have defined their data types (BDT) in standard definitions, and end-users took it without manipulations in BIEs. Therefore, Score provides BDT definitions only for a standard development step.

Core Components (CCs) Naming Rules

Each CC table has naming concept 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:

Each CC table has the column DEN, and it is unmodifiable. The following illustrates how DENs are defined:

• 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 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.DEN: consists of object_class_term of the associating ACC followed by a dot, a space character, and the DEN of the included BCCP​ (e.g., from_acc->object_class_term: ‘Contract’ and to_bccp->DEN: ‘Price. Amount’ → DEN: ‘Contract. Price. Amount’.)

• BCCP.DEN: consists of property_term followed by a dot, a space character, and the representation_term (e.g., property_term: ‘Price’ and 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 CDT) 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’.)

  • (for BDT) 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’.)

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

Data Types (DTs) and Supplementary Components (SCs)

CCTS Data Type Catalog v3.1 defines the rules for developing Core Data Types and Business Data Types to define value domains for 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 into cdt_pri, as follows:

• cdt_awd_pri and cdt_sc_awd_pri tables contain mapping information of allowed primitives for each CDT as defined in the catalog definitions. The following tables are example rows of Amount. Type CDT and Amount. Currency. Code SC.

• xbt table keeps representations of various data formats, such as XML, JSON, and OpenAPI. The following table is a part of xbt rows.

the relationships between xbtrows are determined by XML Schema Data Types, as described 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:

• Finally, bdt_pri_restri and bdt_sc_pri_restri tables have the domain restrictions of BDTs to define value domains of BBIE and BBIE_SC.

Top-Level ASBIEP and other Business Information Entities (BIEs)

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 tables.

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 Score application logics for various purposes, such as the BIE expression.

In addition, it operates for ‘Reused BIE’ which is a function to embed pre-profiled BIEs into the current BIE. It can be checked 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.

SELECT `asbie`.* FROM `asbie` 
JOIN `asbiep` ON `asbie`.`to_asbiep_id` = `asbiep`.`asbiep_id` 
WHERE `asbie`.`owner_top_level_asbiep_id` != `asbiep`.`owner_top_level_asbiep_id` AND
`asbie`.`owner_top_level_asbiep_id` = ?;

Release and Core Component Manifests

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

Each CC table (ACC, ASCC, BCC, ASCCP, BCCP, and DT) 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.

Suppose that we had Location ACC in Release ‘10.0’ as below.

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

From these datasets, we could get a set of ACCs in each release through the following query:

SELECT `acc`.* FROM `acc`
JOIN `acc_manifest` ON `acc`.`acc_id` = `acc_manifest`.`acc_id`
JOIN `release` ON `acc_manifest`.`release_id` = `release`.`release_id`
WHERE `release`.`release_num` = ?;

The query result would be

when release_num is ‘10.0’ in the query parameter; and

when release_num is ‘10.1’.

Moreover, each BIE table is associated with these manifest tables, not directly with CC tables, because BIEs 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 structure that Score uses to express schemas into the 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 each module set is associated with manifests. The following diagram shows these relationships.

Every module-manifest relational table 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.

Note that there are no module-manifest relational tables for ASCC and BCC. Because, all associations in ACCs should be in the same module where the ACC is assigned. Also, dependencies between modules are not managed in the database structure, because it can be logically calculated by components' relations. Suppose that ‘Party’ ACC has ‘Name’ BCCP.

If we want to assign ‘Party’ ACC into ‘Component’ module and ‘Name’ BCCP into ‘Field’ module,

module_acc_manifest and module_bccp_manifest would look like below.

In this case, ‘Component’ module should have a reference to ‘Field’ module to refer ‘Name’ BCCP for ‘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 ‘Field’ schema.

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 table.

seq_key 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 seq_key. Suppose that ‘Party’ ACC had the following ASCCs with unique numeric numbers for sequencing keys.

It can be rewritten with seq_key, as follows:

Now, all (traverse/insert/remove) operations in seq_key follow the same logic in doubly linked list.

Business Contexts

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