CHAPTER 1 o Increased application development productivity

o Enforcement of standards
Database: organized collection of logically related data o Improved data quality
Data: stored representations of meaningful objects and events o Improved data quality
o Reduced program maintenance
 Structured: numbers, text, dates o Improved decision support
 Unstructured: images, video, documents
Elements of the Database Approach
Information: data processed to increase knowledge in the person using the data
o Data models
Metadata: data that describes the properties and context of user data  Graphical system capturing nature and relationship of data
 Enterprise Data Model–high-level entities and relationships for the organization
 Project Data Model–more detailed view, matching data structure in database or
Disadvantages of File Processing/Problems with Data Dependency data warehouse
o Program-Data Dependence o Entities
 All programs maintain metadata for each file they use  Noun form describing a person, place, object, event, or concept
o Duplication of Data  Composed of attributes
 Different systems/programs have separate copies of the same data o Relationships
o Limited Data Sharing  Between entities
 No centralized control of data  Usually one-to-many (1:M) or many-to-many (M:N)
o Lengthy Development Times o Relational Databases
 No centralized control of data  Database technology involving tables (relations) representing entities and
o Excessive Program Maintenance primary/foreign keys representing relationships
 80% of information systems budget

Problems with Data Redundancy

o Waste of space to have duplicate data
o Causes more maintenance headache
o The biggest problem:
 Data changes in one file could cause inconsistencies
 Compromises in data integrity

Advantages of the Database Approach

o Program-data independence
o Planned data redundancy
o Improved data consistency
o Improved data consistency
Components of the Database Environment  Can be determined from businessfunction/data entity matrices
 DBA determines schema for different users
o CASE Tools–computer-aided software engineering
o Conceptual Schema
o Repository–centralized storehouse of metadata
 E-R models–covered in Chapters 2 and 3
o Database Management System (DBMS) –software for managing the database
o Internal Schema
o Database–storehouse of the data
 Logical structures–covered in Chapter 4
o Application Programs–software using the data
 Physical structures–covered in Chapter 5
o User Interface–text and graphical displays to users
o Data/Database Administrators–personnel responsible for maintaining the database Managing Projects
o System Developers–personnel responsible for designing databases and software
o Project–a planned undertaking of related activities to reach an objective that has a
o End Users–people who use the applications and databases
beginning and an end
Two Approaches to Database and IS Development o Initiated and planned in planning stage of SDLC
o Executed during analysis, design, and implementation
o SDLC o Closed at the end of implementation
 System Development Life Cycle
 Detailed, well-planned development process Managing Projects: People Involved
 Time-consuming, but comprehensive
o Business analysts
 Long development cycle
o Systems analysts
o Prototyping
o Database analysts and data modelers
 Rapid application development (RAD)
o Users o Programmers o Database architects
 Cursory attempt at conceptual data modeling
o Data administrators
 Define database during development of initial prototype
o Project managers
 Repeat implementation and maintenance activities with new prototype versions
o Other technical experts

Range of Database Applications

o Personal databases
o Two-tier and N-tier Client/Server databases
o Enterprise applications
 Enterprise
resource
planning (ERP)
systems
 Data
Database Schema
warehousing
o External Schema
 User Views implementations
 Subsets of Conceptual Schema
o
Enterprise Database Applications
o Enterprise Resource Planning (ERP) A Good Business Rule:
 Integrate all enterprise functions (manufacturing, finance, sales, marketing,
inventory, accounting, human resources) o Declarative–what, not how
o Data Warehouse o Precise–clear, agreed-upon meaning
 Integrated decision support system derived from various operational databases o Atomic–one statement
o Consistent–internally and externally
o Expressible–structured, natural language
CHAPTER 2
o Distinct–non-redundant
o Explanation of a term or fact o Business-oriented–understood by business people
 Term–word or phrase with specific meaning
 Fact–association between two or more terms Entities
o Guidelines for good data definition o Entity – a person, a place, an object, an event, or a concept in the user environment about
 A concise description of essential data meaning
