Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

C06 — Conceptual Information Model

Diagram coverage

Model boundaries and representations

The evidence describes a customer, order, inventory, and reporting domain represented in more than one artifact set. The Informix-4GL sources under demo/source define database-oriented records and forms, while the migrated Java sources under demo/target/java and generated records under demo/bin expose corresponding Java-side structures. These representations should be related conceptually, but they should not be assumed to be semantically identical: D4_Cust.java is not demonstrably a one-to-one translation of the displayed menu1.4gl.main or query1.4gl.main, and Order.java and Orderform.java appear to be distinct form variants. E0010 E0012

The principal persistent entities evidenced by table declarations, SQL statements, record classes, unload files, and form bindings are customer, state, manufact, stock, orders, and items. Derived or exchanged records include P_Orders, P_Items, P_Stock, R, and X_Invoice. The database schema itself is not supplied, so primary keys, foreign-key constraints, nullability, precision, and physical indexes remain partly inferred from field usage rather than confirmed schema definitions. Detailed persistence and interface treatment belongs in C08, while validation and integrity decisions are further discussed in C05. E0001 E0013

Customer and state information

A customer record identifies a customer through customer_num, with descriptive and contact attributes fname, lname, company, address1, address2, city, state, zipcode, and phone. The generated Customer record defines customer_num as an integer; fname and lname have length 15; company, address1, and address2 have length 20; city has length 15; state has length 2; zipcode has length 5; and phone has length 18. Its declared field order is customer_num, fname, lname, company, address1, address2, city, state, zipcode, and phone. E0007

The customer forms bind these same attributes to screen fields. customer_num is displayed as a non-entry or identifying field in the form definitions, while the name, company, address, city, state, ZIP code, and telephone fields are entered or displayed as customer details. The state field is configured with UPSHIFT, and the telephone field uses the picture mask ###-###-#### XXXXX. The supplied customer data represents telephone values such as 408-789-8075 and 415-822-1289, while the unload excerpt contains 18 visible records with identifiers 101 through 118. That excerpt is sample data, not evidence that those are the only customer records. E0007 E0009

state is a reference entity with a two-character code and a sname field of length 15. The source and generated record both place code before sname. State data is presented as code/name pairs such as CA|California|, and State_List exposes the pair for selection. Customer state entry can invoke statehelp() when the entered code is absent or not uniquely recognized; the selected state code is then assigned to the customer record. The exact database constraint or validation callback is not established, so this behavior should be treated as application-level selection logic rather than proof of referential enforcement. E0007 E0009

Stock and manufacturer information

Inventory is represented through a combination of stock and manufact. The manufact unload excerpt maps three-letter manufacturer codes to names: SMT to Smith, ANZ to Anza, NRG to Norge, HSK to Husky, and HRO to Hero. The stock1.per form displays manufacturer name, description, unit, and unit price, using fields bound to manufact.manu_name, stock.description, stock.unit, and stock.unit_price. E0009

The P_Stock record adds the identifiers and display fields used by the Java-side model: stock_num, manu_code, manu_name, description, unit_price, and unit_descr. The source unload format confirms that stock.unl begins with a numeric stock number, followed by a manufacturer code, description, price, unit, and unit description; for example, 1|HRO|baseball gloves|250.00|case|10 gloves/case|. The first field is therefore the stock number, not the manufacturer code. E0013 E0010

Stock prices are represented as decimal amounts in the unload data, ranging from values such as 19.80 to 960.00, while Java-side handling uses Money or related numeric wrappers. Units include case and each, and the final descriptive field preserves packaging information such as 10 gloves/case, 24/case, or each. Multiple rows may share a description while differing by manufacturer or price, so description alone is not an identifier. The evidence suggests that a stock item is selected by the combination of stock_num and manu_code; the database’s formal key definition is not supplied. E0009 E0013

Orders and order items

