Outline  Introduction  Background  Distributed DBMS Architecture  Distributed Database Design  Semantic Data Control ➠ View Management ➠ Data Security.

Slides:



Advertisements
Similar presentations
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Advertisements

Relational Model dww-database system.
1 Constraints, Triggers and Active Databases Chapter 9.
Distributed DBMSPage 6. 1© 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database Design.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Distributed DBMS© M. T. Özsu & P. Valduriez Ch.6/1 Outline Introduction Background Distributed Database Design Database Integration Semantic Data Control.
Distributed DBMS © M. T. Özsu & P. Valduriez Ch.7/1 Outline Introduction Background Distributed Database Design Database Integration Semantic Data Control.
Relational Model The main reference of this presentation is the textbook and PPT from : Elmasri & Navathe, Fundamental of Database Systems, 4 th edition,
Relational Model Indra Budi Fakultas Ilmu Komputer UI 2 Essentials of Relational Approach The Relational Model of Data is Based on.
Relational Algebra Indra Budi Fakultas Ilmu Komputer UI 2 n Basic Relational Operations: l Unary Operations  SELECT   PROJECT 
Auditing Computer-Based Information Systems
SQL Constraints and Triggers
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification.
Distributed Database Design & Semantic Data Control
1 File Processing n Data are stored in files with interface between programs and files. n Various access methods exist (e.g., Sequential, indexed, random)
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Basic (Flat) Relational Model.
Introduction to Structured Query Language (SQL)
Chapter 3 An Introduction to Relational Databases.
1 Relational Model. 2 Relational Database: Definitions  Relational database: a set of relations  Relation: made up of 2 parts: – Instance : a table,
Security in Databases. 2 Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security.
Distributed DBMS© 2001 M. Tamer Özsu & Patrick Valduriez Page 1.1 Outline  Introduction à What is a distributed DBMS à Problems à Current state-of-affairs.
Database Systems More SQL Database Design -- More SQL1.
Introduction to Structured Query Language (SQL)
Functions of a Database Management System. Functions of a DBMS C.J. Date n Indexing n Views n Security n Integrity n Concurrency n Backup/Recovery n Design.
10/3/2000SIMS 257: Database Management -- Ray Larson Relational Algebra and Calculus University of California, Berkeley School of Information Management.
CMPT 354, Simon Fraser University, Fall 2008, Martin Ester 157 Database Systems I SQL Constraints and Triggers.
Distributed Databases
Distributed DBMS © M. T. Özsu & P. Valduriez Ch.7/1 Outline Introduction Background Distributed Database Design Database Integration Semantic Data Control.
Query Processing Presented by Aung S. Win.
Chapter 6: Integrity and Security Thomas Nikl 19 October, 2004 CS157B.
Context Tailoring the DBMS –To support particular applications Beyond alphanumerical data Beyond retrieve + process –To support particular hardware New.
CSE314 Database Systems More SQL: Complex Queries, Triggers, Views, and Schema Modification Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
CODD’s 12 RULES OF RELATIONAL DATABASE
Chapter 16 Methodology – Physical Database Design for Relational Databases.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
Relational Model The main reference of this presentation is the textbook and PPT from : Elmasri & Navathe, Fundamental of Database Systems, 4 th edition,
DATABASE MGMT SYSTEM (BCS 1423) Chapter 5: Methodology – Conceptual Database Design.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
FALL 2004CENG 351 File Structures and Data Management1 Relational Model Chapter 3.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
6 1 Lecture 8: Introduction to Structured Query Language (SQL) J. S. Chou, P.E., Ph.D.
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
IS 230Lecture 6Slide 1 Lecture 7 Advanced SQL Introduction to Database Systems IS 230 This is the instructor’s notes and student has to read the textbook.
Fall 2001Database Systems1 Triggers Assertions –Assertions describe rules that should hold for a given database. –An assertion is checked anytime a table.
Methodology – Physical Database Design for Relational Databases.
Module Coordinator Tan Szu Tak School of Information and Communication Technology, Politeknik Brunei Semester
Design Process - Where are we?
CSE314 Database Systems Lecture 3 The Relational Data Model and Relational Database Constraints Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson.
PMIT-6101 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Chapter 5 : Integrity And Security  Domain Constraints  Referential Integrity  Security  Triggers  Authorization  Authorization in SQL  Views 
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Chapter 9 Designing Databases 9.1.
CS34311 The Relational Model. cs34312 Why Relational Model? Currently the most widely used Vendors: Oracle, Microsoft, IBM Older models still used IBM’s.
Lecture 03 Constraints. Example Schema CONSTRAINTS.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
Constraints and Views Chap. 3-5 continued (7 th ed. 5-7)
Distributed DBMS© 2001 M. Tamer Özsu & Patrick Valduriez Page 1.1 Outline n Introduction Background Distributed DBMS Architecture Distributed Database.
SQL- Updates, Assertions and Views. Data Definition, Constraints, and Schema Changes Used to CREATE, DROP, and ALTER the descriptions of the tables (relations)
Chapter 3 An Introduction to Relational Databases.
CS742 – Distributed & Parallel DBMSPage 3. 1M. Tamer Özsu Outline Introduction & architectural issues Data distribution  Distributed query processing.
More SQL: Complex Queries, Triggers, Views, and Schema Modification
Outline Background Introduction Distributed DBMS Architecture
Functions of a Database Management System
DATA ACCESS CONTROL, MANAGEMENT DATA AND SECURITY (CIB125) PERTEMUAN 6
ER Modeling Exercise Consider a set of courses, both at grad and undergrad level. Each course has at least one section. Each section is taught by only.
Outline Introduction Background Distributed DBMS Architecture
Advanced SQL: Views & Triggers
Outline Introduction Background Distributed DBMS Architecture
Presentation transcript:

Outline  Introduction  Background  Distributed DBMS Architecture  Distributed Database Design  Semantic Data Control ➠ View Management ➠ Data Security ➠ Semantic Integrity Control  Distributed Query Processing  Distributed Transaction Management  Distributed Database Operating Systems  Parallel Database Systems  Distributed Object DBMS  Database Interoperability  Current Issues

Semantic Data Control  Involves: ➠ View management ➠ Security control ➠ Integrity control  Objective : ➠ Insure that authorized users perform correct operations on the database, contributing to the maintenance of the database integrity.

View Management View – virtual relation ➠ generated from base relation(s) by a query ➠ not stored as base relations Example : CREATE VIEW SYSAN(ENO,ENAME) AS SELECT ENO, ENAME FROM EMP WHERE TITLE=“Syst. Anal.” ENOENAMETITLE EI J. DoeElect. Eng E2M. SmithSyst. Anal. E3A. LeeMech. Eng. E4J. MillerProgrammer E5B. CaseySyst. Anal. E6L. ChuElect. Eng. E7R. DavisMech. Eng. E8J. JonesSyst. Anal. EMP ENOENAME E2M. Smith E5B. Casey E8J. Jones SYSAN

View Management Views can be manipulated as base relations Example : SELECT ENAME, PNO, RESP FROM SYSAN, ASG WHERE SYSAN.ENO = ASG.ENO

Query Modification ENAMEPNORESP M. SmithP1Analyst M. SmithP2Analyst B. CaseyP3Manager J. JonesP4Manager queries expressed on views queries expressed on base relations Example : SELECT ENAME, PNO, RESP FROM SYSAN, ASG WHERE SYSN.ENO = ASG.ENO SELECT ENAME, PNO, RESP FROM EMP, ASG WHERE EMP.ENO = ASG.ENO AND TITLE = “Syst. Anal.”

View Management  To restrict access CREATE VIEW ESAME AS SELECT * FROM EMP E1, EMP E2 WHERE E1.TITLE = E2.TITLE AND E1.ENO = USER  Query SELECT * FROM ESAME

Updatable CREATE VIEW SYSAN(ENO,ENAME) AS SELECT ENO,ENAME FROM EMP WHERE TITLE=“Syst. Anal.” Non-updatable CREATE VIEW EG(ENAME,RESP) AS SELECT ENAME,RESP FROM EMP, ASG WHERE EMP.ENO=ASG.ENO View Updates

View Management in DDBMS  Views might be derived from fragments.  View definition storage should be treated as database storage  Query modification results in a distributed query  View evaluations might be costly if base relations are distributed ➠ use snapshots Static views - do not reflect the updates to the base relations managed as temporary relations - only access path is sequential scan bad selectivity - snapshots behave as pre-calculated answers periodic recalculation

Data Security Data protection ➠ prevent the physical content of data to be understood by unauthorized users ➠ encryption/decryption Data Encryption Standard Public-key encryption Authorization control ➠ only authorized users perform operations they are allowed to on the database identification of subjects and objects authentication of subjects granting of rights (authorization matrix)

Semantic Integrity Control  Maintain database consistency by enforcing a set of constraints defined on the database.  Structural constraints ➠ basic semantic properties inherent to a data model e.g., unique key constraint in relational model  Behavioral constraints ➠ regulate application behavior e.g., dependencies in the relational model  Two components ➠ Integrity constraint specification ➠ Integrity constraint enforcement

Semantic Integrity Control  Procedural ➠ control embedded in each application program  Declarative ➠ assertions in predicate calculus ➠ easy to define constraints ➠ definition of database consistency clear ➠ inefficient to check assertions for each update a) limit the search space b)decrease the number of data accesses/assertion c)preventive strategies d)checking at compile time

