SM-09-New Reviewed by Hall Version 2

8/10/2019 SM-09-New Reviewed by Hall Version 2

1/54

Chapter 9 Page 99

CHAPTER 9

DATABASE MANAGEMENT SYSTEMS

REVIEW QUESTIONS

1. database planning, design, implementation, operation and maintenance, and change

and growth.

2. the users, the database management system, the database administrator, and the

physical database structures.

3. The primary difference between the network and hierarchical models is in the

parent child relationship. The network model allows a child file to ha!e multiple

parents. The hierarchical model permits a child to be associated with only one

parent record.

". a. #o data redundancy

b. $ingle update of data

c. Current !alues for all user applications

d. Task data independence.


2/54

Chapter 9 Page 1%%

&. program de!elopment, backup and reco!ery, database usage reporting, and

database access.

'. (ne le!el is the schema, which is the conceptual !iew of the data. The schema

describes the entire database, and it represents the database logically. The second

le!el is the internal !iew which is the physical arrangement of the records. )t this

le!el, the physical data records are described as well as linkages between files. The

ne*t le!el is the subschema, which is the e*ternal !iew of the database that specific

users ha!e authori+ation to use. This is also called the user !iew. This is the le!el

that users find of most interest.

. The primary key is a table attribute the !alue of which is uni-ue to the record. t is a

uni-ue identifier.

/. 0ogically related tables need to be physically connected to achie!e the associations

described in the data model. This is accomplished by embedding the primary key of

one table into the related table as a foreign key.

9. The data dictionary describes e!ery data element in the database. The data

dictionary enables all users and programmers to share a common !iew of the data

resource, thus facilitating greatly the analysis of user needs.

1%. )n organi+ation has three di!erse operating units tractors, sewing machines, and

computer chips. These units ha!e different customers, suppliers, and productionfacilities. (perating data are consolidated for financial reporting only.


3/54


4/54

Chapter 9 Page 1%2

1". The term association pertains to the nature of the relationship between two entities.

This is represented by a !erb such as shipped, re-uests, or recei!es. Cardinality is

the degree of association between two entities. $imply stated, cardinality describes

the number of possible occurrences in one table that are associated with a single

occurrence in a related table.

1&. n a many to many association, a link table with a combined composite key

consisting of the primary keys of the two related tables is created in order to link the

related tables.

1'. a. )ll occurrences at the intersection of a row and column are a single !alue. #o

multiple !alues repeating groups , partial dependencies, or transiti!e dependencies

are allowed.

b. The attribute !alues in any column must all be of the same class.

c. 4ach column in a gi!en table must be uni-uely named.

d. 4ach row in the table must be uni-ue in at least one attribute that is considered to be

the primary key.

1 . a. 7estrict 4*tracts rows that satisfy the gi!en condition from a specified table

and places these rows into a new table.

b. Pro@ect4*tracts columns from a specified table and places these attributes

columns into a new table.

c. AoinBuilds a new table from two tables consisting of all concatenated pairs of

rows, one from each table.

1/. ) table normali+ed to 3#= meets the following conditions

1. )ll nonkey attributes in the table are dependent on the primary key.


5/54

Chapter 9 Page 1%3

2. )ll nonkey attributes are independent of the other nonkey attributes.

n other words, the primary key of a table wholly and uni-uely defines each attribute

in the table, and none of the table attributes are defined by an attribute other than

the primary key.


6/54

Chapter 9 Page 1%"

19. The user may restrict the fields of data to !iew with the $404CT command. =urther,

the user may restrict the rows or records of data to be !iewed with the D474

command. The D474 command allows the user to !iew only those records that

ha!e !alues which fall within a certain range for one or more fields of data.

2%. ) data model is the blueprint for creating the physical database.


7/54


8/54

Chapter 9 Page 1%'

1. n the traditional data management en!ironment, applications are de!eloped with

data and program dependency. Typically, these programs are application specific.

Thus, the users of the application data tend to be proprietary about the data in 5their6

application and may not be amenable to sharing such data.

2. f your uni!ersity were to use different databases for the registrar, library, parking,

food ser!ices, and computing ser!ices, then the number of forms you would ha!e to

