PHP Programming Part II and Database Design Session

PHP Programming Part II and Database Design Session 3 INFM 718 N Web-Enabled Databases

Agenda • PHP – Examples – Programming well • Speed dating (20 minutes) • Database design

• Relational normalization • Structured programming • Software patterns • Object-oriented design • Functional decomposition Business Interaction Design rules Interface Design Client Hardware Web Browser Client-side Programming Interchange Language Server-side Programming (PC) (IE, Firefox) (Java. Script) (HTML, XML) (PHP) Database (My. SQL) Server Hardware (PC, Unix)

Databases • Database – Collection of data, organized to support access – Models some aspects of reality • Data. Base Management System (DBMS) – Software to create and access databases • Relational Algebra – Special-purpose programming language

Database “Programming” • Natural language – Goal is ease of use • e. g. , Show me the last names of students in CLIS – Ambiguity sometimes results in errors • Structured Query Language (SQL) – Consistent, unambiguous interface to any DBMS – Simple command structure: • e. g. , SELECT Last name FROM Students WHERE Dept=CLIS – Useful standard for inter-process communications • Visual programming (e. g. , Microsoft Access) – Unambiguous, and easier to learn than SQL

E-R Diagrams • Entities – Types • Subtypes (disjoint / overlapping), aggregation – Attributes • Mandatory / optional – Identifier • Relationships – Cardinality – Existence – Degree

Normalization • 1 NF: – Atomic entries (Doug Oard) -> Doug, Oard – Unique columns (classes -> separate table) • 2 NF – No repeated data in multiple rows • Ford, Taurus -> separate table • 3 NF – Nonkey dependent on primary key • City depends on zip

Goals of “Normalization” • Save space – Save each fact only once • More rapid updates – Every fact only needs to be updated once • More rapid search – Finding something once is good enough • Avoid inconsistency – Changing data once changes it everywhere

Installing WAMP • http: //www. en. wampserver. com/ • Run phpinfo. php – Error reporting on? My. SQL configured? • Create a database and user accounts (mysql) • Run mysql_test. php – Connects OK?

Working with PHP • Local vs. server-based display • HTML as an indirect display mechanism • “View Source” for debugging • Procedural vs. Object-Oriented

Language Learning • Learn some words • Put those words together in simple ways • Examine to broaden your understanding • Create to deepen your mastery • Repeat until fluent

Thinking About PHP • Local vs. Web-server-based display • HTML as an indirect display mechanism • “View Source” for debugging • Procedural perspective (vs. object-oriented)

Arrays in PHP • A set of key-element pairs $days = array(“Jan”->31, “Feb”=>28, …); $months = explode(“/”, “Jan/Feb/Mar/…/Dec”); $_POST • Each element is accessed by the key – {$days[“Jan”]} – $months[0]; • Arrays and loops work naturally together

Thinking about Arrays • Naturally encodes an order among elements – $days = rksort($days); • Natural data structure to use with a loop – Do the same thing to different data • PHP unifies arrays and hashtables – Elements may be different types

Functions in PHP • Declaration function multiply($a, $b=3){return $a*$b; } • Invoking a method $b = multiply($b, 7); • All variables in a function have only local scope • Unless declared as global in the function

Why Modularity? • Limit complexity – Extent – Interaction – Abstraction • Minimize duplication

Using PHP with (X)HTML Forms <form action=“form. Response. Demo. php”, method=“post”> email: <input type=“text”, name=“email”, value=“<? php echo $email ? >”, size=30 /> <input type=“radio”, name=“sure”, value=“yes” /> Yes <input type=“radio”, name=“sure”, value=“no” /> No <input type=“submit”, name=“submit”, value=“Submit” /> <input type=“hidden”, name=“submitted”, value=“TRUE” /> </form> if (isset($_POST[“submitted”])) { echo “Your email address is $email. ”; } else { echo “Error: page reached without proper form submission!”; }

Sources of Complexity • Syntax – Learn to read past the syntax to see the ideas – Copy working examples to get the same effect • Interaction of data and control structures – Structured programming • Modularity

Some Things to Pay Attention To Syntax • How layout helps reading • How variables are named • How strings are used • How input is obtained • How output is created Structured Programming • How things are nested • How arrays are used Modular Programming • Functional decomposition • How functions are invoked • How arguments work • How scope is managed • How errors are handled • How results are passed

Programming Skills Hierarchy • Reusing code [run the book’s programs] • Understanding patterns [read the book] • Applying patterns [modify programs] • Coding without patterns [programming] • Recognizing new patterns

Best Practices • Design before you build • Focus your learning • Program defensively • Limit complexity • Debug syntax from the top down

Rapid Prototyping + Waterfall Update Requirements Initial Requirements Choose Functionality Build Prototype Write Specification Create Software Write Test Plan

Focus Your Learning • Find examples that work – Tutorials, articles, examples • Cut them down to focus on what you need – Easiest to learn with throwaway programs • Once it works, include it in your program – If it fails, you have a working example to look at

