Entity and Relationships
One simple view of all the data is a spreadsheet-like table that contains a unique identifier. Some examples include name of a student, his date of birth, date of enrollment, class in which he is studying and so on. The unique identifier or the “primary key" helps locate a particular record in the table easily. Suppose a database is created for tracking progress of students through the school years. The courses taken by each student and the students’ performance are recorded. This part of data would change every semester. One could plan to have fields for every subject a student is likely to take and create one flat monolithic table. Alternatively, one could have unchanging data, such as data about the student during the degree program, his ID, name and other unchanging data in a master table. There can then be another table (even a set of tables per semester) that captures the changing data of the courses taken and grades in each of them.
To find answers to queries, such as “What was (name)’s score in course 509 in the third semester," one would need to locate the master record first. The other table(s) will have to have a key that is the same as the primary key found in the master record. This typically is called the foreign key. As you can see, this organization takes a lot of planning. You cannot modify the structure over time and add or delete fields and records as needed.
An entity, its attributes and relationships help you plan during the design stage, before any data bit has been entered. If the entities, their attributes and the relationships are thought through completely, one can easily design the master table and related secondary tables. This will ensure that all possible queries can be satisfied easily over the lifetime of the database. What helps with finalization is an ER diagram (entity-relationship diagram) that brings out these relationships visually, allowing you to verify whether all entities, their attributes and the required relationships have been captured. There are several accepted conventions of drawing these diagrams, including the universal modeling language or the UML. What is important is to use any one of these and create an ER diagram, so that the needed structure of the database is absolutely clear and confirms it can do the intended job.