Why does the Transaction table have 6 names and social security fields, instead of a single one? This defies the purpose and advantages of using a related table in the first place (as does the idea of duplicating non-transactional data).
If a transaction is more like an event in which several people can participate, create a child table to Transactions (say, TransactionsPeople) and use it to create one record for each customer/participant of a transaction.
I was going to do it the way I describe because each transaction could have up to six people for one transaction. So you would see:
all people names with their respective socials listed for $1000.00 coming from account number 1234, account number 5678 and account number 9876.
You mention a child table. I'm assuming that would hold a transaction for each person and then I would display them alll together on the transaction layout?
The child table suggested is basically a join table to creat connections between a specific Transaction record and whatever People are associated with that transaction. You can then display and/or create the connections in the manner you describe in a portal (which might be set to DISPLAY six lines at a time, but can CONTAIN as many or as few as are needed).
If you must proceed the way you originally propose you will need to create a relationship to the people table from each of your six SSN fields, so that each field points to a different person. Three issues arise with this approach compared to that suggested by erolst:
1. You have to create and manage more relationships
2. Any Transaction record which has less than six people associated with it has empty fields
3. Worse still, you schema cannot handle a Transaction record which has seven or more associated people