1 r. ching, ph.d. mis dept. california state university, sacramento week 3 september 12 three-level...
TRANSCRIPT
1
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Week 3Week 3September 12September 12
• Three-Level ArchitectureThree-Level Architecture• Database Management System (DBMS)Database Management System (DBMS)
• Relational Data ModelRelational Data Model• ViewsViews
2
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Privacy and ConfidentialityPrivacy and Confidentiality
SSN: 123 45 6789Customer: John K SmithAddress: 1234 Main Street
Dallas, TX 68213
Account: 5432 1234 4567 8901 Credit limit: 20,000Current balance: 9,123.00Employer: Enron Corp.Monthly income: 100,000.00
3
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Schema and SubschemasSchema and Subschemas
SchemaSchemaSchemaSchema
DBMS SoftwareDBMS SoftwareDBMS SoftwareDBMS Software
Individual Individual ViewsViews
Complete catalog of all data Complete catalog of all data retained in the databaseretained in the database
Manages the databaseManages the database
Physical DatabasePhysical Database
SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema
UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser
4
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database EnvironmentDatabase EnvironmentThree Level ArchitectureThree Level Architecture
External External LevelLevel
Conceptual LevelConceptual Level
Internal LevelInternal Level Internal SchemaInternal SchemaInternal SchemaInternal Schema
Physical data Physical data organizationorganization
User’s view of the databaseUser’s view of the database
Community Community viewview
Physical Physical representationrepresentation
Physical storagePhysical storage
Conceptual SchemaConceptual SchemaConceptual SchemaConceptual Schema
5
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
IndependenceIndependence
• Each user should be able to access the same data, but have Each user should be able to access the same data, but have a different customized view of the dataa different customized view of the data
• Users should not have to deal directly with physical Users should not have to deal directly with physical database storage detailsdatabase storage details
• The DBA should be able to change the database storage The DBA should be able to change the database storage structures without affecting the users’ viewsstructures without affecting the users’ views
• The internal structure of the database should be unaffected The internal structure of the database should be unaffected by changes to the physical aspects of storageby changes to the physical aspects of storage
• The DBA should be able to change the conceptual or The DBA should be able to change the conceptual or global structure of the database without affecting all usersglobal structure of the database without affecting all users
6
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Three-Level ArchitectureThree-Level Architecture
• External LevelExternal LevelDescribes that part of the database that is relevant to a Describes that part of the database that is relevant to a particular userparticular user
• Conceptual LevelConceptual LevelDescribes Describes whatwhat data is stored in the database and data is stored in the database and relationships among the datarelationships among the data
• Internal LevelInternal LevelDescribes Describes howhow the data is stored in the database the data is stored in the database
7
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database EnvironmentDatabase EnvironmentThree Level ArchitectureThree Level Architecture
Conceptual SchemaConceptual Schema
Internal SchemaInternal SchemaConceptual/internal Conceptual/internal
mappingmapping
SubschemaSubschema SubschemaSubschema SubschemaSubschema
Ext
erna
lE
xter
nal
Con
cept
ual
Con
cept
ual
Inte
rnal
Inte
rnal
Logical data Logical data independenceindependence
Physical data Physical data independenceindependence
External/conceptual External/conceptual mappingmapping
8
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database EnvironmentDatabase EnvironmentThree Level ArchitectureThree Level Architecture
Conceptual SchemaConceptual Schema
Internal SchemaInternal SchemaConceptual/Conceptual/
internal mappinginternal mapping
Ext
erna
lE
xter
nal
Con
cept
ual
Con
cept
ual
Inte
rnal
Inte
rnal
Logical data Logical data independenceindependence
Physical data Physical data independenceindependence
External/conceptual External/conceptual mappingmapping
SubschemaSubschema SubschemaSubschema SubschemaSubschema
9
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database EnvironmentDatabase EnvironmentThree Level ArchitectureThree Level Architecture
Conceptual SchemaConceptual Schema
Internal SchemaInternal SchemaConceptual/internal Conceptual/internal
mappingmapping
Ext
erna
lE
xter
nal
Con
cept
ual
Con
cept
ual
Inte
rnal
Inte
rnal
External/conceptual External/conceptual mappingmapping
SubschemaSubschema SubschemaSubschema SubschemaSubschema
Logical data Logical data independenceindependence
Physical data Physical data independenceindependence
10
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Data IndependenceData Independence
• Logical data independenceLogical data independenceImmunity of external schemas to changes in the conceptual Immunity of external schemas to changes in the conceptual schemaschema
• Physical data independencePhysical data independenceImmunity of the conceptual schema to changes in the Immunity of the conceptual schema to changes in the internal schemainternal schema
““Plug and Play!”Plug and Play!”
11
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database EnvironmentDatabase Environment
SchemaSchemaSchemaSchema
DBMS SoftwareDBMS SoftwareDBMS SoftwareDBMS Software
Individual Individual ViewsViews
Complete catalog of all data Complete catalog of all data retained in the databaseretained in the database
Manages the databaseManages the database
Physical DatabasePhysical Database
SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema
UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser
Shared and ManagedShared and Managed
12
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
File-Based SystemsFile-Based Systems
SchemaSchemaSchemaSchema
DBMS SoftwareDBMS SoftwareDBMS SoftwareDBMS Software
SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema SubschemaSubschemaSubschemaSubschema
UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser UserUserUserUser
FileFileFileFile FileFileFileFile
Each user has Each user has his/her filehis/her file
FileFileFileFileEveryone has access Everyone has access to all data in the fileto all data in the file
FileFileFileFileIntegrity ProblemsIntegrity ProblemsIntegrity ProblemsIntegrity Problems
13
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database Languages: DDL vs. DMLDatabase Languages: DDL vs. DML
• Data definition language (DDL)Data definition language (DDL)Used to describe name the entities required for the Used to describe name the entities required for the application and the relationships that may exist between application and the relationships that may exist between the different entitiesthe different entities
– Specify or modify the database schema and subschemasSpecify or modify the database schema and subschemas
• Data manipulation language (DML)Data manipulation language (DML)Provides a set of operations that support the basic data Provides a set of operations that support the basic data manipulation operations the datamanipulation operations the data
– Read and update (i.e., insert, update, delete) the Read and update (i.e., insert, update, delete) the databasedatabase
14
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
ModelsModels
• 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...For example...
15
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Data ModelsData Models
• An integrated collection of concepts for describing and An integrated collection of concepts for describing and manipulating data, relationships between data and manipulating data, relationships between data and constraints on the data in an organizationconstraints on the data in an organization
• Three components:Three components:
– Structural part - set of rules applied to the construction Structural part - set of rules applied to the construction of the databaseof the database
– Manipulative part - defines the types of operations Manipulative part - defines the types of operations allowed on the dataallowed on the data
– Integrity rules - ensures the accuracy of the dataIntegrity rules - ensures the accuracy of the data
16
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Data ModelsData Models
• Object-basedObject-based– Entity-relationshipEntity-relationship– SemanticSemantic– FunctionalFunctional– Object-orientedObject-oriented
• Record-based (transactions)Record-based (transactions)– RelationalRelational– NetworkNetwork– HierarchicalHierarchical
• PhysicalPhysical– UnifyingUnifying– Frame memoryFrame memory
How data are storedHow data are stored
Transaction-basedTransaction-based
Knowledge-basedKnowledge-based
Object-relationalObject-relational
17
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Record-Based Data ModelsRecord-Based Data Models
• Relational (Oracle, DB2, Sybase, Informix, SQL 7, Ingres, Relational (Oracle, DB2, Sybase, Informix, SQL 7, Ingres, etc.)etc.)– Based on concepts of mathematical relationsBased on concepts of mathematical relations– Tables, rows, columnsTables, rows, columns
• Network (CODASYL - COnference on DAta SYstem Network (CODASYL - COnference on DAta SYstem Languages) (Image)Languages) (Image)– Many-to-many Many-to-many relationshipsrelationships– Record types, data itemsRecord types, data items
• Hierarchical (IMS)Hierarchical (IMS)– Segment types, fieldsSegment types, fields
In COBOL: files, records, fieldsIn COBOL: files, records, fields
18
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
DatabaseDatabase
DBMSDBMS
Management Management QueriesQueries
Application Application ProgramsPrograms
Other Other SoftwareSoftware
Physical Physical DatabaseDatabase
Manages the databaseManages the database
19
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Functions of a DBMSFunctions of a DBMS
• Data storage, retrieval and updateData storage, retrieval and update
• User-accessible catalogUser-accessible catalog
• Transaction support Transaction support
• Concurrency control services Concurrency 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
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
DBMSDBMS
Program Object Program Object CodeCode
Database Database ManagerManager
Dictionary Dictionary ManagerManager
ProgrammersProgrammers UsersUsers DBADBA
DML ProcessorDML Processor Query ProcessorQuery Processor DDL ProcessorDDL Processor
ApplicationApplicationProgramsPrograms
ApplicationApplicationProgramsPrograms QueriesQueriesQueriesQueries DatabaseDatabase
SchemaSchemaDatabaseDatabaseSchemaSchema
Access MethodsAccess Methods File ManagerFile Manager
System BuffersSystem Buffers
DBMSDBMS
Operating Operating SystemSystem
21
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database ManagerDatabase Manager
Authorization Authorization ControlControl
Authorization Authorization ControlControl
Integrity CheckerIntegrity Checker Command Command ProcessorProcessor
Query Query OptimizerOptimizer
Transaction Transaction ManagerManager SchedulerScheduler
Buffer ManagerBuffer ManagerRecovery Recovery ManagerManager
Data ManagerData Manager
Checks user authorizationChecks user authorization
Checks integrity Checks integrity constraintsconstraints
Processes queryProcesses queryDetermines optimal strategyDetermines optimal strategy
22
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database ManagerDatabase Manager
Authorization Authorization ControlControl
Authorization Authorization ControlControl
Integrity CheckerIntegrity Checker Command Command ProcessorProcessor
Query Query OptimizerOptimizer
Transaction Transaction ManagerManager SchedulerScheduler
Buffer ManagerBuffer ManagerRecovery Recovery ManagerManager
Transfers data between Transfers data between primary and secondary primary and secondary storagestorage
Performs command Performs command operationoperation
Ensures recovery in case of failuresEnsures recovery in case of failures
Manages concurrent operationsManages concurrent operations
23
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Database ManagerDatabase Manager
Authorization Authorization ControlControl
Authorization Authorization ControlControl
Integrity CheckerIntegrity Checker Command Command ProcessorProcessor
Query Query OptimizerOptimizer
Transaction Transaction ManagerManager SchedulerScheduler
Buffer ManagerBuffer ManagerRecovery Recovery ManagerManager
Transfers data between Transfers data between primary and secondary primary and secondary storagestorage
Performs command Performs command operationoperation
Ensures recovery in case of failuresEnsures recovery in case of failures
Manages concurrent operationsManages concurrent operations
Query Query Transaction Transaction Journal Journal Buffered Buffered OS OSQuery Query Transaction Transaction Journal Journal Buffered Buffered OS OS
24
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
System CatalogSystem Catalog
• A repository of information describing the data in the A repository of information describing the data in the database (metadata)database (metadata)
• StoresStores– Names of users authorized to access the DBMSNames of users authorized to access the DBMS– Names of all data items in the databaseNames of all data items in the database
• Types and sizesTypes and sizes• ConstraintsConstraints
– Data items and authorization level granted to each userData items and authorization level granted to each user• Active vs. PassiveActive vs. Passive• Integrated vs. StandaloneIntegrated vs. Standalone
25
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Relational Data ModelRelational Data Model
26
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
CriteriaCriteria
Relational ModelRelational Model
• ObjectivesObjectives
– A degree of data independenceA degree of data independence
– Address data semantic, consistency and redundancy Address data semantic, consistency and redundancy problemsproblems
– Set-oriented data manipulation languageSet-oriented data manipulation language
• Structured Query Language (SQL)Structured Query Language (SQL)
Data SetData Set
Presen-Presen-tation tation methodmethod
DatabaseDatabase
InformationInformation
27
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Data SetData Set
Presen-Presen-tation tation methodmethod
InformationInformation
Data SetData Set
InformationInformation
Data SetData Set
InformationInformation
DatabaseDatabase
CriteriaCriteria
Crit
eria
Crit
eria
Criteria
Criteria
Presen-Presen-tation tation methodmethod
Presen-Presen-tation tation methodmethod
28
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Tuples Tuples (rows)(rows)• CardinalitiyCardinalitiy = =
number of number of tuplestuples
RelationRelation
AttributesAttributes (columns) (columns)• Degree of a relation = number of attributesDegree of a relation = number of attributes
Attrib
ute-
1
Attrib
ute-
1Attr
ibut
e-2
Attrib
ute-
2
Attrib
ute-
n
Attrib
ute-
n
EntityEntity
Domain = all values an attribute can assumeDomain = all values an attribute can assume
29
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Domain of an AttributeDomain of an Attribute
• Set of allowable values for one or more attributesSet of allowable values for one or more attributes
DomainDomain DomainDomainUnionUnion
ororIntersectionIntersection
InformationInformation
Attribute 1Attribute 1 Attribute 2Attribute 2
30
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Properties of RelationsProperties of Relations
• Distinct (i.e., unique) relation nameDistinct (i.e., unique) relation name
• Each cell contains exactly one atomic (single) value Each cell contains exactly one atomic (single) value
– No repeating groupsNo 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 tuplesNo duplicate tuples
• Order of tuples has no significanceOrder of tuples has no significance
31
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Unique Identification of a RelationUnique Identification of a Relation
RelationRelation
keykey
SuperkeySuperkey
Candidate keyCandidate key
Primary keyPrimary key
Foreign keyForeign key??
32
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Identifying a TupleIdentifying a Tuple
• SuperkeySuperkeyAn attribute or a set of attributes that uniquely identifies a tuple An attribute or a set of attributes that uniquely identifies a tuple within a relationwithin a relation
• Candidate keyCandidate keyA super key such that no proper subset is a superkey within the A super key such that no proper subset is a superkey within the relationrelation– Uniquely identifies the tuple (uniqueness)Uniquely identifies the tuple (uniqueness)– Contains no unique subset (irreducibility)Contains no unique subset (irreducibility)
• Primary keyPrimary keyThe candidate key that is selected to identify tuples uniquely The candidate key that is selected to identify tuples uniquely within a relationwithin a relation– Should remain constant over the life of the tupleShould remain constant over the life of the tuple– Most Most efficient efficient way of identifying a tupleway of identifying a tuple
33
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Finding the Primary KeyFinding the Primary Key
Super KeySuper Key
Candidate KeyCandidate Key
Primary keyPrimary key
34
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
KeysKeys
AttributesAttributes• Catalog numberCatalog number• Record titleRecord title• Artist nameArtist name• Record labelRecord label• UPCUPC
CDs RelationCDs Relation
129341129341
129342129342
129343129343
129344129344
Help!Help!
Hard Day’s NightHard Day’s Night
Sergeant Pepper’sSergeant Pepper’s
Magical Mystery TourMagical Mystery Tour
BeatlesBeatles
BeatlesBeatles
BeatlesBeatles
BeatlesBeatles
ColumbiaColumbia
ColumbiaColumbia
ColumbiaColumbia
ColumbiaColumbia
129345129345 Abbey RoadAbbey Road BeatlesBeatles AppleApple
1-29150-8384-01-29150-8384-0
1-29150-7115-01-29150-7115-0
1-29150-2484-01-29150-2484-0
1-29150-7515-01-29150-7515-0
1-15700-9510-01-15700-9510-0
Superkey?Superkey?Candidate key?Candidate key?Primary key?Primary key?
35
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Selecting a KeySelecting a Key
• CriteriaCriteria
– An An efficientefficient way of identifying an entity way of identifying an entity
– The attribute (value) remains constant over the life of The attribute (value) remains constant over the life of the entitythe entity
• Never changesNever changes
36
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Identifying a TupleIdentifying a Tuple
• Foreign keyForeign keyAn attribute or set of attributes within one relation that An attribute or set of attributes within one relation that matches the candidate key of some (possibly the same) matches the candidate key of some (possibly the same) relationrelation
RelationRelation
keykey
keykey
RelationRelation
foreign keyforeign key
37
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Foreign KeyForeign Key
CDs RelationCDs Relation
129341129341
129342129342
129343129343
129344129344
Help!Help!
Hard Day’s NightHard Day’s Night
Sergeant Pepper’sSergeant Pepper’s
Magical Mystery TourMagical Mystery Tour
BeatlesBeatles
BeatlesBeatles
BeatlesBeatles
BeatlesBeatles
COLCOL
COLCOL
COLCOL
COLCOL
129345129345 Abbey RoadAbbey Road BeatlesBeatles APPAPP
1-29150-8384-01-29150-8384-0
1-29150-7115-01-29150-7115-0
1-29150-2484-01-29150-2484-0
1-29150-7515-01-29150-7515-0
1-15700-9510-01-15700-9510-0
COLCOL
APPAPP
Columbia RecordsColumbia Records
Apple RecordsApple RecordsRecording Label Recording Label
RelationRelation(home relation)(home relation)
Must match!Must match!
38
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Relational IntegrityRelational Integrity
Constraints placed on the set of values allowed for the Constraints placed on the set of values allowed for the attributes of a relation.attributes of a relation.• Entity integrityEntity integrity
– No attribute of a primary key can be null (every tuple No attribute of a primary key can be null (every tuple must be uniquely identified)must be uniquely identified)
• Referential integrityReferential integrity– If a foreign key exists in a relation, either the foreign If a foreign key exists in a relation, either the foreign
key value must match a candidate key value of some key value must match a candidate key value of some tuple in its home relation, or the foreign key value must tuple in its home relation, or the foreign key value must be wholly null (i.e., no key exists in the home relation)be wholly null (i.e., no key exists in the home relation)
• Enterprise constraints (organizational)Enterprise constraints (organizational)
39
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Null ValueNull Value
• Absence of any value (i.e., unknown or nonapplicable to a Absence of any value (i.e., unknown or nonapplicable to a tuple)tuple)
40
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
ViewsViews
• A view is a A view is a virtual relation virtual relation or one that does not actually or one that does not actually exist, but exist, but dynamically deriveddynamically derived– Can be constructed by performing operations (i.e., select, Can be constructed by performing operations (i.e., select,
project, join, etc.) on values of existing base relations project, join, etc.) on values of existing base relations • Base relation - a named relation, corresponding to an Base relation - a named relation, corresponding to an
entity in the conceptual schema, whose tuples are entity in the conceptual schema, whose tuples are physically stored in the databasephysically stored in the database
• View - a dynamic result of one or more relational View - a dynamic result of one or more relational operations operating on the base relations to produce operations operating on the base relations to produce anotheranother
41
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Schema and SubschemasSchema and Subschemas
DBMS
Schema Conceptual LevelConceptual Level
External External LevelLevel
Internal LevelInternal LevelPhysical DatabasePhysical Database
DBMS SoftwareDBMS Software
User User User User User User
Subschema
SomeSome end-user applications end-user applications can be supported by can be supported by viewsviews
Subschema Subschema
42
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
ViewsViews
KeyKeyForeign Foreign
KeyKey KeyKey
CriterionCriterion
Base Relation RBase Relation R Base Relation SBase Relation S
ViewView
43
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Purpose of ViewsPurpose of Views
• Provides a powerful and flexible security mechanism by Provides a powerful and flexible security mechanism by hiding parts of the database from certain usershiding parts of the database from certain users
• Permits user access in a way that is customized to their Permits user access in a way that is customized to their needsneeds
• Simplify complex operations on the base relationsSimplify complex operations on the base relations
• Designed to support the external model Designed to support the external model
• Provides logical independenceProvides logical independence
44
R. Ching, Ph.D. • MIS Dept. • California State University, Sacramento
Updating ViewsUpdating Views
• Allowed on views Allowed on views
– Derived from a single base relation, andDerived from a single base relation, and
– Containing the primary key or a candidate keyContaining the primary key or a candidate key
• NOT allowed on viewsNOT allowed on views
– Derived from multiple base relationsDerived from multiple base relations
– Involving aggregations (i.e., summations) or groups Involving aggregations (i.e., summations) or groups operationsoperations
• Vendors may have other constraints on updating viewsVendors may have other constraints on updating views