MODELO DE DATOS E/R

Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos.
Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.

quedarían como sigue:


¿Cómo se pasa del esquema E/R a las tablas?

       Para cada entidad del esquema se creará una tabla con tantos campos como atributos tenga la entidad. Ejemplo:

Tabla 'TRABAJADOR'

DNINUM_SSnombre-apellidos...     
11111111XXXXXXXXXXXFulano de tal...
22222222YYYYYYYYYYYMengano de cual...
........................
       Las relaciones 1-1 se pueden reflejar incluyendo en una de las dos tablas un campo en el que poder colocar la clave del elemento de la otra tabla con el que se está relacionado. Ese nuevo campo que se incluye en la tabla recibe el nombre de clave ajena. Ejemplo:

Tabla 'HOMBRE'

DNINombre...     
11111111......
22222222......
.........

Tabla 'MUJER'

DNINombre...     DNI-ESPOSO
33333333......11111111
44444444...... (nulo)
............
       Donde el campo DNI-ESPOSO es clave ajena de la tabla HOMBRE. Aquí hay que hacer notar que el campo DNI-ESPOSO puede tomar o bien un valor nulo, en el caso de aquellas mujeres que no estén casadas, o bien el valor de alguno de los DNI de la tabla HOMBRE, en el caso de las mujeres casadas; en este segundo caso, ese DNI (la clave ajena) no se deberá repetir en ningún otro registro de la tabla MUJER.
       Las relaciones 1-n se representan de forma muy parecida a como se ha explicado para las relaciones 1-1. La diferencia está en que ahora no es indiferente donde se coloque la clave ajena, esta debe estar obligatoriamente en la tabla del 'mucho' (n); y además, para este caso si se permitirá que haya valores repetidos en dicho campo. Ejemplo:

Tabla 'EMPRESA'

CIFNombre...     
XX-1111-AA......
YY-2222-BB......
.........

Tabla 'TRABAJADOR'

DNINombre...     CIF
11111111......XX-1111-AA
22222222......YY-2222-BB
33333333......YY-2222-BB
44444444...... XX-1111-AA
............
       Para representar las relaciones n-n en tablas lo que se hace es crear una nueva tabla solamente para la relación. Esta nueva tabla tendrá dos claves ajenas y su propia clave estará formada por la unión de las claves ajenas. Ejemplo:

Tabla 'ALUMNO'

DNINombre...     
11111111......
22222222......
.........

Tabla 'ASIGNATURA'

COD-ASIGNATURANombre...     
01......
02......
.........

Tabla 'MATRÍCULA'(esta es la relación)

DNICOD_ASIGNATURANOTA
11111111017.5
11111111026.25
22222222015.5
22222222028
.........
       En la tabla MATRÍCULA es donde se refleja la relación. La clave de dicha tabla está formada por los campos DNI y COD-ASIGNATURA ; y cada uno de ellos es clave ajena, el primero de ALUMNO y el segundo de ASIGNATURA. Hacer ver aquí que la tabla MATRICULAS puede tener más campos además de los que son clave ajena como ocurre en el ejemplo; la tabla añade además un campo NOTA.

ATRIBUTOS Y DOMINIOS




