Design Patterns

This section explains the principles, patterns, and conventions used for the Ed-Fi Unifying Data Model and the associated XML Core Schema.

Ed-Fi Unifying Data Model

The Ed-Fi Unifying Data Model is a conceptual model, and a common framework for the representation of data in the education domain. The UDM serves as the enterprise data model from which is derived all other representations of the standard, including the Ed-Fi XML schema discussed herein.

Notation

The Ed-Fi Unifying Data Model is expressed as Unified Modeling Language (UML) Class diagrams to capture the logical structure of a domain as a set of classes, their features (attributes), and the relationships (associations) between them. UML Class diagrams are more useful than Entity-Relationship diagrams to understand the Ed-Fi Unifying Data Model because they support generalization of classes.

UML Diagram Conventions

In the Ed-Fi Data Model, classes represent the major entities or objects in the education domain, such as students, teachers, campuses, and locations. Additionally, classes model non-physical entities in the education space, such as courses, sections, attendance events, and discipline actions.

The class attributes represent properties or characteristics of entities that are important in the education domain. Complex attributes with many components are defined as separate classes and referenced as the type of the attribute. For example, the complex attribute type Address has the components street address, city, state, and ZIP code. Unless otherwise indicated, attributes are of cardinality 1, meaning that they are single-valued and required. Other cardinalities are shown within square brackets.

Relationships, or associations, represent logical connections between entities that are important in our education domain.

For example, students are associated with campuses through enrollment. The direction of an association indicates readability (as in Student HasAssociated School) in the domain model. The direction of the association has additional meaning in the XML Schema, indicating the class from which the relationship is specified. Cardinalities (e.g., 1-to-1, 1-to-many, many-to-many) are shown for all associations.

An association class is used when an association has attributes. For example, the date of enrollment is an important attribute of the Enrollment Association between student and campus.

A generalization association indicates that a more specialized subclass is a generalization of a broader superclass. For example, a campus or school is a specialization of the more general Education Organization. The attributes and associations defined for the superclass are inherited by the more specialized subclasses. The National Education Data Model (NEDM) relationship IsDerivedFrom has similar semantics. Generalization semantics are compatible with Type extensions in XML schemas.

Notes are included in the Ed-Fi Unifying Data Model to explain or elaborate on points not obvious from the UML model structure or class names.

Association Labels

The Ed-Fi Unifying Data Model uses a subset of the original NEDM¹ association labels, as follows:

Table 1: NEDM Association Labels and Definitions Adopted by the Ed-Fi Data Model

Naming Conventions

The Ed-Fi Data Standard naming conventions are detailed below. Consistent naming is used across all Ed-Fi data artifacts.

General naming conventions are as follows:

• Concatenated title case is used for entities, relationships, and attributes (e.g., “SchoolId”)
• Names use common terminology for the education industry

Generally, the entity and attribute names align with those of CEDS with the following exceptions:

• If the CEDS name does not reflect common terminology or is not applicable to all Ed-Fi community use cases impacted by the entity
• When the CEDS name conflicts with Ed-Fi naming structures and guidelines

By default, association names match those of the original NEDM as described below:

• Associations with attributes are named by concatenating the two related entities and ending with “Association;” for example: “StudentSchoolAssociation”
• When there can be two associations between the same pair of entities, a semantic discriminator is added; for example: StaffEducationOrganizationEmploymentAssociation, StaffEducationOrganizationAssignmentAssociation

The conventions recommended for implementation-specific extensions are as follows:

• Implementation-specific attributes are isolated into implementation-specific extensions of entities, labeled as EXTENSION-<EntityName or AssociationName>Extension
• Attributes that are identified for rework or later retirement are identified as a “Legacy” attribute (e.g., -EXTENSION-Legacy-<AttributeName>)

Extensions to the Ed-Fi Data Standard should carry forward the naming conventions. The same naming conventions apply to the Ed-Fi Unifying Data Model and the associated Ed-Fi XML Core Schema. Additional and specific rules for how the naming conventions apply to the XML Core Schema can be found in the XSD Authoring Guidelines technical article. 

¹ Note that the NEDM is no longer actively maintained, though its work has informed a variety of field work including the Ed-Fi Alliance standards.