ACTIVIDAD 04

Elementos de una base de datos utilizando el modelo relacional -

Diseño de bases de datos

NSTRUCCIONES:

Investiga qué elementos tiene una base de datos en el modelo relacional y descríbelos en un documento word, posteriormente
ejemplifica una base de datos en el modelo relacional.

El Modelo Entidad-Relación, también es conocido como DER (diagramas entidad-relación) es una herramienta de modelado
para bases de datos, propuesto por Peter Chen en 1976, mediante el cual se pretende ‘visualizar’ los objetos que pertenecen a
la Base de Datos como entidades (se corresponde al concepto de clase, cada tupla representaría un objeto, de la Programación
Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones.

Es una representación conceptual de la información. Mediante una serie de procedimientos se puede pasar del modelo E-R a
otros, como por ejemplo el modelo relacional.

El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas entidad relación. No es la única
técnica pero sí la más utilizada. Brevemente consiste en los siguientes pasos:

Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos).

Se hace una lista de los sustantivos y verbos que aparecen.

Los sustantivos son posibles entidades o atributos.

Los verbos son posibles relaciones.

Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.

Se elabora el diagrama (o diagramas) entidad-relación.

Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente
implementable en una base de datos. Brevemente:

Transformación de relaciones múltiples en binarias.

Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).

Conversión en tablas (en caso de utilizar una base de datos relacional).

Ejemplo de diagrama E-R.

Por otra parte los elementos de una base de datos relacional son:

Los datos se organizan en relaciones compuestas por tuplas de atributos. Si convertimos esta definición a tablas tenemos
que los datos se organizan en tablas compuestas por filas (registros) y columnas (campos).

A cada tabla se le asigna un nombre único.

Una tabla tiene 0 o más filas, y cada fila contiene la información de un determinado ‘sujeto’ de la relación.

Las filas en un principio están desordenadas.

La lista de los atributos dispuestos en un orden específico de izquierda a derecha y que forman la definición de una tabla
se denomina esquema de la tabla, mientras que los valores concretos de los datos que están almacenados en la tabla se
llaman ocurrencias.

Por ejemplo, tenemos estas dos tablas:

El esquema de la tabla Piezas está compuesto por las columnas (Código, Denominación, Precio, Fabricante,
Codigo_según_fab).

Código es el código de la pieza, Denominación el nombre de la pieza, Fabricante el código del fabricante que nos
suministra la pieza y Código_según_fab el código que utiliza ese fabricante para identificar la pieza en su sistema de
gestión.

Una ocurrencia de fila de la tabla Piezas sería:1, Taburete 3 patas, 25, Fab1, T123-34.

Todos los valores de una columna determinada tienen el mismo tipo de datos, y éstos están extraídos de un conjunto de
valores legales llamado dominio de la columna. Muchas veces el dominio se corresponderá con un tipo de datos estándar
del sistema.

Por ejemplo en la tabla Piezas la columna Código está definida sobre el dominio de los enteros.

A parte de los valores del dominio, la columna puede contener un valor especial, el valor nulo. 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” o la cadena vacía
o espacios en blanco. 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 un operador
especial (IS NULL). Incluso se han tenido que redefinir los operadores lógicos para tener en cuenta el valor nulo.

Ej. En la tabla Fabricantes el campo dirección de la primera fila contiene el valor nulo (null) esto significa que este
fabricante no tiene dirección (al menos conocida).

En una tabla cada columna tiene un único nombre y éste no se puede utilizar para nombrar otra columna de la misma
tabla, pero sí de otra tabla.

Por ejemplo, en la tabla Piezas no se pueden definir dos columnas llamadas Código, por eso el segundo código lo hemos
llamado Codigo_segun_fab. Pero en la tabla Fabricantes la columna IdFab se podía haber llamado Código sin problema.

En una tabla no se admiten dos filas con los valores coincidentes en todos sus campos. Esta restricción no se suele cumplir.

Esta regla nos dice que por ejemplo en la tabla Fabricantes no puede haber dos filas con los valores Fab1, Muebles la
Madera, null.
Realmente sería información redundante, por eso la existencia de esta regla, no obstante en algunos casos muy concretos
sí es necesario poder almacenar dos ocurrencias de fila idénticas, por esta razón muchos SGBD no cumplen esta regla.

