This paper provides a structured overview of foundational database management concepts addressed through a series of short-answer questions. Topics covered include the distinction between keys and superkeys, SQL data types with examples, the difference between attributes and value sets, specialization versus generalization in entity modeling, requirements collection and analysis, database programming approaches (Embedded SQL, Coral, and LDL), join dependency and fifth normal form, NULL values and dangling tuples, partitioned hashing, and query execution plans. The paper is suitable as a study reference for students learning relational database theory and SQL fundamentals.
A superkey may include superfluous (redundant) attributes, whereas a key may not. A key is essentially a minimal superkey — it is unique and no attribute can be removed from it without losing that uniqueness. A key is therefore more useful than a superkey, which may carry redundancies.
For example, the attribute set {SSN} is a unique key for a student relation, since each student has a unique social security number. A set such as {SSN, Age, Name}, however, contains redundant attributes beyond SSN and is therefore a superkey rather than a minimal key.
SQL requires a Data Definition Language (DDL). The data types available for SQL attributes include numeric, character-string, date, bit-string, and time.
Interval data type: This type is valuable because it is used to incrementally or decrementally modify data of a date, time, or similar field. Intervals can be set to either year/month intervals or day/time intervals. For example, an interval type could calculate the duration between two project start and end dates, or the number of months between an employee's hire date and today.
Character-string data types: These are important because they handle most categories of text data input. They consist of either fixed-length characters or varying-length characters. For example, a fixed-length CHAR(10) might store a postal code, while a varying-length VARCHAR(255) might store a customer's name or address.
An attribute describes a real-world entity or factor. All entities can be described by certain values, and the inclusion of all such values in a set is called the value set (or domain) of that attribute.
For instance, Student is an entity type. A student has attributes such as Name, Address, Class, and Subject. All the possible values for each attribute belong to that attribute's value set. The values that a particular attribute instance takes may be a small subset of everything in the value set.
In more concrete terms, consider the attribute Name for a student. The value set consists of all possible character strings of a given type and length. Any combination of characters within that domain belongs to the value set, but a specific student's name is just one particular value drawn from that domain. The distinction is analogous to the difference between a variable and the component values that variable can take.
Specialization refers to defining a set of subclasses of an entity type. The entity type itself is called the superclass of the specialization. Each subclass contains particular characteristics that distinguish it from the superclass and from other subclasses. For example, the superclass Employee may contain the set of subclasses {Secretary, Engineer, Technician}. Specializations may also add further distinctions — for instance, {Salaried-Employee, Hourly-Employee} can be added to distinguish employees by their rate of pay. Specialization allows designers to define and particularize subclasses with their own unique attributes.
Generalization, on the other hand, is the reverse process: differences are suppressed and multiple entity types are combined into a single, more general group. It abstracts shared characteristics upward into a common superclass.
Schema diagrams display only certain aspects of a schema, such as data items, certain types of constraints, and the names of record types. Because they do not capture the full semantics of the design process, differences between specialization and generalization are generally not displayed in schema diagrams.
Requirements collection and analysis involves interacting with potential users and user groups to gather and document detailed system requirements. This step is critically important because it helps the database designer identify particular problems, needs, and expectations before any implementation begins.
Without a thorough requirements analysis — or when this step is carried out poorly — user needs may go unmet, and an accumulation of frustration, design flaws, and errors can result. Proper requirements collection enables communication procedures, reporting needs, and inter-application dependencies to be identified and addressed early, reducing costly revisions later in the development lifecycle.
"Comparing Embedded SQL, Coral, and LDL"
"Defining join dependency and 5NF"
"Problems caused by null values in joins"
"How partitioned hashing works and its limits"
"How query execution plans operate"
Always verify citation format against your institution’s current style guide requirements.