Data Warehousing: Introducción

 

Desde que se inició la era de la computadora, las organizaciones han usado los datos desde sus sistemas operacionales para atender sus necesidades de información. Algunas proporcionan acceso directo a la información contenida dentro de las aplicaciones operacionales. Otras, han extraído los datos desde sus bases de datos operacionales para combinarlos de varias formas no estructuradas, en su intento por atender a los usuarios en sus necesidades de información.

Ambos métodos han evolucionado a través del tiempo y ahora las organizaciones manejan una data no limpia e inconsistente, sobre las cuales, en la mayoría de las veces, se toman decisiones importantes.

La gestión administrativa reconoce que una manera de elevar su eficiencia está en hacer el mejor uso de los recursos de información que ya existen dentro de la organización. Sin embargo, a pesar de que esto se viene intentando desde hace muchos años, no se tiene todavía un uso efectivo de los mismos.

La razón principal es la manera en que han evolucionado las computadoras, basadas en las tecnologías de información y sistemas. La mayoría de las organizaciones hacen lo posible por conseguir buena información, pero el logro de ese objetivo depende fundamentalmente de su arquitectura actual, tanto de hardware como de software.

El data warehouse, es actualmente, el centro de atención de las grandes instituciones, porque provee un ambiente para que las organizaciones hagan un mejor uso de la información que está siendo administrada por diversas aplicaciones operacionales.

Un data warehouse es una colección de datos en la cual se encuentra integrada la información de la Institución y que se usa como soporte para el proceso de toma de decisiones gerenciales. Aunque diversas organizaciones y personas individuales logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que existen muchas dificultades potenciales.

Reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un ambiente integral centralizado, simplifica el problema de acceso a la información y en consecuencia, acelera el proceso de análisis, consultas y el menor tiempo de uso de la información.

Las aplicaciones para soporte de decisiones basadas en un data warehousing, pueden hacer más práctica y fácil la explotación de datos para una mayor eficacia del negocio, que no se logra cuando se usan sólo los datos que provienen de las aplicaciones operacionales (que ayudan en la operación de la empresa en sus operaciones cotidianas), en los que la información se obtiene realizando procesos independientes y muchas veces complejos.

Un data warehouse se crea al extraer datos desde una o más bases de datos de aplicaciones operacionales. La data extraída es transformada para eliminar inconsistencias y resumir si es necesario y luego, cargadas en el data warehouse. El proceso de transformar, crear el detalle de tiempo variante, resumir y combinar los extractos de datos, ayudan a crear el ambiente para el acceso a la información Institucional. Este nuevo enfoque ayuda a las personas individuales, en todos los niveles de la empresa, a efectuar su toma de decisiones con más responsabilidad.

La innovación de la Tecnología de Información dentro de un ambiente data warehousing, puede permitir a cualquier organización hacer un uso más óptimo de los datos, como un ingrediente clave para un proceso de toma de decisiones más efectivo. Las organizaciones tienen que aprovechar sus recursos de información para crear la información de la operación del negocio, pero deben considerarse las estrategias tecnológicas necesarias para la implementación de una arquitectura completa de data warehouse.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MODELO DE DATOS:

Introducción

 

Desde tiempos remotos, los datos han sido registrados por el hombre en algún tipo de soporte (piedra, papel, madera, etc.) a fin de que quedara constancia de una fenómeno o idea. Los datos han de ser interpretados para que se conviertan en información útil, esta interpretación supone un fenómeno de agrupación y clasificación.

En la era actual y con el auge de los medios informáticos aparece el almacenamiento en soporte electromagnético, ofreciendo mayores posibilidades de almacenaje, ocupando menos espacio y ahorrando un tiempo considerable en la búsqueda y tratamiento de los datos. Es en este momento donde surge el concepto de bases de datos y con ellas las diferentes metodologías de diseño y tratamiento.

El objetivo básico de toda base de datos es el almacenamiento de símbolos, números y letras cadentes de un significado en sí, que con un tratamiento adecuado se convierten en información útil. Un ejemplo podría ser el siguiente dato: 19941224, con el tratamiento correcto podría convertirse en la siguiente información: "Fecha de nacimiento: 24 de diciembre de 1994".

