Man Base Datos I

INACAP Dirección Área de Informática

MANUAL

Bases de Datos I
MARZO DEL 2002

Programa de Estudios:
INGENIERÍA EN GESTIÓN INFORMÁTICA
ANALISTA PROGRAMADOR

Versión 3.0 -0- Bases de Datos I

INACAP Dirección Área Informática

INDICE

Tema Página
1. Enfoques de Bases de Datos 4
1.1 Enfoque tradicional de procesamientos de datos 4
Enfoque por agregación 7
Sistemas de procesamiento de archivos 7
Desventajas 7
Redundancia no controlada 7
Inconsistencia de Datos 7
Inflexibilidad 7
Escasa posibilidad de compartir datos 7
Pobre estandarización 7
Baja productividad del programador 7
Excesiva Mantencion 7
1.2 Enfoque de bases de datos 9
Elementos del enfoque de banco de datos 9
Implementación del enfoque de banco de datos 9
Beneficios y riesgos de usar banco de datos 15
1.3 Tipos de sistemas de información
Operacionales
Administrativos
De apoyo a la toma de decisiones
Concepto Data-Warehouse 15
1.4 Metodologías de Desarrollo
1.5 Administración del recurso información

2. Características y representación de datos 17
2.1 Tipos de bases de datos 17
Jerárquicas 18
De red 17
Relacional 19
Orientada al objeto 20
2.2 Naturaleza del dato 21
2.3 Representación del dato 22
2.4 Entidades 23
2.5 Atributos 23
2.6 Tipos de relaciones 23
Uno a uno 23
Uno a muchos 23
Muchos a muchos 23
Recursivas 23

3. Modelos de datos 24
3.1 Niveles de abstracción 24

Versión 3.0 1 Bases de Datos I


3.2 Semántica de los datos 26
3.3 Cardinalidad 26
3.4 Grado 26
3.5 Dependencia
3.6 Tiempo
3.7 Unicidad
3.8 Clase 27
3.9 Agregación 27
3.10 Modelos de datos dependientes de la tecnología 27
Jerárquico 28
De red 31
Relacional 31
3.11 Modelos de datos independientes de la tecnología 32
Orientada a objeto 32
Entidad – Relación 33
3.12 Normalización de los modelos 35
Primera forma normal 38
Segunda forma normal 41
Tercera forma normal 43

4. Metodología de diseño de una base de datos 44
4.1 Enfoque metodológico 44
Planificación Top – Down 44
Diseño Bottom Up 44
4.2 Planificación de base de datos 44
Análisis Organizacional 45
Funciones 46
Procesos 47
Actividades
Matrices que relacionan los componentes de una
organización
4.3 Obtención del modelo corporativo 49
4.4 Obtención de las bases de datos requeridas por la organización 52
4.5 Proceso de diseño de bases de datos 53
Etapa 1: Formulación y análisis de Requerimientos 54
Paso1:Identificación del ámbito de la base de datos
Paso2:Establecer estándares de recolección de
datos
Paso 3: Identificación de las vistas de usuarios
Paso 4: Construcción del Diccionario de Datos
Paso5:Establecer requerimientos de procesamiento
Etapa 2: Diseño Conceptual 60
Paso 1: Normalización
Paso 2: Integración de vistas
Paso3: Generación del modelo conceptual de datos



Paso 4: Revisión del diseño
Etapa 3: Diseño de la implementación 64
Paso 1: Distribución de datos
Paso 2: Organización de archivos
Paso 3: Indexación
Paso 4: Restricciones de integridad
Paso 5: Mapeo o modelo interno
Paso 6: Diseño de programas

5. Lenguaje de consulta estándar (SQL) 66
5.1 Instrucciones de definición de los datos 66
Create 66
Alter 66
Drop 66
5.2 Instrucciones de manipulación de los datos 67
Select 67
Insert 67
Delete 67
Update 67
5.3 Funciones Especiales
De número
De cadena
De fecha
5.4 Operadores de comparación 67
5.5 Operadores Lógicos 68
5.6 Consulta sobre múltiples tablas 69
5.7 Formato de salidas 69



Unidad 1: Enfoques de Bases de Datos.
1.1 Enfoque tradicional de procesamiento de datos

Las organizaciones al incorporar sistemas de información administrativa, lo hacen
con el fin de resolver problemas puntuales que apoyen la toma de decisiones. La
planificación de un SIA utiliza dos enfoques tradicionales denominados enfoque
por agregación y enfoque de base de datos.

Para iniciar el tema es necesario que demos una mirada introductoria a
algunos conceptos elementales de análisis de sistemas tradicionales que
son la base para una adecuada comprensión del enfoque por agregación y
del enfoque de base de datos.

Las Empresas e Instituciones, organizan su estructura interna en pos de la
eficiencia tecnológica, económica y administrativa para alcanzar los objetivos y
metas que justifican su existencia como tal. Esto determina la búsqueda de
herramientas técnicas y metodológicas que faciliten el proceso de toma de
decisiones. Los sistemas de información administrativos, SIA, son las herramientas
que apoyan la toma de decisiones.

¿Qué es un Sistema de Información Administrativo?

Se entiende por SIA, las personas, estructura organizacional, máquinas manuales
y computarizadas, procedimientos administrativos, recursos logísticos, que en su
conjunto tienen como finalidad la recolección, clasificación, preparación,
almacenamiento, modificación, actualización, recuperación y transmisión de datos
que apoyan la toma de decisiones en la organización.

Recursos logísticos:

Los recursos logísticos son los que permiten cumplir la transformación de los
datos. En general estos recursos son de tipo humano, físicos, equipos
computacionales, software, datos históricos, algoritmos y procedimientos, que
posibilitan guiar la secuencia y la forma de diferentes acciones que determinan la
forma en que se transforman los datos

Procesos de transformación:

Se nutren de datos de entrada y recursos logísticos que logren la transformación
de los datos.



Datos de entrada:

Los datos de entrada se obtienen de tres vertientes, datos primarios o los
provenientes de procesos internos, de datos obtenidos de cómo se tomaron las
decisiones pasadas y desde los resultados de las acciones llevadas a buen
termino por la organización.

Objetivos y Metas:

Toda empresa debe cumplir sus metas y objetivos, de lo contrario no se
justifica, por tanto debe cautelar que los resultados de la gestión de cada uno
de los niveles administrativos de la organización sea lo más eficiente y efectiva
posible. Las metas y objetivos son el resultado de acciones generadas por
decisiones tomadas por los diferentes niveles de la estructura de toma de
decisiones.

Toma de decisiones:

Las decisiones que se adoptan a través del proceso de toma de decisiones son
apoyadas y los problemas que surgen son enfrentados con información (
relevante y oportuna).

Procedimientos administrativos:

Para llevar a buen fin las actividades administrativas mencionadas la
organización implementa un conjunto de procedimientos administrativos.

Toma de decisiones y Sias

La toma de decisiones en un SIA se establece en tres niveles, las estructuradas
o programables, las semi-estructuradas, las no estructuradas o no
programables.

En al marco de la toma de decisiones estructuradas se desarrollan modelos
reglados que establecen la forma de tomar las decisiones.

Respecto de la toma de decisiones no estructuradas, son aquellas que se
toman por expertos y no es posible desarrollar un algoritmo que automatice tal
proceso heurístico.

Niveles de decisión:

Los Sias proporcionan información para la toma de decisiones a tres niveles de
decisión, nivel de planeamiento estratégico, niveles de control de gestión y
operativo.


Nivel de planeamiento estratégico:

Los informes que proporcionan los Sias a este nivel contienen en general: información
actualizada de la base de datos, estimaciones a futuro, basada en la información
actualizada de la base de datos e información que pone el énfasis en situaciones
excepcionales.

Nivel de control de gestión:

Se relaciona con la información necesaria para el uso eficiente y efectivo de los
recursos que permitan cumplir los objetivos y metas de la organización. Los informes
emanados por los Sias para este nivel son aquellos que contengan información para:
analizar y efectuar acciones correctivas sobre la operación y estado de las funciones
correspondientes además de información que refleje estados de transacciones
pasadas.

Nivel de control operacional:

Esta relacionado con la implementación de las diversas actividades que componen la
operación de la organización para lograr los objetivos aplicando los recursos de
acuerdo a las políticas establecidas. Los informes que apoyan la toma de decisiones a
nivel de control operacional se caracterizan por incluir: transacciones rutinarias, datos
utilizados en tareas simples y repetitivas cuyo origen esta establecido claramente.

Tipos de SIAS en el enfoque tradicional de datos

SIA puntual, se caracteriza por apoyar la toma de decisiones en una función especifica
dentro de la organización. Por ejemplo: Sias para la gestión de existencias.

SIA integral, se caracteriza por cubrir todas las actividades de la organización,
pudiendo incluir los denominados SIAS puntuales.

En general y a grosso modo un SIA debe contemplar los siguientes elementos:

Explicitación de metas y objetivos de la organización o función administrativa.

1. Determinación de medidas de eficiencia y efectividad para evaluar el log
objetivos y metas.
2. Estructuración del proceso de toma de decisiones que será utilizado.
3. Identificación y caracterización de la información relevante provista por el SIA.
4. Determinación de datos de salida, entrada, procesos de transformación, tipos y
cantidad de recursos a emplear, talque satisfagan los requerimientos de
información relevante.



