s id S1 S2 S3 S4 S5 in Software

Creation Denso QR Bar Code in Software s id S1 S2 S3 S4 S5

Parts:

weight, 031 007 004 002

Supply:

Figure 7-16

It is possible for associative relations to have no dependent part This would be appropriate for a relation which describes the capability of a speci c Supplier to deliver certain Parts This relationship contains information, and must be explicitly modeled by a relation and two connections Such a relation which associates suppliers which may be called upon to supply speci c parts with the Parts relation is shown in Fig 7-17 The semantic di erence between these two relations is not obvious from the connection structure and has to be described by attaching a de nition to the relation An association can also associate tuples within the same relation Possible supplier:

Figure 7-17

Sec 7-3

A simple case of an association within a relation is created if we were to keep both streets and avenues of Fig 7-15 in one relation Roads Another case occurs when an employee can have multiple supervisors An association Supervision matrix between Employee and supervisors in the Employee relation will permit description of this manyto-many relationship We see that the ownership rules apply here too An entry in the Supervision matrix requires existence of the employee and the supervisor

7-3-8 The View Model We have considered up to now the relations and their connections one by one The view model will of course have many relations and connections; values on the order of a dozen are seen in practice Any relation can participate in multiple connections, and hence have multiple constraining rules imposed on it For instance, referenced relations are often shared by multiple primary relations, and the primary relations may in turn be entitity relations, nests, lexicons, associations, or other referenced entity relations A single-view model should, however, be clear to the participants in the design process If it is not, it is unlikely that semantic errors will be recognized Use of a graphic representation, with the connection symbols given in Sec 7-3-6, reveals the structure of the model If a view model avoids redundancy, the only attributes that appear in more than one relation are those that de ne connections The owner, the reference, and the general attribute(s) are repeated, respectively, in the owned, the referenced, and the subset relation The number of attributes #aH found in all nrel relations is the number of all distinct attributes in all relations plus the number of attributes in connections

#Rh C = #

+ #a(connections)

7-16

where the set of attributes C = A&B is particular to each relation Rh We note also that all replicated attributes are ruling parts on one of the sides of the connections The de nition of functional dependencies is useful to verify view models which have been intuitively constructed The functional dependencies may in turn be veri ed by using available data Although it is not possible to use data to prove the correctness of a functional dependency or of the view model, it is possible to nd errors from existing data Any inconsistencies that are found will be due either to errors in the data, say, di erent ages for the same employee; or to an incorrect perception of the real world: there is indeed a department with two managers, although we stated F D(department) = manager In the latter case the decision has to be made whether the real world should be adjusted (the old department can be split into two departments, each with one manager) or the view model be changed (a new associative relation can be created with a ruling part composed of manager and department jointly)