1
|
- Session 3
- INFM 718N
- Web-Enabled Databases
|
2
|
- PHP
- Examples
- Programming well
- Speed dating (20 minutes)
- Database design
|
3
|
|
4
|
- Database
- Collection of data, organized to support access
- Models some aspects of reality
- DataBase Management System (DBMS)
- Software to create and access databases
- Relational Algebra
- Special-purpose programming language
|
5
|
- 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=3DCLIS
- Useful standard for inter-process communications
- Visual programming (e.g., Microsoft Access)
- Unambiguous, and easier to learn than SQL
|
6
|
- Entities
- Types
- Subtypes (disjoint / overlapping), aggregation
- Attributes
- Identifier
- Relationships
- Cardinality
- Existence
- Degree
|
7
|
- 1NF:
- Atomic entries (Doug Oard) -> Doug, Oard
- Unique columns (classes -> separate table)
- 2NF
- No repeated data in multiple rows
- Ford, Taurus -> separate table
- 3NF
- Nonkey dependent on primary key
|
8
|
- Save space
- 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
|
9
|
- http://www.en.wampserver.com/
- Run phpinfo.php
- Error reporting on? M=
ySQL
configured?
- Create a database and user accounts (mysql)
- Run mysql_test.php
|
10
|
- Local vs. server-based display
- HTML as an indirect display mechanism
- “View Source” for debugging
- Procedural vs. Object-Oriented
|
11
|
- Learn some words
- Put those words together in simple ways
- Examine to broaden your understanding
- Create to deepen your mastery
- Repeat until fluent
|
12
|
- Local vs. Web-server-based display
- HTML as an indirect display mechanism
- “View Source” for debugging
- Procedural perspective (vs. object-oriented)
|
13
|
- A set of key-element pairs
- $days =3D array(“Jan”->31, “Feb”=3D>2=
8,
…);
- $months =3D explode(“/”,
“Jan/Feb/Mar/…/Dec”);
- $_POST
- Each element is accessed by the key
- {$days[“Jan”]}
- $months[0];
- Arrays and loops work naturally together
|
14
|
- Naturally encodes an order among elements
- 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
|
15
|
- Declaration
- function multiply($a, $b=3D3){return $a*$b;}
- Invoking a method
- All variables in a function have only local scope
- Unless declared as global in the function
|
16
|
- Limit complexity
- Extent
- Interaction
- Abstraction
- Minimize duplication
|
17
|
- <form action=3D“formResponseDemo.php”,
method=3D“post”>
- email: <input type=3D“text”, name=3D“emailR=
21;, value=3D“<?php
echo $email ?>”, size=3D30 />
- <input type=3D“radio”, name=3D“sure”,
value=3D“yes” /> Yes
- <input type=3D“radio”, name=3D“sure”,
value=3D“no” /> No
- <input type=3D“submit”, name=3D“submit”,
value=3D“Submit” />
- <input type=3D“hidden”, name=3D“submitted̶=
1;,
value=3D“TRUE” />
- </form>
- if (isset($_POST[“submitted”])) {
- echo “Your email address is $email.”;
- } else {
- echo “Error: page reached without proper form submission!R=
21;;
- }
|
18
|
- 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
- Modularity
|
19
|
- 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
|
20
|
- Reusing code [run the book’s programs]
- Understanding patterns [read the book]
- Applying patterns [modify programs]
- Coding without patterns [programming]
- Recognizing new patterns
|
21
|
- Design before you build
- Focus your learning
- Program defensively
- Limit complexity
- Debug syntax from the top down
|
22
|
|
23
|
- 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
|
24
|
- 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
|
25
|
- 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
|
26
|
- Syntax errors
- 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)
|
27
|
- Focus on the first error message
- 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
|
28
|
- 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!
|
29
|
- 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
|
30
|
- 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
|
31
|
- First, look where the bad data was created
- If that fails, print variables at key locations
- if (DEBUG) echo “\$foobar =3D $foobar”;
- Examine output for unexpected patterns
- Once found, proceed as for run time errors
- define (“DEBUG”, FALSE); to clean the output
|
32
|
- Functional decomposition
- High-level languages
- Structured programming, object-oriented design
- Patterns
- Design patterns, standard algorithms, code reuse
|
33
|
- 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
|
34
|
|
35
|
- 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
|
36
|
|
37
|
- 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
|
38
|
|
39
|
- 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
|
40
|
|
41
|
- 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
|
42
|
- “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
|
43
|
- 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
|
44
|
|
45
|
|
46
|
- Project chooses columns
- Restrict chooses rows
- Based on their contents
- e.g. department ID =3D “HIST”
- These can be specified together
- SELECT Student ID, Dept WHERE Dept =3D “History”
|
47
|
- Each SELECT contains a single WHERE
- Numeric comparison
- Boolean operations
- e.g., Name =3D “John” AND Dept <> “HISTR=
21;
|
48
|
- Attributes
- Appearance
- Concepts (represented by data)
- Behavior
- What it does
- How you control it
- How you observe the results
|
49
|
- 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)
|
50
|
- 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
|
51
|
- One-page contract
- Between developer and requirements commissioner
- Goal The problem to be solved
- Product What you plan to deliver
- Scope Available time and personnel
- Roles What you expect each other to do
|
52
|
- Functionality
- Content
- Usability
- Security/Stability
|
53
|
- What was the muddiest point in today’s class?
- Be brief!
- No names!
|