Mgt 4058 - Database Mgt - Test 1 Vocabulary

Front 1

Database

Back 1

An organized collection of logically related data (includes data & metadata)

Front 2

Data

Back 2

Facts that can be recorded or stored using computer media

Front 3

Information

Back 3

Data processed in such a way that it can increase the knowledge of the person who uses it

Front 4

*** Metadata ***

Back 4

*** Data that describes the properties or characteristics of other data (name, type, length, etc.) ***

Front 5

DBMS

Back 5

(Database Management System) General purpose software system that facilitates the processes of defining, creating, using & maintaining databases

Front 6

Elements of the Database Approach

Back 6

Data Models
Relational Databases
Use of Internet Technology
Database Applications

Front 7

Types of Data Models

Back 7

Enterprise Data Model - high-level entities & relationships for the organization (no attributes on ER Diagram)

Project Data Model - More detailed view, shows exact data structure in database or data warehouse (includes attributes!)

Front 8

Relational Databases

Back 8

Technology involving tables (relations) representing entities & primary/foreign keys representing relationships

Front 9

Database Applications

Back 9

Application programs used to perform database activities (create, read, update, delete) for database users

Front 10

Enterprise Data Model

Back 10

First step in database development
Specifies scope & general content
Overall picture of org. data at high level of abstraction
Includes:
-ER Diagram
-Descriptions of entity types
-Relationships between entities
-Business Rules

Front 11

System Development Life Cycle

Back 11

Detailed, well-planned development process, time-consuming but comprehensive, long development cycle
Steps include:
- Planning
- Analysis
- Logical Design
- Physical Design
- Implementation
- Maintenance

Front 12

SDL Cycle: Step 1

Back 12

Planning
- Purpose: Preliminary understanding
- Deliverable: Request for study
- Database Activity: Enterprise modeling & early conceptual data modeling

Front 13

SDL Cycle: Step 2

Back 13

Analysis
- Purpose: Thorough requirements analysis & structuring
- Deliverable: functional system specifications
- Database Activity: Thorough & integrated conceptual data modeling

Front 14

SDL Cycle: Step 3

Back 14

Logical Design
- Purpose: Info requirements elicitation & structure
- Deliverable: Detailed design specifications
- Database Activity: Logical DB design (transactions, forms, displays, views, data integrity & security)

Front 15

SDL Cycle: Step 4

Back 15

Physical Design
- Purpose: Develop tech & organizational specifications
- Deliverable: Program/data structures, tech purchases, org. redesigns
- Database Activity: Physical database design (define database to DBMS, physical data org. database processing programs)

Front 16

SDL Cycle: Step 5

Back 16

Implementation
- Purpose: Programming, testing, training, installation & documentation
- Deliverable: Operational programs, documentation & training materials
- Database Activity: Database implementation, including coded programs, documentation, installation & conversion

Front 17

SDL Cycle: Step 6

Back 17

Maintenance
- Purpose: monitor, repair & enhance
- Deliverable: Periodic audits
- Database Activity: Database maintenance, performance analysis & tuning, error corrections

Front 18

Database Scheme

Back 18

External Schema
Conceptual Schema
Internal Schema

Front 19

External Schema

Back 19

User views
Subsets of Conceptual Schema - can be determined from business function/data entity matrices
DBA determines schema for different users

Front 20

Conceptual Schema

Back 20

ER Models that links the external schema to the internal schema

Front 21

Internal Schema

Back 21

Logical (database entities, etc.) & Physical (hardware, software features, performance expectations, etc.) structures

Front 22

Business Rule

Back 22

A statement that defines or constrains some aspect of the business. Intended to assert business structure or to control/influence the behavior of business

Front 23

Good Business Rule Is:

Back 23

Declarative - What, not how
Precise - clear, agreed-upon meaning
Atomic - 1 statement
Consistent - internally & externally
Expressible - Structured, natural language
Distinct - Non-redundant
Business-oriented - Understood by business people

Front 24

Good Data Name is:

Back 24

- Related to business (not technical) characteristics
- Readable
- Repeatable
- Meaningful
- Unique
- Composed of words from an approved list
- Follows standard syntax