Los atributos, tanto de entidades como de relaciones, toman sus valores posibles de un conjunto llamado dominio. El dominio es, entonces, el conjunto de valores posibles que puede tomar un atributo dado de un conjunto de entidades dado. Por ejemplo, la fecha de nacimiento de una persona puede ser una fecha cualquiera anterior a la fecha actual. El dominio de las fechas de nacimiento, entonces, es el subconjunto de fechas que son anteriores (o iguales, en algunos casos) a la fecha de hoy. El dominio de los números de teléfono, en Chile, podría ser una cadena de caracteres que cumpliera con el formato (XX) XXX-XXXX (simplificado), donde las X son dígitos. En general los dominios serán más bien amplios, aunque cuando se lleva a cabo la implementación es preferible restringir los dominios lo más posible de manera que el gestor de bases de datos automáticamente haga algunas verificaciones sobre los datos que se almacenan, para asegurar la integridad de los datos. Veremos cómo hacer esto en la sección siguiente.
Algunos atributos de un conjunto de entidades son especiales. De partida es necesario definir cuáles de ellos son opcionales y cuáles son obligatorios. Como el nombre lo indica, un atributo obligatorio es aquel que siempre debe estar definido para toda entidad. Un atributo opcional, en cambio, puede quedar sin definir para algunas de las entidades del conjunto de entidades. En general, es deseable que la mayor cantidad de atributos posible se definan como obligatorios, puesto que permite simplificar mucho algunas operaciones, al tiempo que asegura una mejor integridad de los datos. Veremos más sobre esto en la sección siguiente.
Otro concepto importante relacionado con los atributos es el de las llaves. Una superllave de una entidad es un atributo o conjunto de atributos que permite distinguir de modo único cada entidad dentro de un conjunto de entidades. Por ejemplo, el nombre y RUT de una persona sería una superllave. Sólo el nombre no podría serlo, puesto que dos personas pueden tener el mismo nombre. Un conjunto de entidades puede tener más de una superllave; otra superllave para personas podría ser el nombre, la fecha de nacimiento y la dirección postal, puesto que es muy improbable que dos personas hayan nacido el mismo día, vivan en la misma casa y se llamen igual; pero omitiendo cualquiera de esos atributos es razonable esperar encontrar coincidencias.
Además, una superllave puede contener más atributos de los necesarios para identificar unívocamente cada entidad. Eliminando los atributos innecesarios de las superllaves se obtienen las llaves candidatas. Por ejemplo, en el caso del nombre y RUT, usando sólo el RUT serviría también como superllave, y por lo tanto como llave candidata. Observe que todos los atributos que forman una llave candidata son obligatorios, puesto que si falta alguno, no es posible identificar completamente la entidad.
Finalmente, se escoge una de las llaves candidatas y se designa como llave primaria del conjunto de entidades.
Algunos conjuntos de entidades pueden no tener atributos suficientes para formar una llave primaria. En este caso, se dice que es un conjunto de entidades débil. Un ejemplo claro sería un modelo para almacenar facturas de venta de bienes o servicios. Cada factura en sí es una entidad fuerte; cada línea dentro de una factura es una entidad débil, puesto que no se puede identificar una línea en particular sino en tanto pertenece a una factura. Así cada factura tendría una línea número 1, una línea número 2, etc; por lo tanto, hablamos de una línea en particular como la línea número 5 de la factura número 18.289.
En nuestro ejemplo anterior, todos los conjuntos de entidades son fuertes, puesto que sus elementos cuentan con los atributos suficientes para ser identificados unívocamente. Para ilustrar este nuevo concepto, incluiremos en nuestro modelo los datos de los experimentos que se publican en cada artículo para obtener observaciones sobre las hipótesis que los autores plantean. Cada artículo puede utilizar uno, ninguno o varios experimentos; algunos experimentos serán similares o iguales entre artículos; no hay ningún código asociado intrínsecamente a un experimento, ni modo alguno de distinguirlos de forma unívoca entre todos los artículos. Pero dentro de cada artículo, cada experimento es único. Así, un experimento tendrá un atributo obligatorio que le permitirá ser discriminado de entre el conjunto de experimentos de un mismo artículo (por ejemplo, el número que el mismo autor le asigna en el artículo).
La figura 5 ilustra el nuevo diagrama E-R. Observe que el conjunto de entidades de experimentos se ha marcado como un rectángulo doble, lo cual indica que es débil.




Image ent-rel-debil
Con respecto a las llaves primarias de nuestro modelo de ejemplo, los conjuntos de entidades fuertes tienen por definición llaves primarias. Sin embargo, en muchos casos estas llaves primarias son complejas de implementar. En el caso de las personas chilenas, usar el RUT es una elección natural. Para personas de otros países, la elección se torna complicada: se podría escoger como llave primaria un número identificador por país en conjunto con el país que emite dicho número. Este esquema puede verse en problemas si existe algún país que no emite números identificadores para sus habitantes. Asimismo, identificar un artículo es complejo: el uso del título no es suficiente, puesto que otro artículo podría llevar el mismo título. Una elección teóricamente mejor sería el uso del resumen como llave primaria, elección que en la práctica es irrisoria cuando menos. Para resolver este problema práctico agregaremos a cada una de estos conjuntos un identificador numérico, ficticio, único dentro de cada conjunto de entidades, independiente de cada uno de los identificadores de los otros conjuntos. Este identificador se generará internamente en la base de datos, y no tendrá ningún significado fuera de ella. Una convención usual es ponerle el nombre del conjunto de entidades, en singular, seguido de id, como en autor_id.

RECURSIVAS

Una interrelación recursiva es una interrelación en la que alguna entidad está asociada más de una vez.

Ejemplo de interrelación recursiva Si, para una entidad persona, queremos tener constancia de qué personas están actualmente casadas entre ellas, será necesario definir la siguiente interrelación, que asocia dos veces la entidad persona:persona

Una interrelación recursiva puede ser tanto binaria como n-aria

