The student will understand the basics of the Relational Database Model.
The student will learn Database Administration functions as appropriate for software developers.
The student will learn SQL.
The student will become familiar with the entire implementation cycle of a client server application.
And, you will build one.
2. Who am I?
Name : Guillermo Julca
Phone : 914-309-8412
Email : webmaster@gjp2s.com
Website : gjp2s.com
Best way to reach me is by Email!
What do I do?
Why am I here?
3. Class Info
Implementing the Database Server
MS SQL Server
SW###
#########, Room ###
Tuesday 6:30-9:30PM
Lecture/Lab format
4. SQL Server Versions
Class is based on SQL Server 2005.
Some concepts in the slides may refer to
previous versions of SQL Server - for
reference.
Most of the class will be applicable to any
database environment…
5. Texts
RECOMMENDED, not required. I do not
teach from a book.
Dewson, Beginning SQL Server 2005 for
Developers: From Novice to Professional.
Bowman et al, The Practical SQL Handbook
… or any other books you are comfortable
with!
6. SQL Server 2005 For YOU!
http://www.microsoft.com/sql/downloads/trial-so
180-day trial.
You can order a DVD for $5.99 + shipping.
Don’t dally – 3 weeks average delivery.
Will *NOT* install on Windows 95 or ME.
Previous students highly recommend this.
Good for mid-term and project.
7. Class Objectives
The student will understand the basics of
the Relational Database Model.
The student will learn Database
Administration functions as appropriate for
software developers.
The student will learn SQL.
The student will become familiar with the
entire implementation cycle of a client
server application.
And, you will build one.
10. What is a Database?
A collection of information.
The implication is that there is some
logical ordering of the data stored in it.
Databases are stored as one or more
files, on one or more disks, on one or
more computers.
11. What is a DBMS?
DataBase Management System
A software system that is responsible
for managing the data in the database.
Provides an interface through which
other software applications store and
retrieve data.
Secondary functions: Backup,
Distribution, etc.
SQL Server, Oracle, DB2, MySQL,
Access, etc.
12. Why use a database?
Permanent Storage.
Information is shared.
Provide synchronized access - locking.
Centralized security.
Backups.
13. Types of Databases - ‘Flat’ Files
A single file on a disk.
Access is sequential.
Operations on large files require
enormous amounts of memory (or are
very slow).
Locking is all or nothing - flagged.
Security is based on operating system
privileges.
The original.
14. Types of Databases - Indexed
Files
Start with a flat file. Each item of data is
the same size, and they are in any order.
A smaller external file exists which has
‘key’ data, and a pointer or ‘index’ into the
file.
Something like a table of contents.
File is accessed by an offset like an array
Data of varying sizes not easily modeled.
15. Types of Databases -
Hierarchical
Data is organized as a tree.
Can use a single or multiple files.
The Windows Registry.
Network Database Model (structures that
contain pointers to structures).
16. Types of Databases - Relational
Data is organized in tables.
Tables consist of rows and columns.
Tables with related information are linked,
allowing for data integrity.
Locking can go as low as the row level
(field level?).
17. Type of Databases - Object
Oriented
Classes define the data.
An instance of a class is an object.
Methods can be defined for classes that
contain the application logic.
Inheritance (subclasses) define data that
is related. Multiple inheritance allows for
wide variations in the types of
relationships.
Locking at the object level.
18. System Architecture -
Mainframe
The database is on a mainframe.
The application is also on the mainframe.
Users access ‘dumb terminals’, which are
controlled by the mainframe.
Durable, reliable, centralized.
EXPENSIVE!
19. System Architecture - PC / File
The database and the DBMS are on the
PC.
4GLs define the application, which also
runs on the PC.
Optionally, the database is on the network.
Large amounts of network traffic.
Dbase, FoxPro, Access, etc.
20. System Architecture -
The database Client/Server a server (or
and DBMS are on
set of severs).
Application logic is split between the client and
the server.
Less network traffic.
Allowed for complicated applications involving
multiple users on lower-cost equipment than a
mainframe.
21. Client/Sever - Fat Clients
The bulk of the application logic resides
on the client PC - the ‘workstation’.
Allows very complex logic to be
implemented using programming
languages.
Can be more difficult to design and
manage.
Requires application changes when
‘business rules’ change.
May require more network bandwidth.
Decision Support Systems, Expert
22. Client/Server - Fat Server
The server handles most business logic.
Little or no application changes required
when business rules change.
Uses ‘transactions’.
Implemented with referential integrity,
stored procedures, and constraints.
On-Line Transaction Processing (OLTP).
Systems where orders are processed.
23. Client/Server - ‘Mixed
Environments’
A nice way to say somewhere in the
middle.
Generally, all but very specific systems
should be (and are) designed in this
manner.
Systems that combine OLTP and decision
support functionality.
24. System Architecture - Tiers
Client/Server is passé – the new paradigm (and buzzword) is
“n-tiered architecture”.
As systems that grow from diverse needs require information
from each other, there may be multiple Servers as well as
multiple clients.
In many cases the data from these servers is combined,
processed, or amalgamated on yet another “Server”. This
software is called middleware; the machine is often called a
broker.
A web server is sometimes considered a tier; in this case the
clients are browser-based, and the distribution of application
logic can be divided across multiple tiers (Client side scripts?
Server side ASP / Applets? Database sprocs?).
You can describe a “fat tier” or a “dense tier” – the opposite of a
thin tier or a passthrough tier.
25. System Architecture - SOAs
Service-Oriented Architectures.
SOAs are really free-from tiers with well-
defined interfaces. Each should be, or maintain
the appearance of being, self contained.
A service may have its own database; there
may be a single service that provides an
interface to the database.
Services may be client or server side,
whichever is appropriate.
Each database server may be considered a
service of its own…
26. Application Examples
Fat Client - the advertising system.
Fat Server - UPC generation.
Mixed Environment - Version
Management.
All are somewhat mixed…
Other examples?
27. Scalability
How big is too big?
What is the line between MySQL, SQL
Server, Oracle, and what lies beyond?
Factors:
– Size
– Security
– Usage (TPS)
– Money
– Performance Requirements
– Nature of Transactions (Locking Strategies)
28. The Relational Model.
Defined by Codd, 1969. (Jeopardy?)
We will:
– present the technical definition of each term.
– translate that to standard vocab.
This is useful for talking to Unix gurus and
academic types… but this is a Master’s
program...
29. Domains
A set of values.
Must be atomic - cannot be broken
down further with respect to the
purpose it is modeled for. For example,
FULL_NAME can be atomic, as well as
FIRST_NAME and LAST_NAME
depending on the purpose of the field.
Point is, you never want to use it as less
than the whole thing.
30. Domains
A domain has a data type and optionally a
name.
Data type may be a simple PL data type
such as integer or string, or may be
constrained in some way:
– strings with a maximum length of 20 chars.
– All integers less than 100.
– The name of any city containing an NFL team.
31. Domains
Giving a domain a name is similar to #typedef
in C - it allows you to change the values
allowed in a domain used in multiple places
with a single code change. Not a great idea if
you are defining tables?
Conceptually :
TEAM_NAME = CHAR[26]
SALARY_RANGE = {20000..200000}
If you want to allow for longer team names,
higher salaries...
32. Relation Schema
“Table Definition”
A name and a set of “attributes”
attribute = column
each attribute has a name and a domain.
the “degree of the relation” is the number
of columns in the table.
33. Relation Instance
Relation for short, or just Table.
an instance of a relation schema.
“a set of tuples, where a tuple is an
ordered list of values, and where each
value is in the domain of the
corresponding attributes in the relation
schema being instantiated, or is a
special null value”
a set of unique rows, where each row
has values that match the definition of
34. Null Values
Used to signify that either:
A value does not apply
– An apartment # of a person that lives in a
house.
A value is unknown
– An unlisted phone #.
Comparisons to null values return
UNKNOWN, not TRUE or FALSE.
35. Keys
“by definition of a set, all tuples in a
relation must be distinct.”
No duplicate rows in a table.
a ‘superkey’ is a set of columns that are
unique in every row.
a ‘key’ is a superkey which cannot have
any more columns taken away from it
and still remain unique.
36. Primary Key
The primary key is a key that has been
chosen as the identifying key for that
table.
Usually, a synthetic value (customer
number, type id, etc.) is used. This
abstracts the real data from the key.
Example - product names.
37. Recap
relation schema - definition of a table
relation - table
attribute - column or field
tuple - row
superkey - set of columns guaranteed
unique.
key - a minimal superkey
primary key - the key used as an id for
a row.
38. Naming Conventions
Makes things easier to read.
Should be different than PL code.
My convention:
– All database objects and attributes in upper
case using underscores.
– PL and PL/SQL variables in mixed, starting
with lower
– Other PL names (Functions, Classes) in
mixed starting with caps.
– Table names always singular
(EMPLOYEE)