Model Program Offerings

Model Program Offerings

Several objects that share a theme of "programs" let you model your institution's academic and other offerings—namely an Account record type called Academic Program, the Program Plan object, and the Plan Requirement object. Use this set of objects to track how your learning offerings are structured and administered, and what they require for enrollment and completion.

Programs, defined liberally, can be degree or credential programs, academic support programs, recreational programs, continuing ed, and more—all across the lifelong learning continuum. But we can use the same architectural building blocks to model them in EDA. As we look at these sample data structures for a degree program and an after-school program, consider the possibilities that they suggest for modeling your institution's own offerings.

A Sample Degree Program Offering

The Biological Sciences Department at Connected University offers an undergraduate Biology degree. Account records represent these entities.

• Connected University is an Account with the Educational Institution record type.

• The Biological Sciences Department is an Account with the University Department record type.

• The BS Biology degree is an Account with the Academic Program record type. The Biological Sciences Department administers this degree, so the Academic Program's parent Account is the Department's Account record.

In order to earn the BS Biology degree, students must complete a sequence of study prescribed in the university's course catalog. These high-level requirements for the major are organized using the Program Plan object. For the student cohort enrolling in the 2020-2021 academic year, a Program Plan record named Biology Catalog Year 2020/2021 represents the set of requirements in effect at that time—indicated by the Is Primary field. Program Plans have a limited shelf life. By the time Connected University finalizes its catalog for the next academic year, requirements have usually changed slightly and are then captured in another Program Plan record named Biology Catalog Year 2021/2022.

So the Program Plan object represents a general set of requirements, while the Plan Requirement object represents specific requirements, such as specific Courses, thesis work, an internship, and so on. Plan Requirement records are typically part of a hierarchy. Parent Plan Requirements organize higher-level categories. Underneath, child Plan Requirements can be nested at multiple levels to detail the specifics.

For Biology Catalog Year 2020/2021, here's a partial snapshot of the Plan Requirements hierarchy in effect for Biology undergrads who enrolled under that Program Plan. We've excluded some details for simplicity.

• Lower Division (72 units)

  • Core Sciences (56 units)

    • Biology (16 units)

      • BIO 10 (4 units)

      • BIO 20 (4 units)

      • ...

    • Chemistry (8 units)

      • CHEM 1A (3 units)

      • CHEM 1A Lab (1 unit)

      • CHEM 1B (3 units)

      • CHEM 1B Lab (1 unit)

    • Mathematics (8 units)

      • MATH 10 Applied Track (Optional)

        • MATH 10A (4 units)

        • MATH 10B (4 units)

      • MATH 20 Theory Track (Optional)

        • MATH 20A (4 units)

        • MATH 20B (4 units)

    • ...

  • General Electives (12 units)

    • Lower Division Language (4 units; any qualifying Course)

    • Lower Division Arts & Humanities (4 units; any qualifying Course)

    • Lower Division Social & Behavioral Sciences (4 units; any qualifying Course)

  • Service Learning (4 units; equivalent to 80 service hours)

• Upper Division (48 units)

  • ...

A Sample After-School Program Offering

At Daisy Bates Academy, the Extended Day Support Program offers after-school enrichment. Account records represent these entities.

• Daisy Bates Academy is an Account with the Educational Institution record type.

• The Extended Day Support Program is an Account with the Academic Program record type. Daisy Bates Academy administers this program, so the Academic Program's parent Account is the school's Account record.

For the 2020-2021 academic year, a Program Plan record named Extended Day 2020-2021 represents that year's after-school offerings—indicated by the Is Primary field. The Extended Day Support staff meet at the end of the school year to review and tweak the next year's programming, which means that the Extended Day 2021-2022 Program Plan is going to be even more responsive to students' needs.

So the Program Plan object represents either a general set of requirements or programs, while the Plan Requirement object represents either specific requirements or specific tracks within a program. Plan Requirement records are typically part of a hierarchy. Parent Plan Requirements organize higher-level categories. Underneath, child Plan Requirements can be nested at multiple levels to detail the specifics.

For the Extended Day 2020-2021 Program Plan, here's a partial snapshot of the after-school program's Plan Requirements hierarchy. We've excluded some details for simplicity.

• After-School Learn

  • Tutoring

    • 1:1 Tutoring

    • Group Tutoring

  • Drop-In Workshops (Optional)

    • Chess (Optional)

    • Art Studio (Optional)

    • Writing (Optional)

    • Gaming Garage (Optional)

    • Outdoor Explorers (Optional)

  • Mentoring (Optional)

  • Therapeutic Learning (Optional)

• After-School Refuel and Nutrition

  • Meal Supplement Program

    • Standard Meal Supplement (Optional)

    • Special Diet (Optional)

  • Nutrition in the Kitchen (Optional)

• After-School Recreation and Fitness

  • Basketball (Optional)

  • Martial Arts (Optional)

  • ...

Go Beyond the Basics of Plan Requirements

As you can see from our examples, different flavors of Plan Requirement records make up the hierarchy—parent or nested, required or optional, and related to a specific Course or unrelated to a specific Course. In this general orientation to the EDA data model, it's beyond our scope to cover the details of creating all these records in the correct combinations.

When you're ready to design your actual Plan Requirements hierarchy, see the detailed examples and scenarios at Plan Requirement.