SlideShare una empresa de Scribd logo
1 de 39
Descargar para leer sin conexión
RDBMS Basics Chapter 2: The Relational Database Model (With Considerable Modifications)
RDBMS Basics We already know that a  R elational  D ata B ase  M anagement  S ystem ( RDBMS ) is: ,[object Object],[object Object]
RDBMS Basics    Consider some information the University maintains:    Name    Address    SSN    Major    Courses Taken    Grades Received    Tuition Paid    Tuition Owed    Grants/Scholarships    HOW  is this information stored? You are an  entity  with  attributes  which  vary . Within the University,  different areas  have different interests in you (i.e., the Registrar, the Bursar, etc.). Nonetheless, you are still part of the  University  as a whole.    HOW  does this relate to a database?
RDBMS Basics You are an  entity Record with  attributes Fields which  vary Fields can contain characters, numbers, symbols, etc. Within the University,  different  areas ,  have different interests in you Files (i.e,. The Registrar, Bursar, etc.) Nonetheless, you are still part of the  University Database Database Components:
RDBMS Basics Database Components: A  Database  consists of Files ,  which   contain Records ,  which   contain Fields ,  which   may consist of a variety of data types Jones, Mary 234567890 102 3.87 Notice that there should always be a  Key  (Unique) Field Hernandez, Juan 123456789 72 2.42 • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •  • •  • • • •  • • • • • • • • • • • • • •  • •  • • • •  • • • • • • • • • • • • • • •  • • •  • • •  • • •  • •  • •  • • • •  • • • •  • • • •  • • • • • • • •
RDBMS Basics RDBMS Restrictions/Conventions:    Each Relation  MUST  have a unique name NOT Allowed StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. Accounting •••••• •••••• •••••• •••••• Table  Student Student Owed Department 103456678 1,502.36 Marketing 123456789 COBA219 Finance 456789012 COBA232 Accounting •••••• •••••• •••••• Table  Balance SID •••••• Depart 987654321 •••••• Finance 876543210 •••••• INFOSYS 765432109 •••••• Accounting •••••• •••••• •••••• Table  Student
RDBMS Basics RDBMS Restrictions /Conventions :    Each Relation  MUST  have a unique name Table  Student    All Columns ( Tuples )  MUST  have Unique names * NOTE : The same field names  CAN  be used in different Relations StudentID Name Address Major Address 123456789 Saenz, Lupe 123 Mesa Arlington Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS New York 345678901 Adams, John 54B Hague Dallas Accounting 456789012 Elam, Mary 123-22 E St. Ft. Worth INFOSYS One of the names  MUST  be changed
RDBMS Basics RDBMS Restrictions /Conventions :    Each Relation  MUST  have a unique name Table  Student    All Columns (Tuples)  MUST  have Unique names Unless this is stored as  Character String   “24.34”  (and  NOT  as the real number  24.34 ), it  MUST  be changed    All Column Elements  MUST  be of the same data type StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa 24.34 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS
RDBMS Basics RDBMS Restrictions /Conventions :    Each Relation  MUST  have a unique name Table  Student    All Columns (Tuples)  MUST  have Unique names StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance    All Column Elements  MUST  be of the same data type ,[object Object],A Character String Requiring  9  Bytes of Storage A Character String Requiring  20  Bytes of Storage A Character String Requiring  25  Bytes of Storage A Character String Requiring  10  Bytes of Storage A Total  64  Bytes of Storage
RDBMS Basics RDBMS Restrictions /Conventions :    Each Relation  MUST  have a unique name    All Columns (Tuples)  MUST  have Unique names    All Column Elements  MUST  be of the same data type    The order of Rows is  NOT  important Is the Same as StudentID Name Address Majo r 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting StudentID N ame Address Major 123456789 Saenz, Lupe 123 Mesa Finace 345678901 Adams, John 54B Hague Accounting 234567890 Chung, Mei 37 5 th  St. INFOSYS
RDBMS Basics RDBMS Restrictions /Conventions :    Each Relation  MUST  have a unique name    All Columns (Tuples)  MUST  have Unique names    All Column Elements  MUST  be of the same data type    The order of Rows is  NOT  important Each contains 64 Bytes    The Number of Bytes/Record Must be the same StudentID Name Address Majo r 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting
RDBMS Basics RDBMS Keys:    Purpose    Define entity relationships    Determination    Knowing the value of a key field means you also know ( Determine ) the values of the other fields    E.g., knowing  StudentID  means you know  StudentName ,  StudentAddress , etc. StudentID StudentName ,  StudentAddress (StudentID  Determines   StudentName  and  StudentAddress)
RDBMS Basics RDBMS Keys:    Purpose    Define entity relationships    Determination    An attribute is  functionally dependent  on another if can be determined by that attribute    Functional Dependence StudentID StudentAddress (StudentID  Determines   Student Address)    NOTE: StudentID StudentAddress (Two Students  MAY  live at the same address)
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or   PRIMARY KEY Table  Student No two students can have the same  StudentID StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS •••••• •••••• •••••• ••••••
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or  PRIMARY KEY    A  COMPOSITE KEY  is a combination of keys (Multi-key attributes) used to produce uniqueness StudentName,StudentAddress StudentMajor (StudentName  AND  StudentAddress  Determines   StudentMajor)    NOTE: If Student Major is functionally dependent upon  StudentName  AND  StudentAddress   , BUT not on either  StudentName  or  StudentName  it is  FULLY FUNCTIONAL DEPENDENT  on the Concatenated key (Attributes are fully functionally dependent on  PRIMARY KEYS )
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or  PRIMARY KEY    A is  COMPOSITE KEY  is a combination of keys (Multi-key attributes) used to produce uniqueness    A is  SUPER KEY  is either a  PRIMARY  or  COMPOSITE KEY  that uniquely identifies an entity StudentID StudentAddress AND StudentName,StudentAddress StudentMajor Are BOTH Superkeys
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or  PRIMARY KEY    A is  COMPOSITE KEY  is a combination of keys (Multi-key attributes) used to produce uniqueness    A is  SUPER KEY  is either a  PRIMARY  or  COMPOSITE KEY  that uniquely identifies an entity    A is  CANDIDATE KEY  is any key or group of keys that could become a  SUPER KEY ,[object Object],[object Object],[object Object],(StudentID by itself is a  CANDIDATE KEY )
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or  PRIMARY KEY    A is  COMPOSITE KEY  is a combination of keys (Multi-key attributes) used to produce uniqueness    A is  SUPER KEY  is either a  PRIMARY  or  COMPOSITE KEY  that uniquely identifies an entity    A is  CANDIDATE KEY  is any key or group of keys that could become a  SUPER KEY    A is  SECONDARY KEY  is any field, or combination of fields, which does NOT yield a unique value ,[object Object],[object Object]
RDBMS Basics RDBMS Keys:    Each Relation  MUST  have a unique identifier or  PRIMARY KEY    A is  COMPOSITE KEY  is a combination of keys (Multi-key attributes) used to produce uniqueness    A is  SUPER KEY  is either a  PRIMARY  or  COMPOSITE KEY  that uniquely identifies an entity    A is  CANDIDATE KEY  is any key or group of keys that could become a  SUPER KEY    A is  SECONDARY KEY  is any field, or combination of fields, which does NOT yield a unique value ,[object Object],[object Object]
RDBMS Basics RDBMS Keys:    In Order to relate two (or more) tables   FOREIGN KEYS  must be used   Table  Student Table  Department A  FOREIGN KEY   in one table is  a   PRIMARY/SUPER KEY   In another StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 345678901 Adams, John 54B Hague Accounting DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 Accounting Courtney, H. 555-3456
RDBMS Basics Database Integrity:    Maintaining wholeness and Unity    Entity Integrity:    All Entries MUST be Unique    No NULL values in primary key fields Table  Student Illegal Entries StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th  St. INFOSYS 123456789 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS Bush, G.W. 555 Austin  Marketing
RDBMS Basics Database Integrity:    Maintaining wholeness and Unity    Entity Integrity    Relational Integrity:    Foreign Key MUST have a valid entry in the corresponding table (or be NULL)  Table  Student Table  Department NOT Allowed StudentID Major 123456789 Scamming 234567890 INFOSYS 345678901 DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 Accounting Courtney, H. 555-3456 ???
RDBMS Basics Database Integrity:    Maintaining wholeness and Unity    Entity Integrity    Relational Integrity:    Foreign Key MUST have a valid entry in the corresponding table (or be NULL)  Table  Student Table  Department    Primary Key entry CAN NOT be deleted if a foreign key refers to it INFOSYS can NOT be deleted DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 StudentID Major 123456789 Accounting 234567890 INFOSYS 345678901 Finance
RDBMS Basics Basic RDBMS Operators:    SELECT    Choose All or Specific values from a table SELECT ALL Yields Given: Table  Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th  St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th  St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin
RDBMS Basics Basic RDBMS Operators:    SELECT    Choose All or Specific values from a table SELECT WHERE ADDRESS = “555 Austin” Yields Given: Table  Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th  St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name Address 567890123 Bush, G.W 555 Austin 789012345 Bush, J. Austin
RDBMS Basics Basic RDBMS Operators:    PROJECT    Produce list of all values for a selected attribute PROJECT STUDENTID Yields Given: Table  Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th  St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID 123456789 234567890 345678901 456789012 567890123 678901234 789012345
RDBMS Basics Basic RDBMS Operators:    PROJECT    Produce list of of all values for a selected attribute PROJECT STUDENTID, NAME Yields Given: Table  Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th  St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name 123456789 Saenz, Lupe 234567890 Chung, Mei 345678901 Adams, John 456789012 Elam, Mary 567890123 Bush, G.W 678901234 Clinton, B. 789012345 Bush, J.
RDBMS Basics Basic RDBMS Operators:    JOIN    Links 2 different tables together (Producing a different table)    Each Table MUST have attributes that are common to both tables 123 CID 124 125 126 127 CN AA BB CC BB DD CA 6 20 12 9 18 CR AA BB CC CAdd 123 A 234 B 345 C TableA TableB
RDBMS Basics Basic RDBMS Operators:    JOIN    Consider the relationship between a  Physician  and his/her  Patients 123456789 PhysID Physician Patient 234567890 345678901 Physname Smith, Mary Brown, John Jones, Jerry PatID Patname PhysID 987654321 Washington, G. 234567890 876543210 765432109 654321098 543210987 Adams, J.Q. Jefferson, T. XXX YYY ZZZ AAA 432109876 321098765 345678901 123456789 123456789 234567890 345678901 123456789
RDBMS Basics Basic RDBMS Operators:    JOIN    The Product of the tables is: Physician Patient = * The product of a 3 (row) x 2 (column) Table and a 6 (row) x 3 (column) Table would be a 18 (row) by 5 (column) Table 123456789 Smith, Mary 234567890 Brown, John 345678901 Jones, Jerry Patname PatID Phys Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 PhysID Physname PhysID Physname PatID Patname Phys Adams, J.Q. 876543210 345678901 123456789 Smith, Mary 123456789 Smith, Mary Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 123456789 Smith, Mary Jefferson, T. 765432109 123456789 123456789 Smith, Mary XXX 654321098 123456789 123456789 Smith, Mary YYY 543210987 234567890 123456789 Smith, Mary ZZZ 432109876 345678901 234567890 234567890 234567890 234567890 234567890 234567890 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Brown, John Brown, John Brown, John Brown, John Brown, John Brown, John Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Adams, J.Q. 876543210 345678901 345678901 345678901 345678901 345678901 345678901 345678901 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Adams, J.Q. 876543210 345678901
RDBMS Basics Basic RDBMS Operators:    JOIN ,[object Object],[object Object],Smith, Mary Washington, G. 987654321 PhysID Physname PatID Patname Phys Adams, J.Q. 876543210 345678901 123456789 Smith, Mary 123456789 Smith, Mary Washington, G. 987654321 234567890 123456789 Smith, Mary Jefferson, T. 765432109 123456789 123456789 Smith, Mary XXX 654321098 123456789 123456789 Smith, Mary YYY 543210987 234567890 123456789 Smith, Mary ZZZ 432109876 345678901 234567890 234567890 234567890 234567890 234567890 234567890 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Brown, John Brown, John Brown, John Brown, John Brown, John Brown, John 345678901 345678901 345678901 345678901 345678901 345678901 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry PhysID Physname PatID Patname Phys Adams, J.Q. 876543210 345678901 123456789 Smith, Mary 123456789 234567890 123456789 Smith, Mary Jefferson, T. 765432109 123456789 123456789 Smith, Mary XXX 654321098 123456789 123456789 Smith, Mary YYY 543210987 234567890 123456789 Smith, Mary ZZZ 432109876 345678901 234567890 234567890 234567890 234567890 234567890 234567890 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Brown, John Brown, John Brown, John Brown, John Brown, John Brown, John 345678901 345678901 345678901 345678901 345678901 345678901 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry
RDBMS Basics Basic RDBMS Operators:    JOIN ,[object Object],[object Object],123 CID 124 125 126 127 CN AA BB CC BB DD CA 6 20 12 9 18 TableA CR AA BB CC CAdd 123 A 234 B 345 C TableB TableC CID CN CA CAdd 123 AA 6 123 A 124 BB 20 234 B 125 CC 12 345 C 126 BB 9 234 B 123 AA 6 123 A
RDBMS Basics How???    A Simple  PRODUCT  of the Tables is First created 123 CID 124 125 126 127 CN AA BB CC BB AA CA 6 20 12 9 18 TableA CR AA BB CC CAdd 123 A 234 B 345 C TableB CN CR CAdd CID CA 123 6 AA 123 A AA 124 20 AA 123 A BB 125 12 AA 123 A CC 126 9 AA 123 A BB 127 18 AA 123 A AA 123 6 BB 234 B AA 124 20 BB 234 B BB 125 12 BB 234 B CC 126 9 BB 234 B BB 127 18 BB 234 B AA 123 6 CC 345 C AA 124 20 CC 345 C BB 125 12 CC 345 C CC 126 9 CC 345 C BB 127 18 CC 345 C AA CR   AA  Joins CR   BB  Joins CR   CC  Joins
RDBMS Basics How???    A Simple  PRODUCT  of the Tables is First created    A  SELECT  command where  CN = CR  is issued CN CR CAdd CID CA 123 6 AA 123 A AA 124 20 AA 123 A BB 125 12 AA 123 A CC 126 9 AA 123 A BB 127 18 AA 123 A AA 123 6 BB 234 B AA 124 20 BB 234 B BB 125 12 BB 234 B CC 126 9 BB 234 B BB 127 18 BB 234 B AA 123 6 CC 345 C AA 124 20 CC 345 C BB 125 12 CC 345 C CC 126 9 CC 345 C BB 127 18 CC 345 C AA TableC CID CN CA CAdd 123 AA 6 123 A 124 BB 20 234 B 125 CC 12 345 C 126 BB 9 234 B
RDBMS Basics ADDITIONAL  RDBMS Operators:    UNION (NOT always available)    May use single single table    E.G., Creating a phone directory from 2 separate tables    There are no common values so a join can not be performed    Separate queries will produce separate tables    Duplicate records NOT displayed    Combines the results of two unrelated queries into a single output
RDBMS Basics ADDITIONAL  RDBMS Operators:    INTERSECT (NOT always available)    Similar to UNION (Combines the results of two unrelated queries into a single output)    There MUST be matching rows in the tables    E.G., Creating a phone directory of Faculty with offices in BUS who also teach in the Business Bldg.    Some Faculty Have offices in BUS     Some Faculty Teach in the Business Building     Merge those who do both into one listing
RDBMS Basics ADDITIONAL  RDBMS Operators:    DIFFERENCE (NOT always available)    Yields all rows in one table NOT found in the other    Produces list of all possible pairings    PRODUCT  (Seen Earlier)    DIVIDE
RDBMS Basics RDBMS Software Classifications    Fully Relational    Supports all relational algebra functions    Enforces  Entity  and  Referential  Integrity Rules    Relationally Complete    Supports all relational algebra functions    Does NOT support Integrity Rules    Minimally Relational     Supports only SELECT, PROJECT, and JOIN    Tabular     Supports only SELECT, PROJECT, and JOIN    User MUST define all access paths
RDBMS Basics

