Presentation is loading. Please wait.

Presentation is loading. Please wait.

Switch off your Mobiles Phones or Change Profile to Silent Mode.

Similar presentations


Presentation on theme: "Switch off your Mobiles Phones or Change Profile to Silent Mode."— Presentation transcript:

1 Switch off your Mobiles Phones or Change Profile to Silent Mode

2 Relational Model

3 Topics Database Models Hierarchical Model Network Model Relational Model Entity Relationship Model Object Oriented Model Keys Primary Keys Foreign Keys Relational Integrity Business Rule

4 Database Models A way of thinking about data in a database is called a logical database model (or implementation model). Types of Logical Model Hierarchical Model Network Model Relational Model Entity Relationship Model Object Oriented Model

5 Database Models

6 Hierarchical Model Developed in the 1960s To manage large amounts of data for complex manufacturing projects such as Apollo rocket that landed on moon (1969) Its basic logical structure is represented by an upside-down tree. The hierarchical structure contains levels, or segments. A segment is equivalent of a file system’s record type.

7 Hierarchical Model Within the hierarchy, a higher layer is perceived as the parent of the segment directly beneath it, which is called the child. The hierarchical model depicts a set of one-to-many (1:M) relationships between a parent and its children segments. Each parent can have many children, but each child has only one parent.

8 Hierarchical Model

9

10 Hierarchical views can differ between user group

11 Hierarchical Model Advantages Conceptual simplicity Database security Data independence Database integrity Efficiency

12 Hierarchical Model Disadvantages Complex implementation Difficult to manage Lacks structural independence Complex applications programming and use Implementation limitations Lack of standards

13 Network Model Network Model was created to represent complex data relationships more effectively than hierarchical model, to improve database performance, and to impose a database standard. User perceives the network database as a collection of records in 1:M relationships. Unlike the Hierarchical Model, Network Model allows a record to have more than one parent.

14 Network Model Some important concepts are: Schema, which is the conceptual organization of entire database as viewed by database administrator. Subschema, which defines portion of database “seen” by application programs that actually produce desired information from data contained within the database.

15 Network Model Data Manipulation Language (DML), which defines environment in which data can be managed and to work with data in database. A schema Data Definition Language (DDL), which enables the database administrator to define the schema components.

16 Network Model

17

18 Advantages Conceptual simplicity Handles more relationship types Data access flexibility Promotes database integrity Data independence Conformance to standards Disadvantages System complexity Lack of structural independence

19 Relational Model Relational Model was introduced in 1970 by E. F. Codd (of IBM) in his landmark paper “A Relational Model of Data for Large Shared Databanks” Performs same basic functions provided by hierarchical and network DBMS systems, plus other functions Most important advantage of the RDBMS is its ability to let the user/designer operate in a human logical environment

20 Relational Model Data model that represents data in form of tables or relation. Table (relations) Matrix consisting of a series of row/column intersections Related to each other by sharing a common entity characteristic Relational schema Visual representation of relational database’s entities, attributes within those entities, and relationships between those entities

21 Relational Model Physical Properties A relation consists of 1 or more columns and 0 or more rows. A row is called a tuple. Each relation is given a unique name. Each column has a name unique within the relation. Each row contains an instance of the data associated with the relation. A relation with no rows is empty (contains no data), but still exists.

22 Relational Model Logical Properties Columns are unordered, left to right. This property is designed to preserve the independence of each column. Rows are unordered, top to bottom. This is designed to preserve the independence of each row. No row may be duplicated in a given relation. Uniqueness in a relation is guaranteed by the designation of a Primary Key for each relation.

23 Relational Model A Candidate Key is an attribute that uniquely identifies a row in that relation. A Primary Key is a candidate key that has been selected to be unique identifier for each row. Primary key values cannot be null, since they would then not identify a row. Columns can be interchanged without changing the meaning or use of relation. It makes no difference as whether to insert a new row in front or at end of table.

24 Relational Model

25 Advantages Structural independence Improved conceptual simplicity Easier database design, implementation, management, and use Ad hoc query capability Powerful database management system

26 Relational Model Disadvantages Substantial hardware and system software overhead Can facilitate poor design and implementation May promote “islands of information” problems

27 Entity Relationship Model Peter Chen first introduced the ER data model in 1976 Graphical representation of entities and their relationships in database structure. ER Models are normally represented in an Entity Relationship Diagram (ERD) to model database components. It complemented Relational Data model. Relational Data Model and ERM combined to provide foundation for structured database design.

28 Entity Relationship Model

29 Advantages Visual representation Effective communication tool Integrated with the relational data model Disadvantages Limited constraint representation Limited relationship representation No data manipulation language Loss of information content

30 Object Oriented Model Semantic data model (SDM) developed by Hammer and McLeod in 1981 Modeled both data and their relationships in a single structure known as an object Basis of object oriented data model (OODM) OODM becomes the basis for the object oriented database management system (OODBMS)

31 Object Oriented Model Object-Oriented Data Model (OODM), both data and their relationships are contained in a single structure known as an object OODM reflects a very different way to define and use entities. Object is described by its factual content. Object includes information about relationships between the facts within the object, as well as information about its relationships with other objects.

32 Object Oriented Model

33 Advantages Adds semantic content Visual presentation includes semantic content Database integrity Both structural and data independence

34 Object Oriented Model Disadvantages Slow pace of OODM standards development Complex navigational data access Steep learning curve High system overhead slows transactions Lack of market penetration

35 Database Models Earlier Models Difficult to change structure Unplanned queries difficult to support Have to ‘navigate’ through the database Data stored in linked sets physically Programmer must be aware of structure Relational Model Easy to understand concepts Logical/Physical aspects clearly separated No (visible) physical pointers used Easy to set-up and change Set-oriented (not record-oriented)

