Have to have an identifier and the partial identifier

This preview shows page 3 - 5 out of 22 pages.

have to have an identifier, and the (partial) identifier of a weak entity forms only part of a corresponding relation’s primary key. In addition, there may be several attributes of an entity that may serve as the associated relation’s primary key. All of these situations will be illustrated later in this chapter.A composite keyis a primary key that consists of more than one attribute. For example, the primary key for a relation DEPENDENT would likely consist of the RelationA named two-dimensional table of data.Primary keyAn attribute or a combination of attributes that uniquely identifies each row in a relation.Composite keyA primary key that consists of more than one attribute.EMPLOYEE1EmpIDNameDeptNameSalary100Margaret SimpsonMarketing48,000140Allen BeetonAccounting52,000110Chris LuceroInfo Systems43,000190Lorenzo DavisFinance55,000150Susan MartinMarketing42,000FIGURE 4-1EMPLOYEE1 relation with sample dataWOW! eBook
194Part III • Database Designcombination EmpID and DependentName. We show several examples of composite keys later in this chapter.Often we must represent the relationship between two tables or relations. This is accomplished through the use of foreign keys. A foreign keyis an attribute (possibly composite) in a relation that serves as the primary key of another relation. For example, consider the relations EMPLOYEE1 and DEPARTMENT:EMPLOYEE1(EmpID, Name, DeptName, Salary)DEPARTMENT(DeptName, Location, Fax)The attribute DeptName is a foreign key in EMPLOYEE1. It allows a user to associate any employee with the department to which he or she is assigned. Some authors empha-size the fact that an attribute is a foreign key by using a dashed underline, like this:EMPLOYEE1(EmpID, Name, DeptName, Salary)We provide numerous examples of foreign keys in the remainder of this chapter and discuss the properties of foreign keys under the heading “Referential Integrity.”PROPERTIES OF RELATIONSWe have defined relations as two-dimensional tables of data. However, not all tables are relations. Relations have several properties that distin-guish them from non-relational tables. We summarize these properties next:1. Each relation (or table) in a database has a unique name.2. An entry at the intersection of each row and column is atomic (or single valued). There can be only one value associated with each attribute on a specific row of a table; no multivalued attributes are allowed in a relation.3. Each row is unique; no two rows in a relation can be identical.4. Each attribute (or column) within a table has a unique name.5. The sequence of columns (left to right) is insignificant. The order of the columns in a relation can be changed without changing the meaning or use of the relation.6. The sequence of rows (top to bottom) is insignificant. As with columns, the order of the rows of a relation may be changed or stored in any sequence.REMOVING MULTIVALUED ATTRIBUTES FROM TABLESThe second property of rela-tions listed in the preceding section states that no multivalued attributes are allowed

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture