1 / 10

Introduction to Relations

Introduction to Relations. Relational Model : Topic #1. Why Study the Relational Model?. Data Model : Math abstraction + operations Most widely used data model. IBM, Informix, Microsoft, Oracle, Sybase, And it’s really simple, yet powerful. Relational Database: Definitions.

denise-conway
Download Presentation

Introduction to Relations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to Relations Relational Model : Topic #1

  2. Why Study the Relational Model? • Data Model : Math abstraction + operations • Most widely used data model. • IBM, Informix, Microsoft, Oracle, Sybase, • And it’s really simple, yet powerful

  3. Relational Database: Definitions • Relational database:a set of relations. • Relation: made up of 2 parts: • Schema :specifiesname of relation, plus name and type of each column. (meta-information) • E.g. Students(sid: string, name: string, login: string, age: integer, gpa: real) • Instance : a table, with rows and columns. #rows = cardinality, #fields = degree / arity • A relation instance is a setof rows or tuples. (i.e., all rows are distinct)

  4. Example Instance of Students Relation • Cardinality = 3, degree = 5 , all rows distinct • Do all column values in a relation instance have to • be distinct?

  5. Integrity Constraints (ICs) • IC: condition that must be true for any instance of the database. • ICs are specified when schema is defined (by whom?) • ICs are checked when relations are modified • A legalinstance of a database is one that satisfies all ICs. • DBMS should not allow illegal instances. • If the DBMS checks ICs, stored data is more faithful to real-world meaning. • avoids data entry errors, too!

  6. Primary Key for a Relation • A set of fields is a keyif : 1. no two tuples can have same values in all key fields, and 2. this is not true for any subset of the key • Part 2 false? A superkey. • If there’s >1 key for a relation, one of the keys is chosen (by DBA) to be the primary key. • E.g., sid is a key for Students. (What about name?) The set {sid, gpa} is a superkey.

  7. Foreign Keys, Referential Integrity • Foreign key : set of fields in one relation that is used to `refer’ to a tuple in another relation. (Must correspond to primary key of the second relation.) • E.g. sid is a foreign key referring to Students: • Enrolled(sid: string, cid: string, grade: string) • All foreign key constraints are enforced? referential integrity, i.e., no dangling references. • Name a data model w/o referential integrity!

  8. Where do ICs Come From? • Based on semantics of the real-world enterprise • Can check a database instance to see if an IC is violated, but can NEVER infer an IC by looking at an instance: • IC is a statement about all possible instances! • From example: name is not a key, but DBA says that sid is a key. • Key and foreign key ICs are the most common; more general ICs supported too.

  9. Formal Relational Query Languages Two mathematical Query Languages form the basis for “real” languages (e.g. SQL), and for implementation: • Relational Algebra: More operational, very useful for representing execution plans. • Relational Calculus: Lets users describe what they want, rather than how to compute it. (Non-operational, declarative.) Understanding Algebra & Calculus is key to understanding SQL, query processing!

  10. Relational Query Languages • Query languages: allow manipulation and retrieval of data from a database. • Relational model supports simple, powerful query languages • strong formal foundation based on logic • allows for much optimization • Query Languages != programming languages! • query languages not “Turing complete” • QL’s not intended to be used for complex calculations • QL’s convenient for accessing large data sets (unlike PL’s!)

More Related