I just came back from Scrum training and since my company relies on what i would call a "robust" layer of data design and I had some of the same thoughts that you do.

I think your instinct is right in that in an Agile environment you don't model and build an entire data layer as a distinct phase in your development (that would be closer to waterfall). In Scrum the goal is to always be building thin vertical slices of potentially shippable software, so you wouldn't dedicate an entire sprint or sprints to working out the data layer design. Instead, if you were building, say a CRM, you might spend Sprint 1 just building the data layer required to store a simple Customer Object; later, maybe in Sprint 3, you might work on a story involving storing multiple addresses per customer so then you'd model/build a CustomerAddress story.

What's probably going to happen is that by Sprint 8 you'll find you're throwing out or refactoring a chunk of the work that you did in Sprint 1 b/c the stories will have evolved, but that's supposed to be okay - the work wasn't "wasted" since it helped to lead to a more robust product.

I'm just starting to figure out how to apply this framework in my environment, so I can't vouch for its success but my engineers seem willing to try it.

I guess the approach is that in each Sprint you should keep the big picture in the side view (don't model with blinders on) but your deep focus should be on just developing the stories in that Sprint backlog and not doing work that doesn't apply to those stories.