This version of the Ed-Fi Data Standard is no longer supported. See the Ed-Fi Technology Version Index for a link to the latest version.
Unifying Data Model - Design Patterns
- Ian Christopher
- Chris Moffatt (Deactivated)
- Richard Heim [X] (Unlicensed)
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 NEDM association labels, as follows:
Table 1: NEDM Association Labels and Definitions Adopted by the Ed-Fi Data Model
Label | Definition |
HasAssociated | The object entity has relationship to the associated subject entity |
HasCausalRelationship | A strong relationship in which one entity causes a change in another entity |
HasFunctionalComponent | Reflects the construction of an entity through functional components represented by other entities |
IsDirectProviderOf | Directly provides goods or services |
IsFunctionalComponentOf | This relation indicates that subject entity makes up, in part or in whole, the function of the object entity |
IsOrganizationalComponentOf | Used to indicate an organizational structure of non-person entities such as schools, districts, etc. |
ParticipatesIn | A person-type entity participates in an activity-type entity |
ProvidesServicesTo | Subject provides services to the object |
ReceivesServicesFrom | Subject receives services from the object |
Additional Ed-Fi association types are as follows: | |
Defines | Subject defines the data reflected by the object |
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 there is not an analogous name in CEDS, at which point the NEDM is considered
- If the CEDS or NEDM name does not reflect common terminology or is unnecessarily long
- When the CEDS or NEDM name conflicts with Ed-Fi naming structures and guidelines
By default, association names match those of the NEDM as described below:
- Associations with attributes are named by concatenating the two entities they relate 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.