Toda tabla debe tener una clave principal (clave primaria).

Una clave primaria es cualquier una columna (o combinación de columnas) que permite identificar de forma unívoca
cada una de las filas de la tabla. Para que pueda cumplir su cometido, la clave primaria no puede contener valores nulos
ni valores duplicados (no podrá haber dos filas con el mismo valor en este campo). Hay SGBD que incluyen el concepto
de clave primaria pero no la hacen obligatoria, por lo que en estos sistemas se pueden definir tablas sin clave primaria.

En una tabla pueden existir más de una columna que permita identificar las filas de la tabla, si queremos utilizar tales
columnas como identificadores las definiremos como claves secundarias (alternativas). Una clave secundaria tiene las
mismas restricciones que una clave primaria, pero como no podemos definir dos claves primarias, definimos la que se vaya
a utilizar más frecuentemente como clave primaria y la otra (u otras) como secundarias.

Por ejemplo en la tabla Piezas la clave primaria es el campo Código ya que no hay ni puede haber dos piezas con el
mismo código. Este campo realmente sirve para identificar las filas de la tabla, sabiendo un valor de código (por ejemplo
el 2) sabremos que nos referimos a la fila de la mesa ovalada.

En esta misma tabla tenemos una posible clave alternativa, la formada por los campos Fabricante y Codigo_segun_fab
ya que en la tabla Piezas es imposible tener dos filas con la misma combinación de valores en estos campos (el
código_segun_fab es el código que utiliza el fabricante para identificar sus piezas).

Otro concepto muy importante, fundamental en las bases de datos relacionales, es la clave ajena (externa o foránea).

Una clave ajena es un campo (o combinación de campos) que contiene la referencia a una fila de otra tabla, también
puede referirse a la misma tabla. En otras palabras, es un campo que señala a un registro de otra tabla, contiene un valor
que identifica un registro de la otra tabla. Son los campos que se utilizan para relacionar las tablas entre sí.

Una tabla puede tener 0, una o varias claves ajenas (externas, foráneas).

Una clave ajena puede contener valores duplicados y valores nulos.

Siguiendo el ejemplo anterior, en la tabla Piezas tenemos la clave ajena Fabricante ya que en este campo nos guardamos
un valor que señala a una fila de la tabla Fabricantes, en este campo tenemos el código del fabricante que nos suministra
la pieza y este código nos lleva al fabricante correspondiente en la tabla Fabricantes.

Por ejemplo la pieza 3 es servida por el fabricante Fab2, valor que señala al fabricante Maderas Asociados.

El SGBD deberá velar por la integridad de los datos, para ello incluye varias reglas de integridad que se comprobarán de
forma automática sin necesidad de la intervención externa de los usuarios o de los programas de aplicación.

Existen distintos tipos de reglas de integridad:

La integridad de entidades (integridad de claves): “Toda tabla debe tener una clave primaria que permite identificar
unívocamente los registros que contiene, por lo tanto no puede contener el valor nulo ni valores duplicados”.

En el ejemplo anterior si intentamos insertar una nueva pieza con el código 2, el sistema no nos dejará porque ya hay una
pieza con este mismo código en la tabla.

La integridad referencial: “En una clave ajena no puede haber un valor no nulo que no exista en la tabla de referencia”.
Para que no existan errores de integridad referencial 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.

Volviendo al ejemplo anterior, si intentamos insertar una pieza con un código de fabricante que no existe en la tabla de
fabricantes, el sistema no nos dejará.

A nivel de control sobre los datos, el SGBD debe de proporcionar herramientas para poder definir restricciones de dominio
que se comprobarán de forma automática (se comprueba que el valor introducido en una columna pertenece al dominio
de la columna, al tipo de datos), y reglas de negocio, que son reglas específicas sobre los datos, en este tipo de reglas
entran las reglas de validación y reglas definidas a nivel superior que veremos más adelante.

Una regla de validación sería por ejemplo que el precio no pueda ser inferior a 10 euros, y una regla de negocio, que no
pueda haber más de 20 fabricantes.
Un SGBD relacional sigue la arquitectura de tres niveles en la que tenemos en el nivel externo las vistas, en nivel conceptual
el esquema conceptual con la definición de todas las tablas, columnas que las componen y relaciones entre ellas, en el
nivel interno tenemos la definición física de la base de datos.