in reply to (OT) Old blood versus new blood
As mentioned, the problem with the label "DBA" is the definition of the DBA role depends a lot on the organizational context. I don't think that it's entirely reasonable to take the position that every DBA should know the details of normalization. That depends on where you draw a line.
I've worked in shops where the DBA worked in Operations, but the developer doing schema design worked in R&D. The DBA worried about the physical upkeep of the system, while the developer worried about conceptual integrity. I've also worked in shops where "DBA" meant "everything to do with that icky database thing, which nobody else wants to touch for fear of their mortal soul." The trick is to be clear about where you're drawing the line between logical and physical design.
In chatting with our CTO, he tells me that this is something that he has seen this quite a bit in older DBAs. He claims that they worked in a time when space and CPU time were at a premium and therefore they didn't focus as much on "esoteric" concepts such as normalization.
This generalizes past the DBA. A lot of people get stuck in whatever was hot when they first learned. And some of the people who manage to move past that still fall back on what once was when they're under pressure. And some people have been around through enough fad cycles to realize that what's hot today probably won't be in a few years. That's one of the benefits of experience.