Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction...

77
Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1

Transcript of Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction...

Page 1: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

1

Instructor: Craig Duckett

Lecture 01: Tuesday, April 7, 2015Orientation and Database Introduction

Page 2: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

2

INTRODUCTION

Welcome to the BIT275 Database Design class!

This is a fast-paced class that will cover a lot of ground. Because it consists of 200-level classes, you will be challenged to take more responsibility for your own learning, conducting online research, book reading and video viewing, and study and practice of database design and development including the acquisition of SQL coding syntax and habits.

This is a “student driven” class and a lot will be required of you, but this can make it all the more rewarding! By the end of the quarter you should have a firm handle on the Relational Databases, RDBMS, Tables, and the Structured Query Language (SQL).

Page 3: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

3

Instructor Information

Instructor: Craig DuckettEmail: [email protected]: CC1-203 (in server room alcove just to the right of elevator on this floor)Office Hours: Mondays/Wednesdays 9:30am-11:00am, and by appointment

Course Website

http://faculty.cascadia.edu/cduckett/bit275

StudentTracker

Page 4: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

4

Textbooks (Required)The Second Edition of Mere Mortals is Also Okay to Use

Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design (3rd Edition) Author: Michael J. HernandexCopyright: 2013ISBN-13: 978-0321884497 Pages: 672

The Language of SQL: How to Access Data in Relational Databases (1 Edition)Author: Larry RockoffCopyright: 2010ISBN-13: 978-1435457515 Pages: 256

InterWebs

Page 5: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

5

Laptops, Notebooks, USB Drives If you have a laptop or notebook you are greatly encouraged to bring this to class, since your personal computers may often prove more reliable than the computers in this lab.

If not, then you will need a USB thumb drive to do your work on and to transfer your files between school and home. Since most database files are quite small, the USB drive doesn't need to be a very big one.

Page 6: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

6

Tools and Resources (see Resources page of website)

• XAMPP (First Part of Quarter)• MySQL Workbench (First Part of Quarter)• Azure (Second Part of Quarter)• Visual Studio Community 2013 (Second Part of Quarter)• SQL (W3Schools)• SQLCourse.com• SQLZoo.net• SQL (TutorialsPoint)• SQL Tutorial• SQL (TutsPlus)• Essential SQL• Learn SQL The Hard Way• Udemy Training (Free): Sachin Quickly Learns SQL• Udemy Training (Free): Database Design • Udemy Training (Free): MySQL Database for Beginners• Udemy Training (Free): SQL Server for Beginners

Page 7: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

7

BIT 275 Assignments, Assessments, Exams

• 3 Individual Assignments• In-Class Exercises (ICEs)• 1 Mid-Term Exam• 1 Final Exam

Assessment Type Points

Assignments 150 Points Each x 3 = 450 Points

In-Class Exercises 25 Points Each x 14 = 350 Points

Mid-Term 100 Points

Final Exam 100 Points

1000 Total Points

Page 8: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

8

Assessment announcements, upcoming due dates, etc, will be posted here on each lecture slide going forward.

• We’ll be starting with BASIC SQL in the next Lecture!• Assignment 1 Due: NEXT Thursday, April 16th, by midnight

(uploaded to StudentTracker)

An overview of upcoming assignments, etc, will be posted here.

Page 9: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

9

Course Website WALK THROUGH http://faculty.cascadia.edu/cduckett/bit275/

Page 10: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

10

Tuesday (LECTURE 1)• Database Design for Mere Mortals: Chapter 1

Thursday (LECTURE 2)• The Language of SQL: Chapters 1, 2

Page 11: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

11

• What is a Database?• Two Types of Databases• Early Database Models• The Toy Collection• The Database Modeling Process• The Relational Database Model 1969• Data Modeling and Set Theory• Subjects and Characteristics• The Relational Database Model Today• Similar Concepts, Different Names• The Relational Database Model Deconstructed

• ICE 01: The “Care About” Exercise (with a Partner)

Page 12: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

12

What is a Database?

What is a database? As you probably know, a database is an organized collection of data used to model some type of organization or organizational process.

It really doesn’t matter whether you’re using paper or an application program to collect and store the data. You have a database as long as you’re collecting and storing data in some organized manner for a specific purpose.

Throughout the remainder of this class, we’ll assume that you’ll be using an application program to collect and maintain your data.

Page 13: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

What is a Database?• A database is a way of organizing data into information to make

decisions about important things we care about• Information is represented by questions and their answers that

help us make good decisions about important things• Subjects are objects or events that are significantly related to

