cse 510 web data engineering
play

CSE 510 Web Data Engineering Database Design UB CSE 510 Web Data - PowerPoint PPT Presentation

CSE 510 Web Data Engineering Database Design UB CSE 510 Web Data Engineering How to Design a Database and Avoid Bad Decisions With experience Learn in CSE462 normalization rules of database design Think entities and


  1. CSE 510 Web Data Engineering Database Design UB CSE 510 Web Data Engineering

  2. How to Design a Database and Avoid Bad Decisions • With experience… • Learn in CSE462 normalization rules of database design • Think entities and relationships – translate to relations 2 UB CSE 510 Web Data Engineering

  3. E/R-Based Design Attribute DateCode FirstName Number StartTime UBID LastName Name EndTime Classes Students Enrollment Entity Relationship Credits 3 UB CSE 510 Web Data Engineering

  4. E/R  Relational Schema: Basic Translation • For every entity, create corresponding table – Include an ID attribute even if not in E/R • For every relationship, create table – For each referenced entity E i include foreign key attribute referencing ID of E i 4 UB CSE 510 Web Data Engineering

  5. Example Name Address Year StarsIn Stars Title Length Movies Name Address Owns Studios 5 UB CSE 510 Web Data Engineering

  6. 3-Way Relationship Name Address Year Stars Title Length Movies Contract Name Address Studios Fee • A studio has contracted with a particular star to act in a particular movie 6 UB CSE 510 Web Data Engineering

  7. Relationships with Roles Year Title Length Original Movies SequelOf Sequel 7 UB CSE 510 Web Data Engineering

  8. “Subclassing” Year Title Length Movies StarsIn Name Address Stars IsA Cartoons Voices … 8 UB CSE 510 Web Data Engineering

  9. Transaction Management • Transaction: Collection of actions that maintain the consistency of the database if ran to completion & isolated • Goal: Guarantee integrity and consistency of data despite – Concurrency – Failures • Concurrency Control • Recovery 9 UB CSE 510 Web Data Engineering

  10. Concurrency & Failure Problems • Consider the “John & Mary” checking & savings account – C: checking account balance C2S(X=100) Read(C) – S: savings account balance C:=C-100 • Check-to-Savings transfer Write(C) transaction moves $X from Read(S) C to S S:=S+100 Write(S) – If it runs in the system alone and to completion, the total sum of C and S stays the same 10 UB CSE 510 Web Data Engineering

  11. Failure Problem & Recovery Module’s Goal • Database is in inconsistent state after machine restarts C2S(X=100) • It is not the developer’s Read(C) problem to account for C:=C-100 crashes Write(C) • Recovery module guarantees that all or none of a CPU Halts transaction happens and its Read(S) effects become “durable” S:=S+100 Write(S) 11 UB CSE 510 Web Data Engineering

  12. Concurrency Problem & Concurrency Control Module’s Goals • If multiple Serial Schedule transactions run in Read(C) sequence, the C:=C+100 resulting database is Write(C) consistent Read(S) S:=S-100 • Serial schedules Write(S) – De facto correct Read(C) C:=C+50 Write(C) Read(S) S:=S-50 Write(S) 12 UB CSE 510 Web Data Engineering

  13. Concurrency Problem & Concurrency Control Module’s Goals Good Schedule • Databases allow with Concurrency transactions to run in Read(C) parallel C:=C+100 Write(C) Read(C) C:=C+50 Write(C) Read(S) S:=S-100 Write(S) Read(S) S:=S-50 Write(S) 13 UB CSE 510 Web Data Engineering

  14. Concurrency Problem & Concurrency Control Module’s Goals Bad Schedule • “Bad” interleaved with Concurrency schedules may leave Read(C) database in C:=C+100 inconsistent state Read(C) • Developer should not Write(C) have to account for C:=C+50 parallelism Write(C) • Concurrency control Read(S) module guarantees S:=S-50 serializability Write(S) – only schedules Read(S) equivalent to serial ones S:=S-100 happen Write(S) 14 UB CSE 510 Web Data Engineering

Recommend


More recommend