• Author / Uploaded
• Silvio David

Citation preview

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

|

Enfoque por agregación

|

Sistemas de procesamiento de archivos

|

Desventajas

|

Redundancia no controlada

|

Inconsistencia de Datos

|

Inflexibilidad

|

Escasa posibilidad de compartir datos

|

Pobre estandarización

|

Baja productividad del programador

|

Excesiva Mantencion

|4

|7

| |7

|7

|

| |7

|

|7 |7

| | |7

|7

| |

|7 |7

| |

|

1.2 Enfoque de bases de datos

|

Elementos del enfoque de banco de datos

| |

Implementación del enfoque de banco de datos

|

Beneficios y riesgos de usar banco de datos

|

|9

| |9 |9

|15

1.3 Tipos de sistemas de información Operacionales

|

|

|

Administrativos

|

|

|

De apoyo a la toma de decisiones

|

Concepto Data-Warehouse 1.4 Metodologías de Desarrollo

|

1.5 Administración del recurso información

|

|

|15

|

|

|

|

Jerárquicas

|

De red

|

Relacional

|

Orientada al objeto

|

|

|17

|

|

2.1 Tipos de bases de datos

|

|

|

|2. Características y representación de datos |

|

|

|

|

|

|17 |18

| |

|17

|

|19

| |20

|

|

2.2 Naturaleza del dato

|21

|

|

2.3 Representación del dato

|

2.4 Entidades

|23

|

|

2.5 Atributos

|23

|

|

2.6 Tipos de relaciones

|

Uno a uno

|

Uno a muchos

|22

|

|23 |23 |23

| | |

|

Muchos a muchos

|

Recursivas

|

|23

|

|23

|

|

|

|3. Modelos de datos

|24

|

|

3.1 Niveles de abstracción

|24

|

|

3.2 Semántica de los datos

|26

|

|

3.3 Cardinalidad

|

3.4 Grado

|

3.5 Dependencia

|

3.6 Tiempo

|

|

|

3.7 Unicidad

|

|

|

3.8 Clase

|27

|

|

3.9 Agregación

|26

|

|26

|

|

|

|27

|

| 3.10 Modelos de datos dependientes de la tecnología | |

Jerárquico

|

De red

|

Relacional

| |

|27

|28

|

|31

|

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

4.1 Enfoque metodológico

|

Planificación Top ʹ Down

|

Diseño Bottom Up

|

|44

|44 |44

|

|44

4.2 Planificación de base de datos

| |44

|

Análisis Organizacional

|

Funciones

|46

|

|

Procesos

|47

|

|

Actividades

|

|

| |

Matrices que relacionan los componentes de una organización

|

|

|

|45

|

|

4.3 Obtención del modelo corporativo

|49

|

|53

|

| 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 Etapa 1: Formulación y análisis de Requerimientos

| |

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

|54

|

|

|

| |

| |

|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

|

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

|

|64 |

| |

|

|

| |

|

|

|

| |

|

|

|5. Lenguaje de consulta estándar (SQL)

|66

| 5.1 Instrucciones de definición de los datos

|66

|

Create

|

Alter

|66

|

|

Drop

|66

|

|66

|

| 5.2 Instrucciones de manipulación de los datos |

|67

|

Select

|67

|

|

Insert

|67

|

|

Delete

|

Update

| 5.3 Funciones Especiales

|

|67

|

|67

| |

|

| |

|

De número

|

De cadena

|

De fecha

|

|

|

|

|

|

| 5.4 Operadores de comparación | 5.5 Operadores Lógicos

|67 |68

| 5.6 Consulta sobre múltiples tablas | 5.7 Formato de salidas

| |

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

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

|Nombre Sección

| |

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

|NOMBRE |FECHA |

|LOCALIDAD

|CT

|NART

|ARTICULO

|CANT

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 NCLI

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

|NOMBRE |LOCALIDAD |PVP |FECHA |

|CT

|NART

|ARTICULO

|NCLI |CANT

|NOMBRE |LOCALIDAD |PVP |FECHA |

|CT

|NART

|ARTICULO

Relación Clientes

NCLI

Nombre, Localidad,

Relación Artículos

NART

Artículo, PVP

NART

CANT

Relación Ventas

NCLI

FECHA

a) Diagramas de dependencias funcionales

Relación CLIENTES

|NCLI

|NOMBRE

|LOCALIDAD

|11

|Luis

|Málaga

|44

|Ana

|Gijón

|55

|José

|Valencia

|0.8 |1.1 |1.4

|CT

| | | |

CT

Relación ARTICULOS

|NART

Relación VENTAS

|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

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

puede formar la cadena

A

B, B

B

C.

C

y

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

Relación Transportes

LOCALIDAD

Relación Artículos

NART

Relación Ventas

NCLI

Nombre, Localidad

CT

Artículo, PVP

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

|FEC_VEN |COD_ART

|COD_CLI |

|SUC_COD |ESTY_ART

|NOM_CLI |

|LOT

|

|SUC

|FEC_LOT

|COD_ART

|EMP

|COD_SUC

|EST_SUC

|PRO

|COD_EMP

|NOM_EMP

|COD_CLI |DES_ART

|EST_CLI |

|EST_ART

|COD_EMP |