5. El SIA provee todos los procedimientos administrativos y documentación
necesaria que hacen posible operar las diferentes actividades del SIA.

Enfoque por agregación

Cuando la organización implementa los SIAS por primera vez lo hacen para
resolver problemas puntuales que apoyan la toma de decisiones y controlar el
logro de sus metas y objetivos.

Ahora la planificación para el desarrollo de un SIA que aplica el enfoque por
agregación, se caracteriza por implementar SIAS puntuales independientes uno de
otros con una interacción mínima entre ellos y que apenas comparten recursos. Estos
SIAS puntuales se desarrollan uno sobre el otro a medida que se van necesitando,
originando problemas como la conocida duplicidad de información.

La expansión de las organizaciones produce naturalmente la evolución progresiva de
los SIAS, implicando problemas puntuales de procesamiento de información ( cuellos
de botella), al desarrollar estas soluciones bajo el enfoque por agregación se han
producido los siguientes inconvenientes:

1. Los SIAS se desarrollan en forma independiente entre sí, sin compartir recursos
ni interacción.
2. Se produce consecuentemente duplicidad de información, un dato se encuentra
en varios archivos.
3. Se produce como corolario de lo anterior problemas con la consistencia de la
información ya que los datos duplicados no serán actualizados al mismo tiempo.
4. Además la responsabilidad de la actualización de estos datos recae en muchas
personas.

Otras consecuencias relativas al contexto de los datos:

1. Los datos satisfacen SIAS que responden a necesidades especificas del área,
departamento o función de la organización.
2. Pueden existir datos con la misma denominación pero con valores distintos por
provenir de fuentes distintas, ser interpretados en forma distinta, poseer
procesos de actualización que obedezcan a acontecimientos distintos.
3. Los mismos datos pueden derivar en resultados diferentes dependiendo del SIA
y sus procesos.

Respecto del diseño de los SIAS aplicando el enfoque por agregación, surgen las
siguientes consecuencias:



Sobre el diseño lógico:

1. Al diseñar un SIA bajo este enfoque resulta compleja la delimitación del mismo,
dado que las funciones administrativas están interrelacionadas entre sí.
2. Los datos se encuentran distribuidos en diversos SIAS, lo que implica dificultades
al momento de establecer las fuentes de información u origen de datos para el
sistema.
3. Aumenta la necesidad de relacionar los datos para satisfacer nuevos
requerimientos.
4. La identificación y caracterización de datos se vuelve inorgánico.
5. Sé complejiza el diseño de procedimientos administrativos.

Respecto del diseño físico:

1. Implica la creación de nuevos archivos con datos ya existentes en otros, así
como nuevos datos.
2. El uso de diferentes lenguajes de programación produce incompatibilidad en los
formatos de almacenaje.
3. Al modificar programas de aplicación generalmente es necesario modificar
también sus archivos de datos influyendo a otros programas que usan los
mismos archivos.

Sistema de procesamiento de archivos

En la década del 60 el tratamiento de la información se caracterizó por la aplicación de
programas denominados BALANCE LINE, que se caracterizan por operar con dos tipos
de archivos clásicos de la época, denominados archivos maestros y de transacciones.
La lógica de operación de este tipo de programa conocidos hoy como pareo de
archivos se basa en la actualización de uno o más archivos maestros a partir de uno o
más archivo de transacciones. Es el caso de una cuenta corriente y sus movimientos
respectivamente.
Otro programa de esta era de los sistemas de procesamiento de archivos es el conocido
corte de control, aplicado para producir informes de acuerdo a un criterio de
agrupamiento de datos. Es el caso de la cartola mensual de una cuenta corriente, allí
las transacciones u operaciones son ordenadas por fecha.

Desventajas del enfoque tradicional de datos

1. Redundancia no controlada
2. Inconsistencia de datos
3. Inflexibilidad
4. Escasa posibilidad de compartir datos
5. Pobre estandarización
6. Baja productividad del programador
7. Excesiva Mantención



1.2 Enfoque de bases de datos

Elementos del enfoque de Banco de Datos:

La administración, control y uso de los datos en la organización basado al enfoque
de base de datos se rige de acuerdo a los siguientes consideraciones:

Los datos de la organización son contemplados como un recurso fundamental de
esta, del mismo modo que el capital, los recursos humanos y otros. Por lo tanto se
le da un manejo, control y uso eficiente y efectivo.

En consecuencia se requiere un nivel de decisiones dentro de la organización cuya
responsabilidad sea administrar el recurso información.

Todos los datos de la información se encuentran almacenados en archivos
centralizados, que permiten el acceso de las aplicaciones que las necesitan.

Los archivos centralizados son accesibles por las aplicaciones y los usuarios según
sus necesidades.

Contempla un sistema de identificación, descripción y definición de los datos de la
organización.

Incluye dispositivos de acceso directo y pantallas que facilitan la interrogación por
parte del usuario.

Permite establecer distintos tipos de usuarios con distintos tipos de accesos
centralizados.

Incluye software que facilita la interrogación de la base de datos para los distintos
niveles de usuarios.

Implementa condiciones de seguridad e integridad de los datos y procedimientos de
recuperación de datos en caso de error.

Comprende un almacén centralizado que incluye toda la información necesaria de
los datos de la base de datos con el fin de evitar problemas en su administración a
programadores, analistas de sistemas y otros especialistas.

Implementación del enfoque de Banco de Datos:

Antes de contemplar los elementos del enfoque de base de datos es necesario
examinar las funciones que deben incluirse en la implementación de este enfoque. Para
la implementación del enfoque de base de datos se debe distinguir las siguientes
funciones:



1. Administración de la información:

Encargada de caracterizar, identificar y estandarizar los datos contemplados para la
base de datos

2. Almacenamiento de datos:

Centraliza los datos de la base de datos en archivos integrados, que genéricamente
se denominan base de datos.

3. Supervisión del almacenamiento y recuperación de los datos:

Proporciona las facilidades necesarias para definir, acceder, manejar, recuperar y
controlar los datos que se encuentran en la base de datos. Esta función es apoyada
por el denominado SABD sigla de sistema administrador de base de datos, este
software interactúa fuertemente con el sistema operativo.

4. Administración de la implementación computacional de la base de datos:

Identifica, caracteriza, estructura y estandariza computacionalmente aquellos datos
que nutren la base de datos y que estarán bajo el control del SABD, por lo cual se
llama ASABD, es decir administrador el SABD. Esta función además se encarga de
administrar el hardware y software asociado que permite operar al SABD, así como
aquellos archivos que este origina.

5. Demanda:

Debe agrupar todos los usuarios de la base de datos, que aprovechan las facilidades
provistas por el SABD. Se entiende por usuarios a los que toman decisiones, los
sistemas de información administrativos, los programadores, analistas de sistemas y
otros.

Elementos del enfoque:

A. Administrador de la Información (AI):

El administrador de la información debe identificar, caracterizar y controlar los datos
incluidos en la base de datos, tal que los usuarios finales encuentren en ella los
datos necesarios para la toma de decisiones y los SIAS encuentren los datos para
opera. El AI centraliza los datos evitando la duplicidad descontrolada, ambigüedad e
inconsistencias de la información.



Las actividades del AI:

1. Determinar y estructurar los requerimientos de información de los usuarios.
2. Especificar los requerimientos de Información.
3. Diseñar los procedimientos administrativos para que los usuarios puedan
utilizar los datos de la base de datos y del diccionario de datos. ( que contiene
identificación, caracterización y estructura de los datos de la base de datos)

En la determinación de requerimientos de información el AI tiene en cuenta que la
creación y Mantención de la base de datos debe ser segura, confiable y fiable. Entre
las actividades del AI para identificar la información a incluir en la base de datos están:

1. Determinación de las necesidades de información de cada usuario.
2. Establecimiento de estándares o medidas de los datos de la base de datos.
3. Determinación, análisis y filtrado de los datos a incluir en la base de datos.
4. Producir un inventario de los datos incluidos en la base de datos.

En la especificación de requerimientos el AI, en conjunto con usuarios y el ASABD,
identifica y caracteriza los datos que irán en la BD, documentándolos de manera
unívoca mediante el diccionario de datos, el cual se transforma en la fuente de
información que tiene la organización, en cuanto a la disponibilidad de datos. La
especificación de requerimientos de información se realiza a través del diccionario de
datos, cuya Mantención y uso es responsabilidad del AI.

El diseño de procedimientos administrativos realizado por el AI esta dirigido a:

1. Definición y control de estándares para la identificación y caracterización de los
datos a incluir en la base de datos
2. Modificación de la estructura de la base de datos.
3. Procedimientos para el manejo y acceso de los datos.
4. Determinación de responsabilidades sobre ciertos datos, de manera de
asegurar la confiabilidad de los valores asignados a cada dato.
5. Determinación de procedimientos que regulen el acceso, lectura, inserción,
modificación y eliminación de datos de la BD.
6. Determinación de procedimientos que permitan al AI conocer el uso dado a los
datos de la base de datos.
7. Analizar las alternativas costo / beneficio para la organización acerca de tener
una base de datos que satisfaga los requerimientos de todos los usuarios.
8. Analizar los errores encontrados por los usuarios, con el fin de colaborar en
futuras reestructuraciones de la base de datos.



