Databases and the Internet

1
Databases and the Internet
2
What is a database?
3
What is a database?

• Repository of data
• Longevity issues
• Accessibility issues
• Interaction with other applications
• Workflow manager
• How are the data used?
• Incorporation of Business rules

4
Types of Databases

• Flatfile
• Like a rolodex
• Often, just a text file
• Delimited--Fields divided by a marker character
• CSV (comma-quote)
• Tab text
• Non-Delimited (or Position delimited)--fields
  denotes by column number
• Relational
• "One to many" relationships between tables
• Simultaneous Updates between databases

5
Types of Clients

• Thick clients
• Client does much of the work
• Relatively large and complex
• Thin clients
• Client is simple and light
• Server handles most of the work
• Network intensive
• Client/Server relationships
• Stateless--no information maintained on the
  server (eg. HTML page in a browser--but you can
  use cookies to get around this if need be).
• State maintained--server tracks state, eg.
  location, selections made, user information.

6
Internet Database Models

• Three Types
• Monolithic
• "Dilithic" (my term)
• Three Tier
• Defined by degree of separation of layers between
  the data and the user
• Think of these in relation to the OSI and other
  layered systems

7
Monolithic Databases

• Standalone application
• Application and Data tightly bound
• Examples include many mainframe systems and
  workgroup DB Systems
• Infocus
• ITWorks
• Access and Filemaker used as applications
• All actions take place within a single
  application
• Data may be in a separate or integrated file

8
Monolithic Application Model
9
Monolithic Application ITWorks

• Data file in Access format
• On file server
• Requires mounting drive by clients
• No true record locking
• Application is in Visual Basic, reads datafile
  from a mounted drive via a fileserver
• Any change in the application requires
  redeployment of all applications on all
  workstations

10
Monolithic Client/Server Model
11
Monolithic Client/Server Filemaker

• Filemaker Server (or Application acting as
  server!)
• Filemaker Application as Client
• Changes in Database used by all clients
• Record locking

12
A word about Filemaker

• Crossplatform
• Appletalk, IPX or TCP/IP
• Multiple Modes
• Peer to Peer (Filemaker Pro)
• Client/Server (Filemaker Pro Server)
• Web Server (Filemaker Unlimited)
• Relational (via Portals)
• ODBC (Open DataBase Connectivity) Support

13
Dilithic Databases

• Database with attached Client/Server module
  (these days generally a browser)
• Filemaker
• Fmpro.acgi
• Lasso
• Database and Client/Server module intimately
  linked-not easy to make substitutions

14
Dilithic Database Model
15
Dilithic Database Filemaker Unlimited

• Filemaker Pro Server as backend database
• Controls data and access
• Handles indexing, sorts and finds
• Filemaker Unlimited and HTTP server as interface
  component
• Builds forms
• Generates HTML and XML pages
• Browser acts as thin client

16
Dilithic Database Filemaker Unlimited
17
3 Tier Database Model
18
Three Tier Solutions

• Database backend
• Enterprise Relational Database
• Generally, no direct access to the database
• Middleware component
• Most work is done here
• Builds Database Tables
• Controls Access
• Tracks Changes
• API
• Clients
• Usually Thin
• Usually more than one type

19
Three Tier Solution Remedys Action Request
System

• Used for Problem Tracking by IS/IT
• Oracle backend
• Relatively thin clients, Remedy User and Notifier
• AR Web and Remedy Web
• API supporting Perl and C
• UNC has written some custom apps
• Web submission form
• Email hook for creating or updating tickets
• Possible to link to other problems tracking
  systems "at the hip"

20
Three Tier Solution Remedys Action Request
System
21
Adavantages of 3 Tiers

• Load Distribution
• Changes at one level transparent at other
  levels--eg. New client or backend
• Eases custom development
• Business and data rules, security controlled at
  middleware
• Consistent set of hooks via API

22
So which for what?

• Consider.
• The number of users
• How will the system scale? Does it need to?
• What's your timeline?
• What kind of output do you need?
• Paper forms, web, wireless devices?
• Will your application serve all needs?
• Security Issues
• Where is your security coming from?
• Who needs access to what?
• Need for agility in your code base
• Will you need to migrate? (Yes, you will!)
• Do you need to add specialized applications?