INFM 603: Session 5 Introduction to Databases and Database Design Paul Jacobs The iSchool University of Maryland Thursday, Sept. 29, 2016 This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States See http://creativecommons.org/licenses/by-nc-sa/3.0/us/ for details

Today’s Topics Fundamentals of Databases Relational Databases and Database Design Object-Oriented Databases

Database Fundamentals - Overview What is a database? Purpose Role in application development Relationship to architecture/OO design Some major concepts of database design The database schema Normalization Entity – relationship diagrams Database Fundamentals Database Design Object-Oriented Databases

What is a Database? A database is a mechanism (or system) for organizing and storing information. Within applications, databases are modules (also known as a “tier”) that provide storage and access to widely-used objects Within implementations, databases represent a layer that takes care of, and hides, many aspects of dealing with large quantities of information Database Fundamentals Database Design Object-Oriented Databases

Why do Applications Need Databases? Persistence - In your code, data exists only when the program is running Sharing – Information in a database can be used by different programs, applications Many other features that go along with all that – Access control and security, concurrency control, data backup, etc. Database Fundamentals Database Design Object-Oriented Databases

Database Examples Personal databases (e.g., address book) Human resources (employee and payroll information) Inventory and order processing Library catalogs Company financial data Database Fundamentals Database Design Object-Oriented Databases

Why We Need Databases They encapsulate and hide a wide range of data functionality, such as: Constraints and integrity – e.g., making sure data are correct and not corrupted Data and file storage – e.g., details of where and how to keep data, redundancy, etc. Security Synchronization and concurrency control – e.g. keeping data current, avoiding mess-ups when data changes Details of efficient access Database Fundamentals Database Design Object-Oriented Databases

Static vs. Dynamic Data On-line transaction processing (OLTP) – most online systems On-line analytical processing (OLAP) – data warehouses, business intelligence, data mining Database Fundamentals Database Design Object-Oriented Databases

Types of Database Systems Flat file Hierarchical Network Relational Object-oriented Object-relational Database Fundamentals Database Design Object-Oriented Databases

Relational Databases Databases in which the primary means of organizing information is a table … Which also support crucial elements of database functionality: Structured query (via SQL, the structured query language) Keys, constraints and integrity Views Reporting Database Fundamentals Database Design Object-Oriented Databases

Why Relational Databases? Neat separation of organization from implementation Societal factors Widespread and entrenched availability Trained users and implementors Standardization of SQL and ODBC Database Fundamentals Database Design Object-Oriented Databases

Database Functions Query (retrieve information) “What’s the lowest fare from Baltimore to LA on Friday?” Update “My mobile phone # is 703-307-0467” Report “Show total orders by month for 2015” Analyze (“mine”) “What types of charges are most likely to be unauthorized (i.e., credit card fraud)?” What else? Database Fundamentals Database Design Object-Oriented Databases

Database Design

Relational Database Concepts to Know Schema – the overall design, organization and relationships in a database Tables – the names of data entries and their relationships Fields and columns – the types of entries themselves Records and rows – the individual entries (instances) Keys – fields that uniquely identify a record Relationships – structures or groupings between fields Data types – constraints on fields, such as strings, numbers, dates, etc. Database Fundamentals Database Design Object-Oriented Databases

The Database Schema A group of related objects in the database A data model (especially the organization that makes the data useful and the procedures for using the data) For us, mainly the design of the tables (e.g., what goes in which tables, columns, and fields) “A contact entry has a name, address, and phone number” Database Fundamentals Database Design Object-Oriented Databases

Database Schema Example Database Fundamentals Database Design Object-Oriented Databases

More on Database Schemas Tables Indexes Procedures Views Constraints Schema Owner Database Fundamentals Database Design Object-Oriented Databases schema objects 1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN. (with slight changes by V.G.D.)

Simple Table Example Name Company Phone Number E-mail Paul Jacobs JakeTech 703-307-0467 psjacobs@umd.edu Bugs Bunny ACME, Inc. 650-555-1234 bugs@acme.com Will E. Coyote wille@acme.com Database Fundamentals Database Design Object-Oriented Databases