Según van evolucionando los tiempos, las necesidades de almacenamiento de datos van creciendo y con ellas las necesidades de transformar los mismos datos en información de muy diversa naturaleza. Esta información es utilizada diariamente como herramientas de trabajo y como soporte para la toma de decisiones por un gran colectivo de profesionales que toman dicha información como base de su negocio. Por este motivo el trabajo del diseñador de bases de datos es cada vez más delicado, un error en el diseño o en la interpretación de datos puede dar lugar a información incorrecta y conducir al usuario a la toma de decisiones equivocadas. Se hace necesario la creación de un sistema que ayude al diseñador a crear estructuras correctas y fiables, minimizando los tiempos de diseño y explotando todos los datos, nace así la metodología de diseño de bases de datos.

La metodología de diseño de datos divide cada modelo en tres esquemas:

A) Modelo Global: se trata de una representación gráfica legible por el usuario y que nos aporta el flujo de información dentro de una organización. No existen reglas para su construcción y se debe realizar siempre el esquema más sencillo posible para la comprensión por parte del usuario de la base de datos. Por ejemplo:



B) Modelo Lógico: se trata de una representación gráfica, mediante símbolos y signos normalizados, de la base de datos. Su objetivo es representar la estructura de los datos y las dependencias de los mismos, garantizando la consistencia y evitando la duplicidad. Este modelo de datos se estudiará con profundidad en los capítulos siguientes.

C) Modelo Físico: se trata del almacén de los datos, es la base de datos en sí misma, el soporte donde se almacenan los datos y de donde se extraen para convertir los datos en información. En función del gestor de bases de datos empleado las reglas de almacenamiento varían.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Los Usuarios

En todo sistema de base de datos cabe diferenciar tres tipos diferentes de usuarios, entre todos comparten la información pero acceden a ella de una forma diferente, siempre en función de sus necesidades.

El primer grupo de usuarios es el PED (Procesamiento Electrónico de Datos), normalmente compuestos por los operarios de la organización. Las necesidades básicas de este grupo de usuarios son:

§   El foco operativo fundamental se centra en el almacenamiento de los datos, el procesamiento de los mismos y el flujo de datos;

§   Generan informes de tipo listados;

§   Poseen acceso restringido a la información.

El segundo grupo de usuarios es el SIM (Sistemas de Información de Gestión) y suele estar formado por los mandos medios de la organización. Las necesidades básicas de este grupo de usuarios son:

§   El foco operativo se fundamenta en la toma de decisiones, tomando como partida los datos del grupo PED e introduciendo un volumen pequeño de información;

§   No poseen acceso medianamente restringido a la información;

§   Generan informes de resúmenes de datos del grupo PED y listados de la información que introducen.

El tercer último grupo de usuarios lo forman el STD (Sistema de apoyo a Toma de Decisiones), este grupo se centra en el nivel más alto de la organización y poseen las características siguientes:

§   El foco operativo se centra en la decisión, con una entrada mínima de datos;

§   No tienen acceso restringido;

§   Generan informes globales que les sirven como apoyo a las tomas de decisiones del negocio, estos son los informes más importantes y suelen ir acompañados de resúmenes, gráficas y sobre todo centrados en la evolución y comparación de la información.

Cabe destacar la figura de un cuarto grupo de usuarios, en este caso usuarios avanzados, que está compuesto por los administradores del sistema, cuya opinión es fundamental para seleccionar el soporte de los datos, evitar la duplicación de información ya existente en otros sistemas y sobre todo puede aportar el conocimiento de sus usuarios, sus necesidades y los problemas ya resueltos.

En general, podemos decir que los objetivos de una base de datos son los siguientes:

§   Ayudar en la toma de decisiones;

§   Compartir de forma controlada y restringida los datos y el acceso a la información;

§   Integrar los datos de una forma lógica, evitando la duplicidad;

§   Asegurar un rápido acceso a la información y los datos.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Introducción

Las bases de datos relacionales son el tipo de bases de datos actualmente más difundido. Los motivos de este éxito son fundamentalmente dos:

1.     ofrecen sistemas simples y eficaces para representar y manipular los datos

2.     se basan en un modelo, el relacional, con sólidas bases teóricas

El modelo relacional fue propuesto originariamente por E.F. Codd en un ya famoso artículo de 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido en los años 80 en el más usado para la producción de DBMS.

La estructura fundamental del modelo relacional es precisamente esa, "relación", es decir una tabla bidimensional constituida por líneas (tuple) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la entidad encontrará sitio en una tupla de la relación, mientras que los atributos de la relación representarán las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, se podrá definir una relación llamada "Personas", cuyos atributos describen las características de las personas (tabla siguiente). Cada tupla de la relación "Personas" representará una persona concreta.

Persona

Nombre

Apellido

Nacimiento

Sexo

Estado Civil

Juan

Loza

15/06/1971

H

Soltero

Isabel

Galvez

23/12/1969

M

Casada

Micaela

Ruiz

02/10/1985

M

Soltera

En realidad, siendo rigurosos, una relación es sólo la definición de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se puebla con las tuplas, se habla de "instancia de relación". Por eso, la tabla anterior representa una instancia de la relación persona. Una representación de la definiticón de esa relación podría ser la siguiente:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil)

A continuación, se indicarán ambas (relación e instancia de relación) con el término "relación", a no ser que no quede claro por el contexto a qué acepción se refiere.

Las tuplas en una relación son un conjunto en el sentido matemático del término, es decir una colección no ordenada de elementos diferentes. Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de atributos que permiten identificar unívocamente una tupla en una relación. Naturalmente, en una relación puede haber más combinaciones de atributos que permitan identificar unívocamente una tupla ("llaves candidatas"), pero entre éstas se elegirá una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitirían identificar una tupla concreta en una relación. Esta propiedad de las relaciones y de sus llaves primarias está bajo el nombre de integridad de las entidades (entity integrity).

A menudo, para obtener una llave primaria "económica", es decir compuesta de pocos atributos fácilmente manipulables, se introducen uno o más atributos ficticios, con códigos identificativos unívocos para cada tupla de la relación.

Cada atributo de una relación se caracteriza por un nombre y por un dominio. El dominio indica qué valores pueden ser asumidos por una columna de la relación. A menudo un dominio se define a través de la declaración de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero también es posible definir dominios más complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacion "Personas" podemos definir un dominio por el cual los únicos valores válidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren válidas sólo las fechas de nacimiento después del uno de enero de 1960, si en nuestra base de datos no está previsto que haya personas con fecha de nacimiento anterior a esa. El motor de datos se ocupará de controlar que en los atributos de las relaciones se incluyan sólo los valores permitidos por sus dominios. Característica fundamental de los dominios de una base de datos relacional es que sean "atómicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios más simples. Más formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una característica de las personas en nuestra base de datos fuese la de tener uno o más hijos, no sería posible escribir la relación Personas de la siguiente manera:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

En efecto, el atributo hijos es un atributo no-atómico, bien porque una persona puede tener más de un hijo o porque cada hijo tendrá diferentes características que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones:

Personas (*número_persona, nombre, apellido, fecha_nacimiento, sexo, estado_civil)
Hijos(*número_persona, *nombre_apellido, edad, sexo)

En las relaciones precedentes, los asteriscos (*) indican los atributos que componen sus llaves primarias. Nótese la introducción en la relación Personas del atributo número_persona, a través del cual se asigna a cada persona un identificativo numérico unívoco que se usa como llave primaria. Estas relaciones contienen sólo atributos atómicos. Si una persona tiene más de un hijo, éstos se representarán en tuplas diferentes de la relación Hijos. Las diferentes características de los hijos las representan los atributos de la relación Hijos. La unión entre las dos relaciones está constituida por los atributos número_persona que aparecen en ambas relaciones y que permiten que se asigne cada tupla de la relación hijos a una tupla concreta de la relación Personas. Más formalmente se dice que el atributo número_persona de la relación Hijos es una llave externa (foreign key) hacia la relación Personas. Una llave externa es una combinación de atributos de una relación que son, a su vez, una llave primaria para otra relación. Una característica fundamental de los valores presentes en una llave externa es que, a no ser que no sean null, tienen que corresponder a valores existentes en la llave primaria de la relación a la que se refieren. En nuestro ejemplo, esto significa que no puede existir en la relación Hijos una tupla con un valor del atributo número_persona sin que también en la relación Personas exista una tupla con el mismo valor para su llave primaria. Esta propiedad va bajo el nombre de integridad referencial (referential integrity).

Una de las grandes ventajas del modelo relacional es que define también un álgebra, llamada "álgebra relacional". Todas las manipulaciones posibles sobre las relaciones se obtienen gracias a la combinación de tan sólo cinco operadores: RESTRICT, PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido también tres operadores adicionales que de todos modos se pueden obtener aplicando los cinco fundamentales: JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben como argumento una relación o un conjunto de relaciones y restituyen una única relación como resultado.

