Editing Database design (section)

==Logical data modeling==
{{Main|Logical schema}}
Once the relationships and dependencies amongst the various pieces of information have been determined, it is possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the [[database management system]]. In the case of [[relational databases]] the storage objects are [[database table|tables]] which store data in rows and columns. In an [[Object database]] the storage objects correspond directly to the objects used by the [[Object-oriented programming language]] used to write the applications that will manage and access the data. The relationships may be defined as attributes of the object classes involved or as methods that operate on the object classes.

The way this mapping is generally performed is such that each set of related data which depends upon a single object, whether real or abstract, is placed in a table. Relationships between these dependent objects are then stored as links between the various objects.

Each table may represent an implementation of either a logical object or a relationship joining one or more instances of one or more logical objects. Relationships between tables may then be stored as links connecting child tables with parents. Since complex logical relationships are themselves tables they will probably have links to more than one parent.

=== Normalization ===
{{Main|Database normalization}}
In the field of [[relational database]] design, ''normalization'' is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics—insertion, update, and deletion anomalies that could lead to  loss of [[data integrity]].

A standard piece of database design guidance is that the designer should create a fully normalized design; selective [[denormalization]] can subsequently be performed, but only for [[computer performance|performance]] reasons. The trade-off is storage space vs performance. The more normalized the design is, the less data redundancy there is (and therefore, it takes up less space to store), however, common data retrieval patterns may now need complex joins, merges, and sorts to occur – which takes up more data read, and compute cycles. Some modeling disciplines, such as the [[dimensional modeling]] approach to [[data warehouse]] design, explicitly recommend non-normalized designs, i.e. designs that in large part do not adhere to [[Third normal form|3NF]]. Normalization consists of normal forms that are [[First normal form|1NF]], [[Second normal form|2NF]], 3NF, [[Boyce–Codd normal form|Boyce-Codd NF (3.5NF)]], [[Fourth normal form|4NF]], [[Fifth normal form|5NF]] and [[Sixth normal form|6NF]].

Document databases take a different approach. A document that is stored in such a database, typically would contain more than one normalized data unit and often the relationships between the units as well. If all the data units and the relationships in question are often retrieved together, then this approach optimizes the number of retrieves. It also simplifies how data gets replicated, because now there is a clearly identifiable unit of data whose consistency is self-contained. Another consideration is that reading and writing a single document in such databases will require a single transaction – which can be an important consideration in a [[Microservices]] architecture. In such situations, often, portions of the document are retrieved from other services via an API and stored locally for efficiency reasons. If the data units were to be split out across the services, then a read (or write) to support a service consumer might require more than one service calls, and this could result in management of multiple transactions, which may not be preferred.