March 26th, 2009

Converting Data into Tables (Part 2 of 2)

Posted by admin in O. Database Objects

When designing SQL tables, you go through several logical steps:> Identify all of your tables.

> Decide what columns are to be in each table.

> Decide what column(s) will be used as the primary key so that every row is uniquely identified.
Primary key will be discussed in more detail.

> See that every table has at least one column in common with other columns in other tables in the database.
These common columns provide the logical links to the data in the other tables making this a relational database.

> Now normalize these tables to eliminate irregularities and anomalies.

March 25th, 2009

Converting Data into Tables (Part 1 of 2)

Posted by admin in O. Database Objects

A database table is a two-dimensional array of columns and rows. Tables normally describe places (such as stores), people (such as customers), objects (such as inventory), or relationships (such as sales transactions).

Let’s say that you wish to create a customer table. You might consider the following attributes:

                    Customer ID
                    Customer First Name
                    Customer Last Name
                    Customer Street Address
                    Customer City
                    Customer State
                    Customer Zip Code
                    Customer Phone Number
                    Customer Credit Limit

You can build an SQL command to create this table. For each column, you specify its name, its data type, and possibly one or more constraints as follows:

          CREATE TABLE CUSTOMER_TABLE (
                        CUST_ID                INTEGER        NOT NULL,
                        FIRST_NAME         CHAR(20),
                        LAST_NAME           CHAR(30)      NOT NULL,
                        STREET_ADDRESS CHAR(30),
                        CITY                       CHAR(20),
                        STATE                    CHAR(2),
                        ZIP_CODE              INTEGER,
                        PHONE_NUMBER    CHAR(14),
                        CREDIT_LIMIT        DECIMAL(11,2)
                        );

Now let’s consider creating a sales transaction table. If you have questions about the sale, you would like to have a phone number. If you put the phone number on the sales transaction, you will be repeating the same phone number on each sales ticket for each item processed, but the customer is buying your product and the phone number would occur only once if it is in the customer table. If you wish to change the phone number, you have only one place to change it if it is in the customer table. Look for the most logical association for locations of data.

March 24th, 2009

What are Database Objects? (Part 2 of 2)

Posted by admin in O. Database Objects

A cluster is an SQL session accessing a uniquely named set of catalogs. It is equivalent to an installation of a vendor’s RDBMS system.

A catalog is a uniquely named set of schemas. For very large database systems, such as distributed databases, you may encounter duplicate schemas and a catalog provides a higher hierarchy for grouping.

The schema is a uniquely named set of objects, such as tables, views, system tables, and stored procedures. The system tables contain the self-defining data for describing all of the other objects. The objects and data are owned by a given user. The owner (or creator) then determines who has access privileges to the data and objects.

The tables and views contain columns and rows of data.

You can qualify an object name as follows: CATALOG_NAME.SCHEMA_NAME.TABLE_NAME

> With most RDBMS systems, the cluster controls who gets access to the data.

> With Oracle and SQL Server, the catalog controls who gets access to the data.
For Oracle and SQL Server, you can think of the catalog as equivalent to an instance.

« Previous PageNext Page »