Elementos de una Base de Datos:

Los elementos de una base de datos son los archivos integrados y él catálogo.

• Se entiende por archivos integrados aquellos archivos que han sido modelados y
estructurados de tal forma que se encuentran relacionados entre sí permitiendo su
interrogación. Los SABD proporcionan las herramientas necesaria para la
producción de este tipo de archivos, denominadas lenguajes de definición de datos
( LDD), además de lenguajes de manipulación de datos ( LMD) para interrogar la
base de datos.
• El catálogo es un archivo creado y mantenido por el SABD, en el que se mantienen
las características físicas de los datos de la base de datos. Estas características
son usadas por el SABD en la traducción y ejecución de aplicaciones
computacionales. Él catálogo es producido por un conjunto de rutinas del SABD
mediante las descripciones proporcionadas por el ASABD. Para ser accesado por
otro conjunto de rutinas para efectos de su mantención y lectura. En general la
descripción de los datos almacenados en él catálogo incluye: nombre del dato,
tipo, largo, nivel de seguridad, fecha de origen, archivo de residencia, modo de
acceso y almacenamiento.

B. Administrador de SABD

La persona encargada de esta función tiene la responsabilidad de la implementación y
operación del SABD. El ASABD administra el producto de software denominado SABD,
realiza la creación física y Mantención de la base de datos.

1. Las principales responsabilidades del ASABD son las siguientes:
2. Desarrollo, estructuración y crecimiento de la base de datos de acuerdo a las
facilidades del SABD y la situación de la organización.
3. Habilitación de facilidades que originen una optima implementación del SABD,
como interfaz de usuarios, mecanismos de seguridad, integridad, privacidad,
validación, verificación entre otros.
4. Supervisión del uso dado por el usuario de las facilidades otorgadas por el SABD.
5. Preparación y difusión de procedimientos para la operación del SABD.
6. Asistencia técnica a los usuarios del SABD
7. Medición periódica del desempeño del SABD.

El ASABD, en conjunto con el AI deben determinar como traducir y satisfacer los
requerimientos de información de los usuarios. Para ello, previo a la implementación del
SABD, tanto el ASABD como el AI tienen las siguientes responsabilidades:

1. Producir el inventario de datos de la organización.
2. Coordinar el manejo y seguridad de los datos.



3. Crear y mantener un diccionario de datos
4. Coordinar los procesos de codificación y estandarización de datos.
5. Prepara normas y procedimientos para verter archivos tradicionales a la base de
datos.
6. Experimentar y difundir en forma piloto las funciones del AI y el ASABD.

El diseño físico de la base de datos es labor del ASABD, realizando las siguientes
actividades:

1. Coordinación y apoyo en el desarrollo de SIAS para que estos aprovechen las
facilidades del SABD y la BD.
2. Mantener el contacto con los proveedores del SABD y de otros SABD
3. Mantener información para los usuarios respecto de la organización de la BD.
4. Mantener un control total sobre el DDL
5. Definir las características e identificación de los datos
6. Analizar el contenido de la BD.
7. Mantener el software de apoyo al diccionario de datos.
8. Preparación y Mantención del catálogo de la base de datos.
9. Determinar la estructura física de la base de datos
10. Especificación de la estructura de la BD.
11. Controlar el acceso a los datos de la BD.
12. Coordinación entre las el SABD y el sistema operativo empleado
13. Definición de procedimientos de protección contra destrucción o accesos no
autorizados.
14. Definición de niveles de seguridad para el acceso a la BD.
15. Establecer procedimientos para la seguridad y protección física de los datos.
16. Participación en la s pruebas de programas de aplicación.
17. Establecer procedimientos de respaldo para la BD.
18. Analizar y controlar el seguimiento de trazas y errores.
19. Mantención actualizada de los procedimientos de recuperación de la BD.
20. Determinar procedimientos que permitan detectar violaciones a las reglas de
seguridad e integridad, buscando la identificación del causante e informando a los
niveles que corresponda.

B. Diccionario de datos ( DD)

Este elemento del enfoque de base de datos es el conjunto centralizado de atributos
lógicos que especifican la identificación y caracterización de los datos que se manejan en
la BD. La BD contiene el valor de los datos, el DD contiene meta datos, es decir los
atributos lógicos de dichos datos.



Entre las ventajas del DD se tiene:

1. Es un medio centralizado de tener información sobre los atributos lógicos de los
datos de la BD.
2. Es un medio de estandarización en el manejo y uso de los datos
3. Es un medio expedito de almacenamiento y recuperación de proposiciones de
atributos lógicos originados por analistas de sistemas en el diseño de un SIA.
4. Representa una ayuda para analistas y programadores en el momento de
desarrollo de un SIA.
5. Permite introducir procedimientos estandarizados en le manejo de datos,
informes y documentación de procesos y aplicaciones.

Los usuarios del DD son: el AI, el SABD, usuarios finales, Analistas de Sistemas y
programadores entre otros.

El diccionario de datos contiene para cada dato los siguientes atributos lógicos o meta
datos:

Información respecto de: identificación, control administrativo, seguridad, validación y
sobre relaciones lógicas y físicas.

Atributos de identificación comprende el nombre completo del dato, nombre abreviado,
sinónimos, identificador o clave, fecha de última actualización.

Atributos de información para control administrativo incluye: unidad de origen del dato,
nombre del programa o transformación que lo origina, nombre del documento que lo
contiene por primera vez en la organización, las unidades organizacionales y programas
de aplicación que lo usan, Cardinalidad del dato.

Atributos de seguridad identificación de las personas autorizadas para cambiar las
características del dato, accesarlo o actualizarlo, fecha de última actualización e
identificación del usuario que efectuó esta actualización.

Atributos de validación contienen lista o rango de valores permitidos, nombre de los
programas validadores que actúan sobre él.

Atributos de relaciones lógicas algoritmos de derivación, identifica la forma de
generación del dato, estructuras lógicas, grupos y jerarquías donde el dato es miembro.

Atributos de relación física: largo, tipo, nombre para programación, reglas de edición,
unidad de medida del dato, precisión.



Beneficios y riesgos de usar Banco de Datos.

Un banco de datos esta constituido por todos los datos formales, relevantes para la
toma de decisiones. Los datos del banco de datos se encuentran dispersos en la
organización soportados en diversos medios, como, archivadores, formularios,
documentos, dispositivos de almacenamiento digital y otros.

La base de datos se constituye por todos los datos del banco de datos,
almacenados en archivos centralizados altamente disciplinados, de tal forma que
puedan ser requeridos de diversas maneras lógicas, con el fin de satisfacer las
consultas de los distintos usuarios de la base de datos.

Los beneficios del banco de datos son amplios y casi innumerables, el banco de
datos como se señalo en l párrafos anteriores representa toda la información
relevante y formalizada de la organización, entiéndase por datos de la constitución
de la empresa hasta los relativos al pago de patentes pasando por datos de
acreedores y deudores.

El riesgo del banco de datos es que el volumen de información va aumentando
paulatinamente y se hace inmanejable si no es vertida a un sistema de base de
datos.

1.3 Concepto Data – Warehouse

La traducción literal es almacenamiento de datos. Como es sabido existen
muchos lugares donde podemos buscar datos, pero ha surgido la idea que exista
un mayorista al interior de la empresa que acumule toda la información, bodega de
datos inteligente.

Existen muchas definiciones de DW, pero la más completa es la de Bill Inmón, la
cual dice: “Data Warehouse es una tecnología orientada a temas específicos,
integrada, variante con el tiempo y es una colección no volátil que soporta la
administración del proceso de toma de decisiones dentro de las organizaciones

¿Cuándo y porqué nace?

Día a día van surgiendo nuevos problemas en una organización y junto a ello
nuevas formas de solucionarlos, la idea de DW data de hace mucho tiempo pero
la razón de que hoy día sea un tema de actualidad es que hoy existen tecnologías
de HW y SW suficientemente poderosas para depurar esta información.

Él porque se asocia a la necesidad de mejorar la información analítica a través
de un medio computacional, la mayoría de la información útil en una empresa



está encerrada en viejas aplicaciones y los usuarios creían que bastaba con crear
nuevas formas de acceso pero no es así porque además tienen las siguientes
características, complejidad en la estructura de los sistemas, diseño de sistemas
orientados al rendimiento óptimo, información dependiente, información a menudo
dispersa en múltiples o diversos sistemas, definición inconsistente y la solución fue
crear un almacén de datos, en el cual los datos fueran transformados, integrados y
cargados a un dispositivo en donde tuvieran sentido para aquellas personas que lo
necesiten como soporte a la toma de decisiones.

Su creación se ha estimulado gracias a la necesidad de sistemas de información
que apoyen la toma de decisiones de una organización.



UNIDAD 2: Características y representación de Datos.

2.1 Tipos de Bases de Datos

Base de Datos Red:

