Bases de Datos I

MARZO DEL 2002

Programa de Estudios:

INGENIERÍA EN GESTIÓN INFORMÁTICA

ANALISTA PROGRAMADOR

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 |

| 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 |

Ejemplo de una base de datos en red:

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:

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:

|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 |

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

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.

Los tres niveles de la arquitectura ANSI/X3/SPARC

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

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.

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

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 |

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.

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:

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

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

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

ejemplo anterior:
 NOMBRE NOMBRE

LOCALIDAD LOCALIDAD

|NCLI |NOMBRE |LOCALIDAD |CT |NART |ARTICULO

|CANT |PVP |FECHA |

|NCLI |NOMBRE |LOCALIDAD |CT |NART |ARTICULO

|CANT |PVP |FECHA |

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 |

|A1 |Papel |5 |

|A3 |Cinta |500 |

|A4 |Grapas |50 |

|A9 |Disco |200 |

|NCLI |NART |CANT |FECHA |

|11 |A1 |100 |3/5 |

|11 |A3 |50 |5/5 |

|11 |A9 |25 |7/5 |

|44 |A1 |130 |10/5 |

|55 |A4 |30 |3/5 |

b)Registros de las relaciones

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

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

| |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 | |

[pic]

[pic]

Casos especiales:

1. "ES_UN" nos permite crear jerarquías de entidades, corresponde al concepto de

generalización de Smith y Smith (1977). Ej: tanto un libro como un artículo son documentos

Etapa 2: Diseño Lógico

En esta etapa transformaremos el esquema conceptual obtenido en la fase anterior a un

esquema relacional. Este esquema sigue siendo independiente del SGBD que se utilizará en la
siguiente etapa.

El paso del esquema E/R al relacional se basa en los siguientes principios:

ͻ Todo tipo de entidad se convierte en una relación

ͻ Todo tipo de interrelación N:M se transforma en una relación

Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de la clave o bien se

crea una nueva relación.

[pic]
 Reglas de transformación

1.-Transformación de Dominios

CREATE DOMAIN Estados_Civiles AS CHAR(1)

CHECK(VALUE in ( ͚S͛, ͚C͛, ͚V͛, ͚D͛)

2.-Transformación de entidades

CREATE TABLE... Cada entidad se transforma en una relación.

і Si las entidades que se asocian tienen ambas cardinalidades (0,1):

7.-Transformación de dependencias en identificación y en existencia

Lenguaje de definición de datos

| |

|OBJETIVOS: |

|1- RECONOCER DDL DE SQL. |

|2- IDENTIFICAR LOS TIPOS DE DATOS DE CREATE TABLE. |

|3- APLICAR CORRECTAMENTE CREATE TABLE |

|VEN |CLI |LOT |SUC |EMP |PRO

|

|FEC_VEN |COD_CLI |FEC_LOT |COD_SUC |COD_EMP

|COD_ART |

|SUC_COD |NOM_CLI |COD_ART |EST_SUC |NOM_EMP

|ESTY_ART |
|COD_CLI |EST_CLI |EST_ART |COD_JEF |COD_JEF
|DES_ART |

|COD_EMP |RTG_CLI |DEF_ART | | |

|

|COD_ART | |QTY_ART | | |
|

|QTY_ART | | | | | |

Lenguaje de manipulación de datos

| OBJETIVOS: |

|1- RECONOCER EL DML DE SSQL. |

|2- POBLAR ARCHIVOS DE BASE DE DATOS. |

|3- APLICAR CORRECTAMENTE INSERT. |

| CONTENIDO: INSERT |

|SINTAXIS: INSERT INTO table_name |

|[column_name |

|[,colum_name. ... ] ] |

|VALUES (column_value |

|[, column_value ] ); |

|Sucursal | |ARTiculo |

|COD_SUC |EST_SUC |COD_JEF | |COD_ART |DES_ART |

|1A |AZ |10 | |MW |Megawamp |

|2A |CA |20 | |GC |Gigasnarf |

|1B |AZ |30 | |NM |Nanomouse |

| | | | |DD |Dynamic Dis |

|EMPleado |

|COD_EMP |NOM_EMP |COD_JEF |

|1 |Harvey Bigcheese | |

|10 |Mary Hizzle |1 |

|11 |Marty Nogglater |12 |

|12 |Elark Kaboom |10 |

|13 |Kelly Unlucky |12 |

|14 |Bobo Butters |12 |

|20 |Nancy Umlat |1 |

|22 |Kanga Rat |20 |

|24 |Xero Xanadu |22 |

|27 |Quarkly Poslak |20 |

|30 |Vern Equinox |1 |

|32 |Otto Otter |35 |

|33 |Yarquark Moon |35 |

|35 |Duncan Donut |30 |

|37 |Duncan Bagel |35 |

|EMPleado |

|COD_EMP |COD_ART |EST_ART |DEF_ART |QTY_ART

|

|1 |GC |ID |12 |15 |

|10 |GC |ID |0 |55 |

|11 |NM |CA |17 |93 |

|12 |DD |ID | |25 |

|13 |DD |WA |22 |46 |

|14 |NM |WA |15 |25 |

|20 |DD |AZ |12 |25 |

|22 |DD |CA |15 |25 |

|24 |GC |AZ |4 |43 |

|27 | | | | |

|30 | | | | |

|32 | | | | |

|33 | | | | |

|35 | | | | |

|37 | | | | |

|VENta |

|FEC_VEN |COD_SUC |COD_CLI |COD_EMP |COD_ART

|QTY_ART |

|04/01/94 |1A |ZZ |11 |MW |23 |

|04/01/94 |1A |ZZ |11 |DD |34 |

|04/08/94 |1A |DD |12 |AB |2 |

|04/08/94 |1B |EE |24 |MW |81 |

|04/10/94 |1B |BB |27 |NM |3 |

|04/12/94 |1B |BB |27 |MW |41 |

|04/15/94 |2A |BB |33 |GC |33 |

|04/18/94 |2A |AA |35 |MW |125 |

|04/01/94 |1A |AA |10 |MW |947 |

|04/08/94 |1A |AA |10 |DD |452 |

|04/15/94 |1A |AA |10 |NM |32 |

|04/08/94 |1B |DD |11 |GC |845 |

|04/01/94 |2A |ZZ |12 |NM |45 |

|04/08/94 |2A |ZZ |12 |MW |73 |

|04/15/94 |2A |AA |30 |GC |127 |

|04/15/94 |2A |AA |30 |DD |32 |

|CLIente |

|COD_CLI |NOM_CLI |EST_CLI |RTG_CLI |

|AA |Compugorp |WA |20 |

|BB |Technoharps |OR |15 |

|ZZ |Organomice |AZ |34 |

|DD |QuarkCo |AZ |10 |

|EE |Marswarp |CA |30 |

|FF |Multicrud |NV |2 |

Manipulación de datos del SQL

| |

|OBJETIVOS: |

|1- COMPRENDER EL COMANDO SELECT EN SUS ASPECTOS MAS ELEMENTALES.

|

|2- REPRODUCIR EFICIENTEMENTE CONSULTAS EFECTUADAS EN SQL.

|

|3- IDENTIFICAR LA SEMANTICA DE CADA QWERY SOBRE SELECT.

|

FUNCIONES INTEGRADAS
| |

|OBJETIVOS: |

|1- REPRODUCIR CADA UNA DE LAS CONSULTAS.

|

|2- APLICAR FUNCIONES: SUM, COUNT Y AVG.

|

|3- IDENTIFICAR VALORES NULL. |

| OBJETIVOS: |

|1- APLICAR OPERACIONES ARITMETICAS SOBRE LOS ATRIBUTOS DE LAS RELACIONES EN

CONSULTA. |

|2- APLICAR ORDER BY Y HAVING EN LA CONFECCION DE CONSULTAS.

|

|3- INTERPRETAR SEMANTICAMENTE QWERY EN SQL.

|

| |

|OBJETIVOS: |

|APLICAR CORRECTAMENTE LAS SIGUIENTES ORDENES.

|

|ORDENES: |

|- UPDATE |

|- DELETE Y DROP |

|- CREATE VIEW |

-----------------------
MANUAL

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 logro de 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.

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;
1 Cois 5100

11234 Álvarez Rosa

6 Cois 5100

21344 Rivera Juan

7 Cois 5120

23456 Ríos María

8 Cois 5130

23456 Ríos María

11234 Álvarez Rosa

21344 Rivera Juan

7 Cois 5120

1 Cois 5100

8 Cois 5130
7 Cois 5120

6 Cois 5100

|Sección Curso |

|1 Cois 5100 |

|6 Cois 5100 |

|7 Cois 5120 |

|8 Cois 5130 |

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

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

[pic][pic]

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.

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

EMPLEADO 3

EMPLEADO 2

EMPLEADO 4
EMPLEADO 2

EMPLEADO 1

AUTO 3

AUTO 4

AUTO 2

AUTO 1

SUCURSAL

FECHA - MANTENIMIENTO

EMPLEADO

SUCURSAL

AUTOMOVIL

a) Estructura lógica con cuatro tipos de registros

