Normalization splits data into narrow tables so that each fact is stored exactly once. The storefront schema from Transactional Access Patterns is normalized: a book's title and price live only in books, and each order row refers to the book by book_id. Customers, addresses and payments would each get their own tables. Normal forms (first, second, third and beyond) are the formal rules for reaching this shape; LAMP Stack Development teaches them with MySQL 524 .
The payoff is integrity under constant writes. A price change is one UPDATE to one row, and no copy elsewhere can fall out of date. Foreign keys and constraints, like the stock check that rolled back an order in Transactional Access Patterns, keep the data consistent while hundreds of transactions run at once.
The cost appears when you analyze. A question such as "revenue by genre, author and month" must join orders, order lines, books, authors and a calendar, and a real e-commerce schema has dozens of tables whose names and codes make sense only to the developers. Normalized schemas also change whenever the application does. That is why data engineers seldom point dashboards at an OLTP schema directly: they copy the data out (Ingestion: Getting Data In) and reshape it into one of the analytical models that follow.