Una base de datos de red como su nombre lo indica, esta formado por una colección de
registros, los cuales están conectados entre sí por medio de enlaces. El registro es similar
al de una entidad como las empleadas en el modelo entidad relación.

Un registro es una colección de campos (atributos), cada uno de los cuales contiene
solamente almacenado un solo valor, el enlace es la asociación entre dos registros
exclusivamente, así que podemos verla como una relación estrictamente binaria.

Una estructura de datos de red, llamada algunas veces estructura de plex, abarca más que
la estructura de árbol porque un nodo hijo en la estructura red puede tener más de un
padre. En otras palabras, las restricción de que un árbol jerárquico cada hijo pude tener un
solo padre, se hace menos severa. Así, la estructura de árbol se puede considerar como
un caso especial de la estructura de red tal como lo muestra la siguiente figura. Para
ilustrar las estructura de los registros en una base de datos red, consideramos la base de
datos alumno – materia, los registros en lenguaje pascal entonces quedaría como:

type alumno = record
nombreA: string[30];
control: string[8] ;
esp: string[3]
end;

type material= record
clave: string[7]
nombreM: string[25]
cred= string[2];
end;



Ejemplo de una base de datos en red:

11234 Álvarez Rosa 1 Cois 5100

6 Cois 5100

21344 Rivera Juan

7 Cois 5120

23456 Ríos María

8 Cois 5130

Base de Datos Jerárquicas:

En este tipo de bases de datos la información se distribuye en distintos niveles
según su importancia estructural: por ejemplo de la entidad automóvil, depende la
entidad motor, de esta depende block y de ésta, depende camisa de cilindro.

Un diagrama de estructura de árbol es el esquema de una base de datos. Tiene
dos componentes básicos, Registros y Ligas.

Estos diagramas son similares a los de estructuras de datos en el modelo en red.
La diferencia radica en que el modelo de red los registros se organizan en forma
de un grafo arbitrario, mientras que el modelo jerárquico en forma de un árbol con
raíz.

Las reglas para la formación de árbol son:

1. No hay ciclos
2. De padre a hijos son válidas las relaciones de uno a uno a uno a muchos

El esquema de una base de datos jerárquica se presenta como una colección de
diagramas de estructuras de árbol. Para cada diagrama existe una única instancia
de árbol base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese
nodo son instancias del tipo de registros adecuados:



Ejemplo de una base de datos jerárquica:

11234 Álvarez Rosa 23456 Ríos María

21344 Rivera Juan

1 Cois 5100 7 Cois 5120

6 Cois 5100 7 Cois 5120 8 Cois 5130

Base de Datos Relacional:

Base de datos en la cual la información está almacenada en forma de tablas, y
que permite establecer relaciones entre distintas entidades por medio de campos
en común; por ejemplo, código de cliente en factura y en archivo de clientes.

Ejemplo de una base de datos relacional:

Sección Curso
1 Cois 5100
6 Cois 5100
7 Cois 5120
8 Cois 5130



N° Est. Apellido Nombre Sección
11234 Álvarez Rosa 1
21344 Rivera Juan 6
21344 Rivera Juan 7
23456 Ríos María 7
23456 Ríos María 8

Diferencia entre modelos relacional, red y jerárquico:

Los modelos relacionales se diferencian de los modelos de red y jerárquico en que no
usan puntaros o enlaces. En Cambio el modelo relacional conecta los registros
mediante valores que éstos contienen.

Bases de datos orientadas a objeto:

Modelo orientado a objeto:

Al igual que el modelo entidad – relación se basa en una colección de objetos. Un
objeto contiene valores almacenados en instancias dentro del objeto. Estos valores son
objetos por si mismo, esto es, los objetos contienen objetos a un nivel de anidamiento
de profundidad arbitraria.
Un objeto también contiene partes de un código que operan sobre el objeto, estas
partes se llaman métodos.
Los objetos que contienen los mismos tipos de valores y los mismos métodos se
agrupan en clases.
Una clase puede verse como definición de tipo para objetos.
En este modelo hay dos niveles de abstracción de datos, una que es visible
externamente, que ocurre en la interfase de llamada de los métodos de un objeto y otro
nivel que ocurre en la parte interna del objeto y el código del método.
El interfase externo del objeto permanece sin cambios.
La diferencia de las entidades en el modelo entidad relación, cada objeto tiene su propia
identidad única independiente de los valores que contiene. Así, dos objetos que
contienen los mismos valores son, sin embargo, distintos. La distinción entre objetos
individuales se mantiene en el nivel físico por medio de identificadores de objeto.



2.2 Naturaleza del dato

La percepción del mundo puede ser descrita como una sucesión de fenómenos. Desde
el comienzo de los tiempos el hombre ha tratado de descubrirlos, ya sea que los
entienda completamente o no.

La descripción de estos fenómenos es llamado Dato. Los datos corresponden al
registro discreto (no continuo) de hechos acerca de un fenómeno, con lo cual ganamos
información acerca del mundo que nos rodea (Información: Incremento del conocimiento
que puede ser inferido de los datos).

Usualmente el dato y su significado son registrados juntos, ya que el lenguaje natural es
lo suficientemente poderoso para hacerlo. Por ejemplo, el Kilo de pan cuesta “$460”
registra el valor 460 y su significado o semántica (valor del kilo de pan en pesos).

En ciertos casos los datos están separados de su semántica. Por ejemplo, una planilla
de notas es una tabla de datos. Su interpretación implícita y se supone que quien la lee
conoce su significado.

El uso del computador para procesar datos ha traído consigo una mayor separación
entre lo datos y su interpretación. Mucha de la interpretación de los datos está explícita.
Consideremos por ejemplo un programa que calcula integrales definidas, este programa
recibe valores de entrada y genera valores como salida. Sin embargo el programa en sí
no tiene conocimiento si el problema resuelto es de termodinámica o
electromagnetismo.

2.3 Representación del dato

Ha habido razones para separar los datos de su significado:
• Los computadores no manejan (bien) el lenguaje natural, que es la mejor forma
de dar interpretación y su significado a un dato.
• El almacenamiento de los datos ocupa espacio, e inicialmente este era escaso y
costoso.

Así, tradicionalmente la interpretación de los datos se deja al usuario y al sistema
manual externo al computador.

En muchos sistema la interpretación de datos se encuentra en los programas que hacen
usos de ellos, de modo que los datos pasan a ser una simple colección de valores.

Por otra parte, supongamos que algo de la semántica de los datos se codifica junto con
ellos. Así los datos no sólo son valores, si no que también tienen una semántica y lo
datos están más cerca de la interpretación del mundo. Ellos forman



una “vista” del mundo, la que no es exacta ni concreta, si no que usualmente es bastante
abstracta.

Los datos no son estáticos, y corresponden a un mundo que esta en constante cambio. La
flexibilidad en la interpretación de los datos permite capturar los aspectos dinámicos del mundo
y al mismo tiempo, proveer una estructura estable para los datos. Esta flexibilidad se puede
tener de dos formas:
• El sistema puede permitir que los mismos datos sean vistos de diferente forma. Por
ejemplo, diferentes aplicaciones pueden usar los mismos datos y dar su propia
semántica.
• Diferentes datos pueden ser vistos de la misma forma. Por ejemplo, se quiere ver a los
gerentes, secretarias y empleados sólo como trabajadores de una organización, no
importando su cargo. Aquí la interpretación debe ser lo suficientemente abstracta para
que diferentes vistas del mundo se vean de la misma forma

2.4 Entidades

Consideremos un número de conjuntos cada uno orientado a un tipo particular de objetos.
Estos conjuntos están relacionados con Dominios (conjunto de valores de un mismo tipo. Se
define como un conjunto, ya sea por extensión o comprensión).

Si consideramos la relación dada por el producto cartesiano de estos dominios, una
interpretación que se les da a cada una de estas tuplas es que cada una corresponde a una
entidad particular.

Ejemplo:

(Juan , 70, 80, 50)
(Pedro , 90, 50, 70)

¿Qué es una entidad?

• Cualquier cosa de relevancia para el negocio acerca de la cual debe mantenerse
información.
• Algo con existencia real o conceptual
• Algo a lo que se le da nombre
• Cualquier cosa que se puede identificar claramente
• Un objeto que existe y es distinguible entre otros objetos



¿Cómo se identifican Entidades?

A partir de la descripción del negocio, buscando sustantivos de usos común en el
negocio, buscando sinónimos, que representen conceptos generalizables.

2.5 Atributos

Elemento de un dominio. Aporta mediante su rótulo, la semántica de los valores del
dominio al que está asociado.

Dominio

ATRIBUTO

2.6 Tipos de relaciones.

Uno a Uno:

Relaciones uno a uno (1:1). Una entidad A está asociada a lo más con una
entidad B, y una entidad B a lo más con una entidad A. Ejemplo: “Ser jefe de”
es una relación uno a uno entre las entidades empleado y departamento.

Uno a Muchos:

Relaciones Uno a Muchos (1 : n). Una entidad A está asociada con una o
varias entidades B. Una entidad B, sin embargo, puede estar a lo más
asociada con una entidad A. Ejemplo: “Ser profesor” es una relación 1: n entre
profesor y curso, suponiendo que un curso sólo lo dicta un profesor.

