This action might not be possible to undo. Are you sure you want to continue?

BooksAudiobooksComicsSheet Music### Categories

### Categories

### Categories

Editors' Picks Books

Hand-picked favorites from

our editors

our editors

Editors' Picks Audiobooks

Hand-picked favorites from

our editors

our editors

Editors' Picks Comics

Hand-picked favorites from

our editors

our editors

Editors' Picks Sheet Music

Hand-picked favorites from

our editors

our editors

Top Books

What's trending, bestsellers,

award-winners & more

award-winners & more

Top Audiobooks

What's trending, bestsellers,

award-winners & more

award-winners & more

Top Comics

What's trending, bestsellers,

award-winners & more

award-winners & more

Top Sheet Music

What's trending, bestsellers,

award-winners & more

award-winners & more

Welcome to Scribd! Start your free trial and access books, documents and more.Find out more

RONALD FAGIN IBM Research Laboratory

A new normal form for relational databases, called domain-key normal form (DK/NF), is defined. Also, formal definitions of insertion anomaly and deletion anomaly are presented. It is shown that a schema is in DK/NF if and only if it has no insertion or deletion anomalies. Unlike previously defined normal forms, DK/NF is not defined in terms of traditional dependencies (functional, multivalued, or join). Instead, it is defined in terms of the more primitive concepts of domain and key, along with the general concept of a “constraint.” We also consider how the definitions of traditional normal forms might be modified by taking into consideration, for the first time, the combinatorial consequences of bounded domain sizes. It is shown that after this modification, these traditional normal forms are all implied by DK/NF. In particular, if all domains are infinite, then these traditional normal forms are all implied by DK/NF. Key Words and Phrases: normalization, pendency, join dependency, domain-key plexity CR Categories: 3.73, 4.33, 4.34, 5.21 database design, functional dependency, multivalued denormal form, DK/NF, relational database, anomaly, com-

