Data Models in DBMS A model is a representation of reality, 'real world' objects and events, associations. Data Model can be defined as an integrated collection of concepts for describing and manipulating data, relationships between data, and constraints on the data in an organization. The purpose of a data model is to represent data and to make the data understandable. There have been many data models proposed in the literature. They fall into three broad categories: Object Based Data Models Physical Data Models Record Based Data Models The object based and record based data models are used to describe data at the conceptual and external levels, the physical data model is used to· describe data at the internal level.

Object Based Data Models Object based data models use concepts such as entities, attributes, and relationships. An entity is a distinct object (a person, place, concept, and event) in the organization that is to be represented in the database. An attribute is a property that describes some aspect of the object that we wish to record, and a relationship is an association between entities.Some of the more common types of object based data model are: • Entity-Relationship • Object Oriented • Semantic • Functional

Physical Data Models  Physical data models describe how data is stored in the computer, representing information such as record structures, record ordering, and access paths. There are not as many physical data models as logical data models, the most common one being the Unifying Model.

Record Based Logical Models Record based logical models are used in describing data at the logical and view levels. In contrast to object based data models, they are used to specify the overall logical structure of the database and to provide a higher-level description of the implementation. Record based models are so named because the database is structured in fixed format records of several types. Each record type defines a fixed number of fields, or attributes, and each field is usually of a fixed length.The three most widely accepted record based data models are:   • Hierarchical Model • Network Model • Relational Model

Network Model In the relational model, the data and the relationships among data are represented by a collection of tables. The network model differs from the relational model in that data are represented by collections of records, and relationships among data are represented by links. The sample database in Figure A.1 shows that Hayes has account A-102, Johnson has accounts A-101 and A-201, and Turner has account A-305.

Entity Relationship Diagram Entity-Relationship (ER) Model is based on the notion of real-world entities and relationships among them. While formulating real-world scenario into the database model, the ER Model creates entity set, relationship set, general attributes and constraints. ER Model is best used for the conceptual design of a database. ER Model is based on − Entities and their attributes. Relationships among entities. These concepts are explained below.

Entity − An entity in an ER Model is a real-world entity having properties called attributes. Every attribute is defined by its set of values called domain. For example, in a school database, a student is considered as an entity. Student has various attributes like name, age, class, etc. Relationship − The logical association among entities is called relationship. Relationships are mapped with entities in various ways. Mapping cardinalities define the number of association between two entities. Mapping cardinalities − one to one one to many many to one many to many

Relational Model The most popular data model in DBMS is the Relational Model. It is more scientific a model than others. This model is based on first-order predicate logic and defines a table as an n-ary relation.

The main highlights of this model are − Data is stored in tables called relations. Relations can be normalized. In normalized relations, values saved are atomic(All or nothing) values. Each row in a relation contains a unique value. Each column in a relation contains values from a same domain.

E-R model in DBMS An entity–relationship model (ER model) is a systematic way of describing and defining a business process. An ER model is typically implemented as a database. The main components of E-R model are: entity set and relationship set. Here are the geometric shapes and their meaning in an E-R Diagram – Rectangle: Represents Entity sets. Ellipses: Attributes Diamonds: Relationship Set Lines: They link attributes to Entity Sets and Entity sets to Relationship Set Double Ellipses: Multivalued Attributes Dashed Ellipses: Derived Attributes Double Rectangles: Weak Entity Sets Double Lines: Total participation of an entity in a relationship set A sample E-R Diagram:

ER Diagram with Composite, Multivalued and derived attributes

Multivalued Attributes: An attribute that can hold multiple values is known as multivalued attribute. We represent it with double ellipses in an E-R Diagram. E.g. A person can have more than one phone numbers so the phone number attribute is multivalued. Derived Attribute: A derived attribute is one whose value is dynamic and derived from another attribute. It is represented by dashed ellipses in an E-R Diagram. E.g. Person age is a derived attribute as it changes over time and can be derived from another attribute (Date of birth). Total Participation of an Entity set: A Total participation of an entity set represents that each entity in entity set must have at least one relationship in a relationship set. For example: In the below diagram each college must have at-least one associated Student.

