## 2 Materials and Methods
### Educational Warehouse
#### 2.1.1 Basic System Architecture  
Educational institutions are continually generating data. Some of these data result from academic management processes such as administrative procedures, qualifications or certifications. In contrast, others result from the teaching-learning processes, such as feedback related to student's tasks or comments about their academic behavior. The analytic approaches to educational data must fulfil the requirements of both kinds of data. The origin of this data can be either internal or external depending on the EdTech services that are applied [61]. For example, in times of evaluation, there is a need to know the student's status and other data coming from different academic, learning and behavioral interactions; this data can be hosted both internal platforms and in third-party services available in the company's cloud. In the same way, educational institutions can benefit from data generated by other institutions, that is, the case of research activities, where quality data are fundamental for the correct generation of results. Educational institutions generate a series of anonymous data that can even be considered open data. Those datasets, once depersonalized, are of great value for research. Moreover, institutions are obliged to share data with public administration and government services. The possibility of automating those obligations, liberating tasks now done by machines, facilitates data exportation or even the interoperable connection between the institution and the administration. Based on those mentioned above, we designed a modular architecture that allows for data import, storage, analysis and even external access. This modular characteristic facilitates such scenery, being flexible, adaptable, decentralizable and scalable. It is flexible and adaptable so the different modules can be implemented using the technology required in every case and can be located either inside the institution, in the cloud or in a mixed local-cloud implementation. This arrangement permits adaptation to every institution's needs or even decentralization. Decentralization may allow the replication of the primary system's architecture and may modulate it as needed, whereas scalability would take place at a module level in conjunction with cloud computing. Figure 1 describes the system architecture layers implementing the aforementioned characteristics. Figure 1: The educational warehouse architecture: data are exchanged from different sources to a collector module where it can be processed and then sent into record storage. When there is a petition to analyze data, the Data Intelligence and Visualization module (DIV) accesses the storage to obtain the required data and stores its results. To make the request, the stakeholders use the data access interface module. Each educational warehouse integrates the following essential modules: Extract, Transform and Load (ETL), Learning Record Store (LRS), Data Intelligence and Visualization (DIV) and Data Access Interface (DAI). It is possible to customize them internally or to even add new ones according to each institution's requirements and needs. Some modules can be disabled if necessary. For each module, we proposed a series of possible actions as an example of good practice to ensure PICSPDM. As aforementioned in Section 1.5, each module may be affected by the local jurisdiction. Therefore, the technical actions and good practices associated with the ethical-legal framework should be adequate ones as determined by law. * ETL: This is the module that allows importing data from abroad. It contains the software and hardware in charge of importing data from different data sources (management and educational software of the institution, EdTech, LMS, etc.). The content imported to the ETL module can be of an encrypted and anonymized nature. Once stored, it cannot be identified by any entity but the users involved, i.e., using Pretty Good Privacy (PGP) encryption technology [62].