Itac Test 1

Front 1

flat file

Back 1

Each application is independently developed and maintained; Integration is accomplished by passing data from one application to another: PRO: independent control & inexpensive, CON: redundant (^cost and ineficiencies), narrow focus high aggregation, difficult to integrate across applications

Front 2

data redundancy

Back 2

increases costs and inconsistencies… multiple areas for same data

Front 3

database management system (DBMS)

Back 3

the middleman between the physical storage of the data seen by the user. It is the “engine” responsible for the managing the storage and retrieval of data.

Front 4

hierarchical tree model

Back 4

can support 1:1 or 1:m relationships; one directional path; linking through physical pointers (to the next related record)

Front 5

network model

Back 5

can support 1:1, 1:m, and m:n relationships; linking is explicit through physical pointers, difficult for complex entities.

Front 6

relational model

Back 6

can support 1:1, 1:m, and m:n relationships; linking is implicit through use of key fields

Front 7

data definition language (DDL)

Back 7

used to create tables and relationships among tables

Front 8

data manipulation language (DML)

Back 8

used to add delete and update data (forms are often used to facilitate this process)

Front 9

data query language (DQL)

Back 9

used to extract data from the database

Front 10

structured query language (SQL)

Back 10

a code based technique for extracting data

Front 11

query by example (QBE)

Back 11

a graphic technique for specifying selection criteria

Front 12

data dictionary

Back 12

centralized listing of all data elements in the database; includes a description of the data item the data type which applications can insert, update, or delete the data item, which reports contain the data item etc…

Front 13

attribute

Back 13

(same as field) parts making up the table

Front 14

field

Back 14

(same as attribute) parts making up the table

Front 15

record

Back 15

(same as tuple) data in stored in the field

Front 16

tuple

Back 16

(same as record) data in stored in the field

Front 17

cardinality

Back 17

Cardinalities are established for both sides of a relationship; The maximum cardinality from each side is taken to define the cardinality of the relationship as a whole; Optional relationships are always treated as a “many” relationship

Front 18

entity relationship (ER) diagram

Back 18

shows cardinal relationship between related entities

Front 19

event-driven modeling

Back 19

using events within major business processes to model a diagram

Front 20

operating events/processes

Back 20

only kind of event included in database modeling processes

Front 21

information events/processes

Back 21

not included in database modeling system

Front 22

decision events/processes

Back 22

not included in database modeling system

Front 23

agents

Back 23

need to determine internal and external agents involved with the operating events/processes

Front 24

resources

Back 24

need to determine resources used to complete the operating events/processes

Front 25

repeating group

Back 25

*need to recognize that they represent violations of normal form

Front 26

transitive dependency

Back 26

*need to recognize that they represent violations of normal form

Front 27

partial dependency

Back 27

*need to recognize that they represent violations of normal form

Front 28

flat file

Back 28

Each application is independently developed and maintained; Integration is accomplished by passing data from one application to another: PRO: independent control & inexpensive, CON: redundant (^cost and ineficiencies), narrow focus high aggregation, difficult to integrate across applications

Front 29

data redundancy

Back 29

increases costs and inconsistencies… multiple areas for same data

Front 30

database management system (DBMS)

Back 30

the middleman between the physical storage of the data seen by the user. It is the “engine” responsible for the managing the storage and retrieval of data.

Front 31

hierarchical tree model

Back 31

can support 1:1 or 1:m relationships; one directional path; linking through physical pointers (to the next related record)

Front 32

network model

Back 32

can support 1:1, 1:m, and m:n relationships; linking is explicit through physical pointers, difficult for complex entities.

Front 33

relational model

Back 33

can support 1:1, 1:m, and m:n relationships; linking is implicit through use of key fields

Front 34

data definition language (DDL)

Back 34

used to create tables and relationships among tables

Front 35

data manipulation language (DML)

Back 35

used to add delete and update data (forms are often used to facilitate this process)

Front 36

data query language (DQL)

Back 36

used to extract data from the database

Front 37

structured query language (SQL)

Back 37

a code based technique for extracting data

Front 38

query by example (QBE)

Back 38

a graphic technique for specifying selection criteria

Front 39

data dictionary

Back 39

centralized listing of all data elements in the database; includes a description of the data item the data type which applications can insert, update, or delete the data item, which reports contain the data item etc…

Front 40

attribute

Back 40

(same as field) parts making up the table

Front 41

field

Back 41

(same as attribute) parts making up the table

Front 42

record

Back 42

(same as tuple) data in stored in the field

Front 43

tuple

Back 43

(same as record) data in stored in the field

Front 44

cardinality

Back 44

Cardinalities are established for both sides of a relationship; The maximum cardinality from each side is taken to define the cardinality of the relationship as a whole; Optional relationships are always treated as a “many” relationship

Front 45

entity relationship (ER) diagram

Back 45

shows cardinal relationship between related entities

Front 46

event-driven modeling

Back 46

using events within major business processes to model a diagram

Front 47

operating events/processes

Back 47

only kind of event included in database modeling processes

Front 48

information events/processes

Back 48

not included in database modeling system

Front 49

decision events/processes

Back 49

not included in database modeling system

Front 50

agents

Back 50

need to determine internal and external agents involved with the operating events/processes

Front 51

resources

Back 51

need to determine resources used to complete the operating events/processes

Front 52

repeating group

Back 52

*need to recognize that they represent violations of normal form

Front 53

transitive dependency

Back 53

*need to recognize that they represent violations of normal form

Front 54

partial dependency

Back 54

*need to recognize that they represent violations of normal form