Defensive Programming • Goal of software is to create desired output • Programs transform input into output – Some inputs may yield undesired output • Methods should enforce input assumptions – Guards against the user and the programmer! • Everything should be done inside methods

Limiting Complexity • Single errors are usually easy to fix – So avoid introducing multiple errors • Start with something that works – Start with an existing program if possible – If starting from scratch, start small • Add one new feature – Preferably isolated in its own method

Types of Errors • Syntax errors – Detected at compile time • Run time exceptions – Cause system-detected failures at run time • Logic errors – Cause unanticipated behavior (detected by you!) • Design errors – Fail to meet the need (detected by stakeholders)

Debugging Syntax Errors • Focus on the first error message – Fix one thing at a time • The line number is where it was detected – It may have been caused much earlier • Understand the cause of “warnings” – They may give a clue about later errors • If all else fails, comment out large code regions – If it compiles, the error is in the commented part

Run Time Exceptions • Occur when you try to do the impossible – Use a null variable, divide by zero, … • The cause is almost never where the error is – Why is the variable null? • Exceptions often indicate a logic error – Find why it happened, not just a quick fix!

Debugging Run-Time Exceptions • Run the program to get a stack trace – Where was this function called from? • Print variable values before the failure • Reason backwards to find the cause – Why do they have these values? • If necessary, print some values further back

Logic Errors • Evidenced by inappropriate behavior • Can’t be automatically detected – “Inappropriate” is subjective • Sometimes very hard to detect – Sometimes dependent on user behavior – Sometimes (apparently) random • Cause can be hard to pin down

Debugging Logic Errors • First, look where the bad data was created • If that fails, print variables at key locations – if (DEBUG) echo “$foobar = $foobar”; • Examine output for unexpected patterns • Once found, proceed as for run time errors – define (“DEBUG”, FALSE); to clean the output

Three Big Ideas • Functional decomposition – Outside-in design • High-level languages – Structured programming, object-oriented design • Patterns – Design patterns, standard algorithms, code reuse

Structured Information • Field An “atomic” unit of data – number, string, true/false, … • Record A collection of related fields • Table A collection of related records – Each record is one row in the table – Each field is one column in the table • Primary Key The field that identifies a record – Values of a primary key must be unique • Database A collection of tables

A Simple Example primary key

Another Example • Which students are in which courses? • What do we need to know about the students? – first name, last name, email, department • What do we need to know about the courses? – course ID, description, enrolled students, grades

A “Flat File” Solution Discussion Topic Why is this a bad approach?

Relational Algebra • Tables represent “relations” – Course, course description – Name, email address, department • Named fields represent “attributes” • Each row in the table is called a “tuple” – The order of the rows is not important • Queries specify desired conditions – The DBMS then finds data that satisfies them

A Normalized Relational Database Student Table Department Table Enrollment Table Course Table

Approaches to Normalization • For simple problems – Start with “binary relationships” • Pairs of fields that are related – Group together wherever possible – Add keys where necessary • For more complicated problems – Entity relationship modeling

Example of Join Student Table “Joined” Table Department Table

Problems with Join • Data modeling for join is complex • Join are expensive to compute – Both in time and storage space • But it is joins that make databases relational – Projection and restriction also used in flat files

Some Lingo • “Primary Key” uniquely identifies a record – e. g. student ID in the student table • “Compound” primary key – Synthesize a primary key with a combination of fields – e. g. , Student ID + Course ID in the enrollment table • “Foreign Key” is primary key in the other table – Note: it need not be unique in this table

Referential Integrity • Foreign key values must exist in other table – If not, those records cannot be joined • Can be enforced when data is added – Associate a primary key with each foreign key • Helps avoid erroneous data – Only need to ensure data quality for primary keys

Project New Table SELECT Student ID, Department

Restrict New Table WHERE Department ID = “HIST”

The SELECT Command • Project chooses columns – Based on their label • Restrict chooses rows – Based on their contents • e. g. department ID = “HIST” • These can be specified together – SELECT Student ID, Dept WHERE Dept = “History”

Restrict Operators • Each SELECT contains a single WHERE • Numeric comparison <, >, =, <>, … • e. g. , grade<80 • Boolean operations – e. g. , Name = “John” AND Dept <> “HIST”

What are Requirements? • Attributes – Appearance – Concepts (represented by data) • Behavior – What it does – How you control it – How you observe the results

Who Sets the Requirements? • People who need the task done (customers) • People that will operate the system (users) • People who use the system’s outputs • People who provide the system’s inputs • Whoever pays for it (requirements commissioner)

The Requirements Interview • Focus the discussion on the task – Look for entities that are mentioned • Discuss the system’s most important effects – Displays, reports, data storage – Learn where the system’s inputs come from – People, stored data, devices, … • Note any data that is mentioned – Try to understand the structure of the data • Shoot for the big picture, not every detail

The Project Plan • One-page contract – Between developer and requirements commissioner • • Goal Product Scope Roles The problem to be solved What you plan to deliver Available time and personnel What you expect each other to do

First Things First • Functionality • Content • Usability • Security/Stability

One-Minute Paper What was the muddiest point in today’s class? • Be brief! • No names!