1)  Interrelación  recursiva  binaria:  interrelación  en  la  que  las  ocurrencias asocian dos instancias de la misma entidad*. Las interrelaciones binarias recursivas pueden tener conectividad 1:1, 1:N o M:N, como todas las binarias. En esta interrelación también es posible expresar la dependencia de existencia igual que en el resto de las interrelaciones binarias

Ejemplo de interrelación recursiva binaria

La interrelación boda tiene conectividad 1:1 porque un marido está casado con una sola mujer y una mujer está casada con un solo marido. También tiene un círculo en los dos lados
(según la dependencia de existencia), porque puede haber personas que no estén casadas.

En una interrelación recursiva, puede interesar distinguir los diferentes papeles que una misma entidad tiene en la interrelación. Con este objetivo, se puede etiquetar cada línea de la interrelación con un rol. En las interrelaciones no recursivas normalmente no se especifica el rol; puesto que todas las entidades interrelacionadas son de clases diferentes, sus diferencias de rol se sobreentienden.

Roles diferentes

Una ocurrencia de la interrelación boda asocia a dos personas concretas. Para reflejar el papel diferente que tiene cada una de ellas en la interrelación, una de las personas tendrá el rol de marido y la otra tendrá el rol de  mujer.                                              Entidades asociativas

persona1

Algunas interrelaciones recursivas no presentan diferenciación de roles; entonces, las líneas de la interrelación no se etiquetan.
        
No-diferencia de roles
Consideremos una interrelación amistad que asocia a personas concretas que son amigas. A diferencia de lo que sucedía en la interrelación boda, donde una de las personas es el marido y la otra la mujer, en este caso no hay diferenciación de roles entre las dos personas interrelacionadas. A continuación se muestra esta interrelación. Observad que su conectividad es M:N, teniendo en cuenta que una persona puede tener muchos amigos y, al mismo tiempo, puede haber muchas personas que la consideran amiga.
                                                    
2)  Interrelación recursiva n-aria: interrelación recursiva en la que las ocurrencias asocian más de dos instancias.
Ejemplo de interrelación recursiva ternaria
Consideremos una interrelación que registra todas las bodas que se han producido a lo largo del tiempo entre un conjunto de personas determinado. Esta interrelación permite tener constancia no sólo de las bodas vigentes, sino de todas las bodas realizadas en un cierto periodo de tiempo.
                                                     
Esta interrelación es recursiva y ternaria. Una ocurrencia de la interrelación asocia a una persona que es el marido, a otra que es la mujer y la fecha de su boda. La conectividad es N:1:1.
A los lados del marido y de la mujer les corresponde un 1, porque un marido o una mujer, en una fecha determinada, se casa con una sola persona. Al lado de la entidad fecha le corresponde una N, porque se podría dar el caso de que hubiese, en fechas diferentes, más de una boda entre las mismas personas.


En este subapartado veremos un mecanismo que nos permite considerar una interrelación entre entidades como si fuese una entidad.


La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.



La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

Ejemplo de entidad asociativa

La figura siguiente muestra un ejemplo de entidad asociativa:
            

Recorrido es una interrelación de conectividad M:N que registra las ciudades por donde han pasado los diferentes viajes organizados por una empresa de reparto de paquetes. Consideramos recorrido una entidad asociativa con el fin de interrelacionarla con la entidad cliente; de este modo nos será posible reflejar por orden de qué clientes se han hecho repartos en una ciudad del recorrido de un viaje, así como el número de paquetes cargados y descargados siguiendo sus indicaciones.
El mecanismo de las entidades asociativas subsume el de las entidades débiles
y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.

Ejemplo de sustitución de una entidad débil por una asociativa
A continuación se muestra la entidad débil despacho, que tiene la interrelación asignación con la entidad empleado.
                                               

Podríamos modelizar este caso haciendo que despacho fuese una entidad asociativa si consideramos una nueva entidad número-despacho que contiene simplemente números de despachos. Entonces, la entidad asociativa despacho se obtiene de la interrelación entre edificio ynúmero-despacho.
Aunque las entidades débiles se puedan sustituir por el mecanismo de las entidades asociativas, es adecuado mantenerlas en el modelo ER porque resultan menos complejas y son suficientes para modelizar muchas de las situaciones que se producen en el mundo real

TEORÍA DE RELACIONES

 

