Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-12-12
2003-06-10
Shah, Sanjiv (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06578043
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a method and apparatus for modeling events.
2. Background Art
A company that sells subscriptions to customers stores information about its customers in a database. The company would like to be able to remind a customer when the customer's subscription is about to end, and to give special offers to certain customers depending on who the customers are and how early or late the customers renew a subscription. Current database systems do not operate efficiently when the database becomes large. Current databases also lack the flexibility to be changed to allow the addition of new types of data to a customer database entry. Problems with existing database systems can be understood by first reviewing database systems.
When data is collected and stored on a computer in an organized manner that collection of data is called a database. In an effort to make the data stored in databases easily retrievable, databases are organized according to a predetermined structure. Unfortunately, once the underlying structure of the database is implemented the process of changing it is cumbersome. To add new relationships to a database the structure of the entire database must often be redefined. As a result, current database models inherently lack flexibility.
Database Organization
Databases are organized according to a data model that specifies the organizational structure of the database. A variety of different data models exist and each organizes data in a different manner. Examples of data models include the relational model, the object oriented model and the physical data model.
Once a data model is chosen the overall design of the database is implemented using that model. This overall design of the database is often referred to as the database schema and is defined by using a special language called a data definition language (DDL).
A database may contain one or more tables that are defined in a file called the data dictionary. Tables help keep the data in the database organized.
FIG. 1
illustrates a table
100
that contains information about customers. Each table is designed to store a collection of data and is comprised of a number of rows
101
-
107
. A row is separated into one or more columns
120
-
124
and each column is designated to receive values that have an associated name
140
. When data is placed into the table
100
it is placed in the appropriate column
120
-
124
. For example, values
130
-
135
represent a series of customer identification numbers. These values are placed in column
120
. Once an entry in a column contains an item of data it is referred to as a record. Each table may hold numerous records. When a row
101
-
107
is filled with data it represents a unique set of records. For example, if data were placed in columns
120
-
124
of row
101
that data is representative of the customer that has the customer identification number
130
.
A disadvantage of the way database tables are organized is that its organizational schema is predetermined and fixed. As a result current databases lack a flexible structure. For example, if a person using table
100
wanted to begin collecting other kinds of addressing information about a customer, such as the customers work address or electronic mail address, a new column
206
to hold that information is required and must be defined. To define a new column a new table
200
that has an additional column
206
is created. Thus an inherent disadvantage of current database systems is that the user is locked into collecting the kind of information the table is pre-defined to hold. Table
100
, for example, can only hold information pertaining to a customer's identification number, a customer's name, a customer's address, a customer's phone number, and a customer's fax number. To enter any other kind of information in Table
100
a new column must be defined.
Another disadvantage of current database systems is that every field in a table is assigned a value even if one does not exist. Referring now to Table
200
in
FIG. 1
, if data is entered into one of the columns in row
102
data must also entered into all the remaining columns. When no real information exists to input into a column, some other value, such as a NULL value, zero, or some other value. For example, if the value “Bob” is placed in the column
121
of row
102
and the value “14 Main St” is placed in column
122
of row
102
the remaining columns in row
102
are assigned NULL values. Since values are assigned to every row in column
120
, the remaining values of each row are filled with NULL values. This occurs regardless of whether additional information is actually entered into Table
200
. Once a row is filled with one piece of data the remaining entries for that row are filled with some value. Placing values inside a table even when one is not supplied wastes memory and computing resources.
Data that is stored in the records of a table can form the basis of a relationship between another table in the database as long as the other table has a related record. Data stored in a column (or columns) of a table can form the basis for a relationship between that table and another table in the database having a related column (or columns). For example, the customer table could be related to a table the customer orders table if the customer table contains a series of records having fields with the names “customer identification”, “last name”, “first name”, “street address”, “city”, “zip code” and the customer orders table has fields with the names “customer identification”, “service provided”, and “date service rendered.” Since both of these tables share a field with the name “customer identification”, the tables are both related to the same customer. Using a relationship between columns of two tables, it is possible to join these two tables to provide a single table of information that contains instances of rows from one table combined with related rows from the other table.
Tables may be related via one-to-one, one-to-many, or many-to-one relationships. In a one-to-one relationship, one row in one table is related to a single row in a second table and vice versa. For example, a row in an employee table that contains information about an employee relates to a salaries table that contains the employee's salary information. Since an employee is typically only earning a single salary, there is a one-to-one relationship between an employee's employee table record and the employee's salary table record.
In a one-to-many relationship, a row in one table may be related to many rows in a second table, but each row in the second table matches only one row in the first table. For example, a state table that contains a state identifier and a state name can be related to multiple rows in the employee table. However, a row in the employees table identifies only one state of residence, for example. Conversely, a many-to-one relationship exists where many rows in one table match only one row in a second table, but each row in the second table may match many rows in the first table.
To relate two tables, it is necessary to identify one or more columns that are common to both tables. These columns are typically referred to as keys. A primary key is a unique key within a table and uniquely identifies a row within the table. A foreign key in a second table is comprised of the column(s) containing a first table's primary key information. For example, in the employee table, an employee identifier (employeeID) can be assigned to uniquely identify each employee. The employeeID can be used as a primary key for the employees table. The employeeID can also be used as a foreign key in the salaries table. The employees and salaries tables can be joined by the employeeID columns in each table to have information from both tables available in a single record.
Applications are developed to provide a user with the ability to facilitate access and manipulation of the da
Shah Sanjiv
Starwave Corporation
The Hecker Law Group
LandOfFree
Method and apparatus for event modeling does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for event modeling, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for event modeling will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3099696