An orders record contains the order header. P_Orders defines order_num, order_date, po_num, and ship_instruct. The form definitions additionally bind customer_num, backlog, ship_date, ship_weight, ship_charge, and paid_date. In P_Ordcur, total_price is a form-only money field rather than an evidenced persistent order-column definition. The unload representation contains ten positions: an order identifier, date, customer-related position, shipping instructions, a one-letter backlog-like flag, purchase-order value, ship date, weight, charge, and paid date. Some positions are empty, particularly shipping or payment-related fields. E0009 E0013

order_num is used as the order identifier in queries, generated-number retrieval, updates, deletes, and item association. customer_num links an order to its customer in the customer-oriented order queries and in the deletion check in D4_Cust.java. The source therefore supports a customer-to-orders relationship in which one customer may have multiple orders. Whether the relationship is enforced by a foreign key, and whether deletion is restricted to active orders or all orders, remains unresolved. The Java deletion code counts all rows in orders for the customer while reporting that active orders prevent deletion. E0002 E0007

items represents the repeating lines belonging to an order. The generated and form-oriented structures identify item_num, order_num, stock_num, manu_code, description, quantity, unit_price, and total_price. P_Items contains the same schema-like fields, while Orderform.java presents line columns for item number, stock number, manufacturer code, description, quantity, price, and total. The order forms show four visible rows in some .per definitions, whereas help text and global arrays describe support for up to ten items. This is a representation difference: the evidence does not establish whether the visible row count, scrolling capacity, and persisted maximum are identical across all forms and programs. E0009 E0006 E0007

An item is associated with an order through order_num and with inventory through stock_num and manu_code. Its total_price is calculated from quantity multiplied by unit_price in the order-entry source. The generated item unload excerpt contains six fields, but their meanings are not declared within that file; the mapping to item number, order number, stock number, manufacturer code, quantity, and total price is inferred from cross-file use. E0007 E0009

Invoice and report records

X_Invoice is a denormalized exchange or report record combining order, item, stock, and manufacturer information. Its fields include order number and dates, shipping instructions, backlog, purchase-order number, ship date, weight and charge, item number, stock number, manufacturer code, quantity, total price, description, unit price, unit, unit description, and manufacturer name. This structure supports invoice output without establishing that it is a persistent database entity. R similarly combines customer identity and address fields with order number, order dates, paid date, and total price for report-oriented use. E0013

The accounts-receivable report selects orders whose paid_date is null and groups output by customer and order. Mailing labels use customer fields and sort by ZIP code in the Java target and by zipcode in the 4GL source. These report records therefore represent derived views over customer, order, item, stock, and manufacturer data rather than separate business ownership domains. Backlog and stock-list report methods exist as menu surfaces but are explicitly unimplemented in the supplied Java and 4GL evidence. E0007 E0012

Shared runtime records and lifecycle scope

D4_Globals maintains one shared Customer, one P_Orders, arrays of P_Items, P_Stock, and State, counters for stock and states, and print_option. The capacities evidenced in the Java globals are 10 items, 30 stock rows, and 50 states; startup loaders stop retaining records beyond the stock and state limits. This is application-level working state, not proof of database cardinality or persistence. E0012

Object lifecycles remain separate. A customer, order, order item, stock item, state reference, invoice row, and report row should not be treated as one common lifecycle merely because they share fields or appear in one form. Order creation has an evidenced insert-and-item-insert transaction in D4_Orders, while order update and delete are stubs in that program. Separately, ordmenu.4gl.main reports implemented Modify and Delete operations, so those findings must remain attributed to that exact program rather than generalized to the migrated D4_Orders implementation. E0002 E0009

The unresolved questions for this model are the formal keys and constraints, the precise null and precision rules for monetary and date fields, the maximum persisted item count, and whether the Java records are runtime persistence classes or generated artifacts.

Expandable topic detail

Browse all topic detail.

Conceptual data / class model

Browse diagrams and evidence gaps.