36 Keys Choice of Primary Key is an important design issue Eg. An attribute list for a PERSON entity Surname Firstname DOB Gender Passport number Driving Licence number Election number Citizenship number

37 Primary Keys PRIMARY KEY for a table T1 is a column PK of T1 such that, at any given time, no two rows of T1 have same value for PK. An entity’s primary key is one or more of its attributes which together uniquely identify an occurrence of the entity.

38 Primary Keys STUDENT (Student-ID, Student-Name, Address) Student-idStudent-nameAddress S1001Tom12a Clover Street S1002AlexFlat B High Street S1003Brown218 Tulip Road STUDENT

39 Primary Keys FEATURES Can never take on a particular set of values in more than one occurrence of the entity. No primary key attribute can have a null value. Every attribute in the primary key is mandatory.

40 Foreign Key FOREIGN KEY is a column FK of some table T2 such that, at any given time, every (non NULL) value of FK in T2 is required to be equal to the value of the PRIMARY KEY PK in some row of some base table T1. Foreign keys are the ‘glue’ that holds the database together and rrepresents certain relationships between tuples. CUSTOMER ORDER-LINE ORDER places comprised of

41 Foreign Key Lecturer-idLecturer-nameDepartment*Salary W01Emma GregComputing35,000 S01Wendy HolderComputing42,000 D01Amy KingAccounting27,000 J02Bob JonesComputing29,000 N01Bob WhalesAccounting36,500 J01Jack NelsonHistory41,500 LECTURER(Lecture-Id, Lecture-Name, Department*, Salary) DepartmentLocation ComputingMoorgate AccountingStaples HistoryLewiston LECTURER-LOCATION(Department, Location

42 Foreign Key Cust-idCust-nameCredit-StatusBusiness-type 1001SmithExcellentRetail 1910JonesGoodWholesale 2450BrownFairMultiple CUSTOMER Order-noDateCust-id* 10001/02/061910 10104/06/061001 10215/06/061910 ORDER Order-no*Item-noItem-nameQuality 10011Spade15 10092Shovel10 10111Spade12 10292Shovel50 ORDER-LINE

43 Foreign Key Feature: There is no requirement that a Foreign Key be a component of the Primary Key. Dept-code…… DEPARTMENT Empl-no……Dept-code*…… EMPLOYEE Feature: A foreign key will be composite if the primary key it matches is composite. Manufacturer-nameModel-name…… VEHICLE Vehicle-noManufacturer-name*Model-name*… VEHICLE-IN-STOCK

44 Foreign Key Feature: Many-To-Many relationships are always decomposed with Foreign keys making up a composite Primary Key. Supp-no…… SUPPLIER Supp-no*Part-no*…… SUPPLY Part-no…… PART

45 Foreign Key Feature: Note that T1 and T2 do not have to be distinct Empl-no……Mgr-no*…… EMPLOYEE

46 Foreign Key Cust-idCust-nameCredit-StatusBusiness-type 1001SmithExcellentRetail 1910JonesGoodWholesale 2450BrownFairMultiple CUSTOMER Order-noDateCust-id* 10001/02/061910 10104/06/061001 10215/06/061910 ORDER Feature: There is no requirement that a given Primary Key value must appear in a corresponding Foreign Key.

47 Domains The range of values that the entries in a particular column can take is known as the domain. Example: The domain of gender has only two values (e.g. Male/Female). The domain of start date could be any valid date greater than 01/01/2006. The domain of salary may be restricted to the range 20,000 - 80,000.

48 Relational Integrity Integrity in a database is concerned with the database having correct and consistent data. Domain Integrity Rule Every attribute is required to satisfy the constraint that its values are drawn from the relevant domain. Entity Integrity Rule No component of the primary key of a base relation is allowed to accept nulls.

49 Relational Integrity Referential Integrity Rule The database must not contain any unmatched foreign key values. User-Defined or Application-Specific Integrity

50 Referential Integrity If a foreign key exists in a relation, either foreign key value must match a candidate key value of some tuple in its home relation or foreign key value must be wholly null. CUSTOMER ORDER places

51 Referential Integrity Cust-idCust-nameCredit-StatusBusiness-type 1001SmithExcellentRetail 1910JonesGoodWholesale 2450BrownFairMultiple CUSTOMER(Cust-id, Cust-name, Credit-status, Business-type Order-noDateCust-id* 10001/02/061910 10104/06/061001 10215/06/061910 ORDER(Order-no, Date, Cust-id*)

52 Referential Integrity For Deletion and Update RESTRICTED Operation is ‘restricted’ to the case where no such matching occurs. i.e. attempt to delete (update) customer id 1001 fails. CASCADES Operation cascades to delete matches as well. i.e. delete (update) customer id 1001 and orders 101.

53 Referential Integrity For Deletion and Update NULLIFIES Foreign key is set to null in all matches and record is deleted (updated). i.e. delete (update) record, set cust-id in orders 101 to null.

54 Business Rules Brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization’s environment Apply to any organization that stores and uses data to generate information Description of operations that help to create and enforce actions within that organization’s environment

55 Business Rules Must be rendered in writing Must be kept up to date Sometimes are external to organization Must be easy to understand and widely disseminated Describe characteristics of the data as viewed by company

56 Sources of Business Rules Company Managers Policy Makers Department Managers Written Documentation Procedures Standards Operations manuals Direct interviews with end users

57 Importance of Business Rules Promote creation of accurate data model Standardize company’s view of data Constitute a communications tool between users and designers Allow designer to understand nature, role, and scope of data Allow designer to understand business processes Allow designer to develop appropriate relationship participation rules and constraints

58 Any Questions?


Download ppt "Switch off your Mobiles Phones or Change Profile to Silent Mode."

Similar presentations


Ads by Google