Sections

Scope

Determine whether there are any sections that should be excluded from your imports to Core Data based on local practices or usage goals. For example, you may or may not want to include sections with no student enrollments, depending on your analytical goals. Work with the functional leaders on your campus to determine what sections to exclude and how to identify them in the data.

SectionIdentifier Source

Build SectionIdentifiers based on the term identifier, subject/department code and course number, and section identifiers rather than using system generated identification numbers to ensure uniqueness and avoid duplicates. The section identifiers defined in this file are also used to link student enrollments and instructor teaching assignments. These identifiers MUST be present in the SIS in a way that can be mapped to enrollments and instructor assignments. When building the Sections file, assess which identifiers are used on the tables that define enrollments and instructors.

Data Relationships

The Sections file references three other identifiers that are defined in other files: TermIdentifier, CourseIdentifier, and OrgUnitIdentifier. These identifiers must either be present on the sections tables or be able to be mapped through another table or view to match the identifiers used in the Academic Terms, Courses, and Organizational Units files.

Start and End Dates

Evaluate the completeness of section start and end dates in your data. Determine whether these should default to the term start and end dates if dates are missing from the section data.

DeliveryMode Mapping

The sections import only accepts 3 enumerated values for DeliveryMode: Face2Face, Hybrid, and Online. These values need to be mapped from the codes used in the SIS using case statements in the SQL scripts. The exact mapping depends on your institution’s usage of these codes in the SIS and how classes are delivered on your campus. Evaluate any fields related to delivery mode in your data and use them to guide your decision-making process.

Crosslisting

The crosslisting field is commonly used to relate sections to each other for course evaluation administration and reporting, particularly when each sections has too few students enrolled to permit reporting on the section individually. Discuss the need for section crosslisting with your consultant. The same identifier should be put in the "CrossListingIdentifier" column in order to cross-listed sections together. To remove a cross-listing from a section import the "Sections" file with the section you would like to remove the cross-listing from and leave the "CrossListingIdentifier" field blank. For more information about how cross-listings are used within Evaluate:Cross-Listed Course Sections. For more information about how cross-listings are used within Outcomes see Academic Program File.

Term Logic

Term logic for Sections depends on when data for a given term needs to be available in the system, and what kind of data your institution hopes to capture. For the fullest analytical view of enrollment changes and melt, scripts should be written to begin extracting sections as soon as registration for that term opens. That way, sections are available in Core Data to begin linking adds and drops through the Enrollments file. The Section term logic should then run through the end of the term, so that any changes to section data that happen throughout this time period will be brought over each night.