Make your own free website on Tripod.com

MODELOS DE DATOS

 

Coleccion de herramientas conceptuales que nos sirven para describir datos, las relaciones entre ellos y las definiciones asociadas a las mismas.
Modelos físicos Modelos lógicos
Para aquellos modelos que describen como los datos están almacenados. Nos presentan unos niveles de la base de datos: físico, coneptual y de visión.
 
 

MODELO ENTIDAD-RELACION (E-R)

   
se basa en la definición o percepción del mundo real a travez de unos objetos denominados entidades y las relaciones entre ellos .

Entidad: elemento diferenciable
concreto abstracto.

 

   

 

   
CLAVES

Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus atributos.

Una superclave es un atributo o un conjunto de atributos que identifican de modo único las tuplas de una relación.

Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relación. El atributo o conjunto de atributos K de la relación R es una clave candidata para R si y sólo si satisface las siguientes propiedades:

  • Unicidad: nunca hay dos tuplas en la relación R con el mismo valor de K.
  • Irreducibilidad (minimalidad): ningún subconjunto de K tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de K sin destruir la unicidad.

Cuando una clave candidata está formada por más de un atributo, se dice que es una clave compuesta. Una relación puede tener varias claves candidatas. Por ejemplo, en la relación OFICINA, el atributo Población no es una clave candidata ya que puede haber varias oficinas en una misma población. Sin embargo, ya que la empresa asigna un código único a cada oficina, el atributo Onum sí es una clave candidata de la relación OFICINA. También son claves candidatas de esta relación los atributos Teléfono y Fax.

En la base de datos de la inmobiliaria hay una relación denominada VISITA que contiene información sobre las visitas que los clientes han realizado a los inmuebles. Esta relación contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un número de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinación de los dos atributos sí identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habría que incluir el atributo Fecha para identificar las tuplas de modo único (aunque éste no es el caso de la empresa que nos ocupa).

Para identificar las claves candidatas de una relación no hay que fijarse en un estado o instancia de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia de duplicados en un estado de la base de datos sí es útil para demostrar que cierta combinación de atributos no es una clave candidata. El único modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la relación PLANTILLA se podría pensar que el atributo Apellido es una clave candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos empleados con el mismo apellido, el atributo no es una clave candidata.

La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave primaria estará formada por todos los atributos de la relación, pero normalmente habrá un pequeño subconjunto de los atributos que haga esta función.

Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas. Por ejemplo, la clave primaria de la relación OFICINA es el atributo Onum, siendo Teléfono y Fax dos claves alternativas. En la relación VISITA sólo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.

Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores coinciden con los valores de la clave primaria de alguna otra relación (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla referenciada).

 
   

 

   
El concepto de Agregación establece la relación con esa entidad que tiene toda la información.

con la agregación se desea saber especificamente que empleado en que proyecto en que maquinaria

 

Ejemplo Entidad-Relación.  
   
   

 

MODELO RELACIONAL (FISICO)

   

B.D relacional: Conjunto de tablas.

Fila: Conjunto de valores.

Tabla: Colección de filas.

Relación: Subconjunto de un producto cartesiano de dominios.

 

Atributos A1 A2 A3...An

Dominios D1 * D2* D3...Dn

   

 

   

DEFINICIÓN Y TERMINOLOGÍA DE UN RDBMS

Los sistemas de base de datos relacionales son aquellos que almacenan y administran de manera lógica los datos en forma de tablas. Una TABLA es, a su vez, un método para presentar los datos en la forma de filas y columnas.
Cada columna representa un campo único de un registro. Varias de estas columnas o campo componen un registro, proveyendo información significativa e interrelacionada. Cada registro es representado en una fila. Una tabla puede consistir en varias columnas. Muchas de las tablas que poseen datos interrelacionados e interdependientes son agrupadas por medio de el establecimiento de relaciones entre ellas. Al administrar las tablas y sus relaciones, encontramos los medios para insertar, borrar, consultar y actualizar la información de un sistema RDBMS.

TABLA EMPLEADOS

 

Num-emp

Nombre-emp

Num-depto

1001

Andrés

Ab101

1002

Maria

Ab102

1003

Jose

Ab103

TABLA DEPARTAMENTOS

 

Num-dept

Nombre-dept

Ab101

Finanzas

Ab102

Contabilidad

Ab103

ventas

