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).

Thank you for such an effort to write such a complete and precise reply and although it was quite perfect it arose some questions which i will appreciate if you let me know or at least give me references to read about'em more by myself.
meanwhile, I'll try to address your ambiguities and explain the case clearly. Besides, I suggest you read my other reply to nima for more clarity.

suppose this is a program for a workshop where personnel (2nd Table) do some operations (3rd Table) with some machines (1st Table) and you need to have a work report (4th Table) which contains all the other 3 PKs as FKs plus some additional information like date and duration and .....
Here it seems like we have 3 parents and one child (pls. explain as you introduced them as child tables) and I'm using EJB(CMP) plus ValueObjects and a session  bean facade.
after all, i guess your second answer is closer to the solution but i think the list of business entities would not be that important to insert  a rec. in the 4th table. and give me good Ref.s for coarse-grained beans (composite entity pattern).

What you need to do is to identify the business objects.
corej2eepatterns.com/.../BusinessObject.htm
above link has a new version of the strategy (but the full description can be found in the book), but you can also find an older version in
java.sun.com/.../DataAccessObject.html
(try to find the new version which is much more helpful)

Regarding composite entity pattern have a read through
java.sun.com/.../CompositeEntity.html
you don't necessarily have to map an entity bean  to a business object. You can provide a top level persistent management component that perform queries for you and hide the data source access  from your session  facade or application. the patterns above are giving you the pros and cons of this in more detail.

About what you are saying as "business entities would not be that important to insert  a rec", may be not directly when accessing DB records, but understanding business entities gives you the possibility of utilizing the best strategy for identifying related entities and therefore simplified accessor methods. this will then result to higher performance, low network traffic and low inter-communication. you will then have a less complex design.

1- you build four entity beans with the PKs and FKs defined (with relations between them).
2- you should config your ejb-jar.xml to have references to entity from session  bean.
3- Implement your session bean  method like this :

public String doInsert (any parameter) {

       // Configure your JNDI Properties

        Hashtable environment = new Hashtable();

        environment.put(Context.INITIAL_CONTEXT_FACTORY,
                        " org.jnp.interfaces.NamingContextFactory");
        environment.put(Context.URL_PKG_PREFIXES,
                        "org.jboss.naming:org.jnp.interfaces");
        environment.put(Context.PROVIDER_URL , "jnp://localhost:1099");


         InitialContext ctx = null;
         try {
             ctx = new InitialContext(environment);
         } catch (NamingException ex) { 
         }

         // Lookup entity beans home interfaces (these are configured in <ejb-local-ref> or <ejb-ref> in ejb-jar.xml)

         Object result1=null, result2 = null, result3=null, result4 = null; 
         try {
             result1 = ctx.lookup("java:comp/env/ejb/FirstHome");
             result2 = ctx.lookup("java:comp/env/ejb/SecondHome");
             result3 = ctx.lookup("java:comp/env/ejb/ThirdHome"); 
             result4 = ctx.lookup("java:comp/env/ejb/ForthHome");
         } catch (NamingException ex1) {
         }
         FirstHome firsthome=(FirstHome) result1;
         SecondHome secondhome=(SecondHome) result2; 
         ThirdHome thirdhome=(ThirdHome) result3;
         ForthHome forthhome=(ForthHome) result4;

         try {
             First f=firsthome.create(field_A , field_B);
             Second s= secondhome.create (field_C, field_D, field_E);
             Third t= thirdhome.create(field_F, field_G);
             Forth fo= forthhome.create(field_H, field_J);
             fo.setFirst(f);
             fo.setSecond(s);
             fo.setThird(t);

         }  catch (CreateException ex2) {
         }

        return "";

    }

I got your whole point. but one thing to mention is that, it seemd like you had corresponding accessor methods for foreign keys in your 4th entity bean. because at the end you had :

fo.setFirst(f);
fo.setSecond(s);
fo.setThird(t);

OK, but as you may have noticed, the 4th table  had a 1-n relation with each of the other 3 tables.(4th table is CHILD while the other end is the PARENT).

As I encountered and examined in EJBs like this, the child entity bean  DO NOT have any accessor method  for the foreign keys, instead we define a business method in the parent as:

    public void addChild(LocalChild child) {
        try {
            Collection children = getChildren();

            children.add(child);
        } catch (Exception ex) {
            throw new EJBException(ex.getMessage());
        }
    }

now, we can use this method in the facade session  bean like this:

    public void createChildInParent(childObject, PK) {
        try {
           LocalParent parent = parentHome.findByPrimaryKey(PK)
           LocalChild child = childHome.create(...no FK accessor method...)
           parent.addChild(child);
        } catch (Exception ex) {
            throw new EJBException(ex.getMessage());
        }
    }

Sorry,I made a mistake In my previous reply because I mentioned parent and child reverse.

And now by this hierarchy, you should create the Forth Entity with the PKs of other 3 Entity as FK. These PKs can be obtain by Create or findByPrimaryKey or etc.
And then you should add this Entity (Forth) to any of other 3 entities.

if you have time, also take a look at the EJB 3.0 entity guidelines, if you are using session  bean facade they have a very nice POJO to RDBMS mapping.