Front 25

Data definitions

Back 25

Definition is an explanation of a term or fact

Front 26

Good Data Definitions are:

Back 26

- Gathered in conjunction with systems requirements
- Accompanied by diagrams
- Concise description of essential data meaning
- Achieved by consensus & iteratively refined

Front 27

ER Model

Back 27

Conceptual model that becomes the basis for a database blueprint or a logical representation of data for an org. or for a business area

Front 28

ER Diagram Components

Back 28

Square - Entity
Oval - Attributes
Diamond - Relationship
Lines - link attributes to entities & entities to relationships
Double Oval - multi-valued attributes
Double square - Weak entities
Primary key attributes are underlined

Front 29

Entity Type

Back 29

Collection of entities that share common properties or characteristics (aka Entity)

Front 30

Entity Instance

Back 30

Single occurrence of an entity type

Front 31

Strong Entity

Back 31

Exists independently

Front 32

Weak Entity

Back 32

Depends on the existence of another entity to have significance (Does NOT have to have ti's own identifier key)

Front 33

An entity should be an object that:

Back 33

- will have many instances in the database
- will be composed of multiple attributes
- we are trying to model

Front 34

An entity should NOT be:

Back 34

- a user of the databases system
- an output of the database system (e.g. a report)

Front 35

Attribute Types

Back 35

Simple (atomic)
Composite
Single-Valued
Multi-Valued
Stored
Derived

Front 36

Simple Attribute

Back 36

Cannot be subdivided into further attributes

Front 37

Composite Attribute

Back 37

Can be subdivided into further attributes

Front 38

Single-Valued Attribute

Back 38

1 possible value only

Front 39

*** Multi-Valued Attribute ***

Back 39

*** Multiple values possible (e.g. hobbies) ***

Front 40

Stored Attribute

Back 40

actually put into the database by someone/thing

Front 41

Derived Attribute

Back 41

Calculated based on an algorithm from other, stored data

Front 42

Identifiers

Back 42

An attribute (or combination of attributes) that uniquely identifies each entity instance.
Must include:
- Composite Identifier - an identifier that consists of a composite attribute
- An identifier can be 1 or more attributes
- Create an identifier if there is no obvious identifying attribute
- Underline identifiers in diagrams
- Must be unique
- Should not change value over time
- Guaranteed to have a valid value
- Try to substitute single-attribute identifiers for composite identifiers to simplify design & enhance performance

Front 43

Attributes may be linked to relationships if

Back 43

a relationship has some attributes associated with it

Front 44

Degree of Relationship

Back 44

# of entities involved in a relationship

Front 45

Cardinality

Back 45

describes the # of instances 1 entity can/must be associated with each instance of another entity. Established by business rules.
Types:
- (1:1)
- (1:m)
- (m:n)

Front 46

Associative Entity

Back 46

Entity type that associates the instances of 1 or more entity types & contains the attributes that are peculiar to the relationship between those entity instances. Used to convert (m:n) cardinality into (1:m) relationships

Front 47

Minimum Cardinality

Back 47

Minimum # of instances of 1 entity that may be associated with each instance of another entity

Front 48

Maximum Cardinality

Back 48

Max # of instances of 1 entity that may be associated with each instance of another entity

Front 49

Optional & Mandatory Relationships

Back 49

If minimum cardinality = 0, participation is optional. If minimum cardinality > 0, participation is mandatory

Front 50

Supertype Relationship

Back 50

Generic entity that has a relationship with 1 or more subtypes

Front 51

Subtype Relationship

Back 51

Subgrouping of a supertype entity that is meaningful to an organization. Shares all attributes of its supertype but also has unique attributes of its own &/or has relationships with other entities distinct from those of other subtypes

Front 52

*** When to use Super/Subtype Relationships ***

Back 52

*** 1) When there are attributes that apply to some (but not all) of the instances of an entity type
2) When the instances of a subtype participate in a relationship unique to that subtype ***

Front 53

Super/Subtype Constraints

Back 53

Completeness
a) Total Specialization Rule
b) Partial Specialization Rule
Disjointness:
a) Disjoint Rule
b) Overlap Rule