En la tabla anterior, la tabla Empleados consiste en tres columnas y tres filas. Las columnas o campo conforman un registro lógico, correspondiente a un empleado. La tabla Empleados esta relacionada con la tabla de Departamentos por medio de una columna "Numero de Departamento" que aparece en ambas tablas.
Clave Primaria
Hemos visto que los datos son almacenados de manera lógica en tablas en la Bases de datos relacionales. Cada tabla tiene un nombre único. Para identificar una fila particular en una tabla, se usa una columna o combinación de columnas. Esta columna debe ser tal que identifique de manera única e inequívoca cada fila. No puede haber mas de dos filas (registros) en una tabla que tengan el mismo valor para la columna que haya sido elegida como clave primaria. Una columna identificada como la clave primaria no puede tener valores duplicados no nulos. Por ejemplo, considerando la tabla de Empleados presentada en la Figura No. 1, podemos ver que cada empleado tiene un único numero de empleado. La columna "NUM-EMP" puede ser escogida como la clave primaria. Similarmente, la columna "NUM-DEPT" en la tabla de Departamentos puede ser igualmente una clave primaria.

Clave Foránea

La clave primaria y la clave foránea son usadas para establecer relaciones entre tablas. En la Figura No. 1 el dominio de los valores de la columna "NUM-DEPT" de la tabla Empleados se encuentra dentro del rango de valores de la columna "NUM-DEPT" de la tabla Departamentos. Un empleado deber pertenecer a un Departamento que esté listado en la tabla Departamentos. Se considera entonces que la columna "NUM-DEPT" en la tabla Empleados es una clave foránea. De esta manera, la existencia de esta clave foránea en la tabla Empleados controla que no pueda ser ingresado un nuevo registro de un empleado si este no pertenece primero a un Departamento. Si el empleado que desea ingresarse a la tabla trabaja en un Departamento que no esta listado en la tabla Departamentos, primero debe crearse el registro del Departamento en su respectiva tabla, y luego si procedemos a ingresar al empleado. Este tipo de control que impone la asignación de una clave foránea en una tabla es de mucha utilidad para evitar la existencia de registros huérfanos y para evitar la incongruencia de datos, temas que veremos mas adelante. Además, como dijimos al principio, la clave foránea nos permite relacionar dos tablas, lo cual nos permite compartir y repartir la información de manera que no tengamos los mismos datos duplicados en varias tablas. Estos conceptos serán aterrizados en la sección de Normalización de tablas que se estudiará en un capitulo posterior.

Num-emp

Nombre-emp

Apellido

Cargo

Salario

Extensión

Num-dept

Empleados
 



Num-dept

Nombre-dept

Ubicación

departamentos
Hemos establecido la siguiente convención: En los esquemas de tablas, las claves primarias están subrayadas. Igualmente diagramaremos restricciones de integridad referencial a través de líneas de conexión que van desde cada clave foránea hasta la clave primaria que referencie. Para que haya mejor claridad, la punta de la flecha deberá apuntar hacia la clave primaria de la tabla referenciada.

Nulos

Un Nulo se puede interpretar como un valor indefinido o como ningún valor. Los nulos son usados en las columnas donde se desconozca su valor. Un nulo no significan espacios en blanco. Un valor "nulo" no puede ser usado para hacer ningún cálculo u operaciones de comparación. Un "nulo" puede ser comparable a un infinito. Un "nulo" no es igual a otro "nulo".

Vistas

Los RDBMS gestionan la estructura física de los datos y su almacenamiento. Con esta funcionalidad, el RDBMS se convierte en una herramienta de gran utilidad. Sin embargo, desde el punto de vista del usuario, se podría discutir que los RDBMS han hecho las cosas más complicadas, ya que ahora los usuarios ven más datos de los que realmente quieren o necesitan, puesto que ven la base de datos completa. Conscientes de este problema, los RDBMS proporcionan un mecanismo de vistas que permite que cada usuario tenga su propia vista o visión de la base de datos. El lenguaje de definición de datos permite definir vistas como subconjuntos de la base de datos. Las vistas, además de reducir la complejidad permitiendo que cada usuario vea sólo la parte de la base de datos que necesita, tienen otras ventajas:

  • Las vistas proporcionan un nivel de seguridad, ya que permiten excluir datos para que ciertos usuarios no los vean. Las vistas proporcionan un mecanismo para que los usuarios vean los datos en el formato que deseen.
  • Una vista representa una imagen consistente y permanente de la base de datos, incluso si la base de datos cambia su estructura.
 
   
Ejemplo Modelo relacional.  
   
   
   

DEFINICIÓN DE NORMALIZACION

Normalización es una serie de reglas que involucra análisis y transformación de las estructuras de los datos en relaciones que exhiban propiedades únicas de consistencia, mínima redundancia y máxima estabilidad.
La necesidad para normalizar puede ser mejor comprendida al mencionar las distintas anomalías o desventajas de los datos NO NORMALIZADOS. Consideremos la tabla en la figura 3. La tabla contiene todos los detalles de los empleados de una compañía, y los detalles del Departamento al que pertenecen.


NumEmp

nombre

Salario

Ingresa

numDept

descDept

1001

Andrés

$500.000

1-Ene-01

Ab101

Sistemas

1002

Maria

$700.000

16-Mar-02

Ab101

Sistemas

1003

Carlos

$350.000

5-Dic-01

Ab101

Finanzas

1004

Felipe

$800.000

