Denormalization is a technique to move from higher to lower normal forms of database modeling in order to speed up database access. You may apply Denormalization in the process of deriving a physical data model from a logical form.
The analysis you have started, concentrating on important views only, shows that an Order View is one of the most heavily used views in the database. Reading an Order and the OrderItems costs a join statement and several physical page accesses. Writing it costs several update statements. Further statistical analysis, again concentrating on the important parts of orders, yields that 90 percent of Orders have no more than 5 positions.
How can you manage to read and write most physical views with a single page database access when you have a parent/child (Order/OrderItem) relation?
Time vs. space: Database optimization is mostly a question of time versus space tradeoffs. Normalized logical data models are optimized for minimum redundancy and avoidance of update anomalies. They are not optimized for minimum access time. Time does not play a role in the denormalization process. A 3NF or higher normalized data model can be accessed with minimum complex code if the domain reflects the relational calculus and the logical data model based on it. Normalized data models are usually better to understand than data models that reflect considerations of physical optimizations.
Fill up the Order entity database page with OrderItems until you reach the next physical page limit. Physical pages are usually chunks of 2 or 4K depending on the database implementation.
The number of OrderItems should be near or greater than the number of OrderItems that reflects the order size in 80-95% of cases.
Time: You will now be able to access most Orders with a single database access.
Space: You need more disk space in the database depending on alignment rules. If you are lucky and the database system will begin a new page with every new order the space is even free. As you have to deal with the 5-20% or so cases of orders that do not fit into the Order/OrderItem record, the code will become more complex.
Queries: The database will also become less queryable for ad hoc queries as the physical structure does no longer exactly reflect the logical data model.
DENORMALIZATION GUIDELINES by Craig S. Mullins (The Data Administration Newsletter),
Responsible Denormalization, How to break the rules and get away with it (SQL Magazine)