Muchos a muchos

Relaciones Muchos a Muchos (n : m). Una entidad A está asociada con una o
varias entidades B, y una entidad B está asociada con una o varias entidades
B, y una entidad B está asociada con una o varias entidades A. Ejemplo: “Estar
inscrito” es una relación n : m entre las entidades alumno y curso



Unidad 3: Modelos de Datos.

Es aparente que una representación del mundo es necesaria, la que debe ser
suficientemente abstracta para que no sea afectada por la dinámica del mundo (los
pequeños cambios), y debe ser suficientemente robusta para poder representar como los
datos y el mundo se relacionan. Una herramienta como esta es llamada Modelo de Datos, el
cual permite representar en forma más o menos razonable alguna realidad. El modelo de
datos permite realizar abstracciones del mundo, permitiendo centrarse en los aspectos
macros, sin preocuparse de las particularidades; así nuestra preocupación se centra en
generar un esquema de representación, y no en los valores de los datos.

Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es improbable
generar un modelo que lo capture totalmente.

Sin embargo se puede tener un conocimiento relativamente completo de la parte del mundo
que nos interesa. Así un modelo captura la cantidad de conocimiento tal que cumpla con los
requerimientos que nos hemos impuesto previamente.

Un Modelo de Datos define las reglas por las cuales los datos son estructurados. Esta
estructuración sin embargo, no da a una interpretación completa acerca de los significados
de los datos y la forma en que serán usados. Las operaciones que se permiten efectuar a los
datos deben ser definidos..

3.1 Niveles de Abstracción de los datos

La mayoría de las aplicaciones son dependientes de los datos; la organización del
almacenamiento y los modos de acceso dependen de los requerimientos de la aplicación y
el conocimiento de la organización física de los datos y las técnicas de acceso forman parte
de la lógica de la aplicación. La aplicación es dependiente de los datos, porque no se puede
mejorar la estructura de almacenamiento o los modos de acceso sin afectar la aplicación.

En los sistemas de bases de datos se plantean los siguientes objetivos:

1. Independencia de la base de datos de los programas para su utilización.
2. Proporcionar a los usuarios una visión abstracta de los datos. El sistema esconde los
detalles de almacenamiento físico (como se almacenan y se mantienen los datos)
pero estos deben extraerse eficientemente.

Independencia de los datos:
“La independencia de los datos es la capacidad de un sistema para permitir que las
referencias a los datos almacenados, especialmente en los programas y en sus descriptores
de los datos, estén aislados de los cambios y de los diferentes usos en el entorno de los
datos, como pueden ser la forma de almacenar dichos



datos, el modo de compartirlos con otros programas y como se reorganizan para
mejorar el rendimiento del sistema de bases de datos”.

Para conseguir esta independencia entre los datos y las aplicaciones es necesario
separar la representación física y lógica de los datos, distinción que fue reconocida
oficialmente en 1978, cuando el comité ANSI/X3/SPARC propuso un esqueleto
generalizado para sistemas de bases de datos. Este esqueleto propone una
arquitectura de tres niveles, los tres niveles de abstracción bajo los que podría
verse una base de datos: el nivel interno, el nivel conceptual y el nivel externo.

NE 1 NE 2 NE 3 N IV E L E X T E R N O

N IV E L
CO NCEPTUAL

N IV E L IN T E R N O
Los tres niveles de la arquitectura ANSI/X3/SPARC

Los tres niveles de la arquitectura ANSI/X3/SPARC

• Nivel Interno: En el se define la estructura física de la base de datos: dispositivos de
almacenamiento físico, direcciones físicas, estrategias de acceso, relaciones, índices,
apuntadores, etc. Es responsabilidad de los diseñadores de la base de datos física.
Ningún usuario, en calidad de tal, tiene conocimiento de este nivel.

• Nivel Conceptual: Contiene el nivel conceptual de la base de datos, que implica el
análisis de las necesidades de información de los usuarios y las clases de datos
necesarias para satisfacer dichas necesidades. El resultado del diseño conceptual
contiene la descripción de todos los datos y las interrelaciones entre ellos, así como
las restricciones de integridad y de confidencialidad.



• Nivel Externo: Visión que de la base de datos tiene un usuario o aplicación en
particular. Habrá tantas vistas de la base de datos como exijan las diferentes
aplicaciones. La vistas se derivan directamente del esquema conceptual, o de otras
vistas, y con tienen una descripción de los elementos de datos y sus interrelaciones
orientadas al usuario o aplicación y de las que se compone la vista. Una misma vista
puede ser utilizada por varias aplicaciones.

Esta arquitectura de tres niveles nos proporciona la deseada independencia, que definiremos
como capacidad para cambiar el esquema en un nivel sin tener que cambiarlo en ningún otro
nivel. Distinguimos entre independencia física y lógica:

• Independencia lógica de los datos: Cambio del esquema conceptual sin cambiar las
vistas externas o las aplicaciones.

• Independencia física de los datos: Cambio del esquema interno sin necesidad de
cambiar el esquema conceptual o los esquemas externos.

3.2 Semántica de los datos.

La semántica de los datos es el significado asociado al lenguaje (por ejemplo, el significado de
las palabras y su interpretación dentro de un contexto dado).

3.3 Cardinalidad

La Cardinalidad de un objeto o entidad es el número de ocurrencias del objeto, entendiéndose
por ocurrencia de una entidad o instancia de un objeto, al producto de asociar valores a los
atributos de la entidad u objeto.

3.4 Grado

Se denomina grado, a la cantidad de atributos que se consideran para una entidad u objeto.

3.5 Dependencia

Igual que para los tipos de entidad, los tipos de interrelación pueden ser regulares o fuertes y
débiles, según se asocien dos entidades fuertes o una fuerte y una débil, respectivamente.

En los tipos de interrelación débil no pueden existir si desaparecen en existencia y la
dependencia en identificación.



Dependencia en existencia: Cuando la ocurrencia en un tipo de entidad débil no puede existir si
desaparece la ocurrencia de la entidad fuerte de la que depende.

Dependencia en Identificación: Cuando, además de ser una dependencia en existencia las
ocurrencias de la entidad débil no pueden identificarse únicamente mediante los atributos
propios de la misma.

3.8 Clase

Una clase es un objeto que permite instanciar objetos.

3.9 Agregación

Es una correspondencia que se establece entre dos clases.

3.10 Modelos de Datos dependientes de la tecnología.

La forma o vista externa con que se presentan los datos al usuario en la mayoría de los
sistemas actuales es idéntica o muy semejante a la vista conceptual.

La estructura lógica, a nivel contextual o externo, es la base para la clasificación de los DBMS
en las tres categorías siguientes: Jerárquica , Red y Relacional.

Cualquier categoría del DBMS debe permitir un acceso aleatorio a los datos requeridos,
utilizando para tal fin una de las siguientes estructuras lógicas para almacenar los datos:
redes, árboles, tablas o listas enlazadas.

Cada DBMS esta diseñado para manejar un tipo determinado de estructura lógica. Los
programas que se ejecutan bajo un DBMS no se pueden procesar en otro DBMS.

Los DBMS más conocidos, disponibles en el Mercado en función de su categoría, son:

• Enfoque Jerárquico: El IMS de IBM y el SYSTEM 2000 de Intel.
• Enfoque de Red: Los ejemplos más importantes los proporciona las
especificaciones del grupo de trabajo de base de datos (DBTG) de CODASYL.
• Enfoque Relacional: System R y QBE de IBM, MAGNUM de Tymshare, ORACLE y
otros.



• Enfoque Jerárquico

Un DBMS de enfoque jerárquico utiliza ÁRBOLES para la representación lógica
de los datos.

A los archivos que entre sus registros guardan una relación tipo árbol se les
llama Archivos Jerárquicos.

La figura siguiente muestra una estructura en árbol con 4 tipos de registros:

SUCURSAL
AUTOMOVIL
EMPLEADOS
FECHA-MANTENIMIENTO

Que representan las sucursales filiales de una empresa, los automóviles
asignados a cada una de ellas, los empleados que deben conducir un
determinado coche y la fecha de mantenimiento. El registro SUCURSAL
contiene los campos NUMERO-SUCURSAL, NOMBRE-SUCURSAL, NOMBRE-
CIUDAD, etc.; el registro AUTOMOVIL incluye los datos de los coches; el registro
EMPLEADO, los datos personales del mismo: NUMERO, NONBRE, etc. y, por
último el registro FECHA-MANTENIMIENTO contiene los campos FECHA,
OPERACIÓN.

Ver figura Anexa.


SUCURSAL

AUTOMOVIL

EMPLEADO FECHA - MANTENIMIENTO

a) Estructura lógica con cuatro tipos de registros

SUCURSAL

AUTO 1
AUTO 2 AUTO 3 AUTO 4

EMPLEADO 1 EMPLEADO 2
EMPLEADO 4 EMPLEADO 2 EMPLEADO 3

b) Ejemplo de la base de datos jerárquica de la estructura a

Archivo jerárquico con cuatro tipos de registros



Terminología para describir los árboles

El anexo siguiente muestra un árbol compuesto por una jerarquía de
elementos llamados nodos. Los árboles se dibujan con la raíz arriba y las
hojas abajo

