While a data warehouse can be an extremely valuable LDS component, it is possible to build an LDS that draws data from numerous interoperable silos or separate data stores. What matters is not the type of system used to store the data, but the type of data it collects, stores, and makes available. For example, a data warehouse is not an LDS if it contains only aggregated and/or snapshot data. To be an LDS, a data warehouse must contain comprehensive, student-level longitudinal data that span many years.
Other types of data systems may be confused with an LDS. An operational data store (ODS), which is very similar in structure to a data warehouse, maintains only transitional information from multiple sources. The system is updated frequently to reflect the current status of an object (for example, a student's enrollment), rather than historical data. In effect, users are only able to make queries on recent data. (Inmon 1999) Similarly, a transactional database (a transactional data management system), which is designed for recording and processing data from only a single source, should also be distinguished from an LDS. While transactional systems manage the daily "transactions" of the school (attendance and disciplinary records, financial transactions, library circulation, etc.), their data change frequently and are not typically stored for the long term. Rather, transactional data are typically transformed for permanent storage in a data warehouse and accessed by the LDS for long-term tracking. Even when they are stored, these data are not suitable for trend reporting and analysis. In sum, while very useful for daily school operations, neither of these types of systems can substitute for the functionalities of an LDS.
|"Call the IT department and tell them to build us an LDS."|