which the organization wishes to maintain data
 Gathered in conjunction with systems requirements
o Entity type – a collection of entities that share common properties or characteristics
 Accompanied by diagrams
o Entity instance – A single occurrence of an entity type
 Achieved by consensus, and iteratively refined
Strong vs. Weak Entities and Identifying Relationships

o Strong entity
 exists independently of other types of entities
 has its own unique identifier
 identifier underlined with single line
o Weak entity
 dependent on a strong entity (identifying owner)…cannot exist on its own
 does not have a unique identifier (only a partial identifier)
 entity box and partial identifier have double lines
o Identifying relationship
 links strong entities to weak entities
Business Rules Attributes
o Are statements that define or constrain some aspect of the business o Attribute–property or characteristic of an entity or relationship type
o Are derived from policies, procedures, events, functions
o Classifications of attributes:
o Assert business structure
 Required versus Optional Attributes
o Control/influence business behavior
 Simple versus Composite Attribute
o Are expressed in terms familiar to end users
o Are automated through DBMS software  Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
  Identifier Attributes

Required – must have a value for every entity (or relationship) instance with which it is associated

Optional – may not have a value for every entity (or relationship) instance with which it is associated

Simple vs. Composite Attribute

o Composite attribute – An attribute that has meaningful component parts (attributes)

Modeling Relationships

o Relationship Types vs. Relationship Instances

