Understanding Workday’s Data Model

• Object-Oriented: Workday doesn’t use a traditional relational database with tables. Instead, it has an object-oriented data model. Think of these objects as real-world entities with attributes and relationships. Examples:
  • Worker: Represents an employee, contingent worker, etc.
  • Position: Represents a job role in the organization.
  • Organization: Represents a department, division, etc.
• Business Objects: Workday’s core ‘entities’ are called Business Objects. Each has a defined set of fields (attributes).
• Relationships: Workday defines how Business Objects relate to each other, forming a complex web of connections.

Key HCM Business Objects (Simplified)

• Worker: Central object, includes personal data, job information, compensation, etc.
• Position: Job roles within the organization, links to supervisory organizations.
• Organization: Hierarchical structure of departments, cost centers, locations, etc.
• Supervisory Organization: Specifically highlights reporting relationships.
• Job Profile: Template for positions, defining skills, requirements, etc.
• Compensation: Salary, bonuses, benefits tied to a worker.

ERD Considerations

• Complexity: Workday’s ERD is extremely complex due to the object model and the sheer number of Business Objects with many interconnections. A full diagram would be very intricate.
• Focus: Instead of trying to map the entire model, focus on the specific area of HCM you’re interested in (e.g., Recruiting, Payroll, Benefits, etc.). This will make the ERD more manageable.
• Levels of Detail: You can create ERDs at different levels – conceptual (high-level) to very detailed representations of specific objects and their fields.