Time
9 hours 41 minutes
Difficulty
Intermediate
CEU/CPE
10

Video Transcription

00:00
I welcome the module for this is less than 4.1 requirement review. And this lesson, we're gonna go over the applications summary form. This document will be available for download as well, and you can go ahead and pull it up if you'd like to preview it as we go through this slide.
00:16
Now, something to consider when reviewing this document is that requirements are often bag or not precise. We do want to be able to recognize models and concepts in descriptions when we see them.
00:28
This document describes the entire application in general and not just the database.
00:34
So something to keep in mind when dealing with these type of requirements is that customers are often not developers, and this can create a communication barrier.
00:43
Now the document that will be looking at describes an education database and some obvious models pop into my head. When I think of an education database, I think of users, students, courses, teachers, grades
00:58
And when I think of these models, I think can we simplify these models somehow,
01:03
uh, is a student. A user is a teacher, A user? Would we use separate tables? Would we use a type column on the user table.
01:11
Is the user polymorphic? And how would we represent that in a database? E. R D Diagram.
01:18
What type of relationship should we expect? One too many, many too many? Well,
01:23
honestly, if you're building any kind of database application that's going to even go into even a moderate level complexity, you really need to expect that all the relationships are going to show up now. With that said, let's take a look at the document that describes our application requirements,
01:38
and this is the application description document. This document will be available for download, so feel free to download it and print it out if you need.
01:47
So let's go ahead and walk through this.
01:49
The application description Management needs an application for a customer that is education centric. The application will provide users the ability to store and retrieve student data, teacher data course data and grades.
02:04
Teacher and students should be able to view information related to their data. For example, a teacher convey you their students. A student can view their courses and teachers specific details listed below
02:15
and the users paragraph. We could see that users all the application include administrative staff, students and teachers. Administrative staffs will be able to access all data and chain settings that define its student debt a teacher, data course data and student greats. Now, this is a great example
02:34
off something that doesn't really apply to us as the database designers is faras
02:39
function goes, we are gonna be responsible for controlling how administrative staff interact with the data. We, however, just gonna make sure that our database has the data that facilitates the decision making related to that function. For example, there
02:55
is going to be administrative staff, so there needs to be a way that our database
03:00
identifies a user as administrative staff.
03:05
The front end application designers would be worried about how the administrative staff moves through the application soas faras controlling how they interact and change data that would be in their domain. We just want to make sure that that data exists and it's something that they can actually do
03:23
because it's present in the database.
03:25
So moving on, students will be able to enroll in courses, view grades and view course data. Teachers will be able to view student data course enrollment information and view slash edit student grades that more or less falls in line with the the application developers handling the function.
03:44
We need to make sure the data is there to facilitate that function.
03:47
The next paragraph course data course data will include title category, building, room number, assigned instructors and students. Courses will have a maximum student limit that cannot be exceeded.
03:59
Courses will have a minimum that, if not reached, incurs cancellation off the course.
04:03
Students and instructors cannot enroll or teach in the same course in the same period more than once.
04:10
For example,
04:12
Student A cannot enroll in the same biology course twice during the same semester.
04:16
Now we're going to student data.
04:20
Student data will include name, address, phone number, grades, course enrollments, professors that have had instructed or are instructed the students in courses. Instructor Data Instructor Data will include name addresses, phone number
04:36
course assignments, students they have had or currently instructing.
04:42
So some obvious models it immediately popping in my head when I read through this description includes the courses that students the instructors, three users, the see the building in the room number. We really need to think about how
04:58
we're gonna combine those into one table or if we're going to need multiple tables like, Do we need a teacher table, a student table, a administrative staff table? Or is there a way to make that one table,
05:12
or is there a way to facilitate that in a relationship? Pivot? These are things that we want to consider and think about as we move through the lessons, we will identify and solve the problems effectively and efficiently. But be sure to think about it as well. How you might solve this problem or solve or create the database to facilitate
05:31
the needs of this document,
05:33
and that brings us to the requirement review summary. So what did we do in this lesson?
05:39
Well, we reviewed the requirement document. We tried to identify the models that we would need to facilitate the requirements in that document, and we also try to identify the relationships that we expect between those models. Now, be sure to read through the application description
05:56
and really think about the models and relationships that we would need to effectively and efficiently
06:01
implement the database that meets the requirements of that document and the next few lessons. We of course, they're going to be implementing the models in the relationships using R p HPR Titian development environment that we establish in the previous lessons. We'll think about that before we actually go through it
06:19
so that you can see if we solve the problem in the same way.
06:23
In any case, that completes this lesson and I hope to see you in the next thank you.

Up Next

Intermediate SQL

This free course introduces the student to intermediate concepts found in the implementation and application of Structured Query Language (SQL) within professional business environments.

Instructed By

Instructor Profile Image
Kitt Parker
Instructor