fill out, if any of your personal data changes, would be plentiful. =or e*ample, if you

were to mo!e during the semester to a different apartment, the uni!ersity should be

notified. n this situation, a couple of things could happen. ou could be re-uired to

go to each ser!ice indi!idually and fill out an address form, or you could go to one

central location and fill out a form that has multiple copies, which are sent to the

!arious areas on campus for update. n any case, your address could be keyed in

correctly by the registrar. ou might recei!e some correspondence from the registrar

and assume that the address correction was made. Dowe!er, a keypunch error

might ha!e occurred by the library staff, and you may not recei!e notification that

you ha!e a library book which you forgot about past due. )fter the end of the

semester, you may not recei!e your final grade report. hen you call the registrar,

you may find out that the library has reported that you ha!e an o!erdue book and

that your grades should be held until the book is returned, and the fine is paid.


9/54

Chapter 9 Page 1%

3. ;nder the database concept, the data becomes centrally stored with many different

users accessing the database. Dowe!er, each user should not ha!e access to the

whole database. ;nder the traditional data management approach, where the data

are limited to a single application, the user access problem was not as much of a

threat. The


10/54

Chapter 9 Page 1%/

'. The entity relationship 47 diagram is the graphical representation techni-ue used

to depict a data model. 4ach entity in an 47 diagram is named in the singular noun

form, such as Customer rather than Customers . The labeled line connecting two

entities describes the nature of the association between them. This association is

represented with a !erb, such as shipped, re-uests, or recei!es. The 47 diagram

also represents cardinality the degree of association between two entities . =our

basic forms of cardinality are possible +ero or one %,1 , one and only one 1,1 ,

+ero or many %,? , and one or many 1,? . These are combined to represent

logical associations between entities such as 1 1, 1 %,?, and ? ?.

. $E0 allows users to retrie!e data from many different files without the assistance of

programmer professionals. Thus, if the user has access to data files and knows

$E0, which is !ery user friendly, the user may retrie!e the data instantaneously.

/. The data was not centrally stored for many different applications to use in the

traditional data management en!ironmentF therefore, a database administrator was

not needed. Because it is centrally stored and shared by many users in a database

en!ironment, the need arose for an indi!idual to care for and control these files. The

database administrator is responsible for database planning, de!eloping the data

re-uirements and data dictionary, database design and controls, database

implementation and access controls, operation and maintenance, and establishing

and re!iewing the standards and procedures.


11/54

Chapter 9 Page 1%9

9. The system programmerGs program should not ha!e access to the data, e*cept

perhaps temporarily to test the programs. The database administrator controls the

access to the data. f one person has the authority to both write programs and access

data, then control issues become a concern. The potential to commit fraud or

embe++lement or to destroy or alter the companyGs records increases.

1%. #either table can donate an embedded key to the other, because both are on the

5many6 side. The only solution, therefore, is to create a new link table containing the

key fields of both tables.

11. Tables that are not normali+ed contain anomalies which re-uire e*cessi!e updates

to tables, pre!ent data from being stored properly, and may cause unintentional

deletion of data. )ccountants need to be familiar with normali+ation issues, because

these anomalies threaten the integrity of the financial data of the organi+ation.

12. ) database lockout pre!ents multiple users from accessing the same table

simultaneously and making changes to data !alues while they are temporarily

inconsistent. 0ockouts force changes to be made se-uentially to ensure data

accuracy.

13.


12/54

Chapter 9 Page 11%

1".


13/54

Chapter 9 Page 111

1'. The insertion and update anomalies would create record keeping and operational

problems for the firm. Dowe!er, flawed databases design that pre!ents the insertion

of records, or re-uires the user to perform e*cessi!e updates, would attract attention

-uickly. The presence of the deletion anomaly is less conspicuous, but potentially

more serious from an accounting perspecti!e. Because the deletion anomaly may go

undetected, the user may be unaware of the loss of important data until it is too late.

This anomaly can result in the unintentional loss of critical accounting records and

the destruction of the audit trail.

1 . The organi+ationGs business rules directly impact the structure of the database

tables. f the database is to function properly, its designers need to understand the

