I would recommend one chart per service, with the additional simplification of making the "service B" chart depend on its database. I would make these charts independent: none of the services depend on any other.

The place where Helm dependencies work well is where you have a service that embeds/hides specific single other parts. The database behind B is an implementation detail, for example, and nothing outside B needs to know about it. So B can depend on stable/postgres or some such, and this works well in Helm.

There's one specific mechanical problem that causes problems for the umbrella-chart approach. Say service D also depended on a database, and it was the same "kind" of database (both use PostgreSQL, say). Operationally you want these two databases to be separate. Helm will see the two paths umbrella > B > database and umbrella > D > database, and only install one copy of the database chart, so you'll wind up with the two services sharing a database. You probably don't want that.

The other mechanical issue you'll encounter using Helm dependencies here is that most resources are named some variant of {{ .Release.Name }}-{{ .Chart.Name }}. In your option 1, say you do just install service C; you'd wind up with Deployments like service-C-C, service-C-B, service-C-database. If you then wanted to deploy service A alongside it, that would introduce its own service-A-B and service-A-database, which again isn't what you want.

I'm not aware of a great high-level open-source solution to this problem. A Make-based solution is hacky, but can work:

# -*- gnu-make -*-
all: api-proxy.deployed

%.deployed:
        helm upgrade --install --name $* -f values.yaml ./charts/$*
        touch $@

api-proxy.deployed: a.deployed c.deployed
a.deployed: b.deployed
c.deployed: b.deployed d.deployed