ddia(2)----Chapter2.Data Models and Query Languages

In this chapter we will look at a range of general-purpose data models for data storage and querying.

Relational Model Versus Document Model

The Birth of NoSQL

• NoSQL: Not only SQL
• polyglot persistence: relational databases

The Object-Relational Mismatch

• If data is stored in relational tables, an awkward translation layer is required between the objects in the application code and the database model of tables, rows, and columns. This disconnect between the models is sometimes called an impedance mismatch.

Relational Schema

JSON Schema

{
  "user_id": 251,
  "first_name": "Bill",
  "last_name": "Gates",
  "summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",
  "region_id": "us:91",
  "industry_id": 131,
  "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
  "positions": [
    {
      "job_title": "Co-chair",
      "organization": "Bill & Melinda Gates Foundation"
    },
    {
      "job_title": "Co-founder, Chairman",
      "organization": "Microsoft"
    }
  ],
  "education": [
    {
      "school_name": "Harvard University",
      "start": 1973,
      "end": 1975
    },
    {
      "school_name": "Lakeside School, Seattle",
      "start": null,
      "end": null
    }
  ],
  "contact_info": {
    "blog": "http://thegatesnotes.com",
    "twitter": "http://twitter.com/BillGates"
  }
}

The JSON representation has a better locality than the multi-table schema. If you want to fetch a profile in the relational example, you need to either perform multiple queries(query each table by user_id) or perform a messy multiway join between the user table and its subordinate tables. In the JSON representation, all the relevant information is in one place, and one query is sufficient.

Many-to-One and Many-to-Many Relationships

• In the preceding section, region_id and industry_id are given as IDs, not as plain-text strings. Why?
  1. When you use an ID, the information that is meaningful to humans is stored in only one place, and everything that refers to it uses an ID. When you store the text directly, you are duplicating the human-meaningful information in every record that uses it.
  2. Avoiding ambiguity (e.g., if there are several cities with the same name)
  3. Ease of updating----the ID has no meaning to humans, it never needs to change: the ID can remain the same, even if the information is changed.
  4. Localization support----convenient to translate into other languages
  5. Better search

Those schemas all need many-to-one relationships(many people live in one particular region, and many people work in one particular industry). We can consider some changes we could do:

• Organizations and schools as entities
  In the previous description, organization (the company where the user worked) and school_name (where they studied) are just strings. Perhaps they should be references to entities instead? Then each organization, school, or university could have its own web page (with logo, news feed, etc.)
  

Many-to-Many

Are Document Databases Repeating History?

In the 1970s, the design of IMS used a fairly simple model called the hierarchical model.
Various solutions were proposed to solve the limitations of the hierarchical model: relational model and network model.

The network model

The network model was a generalization of the hierarchical model. In the tree structure of the hierarchical model, every record has exactly one parent; in the network model, a record could have multiple parents. For example, there could be one record for the “Greater Seattle Area” region, and every user who lived in that region could be linked to it. This allowed many-to-one and many-to-many relationships to be modeled.