How-To Determine Velocity for Multiple Teams Involved in a Sprint?

You don't have a team. That's the problem. You've got different workgroups, and there is no clear accountability for work being Done.

Velocity is the rate at which work is Done. Until the matter of the Developers' accountability for this is resolved, velocity will be unmeasurable.

"Until the matter of the Developers' accountability for this is resolved, velocity will be unmeasurable."

Sorry, I'm not following.

For example, we have work items that will always involve the Dev team and the QC team, and sometimes the Database team.

Scrum Teams are fully cross-functional, which means one Scrum Team has all the skills needed to turn ideas into valuable, useful, and 'done' Increments by the end of each Sprint. Not 'almost' done or '99 percent' done. 100% done and potentially releasable.

Velocity measure Done work each Sprint, as mentioned by Ian. The Dev, QA, and Database work by themselves doesn't provide customer value or anything useful until all the components are connected and tested. The velocity of each team is actually ZERO because of the way they are organized.

When using Scrum we are challenged to think differently and challenge the way it's always been done. Being a change agent isn't easy, yet accepting the status quo isn't acceptable if we can bring change. A Scrum Master is accountable for helping the teams become cross-functional and self-managing.

How-To Determine Velocity for Multiple Teams Involved in a Sprint?

The question is not fully clear. Do you have multiple teams or a single team with people in dev, QC and DB ? I assume it is the former and your struggle is to align the work delivered by these teams.

I agree with Ian and Chris here. You seem to have a component-based team at the moment where each team i.e. dev, QC, DB seems to work in silos. You need to think about moving to a feature based structure and your team should have people from dev, QC and DB as it is their combined work that will give an increment of value (which probably is the point Ian seems to suggest when he says you do not have a team and a shared accountability also developers are dev,QC,DB and anyone else who contributes to build a done increment). 

Measuring velocity will be possible only once the team is in place and producing valuable increments in each sprint. The velocity is measured for the team rather than individual functions like dev, QA, DB. It is all about what you achieve together. Velocity is nothing but the number of done story points each sprint and when you do multiple sprints you can get an average velocity which will help you forecast how much work to actually take in a sprint

Agree with everything already said.  But let me try to add my spin in case it helps you better understand.

A Scrum Team is a group of individuals that have all of the skills needed to take a great idea and turn it into something that can be delivered to the stakeholder that asked for the great idea.  Software, hardware, medical treatment plans, large event that allows vendors to showcase their products are all examples of "products" that I have been involved with using Scrum. 

Velocity is the rate at which work is done.  Some people try to use story points to measure this (a practice I personally think is useless because it is based upon guesses), others use throughput or cycle time, while there are others that come up with their own scales.  Velocity for a Sprint is the rate at which a Sprint Backlog Item goes from "hey we need to work on this" to "there is nothing left for us to do on this Sprint Backlog Item. It is now part of the increment."  You can not measure velocity across multiple teams as each team is evaluating the work on their own basis and standards.  You need consistency to do the measurements. If each team works in a single domain, they measure based upon that domain. 

What everyone is trying to explain is that instead of having a developer team, qc team, db team you need to have a single team that has individuals that can be accountable for doing the development, qc, and db work that will estimate the effort for the entire team as a single unit rather than estimating each specific domain independently. Organize teams to have all the skills needed to do the work to turn Product Backlog Items into "done" increments of value that can be delivered to the stakeholders in each and every Sprint.  There shouldn't be a handoff of work from one team to another in a Sprint. 

Does this help?