Front 54

Completeness

Back 54

whether an instance of a supertype must also be a member of at least 1 subtype

Front 55

Total Specialization Rule (Double Line Notation)

Back 55

Each entity instance of that supertype must be a member of some subtype in the relationship

Front 56

*** Partial Specialization Rule (Single Line Notation) ***

Back 56

*** An entity instance of the supertype is allowed to not belong to any subtype. E.g. faculty & staff are not the only possible employee types. ***

Front 57

Disjointness

Back 57

whether an instance of a supertype may simultaneously be a member of 2 or more subtypes

Front 58

Disjoint Rule (letter "d" notation)

Back 58

if an entity instance is a member of 1 subtype, it cannot be a member of any other subtypes. E.g. all people must be either Male or Female

Front 59

Overlap Rule (letter "o" notation)

Back 59

an entity instance can simultaneously be a member of 2 or more subtypes

Front 60

Subtype Discriminator

Back 60

attribute of the supertype whose values determine the target subtype or subtypes. Used to direct into which of the subtypes (if any_ a new instance of the supertype should be inserted. Can be indicated by either a Disjoint or Overlap subtype discriminator (written as a question on the ER diagram)

Front 61

Super/Subtype Hierarchy

Back 61

Hierarchical arrangement of super & sub types where each subtype has only 1 supertype. Attributes are assigned at the highest logical level that is possible in the hierarchy. Subtypes that are lower in the hierarchy inherit attributes not only from their immediate supertype but also from all supertypes higher in the hierarchy (up to the root)

Front 62

Properties of Relations

Back 62

- Each relation in a given database has a unique name
- Each attribute within a given table has a unique name & is atomic (single valued)
- Every row is unique
- The order of the columns/rows is irrelevant

Front 63

Super Key

Back 63

Attribute (or combo of attributes) that uniquely identifies each row (entity instance) in a table

Front 64

Candidate Key

Back 64

Superkey without any redundant attributes (all candidates are super keys, but not all super keys are candidate keys)

Front 65

Primary Key

Back 65

Attribute whose value uniquely identifies each row in a relation

Front 66

Composite Key

Back 66

Primary key made up of more than 1 attribute.
Must have:
- Uniqueness
- Minimality
- Not allowed to accept nulls

Front 67

Uniqueness

Back 67

At any time, no 2 rows of the same table have the same value for the key

Front 68

Minimality

Back 68

If the key is composite (multi-attributes) than no component of it can be eliminated without destroying the uniqueness property

Front 69

Secondary Key

Back 69

Attribute (or combo of attributes) used strictly for data retrieval purposes. Does NOT necessarily yield a unique outcome

Front 70

Foreign Key

Back 70

Attribute in 1 relation that serves as the primary key of another relation in the same database (i.e. linking field)

Front 71

Integrity Constraints

Back 71

- Domain Constraint
- Entity Integrity Rule
- Operational Constraint
- Referential Integrity Constraint

Front 72

Domain Constraint

Back 72

Constrains allowable values for an attribute (e.g. data type, field size, valid range, etc.)

Front 73

Entity Integrity Rule

Back 73

No primary key attribute (or component of a primary key attributes) may be null

Front 74

Operational Constraint

Back 74

Business Rules

Front 75

*** Referential Integrity Constraint ***

Back 75

*** Rule that states that either each foreign key value must match a primary key value in another relation or the foreign key value must be null. E.g. Delete rules in Microsoft Access ***

Front 76

Well Structured Relations are:

Back 76

relations that contain minimal redundancy, allows for users to insert, modify & delete the rows in a table without errors or inconsistencies.

Front 77

Anomalies

Back 77

- Insertion
- Deletion
- Modification

Front 78

Insertion Anomalies

Back 78

an attempt to store a value for 1 attribute does not succeed because the value of another attribute is unknown

Front 79

Deletion Anomalies

Back 79

a value for 1 attribute we wish to keep is unexpectedly removed when a value for another attribute is deleted

Front 80

Modification Anomalies

Back 80

when changes to multiple instances of an entity (rows of a table) are needed to effect an update to a single value of an attribute