1 / 7

Relational DBs

Relational DBs. Basics. Formally understood. Set theoretic Originally defined with an algebra, with Selection, Projection, Join, and Union/Difference/Intersection Declarative calculus that is based on the algebra and supports large grained queries Clean implementation spec

chaney
Download Presentation

Relational DBs

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. Relational DBs • Basics

  2. Formally understood • Set theoretic • Originally defined with an algebra, with Selection, Projection, Join, and Union/Difference/Intersection • Declarative calculus that is based on the algebra and supports large grained queries • Clean implementation spec • Unambiguous optimization - with its own algebra of query parse tree transformations

  3. Structure • Schema based - we can leverage this to address volume • Tables, rows, columns, domains • Keys (PK and CK) • FKs • Triggers as a catch-all integrity constraint • Normalization for formal table minimization

  4. Semantics are in queries • Relational algebra compliant • Queries written in declarative calculus • Set-oriented • Programmers tend to follow PK/FK pairs • Query results are legal tables (Views)

  5. Also we get • Fixed size tuples for easy row-optimization • 2P transactions • Table, Row distribution • Two language based, with lowest common denominator semantics • Security • Checkpointing • Powerful query optimizers

  6. Object-relational DBs • This runs somewhat counter to NoSQL trends - we make the data types even more complex • We make domains out of type constructors • Object IDs • A row can be a tuple - or an object, with an object ID and a tuple, making all relational DBs also O-R

  7. Object-oriented DBs • No tuple rows • Blend SQL and the app language • This avoids lowest common denominator semantics • These bombed, as relational DBs were not O-O • And they are tough to optimize

More Related