Otra de las características importantes que hay que tener en cuenta en este modelo es la cardinalidad de cada extremo en una relación. La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están relacionadas con cuántas entidades del conjunto del otro extremo. Pueden ser ``uno a uno'', ``uno a varios'' o ``varios a varios''. Por ejemplo, un artículo puede ser escrito por un solo autor o por varios, pero nunca por ninguno; un autor puede pertenecer a exactamente una institución (no para cero o varias); un artículo puede tener cero, uno o varios experimentos. Finalmente, un autor puede escribir muchos artículos, o ninguno. Observe que las cardinalidades en algunos casos dependen de restricciones arbitrarias: se podría decidir aceptar sólo aquellos autores que han escrito al menos un artículo (y con esto cambiaría la última regla mencionada); hemos decidido considerar sólo la institución primaria para la cual un determinado autor trabaja (y esto ha determinado nuestra segunda regla).
Hay varias maneras de mostrar las cardinalidades en el diagrama. Una de ellas es poner etiquetas en las líneas que unen las relaciones con las entidades. La etiqueta consiste de un mínimo y un máximo, cada uno de los cuales contiene un cero, un uno o una letra n (``varios''). Si la cardinalidad es exactamente uno, se pone sólo el uno. En el caso de una relación varios a varios, lo usual es poner una m en un extremo y una n en el otro.

Image ent-rel-card




Lo más usual es que las relaciones ocurran entre dos conjuntos de entidades. Esto no es siempre así: en algunos casos puede haber relaciones entre tres o incluso más entidades. Esto no tiene ninguna particularidad teórica; simplemente es una situación peculiar que hay que tener presente que puede existir. Note que si bien es razonable esperar tener relaciones entre tres conjuntos de entidades, cuando surgen relaciones entre cuatro de ellos hay que poner atención al modelo, ya que esto puede indicar alguna debilidad.

Para ilustrar el concepto, supongamos que algunas instituciones otorgan fondos a los autores, para financiar su trabajo en algún artículo. Cada bono de financiamiento se otorga a un autor individual para que trabaje en un artículo; no cubre otros autores del mismo artículo, ni otros artículos del mismo autor. Estos bonos tienen como atributos la fecha en que son entregados y el monto del que consisten. La manera más sencilla de modelar esta situación es incorporar una relación entre autores, artículos e instituciones. 
Image ent-rel-completo


MODELO FÍSICO ENTIDAD RELACIONAL

MODELO LÓGICO RELACIONAL

El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. 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.
Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados «tuplas». Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, esto es, pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o tupla), y columnas (también llamadas campos).

Descripción
En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.
Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo.
Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional permite describir la forma de realizar una consulta, en cambio, el Cálculo relacional sólo indica lo que se desea devolver.

Esquema

Un esquema es la definición de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relación y que tipo de información podrá ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación. Todo esquema constará de:
  • Nombre de la relación (su identificador)
  • Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

 Instancias

Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos. En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento dado, pero también es valido referirnos a una instancia cuando trabajamos o mostramos únicamente un subconjunto de la información contenida en una relación o tabla, como por ejemplo:
  • Ciertos caracteres y números (una sola columna de una sola fila).
  • Algunas o todas las filas con todas o algunas columnas
  • Cada fila es una tupla. El número de filas es llamado cardinalidad.
  • El número de columnas es llamado aridad o grado.

Base de datos relacional

Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros (líneas) y campos (columnas), que se vinculan entre sí por un campo en común, en ambos casos posee las mismas características como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional.
Estrictamente hablando el término se refiere a una colección específica de datos pero a menudo se le usa, en forma errónea como sinónimo del software usado para gestionar esa colección de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del inglés relational database management system).
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera óptima.
Entre las ventajas de este modelo están:
  1. Garantiza herramientas para evitar la duplicidad de registros, a través de campos claves o llaves.
  2. Garantiza la integridad referencial: Así al eliminar un registro elimina todos los registros relacionados dependientes.
  3. Favorece la normalización por ser más comprensible y aplicable.

EL MODELO DE DATOS ENTIDAD-RELACION (E/R)





Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos

Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.



Entidades y Relaciones

       El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:
  • Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
    • Que sea única.
    • Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada cliente un número de cliente?.
    • Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
  • Relación.- Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:
    • Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
    • Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN).
    • Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).

Ejemplos
 Relación muchos a muchos.

Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color  - Tarjeta de circulación -Propietario, No_serie, Tipo.

  
  
              
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.

    En este ejemplo, representamos que existe un solo presidente para cada país.

     Relación muchos a muchos.

 El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero  que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona).

         

ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES






Es la estructura más utilizada actualmente. En ella los datos están estructurados en tablas:

- Cada fila es un registro o entidad.
- Cada columna es un campo de ese registro.
Esta estructura es similar al concepto matemático de relación, por ello ha tenido tanto auge, ya que todas las teorías y reglas matemáticas sobre relaciones son aplicables, lo que hace que sea fácil de formalizar. 
A la tabla se le llama relación, y a cada fila tupla; a cada columna de una tupla se le llama atributo, es en esto en lo que se diferencia del modelo matemático. 


  • Los nombres de relaciones siempre en minúsculas.
  • Cada tupla se puede representar por una variable de tupla.
  • Cada atributo se representa por su nombre.
  • Cardinalidad = Nº de tuplas de una relación.
  • Grado = Nº de atributos de la relación.
  • Cada atributo puede tomar valores dentro de su dominio de atributo (Conjunto de valores posibles)
  • El esquema de una relación se representa en letras mayúsculas: r(R) donde r sería el nombre de la relación y R el nombre del esquema.
  • Formato de un esquema: Nom_esquema=(lista de atributos con sus dominios).
  • Ejemplo:
    Alumnos = (dni: dom_dni; nombre: dom_nombre; edad: dom_edad).
    Obsérvese que la primera letra de Alumnos es mayúscula (es un esquema).
  • Esquema = Definición global y general de una relación.
  • Instancia de una relación = Información que contiene una relación en un momento determinado.

Claves en el Modelo Relacional

Debe existir un atributo o conjunto de atributos que identifique de un modo único a una tupla; a ese atributo se le llamaría superclave (puede ser el conjunto formado por todos los atributos), al menos hay uno siempre.
Para una r(M) diremos que un subconjunto de atributos (K) del esquema será clave de la relación si para toda tupla t1 ≠ t2 se cumple que t1[k] ≠ t2[k] (es decir, dadas dos tuplas diferentes el valor de la clave también lo es).
Dentro de las superclaves, llamaremos claves candidatas a las superclaves más pequeñas (aquellas superclaves que carecen de subconjuntos propios que sean también superclaves).De entre todas las que haya, es el usuario el que decide cual es la primaria, las demás se llaman alternativas.
Reglas de Integridad:

  1. Integridad de Identidad:La clave primaria de una relación no puede contener valores nulos.
  2. Integridad de Referencia:Cuando en una relación hay un atributo que hace referencia a una clave primaria de otra relación, el atributo debe tener un valor coincidente con alguno de la clave primaria o como mucho ser nulo (es decir, no puede tener un valor que no exista entre los valores de la clave primaria en la primera relación).

Propiedades

Miden su grado de bondad/aproximación al modelo real matemático por una serie de "formas normales", según se sube en las formas se dice que la relación está mejor diseñada. Al menos debe estar en la primera forma normal (1NF) y para ello debe cumplir:
  • No hay duplicación de tuplas.
  • No hay orden entre las tuplas.
  • No hay orden entre los atributos (se accede a través de su nombre).
  • No existen atributos que no sean atómicos (una casilla un dato). Es decir, no existe la posibilidad de tener una tabla como la siguiente:





AlumnoAsignatura
JoséCálculo
Algebra
Física
no es correcta, sin embargo si lo es esta otra:
AlumnoAsignatura
JoséCálculo
JoséAlgebra
JoséFísica
Por último, decir que existe la posibilidad de tratar relaciones entre sí a través de atributos comunes, esto evita la duplicación de la información. Dividimos un esquema en más de uno.

Ejemplo: Alumno = (nombre: dom_nombre; nº: entero)
Asignatura = (nº: entero; asignatura:dom_asignatura).
En este caso el campo común entre las relaciones es el campo nº:







NombreNúm.
José
15
Antonio
17
Pedro
18

Num.Asignatura
15
Cálculo
15
Algebra
15
Física
 
Lenguajes de Consulta a Bases e Datos Relacionales

Los podemos dividir en dos tipos: Lenguajes Formales y Lenguajes Comerciales. Los lenguajes formales están basados en el álgebra relacional o en elcálculo relacional. Solamente se han descrito para consulta a Bases de Datos (existen lenguajes comerciales que además de consulta permiten otras operaciones). 
El álgebra relacional tiene procedimientos (procedimental), mientras que los lenguajes basados en el cálculo relacional son aprocedimentales. Dentro del cálculo relacional se distingue entre cálculo relacional orientado a tuplas y cálculo relacional orientado a dominios.
Los lenguajes comerciales, en su mayoría usan enfoques tanto procedimentales como aprocedimentales, o lo que es lo mismo, no son lenguajes puros como los formales. De esta manera hacen su sintaxis más amigable al usuario.

ARCHIVOS


