Un lenguaje llamado SQL (Structured Query Language) fue desarrollado para trabajar con bases de datos relacionales.

...

El modelo relacional dicta que cada fila de una tabla sea única. Si permite que las filas se dupliquen en una tabla, entonces no hay manera de abordar de forma única una fila dada a través de la programación. Esto crea todo tipo de ambigüedades y problemas que es mejor evitar. Se garantiza la unicidad de una tabla mediante la designación de una columna “llave primaria” que contiene valores únicos para una tabla. Cada tabla puede tener sólo una llave primaria, a pesar de que varias columnas o combinación de columnas pueden contener valores únicos. Todas las columnas (o combinación de columnas) en una tabla con valores únicos se conocen como “llaves candidatas”, de las cuales deberá ser creada la llave primaria. Todas las demás columnas de la llave candidata se denominan “llaves suplentes”. Las llaves pueden ser simples o compuestas. Una llave simple es una llave hecha de una columna, mientras que una llave compuesta se compone de dos o más columnas.

La decisión en cuanto a qué clave candidata es la primaria no se basa en ninguna norma absoluta en cuanto a qué clave candidata es la mejor. Fabian Pascal, en su libro SQL y fundamentos relacionales, señala que la decisión debe basarse en los principios de minimalidad (elegir las columnas menor cantidad necesaria), estabilidad (elegir una clave que rara vez cambia), y la simplicidad / familiaridad (elegir una clave que es a la vez simple y familiar para los usuarios). Por ejemplo, podemos decir que una empresa tiene una tabla de clientes llamado tblCustomer, que se parece a la tabla que se muestra en la Figura 1.

[pic 3]

Las llaves candidatas para tblCustomer podrían incluir CustomerId, (LastName + FirstName), Phone#, (Adress, City, State) y (Address, ZipCode). Siguiendo las directrices de Pascal, se descartan los últimos tres candidatos porque los números de teléfono y direcciones pueden cambiar con bastante frecuencia. La elección entre CustomerId y las llaves del nombre y apellido es menos evidente y sería sacrificar algunas cosas. ¿Qué probabilidad de cambio de nombre de un cliente (por ejemplo, matrimonios causan cambio de apellidos)? ¿Será común la falta de ortografía en los nombres? ¿Qué tan probable es que dos clientes tengan el mismo nombre y apellido? ¿Qué tan familiarizado es el CustomerId para los usuarios? No hay una respuesta correcta, pero la mayoría de los desarrolladores están a favor llaves primarias numéricas porque los nombres pueden cambiar y porque la búsqueda y clasificación de columnas numéricas son más eficientes que los de las columnas de texto en Microsoft Access (y la mayoría de las otras bases de datos).

Claves y dominios extranjeros

A pesar de que las llaves primarias están en función de las tablas individuales, si se han creado bases de datos que consisten en tablas sólo independientes y sin relación, tendría poca necesidad de estas. Las llaves primarias se convierten en esencial cuando se empieza a crear relaciones que unen múltiples tablas en una base de datos. Una llave foránea es una columna de una tabla usada para hacer referencia a una llave primaria en otra tabla.

Continuando con el ejemplo presentado en la sección anterior, digamos que se elige un cliente como la llave principal de tblCustomer. Ahora definir una segunda tabla, tblOrder, como se muestra en la Figura 2.

[pic 4]

CustomerId se considera una llave foránea en tblOrder ya que puede ser usado para referirse a determinado cliente (es decir, una fila en la tabla tblCustomer).

Es importante que tanto las llaves foráneas y las llaves primarias que se utilizan para hacer referencia compartan un sentido común y saquen sus valores desde el mismo dominio. Los dominios son simplemente grupos de valores a partir de los cuales se extraen columnas. Por ejemplo, CustomerId es del dominio de la identificación válida al cliente # 's, que en este caso podría ser enteros largos que oscilan entre 1 y 50.000. Del mismo modo, una columna denominada Sex podría estar basada en un dominio de una letra igualando 'M' o 'F'. Los dominios pueden ser considerados como tipos de columnas definidas por el usuario cuya definición implica ciertas reglas que deben seguir las columnas y ciertas operaciones que se pueden realizar en esas columnas.

Relaciones

Se definen las llaves foráneas en una base de datos para modelar las relaciones en el mundo real. Las relaciones entre las entidades del mundo real pueden ser bastante complejas, que incluyen numerosas entidades que cada uno tiene múltiples relaciones entre sí. Por ejemplo, una familia tiene múltiples relaciones entre múltiples personas al mismo tiempo. En una base de datos relacional como Microsoft Access, sin embargo, se tiene en cuenta sólo las relaciones entre pares de tablas. Estas tablas se pueden relacionar en una de tres maneras diferentes: uno a uno, uno a muchos o muchos-a-muchos.

Relaciones Uno-a-uno

Dos tablas están relacionadas en uno-a-uno (1:1) si, para cada fila de la primera tabla, hay como máximo una fila de la segunda tabla. Verdaderas relaciones uno-a-uno rara vez se producen en el mundo real. Este tipo de relación es a menudo creado para moverse por alguna limitación del software de gestión de base de datos en lugar de modelar una situación del mundo real. En Microsoft Access, relaciones uno-a-uno pueden ser necesarias en una base de datos cuando se tiene que dividir una tabla en dos o más tablas debido a preocupaciones de seguridad o rendimiento, o debido al límite de 255 columnas por tabla. Por ejemplo, es posible mantener la mayor parte de la información del paciente tblPatient, pero poner la información especialmente sensible (por ejemplo, el nombre del paciente, número de seguro social y dirección) en tblConfidential (ver Figura 3). El acceso a la información en tblConfidential podría ser más restringido que el de tblPatient. Como segundo ejemplo, tal vez necesite transferir sólo una parte de una mesa grande para alguna otra aplicación sobre una base regular. Se puede dividir la tabla en la transferido y las piezas no transferido, y unirse a ellos en una relación uno-a-uno.

[pic 5]

Las tablas que se relacionan uno-a-uno siempre deben tener la misma llave primaria, que servirá como la columna de combinación.

Relaciones Uno-a-muchos

Dos tablas están relacionadas en una relación de uno a muchos (1:M) si para cada fila de la primera tabla, no puede