Links / Relationships
Overview
Links define relationships between entities in your data model, establishing how different business objects connect to each other. They create the foundation for data navigation, enforce referential integrity, and enable users to move seamlessly between related information.
Links interface showing relationship configuration between entities
Link Definition Properties
Link Name
- Purpose: Unique identifier for the relationship
- Requirements: Must be unique and contain no spaces
- Naming Convention: Use descriptive names that indicate the relationship (e.g., "CustomerProject", "OrderItem")
- Best Practice: Combine the entity names to clearly show the relationship direction
Entity From
- Purpose: The source entity in the relationship
- Function: Defines which entity the link originates from
- Example: In a Customer-Project relationship, "Customer" would be the "Entity from"
Entity To
- Purpose: The target entity in the relationship
- Function: Defines which entity the link points to
- Example: In a Customer-Project relationship, "Project" would be the "Entity to"
Cardinality
- Purpose: Define how many related records are allowed
- Zero (0): Unlimited relationships - no limit on the number of related records
- Positive Number: Specific limit on the number of related records
- Example: Customer can have unlimited projects (cardinality = 0) or maximum 5 projects (cardinality = 5)
- Business Rules: Enforces business constraints at the database level
Exclusive
- Purpose: Define if the relationship is exclusive (one-to-one)
- When Activated: The target entity can be associated with only one source entity
- Example: If exclusive is activated for CustomerProject, each Project can belong to only one Customer
- Database Impact: Changes where the foreign key is stored - it moves to the "Entity to" table, ensuring only one associated "Entity from" record
- Use Cases: One-to-one relationships, unique ownership scenarios
Field Name (Optional)
- Purpose: Override the default foreign key field name
- Default Behavior: Opadeez automatically creates a field name if not provided
- Use Cases: Integration with existing databases, specific naming requirements
- Best Practice: Only specify when necessary for database compatibility
Foreign Key Placement
The location of the foreign key depends on the cardinality and exclusivity settings:
| Cardinality | Exclusive = No | Exclusive = Yes |
|---|---|---|
| 0 (many) | Entity From | N/A |
| 1 | Entity From | Entity To |
| >1 | Entity From | N/A |
Note: Foreign key is placed in "Entity From" by default, except when cardinality=1 and exclusive=true, where it moves to "Entity To". N/A indicates impossible combinations (exclusive relationships with multiple cardinality).
Relationship Types and Examples
One-to-Many Relationships
Most common relationship type where one entity can have multiple related entities:
Customer-Project Example
- Link Name: CustomerProject
- Entity From: Customer
- Entity To: Project
- Cardinality: 0 (unlimited projects per customer)
- Exclusive: True (each project belongs to only one customer)
Order-OrderItem Example
- Link Name: OrderItems
- Entity From: Order
- Entity To: OrderItem
- Cardinality: 0 (unlimited items per order)
- Exclusive: True (each item belongs to only one order)
One-to-One Relationships
Exclusive relationships where entities have a unique connection:
Employee-EmployeeProfile Example
- Link Name: EmployeeProfile
- Entity From: Employee
- Entity To: EmployeeProfile
- Cardinality: 1 (one profile per employee)
- Exclusive: True (each profile belongs to only one employee)
Many-to-Many Relationships
Complex relationships where entities can have multiple connections:
Student-Course Example
- Implementation: Requires an intermediate entity (StudentCourse)
- Link 1: Student → StudentCourse (cardinality: 0, exclusive: false)
- Link 2: Course → StudentCourse (cardinality: 0, exclusive: false)
- Result: Students can enroll in multiple courses, courses can have multiple students
Database Implementation
Foreign Key Creation
- Automatic Generation: Opadeez automatically creates foreign key fields
- Naming Convention: Typically uses the target entity name + "ID"
- Data Type: Matches the primary key type of the target entity
- Indexing: Foreign keys are automatically indexed for performance
Referential Integrity
- Constraint Enforcement: Database constraints prevent orphaned records
- Cascade Options: Define behavior when parent records are deleted
- Data Validation: Ensures all foreign key values reference valid records
- Business Rules: Cardinality and exclusivity rules are enforced
Navigation and User Experience
Data Navigation
- Hierarchical Views: Users can navigate from parent to child entities
- Related Data Access: Easy access to connected information
- Breadcrumb Navigation: Clear path showing relationship hierarchy
- Context Preservation: Maintain context when moving between related entities
DataSet Integration
- Tree Structure: Links define the structure of DataSets
- Entity Relationships: DataSets use links to create navigable data views
- User Interface: Links determine how data is presented to users
- Access Patterns: Define common data access patterns for applications
Best Practices
Link Design
- Clear Naming: Use descriptive names that indicate the relationship purpose
- Logical Direction: Define links from parent to child entities
- Cardinality Planning: Set appropriate limits based on business rules
- Exclusivity Consideration: Use exclusive relationships judiciously
Performance Optimization
- Index Strategy: Foreign keys are automatically indexed
- Query Optimization: Well-designed links improve query performance
- Data Loading: Opadeez uses lazy initialization internally
- Relationship Depth: Avoid overly complex relationship chains
Data Integrity
- Referential Integrity: Ensure all foreign keys reference valid records
- Cascade Rules: Define appropriate cascade behavior for deletions
- Business Rules: Use cardinality and exclusivity to enforce business constraints
- Data Validation: Implement validation rules for relationship constraints
Common Patterns
Master-Detail Relationships
- Invoice-InvoiceItem: One invoice has many line items
- Customer-Order: One customer can have multiple orders
- Product-ProductVariant: One product can have multiple variants
Hierarchical Relationships
- Employee-Manager: Self-referencing relationship for organizational hierarchy
- Category-Subcategory: Nested category structures
- Location-Sublocation: Geographic or organizational hierarchies
Association Relationships
- User-Role: Many-to-many through UserRole entity
- Product-Supplier: Many-to-many through ProductSupplier entity
- Project-Resource: Many-to-many through ProjectResource entity
Troubleshooting Common Issues
Cardinality Violations
- Problem: Attempting to create more relationships than allowed
- Solution: Review cardinality settings and business requirements
- Prevention: Set appropriate cardinality limits during design
Exclusivity Conflicts
- Problem: Trying to associate exclusive entity with multiple parents
- Solution: Review exclusivity settings and data model design
- Prevention: Carefully plan exclusive relationships
Circular References
- Problem: Creating circular relationship chains
- Solution: Redesign relationships to avoid circular dependencies
- Prevention: Plan relationship hierarchy carefully
Getting Started
Ready to create entity relationships? Follow these resources:
- Your First Application - Part 3: Step-by-step tutorial for creating links
- Entities & Attributes: Create entities before defining relationships
Related Topics
- Data Dictionary Overview: Understanding the complete data model
- Entities & Attributes: Create entities and attributes first
- Basic Concepts: Fundamental Opadeez terminology
Pro Tip: Start with simple one-to-many relationships, then add complexity as needed. Well-designed links are the foundation of intuitive data navigation and user experience.