Multivalued and Derived Attribute  The relationship type is modeled as lines between entity types…the instance is
o Multivalued – may take on more than one value for a given entity (or relationship) instance between specific entity instances
o Relationships can have attributes
o Derived – values can be calculated from related attribute values (not physically stored in the
database  These describe features pertaining to the association between the entities in the
relationship
o Two entities can have more than one type of relationship between them (multiple
relationships)
o Associative Entity–combination of relationship and entity

Degree of Relationships

o Degree of a relationship is the number of entity types that participate in it

 Unary Relationship
 Binary Relationship
Identifiers (Keys)
 Ternary Relationship
o Identifier (Key)–an attribute (or combination of attributes) that uniquely identifies individual
instances of an entity type
o Simple versus Composite Identifier
o Candidate Identifier–an attribute that could be a key…satisfies the requirements for being
an identifier
Cardinality of Relationships  If one or more, then mandatory
o Maximum Cardinality
o Cardinality of Relationships
 The maximum number
 Each entity in the relationship will have exactly one related entity
o One-to-Many
 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
o Many-to-Many
 Entities on both sides of the relationship can have many related entities on the
other side

Cardinality Constraints

o Cardinality Constraints—the
number of instances of one entity
that can or must be associated with each
instance of another entity
o Minimum Cardinality
 If zero, then optional
Associative Entities CHAPTER 3

o An entity–has attributes Supertypes and Subtypes

o A relationship–links entities together
o Enhanced ER model: extends original ER model with new modeling constructs
o When should a relationship with attributes instead be an associative entity?
o Subtype: A subgrouping of the entities in an entity type that has attributes distinct from
 All relationships for the associative entity should be many
those in other subgroupings
 The associative entity could have meaning independent of the other entities
o Supertype: A generic entity type that has a relationship with one or more subtypes
 The associative entity preferably has a unique identifier, and should also have other
o Attribute Inheritance:
attributes
 Subtype entities inherit values of all attributes of the supertype
 The associative entity may participate in other relationships other than the entities
 An instance of a subtype is also an instance of the supertype
of the associated relationship
 Ternary relationships should be converted to associative entities

Time stamp – a time value that is associated with a data value, often indicating when some event
occurred that affected the data value

Relationships and Subtypes

CHAPTER 2.1
o Relationships at the supertype level indicate that all subtypes will participate in the
Business Rules relationship
o The instances of a subtype may participate in a relationship unique to that subtype. In this
o When database designers go about selecting or determining the entities, attributes, and
situation, the relationship is shown at the subtype level
relationships that will be used to build a data model, they might start by gaining a thorough
understanding of what types of data exist in an organization, how the data is used, and in
what time frames it is used
o Example
 A customer may generate many invoices.
 An invoice is generated by only one customer.
 A training session cannot be scheduled for fewer than 10 employees or for more
than 30 employees
Generalization and Specialization
o Disjointness Constraints: Whether an instance of a supertype may simultaneously be a
o Generalization: The process of defining a more general entity type from a set of more member of two (or more) subtypes
specialized entity types. BOTTOM-UP  Disjoint Rule: An instance of the supertype can be only ONE of the subtypes
o Specialization: The process of defining one or more subtypes of the supertype and forming  Overlap Rule: An instance of the supertype could be more than one of the subtypes
supertype/subtype relationships. TOP-DOWN

Constraints in Supertype/Subtype Relationships

o Completeness Constraints: Whether an instance of a supertype must also be a member of

at least one subtype
 Total Specialization Rule: Yes (double line)
 Partial Specialization Rule: No (single line)
 o Subtype Discriminator: An attribute of the supertype whose values determine the target CHAPTER 4
subtype(s)
Components of Relational Model
 Disjoint – a simple attribute with alternative values to indicate the possible subtypes
 Overlapping – a composite attribute whose subparts pertain to different o Data structure
subtypes. Each subpart contains a Boolean value to indicate whether or not the  Tables (relations), rows, columns
instance belongs to the associated subtype o Data manipulation
 Powerful SQL operations for retrieving and modifying data
o Data integrity
 Mechanisms for implementing business rules that maintain integrity of manipulated
data

Relation

o A relation is a named, two-dimensional table of data.

o A table consists of rows (records) and columns (attribute or field).

Correspondence with E-R Model

o Relations (tables) correspond with entity types and with many-to-many relationship types.
o Rows correspond with entity instances and with many-to-many relationship instances.
o Columns correspond with attributes.
Entity Clusters
Key Fields
o EER diagrams are difficult to read when there are too many entities and relationships.
o Solution: Group entities and relationships into entity clusters. o Keys are special fields that serve two main purposes:
o Entity cluster: Set of one or more entity types and associated relationships grouped into a  Primary keys are unique identifiers of the relation. Examples include employee
single abstract entity type numbers, social security numbers, etc. This guarantees that all rows are unique.
 Foreign keys are identifiers that enable a dependent relation (on the many side of a
Advantages of Packaged Data Models relationship) to refer to its parent relation (on the one side of the relationship).
o Use proven model components o Keys can be simple (a single field) or composite (more than one field).
o Save time and cost
o Less likelihood of data model errors
o Easier to evolve and modify over time
o Aid in requirements determination
o Easier to read o Supertype/subtype hierarchies promote reuse
o Many-to-many relationships enhance model flexibility
o Vendor-supplied data model fosters integration with vendor’s applications
o Universal models support inter-organizational system
o Keys usually are used as indexes to speed up the response to user queries (more on this in
Chapter 5).
Integrity Constraints Transforming EER Diagrams into Relations

o Domain Constraints o Mapping Regular Entities to Relations

 Allowable values for an attribute (See Table 4-1)  Simple attributes: E-R attributes map
o Entity Integrity directly onto the relation
 No primary key attribute may be null. All primary key fields MUST have data.  Composite attributes: Use only their
o Action Assertions simple, component attributes
 Business rules (Recall from Chapter 3)  Multivalued Attribute: Becomes a separate
relation with a foreign key taken from the
superior entity

o 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)
- For example: Delete Rules
 Restrict–don’t allow delete of “parent” side if related rows exist in “dependent” side
 Cascade–automatically delete “dependent” side rows that correspond with the
“parent” side row to be deleted
 Set-to-Null–set the foreign key in the dependent side to null if deleting from the
parent side  not allowed for weak entities
 Transforming EER Diagrams into Relations  Many-to-Many–Create a new
(con’t…) relation with the primary keys
of the two entities as its
o Mapping Weak Entities
primary key
 Becomes a separate relation with
 One-to-One–Primary key on
