1. 1 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Week 3 September 12 Three-Level ArchitectureThree-Level Architecture Database Management System (DBMS)Database Management System (DBMS) Relational Data ModelRelational Data Model ViewsViews

2. 2 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Privacy and Confidentiality SSN: 123 45 6789 Customer: John K Smith Address: 1234 Main Street Dallas, TX 68213 Account: 5432 1234 4567 8901 Credit limit: 20,000 Current balance: 9,123.00 Employer: Enron Corp. Monthly income: 100,000.00

3. 3 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Schema and Subschemas SchemaSchema DBMS Software Individual Views Complete catalog of all data retained in the database Manages the database Physical Database SubschemaSubschemaSubschemaSubschemaSubschemaSubschema UserUserUserUserUserUserUserUserUserUserUserUser

4. 4 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Environment Three Level Architecture External Level Conceptual Level Internal Level Internal Schema Physical data organization User’s view of the database Community view Physical representation Physical storage Conceptual Schema

5. 5 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Independence Each user should be able to access the same data, but have a different customized view of the dataEach user should be able to access the same data, but have a different customized view of the data Users should not have to deal directly with physical database storage detailsUsers should not have to deal directly with physical database storage details The DBA should be able to change the database storage structures without affecting the users’ viewsThe DBA should be able to change the database storage structures without affecting the users’ views The internal structure of the database should be unaffected by changes to the physical aspects of storageThe internal structure of the database should be unaffected by changes to the physical aspects of storage The DBA should be able to change the conceptual or global structure of the database without affecting all usersThe DBA should be able to change the conceptual or global structure of the database without affecting all users

6. 6 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Three-Level Architecture External Level Describes that part of the database that is relevant to a particular userExternal Level Describes that part of the database that is relevant to a particular user Conceptual Level Describes what data is stored in the database and relationships among the dataConceptual Level Describes what data is stored in the database and relationships among the data Internal Level Describes how the data is stored in the databaseInternal Level Describes how the data is stored in the database

7. 7 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Environment Three Level Architecture Conceptual Schema Internal Schema Conceptual/internal mapping SubschemaSubschemaSubschema External Conceptual Internal Logical data independence Physical data independence External/conceptual mapping

8. 8 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Environment Three Level Architecture Conceptual Schema Internal Schema Conceptual/interna l mapping External Conceptual Internal Logical data independence Physical data independence External/conceptual mapping SubschemaSubschemaSubschema

9. 9 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Environment Three Level Architecture Conceptual Schema Internal Schema Conceptual/internal mapping External Conceptual Internal External/conceptual mapping SubschemaSubschemaSubschema Logical data independence Physical data independence

10. 10 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Data Independence Logical data independence Immunity of external schemas to changes in the conceptual schemaLogical data independence Immunity of external schemas to changes in the conceptual schema Physical data independence Immunity of the conceptual schema to changes in the internal schemaPhysical data independence Immunity of the conceptual schema to changes in the internal schema “Plug and Play!”

11. 11 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Environment SchemaSchema DBMS Software Individual Views Complete catalog of all data retained in the database Manages the database Physical Database SubschemaSubschemaSubschemaSubschemaSubschemaSubschema UserUserUserUserUserUserUserUserUserUserUserUser Shared and Managed

12. 12 R. Ching, Ph.D. MIS Dept. California State University, Sacramento File-Based Systems SchemaSchema DBMS Software SubschemaSubschemaSubschemaSubschemaSubschemaSubschema UserUserUserUserUserUserUserUserUserUserUserUser FileFile FileFile Each user has his/her file FileFile Everyone has access to all data in the file FileFile Integrity Problems

13. 13 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Languages: DDL vs. DML Data definition language (DDL) Used to describe name the entities required for the application and the relationships that may exist between the different entitiesData definition language (DDL) Used to describe name the entities required for the application and the relationships that may exist between the different entities –Specify or modify the database schema and subschemas Data manipulation language (DML) Provides a set of operations that support the basic data manipulation operations the dataData manipulation language (DML) Provides a set of operations that support the basic data manipulation operations the data –Read and update (i.e., insert, update, delete) the database

14. 14 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Models Represents the real thingRepresents the real thing Identifies the components and their interactionsIdentifies the components and their interactions Specifies the behaviorSpecifies the behavior For example...

15. 15 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Data Models An integrated collection of concepts for describing and manipulating data, relationships between data and constraints on the data in an organizationAn integrated collection of concepts for describing and manipulating data, relationships between data and constraints on the data in an organization Three components:Three components: –Structural part - set of rules applied to the construction of the database –Manipulative part - defines the types of operations allowed on the data –Integrity rules - ensures the accuracy of the data

