In information system design, data modeling is the analysis and design of the information in the system, concentrating on the logical entities and the logical dependencies between these entities. Data modeling is an abstraction activity in that the details of the values of individual data observations are ignored in favor of the structure, relationships, names and formats of the data of interest, although a list of valid values is frequently recorded. It is by the data model that definitions of what the data means is related to the data structures.
While a common term for this activity is "data analysis" the activity actually has more in common with the ideas and methods of synthesis (putting things together) than it does in the original meaning of the term analysis (taking things apart). This is because the activity strives to bring the data structures of interest together in a cohesive, inseparable, whole by eliminating unnecessary data redundancies and relating data structures by relationships.
In the early phases of a software development project, emphasis will be on the design of a conceptual data model. This can be detailed into a logical data model sometimes called a functional data model. In later stages, this model may be translated into physical data model.
Several techniques have been developed for the design of a data models. Most noticeable are:
Datamodeling is the act of exploring data-oriented structures.
Physical datamodeling is conceptually similar to design class modeling, the goal being to design the internal schema of a database, depicting the data tables, the data columns of those tables, and the relationships between the tables.
Data normalization is a process in which data attributes within a datamodel are organized to increase the cohesion of tables and to reduce the coupling between tables.
Data attributes on conceptual and logical datamodels, as well as columns on physical datamodels, are modeled using the standard attribute notation.
Traditional datamodels typically don’t have a good way of distinguishing which key an attribute or column is a part of, this information is often left for supporting documentation.
It may be a copy of data from another source, a copy that may or may not be automatically replicated, or it may be deprecated and therefore it is suggested that the database element is not accessed at all.