Base de datos
relacional
Una base de datos relacional es una
base de datos que cumple con el modelo relacional, el cual es el
modelo más utilizado en la actualidad para implementar bases de
datos ya planificadas. Permiten establecer interconexiones
(relaciones) entre los datos (que están guardados en tablas), y a
través de dichas conexiones relacionar los datos de ambas tablas, de
ahí proviene su nombre: "Modelo Relacional". Tras ser
postuladas sus bases en 1970 por Edgar Frank Codd, de los
laboratorios IBM en San José (California), no tardó en consolidarse
como un nuevo paradigma en los modelos de base de datos.
Una base de datos relacional se
compone de varias tablas o relaciones.
No pueden existir dos tablas con
el mismo nombre ni registro.
Cada tabla es a su vez un conjunto
de registros (filas y columnas).
La relación entre una tabla padre
y un hijo se lleva a cabo por medio de las claves primarias y ajenas
(o foráneas).
Las claves primarias son la clave
principal de un registro dentro de una tabla y éstas deben cumplir
con la integridad de datos.
Las claves ajenas se colocan en la
tabla hija, contienen el mismo valor que la clave primaria del
registro padre; por medio de éstas se hacen las relaciones.
Campo clave
Cuando creas una tabla en acces te pide
"un campo Clave" para que es esto pues es un requisito del
las bases de datos para ordenar y realizar relaciones entre tablas y
consultas
Clave primaria
En el diseño de bases de datos
relacionales, se llama clave primaria a un campo o a una combinación
de campos que identifica de forma única a cada fila de una tabla.
Una clave primaria comprende de esta manera una columna o conjunto de
columnas. No pueden haber dos filas en una tabla que tengan la misma
clave primaria.
Una clave primaria debe identificar
unívocamente a todas las posibles filas de una tabla y no solo a las
filas que se encuentran en un momento determinado. Ejemplos de claves
primarias son DNI (asociado a una persona) o ISBN (asociado a un
libro). Las guias telefónicas y diccionarios no pueden usar nombres
o palabras o números del sistema decimal de Dewey como claves
candidatas, porque no identifican unívocamente números de teléfono
o palabras.
Una clave primaria es un caso especial
de clave única. La mayor diferencia es que para claves únicas, no
se impone automáticamente la restricción implícita NOT NULL,
mientras que para claves primarias, sí. Así, los valores en
columnas de clave única pueden o no ser NULL. Otra diferencia es que
las claves primarias deben definirse por medio de otra sintaxis.
El modelo relacional, según se lo
expresa mediante cálculo relacional y álgebra relacional, no
distingue entre clave primaria y otros tipos de claves. Las claves
primarias fueron agregadas al estándar SQL principalmente para
conveniencia del programador.
Clave foranea
En el contexto de bases de datos
relacionales, una clave foránea o clave ajena (o Foreign Key FK) es
una limitación referencial entre dos tablas. La clave foránea
identifica una columna o grupo de columnas en una tabla (tabla hija o
referendo) que se refiere a una columna o grupo de columnas en otra
tabla (tabla maestra o referenciada). Las columnas en la tabla
referendo deben ser la clave primaria u otra clave candidata en la
tabla referenciada.
Los valores en una fila de las columnas
referendo deben existir solo en una fila en la tabla referenciada.
Así, una fila en la tabla referendo no puede contener valores que no
existen en la tabla referenciada. De esta forma, las referencias
pueden ser creadas para vincular o relacionar información. Esto es
una parte esencial de la normalización de base de datos. Múltiples
filas en la tabla referendo pueden hacer referencia, vincularse o
relacionarse a la misma fila en la tabla referenciada. Mayormente
esto se ve reflejado en una relación uno (tabla maestra o
referenciada) a muchos (tabla hija o referendo).
Relaciones uno a uno
En una relación uno a uno, una fila de
la tabla A no puede tener más de una fila coincidente en la tabla B
y viceversa. Se crea una relación uno a uno si las dos columnas
relacionadas son claves principales o tienen restricciones UNIQUE.
Este tipo de relación no es habitual,
ya que la mayor parte de la información relacionada de esta manera
estaría toda en una tabla. Puede utilizar una relación uno a uno
para:
Dividir una tabla con muchas
columnas.
Aislar parte de una tabla por
razones de seguridad.
Almacenar datos que son efímeros
y que pueden eliminarse fácilmente mediante la simple eliminación
de la tabla.
Almacenar información que se
aplica solamente a un subconjunto de la tabla principal.
El lado de la clave principal de una
relación uno a uno se indica mediante un símbolo de clave . El
lado de la clave externa también se indica mediante un símbolo de
clave.
Relacion uno a varios
Una relación uno a varios es el tipo
más habitual de relación. En este tipo de relación, una fila de la
tabla A puede corresponderse con muchas filas de la tabla B, pero una
fila de la tabla B sólo puede corresponderse con otra de la tabla A.
Por ejemplo, en las tablas publishers (editoriales) y titles
(títulos) se da una relación uno a varios: una editorial publica
muchos títulos, pero a cada título le corresponde sólo una
editorial.
Cree una relación uno a varios si
solamente una de las columnas relacionadas es la clave principal o
tiene una restricción unique.
El lado de la clave principal de una
relación uno a varios se indica mediante un símbolo de clave. El
lado de la clave externa de una relación se indica mediante un
símbolo de infinito.
Ventajas y desventajas del modelo
relacional
Ventajas
Provee herramientas que garantizan
evitar la duplicidad de registros.
Garantiza la integridad
referencial, así, al eliminar un registro elimina todos los
registros relacionados dependientes.
Favorece la normalización por ser
más comprensible y aplicable.
Desventajas
Presentan deficiencias con datos
gráficos, multimedia, CAD y sistemas de información geográfica.
No se manipulan de forma manejable
los bloques de texto como tipo de dato.
Las bases de datos orientadas a
objetos (BDOO) se propusieron con el objetivo de satisfacer las
necesidades de las aplicaciones anteriores y así, complementar pero
no sustituir a las bases de datos relacionales.