Apparently you have already chosen the strategy by saying, "EntityBeans(CMP)". If this is the case, each of your tables can be mapped to a single CMP with single PK and one PK class. this is not a good choice though, if your system is growing, but in EJB 2.x you have CMR, which gives you the choice of having related CMPs. But keep in mind that, with entity beans you can only use CMT. So when a method on your entity bean is called, the container will create a transaction with all the entity beans and other related entity beans. As you know, this will lock all the involved beans and lead to possible deadlocks (very important).
My answer: to defend myself :) I don't know the business case and I don't know the db and tables so you have multiple answers here:
Answer 1: A foreign key in database tables is like relationships between entities (this is not entity bean yet). Your example is a many-to-one relationship. In such a case you do not need to map each table to an entity bean. You can introduce multiple simple classes and one parent dependent bean. One of the best strategies is to reduce the inter-entity bean communications. This means that you should implement relationships by coarse-grained entity beans with dependent objects (look at composite entity pattern). This is a strategy used when refactoring an architecture (your example). I prefer this approach as it have memory improvements, lower traffic and better transactional control over object instances.
Answer 2: On the other hand, tables look very simple, so you can have single entity beans for each that provide "local interfaces" to improve performance and if any business logic required, that can be handled by session beans. This needs further analysis, because, there are only in certain circumstances that you can consider separate beans for each of your child tables which are, when child tables are NOT dependent on your parent table (the one with FKs); and child tables can be used without applications even accessing the parent table and finally entity bean that represent the child table CAN exist without the parent object. So as you see that further analysis needs to be done, please do not expect a neat design for your question now.
You did not give us the list of business entities. what we have here is simply a list of unknown tables and PKs. we don't even have names for them. If we had any, we could come up with / guess with one or more business entities and that would simplifies things lot easier in a way that if business entities are/can be mapped to persistent data in your data source, we could consider the correct pattern. i.e. a root dependent object model and a set of TOs (Transfer Objects). This purely depends on how business entities will be introduced/analysed. note that BMP is "usually" used in cases that you can not map business entity to db using container services.
second question is lot simpler: If you are using a session facade, which is a very good choice, it is good practice to use a value object in lower layer to provide access to your business entities. This VO can utilize a factory object to provision a DAO type of thing for CRUD business operations. (DAO can return TOs for lower network/server overhead).