Estimating entire stories vs 'split' estimates

The most common scenario I've seen this is with newer Scrum Team's who have been created from once silo'd areas such as development and quality testing. The user story requires both activities and the Scrum Team ends up estimating both parts and then combining them. This seems to be more of a symptom as they're not used to understanding each others work or estimating together. 

There's a quote form Esther Derby I really like "Estimating is often useful, estimates are not" 

The team can work towards improving their ability to estimate together but it's the discovery required in order to provide an estimate that is of real value. 

Any suggestions on how we can take baby steps to get started on just one estimate? My gut feel says we work on the simplest requirement and build up from there, but I also have to factor in the work coming in shortly. Appreciate this is not something that's going to blossom overnight, but any tips / advice would be highly appreciated.

A team looks at a requirement and splits the effort into front end, business logic & database.

Is the Product Owner expected to order these on the Product Backlog?

I agree with Tony's assessment. It appears like the team needs better understanding of each other's role in order to understand how to estimate the entire story.

Might want to run a workshop on relative story estimates. The one with the various animals and the team sorts them by something like total food consumption for the month. 

The exercise isn't about knowing every detail each skill set required but just enough information to determine which story is bigger/same/smaller. 

Maybe it's worth considering a strategy where there are no handoffs on any given Story, other than the people approving the work? If there are items for each skill set to offer for a Story, what's to stop multiple stories being written with independent Value Statements and Acceptance Criterias and linking them together? 

Ensure you know what element of the estimate is valuable. Often it's just to help the team take on appropriate level of work for the Sprint. So fewer handoffs, approvals, dependencies per story the more flexible you can be, and perhaps that's still not good enough?