To a certain extent, yes it is.
There are 2 methods, one is faster when performing SELECTs and UPDATEs, the other is better database management.
Normalized Data. Say you have a table of users in which a column exists, postal_code. Now, say that you have another table of postal codes that have columns such as county, state, etc, etc. If you want to lookup the state a user is in, you would have to perform a JOIN between your user table, and the postal codes table. This is equiv. to 2 SELECT statements. Under a heavy load site, this essentially doubles the servers load YET, the maintenance headaches are null.
Redundant Data. Lets take the same example from above and say that you are constantly SELECTing users geographical information. You could reduce the load, respectively, by one half if you had a couple extra columns that contained the data that you regularly wanted to know about the users. This does increase the database size a bit but reduces the CPU load substantially. You could make some constraints between your redundant columns, and the table that you would have JOINed to for the data, to ensure that the data remains valid. Using the example, you could use the postal codes table to confirm correct user input, then store the appropriate record data of the users postal code, state, county, etc, in that users record in the user table.
All of that said, and assuming that everything is understood as I intended it, I ALWAYS normalize the hell out of my databases for one reason. "Low maintenance" Hell, servers are running at 3GHz+ these days, although I understand when servers were running at a whopping 300MHz, why this would be advantages, now-a-days, screw redundancy, it's all about normalization!!!
That's my two bits if it matters.
