Design 1 is NOT normalized, I agree. The biggest practical problem with non-normalized databases is that Add/Delete/Update become complicated. Here's an example of the problem with design 1: lots of facts and aliases already loaded. when you delete a fact, you have to scan the whole table to delete all matching aliases. same problem when you update the key column of a fact. Also, you can add a alias that doesn't point to a valid fact. So all this logic gets put into the code of the application, instead of having a normalized database that enforces these relationships. Most such happy coders get the code 99% right, and one day the %1 sneaks in, and someone has to clean up the mess and build it right (normalized) as it should have been. There are cases when de-normalization is used, in strict control, and only for specific reasons....Perhaps "they" should be giving you reasons WHY to use a de-normalized model; instead of you justifying normalization. BTW you can easily port a system between different languages and databases when the db is normalized...an application centric (non-normalized db) system is not easily ported.