Archivo jerárquico con cuatro tipos de registros

E

Nivel 1: Raíz

Nivel 2

Nivel 3

Estructura de un árbol

J
I

Estructura de red

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.

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 [pic] B
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:

ͻ 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.

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.

NCLI

NCLI

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.

NOMBRE, LOCALIDAD, CT

NCLI

NART

FECHA

CANT

ARTICULO, PVP

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).

Una relación sin normalizar, por ejemplo:

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

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.

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.
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 atributo

no clave y dibujar el diagrama de dependencia 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 |

|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

Planificación Top-Down
 Las metodologías descendentes o top-down cuya filosofía es que el esquema conceptual refleje
directamente la visión de la empresa que se intenta modelar en la BD.

Se parte del estudio del universo del discurso (UD) para elaborar el esquema conceptual y
sobre el se definen posteriormente vistas de usuario como subconjuntos de este esquema
conceptual.

Diseño Bottom-Up

Las metodologías ascendentes o bottom-up, entiende el esquema conceptual como el

resultado de la integración de las vistas de los distintos usuarios, por lo que empieza construyendo
las distintas vistas de usuario y teniendo en cuenta las restricciones entre éstas, elabora un
esquema conceptual mediante un proceso de integración de vistas.

4.2. Planificación de bases de datos

El enfoque orientado a procesos se ha transformado en el eje central sobre el cual se apoyan

los nuevos paradigmas de gestión.

Las organizaciones, funcionalmente, desarrollan múltiples actividades. El componente básico

de éstas corresponde a la tarea, entendida como una micro actividad que responsabiliza a una sola
persona. Grupos de tareas conforman actividades más complejas, que en el ámbito organizacional
asumen diversas denominaciones según los enfoques de segmentación que se manejan:
funciones, sistemas, actividades, procesos, etc.

Se define el concepto de Proceso de Negocio como un conjunto de actividades que reciben uno
o más insumos y crea un producto de valor para el cliente. La figura de cliente, que puede ser
externo o interno a la organización, establece en el proceso de negocio la idea de evaluación y
satisfacción por parte de ellos, orientando los procesos de la organización a ser eficientes en el uso
de recursos y eficaces en la atención del cliente. Los procesos de negocios son percibidos como
unidades dentro de las organizaciones, cuyos resultados pueden ser medidos y evaluados
económicamente, lo que asienta un nuevo modelo de segmentación de las empresas basados en
unidades económicamente autosuficientes.

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 lo general un proceso es visto como un conjunto de actividades o una macro actividad.

Otra definición, entiende todo proceso como un "conjunto de tareas lógicamente relacionadas
que existen para obtener un resultado bien definido dentro de un negocio". En adelante nos
basaremos en esta última definición.
 El concepto de la Cadena de Valor es la herramienta básica para examinar todas las actividades
que una empresa desempeña. Bajo ese enfoque, los procesos son clasificados en principales y de
apoyo. Los procesos principales están directamente relacionados con la actividad productiva de las
organizaciones. Los procesos de apoyo son los que apoyan, asisten, respaldan a los procesos
primarios; cuya segmentación se realiza en función de factores estratégicos, funcionales y
organizacionales. El resultado general de la segmentación de procesos es el siguiente:

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 "operados" o "transformados" 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 "regulación" interesará
información más allá del contenido del "trabajo" propiamente tal: fecha de recepción, evaluadores
asignados, resultado de la evaluación, fecha en que se informó al autor, sesión que se le asignó,
etc.

Este modelo es representado gráficamente mediante la siguiente simbología:

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

independientes de datos, con un procedimiento para mantener sincronizado el atributo

compartido.

Por ejemplo, si los empleados están identificados con un departamento, y la producción de

bienes con otro, la lista de departamentos podría proporcionar tal enlace relativamente constante.
Sólo si los empleados se relacionaran con la producción habría un acoplamiento suficientemente
fuerte entre las dos áreas para justificar la combinación de modelos de visión.

La existencia de un atributo compartido que frecuentemente se actualice en dos modelos

independientes de otro modo, proporciona otro incentivo para combinar los modelos y evitar así
esfuerzos redundantes de actualización.
 Un ejemplo de base de datos centralizada se encuentra en los sistemas de reservaciones de
líneas aéreas. Las relaciones básicas que proporcionan la disponibilidad de asientos y los
programas de vuelos tienen que compartirse por todos los usuarios y reciben frecuente acceso.

En las compañías manufactureras a menudo resultan convenientes las bases de datos

distribuidas. Puede existir gran actividad en una sola fábrica, pero que no resulte de interés para
todos los que trabajen en ella. Datos generales de entrada y salida, en términos de materiales,
dinero y productos, describen la fábrica en forma adecuada desde un punto de vista externo.

Las decisiones referentes a distribución se basan principalmente en la experiencia y la

intuición.

Hasta qué punto es más conveniente la distribución que la centralización?, depende del costo
de manejo de operaciones, comunicaciones y procesamiento.

Una base de datos distribuida no implica distribución física sino más bien una distribución de
responsabilidades a múltiples bases de datos.

Un sistema disperso puede estar bien integrado o distribuido. El costo de las comunicaciones
necesarias para un sistema integrado pero repartido en sitios remotos hará posible un enfoque
distribuido.

Cada base de datos en el conjunto distribuido tendrá sus conexiones internas y algunas con
otros sitios. Las relaciones y conexiones disponibles pueden describirse mediante un submodelo
de base de datos. Este puede representar una sola visión o aumentarse y modificarse para tener
en cuenta información y datos provenientes de otras visiones incluidos en la base de datos. Un
sitio también podría tener un modelo global integrado de todos los datos en las bases distribuidas
de datos.

Si una base de datos que opera en un sitio tiene derecho de acceso a datos provenientes de
bases ubicadas en otros puntos, puede convenir tener disponible una copia en cada sitio del
modelo global de base de datos, aún cuando en ese sitio sólo se almacenen datos para el
submodelo local de base de datos. La capacidad de cambiar localmente inclusive la parte local de
un modelo de base de datos estará restringida ahora, ya que se verán afectados modelos remotos,
aunque sus bases de datos no sean afectadas por el cambio de modelo.

Un ejemplo se presenta en los bancos, donde durante las horas de negocios, las bases de datos
primarias se encuentran en las sucursales (submodelos). Después del cierre diario, la
correspondencia de los datos locales con los datos de la oficina central (modelo global) se verifica
y se da la responsabilidad primaria al sitio central. Durante la noche, la base de datos central
puede actualizarse rápidamente con transacciones que llegan de otros bancos a la oficina central.
Los mensajes de actualización se comunican a las sucursales. En la mañana la responsabilidad pasa
a las sucursales, después de una verificación de integridad.
 Se observa que la creación de submodelos de bases de datos implica la existencia de un
modelo integrado de bases de datos (modelo corporativo) aun cuando los datos puedan no estar
integrados. En una base de datos distribuida puede existir un esquema global basado en el modelo
integrado de base de datos que ayude a las consultas globales.

Una vez que se ha decidido cuáles modelos de visión se incluirán en uno sólo, es posible
construir el modelo integrado de bases de datos, que consistirá en relaciones de varios tipos y en
las conexiones entre dichas relaciones. La combinación puede tener el aspecto de un árbol, de
cierto número de árboles (un bosque) o de una red.

Cuando se está construyendo la base integrada de datos, deben tenerse en cuenta algunos
objetivos:

1. Obtener relaciones con el mayor grado de claridad semántica.

2. Conservar la independencia de visión para simplificar la distribución posterior.

3. Tener el menor número de relaciones.

4. Tener el menor número de tuplas.

5. Hacer que el número de datos almacenados sea mínimo.