Nivel 1: Raíz
A

Nivel 2
B
D
C
Nivel 3

H
E G
F

Estructura de un árbol

La terminología para describir los nodos de un árbol es la siguiente:
• Raíz : es el nodo más alto de la jerarquía ( nodo A)
• Padre : Es el nodo al que se haya vinculado otros de nivel inferior. EL padre
de B es A.
• Gemelos : Nodos con el mismo padre Ej: B, C y D.
• Hijos : Son los nodos vinculados con otros del nivel superior los hijos de B
son E, F, G.
• Hojas : Reciben este nombre los nodos que no tienen hijos. (C, H )



El Enfoque de Red

Una estructura de datos en RED, también llamada estructura PLEX, se
caracteriza porque cada nodo hijo puede tener más de un padre, a diferencia
de la estructura en árbol en la que un hijo sólo podía tener un padre.

A B

C

D F

E

G H I J

Estructura de red

El nodo C tiene dos padres A y B. Lo mismo sucede con en nodo H
cuyos padres son D Y E



3.11 Modelos de Datos Independientes de la tecnología.

Objetivos del diseño

En los temas anteriores se han estudiado las arquitecturas de los distintos DBMS, así como
los lenguajes para el manejo de los datos. Pero todavía no se ha considerado un aspecto
fundamental de las bases de datos, como es su diseño. Por diseño se entiende el generar
un conjunto de esquemas de relaciones que permitan almacenar la información con un
mínimo de redundancia pero al mismo tiempo faciliten su recuperación.

Entre los distintos objetivos en el diseño de una base de datos se pueden
considerar:
1. La base de datos resultante tiene que ser capaz de almacenar toda la
información necesaria. El primer paso será determinar los atributos que van a
formar parte de la base de datos y reunirlos en una relación universal. Hasta
que se hayan concretado los campos necesarios no podrá el diseñador
establecer las relaciones entre ellos.
2. Eliminación de la información redundante siempre que sea posible.
3. Mantener el número de relaciones al mínimo entre los componentes de la
base de datos con el fin de facilitar su programación o uso por parte del
usuario.
4. Las relaciones obtenidas deben estar normalizadas con el fin de minimizar los
problemas de actualización y borrado.

Orientado a Objeto

El Modelo Orientado a Objetos se basa en el paradigma de programación orientada a
objetos. Este paradigma ha tenido gran aceptación debido a que es de gran naturalidad
buscar objetos en la realidad a modelar.

Estructura de objetos.
El Modelo orientado a objetos se basa en encapsular código y datos en una única unidad
llamada objeto. La Interfaz entre un objeto y el resto del sistema se define mediante un
conjunto de mensajes.

El motivo de este enfoque puede ilustrase considerando una base de datos de documentos
en la que los documentos se preparan usando uno entre varios paquetes software con
formateador de texto. Para imprimir un documento debe ejecutarse el formateador correcto
en el documento. Bajo un enfoque orientado a objetos cada documento es un objeto que
contiene el texto de un documento y el código que opera sobre el objeto.



Todos los objetos del tipo documento responden al mensaje imprimir, pero lo hacen de
forma diferente. Cada documento responde ejecutando el código formateador adecuado.
Encapsulando dentro del objeto documento la información acerca de cómo imprimirlo,
podemos tener todos los documentos con la misma interfaz externa al usuario ( aplicación).

En General un objeto tiene asociado:

• Un conjunto de atributos que contienen datos acerca del objeto. A su vez, cada valor
de un atributo es un objeto.
• Un conjunto de mensajes a los que responde.
• Un conjunto (puede ser unitario) de métodos, que es un procedimiento o trozo de
código para implementar la respuesta a cada mensaje. Un método devuelve el valor
(otro objeto) como respuesta al mensaje.

Puesto que la única interfaz externa de un objeto es el conjunto de mensajes al que
responde, es posible modificar la definición de métodos y atributos sin afectar a otros
objetos.

También es posible sustituir un atributo por un método que calcule un valor.

Ejemplo: Un objeto documento puede contener un atributo de tamaño que contenga el
número bytes de texto en el documento, o bien un método de tamaño que calcule el
tamaño del documento leyéndolo y contando el número de bytes.

La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está
considerada como una de las mayores ventajas del modelo de programación orientada a
objetos.

Entidad - Relación

En 1976, Peter Chen publicó el modelo entidad – relación, el cual tuvo gran aceptación
principalmente por su expresividad gráfica. Sobre esta primera versión han trabajado
numerosos autores, generando distintas extensiones de mayor a menor utilidad y de
aceptación variable en el medio académico y profesional. Muchas de estas extensiones
son muy útiles, pero poco difundidas debido principalmente ala ausencia de herramientas
automatizadas que apoyen su uso.

¿Cómo modelar en MER (Modelo Entidad Relación)?

Para modelar en MER se sigue generalmente el siguiente orden:

1. Identificar los tipos de entidades
2. Identificar los tipos de Interrelaciones
3. Encontrar las cardinalidades



4. Identificar los atributos de cada entidad
5. Identificar las claves de cada tipo de entidad
La regla básica es distinguir tipos de entidades e interrelaciones de atributos. Así,
los atributos deben ser atómicos y característicos del tipo entidad o interrelación que
describan.

También los atributos deben pertenecer al tipo de entidad o interrelación que
describen y no a otro tipo.

Otra diferencia entre tipo entidad y atributo es que, por ejemplo, se puede tener el
tipo de entidad empleado, que tiene como atributo el departamento al que
pertenece. En Forma alternativa se pueden tener los tipos de entidades Empleado y
Departamento, y el tipo de interrelación trabaja_en, que relaciona a un empleado
con el departamento en donde trabaja.

Esta segunda alternativa es mejor desde el punto de vista del modelamiento
conceptual y presenta una clara diferencia entre atributo y tipos de entidad.

Reglas para elegir identificadores

1. No deben existir dos entidades con el mismo valor del identificador (en los
tipos de entidad).
2. En los tipos de interrelación, la clave es la composición de las claves de los
tipos de entidad involucrados, en caso que no se pueda utilizar la clave de un
subconjunto de ellos.

Ejercicios Propuestos:

1. Construir un esquema MER para una secretaria de universidad. La secretaria
mantiene datos sobre cada asignatura, incluyendo el profesor, lista de
alumnos y la hora y el lugar de las clases. Para cada par estudiante –
asignatura se registra su nota.

2. Construir un esquema MER para una compañía de seguros de autos con un
conjunto de clientes, cada uno de los cuales es propietario de un número de
autos. Cada auto tiene asociado el número de accidentes asociados.

3. Construir un esquema MER para modelar la documentación requerida para
un esquema conceptual E – R.



3.12 Normalización

Se entiende por normalización la descomposición o subdivisión de una relación en
dos o más relaciones para evitar la redundancia; en definitiva, que “cada hecho
esté en su lugar”.

El proceso de normalización generalmente se utiliza en el enfoque relacional; sin
embargo, un modelo relacional se puede modificar para su implantación en un
DBMS jerárquico o de red.

La relación universal

Supongamos que se desea implantar en una base de datos las ventas de una
determinada empresa a sus clientes por la relación ORDENES-VENTA (NCLI,
NOMBRE, LOCALIDAD, CT, NART, ARTICULO, CANT, PVP, FECHA), donde
NCLI es el número del cliente, CT es el costo de transporte y NART el número de
artículo. La implantación, tal como indica la Figura 1, no se puede realizar debido a
la gran cantidad de información redundante y los problemas que surgen a la hora
de las actualizaciones.

Relación ORDENES-VENTA

NCLI NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA
11 Luis Málaga 0.8 A1 Papel 100 5 3/5
11 Luis Málaga 0.8 A3 Cinta 50 500 5/5
11 Luis Málaga 0.8 A9 Disco 25 200 7/5
44 Ana Gijón 1.1 A1 Papel 100 5 10/5
55 José Valencia 1.4 A4 Grapas 30 50 3/5

Figura 1. Información deseada para las ORDENES-VENTA

DEPENDENCIA FUNCIONAL: DF

La normalización se basa en la dependencia funcional.

El concepto de dependencia funcional se tomó de las matemáticas. [Y = f(X)], Y es
función de X si el valor de Y está siempre determinado por el valor de X.

La dependencia funcional (DF) se define: Dados dos atributos A y B de una relación R se
dice que B es funcionalmente dependiente del atributo A si para cada valor de A existe un
valor de B, y sólo uno, asociado con él. En otros términos: si en cualquier instante, conocido
el valor de A, podemos conocer el valor de B. Se simboliza por:

A B



Tanto A como B pueden ser un conjunto de atributos en lugar de atributos simples.

La dependencia funcional establece condiciones entre atributos pertenecientes a
la misma relación. No permite establecer condiciones entre atributos
pertenecientes a la misma relación. No permite establecer condiciones entre
atributos de diferentes relaciones.

Las DF se determinan al estudiar las propiedades de todos los atributos de la
relación y deducir cómo están relacionados los atributos entre sí.

La dependencia funcional está íntimamente ligada con el concepto de clave. Para
el diseño, las claves aparecen subrayadas.
Se pueden distinguir los siguientes tipos de claves:

• Clave candidata: Conjunto de uno o más atributos que podría ser utilizado como clave
principal de una relación.
• Superclave: Conjunto de uno o más atributos que, juntos, permiten identificar de forma
única a una entidad dentro de una relación.
• Clave principal: Es una clave candidata en la que ningún componente puede tomar el
valor nulo.

Para encontrar la clave candidata es preciso estudiar las dependencias
funcionales y, a partir de ellas, obtener el mínimo conjunto posible de atributos
tales que, una vez conocidos sus valores en la tupla, los demás queden definidos

Consideremos la relación CLIENTES: NCLI, NOMBRE, LOCALIDAD, donde NCLI es el
número del cliente. Los campos NOMBRE y LOCALIDAD son funcionalmente
dependientes de NCLI: Para un valor de NCLI existe un único valor de NOMBRE y
LOCALIDAD. Se expresa:

NCLI NOMBRE
NCLI LOCALIDAD
En forma abreviada:
NCLI (NOMBRE, LOCALIDAD)

La proposición NCLI NOMBRE se lee: “el atributo
NOMBRE es funcionalmente dependiente del atributo NCLI”, o también: “el
atributo NCLI determina funcionalmente al atributo NOMBRE”.

La proposición NCLI (NOMBRE, LOCALIDAD) se puede
leer: “el atributo compuesto formado por NOMBRE y LOCALIDAD es
funcionalmente dependiente de NCLI”.

El atributo NCLI es un determinante de los atributos NOMBRE y LOCALIDAD.
Dicho de otra forma: por cada NCLI sólo puede haber un NOMBRE y una


LOCALIDAD asociados a él. NCLI es una superclave. Sin embargo, el NOMBRE no es
un determinante de la LOCALIDAD, ya que puede haber varias personas con igual
nombre en ciudades diferentes o en la misma ciudad.

Determinante: Si A B es una DF y B no es funcionalmente dependiente de A
se dice que A es el determinante de B.
Un determinante son todos los atributos situados en el lado izquierdo de una DF.

Es conveniente representar las DF de una relación en un diagrama de
dependencia funcional; en el ejemplo anterior:

NOMBRE NOMBRE
NCLI o NCLI
LOCALIDAD LOCALIDAD

El diagrama de dependencia funcional para la relación ORDENES-VENTA se
muestra en la Figura 2. Se aprecia que el atributo CANT es totalmente dependiente
de los atributos NCLI, NART y FECHA, lo que da lugar a la aparición de un nuevo
concepto: dependencia funcional total.

Dependencia funcional total: En una relación R, un atributo o colección de atributos B
tiene una dependencia funcional total de otra colección de atributos A de la relación R, si B
es funcionalmente dependiente de todos los atributos de A pero no de un subconjunto de A.

NCLI NOMBRE, LOCALIDAD, CT

CANT NART ARTICULO, PVP

FECHA

Figura 2 Diagrama de dependencia funcional



PRIMERA FORMA: 1FN

Una relación está en primera forma normal si todo atributo contiene un valor
indivisible, atómico.

Esta forma normal está justificada por la sencillez y la estética en la representación de
los registros (Fig. 1).

50 5 5/5

se puede normalizar con la creación de un registro nuevo por cada uno de los distintos
valores de un campo, tal que permita expresar la relación como una tabla

11 Luis Málaga 0.8 A3 Cinta 50 500 5/5

Una relación en 1FN contiene una serie de anomalías de almacenamiento a la
hora de realizar las actualizaciones por la información redundante, como se puede
apreciar en la Figura 1.

NORMALIZACIÓN DE LA RELACIÓN 1FN

Las anomalías de almacenamiento, que se deben a la presencia de campos no clave en la
relación, se pueden subsanar de la siguiente forma:

a) Dividiendo la relación universal en nuevas relaciones.
b) Cada relación tiene la propiedad de que su clave, en su totalidad, es necesaria para
definir cada uno de los campos no clave.

Al proceso de dividir cualquier relación en dos o más relaciones se llama proceso de
normalización. Consiste en reemplazar las relaciones por proyecciones adecuadas, de tal
forma que la reunión natural de las proyecciones genere la relación original, es decir, que no
se produzca pérdida de la información. Incluso las nuevas relaciones pueden contener
información que no se podía representar originalmente (un nuevo registro en alguna de las
nuevas relaciones), pero siempre conservando las dependencias funcionales.



Descomposición sin pérdida. Descomposición de una relación R en R1, R2, ... RN, tal que:

R = R1 * R2 * ... * RN.

Cuando se actualiza la base de datos, el sistema debe poder comprobar que la actualización
no va a generar una relación ilegal, es decir, una que no satisfaga todas las DF establecidas.

Para llevar a cabo el proceso de normalización es aconsejable dar los siguientes pasos:

1. Elegir una clave primaria que puede representar de forma única a cada registro de
la relación.
2. Construir un diagrama de dependencia en función de esas claves.
3. Construir las nuevas relaciones basándose en dichas claves.

Por el paso 1, en la relación ORDENES-VENTA, los atributos que forman la clave primaria
son: NCLI, NART, FECHA.



Los diagramas y las nuevas relaciones aparecen descritas en la figura siguiente.

Relación Clientes NCLI Nombre, Localidad, CT

Relación Artículos NART Artículo, PVP

Relación Ventas NCLI
NART CANT
FECHA

a) Diagramas de dependencias funcionales

Relación CLIENTES

NCLI NOMBRE LOCALIDAD CT
11 Luis Málaga 0.8
44 Ana Gijón 1.1
55 José Valencia 1.4

Relación ARTICULOS Relación VENTAS

NART ARTICULO PVP NCLI NART CANT FECHA

A1 Papel 5 11 A1 100 3/5
A3 Cinta 500 11 A3 50 5/5
A4 Grapas 50 11 A9 25 7/5
A9 Disco 200 44 A1 130 10/5
55 A4 30 3/5

b)Registros de las relaciones

RELACION 1FN NORMALIZADA



SEGUNDA FORMA NORMAL: 2FN

Una relación está en segunda forma normal sí, y sólo sí:

1. Está en 1FN
2. Todo atributo que no pertenezca a la clave debe depender de la clave en su
totalidad y no sólo de una parte; debe tener una dependencia funcional total.

Las relaciones mostradas en la Figura siguiente pertenecen ya a la 2FN. Sin embargo, la
relación CLIENTES presenta anomalías de almacenamiento debido a que el atributo CT es
funcionalmente dependiente de LOCALIDAD, que a su vez depende de NCLI; es decir, hay
una dependencia transitiva que ocasiona problemas a la hora de las actualizaciones.

Por ejemplo, no se puede insertar un CT para una localidad determinada hasta que haya
un cliente para dicha localidad.

Dependencia transitiva

Supongamos la relación R(A,B,C). Si A B, B C y

B A ; entonces se dice que C depende transitivamente de A y se

puede formar la cadena

A B C.
En un diagrama de dependencia funcional, C es transitivamente dependiente de A
si se tiene la siguiente situación:

Relación R A B, C

Se puede descomponer en dos relaciones por la proyección del último eslabón de
la forma;

Relación R1 A B

Relación R2 A C

Normalización de la relación 2FN

Las anomalías de almacenamiento, originadas por la dependencia transitiva en una
relación 2FN, se puede normalizar mediante los siguientes pasos:

1. En una relación, determinar el atributo que es funcionalmente dependiente de un
Versión 3.0 no clave y dibujar el diagrama de dependencia Bases de Datos I
atributo 41 funcional.


2. Crear una nueva relación para almacenar el atributo no clave y su determinante

El diagrama de dependencia funcional y las relaciones CLIENTES y TRANSPORTE se
muestran en la figura 13.4. Han desaparecido las anomalías surgidas por la
dependencia transitiva, como se puede comprobar al dar de alta un nuevo registro en
la relación TRANSPORTE, aunque no haya ningún cliente de esa ciudad.

Relación Clientes NCLI Nombre, Localidad

Relación Transportes LOCALIDAD CT

Relación Artículos NART Artículo, PVP

Relación Ventas NCLI
NART CANT
FECHA

a) Diagramas de dependencias funcionales

Relación CLIENTES

NCLI NOMBRE LOCALIDAD

11 Luis Málaga
44 Ana Gijón
55 José Valencia

Relación TRANSPORTES

LOCALIDAD CT

Málaga 0.8
Gijón 1.1
Valencia 1.4

b) Registros de las relaciones CLIENTES Y TRANSPORTES

RELACION 2FN NORMALIZADA



TERCERA FORMA NORMAL: 3FN

Una relación está en 3FN sí, y sólo sí:

1. Está en 2FN
2. Todo atributo que no pertenezca a la clave no depende de un atributo no clave.

La 3FN elimina las redundancias ocasionadas por las dependencias transitivas.

Las relaciones mostradas en la figura 13.4 pertenecen ya a la 3FN.

En la 3FN se puede decir que en cada relación no existe u atributo no clave que defina a
otro atributo. Existe una excepción: Cuando en una relación hay dos atributos que podría
ser la clave, como el DNI y l número de la seguridad social.

Unidad 4: Metodología de Diseño de una Base de Datos.


