Entity EJB Design question

I'm creating an Entity EJB using Bean Managed Persistence, which could be fairly complex.  It's would represent an object whose data spans multiple DB tables and the fields consist of some potentially large objects (input streams). The cost of storing and loading this info to and from the DB would be fairly high.  This object is essentially representing a program whose code and associated include files are stored in the DB. There are certain attributes that will be used quite a bit more often than others, for example the name, description etc. will be looked up often to generate a list of these programs available to the end-user. Where as the large program files and include files will be used less often only when a user chooses to run the program.  All the attributes will need to be modifiable. I want to avoid having to do the expensive reads and writes of the large attributes every time the ejbLoad and ejbStore methods are called, and only do them when needed. I have a few ideas but I wanted expert input:

1. Create two Entity Beans to model the object. One will contain the commonly used display attributes and the other will contain the less commonly used functional attributes. This will give an easy separation of the object and allow the expensive read/write calls to be used only when needed.  I’m not sure if this will lead to integrity issues since a remove of one will necessitate a removal of the other, and this might cause problems.

2. Use only one Entity EJB and instead of having all the fields in the DB be instance variables of the EJB and be loaded and stored with each call of the ejbStore or ejbLoad. For the large and expensive fields I would create methods that pull and load those fields only when explicitly asked for or changed. To me this seems like the best solution but it doesn’t seem to fit in with the idea of Entity Beans but I’m not too sure, I’m very new to EJBs.

I’m sure there are other possible approaches too. Any input is greatly appreciated.

Thanks
David