6. Hacer que el número de conexiones entre relaciones y atributos compartidos sea mínimo.

7. Hacer que sea mínima la actividad a lo largo de todas las conexiones entre relaciones.

Se han estudiado reglas para establecer una situación óptima de acuerdo con los últimos
cuatro criterios, utilizando dependencias funcionales entre atributos como elementos básicos para
la toma de decisiones. En muchos casos prácticos los diseños de bases de datos sustentados en
cualquiera de los criterios no diferirán mucho.

La claridad semántica aumenta cuando se agrupan aquellos atributos fuertemente

relacionados, y esto puede lograrse con un número limitado de relaciones y conexiones de
interrelación. A menudo la normalización habrá aumentado el número de tuplas y reducido el
número de datos almacenados. La integración puede reducir el número total de tuplas al
combinarlas, pero normalmente aumenta el número total de relaciones y sus conexiones.

El modelo integrado de base de datos puede ser complejo, pero presenta una descripción
precisa de las necesidades del usuario.

Algunas veces es mejor adaptar el submodelo de base de datos a un subconjunto propio de la

base integrada, ya que esto puede proporcionar una visión más realista de la operación y sus
restricciones. Cuando los submodelos de base de datos son subconjuntos del modelo de base de
datos, tal transformación sólo requiere selección y puede lograrse fácilmente.
4.4. Obtención de las bases de datos requeridas por la organización

Es posible construir sistemas de manejo de base de datos con una amplia gama de generalidad.
Una clasificación de estos enfoques en tres niveles distingue los sistemas que apoyan a una sola
aplicación, a varias aplicaciones del mismo tipo o a múltiples tipos de aplicaciones. Se han
desarrollado algunos sistemas a través de estos tres niveles; otros se han diseñado para resolver
problemas en un nivel especifico.

Sistemas de bases de datos de una sola aplicación

Una organización establece una operación de base de datos utilizando las facilidades
disponibles de sistema de archivo y diseña programas de aplicación que realizan una interfase a la
base de datos utilizando un paquete mantenido centralmente que implanta el grado necesario de
descripción de datos y de estructura.

El sistema original de reservación de la línea aérea American Airlines, SABRE, muchos grandes
sistemas de información, tales como MEDLARS (sistema para consultar información médica) y
sistemas de comando y control militar son ejemplos de este enfoque.

Sistemas de bases de datos para varias aplicaciones del mismo tipo.

Un grupo de usuarios trabajando en cierto tipo de áreas de aplicación reconoce la existencia de

necesidades comunes. Ellos o su vendedor de equipo electrónico diseñan un sistema que cubran
sus necesidades. Las diferencias entre usuarios se incluyen en tablas y esquemas específicos para
cada usuario. A menudo, este último paso se realiza después de obtener éxito con un sistema
orientado más bien a un solo objetivo.

Son ejemplos de este enfoque los sistema generalizados de reservación de líneas aéreas
(PARS), sistemas de información clínica (TOD, GEMÍS), y sistemas de facturación de materiales
(BOMP).

Sistemas de bases de datos de tipo de aplicación múltiple.

Un vendedor de equipo electrónico o un grupo académico diseñan un sistema con la intención

de que cubra las necesidades generales de la base de datos en una forma mejor. Desde luego,
habrá cierta tendencia a subrayar aquellos aspectos relacionados con la experiencia de los
diseñadores de manera que en la práctica se encuentra una gran diferencia entre los sistemas
generalizados. Otra fuente para los sistemas generalizados es una evolución continuada a partir de
servicios para una sola aplicación o del tipo de aplicación.
 Una orientación hacia una aplicación específica o a un tipo de aplicación permite reconocer
vínculos semánticos difíciles de explotar en un sistema generalizado. Sin embargo, un sistema
generalizado presenta un mejor equilibrio de los problemas en la implantación de un sistema de
base de datos.

4.5. Proceso de diseño de bases de datos

La concepción de una Base de Datos Relacional es una tarea larga y costosa. Existe la necesidad
de contar con procedimientos ordenados que faciliten el desarrollo de un producto software, ya
que esto tiene una incidencia en cuanto a costos y plazos de entrega, además de la calidad y
mantenimiento del producto.

Según Sommerville (1988) " un buen diseño es la clave de una eficiente ingeniería del software.
Un software bien diseñado es fácil de aplicar y mantener, además de ser comprensible y fiable. Los
sistemas mal diseñados, aunque puedan funcionar, serán costosos de mantener, difíciles de
probar y poco fiables".

Muchas veces, el diseño de una base de datos se limita aplicar la teoría de normalización,
cuando en realidad debe abarcar muchas otras etapas, que van desde la concepción hasta la
instrumentación.

Una metodología es un conjunto de modelos y herramientas que nos permiten pasar de una
etapa a la siguiente en el proceso de diseño de la base de datos. Rolland y Benci (1988).

En la determinación de las fases de la metodología debemos definir una jerarquía de niveles de

abstracción que resulte apropiada, en el sentido de ser lo suficientemente amplia para que a cada
nivel le correspondan decisiones de diseño bien definidas, pero, a la vez, no proponer demasiados
niveles, ya que sería muy sensible a la interpretación del diseñador.

No existe una metodología consagrada, sin embargo, ciertas etapas son distinguibles:

ͻ Diseño Conceptual, cuyo objetivo es obtener una buena representación de los recursos de
información de la empresa, con independencia de usuarios o aplicaciones en particular y fuera de
consideraciones de eficiencia del computador.

ͻ Diseño Lógico, cuyo objetivo es transformar el esquema conceptual obtenido en la etapa

anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar (modelo
relacional).

ͻ Diseño Físico, cuyo objetivo es conseguir una instrumentación lo más eficiente posible del
esquema lógico.
 Causas de malos diseños

ͻ Falta de conocimiento del dominio de la aplicación, conocimiento que no posee el

informático, pero sí el usuario (aunque no sepa estructurarlo ni expresarlo de forma precisa).

ͻ Falta de experiencia en el modelado

Etapa 1: Diseño Conceptual

Consiste de básicamente 2 etapas:

ͻ Etapa de análisis de requisitos

ͻ Etapa de conceptualización

El análisis de requisitos debe responder a la pregunta: qué representar? Para ello hay que
estudiar las reglas de la empresa (del negocio) a los diferentes niveles de la organización, para
elaborar una descripción de la organización. Esquema percibido.

Puede utilizarse el lenguaje natural.

La segunda etapa responde a la pregunta Cómo representar?. Aquí se utilizan los modelos
conceptuales. Nosotros utilizaremos el MER y sus extensiones, que básicamente define entidades,
atributos, interrelaciones y restricciones semánticas. Esquema conceptual.

En el paso del esquema percibido al esquema conceptual. No existen reglas claras que
permitan decidir que elemento es una entidad o cual otro una interrelación. Existen 2 enfoques.

Enfoque lingüístico y categorización de objetos.

En el enfoque lingüístico:

ͻ un sustantivo (nombre común) que actúa como sujeto o complemento directo en un frase
es por lo general un tipo de entidad, aunque podría ser un atributo. Ej.: los socios piden prestados
libros, existen 2 posibles entidades: SOCIO y LIBRO.

ͻ los nombres propios indican ocurrencias de un tipo de entidad, Ej: Date,C indica una
ocurrencia de AUTOR.

ͻ un verbo transitivo o una frase verbal es un tipo de interrelación, Ej: pedir prestado indica
una interrelación entre las entidades LIBRO y SOCIO.
 ͻ una preposición entre 2 nombres suele ser un tipo de interrelación o también establece la
asociación entre una entidad y sus atributos. Ej: la institución del autor, podemos pensar en la
interrelación entre AUTOR e INSTITUCION o bien, el atributo institución de AUTOR.

En el enfoque de categorización de objetos (Navathe, 1983):

ͻ una entidad es un objeto de datos que tiene más propiedades que su nombre o se utiliza
como operando en una sentencia de selección, borrado o inserción. Ej: en la biblioteca existen
libros que poseen una serie de propiedades, como son el título, idioma, nro. de copias, etc. LIBRO
es una entidad, ya que tiene varias propiedades. Ej: cuando un socio deja serlo, es preciso
eliminarlo de la base de datos, SOCIO es una entidad, por ser un operando en una sentencia de
borrado.

ͻ un atributo es un objeto de datos al que se asigna un valor o se utiliza como operando en