organi+ationGs business rules, as well as the specific needs of indi!idual users. =or

e*ample

1. hen an organi+ation decides to purchase the same items of in!entory from

different suppliers, the cardinality between the $upplier and n!entory tables is

? ?.

2. hen a the company purchases all items of a certain type from only one

supplier, the cardinality between $upplier and n!entory tables is 1 ?

respecti!ely.

3. ) policy that a separate recei!ing report is prepared for the receipt of goods

specified on a single purchase order will result in a 1 1 cardinality between the

recei!ing report and purchase order tables. f, howe!er, multiple purchase orders

are combined on a single recei!ing report, then the cardinality between these

tables will be 1 ? respecti!ely.


14/54

Chapter 9 Page 112

1/. The partitioned approach works best for organi+ations that re-uire minimal data

sharing among users at remote sites. To the e*tent that remote users share common

data, the problems associated with the centrali+ed approach will apply. The primary

user must now manage re-uests for data from other sites. $electing the optimum

host location for the partitions, to minimi+e data access problems, re-uires an in

depth analysis of end user data needs.

19. To achie!e data currency, simultaneous access to indi!idual data elements or

records by multiple users needs to be pre!ented. The solution to this problem is a

database lockout , which is a software control that pre!ents multiple simultaneous

accesses to data. ) deadlock occurs when multiple users seeking access to the

same set of records lockout each other. )s a result, the transactions of all users

assume a 5wait6 state until the locks are remo!ed. ) deadlock is a permanent

condition that must be resol!ed by special software that analy+es each deadlock

condition to determine the best solution.


15/54

Chapter 9 Page 113

2%. The primary @ustification for a replicated database is to support read only -ueries in

situations in!ol!ing a high degree of data sharing, but no primary user e*ists. ith

data replicated at e!ery site, data access for -uery purposes is ensured, and

lockouts and delays due to network traffic are minimi+ed. ) potential problem arises,

howe!er, when replicated databases need to be updated by transactions. $ince

each site processes only local transactions, the common data attributes that are

replicated at each site will be updated by different transactions and thus, at any point

in time, will ha!e uni-uely different !alues. $ystem designers need to employ

currency control techni-ues to ensure that transactions processed at differentlocations are accurately reflected in all the database copies.

MULTIPLE CHOICES

1. endor J >endor #ame >endor )ddress Telephone


29/54

Chapter 9 Page 12

12. $ee diagram below.

PI n!entory Table


30/54


31/54

Chapter 9 Page 129

PI $tatus

