Sensor Database Clause Samples

Sensor Database. The purpose of the database is to store the data, which arrives from module 3 for long-run analysis, which will most probably be required in many cases by the optimization modules. Saving historical data will enable statistical analysis required for the development and improve- ment of the controllers’ models. Additionally, this data can be used to create Business Intelli- gence (BI) dashboards and other KPI tools. It is our understanding that in certain applications there will not be a need for such a database, since in some cases all the analysis will be done in memory at real time. However, the majority of the cases we have seen in the industry so far have been hybrid cases where both real-time data and historical data are analyzed. In order to design a generic system which can be applicable to as many scenarios as possible we will have to design an appropriate data schema as part of our WP. For demonstration pur- poses, we present in the following figure a preliminary ERD schema, which we will improve during the project based on the actual cases involved. FactoryName FactoryLocation FactoryDescription PK SensorId ProviderName 1 ∞ SensorType PK SensorTypeID SensorID SensorTypeDescription ManufacturingDate PK PropertyID PropertyType PropertyDescription FactoryID ProcessName ProcessDescription ∞ ProcessID FactoryID NodeLocation PK MeasurementID FactoryID ProcessID NodeID SensorID SensorTypeID ProperyIS MeasurementDate MeasurementValue MeasurementNullIND MeasurementReliability
Sensor Database. The Sensor Database hosts data collected from WSN sensors across pilot sites. It is accessed by the Data Recorder software module described in chapter 4. 1.2.1 and by WP4 data processing software components. The DB solution involves the usage of a document-oriented database MongoDB. The latter eschews the traditional table-based relational database structure in favour of JSON documents with dynamic schemas. MongoDB organize its data in internal databases and, for each database, several collections of heterogeneous documents. The fact of not being tied to a certain schema makes the integration of data of certain types easier and faster in applications where no assumption can be made about the data generated by sources. In DOREMI, the data model will include one internal database with two documents collections: the Data Feed collection and the Data collection.