For anyone beginning to design databases, here are a few lessons I learned. I have walked, so you can fly:)
The popular saying is that 'designing databases are like tattoos. Cool to get on, but stressful to correct mistakes. It's kinda true. Please spend time understanding the stakeholder's requirements.
NoSQL is not ice cream. It can't solve all your problems even though its flexible schema makes it a go-to.
Database modeling is carefully structuring database schema for: a. Meet the functional requirement of the project b. Adhere to standard database design.
It's best practice to not jump into tables or models. Explore the problem statement. E.g. 'Create a feedback system for HR Applications
Define the DB purpose. a. Reason for the project b. Owner/stakeholder expectation? c. Is the project solely for BI? d. Is it to select a DB system? or to optimize a DB system?
Next, define a list of functional requirements. For example: 'Feedback/survey used for multiple products, the user will give feedback in the context of the use, questions will be subjective, objective, etc.'
Now, take a break. Respond to your emails and laugh at posts on quora. Based on functional requirements, list out the entities. Don't worry if it doesn't make it to the table. E.g. (refer to our example so far) a. Department b. Product c. User d. The survey, etc.
Decide the relationship between tables. Functional requirements and normalization methods will usually define the creation of relations between tables. Notes that, some tables may be created just to map relationships.
Decide the columns, keys, and constraints. Columns will be based on functional requirements.
Finally, (tried to keep this under 10. Work on your attention span:)) Design your table. Note your PKs, FKs, Uniques, Null/NotNulls. You are now free to fly and design your DB.