There has been significant progress towards integrated databases through advances in database technology, open systems architecture, and vendor development of applications that integrate data used across applications such as payroll and student information systems. These systems typically contain demographic and financial information on faculty and students that has been difficult to bring together without an integrated database.
The data do not need to reside in a single, physical location. However, the integrated database does need to be able to understand the relationships between files and data elements wherever they physically exist, and does need to eliminate, or reduce, duplicated or redundant data such as names and addresses and account balances. Duplicate or redundant data often imply duplicated data entry, which increases the opportunity for discrepancies to exist between data in different files.
Integration of software applications based on advanced database technology is a key concept. Most markets for new information technology are making integrated solutions a top priority, and vendors are responding to this demand. Some institutions are adopting a "best of breed" strategy of purchasing separate software modules from several different vendors, which makes integration of applications a necessary strategy. Most vendors are designing software so that their applications integrate easily with other vendor products. The choice of underlying database in a commercial product is important because it often limits the software that can be integrated with the financial applications.
Integrated databases can be created from the separate application databases from which they derive -- for example, by employing "design around" strategies. This means that the application processes are updating the primary database and periodically the data are integrated in a separate process that allows enterprise-wide data to be available using a different database "engine." So, proprietary operating systems with their own database supporting legacy systems can be accessed to create an integrated set of data that can be used at the enterprise level. This is not necessarily an overhead, since the total processing time for transactions and data integration, depending on the size of the database, may be less with the design-around strategy and save large investments in the redesign of applications. At best, the design-around approach provides time for more meaningful reengineering of business processes without the immediate commitment to the technological solution.