Schema Integration, View Integration and Database Integration, ER Model & Diagrams and Object-Oriented Model
- 1. Schema Integration, View Integration and Database Integration, ER Model & Diagrams and Object-Oriented Model Mobarok Hossen 17-90216-2, Abdulla Al Mamun 17-90217-2 Rajib Chowdhury 17-90189-2, D.M. Anisuzzaman 17-90119-2 February 27, 2018 1 ER Model & Diagram An entity relationship model, also called an entity- relationship (ER) diagram, is a graphical repre- sentation of entities (which will become your ta- bles) and their relationships to each other. ER Diagrams are most often used to design or de- bug relational databases in the fields of software engineering, business information systems, educa- tion and research. Also known as ERDs or ER Models, they use a defined set of symbols such as rectangles, diamonds, ovals and connecting lines to depict the interconnectedness of entities, rela- tionships and their attributes. ER diagrams are related to data structure di- agrams (DSDs), which focus on the relationships of elements within entities instead of relationships between entities themselves. ER diagrams also are often used in conjunction with data flow diagrams (DFDs), which map out the flow of information for processes or systems. Entity: Entity, which are represented by rect- angles. An entity is an object or concept about which you want to store information. Weak Entity: A weak entity is an entity that de- pends on the existence of another entity. Fig. 1: Entity Fig. 2: Weak Entity Attributes: Attributes, which are represented by ovals. A key attribute is the unique, distin- guishing characteristic of the entity. An entity can have as many attributes as necessary. There are some attribute type such as: Primary Key: It’s sketched the same as a normal attribute but with underline. Fig. 3: Attribute Fig. 4: Primary key Attr. Composite Attribute: It’s a value that com- posed of some other values. For example, you may have Address that’s composed of street, city and number Fig. 5: Composite Attribute Multivalued Attribute: If an attribute can have more than one value it is called a multi valued attribute. For example, a teacher entity can have multiple subject values. Derived Attribute: When you have a column where it’s value could be calculated from another column. This is found rarely in ER diagrams Fig. 6: Multivalued Attribute Fig. 7: Derived At- tribute Actions: Actions which are represented by di- amond shapes, show how two entities share infor- mation in the database using their relationship. Fig. 8: Relationship/Action There are so many Entity Relationship Diagram Style: 1. Information Engineering Style 2. Chen Style 3. Bachman Style 4. Martin Style 1
- 2. Fig. 9: Information Engineering Style Fig. 10: Chen Style Fig. 11: Bachman Style Fig. 12: Martin Style Fig. 13: ER Model & Diagram 2
- 3. How to Draw ER Diagrams? Below points show how to go about creating an ER diagram: Identify all the entities. Cre- ate rectangles for all entities and name them properly. Identify relationships between entities Connect them using a line and add a diamond in the middle describing the relationship. Add attributes for entities. Give meaningful at- tribute names so they can be understood easily. Benefits of ER diagrams: ER diagrams con- stitute a very useful framework for creating and manipulating databases. ER diagrams are easy to understand. ER diagrams to easily communicate with developers, customers, and end users, regard- less of their IT proficiency ER diagrams are read- ily translatable into relational tables which can be used to quickly build databases ER diagrams may be applied in other contexts such as describing the different relationships and operations within an or- ganization. 2 Object Oriented Database Model OODMS: Database that stores data elements as objects. Uses object-oriented concepts. Object - like an entity in an E-R Diagram. Fig. 14: Object based ER Model Why use OODMS: Complex data or rela- tionship requirements. Lack of unique, natural identification. Large numbers of many to many relationships. Frequent use of type codes such as those found in the relational schema. Typical Applications for OODMS: Computer-aided design (CAD). Computer- aided software engineering (CASE). Multimedia databases: Images, video, games, etc. Office automation systems (OIS). Expert database systems. Object Oriented Concept: Vari- ables/Attributes – Object Data. Relationships – References to other objects. Methods – Object Functions. Messages – Accessing Methods Fig. 15: Object based ER Model Advantages of OODMS: Designer can specify the structure of objects and their behavior (methods). Better interaction with object- oriented languages such as Java and C++. Defi- nition of complex and user-defined types. Encap- sulation of operations and user-defined methods. Disadvantages of OODMS: Still develop- ing: Lack of accepted standards, Lack of de- velopment tools,Change is more likely to occur in model. More complicated than the relational model. Takes longer to learn. Not as efficient when data and relations are simple. 3 Schema Integration Database Schema: Overall description of the database which is represented by diagrammat- ically, visually, graphically is called database schema. It is also defined by a relation of the database. Instance: Collection of information stored in the database at a particular moment of time is called database instance which keeps on changing by insertion, deletion or updating. Every differ- ent instance, there can be a different state of the database. Sub-Schema: It is the lower level or the sub level of the schema which actually corresponds to an application where programmers or users view of the data item types and record types, which they use. Schema Integration: Schema integration is the activity of integrating the schemas of exist- ing or proposed databases into a global, unified schema. It actually merges the schemas into a sin- gle global schema where fundamental problems are to take two or more database schemas and also to produce a mapping between attributes of the two or more schemas Fig. 16: Integrated schema and mappings Fig. 17: Integrated schema with ER Model3
- 4. Framework for Schema Integration: 1) Local Schemas: Existing and proposed schemas of the database are taken as local schemas for producing a global unified schema. 2) Schema Transformation: In this part, n source local schemas act as input and which are transformed into n source homogenized schemas by using the method of model and Design Homog- enization. a. Data Model Homogenization: Here all data sources are described using the same model. b. Design Homogenization: Enforce standard design rules to reduce the number of structural conflicts. 3) Schema Matching: Relies on information such as name, description, data type, relationship type, constraints etc. Match Cardinality: a. 1:1 match: one element in one schema matches one element of another schema. b. 1: m match: one element in one schema matches m elements of another schema. c. m :n match: m elements in one schema matches n elements of another schema. Fig. 18: Framework for Schema Integration 4) Schema Integration: Merge the schemas into a single global schema using different integration strategy which’s are: i. One shot strategy: It is an efficient integra- tion process where many correspondences between concepts have to be considered together. ii. Pair at a time strategy: It is more efficient integration process which gives priority to most relevant and stable schemas. iii. Balanced strategy: It will be preferred when the cohesion among schemas is high (e.g.: Produc- tion, marketing, sales). Fig. 19: (a) One shot strategy, (b) Pair at a time strategy, (c) Balanced strategy 4 View Integration We have to wait a little bit to go to the topic of view integration. Let’s see where the concept of view integration fit in the database system de- velopment process (DSDP). DSDP can be divided into four steps: requirements analysis; conceptual design; logical design and physical design. The step ‘conceptual design’ is divided into two steps: view modeling and modification and view integra- tion. And here comes the concept of view integra- tion. In view integration step individual database in- tegrated into a global database schema. There are two view integration approaches: syntac- tic approach and semantic approach. Syntactic approach employs functional relationships (func- tional dependencies) among attributes in different database views to perform view integration. Se- mantic approach uses the meaning of the elements in database views to perform view integration. Se- mantic approach uses the meaning of the elements in database views to perform view integration. View integration is not as easy as it sounds. It arises some conflict when we try to integrate differ- ent view. There are mainly two types of conflicts: naming conflict and structural conflict. Table 1 shows the brief description of these conflicts. Nam- ing conflict contains: Homonyms and Synonyms and the rest four are structural conflict. Table 1: Conflicts in View Integration Conflict Name Meaning Example Homonyms Same name for elements representing different real world objects in different database views. 4
- 5. Conflict Name Meaning Example Synonyms Elements representing the same real world object; described by dif- ferent names in different database views. Type Conflicts The same real world object is represented by different modeling constructs in different database views. Key Conflicts Different keys are assigned to entities or relationships representing the same real world object in different database views.. Cardinalities Conflicts The min-card or max- card within an entity- relationship association are incompatible in different database views. Semantic Con- flicts Different semantic inter- pretations are abstracted into different database views. When a conflict is found between two database views, a solution has to be found. All case solutions are combinations of a set of 11 elementary solution operations: 1. A relationship becomes an entity 2. A relationship attribute becomes an entity 3. An entity attribute becomes an E-R construct 4. Association of an entity to a relationship 5. Relocation of a relationship after creation of new superset or subset classes. 6. Representation of containment. 7. Representation of a common role (W- relation- ship). 8. Representation of a common superset without overlap 9. Representation of a common superset with over- lap 10. Renaming of homonyms and synonyms. 11. Addition of missing objects. 5 Database Integration Database Integration involves combining data from several disparate sources, which are stored using various technologies and provide a unified view of the data. In simple terms, sharing infor- mation between two different computer systems is database integration. Fig. 20: 5
- 6. Three types of database integration: 1) Physical: Coping the data to warehouse. 2) Virtual: Keep the data only at the sources. 3) Within a single organization: Integrating data from different departments or sectors. The core problem associated with database integration is heterogeneity among the data sources. There exist 6 types of heterogeneity. Table 2 gives a brief description of these 6 types. Table 2: Heterogeneities in Database Integration Heterogeneity Name Meaning Example Source Type The source’s system of storing data can be different. Communication 1) Some systems have web inter- face others do not. 2) Some sys- tems allow direct query language others offer APIs. Schema The source’s structure of the ta- bles storing the data can be dif- ferent (even if storing the same data). Data Type Storing the same data (and val- ues) but with different data types. Value Same logical values stored in dif- ferent ways. Semantic Same values in different sources can mean different things. 6
- 7. Three models (Federated Databases; Data Warehousing and Mediation) of database integration are described briefly below: Table 3: Heterogeneities in Database Integration Name Meaning Example Federated Databases It contains the simplest architecture. Every pair of sources can build their own mapping and transformation. Advantage: If many sources and only very few are communicating. Disadvantages: 1) If most sources are com- municating (n2 mappings) and 2) If sources are dynamic (need to change many mappings). Data Warehous- ing It is a very common approach. Data from mul- tiple sources are copied and stored in a ware- house. Data is materialized in the warehouse. Users can then query the warehouse database only. Mediation Mediator is a virtual view over the data (it does not store any data). Data is stored only at the sources. Mediator has a virtual schema that combines all schemas from the sources. The mapping takes place at query time. This is unlike warehousing where mapping takes place at upload time. 7