Presentation is loading. Please wait.

Presentation is loading. Please wait.

DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data.

Similar presentations


Presentation on theme: "DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data."— Presentation transcript:

1

2 DATABASEMODELSDATABASEMODELS

3  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data.  4 models ◦ Entity relationship model ◦ Hierarchical model ◦ Network model ◦ Relational model

4  IEEE defines ER diagram as ‘ a diagram that depicts a set of real-world entities and the logical relationships among them’  It contains: ◦ Data Objects (Entities) ◦ Attributes ◦ Relationships

5  Definition: ◦ An entity is an object or event, real or abstract, about which we would like to store data. Entity is the abbreviation of entity type. It represent a set of entity instances which can be described by the same set of attribute types. The value of the same attribute for each entity instance may be different.

6 An entity has the following  Name  Description  Identifier  Properties: Estimated number (Max., Min., Average) of entity instances  entity instances  Attributes that describe the Entity Types  Examples of entity type instances

7 Entity TypesEntity Instance VendorABC Co. EmployeeTarun CourseMBA Department Marketing Department

8  Tangible or Intangible Things ◦ The nouns that are used to describe the problem domain will often correspond to the major Entity Types of the system. ◦ Examples: Product, Sensor, and Employee, Department, and Sale Office.  Resources ◦ Any resources that an organization needs to manage should be represented as an Entity Type. ◦ Examples: Inventory, Machine, Bank Account, and Customer.  Roles Played ◦ Roles can be played by persons or organizational units. ◦ Examples: Customers, Managers, and Account representatives.  Events ◦ Events are incidents that occur. An event often involve an interaction between two Entity Types or an action that changes the status of an Entity Type. ◦ Examples: Sale, Delivery, and Registration of a motor vehicle.

9  External entity – (anything that produces or consumes information)  Thing (e.g. report or display)  Occurrence or events (e.g. registeration)  Role (e.g. salesperson)  Organizational unit (e.g. accounting department)  Place (e.g. warehouse)  Structure (e.g. File) Data Object can be

10 Data Attributes describe the properties of a data object. Attributes that identify entities are known as key attributes, that describes an entity are known as non-key attributes. Data attributes are used to perform the following function  Naming the instance of the data object  Description of instance Attributes

11  an entity has a set of attributes  attribute defines property of an entity  it is given a name  attribute has value for each entity  value may change over time

12

13  The connection of data objects or entities with each other is known as relationship. car personcar person Basic connection between data objects owns Relationship between data objects

14 14  Degree of a relationship is the number of entity types that participate in it ◦ Unary Relationship ◦ Binary Relationship ◦ Ternary Relationship

15 15 Degree of relationships – from Figure 3-2 Entities of two different types related to each other Entities of three different types related to each other One entity related to another of the same entity type

16 16 Figure 3-12 Examples of relationships of different degrees a) Unary relationships

17 17 Figure Examples of relationships of different degrees (cont.) b) Binary relationships

18 18 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own

19  Cardinality is the specification of the number of occurrences (instances) of one object that relates to the number of instances of another object.  One-to one relationship  One-to many relationship  Many-to-many relationship

20 20  One-to-One ◦ Each entity in the relationship will have exactly one related entity  One-to-Many ◦ An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity  Many-to-Many ◦ Entities on both sides of the relationship can have many related entities on the other side

21 E1 E2 E1 E2 One-to-Many Many-to-Many One-to-One 1:1 1:M M:N

22  The number of Entity Instances involved in the Relationship Instances Grouping in a Relationship Type.  Three Forms of Cardinality 1.One-to-one (1:1) DEPARTMENT has MANAGER Each DEPARTMENT has one and only one MANAGER Each MANAGER manages one and only one DEPARTMENT 2.One-to-many (1:m) CUSTOMER places ORDER Each CUSTOMER sometimes (95%) place one or more ORDERs Each ORDER always is placed by exactly one CUSTOMER 3.Many-to-many (m:n) INSTRUCTOR teaches COURSE Each INSTRUCTION teaches zero, one, or more COURSEs Each COURSE is taught by one or more INSTRUCTORs

23  Modality describes the possibility that whether a relationship between the entities is required or not.  The modality of a relationship is 0 if the relationship is optional, and the modality is 1 if an occurrence of the relationship is essential.

24 24 Figure Examples of cardinality constraints a) Mandatory cardinalities A patient must have recorded at least one history, and can have many A patient history is recorded for one and only one patient

25 25 Figure Examples of cardinality constraints (cont.) b) One optional, one mandatory An employee can be assigned to any number of projects, or may not be assigned to any at all A project must be assigned to at least one employee, and may be assigned to many

26 26 Sample E-R Diagram (Figure )

27 E-R Diagram : Examples

28 Modality: the customer is required to have an order Modality: the customer can arrive without any order Cardinality: single customer Placed a given order Cardinality: customer has Many order customerorder

29 29  Strong entities ◦ exist independently of other types of entities ◦ has its own unique identifier ◦ identifier underlined with single-line  Weak entity ◦ dependent on a strong entity (identifying owner)…cannot exist on its own ◦ does not have a unique identifier (only a partial identifier) ◦ Partial identifier underlined with double-line ◦ Entity box has double line  Identifying relationship ◦ links strong entities to weak entities

30 30 Strong entity Weak entity Identifying relationship


Download ppt "DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data."

Similar presentations


Ads by Google