{
  "id": "first-normal-form-159052-d192108d8d98be4a",
  "slug": "first-normal-form",
  "title": "first normal form",
  "qid": "Q1366465",
  "lead": "First normal form (1NF) is the most basic level of database normalization defined by English computer scientist Edgar F. Codd, the inventor of the relational database. A relation (or a table, in SQL) can be said to be in first normal form if each field is atomic, containing a single value rather than a set of values or a nested table. In other words, a relation complies with first normal form if no attribute domain (the set of values allowed in a given column) has relations as elements. Most relational database management systems do not support creating or using table-valued columns, which means most relational databases will be in first normal form by necessity. Otherwise, normalization to 1NF involves eliminating nested relations by breaking them up into separate relations associated with each other using foreign keys. This process is a necessary step when moving data from a non-relational (or NoSQL) database, such as one using a hierarchical or document-oriented model, to a relational database. A database must satisfy 1NF to satisfy further \"normal forms\", such as 2NF and 3NF, which enable the reduction of redundancy and anomalies.…",
  "body": "First normal form (1NF) is the most basic level of database normalization defined by English computer scientist Edgar F. Codd, the inventor of the relational database. A relation (or a table, in SQL) can be said to be in first normal form if each field is atomic, containing a single value rather than a set of values or a nested table. In other words, a relation complies with first normal form if no attribute domain (the set of values allowed in a given column) has relations as elements. Most relational database management systems do not support creating or using table-valued columns, which means most relational databases will be in first normal form by necessity. Otherwise, normalization to 1NF involves eliminating nested relations by breaking them up into separate relations associated with each other using foreign keys. This process is a necessary step when moving data from a non-relational (or NoSQL) database, such as one using a hierarchical or document-oriented model, to a relational database. A database must satisfy 1NF to satisfy further \"normal forms\", such as 2NF and 3NF, which enable the reduction of redundancy and anomalies. Other benefits of adopting 1NF include the introduction of increased data independence and flexibility (including features like many-to-many relationships) and simplification of the relational algebra and query language necessary to describe operations on the database. Codd considered 1NF mandatory for relational databases, while the other normal forms were merely guidelines for database design. ==Examples== ===Design that violates 1NF=== This table of customers' credit card transactions does not conform to first normal form, as each customer corresponds to a repeating group of transactions. Such a design can be represented in a hierarchical database, but not in an SQL database, since SQL does not support nested tables. |- | 2 || Isaac || |- | 3 || Jacob || |} The evaluation of any query relating to customers' transactions would broadly involve two stages: unpacking one or more customers' groups of transactions, allowing the individual transactions in a group to be examined, and deriving a query result from the results of the first stage. For example, in order to find out the monetary sum of all transactions that occurred in October 2003 for all customers, the database management system (DMBS) would have to first unpack the Transactions field of each customer, then sum the Amount of each transaction thus obtained where the Date of the transaction falls in October 2003. ===Design that complies with 1NF=== Codd described how a database like this could be made less structurally complex and more flexible by transforming it into a relational database in first normal form. To normalize the table so it complies with first normal form, attributes with nonsimple domains must be extracted to separate, stand-alone relations. Each extracted relation gains a foreign key referencing the primary key of the relation which initially contained it. This process can be applied recursively to nonsimple domains nested in multiple levels (i.e., domains containing tables within tables within tables, and so on). In this example, CustomerID is the primary key of the containing relation and will therefore be appended as a foreign key to the new relation: In this modified design, the primary key is {CustomerID} in the first relation and {CustomerID, TransactionID} in the second relation. Now that a single, \"top-level\" relation contains all transactions, it will be simpler to run queries on the database. To find the monetary sum of all October transactions, the DMBS would simply find all rows with a Date falling in October and sum the Amount fields. All values are now easily exposed to the DBMS, whereas previously some values were embedded in lower-level structures that had to be handled specially. Accordingly, the normalized design lends itself well to general-purpose query processing, whereas the unnormalized design does not. It is worth noting that the revised design also meets the additional requirements for second and third normal form. ==Christopher J. Date's definition of 1NF== According to Christopher J. Date's definition, a table is in first normal form if and only if it is \"isomorphic to some relation\", which means, specifically, that it satisfies the following five conditions: There is no specific top-to-bottom ordering of the rows. There is no specific left-to-right ordering of the columns. There are no duplicate rows. Every field (or intersection of a row and a column) contains exactly one value from the applicable domain and nothing else. All columns are regular (i.e., rows have no hidden components such as row IDs, object IDs, or hidden timestamps). Violation of any of these conditions would mean that the table is not strictly relational, and therefore that it is not in first normal form. This definition of 1NF permits relation-valued attributes (tables within tables), which Date argues are useful in rare cases. Examples of tables (or views) that would not meet this definition of first normal form are: A table that lacks a unique key constraint. Such a table would be able to accommodate duplicate rows, in violation of condition 3. A view whose definition mandates that results be returned in a particular order, so that the row-ordering is an intrinsic and meaningful aspect of the view, in violation of condition 1. The tuples in true relations are not ordered with respect to each other (such views cannot be created using SQL that conforms to the SQL:2003 standard). A table with at least one nullable attribute. A nullable attribute would be in violation of condition 4, which requires every column to contain exactly one value from its column's domain. This aspect of condition 4 is controversial; it marks an important departure from Codd's later vision of the relational model, which made explicit provision for nulls. ==See also== Attribute–value system Second normal form (2NF) Third normal form (3NF) Boyce–Codd normal form (BCNF or 3.5NF) Fourth normal form (4NF) Fifth normal form (5NF) Sixth normal form (6NF) ==References== ==Further reading== Date, C. J., & Lorentzos, N., & Darwen, H. (2002). (1st ed.). Morgan Kaufmann. . Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. . Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM, vol. 26, p. 120–125. de:Normalisierung (Datenbank)#Erste Normalform (1NF) pl:Postać normalna (bazy danych)",
  "categories": [
    "108902726",
    "108904611",
    "108904702",
    "129826521",
    "22922474",
    "23118434",
    "23603337",
    "24745118",
    "24745122",
    "59538891",
    "89061593",
    "97454500"
  ],
  "license": "CC BY-SA 4.0",
  "source_uri": "https://en.wikipedia.org/w/index.php?oldid=1370916965",
  "content_hash": "d192108d8d98be4a7f510c38eca62c8ddfb9197c91a10946fcff5ff91a8b3a53",
  "created_at": 1792309428.1295485,
  "updated_at": 1787502040.0,
  "claims": [],
  "contradictions": [],
  "confidence": 0.6,
  "csl": {
    "id": "first-normal-form-159052-d192108d8d98be4a",
    "type": "webpage",
    "title": "first normal form",
    "author": [
      {
        "family": "Anticloud FZ LLE",
        "literal": "Anticloud FZ LLE"
      }
    ],
    "container-title": "encyclopegia.org",
    "publisher": "Anticloud FZ LLE",
    "publisher-place": "Dubai, United Arab Emirates",
    "URL": "https://encyclopegia.org/a/first-normal-form",
    "issued": {
      "date-parts": [
        [
          2026,
          10,
          18
        ]
      ]
    },
    "accessed": {
      "date-parts": [
        [
          2026,
          11,
          15
        ]
      ]
    },
    "license": "CC BY-SA 4.0",
    "DOI": "eo1:first-normal-form-159052-d192108d8d98be4a",
    "isBasedOn": "https://en.wikipedia.org/w/index.php?oldid=1370916965",
    "note": "Immutable snapshot first-normal-form-159052-d192108d8d98be4a, content root d192108d8d98be4a…"
  }
}