those decisions• Characteristics are the particular, unique attributes of a subject

KEYWORDS

Data and InformationSubject and Characteristics

Page 14: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

14

Two Types of Databases

Page 15: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Two Types of Databases• Operational is used in everyday business, institutions, and organizations. They are primarily

used to store data that is collected, maintained, modified, and updated (dynamic data). The type of data stored is dynamic, meaning that it changes constantly and always reflects up-to-the-minute information. Organizations such as retail stores, manufacturing companies, hospitals and clinics, and publishing houses use operational databases because their data is in a constant state of flux. On-Line Transaction Processing (OLTP)

• Analytical is used to track historical data (static data), including trends, statistical data like weather reports, geological surveys, geographical surveys, sports scores, archived records, etc. The type of data stored is static,meaning that the data is never (or very rarely) modified,although new data might often be added.The information gleaned from an analytical database reflects a point-in-time snapshot of the data and is usually not up to date. Chemical labs,geological companies, and marketing analysis firms are examples of organizations that use analytical databases. On-Line Analytical Processing (OLAP)

See: http://datawarehouse4u.info/OLTP-vs-OLAP.htmlSee: http://www.jkinfoline.com/oltp-vs-olap.html

Page 16: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

16

Early Database Models

Page 17: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Early Database ModelsHierarchical database (parent-child table)

A relationship in a hierarchical database is represented by the term parent/child. In this type of relationship, a parent table can be associated with one or more child tables, but a single child table can be associated with only one parent table. These tables are explicitly linked via a pointer or by the physical arrangement of the records within the tables. A user accesses data within this model by starting at the root table and working down through the tree to the target data. This access method requires the user to be very familiar with the structure of the database.

Page 18: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Early Database ModelsNetwork database (nodes and set structures)

The network database was, for the most part, developed as an attempt to address some of the problems of the hierarchical database. The structure of a network database is represented in terms of nodes and set structures. A network database's main disadvantage is that a user has to be very familiar with the structure of the database in order to work through the set structures. Here, for example, it is incumbent on the user to be familiar with the appropriate set structures if he-or-she is to determine whether a particular engagement has been paid.

Page 19: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Early Database Models

Both the hierarchical and Network database models were workable, although the were cumbersome, and the end-user really had to know how the database was structure in order to make his-or-her way around it and get the most out of it.

If only there was a better way?

Page 20: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

20

A Side Trip: The “Toy Collection”

Page 21: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The “Toy Collection”A Visual Demonstration of Dynamic Proportions!

A database is a way of organizing data into information that we use to make decisions about things we care about. Information is represented by the questions that we need to answer in order to make better decisions.

Organizing data so that it is useful for decision making is called data modeling – we do this naturally as human beings! In an experiment with data modeling using toys as the subject, we can group subjects (toys) into sets by using the toys’ characteristics.

We are going to examine all the toys as a whole, then organize them into different groups (subsets) based on their unique as well as similar characteristics.

DEMO and BRIEF EXERCISE: The Toy Database

Page 22: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

22

The Database Modeling Process

Page 23: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Database Modeling Process

• Database Purpose: Describe what the database will do

• Informational Questions: Questions you want to have answered when using the database

• Data-Driven Decisions: Decisions supported by the information

• Data Processes: How you use the data to make decisions

• Subjects: Objects or events important to the decisions

• Characteristics: Attributes specific for each subject

• Sample Data: Examples for each subject that demonstrate the characteristics

Page 24: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

24

The Relational Database Model

Page 25: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelThe relational database was first conceived in 1969 and has arguably become the most widely used database model in database management today.

The father of the relational model, Dr. Edgar F. Codd, was an English research scientist working at the IBM Research Laboratory in San Jose, California. In the late 1960s he was looking into new ways to handle large amounts of data.

His dissatisfaction with the hierarchical and network database models and database products of the time led him to begin thinking of ways to apply the disciplines and structures of mathematics to solve the myriad of problems he had been encountering. Being a mathematician by profession, he strongly believed that he could apply specific branches of mathematics to solve problems, such as data redundancy, weak data integrity, and a database structure's overdependence on its physical implementation.

See: http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/reldb /

The data must relate to the key, the whole key and nothing but the key, so help me Codd.

Page 26: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

26

Data Modeling and Set Theory

Page 27: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Data Modeling & Set TheoryIn 1970, Edgar F. Codd published A Relational Model of Data for Large Shared Data Banks which defined the data model on which relational databases later came to be based. Among other things, it made use of set theory and first order predicate logic