Constraint Specification Language Predefined constraints specify the more common constraints of the relational model ➠ Not-null attribute ENO NOT NULL IN EMP ➠ Unique key (ENO, PNO) UNIQUE IN ASG ➠ Foreign key A key in a relation R is a foreign key if it is a primary key of another relation S and the existence of any of its values in R is dependent upon the existence of the same value in S PNO IN ASG REFERENCES PNO IN PROJ ➠ Functional dependency ENO IN EMP DETERMINES ENAME

Constraint Specification Language Precompiled constraints Express preconditions that must be satisfied by all tuples in a relation for a given update type (INSERT, DELETE, MODIFY) NEW - ranges over new tuples to be inserted OLD - ranges over old tuples to be deleted General Form CHECK ON [WHEN ]

Precompiled constraints ➠ Domain constraint CHECK ON PROJ(BUDGET≥ AND BUDGET≤ ) ➠ Domain constraint on deletion CHECK ON PROJ WHEN DELETE (BUDGET = 0) ➠ Transition constraint CHECK ON PROJ (NEW.BUDGET > OLD.BUDGET AND NEW.PNO = OLD.PNO ) Constraint Specification Language

General constraints Constraints that must always be true. Formulae of tuple relational calculus where all variables are quantified. General Form CHECK ON :,( ) ➠ Functional dependency CHECK ON e1:EMP, e2:EMP (e1.ENAME = e2.ENAME IF e1.ENO = e2.ENO) ➠ Constraint with aggregate function CHECK ON g:ASG, j:PROJ (SUM(g.DUR WHERE g.PNO = j.PNO) < 100 IF j.PNAME = “CAD/CAM”) Constraint Specification Language

Integrity Enforcement Two methods Detection Execute update u: D → D u If Du is inconsistent then compensate D u → D u ’ else undo D u → D Preventive Execute u: D → D u only if Du will be consistent ➠ Determine valid programs ➠ Determine valid states

Query Modification  Preventive  Add the assertion qualification to the update query  Only applicable to tuple calculus formulae with universally quantified variables UPDATE PROJ SET BUDGET = BUDGET*1.1 WHERE PNAME =“CAD/CAM” UPDATE PROJ SET BUDGET = BUDGET*1.1 WHERE PNAME =“CAD/CAM” AND NEW.BUDGET ≥ AND NEW.BUDGET ≤

Compiled Assertions Triple (R,T,C) where R relation T update type (insert, delete, modify) C assertion on differential relations Example: Foreign key assertion ∀ g ∈ ASG, ∃ j ∈ PROJ : g.PNO = j.PNO Compiled assertions: (ASG, INSERT, C1), (PROJ, DELETE, C2), (PROJ, MODIFY, C3) where C1: ∀ NEW ∈ ASG+, ∃ j ∈ PROJ: NEW.PNO = j.PNO C2: ∀ g ∈ ASG, ∀ OLD ∈ PROJ- : g.PNO ≠ OLD.PNO C3: ∀ g ∈ ASG, ∀ OLD ∈ =PROJ-, ∃ NEW ∈ PROJ+:g.PNO ≠OLD.PNO OR OLD.PNO = NEW.PNO

Differential Relations Given relation R and update u R+ contains tuples inserted by u R- contains tuples deleted by u Type of u insert R- empty delete R+ empty modify R+ ∪ (R – R- )

Differential Relations Algorithm Input: Relation R, update u, compiled assertion C i Step 1: Generate differential relations R+ and R– Step 2: Retrieve the tuples of R+ and R– which do not satisfy C i Step 3: If retrieval is not successful, then the assertion is valid. Example : u is delete on J. Enforcing (J, DELETE, C2) : retrieve all tuples of J- Into RESULT where not(C2) If RESULT = φ, the assertion is verified.

Distributed Integrity Control Problems: ➠ Definition of constraints consideration for fragments ➠ Where to store replication non-replicated : fragments ➠ Enforcement minimize costs

Types of Distributed Assertions  Individual assertions ➠ single relation, single variable ➠ domain constraint  Set oriented assertions ➠ single relation, multi-variable functional dependency ➠ multi-relation, multi-variable foreign key  Assertions involving aggregates

Distributed Integrity Control Assertion Definition ➠ similar to the centralized techniques ➠ transform the assertions to compiled assertions Assertion Storage ➠ Individual assertions one relation, only fragments at each fragment site, check for compatibility if compatible, store; otherwise reject if all the sites reject, globally reject ➠ Set-oriented assertions involves joins (between fragments or relations) maybe necessary to perform joins to check for compatibility store if compatible

Distributed Integrity Control Assertion Enforcement ➠ Where do you enforce each assertion? type of assertion type of update and where update is issued ➠ Individual Assertions update = insert ✔ enforce at the site where the update is issued update = qualified ✔ send the assertions to all the sites involved ✔ execute the qualification to obtain R+ and R- ✔ each site enforce its own assertion ➠ Set-oriented Assertions single relation ✔ similar to individual assertions with qualified updates multi-relation ✔ move data between sites to perform joins; then send the result to the query master site