Files
Field (campo)
Record (registro)
Field (archivo)
Database ( Base de Datos)
Un campo (Field) es el elemento de datos básico. Un campo individual contiene un valor único. Esta caracterizado por su longitud y por el tipo de datos. Dependiendo del diseño del archivo, los campos pueden ser de tamaño fijo o variable. Un campo pueden contener un subcampo.
Registro (Record) es una colección de campos relacionados que pueden tratarse como una única unidad por un programa de aplicación. Por ejemplo:, un registro de empleados va contener campos como nombre, numero de seguridad social, etc.
También dependiendo del diseño, los registros pueden ser de longitud fija o de longitud variable. Un registro va a tener una longitud variable si algunos de los campos son de tamaños variables o si el numero de campos es variable. Cada campo tiene un nombre de campo.
Archivo (File) es una colección de registros similares. El archivo es tratado como una entidad individual por los usuarios y las aplicaciones y puede ser referenciada por el nombre. Los archivos tienen nombres únicos y pueden crearse y borrarse. En un sistema compartido, los usuarios y los programas tienen garantizado o denegado el acceso a archivos completos. En algunos sistemas más complejos, dicho control se aplica a los registros o a los campos.
Base de datos(database) es una colección de datos relacionados. El aspecto esencial de la base de datos es que la relación que existe entre los elementos de datos es explícita y la base de datos es diseñada para usarse en un numero diferente de aplicaciones. Una base de datos puede contener toda la información relacionado a una organización o proyecto, corno un estudio de mercado o científico. La base de datos consiste en uno o más tipos de archivos.
Los usuarios y aplicaciones desean usar los archivos. Las operaciones típicas que deben soportarse incluyen las siguientes:
Recuperar Todo ( Retrieve_all): Recuperar todos los registros de un archivo. Esto va a requerir de una aplicación que deba procesar toda la información de un archivo una vez.. Esta opcion es usualmente equivalente con el termino de sequential proccessing, ( proceso secuencial), porque todos los registros son accedidos en secuencia.
Recuperar_Uno (Retrieve_One): Esta operacion requiere la recuperación de un solo un registro. Las
soluciones interactivas orientadas a la transacción necesitan esta operación.
Recuperar_siguiente (Retrieve_Next): Esta operación implica la recuperación del registro que es el siguiente ,según una secuencia lógica, el recuperado hace menos tiempo. Un programa que realice búsquedas puede usar también esta operación.
Recuperar Previo (Retrieve_Previous): Es similar a Recuperar Siguiente, pero en este caso el registro que es "previo" al que se esta accediendo en el momento actual.
Insertar Uno (Insert One): Inserta un nuevo registro dentro del archivo. Es necesario que el nuevo registro se ajuste a una posición particular para preservar la secuencia del archivo.
Borrar uno (Delete One): Borra un registro existente. Ciertos enlaces o otras estructuras
puede que necesiten actualizarse para preservar la secuencia del archivo.
Actualizar Uno ( Update_one): Recupera un registro o actualiza uno o más de sus campos, y rescribe la actualización en el archivo. Es necesario preservar la secuencia con esta operación. Sí el tamaño del registro esta cambiado, la operación de actualización es más difícil si el tamaño es preservado.
Recuperar Varios (Retrieve_ Few): Recupero un numero de registros.
La naturaleza de las operaciones que comúnmente se ejecutan. sobre un archivo va a influenciar sobre el modo en que se va a organizar el mismo.
Sistemas de Gestión de Archivos (File Management Sytems)
Un sistema de gestión de archivos es aquel sistema software que provee servicios a los usuarios y aplicaciones en el uso de archivos. El único camino que tiene el usuario o la aplicación tiene para acceder a los archivos es a través de un sistema de gestión de archivos. Esto revela para el usuario o programador la necesidad de desarrollar software de propósito especial para cada aplicación y provee al sistema un medio de controlar su ventaja más importante.
Objetivos
Tratar las estructuras y principales características de los sistemas de archivos.

Estos son los objetivos de un sistema de gestión de archivos:
Cumplir con las necesidades de gestión de datos y con los requisitos del usuario, que incluye el almacenamiento de, datos y la capacidad de ejecutar las operaciones en la lista precedente.
Garantizar, en la medida de lo posible, que el dato en el archivo es valido.
Optimizar el rendimiento, ambos desde el punto de vista del sistema en términos de productividad global, y como punto de vista del usuario en tiempos de respuesta.
Para proveer soporte de E/S para una variedad de tipos de dispositivos de almacenamiento.
Para minimizar o eliminar la posibilidad de perdida o destrucción de datos.
Para proveer un conjunto estándar de rutinas de E/S.
Para proveer soporte de E/S para múltiples usuarios, en caso de sistemas multiusuarios.
1.4) Arquitectura de los sistemas de Archivos
Funciones de la gestión de archivos (File management Functions)
 Los usuarios y las aplicaciones interactúan con el sistema de archivos mediante comandos para crear y borrar archivos y realizar operaciones sobre los archivos. Antes de ejecutar alguna operación, los archivos del sistema deben identificar y localizar el archivo seleccionado. Esto requiere el uso de alguna clase de directorio que es reservado para describir la localización de todos los archivos, mas sus atributos. Además , la mayoría de los sistemas compartidos aplican algún control de acceso a los usuarios: solamente los usuarios autorizados están permitidos para acceder a archivos particulares en determinados lugares. Las operaciones básicas que el usuario o el programa puede ejecutar sobre un archivo se puede realizar a nivel de registro. El usuario o la aplicación ve el archivo con una estructura que organiza los registros, como una estructura secuencial. De este modo, para traducir las ordenes del usuario a ordenes específicas de manipulación de archivos., debe emplearse el método de acceso apropiado para esta estructura de archivo.
  
