You can cause the completion of one build to trigger another. You can also pass parameters to a build.
First, some terminology: I'll refer to each of Database, Client, Cucumber Tests, and Library as a repository. A job is how Jenkins defines it: a runnable task controlled/monitored by Jenkins. A build is an execution of a job.
Two schemes for causing a version control commit to start a build would be Push and Pull. Push means the version control system takes an action that causes Jenkins to start a build. Pull means Jenkins polls the version control system for changes that justify starting a build.
Each scheme starts with creating a job with four parameters, one per build. Each parameter specifies a branch name.
In a Push scheme, a build would be launched by a commit hook in the version control system. For example, if the OP uses Git, they can use the post-commit hook to determine which branch had changed and then issue an HTTP request to Jenkins to launch the build.
That assumes there is network connectivity between the committer and Jenkins, and that any Jenkins access control issues can be worked out.
If access control is not a problem but there is no network connectivity, it may be possible for commit hook to post a build request to an intermediary, and then for the intermediary to cause Jenkins to launch a build.
The goal for the Pull system would be to configure Jenkins to poll for changes in all branches of four repository. Jenkins has a Multiple SCMs Plugin that might do what you want. The documentation says the plugin was deprecated in favor of the Pipeline Plugin. You might try looking at that too.
Another option would be to create four "launcher" jobs, one per repository. Each launcher job would poll the version control system for changes in its corresponding repository. The Git Plugin supports polling all branches. When it detects change, it would launch a build with the appropriate branch information. You will have to research how to determine which specific branch has changed.