Chapter 3 Flashcards

1
Q

Transaction Processing Systems (TPS)

A

Designed to support the processing of everyday operational business transactions (i.e., retrieving, adding, modifying, and deleting data)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Decision Support Systems (DSS)

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Business rules

A

Can be used to define or constrain some aspect of a business’s structure or processes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Data Modeling

A

is a design technique for capturing reality

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Conceptual Data Modeling

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Logical Data Modeling

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Physical Data Modeling

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

(ERD)- Entities

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

(ERD)– Attributes

A

named as singular nouns

A discrete data element
–Describes an entity (i.e., is a characteristic

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

(ERD)–Relationships

A

named as verbs or verb phrases

is an association between entities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Types of Attributes–Simple

A

at the atomic, most basic level

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Types of Attributes–Composite

A

a related group of attributes

example: Address (Street, City, State, Zip)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Types of Attributes–Single Valued

A

only one value per entity instance (e.g., Last Name, Date Of Birth)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Types of Attributes–Multivalued

A
  • multiple values per entity instance are possible (e.g., Degree, Club, Skill)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Types of Attributes–Derived

A

calculated, but not stored (e.g., Total)

These are only optionally shown on an ERD

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Types of Attributes–Identifier

A
  • an attribute that uniquely identifies each entity instance (e.g., Social Security Number)
17
Q

candidate key

A

is any attribute that would qualify as an identifier (e.g., SSN and Employee ID)

18
Q

cardinality

A

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)

19
Q

optionality

A

(modality) indicates whether partici-pation in the relationship is required or not
specified as either mandatory or optional

20
Q

Two Cases When you Must Use Associative Entities–Case #1

A

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.)

21
Q

Two Cases When you Must Use Associative Entities–Case #2

A

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.

22
Q

Strong Entity

A
  • -exists independently of other entities
  • -has its own unique identifier (shown w/single underline)
  • -represented with regular rectangle symbol
23
Q

Dependent (Weak) Entity

A
  • -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
24
Q

Identifying Relationship

A
  • -links strong entities to dependent (weak) entities

- -represented with diamond symbol with lines in corners

25
Q

Two Processes to Develop Supertype/Subtypes-Generalization

A

The process of defining a more general entity type from a set of more specialized entity types
–A “bottom-up” approach

26
Q

Two Processes to Develop Supertype/Subtypes–Specialization

A

The process of defining one or more sub-types of a general entity based on distinguishing attributes or relationships
–A “top-down” approach

27
Q

Supertype

A

(example: Employee)

a generic entity that has a relationship with one or more subtypes

28
Q

Subtype

A

(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

29
Q

Inheritance Rule

A
  • -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
30
Q

Rule Restricting the Use of Supertype/Subtypes

A

1 when there are attributes that apply to some (but not all) of the instances of an entity type

31
Q

Rule Restricting the Use of Supertype/Subtypes

A

2 .When the instances of a subtype participate in a relationship unique to that subtype

32
Q

Supertype/Subtype Relationships Rule

A

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)

33
Q

Completeness Constraint

A

Addresses the question of whether an instance of a supertype must also be a member of at least one subtype

34
Q

Disjointness Constraint

A

Addresses the question of whether an instance of a supertype may simultaneously be a member of two (or more) subtypes

35
Q

Total Specialization Rule (Double-line notation)

A

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)

36
Q

Partial Specialization Rule (Single-line notation)

A

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)

37
Q

Disjoint Rule (Letter “d” notation)

A

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)

38
Q

Overlap Rule (Letter “o” notation)

A

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)

39
Q

Subtype Discriminator

A

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