a foreign key taken from the
mandatory side becomes a
superior entity
foreign key on optional side
 Primary key composed of:

 Par
t ial

o Mapping Associative Entities

 Identifier Not Assigned
 Default primary key for the
identifier of weak entity association relation is
 Primary key of identifying relation (strong entity)m composed of the primary
keys of the two entities (as
in M:N relationship)
o Identifier Assigned
 It is natural and familiar to endusers
 Default identifier may not be
unique

o Mapping Binary Relationships

 One-to-Many–Primary key on the one side becomes a foreign key on the many side
 Mapping Supertype/Subtype Relationships

o Mapping Unary Relationships o One relation for supertype and for each subtype
 One-to-Many–Recursive foreign key o Supertype attributes (including identifier and subtype discriminator) go into supertype
in the same relation relation
 Many-to-Many–Two relations: o Subtype attributes go into each subtype; primary key of supertype relation also becomes
 One for the entity type primary key of subtype relation
 One for an associative o 1:1 relationship established between supertype and each subtype, with supertype as
relation in which the primary table
primary key has two
attributes, both taken from
the primary key of the
entity

Data Normalization

o Primarily a tool to validate and improve a logical design so that it satisfies certain constraints
that avoid unnecessary duplication of data
o The process of decomposing relations with anomalies to produce smaller, well-structured
relations

Well-structured Relations

o A relation that contains minimal data redundancy and allows users to insert, delete, and
update rows without causing data inconsistencies
o Goal is to avoid anomalies
 Insertion Anomaly–adding new rows forces user to create duplicate data
 Deletion Anomaly–deleting rows may cause a loss of data that would be needed for
other future rows
  Modification Anomaly–changing data in a row forces changes to other rows
because of duplication

Anomalies in this table

o Insertion–can’t enter a new employee without having the employee take a class (or at least
empty fields of class information)
o Deletion–if we remove employee 140, we lose information about the existence of a Tax Acc
class
o Modification–giving a salary increase to employee 100 forces us to update multiple records

First Normal Form

o No multivalued attributes
o Every attribute value is atomic Third Normal Form
o Fig. 4-25 is not in 1st Normal Form (multivalued attributes)  it is not a relation.
o Fig. 4-26 is in 1st Normal form. o 2NF PLUS no transitive dependencies (functional dependencies on non-primary-key
o All relations are in 1st Normal Form. attributes)
o Note: This is called transitive, because the primary key is a determinant for another
attribute, which in turn is a determinant for a third
o 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

Second Normal Form

o 1NF PLUS every non-key attribute is fully functionally dependent on the ENTIRE primary key
 Every non-key attribute must be defined by the entire key, not by only part of the Enterprise Keys
key o Primary keys that are unique in the whole database, not just within a single relation
 No partial functional dependencies o Corresponds with the concept of an object ID in object-oriented systems
 CHAPTER 5

Physical Database Design

o Purpose–translate the
logical description of data
Normalization
into the technical
specifications for storing
and retrieving data
o Goal–create a design for
storing data that will
provide adequate
performance and ensure
database integrity, security, and recoverability

Physical Design for Regulatory Compliance o Unnor

o Sarbanes- Oxley Act (SOX) – protect investors by improving accuracy and reliability malized
o Committee of Sponsoring Organizations (COSO) of the Treadway Commission form
o IT Infrastructure Library (ITIL) o Control Objectives for Information and Related Technology 
(COBIT) 

Designing Fields 

o Field: smallest unit of application data recognized by system software
There are two rows of product items in one row of data.
o Field design
 We call it multivalued attributes
 Choosing data type
 Coding, compression, encryption
 Controlling data integrity

Field Data Integrity

o Default value–assumed value if no explicit value

o Range control–allowable value limitations (constraints or validation rules)
o Null value control–allowing or prohibiting empty fields
o Referential integrity–range control (and null value allowances) for foreign-key to primary
key match-ups
 o First

Normal Form (1NF)

 Remov
e

multivalued attributes
 Each row of data has one value