una operación aritmética, boolean, etc. Ej: se puede consultar si el título de un libro es Bases de
datos, luego, título es un atributo.

ͻ una interrelación es un objeto de datos que hace posible la selección de una entidad por
medio de una referencia a un atributo de otra entidad. Ej: seleccionar los libros que ha escrito un
determinado autor, por lo que escribir es una interrelación, ya que nos permite seleccionar una
entidad (LIBRO) por medio de una referencia a un atributo de otra entidad (Nombre de AUTOR).

Los atributos de DOCUMENTO son heredados por ARTICULO y LIBRO. También pueden haber
atributos que son exclusivos de las entidades subtipos, por ejemplo, editorial podría ser un
atributo de LIBRO pero no de ARTICULO.

2. TIENE, este verbo, posee muchas interpretaciones.

ʹ Ocurrencia de, Ej.: un libro tiene varios ejemplares, en el sentido que un ejemplar es una
ocurrencia de libro. Cual sería el identificador de la entidad, que es ocurrencia, (EJEMPLAR)???. Se
forma con el identificador de la entidad principal (LIBRO) junto a un atributo discriminante de la
ocurrencia. Ej: libros con 5 dígitos y 2 dígitos para los ejemplares.

ʹ Interrelación entre entidades Ej: los libros pueden tener más de un autor, actúa como
interrelación entre AUTOR y LIBRO.
 ʹ Asociación de las entidades con sus atributos (agregación) Ej: los libros tienen un título, un
año de publicación y un idioma, estamos asociando a la entidad LIBRO una serie de atributos.

Algunas mañas:

і Si decimos los socios piden prestados libros, estaríamos generando un diagrama con
entidades LIBRO, SOCIO, EJEMPLAR, e interrelaciones presta (LIBRO, SOCIO) y tiene
(LIBRO,EJEMPLAR), lo que es incorrecto.

і Debería ser, las mismas entidades, e interrelaciones tiene (LIBRO, EJEMPLAR) y presta
(EJEMPLAR,SOCIO).

і En las jerarquías de supertipo y subtipos, los atributos deben definirse a un nivel

adecuado, es decir, si tanto libros como artículos tienen titulo e idioma, estos atributos deben
estar en DOCUMENTO.

Características del esquema conceptual

La fase de modelación conceptual cumple los siguientes objetivos:

ͻ Captar y almacenar el universo del discurso mediante una descripción rigurosa,

representando la información que describe a la organización y que es necesaria para su
funcionamiento.

ͻ Aislar la representación de la información de los requisitos de la máquina y exigencias de

cada usuario en particular.

ͻ Independizar la definición de la información de los SGBD en concreto.

Los esquemas conceptuales se caracterizan por:

ͻ Claridad, la significación es no ambigua.

ͻ Coherencia, sin contradicciones o confusiones

ͻ Plenitud, representa lo esencial sin ser exhaustivo.

ͻ Fidelidad, la representación del universo del discurso ha de hacerse sin desviaciones ni

deformaciones.
 ͻ Simplicidad, máxima sencillez (Nº reducido de componentes, conceptos separados,
redundancia controlada).

Notar que desde un mismo universo del discurso se pueden obtener distintos esquemas
conceptuales.

El problema de la equivalencia entre DEI es importante. Algunos criterios de equivalencia son:

ͻ Compatibilidad de dominios de datos, los DEI representan el mismo UD

ͻ Equivalencia de dependencias de datos, representan las mismas restricciones.

ͻ Equivalencia de ocurrencias de datos

Existen ciertas restricciones de tipo semánticas que no son posibles de describir a través de
típicamente el MER extendido. Muchas de estas se escriben en lenguaje natural dentro del mismo
DEI.

Proceso de integración de vistas

Las vistas se dividen en idénticas y no idénticas. Las idénticas contienen los mismos tipos de
objetos, puede que con distintos nombres. Las no idénticas, poseen diferentes tipos de objetos
(todo o en parte). Dentro de estas ultimas hay que distinguir las que son equivalentes de las que
no lo son.

La integración de vistas consiste en partir de dos vistas y obtener una tercera que las englobe,
así sucesivamente hasta llegar al esquema global.

Al querer integrar vistas surgen algunos problemas:

1.- Conflictos de nombres:

ͻ Homonimia, a dos objetos se les ha asignado el mismo nombre

ͻ Sinonimia, un mismo objeto con mas de un nombre

Ejemplo: conflicto de nombre e entidades, un sistema trata con AUTOR y con cod_autor
como atributo identificador y otro, con ESCRITOR e identificador cod_escritor.

Solución: usar una sola con su respectivo identificador. Conflicto de nombre en

interrelaciones, una REVISTA publica ARTICULO o bien, en una REVISTA aparece un ARTICULO.
Solución: Cambiar el nombre, adoptar uno solo.
 2.- Conflictos entre entidades:

o una entidad es un subconjunto de otra. Solución: introducir un subtipo. Ej: entidades

REVISTA y PUBLICACION, esta última incluye además revistas, recopilaciones y otros tipos, se
puede resolver introduciendo la revista como un subtipo de publicación. Se llama restricción de
selección.

o una entidad es disjunta con respecto a otra, pero ambas poseen atributos comunes, es
decir, son un subtipo de una tercera entidad. Solución: crear el supertipo. Se llama restricción de
disyunción.

3.- Conflicto entre tipos de objetos en los que un atributo en una vista es una entidad es otra o
viceversa:

La solución es transformar el atributo en entidad o la entidad en atributo según convenga.

Ej: entidad EDITORIAL o atributo de LIBRO?. Si vemos que es importante almacenar información de
la editorial la consideraremos una entidad, sino será atributo.

4.- Conflicto de cardinalidades en interrelaciones:

Ej: interrelación escribe entre AUTOR y DOCUMENTO, en un caso 1,n y en otro n,n.

o se trata de la misma interrelación, en este caso se deja la menos restrictiva n,n.

o se trata de dos interrelaciones distintas como escribe de tipo n,n y edita de tipo 1,n
(suponiendo que un documento puede ser editado por una persona). En este caso se deben
reflejar ambas interrelaciones con distintos nombres.

o la entidad AUTOR tiene una interrelación con DOCUMENTO que es escribe, mientras que un
subtipo de ella (que es EDITOR) tiene otra interrelación con DOCUMENTO, que es edita.
 o existen dos subtipos de la entidad AUTOR, que poseen interrelaciones distintas con
DOCUMENTO, por ejemplo, el subtipo ESCRITOR y el subtipo EDITOR con las interrelaciones
escribe y edita, respectivamente.

5.- Análisis de redundancia de interrelaciones:

Una vez integradas las vistas, habrá que analizar si se producen redundancias de
interrelaciones, lo que gráficamente se refleja en ciclos.

3.-Transformación de atributos de entidades

Los AIP, pasan a ser la clave primaria de la relación PRIMARY KEY. Los AIA, pasan a ser
UNIQUE. Ambas son cláusulas en el comando CREATE TABLE.

4.-Transformación de Interrelaciones

i ) Interrelaciones N:M

Se transforma en una relación que tendrá como clave primaria la concatenación de los AIP
de las entidades que asocia. Cada uno de estos atributos que forman parte de la clave primaria son
clave foránea respecto a las tablas en donde son claves primarias. Esto se representa por al
cláusula FOREING KEY dentro del comando CREATE TABLE de la relación.

ii ) Interrelaciones 1:N

ͻ Propagar el AIP de la entidad que tiene cardinalidad máxima 1 a la que tiene n.

ͻ Transformarlo en una relación, como si se tratara de una interrelación N:M. Esto es más
conveniente cuando:

o El número de ocurrencias de la entidad que propaga su clave es muy pequeño,

evitando los valores nulos.

o Cuando se prevé que en el futuro dicha interrelación se convierta en una N:M

o Cuando la interrelación tiene atributos propios

Un aspecto importante en estas interrelaciones se relaciona con las cardinalidades

mínimas. Si la cardinalidad mínima de la entidad que se propaga es 1, significa que no pueden
admitirse valores nulos en la clave foránea (clave propagada). En cambio, si es 0, si se admiten
valores nulos.

iii ) Interrelaciones 1:1

Son casos en donde se puede crear una relación o bien propagar la clave. Esto último puede
ser en ambas direcciones.

En el MR: MATRIMONIO(cod_hombre , cod_mujer)

HOMBRE(cod_hombre,....)

