The assignment requires you to organize a relational database for employee information by representing entries as sets of tuples and analyzing relations and functions within this context. Specifically, you will create sample entries, examine the properties of binary relations derived from specific fields, determine if certain relations are functions, identify an appropriate unique key field, and describe a relation between two fields as a function, analyzing its properties.
Paper For Above instruction
In the realm of relational databases, the foundational concept revolves around the organization of data in terms of relations and functions, represented as sets of tuples. A tuple is a finite ordered list of elements, which in databases corresponds to a single record or row. To exemplify, consider a database that stores employee information with six specific fields: firstName, lastName, SS#, age, yearsAtCompany, and phoneNumber. Creating sample data involves devising realistic or fabricated entries for three employees, which can be expressed as a set of three 6-tuples. For example: ("John", "Doe", "123-45-6789", 30, 5, "555-1234") ("Jane", "Smith", "987-65-4321", 25, 3, "555-5678") ("Alice", "Johnson", "555-55-5555", 40, 10, "555-8765")
These entries collectively form a relation of degree 6 (or a 6-ary relation), since they encompass six fields per record, encapsulated as a set of six-tuples. Moving forward, focusing on two particular fields—firstName and lastName—enables the construction of a binary relation, which is a set of ordered 2-tuples, each pairing a firstName with a lastName from the database. This relation's properties such as symmetry, transitivity, and reflexivity can be evaluated through concrete examples.
For instance, the relation R defined by:
R = {("John", "Doe"), ("Jane", "Smith"), ("Alice", "Johnson")}
would be considered symmetric if, whenever ("John", "Doe") is in R, ("Doe", "John") also belongs to R. Since the last name is generally not related to the first name in such a manner, R is not symmetric. Transitivity would require that if ("John", "Doe") and ("Doe", "Smith") are in R, then ("John", "Smith") should also be in R, which is not necessarily true. Lastly, R is reflexive if all individuals share their own
relation, i.e., ("John", "John") in R, which in this context is unlikely or not guaranteed, so R is not reflexive.
Next, considering whether the binary relation formed by firstName and lastName qualifies as a function, we observe that for a relation to be a function, each element in the domain, firstName, must be associated with exactly one element in the range, lastName. Given that multiple employees can share the same first name, the relation assigns multiple last names to a single first name, violating the definition of a function. Thus, this relation is not a function because a single domain element maps to multiple range elements.
In the context of database design, a key is a field that uniquely identifies each record. Looking at our sample data, SS# is an ideal candidate for the primary key since each Social Security number is unique to an individual. Alternatively, phoneNumber might also serve as a key if it is unique across employees; however, SS# is typically more reliable. Employing SS# as the key ensures that each record is uniquely identifiable and prevents duplication or ambiguity in data retrieval.
Finally, to illustrate a relation that is a function between two chosen fields, consider the relation between lastName and firstName, where each last name maps to exactly one first name. In most cases, if each last name corresponds to a unique person, then this relation is a function. If, however, multiple individuals share the same last name, then this function would not be injective (one-to-one) but could be surjective (onto) if every first name in the database appears as an image of some last name. An example of such a relation could be defined by:
F = {("Johnson", "Alice")}
where the domain is lastName, and the range is firstName. If this relation maps every last name to a different first name, and each last name corresponds to exactly one first name, then it is a bijective function. Typically, due to commonality of last names, this relation may be neither injective nor surjective unless designed carefully. An illustration might involve assigning each unique last name to a specific first name, creating a one-to-one correspondence, which is bijective, provided all last names are uniquely mapped to first names, and vice versa.
References
Koshy, T. (2004).
Discrete mathematics with applications
. Burlington, MA: Elsevier Academic Press.
Johnsonbaugh, R. (2018).
Discrete mathematics (8th ed.). New York, NY: Pearson.
Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009).
Introduction to algorithms (3rd ed.). The MIT Press.
Database management systems . McGraw-Hill.
Principles of database systems . Computer Science Press.
Database systems: The complete book . Prentice Hall.
Database and knowledge-base systems . Springer Science & Business Media.