Master implied, but needed in design?

Pardon me for this basic relational theory question. I'm writing an Informix 4GL program allowing edits of "packages" which contain "order codes". Constraints: 1) Each package contains one or more order codes. 2) An order code can only exist once in a package. 3) Different packages can contain the same set of order codes. 4) There is no data to store for a package except the set of order codes. 5) There will never be enough of these for disk space to become a concern. This was originally designed as a single table, to wit: create table pkg_orders ( pkgcode char(5), ordercode char(5) ); The screen design presents the user with a single pkgcode screen field and multiple ordercode entry fields. The design treats add and delete operations as affecting an entire package, and change operations as affecting the ordercode columns. For example, adding ordercodes becomes a "change" operation from the user's point of view. In my view, it would help to add a new table, say pkg_hdr, with a single column pkgcode. An associate claims this is unnecessary from a relational theory view. I'm thinking that the additional table provides for: 1) Easier coding and maintenance, as plentiful master-detail examples exist. 2) A master-detail relationship seems to me closer to the design concept as described above. 3) Inevitably, when additional columns are added to the definition of a package, changing the code to conform will be simplified. I realize I could use a temp table in my program... I'm thinking the original single table design violates relational theory but this comes from an intuitive feel rather than a deep understanding. I'd appreciate any arguments for or against my position. Thanks! -Mike -- | o==== . : ... : : . |Mail Me Neat Stuff->POB 3703 Arlington VA 22203 --@-- . o o o ... O -O- o o : | mwiik@netcom.com | ... : : |----------------------------------------------- mEssAGE fRoM sPAcE ARt stUdiOs |No disclaimer necessary,I actually pay for this