In this case (as it is done in real work places) one table might represent a more global view with multiple foreign keys. For example, the table Employees might contain department where they work, current project that they participate in, etc. These additional entities (departments, projects, others) are represented by some id/foreign key and have respective separate tables describing them in more detail.
Then the Interface might be designed in a way when the user selects a particular employee while browsing or searching, additional tables describing details of the department, project, etc. are automatically shown. Note that there could be several logically grouped attributes from the same employee table describing some specific attributes of the employee (like salary, recent promotion, etc.) that do not have to appear in the main GridView of the Employees table. This will offer even more design flexibility and make the UI (user interface even more attractive). The key to the connection of the corresponding rows from various tables to the main browsing activity of the Employee GridView can be achieved in a very simple way (along with other possible methods) just be indicating that the key of the Specific Table equals to the corresponding foreign key of the main browsing table in the GridView control (as was described in the previous post on connecting DetailsView and GridView controls).