15-Jun-01

Ab103

Finanzas

1005

Oscar

$500.000

1-Ene-03

Ab102

Contabilidad

1006

Marta

$700.000

5-Dic-01

Ab104

Ventas

1007

Beatriz

$800.000

1-Ene-01

Ab110

Gerencia

A primera vista, parece conveniente almacenar todos los detalles en una sola tabla. Pero ciertas anomalías se pueden manifestar durante la inserción, actualización y borrado de datos. La normalización provee un método de remover todas estas indeseables anomalías haciendo la base de datos mas confiable y estable.

Anomalía de inserción (INSERT)

Suponga que un nuevo Departamento ha sido creado, el cual no tiene empleados todavía, por lo tanto, en nuestra tabla original, los datos correspondientes al empelado estarían vacíos (nulos), y solo tendríamos la información del Departamento: Columnas "numDept" y "descDept".
Anomalía de Actualización (UPDATE)
Suponga que el número del Departamento de "Sistemas" ha sido cambiado a AB108. Esto involucra tener q1ue cambiar el numero del departamento para todos los empleados que pertenezcan al departamento de "Sistemas", lo cual representa tiempo y recursos de sistema adicionales.
Anomalía de borrado (DELETE)
Si todos los empleados en el Departamento de "Finanzas" abandonan la compañía, todos los registros de estos tendrían que ser borrados. Hecho así, los detalles del Departamento "Finanzas" se perderían. Los datos en la tabla entonces no representan una información correcta sobre el estado de la compañía, y por lo tanto se pierde la integridad de los datos.
PROPIEDADES DE UNA BASE DE DATOS DESPUÉS DE LA NORMALIZACION
Una base de datos normalizada debe representar las siguientes propiedades:

  • Los requerimientos para almacenamiento de datos se minimizan, dado que el proceso de normalización sistemáticamente elimina la duplicación de los datos.
  • Desde que los datos son almacenados en el mínimo número de lugares, las posibilidades de inconsistencias en la información son reducidas al mínimo.
  • Las estructuras normalizadas son óptimas para efectuar actualizaciones de los datos. Dado que los datos existen en el mínimo número de lugares, una operación de actualización (UPDATE) necesitará acceder a una mínima cantidad de datos.

PROCEDIMIENTOS DE NORMALIZACION
El proceso de normalización involucra básicamente tres pasos. Después de cada paso, la base de datos se convierte en formas llamadas "formas normales". Generalmente, la "tercera forma normal" es el estado que debe alcanzar una base de datos para que se diga que está totalmente normalizada. La cuarta y la quinta forma normal también existen, pero no son usadas en el diseño de una base de datos.
A continuación, consideremos un pequeño ejercicio acerca de un Documento de Orden de Compra, el cual trataremos de convertirlo a una forma normalizada. Pero antes explicaremos unas pequeñas reglas:

Propiedades de una relación

Una tabla debe satisfacer ciertos criterios previos antes de calificar para convertirse en una relación

No duplicados

No debe haber nunca dos columnas o filas totalmente idénticas. Si dos filas son totalmente idénticas, entonces hacen falta algunos atributos que las haga diferentes y distinguibles. Ejemplo: Dos registros de discos compactos en una tienda serían idénticos si son dos copias del último álbum de Shakira, si no fuera porque cada disco compacto tiene un numero código que los hace diferentes.

Clave Única

Cada registro tiene que tener una clave única que lo identifique. Cualquier atributo puede ser una clave, pero en lo posible trataremos de elegir como clave única al atributo que tenga una longitud menor y fija, como por ejemplo un numero de ID. Si un atributo es insuficiente para identificar un registro de manera única, entonces mas de un atributo puede conformar la clave única. En tal caso, el número de atributos que conformen una clave debe ser el mínimo necesario y suficiente.

 

Insignificancia del orden

La secuencia en la cual los atributos son escritos no debe importar. Podemos escribir el ID del empleado de primero, o el nombre y el apellido de primero, y esto no afectará las relaciones que establezcamos con otras tablas. Por otro lado, los registros deben ser totalmente independiente de su secuencia o posición en la base de datos (dependencia posicional). Esto significa que si intentamos identificar un registro por su posición dentro de la tabla, estaremos creando una clave inválida.

Forma no-normalizada

Los datos, en su forma elemental, no están normalizados. Por lo tanto, lo primero con lo que debemos comenzar es con los datos elementales o básicos que conformarán el diccionario de datos. El diccionario de datos es creado a partir de los documentos o diagramas de flujo de la compañía. Se deben listar los elementos uno debajo del otro. Así, obtendremos la forma no-normalizada para el ejercicio de ARD (Análisis Relacional de Datos), con el cual deberemos obtener al final distintos grupos de elementos. Mas tarde, dichos grupos se combinarán con los grupos de otros documentos al cual también se les ha hecho el análisis ARD, y se establecerán relaciones entre ellos.