Appendix A: Q&A

1. Are the naming conventions used in this data model generally accepted in fields outside of education?
   

   Naming of classes, entities, and attributes in the Data Model was influenced by the well-documented and accepted ISO/EEC 11179 standards. For example, the Education Data Model hierarchy has the following properties:

   • Unique names
   • Many items that follow the multi-part naming convention, i.e., [Object] [Qualifier] Property RepresentationTerm
   • A classification framework in which items can be located using dot notation, such as classname.classname.entity.attribute

   Also, class names begin with a capital letter and contain no spaces; entity and relationship names begin with a lower-case letter, followed by camel case, with no spaces; attribute names contain spaces and are capitalized. For example, Person and Client are classes, libraryPatron is an entity, and Library Patron Name is an attribute.
   
   

2. Couldn't some items be an entity and attribute at the same time?
   Yes. For example, a person listed in a discipline incident could have a victim attribute or a perpetrator attribute; or, we could model the role of victim as an entity. In this case, this is essentially the relationship between a discipline incident and a victim. Attributes of this entity might include injuries sustained and the victim's description of the incident. The Data Model strives to reflect consistent decisions with respect to such issues.
   
   
3. Why not just use entity relationship (ER) diagrams or a UML object diagram?
   These types of diagrams are used to represent logical or physical models. The Education Data Model is a conceptual map (ontology) with the addition of attribute detail that cannot be represented using ER diagrams or UML object diagrams.
   
   
4. How specific are the entities? When do we stop creating classes based on different types and create an entity?
   

   In creating the taxonomy, a number of questions arose concerning the scope and depth of the taxonomy. For example, where do we draw the line between classes and entities? Is "science teacher" an entity in the class of teachers? Or is teacher an entity and the "Subject Taught" a characteristic (attribute) of teachers? Is a "warehouse" a type of building (that is, a coded value in a code set for building type)? Or is a warehouse a separate entity in a class of buildings?

   A subjective criterion for creating a lower level entity might be that characteristics of the lower level item must be significantly different from the parent item. Another view might be that characteristics of the child item must be a significant addition to the parent characteristics. So teacher is a type of person and is a child of the class of persons because the characteristics for teachers are a significant addition to the person attributes.

   In order to clarify the distinction between a class and an entity, the following guidelines were used in developing the Data Model:

   Entity

   • An entity may represent a table in an ER design.
   • An entity may represent a class (not an instance) in an object-oriented (OO) design. The word "class" has a different meaning in OO design than in the Data Model.
   • An entity should fit as part of the collection of entities that make up a class.
   • The entities in a class do not make up the complete set of possible entities for the class. In reality, there are an infinite number of possible entities for each class.

   Class

   • Classes represent concepts.
   • Sub-classes make up the complete set within their class. For example, Area and Location make up the complete set of Places in the Data Model.

   As an example, there are two teacher-type entities located within the taxonomy in the following way:

   Person → Provider → Teacher
   Person → Provider → Substitute Teacher

   Then shouldn't we also have:

   Person → Provider → Teacher → High School Teacher?

   or,

   Person → Provider → Certified Teacher?

   One guideline to use in deciding whether to create the next level of detail, or whether to create a variation of an entity, involves anticipating when a different table for the concepts would be used in a physical or logical model.

   Is it reasonable to think that teachers and substitute teachers would be tracked in two separate tables? The answer, in this case, is yes because substitute teachers are different enough from regular teachers that they are typically tracked by different systems or by different rules.

   On the other hand, high school teachers and middle school teachers would best be tracked in a single table with a coded field that indicates the level of their teaching assignment. Similarly, certified teachers could be tracked as a status field in a teacher table or as a link to a certifications table.

   
   

   Top