Instructor: Craig Duckett. Lecture 01: Tuesday, March 27 th, 2018 Orientation and Database Introduction

Transcription

1 Instructor: Craig Duckett Lecture 01: Tuesday, March 27 th, 2018 Orientation and Database Introduction 1

2 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). 2

3 Instructor: Craig Duckett Office: CC3-321 (Mobius Hall, 3rd Floor, through Double Doors, Right-Hand Hall) Office Hours: Tuesday/Thursday 11:00am-12:30pm (CC2-180 or CC3-321) StudentTracker 3

4 Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design (3rd Edition) Author: Michael J. Hernandex Copyright: 2013 ISBN-13: Pages: 672 The 2nd Edition is also okay to use (either physical or digital) The Language of SQL: How to Access Data in Relational Databases (Either 1 st Edition or 2 nd Edition) Author: Larry Rockoff Copyright: 2010 ISBN-13: Pages: 256 InterWebs 4

5 Free to join, either through username/password or Facebook account. If your decide to purchase a video course, I recommend doing a Google search first for Udemy coupon then apply the coupon code to your purchase. You NEVER have to pay full price for a Udemy course. Learn Database Design with MySQL MySQL for Beginners Database Design and MySQL Introduction to Databases and SQL Querying Advanced Databases and SQL Querying SQL Server for Beginners (Setting it Up) 5

6 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. 6

7 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 7

8 3 - Individual Assignments 1 Database Presentation (PowerPoint) 15 - In-Class Exercises (ICEs) 1 - Mid-Term Exam 1 - Final Exam Assessment Type Assignment Database presentation (PowerPoint) Points 150 each x 3 = 450 points 50 Points In-Class Exercises (ICEs) 20 points each x 15 = 300 Mid-Term Final Exam 100 points 100 points 1000 Total Points The above assessment schedule may be subject to change depending on needs/flow of the class 8

9 3 x 150 Points (450 points Total) Assignment 1 (Stage 1): DUE LECTURE 5 Tuesday, April 10 th Assignment 2 (Stage 2): DUE LECTURE 12 Tuesday, May 8 th Assignment 3 (Stage 3): DUE LECTURE 20 Tuesday, June 5 th Database Presentation: DUE LECTURE 20 Tuesday, June 5 th 9

10 15 x 20 Points (300 points Total) ICEs are located under the Lectures tab on the Website, in each of the Lecture accordion bars 10

11 2 x 100 Points (200 points Total) Exams will consist of pencil on paper. You will be allowed one (1) large index card for notes. Exam Guides for both the Mid-Term and Final Exams are posted in the right-hand column of the website. 11

12 Points Available (To Be Determined) I may make Extra Credit available throughout the quarter, on the Mid-Term, Final-Exam, and Assignment 3 (Stage 3). I may also make extra credit available as a supplement to some of the In- Class Exercises (ICEs) 12

13 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 Lecture 5, April 11 th, by midnight (uploaded to StudentTracker) An overview of upcoming assignments, etc, will be posted here. 13

14 BIT275 Course Website WALK THROUGH 14

15 Tuesday (LECTURE 1) Database Design for Mere Mortals: Chapter 1 Thursday (LECTURE 2) The Language of SQL: Chapters 1, 2 15

16 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) 16

17 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. 17

18 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 Information Subject and Characteristics

19 Two Types of Databases 19

20 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: See:

21 Early Database Models 21

22 Early Database Models Hierarchical 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.

23 Early Database Models Network 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.

24 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?

25 A Side Trip: The Toy Collection 25

26 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

27 The Database Modeling Process 27

28 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

29 The Relational Database Model 29

30 The Relational Database Model The 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. The data must relate to the key, the whole key and nothing but the key, so help me Codd. See: /

31 Data Modeling and Set Theory 31

32 Data Modeling & Set Theory In 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 Theory This 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.

33 Subjects and Characteristics 33

34 Subjects and Characteristics First Order Predicate Logic First-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 and data modelling we will be talking about subjects and characteristics (DISCUSSION TO FOLLOW SOON)

35 Relational Database Model Today 35

36 The Relational Database Model Computerized 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.

37 The Relational Database Model Flat-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.

38 The Relational Database Model Relational 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

39 The Relational Database Model The 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.

40 The Relational Database Model A 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.

41 Similar Concepts. Different Names 41

42 Similar Concepts, Different Names Codd s Model Relation Attribute Tuple Files File Field Record SQL Table Column Row

43 Relational Database Model Deconstructed 43

44 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.

45 The Relational Database Deconstructed According 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.

46 The Relational Database Deconstructed A 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.

47 The Relational Database Deconstructed A 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 database 2. 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!

48 The Relational Database Deconstructed When 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.

49 The Relational Database Deconstructed A 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.

50 The RDB Model Deconstructed

51 The RDB Model Deconstructed

52 The RDB Model Deconstructed

53 The RDB Model Deconstructed

54 The RDB Model Deconstructed

55 The RDB Model Deconstructed

56 The RDB Model Deconstructed

57 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

58 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

59 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

60 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

61 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

62 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

63 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

64 The RDB Model Deconstructed Exploring Unique Vales and Primary Keys

65 The RDB Model Deconstructed Defining Table Relationships

66 The RDB Model Deconstructed Defining Table Relationships

67 The RDB Model Deconstructed Defining Table Relationships

68 The RDB Model Deconstructed Defining Table Relationships

69 The RDB Model Deconstructed Defining Table Relationships: ONE-TO-MANY

70 The RDB Model Deconstructed Defining Table Relationships: ONE-TO-MANY Crow s Foot Infinity

71 The RDB Model Deconstructed Defining Table Relationships: ONE-TO-MANY

72 The RDB Model Deconstructed Defining Many-to-Many Relationships

73 The RDB Model Deconstructed Defining Many-to-Many Relationships

74 The RDB Model Deconstructed Defining Many-to-Many Relationships

75 The RDB Model Deconstructed Defining Many-to-Many Relationships

76 The RDB Model Deconstructed Defining Many-to-Many Relationships

77 The RDB Model Deconstructed Defining Many-to-Many Relationships

78 The RDB Model Deconstructed Defining Many-to-Many Relationships

79 The RDB Model Deconstructed Defining One-to-One Relationships PLEASE NOTE: WE WILL BE EXAMINING & DISCUSSING RELATIONSHIPS IN MUCH FURTHER DETAIL IN LATER CLASSES

80 Assignment 1 (Review) DUE LECTURE 5, Tuesday, April 10 th (Uploaded to Student Tracker) by MIDNIGHT

81 BIT 275 ICE 01 81

82 The Care About Exercise (with a 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