16. 16 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Data Models Object-basedObject-based –Entity-relationship –Semantic –Functional –Object-oriented Record-based (transactions)Record-based (transactions) –Relational –Network –Hierarchical PhysicalPhysical –Unifying –Frame memory How data are stored Transaction-based Knowledge-based Object-relational

17. 17 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Record-Based Data Models Relational (Oracle, DB2, Sybase, Informix, SQL 7, Ingres, etc.)Relational (Oracle, DB2, Sybase, Informix, SQL 7, Ingres, etc.) –Based on concepts of mathematical relations –Tables, rows, columns Network (CODASYL - COnference on DAta SYstem Languages) (Image)Network (CODASYL - COnference on DAta SYstem Languages) (Image) –Many-to-many relationships –Record types, data items Hierarchical (IMS)Hierarchical (IMS) –Segment types, fields In COBOL: files, records, fields

18. 18 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database DBMS Management Queries Application Programs Other Software Physical Database Manages the database

19. 19 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Functions of a DBMS Data storage, retrieval and updateData storage, retrieval and update User-accessible catalogUser-accessible catalog Transaction supportTransaction support Concurrency control servicesConcurrency control services Recovery servicesRecovery services Authorization servicesAuthorization services Support for data communicationsSupport for data communications Integrity servicesIntegrity services Services to promote data independenceServices to promote data independence Utility servicesUtility services

20. 20 R. Ching, Ph.D. MIS Dept. California State University, Sacramento DBMS Program Object Code Database Manager Dictionary Manager ProgrammersUsersDBA DML Processor Query Processor DDL Processor ApplicationProgramsApplicationProgramsQueriesQueriesDatabaseSchemaDatabaseSchema Access Methods File Manager System Buffers DBMS Operating System

21. 21 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Manager Authorization Control Integrity Checker Command Processor Query Optimizer Transaction Manager Scheduler Buffer Manager Recovery Manager Data Manager Checks user authorization Checks integrity constraints Processes query Determines optimal strategy

22. 22 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Manager Authorization Control Integrity Checker Command Processor Query Optimizer Transaction Manager Scheduler Buffer Manager Recovery Manager Transfers data between primary and secondary storage Performs command operation Ensures recovery in case of failures Manages concurrent operations

23. 23 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Database Manager Authorization Control Integrity Checker Command Processor Query Optimizer Transaction Manager Scheduler Buffer Manager Recovery Manager Transfers data between primary and secondary storage Performs command operation Ensures recovery in case of failures Manages concurrent operations Query  Transaction  Journal  Buffered  OS

24. 24 R. Ching, Ph.D. MIS Dept. California State University, Sacramento System Catalog A repository of information describing the data in the database (metadata)A repository of information describing the data in the database (metadata) StoresStores –Names of users authorized to access the DBMS –Names of all data items in the database Types and sizesTypes and sizes ConstraintsConstraints –Data items and authorization level granted to each user Active vs. PassiveActive vs. Passive Integrated vs. StandaloneIntegrated vs. Standalone

25. 25 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Relational Data Model

26. 26 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Criteria Relational Model ObjectivesObjectives –A degree of data independence –Address data semantic, consistency and redundancy problems –Set-oriented data manipulation language Structured Query Language (SQL)Structured Query Language (SQL) Data Set Presen- tation method Database Information

27. 27 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Data Set Presen- tation method Information Data Set Information Information Database Criteria Criteria Criteria Presen- tation method Presen-

28. 28 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Tuples (rows) Cardinalitiy = number of tuplesCardinalitiy = number of tuples Relation Attributes (columns) Degree of a relation = number of attributes Degree of a relation = number of attributes Attribute-1Attribute-2Attribute-n Entity Domain = all values an attribute can assume

29. 29 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Domain of an Attribute Set of allowable values for one or more attributesSet of allowable values for one or more attributes Domain Domain UnionorIntersection Information Attribute 1 Attribute 2

30. 30 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Properties of Relations Distinct (i.e., unique) relation nameDistinct (i.e., unique) relation name Each cell contains exactly one atomic (single) valueEach cell contains exactly one atomic (single) value –No repeating groups Distinct attribute nameDistinct attribute name The values of an attribute come from the same domainThe values of an attribute come from the same domain Order of attributes has no significanceOrder of attributes has no significance Each tuple is distinct (i.e., unique)Each tuple is distinct (i.e., unique) –No duplicate tuples Order of tuples has no significanceOrder of tuples has no significance

31. 31 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Unique Identification of a Relation Relation key Superkey Candidate key Primary key Foreign key ?

32. 32 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Identifying a Tuple Superkey An attribute or a set of attributes that uniquely identifies a tuple within a relationSuperkey An attribute or a set of attributes that uniquely identifies a tuple within a relation Candidate key A super key such that no proper subset is a superkey within the relationCandidate key A super key such that no proper subset is a superkey within the relation –Uniquely identifies the tuple (uniqueness) –Contains no unique subset (irreducibility) Primary key The candidate key that is selected to identify tuples uniquely within a relationPrimary key The candidate key that is selected to identify tuples uniquely within a relation –Should remain constant over the life of the tuple –Most efficient way of identifying a tuple

33. 33 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Finding the Primary Key Super Key Candidate Key Primary key

34. 34 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Keys Attributes Catalog numberCatalog number Record titleRecord title Artist nameArtist name Record labelRecord label UPCUPC CDs Relation 129341 129342 129343 129344 Help! Hard Day’s Night Sergeant Pepper’s Magical Mystery Tour Beatles Beatles Beatles Beatles Columbia Columbia Columbia Columbia 129345 Abbey Road BeatlesApple 1-29150-8384-0 1-29150-7115-0 1-29150-2484-0 1-29150-7515-0 1-15700-9510-0 Superkey? Candidate key? Primary key?

35. 35 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Selecting a Key CriteriaCriteria –An efficient way of identifying an entity –The attribute (value) remains constant over the life of the entity Never changesNever changes

36. 36 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Identifying a Tuple Foreign key An attribute or set of attributes within one relation that matches the candidate key of some (possibly the same) relationForeign key An attribute or set of attributes within one relation that matches the candidate key of some (possibly the same) relation Relation key key Relation foreign key

37. 37 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Foreign Key CDs Relation 129341 129342 129343 129344 Help! Hard Day’s Night Sergeant Pepper’s Magical Mystery Tour Beatles Beatles Beatles Beatles COL COL COL COL 129345 Abbey Road BeatlesAPP 1-29150-8384-0 1-29150-7115-0 1-29150-2484-0 1-29150-7515-0 1-15700-9510-0 COL APP Columbia Records Apple Records Recording Label Relation (home relation) Must match!

38. 38 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Relational Integrity Constraints placed on the set of values allowed for the attributes of a relation. Entity integrity Entity integrity –No attribute of a primary key can be null (every tuple must be uniquely identified) Referential integrity Referential integrity –If a foreign key exists in a relation, either the foreign key value must match a candidate key value of some tuple in its home relation, or the foreign key value must be wholly null (i.e., no key exists in the home relation) Enterprise constraints (organizational) Enterprise constraints (organizational)

39. 39 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Null Value Absence of any value (i.e., unknown or nonapplicable to a tuple)Absence of any value (i.e., unknown or nonapplicable to a tuple)

40. 40 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Views A view is a virtual relation or one that does not actually exist, but dynamically derivedA view is a virtual relation or one that does not actually exist, but dynamically derived –Can be constructed by performing operations (i.e., select, project, join, etc.) on values of existing base relations Base relation - a named relation, corresponding to an entity in the conceptual schema, whose tuples are physically stored in the databaseBase relation - a named relation, corresponding to an entity in the conceptual schema, whose tuples are physically stored in the database View - a dynamic result of one or more relational operations operating on the base relations to produce anotherView - a dynamic result of one or more relational operations operating on the base relations to produce another

41. 41 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Schema and Subschemas DBMS Schema Conceptual Level External Level Internal Level Physical Database DBMS Software User Subschema Some end-user applications can be supported by views Subschema

42. 42 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Views Key Foreign Key Key Criterion Base Relation R Base Relation S View

43. 43 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Purpose of Views Provides a powerful and flexible security mechanism by hiding parts of the database from certain usersProvides a powerful and flexible security mechanism by hiding parts of the database from certain users Permits user access in a way that is customized to their needsPermits user access in a way that is customized to their needs Simplify complex operations on the base relationsSimplify complex operations on the base relations Designed to support the external modelDesigned to support the external model Provides logical independenceProvides logical independence

44. 44 R. Ching, Ph.D. MIS Dept. California State University, Sacramento Updating Views Allowed on viewsAllowed on views –Derived from a single base relation, and –Containing the primary key or a candidate key NOT allowed on viewsNOT allowed on views –Derived from multiple base relations –Involving aggregations (i.e., summations) or groups operations Vendors may have other constraints on updating viewsVendors may have other constraints on updating views

45. 45 R. Ching, Ph.D. MIS Dept. California State University, Sacramento