Main Page: Difference between revisions

From formulasearchengine
Jump to navigation Jump to search
← Older editNewer edit →
No edit summary
mNo edit summary
Line 1: Line 1:
{{Original research|date=June 2010}}
A '''federated database system''' is a type of [[meta-]][[database management system]] (DBMS), which transparently maps multiple autonomous [[Database management system|database systems]] into a single '''federated database'''. The constituent [[database]]s are interconnected via a [[computer network]] and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or '''virtual database''', is a composite of all constituent databases in a federated database system.  There is no actual data integration in the constituent disparate databases as a result of data federation.


[[Image:Hyperbolic coordinates.svg|thumb|400px|right|Hyperbolic coordinates plotted on the Cartesian plane: ''u'' in blue and ''v'' in red.]]
Through [[data abstraction]], federated database systems can provide a uniform [[user interface]], enabling [[user (computing)|users]] and [[Client (computing)|clients]] to store and retrieve [[data]] from multiple noncontiguous [[database]]s with a single [[Information retrieval|query]] -- even if the constituent databases are [[heterogeneous]]. To this end, a federated database system must be able to decompose the query into subqueries for submission to the relevant constituent [[database management system|DBMS's]], after which the system must composite the [[result set]]s of the subqueries. Because various database management systems employ different [[query language]]s, federated database systems can apply [[wrapper function|wrappers]] to the subqueries to translate them into the appropriate [[query language]]s.


In [[mathematics]], '''hyperbolic coordinates''' are a method of locating points in Quadrant I of the [[Cartesian plane]]{{Why?|date=May 2010}}
==Definition==
McLeod and Heimbigner<ref name ="reftwo">"{{cite conference | author = McLeod and Heimbigner | title=A Federated Architecture for information management | booktitle = ACM Transactions on Information Systems, Volume 3, Issue 3 | year =1985 | pages = 253–278 | url= http://dl.acm.org/citation.cfm?id=4233}}</ref> were among the first to define a federated database system in the mid 1980's. 


:<math>\{(x, y) \ :\ x > 0,\ y > 0\ \} = Q\ \!</math >.
A FDBS is one which "define[s] the architecture and interconnect[s] databases that minimize central authority yet support partial sharing and coordination among database systems".<ref name ="reftwo" /> This description might not accurately reflect the McLeod/Heimbigner<ref name="reftwo"/> definition of a federated database.  Rather, this description fits what McLeod/Heimbinger called a ''composite'' database. McLeod/Heimbigner's federated database is a collection of autonomous components that make their data available to other members of the federation through the publication of an export schema and access operations; there is no unified, central schema that encompasses the information available from the members of the federation.


Hyperbolic coordinates take values in the hyperbolic plane defined as:
Among other surveys,<ref name ="refone">"{{cite conference | author=Sheth and Larson | title=Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases | booktitle = ACM Computing Surveys, Vol. 22, No.3 | year=1990 | pages= 183–236 | url=http://dl.acm.org/citation.cfm?id=96604}}</ref> practitioners define a Federated Database as a collection of cooperating component systems which are autonomous and are possibly [[Heterogeneous Database System|heterogeneous]].


:<math>HP = \{(u, v) : u \in \mathbb{R}, v > 0 \}</math>.
The three important components of an FDBS are autonomy, [[Heterogeneous Database System|heterogeneity]] and distribution.<ref name="refone"/> Another dimension which has also been considered is the Networking Environment [[Computer Network]], e.g., many DBSs over a  [[Local Area Network|LAN]] or many DBSs over a [[Wide Area Network|WAN]] update related functions of participating DBSs (e.g., no updates, nonatomic transitions, [[atomicity (database systems)|atomic updates]]).


These coordinates in ''HP'' are useful for studying logarithmic comparisons of [[direct proportion]] in ''Q'' and measuring deviations from direct proportion.
== FDBS architecture ==


For <math>(x,y)</math> in <math>Q</math> take
A [[Database management system|DBMS]] can be classified as either centralized or distributed. A centralized system manages a single database while distributed manages multiple databases. A component [[Database|DBS]] in a DBMS may be centralized or distributed. A multiple DBS (MDBS) can be classified into two types depending on the autonomy of the component DBS as federated and non federated. A nonfederated database system is an integration of component [[Database management system|DBMS]] that are not autonomous.
A federated database system consists of component [[Database|DBS]] that are autonomous yet participate in a federation  to allow partial and controlled sharing of their data.


:<math>u = -\frac{1}{2} \ln \left( \frac{y}{x} \right)</math>
Federated architectures differ based on levels of integration with the component database systems and the extent of services offered by the federation. A FDBS can be categorized as loosely or tightly coupled systems.


and
* Loosely Coupled require component databases to construct their own federated [[Database schema|schema]]. A user will typically access other component database systems by using a multidatabase language but this removes any levels of location transparency, forcing the user to have direct knowledge of the federated schema. A user imports the data they require from other component databases and integrates it with their own to form a federated schema.
* Tightly coupled system consists of component systems that use independent processes to construct and publicize an integrated federated schema.


:<math>v = \sqrt{xy}</math>.
Multiple DBS of which FDBS are a specific type can be characterized along three dimensions: Distribution, Heterogeneity and Autonomy. Another characterization could be based on the dimension of networking, for example single databases or multiple databases in a [[Local Area Network|LAN]] or [[Wide Area Network|WAN]].


Sometimes the parameter <math>u</math> is called [[hyperbolic angle]] and v the [[geometric mean]].
=== Distribution ===


The inverse mapping is
Distribution of data in an FDBS is due to the existence of a multiple DBS before an FDBS is built. Data can be distributed among multiple DB which could be stored in a single computer or multiple computers. These computers could be geographically located in different places but interconnected by a network. The benefits of data distribution help in increased availability and reliability as well as improved access times.


:<math>x = v e^u ,\quad y = v e^{-u}</math>.
==== Heterogeneity ====
{{main|Heterogeneous database system}}
Heterogeneities in databases arise due to factors such as differences in structures, semantics of data, the constraints supported or [[query language|query]] language. Differences in structure occur when two [[data model]]s provide different primitives such as [[Object-Oriented Modeling|object oriented (OO) models]] that support specialization and inheritance and [[relational model]]s that do not. Differences due to constraints occur when two models support two different constraints. For example the set type in [[CODASYL]] [[Database schema|schema]] may be partially modeled as a referential integrity constraint in a relationship schema. [[CODASYL]] supports insertion and retention that are not captured by referential integrity alone. The query language supported by one [[Database management system|DBMS]] can also contribute to  [[Heterogeneous Database System|heterogeneity]] between other component [[Database management system|DBMSs]]. For example, differences in query languages with the same [[data model]]s or different versions of query languages could contribute to [[Heterogeneous Database System|heterogeneity]].


This is a [[continuous mapping]], but not an [[analytic function]].
Semantic heterogeneities arise when there is a disagreement about meaning, interpretation or intended use of [[data]]. At the schema and data level, classification of possible heterogeneities include:
* Naming conflicts e.g. [[database]]s using different names to represent the same concept.
* Domain conflicts or [[data]] representation conflicts e.g. [[database]]s using different values to represent same concept.
* Precision conflicts e.g. [[database]]s using same data values from domains of different [[Cardinality|cardinalities]] for same [[data]].
* [[Metadata]] conflicts e.g. same concepts are represented at [[Database schema|schema]] level and instance level.
* [[Data]] conflicts e.g. missing [[Attribute (computing)|attributes]]
* [[Database schema|Schema]] conflicts e.g. table versus table conflict which includes naming conflicts, data conflicts etc.


==Quadrant model of hyperbolic geometry==
In creating a federated schema, one has to resolve such heterogeneities before integrating the component DB schemas.


The correspondence
==== Schema matching, schema mapping ====
Dealing with incompatible data types or query syntax is not the only obstacle to a concrete implementation of an FDBS. In systems that are not planned top-down, a generic problem lies in matching [[semantic equivalence|semantically equivalent]], but differently named parts from different [[logical schema|schemas]] (=data models) (tables, attributes). A pairwise mapping between ''n'' attributes would result in <math>n (n-1) \over 2</math> mapping rules (given equivalence mappings) - a number that quickly gets too large for practical purposes. A common way out is to provide a global schema that comprises the relevant parts of all member schemas and provide mappings in the form of [[database view]]s. Two principal solutions can be realized, depending on the direction of the mapping:
# Global as View (GaV): the global schema is defined in terms of the underlying schemas
# Local as View (LaV): the local schemas are defined in terms of the global schema
Both are explained in more detail in the article [[Data integration]].
Alternate approaches to the schema matching problem and a classification of the same are explained in more detail in the article [[Schema Matching]]


:<math>Q \leftrightarrow HP</math>
=== Autonomy ===
Fundamental to the difference between an MDBS and an FDBS is the concept of autonomy.  It is important to understand the aspects of autonomy for component databases and how they can be addressed when a component DBS participates in an FDBS.
There are four kinds of autonomies addressed:
* Design Autonomy which refers to ability to choose its design irrespective of data, query language or conceptualization, functionality of the system implementation.
[[Heterogeneous Database System|Heterogeneities]] in an FDBS are primarily due to design autonomy.
* Communication autonomy refers to the general operation of the DBMS to communicate with other [[Database management system|DBMS]] or not.
* Execution autonomy allows a component DBMS to control the operations requested by local and external operations.
* Association autonomy gives a power to component DBS to disassociate itself from a federation which means FDBS can operate independently of any single [[Database|DBS]].


affords the [[hyperbolic geometry]] structure to ''Q'' that is erected on ''HP'' by [[hyperbolic motion]]s. The ''hyperbolic lines'' in ''Q'' are [[Line (mathematics)#Ray|rays]] from the origin or [[petal]]-shaped [[curve]]s leaving and re-entering the origin. The left-right shift in ''HP'' corresponds to a [[squeeze mapping]] applied to ''Q''. Note that hyperbolas in ''Q'' do ''not'' represent [[geodesic]]s in this model.
The ANSI/X3/SPARC Study Group outlined a three level data description architecture, the components of which are the conceptual schema, internal schema and external schema of databases. The three level architecture is however inadequate to describing the architectures of an FDBS.  It was therefore extended to support the three dimensions of the FDBS namely Distribution, Autonomy and Heterogeneity. The five level schema architecture is explained below.


If one only considers the [[Euclidean topology]] of the plane and the topology inherited by ''Q'', then the lines bounding ''Q'' seem close to ''Q''. Insight from the [[metric space]] ''HP'' shows that the [[open set]] ''Q'' has only the [[origin (mathematics)|origin]] as boundary when viewed as the quadrant model of the hyperbolic plane. Indeed, consider rays from the origin in ''Q'', and their images, vertical rays from the boundary ''R'' of ''HP''. Any point in ''HP'' is an infinite distance from the point ''p'' at the foot of the perpendicular to ''R'', but a sequence of points on this perpendicular may tend in the direction of ''p''. The corresponding sequence in ''Q'' tends along a ray toward the origin. The old Euclidean boundary of ''Q'' is irrelevant to the quadrant model.
=== Concurrency control ===
The ''Heterogeneity'' and ''Autonomy'' requirements pose special challenges concerning [[concurrency control]] in an FDBS, which is crucial for the correct execution of its concurrent [[Database transaction|transactions]] (see also [[Global concurrency control]]). Achieving [[global serializability]], the major correctness criterion, under these requirements has been characterized as very difficult and unsolved.<ref name="refone" /> [[Commitment ordering]], introduced in 1991, has provided a general solution for this issue (See [[Global serializability]]; See [[Commitment ordering]] also for the architectural aspects of the solution).


==Applications in physical science==
== Five Level Schema Architecture for FDBSs ==
Physical unit relations like:
The five level schema architecture includes the following:
* ''V'' = ''I R''  : [[Ohm's law]]
* ''P'' = ''V I''  : [[Electrical power]]
* ''P V'' = ''k T''  : [[Ideal gas law]]
* ''f'' λ = ''c'' : [[Sine wave]]s
all suggest looking carefully at the quadrant. For example, in [[thermodynamics]] the [[isothermal process]] explicitly follows the hyperbolic path and [[work (thermodynamics)|work]] can be interpreted as a hyperbolic angle change. Similarly, an [[isobaric process#Variable density viewpoint|isobaric process]] may trace a hyperbola in the quadrant of absolute temperature and gas density.


For hyperbolic coordinates in the [[Theory of relativity]] see the History section below.
* Local Schema is the conceptual concept ''[unclear]'' expressed in primary data model of component DBMS.
* Component Schema is derived by translating local schema into a model called the canonical data model or common data model.  They are useful when semantics missed in local schema are incorporated in the component.  They help in integration of data for tightly coupled FDBS.
* Export Schema represents a subset of a component schema that is available to the FDBS.  It may include access control information regarding its use by specific federation user.  The export schema help in managing flow of control of data.
* Federated Schema is an integration of multiple export schema. It includes information on data distribution that is generated when integrating export schemas.
* External Schema defines a schema for a user/applications or a class of users/applications.


==Statistical applications==
While accurately representing the state of the art in data integration, the Five Level Schema Architecture above does suffer from a major drawback, namely IT imposed look and feel. Modern data users demand control over how data is presented; their needs are somewhat in conflict with such bottom-up approaches to data integration.
*Comparative study of [[population density]] in the quadrant begins with selecting a reference nation, region, or [[urban density|urban]] area whose population and area are taken as  the point (1,1).
*Analysis of the [[legislator|elected representation]] of regions in a [[representative democracy]] begins with selection of a standard for comparison: a particular represented group, whose magnitude and slate magnitude (of representatives) stands at (1,1) in the quadrant.


==Economic applications==
== See also ==
There are many natural applications of hyperbolic coordinates in [[economics]]:
* [[Enterprise Information Integration]] (EII)
* Analysis of currency [[exchange rate]] fluctuation:
* [[Data Virtualization]]
The unit currency sets <math>x = 1</math>. The price currency corresponds to <math>y</math>. For
* [[Master data management]] (MDM)
* [[Schema Matching]]
* [[Universal relation assumption]]
* [[Linked Data]]
* [[SPARQL]]


:<math>0 < y < 1</math>
== References ==
 
we find <math>u > 0</math>, a positive hyperbolic angle. For a ''fluctuation'' take a new price
 
:<math>0 < z < y</math>.
 
Then the change in ''u'' is:
 
:<math>\Delta u = \frac{1}{2} \log \left( \frac{y}{z} \right)</math>.
 
Quantifying exchange rate fluctuation through hyperbolic angle provides an objective, symmetric, and consistent [[measure (mathematics)|measure]]. The quantity <math>\Delta u</math> is the length of the left-right shift in the hyperbolic motion view of the currency fluctuation.
* Analysis of inflation or deflation of prices of a [[basket of consumer goods]].
* Quantification of change in marketshare in [[duopoly]].
* Corporate [[stock split]]s versus stock buy-back.
 
==History==
While the geometric mean is an ancient concept, the hyperbolic angle is contemporary with the development of [[logarithm]], the latter part of the seventeenth century. [[Gregoire de Saint-Vincent]], [[Marin Mersenne]], and [[Alphonse Antonio de Sarasa]] evaluated the quadrature of the hyperbola as a function having properties now familiar for the logarithm. The exponential function, the hyperbolic sine, and the hyperbolic cosine followed. As [[complex function]] theory referred to [[infinite series]] the circular functions sine and cosine seemed to absorb the hyperbolic sine and cosine as depending on an imaginary variable. In the nineteenth century [[biquaternion]]s came into use and exposed the alternative complex plane called [[split-complex number]]s where the hyperbolic angle is raised to a level equal to the classical angle. In English literature biquaternions were used to model [[spacetime]] and show its symmetries. There the hyperbolic angle parameter came to be called [[rapidity]]. For relativists, examining the quadrant as the possible future between oppositely directed photons, the geometric mean parameter is [[time|temporal]].
 
In relativity the focus is on the 3-dimensional [[hypersurface]] in the future of spacetime where various velocities arrive after a given [[proper time]]. Scott Walter<ref>Walter (1999) page 6</ref> explains that in November 1907 [[Herman Minkowski]] alluded to a well-known three-dimensional hyperbolic geometry while speaking to the Göttingen Mathematical Society, but not to a four-dimensional one.<ref>Walter (1999) page 8</ref>
In tribute to [[Wolfgang Rindler]], the author of the standard introductory university-level textbook on relativity, hyperbolic coordinates of spacetime are called [[Rindler coordinates]].
 
==References==
<references/>
<references/>
*David Betounes (2001) ''Differential Equations: Theory and Applications'', page 254, Springer-TELOS, ISBN 0-387-95140-7 .
*Scott Walter (1999). [http://www.univ-nancy2.fr/DepPhilo/walter/papers/nes.pdf "The non-Euclidean style of Minkowskian relativity"]. Chapter 4 in: Jeremy J. Gray (ed.), ''The Symbolic Universe: Geometry and Physics 1890-1930'', pp.&nbsp;91–127. [[Oxford University Press]]. ISBN 0-19-850088-2.


{{Orthogonal coordinate systems}}
== External links ==
* [http://citeseer.ist.psu.edu/cache/papers/cs/9149/http:zSzzSzwww.bm.ust.hkzSz~zhaozSzDSS96.pdf/schema-coordination-in-federated.pdf Schema coordination in federated database management: a comparison with schema integration]
* [http://www.computing.dcu.ie/~dalenk/publications/PhD%20Transfer%20talk.ppt Storage of Behaviour of Object Database]
* [http://www.ibm.com/developerworks/db2/library/techarticle/dm-0504zikopoulos/ DB2 and Federated Databases]
* [http://www.vldb.org/conf/1991/P489.PDF Tutorial on Federated Database]
* [http://www.dcs.bbk.ac.uk/~lucas/talks/SCSIS_RD_200507.pps GaV and LaV explained]
* [http://www.ibm.com/developerworks/db2/library/techarticle/0304lurie/0304lurie.html Issues of where to perform the join aka "pushdown" and other performance characteristics]
* [http://www.ibm.com/developerworks/db2/library/techarticle/0307lurie/0307lurie.html Worked example federating Oracle, Informix, DB2, and Excel]
* [http://www.compositesw.com/products/cis.shtml Composite Information Server - a commercial federated database product]
* Freitas, André, Edward Curry, João Gabriel Oliveira, and Sean O’Riain. 2012. [http://www.edwardcurry.org/publications/freitas_IC_12.pdf “Querying Heterogeneous Datasets on the Linked Data Web: Challenges, Approaches, and Trends.”] IEEE Internet Computing 16 (1): 24–33.
* [https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=f6ce657b-f385-43b2-8350-458e6e4a344f  IBM Gaian Database: A dynamic Distributed Federated Database]
* [http://www.google.com/patents/US7392255 Federated system and methods and mechanisms of implementing and using such a system ]


[[Category:Coordinate systems]]
{{Databases}}
[[Category:Hyperbolic geometry]]


[[ar:نظام إحداثيات قطعي زائدي]]
{{DEFAULTSORT:Federated Database System}}
[[pt:Coordenadas hiperbólicas]]
[[Category:Database management systems]]
[[zh:雙曲坐標系]]

Revision as of 12:16, 13 August 2014

A federated database system is a type of meta-database management system (DBMS), which transparently maps multiple autonomous database systems into a single federated database. The constituent databases are interconnected via a computer network and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or virtual database, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation.

Through data abstraction, federated database systems can provide a uniform user interface, enabling users and clients to store and retrieve data from multiple noncontiguous databases with a single query -- even if the constituent databases are heterogeneous. To this end, a federated database system must be able to decompose the query into subqueries for submission to the relevant constituent DBMS's, after which the system must composite the result sets of the subqueries. Because various database management systems employ different query languages, federated database systems can apply wrappers to the subqueries to translate them into the appropriate query languages.

Definition

McLeod and Heimbigner[1] were among the first to define a federated database system in the mid 1980's.

A FDBS is one which "define[s] the architecture and interconnect[s] databases that minimize central authority yet support partial sharing and coordination among database systems".[1] This description might not accurately reflect the McLeod/Heimbigner[1] definition of a federated database. Rather, this description fits what McLeod/Heimbinger called a composite database. McLeod/Heimbigner's federated database is a collection of autonomous components that make their data available to other members of the federation through the publication of an export schema and access operations; there is no unified, central schema that encompasses the information available from the members of the federation.

Among other surveys,[2] practitioners define a Federated Database as a collection of cooperating component systems which are autonomous and are possibly heterogeneous.

The three important components of an FDBS are autonomy, heterogeneity and distribution.[2] Another dimension which has also been considered is the Networking Environment Computer Network, e.g., many DBSs over a LAN or many DBSs over a WAN update related functions of participating DBSs (e.g., no updates, nonatomic transitions, atomic updates).

FDBS architecture

A DBMS can be classified as either centralized or distributed. A centralized system manages a single database while distributed manages multiple databases. A component DBS in a DBMS may be centralized or distributed. A multiple DBS (MDBS) can be classified into two types depending on the autonomy of the component DBS as federated and non federated. A nonfederated database system is an integration of component DBMS that are not autonomous. A federated database system consists of component DBS that are autonomous yet participate in a federation to allow partial and controlled sharing of their data.

Federated architectures differ based on levels of integration with the component database systems and the extent of services offered by the federation. A FDBS can be categorized as loosely or tightly coupled systems.

  • Loosely Coupled require component databases to construct their own federated schema. A user will typically access other component database systems by using a multidatabase language but this removes any levels of location transparency, forcing the user to have direct knowledge of the federated schema. A user imports the data they require from other component databases and integrates it with their own to form a federated schema.
  • Tightly coupled system consists of component systems that use independent processes to construct and publicize an integrated federated schema.

Multiple DBS of which FDBS are a specific type can be characterized along three dimensions: Distribution, Heterogeneity and Autonomy. Another characterization could be based on the dimension of networking, for example single databases or multiple databases in a LAN or WAN.

Distribution

Distribution of data in an FDBS is due to the existence of a multiple DBS before an FDBS is built. Data can be distributed among multiple DB which could be stored in a single computer or multiple computers. These computers could be geographically located in different places but interconnected by a network. The benefits of data distribution help in increased availability and reliability as well as improved access times.

Heterogeneity

Mining Engineer (Excluding Oil ) Truman from Alma, loves to spend time knotting, largest property developers in singapore developers in singapore and stamp collecting. Recently had a family visit to Urnes Stave Church. Heterogeneities in databases arise due to factors such as differences in structures, semantics of data, the constraints supported or query language. Differences in structure occur when two data models provide different primitives such as object oriented (OO) models that support specialization and inheritance and relational models that do not. Differences due to constraints occur when two models support two different constraints. For example the set type in CODASYL schema may be partially modeled as a referential integrity constraint in a relationship schema. CODASYL supports insertion and retention that are not captured by referential integrity alone. The query language supported by one DBMS can also contribute to heterogeneity between other component DBMSs. For example, differences in query languages with the same data models or different versions of query languages could contribute to heterogeneity.

Semantic heterogeneities arise when there is a disagreement about meaning, interpretation or intended use of data. At the schema and data level, classification of possible heterogeneities include:

  • Naming conflicts e.g. databases using different names to represent the same concept.
  • Domain conflicts or data representation conflicts e.g. databases using different values to represent same concept.
  • Precision conflicts e.g. databases using same data values from domains of different cardinalities for same data.
  • Metadata conflicts e.g. same concepts are represented at schema level and instance level.
  • Data conflicts e.g. missing attributes
  • Schema conflicts e.g. table versus table conflict which includes naming conflicts, data conflicts etc.

In creating a federated schema, one has to resolve such heterogeneities before integrating the component DB schemas.

Schema matching, schema mapping

Dealing with incompatible data types or query syntax is not the only obstacle to a concrete implementation of an FDBS. In systems that are not planned top-down, a generic problem lies in matching semantically equivalent, but differently named parts from different schemas (=data models) (tables, attributes). A pairwise mapping between n attributes would result in mapping rules (given equivalence mappings) - a number that quickly gets too large for practical purposes. A common way out is to provide a global schema that comprises the relevant parts of all member schemas and provide mappings in the form of database views. Two principal solutions can be realized, depending on the direction of the mapping:

  1. Global as View (GaV): the global schema is defined in terms of the underlying schemas
  2. Local as View (LaV): the local schemas are defined in terms of the global schema

Both are explained in more detail in the article Data integration. Alternate approaches to the schema matching problem and a classification of the same are explained in more detail in the article Schema Matching

Autonomy

Fundamental to the difference between an MDBS and an FDBS is the concept of autonomy. It is important to understand the aspects of autonomy for component databases and how they can be addressed when a component DBS participates in an FDBS. There are four kinds of autonomies addressed:

  • Design Autonomy which refers to ability to choose its design irrespective of data, query language or conceptualization, functionality of the system implementation.

Heterogeneities in an FDBS are primarily due to design autonomy.

  • Communication autonomy refers to the general operation of the DBMS to communicate with other DBMS or not.
  • Execution autonomy allows a component DBMS to control the operations requested by local and external operations.
  • Association autonomy gives a power to component DBS to disassociate itself from a federation which means FDBS can operate independently of any single DBS.

The ANSI/X3/SPARC Study Group outlined a three level data description architecture, the components of which are the conceptual schema, internal schema and external schema of databases. The three level architecture is however inadequate to describing the architectures of an FDBS. It was therefore extended to support the three dimensions of the FDBS namely Distribution, Autonomy and Heterogeneity. The five level schema architecture is explained below.

Concurrency control

The Heterogeneity and Autonomy requirements pose special challenges concerning concurrency control in an FDBS, which is crucial for the correct execution of its concurrent transactions (see also Global concurrency control). Achieving global serializability, the major correctness criterion, under these requirements has been characterized as very difficult and unsolved.[2] Commitment ordering, introduced in 1991, has provided a general solution for this issue (See Global serializability; See Commitment ordering also for the architectural aspects of the solution).

Five Level Schema Architecture for FDBSs

The five level schema architecture includes the following:

  • Local Schema is the conceptual concept [unclear] expressed in primary data model of component DBMS.
  • Component Schema is derived by translating local schema into a model called the canonical data model or common data model. They are useful when semantics missed in local schema are incorporated in the component. They help in integration of data for tightly coupled FDBS.
  • Export Schema represents a subset of a component schema that is available to the FDBS. It may include access control information regarding its use by specific federation user. The export schema help in managing flow of control of data.
  • Federated Schema is an integration of multiple export schema. It includes information on data distribution that is generated when integrating export schemas.
  • External Schema defines a schema for a user/applications or a class of users/applications.

While accurately representing the state of the art in data integration, the Five Level Schema Architecture above does suffer from a major drawback, namely IT imposed look and feel. Modern data users demand control over how data is presented; their needs are somewhat in conflict with such bottom-up approaches to data integration.

See also

References

  1. ↑ 1.0 1.1 1.2 "55 years old Systems Administrator Antony from Clarence Creek, really loves learning, PC Software and aerobics. Likes to travel and was inspired after making a journey to Historic Ensemble of the Potala Palace.

    You can view that web-site... ccleaner free download
  2. ↑ 2.0 2.1 2.2 "55 years old Systems Administrator Antony from Clarence Creek, really loves learning, PC Software and aerobics. Likes to travel and was inspired after making a journey to Historic Ensemble of the Potala Palace.

    You can view that web-site... ccleaner free download

External links

Template:Databases

Retrieved from "https://en.formulasearchengine.com/index.php?title=Main_Page&oldid=50152"