Administration
  Home arrow Administration arrow Page 3 - Database Essentials
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Mobile Linux 
App Generation ROI 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Database Essentials
By: icarus, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 7
    2001-02-26

    Table of Contents:
  • Database Essentials
  • The Customer Is King
  • Relationships
  • Invasion Of The Foreign Keys
  • Looking Up The Index
  • Joined At The Hip
  • Room With A View
  • Pulling The Trigger
  • So That's Where All My Money Went...

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Database Essentials - Relationships


    (Page 3 of 9 )

    Many of today's databases are "relational database management systems", referred to by the acronym RDBMS. A relational database is typically composed of multiple tables, which contain inter-related pieces of information. SQL, or Structured Query Language, allows you to combine the data from these tables in different ways, thereby allowing you to create and analyze new relationships.

    The example you just saw consists of a single table. While this is fine by itself, it's when you add more tables, and relate the information between them, that you truly start to see the power inherent in this system. Here's an example:

    # "names" table
    +------------+-----------+----------+
    | CustomerID | FirstName | LastName |
    +------------+-----------+----------+
    |     234673 | John      | Doe      |
    |     734736 | Julius    | Caesar   |
    |       1243 | Daffy     | Duck     |
    +------------+-----------+----------+
    # "addresses" table
    +------------+------------------------------+---------------+-------+--------+---------+
    | CustomerID | StreetAddress                | City          | State | Zip    | Country |
    +------------+------------------------------+---------------+-------+--------+---------+
    |     234673 | 12, Some Street              | Nowheresville | ZZ    | 748202 |     56  |
    |     734736 | The Palace Behind The Lake   | Ancient Rome  | NA    |      0 |       0 |
    |       1243 | Next Door To The Rabbit Hole | Toontown      | TT    |  98765 |       0 |
    +------------+------------------------------+---------------+-------+--------+---------+
    # "balance" table
    +------------+----------------+
    | CustomerID | AccountBalance |
    +------------+----------------+
    |     734736 |     6546867.67 |
    |     234673 |        3275.99 |
    |       1243 |           3.00 |
    +------------+----------------+
    


    Each of these three tables is an independent entity; however, they can be linked to each other by means of the CustomerID field common to all of them. For example, you could easily use the CustomerID 1243 to find out that user "Daffy Duck" lives in Toontown, and has a balance of exactly $3.00 in his account. Or you could go about it the other way: among all the customers with a balance less than $10.00 in their accounts, CustomerID 1243, aka "Daffy Duck", is the only one living in Toontown, TT.

    These relationships are the fundamental basis of a relational database system. By making it possible to easily relate records in different tables to one another, an RDBMS makes it possible to analyze date in different ways, while simultaneously keeping it organized in a systematic fashion, with minimal redundancy.

    More Administration Articles
    More By icarus, (c) Melonfire


     

       

    ADMINISTRATION ARTICLES

    - Scalix: Linux Administrator`s Guide
    - Network Administration with FreeBSD 7
    - Components of an Information Architecture
    - The Anatomy of an Information Architecture
    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 6 hosted by Hostway
    Stay green...Green IT