7 hours 36 minutes
I welcome back to Module five sequel development. We're currently in less than one skimmer development, and we are in sub Listen. 1.3 identified requirements. Now this lesson. We'll take a look at a requirement document that has been handed to us from a team member that describes an application we're trying to build.
This document is available for download, so feel free to go out there and grab it if you need to.
With that said, let's take a closer look at the document.
We can see that it's a describing a content management system, or CMS for Short,
which is a website for editors, writing, news articles, tutorials and reviews.
If we look at the capabilities, will see a few what looks like a few different objects. With the attributes described,
We have a user who can write reviews, tutorials and news articles can tag article types mention above. If owner or admin
can put article and category type is user name and password controls.
Now, if you compare that to the guests will see that it can leave. Comments on both items must be logged in to comment.
Can read reviews, articles in tutorials, guess who's not long and can still read various article types so that it sounds like they can read article types. But they just won't be able to comment until they logged. And so that will be something Thio, remember
and adman can add. Delete comments, tags and all article types and users.
Okay, so that's the super user.
What's the articles can be. Tutorials reviews News articles may have multiple images. We'll need to remember that images attributes because the database will need a way to save the path to the image
so that it can be used and displayed to the user. That muse the website
can only be edited or deleted by the owner. Admin OK,
tags attached to articles, single word
categories attached to article, single word description.
So something to think about when looking at these requirements is we have user guess, an admin.
So will that be three different tables? Will there be a user table, a guest table and admin table? Or is there a way for us to have one table and just signify the differences?
Ah, between the use of the gas and they have been on that one table in a way that makes sense.
Same thing for articles. Do we need a tutorials table, a reviews table and a news article table? Or is there a way for us to just have one table
in a way that makes sense and distinguish between those different types?
Another consideration tags and categories? Those seem like too closely related ideas. Is it possible that they could be one table or be again? Two different tables attack table in category two? Definitely something we need to consider. Definitely something we need to. Ah,
I think about when we implement.
Now. If we look at the notes and say, Remember to focus on the models,
we only need to ensure that the database allows for decisions to be made based on data that is reminding us to not really concern ourselves with how these actions are going to occur.
Just that there is a way to store and read the current status of those items.
I said, Think about the models we need.
Do we need a review table on article table in editorial table?
Or is there a way to create one table that would store that data while indicating the type so in the following lessons, we're really gonna
implement a lot of the different things that we went over in the previous lessons. Such as constraints. Many too many relationships. Ah, one too many relationships. When developing this model, we're gonna add some floor and key constraints as well. So I hope you enjoy this lesson and hope to see in the next where we really get started on building this.