Why is a non-dependency preserving BCNF decomposition still considered to be in BCNF?

From the Database Systems Concept textbook, for a schema r with the set of dependencies F to be considered in BCNF, for all dependencies in F+ (i.e. the closure of F) of the form a → b, at least one of the following must be true:

• a → b is a trivial functional dependency (b ⊆ a)
• a is a superkey for schema r

The example that the textbook gives is that for a schema dept_advisor (s_ID,i_ID,dept_name) with the functional dependencies F = {i_ID → dept_name; s_ID, dept_name → i_ID}, the BCNF decomposition would be:

• r1 (s_ID, i_ID)
• r2 (i_ID, dept_name)

This decomposition fulfills the 1st dependency (i_ID → dept_name) since i_ID is a superkey for r2, but since it doesn't satisfy the 2nd dependency (s_ID, dept_name → i_ID, hence being non-dependency preserving), doesn't this decomposition not adhere to BCNF since the 2nd dependency is nontrivial but is not a superkey for the schema of the decomposition?

You have correctly reported a definition for BCNF: for each non-trivial dependency of F⁺, the determinant is a superkey.

So, in your example, both the relation schemas in the decomposition fulfill this definition: in r2 in the only non-trivial dependency i_ID → dept_name the determinant is a superkey, while in r1 there are no non-trivial dependencies so the definition is still satisfied. So you have two schemas which are both in BCNF.

But, as again you have correctly noted, the dependency s_ID, dept_name → i_ID does not hold in the set of dependencies of the decomposition (even if you perform the closure of the union of the set of dependencies of the r1 and r2), and this means that the decomposition does not preserve the dependencies. What this means, in practice, is that in the decomposed schema the fact that a couple of values of s_ID and dept_name could correspond to more than one value of i_ID, so losing an important integrity contraint.

What this example can teach us? That we can have a decomposition of a schema in BCNF which produces a database that could contain inconsistent data. And note that in this particular case there is no decomposition in BCNF that can preserve the dependencies. So BCNF is not a panacea for eliminating all problems in database design, and in fact other normal forms have been defined and can be used to alleviate several problems of database design. For instance, the original schema of the example is already in Third Normal Form (3NF), and this is considered acceptable in practical situations.