I don't begin to understand the relationship between the passenger and the agent, my first thoughts were it was some sort of flight booking system? But it also looks a bit like a hotel booking system, but using the wrong terms to describe the individuals. They're not passengers! They are guests!
How you proceed with the construction of your database is dependent on what information you want to store. In the case of a flight booking system, I think it is doubtful that you will want to retain information about a passenger, like who the father, mother, brother, sister was. This information would be practically irrelevant for further flights. If it were to be a flight booking system I think I would have a table just for passengers. Without any provision for recording the relationships between the passengers.
However if it was a hotel booking system, then you might want to consider recording relationships, for regular guests you might well want to establish rapport with the family, and in this case it would be good to know the relationships of the individuals...
It might sound a bit like I'm waffling here, and indeed I am a tad! However it is important to understand the business needs, the business processes before you construct the database.
This is really the point here. And indeed, I don't think I've ever seen such a good example of how the different requirements of a business would affect the construction of the database. The difference between airline passengers and hotel guests is a good Example. Very similar details are required passport, name, etc, and then the family relationship, required for one and not required for the other.