You'll like this, but not a lot...
Paul Daniels was THE television magician. With a combination of slick high drama illusions, close-up trickery and cheeky end-of-the-pier humour, (plus a touch of glamour courtesy of The Lovely Debbie McGee TM), Paul had millions of viewers captivated on a weekly basis and his cheeky catch-phrases are still recognised to this day.
Of course. part of the fascination of watching a magician perform is to wonder how the trick works. "How the bloody hell did he do that?" my dad would splutter as Paul Daniels performed yet another goofy gag or hair-raising stunt (no mean feat, when you're as bald as a coot...) But most people don't REALLY want to know the inner secrets, and ever fewer of us are inspired to spray a riffle-shuffled a pack of cards all over granny's lunch, stick a coin up their nose or grab the family goldfish from its bowl and hide it in the folds of our nether-garments. (Um, yeah. Let's not go there...)
Penn and Teller are great of course, because they expose the basic techniques of really old, hackneyed tricks and force more innovation within the magician community. They're at their most engaging when they actually do something that you don't get to see the workings of. Illusion maintained, audience entertained. (Here is Paul Daniels doing the classic "ball and cup" routine, and Penn & Teller doing their expose of the same thing...)
As data practitioners, I think we can learn a few of these tricks. I often see us getting too hot-and-bothered about differentiating data, master data, reference data, metadata, classification scheme, taxonomy, dimensional vs relational vs data vault modelling etc. These concepts are certainly relevant to our practitioner world, but I don't necessarily believe they need to be exposed at the business-user level.
For example, I often hear business users talking about "creating the metadata" for an event or transaction, when they're talking about compiling the picklist of valid descriptive values and mapping these to the contextualising descriptive information for that event (which by my reckoning, really means compiling the reference data!). But I've found that business people really aren't all that bothered about the underlying structure or rigour of the modelling process.
That's our job.
There will always be exceptions. My good friend and colleague Ben Bor is something a special case and has the talent to combine data management and magic.
But for the rest of us mere mortals, I suggest that we keep the deep discussion of data techniques for the Data Magic Circle, and just let the paying customers enjoy the show....