Storage and File Structure:Data-Dictionary Storage

By -

Data-Dictionary Storage

So far, we have considered only the representation of the relations themselves. A relational-database system needs to maintain data about the relations, such as the

image

image

schema of the relations. This information is called the data dictionary, or system catalog. Among the types of information that the system must store are these:

• Names of the relations

• Names of the attributes of each relation

• Domains and lengths of attributes

• Names of views defined on the database, and definitions of those views

• Integrity constraints (for example, key constraints)

In addition, many systems keep the following data on users of the system:

• Names of authorized users

• Accounting information about users

• Passwords or other information used to authenticate users

Further, the database may store statistical and descriptive data about the relations, such as:

• Number of tuples in each relation

• Method of storage for each relation (for example, clustered or nonclustered)

The data dictionary may also note the storage organization (sequential, hash or heap) of relations, and the location where each relation is stored:

• If relations are stored in operating system files, the dictionary would note the names of the file (or files) containing each relation.

• If the database stores all relations in a single file, the dictionary may note the blocks containing records of each relation in a data structure such as a linked list.

In Chapter 12, in which we study indices, we shall see a need to store information about each index on each of the relations:

• Name of the index

• Name of the relation being indexed

• Attributes on which the index is defined

• Type of index formed

All this information constitutes, in effect, a miniature database. Some database systems store this information by using special-purpose data structures and code. It is generally preferable to store the data about the database in the database itself. By using the database to store system data, we simplify the overall structure of the system and harness the full power of the database for fast access to system data.

The exact choice of how to represent system data by relations must be made by the system designers. One possible representation, with primary keys underlined, is Relation-metadata (relation-name, number-of-attributes, storage-organization, location) Attribute-metadata (attribute-name, relation-name, domain-type, position, length) User-metadata (user-name, encrypted-password, group) Index-metadata (index-name, relation-name, index-type, index-attributes) View-metadata (view-name, definition) In this representation, the attribute index-attributes of the relation Index-metadata is assumed to contain a list of one or more attributes, which can be represented by a character string such as “branch-name, branch-city”. The Index-metadata relation is thus not in first normal form; it can be normalized, but the above representation is likely to be more efficient to access. The data dictionary is often stored in a non-normalized form to achieve fast access.

The storage organization and location of the Relation-metadata itself must be recorded elsewhere (for example, in the database code itself), since we need this information to find the contents of Relation-metadata.

Comments

Post a Comment

Popular posts from this blog

XML Document Schema

By -
Image
XML Document Schema Databases have schemas, which are used to constrain what information can be stored in the database and to constrain the data types of the stored information. In contrast, by default, XML documents can be created without any associated schema: An el- ement may then have any subelement or attribute. While such freedom may occasionally be acceptable given the self-describing nature of the data format, it is not generally useful when XML documents must be processesed automatically as part of an application, or even when large amounts of related data are to be formatted in XML. Here, we describe the document-oriented schema mechanism included as part of the XML standard, the Document Type Definition , as well as the more recently defined XML S chema . Document Type Definition The document type definition ( D TD ) is an optional part of an XML document. The main purpose of a DTD is much like that of a schema: to constrain and type the information present in the docume
Read more

Extended Relational-Algebra Operations.

By -
Image
Extended Relational-Algebra Operations The basic relational-algebra operations have been extended in several ways. A simple extension is to allow arithmetic operations as part of projection. An important extension is to allow aggregate operations such as computing the sum of the elements of a set, or their average. Another important extension is the outer-join operation, which allows relational-algebra expressions to deal with null values, which model missing information. Generalized Projection The generalized-projectio n operation extends the projection operation by allowing arithmetic functions to be used in the projection list. The generalized projection operation has the form where E is any relational-algebra expression, and each of F 1 , F 2 ,.. . , F n is an arithmetic expression involving constants and attributes in the schema of E . As a special case, the arithmetic expression may be simply an attribute or a constant. For example, suppose we have a relation c r
Read more

Distributed Databases:Concurrency Control in Distributed Databases

By -
Image
Concurrency Control in Distributed Databases We show here how some of the concurrency-control schemes discussed in Chapter 16 can be modified so that they can be used in a distributed environment. We assume that each site participates in the execution of a commit protocol to ensure global trans- action atomicity. The protocols we describe in this section require updates to be done on all replicas of a data item. If any site containing a replica of a data item has failed, updates to the data item cannot be processed. In Section 19.6 we describe protocols that can continue transaction processing even if some sites or links have failed, thereby providing high availability. Locking Protocols The various locking protocols described in Chapter 16 can be used in a distributed environment. The only change that needs to be incorporated is in the way the lock manager deals with replicated data. We present several possible schemes that are applicable to an environment where data can be rep
Read more