CS Resource Entities & Relationships

A breakdown of the structure of Agencies, Sites, Services, and Resources within the CS Resource application.

Hierarchical Structure

When delving into resource, the core components (entities & relationships) can best be understood hierarchically:

Organization (Your Organization)
  └── Agency (Service provider agencies listed in your database)
       ├── Site
       │    └── Service
       └── Service
            └── Resource (Site + Service)

Resource Creation Logic

Resource =  Site (required) + Service (required)

Example Flow:

  1. Agency: "Homeless Services Network" (created within the organizations resource database)

  2. Site: "Downtown Shelter" (created under agency)

  3. Service: "Emergency Shelter" (created under agency/site)

  4. Resource: "Downtown Shelter - Emergency Shelter" (created by combining site/service)

Example Entry:

Resource Entities Overview

Entity
Purpose
Scope
Example

Agency

Service provider name

High-level

"Homeless Services Network"

Site

Physical/virtual location

Location-specific

"Downtown Shelter" at 123 Main St

Service

Type of service offered

Service type

"Emergency Shelter"

Resource

Service being provided at physical/virtual location

Specific entity

"Downtown Shelter offers Emergency Shelter"

Summary of entity contents

For full list of fields and definition see Entity Definitions & Fields

Agency (Total: ~40+ fields)

Core Identity: id, name, description, alias Organization Info: organizationId, agencyType, legalStatus, status Financial: annualBudget, federalEIN, irsTaxCode, yearIncorporated Leadership: directorName, directorTitle Relationships: parentAgency, sites[], services[] Contact Info: addresses[], emails[], phones[], contactPersons[] Other: url, hour, references[], metadata

Site (Total: ~25+ fields)

Core Identity: id, name, description, alias Relationships: organizationId, agencyId, agency (nested) Status: status Contact Info: addresses[], emails[], phones[], contactPersons[] Other: url, hour, references[], annotations[], metadata

Service (Total: ~30+ fields)

Core Identity: id, name, description, alias Relationships: organizationId, agencyId Classification: airsTaxonomyId, metadata.airsTaxonomy Status: status Geographic: geoArea Legacy: metadata.serviceNeed (deprecated) Contact Info: emails[], phones[], contactPersons[] Other: hour, references[], annotations[], metadata

Resource (Total: ~35+ fields)

Core Identity: id, description, alias Relationships: organizationId, serviceId, siteId, agencyId Nested Objects: service (full), site (full), site.agency (full), organization Status: status, visibility, limitedAvailability Service Area: metadata.serviceAreaName[], metadata.serviceAreaRegion[], metadata.serviceAreaZipCodes[] Service Details: metadata.fees, metadata.applicationProcedure, metadata.serviceRequirements, metadata.serviceExclusions, metadata.serviceConditions Contact Info: addresses[], emails[], phones[], contactPersons[] Other: hour, references[], networks[], area (null)

Detailed Relationship Matrix

1. Organization → Agency

  • Type: One-to-Many

  • Constraint: Each agency belongs to exactly one organization

  • Example: "211 Los Angeles" organization has "Homeless Services Network" agency

2. Agency → Site

  • Type: One-to-Many

  • Constraint: Each site belongs to exactly one agency

  • Example: "Homeless Services Network" has "Downtown Shelter" and "Westside Outreach" sites

3. Agency → Service

  • Type: One-to-Many

  • Constraint: Services must belong to an agency

  • Example: "Homeless Services Network" offers "Emergency Shelter" and "Food Assistance" services

4. Site → Service

  • Type: One-to-Many

  • Constraint: Services can belong to a site

  • Note: Services belong to an agency, but can be site-specific

  • Example: "Downtown Shelter" site offers "Emergency Shelter" service

5. Service → Resource

  • Type: One-to-Many

  • Constraint: Resources require site + service combination

  • Formula: Resource = Site + Service

  • Example: "Emergency Shelter" service at "Downtown Shelter" site creates a resource

Site → Resource (via references)

  • Type: One-to-Many

  • Relationship: Resources reference site via siteId

  • Note: Site is required for resource creation

Inheritance Logic between entities

Inherited fields follow the hierarchical structure in the sense that only lower entities can inherit information from higher level entities. Inheritable fields, at each entity level, can be seen in the diagram below:

Visual Relationship Diagram

  • Note on Diagram: Each entity has set minimum field requirements for creation. The diagram displays both inherited fields and minimally required fields for entity creation.

Last updated

Was this helpful?