-1

If a database decomposition is not dependency preserving, is it safe to conclude that the decomposition is lossy as well without further proof?

To clarify - when I use decomposition in my question, I am referring to the act of breaking down a relation into smaller relations when trying to normalise a relation. E.g. decomposing a 1NF relation into a series of 2NF relations.

As outlined by this Quora post, a decomposition should be "lossless" and "preserve dependencies". I understand that a decomposition that preserves dependencies may not be lossless and vice versa; however, are there situations where a decomposition that doesn't preserve dependencies is not lossy?

A more formal definition of database decomposition can be outlined in "Database Systems: The Complete Book" (refer to below excerpt)

enter image description here

ptk
  • 6,835
  • 14
  • 45
  • 91
  • Define "decomposition". – philipxy Nov 21 '18 at 06:26
  • Hi. That is not a definition. It defers to "the process" that it says some vague stuff about but doesn't define. ("Decompostion" is frequently used to mean "lossless decomposition". FD preservation is only ever discussed in a context of lossless decomposition.) Please show effort. Why would it be lossy or not? An answer has to refer to decomposition, preservation & loss. If you gave some arguments, we could refer to the aspects that you refer to & expect you to understand. But you say nothing, so i've asked for a definition. Your question is so basic it seems to come from lack of definitions. – philipxy Nov 21 '18 at 07:35
  • PS Please make posts self-contained, put anything that is needed for your question in your question, with credit. PS Please don't append EDITs, edit your post to be the best it can be. PS Learn from a published academic textbook. Dozens are online free in pdf. PS [Re lossless decompostion & FD preservation.](https://stackoverflow.com/a/23966489/3404097) – philipxy Nov 21 '18 at 07:35
  • Thanks. Please [use text, not images/links, for text (including code, tables & ERDs)](https://meta.stackoverflow.com/q/285551/3404097). Use a link/image only for convenience to supplement text and/or for what cannot be given in text. And never give a diagram without a legend/key. Use edit functions to inline, not links, if you have the rep--make your post self-contained. PS Free OCR is online. But pdfs usually support cut & paste to text. – philipxy Nov 21 '18 at 20:52

1 Answers1

3

Consider a schema (A B C) with FDs {{A}->{B} ; {B}->{C}}.

Because of these FDs the candidate key will be {A}.

Consider the decomposition into schemas (A B) and (A C).

Because of the key [of the (ABC) schema] being {A}, this decomposition is lossless, in the [usual] sense that for any valid relation value r1 appearing for the (ABC) schema, we can take the corresponding relation values r2/r3 that would appear for the (AB) (AC) schemas, natural join them and be guaranteed we'll get back the original r1.

Now [do yourself a favour and do some thinking to] consider whether that decomposition is also dependency-preserving, and what the consequences are.

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52
  • Thanks for the clear explanation! In your example, the decomposition is not dependency-preserving since neither relation support the dependency where B -> C. However since it is still lossless, it means the answer to my question is a resounding **no**. – ptk Nov 21 '18 at 12:47
  • 1
    The "consequences" I hinted at were that since the {B}->{C} FD is "lost", the "losslessness" is only guaranteed for valid values of the (ABC) schema and not the other way round, i.e. there could be values in the decomposed version that could not validly appear in the nondecomposed one. I mentioned this (and carefully explained my sense of "lossless") so you would carefully check your textbook/course uses the exact same sense of "lossless", not more and not less, so to speak. – Erwin Smout Nov 21 '18 at 15:07