Jump to content

Schema evolution: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Jfroddick (talk | contribs)
No edit summary
Jfroddick (talk | contribs)
No edit summary
Line 1: Line 1:
In [[computer science]], '''schema versioning''', and its weaker companion, '''schema evolution''', deal with the need to retain current data and software system functionality in the face of changing database structure<ref>{{cite journal|last1=Roddick|first1=John F|title=A survey of schema versioning issues for database systems|journal=nformation and Software Technology|date=1995|volume=37|issue=7|pages=383-393|doi=10.1016/0950-5849(95)91494-K|url=http://www.sciencedirect.com/science/article/pii/095058499591494K}}</ref>. The problem is not limited to the modification of the schema. It, in fact, affects the data stored under the given schema and the queries (and thus the applications) posed on that schema.
In [[computer science]], '''schema versioning''', and its weaker companion, '''schema evolution''', deal with the need to retain current data and software system functionality in the face of changing database structure<ref>{{cite journal|last1=Roddick|first1=John F|title=A survey of schema versioning issues for database systems|journal=Information and Software Technology|date=1995|volume=37|issue=7|pages=383-393|doi=10.1016/0950-5849(95)91494-K|url=http://www.sciencedirect.com/science/article/pii/095058499591494K}}</ref>. The problem is not limited to the modification of the schema. It, in fact, affects the data stored under the given schema and the queries (and thus the applications) posed on that schema.


Until recently the design of a database was expected{{By whom|date=September 2016}} to create a "one size fits all" schema capable of accepting every future change in the requirements, thus, schema evolution was not considered{{By whom|date=September 2016}}. This assumption, almost unrealistic in the context of traditional information systems, becomes unacceptable in the context of [[Web information system|Web Information Systems]], that due to the distributed and cooperative nature of their development and fruition are subject of an even stronger pressure toward change (from 39% to over 500% more intense than in traditional settings).<ref>{{Cite web |url=http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Schema_Evolution_Benchmark |title=Schema Evolution Benchmark - Schema Evolution |publisher=yellowstone.cs.ucla.edu |accessdate=2010-07-29 }}</ref> Due to this historical heritage the process of schema evolution is nowadays a particularly taxing one. It is, in fact, widely acknowledged that the data management core of an applications is one of the most difficult and critical components to evolve. The key problem is the impact
Until recently the design of a database was expected{{By whom|date=September 2016}} to create a "one size fits all" schema capable of accepting every future change in the requirements, thus, schema evolution was not considered{{By whom|date=September 2016}}. This assumption, almost unrealistic in the context of traditional information systems, becomes unacceptable in the context of [[Web information system|Web Information Systems]], that due to the distributed and cooperative nature of their development and fruition are subject of an even stronger pressure toward change (from 39% to over 500% more intense than in traditional settings).<ref>{{Cite web |url=http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Schema_Evolution_Benchmark |title=Schema Evolution Benchmark - Schema Evolution |publisher=yellowstone.cs.ucla.edu |accessdate=2010-07-29 }}</ref> Due to this historical heritage the process of schema evolution is nowadays a particularly taxing one. It is, in fact, widely acknowledged that the data management core of an applications is one of the most difficult and critical components to evolve. The key problem is the impact
Line 11: Line 11:
</ref> (which provides an analysis of the MediaWiki evolution) each evolution step might affect up to 70% of the queries operating on the schema, that must be manually reworked consequently.
</ref> (which provides an analysis of the MediaWiki evolution) each evolution step might affect up to 70% of the queries operating on the schema, that must be manually reworked consequently.


The problem has been recognized as a very pressing one by the database community for more than 12 years.<ref>{{cite web |title=An Online Bibliography on Schema Evolution |vauthors=Rahm E, Bernstein PA |url=http://www.sigmod.org/sigmod/record/issues/0612/p30-article-rahm.pdf |access-date=2 May 2017}}</ref>
The problem has been recognized as a very pressing one by the database community for more than 12 years.<ref>{{cite web |title=An Online Bibliography on Schema Evolution |vauthors=Rahm E, Bernstein PA |url=http://www.sigmod.org/sigmod/record/issues/0612/p30-article-rahm.pdf |access-date=2 May 2017}}</ref><ref>{{Cite book|url=https://link.springer.com/referenceworkentry/10.1007/978-0-387-39940-9_323|title=Encyclopedia of Database Systems|last=Roddick|first=John F.|date=2009|publisher=Springer, Boston, MA|pages=2499–2502|language=en|doi=10.1007/978-0-387-39940-9_323}}</ref> The support for Schema Evolution, is a difficult problem involving complex mapping among schema versions, the tool support has been so far very limited. The recent theoretical advances on mapping composition<ref>{{Cite web|url=http://portal.acm.org/citation.cfm?id=1206053 |title=Composition of mappings given by embedded dependencies |publisher=portal.acm.org |accessdate=2010-07-29 }}</ref> and mapping invertibility,<ref>{{cite web |title=Quasi-inverses of Schema Mappings |vauthors=Fagin R, Kolaitis PG, Popa L, Tan WC |url=http://www.almaden.ibm.com/cs/people/fagin/quasi.pdf}}</ref> which represent the core problems underlying the schema evolution remains almost inaccessible to the large public.
The support for Schema Evolution, is a difficult problem involving complex mapping among schema versions, the tool support has been so far very limited. The recent theoretical advances on mapping composition<ref>{{Cite web|url=http://portal.acm.org/citation.cfm?id=1206053 |title=Composition of mappings given by embedded dependencies |publisher=portal.acm.org |accessdate=2010-07-29 }}</ref> and mapping invertibility,<ref>{{cite web |title=Quasi-inverses of Schema Mappings |vauthors=Fagin R, Kolaitis PG, Popa L, Tan WC |url=http://www.almaden.ibm.com/cs/people/fagin/quasi.pdf}}</ref> which represent the core problems underlying the schema evolution remains almost inaccessible to the large public.


==Related works==
==Related works==

Revision as of 04:37, 18 January 2018

In computer science, schema versioning, and its weaker companion, schema evolution, deal with the need to retain current data and software system functionality in the face of changing database structure[1]. The problem is not limited to the modification of the schema. It, in fact, affects the data stored under the given schema and the queries (and thus the applications) posed on that schema.

Until recently the design of a database was expected[by whom?] to create a "one size fits all" schema capable of accepting every future change in the requirements, thus, schema evolution was not considered[by whom?]. This assumption, almost unrealistic in the context of traditional information systems, becomes unacceptable in the context of Web Information Systems, that due to the distributed and cooperative nature of their development and fruition are subject of an even stronger pressure toward change (from 39% to over 500% more intense than in traditional settings).[2] Due to this historical heritage the process of schema evolution is nowadays a particularly taxing one. It is, in fact, widely acknowledged that the data management core of an applications is one of the most difficult and critical components to evolve. The key problem is the impact of the schema evolution on queries and applications. As shown in [3] (which provides an analysis of the MediaWiki evolution) each evolution step might affect up to 70% of the queries operating on the schema, that must be manually reworked consequently.

The problem has been recognized as a very pressing one by the database community for more than 12 years.[4][5] The support for Schema Evolution, is a difficult problem involving complex mapping among schema versions, the tool support has been so far very limited. The recent theoretical advances on mapping composition[6] and mapping invertibility,[7] which represent the core problems underlying the schema evolution remains almost inaccessible to the large public.

Related works

References

  1. ^ Roddick, John F (1995). "A survey of schema versioning issues for database systems". Information and Software Technology. 37 (7): 383–393. doi:10.1016/0950-5849(95)91494-K.
  2. ^ "Schema Evolution Benchmark - Schema Evolution". yellowstone.cs.ucla.edu. Retrieved 2010-07-29.
  3. ^ Curino CA, Moon HJ, Tanca L, Zaniolo C (2008). Schema Evolution in Wikipedia: toward a Web Information System Benchmark, (PDF). ICEIS.
  4. ^ Rahm E, Bernstein PA. "An Online Bibliography on Schema Evolution" (PDF). Retrieved 2 May 2017.
  5. ^ Roddick, John F. (2009). Encyclopedia of Database Systems. Springer, Boston, MA. pp. 2499–2502. doi:10.1007/978-0-387-39940-9_323.
  6. ^ "Composition of mappings given by embedded dependencies". portal.acm.org. Retrieved 2010-07-29.
  7. ^ Fagin R, Kolaitis PG, Popa L, Tan WC. "Quasi-inverses of Schema Mappings" (PDF).