Database Schema #57
-
|
Thread for all database schema finalization. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 26 replies
-
|
No documentation to go with it yet, so no cookie for me, but I think I've put together a good foundation that we can throw the documentation on top of. I know @jmyrick02 has said he has a good deal of documentation done already, so perhaps he can apply/adjust that to fit this? I'm open to changing anything I've provided in the above document, but I think it's adherent to the agreements we've come to. |
Beta Was this translation helpful? Give feedback.
-
|
*Also note I've trimmed the |
Beta Was this translation helpful? Give feedback.
-
|
Could you post that on this thread and organize it similar to #10 please. |
Beta Was this translation helpful? Give feedback.
-
|
I'm currently working on the documentation in the format of #10. |
Beta Was this translation helpful? Give feedback.
-
CourseOverviewThe Object RepresentationCourse = {
"_id": ObjectId,
"course_number": string,
"subject_prefix": string,
"title": string,
"description": string,
"school": string,
"credit_hours": string,
"class_level": string,
"activity_type": string,
"grading": string,
"internal_course_number": string,
"prerequisites": CollectionRequirement,
"corequisites": CollectionRequirement,
"lecture_contact_hours": string,
"laboratory_contact_hours": string,
"offering_frequency": string,
"attributes": Object,
}Properties
SectionOverviewA Object RepresentationSection = {
"_id": ObjectId,
"section_number": string,
"course_reference": ObjectId,
"section_corequisites": CollectionRequirement,
"academic_session": AcademicSession,
"professors": Array<ObjectId>,
"teaching_assistants": Array<Assistant>,
"internal_class_number": string,
"instruction_mode": string,
"meetings": Array<Meeting>,
"syllabus_uri": string,
"grade_distribution": Array<number>,
"attributes": Object,
}Properties
ExamOverviewAn Object RepresentationExamType = "AP" | "ALEKS" | "CLEP" | "IB" | "CS placement"
abstract Exam = {
"_id": ObjectId,
"type": ExamType,
"yields": Dictionary<int, Array<ObjectId>>,
}
APExam extends Exam = {
"_id": ObjectId,
"type": "AP",
"name": string,
"yields": Dictionary<int, Array<ObjectId>>,
}
ALEKSExam extends Exam = {
"_id": ObjectId,
"type": "ALEKS",
"yields": {},
}
CLEPExam extends Exam = {
"_id": ObjectId,
"type": "CLEP",
"name": string,
"yields": Dictionary<int, Array<ObjectId>>,
}
IBExam extends Exam = {
"_id": ObjectId,
"type": "IB",
"name": string,
"level": string,
"yields": Dictionary<int, Array<ObjectId>>,
}
CSPlacementExam extends Exam = {
"_id": ObjectId,
"type": "CS placement",
"yields": {70: [CS1336._id, CS1136._id]},
}Properties
Academic SessionOverviewAn Object RepresentationAcademicSession = {
"name": string,
"start_date": string,
"end_date": string,
}Properties
AssistantOverviewAn 'Assistant' represents a teaching assistant at UT Dallas. Object RepresentationAssistant = {
"first_name": string,
"last_name": string,
"role": string,
"email": string,
}Properties
MeetingOverviewA 'Meeting' represents a recurring meeting. This schema can represent both recurring meetings and single meetings. Meetings occur repeatedly on the specified days of the week during a period. Non-recurring meetings should have the Object RepresentationModalityType = "pending" | "traditional" | "hybrid" | "flexible" | "remote" | "online"
Meeting = {
"start_date": string,
"end_date": string,
"meeting_days": Array<string>,
"start_time": string,
"end_time": string,
"modality": ModalityType,
"location": Location,
}Properties
ProfessorOverviewA Object RepresentationProfessor = {
"_id": ObjectId,
"first_name": string,
"last_name": string,
"title": string,
"email": string,
"phone_number": string,
"office": Location,
"profile_uri": string,
"office_hours": Array<Meeting>,
}Properties
LocationOverviewA location on the UT Dallas campus. Object RepresentationLocation = {
"building": string,
"room": string,
"map_uri": string,
}Properties
RequirementOverviewA 'Requirement' represents a requirement that can be satisfied. This is probably the most important concept in the API and also has the most cognitive overhead. Course RequirementA Section RequirementA Exam RequirementAn Major RequirementA Minor RequirementA GPA RequirementA Consent RequirementA Collection RequirementA For example, a As a more real example, consider the prerequisites for the course CS 3305. It requires CE 2305 or CS 2305 or TE 2305 with a grade of C or better and MATH 2414 or MATH 2419. This would be represented as a Hours RequirementAn Other RequirementAn Object RepresentationRequirementType = "course" | "section" | "exam" | "major" | "minor" | "gpa" | "consent" | "collection" | "hours" | "other"
abstract Requirement = {
"type": RequirementType,
}
CourseRequirement extends Requirement = {
"type": "course",
"class_reference": ObjectId,
"minimum_grade": string,
}
SectionRequirement extends Requirement = {
"type": "section",
"section_reference": ObjectId,
}
ExamRequirement extends Requirement = {
"type": "exam",
"exam_reference": ObjectId,
"minimum_score": number,
}
MajorRequirement extends Requirement = {
"type": "major",
"major": string,
}
MinorRequirement extends Requirement = {
"type": "minor",
"minor": string,
}
GPARequirement extends Requirement = {
"type": "gpa",
"minimum": number,
"subset": string,
}
ConsentRequirement extends Requirement = {
"type": "consent",
"granter": string,
}
OtherRequirement extends Requirement = {
"type": "other",
"description": string,
"condition": string,
}
CollectionRequirement extends Requirement = {
"type": "collection",
"name": string,
"required": number,
"options": Array<Requirement>,
}
HoursRequirement extends Requirement = {
"type": "hours",
"required": number,
"options": Array<CourseRequirement>,
}Properties
DegreeOverviewA Object RepresentationDegreeSubtype = "major" | "minor" | "concentration"
Degree = {
"_id": ObjectId,
"subtype": DegreeSubtype,
"name": string,
"abbreviation": string,
"minimum_credit_hours": number,
"requirements": CollectionRequirement,
}Properties
|
Beta Was this translation helpful? Give feedback.
-
|
I think the problem with representing the objects as raw objects with no inter-type relationships is that it gets difficult to describe some things. For example, the I'm open to using syntax other than Edit: I do think that it's not clear that the base classes not meant to be initialized in the database so perhaps we should add an |
Beta Was this translation helpful? Give feedback.
-
|
When you guys finalize the schemas, please use something similar to drawsql which @jmyrick02 linked above. However, do not save this documentation as an image. We need to be able to change it later as we get more data and the scope of what the API provides may change. |
Beta Was this translation helpful? Give feedback.
-
|
I think the current schema is readable by people who are not familiar with typescript and gets the point across which is what we want. I sympathize with Josh as this will be useful, so @hochladen post the schema using proper typescript. |
Beta Was this translation helpful? Give feedback.
-
|
I will concede that it is helpful to be able to see the type relationships, which is one of the reasons I was trying to advocate for presenting the TypeScript representations of the objects, as one of the main purposes of TypeScript is to allow for effectively typing JSON (which is precisely what MongoDB will be storing). TypeScript's syntax makes the types, relationships, and structure of objects clear as far as both implementation and object representation are concerned. That being said, I would be willing to compromise so long as we are in agreement that the TypeScript representations need clear documentation somewhere, which we seem to be. |
Beta Was this translation helpful? Give feedback.
-
|
Overall, I'm proud of what we've been able to develop over the past few days, and think this will be a major step in the right direction. I will write up a full typescript-formatted version of this documentation tomorrow, as I do not think it's immediately necessary (and I'm tired lol). Good work everyone :) |
Beta Was this translation helpful? Give feedback.
-
|
Athena has expressed a desire for API data aggregation and to enable data over time analysis. Data over time analysis can be resolved with, and aggregating around, the 'academic_session' properity of sections. We do not handle 8 week sessions well at the moment!! They also want aggregates for Courses to Sections. Professors to Courses and Professors to Sections. I propose the following additions to the schema: CourseSection = {
"course": Course,
"academic_session_name": string,
"sections": Array<Section>
}
ProfessorCourses = {
"professor": Professor,
"courses": Array<CourseSection>
}We may want to swap for ObjectId's, idk.. have to get to class so this is somewhat half-baked, I will finish this later :) |
Beta Was this translation helpful? Give feedback.
-
|
I may have misled you @AdamMcAdamson if I misunderstood Eric and Charlie's suggestion. I apologize if that's the case. Courses having references to their sections could be useful, although currently I believe no other Nebula projects would have a direct use case for that. It may be justified in adding since it would probably come up as a requested feature eventually. |
Beta Was this translation helpful? Give feedback.
-
|
@AdamMcAdamson You're correct about courses not currently referencing their sections. I had proposed such in some of my schema proposals, and still think there's pretty much no downside to including them (i.e. by adding a |
Beta Was this translation helpful? Give feedback.
-
|
Okay, then yeah, I think we should do that too. I will include in the endpoints discussion a potential solution for handling aggregation and lookups. |
Beta Was this translation helpful? Give feedback.
-
|
Also, upon doing more research about the usage of MongoDB's |
Beta Was this translation helpful? Give feedback.
-
|
As noted in #82: Also, there are a few 'or' conditions across the exams, which are not handled (AP Math and 2 IB Math exams). Any comments on how/if we should handle them would be greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
There are some requirements in certain Major degree plans that are more difficult to validate. Below are two instances of this: History major requirement Economics and Finance Double Major Requirement To handle these kinds of edge cases, I propose adding the following properties to CollectionRequirements:
The "selfValidate" field denotes whether or not the user will have to validate that their degree plan satisfies the following CollectionRequirement. This will be set to "true" whenever edge cases requirements are encountered. The "description" field will contain information about how to fulfill a certain CollectionRequirement. This will only be used for edge cases. Below is an example description from the Economics and Finance example.
Please let me know what you guys think about the proposed change. |
Beta Was this translation helpful? Give feedback.
-
|
We currently have the |
Beta Was this translation helpful? Give feedback.
-
|
Okay cool that makes sense; that should work on the Planner side. Thanks! |
Beta Was this translation helpful? Give feedback.
Course
Overview
The
Courseobject represents a course available at the University of Texas at Dallas. ACourseshould not be confused with aSectionwhich is the actual instantiation of aCoursewith a professor and dedicated meeting times.Object Representation