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 databases 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 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 n (n-1) \over 2 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 approaches depend 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 examples of
data integration, called the
schema matching problem.
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. == Five level schema architecture for FDBSs ==