Hacker News Reader

Comment by lqet | Hacker News Reader

I also read the beginning of a few chapters and have to agree: the writing style is very concise.

Example (from the Introduction):

  One of the major advantages of the relational model is its uniformity. All data
  is viewed as being stored in tables, with each row in the table having the same
  format. Each row in the table summarizes some object or relationship in the
  real world. Whether the corresponding entities in the real world actually
  possess the uniformity the relational model ascribes to them is a question
  that the user of the model must answer. It is a question of the suitability of
  the model for the application at hand.
  Whether or not the relational model is appropriate for a particular set of
  data shall not concern us. There are plenty of instances where the model is
  appropriate, and we always assume we are dealing with such instances.

View on HN

Worth noting that here the use of the word "model" refers not to some indefinite domain-specific data schema, but "The Relational Model" as a paradigm.

It displaced the earlier paradigm of hierarchical data model, which derived more or less from physical media (eg punch cards).

The relational model is not well suited to uncertain data, as a row in a table is generally interpreted as a true proposition. For statistical data sets, analytical processing may be better served by array/tensor models (which also exhibit uniformity).

>The relational model is not well suited to uncertain data, as a row in a table is generally interpreted as a true proposition. For statistical data sets, analytical processing may be better served by array/tensor models (which also exhibit uniformity).

An outer join is an outer product, and you have the null value. I've never seen anyone use real tensors outside of physical simulations, but then again relational databases don't use real relationships either.

Null is intended for missing information, not uncertain information. It's common to use vectors to represent a signal.

Relational databases really are based on the set theoretic concepts of relations and functional dependency.

> The relational model is not well suited to uncertain data, as a row in a table is generally interpreted as a true proposition

True, but the proposition does not necessarily indicate a certain fact about the world. It might be e.g. measurement or observation or opinion or guess or whatever. The proposition is just that the measurement, guess or opinion is this.

The power of the relational model is that we can use operators to combine relations to form new relations, which are then understood to also encode true propositions. A relational join is a logical implication. This is how SQL is able to answer complex queries with certainty from elementary certain data.

Bayesian networks are able to do similar things from uncertain data.

> The relational model is not well suited to uncertain data, as a row in a table is generally interpreted as a true proposition. For statistical data sets, analytical processing may be better served by array/tensor models (which also exhibit uniformity).

Arrays/tensors and (relational) tables can be thought of as alternative ways to represent a set with this major difference:

o [Relational table] Each column is an axis. A row is point.

o [Arrays] Each dimension is an axis. A cell is a point.

This is why it is wrong to interpret a table with a two-dimensional array - their data have completely different semantics.

The success of a (data) model depends on its ability to represent and manipulate relationships in a simple and natural way.

There exist of course other uniform ways to represent data, for example, using functions (and operations with functions). But many of them have been developed under the umbrella of the relational model even though they have little to do with the relational principles.

Reply on news.ycombinator.com