father, Hare Hare Hare Hawk in Software

Make Quick Response Code in Software father, Hare Hare Hare Hawk

schooltype : High school High school College school name, St Mary St Mary UC Berkeley subject ; Science Social science Political science

Figure 7-8

In any relation the ruling and dependent parts should be clearly identi ed We do often encounter relations which have more than one candidate ruling part, for instance Department detail: RELATION dep no dep name : manager, location, budget,

To resolve the ambiguities in the dependencies when there are multiple candidate ruling parts we remove redundant ruling parts of a relation R into a very speci c type of a relation, the lexicon L After this process, for R, F D(Bi )=(A1 , A2 , , Aj ) 7-13

where Bi and Ai are de ned as in Eq 7-3 Now Eq 7-5 is satis ed, except for the lexicon relation L itself A lexicon de nes a one-to-one correspondence between two sets A and B by the binary relation L : A B Here the dependent part is functionally dependent on the ruling part and the ruling part is functionally dependent on the dependent part, ie, F D(A) = B and F D(B) = A In simple terms we can say that a lexicon implements equivalency Each tuple in a lexicon should reference a corresponding tuple in the entity relation and vice versa We note in the view model this structural dependency using reference connections between the relations A lexicon relation, giving a listing of department names versus department numbers, is shown in Fig 7-9 Since the ruling and the dependent part are symmetric, either attribute can be used as the ruling part in an implementation and the other part can then be uniquely determined

The nal entity relation which describes departments in detail (Dep detail) has as its ruling part the dep name, and the dep no would be the key for the related lexicon To get data about a department known by number, one would use the lexicon to obtain the dep name, and then proceed to Dep detail

Departments:

dep name ; Bookkeeping Auditing Foundry Forge Stamping Finishing Assembly Test Quality control Inside sales Outside sales

Figure 7-9

Lexicons occur frequently in operational databases, and recognition of lexicons during the view analysis simpli es the design process since ruling-part con icts are avoided Such con icts also occur when distinct view models are integrated, and lexicons are often created during that process

Another case for a lexicon appears in the Employee relation of Fig 7-6 The relation has another candidate for the ruling part, namely, the health no In a view model for employee health care, this number may be the ruling part A lexicon will connect the two view models

Lexicons can be treated conceptually as a single attribute while designing a database model, and this approach can greatly reduce the number of possible alternatives of the model This pseudo-attribute could be named department id, deferring the decision on how the department is actually identi ed Once a lexical pseudo-attribute is de ned, the lexicon does not take part in the model manipulations until the le implementation is considered

7-3-4 Second and Third Normal Form In Fig 7-4 we placed the years of experience of the employee in the Supervision relation, since this provided a meaningful separation of personal and professional data The ruling part for this relation, using the earlier de nitions, is the two attributes super and sub The values of years supervised are functionally dependent on this ruling part, but the experience is functionally dependent only on a subset of the ruling part, super We note that the experience is hence redundantly recorded in every tuple beyond the rst one for each supervising employee To avoid this redundancy the attributes which depend on subsets of the ruling part are moved to a separate relation or added to another, appropriate relation In this case the experience attribute will be assigned to the Employee relation rather than to the Supervision to in order to achieve a nonredundant form as shown in Fig 7-10 At other times a new relation may have to be de ned, as shown in Example 7-5 Employee 2: