Моделирование бизнес-процессов / Моделирование бизнес-процессов / I D E F / Idef1x
.pdfB.5.3.19 Child Cardinality is Z or 1 Iff Roles Contain the Primary Key or Any B.5.3.19 Child Cardinality is Z or 1 Iff Roles Contain the Primary Key or Any Alternate Key
If the connection relationship has a child high cardinality value, has foreign key attributes, and the child in the relationship h primary key, then the child high cardinality is 1 if and only if every primary key attribute is a foreign key attribute or for s alternate key, every alternate key attribute is a foreign key attribute.
( for all * )
( if ( mm: connectionRelationship ): I has childHigh: CH, ( mm: connectionRelationship ): I has fkeys: Fkeys, ( mm: connectionRelationship ): I has child: J,
( ( mm: viewEntity ): J has pkeys: Pkeys then
CH = 1 iff
( for all X )
( if member( Pkeys, X ) then
member( Fkeys, X ) )
or
( for some K )
( ( mm: viewEntity ): J has alternateKey: K, ( for all L, M, X )
( if ( mm: alternateKey ): K has contains: L,
( mm: alternateKeyAttribute ): L has viewEntityAttribute: M, ( mm: viewEntityAttribute ): M has domain: X
then
member( Fkeys, X ) ) ) ).
B.5.3.20 Is-Mandatory is True Iff All Roles Are NonullB.5.3.20 Is-Mandatory is True Iff All Roles Are Nonull
A relationship is mandatory if and only if the relationship has foreign key attributes and they are all non-null.
( for all * )
( if ( mm: connectionRelationship ): I has is_mandatory: TF, ( mm: connectionRelationship ): I has fkeys: Fkeys,
( mm: connectionRelationship ): I has child: J, then
FK = ‘True’ iff
( for all X )
( if member( Fkeys, X ) then ( for some K )
( ( mm: viewEntity ): J has contains: K,
( mm: viewEntityAttribute ): K has domain: X,
( mm: viewEntityAttribute ): K has is_nonull: ‘True’ ) ) ).
B.5.3.21 Connection with Foreign Keys is Identifying Iff the Foreign Key Attributes Are a Subset of the Child Primary KeyB.5.3.21 Connection with Foreign Keys is Identifying Iff the Foreign Key Attributes Are a Subset of the Child Primary Key
( for all * )
( if ( mm: connectionRelationship ): I has is_identifying: TF, ( mm: connectionRelationship ): I has fkeys: Fkeys,
( mm: connectionRelationship ): I has child: J, ( mm: viewEntity ): J has pkeys: Pkeys
then
131
FK = ‘True’ iff
( for all X )
( if member( Fkeys, X ) then member( Pkeys, X ) ) ).
B.5.3.22 Foreign Key Attributes Determine ConnectionNoB.5.3.22 Foreign Key Attributes Determine
ConnectionNo
( for all * )
( if ( mm: connectionRelationship ): I1 has connectionNo: CN1, ( mm: connectionRelationship ): I1 has fkeys: Fkeys1,
( mm: connectionRelationship ): I1 has child: C, ( mm: connectionRelationship ): I1 has parent: P,
( mm: connectionRelationship ): I2 has connectionNo: CN2, ( mm: connectionRelationship ): I2 has fkeys: Fkeys2,
( mm: connectionRelationship ): I2 has child: C, ( mm: connectionRelationship ): I2 has parent: P,
( for all X ) ( if member( Fkeys1, X ) then member( Fkeys2, X ) ), ( for all X ) ( if member( Fkeys2, X ) then member( Fkeys1, X ) )
then
CN1 = CN2 ).
B.5.3.23 Connection Foreign Key Attributes Type Uniquely Onto Parent Primary Key Attributes
In a connection relationship, there are the same number of foreign key attributes as primary key attributes and every foreign key attribute in the child references exactly one primary key attribute in the parent.
The number of connection foreign key attributes equals the number of parent primary key attributes.
( for all * )
( if ( mm: connectionRelationship ): I has fkeys: L1, ( mm: connectionRelationship ): I has parent: J, ( mm: viewEntity ): J has pkeys: L2,
count( L1, C ) then
count( L2, C ) ).
A domain D1 references another domain, D2, if D1 = D2 or if D2 is an ancestor of D1.
( for all * )
( ( mm: domain ): I has references: J. ifdef I = J
or
( mm: domain ): I has ancestor: J ).
Each connection foreign key attribute references a parent primary key attribute.
( for all * )
( if ( mm: connectionRelationship ): I has fkeys: L1, ( mm: connectionRelationship ): I has parent: K, ( mm: viewEntity ): K has pkeys: L2,
member( L1, Fk ) then ( for some Pk )
( member( L2, Pk ),
( mm: domain ): Fk has references: Pk ) ).
Each connection foreign key attribute references at most one parent primary key attribute.
132
( for all * )
( if ( mm: connectionRelationship ): I has fkeys: L1, ( mm: connectionRelationship ): I has parent: K, ( mm: viewEntity ): K has pkeys: L2,
member( L1, Fk ), member( L2, Pk1 ), member( L2, Pk2 ),
( mm: domain ): Fk has references: Pk1 ( mm: domain ): Fk has references: Pk2
then
Pk1 = Pk2 ).
B.5.3.24 Category Primary Key Attributes Type Uniquely Onto Generic Primary Key Attributes B.5.3.24 Category Primary Key Attributes Type Uniquely Onto Generic Primary Key Attributes
The number of category primary key attributes equals the number of generic primary key attributes and every category primary key attribute references exactly one generic primary key attribute.
The number of category primary key attributes equals the number of generic primary key attributes.
( for all * )
( if ( mm: category ): I has pkeys: L1, ( mm: category ): I has cluster: K, ( mm: cluster ): K has generic: J,
( mm: viewEntity ): J has pkeys: L2, count( L1, C )
then
count( L2, C ) ).
Each category primary key attribute references a generic primary key attribute.
( for all * )
( if ( mm: category ): I has pkeys: L1, ( mm: category ): I has cluster: K, ( mm: cluster ): K has generic: J,
( mm: viewEntity ): J has pkeys: L2, member( L1, Fk )
then ( for some Pk )
( member( L2, Pk ),
( mm: domain ): Fk has references: Pk ) ).
133
Each category primary key attribute references at most one generic primary key attribute.
( for all * )
( if ( mm: category ): I has pkeys: L1, ( mm: category ): I has cluster: K, ( mm: cluster ): K has generic: J,
( mm: viewEntity ): J has pkeys: L2, member( L1, Fk ),
member( L2, Pk1 ), member( L2, Pk2 ),
( mm: domain ): Fk has references: Pk1 ( mm: domain ): Fk has references: Pk2
then
Pk1 = Pk2 ).
B.5.4 Valid IDEF1X ModelB.5.4 Valid IDEF1X Model
The meta model informally defines the set of valid IDEF1X models in the usual way. The meta model also formally defines the set of valid IDEF1X models in the following way. The meta model, as an IDEF1X model, has a corresponding formal theory. The semantics of the theory are defined in the standard way. That is, an interpretaion of a theory consists of a domain of individuals and a set of assignments:
To each constant in the theory, an individual in the domain is assigned.
To each n-ary function symbol in the theory, an n-ary function over the domain is assigned.
To each n-ary predicate symbol in the theory, an n-ary relation over the domain is assigned.
In the intended interpretation, the domain of individuals consists of views, such as production; entities, such as part and vendor; domains, such as qty_on_hand; connection relationships; category clusters; and so on.
If every axiom in the theory is true in the interpretation, then the interpretation is called a model for the theory. Every model for the IDEF1X theory corresponding to the IDEF1X meta model and its constraints is a valid IDEF1X model.
134
B.6 BibliographyB.6 Bibliography
[B1] Brown, R. G., Logical Database Design Techniques, The Database Design Group, Inc., Mountain View, California, 1982.
[B2] Brown, R. G. and Parker, D. S. "LAURA, A Data Model and Her Logical Design Methodology," Proc. 9th VLDB Conf., Florence, Italy, 1983.
[B3] Bruce, T. A., Designing Quality Databases with IDEF1X Information Models, Dorset House, 1992.
[B4] Hogger, C. J., Introduction to Logic Programming, Acedemic Press, 1984.
[B5] Loomis, M.E.S., The Database Book, Macmillan, 1987.
[B6] Manna, Z. and Waldinger, R., The Logical Basis for Computer Programming, Volume 1, AddisonWesley, 1985.
[B7] Information processing systems - Concepts and terminology for the conceptual schema and the information base, ISO Technical Report 9007, 1987.
B.7 AcknowledgementsB.7 Acknowledgements
The January 1993 IDEF1X Formalization was written by Robert G. Brown (The Database Design Group) helped by reviews of several drafts. Reviewers included Tom Bruce (Bank of America), Ben Cohen (Logic Works), Dave Brown (McDonell Douglas), Twyla Courtot (Mitre), Chris Dabrowski (NIST), Jack Boudreaux (NIST), Dan Spar (SRA), and Mary Loomis (Versant Object Technology).
135