Database with Multiple Tables Publishers Books Customers Authors Inventory Orders Database Fundamentals Database Design Object-Oriented Databases 1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN. (with slight changes by V.G.D.)

Table Example Customers Name Company Phone Number E-mail Paul Jacobs JakeTech 703-307-0467 psjacobs@ umd.edu Bugs Bunny ACME, Inc. 650-555-1234 bugs@acme.com Will E. Coyote wille@acme.com Database Fundamentals Database Design Object-Oriented Databases

Table Example – Fields (Columns) a field Customers Name Company Phone Number E-mail Paul Jacobs JakeTech 703-307-0467 psjacobs@ umd.edu Bugs Bunny ACME, Inc. 650-555-1234 bugs@acme.com Will E. Coyote wille@acme.com Database Fundamentals Database Design Object-Oriented Databases

Table Example – Records (Rows) Customers Name Company Phone Number E-mail Paul Jacobs JakeTech 703-307-0467 psjacobs@ umd.edu Bugs Bunny ACME, Inc. 650-555-1234 bugs@acme.com Will E. Coyote wille@acme.com Database Fundamentals Database Design Object-Oriented Databases a record

Table Example – Primary Key Customers User ID Name Company Phone Number E-mail address 9475 Paul Jacobs JakeTech 703-307-0467 psjacobs@ umd.edu 4343 Bugs Bunny ACME, Inc. 650-555-1234 bugs@acme.com 5789 Will E. Coyote wille@acme.com Database Fundamentals Database Design Object-Oriented Databases

