In Sanka, associations between objects are represented as "associations."
Unlike traditional RDBs, where foreign keys are embedded directly in records, Sanka treats the relationships themselves as independent objects.
This section will clarify what associations are, how this differs from conventional PK/FK-based design, and the role of association labels.
In Sanka, associations are managed using the following two-layer structure.
Fields: Label, Source Object, Target Object, Type, Creator, Creation Date etc.
Role: Metadata that expresses “which objects are linked, under what name and constraints.”
Source Object / Target Object contain objects such as Order or Contact, and are used for candidate control in the UI.
Type toggles between One-to-One / Many-to-Many, restricting selection in the UI and service layer.
Mechanism: Connects arbitrary object records via a unique ID.
Design options such as One-to-One, One-to-Many are available.
By using association labels, it is also possible to adjust the designation, for example, so that an Order appears from a Contact’s perspective, or a Customer from an Order’s perspective.
In other words, it is possible to manage the fact of "which records of which objects are associated with each other" by means of this association.
Add a foreign key (FK) column such as customer_id to the table schema, and the database ensures referential integrity.
Since relationships between tables are fixed at the schema stage, migration is required to add or modify relationships.
While joins and constraints are powerful, they lack flexibility when connecting different modules or custom objects after the fact.
Perspective | RDB PK/FK | Sanka Association |
Unit of Design | Table Definition and ID Column | Association management function for records expanded with an intermediate table |
Addition of Relationships | Migration Required | Immediate reflection by creating a label from UI/API |
Connectable Target | Fixed Two Tables | Any standard/custom object, linkage of multiple tables, control function |
Integrity Assurance | Assured by DB through FK constraints | Logic control at the application/UI layer |
Definition of Relationship Meaning | Dependent on column name (e.g., order_contact_id) | Multilingual and context-specific naming provided by labels |
Search/Aggregation | SQL JOIN as standard | Extraction per label, with RDB JOIN or API processing performed as needed |
Q. Is it necessary to enter the ID directly into the property?
With associations, simply adding a record enables the creation of a new relationship. In contrast, in RDB, adding a foreign key necessitates schema modifications and migrations, making it difficult to quickly provide custom relationships for each client.
Q. What is an association label?
A label defines what a particular relationship means and between which objects it is permitted. It centrally manages elements such as the display name in the UI, selectable targets, and one-to-many constraints.
Q. How is data integrity maintained?
Instead of rigid constraints such as foreign keys in an RDB, integrity is maintained through application-layer logic. It is also possible to reset specific labels or enforce uniqueness constraints.
Associations in Sanka are a mechanism that "expands and upgrades the relationships themselves."
Declare meaning and constraints via labels and store specific pairs as records.
As relationships can be flexibly reconfigured without schema changes, it is well suited for ERPs with many custom objects and external integrations.
