considerations when implementing database into mobile application

41
Rakia Finley | rfi[email protected] | @rakiamc @SurgeAssembly Basics to Database Development

Upload: rakiamc

Post on 09-Jul-2015

257 views

Category:

Technology


0 download

DESCRIPTION

Powerpoint deck from the Washington, DC 2014 Code Her Conference by Rakia Finley, CEO, Surge Assembly www.surgeassembly.com

TRANSCRIPT

Page 1: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SurgeAssembly

Basics to Database Development

Page 2: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Rakia Finley CEO, Surge Assembly

Page 3: Considerations When Implementing Database into Mobile Application

www.SURGEASSEMBLY.com

Page 4: Considerations When Implementing Database into Mobile Application
Page 5: Considerations When Implementing Database into Mobile Application
Page 6: Considerations When Implementing Database into Mobile Application

Rain Maker Workshop

September 23rd & September 30th

9:30am-2pm

WeWork Wonder Bread Factory

Page 7: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

What is a Database?

"A database is an organized collection of information".

Page 8: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Database Basics

•You use databases all the time, although you might not realize it!

•Google Map directories

•The list of contacts on your phone

•Online product catalogues and shops

Page 9: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Database Basics•The important thing about databases is the way information is organized.

•Let's look at a simple telephone directory as an example. It has entries like this:

•Bloggs, Joe 1234 Main St. ........... (123) 123456

•You could simply enter all the information as shown here and then print your directory. The problem is that if you wanted to do something else with the data - for example, organize it in a different way; find all the people in the 123 area code, or publish a different version of the directory, you would have a lot of work to do. But if the information was organized in a database, those tasks would be very easy.

Page 10: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Database Basics•Your listing consists of five different pieces of information:

•Last name

•First name

•Address

•Area code

•Phone number

•Each of these bits of data are fields.

•Each group of fields belonging to the same item (product, person, company, etc.) is called a record.

•And each collection of records of the same type of data is called a table.

Page 11: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Database Basics•A good analogy is a Rolodex:

•The whole Rolodex is equivalent to a table

•Each card is equivalent to one record

•And each individual piece of information on each card is a field

•Another (more modern!) analogy is a spreadsheet:

•One worksheet is a table

•Each row in the worksheet is a record

•Each column is a field

Page 12: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Common Terminology•Database Management System (DBMS)

•software which controls the storage, retrieval, deletion, security, and integrity of data within a database

•Relational Database Management System (RDBMS)

•Stores data in tables

Page 13: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Relational Databases•The structure described is referred to as a "flat-file" database:

•A one-dimensional collection of data about one topic. This is fine for many purposes, but frequently we need to maintain more complex structures in which data from two or more tables is linked together. Typical examples are:

•Families (parents and children)

•Products and Parts

•Manufacturers and Products

•Classes and Students

•Customers and Invoices

Page 14: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Relational Databases•You might be tempted to think "Why can't I just add more fields if I need more information?" For example, if your database contains information about products and you want to add a list of the parts that make up each product, why not just add fields for "part 1", "part 2" and so on? You'll eventually run into limitations such as:

•Some products might have only one part; another might have 20. How do you know how many fields to add?

•What if the same part is used in a number of different products?

•What if you wanted to find a particular part? You would have to search all those additional parts fields, because you wouldn't know which one it might be in!

•What if you wanted to produce a report listing all your parts and their prices? That would be extremely difficult.

•That's why we have relational databases. In our products and parts example, we would have two tables: products and parts. The basic product details would go into fields in the Products table, and all the details about each part would go into a record in the parts table. We refer to the "one" table (products in this example) as the parent table, and the "many table (parts) as the child table. One more important thing is needed: something to tell the database how the records are linked together - in other words, which parts belong to which product.

Page 15: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Relational Databases•Each record must have a unique identifier. It must be UNIQUE for each record in the table and it must never change.

•The following illustration shows a setup for a many-to-one relationship between our products and parts tables:

Page 16: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Relational Databases•Many parts can be related to one product by matching the RelatedRecordNumber to a RecordNumber.

•To find all the parts that comprise the product whose RecordNumber is 1234, you would search the parts table for all records whose RelatedRecordNumber is 1234.

•But what if the same part can be used in a number of different products? That's what we call a many-to-many relationship: many components can be related to many products. To facilitate this, we need to introduce an additional table just to keep track of those relationships. Consider this illustration:

The Table Links table would contain one record for each link between a product and a part. With this sort of structure, you can easily produce reports showing all the parts belonging to a product, or all the products in which a particular part is used.

Page 17: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Common Uses of RDBMS•Object storage.

•Store an object in a relational database you need to flatten it – create a data representation of the object – because relational databases only store data. To store objects successfully in relational databases you need to learn how to map your object schema to your relational database schema.

•Implementing behavior within the database.

•Behavior is implemented in a relational database via stored procedures and/or stored functions that can be invoked internally within the database and often by external applications. Stored functions and procedures are operations that run within an RDBMS, the difference being what the operation can return and whether it can be invoked in a query.

•Concurrency control.

•Consider an airline reservation system. There is a flight with one seat left on it, and two people are trying to reserve that seat at the same time. Both people check the flight status and are told that a seat is still available. Both enter their payment information and click the reservation button at the same time. What should happen? If the system is working properly only one person should be given a seat and the other should be told that there is no longer one available. Concurrency control is what makes this happen. Concurrency control must be implemented throughout your object source code and within your database.

