In reading a number of articles on 1NF, they all pretty much state the following:
Every column in the table must be unique
Separate tables must be created for each set of related data
Each table must be identified with a unique column or concatenated columns called the primary key
No rows may be duplicated
no columns may be duplicated
no row/column intersections contain a null value
no row/column intersections contain multivalued fields
I am not seeing how total_price is violating any of these rules.
However, when it comes to 3NF, total_price can be derived by multiplying the unit_price by the amount, therefore it's not fully dependent upon the primary key. Strictly speaking, you must remove it from the table to comply with the 3NF. This means that every single query asking about the the total price will need to do something like:
SELECT order_id, product_id, amount, unit_price,
amount * unit_price as total_price
WHERE order_id = 5
This is where experience and wisdom of the developer comes into play to determine if this is the way to go or if breaking 3NF has other benefits in the bigger picture.
For example, I have a table with:
The tax amount is calculated by multiplying the value by a rate that comes from another table. I found that I was always summing tax amounts and comparing taxes charged against taxes paid. It was much, much easier to have the tax amount always computed then to have to do it on the fly.
The other option to maintain 3NF is to declare the total_price as a computed column in the DDL.