Database Systems: SQL Report on Composite Keys and Attributes

This report delves into the concepts of composite keys and composite attributes within the context of SQL and database systems. It begins by defining both terms, explaining their roles in database design and normalization. The report differentiates between composite keys, which uniquely identify rows in a table, and composite attributes, which can be broken down into multiple atomic attributes. It uses examples from supplier and order tables to illustrate these concepts. The document also discusses how composite attributes and keys are represented in Entity Relationship Diagrams (ERD). Finally, it highlights the differences between composite keys and composite attributes, emphasizing the importance of composite keys in maintaining relationships and the role of composite attributes in the normalization process. References are provided for further reading.

Running Head: SQL - COMPOSITE KEYS AND COMPOSITE ATTRIBUTES
SQL - Composite keys and composite attributes
Name of the Student
Name of the University
Authors note

SQL - COMPOSITE KEYS AND COMPOSITE ATTRIBUTES1
Composite Key
In database a composite key is one that contains more than an attribute that helps in
unique identification of each row in a specific table of a databases. A composite key can be a
primary key or a candidate key.
Composite Attribute
An attribute is said to be a composite attribute is when it consists of more than one
attribute in it and can be divided into the multiple atomic components in the normalization
process.
Comparison and contrast between the composite key and
composite attribute
In database an attribute is a component of a table. For a composite attribute it
includes multiple atomic attributes such as address field. In case of “address” field for an
employee table it may include street no, town name, house no, Zip code.
On the contrary the Composite key acts as a unique identifier that is used identify a
row from the table uniquely. For example, for a supplier tables includes a vendor with orders
then the order table will contain order number, order day, order quantity. A vendor table may
contain vendor address, vendor code.
Here it can be stated that the vendor and order are entities and vendor code, order
number are Composite keys as they are unique for each vendor and order (Jukic, Vrbsky and
Nestorov 2016). Whereas for vendor address as it may include multiple values then it is a
Composite attribute, and order day is an attribute only as it is not unique for each order.

SQL - COMPOSITE KEYS AND COMPOSITE ATTRIBUTES2
Displaying composite key and composite attribute in ERD
For a composite attribute, they are further distributed in tree structure. Every node
connected to the entity is an attribute. For the composite attributes, they are denoted by
ellipses connected with another ellipse which connects the tree structure with the entity
(Condit et al. 2014).
For the composite key, they text in the ellipses are underlined to denote them as a
primary key.
Difference between composite key and a composite attribute
A composite attribute can be derived in to multiple atomic attributes in order to
simplify the database through the normalization process. Where as in case of composite key it
is the collection of attributes that are helpful in identifying the rows of a table uniquely
(Jukic, Vrbsky and Nestorov 2016). Any change in the composite key may lead to
inconsistent relationship between the tables of the database. The composite may contain
candidate keys to create the composite key.

SQL - COMPOSITE KEYS AND COMPOSITE ATTRIBUTES3
References
Al-Masree, H.K., 2015. Extracting Entity Relationship Diagram (ERD) from relational
database schema. International Journal of Database Theory and Application, 8(3), pp.15-26.
Condit, R., Lao, S., Singh, A., Esufali, S. and Dolins, S., 2014. Data and database standards
for permanent forest plots in a global network. Forest Ecology and Management, 316, pp.21-
31.
Jukic, N., Vrbsky, S. and Nestorov, S., 2016. Database systems: Introduction to databases
and data warehouses. Prospect Press.
Rossi, B., 2014. Entity relationship diagram.