Table P(P( J PI endor J =I

Table P(K temP( J PI tem J PI Euantity

Table temtem J PI endor >endor J PI #ame )ddress Contact Terms Balance


32/54

Chapter 9 Page 13%

1&.

16. Defining Entities and Data Modeling - Payroll

7esponse


33/54

Chapter 9 Page 131

1 and 2

7e@ected 4ntitiesa 7eason

Payroll clerk >iolates rule 1 and 2 ordingsuggests only one clerk rule 1 and noe!idence of attributes uni-ue to thisentity rule 2

$agerod manufacturing company >iolates 7ule 1 the company is asingle occurrence

cash disbursements clerk >iolates rule 1 and 2

super!isor >iolates rule 1 and 2check for the total payroll This is a !iew >iolates rule 2paycheck This is a !iew >iolates rule 2payroll summary This is a !iew >iolates rule 2

V& ' %-" " %/

4mployeePaycheck register Cash disbursement @ournalTime card4mployee earnings =ile


34/54


35/54

Chapter 9 Page 133

data need to be captured by this system;nloading Personnel >iolates rule 2 )ssumption no employee specific

data need to be captured by this system$ales

7epresentati!es

>iolates rule 2 )ssumption The company does not

capture $ales 7ep data uni-ue to each transaction.(bsolescence

7eports

This is a !iew iolates rule 2n!oice physical This is a !iew ;sed to create n!oice 7ecord

>iolates rule 2Check physical This is a !iew iolates rule 2

Payment $ummary This is a !iew iolates rule 2Purchase 7e-uisition This is a !iew ;sed to create Purchase (rder

>iolates rule 2Customers #ot rele!ant to this system

V& ' E-" " %/ R%&/o-

Purchase ?anager )ssumption all store purchase managers will usethe system. This entity will consist of multiple

occurrences and pro!ide managerKstore specific

data not contained in other entities.$upplier ?eets conditions of 7ules 1 and 2n!entory ?eets conditions of 7ules 1 and 2Purchase (rder ?eets conditions of 7ules 1 and 27ecei!ing 7eport ?eets conditions of 7ules 1 and 2

n!oice record ?eets conditions of 7ules 1 and 2Payment (bligation ?eets conditions of 7ules 1 and 2Check register ?eets conditions of 7ules 1 and 2


36/54

Chapter 9 Page 13"


37/54

Chapter 9 Page 13&

1/. $olution a. and b.

R% %c"%' E-" " %/ R%&/o- )ccounts Payable

iolates rule 1 and 2M ording suggests only one

clerk rule 1 and no e!idence of attributes uni-ue to

this entity rule 2$afe Buy Hrocery

$tores

>iolates 7ule 1Mthe company is a single occurrence

=) 7ecei!ing 7eport

$ummary

This is a !iewM t deri!es entirely from recei!ing

report and thus !iolates rule 2


38/54

Chapter 9 Page 13'

7ecei!ing Clerk >iolates rule 2M)ssumption no employee specific

data need to be captured by this system )ccounts Payable

?anager

>iolates rule 2M)ssumption no employee specific

data need to be captured by this systemiolates rule 2Check physical This is a !iewMiolates rule 2Payment $ummary This is a !iewMiolates rule 2Purchase 7e-uisition This is a !iewM;sed to create Purchase (rder.

>iolates rule 2$tore ?anager )ssumption managerKstore specific data will be

contained in other entities i.e. Purchase (rder

V& ' E-" " %/ R%&/o-

$upplier ?eets conditions of 7ules 1 and 2=i*ed )ssets n!entory ?eets conditions of 7ules 1 and 2Purchase (rder ?eets conditions of 7ules 1 and 27ecei!ing 7eport ?eets conditions of 7ules 1 and 2n!oice record ?eets conditions of 7ules 1 and 2Payment (bligation ?eets conditions of 7ules 1 and 2Check register ?eets conditions of 7ules 1 and 2


39/54

Chapter 9 Page 13


40/54

Chapter 9 Page 13/


41/54

Chapter 9 Page 139

19.

7esponse1 and 2

7e@ected 4ntities a 7easonLotus Tea Importer Companyand all departments such asSales, warehouse, shippingdepartment, general ledgerdepartment, etc.

>iolates 7ule 1 the company and thesedepartments are single occurrences

>arious clerks such as $alesrepresentati!e, accountingdepartment clerk, )7 Clerk,etc.

>iolates rule 1 and 2 ording suggests onlyone clerk rule 1 and no e!idence of attributesuni-ue to this entity rule 2

stock release document This is a !iew t deri!es entirely from salesorder and thus !iolates rule 2

?ail room employees >iolates rule 2 )ssumption no employeespecific data need to be captured by this system

packing slip. This is a !iew iolates rule 2

n!oice physical This is a !iew deri!ed from sales order >iolatesrule 2

Customer Check physical This is a !iew used to create record in cashreceipts @ournal >iolates rule 2

in!entory account summary This is a !iew iolates rule 2

remittance ad!ices This is a !iew that is deri!ed from the sales orderand sent to the customer to facilitate postingpayments to the correct customer account

)7 account summery This a !iew deri!ed from the )7 subsidiaryledger or the total of all unpaid sales orders

price list Hi!en the limited information in the problem, thisentity may be represented as either a separatetable or more simply as a field in the in!entoryrecord. e assume the latter in this solution.


42/54

Chapter 9 Page 1"%

V& ' %-" " %/ R%&/o-

Customer ?eets conditions of 7ules 1 and 2$ales order ?eets conditions of 7ules 1 and 2in!entory product ?eets conditions of 7ules 1 and 2

?eets conditions of 7ules 1 and 2Cash receipts record C7

@ournal?eets conditions of 7ules 1 and 2