Primary Keys Unique identifiers that select rows May be created manually or automatically (e.g. Sequence ID # vs. ISBN) Database Fundamentals Database Design Object-Oriented Databases

Compound Primary Key Example MovieRoles Database Fundamentals Database Design Object-Oriented Databases primary key fields

Table Example – Foreign Keys primary key field parent table Directors relationship child table Movies Database Fundamentals Database Design Object-Oriented Databases foreign key field

Why “Foreign Keys” are Important You can’t put everything in one table! It would be terribly cumbersome and inefficient It would make it harder to find some data (say, personal details about directors) It could be inconsistent and needlessly duplicative (e.g., people have names, birthdates, contact info, etc., regardless of whether they are movie directors or students) But often you need to combine information from multiple tables – this is called a “join” Some of the most complex of database queries Often hidden in software that accesses databases (why?) Good to know about (for correct design, avoiding inefficiencies and delays) Database Fundamentals Database Design Object-Oriented Databases

Data Types in Databases Very similar to data types in programming Alphanumeric (Text, Memo) Numeric (Number, Currency, etc.) Date/Time Boolean (Yes/No) However, databases are a higher level and types can be more powerful and more abstract, e.g. Checking to make sure data is valid – is this a valid date? Converting and reformatting – easily show the same date in multiple formats Computation and comparison – sort by date Database Fundamentals Database Design Object-Oriented Databases

Tables and Records - Terminology A table (entity, object class) describes a type of object and its associations or relationships A record (row, instance, object) describes an individual – e.g., in the table of customers, John’s customer entry is a record A field (column, attribute, property) is a part of a table An association or relationship relates multiple tables, entities or classes Database Fundamentals Database Design Object-Oriented Databases

Relating Different Terms Class  Object  Attribute  Association  … Database Fundamentals Database Design Object-Oriented Databases

Relating Different Terms Class  Table (Entity) Object  Record (Row) Attribute  Column (Field, Attribute) Association  Relationship … Database Fundamentals Database Design Object-Oriented Databases

Database Normalization

What is Normalization? A method for organizing data elements into tables. Done in order to avoid Duplication of data Insert anomaly Delete anomaly Update anomaly Database designs can be in first normal form (1NF), second normal form (2NF), and third normal form (3NF) – ideal is 3NF Database Fundamentals Database Design Object-Oriented Databases

Example (Unnormalized) Table: SalesOrders (Un-normalized) SalesOrderNo Date CustomerName CustomerAddress ClerkName Item1Description Item1Quantity Item1UnitPrice Item2Description Item2Quantity Item2UnitPrice Item3Description Item3Quantity Item3UnitPrice Total Database Fundamentals Database Design Object-Oriented Databases

Normalizing into 1NF Separate repeating groups into new tables. Start a new table for the repeating data. The primary key for the repeating group is usually a composite key. Database Fundamentals Database Design Object-Oriented Databases

Example (1NF) Table: SalesOrders Table: OrderItems SalesOrderNo Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo ItemNo ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases

Dependencies Functional dependency: The value of one attribute depends entirely on the value of another. Partial dependency: An attribute depends on only part of the primary key. (The primary key must be a composite key.) Transitive dependency: An attribute depends on an attribute other than the primary key. Database Fundamentals Database Design Object-Oriented Databases

Normalizing into 2NF Remove partial dependencies. Start a new table for the partially dependent data and the part of the key it depends on. Tables started at this step usually contain descriptions of resources. Database Fundamentals Database Design Object-Oriented Databases

Example (2NF) Table: OrderItems Table: InventoryItems SalesOrderNo ItemNo ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo ItemDescription Database Fundamentals Database Design Object-Oriented Databases

What if we hadn’t done 2NF? Duplication of data: ItemDescription would appear for every order. Insert anomaly: To insert an inventory item, you must insert a sales order. Delete anomaly: Information about the items stay with sales order records. Delete a sales order record, delete the item description. Update anomaly: To change an item description, you must change all the sales order records that have the item. Database Fundamentals Database Design Object-Oriented Databases

Normalizing into 3NF Remove transitive dependencies. Start a new table for the transitively dependent attribute and the attribute it depends on. Keep a copy of the key attribute in the original table. Database Fundamentals Database Design Object-Oriented Databases

Example (3NF) Table: SalesOrders Table: Customers Table: Clerks SalesOrderNo Date CustomerNo ClerkNo Total Table: Customers CustomerNo CustomerName CustomerAddress Table: Clerks ClerkNo ClerkName Database Fundamentals Database Design Object-Oriented Databases

What if we hadn’t done 3NF? Duplication of data: Customer and Clerk details would appear for every order. Insert anomaly: To insert a customer or clerk, you must insert a sales order. Delete anomaly: Information about the customers and clerks stay with sales order records. Delete a sales order record, delete the customer or clerk. Update anomaly: To change the details of a customer or clerk, you must change all the sales order records that involve that customer or clerk. Database Fundamentals Database Design Object-Oriented Databases

Example (Final Tables) Table: SalesOrders SalesOrderNo Date CustomerNo ClerkNo Total Table: OrderItems ItemNo ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo ItemDescription Table: Customers CustomerNo CustomerName CustomerAddress Table: Clerks ClerkNo ClerkName Database Fundamentals Database Design Object-Oriented Databases

Table: SalesOrders (Un-normalized) SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Item1Description Item1Quantity Item1UnitPrice Item2Description Item2Quantity Item2UnitPrice Item3Description Item3Quantity Item3UnitPrice Total Database Fundamentals Database Design Object-Oriented Databases

Table: SalesOrders (Un-normalized) SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Item1Description Item1Quantity Item1UnitPrice Item2Description Item2Quantity Item2UnitPrice Item3Description Item3Quantity Item3UnitPrice Total For 1NF Separate repeating fields Database Fundamentals Database Design Object-Oriented Databases

Table: SalesOrders Table: OrderItems SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases Needs PK and relationship with the “origin” table (SalesOrders).

Table: SalesOrders Table: OrderItems SalesOrderNo (PK) Date ItemNo CustomerName CustomerAddress ClerkName Total Table: OrderItems ItemNo ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases Generate new ID field for order items.

Table: SalesOrders Table: OrderItems SalesOrderNo SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo ItemNo ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases Insert the PK of the “origin” table (SalesOrders).

Table: SalesOrders Table: OrderItems SalesOrderNo (CPK) 1NF Table: SalesOrders SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases These two together make up the CPK of the new table.

Table: SalesOrders Table: OrderItems SalesOrderNo (CPK) SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemDescription ItemQuantity ItemUnitPrice Not 2NF business. Database Fundamentals Database Design Object-Oriented Databases For 2NF do not touch the table(s) with single-field primary keys.

Table: SalesOrders Table: OrderItems SalesOrderNo (CPK) SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemDescription ItemQuantity ItemUnitPrice Database Fundamentals Database Design Object-Oriented Databases For 2NF remove fields that do not depend on all parts of multi-field primary keys.

Table: InventoryItems 2NF Table: SalesOrders SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo (PK) ItemDescription These depend on both SalesOrderNo and ItemNo. Database Fundamentals Database Design Object-Oriented Databases The field generated in 1NF goes into the new table as PK. This depends only on ItemNo.

Table: InventoryItems Table: SalesOrders SalesOrderNo (PK) Date CustomerName CustomerAddress ClerkName Total Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo (PK) ItemDescription Database Fundamentals Database Design Object-Oriented Databases For 3NF separate transitively dependent fields; i.e., fields that conceptually constitute separate entities.

Table: InventoryItems Table: SalesOrders SalesOrderNo (PK) Date Total Table: Customers CustomerNo (PK) CustomerName CustomerAddress Table: Clerks ClerkNo (PK) ClerkName Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo (PK) ItemDescription Database Fundamentals Database Design Object-Oriented Databases Generate new PK fields for the new tables…

Table: InventoryItems 3NF Table: SalesOrders SalesOrderNo (PK) Date CustomerNo (FK) ClerkNo (FK) Total Table: Customers CustomerNo (PK) CustomerName CustomerAddress Table: Clerks ClerkNo (PK) ClerkName Table: OrderItems SalesOrderNo (CPK) ItemNo (CPK) ItemQuantity ItemUnitPrice Table: InventoryItems ItemNo (PK) ItemDescription Database Fundamentals Database Design Object-Oriented Databases … and add those new fields as FKs to the “origin” table(s).

Database Documentation Entity-Relationship Diagrams Example

Entity – Relationship Diagrams Entities (example) SALES ORDERS INV. ITEMS ORDER ITEMS CLERKS CUSTOMERS Database Fundamentals Database Design Object-Oriented Databases

Entity – Relationship Diagrams (Relationships) Many-to-Many Relationships One-to-Many Relationships One-to-One Relationships Mandatory Relationships Optional Relationships Database Fundamentals Database Design Object-Oriented Databases

Entity – Relationship Diagrams Entities with Relationships (example) SALES ORDERS INV. ITEMS ORDER ITEMS CLERKS CUSTOMERS Database Fundamentals Database Design Object-Oriented Databases

Why Might We Do E-R Diagrams? Document the Database Schema Hide Implementation Details However, Many Databases are Documented by Tables (as with Earlier Examples) Database Fundamentals Database Design Object-Oriented Databases

What About Object-Oriented Principles? Object-Oriented Design (Re-Use, Encapsulation, Inheritance, Abstraction, Etc.) Can be carried out with relational, object-oriented, or object-relational DBs In many ways is supported by the relational model Object-Oriented Implementation (Object classes, Instances, Methods, Constructors, etc.) Can get complicated, hard in perfecting DB interaction Alternatives exist – persistent object store, object mapping, many tools to manipulate objects in programs and store them in relational/object-relational DBs Database Fundamentals Database Design Object-Oriented Databases

Recap Covered database fundamentals Persistent storage of shared information Organization into relations (table structures, like objects) Gave a snapshot of designing a good (relational) database Examples of relations Use of primary, compound, foreign keys Recognition of dependencies and issues Carrying out normalization Hinted at what’s to come next (implementation, interaction between programs and databases) Database Fundamentals Database Design Object-Oriented Databases