We have an insurance Database. We have 5 different tables for different insurance plans. With columns like: Plan ID, Plan Name, Max Coverage, Min Coverage... 3 of these tables have the same structure and the other 2 have the same structure as these 3 with a slight variation.
We all agree this isn't good design. However a co-worker said it violates normalization. I didn't think that it does.
Does this design violate normalization? If so, which rule - if not, what is the name if the design principle it does violate?
so think of this lets say tomorrow the whole world turns to your company and you have to setup thousands of insurance plans....
do you see where this is going?
Like I said "We all agree this isn't good design"!!!
OK - I bolded that.
its not even an issue of normalization. its a design that cannot scale. But then again sometimes it could be a good design because each insurance plan might have wildly different processes and requirements. so the answer is it depends
Let's say there are only these 5 plan types and will never be more. And no, each plan is not different, just slightly. It's still bad design. I'm just wondering if there is a name of what this "violates" or a rule name? We all know why it's a problem. I just want to know what the name of this issue is. Or if there is an interpretation of normalization that applies here.
your situation does not even come under any of the normalization rules 
I would call it normalization agnostic bordering on Unnormalized form hence breaks the basic rules of normalization. Also would help to see the schema and relationship of these tables to the each other .
Would have to see the full ddl of all the tables to determine normalization issues.
But, since the overwhelming, vast majority of tables are not normalized, I'd say yours are not either.
The tables could, in theory, be valid forms of a supertype and subtype and thus be "normalized". It might just be a poor physical implementation of an acceptable logical model.
Too many developers "design" -- as they deem it -- their own tables. They're not data modelers and never have been. Most often they completely skip the logical design phase and go straight to physical tables (with an identity on every table, no less!).
Large system or small, seems to make no difference, the "quickie" approach is the same, even though it costs vastly more time later, both development and computer, to make up for the poor data and database "designs".