If you only have those tables there will be little difference between your datawarehouse star schema and your actual schema.
You probably have a much more complex relational schema though, where you also have customer groups or item types and your schema looks more like
fact table -> customer table -> customer group table
fact table -> item table -> item type table
When you are working towards a star schema you would then denormalize your schema so you include the customer group description in your customer dimension table and your item type description in your item dimension table.
The basis of a star schema is that you have a fact table, and every dimension is a single table just a single step away from the fact table.
The way kimball describes it:
Star schemas characteristically consist of fact tables linked to
associated dimension tables via primary/foreign key relationships.
If you don't denormalize your dimensions into single dimension tables you end up with a snowflake schema. Snowflakes may seem like a good idea, but they often result in poorer query performance and can get you in all kinds of trouble later on, especially if you plan to build a cube on top of your data warehouse.
Again Kimball has a post on it:
We generally encourage you to handle many-to-one hierarchical
relationships in a single dimension table rather than snowflaking.
Snowflakes may appear optimal to an experienced OLTP data modeler, but
they’re suboptimal for DW/BI query performance. The linked snowflaked
tables create complexity and confusion for users directly exposed to
the table structures; even if users are buffered from the tables,
snowflaking increases complexity for the optimizer which must link
hundreds of tables together to resolve queries. Snowflakes also put
burden on the ETL system to manage the keys linking the normalized
tables which can become grossly complex when the linked hierarchical
relationships are subject to change. While snowflaking may save some
space by replacing repeated text strings with codes, the savings are
negligible, especially in light of the price paid for the extra ETL
burden and query complexity.
With regards to your question about changing the customer data and losing history, in a datawarehouse that's solved by using "slowly changing dimensions".
You basically have several types of slowly changing dimensions, but you are probably looking for "type 2" which largely comes down to storing a valid_from and valid_to date on your dimension row so you can select the row that was valid at the time of the transaction.
Type 2 SCD's
In addition to the primary surrogate key, I recommend adding five
additional fields to a dimension that is undergoing Type 2 processing.
These fields are shown in Figure 1. The datetimes are full time stamps
that represent the span of time between when the change became
effective and when the next change becomes effective. The
end-effective-datetime of a Type 2 dimension record must be exactly
equal to the begin-effective-datetime of the next change for that
It's a broad subject to cover but I hope this sets you on the right track for the basics and you can use the correct terminology in the future.
The kimball site is a great resource (and many call it the reference) for dimensional modeling so I suggest you browse the glossary and the design tips section