SQL Workshop. Database Design. Doug Shook

Transcription

1 SQL Workshop Database Design Doug Shook

2 Data Structure Design Real-world system Database system People Tables Documents Facilities Columns Other systems Rows 2

3 Data Structure Design Relational database systems should model real world elements The entity represents an object The columns represent attributes Each row represents an instance The technique used to create a design is called entity relationship (ER) modeling 3

4 Data Structure Design Six step process Identify data elements Subdivide each element into its smallest useful components Identify the tables and assign columns Identify the primary and foreign keys Review whether the data structure is normalized Identify the indexes 4

5 Identifying data elements Where can we find data elements? Data elements are not always equal to entities Typically an entity will consist of many elements 5

6 Identifying data elements Acme Fabrication, Inc. Custom Contraptions, Contrivances and Confabulations 1234 West Industrial Way East Los Angeles California fax Invoice Number: Invoice Date: Terms: I /05/12 Net 30 Part No. Qty. Description Unit Price Extension CUST Design service, hr Baling wire, 25x3ft roll Duct tape, black, yd Rubber tubing, 100ft roll CUST281 7 Assembly, hr CUST917 2 Testing, hr Sales Tax Your salesperson : Ruben Goldberg, ext 4512 Accounts receivable: Inigo Jones, ext 4901 $7, PLEASE PAY THIS AMOUNT Thanks for your business! 6

7 Identifying data elements The data elements on the invoice document Vendor name Vendor address Vendor phone number Vendor fax number Vendor web address Invoice number Invoice date Invoice terms Item part number Item quantity Item description Item unit price Item extension Vendor sales contact name Vendor sales contact extension Vendor AR contact name Vendor AR contact extension Invoice total 7

8 Subdividing Data Elements Finding the smallest useful element can be tricky What happens if we do this incorrectly? When in doubt, use smaller elements 8

9 Subdividing Data Elements Vendor sales contact name Ruben Goldberg Vendor sales contact first name Ruben Vendor sales contact last name Goldberg Vendor address 1234 West Industrial Way, East Los Angeles, California Street and number City State Zip 1234 West Industrial Way East Los Angeles California

10 Identifying Tables and Columns Begin by grouping data elements into entities Some might belong to multiple entities Some might not be needed The entities will eventually become tables The data elements will become columns Let s try this with the data elements on slide 7 Can you think of any additional elements that would be nice to include but weren t on the invoice? 10

11 Identifying Tables and Columns Possible tables and columns for an A/P system Vendors Vendor name Vendor address Vendor city Vendor state Vendor zip code Vendor phone number Vendor fax number Vendor web address Vendor contact first name Vendor contact last name Vendor contact phone Vendor AR first name Invoices Invoice number* Invoice date Terms* Invoice total Payment date Payment total Invoice due date Credit total Account number* 11

12 Identifying Tables and Columns Possible tables and columns for an A/P system (continued) Vendors Vendor AR last name Vendor AR phone Terms* Account number* Invoice line items Invoice number* Item part number Item quantity Item description Item unit price Item extension Account number* Sequence number 12

13 Identifying Primary and Foreign Keys Primary keys must uniquely identify each record Use an existing column, if possible Primary keys should almost never change Use an identity column, if necessary Relationships play a role in choosing keys One-to-many relationships should have a foreign key on the many side Many-to-many relationships should use a linking table One-to-one relationships should share primary keys 13

14 Identifying Primary and Foreign Keys Vendors Invoices InvoiceLineItems VendorID VendorName VendorAddress VendorCity VendorState VendorZipCode VendorPhone VendorContactFName VendorContactLName Terms AccountNo InvoiceID VendorID InvoiceNumber InvoiceDate InvoiceTotal PaymentTotal CreditTotal Terms InvoiceDueDate PaymentDate AccountNo InvoiceID InvoiceSequence AccountNo InvoiceLineItemDescription ItemQuantity ItemUnitPrice InvoiceLineItemAmount 14

15 Identifying Primary and Foreign Keys Employees EmployeeID FirstName LastName Memberships EmployeeID CommitteeID Linking table Committees CommitteeID CommitteeName Employees EmployeeID FirstName LastName EmployeePhotos EmployeeID EmployeePhoto 15

16 Enforcing Relationships Maintaining the relationships between tables is extremely important Referential integrity Two ways to enforce referential integrity Foreign key constraints Delete related rows or throw an error Triggers Executed upon insert, update, or delete 16

17 Enforcing Relationships Operations that can violate referential integrity Deleting a row from the primary key table If the foreign key table contains one or more rows related to the deleted row Inserting a row in the foreign key table If the foreign key value doesn t have a matching primary key value in the related table Updating the value of a foreign key If the new foreign key value doesn t have a matching primary key value in the related table Updating the value of a primary key If the foreign key table contains one or more rows related to the row that s changed 17