Más contenido relacionado

La actualidad más candente

Relational Data Model Introduction
Relational Data Model IntroductionRelational Data Model Introduction
Relational Data Model IntroductionNishant Munjal
 
Relational Model - An Introduction
Relational Model - An IntroductionRelational Model - An Introduction
Relational Model - An IntroductionRajeev Srivastava
 
Relational database- Fundamentals
Relational database- FundamentalsRelational database- Fundamentals
Relational database- FundamentalsMohammed El Hedhly
 
Relational Database Fundamentals
Relational Database FundamentalsRelational Database Fundamentals
Relational Database FundamentalsKHALID C
 
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...Raj vardhan
 
Database : Relational Data Model
Database : Relational Data ModelDatabase : Relational Data Model
Database : Relational Data ModelSmriti Jain
 
The relational data model part[1]
The relational data model part[1]The relational data model part[1]
The relational data model part[1]Bashir Rezaie
 
DATABASE CONCEPTS AND PRACTICAL EXAMPLES
DATABASE CONCEPTS AND PRACTICAL EXAMPLESDATABASE CONCEPTS AND PRACTICAL EXAMPLES
DATABASE CONCEPTS AND PRACTICAL EXAMPLESNathRam2
 
DBMS-Quick Reference
DBMS-Quick ReferenceDBMS-Quick Reference
DBMS-Quick ReferenceShrija Madhu
 