Set TheoryThis Venn diagram expresses the results of operations on sets. The rectangle (U) represents the Universe, and the circles (A and B) inside represent sets of objects. The relative position and overlap of the circles indicate relationships between the two sets. In the relational model, the circles are tables, and the rectangle is all the information in the database.

Page 28: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

28

Subjects and Characteristics

Page 29: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Subjects and Characteristics

First Order Predicate LogicFirst-order logic is symbolized reasoning in which each sentence, or statement, is broken down into a subject and a predicate. The predicate modifies or defines the properties of the subject.

The term relation is typically used of a predicate which is applied to more than one thing, e.g. "greater than", which is applied to two things to make a comparison, but can also be used for predicates taking one or zero things. The number of "things" involved (as arguments) is called the arity of the predicate or relation.

A classic, if elementary, example of what can be done with the predicate logic is the inference from the premises:

All human beings are mortal. Socrates is a human being.

Therefore:

Socrates is mortal.

In our discussion about databases anddata modelling we will be talking aboutsubjects and characteristics

(DISCUSSION TO FOLLOW SOON)

Page 30: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

30

Relational Database Model Today

Page 31: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelComputerized databases help people store and track huge amounts of

information. The smallest unit of information in a database is called a field. Fields

are grouped together to form records. Records are then grouped together to form

tables.

Page 32: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelFlat-file databases take all the information from all the records and store

everything in one table. This works fine when you have a small number of records related to a single topic, such as a person’s name and phone number, but if you have hundreds or thousands of records, each with a number of fields, the database quickly becomes difficult to use.

Page 33: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelRelational databases separate this mass of information into numerous tables.

All the columns in each table should be about one topic, such as “student information,” “class information,” or “trainer information.”

student class trainer

Page 34: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelThe tables for a relational database are linked to each other through the use of keys.

Each table may have one primary key and any number of foreign keys.

A foreign key is simply a primary key from one table that has been placed in another table.

Page 35: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database ModelA relational database stores data in relations, which the user perceives as tables. Each relation is composed of tuples (or records) and attributes (or fields). We usually think of these in terms of rows and columns.

The physical order of the records or fields in a table is completely immaterial, and each record in the table is identified by a field that contains a unique value known as the Primary Key (PK).

These are the two characteristics of a relational database that allow the data to exist independently of the way it is physically stored in the computer. As such, a user isn't required to know the physical location of a record in order to retrieve its data. This is unlike the hierarchical and network database models, in which knowing the layout of the structures is crucial to retrieving data.

Page 36: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

36

Similar Concepts. Different Names

Page 37: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Similar Concepts, Different Names

Codd’s ModelRelationAttributeTuple

SQLTableColumnRow

FilesFileFieldRecord

Page 38: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

38

Relational Database Model Deconstructed

Page 39: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

What follows is a brief overview of the relational database model and several of the elements and features that make up a database.

NOT TO WORRY! Although I’ll be speeding along at a steady clip in today’s lecture, we will be going over each of these elements and features individually in upcoming lectures.

I’ll also be repeating myself a few times during these first few lectures—this is intentional!—to drive home certain key words and phrases, but I’ll go ahead and apologize for this now.

Page 40: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database DeconstructedAccording to the relational model, data in a relational database is stored in relations, which are perceived by the user as tables. Each relation is composed of tuples (records or rows) and attributes (fields or columns). A relational database has several other characteristics, which are discussed in this section.

Tables are the main structures in the database. Each table always represents a single, specific subject. The logical order of records and fields within a table is of absolutely no importance. Every table contains at least one field—known as a primary key—that uniquely identifies each of its records.

The subject that a given table represents can be either an object or an event. When the subject is an object, the table represents something that is tangible, such as a person, place, or thing. Regardless of its type, every object has characteristics that can be stored as data. You can then process this data in an almost infinite number of ways. Employees, products, machines, students, buildings, and equipment are all examples of objects that can be represented by a table.

When the subject of a table is an event, the table represents something that occurs at a given point in time and has characteristics you wish to record. These characteristics can be stored as data and then processed as information in exactly the same manner as a table that represents some specific object. Examples of events you might need to record include class times, judicial hearings, distributions of funds, lab test results, and geological surveys.

NOTE: I will take a closer look at the difference between Data and Information in an upcoming Lecture.

Page 41: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database DeconstructedA field is the smallest structure in the database, and it represents a characteristic of the subject of the table to which it belongs.

Fields are the structures that store data.

You can retrieve the data in these fields and then present it as information in almost any configuration imaginable. Remember that the quality of the information you get from your data is in direct proportion to the amount of time you’ve dedicated to ensuring the structural integrity and data integrity of the fields themselves. There is just no way to underestimate the importance of fields.