E-R diagram corresponding to customers and loans.

Relationships. (a) one to many. (b) many to one. (c) one-to-one.

Relational model in DBMS Course table: Course table Relational model in DBMS In relational model, the data and relationships are represented by collection of inter-related tables. Each table is a group of column and rows, where column represents attribute of an entity and rows represents records. Sample relationship Model: Student table with 3 columns and four records. Stu_Id Stu_Name Stu_Age 111 Ashish 23 123 Saurav 22 169 Lester 24 234 Lou 26

Course table: Course table Stu_Id Course_Id Course_Name 111 C01 Science C02 DBMS 169 C22 Java C39 Computer Networks Here Stu_Id, Stu_Name & Stu_Age are attributes of table Student and Stu_Id, Course_Id & Course_Name are attributes of table Course. The rows with values are the records (commonly known as tuples).

Hierarchical model in DBMS In hierarchical model, data is organized into a tree like structure with each record is having one parent record and many children. The main drawback of this model is that, it can have only one to many relationships between nodes.

Example of hierarchical data represented as relational tables: The above hierarchical model can be represented as relational tables like this: Student Table Stu_Id Stu_Name Stu_Age 123 Steve 29 367 Chaitanya 27 234 Ajeet 28 Course Table: Course_Id Course_Name Stu_Id C01 Cobol 123 C21 Java 367 C22 Perl C33 JQuery 234

ACID Properties in DBMS A transaction is a single logical unit of work which accesses and possibly modifies the contents of a database. Transactions access data using read and write operations. In order to maintain consistency in a database, before and after transaction, certain properties are followed. These are called ACID properties.

Atomicity mean that either the entire transaction takes place at once or doesn’t happen at all. There is no midway i.e. transactions do not occur partially. Each transaction is considered as one unit and either runs to completion or is not executed at all. It involves following two operations. —Abort: If a transaction aborts, changes made to database are not visible. —Commit: If a transaction commits, changes made are visible. Atomicity is also known as the ‘All or nothing rule’. Consider the following transaction T consisting of T1 and T2: Transfer of 100 from account X to account Y.

If the transaction fails after completion of T1 but before completion of T2.( say, after write(X) but before write(Y)), then amount has been deducted from X but not added to Y. This results in an inconsistent database state. Therefore, the transaction must be executed in entirety in order to ensure correctness of database state.

Consistency This means that integrity constraints must be maintained so that the database is consistent before and after the transaction. It refers to correctness of a database. Referring to the example above, The total amount before and after the transaction must be maintained. Total before T occurs = 500 + 200 = 700. Total after T occurs = 400 + 300 = 700. Therefore, database is consistent. Inconsistency occurs in case T1 completes but T2 fails. As a result T is incomplete.

Isolation This property ensures that multiple transactions can occur concurrently without leading to inconsistency of database state. Transactions occur independently without interference. Changes occurring in a particular transaction will not be visible to any other transaction until that particular change in that transaction is written to memory or has been committed. This property ensures that the execution of transactions concurrently will result in a state that is equivalent to a state achieved these were executed serially in some order.

Let X= 500, Y = 500. Consider two transactions T and T”. Suppose T has been executed till Read (Y) and then T’’ starts. As a result , interleaving of operations takes place due to which T’’ reads correct value of X but incorrect value of Y and sum computed by T’’: (X+Y = 50, 000+500=50, 500) is thus not consistent with the sum at end of transaction:  T: (X+Y = 50, 000 + 450 = 50, 450). This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take place in isolation and changes should be visible only after a they have been made to the main memory.  

Durability: This property ensures that once the transaction has completed execution, the updates and modifications to the database are stored in and written to disk and they persist even is system failure occurs. These updates now become permanent and are stored in a non-volatile memory. The effects of the transaction, thus, are never lost. The ACID properties, in totality, provide a mechanism to ensure correctness and consistency of a database in a way such that each transaction is a group of operations that acts a single unit, produces consistent results, acts in isolation from other operations and updates that it makes are durably stored.