Veamos brevemente estos ocho operadores:

RESTRICT: restituye una relación que contiene un subconjunto de las tuplas de la relación a la que se aplica. Los atributos se quedan como estaban.

PROJECT: restituye una relación con un subconjunto de los atributos de la relación a la que viene aplicado. Las tuplas de la relación resultado se componen de las tuplas de la relacion original, de manera que siguen siendo un conjunto en sentido matemático.

TIME: se aplica a dos relaciones y efectúa el producto cartesiano de las tuplas. Cada tupla de la primera relación está concatenada con cada tupla de la segunda.

JOIN: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un conjunto de sus atributos.

UNION: aplicando este operador a dos relaciones compatibles, se obtiene una que contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el mismo número de atributos y los atributos correspondientes en las dos relaciones tienen el mismo dominio.

MINUS: aplicado a dos relaciones compatibles restituye una tercera que contiene las tuplas que se encuentran sólo en la primera relación.

INTERSECT: aplicado a dos relaciones compatibles restituye una relación que contiene las tuplas que existen en ambas.

DIVIDE: aplicado a dos relaciones que tengan atributos comunes, restituye una tercera que contiene todas las tuplas de la primera relación que se puede hacer que correspondan con todos los valores de la segunda relación.

En las siguientes tablas, a título de ejemplo, se representan los resultados de la aplicación de algunos operadores relacionales a las relaciones Personas e Hijos. Como nombres para las relaciones resultado se han utilizado las expresiones que las producen.

Personas

número_persona

nombre

apellido

fecha_nacimiento

sexo

estado_civil

2

Mario

Rossi

29/03/1965

M

Casado

1

Giuseppe

Russo

15/11/1972

M

Soltero

3

Alessandra

Mondella

13/06/1970

F

Soltera

 

Hijos

número_persona

nombre_apellido

edad

sexo

2

Maria Rossi

3

F

2

Gianni Rossi

5

M

 

RESTRICT (Personas)
sesso='M'

número_persona

nombre

apellido

fecha_nacimiento

sexo

estado_civil

2

Mario

Rossi

29/03/1965

M

Casado

1

Giuseppe

Russo

15/11/1972

M

Soltero

 

PROJECT sexo (Personas)
sexo
M
F
RESTRICT (Personas)
sexo='M'

n.

nombre

apellido

nacimiento

sexo

stado_civil

nombre

edad

sexo

Mario

Rossi

apellido

29/03/1965

M

Csado

Maria Rossi

3

F

Mario

Rossi

Apellido

29/03/1965

M

Casado

Gianni Rossi

5

M

Las bases de datos relacionales efectúan todas las operaciones en las tablas usando el álgebra relacional, aunque normalmente no le permiten al usuario usarla. El usuario interacciona con la base de datos a través de una interfaz diferente el lenguaje SQL, un lenguaje declarativo que permite escribir conjuntos de datos. Las instrucciones SQL vienen descompuestas por el motor de datos en una serie de operaciones relacionales.

 

Las interrelaciones

Las interrelaciones son las relaciones que existen entre varias tablas del sistema (Clientes y Pedidos, por ejemplo). Existen tres formas de interrelaciones dependiendo de la cardinalidad con la que se combinan los elementos de ambas tablas.

Interrelaciones uno a uno

Una interrelación es de uno a uno entre la tabla A y la tabla B cuando a cada elemento de la clave de A se le asigna un único elemento de la tabla B y para cada elemento de la clave de la tabla B contiene un único elemento en la tabla A. Un ejemplo de interrelación de este tipo es la formada por las tablas Datos Generales de Clientes y Datos Contables de Clientes. En esta relación cada cliente tiene una única dirección y una dirección en cada una de las tablas. Representamos la relación como A 1: 1 B.

Ante la presencia de este tipo de relación nos podemos plantear el caso de unificar todos los datos en única tabla pues no es necesario mantener ambas tablas a la misma vez.

Este tipo de relación se genera cuando aparecen tablas muy grandes, con gran cantidad de campos, disgregando la tabla principal en dos para evitar tener una tabla muy grande. También surge cuando los diferentes grupos de usuario cumplimentan una información diferente para un mismo registros; en este caso se crean tantas tablas como registros, evitando así tener que acceder a información que el usuario del grupo actual no necesita.

