" So is your answer "it's not possible"? "
Many things are possible. In your very particular case, it looks to me like enforcing your 'additional' constraint can be achieved by keeping the database single-table (4-column). This will guarantee you that any combined a,b will always correspond to the same d (because there can only ever be one single d). The price you pay is that there is no longer a "natural" way (i.e. one that is an immediate consequence of the very logical structure of the database itself) that will enforce your a->d and b->d FDs "automatically".
It is a well-known fact that the classical process of normalization-through-decomposition, sometimes requires that certain FDs be reinstated as a database constraint, because in the decomposed design the rule can no longer be stated as an FD. Your particular case seems to be one such, where you have the choice between a design that "automatically" enforces a->d and b->d, but where you have to do extra effort to enforce your additional constraint, or a design that "automatically" enforces your additional constraint, but where you have to do extra work to enforce [the constraints corresponding to] your a->d and b->d FDs.
Having ALL the constraints you mention enforced merely by database structure, is possible, in your particular case, using onedaywhen's solution. However, (a) that is only a solution for particular cases such as your example, (b) the price you pay is increased redundancy, and therefore additional complexity in updating your database (and certain updates might be impossible to achieve !!!), and (c) it still remains a fact that not all conceivable database constraints are expressible as an FD.
(Sorry for posting a second answer. My Stackoverflow login doesn't allow me to comment here.)