( File System Architecture)
Un camino para hacerse una idea del alcance de la gestión de archivos es de mirar una representación típica de la organización del software, como se muestra en la figura de abajo:
Diferentes sistemas van a tener diferente organizaciones pero estas organizaciones son razonablemente representativas. A un nivel mas bajo los manejadores de dispositivos (device drivers) se comunican directamente con los dispositivos de periféricos o con sus canales o controladores. Un controlador de
dispositivos es responsable de iniciar las operaciones de E/S en un dispositivo y procesar la terminación de una petición de E/S. Para operaciones de archivos, el controlador típico de dispositivos son discos y unidades de cinta. Los manejadores de los dispositivos son usualmente considerados como parte del sistema operativo.
El próximo nivel esta referido con el nombre de sistema de archivos básicos ( basic file system), o nivel de E/S física ( physical I/O) . Esta es la interfase primaria con el ambiente fuera del sistema de la computadora. Este nivel trata con bloques de datos que son intercambiados con sistemas de disco o cinta. De este modo. se preocupa de ubicar dichos bloques en el dispositivo de almacenamiento secundario y del almacenamiento intermedio de los mismos en memoria principal. Este nivel no comprenderá el contenido de los datos o la estructura de los archivos implicados. El sistema de archivos básicos es usualmente considerado como parte del sistema operativo.
El supervisor básico de E/S (Basic I/O supervisor) es el responsable de la iniciación y terminación de todas las E/S con archivos. En este nivel, hay unas estructuras de control que se encargan de la entrada y de salida con los dispositivos la planificación y el estado de los archivos. El supervisor básico de E/S se encarga de seleccionar el dispositivo donde se va a realizar la E/S con los archivos dependiendo del archivo seleccionado. También se encarga de la planificación de los accesos a disco y cinta para optimizar el rendimiento. En este nivel se asignan los buffers de E/S y se reserva la memoria secundaria. El supervisor básico de E/S es parte del sistema operativo.
La E/S lógica habilita a los usuarios y aplicaciones de acceder a registros. Así mientras el sistema de archivos básico trabaja con bloques de datos. el modulo lógico de E/S trabaja con el archivo de registros. La E/S lógica provee una capacidad de E/S de registro de propósito general y mantiene los datos básicos acerca de los archivos.
El nivel del sistema de archivo mas cercano de usuario es usualmente el método de acceso (access method). Provee una interfase estándar entre aplicaciones y los archivos del sistema a dispositivos que guarden datos. Los diferentes métodos de acceso reflejan los diferentes estructuras de datos y diferentes maneras de acceder y procesar el dato.
Organización y acceso a archivos (File organizittion and access)
En esta parte vamos a usar el termino organización de archivos para referirnos a la estructura lógica de los registros determinada por la manera en que se accede a ellos. La organización fisica del archivo en almacenamiento secundario depende de la estrategia de agrupación y de la estrategia de asignación de archivos.
Para seleccionar una organización de archivos hay diversos criterios que son importantes: 
  • Acceso Rápido para recuperar la información
  • Fácil actualización
  • Economia de almacenamiento
  • Mantenimiento simple.
  • Fiabilidad para asegurar la confianza de los datos.
  • La prioridad relativa de estos criterios va a depender de las aplicaciones que va a usar el archivo.
El numero de alternativas de organización de archivos que se han implementado o propuesto es inmanejable, incluso para un libro dedicado a los sistemas de archivos.
La mayor parte de las estructuras empleadas en los sistemas reales se encuadran en una de estas categorias o puede implementarse como una combinación de estas:
TIPOS DE ARCHIVOS 
  • Pilas (The pile)
  • Archivos secuenciales (sequential file)
  • Archivos Secuenciales indexados. (indexed sequential file)
  • Archivos indexados.(indexed file)
  • Archivos directos o de dispersión (direct, or hashed, file).
 Pilas
 La forma menos complicada de organización de archivos puede denominarse la pila. Los datos se recolectan en el orden en que llegan. Cada registro consiste en una ráfaga de datos. El propósito de la pila es simplemente acumular la masa de datos y guardarlo.
