cipher key (Kc)

The term key, cipher key( CK or Kc), is discussed below in the context of encryption and databases.

1. In the context discussed here, a key is a generated bit combination with which a ciphertext is generated from a plaintext and with which the plaintext is recovered from the ciphertext on the receiving side
   The key is generated using mathematical procedures or random procedures involving prime numbers. The key length is decisive for the security of the transmitted data. Depending on the encryption method, it can be a public or private key. The public key is the publicly known part of an asymmetric key pair. It is contained in the certificate and can be used by all participants in the security infrastructure( PKI). Only by using the private key can the key holder decrypt the data. The private key, on the other hand, is the secret part of the asymmetric key pair.

2. The term key in the context of databases

   A key is used to uniquely identify a record (tuple) in a relational database - each relation has at least one key. A key is an attribute or even a minimal combination of attributes whose values can then be used to uniquely identify the tuples. As a consequence, such a key may appear only once in a relation. Since a set of tuples differs at least in the key value, this means conversely that a tuple may appear only once in a relation. Basically, the principle of minimality applies to the formation of keys - i.e. a key must be kept as short as possible. To distinguish keys from other attributes, keys in a relation are marked by underlining the key attribute(s). Seen from the point of view of a table, the columns form a key of the relation if the complete tuple can be uniquely determined with the help of the values of some columns of a relation. In general, there is a functional dependency between the key of a relation and all other columns of this relation. A functional dependency exists if the values of fields can be uniquely traced back to other fields in a data set. Frequently, relational databases also allow the creation of tables without keys. However, this does not satisfy a practical relevance, since as soon as in a table same data records occur, one cannot identify these then any longer. In the sense of the relational data base scheme namely a tuple cannot belong several times to a relation. For the treatment of relational data base schemes still the following definitions developed in connection with the term key: Primary key. Each relation has a primary key that uniquely identifies the tuples of the table. For the insertion of a tuple into a relation, at least the primary key value must be specified. Further attribute values of the tuple do not necessarily have to be known for the creation of the data record, since they are represented by so-called null values. A null value in this context means something like "non-existent" and has no relation to a numeric 0 value. A primary key should be stable over the life cycle of a table. For example, if a table has no unique attributes - also called data fields - an additional unique ID number can be assigned as a primary key. Key candidates. All attributes or combinations of attributes are called key candidates. The values of these attributes must in turn be unique. In addition, a relation can in principle have any number of additional keys. In this case, the primary key and any additional key are mutually associated. Foreign key. This refers to an attribute in a relation that establishes a relationship to a key field of another relation. If a table has no unique attributes - also called data fields - for example a unique ID number can be assigned as primary key. Index. An index is a tool of relational databases to find records more efficiently in search functions. Indexes are created in addition to the primary key to speed up access to the data. Indexes can be created for any column - it makes sense to use them for records that are searched for most often. However, when using multiple indexes, for example when filling a table, a lot of time is needed to update the indexes. In this case it is more advantageous to update the indexes only after filling the table.