4.1 Enfoque metodológico


Todo proceso tiene entradas -recursos humanos, tecnológicos, materiales y
otros- para el desarrollo de las actividades que lo conforman; como salidas se
esperan productos, servicios, información, activos financieros u otros. Si bien la
distinción entre actividad y proceso no es nítida, por Bases de Datos I
Versión 3.0 44 lo general un proceso es
visto como un conjunto de actividades o una macro actividad.

Otra definición, entiende todo proceso como un quot;conjunto de tareas lógicamente


PROCESOS DE APOYO
Gestión de recursos humanos
Gestión de adquisiciones
Gestión de recursos
tecnológicos
Gestión de logística de entrada
Gestión de operaciones
Gestión de logística de salida
Gestión de ventas
Gestión de servicio
PROCESOS PRINCIPALES

Por tanto, los procesos principales serían los conjuntos de actividades
vinculadas a la creación, venta, transferencia y asistencia posterior de
productos o servicios; mientras que los de apoyo serían todos aquellos
conjuntos de actividades que sustentan las actividades involucradas en los
procesos principales proporcionándoles insumos, tecnologías, recursos
humanos y variadas funciones administrativas.

Modelo de Procesos por Regulación

Uno de los modelos para representar los conjuntos de actividades asociados a los
procesos es el llamado Modelo de Procesos por Regulación (MPR). El modelo
asume que el propósito de todo sistema de gestión es el de regular el
comportamiento de los recursos que manejan las organizaciones ante
perturbaciones generadas por un entorno cambiante y



no controlable. Los recursos regulados son ingresados desde el entorno hacia la
organización, para ser quot;operadosquot; o quot;transformadosquot; en su interior y devueltos al
exterior. Bajo este modelo es crucial identificar los recursos que interesan regular,
que pueden ser recursos materiales, humanos u otros.

A modo de ejemplo, para la organización de una conferencia de informática, un
recurso que interesará regular serían los trabajos que se presenten. Con propósitos
de quot;regulaciónquot; interesará información más allá del contenido del quot;trabajoquot;

Las operaciones o actividades que se ejecutan sobre los recursos son las que
están sometidas a regulación. Por tanto, a nivel de actividades suelen
distinguirse aquellas que producen bienes / servicios (actividades físicas) de
las actividades que las regulan (actividades administrativas). Lo anterior
implica que a nivel de los flujos existen los físicos y los de información. Los
flujos físicos son aquellos asociados a los recursos que se aspira regular a
través de los flujos de información. Ejemplos de flujos físicos pueden ser flujos
de materiales, de dinero, de personas, de documentos, etc. Las actividades
que tienen como entrada los flujos físicos modifican el estado de los recursos
involucrados para dar origen a productos / servicios. Las actividades
administrativas que regulan estos flujos, lo realizan a través de
procesamientos, procedimientos, monitoreo, coordinación, toma de
decisiones, dirección y control de los flujos físicos.

Los objetos del entorno son todas aquellas unidades organizacionales o
personas que originan o reciben los flujos físicos de entrada / salida, en tanto
que lo sistemas externos son aquellos con los cuales sé interactúa y que
inciden en la toma de decisiones.

La siguiente figura presenta la estructura básica de un ciclo clásico de
regulación, observándose que las actividades administrativas pueden
descomponerse en las orientadas a registrar los cambios de estado que

experimenta el recurso regulado, y aquellas orientadas a tomar decisiones que impliquen
acciones sobre las actividades físicas llevadas a cabo


Sistemas de Información

Se entenderá por sistema de información al conjunto de componentes interrelacionados
que operan conjuntamente para capturar, procesar, almacenar y distribuir información que
apoye la toma de decisiones, la coordinación, el control y análisis en una organización.
Según el nivel organizacional al cual los sistemas satisfacen y su valor para la
organización, los tipos de sistemas que interesarán son:

• de Procesamiento de Transacciones (SPT): registran las transacciones rutinarias del
negocio y que sirven para el nivel operacional de las organizaciones.
• de Apoyo a las Decisiones (SAD): están a nivel de gestión de las organizaciones, y
combinan datos y modelos analíticos sofisticados para apoyar el proceso de
decisión.
• de Información Administrativos o de Gestión (SIA o SIG): están a nivel de gestión de
las organizaciones, y apoyan las funciones de planificación y control para proveer
informes de resumen y de excepción; dependen de datos proporcionados por los
SPT.
• de Apoyo Ejecutivos (SAE): están a nivel estratégico de la organización diseñados
para apoyar las decisiones no estructuradas y crear un entorno generalizado de
automatización y comunicaciones de redes; son sistemas que incorporan
información de eventos externos, tales como políticas impositivas, comportamientos
de la competencia.



Metodología

Para estructurar un sistema de información orientado a satisfacer requerimientos
estratégicos de las organizaciones se desarrolló una metodología, apoyada en el
modelamiento de procesos por regulación, que consta de las siguientes etapas:

Etapa 1: Identificación de procesos

Utilizando la cadena de valor planteada por Porter se identifican los procesos más
relevantes dentro de una organización, diferenciando los principales y los de apoyo.
En esta etapa se deben tomar en consideración la misión y los objetivos estratégicos
fijados en la organización.

Etapa 2: Selección de procesos

Cumplido lo anterior se seleccionan aquellos en los que interesa focalizar los
esfuerzos y recursos disponibles. Entre las herramientas de apoyo utilizadas en esta
fase se encuentran el análisis FODA
(Fortalezas/Oportunidades/Debilidades/Amenazas) y los FCE (Factores Críticos de
Éxito).

Etapa 3: Descomposición de procesos

A continuación se identifican los recursos a regular, los subprocesos físicos que
afectarán al recurso involucrado, y los administrativos o de gestión que regularán el
comportamiento de los subprocesos físicos.

Etapa 4: Estructuración del sistema de información

Cada uno de los subprocesos administrativos da origen a tres subsistemas de
información: de procesamiento de transacciones, de información administrativa, y de
apoyo a las decisiones. El primero captura las transacciones que den cuenta de los
cambios de estado del recurso que se está regulando; el segundo apoya las
funciones de planificación y control; el tercero apoya el proceso de toma de
decisiones. Sobre la totalidad de estos subsistemas se implementa el sistema de
apoyo ejecutivo con propósitos de coordinación e interacción con los anteriores y
con el medio externo.

Este enfoque metodológico genera, para cada uno de los subprocesos identificados,
sistemas de información orientados a los procesos con componentes a nivel
operacional, táctico y estratégicos.



4.3. Obtención del Modelo Corporativo

Una sola visión de la base de datos puede describirse mediante un modelo. Un
modelo de visión representa un pequeño subconjunto de la realidad, apropiado
para una aplicación del contenido de la base de datos. La mayoría de las bases de
datos para especificarse requerirán varios modelos de visión. El estrecho enfoque de
visión por visión para comprender la estructura de una base de datos tiene la ventaja
de que la complejidad de los vínculos que se presentan en las bases de datos del
mundo real puede dominarse.

Cuando se ha establecido un conjunto comprensivo de modelos de visión, es posible
establecer la construcción de un modelo para toda la base de datos. Se combinan
relaciones provenientes de modelos separados de visión con base en los atributos
que tengan en común. Si los modelos de visión no tienen atributos en común no se
obtiene ningún beneficio al unir estos datos en un solo modelo de base de datos.

Aunque haya atributos comunes podría no haber conexiones. La falta de conexiones
indica que las visiones o los grupos de visiones pueden mantenerse
independientemente unas de otras. A una base de datos creada a partir de visiones
que no se conectan con otras bases de datos se les denomina base de datos
independiente, esta se mantiene mejor en forma distribuida, aún cuando el equipo de
computación sea compartido. Hay beneficios ( funcionales, geográficos, desempeño,
autonomía, confiabilidad, crecimiento) al efectuar distribución, y si las bases de datos
pueden conservarse más pequeñas y manejarse en forma autónoma, probablemente
los costos totales sean más bajos.

Para permitir consultas de recuperación con acceso a datos de múltiples bases de
datos independientes suele forzarse a que bases de datos más independientes
queden en una base de datos integrada. Actualmente sólo unos cuantos sistemas de
manejo de base de datos permiten que se procesen consultas con acceso a más de
una base de datos. El costo de combinar bases de datos independientes consiste en
un costo incrementado en demasía del sistema de base de datos, a fin de
proporcionar la independencia requerida del modelo de visión y la protección para
las transacciones de actualización. Los costos de manejo, debidos al intento de
volver comunitarias áreas en las que existen pocos incentivos naturales para
cooperar, también pueden ser altos.

Ni siquiera deben integrarse todos los modelos conectados de visión. El enlace entre
algunos conjuntos de visiones puede ser relativamente débil y no garantizará la
integración de un modelo de visión en la base de datos. Un enlace débil puede
deberse a un atributo compartido, pero que no cambia. En esos casos también se
diseñarán bases de datos


Man Base Datos I

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Destaque

Destaque (20)

Semelhante a Man Base Datos I

Semelhante a Man Base Datos I (20)

Mais de Francisco Godoy

Mais de Francisco Godoy (20)

Último

Último (20)

Man Base Datos I