Interrelaciones uno a varios

Una interrelación es de uno a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee un único elemento relacionado en la tabla A.

Estudiemos la relación entre la tabla de clientes y la tabla de pedidos. Un cliente puede realizar varios pedidos pero un pedido pertenece a un único cliente, por tanto se trata de una relación uno a varios y la representamos A 1: n B.

Estas relaciones suelen surgir de aplicar la 1NF a una tabla.

Interrelaciones varios a varios

Una interrelación es de varios a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A.

Un caso muy característico de esta interrelación es la que surge entre las tablas de Puestos de Trabajo y Empleados de una empresa. Un Empleado puede desempeñar realizar varias funciones dentro de una empresa (desempeñar varios puestos de trabajo), y un puesto de trabajo puede estar ocupado por varios empleados a la misma vez. Esta interrelación la representamos como A n: n B.

No se deben definir relaciones de este tipo en un sistema de bases de datos, debido a su complejidad a la hora de su mantenimiento, por este motivo se debe transformar este tipo de relación es dos interrelaciones de tipo 1: n, empleando para ello una tabla que denominaremos puente y que estará formada por las claves de ambas tablas. Esta tabla puente debe contener una única clave compuesta formada por los campos clave de las tablas primeras.

Empleados

Puestos

Código Empleado

Empleado

Código Puesto

Puesto

103

Juan

52

Comercial

105

Luisa

73

Administrativo

251

Martín

 

 

736

Ana María

 

 

Tabla Puente

Código Empleado

Código Puesto

103

52

103

73

105

73

251

52

736

52

736

73

Ahora existe una relación 1: n entre Empleados y Tabla Puente y otra relación 1: n entre Puestos y Tabla Puente ya que un empleado posee varios códigos de empleado en la tabla puente pero cada elemento de la tabla puente pertenece a un único empleado.

Por otro la un puesto de trabajo posee varios elementos relacionados en la tabla puente, pero cada elemento de la tabla puente está relacionado con un único elemento de la tabla puestos.

Problemas con las interrelaciones

A la hora de establecer las interrelaciones existentes en un sistema de bases de datos nos podemos encontrar dos problemas:

1.     Interrelaciones recursivas: un elemento se relaciona consigo mismo directamente.

2.     Interrelaciones circulares o cíclicas: A se relaciona con B, B se relaciona con C y C se relaciona con A.

Ambos casos pueden suponer un grabe problema si definimos una relación con integridad referencial y decimos eliminar en cascada (al eliminar una clave de la tabla A se eliminan los elementos relacionados en la tabla B). Supongamos la relación recursiva existen en la relación Empleado y Supervisor (ambos son empleados de la empresa). Está claro que un empleado está supervisado por otro empleado. Veamos la forma de solucionarlo:

Empleados

Código

Nombre

Supervisor

102

Juan

NO

105

Luis

SI

821

María

NO

956

Martín

SI

Para solucionar la relación debemos crear una tabla formada por dos campos. Ambos campos deben ser el código del empleado pero como no podemos tener dos campos con el mismo nombre a uno de ellos le llamaremos código supervisor.

Tabla Puente

Código Empleado

Código Supervisor

102

105

105

956

821

105

956

105

Para terminar de resolver la interrelación recursiva basta con definir dos interrelaciones entre la tabla empleados y la tabla puente de tipo 1: n. La primera relación se crea utilizando las claves Empleados[Código] y Tabla Puente[Código Empleado]. La segunda entre Empleados[Código] y Tabla Puente [Código Supervisor].

Las interrelaciones cíclicas o circulares no son muy frecuentes y no existe una metodología estándar para su eliminación, normalmente son debidas a errores de diseño en la base de datos, principalmente en el diseño conceptual del sistema de datos. Por tanto si llegamos a este punto hay que volver a replantearse todo el diseño de la base de datos.

Atributos de las interrelaciones

En la mayoría de las interrelaciones definidas será conveniente exigir integridad relacional entre las claves. Exigiendo la integridad referencial se consigue que en una relación de tipo 1: n o de tipo 1: 1, no se puede añadir ningún valor en la tabla destino si no existe en la tabla origen. Dicho con un ejemplo: en la relación Clientes y Pedidos la tabla Pedidos contiene un campo que se corresponde con el código del Cliente, si se exige la integridad referencia no se podrá escribir un código de cliente en la tabla Pedidos que no exista en la tabla Clientes; de no exigir la integridad referencial se podrán crear pedidos con códigos de clientes que no existen, generando incongruencia de datos en la base de datos.

