Unify and enhance data model related documents

In IoTDB, there are two interchangeable concepts: sensor, measurement. Both of them are the names of physical variables recorded by a timeseries, like "temperature", "pressure", "voltage". Together with another important concept, device, a timeseries is described. A device is the full name of a physical entity that collects timeseries data, for example, "root.BJ.ServerRoom001.Server007" describes a computer whose Id is 007 in a server room with an Id of 001 in Beijing. Put together, device + measurement describes the full name of a timeseries, which is a collection of observations and the observed timestamps, for example, timeseries "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility" stores the utility of a CPU core of a computer mentioned above.

To make it simple:
sensor=measurement=the name of an observation
device=the name of an entity that collects data with timestamp
timeseries=device + measurement=an observation taken by a specific entity

It should be noticed that a device in IoTDB must collect data itself, which means having measurements directly under it, and this may conflict with some intuition. For example, we can model the utility of CPU cores like "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility", but the device is "root.BJ.ServerRoom001.Server007.CPU0" and "root.BJ.ServerRoom001.Server007" is not a device in IoTDB as it does not collect data directly. From the point of view of asset management, "root.BJ.ServerRoom001.Server007" is certainly another type of device, but IoTDB focuses on timeseries management instead of asset management, so we have a different definition of device. It is currently advised to cope with a relational DBMS for asset management instead of completely relying on IoTDB.

In practice, a real sensor is a device itself, so the name sensor is very confusing. I would like to propose that we replace all sensor occurrences with measurement.

measurement is also used in other systems like InfluxDB, but has a totally different meaning, as measurement in InfluxDB is more like the table name in a relational DBMS. For a viable schema mapping, one can refer to the following:
measurement(IoTDB)=field(InfluxDB)=non-indexed columns(relational DB)
device(IoTDB)=measurement+tags(Influxdb)=indexed columns(relational DB)
For the "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility" example above, the corresponding InfluxDB schema can be:
measurement(InfluxDB)="BJ"
tags(InfluxDB)=(ServerRoomId=001, ServerId=007, CPUId=0)
field(InfluxDB)=Core0_Utility