Como no hay estructura para el archivo de la pila. el acceso a registro es por búsqueda exhaustiva..Si se quiere todos los registros que contienen un campo particular o que tienen un valor determinado para ese campo, debe buscarse en el archivo entero.
 Los archivos de pilas se aplican cuando los datos se recogen y almacenan antes de procesarlos o cuando no son fáciles de organizar. Este tipo de archivo usa bien el espacio cuando los datos almacenados varían en tamaño y en estructuras. Este tipo de archivos no se adapta a la mayoría de las aplicaciones.
Archivos Secuenciales indexados
 Un método popular para superar las desventajas de los archivos secuenciales es el del archivo secuencias indexado. El archivo secuencial indexado mantiene las caracteristicas básicas de los archivos secuenciales: los registros están organizados en una secuencia basada en un campo. Dos características se añaden: un índice del archivo para soportar los accesos aleatorios y un archivo de desbordamiento ( overflow ). El indice provee una capacidad de búsqueda para llegar rapidamente a las proximidades de un registro deseado. El archivo de desbordamiento (overflow) es similar al archivo de registro usado en un archivo secuencial, pero esta intregrado de forma que los registros del archivo de desbordamiento se ubican en la dirección de un puntero desde si registro precedente. En la estructura secuencial indexada mas simple, se usa un solo nivel de indexacion. El indice, en este caso, es un archivo secuencial simple. Cada registro del archivo indice tiene dos campos: un campo clave, que es el mismo que el campo clave del archivo principal y un puntero al archivo principal. Para encontrar un campo especifico se busca en el indice hasta encontrar el valor mayor de la clave que es igual o precede al valor deseado de la clave. La busqueda continua en el archivo principal a partir de la posición indicada por el puntero.
Archivos Secuenciales 
La forma mas común de estructura de archivo es el archivo secuencial. En este tipo de archivo, un formato fijo es usado para los registros. Todos los registros tienen el mismo tamaño, constan del mismo numero de campos de tamaño fijo en un orden particular. Como se conocen la longitud y la posición de cada campo, solamente los valores de los campos se necesitan almacenarse; el nombre del campo y longitud de cada campo son atributos de la estructura de archivos.
 Un campo particular, generalmente el primero de cada registro se conoce como el campo clave. El campo clave identifica unívocamente al registro. así, los valores de la clave para registros diferentes son siempre diferentes.
Los archivos secuenciales son típicamente utilizados en aplicaciones de proceso de lotes Y son óptimos para dichas aplicaciones si se procesan todos los registros. La organización secuencias de archivos es la única que es fácil de usar tanto en disco como en cinta. 
Para las aplicaciones interactivas que incluyen peticione s o actualizaciones de registros individuales, los archivos secuenciales ofrecen un rendimiento pobre.
 Normalmente un archivo secuencial se almacena en bloques, en un orden secuencial simple de los registros. La organización física del archivo en una cinta o disco se corresponde exactamente con la ubicación lógica del archivo. En este caso, el procedimiento para ubicar los nuevos registros en un archivo de pila separado, llamado archivo de registro (log file) o archivo de transacciones. Periódicamente, se realiza una actualización por lotes que mezcla el archivo de registro con el archivo maestro para producir un nuevo archivo en secuencia correcta de claves.
Archivos Directos o de Dispersión
 Los archivos directos explotan la capacidad de los discos para acceder directamente a cualquier bloque de dirección conocida. Como en los archivos secuenciales y secuenciales indexados, se requiere un campo clave en cada registro. Sin embargo, aquí no hay concepto de ordenamiento secuencial.
Archivos Indexados
 Los archivos secuenciales indexados retienen la limitación del archivo secuencial: la eficacia en el procesamiento se limita al basado en un único campo del archivo. Cuando es necesario buscar un registro basándose en algún otro atributo distinto del campo clave ambas formas de archivo secuencial no son adecuadas. En algunas aplicaciones esta flexibilidad es deseable.
Para alcanzar esta flexibilidad, se necesita una estructura que utilice múltiples índices, uno para cada tipo de campo que pueda ser objeto de la búsqueda.
Se suelen utilizar dos tipos de índices. Uno indice exhaustivo contiene una entrada par cada registro del archivo principal. Otro índice parcial contendrá entradas a los registros donde este el campo de interés. Con registros de longitud variable, algunos registros no contendran todos los campos.
Los archivos indexados son muy utilizados en aplicaciones donde es critica la oportunidad de la informacion y donde los datos son rara vez procesados de forma exhaustiva.