bill of lading ?eets conditions of 7ules 1 and 2carrier ?eets conditions of 7ules 1 and 2deposit slip ?eets conditions of 7ules 1 and 2$hipping #otice ?eets conditions of 7ules 1 and 2

?eets conditions of 7ules 1 and 2

T$% ER ' &.*& / - "$% /"!'%-" /o !" o-/ +*o# co-"& - "$%&cco!-" -.2*%co*' %-" " %/ - "$% " % #% o34 T%c$- c& , $o3%5%*,"$%/% %-" " %/ &*% -o" -%c%//&* - & o'%*- '&"&/% / /"% 4 T$ ///!% / &- &/+%c" o6 REA o'% -. "$&" / %7& -%' - '%"& - c$&+"%* 10 o6 "$% "%7"4 T$% " % #% o3 !/"*&"%/ $o3 %&c$ o6 "$%/% &cco!-" -.*%co*'/ c&- #% '%* 5%' 6*o o"$%* "*&-/&c" o-& '&"&/% " %/4 T$%/o !" o-/ "o +&*"/ C &-' D o6 "$ / +*o# % 'o -o" -c !'% "$%/%!--%c%//&* %-" " %/

U--%c%//&*Acco!-" -. R%co*'/

M& #% '%* 5%' &/ 6o o3/

$ales Aournal This is e-ui!alent to sales order records

)7 $ubsidiary ledger This is the sum of all sales order records organi+edby customer that are still open unpaid at periodend.

)7 control accounts H0 This is the sum total of all sales order records thatare still open unpaid at the period end.

cost of goods sold accountH0

Calculated as the -uantity sold sales (rder 8 thecost of the item taken from the in!entory record

in!entory control H0 $um of all in!entory records

sales account H0 This is sum total sales order records @ournal !oucher This is the sum of the transaction detail captured

by the cash receipts records andKor the c


43/54

Chapter 9 Page 1"1


44/54

Chapter 9 Page 1"2


45/54

Chapter 9 Page 1"3

2%


46/54

Chapter 9 Page 1""

21.


47/54


48/54

Chapter 9 Page 1"'

R% %c"%' E-" " %/ R%&/o-$ara, Purchasing

Clerk

>iolates rule 2M)ssumption no employee specific

data need to be captured by this system.P( Blind Copy This is a !iewMderi!ed from Purchase (rder

record. >iolates rule 2Cash iolates rule 2M)ssumption no employee specific

data need to be captured by this system.Payment Check

Physical

This is a !iewMCreated from Check 7egister

record. >iolates rule 2Packing $lip This is a !iewMCreated from $ales (rder record.

>iolates rule 2


49/54

Chapter 9 Page 1"

V& ' %-" " %/ R%&/o-Customer ?eets conditions of 7ules 1 and 2$ales (rder ?eets conditions of 7ules 1 and 2$ales Aournal ?eets conditions of 7ules 1 and 2n!entory $ub 0edger ?eets conditions of 7ules 1 and 2

Bill of 0ading ?eets conditions of 7ules 1 and 2Heneral 0edger ?eets conditions of 7ules 1 and 2Cash 7eceipts Aournal ?eets conditions of 7ules 1 and 27eturn 7ecord ?eets conditions of 7ules 1 and 2Purchase (rder ?eets conditions of 7ules 1 and 2$upplier ?eets conditions of 7ules 1 and 2

)ccount Payable ?eets conditions of 7ules 1 and 27ecei!ing 7eport ?eets conditions of 7ules 1 and 2

$upplier n!oice

record

?eets conditions of 7ules 1 and 2

Check register ?eets conditions of 7ules 1 and 2


50/54

Chapter 9 Page 1"/

22, part c.


51/54

Chapter 9 Page 1"9

22, part d. =ully )ttributed ?odel 4*penditure Procedures


52/54

Chapter 9 Page 1&%

22 part d. =ully )ttributed ?odel 7e!enue Cycle Procedures

22, part e.


53/54

Chapter 9 Page 1&1


54/54

Chapter 9 Page 1&2

SM-09-New Reviewed by Hall Version 2

Documents

Transcript of SM-09-New Reviewed by Hall Version 2