Chapter 3 Flashcards
Transaction Processing Systems (TPS)
Designed to support the processing of everyday operational business transactions (i.e., retrieving, adding, modifying, and deleting data)
Decision Support Systems (DSS)
Specifically designed to aid managers in decision-making tasks
- -Contain data that has been accumulated over time to aid in trend analysis and forecasting
- -Data about subjects must be organized in such a way that it provides a unified, overall picture of all the important details about the subjects over time
- -Data warehouses are the most common example
- -Data marts are subsets of data warehouses designed to support a part of an organization
Business rules
Can be used to define or constrain some aspect of a business’s structure or processes
Data Modeling
is a design technique for capturing reality
Conceptual Data Modeling
goal is to arrive at an understanding of the principal data sources and data elements of interest to the business or organization, and the relationships between the data sources, in order to satisfy requirements for information
tool is the Entity-Relationship Diagram (ERD)
Logical Data Modeling
goal is to convert the conceptual model into a form that can be utilized to create an IS (e.g., a relational database)
–tool is the Relational Schema
Physical Data Modeling
goal is to specify all identifying & operational characteristics of the data that will be recorded in the information system
–tools include the Data Dictionary and others
(ERD)- Entities
named as singular nouns
Entity is something of interest in the environment that is described by attributes and that will have numerous instances we wish to track
(ERD)– Attributes
named as singular nouns
A discrete data element
–Describes an entity (i.e., is a characteristic
(ERD)–Relationships
named as verbs or verb phrases
is an association between entities
Types of Attributes–Simple
at the atomic, most basic level
Types of Attributes–Composite
a related group of attributes
example: Address (Street, City, State, Zip)
Types of Attributes–Single Valued
only one value per entity instance (e.g., Last Name, Date Of Birth)
Types of Attributes–Multivalued
- multiple values per entity instance are possible (e.g., Degree, Club, Skill)
Types of Attributes–Derived
calculated, but not stored (e.g., Total)
These are only optionally shown on an ERD
Types of Attributes–Identifier
- an attribute that uniquely identifies each entity instance (e.g., Social Security Number)
candidate key
is any attribute that would qualify as an identifier (e.g., SSN and Employee ID)
cardinality
of a relationship describes the number of instances of one entity that may be associated with one instance of another entity
specified as either one or many (many = one or more)
optionality
(modality) indicates whether partici-pation in the relationship is required or not
specified as either mandatory or optional
Two Cases When you Must Use Associative Entities–Case #1
If it is necessary to assign an identifier to uniquely identify each occurrence of the M:M relationship between the original entities, then an associative entity must be created.
(Entities have identifiers; relationships do not.)
Two Cases When you Must Use Associative Entities–Case #2
In a ternary relationship, if the optionalities at all three entities are not identical, then an associative entity must be created. Other- wise, the ERD cannot depict the interactions between the entities without ambiguity.
Strong Entity
- -exists independently of other entities
- -has its own unique identifier (shown w/single underline)
- -represented with regular rectangle symbol
Dependent (Weak) Entity
- -dependent on a strong entity; cannot exist on its own
- -does not have a unique identifier, only a partial –identifier (shown w/double underline)
- -represented with rectangle symbol with lines in corners
Identifying Relationship
- -links strong entities to dependent (weak) entities
- -represented with diamond symbol with lines in corners
Two Processes to Develop Supertype/Subtypes-Generalization
The process of defining a more general entity type from a set of more specialized entity types
–A “bottom-up” approach
Two Processes to Develop Supertype/Subtypes–Specialization
The process of defining one or more sub-types of a general entity based on distinguishing attributes or relationships
–A “top-down” approach
Supertype
(example: Employee)
a generic entity that has a relationship with one or more subtypes
Subtype
(example: Manager)
a subgrouping of a supertype entity that is meaningful to an organization (not just possible)
–shares all attributes of its supertype, but also has unique attributes of its own and/or :
–has relationships with other entities distinct from those of other subtypes
Inheritance Rule
- -An instance of a subtype is also an instance of the supertype
- -Subtype entities inherit values of all attributes of the supertype
- –this makes it unnecessary to include the supertype’s attributes redundantly with the subtypes
Rule Restricting the Use of Supertype/Subtypes
1 when there are attributes that apply to some (but not all) of the instances of an entity type
Rule Restricting the Use of Supertype/Subtypes
2 .When the instances of a subtype participate in a relationship unique to that subtype
Supertype/Subtype Relationships Rule
Relationships shown at the supertype level indicate that all subtypes will participate in the relationship
—(Example: “is assigned to” relationship on slide #40)
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
—(Example: “belongs to” relationship on slide #40)
Completeness Constraint
Addresses the question of whether an instance of a supertype must also be a member of at least one subtype
Disjointness Constraint
Addresses the question of whether an instance of a supertype may simultaneously be a member of two (or more) subtypes
Total Specialization Rule (Double-line notation)
Specifies that each entity instance of the super-type must be a member of some subtype in the relationship
–(Example: all STUDENTS are either UNDERGRADUATE or GRADUATE students)
Partial Specialization Rule (Single-line notation)
Specifies that an entity instance of the super-type is allowed to not belong to any subtype (Example: FACULTY and STAFF are not the only possible types of EMPLOYEE)
Disjoint Rule (Letter “d” notation)
Specifies that if an entity instance is a member of one subtype, it cannot simultaneously be a member of any other subtype (Example: all PERSONS are either MALE or FEMALE)
Overlap Rule (Letter “o” notation)
Specifies that an entity instance can simultaneously be a member of two (or more) subtypes (Example: an ATHLETE can be both a RUNNER and a JUMPER)
Subtype Discriminator
An attribute of the supertype whose values etermine the target subtype or subtypes
(Used to direct into which of the subtypes, if any, a new instance of the supertype should be inserted)
Disjoint – a simple attribute with alternative values to indicate the possible subtypes
Overlap – a composite attribute whose subparts pertain to different subtypes; each subpart contains a boolean value (yes or no) to indicate whether or not the instance belongs to the associated subtype
