The database design phase is divided into three steps:
conceptual database design
logical database design
physical database design
In the conceptual database design phase, the model of the data to be used independent of all physical considerations is to be constructed. The model is based on the requirements specification of the system.
In the logical database design phase, the model of the data to be used is based on a specific data model, but independent of a particular database management system is constructed. This is based on the target data model for the database e.g. relational data model.
In the physical database design phase, the description of the implementation of the database on secondary storage is created. The base relations, indexes, integrity constraints, security, etc. are defined using the SQL language.
Database Application Development
Database Application Development is the process of obtaining real-world requirements, analyzing requirements, designing the data and functions of the system and then implementing the operations in the system, in compliance with requirement specifications.
Implementation involves the construction of a database according to the specification of a logical schema. This will include the specification of an appropriate storage schema, security enforcement, external schema, and so on. Implementation is heavily influenced by the choice of available DBMS, database tools and operating environment.
There are additional tasks beyond simply creating a database schema and implementing the constraints – data must be entered into the tables, issues relating to the users and user processes need to be addressed and the management activities associated with wider aspects of corporate data management need to be supported. In keeping with the DBMS approach we want as many of these concerns as possible to be addressed within the DBMS.
In practice, implementation of the logical schema in a given DBMS requires a very detailed knowledge of the specific features and facilities that the DBMS has to offer. In an ideal world, and in keeping with good software engineering practice, the first stage of implementation would involve matching the design requirement specifications with the best available implementing tools and then using those tools for the implementation. In database terms, this might involve choosing vendor products who’s DBMS and SQL variants are most suited to the database we need to implement.
However, we don’t live in an ideal world and more often than not, hardware choice and decisions regarding the DBMS will have been made well in advance of consideration of the database design. Consequently, implementation can involve additional flexing of the design to overcome any software or hardware limitations.
Biometric Security Template Storage
Special case of database design is data storage design for biometric data. Biometric data should never be stored in its raw format, but instead in template format. The template that is created and stored is not the biometric data itself (e.g., the fingerprint image) but instead the results from some kind of analysis and summary of the biometric data. This might be an analysis of the locations of minutia contained in fingerprints or a mathematical summary of the patterns in an iris image.
These templates contain the unique characteristics of a user's biometric information, and they are the master copies that each future data acquisition would be compared to.
Data retention requirements mandated by laws, regulations, accounting requirements, etc. will have a direct bearing of data storage design.
Biometric-based applications are growing with a need for large-scale deployment. Large-scale biometric applications do loose integration with RDBMS.
"A database is a collection of information organized to provide efficient retrieval."