Every field in a properly designed database contains one and only one value, and its name identifies the type of value it holds. This makes entering data into a field very intuitive.

If you see fields with names such as FirstName, LastName, City, State, and ZipCode, you know exactly what type of value goes into each field. You’ll also find it very easy to sort the data by state or to look for everyone whose last name is Winkus.

Page 42: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database DeconstructedA record represents a unique instance of the subject of a table. It is composed of the entire set of fields in a table, regardless of whether or not the fields contain any values. Because of the manner in which a table is defined, each record is identified throughout the database by a unique value in the primary key field of that record.

Records are a key factor in understanding table relationships because you need to know how a record in one table relates to other records in another table.

A primary key is a field or group of fields that uniquely identifies each record within a table. (When a primary key is composed of two or more fields, it is known as a composite primary key.) The primary key is the most important for two reasons:

1. Its value identifies a specific record throughout the entire database2. Its field identifies a given table throughout the entire database.

Primary keys also enforce table-level integrity and help establish relationships with other tables.

Every table in your database should have a primary key.

Page 43: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database DeconstructedWhen you determine that a pair of tables has a relationship to each other, you typically establish the relationship by taking a copy of the primary key from the first table and inserting it into the second table, where it becomes a foreign key.

The term foreign key is derived from the fact that the second table already has a primary key of its own, and the primary key you are introducing from the first table is “foreign” to the second table.

Foreign keys are important not only for the obvious reason that they help establish relationships between pairs of tables but also because they help ensure relationship-level integrity. This means that the records in both tables will always be properly related because the values of a foreign key must be drawn from the values of the primary key to which it refers.

Foreign keys also help you avoid the dreaded “orphaned records,” a classic example of which is an order record without an associated customer. If you don’t know who placed the order, you can’t process it, and you obviously can’t invoice it.

Page 44: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The Relational Database DeconstructedA view is a virtual table composed of fields from one or more tables in the database. The tables that comprise the view are known as base tables. The relational model refers to a view as virtual because it draws data from base tables rather than storing any data on its own. In fact, the only information about a view that is stored in the database is its structure.

Views enable you to see the information in your database from many different perspectives, thus providing great flexibility for working with data. You can create views in a variety of ways—they are especially useful when based on multiple related tables. For example, you can create a view that summarizes information such as the total number of hours worked by every carpenter within the Seattle area in the past six months. Or you can create a view that groups data by specific fields.

In many RDBMS programs, a view is commonly implemented and referred to as a saved query or, more simply, a query. In most cases, a query has all the characteristics of a view, so the only difference is that it is referred to by a different name.

It’s important to note that some vendors refer to a query by its real name. Regardless of what it’s called in your RDBMS program, you’ll certainly use views in your database.

Page 45: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 46: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 47: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 48: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 49: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 50: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 51: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model Deconstructed

Page 52: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 53: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 54: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 55: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 56: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 57: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 58: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 59: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedExploring Unique Vales and Primary Keys

Page 60: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships

Page 61: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships

Page 62: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships

Page 63: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships

Page 64: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships: ONE-TO-MANY

Page 65: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships: ONE-TO-MANY

Crow’s Foot

Infinity

Page 66: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Table Relationships: ONE-TO-MANY

Page 67: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 68: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 69: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 70: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 71: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 72: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 73: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining Many-to-Many Relationships

Page 74: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The RDB Model DeconstructedDefining One-to-One Relationships

PLEASE NOTE: WE WILL BE EXAMINING & DISCUSSINGRELATIONSHIPS IN MUCH FURTHER DETAIL IN LATER CLASSES

Page 75: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

Assignment 1 (Review)

DUE Thursday, April 16, (Uploaded to Student Tracker) by MIDNIGHT

Page 76: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

76

BIT 275 ICE 01

Page 77: Instructor: Craig Duckett Lecture 01: Tuesday, April 7, 2015 Orientation and Database Introduction 1.

The “Care About” Exercise (with Partner)

A database is a way of organizing data into information that we use to make decisions about things we care about. Information is represented by the questions that we need to answer in order to make better decisions.

Think of a topic that you know and care about. With a partner, share your topic and brainstorm about situations related to the topic where you have found that accurate information helps you make better decisions.

List several Subjects that are important in those decisions, and several Characteristics for each Subject. Be prepared to share about your partner's topic with the class.

Some examples:

• School• Getting Good Grades• Family• Video Games• Baseball• A Job