Definida la integridad referencial (siempre necesaria) podemos exigir la actualización en cascada (siempre necesaria); esta actualización implica que si cambiamos el código a un cliente, debemos actualizar dicho código en la tabla de pedidos, de no ser así, al cambiar el código a un cliente, perderemos los pedidos que tenía realizados.

Para concluir debemos hablar de la eliminación en cascada (NO siempre necesaria), la eliminación en cascada consiste en eliminar todos los datos dependientes de una clave. En nuestro ejemplo implica que al borrar un cliente hay que eliminar todos los pendidos que ha realizado. En muchas ocasiones no interesa realizar esta operación de eliminación en cascada por motivos diversos. Si en el caso de clientes y pedidos no se exige eliminación en cascada no se podrá borrar ningún cliente en tanto en cuanto tenga realizado algún pedido (de lo contrario tendríamos incongruencia de datos).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Entidades

Se puede definir cono entidad a cualquier objeto, real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información, por ejemplo: "PROFESOR", "CURSO", "ALUMNO". Las entidades las podemos clasificar en:

 

A.     Regulares: aquellas que existen por sí mismas y que la existencia de un ejemplar en la entidad no depende de la existencia de otros ejemplares en otra entidad. Por ejemplo "EMPLEADO", "PROFESOR". La representación gráfica dentro del diagrama es la siguiente:

B.     Débiles: son aquellas entidades en las que se hace necesaria la existencia de ejemplares de otras entidades distintas para que puedan existir ejemplares en esta entidad. Un ejemplo sería la entidad "ALBARÁN" que sólo existe si previamente existe el correspondiente pedido. La representación gráfica dentro del diagrama es la siguiente:

 

Como complemento al diagrama de entidades del modelo de datos, podemos utilizar la siguiente plantilla para definir las diferentes entidades:

Nombre

PROFESOR

Objeto

Almacenar la información relativa de los profesores de la organización.

Alcance

Se entiende como profesor a aquella persona que, contratada por la organización, imparte, al menos, un curso dentro de la misma.

Número de ejemplares

10 profesores

Crecimiento previsto

2 profesores / año

Confidencialidad
  1. Nombre y apellidos: Acceso público.
  2. Datos personales: Acceso restringido a secretaría y dirección.
  3. Salario: Acceso restringido a dirección.

Derechos de Acceso

Para garantizar la total confidencialidad de esta entidad, el sistema de bases de datos deberá solicitar un usuario y una contraseña para visualizar los elementos de la misma.

Observaciones

Los ejemplares dados de baja no serán eliminados de la base de datos; pasarán a tener una marca de eliminado y no serán visualizados desde la aplicación.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

El modelo lógico

Bases de datos-Modelo de datos-El modelo lógico

Anteriormente se expuso el ciclo de vida del desarrollo de una base de datos. Este capítulo se centrará en el diseño del modelo lógico de los datos, por tanto antes de comenzar esta modelación es necesario tener documentado las necesidades, viabilidad y definición de los requisitos, así como tener elaborado el modelo global o conceptual del diseño.

El paso del modelo global o conceptual de datos al modelo lógico supone una abstracción, un mecanismo para la conversión del mundo real a un mundo formado por datos, a su agrupación y clasificación. El proceso de abstracción consiste en identificar los elementos ó conceptos empleados en el modelo global y transformarlo en lo que denominamos entidades en el modelo lógico. La abstracción se puede realizar de las siguientes formas:

Clasificación

Consiste en generar una única entidad conceptos con características comunes, todos ellos tendrán las mismas características y se diferencian unos de otros por los valores que toman dichas características. Por ejemplo: los conceptos cursos de inglés, cursos de español y cursos de francés se pueden agrupar en una única entidad denominada "CURSOS" que englobe y diferencie cada uno de los diferentes cursos que se imparten.

 

Agregación

Consiste en separar cada una de las partes de un concepto para generar distintas entidades, por ejemplo el concepto coche lo podemos definir utilizando las entidades rueda, motor y chasis.

 

Generalización

Consiste en ir generado entidades de diferentes niveles de tal forma que cada entidad de nivel superior agrupe las de nivel inferior.

 

Asociación

Consiste en la generalización de entidades a partir de entidades ya existentes.