I have a few observations and suggestions:
Do not create a
DATE table when all you need is an element (column) for the date of the
POST. Generally speaking, a table with nothing but a meaningless ID and one other column is a good indication that you need to look hard at whether all you really need is the non-key column.
CATEGORY, this also has just its ID and the category description. Is this a good candidate for an independent table? There are two things to think about:
- Are there likely to be other attributes that depend on the category? In other words, should category be normalized out of posts?
- Is it possible that categories could exist that have zero posts? In other words, is the category list something that needs to be managed by an administrator or someone other than the person who creates posts?
On another subject:
Your model indicates that a
POST can be written by many
USERs. I'm not sure that this is really possible in your system, since you don't say anything about collaborative authorship. However, one thing that is almost certainly a problem is that each user can only ever author one post. I'm sure that's not what you meant.
To fix this you either need to move the foreign key in the relationship between
POST to the post side or you need to create an intersection entity if posts can have multiple authors.
Your business rules state that posts can have multiple
TAG assignments, however, your model doesn't reflect this. In your model each post can have exactly one of each of these.
To fix this you need to implement a many-to-many relationship for each of tags and categories. This will result in an intersection table in each case.
Why is some of your user information segregated into another table with a many-to-many relationship to the main user table? There may be good reasons to keep password information in a separate table from other user information, but I don't see any reason stated in your business rules. Also, it isn't likely that password will be many-to-many with your user record.