MUJER(cod_mujer,....)

Así, se evitan los valores nulos que aparecerían en caso de propagar la clave de la entidad
MUJER a la entidad HOMBRE o viceversa. Recordar que no todos los hombres ni todas las mujeres
están casados.

і Una de las entidades tiene cardinalidad (0,1) y la otra (1,1), conviene propagar la clave de
la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1).

En MR: EMPLEADO(cod_empleado,...)

DEPTO(cod_depto,cod_empleado) , clave foránea, NOT NULL

і En el caso de que ambas entidades tengan cardinalidades (1,1), se puede propagar la

clave en cualquier dirección. Sería conveniente tener en cuenta acceso más frecuentes y
prioritarios de los datos.

5.-Transformación de atributos de interrelaciones

Es conveniente que aquellas interrelaciones que posean atributos propios se transformen en

una relación en donde aquellos atributos pasan a ser columnas de dicha relación.

6.-Transformación de restricciones
 Las restricciones son por ejemplo rango de valores para un determinado dominio. Muchas
de las restricciones no se representan en el esquema conceptual por lo que no existen reglas
claras para transformarlas. Usualmente las restricciones se consideran en la fase siguiente y se
implementan a través de funcionalidades particulares que ofrecen los SGBD comerciales.
Típicamente esto es a través de triggers.

En MR: LIBRO(cod_libro,...)

EJEMPLAR(cod_libro, cod_ejemplar,...)

clave foránea, NOT NULL, ON DELETE CASCADE, ON UPDATE CASCADE.

Para dependencia en identificación, la clave primaria de la entidad débil debe estar formada
por la concatenación de las claves de las dos entidades participantes en la interrelación.

8.-Transformación de tipos y subtipos

a Una sola relación, correspondiente al supertipo. Es conveniente cuando existan muy pocos
atributos diferentes entre los subtipos y las interrelaciones que los asocian con el resto de las
entidades del diagrama son las mismas para todos los subtipos.

DOCUMENTO(código, título, idioma,...,tipo)

b Una relación para entidad: el supertipo y los subtipos correspondientes. Es conveniente

cuando existen muchos atributos diferentes entre los subtipos y además se quieren mantener los
atributos comunes de todos ellos en una relación (supertipo).

DOCUMENTO(código, título, idioma,...)

ARTICULO(código,....)

LIBRO(código,...)

c Relaciones para los subtipos, que contengan además los atributos comunes. Es conveniente
cuando existen muchos atributos distintos entre los subtipos y los accesos realizados sobre los
datos de los distintos subtipos siempre afectan a atributos comunes.

LIBRO(código,título, idioma,...)

ARTICULO(código,título, idioma, ....)

 Etapa 3: Diseño Físico

Esta etapa depende del SGBD comercial que se utilizará para implementar la base de datos

Algunos elementos de diseño físico son:

Indices

Son lógicamente y físicamente independientes de los datos. Se crean o eliminan sin que
produzca efectos en la base de datos. Se mantienen en forma automática por los SGBD.

Se utiliza el comando CREATE UNIQUE INDEX.

Se estructuran en árboles B*-tree.

Secuencias

Son generadores de números secuenciales utilizados como valor único para un determinado
atributo de una relación. Sin secuencias, el proceso normal de generación de estos enteros
conlleva un bloqueo manual en acceso para actualización de la tabla que los contiene. Con este
mecanismo, las estructuras se bloquean justo en el momento de la actualización.

Se utiliza el comando CREATE SEQUENCE...

Cluster o agrupaciones

Es una estructura formada por una o varias tablas. Las filas de éstas que comparten el mismo
valor de clave se almacenan físicamente juntas.

Vistas

Son visiones lógicas de tablas, que permiten entregar a los usuarios sólo la información que a
éstos les interesa. Facilitan el control de la seguridad de la base de datos

Sinónimos

Proporcionan un nombre alternativo para referenciar tablas, vistas o secuencias.

Links

Son enlaces definidos desde la base de datos local a una base de datos remota.

Unidad 5: Lenguaje de consulta estándar (SQL).

El lenguaje de consulta estructurado (SQL) es un lenguaje de bases de datos normalizado, utilizado
por el motor de base de datos Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el
argumento de origen del método.

OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar
con el método Execute para crear y manipular directamente las bases de datos Jet y crear
consultas SQL de paso a través para manipular bases de datos remotas Cliente ʹ Servidor.

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones de agregado.
Estos elementos se combinan en las instrucciones para crear actualizar y manipular las bases de
datos.

Existen dos tipos de comandos SQL:

ͻ Los DLL que permiten crear y definir nuevas bases de datos, campos e índices.

ͻ Los DML que permiten generar consultas para ordenar , filtrar y extraer datos de la base de
datos.

5.1 Instrucciones de definición de los datos

Comandos DLL

Create:

Utilizado para crear nuevas tablas campos e índices

Alter:

Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

Drop:

Empleado para eliminar tablas e índices

5.2 Instrucciones de manipulación de los datos

Comandos DML

Select:

Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado
Insert:

Utilizado para cargar lotes de datos en la base de datos en un a única operación

Delete:

Utilizado para eliminar registros de una tabla de una base de datos.

Update

Utilizado para modificar los valores de los campos y registros especificados.

5.4 Operadores de comparación

<

Menor que

>

Mayor que

Distinto que

Mayor ó igual que

Igual que

Between

Utilizado para expresar un intervalo de valores

Like

Utilizado en la comparación de un modelo

In

Utilizado para especificar registros de una base de datos

5.5 Operadores Lógicos

And

Es el ͞y͟ lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas

Or

Es el ͞o͟ lógico. Evalúa dos condiciones y devuelve un valor de verdad si en alguna de las dos es
cierta.

Not

Negación lógica. Devuelve el valor contrario de la expresión.

5.6 Consultas sobre múltiples tablas y 5.7 Formato de las salidas

SQL y el álgebra relacional

 SQL como lenguaje para consultas se fundamenta en el álgebra relacional, se dice que SQL será
completo cuando incluya todas las operaciones del álgebra.

Se señalaba hace un par de décadas respecto de las variadas versiones existentes que la mejor
versión de SQL debería incorporar todas las operaciones del álgebra relacional.

Actualmente SQL no incluyen la operación división por esto podemos afirmar que SQL es
incompleto respecto del álgebra relacional. Sin embargo es posible emular esta operación en la
mayoría de las versiones de SQL.

Tabla de base

Es una tabla que tiene existencia independiente. En la base de datos física se representa por un
archivo almacenado. Se puede crear una tabla de base en cualquier momento ejecutando la
proposición CREATE TABLE del DDL de SQL, la cual adopta la forma general:

CREATE TABLE nombre-de-tabla-de-base

(definición-de-campo [,definición-de-campo ] ...)

[ IN SEGMENT nombre-de-segmento ]

donde una definición-de-campo, a su vez, adopta la forma:

nombre-de-campo ( tipo-de-datos [NONULL] )

(salvo que se indique de modo explícito lo contrario)

CREATE TABLA S ( SX (CHAR(5), NONULL),

NOMS (CHAR(20) ),
 ESTADO (SMALLINT) ),

CIUDAD(CHAR(15) ) )

CREATE TABLA P ( PX (CHAR(6), NONULL),

NOMP (CHAR(20) ),

COLOR (CHAR(6) ),

PESO (SMALLINT) ),

CIUDAD(CHAR(15) ) )

CREATE TABLA SP( SX (CHAR(5), NONULL),

PX (CHAR(6), NONULL),

CTD (INTEGER) )

La ejecución fructífera de una proposición CREATE TABLE hace que una tabla de base nueva
(vacía) se cree en el segmento especificado con el nombre-de-tabla-de-base especificado v las
definiciones-de-campo especificadas. (Los segmentos y las definiciones-de-campo se explican más
adelante). El usuario puede ahora proceder a introducir datos en esa tabla usando la proposición
INSERT de SQL (parte del DML de SQL). Por otra parte, el usuario puede invocar al cargador de
System R, que es un programa de utilería suministrado por el sistema para realizar esta función.

Campos

Cada definición-de-campo de CREATE TABLE incluye tres elementos: un nombre-de-campo, un

tipo-de-datos para el campo y (como opción) una especificación NONULL. El nombre-de-campo,
desde luego, debe ser único en la tabla de base. Los tipos-de-datos permitidos son los siguientes:

CHAR (n) hilera de caracteres de longitud fija.

CHAR (n) VAR hilera de caracteres de longitud variable.

INTEGER entero en binario de una palabra.

 SMALLINT entero en binario de media palabra.

FLOAT número en punto flotante de doble palabra.

SQL admite el concepto de valores de campos nulos. En efecto, cualquier campo puede contener
un valor nulo a menos que la definición de ese campo en CREATE TABLE incluya de modo explícito
la especificación NONULL. Nulo es un valor especial que se usa para representar un "valor
desconocido͟ o un ͞valor inaplicable". Por ejemplo, un registro de remesa puede contener un
valor nulo de CTD (se sabe que la remesa existe, pero se desconoce la cantidad enviada); o un
registro de proveedor puede contener un valor nulo de ESTADO (quizá el "estado" no se aplique a
los proveedores de parís por alguna razón). Aquí no se estudian en detalle las propiedades del
valor nulo, sino que basta señalar que (a) las expresiones aritméticas donde uno de los operandos
es nulo se evalúan en el valor nulo, y (b) las comparaciones donde uno de los operandos de
comparación es nulo se evalúan en el valor de verdad "desconocido".

Al igual que una tabla de base nueva puede crearse en cualquier momento, también una tabla de
base existente puede agrandarse en cualquier instante, adicionando una nueva columna (un
campo) a la derecha:

EXPAND TABLE nombre-de-tabla-de-base

ADD FIELD nombre-de-campo (tipo-de-datos)

Por ejemplo

EXPAND TABLE SP

ADD FIELD FECHA ( CHAR (6) )

Esta proposición adiciona un campo FECHA a la tabla SP. Todos los registros existentes de SP se
aumenta de tres a cuatro campos; el valor del campo nuevo es nulo en cada caso (no se permite
la especificación NONULL en EXPAND TABLE ). Nótese, además, que la ampliación de los registros
existentes antes mencionada no significa que los registros de la base de datos sean en realidad
actualizados en ese instante solo su descripción almacenada cambia. También es posible destruir
una tabla de base existente en cualquier instante:
 DROP TABLE nombre-de-tabla-de-base

Todos los registros de tabla de base especificada se eliminan, todos los índices y las vistas sobre
esa tabla se destruyen, y luego se destruye, también la tabla misma (es decir, su descripción se
suprime del diccionario y su espacio de almacenamiento se libera).

Índices

Al igual que las tablas de base, los índices se crean y eliminan usando el DDL de SQL sin embargo,
CREATE INDEX y DROP INDEX así como ciertas proposiciones de control de los datos, son las únicas
del lenguaje SQL que se refieren a los índices; otras proposiciones -en particular las de acceso a los
datos, como SELECT- no incluyen de modo explícito ninguna de esas referencias. La decisión en
cuanto a usar o no un índice al responder una solicitud particular de datos no la toma el usuario,
sino System R (en realidad el optimizador componente del precompilador de RDS).

CREATE INDEX adopta la forma general:

CREATE [UNIQUE] INDEX nombre-de-índice ON

Nombre-de-tabla-de-base

(nombre-de-campo [ORDER] [, nombre-de-campo [ORDER] ] ...)

donde "orden" es ASC (ascendente) o DESC (descendente). Si no se especifica ASC ni DESC,

entonces se supone ASC por omisión. La secuencia de izquierda a derecha de los campos
nombrados en la proposición CREATE INDEX corresponden a un ordenamiento de mayor a
menor en la manera usual; por ejemplo, la proposición:

CREATE INDEX X ON T ( A, B, C )

creará un índice llamado X sobre la tabla de base T donde las entradas se ordenan por valores
ascendentes de C dentro de valores ascendentes de B dentro de los valores ascendentes de A.
Una vez creado, un índice se mantiene de manera automática (por RSS) para reflejar las
actualizaciones en la tabla de base indicada, hasta el instante en que el índice se suprime. La
opción UNIQUE de CREATE INDEX especifica que no habrá dos registros en la tabla de base
indicada a los que se les permita tomar el mismo valor para el campo o combinación de campos
indicados (al mismo tiempo). Esta es la única manera de especificar que no se permiten valores
duplicados para ningún campo o combinación de campos. De esta manera, si se desea hacer
cumplir la unicidad de las llaves primarias en la base de datos de proveedores y partes, se deben
añadir proposiciones tales como las siguientes:

CREATE UNIQUE INDEX XS ON S ( SX )

CREATE UNIQUE INDEX XP ON P ( PX )

CREATE UNIQUE INDEX XSP ON SP ( SX PX )

(los índices, al igual que las tablas de base, se pueden crear y suprimir en cualquier momento. En
el ejemplo se debe asegurar que los índices XS, XP y XSP se crean antes de colocar cualquier dato
en las tablas de base S, P y SP; de lo contrario, las restricciones de unicidad pueden haberse
violado. Un intento de crear un índice único sobre una tabla que no satisfaga la restricción de
unicidad tendrá que fracasar). La proposición para suprimir un índice es DROP INDEX nombre-de-
índice.

El comando CREATE TABLE es usado para crear archivos de base de datos, también se
encuentra un par de comandos para insertar tuplas o para actualizarlas. Se puede definir un
archivo o tabla de hasta 27 Columnas.

SINTAXIS : CREATE TABLE table-name ( column_definition

[, column_definition . . .]

[, uniqueness constraint] );

COMPONENTES DE CREATE TABLE table_name

El nombre de un archivo de base de datos puede ser de 1 a 10 caracteres. Los primeros ocho
caracteres son los significativos, el primer carácter debe ser alfabético.

Column_definition

Column_name data_type [NOT NULL [UNIQUE]]

column_name

Un atributo puede tener de 1 a 10 caracteres, el primer carácter del atributo debe ser una
letra.

data_type

Los tipos de datos son de dos clases: números o caracteres.

Numeric

(Exact Numeric)

NUMERIC [ ( length [.decimal_places] ) ]

DECE [ (length [, declmal_places ] ) ]

INT

SMALLINT

Characters

[Char (length) ]
 Este tipo de datos permite combinar caracteres, se justifica a la izquierda, el máximo es
ochenta caracteres. CHARACTER y CHAR pueden usarse indistintamente. Si se omite el length
modifier, entonces se asume el largo uno.

Date

Este tipo crea una columna de ancho ocho caracteres. Las fechas son de la forma mm/dd/'yy
estimándose atómica.

Logical

Y, y, N, n, T, t, F, f, or ?

Not Null

Caracteriza valores que son distinto de ͞blanco͞.

UNIQUE modifier

Señala llave primaria.

ACTIVIDAD:

͞EMPRESA MANUFACTURAS MONOLITICAS͟

Manufacturas monolíticas produce y vende productos de alta calidad en el oeste de los EE.UU.
posee sucursales en varios estados. Los productos son manufactura dos por lotes, cuando el lote
es terminado se registra en la base de datos, específicamente en el archivo de base de datos
correspondiente, con la fecha, el código del producto, el estado donde el producto fue
manufacturado la cantidad de ítems vendibles y el porcentaje de defectuosos del lote. Señala al
archivo de manufacturado el archivo de productos algo tan simple como, dado el código, la
descripción del producto. Las ventas efectuadas por cada sala de venta es registrada en un archivo
de ventas. Cuando una venta es efectuada, se registra la fecha, la sucursal, el comprador, el
vendedor, el producto y la cantidad vendida. Señala el archivo de ventas al archivo de sucursales,
al de vendedores y al de clientes. El archivo de empleados contiene el número del empleado, su
nombre, y el empleado jefe. El archivo de sucursales contiene el número de sucursal el estado y
el administrador. El archivo de cliente contiene el número de cliente, el estado donde reside, su
nombre.

En detalle los seis archivos de la base de datos de manufacturas monolíticas:

Ejemplificamos con la creación del archivo de base de datos CLI(ente):

create table CLI (

COD_CLI char(2) not null unique,

NOM_CLI char(15) not null,

EST_CLI char(2) not null,

RTG CLI numeric(2) );

EJEMPLO: insert into CLI COD_CLI, NOM_CLI, EST_CLI, RTG _CLI

values (͚AA͛, ͚Compugorp͛, ͚WA͛ ,20);

ACTIVIDAD: Dada la siguiente lista de tuplas de la base de datos de manufacturas monolíticas,

poblar los archivos del ejercicio anterior.