|RTG_CLI

|COD_ART |

|

|QTY_ART

|QTY_ART

|

|

|COD_JEF

|DEF_ART

|COD_JEF

|

|

|

|

|

|

|

|

|

|

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

|

|COD_SUC

|EST_SUC

|ARTiculo

|COD_JEF

|

| |COD_ART

|1A

|AZ

|10

|

|MW

|2A

|CA

|20

|

|GC

|Gigasnarf

|1B

|AZ

|30

|

|NM

|Nanomouse

|

|

|

|

|DD

|DES_ART

|Megawamp

|Dynamic Dis

| |

| | |

|EMPleado

|

|COD_EMP

|NOM_EMP

|COD_JEF |

|

|1

|Harvey Bigcheese

|

|10

|Mary Hizzle

|11

|Marty Nogglater

|12

|Elark Kaboom

|13

|Kelly Unlucky

|12

|

|14

|Bobo Butters

|12

|

|20

|Nancy Umlat

|1

|

|22

|Kanga Rat

|24

|Xero Xanadu

|22

|

|27

|Quarkly Poslak

|20

|

|30

|Vern Equinox

|1

|32

|Otto Otter

|33

|Yarquark Moon

|35

|

|35

|Duncan Donut

|30

|

|37

|Duncan Bagel

|1

| |12

|

|10

|

|20

|

|

|35

|

|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

|12

|DD

|ID

|17 |

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

|27

|

|

|

|

|

|30

|

|

|

|

|

|32

|

|

|

|

|

|33

|

|

|

|

|

|35

|

|

|

|

|

|37

|

|

|

|

|

|43

|VENta

|

|

|FEC_VEN |QTY_ART

|COD_SUC |

|COD_CLI

|COD_EMP

|COD_ART

|04/01/94

|1A

|ZZ

|11

|MW

|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

|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

|

|23

|33

|

| | | |

|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

|AA

|Compugorp

|WA

|BB

|Technoharps

|OR

|ZZ

|Organomice

|AZ

|RTG_CLI

|

|20

|

|15

|

|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

6

Rivera

Juan

Cois 5120

23456

8

Rosa

Cois 5100

21344

7

Álvarez

Ríos

María

Cois 5130

23456

Ríos

11234

Álvarez

Rosa

21344

Rivera

Juan

7

Cois 5120

1

Cois 5100

8

Cois 5130

María

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

F

H

D

C

G

B

A

Nivel 1: Raíz

Nivel 2

Nivel 3

Estructura de un árbol

J

I

E

F

H

D

C

G

B

A

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

o

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 |Málaga

|CT |0.8

| |

| | | |

|Gijón |Valencia

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

NOMS (CHAR(20) ),

(CHAR(5), NONULL),

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 INTEGER

hilera de caracteres de longitud variable.

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

insert into

CLI COD_CLI, NOM_CLI, EST_CLI, RTG _CLI

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

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

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

25

DEF_ART

QTY_ART

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

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

DEF_ART

QTY_ART

TECHNOHARPS ORGANOMICE QUARKCO MARSWARP MULTICRUD

8- SELECT * FROM LOT WHERE EST_ART = ͚ID͛;

FEC_LOT

COD_ART

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

DEF_ART

QTY_ART

FEC_LOT

COD_ART

EST_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

DEF_ART

QTY_ART

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

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

DEF_ART

QTY_ART

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

02-07-94

GC

ID

12

15

02-01-94

GC

ID

0

55

02-02-94

NM

WA

15

25

DEF_ART

QTY_ART

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

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

DEF_ART

QTY_ART

WHERE DEF_ART = ANY(12,15);

FEC_LOT

COD_ART

02-07-94

GC

ID

02-02-94

NM

WA

02-04-94

DD

AZ

02-04-94

DD

CA

EST_ART

20- SELECT FEC_LOT, COD_ART, EST_ART FROM LOT WHERE EST_ART != ALL(͚WA͛, ͛ID͛);

FEC_LOT

COD_ART

02-02-94

NM

CA

02-04-94

DD

AZ

02-04-94

DD

CA

02-06-94

GC

AZ

EST_ART

21- SELECT COD_ART, EST_ART, DEF_ART FROM LOT WHERE DEF_ART BETWEEN 12 AND 16;

COD_ART GC ID

12

NM

WA

DD AZ

12

EST_ART

15

DEF_ART

DD CA

15

22- SELECT * FROM LOT WHERE DEF_ART != 15;

FEC_LOT

COD_ART

EST_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

DEF_ART

QTY_ART

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

26- SELECT COUNT(*)

FROM LOT; CNT(*) 9

27- SELECT COUNT(COD_JEF) SELECT EMP;

CNT(COD_JEF) 14

28- SELECT COUNT(DISTINCT COD_JEF) SELECT EMP; CNT(COD_JEF) 7

29- SELECT COD_ART, EST_ART, DEF_ART FROM LOT WHERE EST_ART = ͚ID͛;

COD_ART GC ID

12

GC ID

0

EST_ART

DD ID

30- SELECT AVG (DEF_ART) FROM LOT WHERE EST_ART = ͚ID͛;

AVG (DEF_ART) 6

31- SELECT SUM (QTY_ART) FROM LOT

DEF_ART

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