Para terminar con las claves, tenemos otro tipo de claves, las claves ajenas (foráneas/externas).
Una clave ajena es un campo (o combinación de campos) que señala a un registro de otra tabla, contiene un valor que identifica un registro de la otra tabla. Estos campos sirven para relacionar las tablas entre sí.
Por ejemplo tenemos una tabla de facturas con los siguientes campos: Código de factura, Fecha, importe total, cliente. El campo cliente indica de qué cliente es la factura, contiene pues un código de cliente. Es una clave ajena, señala a un registro de la tabla de clientes. Es evidente que para que no haya errores en la tabla de facturas, los códigos de cliente introducidos deben ser de clientes registrados en la tabla de Clientes.
En esto consiste la integridad referencial. Para que no existan errores de integridad en la base de datos, el sistema comprueba automáticamente que los valores introducidos en las claves ajenas existan en el campo de referencia en la otra tabla, si no existe, no nos dejará insertar el registro.
Si intentamos grabar una factura con un código de cliente que no existe en la tabla de clientes, el sistema no nos dejará grabar la factura. A diferencia de las claves primarias y secundarias, una clave ajena en principio sí puede contener el valor nulo (es decir ningún valor) como cualquier otro campo.
El valor nulo (NULL) es importante porque representa la ausencia de valor en el campo y no es lo mismo que el valor cero”0“. De hecho es un valor tan especial que no funciona como los demás valores, por ejemplo no podemos comparar (con el operador de comparación =) un campo con el valor nulo, tenemos que utilizar una fórmula especial (IS NULL).
Estos son los conceptos mínimos, luego cada SGBD utiliza sus propios objetos que en algunos casos se repiten en varios sistemas como las VIEWs, TRIGGERs, INDEX etc... pero esto se verá cuando se estudie un SGBD concreto como haremos con SQL Server.
los Modelos Relacionales son de los utilizados muy ampliamente y recordando que el modelo es la base (core) para los DBMS es importante refrendar los conceptos básicos y de donde vienen. Muchas disciplinas (y sus metodologías de diseño asociadas) tienen algún tipo de base teórica.
Los ingenieros industriales diseñan estructuras utilizando teorías de la física. Los compositores crean sinfonías utilizando conceptos de teoría de la música. La industria del automóvil utiliza teorías de la aerodinámica para diseñar automóviles con menor consumo.
La industria aeronáutica utiliza las mismas teorías para diseñar alas de aviones que reduzcan la resistencia al viento. Estos ejemplos demuestran que la teoría es muy importante. La ventaja principal de la teoría es que hace que las cosas sean predecibles: nos permite predecir qué ocurrirá si realizamos una determinada acción.
Por ejemplo, sabemos que si soltamos una piedra, caerá al suelo. Si somos rápidos, podemos apartar nuestros pies del camino de la teoría de la gravedad de Newton.
Lo importante es que siempre funciona. Si ponemos una piedra plana encima de otra piedra plana, podemos predecir que se quedarán tal y como las hemos puesto. Esta teoría permite diseñar pirámides, catedrales y casas de ladrillos. Consideremos ahora el ejemplo de una base de datos relacional. Sabemos que si un par de tablas están relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teoría de las }bases de datos relacionales.
Los datos que se saquen de las dos tablas se basarán en los valores coincidentes del campo que ambas tienen en común. Una vez más, nuestras acciones tienen un resultado predecible.
El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las ASES DE DATOS MIS 308 2 matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemáticos para tan sólo llevar a cabo una tarea bastante concreta.
Es habitual escuchar quejas sobre que las teorías matemáticas en las que se basa el modelo relacional y sus metodologías de diseño, no tienen relevancia en el mundo real o que no son prácticas. No es cierto: las matemáticas son básicas en el modelo relacional. Pero, por fortuna, no hay que aprender teoría de conjuntos o lógica de predicados de primer orden para utilizar el modelo relacional. Sería como decir que hay que saber todos los detalles de la aerodinámica para poder conducir un automóvil. Las teorías de la aerodinámica ayudan a entender cómo un automóvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo.
La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona las líneas a seguir para construirla.
El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseño. En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional.
En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un puntero físico, siempre señalaría desde el registro al registro.
Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico.
Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos.
Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los DBMS. El modelo relacional representa la segunda generación de los DBMS. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta.
Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los DBMS de la primera generación, lo que constituye otro punto a su favor. BASES DE DATOS MIS 308 3 Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lógico que soportan (de red o jerárquico).
Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los datos. En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos: o Estructura de datos. o Integridad de datos. o Manejo de datos.
Definición del problema
La definición del problema es el proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar.
Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para expertos: más un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseño de bases de datos y éste se considera ahora una disciplina estable, con métodos y técnicas propios. Debido a la creciente aceptación de las bases de datos por parte de la industria y el gobierno en el plano comercial, y a una variedad de aplicaciones científicas y técnicas, el diseño de bases de datos desempeña un papel central en el empleo de los recursos de información en la mayoría de las organizaciones.
El diseño de bases de datos ha pasado a constituir parte de la formación general de los informáticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programación convencional Para definir correctamente al Problema lo primero es realizar diseño conceptual, que parte de las especificaciones de los requisitos del usuario y su resultado es el esquema conceptual de la base de datos que corresponderá a un Modelo Entidad – Relación (E / R).
Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del DBMS que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales.
El objetivo del diseño conceptual es describir el contenido de los Datos de la base de datos (DB) y no las BASES DE DATOS MIS 308 4 estructuras de almacenamiento que se necesitarán para manejar esta información. El modelo relacional representa un sistema de bases de datos en un nivel de abstracción un tanto alejado de los detalles de la máquina subyacente, de la misma manera como, por ejemplo, un lenguaje del tipo de PL/1 representa un sistema de programación con un nivel de abstracción un tanto alejado de los detalles de la máquina subyacente.
De hecho, el modelo relacional puede considerarse como un lenguaje de programación mas bien abstracto, orientado de manera específica hacia las aplicaciones de bases de datos [Date, 1993] En términos tradicionales una relación se asemeja a un archivo, una tupla a un registro, y un atributo a un campo. Pero estas correspondencias son aproximadas, en el mejor de los casos. Una relación no debe considerase como ``solo un archivo'', sino mas bien como un archivo disciplinado, siendo el resultado de esta disciplina una simplificación considerable de las estructuras de datos con las cuales debe interactuar el usuario, lo cual a su vez simplifica los operadores requeridos para manejar esas estructuras.
Características principales de los ``archivos'' relacionales:
• Cada ``archivo'' contiene solo un tipo de registros
• Los campos no tienen un orden específico, de izquierda a derecha
• Los registros no tienen un orden específico, de arriba hacia abajo
• Cada campo tiene un solo valor
• Los registros poseen un campo identificador único (o combinación de campos) llamado clave primaria Así, todos los datos en una base de datos relacional se representan de una y solo una manera, a saber, por su valor explícito (esta se denomina en ocasiones ``principio básico del modelo relacional'').
En particular, las conexiones lógicas dentro de una relación y entre las relaciones se representan mediante esos valores; no existen ``ligas'' o apuntadores visibles para el usuario, ni ordenamientos visibles para el usuario, ni grupos repetitivos visibles para el usuario, etc. Actualmente algunos de los manejadores de bases de datos, utilizan un sistema de búsqueda con algoritmos de árboles b.
Pero las búsquedas que se pueden realizar con estos algoritmos son sólo para memoria principal. Los algoritmos implementados para realizar búsquedas con listas salteadas o por bloques (skip lists) son eficientes para realizar búsquedas en memoria secundaria.
Como tienen varios niveles en cada BASES DE DATOS MIS 308 5 nodo de la lista, nos permite dar saltos mas largos al realizar las búsquedas, esto provoca que las sean mas rápidas. El primer paso para la definición del Problema l diseño de una base de datos es la producción del esquema conceptual.
Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la información.
Cada una de estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos humanos, etc. A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores.
El esquema conceptual también tendrá una documentación, que se irá produciendo durante su desarrollo. Las tareas a realizar en el diseño conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama entidad-relación.
8. Revisar el esquema conceptual local con el usuario El modelo Entidad-Relación (E/R) se basa en una representación del mundo real en que los datos se describen como entidades, relaciones y atributos.
El principal concepto del modelo ER es la entidad, que es una "cosa" en el mundo real con existencia independiente. Una entidad puede ser un objeto físico (una persona, un auto, una casa o un empleado) o un objeto conceptual (una compañía, un puesto de trabajo o un curso universitario).
En nuestro ejemplo de la sección anterior podemos definir dos entidades alumnos y cursos. Cada entidad tiene propiedades específicas, llamadas atributos, que la describen. Por ejemplo, una sala de clases tiene un nombre, una ubicación, un cupo máximo, etc. En nuestro ejemplo, la entidad "alumno" ASES DE DATOS MIS 308 6 posee los atributos nombre y matrícula. Una entidad particular tiene un valor para cada uno de los atributos.
Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. Por ejemplo, "matrícula" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres. Para todo conjunto de valores de una entidad, debe existir un atributo o combinación de atributos, que identifique a cada entidad en forma única.
Este atributo o combinación de atributos se denomina llave (primaria). Por ejemplo, el número de matricula es una buena llave para la entidad alumno, no así el nombre, porque pueden existir dos personas con el mismo nombre. Una relación se puede definir como una asociación entre entidades.
Por ejemplo, la entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relación "está pedido".
La entidad "alumno" puede estar relacionada con la entidad "curso" por la relación "está inscrito". Una relación también puede tener atributos. Por ejemplo, la relación "está inscrito" puede tener los atributos "semestre" y "nota de aprobación".
Pon el zoom en 150+ Para ver bien la imagen
Ejemplo:
DIAGRAMA FASES DISENO DB BASES DE DATOS MIS 308 7
Suponga que estamos modelando los datos de una COMPAÑIA. La base de datos COMPAÑIA debe mantener los Datos sobre los empleados de la compañía, los departamentos y los proyectos.
La descripción del minimundo (la parte de la compañía a ser representada en la base de datos) es la siguiente:
1. La compañía está organizada en departamentos. Cada departamento tiene un nombre único. Un número único, y un empleado particular quien lo administra. Se quiere saber la fecha en que el empleado administrador empezó a hacerse cargo del departamento. Un departamento puede tener varios locales.
2. Cada departamento controla un cierto número de proyectos. Cada proyecto tiene un nombre y número únicos, y un local.
3. Para cada empleado se desea tener su nombre, rut, dirección, salario, sexo y año de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios proyectos, los que no son necesariamente controlados por el mismo departamento. Se quiere saber el número de horas semanales que un empleado trabaja en cada proyecto. Se quiere además saber cuál es el supervisor directo de cada empleado.
4. Se desea conocer las personas dependientes de cada empleado para propósitos de seguros. De cada dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relación con el empleado. La siguiente figura muestra el esquema de esta base de datos, a través de una notación gráfica llamada diagrama ER.
es la igualdad Clave Primaria = Clave Externa (o Foránea), y la proyección elimina la columna duplicada (clave externa).
Apoderados
Alumnos 
Alumnos
Inscritos 
Cursos
Inscritos 
Alumnos
Resultado 1
Curso
Inscrito