Basically for large databases with many expected users and applications the view integration approach of designing individual schema and then merging them can be used. Because the individual views can be kept relatively small to simplified the design of the schema. However, the methodology for integrating the views into a global database schemas is needed. Schema Integration basically divided into the following subtask.
1. Identifying correspondences and conflicts among the schema:
As the schemas are designed individually it is necessary to specify constructs in the schemas that represent the same real-world concept. We must identify these correspondences before proceeding the integration. During this process, several types of conflicts may occur such as:
- Naming conflict –
Naming conflicts are basically of two types synonyms and homonyms. A synonym occurs when two schemas basically use different names to describe the same concept, for example, an entity type CUSTOMER in one a schema may describe the same concept as an entity type CLIENT in another schema. A homonym occurs when two schemas use the same name to describe different concepts. for example, an entity type Classes may represent train classes in one schema and aeroplane classes in another schema.
- Type conflicts –
The same concept may be represented in two schemas by different modelling constructs. For example, the concept of the department may be an entity type in one schema and an attribute in another.
- Domain conflicts –
A single attribute may have different domains in different schemas. For example, we may declare Ssn as an integer in one schema and in another schema, we may declare them as a character string. A conflict of the unit of measure could occur if one schema represented weight in pounds and other used kgs.
- Conflicts among constraints –
Two schemas may impose different constraints, for example, the key of an entity type may be different in each schema.
2. Modifying views to conform to one another:
Some schemas are modified so that they conform in other schemas more closely. Some of the conflicts that may occur during the first steps are resolved in this step.
3. Merging of Views and Restructuring:
The global schemas are created by merging the individual schemas. Corresponding concepts are represented only once in the global schema and mapping between the views and the global schemas are specified. This is basically the hardest step to achieve in the real world databases which involve hundreds of entities and relations. It involves a considerable amount of human intervention and negotiation to resolve conflicts and to settle on the most reasonable and acceptable solution for a global schema. Restructuring As a final optional step the global schemas may be analyzed and restructured to remove any redundancies or unnecessary complexity.
- Relation Schema in DBMS
- Difference between Schema and Instance in DBMS
- Strategies for Schema design in DBMS
- Difference between Star Schema and Fact Constellation Schema
- Difference between Snowflake Schema and Fact Constellation Schema
- Difference between Star Schema and Snowflake Schema
- What is EII(Enterprise Information Integration)?
- Difference between Schema and Database
- Snowflake Schema in Data Warehouse Model
- Types of Keys in Data Warehouse Schema
- Star Schema in Data Warehouse modeling
- Create, Alter and Drop schema in MS SQL Server
- Need for DBMS
- Deadlock in DBMS
- Disadvantages of DBMS
- Difference between 1NF and 2NF in DBMS
- Recoverability in DBMS
- Cascadeless in DBMS
- Interfaces in DBMS
- History of DBMS