1. INTRODUCTION Historically, the study of normal forms in a relational database has dealt with two separate issues. The first issue concerns the definition of the normal form in question, call it Q normal form (where Q can be “third” [lo], “Boyce-Codd” [ 111, “fourth” [16], “projection-join” [17], etc.). A relation schema (which, as we shall see, can be thought of as a set of constraints that the instances must obey) is considered to be “good” in some sense if it is in Q normal form. The second issue concerns the normalization process, that is, how one might, if possible, convert a relation schema that is not in Q normal form into a collection of relation schemata, each of which is in Q normal form, and where the new set of schemata is somehow equivalent to the original schema. In this paper, our primary focus is the first issue. We show that the second issue leads to a host of research questions. We define a new normal form for relational databases that is based only on the primitive concepts of domain and key, and we call it domain-key normal form, or DK/NF. Intuitively, a relation schema is in DK/NF if every constraint can be inferred by simply knowing the set of attribute names and their underlying domains, along with the set of keys. We also define insertion and deletion

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. Author’s address: IBM Research Laboratory, San Jose, CA 95193. 0 1981 ACM 0362-5915/81/0900-0387 $00.75

ACM Transactions on Database Systems, Vol. 6, No. 3, September 1981, Pages 387-415.

388

*

Ronald Fagin

anomalies. (Our definition of “anomaly” is different from that of Codd [lo]. Codd’s anomalies have been adequately resolved, that is, prevented, by BoyceCodd normal form [ll].) Intuitively, an insertion anomaly (in our sense) occurs when a seemingly legal insertion of a single tuple into a valid instance of the schema causes the resulting relation to violate one of the constraints of the schema. Here, “seemingly legal” means that every entry of the new tuple is in the appropriate domain, and that the new tuple differs from all previous tuples on every key. Similarly, a deletion anomaly occurs when the deletion of a single tuple from a valid instance of the schema causes a constraint to be violated. We show that a satisfiable relation schema (a schema that has at least one valid instance) is in DK/NF if and only if it has no insertion or deletion anomalies. Unlike previous normal form definitions, our definition of DK/NF is operator free. Our viewpoint is that in the best of all possible worlds, every relation schema in a database would be in DK/NF. (Ideally, there would be no interrelational constraints either. We discuss the issue of interrelational constraints more in Section 4.) The very important practical question of exactly when DK/NF can be obtained (and how to obtain it) is open. It certainly depends on what the allowed transformations are. We discuss this issue more in Section 4. In this paper, we deal mainly with the issue of what DK/NF is, that is, with what it means for a relation schema to be “good.” We consider it to be an important research problem to deal with the other question, of how and when DK/NF is obtainable under various transformations. In Section 2, we present a number of definitions. In Section 3, we show that a satisfiable relation schema is in DK/NF if and only if it has no insertion or deletion anomalies. In Section 4, we present some schemata as examples, and discuss the issue of converting them into DK/NF. We also discuss the general problem of transformation into DK/NF. In Section 5, we summarize some results from [17] about Boyce-Codd normal form, fourth normal form, and projectionjoin normal form. These results expose a strong analogy that holds between them. In Section 6, we consider the effect of modifying these previously defined normal forms to take account of the combinatorial effects of bounded domain sizes. This effect has been largely ignored in the past. Previous research proceeded under the assumption that domain sizes were infinite (or, perhaps, so large that no unexpected combinatorial effects would appear). We show that after this modification, these previously defined normal forms are all implied by DK/NF. It follows, in particular, that if all domains are infinite, then DK/NF implies all of these normal forms. We also consider a formalization of Smith’s “(3,3) normal form” [28] and show that it, too, is implied by DK/NF. In Section 7, we discuss approaches toward weakening DK/NF by allowing other simple constraints besides domain and key constraints. In Section 8, we present our conclusions. 2. DEFINITIONS Let X be a finite set of distinct symbols called attributes (or column names). In the spirit of Armstrong [3] and of Aho, Beeri, and Ulhnan [l] we define an X-tuple (or simply a tuple if X is understood) to be a function with domain X. Thus a tuple is a mapping that associates a value with each attribute in X. We call the value associated with the attribute A the A entry of the tuple. Note that

ACM Transactions on Database Systems, Vol. 6, No. 3, September 1981.

and let I: be either a constraint or a set of constraints. If R is an X-relation. or that (I holds in R. and we have imposed no ordering on the attributes. When we say that Z logically implies u (in the context of X). The functional dependency [9] U + V is a constraint that says that every pair of tuples that agree in the U entries must also agree in the V entries. the projection of R onto Y. the often-made statement that “the order of the columns does not matter” is true. 3. if under this mapping. (1) Functional. Note that we are explicitly assuming the finiteness of relations (that is. The proof of Theorem 3. since “columns” correspond to attributes. We must make this assumption explicit since the concept of logical consequence (defined later) would otherwise be subtly different. 6. {A+B. or that u is a logical consequence of I2 (in the context of X). This corresponds to custom. That is. simply Z I= u.” Later in this section we discuss certain constraints of special interest to us. multivalued. So that we can always speak of constraints in the schema. Note that for us. in that they deal with relations. As a simple example.) We say that relation R obeys constant u. Let U and V be sets of attributes. if the context X is understood. FALSE}. let u be a constraint. An X-constraint (or simply a constraint if X is understood) is a mapping from the collection of all X-relations into {TRUE. We write 2 i=x u. then u is also a constraint of the schema. we are not considering “dynamic constraints. An X-relation (or simply a relation if X is understood) is a finite set of X-tuples. and if u is a constraint such that Z I= u. it is convenient to assume that the set of constraints of the schema is closed under logical consequence.B-+C)kA-+C. Otherwise. Following Cadiou [7].13. then so does u. That is. then by R [ Y]. Let X be a set of attributes. rather than constraints that are logical consequences of those in the schema. September 1981. along with a set of constraints. but not with transitions between relations. for example. we say that u fails in R. No.Normal Form for Relational Databases Based on Domains and Keys * 389 under this definition. and join dependencies. of course. we mean the set of all tuples t[Y]. to practice. then t[Y] denotes the Y-tuple obtained by restricting the mapping to Y. where t is in R. Constraints are often restricted to those that can be specified by sentences written in a given language. and join dependencies). A relation is a valid instance (or simply an instance) of the schema if it has the same attributes as the schema. there is no “counterexample relation” R with X as its set of attributes such that every constraint in Z holds in R. (We make no such restriction. relations are assumed to be finite sets of tuples). not dynamic. Vol. We now define certain dependencies of special interest. ACM Transactions on Database Systems. That is. we mean that whenever Z holds for a relation with attributes X. These include (1) tradi- tional dependencies (functional. and if it obeys every constraint of the schema. relation R takes on the value TRUE. or. If Y is a subset of X. and. constraints are static. and if Y is a subset of X. (2) domain dependencies (or DDs). but such that u fails in R. and (3) key dependencies (or KDs). if Z is the set of constraints of the schema. such as first-order predicate calculus. we define a relation schema to be a set of attributes. multivalued. and if t is an X-tuple. .” such as “an employee’s salary cannot decrease. requires the finiteness assumption.

and still get the same answer.]. . . . and where for each i. we abbreviate functional dependency. ACM Transactions on Database Systems. . and then joining this result with R4. and if W is the set of attributes of R not in U or V. Furthermore.. then the join of the set {RI. u. . joining the result with RB.. we mean the set U U V. MVD. R [X.. We note that Nicolas [24] defined the mutual dependency. For example. . then the multivalued dependency U ++ V holds in R if and only if R is the join of its projections R[ UV] and R[UW]. No. (Note: When we write UV. . that is. . . . * {RI.R4) also equals (Rz * Rs)*(R4 * RI). . and Ullman [l]. . . the result of joining RI and Rz. which is a special case of the join dependency where there are exactly three relations to be joined. Rz. V. .. 3. Following Rissanen [26].. B}. . . . and JD. Thus it is possible to represent each multivalued dependency by a join dependency. . Specifically. Beeri. then the multivalued dependency U++ V holds in R if and only if the join dependency * {UV. . we mean the set {A. are relations. September 1981 . .) onto the attributes of Ri is a tuple in the relation Ri. R. .. wr of R such that wi[Xi] = t[Xi] for each i (15 i 5 r)} . . the join * {RI. . 6. . If R and U. A. where Al. where U and Vare sets of attributes. . the join of the projections R[XJ. R[X. (This characterization of multivalued dependencies appears in [lS] as Theorem 1.) The concept of multivalued dependency (see Fagin [16]) is intimately related to that of join. . Rd} is equal to (((RI * Rz) * Rs) * RJ. w) is in T. . Delobel [E] and Dayal and Bernstein [ 141 also explore properties of join dependencies. . . Vol. . . Xr} holds for the relation R if and only if R contains each tuple t for which there are tuples wl. By the associativity and commutativity of the binary join. R. similarly for ABCD and so on. where each attribute of R is contained in at least one of Xl. . RB. and parenthesize however we wish. From this point on. X. . we can take the binary joins in any order we wish.) It is convenient for us to use a generalized definition of join. zu). where A and B are attributes.} is the set of all tuples (al. . multivalued dependency. . and join dependency by FD. It is straightforward to verify that the old and new definitions of join agree when there are only two relations to be joined. . Xr} if R is the join of its projections R[XJ. . . If RI. . then the join S * T of S and T is the relation consisting of the tuples (u. . For example. that gives the join of an arbitrary collection of relations. Let X1.] of R equals {t: there are tuples wl. . .. where (u. . the projection of the tuple (al. When we write AB. X. if U and V are subsets of attributes of a relation R. due to Aho. Rz.390 * Ronald Fagin If S is a UV-relation and T is a UW-relation (where the attributes in common are the attributes in U). v) is in S and (u.. . of R (not necessarily distinct) such that Wi[Xi] = t[XJ for each i (15 i I r). . are the attributes appearing in at least one ofRl. a. respectively. each be subsets (not necessarily disjoint) of the attributes of relation R. . R. .. . . we say that R obeys the join dependency * {Xl. a. RJ. As noted in [l]. . w. .). this generalized join can be “built up” out of binary joins. UW} holds in R. W are as in the definition above of multivalued dependency. .. It follows that the join dependency * {X1.

. is not a valid instance of R* (i. DELETION ANOMALY. this minimality assumption is not useful at the instance level. DEPT. S) if and only if the SALARY entry of every tuple of R is an integer between 10. Thus a compatible KDs. . .) for KEY( {Al. then KEY(K) holds for R if and only if the FD K+X does. . A. is more convenient for our purposes. and we show that a satisfiable relation schema is in DK/NF if and only if it has no insertion or deletion anomalies. then R obeys IN(A.1. Let R* be a relation schema. If A is one of the attributes of relation R. Relation schema R * has an insertion anomaly if there is a valid instance R of R* and there is a tuple t compatible with R such that R U {t} . 3. DEFINITION OF INSERTION ANOMALY. . where K is a set of attributes. that is. we present a definition of an insertion anomaly and of a deletion anomaly.e. . Thus if R is an X-relation. if X is the set of attributes of relation R. and let R be a valid instance of R*.000. (3) Key dependencies (KDs). The domain dependency IN(A. that no proper subset of K is a key. No. let A be the attribute SALARY. AND DK/NF In this section. For notational convenience.3.S). in which minimality is not assumed. 6. So our definition. We remark that keys are usually defined at the schema level. Let t be an arbitrary tuple not in R. that is. At the schema level. the relation obtained by inserting t into R. and is the set of all 1981. September . We define DK/NF. for K to be a key. not at the instance level. Vol. where A is an attribute and S is a set..000 and 100. tuple is “insertible” into R without violating any DDs or Definition 3.000. A. .000 and 100. says that K is a key. . that no two tuples have the same K entries. However. Thus we wish a relation in which a proper subset of K happens to uniquely identify tuples to be a possible instance of a schema in which K is a key. and (3) t[K] # s[K] for each KD KEY(K) of R* and for each tuple s of R. S) of R *. that is. The key dependency KEY(K). We say that tuple t is compatible with R (in the context of R*) if (1) t has the same attributes as R.}). Definition 3. We assume throughout this paper that every relation schema we consider is already in Codd’s first normal form (lNF). and let S be the set of all integers between 10. and with the following constraints ACM Transactions (where %@&!20 EMP. violates a constraint of R *) . on Database Systems. Let R* be a relation schema with attributes MGR. (2) the A entry of t is in set S for each attribute A and each DD IN(A. we may write KEY(A1. Example 3. We present some schemata as examples. means that the A entry in each tuple must be a member of the set S. 3. that is.2. it is usually assumed that K is minimal. For example.Normal Form for Relational Databases Based on Domains and Keys - 391 (2) Domain dependencies (DDs). each entry of each instance is atomic.

This is a valid instance of the schema R *. September 1981. Let R be the relation in Figure 1. or even in third normal form [lo]. we tacitly close the set of constraints under logical consequence.392 ’ Ronald Fagin Figure 1 1 EMP Hilbert Pythagoras Turing Cauchy 1 DEPT Math Math Computer Science Math Figure 2 MGR Gauss Gauss van Neumann Euler character strings of at most 20 characters): IN(EMP. WSlr920) IN( DEPT. Vol. . 1. J&W) IN@. because of the “transitive dependence” of MGR on EMP via EMP + DEPT and DEPT + MGR. S$%%&‘20) KEY (EMP) DEPT + MGR As we noted earlier. Example 3. 2. The schema is not in Boyce-Codd normal form. &‘&W) IN( C.4. However. . 6. 3. No. that is. which is not a valid instance of the schema. under I=. Euler). Math. it is not clear whether the intent is simply to insert information about a new employee (Cauchy). Let R* be a relation schema with attributes ABC. Thus there is an insertion anomaly. We now show that R* has an insertion anomaly. or whether the intent is also to update the name of the chairman of the math department. One intuitive viewpoint on what is happening here is that by the insertion of the tuple (Cauchy. Let t be the tuple (Cauchy. Tuple t is compatible with relation R. and with the following constraints (where J&‘Ss the set (0. Euler).} of natural numbers): IN(A. . since it violates the FD DEPT + MGX. Math. then we would obtain the relation in Figure 2. J&W) KEY (ABC) A++B ACM Transactions on Database Systems. if we were to insert tuple t. %Xk%’ 20) IN(MGR. . .

In English. that agent a represents product p produced by company c.) ACM Transactions on Database Systems. then we would obtain the relation in Figure 6. We now show that R* has an insertion anomaly. which is not a valid instance of the schema. However. (If we were to add the tuple (Jones. precisely the following: Assume that agent agent a represents represents product product p produced the JD u says a represents product p produced by company c’. which is not a valid instance of the schema. Then agent a represents by company c. Tuple t is compatible with relation R. 3. PC} Let us denote the JD * {AP. Assume that there are only three attributes A.AC. It is shown in [17] that the schema R* is in fourth normal form but not in projection-join normal form. %&@?20) * {AP. if we were to insert tuple t. Tuple t is compatible with relation R. Let t be the tuple (Smith. since it violates the JD u. .Normal Form for Relational Databases Based on Domains and Keys - 393 Figure 3 Figure 4 The schema R* is not in fourth normal form (although it is in Boyce-Codd normal form). bolt. and with the following constraints: IN(A. However.l). Acme). C. This example. Example 3. is a slight modification of an example due to Nicolas [24]. Vol. No. since the MVD A-t+ B holds. Let R be the relation in Figure 5. then we would obtain the relation in Figure 4. and A is not a key. if we were to insert tuple t. 6. P. bolt. 1. since it violates the MVD A ++ B. We now show that R* has an insertion anomaly.5. and that agent a’ p produced by company c. c) means. AC. then it would obey cr. @%&?20) IN(C. which is discussed in [17]. Let R be the relation in Figure 3. Let R* be a relation schema with these attributes.p. intuitively. %9&&?20) IN(P. PC} above by u. It is a valid instance of the schema. where the tuple (a. September 1981. This is a valid instance of the schema R*. Acme) to the relation in Figure 6. Let t be the tuple (0. that product p’ produced by company c.

represented by 0 and 1. September 1981. 1) ) {n: 10. KEY (EMP#) Vt( @[STATUS] = 0) * @[SALARY] {n: n is a six-digit integer} ) (0. 3. However. IN(SALARY. STATUS. except that employees with status 0 have a salary of at most $50.OOO~n~100. Vol. Tuple t is compatible with relation R. there are two statuses. IN(STATUS. However. This schema is in fourth normal form. Let t be the tuple (141421. and is the key.000.394 ’ Ronald Fagin A Jones Jones P bolt screw Figure 5 c Ace Acme Figure 6 STATUS 1 0 1 Figure 7 T t SALARY 73000 37000 46000 STATUS SALARY 73000 37000 46ooo 57000 Figure 8 Example 3. No. Let R be the relation in Figure 7.0. then we would obtain the relation in Figure 8.000. I 50. it has the following insertion anomaly. It is a valid instance of the schema. Let R* be a relation schema with attributes and SALARY. . and with the following constraints: IN(EMP#.57000).6. 6. if we were to insert tuple t. and even in projection-join normal form.000}) EMP#. our constraints say that EMP# is a six-digit integer. which is not a valid instance of the ACM Transactions on Database Systems.000 and $100.000)) Intuitively. and salaries are between $10.

Our intent is not that.. The schema has an insertion anomaly since it is possible to insert a tuple that gives the same person two different sex roles. but not in Smith’s (3. Smith notes that the schema can be split [17] into two schemata. This schema is in projection-join normal form. violates a constraint of R*). .000. The schema SEX-ROLE obeys the FD PERSON + ROLE.e. and that the user should decide which relation to insert a tuple into. In our terminology. Let R* be the same relation schema as in Example 3. our intent is that the user view of the database be two relations. but only one sex. Instead. each of which is in DK/NF. A PERSON is assumed to have two types of ROLES: sex role (male or female) and professional role. It is assumed that a person can have several professions. a schema that is not in DK/NF has been split into two schemata. This example is due to Smith [28]. and tuples about his professional roles go into the second. since it violates the MVD A++ B. Let P-ROLE be a relation schema with attributes PERSON and ROLE. SEX-ROLE and PROF-ROLE. No. the database management system check the tuple and decide which of the two relations it should go into. This is a valid instance of the schema R*.7. while the schema PROF-ROLE does not. 3. A tuple about a person’s sex role goes into the first relation. ACM Transactions on Database Systems. Let R be the relation in Figure 9. that no employee with status 0 can have Example 3. September 1961. Vol. We now define a deletion anomaly. one involving sex roles and one involving professional roles. Let t be the tuple (1. since it violates the constraint a salary greater than $50.8.9. Definition 3. at time of insertion. which is not a valid instance of the schema. If we delete tuple t from relation R. 6.4. 1. an advantage of splitting is that the system’s key maintenance mechanism can then prevent the insertion of two sex roles for one person. then we obtain the relation in Figure 10. without violating any DDs or KDs.3) normal form [28] (which we discuss briefly at the end of Section 6). Example 3.Normal Form for Relational Databases Based on Domains and Keys - 395 Figure 9 ml A B C 1 1 1 0 0 1 0 1 0 Figure 10 schema. Relation schema R* has a deletion anomaly if there is a valid instance R of R* and a tuple t in R such that the relation obtained by removing t from R is not a valid instance of R* (i. We now show that R* has a deletion anomaly. As Smith notes.l).

This schema is in projection-join normal form. in which we might say that each A entry of relation R appears as a B entry of relation S. we mean the constraint that says that every MGRf entry must also be an EMP# entry. . We discuss them more in Section 4. 6. Example 3. IN(MGR#.11. September 1981. This is a valid instance of the schema (we have a null entry corresponding to the manager of employee number 449489 since this employee is the head of the organization and has no manager). {n: n is a six-digit integer} ) By MGR# C EMP#. No.10. and 3t&23t3((tl z t2) A @I z 6) A @2 z t3)) ACM Transactions on Database Systems. then we obtain the relation in Figure 12. KEY (EMP#) MGR# G EMP# {n: n is a six-digit integer} ) EMP# and MGR#. Inclusion dependencies are a special case of extended embedded implicational dependencies (see Fagin [ES]). which is not a valid instance of the schema since it violates the inclusion dependency MGR# c EMP#. However. If we delete tuple t from relation R. Let t be the tuple (732050. More generally. Vol. we now show that it has a deletion anomaly. an inclusion dependency can say that the projection onto a given m columns of relation R are a subset of the projection onto a given m columns of relation S. Probably their greatest importance is as an interrelational constraint. and Codd [ 121. They have also been used by Smith and Smith [29]. Zaniolo [34]. We call such constraints inclusion dependencies.449489). 3.396 - Ronald Fagin Figure 11 Figure 12 Example 3. Let R be the relation in Figure 11. Let R* be a relation schema with attributes and with the following constraints: IN(EMP#. Let R* be a relation with the following constraints: schema with only one attribute A.

by enforcing the DDs and KDs. We remark that if the DD IN(A. where 0 is the empty set. He notes that data definition languages tend to allow the definition of keys. It simply means that the only possible valid instance for the schema is the empty relation (with no tuples). A relation schema is satisfiable if it has at least one valid instance. ACM Transactions on Database Systems. each of Boyce-Codd normal form. Our definitions of DK/NF and of anomaly. That is. Definition 3. more exactly. Another point about the basic nature of the key concept: relations.0). however. and projection-join normal form (all discussed in the next section) depend heavily on the concept of FD. since DDs (“this entry must lie in this set”) and KDs (“this entry is a unique identifier”) are quite fundamental and easily understood.” Bernstein [6. 3. every constraint of the schema is automatically enforced. Although these three traditional dependencies are quite useful from a practical point of view. It is easy to see that this schema has a deletion anomaly. 2801 also discusses the basic nature of the key concept. it does support keys (via “unique indices”). Let R* be a 1NF relation schema. Thus a relation schema is satisfiable if its set of constraints is noncontradictory. and let I’ be the set of DDs and KDs of the schema. rather than a mechanism for supporting more general constraints. along with the general concept of a “constraint. We remark that while System R [5] does not even support general FDs. This is good. the latter two normal forms also depend on the concepts of MVD and JD. He defines an FD to be embodied in a schema if its left-hand side is a key of the schema (and if its right-hand side is an attribute of the schema). If all relation schemata that correspond to stored relations in a database are in DK/NF (and if there are no interrelatonal dependencies). are unordered. the schema determined by a set of attributes along with this set of constraints) is satisfiable. a INF relation schema is in DK/NF if every constraint can be inferred by simply knowing the DDs (domain dependencies) and the KDs (key dependencies). keys provide a uniform mechanism for doing so. every set of KDs and DDs alone (or. Of course. then this does not necessarily mean that the schema is unsatisfiable. Vol.Normal Form for Relational Databases Based on Domains and Keys l 397 The predicate calculus expression simply says that there are at least three distinct tuples. Putting it another way: a 1NF relation schema is in DK/NF if. We now need to define the concept of satisfiability. depend only on the primitive concepts of domains (via DDs) and keys (via KDs). Hence it is desirable to refer to a tuple in a content-addressable manner. fourth normal form. the only schemata of any interest are satisfiable. being sets (of tuples). then the database management system need only have a mechanism for supporting DDs and KDs.12. but not of FDs. He thereby allows one to replace the specification of FDs by the more primitive notion of specification of keys. By constrast. R * is in domain-key normal form (DK/NF) if I’ E u for every constraint u of R*. . In particular. No. holds for a relation schema. it is difficult to justify that they are inherently fundamental (from a mathematical point of view) to the relational model. An example of a nonsatisfiable schema would be one in which one of the constraints is 3t(t # t). p. September 1981. 6. We now define DK/NF.

.” since it discusses the effects of (in particular. S is not a valid instance of the schema R *. It is easy to verify that since R obeys I’. 3. We must show that R’. we gave. a “relation” is a finite set of tuples. which could be called “static. . Ti (lsi%q) TQ = {Sl.} = s ACM Transactions on Database Systems..SZ) = {Sly a. shows that there are two equivalent means for a satisfiable 1NF schema to be in DK/NF. . . . The following theorem.13. But if u is an arbitrary constraint of R *. Since.+1 = {rl. then it has either an insertion or a deletion anomaly. it follows that R’ obeys u. Assume that R containsp distinct tuples rl. so does R’. Let us call this valid instance R. . 6. Let I be the set of DDs and KDs of R*.398 * Ronald Fagin since the empty relation instance. Si} (lSi5p) . September 1981. PROOF. . . . as follows: T-P = {rl. Conversely. each of R and S contain a finite number of tuples.Assume first that R* is a satisfiable 1NF relation schema in DK/NF. A satisfiable 1NF relation schema is in DK/NF if and only if it has no insertion or deletion anomalies. . and that S contains q distinct tuples sl. Vol. it says that there are no insertion or THEOREM3. since R * is in DK/NF. or by deleting a tuple from R. we now show that if R* is a satisfiable 1NF relation schema that is not in DK/NF.. it has a constraint u that is not a logical consequence of I.. as desired. Assume that R * is a satisfiable 1NF relation schema that is not in DK/NF. In particular. We now define p+q+ 1 relations Ti(-psilq). Let R be a valid instance of R*..” The second be called “dynamic. Since R * is satisfiable. Let I’ be the set of DDs and KDs of R *. . . it has a valid instance. ways of defining what it The first is the definition possible definition could insertions and deletions deletion anomalies). . . rp-l) T-i TO Tl 7’2 = {rl. is also a valid instance of R *. Hence since R’ obeys r and since r k u. ri} =0 = {Sl) = {Sl. No. s. . by our definitions. . . . By definition of logical consequence. then l? I= u. (with the appropriate attributes) is always a valid which is not deep. Since R* is not in DK/NF. ... . . r. s. since o fails. To show that R’ is a valid instance of R*. . We shall show that R * has no insertion or deletion anomalies. this means that there exists a “counterexample relation” S for which r holds and a fails. which is obtained from R by either inserting a tuple compatible with R.. we must show that R ’ obeys every constraint u of R*.rP} =R T-. .

all of our examples that are not in DK/NF (except Example 3. since the empty relation obeys every DD and KD. 3.13. Therefore. Vol. = Now the first relation ( TmP R) in the sequence is a valid instance of the schema. then R * has an insertion anomaly. PROOF. which is not in DK/NF. So (1) holds. if Tk+.13. The schema in Example 3. (The reason that t is compatible with Tk is that t and all of the tuples of Tk are in S. it is possible for a satisfiable schema to violate DK/NF without having an insertion anomaly. If k ~0. and the (non-DK/NF) schema in Example 3.14. then one tuple at a time is deleted until the empty relation is obtained. And. but can be decomposed into two DK/NF schemata RT and Rz*. respectively. we know that Tk is a valid instance of the schema and Tk+. obeys (1) but not (2). and the last relation (Tg = S) in the sequence is not a valid instance of the schema.Normal Form for Relational Databases Based on Domains and Keys * 399 Thus the sequence of relations Ti is obtained as follows. rather than on telling how to obtain DK/NF (and on determining when this is possible).11 has a deletion anomaly but no insertion anomaly. 6. We have now proved the “only if” direction of the theorem. MVD. and JD (with the same attributes).3 has an insertion anomaly but no deletion anomaly. Assume first that R* is in DK/NF. We note that sometimes (but not always). This schema. is not. if Tk+l is obtained from Tk by inserting a tuple t. If kt0. (2) holds. The schema in Example 3. Thus in this paper. it follows that R * has no insertion anomaly. September 1981. then one tuple at a time is inserted until the relation S is obtained. since t is compatible with Tk. The “if” direction can be proved by a modification of the proof of the “if” direction of Theorem 3. as we just noted. as introduced by Codd [lo]. MGR] ) is not in DK/NF. for some k (-p f k 5 q . . we do have the following result. KD. and S obeys I’. it might be desirable in practice to have an inter-relational constraint that says ACMTransactions on Database Systems. MGR} .) Thus R * has either an insertion or a deletion anomaly. that is. the primary focus of this paper is on defining DK/NF (and on giving some of its properties).14. and (2) the empty relation (with the appropriate attributes) is a valid instance of the schema. As in the proof of the “only if” direction of Theorem 3.” rather than on how to make it good. 0 Note that the (non-DK/NF) schema in Example 3. No. which was to be shown. where 0 we let the relation R in the proof be the empty relation. Note that the empty relation (with a given set of attributes) obeys every DD. DEPT} and {DEPT.11 is one for which the empty relation is not a valid instance. Although. FD. THEOREM 3. that is. We begin by considering the normalization of the examples in the previous section.3 (with attributes {EMP. In particular. the main issue is what it means for a relation schema to be “good. is obtained from Tk by deleting a tuple. 4. Then R * is in DK/NF if and only if (1) it has no insertion anomaly. DEPT. We now briefly discuss this latter issue. with attributes (EMP.l). Let R * be a 1NF relation schema. TRANSFORMING INTO DK/NF As we noted in the introduction. then R * has a deletion anomaly. This is classic normalization. The sequence begins with the relation R.11) obey (2) but not (1) of Theorem 3.

we obtain three DK/NF schemata. where instances of schema Rf deal with employees of status 0. define the class of legal transformations. and where instances of schema R2* deal with employees of status 1. in theory. that the DEPT entries must be the same. the corresponding instance of the second schema). and the decomposition approach (the use of projections) is not powerful enough to obtain DK/NF. we replace the original schema R * of Example 3. the transformation consists of mapping a relation into a collection of certain of its projections. natural way to convert it into several schemata. That is. has attributes EMP# and SALARY. is just like schema R :. A transformation from one database schema into another is a mapping from the valid instances of the first database schema into the valid instances of the second. except that 50. IN(SALARY. (We sometimes say loosely that the transformation maps one schema into another. then RJDEPT] = &[DEPT]. We now discuss this issue. possibly along with interrelational constraints. Schema R2*. which is not in DK/NF. In order to discuss the possibility or impossibility of converting a schema into DK/NF. KEY (EMP#) Note that a STATUS attribute is no longer necessary or desirable since all STATUS values would be identically 0. No. {n: n is a six-digit integer} ) {n: 10. we obtain two DK/NF schemata.4 is not in DK/NF. The schema in Example 3. respectively. and the following constraints: IN(EMP#.000~n~50. September 1981. and PC.6 by two schemata R T and R 2*. Define a database schema to be a collection of relation schemata (each of which is a set of attributes and a set of constraints). One natural demand on a transformation from one schema into another is that the transformation be l-l. By decomposing the schema into two schemata. respectively. since the fact that f is l-l says precisely ACM Transactions on Database Systems. However.7. into two schemata. The schema in Example 3.3). in Example 3.10 is not in DK/NF.11. which deals with status 0 employees. Thus R ?. and there is no obvious.000}) . if D is a valid instance of the original schema. as discussed in Example 3. Similarly.We shall return to this example later.) In classic decomposition (as would take place. The schema in Example 3.6 is not in DK/NF. The same comment applies to the schema of Example 3.000 is replaced by 100. the split operator (as discussed in [17] and in Example 3.5 is not in DK/NF. which we return to later in this section.e. of course. However. For. 6. then it is possible. each of which is in DK/NF. 3. for example. the split operator converts the schema of Example 3. The schema of Example 3. Vol. with attributes AB and AC. This issue is a subtle one. AC.7. with attributes AP. by decomposing the schema into three schemata. respectively.000. we must.7) does do the job. each of which is in DK/NF.. and if f (D) is the transformed version (i.400 * Ronald Fagin that if RI and Rz are the instances at a given time of RT and RI. which deals with status 1 employees. that is. to reconstruct D from f(D).

Thus one of the reasons that Codd gives for h normalizing the {EMP.DEPT} relation to be different from the DEPT entries in the {DEPT. No.e. its only flaw is that the transformation is not quite onto. Thus to every relation schema in the source database schema. Even if we were to demand that the transformation map be both l-l and onto. Although ACM Transactions on Database Systems. further. In this case. The whole point of Rissanen’s paper on independent components of relations [25] is to consider the situation in which the transformation is not only l-l.MGR} relation in which the DEPT entries are different. MGR} schema is to be able to maintain manager information for a department with no employees. We simply let the transformation f be the identity map (in which f(D) = D). Classical decomposition (using projections) has this l-l property. we describe a transformation that “almost” works. in the presence of the appropriate FDs. since it misses one valid instance of the target schema (the empty instance). INCA. the transformation can be made onto. Interestingly enough. MVDs. Intuitively. DEPT} SC ema and a {DEPT. 6. when a transformation map is not onto. September 1981. or JDs. MGR} SC ema of Example 3. but with all constraints removed. There are exactly two attributes A and B in the target schema. there is still always a trivial transformation of every satisfiable database schema into a single DK/NF relation schema. but also onto.DEPT. . KU) IN(B. This last observation gives us a clue to a trivial l-l transformation from an arbitrary database schema into a database schema in which every relation schema is in DK/NF.. there are “less constraints” (i. The target schema has precisely the following constraints..e.S) KEY(A) an instance D to the one-tuple relation with 0 as the DK/NF has been attained. it is clear that nothing at all has been gained by this transformation. “more possible database instances”).Normal Form for Relational Databases Based on Domains and Keys l 401 that f(D) uniquely determines D. Vol. Thus Codd wants it to be possible for the DEPT entries in the (EMP. The transformation f maps A entry and with D as the B entry. For ease in exposition. the transformation map is not onto. the original) database schema. one of Codd’s original motivations for normalization is in direct contradiction to the “onto” property. the target database schema has no interrelational constraints). 3.3 (with the FD h DEPT + MGR) into an {EMP.DEPT} relation and a {DEPT. there corresponds a relation schema in the target database schema with exactly the same attributes. This is what corresponds in the database literature to a “lossless” transformation. and in which there are no inter-relational constraints. Furthermore. and we let the “target” database schema (the result of the transformation) be the same as the “source” (i. MGR} relation. Let S be the set of all valid database instances of the source database schema. MGR} relation has as a pair of projections an {EMP. since no {EMP. We remark that by a trivial finite modification of the transformation. All the difficulties of maintaining the constraints of the source schema have simply been converted into difficulties in maintaining a very complex domain dependency. but with no constraints (and. DEPT. 161. or a transformation “without loss of information” [l.

both as a user view and as a way for data to be actually stored. that is also natural. deletion. We first form one relation schema R* that contains ah of the attributes in the source relation schema. and thereby to enforce the constraint by checking the indices whenever there is an insertion.10) as interrelational constraints. R ?. is equivalent to two inclusion dependencies (R[A] c S[B] and S[B] c R[A]).1. The interrelational constraints say that each relation is a projection of the instance R of R* (this can be said with a collection of inclusion dependencies). The first issue is: what is a “DK/NF database schema”? We have so far only defined a DK/NF relation schema. and with the single constraint KEY(X). in that inclusion dependencies are very important constraints that a database management system should have the capability of enforcing anyway. This schema is not in DK/NF (it is not even in Boyce-Codd normal form). A less strict demand. that the A entries of relation R must always be a subset (not necessarily proper) of the B entries of relation S. for example. 6.. Vol.” which says. September 1981. We certainly insist that a DK/NF database schema contain only DK/NF relation schemata. What about interrelational constraints? We might insist that a DK/NF database schema contain no inter-relational constraints. that the set of A entries of relation R must equal the set of B entries of relation S. . for example. This process can be best understood by an example. in which the only interrelational constraints are inclusion dependencies. but with no constraints. it is possible to keep an index on both R[A] and S[B] (possibly in the same physical index. In order to adequately deal with the theoretical issues involved in the problem of when it is desirable and how it is possible to convert a database schema into a “DK/NF database schema. One efficient mechanism for enforcing inclusion dependencies in a double index. and no constraints. We transform this schema into a new database schema with three relation schemata R T. and that the constraints are the FDs AB + C and C + A. Schema R *3 contains attributes AC and the single constraint KEY(C). The interrelational constraints are R2 G RI[ABC] R2 Rl[ABC] c Rs c RI[AC] Rl[AC] c RS ACM Transactions on Database Systems. and R *3. For each FD X+ Y of the source schema. 3. Example 4. as in ADABAS [30]). Schema R T contains alI four attributes ABCD. Assume that the source relation schema contains exactly four attributes ABCD. Allowing inclusion dependencies as interrelational constraints is in the spirit of our definition of a DK/NF relation schema. Note that an “equality dependency. Schema R 1 contains attributes ABC and the single constraint KEYlAB). we also form a new relation schema with attributes XY. or update affecting these entries. No.” a number of problems must be addressed. is to allow only inclusion dependencies (see Example 3.402 * Ronald Fagin the target schema is clearly unacceptable in every way. It is interesting to note that any relation schema in which the only constraints are FDs can always be transformed in a simple manner into a DK/NF database schema. Thus to maintain the inclusion dependency which says.

it is possible to completely specify any finite domain (e. Furthermore. MVDs. In IBM’s GIS [19]. there are known decision procedures [23] for determining when traditional dependencies (FDs. An important practical issue is: how complicated a domain dependency can we expect (or demand) that the relational database management system be able to enforce? System R [5] and ADABAS [30] currently have the capability of enforcing domain constraints such as “each A entry of relation R must be exactly n bytes. Another important practical issue that may arise relates to the complexity of the transformation fi (This would be an issue if the target schema is how the data are to be stored. The definitions that we give are not the same as the original definitions. we present definitions of some previously defined normal forms that are based on the projection and join operators: Boyce-Codd normal form [ 111. AND PJ/NF In this section. if the database instance D’ is obtained from D by a simple operation (such as an insertion or a deletion of a single tuple). see [4]. This technique is a special case of a more general approach by Armstrong and Delobel[4]. Thus every MVD is the result of keys. and projection-join normal form [ 171. respectively. it is not even decidable as to whether a sentence of first-order logic is a tautology (this is Church’s theorem [a]). A 1NF relation schema R * is in BCNF if A I= u for each FD u of R *. We shall come back to the issue of what interrelational dependencies to allow in Section 7. screw} ). 5. 6. We shall not pursue this matter further in this paper.2. but n must be at most 6. Query-by-example [21] and INGRES [32] also have this capability. September 1981. BCNF. For example. Vol. We hereafter refer to these latter three normal forms as BCNF. in which they project onto saturated sets and antiroots. Possibly. A 1NF relation schema R * is in 4NF if A I= u for each MVD u of R *. and PJ/NF. since we immediately run into undecidability results.Normal Form for Relational Databases Based on Domains and Keys * 403 The first two interrelational constraints say that Rz is the projection of RI onto ABC. ACM Transactions on Database Systems. No. fourth normal form [ 161. but. as shown in Fagin [17].” for arbitrary fixed n. and JDs) are consequences of other traditional dependencies. and the second two interrelational constraints say that RS is the projection of RI onto AC. bolt. Definition 5. are equivalent to the original definitions.1. Definition 5.. and the source schema is how the data are to be viewed. 4NF.” Clearly. it is possible to say that every entry in column B of relation R must be a member of the finite domain {nail. Thus every FD is the result of keys. We close this section with a warning. “easy” might mean “constant time. where A is the set of KDs of R *. 4NF. the time complexity of f and its inverse should be linear. One approach to circumventing undecidability is to restrict the class of constraints. . It is easy to verify that there is a l-l correspondence between the source and the target database instances. as well as the number of page faults. For details.g. In the general case. For example. then it should be easy to convert f(D) into f(D’). here. it is not useful to think in terms of mechanical procedures for conversion to DK/NF. 3. this is a fertile area for research. where A is the set of KDs of R *.) The complexity measure might involve computation time and memory requirements.

Namely. none of these earlier normal forms considered the role of domains. every KD implied by the constraints of the schema is in A.3. in the presence of KDs and DDs. In what follows. ACM Transactions on Database Systems. while r is the set of KDs and DDs). The modification consists of taking into account the effect of DDs. for the first time. and PJ/NF. The following theorem is proved in [17]. where 0 is the set of DDs of the schema. September 1981. . Let A be a set of KDs. 4NF and BCNF). S) E 0}. THEOREM PJ/NF . This effect has been neglected in the past. Let Q be a set of constraints. and PJ/NF. of BCNF. 0 a set of DDs. 3. of course. The next two lemmas give conditions under which there is no difference. Thus every JD is the result of keys. AND PJ/NF In this section.4. then. LEMMA6.) We usually write simply dam(A) for damn(A). the set of KDs of the schema. This is because. That is. they deal with the issue of whether or not A I= u. Vol. the tableaux technique of Aho. provided no domain is too small. the cardinality of dam(A) . In particular. Let a be an FD or MVD. then DK/NF implies PJ/NF (and. Kanellakis [22] has recently shown another effect of bounded domain sizes. he proves that the property of determining whether or not a lossless join property holds. Assume that Idom(A)lr2f or each attribute A. 5. 4NF. In fact. where A is the set of KDs of R *. Unlike DK/NF. 4NF. 4NF’. and the constructions of Armstrong [3] implicitly assume that it is always possible to introduce an arbitrary number of new entries of new tuples. 6. The purpose of the next section is to remedy this neglect. There is a striking analogy between the definitions. for certain constraints u. and PJ/NF’. the combinatorial effects of a bounded domain size are being considered. rather than whether or not I’ h u (recall that A is the set of KDs of a schema. No.1. We show that if all domains are infinite. 4NF. S)}. Thus domn(A) is the collection of all possible values that the A entry of a tuple of a relation can assume. then domQ(A) = II {S : IN(A. if the relation obeys 52. For example. (Similarly. Beeri. define doma = n {S : Sz t= IN(A. and show that it is also implied by DK/NF.4NF . For each attribute A. and Ullman [l]. and I7 = A U 8. we shall often be concerned with 1dam(A) I. and PJ/NF in Section 4 ignore the effects of DDs. the set of constraints of a schema are assumed to be closed under logical consequence. as we stated in the introduction.If P is the set of constraints of a relation schema. We also show that DK/NF j PJ/NF’ e 4NF’ .404 * Ronald Fagin Definition 5. 6. every DD implied by the constraints of the schema is in 0. We also give a formalization of Smith’s (3. respectively.BCNF. A 1NF relation schema R* is in PJ/NF if A I= u for each JD u of R *.BCNF’. Then A I= 0 if and only if l? I= u.3) normal form. is NP-complete. as presented above. It is proved that the original and modified versions are equivalent. we define modified versions of BCNF. MODIFIED VERSIONS OF BCNF. which we call BCNF’. One view of this section is that. this observation was one of the author’s motivations in defining DK/NF. 4NF. The definitions of BCNF.

My) ABCDE. To show that u holds in R. September (6. However.3. &X7) KEY(BC) Let u be the FD 0 + A. we must show that R contains each tuple t for which there are tuples wl. wz./Gzz’F) IN(D. 3.2. BCE. it follows from the membership algorithm in [IT] (or from the “chase” algorithm in [23]) that it is false that A I= u. We now show. Note that 1dam(A) I= 1. BCE. ACDE}. Example 6. let 0 be the set consisting of the three DDs above. (If the reader is not comfortable with FDs in which the left-hand side is the empty set. ACDE}. and our example will work just as well. it is helpful to consider two examples.13) IN(B. Let I be the set of all constraints listed above. We must show that u necessarily holds in R. Thus Lemma 6. We make use of this example again later. We shall show that I’ l= u. Let R be a relation in which I’ holds. Recall that u is * (BCD. and let I = A U 8. Vol.1. (11) ABC. where the left-hand side is the empty set. while it is false that A I= u. We make use of this example again later. Example 6. My) IN(C.Normal Form for Relational Databases Based on Domains and Keys - 405 Before we prove Lemma 6.) Let A be the singleton set {KEY(BC)}. 6. and let A be the set containing only the two KDs above. and with KEY(AB) KEY(CDE) Let u be the JD *(BCD. ACM Transactions . The reader can easily verify from the formal definition of functional dependency that the special functional dependency 0 + A.w4 of R (not necessarily distinct) such that w. says precisely that the A entry of every tuple is the same.2) 1981. then he can let u be the FD B + A. ~13. and with the IN(B. No. as promised. Then u is a constraint of the schema since u is a logical consequence of the first DD above. Let R* be a relation schema with attributes the following constraints: INA.1 is false if we drop the assumption that 1dam(A) ) z 2. that l? l= u. Then r I= a.1) (6. Thus Lemma 6. {0. where 0 is the empty set.[BCD] wz[BCE] = t[BCD] = t[BCE] on Database Systems. BDE. BDE. Let R * be a relation schema with attributes following constraints: INtA.1 would be false if we were to allow u to be a JD. .

it is easy to see R contains a 2-tuple subrelation for which u fails. w4 = w. . This is a contradiction. such that the relation S. For each attribute A. which contains precisely these two tuples. Thus wi [AB] = w2[AB]. also A holds in T and u fails in T. we know that both w[ CDE] and w4 [ CDE] equal t[CDE]. since A c r. and (6. (6. One’s first thought might be that the combinatorial curiosities exhibited by the schema in Example 6. Assume that w[A] = wz[A]. w3. since A holds in S. Now. If sIrA] # s:![A]. Hence w[CDE] = wd[ CDE]. (6. WZ. we know that there is a counterexample relation R for which A holds but u fails. then let tl[A] = . obeys the set A of KDs. but that it is false that A E u. and t2.4). it follows that w[ABCDE] = t[ABCDE]. Hence w[A] = t[A]. this is possible since 1dam(A) ) 2 2. Furthermore. Since AB is a key. where a is an arbitrary member of dam(A). the “2-tuple subrelation lemma. then A I= u. Now w1 [A]. w2. For example. 3) ) taken together logically imply that each instance may have no more than four tuples. 1. this is not what “goes wrong” in this case. that is.4). (0. Since it is false that A I= u.2). Clearly S. 0 It is certainly possible for a set I? of DDs and KDs to logically imply a fixed bound on the number of tuples. Lemma 91. ACM Transactions on Database Systems. For. September 1981. and that w[BCE] = t[BCE] by (6.” In particular.2). we must show that t is also in R. wz[A]. there are two tuples s1 and s2 of R. Let T be the relation containing precisely t1 and k.3 were caused by such a phenomenon.406 * Ronald Fagin wa[BDE] = t[BDE] wd[ACDE] = t[ACDE]. Hence r holds in T. then let tl[A] = a. Denote the common value of WI and wp by w. 3. where a and b are distinct members of dam(A). Thus t is indeed in R.. That is. It follows that w[BCDE] = t[BCDE]. KEY(A) and IN(A. tl[A] = &[A]) if and only if the two tuples of S agree on attribute A.4) Thus assume that t.3). then I’ != u.1).“) We define two new tuples t. But w4[A] = t[A] by (6.1. being a subrelation of R.2). attribute by attribute. Now wl[B] = wa[B] since both equal t[B]. an instance of the schema in Example 6. the proof is almost identical in the other two cases. we showed that I’ holds in T and u fails in T. by (6. No. 6. we have defined T so that the two tuples of T agree on attribute A (i.e. which was to be shown. 2. This concludes the example. as follows. Let A be an arbitrary attribute. since ( dam(A) ] = 2. We know that w[BCD] = t[BCD] by (6. wl. Since u is either an FD or MVD.1).3) (6. Thus S and T are “isomorphic. Since CDE is a key. If A I= u.4). If sl[A] = s2[A]. and w3[A] cannot all be distinct.&[A] = a. w4 are as in (6. does not obey u.1) and (6. w4[ACDE] = t[ACDE] by (6. However. w3. w4 in R. we have constructed T so that all of the DDs in 0 hold in T. (6. Since we also already showed that w[BCDE] = t[BCDE]. Assume that r i= u.and u fails in S. PROOF OF LEMMA 6. w = t. But. By these last two facts. and let &[A] = b. (We note that a strong version of the result that says that there is a 2-tuple counterexample subrelation appears in [27. with WI. By assumption.3 may have an arbitrarily large number of tuples. Thus S is a 2-tuple counterexample relation for which A holds but u fails. Vol. So we need only show that if r I= u. We will derive a contradiction. r I= u. it follows that w1 = cop.

We now present modified versions of BCNF. Let R * be a relation schema in which dam(A) is infinite for ACM Transactions . A 1NF relation schema R * is in PJ/NF’ of R *.4) gives a condition. The proof of Lemma 6. A 1NF relation schema R * is in BCNF’ if F b u for each FD u of R *. except that unlike them. of a key with no proper subset that is a key. Then R * is in PJINF if and only if it is in PJ/NF’. If u is an arbitrary JD.4 (and in the proof in Example 6. (C(n. [n/2]) for each prime attribute A. Definition 6. Let o be a JD.1. September 1981. q Definition 6. analogous to Lemma 6. PROOF.“) Finally. m) is sometimes read as “n choose m. Vol.6. 0 if I? I= u for each JD u Definition 6. Let R * be a relation schema in which I dam(A) I E 2 for each nonprime attribute A. Then R * is in BCNF if and only if it is in BCNF’. then A l= u if and only if I’ k u. Then A t= u if and only if I’ I= cr.Normal Form for Relational Databases Based on Domains and Keys - 407 Example 6. [n/2]) in Lemma 6.5/ (74. for the JD case. 4NF. THEOREM6.1. THEOREM6.1.Immediate from the definitions and from Lemma 6. where x is a real number. assume that there are five attributes. Assume that 1dam(A) 1~ 2 for each nonprime attribute A. As an example of Lemma 6. where F is the set of DDs and KDs of R *. we need a few more definitions. We note also that by Stirling’s formula. where I? is the set of DDs and KDs of R *. Before we can state Lemma 6. and that I dam(A) I 2 10 for each prime attribute A.8. and that 1dam(A) 1 L C(n. COROLLARY 6.4.4 appears in the appendix. 0 a set of DDs.5. and I? = A U 0.1 fails if we allow u to be a JD. Then R * is in 4NF if and only if it is in 4NF’.5. m).3 shows us that Lemma 6. in which the combinatorial effect of the DDs are explicitly taken into account.7. by [x]. Let R * be a relation schema in which ( dam(A) I 2 2 for each attribute A. 6.3) is in the spirit of the “chase” technique of Maier. we say that an attribute is prime if it is a member of a minimal key. PROOF.11.4 is asymptotic to 2n+0.4.4. Let A be a set of KDs. Then R * is in PJ/NF and from Lemma 6. and Sagiv [23]. LEMMA 6. The next lemma (Lemma 6. we must take into consideration the effects of bounded domains. where I’ is the set of DDs and KDs of R *. [n/2]) f or each prime attribute A.Immediate from the definitions each attribute A. PROOF. that is. Let n be the number of attributes. 3. Let R * be a relation schema in which 1dam(A) I 2 2 for each attribute A. the term C(n. Mendelzon. 0 if and only if it is in PJ/NF’. and in which I dam(A) I 2 C(n. and PJ/NF. THEOREM6. on Database Systems. By C(n. Following Codd [lo]. taken m at a time. we mean the number of combinations of n objects. No. we mean the greatest integer not exceeding x.10.Immediate from the definitions and from Lemma 6.9.4. A 1NF relation schema R * is in 4NF’ if F I= u for each MVD u of R *. Our technique in the proof of Lemma 6. that 1dam(A) 1 2 2 f or each nonprime attribute A.

it is immediate from the definitions that DK/NF q PJ/NF’ since every JD is a constraint. If R* is in DK/NF.Since R * is in DK/NF. For each attribute C in U U V. in which I dam(A) I 2 2 for each attribute A. where a and b are distinct members of dom( C). Thus sl [A] # ACM Transactions on Database Systems. The other implications (PJ/NF * 4NF * BCNF) hold in general.12.3. The fact that PJ/NF’ =+ 4NF’ follows from the fact. Let R * be a relation schema in which dam(A) is infinite for each attribute A. Cl Example 6. Let V be the set of those attributes C such that I dam(C) I = 1.3 shows that it is not sufficient to replace the assumptions on 1dam(A) ] in the statement of Theorem 6. is in PJ/NF’ but not in PJ/NF. Example 6. we shall derive a contradiction. Cl COROLLARY 6. Thus if all domains are infinite. as are 4NF and 4NF’. where a is an arbitrary member of dam(C).BCNF.2 shows that the assumption 1dam(A) ] > 2 is necessary in Theorems 6.10. Let P be the set of DDs and KDs of R*. So.11 that R * is in PJ/NF. No.6 and 6. by Theorems 6.As before. Let R * be a relation schema in 4NF’. If ] dam(C) ) = 0 for some attribute C. Another lesson we should learn from these results is that a reasonable restriction to place on a DK/NF schema is that ] dam(A) I z 2.408 * Ronald Fagin PROOF.13. September 1981. 3. we shall show that it is in BCNF’. We can assume without loss of generality that the right-hand side of the FD u is a single attribute. or else we would have ] dam(A) I = 1 for some attribute A (in which case there is no reason to include A as an attribute).2 is in BCNF’ and 4NF’ but not in BCNF or 4NF. or else I’ I= U -+ A would hold.8 since the schema in Example 6.6 and 6. we can assume that 1dam(C) ( I 1. it follows immediately from the definitions that R * is in PJ/NF’ (because every JD is a constraint). it follows that BCNF and BCNF’ are the same for all reasonable schemata. However.10 by simply “ 1dam(A) 1 L 2 for each attribute A. Since R * is not in BCNF’. Our viewpoint on PJ/NF versus PJ/NF’ is that PJ/NF’ is fundamentally more natural than PJ/NF since the effects of bounded domain sizes are quite real and should be taken into account. We note that it is not hard to modify Example 6. The proof that 4NF’ * BCNF’ requires some work. PROOF. for each integer K.4. PROOF.” since the schema in Example 6.Immediate from Theorem 6. For each remaining attribute C. there is an FD (I of the schema such that P does not logically imply cr. then R * is in BCNF’. then DK/NF =+ PJ/NF * 4NF .8. that each MVD can be represented by a JD. a schema in which I dam(A) ] 2 K for each attribute A. A relation schema that violates the assumption of Theorems 6. It then follows from Corollary 6. DK/NF =+ PJ/NF’ * 4NF’ + BCNF’.10 and still be reasonable.8 would certainly be unreasonable. Let us write u as U+ A. and which is in PJ/NF’ but not in PJ/NF. For. noted in Section 2.3 to obtain. then it is in PJ/NF. we set s1 [C] = a[C] = a. we set s1[C] = a and s2[ C] = b. Thus for each attribute C.6 and 6. Note that A is not in U U V. THEOREM6. we would either have ] dam(A) I = 0 for some attribute A (in which case the schema would have no valid instance that is nonempty). Vol. a schema could certainly violate the assumptions of Theorem 6. Assume not. We define two tuples s1 and s2 as follows. . by Theorem 5. where A is a single attribute. 6.

Then sl[B] # sz[B].7) are all logical consequences of r. But then.3)NF if those “embedded” FDs that hold in a subrelation obtained by splitting (in exactly the same sense as in Example 3.[U] = sz[Ul (6. if a schema is in DK/NF. since KEY( U) would be in I’. we would have K c U U V. We might define new classes of normal forms (for relation schemata and for database schemata) by selecting a certain class g of constraints (including ACM Transactions on Database Systems. Thus it is reasonable to assume that a database management system should have the power to enforce our KDs and at least a limited version of our DDs (such as those DDs that state that the domain of a given attribute is. We already showed that U ++ A fails in S. It is not hard to see that (6. (3. distinct from A. which is not in U U V.3) normal form ((3. say. In fact. and 0 since R * is in 4NF’. which would imply that KEY(U) is in I’. r holds in S.3)NF is to say that a 1NF schema is in (3. which would imply that r i= u. strings of six characters). Since A and B are distinct attributes not in U. by construction. S is a counterexample relation that shows that r I= U ++ A is false. then there is no extra overhead in supporting the constraints of a DK/NF schema. Then. A PARADIGM FOR NORMAL FORMS Earlier. by definition of s1 and ~2. 3. 7.6) for arbitrary II/. We close this section with some remarks on Smith’s (3. U ++ A is a constraint of R * (since U + A is). Then sl [K] # sg[K]. a contradiction. So.[B] f s&B].Normal Form for Relational Databases Based on Domains and Keys * 409 s2[A]. every DD in I? holds in S. That is. So. . But on the other hand. One formalization of the intent of (3. exists. it follows that r I= U -++ A. Assume not. Let KEY(K) be an arbitrary KD in I’. and V.” It follows from what we have said that DK/NF * (3. we discussed the fundamental nature of domains and keys for relational databases.6) says that “the relation consisting of those tuples t that satisfy Ii/(t) obeys the FD U + V. a contradiction. That is. Also. Let S be a 2-tuple relation containing precisely s1 and SZ.5) that the MVD U ++ A fails in S. since (6.5) s1[Al Z s&II s. 6. Vol.3)NF.We know that s. We now show that there is some other attribute B. since U + A and U + V are constraints in R *. it would follow that KEY( U) is a constraint of R *. it is very good if all of the constraints of a schema can be enforced by simply enforcing domains and keys (which is precisely what DK/NF is all about). it follows easily from (6. since U -4 A is an MVD of R *.3)NF means that r logically implies each of the schema’s constraints that are of the form VtIVt2(wI) A $02) A h[U] = tz[ul)) * ((t1Wl = t2lm) (6. it would follow that r I= U + A. Since domains and keys are already being supported for other reasons. as described above. or else. Thus we have shown that B. Hence every KD in r holds in S.6) is simply another constraint. This is a contradiction. the database management system may well not have the capability for supporting constraints other than those that are automatically enforced by enforcing domains and keys. No.3)NF) [28]. So. U. September 1981.

3. these cardinality constraints might be easily implemented by associating a tuple counter with each relation. Depending on the database management system. No.” where a side computation can be done before an insertion or an update. without referencing any other tuples. It is easy to see that if % c ‘&. the last constraint (which says that employees with status 0 have a salary of at most $50. By this means. if % is the class of all DDs and KDs. where $(t) is quantifier free in some language. A schema is in %? normal form if the set of constraints of the schema is precisely the set of logical consequences of some set of constraints. Each of these modified normal forms is implied by DK/NF. Vol. These are constraints of the form V&(t). IMS can enforce arbitrary single-tuple dependencies.” We have also presented a formal definition of an insertion anomaly and a deletion anomaly. If the database management system has the capability of enforcing inclusion dependencies as interrelational constraints. each of which is in the class %‘. along with the general concept of a “constraint. but the computation can be arbitrarily complex. Unlike traditional complexity theory. If we allow G(t) to be an arbitrary computable predicate. Thus whatever the language of 4(t) is. +(t) should be computable.6. as we have shown. the side computation cannot look at any other tuples other than the one to be inserted.000) is an example of a single-tuple dependency. then computable domain dependencies are special cases of single-tuple dependencies.10). Another natural class of simple constraints are single-tuple dependencies. Another example of a constraint that might be easy to enforce is a cardinality constraint on the number of tuples in a relation. In Example 3.. “there is at least one tuple”). 8. then 5%normal form implies %$normal form.” we need a complexity theory for database constraints. which is based only on the primitive concepts of domain and key.” to take into consideration the combinatorial consequences of bounded domain sizes.e. INGRES [32] and MAGNUM [33] are designed to enforce singletuple dependencies. then % normal form is the same as DK/NF. but rather the number of page faults. For example.” To properly define “easy to enforce. We have shown that a satisfiable 1NF relation schema is in DK/NF if and only if it has no insertion or deletion anomalies. IMS [20] supports “exits.410 * Ronald Fagin interrelational constraints) that are somehow primitive. 6.” A special case that one might want is the constraint that says “the relation is not empty” (i. ACM Transactions on Database Systems. the primary cost is not the computation time or memory. or “easy to enforce. CONCLUSIONS We have defined a new normal form. Single-tuple dependencies involve only the tuple to be inserted and no other tuples. . called domain-key normal form (DK/NF).” or “there are at most 117 tuples. We have shown how traditional normal forms might be modified “in the spirit of DK/NF. September 1981. the counter is updated whenever the relation is. is that the original normal form and its modified counterpart are equivalent provided no domain size is too small. The effect of the modifications. then it is reasonable to consider allowing such dependencies as constraints within ‘a relation schema (as in the schema of Example 3. such as “there are at least 3 tuples.

) “Simple” should somehow mean “fast for a database management system to perform. where no two Xi are the same. (The concept of a simple transformation is needed for dealing with the question of converting a database schema into a DK/NF database schema. We begin by proving the following lemma. and that 1dam(A) I > r f or each prime attribute A. Let u be a JD with r components. and r = L\ U 0. September 1981. we feel that in the database design process. Let b be a set of KDs. 0 a set of DDs. such as inclusion dependencies). Since it is false that A b u.. All constraints (including inter-relational constraints) should be “simple. In practice. it has at least one valid instance). this goal is unlikely to be attained. A good research problem might be to define reasonable ways in which we can “set our sights lower”. We have discussed paradigms for normal forms (both for relation schemata and for database schemata). easily enforceable.e. Assume that 1dam(A) 12 2 for each nonprime attribute A. but DK/NF could be defined without this assumption).4. If then A I= u. Our viewpoint on DK/NF is that in the best of all possible worlds. then r I= u since A c I’. Lemma 6.” that is. Vol. and that 1dam(A) 1 1 C(n. XT}. the designer should strive to obtain DK/NF.Normal Form for Relational Databases Based on Domains and Keys * 411 Our results indicate that it is reasonable to insist that a relation schema obey other properties besides being in DK/NF.” A good example of a simple and important interrelational constraint is the inclusion dependency. Let n be the number of attributes. but that it is false that A != u.4. IfaisaJD*(X1. So. 6.. 3. Let o be a JD. APPENDIX The purpose of this appendix is to prove Lemma 6. We consider it an important research problem to find other natural restrictions that should be imposed. Assume that r l= u. Assume that 1dam(A) I > 2 for each nonprime attribute A. Then A F u if and only if r I= u. No. 0 a set of DDs. we need only show that if I? != u.. We shall derive a contradiction. These restrictions include: (1) The schema is in 1NF (we have discussed nothing but 1NF schemata in this paper. Let A be a set of KDs. Then A k a if and only if F t= u. A I= U. (3) 1dam(A) 1z 2 for each attribute A. to clarify what a “simple” constraint is and what a “simple” transformation from one database schema into another is. and r = A U 0. or perhaps only easily enforceable inter-relational constraints. (4) All domain constraints are “simple. then we say that u has r components. one possibility is to consider weaker normal forms than DK/NF.” Such a complexity notion might lead to the isolation of a set of primitive operations that a database management system can and should support easily. which is as follows. PROOF. (2) The schema is satisfiable (i. LEMMAAl. From a purely practical point of view. . A “database complexity theory” is needed. every relation schema in a database would be in DK/NF (and there would be no interrelational constraints.. . we know that there is a counterexample ACM Transactions on Database Systems. [n/2]) f or each prime attribute A.

Vol. since si[A] # u[A] and sj[A] = u[A]. . 1 5 j 5 r. we know that tj[A] = u[A]. We know that there is some i such that a[A] = u[A] (we simply find i such that A E X. it follows from the definition of ti[A] and of tj[A] that ti[A] and tj[A] are unequal. .. . 3. Let T be a relation containing precisely the tuples tl. But this is easily verified from our definitions. the set of DDs. . Then u fails in S.} . Let K’ be a minimal subset of K such that KEY(K’) is in A. since. ACM Transactions on Database Systems. Assume first that A is prime. Ronald Fagin relation R for which A holds and u fails. For each i (1 I i 5 r). . it follows from the definition of ti[A] and of tj[A] that si[A] = sj [A]. whether A is prime or nonprime. By definition of u. Recall that u is a tuple not in S such that si[Xi] = u[Xi]. . Let A be an arbitrary attribute. . it follows from our construction that for each i. KEIY(K’) holds in T. tr.. Since K’ contains only prime attributes. 15 i d r. attribute by attribute. Thus (Al) is proved in both cases. we have ti[K’] = tj[K’] if and only if si[K’] = si[K’]. ti[A] = b if s. . . A is a nonprime attribute. SOsi[A] = u[A]). s. We now define new tuples tl. we shall derive a contradiction. So. Let a and b be two distinct members of dam(A). then ti[A] = u[A] by definition of u. there are tuples sl. Case 1. of R. . then ti[A] = tj [A]. Let KEY(K) be an arbitrary KD in A. we have &[A] = u[A] if and only if si[A] = u[A]. . . since KEY (K’) holds in S. . attribute by attribute. t. We now define a tuple u. Let S be a relation containing only the tuples sl. So ti[A] = tj[A].. . However. But si[K’]# s~[K’] w h en i # j.[A] # u[A]. by assumption. This will give us a contradiction. Our goal is to show that r holds in T and that u fails in T. Now assume that A is nonprime. set &[A] = a if si[A] = u[A]. . . since both equal u[A]. . Let us write u as * {Xl. . Case 2. j(l5 i 5 r.]. [A] = tj[A] if and only if sJA] = sj[A]. . Find j such that A E Xj. sr of R (not necessarily distinct) and a tuple u not in R such that ai[Xi] = u[Xi] for each i (1 5 i I r). Set u[A] = &[A].412 . A holds in S since it holds in R. A is a prime attribute. So. 1 I i I r. Clearly 0. That is. 15 i ZGr. (b) t. . Since si[A] # u[A] and sj[A] = u[A]. depending on whether or not A is prime. X. Then Si[Xi] = u[X. Assume that si[A] # u[A]. This is a contradiction. &[A] so that (a) &[A] E dam(A).. September 1981. No. There are now two cases. Then sj[A] = u[A]. Since u fails in R. We now show that for each attribute A. Since ti[A] = tj[A]. I? I= u. Thus ti[K’] # tj[K’] if i # j. This is a contradiction. . we need only show that KEY(K’) holds in T. Conversely. holds in T. We can define tl[A]. The reason that (b) is possible is that ] dam(A) ] 2 r. . We must show that $A] is well defined. Finally. .. assume that ti[A] = u[A]. (Al) If a[A] = u[A]. To show that KEY(K) holds in T. we must show that u does not hold in T. the proof is complete if we show that each KD in A holds in T and that u fails in T. we must show that if si[A] and sj[A] both equal u[A]. by construction. . 6. which was to be shown. 1 5 j 5 r). We wish to show that si[A] = u[A]. .

Jorma Rissanen. LEMMA A3. which is obtained from the original JD by “removing” each component Xi that is a proper subset of another component Xi. . . q We note that Lemma A3 is an immediate consequence of results by Aho. AHO.. 2. 1979). LEMMA A4. Lemma 6.. . J. Database Syst. * R[Xi-I] * R[Xi+l] * . . September 1981. * R[X. SIAM J. [n/2]) components. . ACKNOWLEDGMENTS The author is grateful to Bill Armstrong. Phil Bernstein. AHO.This follows immediately from a theorem of Sperner [31]. . X. John Smith. and Ullman [2]. by (Al). R = RIXl] * . A JD * {X1. where n is the number of attributes. ARMSTRONG. j with i # j is it true that Xi c Xj . This was to be shown. A. we need only consider irreducible JDs. [n/2]). the JD *{X1. So u does not hold in T. SAGIV. we would have u = ti. then the maximal value of r we need to consider is C(n.4 then follows. . * R[X. Conput. AND ULLMAN.Normal Form for Relational Databases Based on Domains and Keys - 413 Since si[Xi] = u[Xi] (1 I i 5 r). Every JD is equivalent to an irreducible JD. AND ULLMAN. BEERI. . If u were in T. But then. North-Holland. Thus since the join is zdimutative and associative.} is equivalent to an irreducible JD. 0 Definition A2. 580-583. Larry Carter. If Xi c Xi. Hence to show that o does not hold in T. J. W. REFERENCES 1. Y. 297-314.} holds for a relation R precisely if R = R[X. X.3 (Sept. Chris Date. . Ted Codd. . X.) The reason for the equivalence is as follows. A. This process is repeated until an irreducible JD is obtained. then for some i. (We do not need to consider the case where two components are equal since we are thinking of {X1. . we need only show that u is not in T. 6. . 4.] * R[X. then R[Xi] * R [X. Equivalences among relational expressions. In Proc. 3. W.4. . Cl We can now prove Lemma 6. . 218-246. Dick Karp. Thus if r is as in Lemma Al.As we now show. . PROOF. 3. . PROOF. ACM Transactions on Database Systems.2 (May 1979). [n/2]). . The theory of joins in relational databases.]. By Lemma A3. [n/2]). 1974. No. By Lemma A4. The JD *{X1. Sagiv. it follows from (Al) that ti[Xi] = u[X~] (1 I i I r). Amsterdam. 8. Vol. C. Nat Goodman. 1974 IFIP Congr. which by definition has no duplicates. pp. . . He is especially grateful to Jean-Marie Cadiou for asking the probing questions which inspired this research.. . . This is impossible since u is not in S.] = R[Xj]. . V. and Jeff Ullman for helpful comments.] if and only if R = R[Xl] * . The maximum number of components an irreducible JD can have is C(n. it would follow that u = si. John Sowa. XT} as a set. which states that the maximum number of pairwise incomparable (under &) subsets of a set of n elements is C(n. ACM Trans.. D. no irreducible JD can have more than C(n. This latter equality holds if and only if the JD obtained from the original JD by removing the Xi component holds in R..]. D.} is irreducible if for no i. Dependency structures of database relationships.. . V.

CADIOU. E. 1974. FAGIN. 1980). P. SH20-2078. Independent components of relations. ACM 13. 1017-1021. Reston. pp. Extending the database relational model to capture more meaning.. 1. FAGIN. 2nd ed. vol. In Proc. Database Syst. ACM Trans. Information Management System/Virtual Storage Utilities Reference h4unuaZ. SOFTWARE AG. A. 1978. Testing implications of data dependencies. DELOBEL. On semantic issues in the relational model of data. In Proc. Symp. CODD. 1975. 537-551. Normal forms and relational database operators. 11806 Sunrise Valley Drive. 21. P. In Proc. pp. 19. Mass. 16. A. U. AND FAGIN. 22. System R: A relational approach to database management. D. CHURCH. 2. 6. Va. Grenoble.4 (Dec. ACM Trans. Database Syst. 1979). Znf Process..4 (Dec. AND DELOBEL. J. Nov. 455-469. Computer Corporation of America. 14. Theory of relations for databases-A tutorial survey. Commun. 1977). F. SMITH. Mass. W. E. Theory of Computation. DELOBEL. D. 12. J. 1972. IBM CORPORATION. Database abstractions: Aggregation. R. SMITH. An equivalence between relational database dependencies and a fragment of propositional logic. 1. West Berlin. 30. 404-430. M. Muthematical Foundations of Computer Science. pp. ACM 28. 25. Cambridge.-M. Englewood Cliffs. Lecture Notes in Computer Sciences. 101102. NICOLAS. ADABAS Introductory Manual. SH20-9029. Tech. 1973. 23. Correction.. 4. Y. F. An Introduction to Database Systems.. J. Generalized Information System/Virtual Storage. 17. 262-278. Gdansk. 29. J. 3.414 - Ronald Fagin 4. 8. 15. 1976).. KANELLAKIS. Database Syst. F. No. AND BERNSTEIN.. 277-298. 360-367. 1977. C. CODD. 97-137. Addison-Wesley. In Proc. 6. Prentice-Hall. P. J. Lecture Notes in Computer Science. Sept. R. Database Syst. 123-134. In Proc. CODD.D. 317-325. Database Syst. In Proc. Muthematical Foundations of Computer Science. 4 (Dec. 1978. ACM SZGACT Symp. ACM Trans. E. DAYAL.. ACM 20. West Berlin. 1979. IBM CORPORATION. Symbolic Logic 1. ACM Trans. SH209036. M. S. User’s Guide. Poland. 26. J. 15. Znt. Database Syst.4 (Dec. ACM Trans. 27. A. AND SMITH. Univ. 7th Symp. AND SAGIV.2 (Oct. 11. ACM Trans. BERNSTEIN.4 (Dec.. J. 22091.6 (June 1970). Vol. Amsterdam. 18. ARMSTRONG. 435-453. September 1981. In Proc. 1977). 28. C. 4th Conf Very Large Data Bases. Ph. 65-98. 1978. 11. ACM Trans. ASTRAHAN. 1974 ZFZP Congr. ACM SZGMGD. C. 2. User’s Guide. Rep. 64. Contribution theorique a la conception des systemes d’information. 5. Multivalued dependencies and a new normal form for relational databases. Springer-Verlag. 98-101. J. RISSANEN. A. 1978. DATE. RISSANEN. Commun. 397-434. J. 1980). Horn clauses and database dependencies.. pp.. SAGIV. pp. 10. IBM CORPORATION. M. P. Y. N. A relational model of data for large shared data banks. . R. W. pp. Query by Example. FAGIN. 2 (April 1981). Very Large Data Bases. Mutual dependencies and some results on undecomposable relations.. Springer-Verlag. In Data Base Systems. CCA-78-13. D. C. ET AL. A note on the Entscheidungsproblem. 9. Further normalization of the database relational model. 3 (Sept. C. pp. Synthesizing third normal form relations from functional dependencies. A normal form for abstract syntax. 5. M. Lett. Recent investigations in relational database systems. PARKER. 13. 153-160. On the computational complexity of cardinality constraints in relational databases. ACM Transactions on Database Systems. 1980. M. E.J. 1979). Software AG North America Inc. 24. The fragmentation problem: Lossless decomposition of relations into files. MENDELZON. 20...2 (June 1976). CODD. C. Heidelberg. Reading. 156-162. Courant Computer Science Symposia 6. Decompositions and functional dependencies in relations. 4th Conf. 4. R. 6 (June 1977) 405-413. Grenoble. North-Holland. Database Syst. MAIER. 7. 377-387.40-41. F. France. Dissertation.

P. G. Design of relational views over network schemas. 1. pp. KREPS. 179-190. 3. accepted October 1980 ACM Transactions on Database Systems. 544-548. Zeitschrift 27 (1928). Math. Database Syst. E. - 415 Ein satz iiber Untermengen einer endlichen Menge.Normal Form for Relational Databases Based on Domains and Keys 31.. M.. ACM SIGMOD. 1976). No. C. 189-222. Received July 1979. E. Vol. AND HELD. WONG. TYMSHARE INC. ACM Trans. 34. 6. revised June 1980. Nov. MAGNUM Reference Manual. The design and implementation of INGRES. 32..3 (Sept. 33. STONEBRAKER. September 1981. In Proc. 1979. ZANIOLO. SPERNER. . 1975.

Are you sure?

This action might not be possible to undo. Are you sure you want to continue?

We've moved you to where you read on your other device.

Get the full title to continue

Get the full title to continue listening from where you left off, or restart the preview.

scribd