Chapter3 the relational data model and the relation database constraints part2
Chapter3 the relational data model and the relation database constraints part2Chapter3 the relational data model and the relation database constraints part2
Chapter3 the relational data model and the relation database constraints part2eidah20
 
Chapter 6 relational data model and relational
Chapter  6  relational data model and relationalChapter  6  relational data model and relational
Chapter 6 relational data model and relationalJafar Nesargi
 
Chapter-5 The Relational Data Model
Chapter-5 The Relational Data ModelChapter-5 The Relational Data Model
Chapter-5 The Relational Data ModelKunal Anand
 
Fundamentals of database system - Relational data model and relational datab...
Fundamentals of database system  - Relational data model and relational datab...Fundamentals of database system  - Relational data model and relational datab...
Fundamentals of database system - Relational data model and relational datab...Mustafa Kamel Mohammadi
 
DEE 431 Database keys and Normalisation Slide 2
DEE 431 Database keys and Normalisation Slide 2DEE 431 Database keys and Normalisation Slide 2
DEE 431 Database keys and Normalisation Slide 2YOGESH SINGH
 

La actualidad más candente (20)

Relational Data Model Introduction
Relational Data Model IntroductionRelational Data Model Introduction
Relational Data Model Introduction
 
Relational Model - An Introduction
Relational Model - An IntroductionRelational Model - An Introduction
Relational Model - An Introduction
 
Relational model
Relational modelRelational model
Relational model
 
Relational model
Relational modelRelational model
Relational model
 
Relational database- Fundamentals
Relational database- FundamentalsRelational database- Fundamentals
Relational database- Fundamentals
 
Relational Database Fundamentals
Relational Database FundamentalsRelational Database Fundamentals
Relational Database Fundamentals
 
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...
The Relational Data Model and Relational Database Constraints Ch5 (Navathe 4t...
 
Database : Relational Data Model
Database : Relational Data ModelDatabase : Relational Data Model
Database : Relational Data Model
 
Dbms relational data model and sql queries
Dbms relational data model and sql queries Dbms relational data model and sql queries
Dbms relational data model and sql queries
 
B & c
B & cB & c
B & c
 
The relational data model part[1]
The relational data model part[1]The relational data model part[1]
The relational data model part[1]
 
DBMS:Relational Modal
DBMS:Relational ModalDBMS:Relational Modal
DBMS:Relational Modal
 
DATABASE CONCEPTS AND PRACTICAL EXAMPLES
DATABASE CONCEPTS AND PRACTICAL EXAMPLESDATABASE CONCEPTS AND PRACTICAL EXAMPLES
DATABASE CONCEPTS AND PRACTICAL EXAMPLES
 
DBMS-Quick Reference
DBMS-Quick ReferenceDBMS-Quick Reference
DBMS-Quick Reference
 
Chapter3 the relational data model and the relation database constraints part2
Chapter3 the relational data model and the relation database constraints part2Chapter3 the relational data model and the relation database constraints part2
Chapter3 the relational data model and the relation database constraints part2
 
Chapter 6 relational data model and relational
Chapter  6  relational data model and relationalChapter  6  relational data model and relational
Chapter 6 relational data model and relational
 
Chapter-5 The Relational Data Model
Chapter-5 The Relational Data ModelChapter-5 The Relational Data Model
Chapter-5 The Relational Data Model
 
Fundamentals of database system - Relational data model and relational datab...
Fundamentals of database system  - Relational data model and relational datab...Fundamentals of database system  - Relational data model and relational datab...
Fundamentals of database system - Relational data model and relational datab...
 
My sql
My sqlMy sql
My sql
 
DEE 431 Database keys and Normalisation Slide 2
DEE 431 Database keys and Normalisation Slide 2DEE 431 Database keys and Normalisation Slide 2
DEE 431 Database keys and Normalisation Slide 2
 

Similar a Relational D Bs3

Similar a Relational D Bs3 (20)

RelationalDBs3.ppt
RelationalDBs3.pptRelationalDBs3.ppt
RelationalDBs3.ppt
 
Database Concepts.pptx
Database Concepts.pptxDatabase Concepts.pptx
Database Concepts.pptx
 
Data Base Management System.pdf
Data Base Management System.pdfData Base Management System.pdf
Data Base Management System.pdf
 
NMEC RD_UNIT 1.ppt
NMEC RD_UNIT 1.pptNMEC RD_UNIT 1.ppt
NMEC RD_UNIT 1.ppt
 
DBMS-Unit-2.pptx
DBMS-Unit-2.pptxDBMS-Unit-2.pptx
DBMS-Unit-2.pptx
 
19IS305_U2_LP4_LM4-22-23.pdf
19IS305_U2_LP4_LM4-22-23.pdf19IS305_U2_LP4_LM4-22-23.pdf
19IS305_U2_LP4_LM4-22-23.pdf
 
Dbms relational model
Dbms relational modelDbms relational model
Dbms relational model
 
Ms access Database
Ms access DatabaseMs access Database
Ms access Database
 
DATABASE-1.pptx
DATABASE-1.pptxDATABASE-1.pptx
DATABASE-1.pptx
 
2.2 keys
2.2 keys2.2 keys
2.2 keys
 
Advanced Database Systems - Presentation 1 with quiz.pptx
Advanced Database Systems - Presentation 1 with quiz.pptxAdvanced Database Systems - Presentation 1 with quiz.pptx
Advanced Database Systems - Presentation 1 with quiz.pptx
 
CSCI 4140-AA Pre-Req.ppt
CSCI 4140-AA Pre-Req.pptCSCI 4140-AA Pre-Req.ppt
CSCI 4140-AA Pre-Req.ppt
 
SQL Fundamentals (Oracle 11g) - Lecture 1
SQL Fundamentals (Oracle 11g) - Lecture 1SQL Fundamentals (Oracle 11g) - Lecture 1
SQL Fundamentals (Oracle 11g) - Lecture 1
 
Sql introduction
Sql introductionSql introduction
Sql introduction
 
sql_data.pdf
sql_data.pdfsql_data.pdf
sql_data.pdf
 
Unit 2 DBMS.pptx
Unit 2 DBMS.pptxUnit 2 DBMS.pptx
Unit 2 DBMS.pptx
 
RELATIONSHIP IN DBMS.pptx
RELATIONSHIP IN DBMS.pptxRELATIONSHIP IN DBMS.pptx
RELATIONSHIP IN DBMS.pptx
 
Relational Model
Relational ModelRelational Model
Relational Model
 
Lesson2 dbms
Lesson2 dbmsLesson2 dbms
Lesson2 dbms
 
RDBMS Model
RDBMS ModelRDBMS Model
RDBMS Model
 

Último

Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Mark Simos
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxLoriGlavin3
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfIngrid Airi González
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Hiroshi SHIBATA
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesBernd Ruecker
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Karmanjay Verma
 
All These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFAll These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFMichael Gough
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationKnoldus Inc.
 
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS:  6 Ways to Automate Your Data IntegrationBridging Between CAD & GIS:  6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integrationmarketing932765
 
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Nikki Chapple
 
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical InfrastructureVarsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructureitnewsafrica
 
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...itnewsafrica
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsRavi Sanghani
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...Wes McKinney
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI AgeCprime
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfLoriGlavin3
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesThousandEyes
 
UiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPathCommunity
 
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfSo einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfpanagenda
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxLoriGlavin3
 

Último (20)

Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
Tampa BSides - The No BS SOC (slides from April 6, 2024 talk)
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
 
Generative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdfGenerative Artificial Intelligence: How generative AI works.pdf
Generative Artificial Intelligence: How generative AI works.pdf
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architectures
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#
 
All These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDFAll These Sophisticated Attacks, Can We Really Detect Them - PDF
All These Sophisticated Attacks, Can We Really Detect Them - PDF
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog Presentation
 
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS:  6 Ways to Automate Your Data IntegrationBridging Between CAD & GIS:  6 Ways to Automate Your Data Integration
Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
 
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
Microsoft 365 Copilot: How to boost your productivity with AI – Part one: Ado...
 
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical InfrastructureVarsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
Varsha Sewlal- Cyber Attacks on Critical Critical Infrastructure
 
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and Insights
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
 
A Framework for Development in the AI Age
A Framework for Development in the AI AgeA Framework for Development in the AI Age
A Framework for Development in the AI Age
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdf
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
 
UiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to Hero
 
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfSo einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
 

Relational D Bs3

  • 1. RDBMS Basics Chapter 2: The Relational Database Model (With Considerable Modifications)
  • 2.
  • 3. RDBMS Basics  Consider some information the University maintains:  Name  Address  SSN  Major  Courses Taken  Grades Received  Tuition Paid  Tuition Owed  Grants/Scholarships  HOW is this information stored? You are an entity with attributes which vary . Within the University, different areas have different interests in you (i.e., the Registrar, the Bursar, etc.). Nonetheless, you are still part of the University as a whole.  HOW does this relate to a database?
  • 4. RDBMS Basics You are an entity Record with attributes Fields which vary Fields can contain characters, numbers, symbols, etc. Within the University, different areas , have different interests in you Files (i.e,. The Registrar, Bursar, etc.) Nonetheless, you are still part of the University Database Database Components:
  • 5. RDBMS Basics Database Components: A Database consists of Files , which contain Records , which contain Fields , which may consist of a variety of data types Jones, Mary 234567890 102 3.87 Notice that there should always be a Key (Unique) Field Hernandez, Juan 123456789 72 2.42 • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
  • 6. RDBMS Basics RDBMS Restrictions/Conventions:  Each Relation MUST have a unique name NOT Allowed StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. Accounting •••••• •••••• •••••• •••••• Table Student Student Owed Department 103456678 1,502.36 Marketing 123456789 COBA219 Finance 456789012 COBA232 Accounting •••••• •••••• •••••• Table Balance SID •••••• Depart 987654321 •••••• Finance 876543210 •••••• INFOSYS 765432109 •••••• Accounting •••••• •••••• •••••• Table Student
  • 7. RDBMS Basics RDBMS Restrictions /Conventions :  Each Relation MUST have a unique name Table Student  All Columns ( Tuples ) MUST have Unique names * NOTE : The same field names CAN be used in different Relations StudentID Name Address Major Address 123456789 Saenz, Lupe 123 Mesa Arlington Finance 234567890 Chung, Mei 37 5 th St. INFOSYS New York 345678901 Adams, John 54B Hague Dallas Accounting 456789012 Elam, Mary 123-22 E St. Ft. Worth INFOSYS One of the names MUST be changed
  • 8. RDBMS Basics RDBMS Restrictions /Conventions :  Each Relation MUST have a unique name Table Student  All Columns (Tuples) MUST have Unique names Unless this is stored as Character String “24.34” (and NOT as the real number 24.34 ), it MUST be changed  All Column Elements MUST be of the same data type StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa 24.34 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS
  • 9.
  • 10. RDBMS Basics RDBMS Restrictions /Conventions :  Each Relation MUST have a unique name  All Columns (Tuples) MUST have Unique names  All Column Elements MUST be of the same data type  The order of Rows is NOT important Is the Same as StudentID Name Address Majo r 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting StudentID N ame Address Major 123456789 Saenz, Lupe 123 Mesa Finace 345678901 Adams, John 54B Hague Accounting 234567890 Chung, Mei 37 5 th St. INFOSYS
  • 11. RDBMS Basics RDBMS Restrictions /Conventions :  Each Relation MUST have a unique name  All Columns (Tuples) MUST have Unique names  All Column Elements MUST be of the same data type  The order of Rows is NOT important Each contains 64 Bytes  The Number of Bytes/Record Must be the same StudentID Name Address Majo r 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting
  • 12. RDBMS Basics RDBMS Keys:  Purpose  Define entity relationships  Determination  Knowing the value of a key field means you also know ( Determine ) the values of the other fields  E.g., knowing StudentID means you know StudentName , StudentAddress , etc. StudentID StudentName , StudentAddress (StudentID Determines StudentName and StudentAddress)
  • 13. RDBMS Basics RDBMS Keys:  Purpose  Define entity relationships  Determination  An attribute is functionally dependent on another if can be determined by that attribute  Functional Dependence StudentID StudentAddress (StudentID Determines Student Address)  NOTE: StudentID StudentAddress (Two Students MAY live at the same address)
  • 14. RDBMS Basics RDBMS Keys:  Each Relation MUST have a unique identifier or PRIMARY KEY Table Student No two students can have the same StudentID StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS •••••• •••••• •••••• ••••••
  • 15. RDBMS Basics RDBMS Keys:  Each Relation MUST have a unique identifier or PRIMARY KEY  A COMPOSITE KEY is a combination of keys (Multi-key attributes) used to produce uniqueness StudentName,StudentAddress StudentMajor (StudentName AND StudentAddress Determines StudentMajor)  NOTE: If Student Major is functionally dependent upon StudentName AND StudentAddress , BUT not on either StudentName or StudentName it is FULLY FUNCTIONAL DEPENDENT on the Concatenated key (Attributes are fully functionally dependent on PRIMARY KEYS )
  • 16. RDBMS Basics RDBMS Keys:  Each Relation MUST have a unique identifier or PRIMARY KEY  A is COMPOSITE KEY is a combination of keys (Multi-key attributes) used to produce uniqueness  A is SUPER KEY is either a PRIMARY or COMPOSITE KEY that uniquely identifies an entity StudentID StudentAddress AND StudentName,StudentAddress StudentMajor Are BOTH Superkeys
  • 17.
  • 18.
  • 19.
  • 20. RDBMS Basics RDBMS Keys:  In Order to relate two (or more) tables FOREIGN KEYS must be used Table Student Table Department A FOREIGN KEY in one table is a PRIMARY/SUPER KEY In another StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 345678901 Adams, John 54B Hague Accounting DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 Accounting Courtney, H. 555-3456
  • 21. RDBMS Basics Database Integrity:  Maintaining wholeness and Unity  Entity Integrity:  All Entries MUST be Unique  No NULL values in primary key fields Table Student Illegal Entries StudentID Name Address Major 123456789 Saenz, Lupe 123 Mesa Finance 234567890 Chung, Mei 37 5 th St. INFOSYS 123456789 Adams, John 54B Hague Accounting 456789012 Elam, Mary 123-22 E St. INFOSYS Bush, G.W. 555 Austin Marketing
  • 22. RDBMS Basics Database Integrity:  Maintaining wholeness and Unity  Entity Integrity  Relational Integrity:  Foreign Key MUST have a valid entry in the corresponding table (or be NULL) Table Student Table Department NOT Allowed StudentID Major 123456789 Scamming 234567890 INFOSYS 345678901 DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 Accounting Courtney, H. 555-3456 ???
  • 23. RDBMS Basics Database Integrity:  Maintaining wholeness and Unity  Entity Integrity  Relational Integrity:  Foreign Key MUST have a valid entry in the corresponding table (or be NULL) Table Student Table Department  Primary Key entry CAN NOT be deleted if a foreign key refers to it INFOSYS can NOT be deleted DeptName Chairman Telephone INFOSYS Sircar, Sumit 555-1234 Marketing McDaniel, C. 555-2345 StudentID Major 123456789 Accounting 234567890 INFOSYS 345678901 Finance
  • 24. RDBMS Basics Basic RDBMS Operators:  SELECT  Choose All or Specific values from a table SELECT ALL Yields Given: Table Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin
  • 25. RDBMS Basics Basic RDBMS Operators:  SELECT  Choose All or Specific values from a table SELECT WHERE ADDRESS = “555 Austin” Yields Given: Table Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name Address 567890123 Bush, G.W 555 Austin 789012345 Bush, J. Austin
  • 26. RDBMS Basics Basic RDBMS Operators:  PROJECT  Produce list of all values for a selected attribute PROJECT STUDENTID Yields Given: Table Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID 123456789 234567890 345678901 456789012 567890123 678901234 789012345
  • 27. RDBMS Basics Basic RDBMS Operators:  PROJECT  Produce list of of all values for a selected attribute PROJECT STUDENTID, NAME Yields Given: Table Student StudentID Name Address 123456789 Saenz, Lupe 123 Mesa 234567890 Chung, Mei 37 5 th St. 345678901 Adams, John 54B Hague 456789012 Elam, Mary 123-22 E St. 567890123 Bush, G.W 555 Austin 678901234 Clinton, B. 89 Congress 789012345 Bush, J. 555 Austin StudentID Name 123456789 Saenz, Lupe 234567890 Chung, Mei 345678901 Adams, John 456789012 Elam, Mary 567890123 Bush, G.W 678901234 Clinton, B. 789012345 Bush, J.
  • 28. RDBMS Basics Basic RDBMS Operators:  JOIN  Links 2 different tables together (Producing a different table)  Each Table MUST have attributes that are common to both tables 123 CID 124 125 126 127 CN AA BB CC BB DD CA 6 20 12 9 18 CR AA BB CC CAdd 123 A 234 B 345 C TableA TableB
  • 29. RDBMS Basics Basic RDBMS Operators:  JOIN  Consider the relationship between a Physician and his/her Patients 123456789 PhysID Physician Patient 234567890 345678901 Physname Smith, Mary Brown, John Jones, Jerry PatID Patname PhysID 987654321 Washington, G. 234567890 876543210 765432109 654321098 543210987 Adams, J.Q. Jefferson, T. XXX YYY ZZZ AAA 432109876 321098765 345678901 123456789 123456789 234567890 345678901 123456789
  • 30. RDBMS Basics Basic RDBMS Operators:  JOIN  The Product of the tables is: Physician Patient = * The product of a 3 (row) x 2 (column) Table and a 6 (row) x 3 (column) Table would be a 18 (row) by 5 (column) Table 123456789 Smith, Mary 234567890 Brown, John 345678901 Jones, Jerry Patname PatID Phys Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 PhysID Physname PhysID Physname PatID Patname Phys Adams, J.Q. 876543210 345678901 123456789 Smith, Mary 123456789 Smith, Mary Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 123456789 Smith, Mary Jefferson, T. 765432109 123456789 123456789 Smith, Mary XXX 654321098 123456789 123456789 Smith, Mary YYY 543210987 234567890 123456789 Smith, Mary ZZZ 432109876 345678901 234567890 234567890 234567890 234567890 234567890 234567890 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Brown, John Brown, John Brown, John Brown, John Brown, John Brown, John Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Adams, J.Q. 876543210 345678901 345678901 345678901 345678901 345678901 345678901 345678901 Washington, G. 987654321 234567890 Adams, J.Q. 876543210 345678901 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Jones, Jerry Washington, G. 987654321 234567890 Jefferson, T. 765432109 123456789 XXX 654321098 123456789 YYY 543210987 234567890 ZZZ 432109876 345678901 Adams, J.Q. 876543210 345678901
  • 31.
  • 32.
  • 33. RDBMS Basics How???  A Simple PRODUCT of the Tables is First created 123 CID 124 125 126 127 CN AA BB CC BB AA CA 6 20 12 9 18 TableA CR AA BB CC CAdd 123 A 234 B 345 C TableB CN CR CAdd CID CA 123 6 AA 123 A AA 124 20 AA 123 A BB 125 12 AA 123 A CC 126 9 AA 123 A BB 127 18 AA 123 A AA 123 6 BB 234 B AA 124 20 BB 234 B BB 125 12 BB 234 B CC 126 9 BB 234 B BB 127 18 BB 234 B AA 123 6 CC 345 C AA 124 20 CC 345 C BB 125 12 CC 345 C CC 126 9 CC 345 C BB 127 18 CC 345 C AA CR AA Joins CR BB Joins CR CC Joins
  • 34. RDBMS Basics How???  A Simple PRODUCT of the Tables is First created  A SELECT command where CN = CR is issued CN CR CAdd CID CA 123 6 AA 123 A AA 124 20 AA 123 A BB 125 12 AA 123 A CC 126 9 AA 123 A BB 127 18 AA 123 A AA 123 6 BB 234 B AA 124 20 BB 234 B BB 125 12 BB 234 B CC 126 9 BB 234 B BB 127 18 BB 234 B AA 123 6 CC 345 C AA 124 20 CC 345 C BB 125 12 CC 345 C CC 126 9 CC 345 C BB 127 18 CC 345 C AA TableC CID CN CA CAdd 123 AA 6 123 A 124 BB 20 234 B 125 CC 12 345 C 126 BB 9 234 B
  • 35. RDBMS Basics ADDITIONAL RDBMS Operators:  UNION (NOT always available)  May use single single table  E.G., Creating a phone directory from 2 separate tables  There are no common values so a join can not be performed  Separate queries will produce separate tables  Duplicate records NOT displayed  Combines the results of two unrelated queries into a single output
  • 36. RDBMS Basics ADDITIONAL RDBMS Operators:  INTERSECT (NOT always available)  Similar to UNION (Combines the results of two unrelated queries into a single output)  There MUST be matching rows in the tables  E.G., Creating a phone directory of Faculty with offices in BUS who also teach in the Business Bldg.  Some Faculty Have offices in BUS  Some Faculty Teach in the Business Building  Merge those who do both into one listing
  • 37. RDBMS Basics ADDITIONAL RDBMS Operators:  DIFFERENCE (NOT always available)  Yields all rows in one table NOT found in the other  Produces list of all possible pairings  PRODUCT (Seen Earlier)  DIVIDE
  • 38. RDBMS Basics RDBMS Software Classifications  Fully Relational  Supports all relational algebra functions  Enforces Entity and Referential Integrity Rules  Relationally Complete  Supports all relational algebra functions  Does NOT support Integrity Rules  Minimally Relational  Supports only SELECT, PROJECT, and JOIN  Tabular  Supports only SELECT, PROJECT, and JOIN  User MUST define all access paths