La década de 1970 vio nacer los sistemas computacionales de bases de datos relacionales en entornos informáticos que sentaron las bases teóricas y prácticas de lo que conocemos hoy como sistemas de gestión de bases de datos relacionales o RDBMS por sus siglas en inglés.
Uno de los hitos más significativos en el campo de lo datos en esta década fue la publicación del modelo relacional por parte del informático Inglés Edgar F. Codd en su influyente artículo "A Relational Model of Data for Large Shared Data Banks" ("Un modelo relacional de datos para grandes bancos de datos compartidos"). Este modelo proponía representar los datos en forma de tablas con filas y columnas, y para relacionar los diferentes conjuntos de datos se implementó el uso de un tipo de elementos que llamados "Keys". Estas keys permiten identificar las filas/tuplas de una tabla y también establecer relaciones entre varias columnas o tablas. Pocos años mas tarde, en 1976, Peter Chen publica su artículo "The Entity-Relationship Model - Toward a Unified View of Data" dando forma a lo que conocemos hoy como las bases del modelo entidad relación o MER.
La Integridad de Clave o Restricciones de Integridad
Edgar F. Codd, si bien no le pone nombre al concepto, describe en su obra un conjunto de reglas o restricciones que aplicadas a las claves primarias y foráneas garantizan la validez y la consistencia en una base de datos relacional:
Unicidad: Cada clave primaria debe ser única en la tabla a la que pertenece.
No nulidad: Las claves primarias no pueden contener valores nulos.
Referencialidad: Las claves foráneas deben hacer referencia a una clave primaria (o una clave única) en otra tabla. Esto garantiza la coherencia y la integridad referencial entre las tablas relacionadas.
Consistencia: Las relaciones entre las claves primarias y foráneas deben mantenerse en todo momento. No se deben permitir operaciones que dejen relaciones huérfanas o incoherentes en la base de datos.
Los tipos de keys
En el modelo de entidad relación, las keys más popularmente conocidas quizás sean:
Primary Keys: Las primary keys eran identificadores únicos asignados a cada registro dentro de una tabla. Estas keys aseguraban la unicidad de los datos en la tabla y servían como punto de referencia para las relaciones con otras tablas.
Secondary Keys: También conocidas como "alternate keys", estas keys proporcionan identificaciones únicas para registros específicos dentro de una tabla. Aunque no son las claves principales, mejoran la eficiencia de las consultas al permitir búsquedas en columnas específicas.
Foreign Keys o cláves foraneas: Las foreign keys establecen relaciones entre las tablas de una base de datos relacional. Estas keys hacen referencia a las primary keys de otras tablas, garantizando la integridad referencial entre los datos y evitando la aparición de registros huérfanos o inconsistentes.
Sin embargo, otros conceptos de claves no tan populares pero igualmente importantes son:
Candidate Keys: Son claves primarias potenciales. De todas las claves candidatas en una tabla, generalmente se selecciona una para ser la clave primaria. También conocidas como "candidate primary keys", son columnas o combinaciones mínimas de columnas que podrían funcionar como primary keys ya que identifican de manera única una tupla (fila) cumpliendo con la propiedad de unicidad.
Unique Key: El concepto es similar al de una primary key, pero puede contener valores NULL y puede haber múltiples claves únicas en una tabla. Mientras que una clave primaria garantiza la unicidad de cada fila en una tabla (no puede haber dos filas con el mismo valor en la columna de la clave primaria), una clave única garantiza la unicidad de los valores en una columna o un conjunto de columnas, pero puede permitir valores nulos. La unique key garantiza que los valores en una columna, o una combinación de columnas, sean únicos para cada fila en la tabla, es decir no pueden tener valores duplicados (excepto posiblemente NULL, dependiendo de la configuración).
Composite Keys: Son claves compuestas por dos o más columnas y que, en conjunto, identifican de manera única cada registro en una tabla. Estas keys son útiles cuando ninguna columna por sí sola puede servir como primary key. Si pensas que las composite keys son muy similares a una candidate keys, no estarias del todo equivocado, pero la gran diferencia es que una candidate key puede ser una sola comuna mientras que para ser una composite key esta debe ser de dos o más columnas.
Super Keys: Es cualquier conjunto de una o más columnas que puede identificar de manera única cada fila en una tabla, aunque no sea el conjunto mínimo, esto incluye tanto claves primarias como claves candidatas. Si bien por definición toda Composite key es una Superkey, el uso de Super Keys puede proporcionar varias ventajas en términos de eficiencia y rendimiento en la administración de bases de datos que abordaremos en otro artículo posterior de esta serie.
La siguiente imagen ilustra muy claramente como una Superkey, CandidateKey y PrimaryKey se relacionan:
Ahora bien, cuando hablamos de keys, es también importante comprender los siguientes conceptos:
Natural Key: Este tipo de key deriva de la propia naturaleza de los datos que representa. Estos atributos suelen ser valores que ya existen en el mundo real y que se capturan en la base de datos para identificar de manera única una fila en una tabla. Algunos ejemplos comunes de Natural Keys incluyen números de identificación personal, pasaporte, teléfono, códigos de producto, nombres de usuario únicos, etc. Estos atributos son únicos y no se repiten dentro del conjunto de datos relevante. En general, elegir Natural Keys apropiadas y significativas puede resultar conveniente haciendo que la lectura del conjunto de datos resulte significativa, mejorando la integridad y la calidad de los mismos. Sin embargo, esto a veces puede presentar desafíos en términos del manejo de cambios en los datos o de escalabilidad. Por ejemplo: si el formato de una Natural Key cambia en el futuro ya que puede ser difícil actualizar todos los registros relacionados. Un caso concreto de este ejemplo es el de las patentes automotores en Argentina que tuvo cuatro formatos de codificación diferentes en los últimos 30 años a nivel nacional.
Index Key: No es una clave en el sentido tradicional, sino que es una estructura utilizada para mejorar la velocidad de las consultas. Un índice permite el acceso rápido a los datos basado en los valores de una o más columnas.
Clustered Keys: Refieren al orden físico de los datos en una tabla. A diferencia de las claves primarias o secundarias que simplemente identifican registros únicos, una clave clusterizada determina cómo se almacenan físicamente los datos en el disco.
Última en esta lista pero muy lejos de ser el concepto menos importante:
Surrogate keys oclaves sustitutas: Son claves artificiales creadas específicamente con el propósito de servir como identificadores únicos para las filas de una tabla en una base de datos relacional. A diferencia de las Natural Keys, que se derivan de atributos intrínsecos de los datos, las Surrogate Keys son valores generados automáticamente por el sistema de gestión de bases de datos (DBMS) y no tienen un significado inherente o relación directa con los datos que representan. Su uso se ha vuelto omnipresente en el management de datos actualmente ya que no están limitadas exclusivamente a las bases de datos relacionales. Por ejemplo, en sistemas NoSQL o en bases de datos de tipo documento, como MongoDB, es común utilizar identificadores únicos generados automáticamente (por ejemplo, UUID) para identificar documentos o registros de manera única. Estos identificadores pueden considerarse como Surrogate Keys en el sentido de que son claves artificiales que no tienen una relación directa con los datos que representan, sino que son asignadas automáticamente por el sistema para garantizar la unicidad. Sobre ellas hablaremos también en un próximo artículo de esta serie.
Un dato de color:
Como parte del hervor tecnológico en datos de la década del 70 surge el proyecto System R de IBM. Un proyecto de investigación iniciado en 1974 que incluía un lenguaje para realizar consultas en forma estructurada para el idioma inglés ("Structured English Query Language") bajo el nombre "SEQUEL". Su nombre fue cambiando con el tiempo y hoy lo llamamos "SQL".
System R fue pionero en demostrar que un sistema de gestión de bases de datos relacionales podría proporcionar un buen rendimiento en el procesamiento de transacciones y para 1977 se convirtió en un producto comercial de IBM dando inicio a una era en la gestión de datos e influenciando a todos los RDBMS que le sucedieron.