18 Normalization The goal of normalization is to reduce data redundancy Ideally, each table contains information about a single entity, and each piece of data is stored in only one place Normalization is accomplished by applying forms Seven forms total Three is typically considered to be sufficient 18

19 Normalization Benefits More tables -> more indexes More efficient Simplifies maintenance Reduces storage More efficient insert, update, and delete 19

20 Normalization First normal form The value stored at the intersection of each row and column must be scalar A table must not contain any repeating column Will still likely have repeating values in rows 20

21 Normalization Unnormalized invoice data The invoice data with a column that contains repeating values The invoice data with repeating columns 21

22 Normalization The invoice data in first normal form 22

23 Normalization Second Normal Form Every non-key column must depend on the entire primary key If the above is false it indicates there are multiple entities within the table Application Move columns that don t depend on the entire key to a different table Establish a relationship between the tables The step removes redundant row data 23

24 Normalization The invoice data in first normal form with keys added 24

25 Normalization The invoice data in second normal form 25

26 Normalization Third Normal Form Each non-key column must depend only on the primary key If a column does not depend only on the primary key Assigned to the wrong table Can be computed from other columns Derived data 26

27 Normalization Invoices InvoiceID VendorName VendorAddress VendorCity VendorState VendorZipCode VendorPhone VendorContactFName VendorContactLName InvoiceNumber InvoiceDate InvoiceTotal PaymentTotal CreditTotal Terms InvoiceDueDate PaymentDate AccountNo InvoiceLineItems InvoiceID InvoiceSequence AccountNo InvoiceLineItemDescription ItemQuantity ItemUnitPrice InvoiceLineItemAmount 27

28 Normalization Does the vendor information depend only on the InvoiceID column? Does the Terms column depend only on the InvoiceID column? Does the AccountNo column depend only on the InvoiceID column? Can the InvoiceDueDate and InvoiceLineItemAmount columns be derived from other data? 28

29 Normalization Vendors VendorID VendorName VendorAddress VendorCity VendorState VendorZipCode VendorPhone VendorContactFName VendorContactLName DefaultTermsID DefaultAccountNo Invoices InvoiceID VendorID InvoiceNumber InvoiceDate InvoiceTotal PaymentTotal CreditTotal TermsID InvoiceDueDate PaymentDate Terms TermsID TermsDescription TermsDueDays InvoiceLineItems InvoiceID InvoiceSequence AccountNo InvoiceLineItemAmount InvoiceLineItemDescription GLAccounts AccountNo AccountDescription 29

30 Denormalization When is denormalization appropriate? 30

31 Denormalization When is denormalization appropriate? When a joined column is used repeatedly, consider moving that column to the primary key table If a table is updated infrequently, denormalization can increase efficiency Include derived columns if they are used frequently in search conditions Bottom line: if it increases performance, then try it 31

32 Denormalization Vendors VendorID VendorName VendorAddress VendorZipCode VendorAreaCodeID VendorPhone VendorContactFName VendorContactLName DefaultTermsID DefaultAccountNo ZipCodes ZipCode City State AreaCodes AreaCodeID AreaCode Invoices InvoiceID VendorID InvoiceNumber InvoiceDate InvoiceTotal PaymentTotal CreditTotal TermsID InvoiceDueDate PaymentDate Terms TermsID TermsDescription TermsDueDays InvoiceLineItems InvoiceID InvoiceSequence AccountNo InvoiceLineItemQty InvoiceLineItemUnitPrice LineItemDescriptionID LineItemDescriptions LineItemDescriptionID InvoiceLineItemDescription GLAccounts AccountNo AccountDescription 32

33 Identifying Indexes Indexes are used to locate information more quickly Two types Clustered Defines the sequence in which rows are stored Only one per table Created for primary key by default Nonclustered Up to 249 for one table But don t use too many... 33

34 Identifying Indexes When to create an index When the column is a foreign key When the column is used frequently in searches or joins When the column contains a large number of distinct values When the column is updated infrequently 34

35 35 Exercises Design a database diagram for a product orders database with the following tables. Identify what columns might be included in each table, the primary keys for each table, and foreign keys for each table. Customers Orders OrderLineItems Products

36 36 Exercises Add two tables into the database from the previous problem: Shippers Employees Explain how these tables fit into your design. Identify which columns in this database should be indexed, and why.

37 37 Exercises Design a database diagram that allows individuals to be assigned membership in one or more groups. Each group can have any number of individuals and each individual can belong to any number of groups. Create additional tables and columns if necessary. Explain your design decisions.

38 38 Exercises Modify your design from the previous exercise to keep track of the role served by each individual in the group. Each individual can only serve one role in each group. Each group has a unique set of roles that members can fulfill. Create additional tables and columns as necessary. Explain your design decisions.