For example, let’s say you have products and orders. Every order has some products. But they’re not the products as they exist now, they’re the products as they existed at the time of the order. You may later change the product price, remove a guarantee from the description, or delete the product, but the order remains the same. The difference is important when later fulfilling orders, and also for historical data. How do you represent this?
It seems to me that there are 3 separate things, though you may divide it how you wish:
What you claim to sell
These are items you would like to sell to customers, you might have them in stock and they are available immediately or you might be sold out; yet you would still like the customer to be able to place a reservation (something less than an "order" because you can't bill for something that you don't know you can sell).
If you are sold out you might have to obtain new stock from a different source, this might affect pricing and guarantee along with delivery time.
What the customer wants
It can be a 'wish list' which shows how many customers are interested in something that you don't actually stock but might consider stocking (or having drop shipped) if there is enough interest and it aligns with what you currently sell.
It can be an "order". An order is exactly that, the customer orders what you promised. They have agreed to the fine print of your terms and are paying for what they want - they don't want something different (you'd be surprised how many places have employees whom having established exactly what the customer wants immediately think that they would want something different, it's not upselling it's arguing and time wasting).
What you can offer.
You can immediately offer what is in stock, ship it by end of day, and it will arrive when it's delivered.
Items not in stock are on backorder, you can't establish a certain price or guarantee unless you are willing to absorb any losses associated with doing that, the customer certainly isn't.
Thus, the package description, color, weight, price, guarantee, and whatever else are fixed at the time of sale.
You can alter any of those for subsequent sales but any sales already made are tied to what they are when the sale is made - changing things often and always making it worse (shorter guarantees and higher prices) won't go over well. Having a "sale" where prices are temporarily lower or buying a particular quantity nets a discount is acceptable but you need to be clear about the terms and duration (no pulling the rug out, or bait and switch).
The flowchart is:
The customer is: "just looking", "asking if you have" (this can be a "wish list", questions in an email, or you can examine your website's searches), or is actually "buying".
You have the item and will put it on the next truck or you need to backorder, if it's a "wish list item" do you wish to make such items orderable and either drop ship them or stock them.
Also there are your terms treat this as though it was something you stock and include in the box when you ship the item ordered. Items ordered are decremented from stock when sold so they can't be sold twice and the "price", "guarantee", "terms and conditions", etc. are treated like something packaged in the box that was shipped - they don't change in transit.
This makes it difficult or impossible to answer questions like “when we moved feature X from product Y to product Z, how did that affect sales?”, encourages data loss (did we tell that customer, in the description, that they have that guarantee?), and of course stores a lot of duplicate data.
I believe that the way I described of looking at things avoids those problems.
Products and orders is a very typical use case for relational databases, ...
One of many.
One reason you might want to have a relational database is you can query (for example) "What color umbrellas do men buy in winter" (from your stores, if sales are low perhaps they must go to a different store to obtain their favorite brand and color; without a "wish list" (non-binding sale) you don't know how you are coming up short you are assuming you know best - sometimes thst works, sometimes it's rejected - you can only ask what you know "from your stores" you can't query what's the latest fashion or most popular widget - the database doesn't perform miracles).
A relational database allows complex queries and analysis beyond "what do we stock and how many do we have". You can ask how long does it take for you to order from the manufacturer and have it in the customer's hands, that allows you to order in advance for seasonal items based on predicted sales from previous years.
You can determine which brands and colors that you have previously sold were most popular and order a greater number of those, you can't ask the database about information not contained within, why did the customer walk out without buying (price?, selection?, service?, or lack thereof).
You need additional sources of information like an email address, customer service department, feedback forms, polite and non-intrusive surveys (don't follow with a clipboard like some stores do), even free samples or EOL sales and discounts. The relational database alone won't solve everything.