•Transaction control.

•A transaction is a collection of actions on your database – such as the saving of, retrieval of, or deletion of data – which form a work unit. A flat transactions is an “all-or-nothing” approach where all the actions must either succeed or be rolled back (canceled). A nested transaction is an approach where some of the actions are transactions in their own right. These sub-transactions are committed once successful and are not rolled back if the larger transaction fails.

•Enforcing referential integrity.

•The assurance that a reference from one entity to another entity is valid. For example, if a customer references an address, then that address must exist. If the address is deleted then all references to it must also be removed, otherwise your system must not allow the deletion.

Page 18: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

What to Know Before You Build Your Database

•What Information you need for your application to function

•What Information you need to understand your user and product

•What Information you need for proper process modeling

•What do you want your App to do

•What problem are you solving

Page 19: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Let’s Build A Database

Page 20: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates Database

•Relationship

•Business Rules/Stored Procedures

•Triggers

•Data Models

Page 21: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates

•Relationships

Page 22: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates Database

•Business Rules/Stored Procedures

Page 23: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Stored Procedure Overview

•A function stored in the DB server

•Can be invoked multiple times

•Advantage: reduce network traffic

•Can also be written using other languages (e.g., C, Java)

•Different vendors could have different implementations

•Check the manual and sample programs

Page 24: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates Database

•Triggers

Page 25: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Triggers•Activation - Occurrence of the event

•Consideration - The point, after activation, when condition is evaluated

•Immediate or deferred (when the transaction requests to commit)

•Condition might refer to both the state before and the state after event occurs

Page 26: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates Database

•Data Models

•Capture and translate complex system designs into easily understood representations of the data flows and processes, creating a blueprint for construction and/or re-engineering.

Page 27: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Postmates Database

•Data Models

•Capture and translate complex system designs into easily understood representations of the data flows and processes, creating a blueprint for construction and/or re-engineering.

Page 28: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Let’s Build A Database

Page 29: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Trigger Details•Multiple Triggers

•How should multiple triggers activated by a single event be handled?

•Evaluate one condition at a time and if true immediately execute action or

•Evaluate all conditions, then execute actions

•The execution of an action can affect the truth of a subsequently evaluated condition so the choice is significant.

Page 30: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

The Importance of Triggers•Element of the database schema

•General form: ON <event> IF <condition> THEN <action>

•Event- request to execute database operation

•Condition - predicate evaluated on database state

•Action – execution of procedure that might involve database updates

•Example: ON updating maximum course enrollment IF number registered > new max enrollment limit THEN deregister students using LIFO policy

Page 31: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Trigger Details•Execution

•- point at which action occurs With deferred consideration, execution is also deferred

•With immediate consideration, execution can occur immediately after consideration or it can be deferred

•If execution is immediate, execution can

Page 32: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Trigger Details

•Granularity -

•Row-level granularity: change of a single row is an event (a single UPDATE statement might result in multiple events)

•Statement-level granularity: events are statements (a single UPDATE statement that changes multiple rows is a single event).

Page 33: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Triggers in SQL/3•Events: INSERT, DELETE, or UPDATE statements or changes to individual rows caused by these statements

•Condition: Anything allowed in a WHERE clause

•No subqueries in Oracle

•Action: An individual SQL statement or a program written in the language of Procedural Stored Modules (PSM) (which can contain embedded SQL statements)

Page 34: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Triggers in SQL:1999•Consideration: Immediate

•Condition can refer to both the state of the affected row or table before and after the event occurs

•Execution: Immediate - can be before or after the execution of triggering event .

•Action of before trigger cannot modify the database

•Granularity: Both row-level and statement-level granularity

Page 35: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

A Program to Access Databases

•A program that includes SQL constructs.

•SQL constructs can be included in a program in two different ways:

•Statement Level Interface

•Call Level Interface

Page 36: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Statement Level Interface

•SQL constructs in application take two forms:

•Standard SQL statements (static or embedded SQL): Useful when SQL portion of program is known at compile time

•Directives (dynamic SQL): Useful when SQL portion of program not known at compile time. Application constructs SQL statements at run time as values of host language variables that

Page 37: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Call Level Interface•Application program written entirely in host language (no precompiler)

•Examples: JDBC, ODBC

•SQL statements are values of string variables constructed at run time using host language

•As with dynamic SQL

•Application uses strings as arguments of library

Page 38: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Embedded SQL•You can embed SQL statements into many programming languages procedural power (loops, variables, etc.)

•The main components of embedded SQL programming:

•Regular program blocks

•SQL code

Page 39: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Cursor Overview•Result set - set of rows produced by a SELECT statement

•Cursor - pointer to a row in the result set.

•Cursor operations:

•Declaration

•Open - execute SELECT to determine result set and initialize pointer

Page 40: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SURGEASSEMBLY

Cursor Types

•Insensitive cursor: Result set (effectively) computed and stored in a separate table at OPEN time

•Changes made to base table subsequent to OPEN (by any transaction) do not affect result set

•Cursor is read-only

Page 41: Considerations When Implementing Database into Mobile Application

Rakia Finley | [email protected] | @rakiamc

@SurgeAssembly

Basics to Database Development