En esta parte se presenta la porción de DML del lenguaje SQL El DML de SQL opera a la vez con
tablas de base y vistas.

Operaciones de recuperación

La operación fundamental en SQL es la transformación, que se representa sintacticamente como

un bloque SELECT-FROM-WHERE. Por ejemplo, la consulta ͞obtenga números de proveedores y
estado para los proveedores en parís" puede expresarse como sigue:
 SELECT SX, ESTADO

FORM

WHERE CIUDAD = ͚PARIS͛

Se puede advertir en este ejemplo que la operación de 'transformación" es, en efecto, la

formación de un subconjunto horizontal (halle todos los renglones donde CIUDAD = "PARIS")
seguida de la formación de un subconjunto vertical (extraiga Sx y ESTADO de estos renglones). En
términos algebraicos se puede considerar como un SELECT seguido por un PROJECT excepto que,
como se señala después, la operación encaminada a formar un subconjunto horizontal puede ser
mucho más compleja que la sencilla operación algebraica SELECT. (no

debe confundirse el SELECT algebraico con el SELECT de SQL) Ahora se procede a explicar las
características principales del lenguaje de recuperación por medio de un conjunto de ejemplos
desarrollados con cuidado.

Recuperación simple

Obtenga los números de parte de todas las partes suministradas:

SELECT PX

FROM SP

Se sugirió que una transformación (SELECT-FROM-WHERE) puede considerarse como una

formación de un subconjunto horizontal seguida por una proyección. En este ejemplo, el
subconjunto horizontal es la tabla completa (sin la cláusula WHERE). En cuanto a la proyección,
se recuerda al lector que PROJECT, como se definió formalmente, opera extrayendo columnas
especificadas y luego eliminando los renglones duplicados redundantes de las columnas extraídas
(el resultado es una relación, sin renglones duplicados). Sin embargo, SQL en general no elimina
los duplicados del resultado de ejecutar una proposición SELECT a menos que el usuario lo
solicite de modo explícito por medio de la palabra clave UNIQUE, como en el ejemplo
siguiente:

SELECT UNIQUE PX

FROM SP

La justificación para exigir al usuario que especifique UNIQUE en tales casos es que (a) la
eliminación de duplicados puede ser una operación costosa, y (b) los usuarios a menudo no
advertirán la presencia de los duplicados en sus resultados. Además, se adopta en INGRES una
filosofía semejante.

Recuperación simple

Obtenga todos los detalles de todos los proveedores.

SELECT *

FORM S

Resultado : Una copia de la tabla S completa.

El asterisco es una abreviatura de una lista ordenada de todos los nombres de campo en la tabla
FROM (como lo especificó el diccionario se SQL en el momento en que el SELECT se precompiló: no
se incluirá ningún campo agregado después de la tabla por medio de EXPAND TABLE). La
proposición SELECT mostrada es, pues, equivalente a:

SELECT SX, NOMS, ESTADO, CIUDAD

FROM S
Recuperación calificada:

Obtenga números de proveedor para los proveedores de París con estado > 20.

SELECT SX

FROM S

WHERE CIUDAD = aPARISa

AND ESTADO > 20

La condición o predicado que sigue a WHERE puede incluir los operadores de comparación =, =(no
igual), >, >=, 25

El proveedor S5 no satisface los requisitos. Cuando un valor nulo se compara con algún otro valor
al evaluar un predicado, cualquiera que sea el operador de comparación utilizado, el resultado de
la comparación nunca es verdadero, incluso si ese otro valor también es nulo; en otras palabras,
ninguna de las siguientes comparaciones da verdadero:

nulo > 25

nulo < 25

nulo = 25

nulo = 25

nulo = nulo

ACTIVIDAD:

APLICANDO SQL PRUEBE CADA UNO DE LOS SIGUIENTES EJEMPLOS

1- SELECT *

FROM LOT;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-02-94 NM CA 17 93

02-02-94 DD ID 25

02-03-94 DD WA 22 46

02-02-94 NM WA 15 25

02-04-94 DD AZ 12 25

02-04-94 DD CA 15 25

02-06-94 GC AZ 4 43

2- SELECT COD_ART, EST_ART

FROM LOT;

COD_ART EST_ART

GC ID

GC ID

NM CA

DD ID

DD WA

NM WA

DD AZ
 DD CA

GC AZ

3- SELECT DISTINCT EST_ART

FROM LOT;

EST_ART

ID

CA

WA

AZ

4- SELECT EST_ART, COD_ART

FROM LOT;

EST_ART COD_ART

ID GC

ID GC

CA NM

ID DD

WA DD

WA NM

AZ DD

CA DD

AZ GC
5- SELECT *

FROM CLI

WHERE EST_CLI = ͚AZ͛;

COD_CLI NOM_CLI EST_CLI RTG_CLI

ZZ ORGANOMICE AZ 34

DD QUARKO AZ AZ

6- SELECT *

FROM LOT

WHERE DEF_ART > 10;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-02-94 NM CA 17 93

02-03-94 DD WA 22 46

02-02-94 NM WA 15 25

02-04-94 DD AZ 12 25

02-04-94 DD CA 15 25

7- SELECT NOM_CLI

FROM CLI

WHERE NOM_CLI > ͚MACHADO͛;

NOM_CLI
 TECHNOHARPS

ORGANOMICE

QUARKCO

MARSWARP

MULTICRUD

8- SELECT *

FROM LOT

WHERE EST_ART = ͚ID͛;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-02-94 DD ID 0 25

9- SELECT COD_ART

FROM LOT

WHERE DEF_ART IS NULL;

COD_ART

DD

10- SELECT *

FROM LOT

WHERE DEF_ART IS NOT NULL;

 FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-02-94 NM CA 17 93

02-03-94 DD WA 22 46

02-02-94 NM WA 15 25

02-04-94 DD AZ 12 25

02-04-94 DD CA 15 25

02-06-94 GC AZ 4 43

11- SELECT DISTINCT COD_ART

FROM LOT

WHERE EST_ART = ´WA´ AND DEF_ART > 16;

COD_ART

DD

12- SELECT DISTINCT COD_ART

FROM LOT

WHERE EST_ART = ´WA´ OR EST_ART = ͚ID͛;

COD_ART

GC

DD

NM
13- SELECT DISTINCT COD_ART

FROM LOT

WHERE EST_ART = ´WA´ AND EST_ART = ͚ID͛;

COD_ART

NO ROWS FOUND

14- SELECT *

FROM LOT

WHERE NOT(EST_ART = ´WA´ OR EST_ART = ͚ID͛);

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-02-94 NM CA 17 93

02-04-94 DD AZ 12 25

02-04-94 DD CA 15 25

02-06-94 GC AZ 4 43

15- SELECT DISTINCT COD_ART

FROM LOT

WHERE COD_ART ¡= ͚NM͛ AND COD_ART ¡= ͚GC͛ AND COD_ART ¡= ͚DD͛;

16- SELECT DISTINCT COD_ART

FROM LOT

WHERE EST_ART = ͚WA͛ OR EST_AR = ͚ID͛;

 COD_ART

GC

DD

NM

17- SELECT DISTINCT COD_ART

FROM LOT

WHERE (EST_ART = ͚WA͛ OR COD_ART = ͚ID͛) AND DEF_ART < 16;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-02-94 NM WA 15 25

18- SELECT DISTINCT COD_ART

FROM LOT

WHERE EST_ART = ͚WA͛ OR COD_ART = ͚ID͛ AND DEF_ART < 16;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-03-94 DD WA 22 46

02-02-94 NM WA 15 25

19- SELECT FEC_LOT, COD_ART, EST_ART

FROM LOT
 WHERE DEF_ART = ANY(12,15);

FEC_LOT COD_ART EST_ART

02-07-94 GC ID

02-02-94 NM WA

02-04-94 DD AZ

02-04-94 DD CA

20- SELECT FEC_LOT, COD_ART, EST_ART

FROM LOT

WHERE EST_ART != ALL(͚WA͛, ͛ID͛);

FEC_LOT COD_ART EST_ART

02-02-94 NM CA

02-04-94 DD AZ

02-04-94 DD CA

02-06-94 GC AZ

21- SELECT COD_ART, EST_ART, DEF_ART

FROM LOT

WHERE DEF_ART BETWEEN 12 AND 16;

COD_ART EST_ART DEF_ART

GC ID 12

NM WA 15

DD AZ 12
 DD CA 15

22- SELECT *

