Editing Database (section)

==Storage==
{{Main|Computer data storage|Database engine}}

Database storage is the container of the physical materialization of a database. It comprises the ''internal'' (physical) ''level'' in the database architecture. It also contains all the information needed (e.g., [[metadata]], "data about the data", and internal [[data structure]]s) to reconstruct the ''conceptual level'' and ''external level'' from the internal level when needed. Databases as digital objects contain three layers of information which must be stored: the data, the structure, and the semantics. Proper storage of all three layers is needed for future [[Database preservation|preservation]] and longevity of the database.<ref>{{cite journal |author1=Ramalho, J.C. |author2=Faria, L. |author3=Helder, S. |author4=Coutada, M. |date=31 December 2013 |title=Database Preservation Toolkit: A flexible tool to normalize and give access to databases |journal=Biblioteca Nacional de Portugal |publisher=University of Minho |url=https://core.ac.uk/display/55635702?algorithmId=15&similarToDoc=55614406&similarToDocKey=CORE&recSetID=f3ffea4d-1504-45e9-bfd6-a0495f5c8f9c&position=2&recommendation_type=same_repo&otherRecs=55614407,55635702,55607961,55613627,2255664 }}</ref> Putting data into permanent storage is generally the responsibility of the [[database engine]] a.k.a. "storage engine". Though typically accessed by a DBMS through the underlying operating system (and often using the operating systems' [[file system]]s as intermediates for storage layout), storage properties and configuration settings are extremely important for the efficient operation of the DBMS, and thus are closely maintained by database administrators. A DBMS, while in operation, always has its database residing in several types of storage (e.g., memory and external storage). The database data and the additional needed information, possibly in very large amounts, are coded into bits. Data typically reside in the storage in structures that look completely different from the way the data look at the conceptual and external levels, but in ways that attempt to optimize (the best possible) these levels' reconstruction when needed by users and programs, as well as for computing additional types of needed information from the data (e.g., when querying the database).

Some DBMSs support specifying which [[character encoding]] was used to store data, so multiple encodings can be used in the same database.

Various low-level database storage structures are used by the storage engine to serialize the data model so it can be written to the medium of choice. Techniques such as indexing may be used to improve performance. Conventional storage is row-oriented, but there are also [[column-oriented DBMS|column-oriented]] and [[correlation database]]s.

===Materialized views===
{{Main|Materialized view}}

Often storage redundancy is employed to increase performance. A common example is storing ''materialized views'', which consist of frequently needed ''external views'' or query results. Storing such views saves the expensive computing them each time they are needed. The downsides of materialized views are the overhead incurred when updating them to keep them synchronized with their original updated database data, and the cost of storage redundancy.

===Replication===
{{See also|Replication (computing)#Database replication}}

Occasionally a database employs storage redundancy by [[database object]]s replication (with one or more copies) to increase data availability (both to improve performance of simultaneous multiple end-user accesses to the same database object, and to provide resiliency in a case of partial failure of a distributed database). Updates of a replicated object need to be synchronized across the object copies. In many cases, the entire database is replicated.

===Virtualization===
With [[data virtualization]], the data used remains in its original locations and real-time access is established to allow analytics across multiple sources. This can aid in resolving some technical difficulties such as compatibility problems when combining data from various platforms, lowering the risk of error caused by faulty data, and guaranteeing that the newest data is used. Furthermore, avoiding the creation of a new database containing personal information can make it easier to comply with privacy regulations. However, with data virtualization, the connection to all necessary data sources must be operational as there is no local copy of the data, which is one of the main drawbacks of the approach.<ref name="Paiho">{{cite journal | doi=10.1049/smc2.12044 | title=Opportunities of collected city data for smart cities | year=2022 | last1=Paiho | first1=Satu | last2=Tuominen | first2=Pekka | last3=Rökman | first3=Jyri | last4=Ylikerälä | first4=Markus | last5=Pajula | first5=Juha | last6=Siikavirta | first6=Hanne | journal=IET Smart Cities | volume=4 | issue=4 | pages=275–291 | s2cid=253467923 | doi-access=free | issn=2631-7680}}</ref>