How to correctly use PFILE keyword in DDS Logical File? (AS400)
Each of these four things should be given its own PF (aka table).  In the real world, any of them might even be best served by additional supplementary tables, as may be appropriate.  For example, suppose a customer wishes to pace an order for several different items.  This would normally be handled with an order header file, to store data pertaining to the order as a whole, and an order detail file for each item being ordered. But we'll stay within the bounds of your assignment, which has been specifically worded with an expected design.

The tables do not access each others information, per se. But they will contain fields (aka columns) which will refer to key field in other tables.  It is generally a good idea to create indexes on each table, for the various ways we can expect it to be accessed, by creating a simple keyed logical file for each such key sequence.

In this case, after you have defined your ORDFILE, you might define a logical file, called for example ORDFILE1, with CUSTOMER as the [first] key field, perhaps followed by ORDRNUM.  You might have another keyed by ITEMNUM. Whatever key sequences may come in handy can each have it's own LF. Indexes are very low overhead on the iSeries, so having several dozen is not a problem, even though other platforms might have a lower recommend guideline. So in the real world you might want to create a good variety over these files, to help the optimizer with various queries that your users may want.  For an assignment like this, create only those that are relevant to the requirements.

The type of LF that would combine fields from various physicals is called a join (or joined) logical file. Unless your professor has mentioned it, that may be outside the scope of his/her expectations.  A query can read multiple PFs, much as a join logical would, so a join LF may be superfluous in this case.



Disclaimer

Modern best practices on this platform would generally be to use SQL for databases, rather than DDS &amp; Query/400.  And it may be handy to know that QM Query can convert Query/400 queries to SQL.  But most companies still have plenty of DB files defined with DDS. It is important to understand these earlier technologies when you are a professional developer on this platform, since you may have to support them.