The structures of the data within a database
can be viewed in two ways, physically and logically.
The physical data structure refers to the
physical arrangement of the data on the secondary storage device, usually disk.
Typically, this physical structure is the concern of specialists who design
DBMSs. Analysts, programmers, and users are generally less concerned with the
physical structure than with the logical structure.
The logical data structure concerns how the
data "seem" to be arranged and the meanings of the data elements in
relation to one another. This structure, or model, is generally defined in terms
of a schema- an overall conceptual view of the logical relationships between the
data elements in the database. It includes the names of the major elements,
their attribute, and the logical relationships between them. The figure below
shows a schema that might apply to database of an autoparts store. Although
greatly simplified, it illustrates that relationships exist between part
numbers, types of cars, models, and manufactures. The connecting lines indicate
links and the arrows the type of relationship. For example, in this schema,
manufacturer is linked to part number, and the relationship in one-to-many (a
double-headed arrow implies many and single-headed arrow one). That is, one
manufacturer produces many part numbers, but each part number has only one
manufacturer. There are also indirect links indicated. A part number, for
example, is linked to type of vehicle through model.
In a large database, the relationships are
far more complex than those shown. Typically, each user or applications program
is concerned with only a small part or subset of the data elements in the
schema. The subset of the database schema required by a particular applications
program is referred to as a subschema or users� view. The subschema of a
payroll program would be different from the subschema of an accounts payable
program, and so on. This logical arrangement not only clarified the user�s
view of the database but also serves to enhance data security by providing
access to limited data elements on a need-to-know basis. A programmer working on
an inventory program, for example, would have no need to access employee salary