FROM LOT

WHERE DEF_ART != 15;

FEC_LOT COD_ART EST_ART DEF_ART QTY_ART

02-07-94 GC ID 12 15

02-01-94 GC ID 0 55

02-02-94 NM CA 17 93

02-03-94 DD WA 22 46

02-04-94 DD AZ 12 25

02-06-94 GC AZ 4 43

23- SELECT

FROM LOT

WHERE DEF_ART != 15;

(NO HAY RESULTADO, NO SE INDICO LO QUE SE DEBIA SELECCIONAR)

El lenguaje de recuperación descrito hasta ahora es ͞completo͟, según se acaba de explicar, es aún
inadecuado para muchos problemas prácticos. SQL, por tanto, proporciona varias funciones
integradas especiales para mejorar su poder básico de recuperación. Las funciones soportadas
actualmente son: COUNT, SUM, AVG, MAX y MIN. Todas estas funciones producen el siguiente
resultado:

COUNT : el número de valores

SUM : la suma de los valores

 AVG : el promedio de 10 valores

MAX : el valor más grande

MIN : el valor más pequeño

ACTIVIDAD:

En SQL aplique cada una de las consultas dadas e identifique la semántica de cada consulta,
señale en que consultas afectan los valores NULL de los archivos de base de datos monolítica.

24- SELECT COUNT(COD_ART)

FROM LOT;

CNT(COD_ART)

25- SELECT COUNT(DISTINCT EST_ART)

FROM LOT;

CNT(EST_ART)

26- SELECT COUNT(*)

FROM LOT;

CNT(*)

27- SELECT COUNT(COD_JEF)

SELECT EMP;
 CNT(COD_JEF)

14

28- SELECT COUNT(DISTINCT COD_JEF)

SELECT EMP;

CNT(COD_JEF)

29- SELECT COD_ART, EST_ART, DEF_ART

FROM LOT

WHERE EST_ART = ͚ID͛;

COD_ART EST_ART DEF_ART

GC ID 12

GC ID 0

DD ID

30- SELECT AVG (DEF_ART)

FROM LOT

WHERE EST_ART = ͚ID͛;

AVG (DEF_ART)

31- SELECT SUM (QTY_ART)

FROM LOT
 WHERE COD_ART = ͚DD͛;

SUM(QTY_ART)

121

32- SELECT AVG (QTY_ART), SUM (QTY_ART)

FROM LOT

WHERE COD_ART = ͚DD͛;

AVG(QTY_ART) SUM(QTY_ART)

30 121

ACTIVIDAD:

Reproducir cada consulta e indicar su correspondiente significado.

33- SELECT COD_ART, DEF_ART*2

FROM LOT;

COD_ART DEF_ART

GC 24

GC 0

NM 34

DD

DD 44

NM 30

DD 24
 DD 30

GC 8

34- SELECT EST_ART, AVG(DEF_ART)

FROM LOT

GROUP BY EST_ART;

EST_ART AVG(DEF_ART)

AZ 8

CA 16

ID 6

WA 18

35- SELECT EST_ART, AVG(DEF_ART)

FROM LOT

GROUP BY EST_ART HAVING AVG(DEF_ART) > 10;

36- SELECT FEC_LOT, COD_ART, DEF_ART

FROM LOT

WHERE EST_ART = ͚ID͛

ORDER BY ART_DEF;

37- SELECT FEC_LOT, EST_ART, COD_ART, QTY_ART

FROM LOT

GROUP BY FEC_ART, EST_ART;

 Una vista es una relación o archivo de base de datos derivado, que describe una alternativa de
acceso a los archivos de la base de datos (que ya existen), las vistas son relaciones virtuales.

SINTAXIS:

CREATE VIEW view_name [(column_name

[, column_name... )]] AS

select_statement

UPDATE

Permite modificar los valores de los atributos.

SINTAXIS:

UPDATE table_name

SET column_name = value [, column_name = value...]

WHERE search_condition

DELETE (ATRIBUTOS)

SINTAXIS:_

DELETE FROM table_name

WHERE search expression]

DROP TABLE/VIEW

El comando DROP elimina archivos de base de datos y vistas.

SINTAXIS:

DROP TABLE table_name; o DROP VIEW view_name;

ACTIVIDAD:

Determine la salida de cada consulta sin aplicar SSQL, aplique sólo para verificar.

38- SELECT *

FROM LOT

WHERE EST_ART = ͚AZ͛

REDIRECTO ARIZ ORDER BY COD_ART;

39- SELECT COD_ART, EST_ART

FROM LOT WHERE EST_ART = ͚CA͛

UNION

SELECT COD_ART, EST_ART

FROM PRO WHERE EST_ART = ͚ID͛;

40- SELECT NOM_CLI, COD_ART, QTY_ART

FROM VEN, CLI

WHERE VEN.COD_CLI = CLI.COD_CLI;

41- SELECT COD_CLI, QTY_ART

FROM VEN

WHERE COD_ART = ͚NM͛

AND QTY_ART >

(SELECT SUM(QTY_ART)

FROM VEN

WHERE COD_CLI= ͚BB͛

AND COD_ART = ͚NW͛);

42- SELECT DISTINCT COD_ART

FROM VEN

WHERE COD_CLI IN

(SELECT COD_CLI

FROM CLI

WHERE EST_CLI = ͚AA͛);

43- SELECT *

FROM VEN

WHERE QTY_ART >

(SELECT AVG(QTY_ART)

FROM VEN);

44- ¡Suponga existe VEN1 idéntica a VEN!

SELECT *

FROM VEN, VEN1

 WHERE QTY_ART >

(SELECT AVG(QTY_ART)

FROM VEN

WHERE VEN.COD_ART = VEN1.COD_ART);

45- SELECT DES_ART

FROM ART

WHERE EXIST

(SELECT *

FROM VEN

WHERE ART_COD_ART = VEN.COD_ART);

46- UPDATE CLI

SET RTG_CLI = RTG_CLI + 5

WHERE COD_CLI = ͚AA͛;

47- UPDATE CLI

SET RTG_CLI = NULL

WHERE COD_CLI = ͚CC͛;

48- UPDATE LOT

SET DEF_ART = 10

WHERE FEC_LOT = ͚07/21/94͛ AND COD_CLI = ͚GC͛

AND EST_ART = ͚ID͛;

49- UPDATE CLI

 SET RTG_CLI = 14, EST_CLI = ͚ID͛

WHERE COD_CLI = ͚BB͛;

50- UPDATE CLI

SET RTG_CLI = 30

WHERE COD_CLI IN

(SELECT DISTINCT COD_CLI

FROM CLI, VEN

WHERE CLI.COD_CLI = VEN.COD_CLI AND COD_SUC = ͚2A͛;

AND QTY_ART >

(SELECT AVG(QTY_ART)

FROM VEN) );

51- DELETE FROM CLI;

52- DELETE FROM CLI

WHERE RTG_CLI < 10;

53- SELECT *

FROM VEN

WHERE COD_CLI IN

(SELECT COD_CLI

FROM CLI

WHERE RTG_CLI < 10);

54- DELETE FROM VEN

 WHERE COD_CLI IN

(SELECT COD_CLI

FROM CLI

WHERE RTG_CLI < 10);

55- DELETE FROM VEN

WHERE NOT EXISTS

(SELECT *

FROM CLI

WHERE VEN.COD_CLI = CLI.COD_CLI);

56- CREATE VIEW CLTE AS

SELECT COD_CLI, NOM_CLI, EST_CLI

FROM CLI;

57- SELECT *

FROM CLTE;

58- DROP TABLE CLI

59- DROP VIEW CLTE

Fin

BIBLIOGRAFÍA
ͻ Silberschatz, Abraham Korth, Sudarshan, S. Fundamentos de Bases de Datos, Tercera Edición,
Madrid, Editorial Mc Hill, 1998.

ͻ Wiederhold, Gio Diseño de Bases de Datos. Segunda Edición, USA, Editorial Mc Graw Hill, 1998.

ͻ http://usuarios.tripod.es/smaug

ͻ Bases de Datos tema1. DECUPS, curso 2000 ʹ 2001.

ͻ Introducción a las Bases de Datos, Victor Pérez, Editorial Universitaria.

ͻ Introducción a los Sistemas de Bases de Datos, C. J. Date, Prentice H.

CC42A Bases de Datos, Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas,

Departamento de Ciencias de la Computación