Your SlideShare is downloading. ×
0
Grading System <ul><li>Lecture Grade </li></ul><ul><ul><li>1 st  Exam - 10% Ch 1 – 2  </li></ul></ul><ul><ul><li>2 nd  Exa...
<ul><li>Laboratory Grade </li></ul><ul><ul><li>Laboratory Exercises - 10% </li></ul></ul><ul><ul><li>Hands – on Exam - 15 ...
Chapter 1: The Database Environment Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Prescott,  Fred R....
Objectives <ul><li>Definition of terms </li></ul><ul><li>Explain growth and importance of databases </li></ul><ul><li>Name...
Definitions <ul><li>Database: organized collection of logically related data </li></ul><ul><li>Data: stored representation...
Figure 1-1a Data in context Context helps users understand data
Graphical displays turn data into useful information that managers can use for decision making and interpretation Figure 1...
Descriptions of the properties or characteristics of the data, including data types, field sizes, allowable values, and da...
Disadvantages of File Processing <ul><li>Program-Data Dependence </li></ul><ul><ul><li>All programs maintain metadata for ...
Problems with Data Dependency <ul><li>Each application programmer must maintain his/her own data </li></ul><ul><li>Each ap...
Figure 1-3 Old file processing systems at Pine Valley Furniture Company Duplicate Data
Problems with Data Redundancy <ul><li>Waste of space to have duplicate data </li></ul><ul><li>Causes more maintenance head...
SOLUTION:  The DATABASE Approach <ul><li>Central repository of shared data </li></ul><ul><li>Data is managed by a controll...
Database Management System DBMS manages data resources like an operating system manages hardware resources <ul><li>A softw...
Advantages of the Database Approach <ul><li>Program-data independence </li></ul><ul><li>Planned data redundancy </li></ul>...
Costs and Risks of the Database Approach <ul><li>New, specialized personnel </li></ul><ul><li>Installation and management ...
Elements of the Database Approach <ul><li>Data models  </li></ul><ul><ul><li>Graphical system capturing nature and relatio...
Segment of an Enterprise Data Model Segment of a Project-Level Data Model
One customer may place many orders, but each order is placed by a single customer    One-to-many relationship
One order has many order lines; each order line is associated with a single order    One-to-many relationship
One product can be in many order lines, each order line refers to a single product    One-to-many relationship
Therefore, one order involves many products and one product is involved in many orders    Many-to-many relationship
Figure 1-4 Enterprise data model for Figure 1-3 segments
Figure 1-5 Components of the Database Environment
Components of the  Database Environment <ul><li>CASE Tools – computer-aided software engineering </li></ul><ul><li>Reposit...
The Range of Database Applications <ul><li>Personal databases </li></ul><ul><li>Workgroup databases </li></ul><ul><li>Depa...
Figure 1-6 Typical data from a personal database
Figure 1-7 Workgroup database with wireless  local area network
Enterprise Database Applications <ul><li>Enterprise Resource Planning (ERP) </li></ul><ul><ul><li>Integrate all enterprise...
Figure 1-8 An enterprise data warehouse
Evolution of DB Systems
Chapter 2:  The Database Development Process  Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Prescott...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Describe system development life cycle </li></ul><ul><li>Explain ...
Enterprise Data Model <ul><li>First step in database development </li></ul><ul><li>Specifies scope and general content </l...
Figure 2-1 Segment from enterprise data model Enterprise data model describes the high-level entities in an organization a...
Information Systems Architecture (ISA) <ul><li>Conceptual blueprint for organization’s desired information systems structu...
Information Engineering <ul><li>A data-oriented methodology to create and maintain information systems </li></ul><ul><li>T...
Information Systems Planning  (Table 2-1) <ul><li>Purpose – align information technology with organization’s business stra...
Identify Strategic Planning Factors (Table 2-2) <ul><li>Organization goals–what we hope to accomplish </li></ul><ul><li>Cr...
Identify Corporate Planning Objects (Table 2-3) <ul><li>Organizational units–departments </li></ul><ul><li>Organizational ...
Develop Enterprise Model <ul><li>Functional decomposition </li></ul><ul><ul><li>Iterative process breaking system descript...
Figure 2-2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition = break...
Planning Matrixes <ul><li>Describe relationships between planning objects in the organization </li></ul><ul><li>Types of m...
Example business function-to-data entity matrix (Fig. 2-3)
Two Approaches to Database and IS Development <ul><li>SDLC </li></ul><ul><ul><li>System Development Life Cycle </li></ul><...
Systems Development Life Cycle (see also Figures 2.4, 2.5)  Planning Analysis Physical Design Implementation Maintenance L...
Systems Development Life Cycle (see also Figures 2.4, 2.5)  (cont.) Planning Purpose – preliminary understanding Deliverab...
Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.)  Analysis Purpose–thorough requirements analysis and st...
Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.)  Logical Design Purpose–information requirements elicit...
Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.)  Physical Design Purpose–develop technology and organiz...
Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.)  Implementation Purpose–programming, testing, training,...
Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.)  Maintenance Purpose–monitor, repair, enhance Deliverab...
Prototyping Database Methodology (Figure 2.6)
Prototyping Database Methodology (Figure 2.6)  (cont.)
Prototyping Database Methodology (Figure 2.6)  (cont.)
Prototyping Database Methodology (Figure 2.6)  (cont.)
Prototyping Database Methodology (Figure 2.6)  (cont.)
CASE <ul><li>Computer-Aided Software Engineering (CASE)–software tools providing automated support for systems development...
Packaged Data Models <ul><li>Model components that can be purchased, customized, and assembled into full-scale data models...
Managing Projects <ul><li>Project–a planned undertaking of related activities to reach an objective that has a beginning a...
Managing Projects: People Involved <ul><li>Business analysts </li></ul><ul><li>Systems analysts </li></ul><ul><li>Database...
Database Schema <ul><li>Physical Schema  </li></ul><ul><ul><li>Physical structures–covered in Chapters 5 and 6 </li></ul><...
Different people have different views of the database…these are the external schema The internal schema is the underlying ...
Figure 2-8 Developing the three-tiered architecture
Figure 2-9 Three-tiered client/server database architecture
Pine Valley Furniture Segment of project data model  (Figure 2-11)
Figure 2-12 Four relations (Pine Valley Furniture)
Figure 2-12 Four relations (Pine Valley Furniture) (cont.)
Chapter 3: Modeling Data in the Organization Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Prescott,...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Importance of data modeling </li></ul><ul><li>Write good names an...
Business Rules <ul><li>Statements that define or constrain some aspect of the business </li></ul><ul><li>Assert business s...
A Good Business Rule is: <ul><li>Declarative–what, not how </li></ul><ul><li>Precise–clear, agreed-upon meaning </li></ul>...
A Good Data Name is: <ul><li>Related to business, not technical, characteristics </li></ul><ul><li>Meaningful and self-doc...
Data Definitions <ul><li>Explanation of a term or fact </li></ul><ul><ul><li>Term–word or phrase with specific meaning </l...
E-R Model Constructs <ul><li>Entities: </li></ul><ul><ul><li>Entity instance–person, place, object, event, concept (often ...
Sample E-R Diagram (Figure 3-1)
Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity ty...
What Should an Entity Be? <ul><li>SHOULD BE: </li></ul><ul><ul><li>An object that will have many instances in the database...
Inappropriate entities Figure 3-4 Example of inappropriate entities System  user System output Appropriate entities
Attributes <ul><li>Attribute–property or characteristic of an entity or relationahip type </li></ul><ul><li>Classification...
Identifiers (Keys) <ul><li>Identifier (Key)–An attribute (or combination of attributes) that uniquely identifies individua...
Characteristics of Identifiers <ul><li>Will not change in value </li></ul><ul><li>Will not be null </li></ul><ul><li>No in...
Figure 3-7  A  composite  attribute An attribute broken into component parts Figure 3-8  Entity with  multivalued  attribu...
Figure 3-9 Simple and composite identifier attributes The identifier is boldfaced and underlined
Figure 3-19  Simple example of time-stamping This attribute that is both multivalued  and  composite
More on Relationships <ul><li>Relationship Types vs. Relationship Instances </li></ul><ul><ul><li>The relationship type is...
Figure 3-10 Relationship types and instances a) Relationship type b) Relationship instances
Degree of Relationships <ul><li>Degree of a relationship is the number of entity types that participate in it </li></ul><u...
Degree of relationships – from Figure 3-2 Entities of two different types related to each other Entities of three differen...
Cardinality of Relationships <ul><li>One-to-One </li></ul><ul><ul><li>Each entity in the relationship will have exactly on...
Cardinality Constraints <ul><li>Cardinality Constraints - the number of instances of one entity that can or must be associ...
Figure 3-12 Examples of relationships of different degrees a) Unary relationships
Figure 3-12 Examples of relationships of different degrees (cont.) b) Binary relationships
Figure 3-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have a...
Figure 3-17 Examples of cardinality constraints a) Mandatory cardinalities A patient must have recorded at least one histo...
Figure 3-17 Examples of cardinality constraints (cont.) b) One optional, one mandatory An employee can be assigned to any ...
Figure 3-17 Examples of cardinality constraints (cont.) a) Optional cardinalities A person is is married to at most one ot...
Entities can be related to one another in more than one way Figure 3-21 Examples of multiple relationships a) Employees an...
Figure 3-21 Examples of multiple relationships (cont.) b) Professors and courses (fixed lower limit constraint) Here, min ...
Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships simple composite
Strong vs. Weak Entities, and Identifying Relationships <ul><li>Strong entities  </li></ul><ul><ul><li>exist independently...
Strong entity Weak entity Identifying relationship
Associative Entities <ul><li>An  entity –has attributes </li></ul><ul><li>A  relationship –links entities together </li></...
Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the emplo...
Figure 3-11b An associative entity (CERTIFICATE) Associative entity is like a relationship with an attribute, but it is al...
Figure 3-13c An associative entity – bill of materials structure This could just be a relationship with attributes…it’s a ...
Figure 3-18 Ternary relationship as an associative entity
Microsoft Visio Example for E-R diagram Different modeling software tools may have different notation for the same constru...
Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Pr...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Use of supertype/subtype relationships </li></ul><ul><li>Use of g...
Supertypes and Subtypes <ul><li>Subtype:   A subgrouping of the entities in an entity type that has attributes distinct fr...
Figure 4-1 Basic notation for supertype/subtype notation a) EER  notation
Different modeling tools may have different notation for the same modeling constructs  b) Microsoft Visio Notation Figure ...
Figure 4-2  Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired ...
Relationships and Subtypes <ul><li>Relationships at the  supertype  level indicate that all subtypes will participate in t...
Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a respons...
Generalization and Specialization <ul><li>Generalization:  The process of defining a more general entity type from a set o...
Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have co...
Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycl...
Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts
b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) ...
Constraints in Supertype/ Completeness Constraint <ul><li>Completeness Constraints : Whether an instance of a supertype  m...
Figure 4-6 Examples of completeness constraints a) Total  specialization rule A patient must be either an outpatient or a ...
b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, ...
Constraints in Supertype/ Disjointness constraint <ul><li>Disjointness Constraints :  Whether an instance of a supertype m...
a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not b...
b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured
Constraints in Supertype/ Subtype Discriminators <ul><li>Subtype Discriminator : An attribute of the supertype whose value...
Figure 4-8 Introducing a subtype discriminator ( disjoint  rule) A simple attribute with different possible values indicat...
Figure 4-9 Subtype discriminator ( overlap  rule) A composite attribute with sub-attributes indicating “yes” or “no” to de...
Figure 4-10 Example of supertype/subtype hierarchy
Entity Clusters <ul><li>EER diagrams are difficult to read when there are too many entities and relationships </li></ul><u...
Figure 4-13a  Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could becom...
Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?
Figure 4-14 Manufacturing entity cluster Detail for a single cluster
Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Pr...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Use of supertype/subtype relationships </li></ul><ul><li>Use of g...
Supertypes and Subtypes <ul><li>Subtype:   A subgrouping of the entities in an entity type that has attributes distinct fr...
Figure 4-1 Basic notation for supertype/subtype notation a) EER  notation
Different modeling tools may have different notation for the same modeling constructs  b) Microsoft Visio Notation Figure ...
Figure 4-2  Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired ...
Relationships and Subtypes <ul><li>Relationships at the  supertype  level indicate that all subtypes will participate in t...
Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a respons...
Generalization and Specialization <ul><li>Generalization:  The process of defining a more general entity type from a set o...
Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have co...
Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycl...
Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts
b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) ...
Constraints in Supertype/ Completeness Constraint <ul><li>Completeness Constraints : Whether an instance of a supertype  m...
Figure 4-6 Examples of completeness constraints a) Total  specialization rule A patient must be either an outpatient or a ...
b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, ...
Constraints in Supertype/ Disjointness constraint <ul><li>Disjointness Constraints :  Whether an instance of a supertype m...
a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not b...
b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured
Constraints in Supertype/ Subtype Discriminators <ul><li>Subtype Discriminator : An attribute of the supertype whose value...
Figure 4-8 Introducing a subtype discriminator ( disjoint  rule) A simple attribute with different possible values indicat...
Figure 4-9 Subtype discriminator ( overlap  rule) A composite attribute with sub-attributes indicating “yes” or “no” to de...
Figure 4-10 Example of supertype/subtype hierarchy
Entity Clusters <ul><li>EER diagrams are difficult to read when there are too many entities and relationships </li></ul><u...
Figure 4-13a  Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could becom...
Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?
Figure 4-14 Manufacturing entity cluster Detail for a single cluster
Packaged data models provide generic models that can be customized for a particular organization’s business rules
Business rules <ul><li>Statements that  define  or  constrain  some aspect of the business </li></ul><ul><li>Classificatio...
Figure 4-18 EER diagram to describe business rules
Types of Action Assertions <ul><li>Result </li></ul><ul><ul><li>Condition–IF/THEN rule </li></ul></ul><ul><ul><li>Integrit...
Stating an Action Assertion <ul><li>Anchor Object–an object on which actions are limited </li></ul><ul><li>Action–creation...
Figure 4-19 Data model segment for class scheduling
Figure 4-20  Business Rule 1: For a faculty member to be assigned to teach a section of a course, the faculty member must ...
Figure 4-21  Business Rule 2: For a faculty member to be assigned to teach a section of a course, the faculty member must ...
Chapter 5: Logical Database Design and the Relational Model Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Ma...
Objectives <ul><li>Definition of terms </li></ul><ul><li>List five properties of relations </li></ul><ul><li>State two pro...
Relation <ul><li>Definition: A relation is a named, two-dimensional table of data  </li></ul><ul><li>Table consists of row...
Correspondence with E-R Model <ul><li>Relations (tables) correspond with entity types and with many-to-many relationship t...
Key Fields <ul><li>Keys are special fields that serve two main purposes: </li></ul><ul><ul><li>Primary keys  are  unique  ...
Figure 5-3 Schema for four relations (Pine Valley Furniture Company) Primary Key Foreign Key  (implements 1:N relationship...
Integrity Constraints <ul><li>Domain Constraints </li></ul><ul><ul><li>Allowable values for an attribute. See Table 5-1 </...
Domain definitions enforce domain integrity constraints
Integrity Constraints <ul><li>Referential Integrity–rule states that any foreign key value (on the relation of the many si...
Figure 5-5  Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arro...
Figure 5-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key referen...
Transforming EER Diagrams into Relations <ul><li>Mapping Regular Entities to Relations  </li></ul><ul><ul><li>Simple attri...
(a) CUSTOMER entity type with simple attributes Figure 5-8 Mapping a regular entity (b) CUSTOMER relation
(a) CUSTOMER entity type with composite attribute Figure 5-9 Mapping a composite attribute (b) CUSTOMER relation with addr...
Figure 5-10 Mapping an entity with a multivalued attribute One–to–many relationship between original entity and new relati...
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Weak Entities </li></ul><ul><ul><li>Becomes a separate re...
Figure 5-11 Example of mapping a weak entity a) Weak entity DEPENDENT
NOTE: the domain constraint for the foreign key should NOT allow  null  value if DEPENDENT is a weak entity Foreign key Fi...
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Binary Relationships </li></ul><ul><ul><li>One-to-Many–Pr...
Figure 5-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one Agai...
Figure 5-13 Example of mapping an M:N relationship a) Completes relationship (M:N) The  Completes  relationship will need ...
New  intersection relation Figure 5-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations Foreign...
Figure 5-14 Example of mapping a binary 1:1 relationship a) In_charge relationship (1:1) Often in 1:1 relationships, one d...
b) Resulting relations Figure 5-14 Example of mapping a binary 1:1 relationship (cont.) Foreign key goes in the relation o...
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Associative Entities </li></ul><ul><ul><li>Identifier Not...
Figure 5-15 Example of mapping an associative entity a) An associative entity
Figure 5-15 Example of mapping an associative entity (cont.) b) Three resulting relations Composite primary key formed fro...
Figure 5-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity
Figure 5-16 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key d...
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Unary Relationships </li></ul><ul><ul><li>One-to-Many–Rec...
Figure 5-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recurs...
Figure 5-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Ternary (and n-ary) Relationships </li></ul><ul><ul><li>O...
Figure 5-19 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity
b) Mapping the ternary relationship PATIENT TREATMENT Remember that the primary key MUST be unique Figure 5-19 Mapping a t...
Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Supertype/Subtype Relationships </li></ul><ul><ul><li>One...
Figure 5-20 Supertype/subtype relationships
Figure 5-21  Mapping Supertype/subtype relationships to relations These are implemented as one-to-one relationships
Data Normalization <ul><li>Primarily a tool to validate and improve a logical design so that it satisfies certain constrai...
Well-Structured Relations <ul><li>A relation that contains minimal data redundancy and allows users to insert, delete, and...
Example–Figure 5-2b Question–Is this a relation?   Answer–Yes: Unique rows and no multivalued attributes Question–What’s t...
Anomalies in this Table <ul><li>Insertion –can’t enter a new employee without having the employee take a class </li></ul><...
Functional Dependencies and Keys <ul><li>Functional Dependency: The value of one attribute (the  determinant ) determines ...
Figure 5.22 Steps in normalization
First Normal Form <ul><li>No multivalued attributes </li></ul><ul><li>Every attribute value is atomic </li></ul><ul><li>Fi...
Table with multivalued attributes, not in 1 st  normal form Note: this is NOT a relation
Table with no multivalued attributes and unique rows, in 1 st  normal form Note: this is relation, but not a well-structur...
Anomalies in this Table <ul><li>Insertion –if new product is ordered for order 1007 of existing customer, customer data mu...
Second Normal Form <ul><li>1NF PLUS  every non-key attribute is fully functionally dependent on the ENTIRE primary key </l...
Order_ID    Order_Date, Customer_ID, Customer_Name, Customer_Address Therefore, NOT in 2 nd  Normal Form Customer_ID    ...
Partial dependencies are removed, but there are still transitive dependencies Getting it into Second Normal Form Figure 5-...
Third Normal Form <ul><li>2NF PLUS  no transitive dependencies  (functional dependencies on non-primary-key attributes) </...
Transitive dependencies are removed Figure 5-28 Removing partial dependencies Getting it into Third Normal Form
Merging Relations <ul><li>View Integration–Combining entities from multiple ER models into common relations </li></ul><ul>...
Enterprise Keys <ul><li>Primary keys that are unique in the whole database, not just within a single relation </li></ul><u...
Figure 5-31 Enterprise keys a) Relations with enterprise key b) Sample data with enterprise key
Chapter 6: Physical Database Design and Performance Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Pr...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Describe the physical database design process </li></ul><ul><li>C...
Physical Database Design <ul><li>Purpose–translate the logical description of data into the  technical specifications  for...
Physical Design Process <ul><li>Normalized relations </li></ul><ul><li>Volume estimates </li></ul><ul><li>Attribute defini...
Figure 6-1 Composite usage map (Pine Valley Furniture Company)
Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Data volumes
Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Access Frequencies (per hour)
Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 140 purchased parts accessed per ho...
Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 75 suppliers accessed per hour   4...
Designing Fields <ul><li>Field: smallest unit of data in database </li></ul><ul><li>Field design  </li></ul><ul><ul><li>Ch...
Choosing Data Types <ul><li>CHAR–fixed-length character </li></ul><ul><li>VARCHAR2–variable-length character (memo) </li><...
Figure 6-2  Example code look-up table (Pine Valley Furniture Company) Code saves space, but costs an additional lookup to...
Field Data Integrity <ul><li>Default value–assumed value if no explicit value </li></ul><ul><li>Range control–allowable va...
Handling Missing Data <ul><li>Substitute an estimate of the missing value (e.g., using a formula) </li></ul><ul><li>Constr...
Physical Records <ul><li>Physical Record: A group of fields stored in adjacent memory locations and retrieved together as ...
Denormalization <ul><li>Transforming  normalized  relations into  unnormalized  physical record specifications </li></ul><...
Figure 6-3  A possible denormalization situation: two entities with one-to-one relationship
Figure 6-4  A possible denormalization situation: a many-to-many relationship with nonkey attributes Extra table access re...
Figure 6-5 A possible denormalization situation: reference data Extra table access required  Data duplication
Partitioning <ul><li>Horizontal Partitioning: Distributing the rows of a table into several separate files </li></ul><ul><...
Partitioning (cont.) <ul><li>Advantages of Partitioning: </li></ul><ul><ul><li>Efficiency: Records used together are group...
Data Replication <ul><li>Purposely storing the same data in multiple locations of the database </li></ul><ul><li>Improves ...
Designing Physical Files <ul><li>Physical File:  </li></ul><ul><ul><li>A named portion of secondary memory allocated for t...
Figure 6-4  Physical file terminology in an Oracle environment
File Organizations <ul><li>Technique for physically arranging records of a file on secondary storage </li></ul><ul><li>Fac...
Figure 6-7a  Sequential file organization If not sorted Average time to find desired record = n/2 1 2 n Records of the fil...
Indexed File Organizations <ul><li>Index–a separate table that contains organization of records for quick retrieval </li><...
Figure 6-7b B-tree index uses a  tree search Average time to find desired record =  depth of the tree Leaves of the tree a...
Figure 6-7c Hashed  file or index organization  Hash algorithm Usually uses division-remainder to determine record positio...
Figure 6-8 Bitmap  index index organization  Bitmap saves on space requirements Rows - possible values of the attribute Co...
Figure 6-9  Join  Indexes–speeds up join operations
Clustering Files <ul><li>In some relational DBMSs, related records from different tables can be stored together in the sam...
Rules for Using Indexes <ul><li>Use on larger tables </li></ul><ul><li>Index the primary key of each table </li></ul><ul><...
Rules for Using Indexes (cont.) <ul><li>Avoid use of indexes for fields with long values; perhaps compress values first </...
RAID <ul><li>Redundant Array of Inexpensive Disks </li></ul><ul><li>A set of disk drives that appear to the user to be a s...
<ul><li>Figure 6-10 </li></ul><ul><ul><li>RAID with four disks and striping </li></ul></ul>Here, pages 1-4 can be read/wri...
Raid Types (Figure 6-10) <ul><li>Raid 0 </li></ul><ul><ul><li>Maximized parallelism </li></ul></ul><ul><ul><li>No redundan...
Database Architectures  (Figure 6-11) Legacy Systems Current Technology Data Warehouses
Chapter 7: Introduction to SQL Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Prescott,  Fred R. McFa...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Interpret history and role of SQL  </li></ul><ul><li>Define a dat...
SQL Overview <ul><li>Structured Query Language </li></ul><ul><li>The standard for relational database management systems (...
History of SQL <ul><li>1970–E. Codd develops relational database concept </li></ul><ul><li>1974-1979–System R with Sequel ...
Purpose of SQL Standard <ul><li>Specify syntax/semantics for data definition and manipulation </li></ul><ul><li>Define dat...
Benefits of a Standardized Relational Language <ul><li>Reduced training costs </li></ul><ul><li>Productivity </li></ul><ul...
SQL Environment <ul><li>Catalog   </li></ul><ul><ul><li>A set of schemas that constitute the description of a database </l...
Figure 7-1 A simplified schematic of a typical SQL environment, as described by the SQL-2003 standard
Some SQL Data types
Figure 7-4  DDL, DML, DCL, and the database development process
SQL Database Definition <ul><li>Data Definition Language (DDL) </li></ul><ul><li>Major CREATE statements: </li></ul><ul><u...
Table Creation Figure 7-5 General syntax for CREATE TABLE <ul><li>Steps in table creation: </li></ul><ul><li>Identify data...
The following slides create tables for this enterprise data model
Figure 7-6 SQL database definition commands for Pine Valley Furniture Overall table definitions
Defining attributes and their data types
Non-nullable specification Identifying primary key Primary keys can never have NULL values
Non-nullable specifications Primary key Some primary keys are composite– composed of multiple attributes
Default value Domain constraint Controlling the values in attributes
Primary key of  parent table Identifying foreign keys and establishing relationships Foreign key of  dependent table
Data Integrity Controls <ul><li>Referential integrity–constraint that ensures that foreign key values of a table must matc...
Relational integrity is enforced via the primary-key to foreign-key match Figure 7-7 Ensuring data integrity through updates
Changing and Removing Tables <ul><li>ALTER TABLE statement allows you to change column specifications: </li></ul><ul><ul><...
Schema Definition <ul><li>Control processing/storage efficiency: </li></ul><ul><ul><li>Choice of indexes </li></ul></ul><u...
Insert Statement <ul><li>Adds data to a table </li></ul><ul><li>Inserting into a table </li></ul><ul><ul><li>INSERT INTO C...
Creating Tables with Identity Columns <ul><li>Inserting into a table does not require explicit customer ID entry or field ...
Delete Statement <ul><li>Removes rows from a table </li></ul><ul><li>Delete certain rows </li></ul><ul><ul><li>DELETE FROM...
Update Statement <ul><li>Modifies data in existing rows </li></ul><ul><li>UPDATE PRODUCT_T SET UNIT_PRICE = 775 WHERE PROD...
Merge Statement Makes it easier to update a table…allows combination of Insert and Update in one statement Useful for upda...
SELECT Statement <ul><li>Used for queries on single or multiple tables </li></ul><ul><li>Clauses of the SELECT statement: ...
<ul><li>Figure 7-10  </li></ul><ul><ul><li>SQL statement processing order  (adapted from van der Lans, p.100) </li></ul></ul>
SELECT Example <ul><li>Find products with standard price less than $275 </li></ul><ul><ul><li>SELECT  PRODUCT_NAME, STANDA...
SELECT Example Using Alias <ul><li>Alias is an alternative column or table name </li></ul><ul><ul><ul><li>SELECT  CUST .CU...
SELECT Example  Using a Function <ul><li>Using the COUNT  aggregate function  to find totals </li></ul><ul><ul><li>SELECT ...
SELECT Example–Boolean Operators <ul><li>AND ,  OR , and  NOT  Operators for customizing conditions in WHERE clause </li><...
Venn Diagram from Previous Query
SELECT Example –  Sorting Results with the ORDER BY Clause <ul><li>Sort the results first by STATE, and within a state by ...
SELECT Example–  Categorizing Results Using the GROUP BY Clause <ul><li>For use with aggregate functions </li></ul><ul><ul...
SELECT Example–  Qualifying Results by Categories  Using the HAVING Clause <ul><li>For use with GROUP BY </li></ul><ul><ul...
Using and Defining Views <ul><li>Views provide users controlled access to tables </li></ul><ul><li>Base Table–table contai...
Sample CREATE VIEW <ul><ul><li>CREATE VIEW EXPENSIVE_STUFF_V AS </li></ul></ul><ul><ul><li>SELECT PRODUCT_ID, PRODUCT_NAME...
Advantages of Views <ul><li>Simplify query commands </li></ul><ul><li>Assist with data security (but don't rely on views f...
Disadvantages of Views <ul><li>Use processing time each time view is referenced </li></ul><ul><li>May or may not be direct...
Chapter 8: Advanced SQL Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Prescott,  Fred R. McFadden © ...
Objectives <ul><li>Definition of terms </li></ul><ul><li>Write multiple table SQL queries </li></ul><ul><li>Define and use...
Processing Multiple Tables–Joins <ul><li>Join – a relational operation that causes two or more tables with a common domain...
The following slides create tables for this enterprise data model
These tables are used in queries that follow Figure 8-1 Pine Valley Furniture Company Customer and Order tables with point...
<ul><li>For each customer who placed an order, what is the customer’s name and order number? </li></ul><ul><ul><li>SELECT ...
<ul><li>List the customer name, ID number, and order number for all customers. Include customer information even for custo...
Results Unlike INNER join, this will include customer rows with no matching order rows
<ul><li>Assemble all information necessary to create an invoice for order number 1006 </li></ul><ul><ul><li>SELECT CUSTOME...
Figure 8-2 Results from a four-table join From CUSTOMER_T table From ORDER_T table From PRODUCT_T table
Processing Multiple Tables  Using Subqueries <ul><li>Subquery–placing an inner query (SELECT statement) inside an outer qu...
<ul><li>Show all customers who have placed an order </li></ul><ul><ul><li>SELECT CUSTOMER_NAME  FROM CUSTOMER_T </li></ul>...
Correlated vs. Noncorrelated Subqueries <ul><li>Noncorrelated subqueries: </li></ul><ul><ul><li>Do not depend on data from...
Figure 8-3a Processing a noncorrelated subquery No reference to data in outer query, so subquery executes once only These ...
<ul><li>Show all orders that include furniture finished in natural ash </li></ul><ul><ul><li>SELECT DISTINCT ORDER_ID FROM...
Figure 8-3b Processing a correlated subquery Subquery refers to outer-query data, so executes once for each row of outer q...
<ul><li>Show all products whose standard price is higher than the average price </li></ul><ul><ul><li>SELECT PRODUCT_DESCR...
Union Queries <ul><li>Combine the output (union of multiple queries) together into a single result table </li></ul>First q...
Conditional Expressions Using Case Syntax <ul><li>This is available with newer versions of SQL, previously not part of the...
Ensuring Transaction Integrity <ul><li>Transaction = A discrete unit of work that must be completely processed or not proc...
Figure 8-5 An SQL Transaction sequence (in pseudocode)
Data Dictionary Facilities <ul><li>System tables that store metadata </li></ul><ul><li>Users usually can view some of thes...
SQL:1999 and SQL:2003 Enhancements/Extensions <ul><li>User-defined data types (UDT) </li></ul><ul><ul><li>Subclasses of st...
<ul><li>Persistent Stored Modules (SQL/PSM) </li></ul><ul><ul><li>Capability to create and drop code modules </li></ul></u...
Routines and Triggers <ul><li>Routines </li></ul><ul><ul><li>Program modules that execute on demand </li></ul></ul><ul><ul...
Figure 8-6 Triggers contrasted with stored procedures Procedures are called explicitly Triggers are event-driven Source : ...
Figure 8-7 Simplified trigger syntax, SQL:2003 Figure 8-8 Create routine syntax, SQL:2003
Embedded and Dynamic SQL <ul><li>Embedded SQL </li></ul><ul><ul><li>Including hard-coded SQL statements in a program writt...
Chapter 9:  The Client/Server Database Environment Modern Database Management 8 th  Edition Jeffrey A. Hoffer, Mary B. Pre...
Objectives <ul><li>Definition of terms </li></ul><ul><li>List advantages of client/server architecture </li></ul><ul><li>E...
Client/Server Systems <ul><li>Networked computing model </li></ul><ul><li>Processes distributed between clients and server...
Application Logic in C/S Systems GUI Interface Procedures, functions, programs DBMS activities <ul><li>Processing Logic </...
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Modern database management   jeffrey a. hoffer, mary b. prescott,
Upcoming SlideShare
Loading in...5
×

Modern database management jeffrey a. hoffer, mary b. prescott,

18,814

Published on

Modern Database Management - Jeffrey A. Hoffer, Mary B. Prescott

Published in: Education
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
18,814
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
774
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide
  • 2
  • 3
  • 8
  • 5
  • 6
  • 7
  • 12
  • 14
  • 37
  • 17
  • 16
  • 8
  • 29
  • 22
  • 22
  • 22
  • 1
  • 1
  • 1
  • 40
  • 40
  • 20
  • 21
  • 27
  • 36
  • Transcript of "Modern database management jeffrey a. hoffer, mary b. prescott, "

    1. 1. Grading System <ul><li>Lecture Grade </li></ul><ul><ul><li>1 st Exam - 10% Ch 1 – 2 </li></ul></ul><ul><ul><li>2 nd Exam - 10% Ch 3 – 5 </li></ul></ul><ul><ul><li>3 rd Exam - 10% Ch 7 – 8 (SQL) </li></ul></ul><ul><ul><li>4 th Exam - 15% Overall </li></ul></ul><ul><ul><li>Project - 15% </li></ul></ul><ul><ul><li>Q/A/Etc - 40% </li></ul></ul><ul><ul><ul><li>TOTAL - 100% * .75 </li></ul></ul></ul>
    2. 2. <ul><li>Laboratory Grade </li></ul><ul><ul><li>Laboratory Exercises - 10% </li></ul></ul><ul><ul><li>Hands – on Exam - 15 % </li></ul></ul><ul><ul><ul><li>TOTAL - 25% </li></ul></ul></ul><ul><li>GRADE = LEC + LAB = 75% + 25% = 100% </li></ul>
    3. 3. Chapter 1: The Database Environment Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    4. 4. Objectives <ul><li>Definition of terms </li></ul><ul><li>Explain growth and importance of databases </li></ul><ul><li>Name limitations of conventional file processing </li></ul><ul><li>Identify five categories of databases </li></ul><ul><li>Explain advantages of databases </li></ul><ul><li>Identify costs and risks of databases </li></ul><ul><li>List components of database environment </li></ul><ul><li>Describe evolution of database systems </li></ul>
    5. 5. Definitions <ul><li>Database: organized collection of logically related data </li></ul><ul><li>Data: stored representations of meaningful objects and events </li></ul><ul><ul><li>Structured: numbers, text, dates </li></ul></ul><ul><ul><li>Unstructured: images, video, documents </li></ul></ul><ul><li>Information: data processed to increase knowledge in the person using the data </li></ul><ul><li>Metadata: data that describes the properties and context of user data </li></ul>
    6. 6. Figure 1-1a Data in context Context helps users understand data
    7. 7. Graphical displays turn data into useful information that managers can use for decision making and interpretation Figure 1-1b Summarized data
    8. 8. Descriptions of the properties or characteristics of the data, including data types, field sizes, allowable values, and data context
    9. 9. Disadvantages of File Processing <ul><li>Program-Data Dependence </li></ul><ul><ul><li>All programs maintain metadata for each file they use </li></ul></ul><ul><li>Duplication of Data </li></ul><ul><ul><li>Different systems/programs have separate copies of the same data </li></ul></ul><ul><li>Limited Data Sharing </li></ul><ul><ul><li>No centralized control of data </li></ul></ul><ul><li>Lengthy Development Times </li></ul><ul><ul><li>Programmers must design their own file formats </li></ul></ul><ul><li>Excessive Program Maintenance </li></ul><ul><ul><li>80% of information systems budget </li></ul></ul>
    10. 10. Problems with Data Dependency <ul><li>Each application programmer must maintain his/her own data </li></ul><ul><li>Each application program needs to include code for the metadata of each file </li></ul><ul><li>Each application program must have its own processing routines for reading, inserting, updating, and deleting data </li></ul><ul><li>Lack of coordination and central control </li></ul><ul><li>Non-standard file formats </li></ul>
    11. 11. Figure 1-3 Old file processing systems at Pine Valley Furniture Company Duplicate Data
    12. 12. Problems with Data Redundancy <ul><li>Waste of space to have duplicate data </li></ul><ul><li>Causes more maintenance headaches </li></ul><ul><li>The biggest problem: </li></ul><ul><ul><li>Data changes in one file could cause inconsistencies </li></ul></ul><ul><ul><li>Compromises in data integrity </li></ul></ul>
    13. 13. SOLUTION: The DATABASE Approach <ul><li>Central repository of shared data </li></ul><ul><li>Data is managed by a controlling agent </li></ul><ul><li>Stored in a standardized, convenient form </li></ul>Requires a Database Management System (DBMS)
    14. 14. Database Management System DBMS manages data resources like an operating system manages hardware resources <ul><li>A software system that is used to create, maintain, and provide controlled access to user databases </li></ul>Order Filing System Invoicing System Payroll System DBMS Central database Contains employee, order, inventory, pricing, and customer data
    15. 15. Advantages of the Database Approach <ul><li>Program-data independence </li></ul><ul><li>Planned data redundancy </li></ul><ul><li>Improved data consistency </li></ul><ul><li>Improved data sharing </li></ul><ul><li>Increased application development productivity </li></ul><ul><li>Enforcement of standards </li></ul><ul><li>Improved data quality </li></ul><ul><li>Improved data accessibility and responsiveness </li></ul><ul><li>Reduced program maintenance </li></ul><ul><li>Improved decision support </li></ul>
    16. 16. Costs and Risks of the Database Approach <ul><li>New, specialized personnel </li></ul><ul><li>Installation and management cost and complexity </li></ul><ul><li>Conversion costs </li></ul><ul><li>Need for explicit backup and recovery </li></ul><ul><li>Organizational conflict </li></ul>
    17. 17. Elements of the Database Approach <ul><li>Data models </li></ul><ul><ul><li>Graphical system capturing nature and relationship of data </li></ul></ul><ul><ul><li>Enterprise Data Model–high-level entities and relationships for the organization </li></ul></ul><ul><ul><li>Project Data Model–more detailed view, matching data structure in database or data warehouse </li></ul></ul><ul><li>Relational Databases </li></ul><ul><ul><li>Database technology involving tables (relations) representing entities and primary/foreign keys representing relationships </li></ul></ul><ul><li>Use of Internet Technology </li></ul><ul><ul><li>Networks and telecommunications, distributed databases, client-server, and 3-tier architectures </li></ul></ul><ul><li>Database Applications </li></ul><ul><ul><li>Application programs used to perform database activities (create, read, update, and delete) for database users </li></ul></ul>
    18. 18. Segment of an Enterprise Data Model Segment of a Project-Level Data Model
    19. 19. One customer may place many orders, but each order is placed by a single customer  One-to-many relationship
    20. 20. One order has many order lines; each order line is associated with a single order  One-to-many relationship
    21. 21. One product can be in many order lines, each order line refers to a single product  One-to-many relationship
    22. 22. Therefore, one order involves many products and one product is involved in many orders  Many-to-many relationship
    23. 23. Figure 1-4 Enterprise data model for Figure 1-3 segments
    24. 24. Figure 1-5 Components of the Database Environment
    25. 25. Components of the Database Environment <ul><li>CASE Tools – computer-aided software engineering </li></ul><ul><li>Repository – centralized storehouse of metadata </li></ul><ul><li>Database Management System (DBMS) – software for managing the database </li></ul><ul><li>Database – storehouse of the data </li></ul><ul><li>Application Programs – software using the data </li></ul><ul><li>User Interface – text and graphical displays to users </li></ul><ul><li>Data/Database Administrators – personnel responsible for maintaining the database </li></ul><ul><li>System Developers – personnel responsible for designing databases and software </li></ul><ul><li>End Users – people who use the applications and databases </li></ul>
    26. 26. The Range of Database Applications <ul><li>Personal databases </li></ul><ul><li>Workgroup databases </li></ul><ul><li>Departmental/divisional databases </li></ul><ul><li>Enterprise database </li></ul>
    27. 27.
    28. 28. Figure 1-6 Typical data from a personal database
    29. 29. Figure 1-7 Workgroup database with wireless local area network
    30. 30. Enterprise Database Applications <ul><li>Enterprise Resource Planning (ERP) </li></ul><ul><ul><li>Integrate all enterprise functions (manufacturing, finance, sales, marketing, inventory, accounting, human resources) </li></ul></ul><ul><li>Data Warehouse </li></ul><ul><ul><li>Integrated decision support system derived from various operational databases </li></ul></ul>
    31. 31. Figure 1-8 An enterprise data warehouse
    32. 32. Evolution of DB Systems
    33. 33. Chapter 2: The Database Development Process Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    34. 34. Objectives <ul><li>Definition of terms </li></ul><ul><li>Describe system development life cycle </li></ul><ul><li>Explain prototyping approach </li></ul><ul><li>Explain roles of individuals </li></ul><ul><li>Explain three-schema approach </li></ul><ul><li>Explain role of packaged data models </li></ul><ul><li>Explain three-tiered architectures </li></ul><ul><li>Explain scope of database design projects </li></ul><ul><li>Draw simple data models </li></ul>
    35. 35. Enterprise Data Model <ul><li>First step in database development </li></ul><ul><li>Specifies scope and general content </li></ul><ul><li>Overall picture of organizational data at high level of abstraction </li></ul><ul><li>Entity-relationship diagram </li></ul><ul><li>Descriptions of entity types </li></ul><ul><li>Relationships between entities </li></ul><ul><li>Business rules </li></ul>
    36. 36. Figure 2-1 Segment from enterprise data model Enterprise data model describes the high-level entities in an organization and the relationship between these entities
    37. 37. Information Systems Architecture (ISA) <ul><li>Conceptual blueprint for organization’s desired information systems structure </li></ul><ul><li>Consists of: </li></ul><ul><ul><li>Data (e.g. Enterprise Data Model – simplified ER Diagram) </li></ul></ul><ul><ul><li>Processes – data flow diagrams, process decomposition, etc. </li></ul></ul><ul><ul><li>Data Network – topology diagram (like Fig 1-9) </li></ul></ul><ul><ul><li>People – people management using project management tools (Gantt charts, etc.) </li></ul></ul><ul><ul><li>Events and points in time (when processes are performed) </li></ul></ul><ul><ul><li>Reasons for events and rules (e.g., decision tables) </li></ul></ul>
    38. 38. Information Engineering <ul><li>A data-oriented methodology to create and maintain information systems </li></ul><ul><li>Top-down planning–a generic IS planning methodology for obtaining a broad understanding of the IS needed by the entire organization </li></ul><ul><li>Four steps to Top-Down planning: </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Analysis </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Implementation </li></ul></ul>
    39. 39. Information Systems Planning (Table 2-1) <ul><li>Purpose – align information technology with organization’s business strategies </li></ul><ul><li>Three steps: </li></ul><ul><ul><ul><li>Identify strategic planning factors </li></ul></ul></ul><ul><ul><ul><li>Identify corporate planning objects </li></ul></ul></ul><ul><ul><ul><li>Develop enterprise model </li></ul></ul></ul>
    40. 40. Identify Strategic Planning Factors (Table 2-2) <ul><li>Organization goals–what we hope to accomplish </li></ul><ul><li>Critical success factors–what MUST work in order for us to survive </li></ul><ul><li>Problem areas–weaknesses we now have </li></ul>
    41. 41. Identify Corporate Planning Objects (Table 2-3) <ul><li>Organizational units–departments </li></ul><ul><li>Organizational locations </li></ul><ul><li>Business functions–groups of business processes </li></ul><ul><li>Entity types–the things we are trying to model for the database </li></ul><ul><li>Information systems–application programs </li></ul>
    42. 42. Develop Enterprise Model <ul><li>Functional decomposition </li></ul><ul><ul><li>Iterative process breaking system description into finer and finer detail </li></ul></ul><ul><li>Enterprise data model </li></ul><ul><li>Planning matrixes </li></ul><ul><ul><li>Describe interrelationships </li></ul></ul><ul><ul><li>between planning objects </li></ul></ul>
    43. 43. Figure 2-2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition = breaking large tasks into smaller tasks in a hierarchical structure chart
    44. 44. Planning Matrixes <ul><li>Describe relationships between planning objects in the organization </li></ul><ul><li>Types of matrixes: </li></ul><ul><ul><li>Function-to-data entity </li></ul></ul><ul><ul><li>Location-to-function </li></ul></ul><ul><ul><li>Unit-to-function </li></ul></ul><ul><ul><li>IS-to-data entity </li></ul></ul><ul><ul><li>Supporting function-to-data entity </li></ul></ul><ul><ul><li>IS-to-business objective </li></ul></ul>
    45. 45. Example business function-to-data entity matrix (Fig. 2-3)
    46. 46. Two Approaches to Database and IS Development <ul><li>SDLC </li></ul><ul><ul><li>System Development Life Cycle </li></ul></ul><ul><ul><li>Detailed, well-planned development process </li></ul></ul><ul><ul><li>Time-consuming, but comprehensive </li></ul></ul><ul><ul><li>Long development cycle </li></ul></ul><ul><li>Prototyping </li></ul><ul><ul><li>Rapid application development (RAD) </li></ul></ul><ul><ul><li>Cursory attempt at conceptual data modeling </li></ul></ul><ul><ul><li>Define database during development of initial prototype </li></ul></ul><ul><ul><li>Repeat implementation and maintenance activities with new prototype versions </li></ul></ul>
    47. 47. Systems Development Life Cycle (see also Figures 2.4, 2.5) Planning Analysis Physical Design Implementation Maintenance Logical Design
    48. 48. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Planning Purpose – preliminary understanding Deliverable – request for study Database activity – enterprise modeling and early conceptual data modeling Planning Analysis Physical Design Implementation Maintenance Logical Design
    49. 49. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Analysis Purpose–thorough requirements analysis and structuring Deliverable–functional system specifications Database activity–Thorough and integrated conceptual data modeling Planning Analysis Physical Design Implementation Maintenance Logical Design
    50. 50. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Logical Design Purpose–information requirements elicitation and structure Deliverable–detailed design specifications Database activity– logical database design (transactions, forms, displays, views, data integrity and security) Planning Analysis Physical Design Implementation Maintenance Logical Design
    51. 51. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Physical Design Purpose–develop technology and organizational specifications Deliverable–program/data structures, technology purchases, organization redesigns Database activity– physical database design (define database to DBMS, physical data organization, database processing programs) Planning Analysis Physical Design Implementation Maintenance Logical Design
    52. 52. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Implementation Purpose–programming, testing, training, installation, documenting Deliverable–operational programs, documentation, training materials Database activity– database implementation, including coded programs, documentation, installation and conversion Planning Analysis Physical Design Implementation Maintenance Logical Design
    53. 53. Systems Development Life Cycle (see also Figures 2.4, 2.5) (cont.) Maintenance Purpose–monitor, repair, enhance Deliverable–periodic audits Database activity– database maintenance, performance analysis and tuning, error corrections Planning Analysis Physical Design Implementation Maintenance Logical Design
    54. 54. Prototyping Database Methodology (Figure 2.6)
    55. 55. Prototyping Database Methodology (Figure 2.6) (cont.)
    56. 56. Prototyping Database Methodology (Figure 2.6) (cont.)
    57. 57. Prototyping Database Methodology (Figure 2.6) (cont.)
    58. 58. Prototyping Database Methodology (Figure 2.6) (cont.)
    59. 59. CASE <ul><li>Computer-Aided Software Engineering (CASE)–software tools providing automated support for systems development </li></ul><ul><li>Three database features: </li></ul><ul><ul><li>Data modeling–drawing entity-relationship diagrams </li></ul></ul><ul><ul><li>Code generation–SQL code for table creation </li></ul></ul><ul><ul><li>Repositories–knowledge base of enterprise information </li></ul></ul>
    60. 60. Packaged Data Models <ul><li>Model components that can be purchased, customized, and assembled into full-scale data models </li></ul><ul><li>Advantages </li></ul><ul><ul><li>Reduced development time </li></ul></ul><ul><ul><li>Higher model quality and reliability </li></ul></ul><ul><li>Two types: </li></ul><ul><ul><li>Universal data models </li></ul></ul><ul><ul><li>Industry-specific data models </li></ul></ul>
    61. 61. Managing Projects <ul><li>Project–a planned undertaking of related activities to reach an objective that has a beginning and an end </li></ul><ul><li>Involves use of review points for: </li></ul><ul><ul><li>Validation of satisfactory progress </li></ul></ul><ul><ul><li>Step back from detail to overall view </li></ul></ul><ul><ul><li>Renew commitment of stakeholders </li></ul></ul><ul><li>Incremental commitment–review of systems development project after each development phase with rejustification after each phase </li></ul>
    62. 62. Managing Projects: People Involved <ul><li>Business analysts </li></ul><ul><li>Systems analysts </li></ul><ul><li>Database analysts and data modelers </li></ul><ul><li>Users </li></ul><ul><li>Programmers </li></ul><ul><li>Database architects </li></ul><ul><li>Data administrators </li></ul><ul><li>Project managers </li></ul><ul><li>Other technical experts </li></ul>
    63. 63. Database Schema <ul><li>Physical Schema </li></ul><ul><ul><li>Physical structures–covered in Chapters 5 and 6 </li></ul></ul><ul><li>Conceptual Schema </li></ul><ul><ul><li>E-R models–covered in Chapters 3 and 4 </li></ul></ul><ul><li>External Schema </li></ul><ul><ul><li>User Views </li></ul></ul><ul><ul><li>Subsets of Conceptual Schema </li></ul></ul><ul><ul><li>Can be determined from business-function/data entity matrices </li></ul></ul><ul><ul><li>DBA determines schema for different users </li></ul></ul>
    64. 64. Different people have different views of the database…these are the external schema The internal schema is the underlying design and implementation Figure 2-7 Three-schema architecture
    65. 65. Figure 2-8 Developing the three-tiered architecture
    66. 66. Figure 2-9 Three-tiered client/server database architecture
    67. 67. Pine Valley Furniture Segment of project data model (Figure 2-11)
    68. 68. Figure 2-12 Four relations (Pine Valley Furniture)
    69. 69. Figure 2-12 Four relations (Pine Valley Furniture) (cont.)
    70. 70. Chapter 3: Modeling Data in the Organization Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    71. 71. Objectives <ul><li>Definition of terms </li></ul><ul><li>Importance of data modeling </li></ul><ul><li>Write good names and definitions for entities, relationships, and attributes </li></ul><ul><li>Distinguish unary, binary, and ternary relationships </li></ul><ul><li>Model different types of attributes, entities, relationships, and cardinalities </li></ul><ul><li>Draw E-R diagrams for common business situations </li></ul><ul><li>Convert many-to-many relationships to associative entities </li></ul><ul><li>Model time-dependent data using time stamps </li></ul>
    72. 72. Business Rules <ul><li>Statements that define or constrain some aspect of the business </li></ul><ul><li>Assert business structure </li></ul><ul><li>Control/influence business behavior </li></ul><ul><li>Expressed in terms familiar to end users </li></ul><ul><li>Automated through DBMS software </li></ul>
    73. 73. A Good Business Rule is: <ul><li>Declarative–what, not how </li></ul><ul><li>Precise–clear, agreed-upon meaning </li></ul><ul><li>Atomic–one statement </li></ul><ul><li>Consistent–internally and externally </li></ul><ul><li>Expressible–structured, natural language </li></ul><ul><li>Distinct–non-redundant </li></ul><ul><li>Business-oriented–understood by business people </li></ul>
    74. 74. A Good Data Name is: <ul><li>Related to business, not technical, characteristics </li></ul><ul><li>Meaningful and self-documenting </li></ul><ul><li>Unique </li></ul><ul><li>Readable </li></ul><ul><li>Composed of words from an approved list </li></ul><ul><li>Repeatable </li></ul>
    75. 75. Data Definitions <ul><li>Explanation of a term or fact </li></ul><ul><ul><li>Term–word or phrase with specific meaning </li></ul></ul><ul><ul><li>Fact–association between two or more terms </li></ul></ul><ul><li>Guidelines for good data definition </li></ul><ul><ul><li>Gathered in conjunction with systems requirements </li></ul></ul><ul><ul><li>Accompanied by diagrams </li></ul></ul><ul><ul><li>Iteratively created and refined </li></ul></ul><ul><ul><li>Achieved by consensus </li></ul></ul>
    76. 76. E-R Model Constructs <ul><li>Entities: </li></ul><ul><ul><li>Entity instance–person, place, object, event, concept (often corresponds to a row in a table) </li></ul></ul><ul><ul><li>Entity Type–collection of entities (often corresponds to a table) </li></ul></ul><ul><li>Relationships: </li></ul><ul><ul><li>Relationship instance–link between entities (corresponds to primary key-foreign key equivalencies in related tables) </li></ul></ul><ul><ul><li>Relationship type–category of relationship…link between entity types </li></ul></ul><ul><li>Attribute– property or characteristic of an entity or relationship type (often corresponds to a field in a table) </li></ul>
    77. 77. Sample E-R Diagram (Figure 3-1)
    78. 78. Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed Basic E-R notation (Figure 3-2) Entity symbols A special entity that is also a relationship Relationship symbols Attribute symbols
    79. 79. What Should an Entity Be? <ul><li>SHOULD BE: </li></ul><ul><ul><li>An object that will have many instances in the database </li></ul></ul><ul><ul><li>An object that will be composed of multiple attributes </li></ul></ul><ul><ul><li>An object that we are trying to model </li></ul></ul><ul><li>SHOULD NOT BE: </li></ul><ul><ul><li>A user of the database system </li></ul></ul><ul><ul><li>An output of the database system (e.g., a report) </li></ul></ul>
    80. 80. Inappropriate entities Figure 3-4 Example of inappropriate entities System user System output Appropriate entities
    81. 81. Attributes <ul><li>Attribute–property or characteristic of an entity or relationahip type </li></ul><ul><li>Classifications of attributes: </li></ul><ul><ul><li>Required versus Optional Attributes </li></ul></ul><ul><ul><li>Simple versus Composite Attribute </li></ul></ul><ul><ul><li>Single-Valued versus Multivalued Attribute </li></ul></ul><ul><ul><li>Stored versus Derived Attributes </li></ul></ul><ul><ul><li>Identifier Attributes </li></ul></ul>
    82. 82. Identifiers (Keys) <ul><li>Identifier (Key)–An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type </li></ul><ul><li>Simple versus Composite Identifier </li></ul><ul><li>Candidate Identifier–an attribute that could be a key…satisfies the requirements for being an identifier </li></ul>
    83. 83. Characteristics of Identifiers <ul><li>Will not change in value </li></ul><ul><li>Will not be null </li></ul><ul><li>No intelligent identifiers (e.g., containing locations or people that might change) </li></ul><ul><li>Substitute new, simple keys for long, composite keys </li></ul>
    84. 84. Figure 3-7 A composite attribute An attribute broken into component parts Figure 3-8 Entity with multivalued attribute (Skill) and derived attribute (Years_Employed) Multivalued an employee can have more than one skill Derived from date employed and current date
    85. 85. Figure 3-9 Simple and composite identifier attributes The identifier is boldfaced and underlined
    86. 86. Figure 3-19 Simple example of time-stamping This attribute that is both multivalued and composite
    87. 87. More on Relationships <ul><li>Relationship Types vs. Relationship Instances </li></ul><ul><ul><li>The relationship type is modeled as lines between entity types…the instance is between specific entity instances </li></ul></ul><ul><li>Relationships can have attributes </li></ul><ul><ul><li>These describe features pertaining to the association between the entities in the relationship </li></ul></ul><ul><li>Two entities can have more than one type of relationship between them (multiple relationships) </li></ul><ul><li>Associative Entity–combination of relationship and entity </li></ul>
    88. 88. Figure 3-10 Relationship types and instances a) Relationship type b) Relationship instances
    89. 89. Degree of Relationships <ul><li>Degree of a relationship is the number of entity types that participate in it </li></ul><ul><ul><li>Unary Relationship </li></ul></ul><ul><ul><li>Binary Relationship </li></ul></ul><ul><ul><li>Ternary Relationship </li></ul></ul>
    90. 90. Degree of relationships – from Figure 3-2 Entities of two different types related to each other Entities of three different types related to each other One entity related to another of the same entity type
    91. 91. Cardinality of Relationships <ul><li>One-to-One </li></ul><ul><ul><li>Each entity in the relationship will have exactly one related entity </li></ul></ul><ul><li>One-to-Many </li></ul><ul><ul><li>An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity </li></ul></ul><ul><li>Many-to-Many </li></ul><ul><ul><li>Entities on both sides of the relationship can have many related entities on the other side </li></ul></ul>
    92. 92. Cardinality Constraints <ul><li>Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity </li></ul><ul><li>Minimum Cardinality </li></ul><ul><ul><li>If zero, then optional </li></ul></ul><ul><ul><li>If one or more, then mandatory </li></ul></ul><ul><li>Maximum Cardinality </li></ul><ul><ul><li>The maximum number </li></ul></ul>
    93. 93. Figure 3-12 Examples of relationships of different degrees a) Unary relationships
    94. 94. Figure 3-12 Examples of relationships of different degrees (cont.) b) Binary relationships
    95. 95. Figure 3-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own
    96. 96. Figure 3-17 Examples of cardinality constraints a) Mandatory cardinalities A patient must have recorded at least one history, and can have many A patient history is recorded for one and only one patient
    97. 97. Figure 3-17 Examples of cardinality constraints (cont.) b) One optional, one mandatory An employee can be assigned to any number of projects, or may not be assigned to any at all A project must be assigned to at least one employee, and may be assigned to many
    98. 98. Figure 3-17 Examples of cardinality constraints (cont.) a) Optional cardinalities A person is is married to at most one other person, or may not be married at all
    99. 99. Entities can be related to one another in more than one way Figure 3-21 Examples of multiple relationships a) Employees and departments
    100. 100. Figure 3-21 Examples of multiple relationships (cont.) b) Professors and courses (fixed lower limit constraint) Here, min cardinality constraint is 2
    101. 101. Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships simple composite
    102. 102. Strong vs. Weak Entities, and Identifying Relationships <ul><li>Strong entities </li></ul><ul><ul><li>exist independently of other types of entities </li></ul></ul><ul><ul><li>has its own unique identifier </li></ul></ul><ul><ul><li>identifier underlined with single-line </li></ul></ul><ul><li>Weak entity </li></ul><ul><ul><li>dependent on a strong entity (identifying owner)…cannot exist on its own </li></ul></ul><ul><ul><li>does not have a unique identifier (only a partial identifier) </li></ul></ul><ul><ul><li>Partial identifier underlined with double-line </li></ul></ul><ul><ul><li>Entity box has double line </li></ul></ul><ul><li>Identifying relationship </li></ul><ul><ul><li>links strong entities to weak entities </li></ul></ul>
    103. 103. Strong entity Weak entity Identifying relationship
    104. 104. Associative Entities <ul><li>An entity –has attributes </li></ul><ul><li>A relationship –links entities together </li></ul><ul><li>When should a relationship with attributes instead be an associative entity ? </li></ul><ul><ul><li>All relationships for the associative entity should be many </li></ul></ul><ul><ul><li>The associative entity could have meaning independent of the other entities </li></ul></ul><ul><ul><li>The associative entity preferably has a unique identifier, and should also have other attributes </li></ul></ul><ul><ul><li>The associative entity may participate in other relationships other than the entities of the associated relationship </li></ul></ul><ul><ul><li>Ternary relationships should be converted to associative entities </li></ul></ul>
    105. 105. Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship
    106. 106. Figure 3-11b An associative entity (CERTIFICATE) Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right. Note that the many-to-many cardinality between entities in Figure 3-11a has been replaced by two one-to-many relationships with the associative entity.
    107. 107. Figure 3-13c An associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call
    108. 108. Figure 3-18 Ternary relationship as an associative entity
    109. 109. Microsoft Visio Example for E-R diagram Different modeling software tools may have different notation for the same constructs
    110. 110. Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    111. 111. Objectives <ul><li>Definition of terms </li></ul><ul><li>Use of supertype/subtype relationships </li></ul><ul><li>Use of generalization and specialization techniques </li></ul><ul><li>Specification of completeness and disjointness constraints </li></ul><ul><li>Develop supertype/subtype hierarchies for realistic business situations </li></ul><ul><li>Develop entity clusters </li></ul><ul><li>Explain universal data model </li></ul><ul><li>Name categories of business rules </li></ul><ul><li>Define operational constraints graphically and in English </li></ul>
    112. 112. Supertypes and Subtypes <ul><li>Subtype: A subgrouping of the entities in an entity type that has attributes distinct from those in other subgroupings </li></ul><ul><li>Supertype: A generic entity type that has a relationship with one or more subtypes </li></ul><ul><li>Attribute Inheritance: </li></ul><ul><ul><li>Subtype entities inherit values of all attributes of the supertype </li></ul></ul><ul><ul><li>An instance of a subtype is also an instance of the supertype </li></ul></ul>
    113. 113. Figure 4-1 Basic notation for supertype/subtype notation a) EER notation
    114. 114. Different modeling tools may have different notation for the same modeling constructs b) Microsoft Visio Notation Figure 4-1 Basic notation for supertype/subtype notation (cont.)
    115. 115. Figure 4-2 Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired Each employee subtype will also have its own attributes
    116. 116. Relationships and Subtypes <ul><li>Relationships at the supertype level indicate that all subtypes will participate in the relationship </li></ul><ul><li>The instances of a subtype may participate in a relationship unique to that subtype. In this situation, the relationship is shown at the subtype level </li></ul>
    117. 117. Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed
    118. 118. Generalization and Specialization <ul><li>Generalization: The process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UP </li></ul><ul><li>Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships. TOP-DOWN </li></ul>
    119. 119. Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes
    120. 120. Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycle, since it has no unique attributes b) Generalization to VEHICLE supertype
    121. 121. Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts
    122. 122. b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) Note: multivalued attribute was replaced by an associative entity relationship to another entity
    123. 123. Constraints in Supertype/ Completeness Constraint <ul><li>Completeness Constraints : Whether an instance of a supertype must also be a member of at least one subtype </li></ul><ul><ul><li>Total Specialization Rule: Yes (double line) </li></ul></ul><ul><ul><li>Partial Specialization Rule: No (single line) </li></ul></ul>
    124. 124. Figure 4-6 Examples of completeness constraints a) Total specialization rule A patient must be either an outpatient or a resident patient
    125. 125. b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, or neither
    126. 126. Constraints in Supertype/ Disjointness constraint <ul><li>Disjointness Constraints : Whether an instance of a supertype may simultaneously be a member of two (or more) subtypes </li></ul><ul><ul><li>Disjoint Rule: An instance of the supertype can be only ONE of the subtypes </li></ul></ul><ul><ul><li>Overlap Rule: An instance of the supertype could be more than one of the subtypes </li></ul></ul>
    127. 127. a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not both
    128. 128. b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured
    129. 129. Constraints in Supertype/ Subtype Discriminators <ul><li>Subtype Discriminator : An attribute of the supertype whose values determine the target subtype(s) </li></ul><ul><ul><li>Disjoint – a simple attribute with alternative values to indicate the possible subtypes </li></ul></ul><ul><ul><li>Overlapping – a composite attribute whose subparts pertain to different subtypes. Each subpart contains a boolean value to indicate whether or not the instance belongs to the associated subtype </li></ul></ul>
    130. 130. Figure 4-8 Introducing a subtype discriminator ( disjoint rule) A simple attribute with different possible values indicating the subtype
    131. 131. Figure 4-9 Subtype discriminator ( overlap rule) A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype
    132. 132. Figure 4-10 Example of supertype/subtype hierarchy
    133. 133. Entity Clusters <ul><li>EER diagrams are difficult to read when there are too many entities and relationships </li></ul><ul><li>Solution: Group entities and relationships into entity clusters </li></ul><ul><li>Entity cluster : Set of one or more entity types and associated relationships grouped into a single abstract entity type </li></ul>
    134. 134. Figure 4-13a Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could become clusters
    135. 135. Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?
    136. 136. Figure 4-14 Manufacturing entity cluster Detail for a single cluster
    137. 137. Chapter 4: The Enhanced ER Model and Business Rules Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    138. 138. Objectives <ul><li>Definition of terms </li></ul><ul><li>Use of supertype/subtype relationships </li></ul><ul><li>Use of generalization and specialization techniques </li></ul><ul><li>Specification of completeness and disjointness constraints </li></ul><ul><li>Develop supertype/subtype hierarchies for realistic business situations </li></ul><ul><li>Develop entity clusters </li></ul><ul><li>Explain universal data model </li></ul><ul><li>Name categories of business rules </li></ul><ul><li>Define operational constraints graphically and in English </li></ul>
    139. 139. Supertypes and Subtypes <ul><li>Subtype: A subgrouping of the entities in an entity type that has attributes distinct from those in other subgroupings </li></ul><ul><li>Supertype: A generic entity type that has a relationship with one or more subtypes </li></ul><ul><li>Attribute Inheritance: </li></ul><ul><ul><li>Subtype entities inherit values of all attributes of the supertype </li></ul></ul><ul><ul><li>An instance of a subtype is also an instance of the supertype </li></ul></ul>
    140. 140. Figure 4-1 Basic notation for supertype/subtype notation a) EER notation
    141. 141. Different modeling tools may have different notation for the same modeling constructs b) Microsoft Visio Notation Figure 4-1 Basic notation for supertype/subtype notation (cont.)
    142. 142. Figure 4-2 Employee supertype with three subtypes All employee subtypes will have emp nbr, name, address, and date-hired Each employee subtype will also have its own attributes
    143. 143. Relationships and Subtypes <ul><li>Relationships at the supertype level indicate that all subtypes will participate in the relationship </li></ul><ul><li>The instances of a subtype may participate in a relationship unique to that subtype. In this situation, the relationship is shown at the subtype level </li></ul>
    144. 144. Figure 4-3 Supertype/subtype relationships in a hospital Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed
    145. 145. Generalization and Specialization <ul><li>Generalization: The process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UP </li></ul><ul><li>Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships. TOP-DOWN </li></ul>
    146. 146. Figure 4-4 Example of generalization a) Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes
    147. 147. Figure 4-4 Example of generalization (cont.) So we put the shared attributes in a supertype Note: no subtype for motorcycle, since it has no unique attributes b) Generalization to VEHICLE supertype
    148. 148. Figure 4-5 Example of specialization a) Entity type PART Only applies to manufactured parts Applies only to purchased parts
    149. 149. b) Specialization to MANUFACTURED PART and PURCHASED PART Created 2 subtypes Figure 4-5 Example of specialization (cont.) Note: multivalued attribute was replaced by an associative entity relationship to another entity
    150. 150. Constraints in Supertype/ Completeness Constraint <ul><li>Completeness Constraints : Whether an instance of a supertype must also be a member of at least one subtype </li></ul><ul><ul><li>Total Specialization Rule: Yes (double line) </li></ul></ul><ul><ul><li>Partial Specialization Rule: No (single line) </li></ul></ul>
    151. 151. Figure 4-6 Examples of completeness constraints a) Total specialization rule A patient must be either an outpatient or a resident patient
    152. 152. b) Partial specialization rule Figure 4-6 Examples of completeness constraints (cont.) A vehicle could be a car, a truck, or neither
    153. 153. Constraints in Supertype/ Disjointness constraint <ul><li>Disjointness Constraints : Whether an instance of a supertype may simultaneously be a member of two (or more) subtypes </li></ul><ul><ul><li>Disjoint Rule: An instance of the supertype can be only ONE of the subtypes </li></ul></ul><ul><ul><li>Overlap Rule: An instance of the supertype could be more than one of the subtypes </li></ul></ul>
    154. 154. a) Disjoint rule Figure 4-7 Examples of disjointness constraints A patient can either be outpatient or resident, but not both
    155. 155. b) Overlap rule Figure 4-7 Examples of disjointness constraints (cont.) A part may be both purchased and manufactured
    156. 156. Constraints in Supertype/ Subtype Discriminators <ul><li>Subtype Discriminator : An attribute of the supertype whose values determine the target subtype(s) </li></ul><ul><ul><li>Disjoint – a simple attribute with alternative values to indicate the possible subtypes </li></ul></ul><ul><ul><li>Overlapping – a composite attribute whose subparts pertain to different subtypes. Each subpart contains a boolean value to indicate whether or not the instance belongs to the associated subtype </li></ul></ul>
    157. 157. Figure 4-8 Introducing a subtype discriminator ( disjoint rule) A simple attribute with different possible values indicating the subtype
    158. 158. Figure 4-9 Subtype discriminator ( overlap rule) A composite attribute with sub-attributes indicating “yes” or “no” to determine whether it is of each subtype
    159. 159. Figure 4-10 Example of supertype/subtype hierarchy
    160. 160. Entity Clusters <ul><li>EER diagrams are difficult to read when there are too many entities and relationships </li></ul><ul><li>Solution: Group entities and relationships into entity clusters </li></ul><ul><li>Entity cluster : Set of one or more entity types and associated relationships grouped into a single abstract entity type </li></ul>
    161. 161. Figure 4-13a Possible entity clusters for Pine Valley Furniture in Microsoft Visio Related groups of entities could become clusters
    162. 162. Figure 4-13b EER diagram of PVF entity clusters More readable, isn’t it?
    163. 163. Figure 4-14 Manufacturing entity cluster Detail for a single cluster
    164. 164. Packaged data models provide generic models that can be customized for a particular organization’s business rules
    165. 165. Business rules <ul><li>Statements that define or constrain some aspect of the business </li></ul><ul><li>Classification of business rules: </li></ul><ul><ul><li>Derivation–rule derived from other knowledge, often in the form of a formula using attribute values </li></ul></ul><ul><ul><li>Structural assertion–rule expressing static structure. Includes attributes, relationships, and definitions </li></ul></ul><ul><ul><li>Action assertion–rule expressing constraints/control of organizational actions </li></ul></ul>
    166. 166. Figure 4-18 EER diagram to describe business rules
    167. 167. Types of Action Assertions <ul><li>Result </li></ul><ul><ul><li>Condition–IF/THEN rule </li></ul></ul><ul><ul><li>Integrity constraint–must always be true </li></ul></ul><ul><ul><li>Authorization–privilege statement </li></ul></ul><ul><li>Form </li></ul><ul><ul><li>Enabler–leads to creation of new object </li></ul></ul><ul><ul><li>Timer–allows or disallows an action </li></ul></ul><ul><ul><li>Executive–executes one or more actions </li></ul></ul><ul><li>Rigor </li></ul><ul><ul><li>Controlling–something must or must not happen </li></ul></ul><ul><ul><li>Influencing–guideline for which a notification must occur </li></ul></ul>
    168. 168. Stating an Action Assertion <ul><li>Anchor Object–an object on which actions are limited </li></ul><ul><li>Action–creation, deletion, update, or read </li></ul><ul><li>Corresponding Objects–an object influencing the ability to perform an action on another business rule </li></ul>Action assertions identify corresponding objects that constrain the ability to perform actions on anchor objects
    169. 169. Figure 4-19 Data model segment for class scheduling
    170. 170. Figure 4-20 Business Rule 1: For a faculty member to be assigned to teach a section of a course, the faculty member must be qualified to teach the course for which that section is scheduled Action assertion Anchor object Corresponding object Corresponding object In this case, the action assertion is a R estriction
    171. 171. Figure 4-21 Business Rule 2: For a faculty member to be assigned to teach a section of a course, the faculty member must not be assigned to teach a total of more than three course sections Action assertion Anchor object Corresponding object In this case, the action assertion is an U pper LIM it
    172. 172. Chapter 5: Logical Database Design and the Relational Model Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    173. 173. Objectives <ul><li>Definition of terms </li></ul><ul><li>List five properties of relations </li></ul><ul><li>State two properties of candidate keys </li></ul><ul><li>Define first, second, and third normal form </li></ul><ul><li>Describe problems from merging relations </li></ul><ul><li>Transform E-R and EER diagrams to relations </li></ul><ul><li>Create tables with entity and relational integrity constraints </li></ul><ul><li>Use normalization to convert anomalous tables to well-structured relations </li></ul>
    174. 174. Relation <ul><li>Definition: A relation is a named, two-dimensional table of data </li></ul><ul><li>Table consists of rows (records) and columns (attribute or field) </li></ul><ul><li>Requirements for a table to qualify as a relation: </li></ul><ul><ul><li>It must have a unique name </li></ul></ul><ul><ul><li>Every attribute value must be atomic (not multivalued, not composite) </li></ul></ul><ul><ul><li>Every row must be unique (can’t have two rows with exactly the same values for all their fields) </li></ul></ul><ul><ul><li>Attributes (columns) in tables must have unique names </li></ul></ul><ul><ul><li>The order of the columns must be irrelevant </li></ul></ul><ul><ul><li>The order of the rows must be irrelevant </li></ul></ul><ul><li>NOTE: all relations are in 1 st Normal form </li></ul>
    175. 175. Correspondence with E-R Model <ul><li>Relations (tables) correspond with entity types and with many-to-many relationship types </li></ul><ul><li>Rows correspond with entity instances and with many-to-many relationship instances </li></ul><ul><li>Columns correspond with attributes </li></ul><ul><li>NOTE: The word relation (in relational database) is NOT the same as the word relationship (in E-R model) </li></ul>
    176. 176. Key Fields <ul><li>Keys are special fields that serve two main purposes: </li></ul><ul><ul><li>Primary keys are unique identifiers of the relation in question. Examples include employee numbers, social security numbers, etc. This is how we can guarantee that all rows are unique </li></ul></ul><ul><ul><li>Foreign keys are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship) </li></ul></ul><ul><li>Keys can be simple (a single field) or composite (more than one field) </li></ul><ul><li>Keys usually are used as indexes to speed up the response to user queries (More on this in Ch. 6) </li></ul>
    177. 177. Figure 5-3 Schema for four relations (Pine Valley Furniture Company) Primary Key Foreign Key (implements 1:N relationship between customer and order) Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)
    178. 178. Integrity Constraints <ul><li>Domain Constraints </li></ul><ul><ul><li>Allowable values for an attribute. See Table 5-1 </li></ul></ul><ul><li>Entity Integrity </li></ul><ul><ul><li>No primary key attribute may be null. All primary key fields MUST have data </li></ul></ul><ul><li>Action Assertions </li></ul><ul><ul><li>Business rules. Recall from Ch. 4 </li></ul></ul>
    179. 179. Domain definitions enforce domain integrity constraints
    180. 180. Integrity Constraints <ul><li>Referential Integrity–rule states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null) </li></ul><ul><ul><li>For example: Delete Rules </li></ul></ul><ul><ul><ul><li>Restrict–don’t allow delete of “parent” side if related rows exist in “dependent” side </li></ul></ul></ul><ul><ul><ul><li>Cascade–automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted </li></ul></ul></ul><ul><ul><ul><li>Set-to-Null–set the foreign key in the dependent side to null if deleting from the parent side  not allowed for weak entities </li></ul></ul></ul>
    181. 181. Figure 5-5 Referential integrity constraints (Pine Valley Furniture) Referential integrity constraints are drawn via arrows from dependent to parent table
    182. 182. Figure 5-6 SQL table definitions Referential integrity constraints are implemented with foreign key to primary key references
    183. 183. Transforming EER Diagrams into Relations <ul><li>Mapping Regular Entities to Relations </li></ul><ul><ul><li>Simple attributes: E-R attributes map directly onto the relation </li></ul></ul><ul><ul><li>Composite attributes: Use only their simple, component attributes </li></ul></ul><ul><ul><li>Multivalued Attribute–Becomes a separate relation with a foreign key taken from the superior entity </li></ul></ul>
    184. 184. (a) CUSTOMER entity type with simple attributes Figure 5-8 Mapping a regular entity (b) CUSTOMER relation
    185. 185. (a) CUSTOMER entity type with composite attribute Figure 5-9 Mapping a composite attribute (b) CUSTOMER relation with address detail
    186. 186. Figure 5-10 Mapping an entity with a multivalued attribute One–to–many relationship between original entity and new relation (a) Multivalued attribute becomes a separate relation with foreign key (b)
    187. 187. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Weak Entities </li></ul><ul><ul><li>Becomes a separate relation with a foreign key taken from the superior entity </li></ul></ul><ul><ul><li>Primary key composed of: </li></ul></ul><ul><ul><ul><li>Partial identifier of weak entity </li></ul></ul></ul><ul><ul><ul><li>Primary key of identifying relation (strong entity) </li></ul></ul></ul>
    188. 188. Figure 5-11 Example of mapping a weak entity a) Weak entity DEPENDENT
    189. 189. NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Figure 5-11 Example of mapping a weak entity (cont.) b) Relations resulting from weak entity Composite primary key
    190. 190. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Binary Relationships </li></ul><ul><ul><li>One-to-Many–Primary key on the one side becomes a foreign key on the many side </li></ul></ul><ul><ul><li>Many-to-Many–Create a new relation with the primary keys of the two entities as its primary key </li></ul></ul><ul><ul><li>One-to-One–Primary key on the mandatory side becomes a foreign key on the optional side </li></ul></ul>
    191. 191. Figure 5-12 Example of mapping a 1:M relationship a) Relationship between customers and orders Note the mandatory one Again, no null value in the foreign key…this is because of the mandatory minimum cardinality Foreign key b) Mapping the relationship
    192. 192. Figure 5-13 Example of mapping an M:N relationship a) Completes relationship (M:N) The Completes relationship will need to become a separate relation
    193. 193. New intersection relation Figure 5-13 Example of mapping an M:N relationship (cont.) b) Three resulting relations Foreign key Foreign key Composite primary key
    194. 194. Figure 5-14 Example of mapping a binary 1:1 relationship a) In_charge relationship (1:1) Often in 1:1 relationships, one direction is optional.
    195. 195. b) Resulting relations Figure 5-14 Example of mapping a binary 1:1 relationship (cont.) Foreign key goes in the relation on the optional side, Matching the primary key on the mandatory side
    196. 196. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Associative Entities </li></ul><ul><ul><li>Identifier Not Assigned </li></ul></ul><ul><ul><ul><li>Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship) </li></ul></ul></ul><ul><ul><li>Identifier Assigned </li></ul></ul><ul><ul><ul><li>It is natural and familiar to end-users </li></ul></ul></ul><ul><ul><ul><li>Default identifier may not be unique </li></ul></ul></ul>
    197. 197. Figure 5-15 Example of mapping an associative entity a) An associative entity
    198. 198. Figure 5-15 Example of mapping an associative entity (cont.) b) Three resulting relations Composite primary key formed from the two foreign keys
    199. 199. Figure 5-16 Example of mapping an associative entity with an identifier a) SHIPMENT associative entity
    200. 200. Figure 5-16 Example of mapping an associative entity with an identifier (cont.) b) Three resulting relations Primary key differs from foreign keys
    201. 201. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Unary Relationships </li></ul><ul><ul><li>One-to-Many–Recursive foreign key in the same relation </li></ul></ul><ul><ul><li>Many-to-Many–Two relations: </li></ul></ul><ul><ul><ul><li>One for the entity type </li></ul></ul></ul><ul><ul><ul><li>One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity </li></ul></ul></ul>
    202. 202. Figure 5-17 Mapping a unary 1:N relationship (a) EMPLOYEE entity with unary relationship (b) EMPLOYEE relation with recursive foreign key
    203. 203. Figure 5-18 Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations
    204. 204. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Ternary (and n-ary) Relationships </li></ul><ul><ul><li>One relation for each entity and one for the associative entity </li></ul></ul><ul><ul><li>Associative entity has foreign keys to each entity in the relationship </li></ul></ul>
    205. 205. Figure 5-19 Mapping a ternary relationship a) PATIENT TREATMENT Ternary relationship with associative entity
    206. 206. b) Mapping the ternary relationship PATIENT TREATMENT Remember that the primary key MUST be unique Figure 5-19 Mapping a ternary relationship (cont.) This is why treatment date and time are included in the composite primary key But this makes a very cumbersome key… It would be better to create a surrogate key like Treatment#
    207. 207. Transforming EER Diagrams into Relations (cont.) <ul><li>Mapping Supertype/Subtype Relationships </li></ul><ul><ul><li>One relation for supertype and for each subtype </li></ul></ul><ul><ul><li>Supertype attributes (including identifier and subtype discriminator) go into supertype relation </li></ul></ul><ul><ul><li>Subtype attributes go into each subtype; primary key of supertype relation also becomes primary key of subtype relation </li></ul></ul><ul><ul><li>1:1 relationship established between supertype and each subtype, with supertype as primary table </li></ul></ul>
    208. 208. Figure 5-20 Supertype/subtype relationships
    209. 209. Figure 5-21 Mapping Supertype/subtype relationships to relations These are implemented as one-to-one relationships
    210. 210. Data Normalization <ul><li>Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data </li></ul><ul><li>The process of decomposing relations with anomalies to produce smaller, well-structured relations </li></ul>
    211. 211. Well-Structured Relations <ul><li>A relation that contains minimal data redundancy and allows users to insert, delete, and update rows without causing data inconsistencies </li></ul><ul><li>Goal is to avoid anomalies </li></ul><ul><ul><li>Insertion Anomaly –adding new rows forces user to create duplicate data </li></ul></ul><ul><ul><li>Deletion Anomaly –deleting rows may cause a loss of data that would be needed for other future rows </li></ul></ul><ul><ul><li>Modification Anomaly –changing data in a row forces changes to other rows because of duplication </li></ul></ul>General rule of thumb: A table should not pertain to more than one entity type
    212. 212. Example–Figure 5-2b Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title
    213. 213. Anomalies in this Table <ul><li>Insertion –can’t enter a new employee without having the employee take a class </li></ul><ul><li>Deletion –if we remove employee 140, we lose information about the existence of a Tax Acc class </li></ul><ul><li>Modification –giving a salary increase to employee 100 forces us to update multiple records </li></ul><ul><li>Why do these anomalies exist? </li></ul><ul><ul><li>Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities </li></ul></ul>
    214. 214. Functional Dependencies and Keys <ul><li>Functional Dependency: The value of one attribute (the determinant ) determines the value of another attribute </li></ul><ul><li>Candidate Key: </li></ul><ul><ul><li>A unique identifier. One of the candidate keys will become the primary key </li></ul></ul><ul><ul><ul><li>E.g. perhaps there is both credit card number and SS# in a table…in this case both are candidate keys </li></ul></ul></ul><ul><ul><li>Each non-key field is functionally dependent on every candidate key </li></ul></ul>
    215. 215. Figure 5.22 Steps in normalization
    216. 216. First Normal Form <ul><li>No multivalued attributes </li></ul><ul><li>Every attribute value is atomic </li></ul><ul><li>Fig. 5-25 is not in 1 st Normal Form (multivalued attributes)  it is not a relation </li></ul><ul><li>Fig. 5-26 is in 1 st Normal form </li></ul><ul><li>All relations are in 1 st Normal Form </li></ul>
    217. 217. Table with multivalued attributes, not in 1 st normal form Note: this is NOT a relation
    218. 218. Table with no multivalued attributes and unique rows, in 1 st normal form Note: this is relation, but not a well-structured one
    219. 219. Anomalies in this Table <ul><li>Insertion –if new product is ordered for order 1007 of existing customer, customer data must be re-entered, causing duplication </li></ul><ul><li>Deletion –if we delete the Dining Table from Order 1006, we lose information concerning this item's finish and price </li></ul><ul><li>Update –changing the price of product ID 4 requires update in several records </li></ul><ul><li>Why do these anomalies exist? </li></ul><ul><ul><li>Because there are multiple themes (entity types) in one relation. This results in duplication and an unnecessary dependency between the entities </li></ul></ul>
    220. 220. Second Normal Form <ul><li>1NF PLUS every non-key attribute is fully functionally dependent on the ENTIRE primary key </li></ul><ul><ul><li>Every non-key attribute must be defined by the entire key, not by only part of the key </li></ul></ul><ul><ul><li>No partial functional dependencies </li></ul></ul>
    221. 221. Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address Therefore, NOT in 2 nd Normal Form Customer_ID  Customer_Name, Customer_Address Product_ID  Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID  Order_Quantity Figure 5-27 Functional dependency diagram for INVOICE
    222. 222. Partial dependencies are removed, but there are still transitive dependencies Getting it into Second Normal Form Figure 5-28 Removing partial dependencies
    223. 223. Third Normal Form <ul><li>2NF PLUS no transitive dependencies (functional dependencies on non-primary-key attributes) </li></ul><ul><li>Note: This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third </li></ul><ul><li>Solution: Non-key determinant with transitive dependencies go into a new table; non-key determinant becomes primary key in the new table and stays as foreign key in the old table </li></ul>
    224. 224. Transitive dependencies are removed Figure 5-28 Removing partial dependencies Getting it into Third Normal Form
    225. 225. Merging Relations <ul><li>View Integration–Combining entities from multiple ER models into common relations </li></ul><ul><li>Issues to watch out for when merging entities from different ER models: </li></ul><ul><ul><li>Synonyms–two or more attributes with different names but same meaning </li></ul></ul><ul><ul><li>Homonyms–attributes with same name but different meanings </li></ul></ul><ul><ul><li>Transitive dependencies–even if relations are in 3NF prior to merging, they may not be after merging </li></ul></ul><ul><ul><li>Supertype/subtype relationships–may be hidden prior to merging </li></ul></ul>
    226. 226. Enterprise Keys <ul><li>Primary keys that are unique in the whole database, not just within a single relation </li></ul><ul><li>Corresponds with the concept of an object ID in object-oriented systems </li></ul>
    227. 227. Figure 5-31 Enterprise keys a) Relations with enterprise key b) Sample data with enterprise key
    228. 228. Chapter 6: Physical Database Design and Performance Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    229. 229. Objectives <ul><li>Definition of terms </li></ul><ul><li>Describe the physical database design process </li></ul><ul><li>Choose storage formats for attributes </li></ul><ul><li>Select appropriate file organizations </li></ul><ul><li>Describe three types of file organization </li></ul><ul><li>Describe indexes and their appropriate use </li></ul><ul><li>Translate a database model into efficient structures </li></ul><ul><li>Know when and how to use denormalization </li></ul>
    230. 230. Physical Database Design <ul><li>Purpose–translate the logical description of data into the technical specifications for storing and retrieving data </li></ul><ul><li>Goal–create a design for storing data that will provide adequate performance and insure database integrity , security , and recoverability </li></ul>
    231. 231. Physical Design Process <ul><li>Normalized relations </li></ul><ul><li>Volume estimates </li></ul><ul><li>Attribute definitions </li></ul><ul><li>Response time expectations </li></ul><ul><li>Data security needs </li></ul><ul><li>Backup/recovery needs </li></ul><ul><li>Integrity expectations </li></ul><ul><li>DBMS technology used </li></ul>Inputs <ul><li>Attribute data types </li></ul><ul><li>Physical record descriptions (doesn’t always match logical design) </li></ul><ul><li>File organizations </li></ul><ul><li>Indexes and database architectures </li></ul><ul><li>Query optimization </li></ul>Leads to Decisions
    232. 232. Figure 6-1 Composite usage map (Pine Valley Furniture Company)
    233. 233. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Data volumes
    234. 234. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Access Frequencies (per hour)
    235. 235. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 140 purchased parts accessed per hour  80 quotations accessed from these 140 purchased part accesses  70 suppliers accessed from these 80 quotation accesses
    236. 236. Figure 6-1 Composite usage map (Pine Valley Furniture Company) (cont.) Usage analysis: 75 suppliers accessed per hour  40 quotations accessed from these 75 supplier accesses  40 purchased parts accessed from these 40 quotation accesses
    237. 237. Designing Fields <ul><li>Field: smallest unit of data in database </li></ul><ul><li>Field design </li></ul><ul><ul><li>Choosing data type </li></ul></ul><ul><ul><li>Coding, compression, encryption </li></ul></ul><ul><ul><li>Controlling data integrity </li></ul></ul>
    238. 238. Choosing Data Types <ul><li>CHAR–fixed-length character </li></ul><ul><li>VARCHAR2–variable-length character (memo) </li></ul><ul><li>LONG–large number </li></ul><ul><li>NUMBER–positive/negative number </li></ul><ul><li>INEGER–positive/negative whole number </li></ul><ul><li>DATE–actual date </li></ul><ul><li>BLOB–binary large object (good for graphics, sound clips, etc.) </li></ul>
    239. 239. Figure 6-2 Example code look-up table (Pine Valley Furniture Company) Code saves space, but costs an additional lookup to obtain actual value
    240. 240. Field Data Integrity <ul><li>Default value–assumed value if no explicit value </li></ul><ul><li>Range control–allowable value limitations (constraints or validation rules) </li></ul><ul><li>Null value control–allowing or prohibiting empty fields </li></ul><ul><li>Referential integrity–range control (and null value allowances) for foreign-key to primary-key match-ups </li></ul>Sarbanes-Oxley Act (SOX) legislates importance of financial data integrity
    241. 241. Handling Missing Data <ul><li>Substitute an estimate of the missing value (e.g., using a formula) </li></ul><ul><li>Construct a report listing missing values </li></ul><ul><li>In programs, ignore missing data unless the value is significant (sensitivity testing) </li></ul>Triggers can be used to perform these operations
    242. 242. Physical Records <ul><li>Physical Record: A group of fields stored in adjacent memory locations and retrieved together as a unit </li></ul><ul><li>Page: The amount of data read or written in one I/O operation </li></ul><ul><li>Blocking Factor: The number of physical records per page </li></ul>
    243. 243. Denormalization <ul><li>Transforming normalized relations into unnormalized physical record specifications </li></ul><ul><li>Benefits: </li></ul><ul><ul><li>Can improve performance (speed) by reducing number of table lookups (i.e. reduce number of necessary join queries ) </li></ul></ul><ul><li>Costs (due to data duplication) </li></ul><ul><ul><li>Wasted storage space </li></ul></ul><ul><ul><li>Data integrity/consistency threats </li></ul></ul><ul><li>Common denormalization opportunities </li></ul><ul><ul><li>One-to-one relationship (Fig. 6-3) </li></ul></ul><ul><ul><li>Many-to-many relationship with attributes (Fig. 6-4) </li></ul></ul><ul><ul><li>Reference data (1:N relationship where 1-side has data not used in any other relationship) (Fig. 6-5) </li></ul></ul>
    244. 244. Figure 6-3 A possible denormalization situation: two entities with one-to-one relationship
    245. 245. Figure 6-4 A possible denormalization situation: a many-to-many relationship with nonkey attributes Extra table access required Null description possible
    246. 246. Figure 6-5 A possible denormalization situation: reference data Extra table access required Data duplication
    247. 247. Partitioning <ul><li>Horizontal Partitioning: Distributing the rows of a table into several separate files </li></ul><ul><ul><li>Useful for situations where different users need access to different rows </li></ul></ul><ul><ul><li>Three types: Key Range Partitioning, Hash Partitioning, or Composite Partitioning </li></ul></ul><ul><li>Vertical Partitioning: Distributing the columns of a table into several separate relations </li></ul><ul><ul><li>Useful for situations where different users need access to different columns </li></ul></ul><ul><ul><li>The primary key must be repeated in each file </li></ul></ul><ul><li>Combinations of Horizontal and Vertical </li></ul>Partitions often correspond with User Schemas (user views)
    248. 248. Partitioning (cont.) <ul><li>Advantages of Partitioning: </li></ul><ul><ul><li>Efficiency: Records used together are grouped together </li></ul></ul><ul><ul><li>Local optimization: Each partition can be optimized for performance </li></ul></ul><ul><ul><li>Security, recovery </li></ul></ul><ul><ul><li>Load balancing: Partitions stored on different disks, reduces contention </li></ul></ul><ul><ul><li>Take advantage of parallel processing capability </li></ul></ul><ul><li>Disadvantages of Partitioning: </li></ul><ul><ul><li>Inconsistent access speed: Slow retrievals across partitions </li></ul></ul><ul><ul><li>Complexity: Non-transparent partitioning </li></ul></ul><ul><ul><li>Extra space or update time: Duplicate data; access from multiple partitions </li></ul></ul>
    249. 249. Data Replication <ul><li>Purposely storing the same data in multiple locations of the database </li></ul><ul><li>Improves performance by allowing multiple users to access the same data at the same time with minimum contention </li></ul><ul><li>Sacrifices data integrity due to data duplication </li></ul><ul><li>Best for data that is not updated often </li></ul>
    250. 250. Designing Physical Files <ul><li>Physical File: </li></ul><ul><ul><li>A named portion of secondary memory allocated for the purpose of storing physical records </li></ul></ul><ul><ul><li>Tablespace–named set of disk storage elements in which physical files for database tables can be stored </li></ul></ul><ul><ul><li>Extent–contiguous section of disk space </li></ul></ul><ul><li>Constructs to link two pieces of data: </li></ul><ul><ul><li>Sequential storage </li></ul></ul><ul><ul><li>Pointers–field of data that can be used to locate related fields or records </li></ul></ul>
    251. 251. Figure 6-4 Physical file terminology in an Oracle environment
    252. 252. File Organizations <ul><li>Technique for physically arranging records of a file on secondary storage </li></ul><ul><li>Factors for selecting file organization: </li></ul><ul><ul><li>Fast data retrieval and throughput </li></ul></ul><ul><ul><li>Efficient storage space utilization </li></ul></ul><ul><ul><li>Protection from failure and data loss </li></ul></ul><ul><ul><li>Minimizing need for reorganization </li></ul></ul><ul><ul><li>Accommodating growth </li></ul></ul><ul><ul><li>Security from unauthorized use </li></ul></ul><ul><li>Types of file organizations </li></ul><ul><ul><li>Sequential </li></ul></ul><ul><ul><li>Indexed </li></ul></ul><ul><ul><li>Hashed </li></ul></ul>
    253. 253. Figure 6-7a Sequential file organization If not sorted Average time to find desired record = n/2 1 2 n Records of the file are stored in sequence by the primary key field values If sorted – every insert or delete requires resort
    254. 254. Indexed File Organizations <ul><li>Index–a separate table that contains organization of records for quick retrieval </li></ul><ul><li>Primary keys are automatically indexed </li></ul><ul><li>Oracle has a CREATE INDEX operation, and MS ACCESS allows indexes to be created for most field types </li></ul><ul><li>Indexing approaches: </li></ul><ul><ul><li>B-tree index, Fig. 6-7b </li></ul></ul><ul><ul><li>Bitmap index, Fig. 6-8 </li></ul></ul><ul><ul><li>Hash Index, Fig. 6-7c </li></ul></ul><ul><ul><li>Join Index, Fig 6-9 </li></ul></ul>
    255. 255. Figure 6-7b B-tree index uses a tree search Average time to find desired record = depth of the tree Leaves of the tree are all at same level  consistent access time
    256. 256. Figure 6-7c Hashed file or index organization Hash algorithm Usually uses division-remainder to determine record position. Records with same position are grouped in lists
    257. 257. Figure 6-8 Bitmap index index organization Bitmap saves on space requirements Rows - possible values of the attribute Columns - table rows Bit indicates whether the attribute of a row has the values
    258. 258. Figure 6-9 Join Indexes–speeds up join operations
    259. 259.
    260. 260. Clustering Files <ul><li>In some relational DBMSs, related records from different tables can be stored together in the same disk area </li></ul><ul><li>Useful for improving performance of join operations </li></ul><ul><li>Primary key records of the main table are stored adjacent to associated foreign key records of the dependent table </li></ul><ul><li>e.g. Oracle has a CREATE CLUSTER command </li></ul>
    261. 261. Rules for Using Indexes <ul><li>Use on larger tables </li></ul><ul><li>Index the primary key of each table </li></ul><ul><li>Index search fields (fields frequently in WHERE clause) </li></ul><ul><li>Fields in SQL ORDER BY and GROUP BY commands </li></ul><ul><li>When there are >100 values but not when there are <30 values </li></ul>
    262. 262. Rules for Using Indexes (cont.) <ul><li>Avoid use of indexes for fields with long values; perhaps compress values first </li></ul><ul><li>DBMS may have limit on number of indexes per table and number of bytes per indexed field(s) </li></ul><ul><li>Null values will not be referenced from an index </li></ul><ul><li>Use indexes heavily for non-volatile databases; limit the use of indexes for volatile databases </li></ul><ul><ul><li>Why? Because modifications (e.g. inserts, deletes) require updates to occur in index files </li></ul></ul>
    263. 263. RAID <ul><li>Redundant Array of Inexpensive Disks </li></ul><ul><li>A set of disk drives that appear to the user to be a single disk drive </li></ul><ul><li>Allows parallel access to data (improves access speed) </li></ul><ul><li>Pages are arranged in stripes </li></ul>
    264. 264. <ul><li>Figure 6-10 </li></ul><ul><ul><li>RAID with four disks and striping </li></ul></ul>Here, pages 1-4 can be read/written simultaneously
    265. 265. Raid Types (Figure 6-10) <ul><li>Raid 0 </li></ul><ul><ul><li>Maximized parallelism </li></ul></ul><ul><ul><li>No redundancy </li></ul></ul><ul><ul><li>No error correction </li></ul></ul><ul><ul><li>no fault-tolerance </li></ul></ul><ul><li>Raid 1 </li></ul><ul><ul><li>Redundant data – fault tolerant </li></ul></ul><ul><ul><li>Most common form </li></ul></ul><ul><li>Raid 2 </li></ul><ul><ul><li>No redundancy </li></ul></ul><ul><ul><li>One record spans across data disks </li></ul></ul><ul><ul><li>Error correction in multiple disks– reconstruct damaged data </li></ul></ul><ul><li>Raid 3 </li></ul><ul><ul><li>Error correction in one disk </li></ul></ul><ul><ul><li>Record spans multiple data disks (more than RAID2) </li></ul></ul><ul><ul><li>Not good for multi-user environments, </li></ul></ul><ul><li>Raid 4 </li></ul><ul><ul><li>Error correction in one disk </li></ul></ul><ul><ul><li>Multiple records per stripe </li></ul></ul><ul><ul><li>Parallelism, but slow updates due to error correction contention </li></ul></ul><ul><li>Raid 5 </li></ul><ul><ul><li>Rotating parity array </li></ul></ul><ul><ul><li>Error correction takes place in same disks as data storage </li></ul></ul><ul><ul><li>Parallelism, better performance than Raid4 </li></ul></ul>
    266. 266. Database Architectures (Figure 6-11) Legacy Systems Current Technology Data Warehouses
    267. 267. Chapter 7: Introduction to SQL Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    268. 268. Objectives <ul><li>Definition of terms </li></ul><ul><li>Interpret history and role of SQL </li></ul><ul><li>Define a database using SQL data definition language </li></ul><ul><li>Write single table queries using SQL </li></ul><ul><li>Establish referential integrity using SQL </li></ul><ul><li>Discuss SQL:1999 and SQL:2003 standards </li></ul>
    269. 269. SQL Overview <ul><li>Structured Query Language </li></ul><ul><li>The standard for relational database management systems (RDBMS) </li></ul><ul><li>RDBMS: A database management system that manages data as a collection of tables in which all relationships are represented by common values in related tables </li></ul>
    270. 270. History of SQL <ul><li>1970–E. Codd develops relational database concept </li></ul><ul><li>1974-1979–System R with Sequel (later SQL) created at IBM Research Lab </li></ul><ul><li>1979–Oracle markets first relational DB with SQL </li></ul><ul><li>1986–ANSI SQL standard released </li></ul><ul><li>1989, 1992, 1999, 2003–Major ANSI standard updates </li></ul><ul><li>Current–SQL is supported by most major database vendors </li></ul>
    271. 271. Purpose of SQL Standard <ul><li>Specify syntax/semantics for data definition and manipulation </li></ul><ul><li>Define data structures </li></ul><ul><li>Enable portability </li></ul><ul><li>Specify minimal (level 1) and complete (level 2) standards </li></ul><ul><li>Allow for later growth/enhancement to standard </li></ul>
    272. 272. Benefits of a Standardized Relational Language <ul><li>Reduced training costs </li></ul><ul><li>Productivity </li></ul><ul><li>Application portability </li></ul><ul><li>Application longevity </li></ul><ul><li>Reduced dependence on a single vendor </li></ul><ul><li>Cross-system communication </li></ul>
    273. 273. SQL Environment <ul><li>Catalog </li></ul><ul><ul><li>A set of schemas that constitute the description of a database </li></ul></ul><ul><li>Schema </li></ul><ul><ul><li>The structure that contains descriptions of objects created by a user (base tables, views, constraints) </li></ul></ul><ul><li>Data Definition Language (DDL) </li></ul><ul><ul><li>Commands that define a database, including creating, altering, and dropping tables and establishing constraints </li></ul></ul><ul><li>Data Manipulation Language (DML) </li></ul><ul><ul><li>Commands that maintain and query a database </li></ul></ul><ul><li>Data Control Language (DCL) </li></ul><ul><ul><li>Commands that control a database, including administering privileges and committing data </li></ul></ul>
    274. 274. Figure 7-1 A simplified schematic of a typical SQL environment, as described by the SQL-2003 standard
    275. 275. Some SQL Data types
    276. 276. Figure 7-4 DDL, DML, DCL, and the database development process
    277. 277. SQL Database Definition <ul><li>Data Definition Language (DDL) </li></ul><ul><li>Major CREATE statements: </li></ul><ul><ul><li>CREATE SCHEMA–defines a portion of the database owned by a particular user </li></ul></ul><ul><ul><li>CREATE TABLE–defines a table and its columns </li></ul></ul><ul><ul><li>CREATE VIEW–defines a logical table from one or more views </li></ul></ul><ul><li>Other CREATE statements: CHARACTER SET, COLLATION, TRANSLATION, ASSERTION, DOMAIN </li></ul>
    278. 278. Table Creation Figure 7-5 General syntax for CREATE TABLE <ul><li>Steps in table creation: </li></ul><ul><li>Identify data types for attributes </li></ul><ul><li>Identify columns that can and cannot be null </li></ul><ul><li>Identify columns that must be unique (candidate keys) </li></ul><ul><li>Identify primary key – foreign key mates </li></ul><ul><li>Determine default values </li></ul><ul><li>Identify constraints on columns (domain specifications) </li></ul><ul><li>Create the table and associated indexes </li></ul>
    279. 279. The following slides create tables for this enterprise data model
    280. 280. Figure 7-6 SQL database definition commands for Pine Valley Furniture Overall table definitions
    281. 281. Defining attributes and their data types
    282. 282. Non-nullable specification Identifying primary key Primary keys can never have NULL values
    283. 283. Non-nullable specifications Primary key Some primary keys are composite– composed of multiple attributes
    284. 284. Default value Domain constraint Controlling the values in attributes
    285. 285. Primary key of parent table Identifying foreign keys and establishing relationships Foreign key of dependent table
    286. 286. Data Integrity Controls <ul><li>Referential integrity–constraint that ensures that foreign key values of a table must match primary key values of a related table in 1:M relationships </li></ul><ul><li>Restricting: </li></ul><ul><ul><li>Deletes of primary records </li></ul></ul><ul><ul><li>Updates of primary records </li></ul></ul><ul><ul><li>Inserts of dependent records </li></ul></ul>
    287. 287. Relational integrity is enforced via the primary-key to foreign-key match Figure 7-7 Ensuring data integrity through updates
    288. 288. Changing and Removing Tables <ul><li>ALTER TABLE statement allows you to change column specifications: </li></ul><ul><ul><li>ALTER TABLE CUSTOMER_T ADD (TYPE VARCHAR(2)) </li></ul></ul><ul><li>DROP TABLE statement allows you to remove tables from your schema: </li></ul><ul><ul><li>DROP TABLE CUSTOMER_T </li></ul></ul>
    289. 289. Schema Definition <ul><li>Control processing/storage efficiency: </li></ul><ul><ul><li>Choice of indexes </li></ul></ul><ul><ul><li>File organizations for base tables </li></ul></ul><ul><ul><li>File organizations for indexes </li></ul></ul><ul><ul><li>Data clustering </li></ul></ul><ul><ul><li>Statistics maintenance </li></ul></ul><ul><li>Creating indexes </li></ul><ul><ul><li>Speed up random/sequential access to base table data </li></ul></ul><ul><ul><li>Example </li></ul></ul><ul><ul><ul><li>CREATE INDEX NAME_IDX ON CUSTOMER_T(CUSTOMER_NAME) </li></ul></ul></ul><ul><ul><ul><li>This makes an index for the CUSTOMER_NAME field of the CUSTOMER_T table </li></ul></ul></ul>
    290. 290. Insert Statement <ul><li>Adds data to a table </li></ul><ul><li>Inserting into a table </li></ul><ul><ul><li>INSERT INTO CUSTOMER_T VALUES (001, ‘Contemporary Casuals’, ‘1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, 32601); </li></ul></ul><ul><li>Inserting a record that has some null attributes requires identifying the fields that actually get data </li></ul><ul><ul><li>INSERT INTO PRODUCT_T (PRODUCT_ID, PRODUCT_DESCRIPTION,PRODUCT_FINISH, STANDARD_PRICE, PRODUCT_ON_HAND) VALUES (1, ‘End Table’, ‘Cherry’, 175, 8); </li></ul></ul><ul><li>Inserting from another table </li></ul><ul><ul><li>INSERT INTO CA_CUSTOMER_T SELECT * FROM CUSTOMER_T WHERE STATE = ‘CA’; </li></ul></ul>
    291. 291. Creating Tables with Identity Columns <ul><li>Inserting into a table does not require explicit customer ID entry or field list </li></ul><ul><ul><li>INSERT INTO CUSTOMER_T VALUES ( ‘Contemporary Casuals’, ‘1355 S. Himes Blvd.’, ‘Gainesville’, ‘FL’, 32601); </li></ul></ul>New with SQL:2003
    292. 292. Delete Statement <ul><li>Removes rows from a table </li></ul><ul><li>Delete certain rows </li></ul><ul><ul><li>DELETE FROM CUSTOMER_T WHERE STATE = ‘HI’; </li></ul></ul><ul><li>Delete all rows </li></ul><ul><ul><li>DELETE FROM CUSTOMER_T; </li></ul></ul>
    293. 293. Update Statement <ul><li>Modifies data in existing rows </li></ul><ul><li>UPDATE PRODUCT_T SET UNIT_PRICE = 775 WHERE PRODUCT_ID = 7; </li></ul>
    294. 294. Merge Statement Makes it easier to update a table…allows combination of Insert and Update in one statement Useful for updating master tables with new data
    295. 295. SELECT Statement <ul><li>Used for queries on single or multiple tables </li></ul><ul><li>Clauses of the SELECT statement: </li></ul><ul><ul><li>SELECT </li></ul></ul><ul><ul><ul><li>List the columns (and expressions) that should be returned from the query </li></ul></ul></ul><ul><ul><li>FROM </li></ul></ul><ul><ul><ul><li>Indicate the table(s) or view(s) from which data will be obtained </li></ul></ul></ul><ul><ul><li>WHERE </li></ul></ul><ul><ul><ul><li>Indicate the conditions under which a row will be included in the result </li></ul></ul></ul><ul><ul><li>GROUP BY </li></ul></ul><ul><ul><ul><li>Indicate categorization of results </li></ul></ul></ul><ul><ul><li>HAVING </li></ul></ul><ul><ul><ul><li>Indicate the conditions under which a category (group) will be included </li></ul></ul></ul><ul><ul><li>ORDER BY </li></ul></ul><ul><ul><ul><li>Sorts the result according to specified criteria </li></ul></ul></ul>
    296. 296. <ul><li>Figure 7-10 </li></ul><ul><ul><li>SQL statement processing order (adapted from van der Lans, p.100) </li></ul></ul>
    297. 297. SELECT Example <ul><li>Find products with standard price less than $275 </li></ul><ul><ul><li>SELECT PRODUCT_NAME, STANDARD_PRICE </li></ul></ul><ul><ul><li>FROM PRODUCT_V </li></ul></ul><ul><ul><li>WHERE STANDARD_PRICE < 275; </li></ul></ul>Table 7-3: Comparison Operators in SQL
    298. 298. SELECT Example Using Alias <ul><li>Alias is an alternative column or table name </li></ul><ul><ul><ul><li>SELECT CUST .CUSTOMER AS NAME , CUST.CUSTOMER_ADDRESS </li></ul></ul></ul><ul><ul><ul><li>FROM CUSTOMER_V CUST </li></ul></ul></ul><ul><ul><ul><li>WHERE NAME = ‘Home Furnishings’; </li></ul></ul></ul>
    299. 299. SELECT Example Using a Function <ul><li>Using the COUNT aggregate function to find totals </li></ul><ul><ul><li>SELECT COUNT(*) FROM ORDER_LINE_V </li></ul></ul><ul><ul><li>WHERE ORDER_ID = 1004; </li></ul></ul><ul><ul><li>Note: with aggregate functions you can’t have single-valued columns included in the SELECT clause </li></ul></ul>
    300. 300. SELECT Example–Boolean Operators <ul><li>AND , OR , and NOT Operators for customizing conditions in WHERE clause </li></ul><ul><ul><li>SELECT PRODUCT_DESCRIPTION, PRODUCT_FINISH, STANDARD_PRICE </li></ul></ul><ul><ul><li>FROM PRODUCT_V </li></ul></ul><ul><ul><li>WHERE (PRODUCT_DESCRIPTION LIKE ‘ % Desk’ </li></ul></ul><ul><ul><li>OR PRODUCT_DESCRIPTION LIKE ‘ % Table’) </li></ul></ul><ul><ul><li>AND UNIT_PRICE > 300; </li></ul></ul>Note: the LIKE operator allows you to compare strings using wildcards. For example, the % wildcard in ‘%Desk’ indicates that all strings that have any number of characters preceding the word “Desk” will be allowed
    301. 301. Venn Diagram from Previous Query
    302. 302. SELECT Example – Sorting Results with the ORDER BY Clause <ul><li>Sort the results first by STATE, and within a state by CUSTOMER_NAME </li></ul><ul><ul><li>SELECT CUSTOMER_NAME, CITY, STATE </li></ul></ul><ul><ul><li>FROM CUSTOMER_V </li></ul></ul><ul><ul><li>WHERE STATE IN (‘FL’, ‘TX’, ‘CA’, ‘HI’) </li></ul></ul><ul><ul><li>ORDER BY STATE, CUSTOMER_NAME; </li></ul></ul>Note: the IN operator in this example allows you to include rows whose STATE value is either FL, TX, CA, or HI. It is more efficient than separate OR conditions
    303. 303. SELECT Example– Categorizing Results Using the GROUP BY Clause <ul><li>For use with aggregate functions </li></ul><ul><ul><li>Scalar aggregate : single value returned from SQL query with aggregate function </li></ul></ul><ul><ul><li>Vector aggregate : multiple values returned from SQL query with aggregate function (via GROUP BY) </li></ul></ul><ul><ul><li>SELECT CUSTOMER_STATE, COUNT(CUSTOMER_STATE) </li></ul></ul><ul><ul><li>FROM CUSTOMER_V </li></ul></ul><ul><ul><li>GROUP BY CUSTOMER_STATE; </li></ul></ul><ul><ul><li>Note: you can use single-value fields with aggregate functions if they are included in the GROUP BY clause </li></ul></ul>
    304. 304. SELECT Example– Qualifying Results by Categories Using the HAVING Clause <ul><li>For use with GROUP BY </li></ul><ul><ul><li>SELECT CUSTOMER_STATE, COUNT(CUSTOMER_STATE) </li></ul></ul><ul><ul><li>FROM CUSTOMER_V </li></ul></ul><ul><ul><li>GROUP BY CUSTOMER_STATE </li></ul></ul><ul><ul><li>HAVING COUNT(CUSTOMER_STATE) > 1; </li></ul></ul><ul><ul><li>Like a WHERE clause, but it operates on groups (categories), not on individual rows. Here, only those groups with total numbers greater than 1 will be included in final result </li></ul></ul>
    305. 305. Using and Defining Views <ul><li>Views provide users controlled access to tables </li></ul><ul><li>Base Table–table containing the raw data </li></ul><ul><li>Dynamic View </li></ul><ul><ul><li>A “virtual table” created dynamically upon request by a user </li></ul></ul><ul><ul><li>No data actually stored; instead data from base table made available to user </li></ul></ul><ul><ul><li>Based on SQL SELECT statement on base tables or other views </li></ul></ul><ul><li>Materialized View </li></ul><ul><ul><li>Copy or replication of data </li></ul></ul><ul><ul><li>Data actually stored </li></ul></ul><ul><ul><li>Must be refreshed periodically to match the corresponding base tables </li></ul></ul>
    306. 306. Sample CREATE VIEW <ul><ul><li>CREATE VIEW EXPENSIVE_STUFF_V AS </li></ul></ul><ul><ul><li>SELECT PRODUCT_ID, PRODUCT_NAME, UNIT_PRICE </li></ul></ul><ul><ul><li>FROM PRODUCT_T </li></ul></ul><ul><ul><li>WHERE UNIT_PRICE >300 </li></ul></ul><ul><ul><li>WITH CHECK_OPTION; </li></ul></ul><ul><li>View has a name </li></ul><ul><li>View is based on a SELECT statement </li></ul><ul><li>CHECK_OPTION works only for updateable views and prevents updates that would create rows not included in the view </li></ul>
    307. 307. Advantages of Views <ul><li>Simplify query commands </li></ul><ul><li>Assist with data security (but don't rely on views for security, there are more important security measures) </li></ul><ul><li>Enhance programming productivity </li></ul><ul><li>Contain most current base table data </li></ul><ul><li>Use little storage space </li></ul><ul><li>Provide customized view for user </li></ul><ul><li>Establish physical data independence </li></ul>
    308. 308. Disadvantages of Views <ul><li>Use processing time each time view is referenced </li></ul><ul><li>May or may not be directly updateable </li></ul>
    309. 309. Chapter 8: Advanced SQL Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    310. 310. Objectives <ul><li>Definition of terms </li></ul><ul><li>Write multiple table SQL queries </li></ul><ul><li>Define and use three types of joins </li></ul><ul><li>Write correlated and noncorrelated subqueries </li></ul><ul><li>Establish referential integrity in SQL </li></ul><ul><li>Understand triggers and stored procedures </li></ul><ul><li>Discuss SQL:1999 standard and its extension of SQL-92 </li></ul>
    311. 311. Processing Multiple Tables–Joins <ul><li>Join – a relational operation that causes two or more tables with a common domain to be combined into a single table or view </li></ul><ul><li>Equi-join – a join in which the joining condition is based on equality between values in the common columns; common columns appear redundantly in the result table </li></ul><ul><li>Natural join – an equi-join in which one of the duplicate columns is eliminated in the result table </li></ul><ul><li>Outer join – a join in which rows that do not have matching values in common columns are nonetheless included in the result table (as opposed to inner join, in which rows must have matching values in order to appear in the result table) </li></ul><ul><li>Union join – includes all columns from each table in the join, and an instance for each row of each table </li></ul>The common columns in joined tables are usually the primary key of the dominant table and the foreign key of the dependent table in 1:M relationships
    312. 312. The following slides create tables for this enterprise data model
    313. 313. These tables are used in queries that follow Figure 8-1 Pine Valley Furniture Company Customer and Order tables with pointers from customers to their orders
    314. 314. <ul><li>For each customer who placed an order, what is the customer’s name and order number? </li></ul><ul><ul><li>SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME, ORDER_ID </li></ul></ul><ul><ul><li>FROM CUSTOMER_T NATURAL JOIN ORDER_T ON </li></ul></ul><ul><ul><li>CUSTOMER_T.CUSTOMER_ID = ORDER_T.CUSTOMER_ID; </li></ul></ul>Natural Join Example Note: from Fig. 1, you see that only 10 Customers have links with orders.  Only 10 rows will be returned from this INNER join. Join involves multiple tables in FROM clause ON clause performs the equality check for common columns of the two tables
    315. 315. <ul><li>List the customer name, ID number, and order number for all customers. Include customer information even for customers that do have an order </li></ul><ul><ul><li>SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME, ORDER_ID </li></ul></ul><ul><ul><li>FROM CUSTOMER_T, LEFT OUTER JOIN ORDER_T </li></ul></ul><ul><ul><li>ON CUSTOMER_T.CUSTOMER_ID = ORDER_T.CUSTOMER_ID; </li></ul></ul>Outer Join Example (Microsoft Syntax) Unlike INNER join, this will include customer rows with no matching order rows LEFT OUTER JOIN syntax with ON causes customer data to appear even if there is no corresponding order data
    316. 316. Results Unlike INNER join, this will include customer rows with no matching order rows
    317. 317. <ul><li>Assemble all information necessary to create an invoice for order number 1006 </li></ul><ul><ul><li>SELECT CUSTOMER_T.CUSTOMER_ID, CUSTOMER_NAME, CUSTOMER_ADDRESS, CITY, SATE, POSTAL_CODE, ORDER_T.ORDER_ID, ORDER_DATE, QUANTITY, PRODUCT_DESCRIPTION, STANDARD_PRICE, (QUANTITY * UNIT_PRICE) </li></ul></ul><ul><ul><li>FROM CUSTOMER_T, ORDER_T, ORDER_LINE_T, PRODUCT_T </li></ul></ul><ul><ul><li>WHERE CUSTOMER_T.CUSTOMER_ID = ORDER_LINE.CUSTOMER_ID AND ORDER_T.ORDER_ID = ORDER_LINE_T.ORDER_ID </li></ul></ul><ul><ul><ul><li>AND ORDER_LINE_T.PRODUCT_ID = PRODUCT_PRODUCT_ID </li></ul></ul></ul><ul><ul><ul><li>AND ORDER_T.ORDER_ID = 1006; </li></ul></ul></ul>Multiple Table Join Example Four tables involved in this join Each pair of tables requires an equality-check condition in the WHERE clause, matching primary keys against foreign keys
    318. 318. Figure 8-2 Results from a four-table join From CUSTOMER_T table From ORDER_T table From PRODUCT_T table
    319. 319. Processing Multiple Tables Using Subqueries <ul><li>Subquery–placing an inner query (SELECT statement) inside an outer query </li></ul><ul><li>Options: </li></ul><ul><ul><li>In a condition of the WHERE clause </li></ul></ul><ul><ul><li>As a “table” of the FROM clause </li></ul></ul><ul><ul><li>Within the HAVING clause </li></ul></ul><ul><li>Subqueries can be: </li></ul><ul><ul><li>Noncorrelated–executed once for the entire outer query </li></ul></ul><ul><ul><li>Correlated–executed once for each row returned by the outer query </li></ul></ul>
    320. 320. <ul><li>Show all customers who have placed an order </li></ul><ul><ul><li>SELECT CUSTOMER_NAME FROM CUSTOMER_T </li></ul></ul><ul><ul><li>WHERE CUSTOMER_ID IN </li></ul></ul><ul><ul><li>(SELECT DISTINCT CUSTOMER_ID FROM ORDER_T); </li></ul></ul>Subquery Example Subquery is embedded in parentheses. In this case it returns a list that will be used in the WHERE clause of the outer query The IN operator will test to see if the CUSTOMER_ID value of a row is included in the list returned from the subquery
    321. 321. Correlated vs. Noncorrelated Subqueries <ul><li>Noncorrelated subqueries: </li></ul><ul><ul><li>Do not depend on data from the outer query </li></ul></ul><ul><ul><li>Execute once for the entire outer query </li></ul></ul><ul><li>Correlated subqueries: </li></ul><ul><ul><li>Make use of data from the outer query </li></ul></ul><ul><ul><li>Execute once for each row of the outer query </li></ul></ul><ul><ul><li>Can use the EXISTS operator </li></ul></ul>
    322. 322. Figure 8-3a Processing a noncorrelated subquery No reference to data in outer query, so subquery executes once only These are the only customers that have IDs in the ORDER_T table <ul><li>The subquery executes and returns the customer IDs from the ORDER_T table </li></ul><ul><li>The outer query on the results of the subquery </li></ul>
    323. 323. <ul><li>Show all orders that include furniture finished in natural ash </li></ul><ul><ul><li>SELECT DISTINCT ORDER_ID FROM ORDER_LINE_T </li></ul></ul><ul><ul><li>WHERE EXISTS </li></ul></ul><ul><ul><li>(SELECT * FROM PRODUCT_T </li></ul></ul><ul><ul><li>WHERE PRODUCT_ID = ORDER_LINE_T.PRODUCT_ID </li></ul></ul><ul><ul><li>AND PRODUCT_FINISH = ‘Natural ash’); </li></ul></ul>Correlated Subquery Example The subquery is testing for a value that comes from the outer query The EXISTS operator will return a TRUE value if the subquery resulted in a non-empty set, otherwise it returns a FALSE
    324. 324. Figure 8-3b Processing a correlated subquery Subquery refers to outer-query data, so executes once for each row of outer query Note: only the orders that involve products with Natural Ash will be included in the final results
    325. 325. <ul><li>Show all products whose standard price is higher than the average price </li></ul><ul><ul><li>SELECT PRODUCT_DESCRIPTION, STANDARD_PRICE, AVGPRICE </li></ul></ul><ul><ul><li>FROM </li></ul></ul><ul><ul><ul><li>(SELECT AVG(STANDARD_PRICE) AVGPRICE FROM PRODUCT_T), </li></ul></ul></ul><ul><ul><ul><li>PRODUCT_T </li></ul></ul></ul><ul><ul><ul><li>WHERE STANDARD_PRICE > AVG_PRICE; </li></ul></ul></ul>Another Subquery Example The WHERE clause normally cannot include aggregate functions, but because the aggregate is performed in the subquery its result can be used in the outer query’s WHERE clause One column of the subquery is an aggregate function that has an alias name. That alias can then be referred to in the outer query Subquery forms the derived table used in the FROM clause of the outer query
    326. 326. Union Queries <ul><li>Combine the output (union of multiple queries) together into a single result table </li></ul>First query Second query Combine
    327. 327. Conditional Expressions Using Case Syntax <ul><li>This is available with newer versions of SQL, previously not part of the standard </li></ul>
    328. 328. Ensuring Transaction Integrity <ul><li>Transaction = A discrete unit of work that must be completely processed or not processed at all </li></ul><ul><ul><li>May involve multiple updates </li></ul></ul><ul><ul><li>If any update fails, then all other updates must be cancelled </li></ul></ul><ul><li>SQL commands for transactions </li></ul><ul><ul><li>BEGIN TRANSACTION/END TRANSACTION </li></ul></ul><ul><ul><ul><li>Marks boundaries of a transaction </li></ul></ul></ul><ul><ul><li>COMMIT </li></ul></ul><ul><ul><ul><li>Makes all updates permanent </li></ul></ul></ul><ul><ul><li>ROLLBACK </li></ul></ul><ul><ul><ul><li>Cancels updates since the last COMMIT </li></ul></ul></ul>
    329. 329. Figure 8-5 An SQL Transaction sequence (in pseudocode)
    330. 330. Data Dictionary Facilities <ul><li>System tables that store metadata </li></ul><ul><li>Users usually can view some of these tables </li></ul><ul><li>Users are restricted from updating them </li></ul><ul><li>Some examples in Oracle 10g </li></ul><ul><ul><li>DBA_TABLES–descriptions of tables </li></ul></ul><ul><ul><li>DBA_CONSTRAINTS–description of constraints </li></ul></ul><ul><ul><li>DBA_USERS–information about the users of the system </li></ul></ul><ul><li>Examples in Microsoft SQL Server 2000 </li></ul><ul><ul><li>SYSCOLUMNS–table and column definitions </li></ul></ul><ul><ul><li>SYSDEPENDS–object dependencies based on foreign keys </li></ul></ul><ul><ul><li>SYSPERMISSIONS–access permissions granted to users </li></ul></ul>
    331. 331. SQL:1999 and SQL:2003 Enhancements/Extensions <ul><li>User-defined data types (UDT) </li></ul><ul><ul><li>Subclasses of standard types or an object type </li></ul></ul><ul><li>Analytical functions (for OLAP) </li></ul><ul><ul><li>CEILING, FLOOR, SQRT, RANK, DENSE_RANK </li></ul></ul><ul><ul><li>WINDOW–improved numerical analysis capabilities </li></ul></ul><ul><li>New Data Types </li></ul><ul><ul><li>BIGINT, MULTISET (collection), XML </li></ul></ul><ul><li>CREATE TABLE LIKE–create a new table similar to an existing one </li></ul><ul><li>MERGE </li></ul>
    332. 332. <ul><li>Persistent Stored Modules (SQL/PSM) </li></ul><ul><ul><li>Capability to create and drop code modules </li></ul></ul><ul><ul><li>New statements: </li></ul></ul><ul><ul><ul><li>CASE, IF, LOOP, FOR, WHILE, etc. </li></ul></ul></ul><ul><ul><ul><li>Makes SQL into a procedural language </li></ul></ul></ul><ul><li>Oracle has propriety version called PL/SQL, and Microsoft SQL Server has Transact/SQL </li></ul>SQL:1999 and SQL:2003 Enhancements/Extensions (cont.)
    333. 333. Routines and Triggers <ul><li>Routines </li></ul><ul><ul><li>Program modules that execute on demand </li></ul></ul><ul><ul><li>Functions –routines that return values and take input parameters </li></ul></ul><ul><ul><li>Procedures –routines that do not return values and can take input or output parameters </li></ul></ul><ul><li>Triggers </li></ul><ul><ul><li>Routines that execute in response to a database event (INSERT, UPDATE, or DELETE) </li></ul></ul>
    334. 334. Figure 8-6 Triggers contrasted with stored procedures Procedures are called explicitly Triggers are event-driven Source : adapted from Mullins, 1995.
    335. 335. Figure 8-7 Simplified trigger syntax, SQL:2003 Figure 8-8 Create routine syntax, SQL:2003
    336. 336. Embedded and Dynamic SQL <ul><li>Embedded SQL </li></ul><ul><ul><li>Including hard-coded SQL statements in a program written in another language such as C or Java </li></ul></ul><ul><li>Dynamic SQL </li></ul><ul><ul><li>Ability for an application program to generate SQL code on the fly, as the application is running </li></ul></ul>
    337. 337. Chapter 9: The Client/Server Database Environment Modern Database Management 8 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden © 2007 by Prentice Hall
    338. 338. Objectives <ul><li>Definition of terms </li></ul><ul><li>List advantages of client/server architecture </li></ul><ul><li>Explain three application components: presentation, processing, and storage </li></ul><ul><li>Suggest partitioning possibilities </li></ul><ul><li>Distinguish between file server, database server, 3-tier, and n-tier approaches </li></ul><ul><li>Describe and discuss middleware </li></ul><ul><li>Explain database linking via ODBC and JDBC </li></ul>
    339. 339. Client/Server Systems <ul><li>Networked computing model </li></ul><ul><li>Processes distributed between clients and servers </li></ul><ul><li>Client–Workstation (usually a PC) that requests and uses a service </li></ul><ul><li>Server–Computer (PC/mini/mainframe) that provides a service </li></ul><ul><li>For DBMS, server is a database server </li></ul>
    340. 340. Application Logic in C/S Systems GUI Interface Procedures, functions, programs DBMS activities <ul><li>Processing Logic </li></ul><ul><ul><li>I/O processing </li></ul></ul><ul><ul><li>Business rules </li></ul></ul><ul><ul><li>Data management </li><
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×