Suppliers and Parts database

The Suppliers and Parts database is an example relational database that is referred to extensively in the literature and described in detail in C. J. Date's "Introduction" 8ed.^[1] It is a simple database comprising three tables: Supplier, Part and Shipment, and is often used as a minimal exemplar of the interrelationships found in a database.

1. The Supplier relation^[2] holds information about suppliers. The SID attribute identifies the supplier, while the other attributes each hold one piece of information about the supplier.
2. The Part relation holds information about parts. Likewise, the PID attribute identifies the part, while the other attributes hold information about the part.
3. The Shipment relation holds information about shipments. The SID and PID attributes identify the supplier of the shipment and the part shipped, respectively. The remaining attribute indicates how many parts where shipped.

• Referential constraints known as Foreign keys ensure that these attributes can only hold values that are also found in the corresponding attributes in the Supplier and Parts relations.
• It is assumed that only one shipment exists for each supplier/part pairing, which isn't realistic for real world scenarios. This is intentionally oversimplified for pedagogical purposes, as is the entire database.

SQL

The following SQL schema is one possible expression of the Suppliers-and-Parts database.

CREATE TABLE Supplier (
  SID     int          primary key,
  SName   varchar(10)  NOT NULL,
  Status  int          NOT NULL,
  City    varchar(10)  NOT NULL
)

CREATE TABLE Part (
  PID     int          primary key,
  PName   varchar(10)  NOT NULL,
  Color   int          NOT NULL,
  Weight  real         NOT NULL,
  City    varchar(10)  NOT NULL
)

CREATE TABLE Shipment (
  SID     int          NOT NULL FOREIGN KEY REFERENCES Supplier(SID),
  PID     int          NOT NULL FOREIGN KEY REFERENCES Part(PID),
  Qty     int          NOT NULL,
  PRIMARY KEY (SID, PID)
)

Notes:

1. The ID attributes are simple integers, but they could be (among other things) UUIDs or a system-defined identifier type that holds system-generated values.
2. The choice of VARCHAR(10) is arbitrary and would be too small for real-world use.
3. The application of the NOT NULL constraint to all attributes is a design decision based on the view that NULLs are to be avoided. It is not, strictly speaking, a requirement of the schema.

References