introduction to fis 318/618, financial systems & databases: the relational database model...
Post on 19-Dec-2015
227 views
TRANSCRIPT
![Page 1: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/1.jpg)
Introduction to FIS 318/618,Financial Systems & Databases:
The Relational Database Model
Oakland UniversitySchool of Business Administration
Accounting and FinanceJoe Callaghan
![Page 2: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/2.jpg)
The Relational Database Model
• Based on the theory of relational math (set theory)• It is an “automatic transmission” database (with
embedded relationships between tables) which replaces the “standard transmission” database (which employs flat-file techniques with explicit pointers between files and records)
• Flat-files (collections of similar records) are being replaced by collections of interrelated files
• Allows data to be broken down into logical, smaller, more manageable units - simplifies the organization of complex sets of data
![Page 3: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/3.jpg)
Why A Relational Model?• Duplicate data reduced - less input, maintenance, storage,
and improved data integrity• Data independence: Data can be thought of as being stored
in tables regardless of how physically stored.• Application independence: Databases defined
independently from the systems and programs that will use them - allows users to create ad hoc queries, rather than only receive pre-specified reports
• A change in the database does not require rewriting all the application program codes. Ability to share same data across multiple applications and systems.
• It has the ability to maintain several tables of related information that can be accessed by several different users in many different ways - a single query can retrieve data from more than one table.
![Page 4: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/4.jpg)
Some Definitions...Data: Raw facts about the organization and its business
transactions that are of interest to the end user
Database: A computer structure that houses a collection of data
Relational database: Stores information about instances of entities (a specific sales event, salesperson), attributes of those entities (invoice no., salesperson ID) , and the relationships among these entities (each sale can only have one salesperson) - perceived by user to be a collection of two-dimensional tables
RDBMS: Software that manages a relational database, controls access, and allows users to retrieve requested data through a standard data-access language, SQL.
![Page 5: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/5.jpg)
Entity-type: Something of significance about which you want to store data in a database, e.g., customers, employees, suppliers, inventory items (note: this is a data modeling term – an entity becomes a table in a RDBMS)
Table: An entity-type (e.g., customer) and its attributes
Attribute: A property or characteristic of an entity. A column in a relational database table, e.g., customer name, reference #, address, zip ((note: this is a data modeling term – an attribute becomes a column in a RDBMS
Row (tuple, record): A record of data in a database table - a single occurrence or entity instance
Value: Data in a “cell” – the intersection between row and column in a database table
![Page 6: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/6.jpg)
Types of AttributesKey (identifier in data modeling): Attribute, or combination of
attributes, that determines the values of other attributes in each row
Composite Key: Multiple-attribute keys; may be further subdivided, e.g., phone may be area code and number - can be a primary key
Candidate Key (CK): Attribute (or a minimum combination of attributes) that uniquely identifies each row in a given table - there can be more than one CK (employee entity type: SSN; assigned ID#)
Primary Key (PK) ( a unique identifier in data modeling): A CK selected to uniquely identify all other attributes in a given row; cannot be Null
Foreign Key (FK): ( a relationship in data modeling): Attribute (combination of attributes) whose value(s) must match the Primary Key in another table in the same database, or whose value(s) must be Null
Non-key Attribute: Attribute that is not part of a key
![Page 7: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/7.jpg)
Attributes With A Null Value • Null Value: An unknown attribute value (e.g.,
salesperson not yet allocated to a customer) - it is not a zero. It is an optional attribute.
• Inclusion of nulls in a table is important - they provide a consistent way to distinguish between valid data such as a 0 and missing data, e.g., an account payable with 0 is good to see; one with an unknown balance can indicate a significant problem
• In most cases, nulls appear as blanks on a query’s result table on a screen
![Page 8: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/8.jpg)
Relationships
• Data modeling term that indicates an association between tables: How the things of significance are related (A FK must match to an existing PK, or else be NULL)
• This controlled redundancy allows linking of tables (hence “relational”)
• Entity-Relationship Diagram (ERD): A data model (at the conceptual level) that shows the relationships enforcing business rules between entities (tables) in a database environment (Fig. 5.4)
![Page 9: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/9.jpg)
Business Rules
• Narrative descriptions of policies, procedures, or principles in an organization
• Examples: – A pilot cannot be on duty for more than 10 hours
in a 24-hour period– A professor must teach at least three classes in
a semester– A class may not have fewer than 10 enrollments
![Page 10: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/10.jpg)
Concept to Definition
FileConcept System Modeling RDBMS ExampleCollection of Objects File Entity-Type Table CustomersObject record entity row (tuple) John Doe, a particualr customerAspect field attribute column of a
data typeHair Color
Uniqueness index? identifier primary key customer #Relationship programmed relationship
with cardinalityand optionality
primary key toforeign key matching sometimes has orders
Value value realization cell Blonde
![Page 11: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/11.jpg)
Example from Ch. 3 (P&S)
• Partial MSC:– Sale to Customer– Ship to Customer
• Multi-product merchandiser
• Salesperson, Shipping Clerk
![Page 12: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/12.jpg)
Figure 3.25 Entity-relationship diagram.
Customer Invoiceis sent an1 M
Invoice Invoice LinecontainsM1
draws uponM M
InventoryInvoice
![Page 13: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/13.jpg)
Figure 3.26 Revised entity-relationship diagram.
Customer Invoiceis sent an1 M
Invoice Invoice LinecontainsM1
InvoiceInvenM M
InventoryInvoice1 1
![Page 14: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/14.jpg)
Figure 3.1 Sales transactions stored in a database accounting system.
![Page 15: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/15.jpg)
Figure 3.7 The Customer relation, tblCustomer.
![Page 16: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/16.jpg)
Figure 3.8 Primary key and foreign key relationship.
foreign key
primary key
![Page 17: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/17.jpg)
Figure 3.9 Schemas of tables in the invoicing system.
tblCountryName (CountryID, CountryName, ExportCoffeeBags, ExportTeaPounds)
tblCustomer (CustomerID, CompanyName, Contact, Address, City, State,ZipCode, PhoneNumber, FaxNumber, CreditLimit)
tblEmployee (EmployeeID, EmployeeFirstName, EmployeeLastName,EmployeeWorkPhone, EmployeeTitleID, EmployeeCommRate,EmployeeHireDate, EmployeeDOB, EmployeeGender,EmployeeNotes)
tblEmployeeTitle (TitleID, Title)
tblInventory (InventoryID, ItemID, Caffeinated, Price, OnHand)
tblInventoryDescription (ItemID, Name, BeverageType, Flavored, CountryID, Comments)
tblInvoice (InvoiceID, InvoiceDate, OrderDate, CustomerID, EmployeeID,CustomerPO)
tblInvoiceLine (InvoiceID, InventoryID, Quantity, UnitPrice, Discount)
tblSalesTaxRate (StateAbbreviation, StateName, TaxRate, Population, LandArea)
![Page 18: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/18.jpg)
Figure 3.10 Example rows in the Invoice table, tblInvoice.
primary keyforeign key
500 records in this table
![Page 19: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/19.jpg)
Figure 3.11 Example rows in the Invoice Line table, tblInvoiceLine.
primary keyforeign key
![Page 20: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/20.jpg)
Figure 3.12 Example rows in the primary Inventory table, tblInventory.
primary keyforeign key
![Page 21: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/21.jpg)
Figure 3.13 Example rows in the secondary Inventory table, tblInventoryDescription.
primary keyforeign key
![Page 22: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/22.jpg)
Normalization• Process of taking a “raw” database and breaking it
into logical units called tables, by following theoretical rules called normal forms
• The intent is to create a degree of controlled redundancy that allows two or more tables to be joined, by matching a FK in one table to a PK in another table
• Referential integrity (constraint created upon table creation) is enforced when every non-null FK value must match an existing PK value (if there is a FK, there has to be a PK for that FK in another table)
• Normalization has six nested normal forms• Generally a well-formed business database will be
normalized through 3rd normal form (3NF)
![Page 23: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/23.jpg)
Benefits of Normalization • Greater overall database organization• Minimize data redundancies• Data consistency within the database• A more flexible database design• Data can be used more productively• A better handle on database security
Disadvantage of Normalization• Reduced database performance because database must locate requested tables and join data - requires additional processing logic
![Page 24: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/24.jpg)
Normal Forms
—Normalization through a series of stages called NORMAL FORMS
–Each NF depends on normalization steps taken in the previous NF
»First Normal Form - 1NF»Second Normal Form - 2NF»Third Normal Form - 3NF
![Page 25: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/25.jpg)
1NFFirst normal form rules:
•All key attributes must be defined
•There must be no repeating groups (values), i.e., each row/column intersection can have only one value
•All attributes must be functionally dependent on the PK, or part of the PK - e.g., SSN determines DOB, but DOB cannot determine SSN
Hint: Put all attributes in a two-dimensional flat table, with no repeating values
![Page 26: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/26.jpg)
General Journal Entry:Traditional View - Unnormalized
Table 1
Traditional General Journal Entries
Tran_# Date Title Acct_# Debit Credit Explain
1 1/3/96 Cash 11001 100.00
Receivable 11003 200.00
Sales 41001 300.00
credit sale with down payment
2 1/3/96 COGS 51001 150.00
Inventory 11004 150.00
sale of inventory
Assume that the transaction # will reset to 1 at the beginning of the next fiscal year
![Page 27: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/27.jpg)
GJ: First Normal Form
Table 2
General Journal Entries: 1NF
Tran_# Date Title Acct_# Debit Credit Explain
1 1/3/96 Cash 11001 100.00 0.00 credit sale
1 1/3/96 Receivable 11003 200.00 0.00 credit sale
1 1/3/96 Sales 41001 0.00 300.00 credit sale
2 1/3/96 COGS 51001 150.00 0.00 sale ofinventory
2 1/3/96 Inventory 11004 0.00 150.00 sale ofinventory
![Page 28: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/28.jpg)
2NF–Second Normal Form Rules:
»Table is in 1NF; and»Table includes no partial dependencies;
that is, no attribute is dependent on only portion of the primary key – must be dependent on entire PK
Hint: Examine non-key attributes to determine whether any are dependent on only portion of a composite PK - this would violate 2NF
If a table only has one attribute as a PK, then it is in 2NF.
![Page 29: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/29.jpg)
Chart of Accounts Table
Table C
General Journal Entries: 2NF, 3NF Acct_#
Title
11001
Cash
11003
Receivable
41001
Sales
51001
COGS
11004
Inventory
![Page 30: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/30.jpg)
Transaction Listing Table
Table A
General Journal Entries: 2NF, 3NF
Tran_#
Date
Explain
1
1/3/96
credit sale with down payment
2
1/3/96
sale of inventory
![Page 31: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/31.jpg)
Transaction Detail Table(Base Table)
Table B
General Journal Entries: 2NF
Tran_# Date Acct_# Debit Credit
1 1/3/96 11001 100.00 0.00
1 1/3/96 11003 200.00 0.00
1 1/3/96 41001 0.00 300.00
2 1/3/96 51001 150.00 0.00
2 1/3/96 11004 0.00 150.00
![Page 32: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/32.jpg)
3NF–Third Normal Form Rules:
»Table is in 2NF and
»There are no transitive dependencies
Hint: You will violate 3NF if you can deduce the value of a non-key attribute by knowing the value of another non-key attribute
![Page 33: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/33.jpg)
NormalizedTransaction Detail (Base) Table
Table D
General Journal Entries: 3NF
Tran_#
Date
Acct_#
Amount
1
1/3/96
11001
$100.00
1
1/3/96
11003
$200.00
1
1/3/96
41001
($300.00)
2
1/3/96
51001
$150.00
2
1/3/96
11004
($150.00)
![Page 34: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/34.jpg)
Example from Ch. 3 (P&S)Continued
![Page 35: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/35.jpg)
Figure 3.14 Example table containing repeating groups.
repeating group
repeating group
repeating group
repeating group
![Page 36: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/36.jpg)
Figure 3.15 Example rows of the Customer table in first normal form (1NF).
![Page 37: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/37.jpg)
Figure 3.16 Functional dependencies in the Customer table.
CustomerID CompanyName PhoneNumber Contact InvoiceID Total
![Page 38: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/38.jpg)
Figure 3.17 Invoice table in second normal form (2NF).
![Page 39: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/39.jpg)
Figure 3.18 Transitive dependencies in the Invoice table shown in Figure 3.17.
InvoiceID InvoiceDate OrderDate CustomerID EmployeeID Contact
![Page 40: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/40.jpg)
Operations
• Restrict aka Select• Project• Join• SQL the standard language
– DDL: data definition language– DML: data manipulation language
• Destructive: CUD• Non-Destructive: R• CRUD again
![Page 41: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/41.jpg)
Figure 3.19 Select operation.
Employee table:
ID Name Comm HireDate BirthDate Gender1301 Stonesifer 5% 07/06/96 03/10/66 F1364 Pruski 4% 12/01/00 01/26/79 M1528 Pacioli 6% 08/26/95 05/06/50 M1695 Nagasaki 4% 01/28/00 04/10/77 M2240 Stonely 15% 11/05/88 05/03/61 F2318 Hunter 8% 11/16/93 01/26/54 F2754 Kahn 5% 05/14/97 05/29/61 M3370 Kole 9% 02/08/92 03/23/63 M3432 English 8% 10/01/93 02/14/56 F3436 Gates 6% 04/11/95 03/09/54 M3458 Morrison 15% 12/13/89 07/04/56 F3609 Chang 5% 09/16/97 03/30/77 F
… … … … … …4112 Goldman 11% 12/24/90 03/05/62 M
Result of selection operation: HireDate > 1/1/97
ID Name Comm HireDate BirthDate Gender1364 Pruski 4% 12/01/00 01/26/79 M1695 Nagasaki 4% 01/28/00 04/10/77 M2754 Kahn 5% 05/14/97 05/29/61 M3609 Chang 5% 09/16/97 03/30/77 F
![Page 42: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/42.jpg)
Figure 3.20 Project operation.
Employee table:
ID Name Comm HireDate BirthDate Gender Name Gender1301 Stonesifer 5% 07/06/96 03/10/66 F Stonesifer F1364 Pruski 4% 12/01/00 01/26/79 M Pruski M1528 Pacioli 6% 08/26/95 05/06/50 M Pacioli M
… … … … … … … …4057 Bateman 9% 02/16/92 05/01/58 M Bateman M4058 Halstead 5% 06/16/96 12/22/73 F Halstead F4082 Flintsteel 11% 03/21/90 08/22/58 F Flintsteel F4112 Goldman 11% 12/24/90 03/05/62 M Goldman M
Projection:
![Page 43: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/43.jpg)
Figure 3.21 Join operation.
tblEmployee tblEmployeeTitle
ID Name TitleID HireDate Gender TitleID Title1301 Stonesifer 2 07/06/96 F 1 Sales Trainee1364 Pruski 1 12/01/00 M 2 Sales Associate1528 Pacioli 2 08/26/95 M 3 Senior Sales Associate1695 Nagasaki 1 01/28/00 M 4 Sales Manager2240 Stonely 3 11/05/88 F 5 Senior Sales Manager2318 Hunter 2 11/16/93 F 6 Division Sales Manager2754 Kahn 2 05/14/97 M 7 Regional Manager3370 Kole 2 02/08/92 M 8 Division Manager3432 English 2 10/01/93 F 9 National Sales Manager3436 Gates 2 04/11/95 M
… … … … …4082 Flintsteel 3 03/21/90 F4112 Goldman 3 12/24/90 M
Result of join operation:ID Name TitleID HireDate Gender Title1301 Stonesifer 2 07/06/96 F Sales Associate1364 Pruski 1 12/01/00 M Sales Trainee1528 Pacioli 2 08/26/95 M Sales Associate1695 Nagasaki 1 01/28/00 M Sales Trainee2240 Stonely 3 11/05/88 F Senior Sales Associate2318 Hunter 2 11/16/93 F Sales Associate2754 Kahn 2 05/14/97 M Sales Associate3370 Kole 2 02/08/92 M Sales Associate3432 English 2 10/01/93 F Sales Associate3436 Gates 2 04/11/95 M Sales Associate
… … … … … …4082 Flintsteel 3 03/21/90 F Senior Sales Associate4112 Goldman 3 12/24/90 M Senior Sales Associate
![Page 44: Introduction to FIS 318/618, Financial Systems & Databases: The Relational Database Model Oakland University School of Business Administration Accounting](https://reader035.vdocuments.net/reader035/viewer/2022081506/56649d3f5503460f94a18f5b/html5/thumbnails/44.jpg)
Figure 3.22 Joining tables with primary key/foreign key relationships.
tblCustomer CustomerID CompanyName Contact Address PhoneNumber FaxNumber CreditLimit
(city, state,zip)
tblInvoice InvoiceID InvoiceDate OrderDate CustomerID EmployeeID CustomerPO
tblInvoiceLine InvoiceID InventoryID Quantity UnitPrice Discount
tblInventory InventoryID ItemID Caffeinated Price OnHand
tblInventoryDescription ItemID Name BeverageType Flavored CountryID Comments