Suppliers and Parts database explained

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 An Introduction to Database Systems, 8th ed.^[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.

Notes and References

1. Book: Date, C.J. . 2004 . An Introduction to Database Systems — Eighth Edition . Chapter 3 / An Introduction to Relational Databases . Pearson Education Inc. . 0-321-18956-6.
2. Relations and SQL tables are roughly synonymous.