payroll – production / sales / purchasing – personnel
Update employee’s address – each department’s file
Each department has own file containing addresses
Duplication of data
For a single organization want integrated information stored and maintained in a “single” location
Fig. 9.1: A file versus a database organization Data in “single” location. All access single location. Data now stored for good of company – not for benefit of department only.
Database concepts database administrator (DBA) – administrator (not an executive) - knows data available - knows data organization - accommodates needs of organization and then departments With benefits of data integration comes problems - access to sensitive data News letter editor – has no need to see payroll info Payroll people – have no need to see financial records Personnel – has no need to see strategic plans, etc. Must control access to data
Database concepts Must control access to data – so we develop schemas schema – description of entire database – used by database software to maintain database subschema – description of only a part of database that is pertinent to particular user’s or department’s needs Soooo - subschema definition includes who has access to this part and issue of security is addressed
#2 - deleting info that causes other info to also be removed
See Fig. 9.4
Fig. 9.4a: A relation containing redundancy #1 – lack of efficiency due to redundancy #2 - deleting a tuple may cause other info to be lost Delete Joe E. Baker – what happens to info for job D7? added to employee relation
Fig. 9.4b: A relation containing redundancy Problems all caused by combining more than one concept into a single relation. - Employee info (name, ID, address, SS Num) - Job info (start date, end date) - Info on relationship between employees and jobs added to employee relation
Fig. 9.5: Employee database made with 3 relations ASSIGNMENT relation Empl ID Job ID Start Date Term Date 23Y34 S25X 3-1-1999 4-30-2001 34Y70 F5 10-1-2001 * 23Y34 S25Z 5-1-2001 * - - - - - - - - - - - - Now – only one concept per relation
Fig. 9.6a: Finding the departments in which employee 23Y34 has worked
Fig. 9.6b: Finding the departments in which employee 23Y34 has worked Info available in the one large relation accessible via three small relations without the problems discussed.
Fig. 9.7: A relation and a proposed decomposition May lose data – How would we find employee’s department if more than one department had a job with same title? A decomposition into smaller relations that does NOT lose information is a loss-less decomposition or nonloss decomposition. 25X1 programmer accounting 33Z2 programmer finance 25X1 programmer programmer accounting 33Z2 programmer programmer finance
Fig. 9.8: The SELECT operation find all info about a specific employee SELECT gets rows (tuples)
Fig. 9.9: The PROJECT operation get only specific info (attributes) about all employees PROJECT gets specific columns (attributes)
How are relational operations SELECT, PROJECT, & JOIN performed in SQL?
NEW1 JOIN ASSIGNMENT and JOB where ASSIGNMENT.JobId = JOB.JobId NEW2 SELECT from NEW1 where ASSIGNMENT.TermDate = “ * ” LIST PROJECT ASSIGNMENT.EmplId, JOB.Dept from NEW2 SQL statements select EmplId, Dept from ASSIGNMENT, JOB where ASSIGNMENT.JobId = JOB.JobId and ASSIGNMENT.TermDate = ‘*’
Relational operation – SQL statements select EmplId, Dept select clause PROJECT operation from ASSIGNMENT, JOB from clause JOIN operation where ASSIGNMENT.JobId = JOB.JobId where clause and ASSIGNMENT.TermDate = ‘*’ SELECT operation NEW1 JOIN ASSIGNMENT and JOB where ASSIGNMENT.JobId = JOB.JobId NEW2 SELECT from NEW1 where ASSIGNMENT.TermDate = “ * ” LIST PROJECT ASSIGNMENT.EmplId, JOB.Dept from NEW2
More SQL examples select EmplId, Name, Address, SSNum SELECT operation from EMPLOYEE where Name = ‘Cheryl H. Clark’ select Name, Address PROJECT operation from EMPLOYEE select Name, Address combined from EMPLOYEE SELECT and where Name = ‘Cheryl H. Clark’ PROJECT operation
More SQL select EMPLOYEE.Name, ASSIGNMENT.StartDate PROJECTing from EMPLOYEE, ASSIGNMENT JOINing where EMPLOYEE.EmplId = ASSIGNMENT.EmplId SELECTing
SQL statement provide SQL statements for - defining relational structures - creating relations - modifying relations - querying (as we have seen) insert into EMPLOYEE adds a tuple values (’42Z12’, ‘Sue A. Burt’, ’33 Fair St.’, ‘444661111’) delete from EMPLOYEE removes a tuple where Name = ‘G. Jerry Smith’ update EMPLOYEE modify tuple’s attributes set Address = ‘1812 Napoleon Ave.’ where Name = ‘Joe E. Baker’