Você está na página 1de 85
Tema V: Tecnología de bases de datos 3 1. Organización de los Datos 3 1.1. Tipos

Tema V: Tecnología de bases de datos

 

3

  • 1. Organización de los Datos

3

  • 1.1. Tipos de organización de datos

3

  • 1.2. Tipos de acceso a los

4

  • 2. Sistema tradicional de archivos

5

  • 3. Sistema de Bases de Datos

6

  • 4. Modelos de Base de Datos

9

  • 4.1. Modelo jerárquico de datos

9

4.2

Modelo de datos en red

......................................................................................................................

10

  • 4.3. Modelo relacional de datos

11

  • 4.4. Ventajas y desventajas de los tres modelos de bases de datos

13

  • 5. Modelos de Datos Conceptuales (Semánticos)

15

  • 5.1. Elementos del Modelo Entidad-Relación

.........................................................................................

15

  • 5.2. Diagramas Entidad - Relacionamiento (objetos de datos y sus relaciones)

16

  • 5.3. Modelo de Datos

 

17

 

Fases de la Metodología para la estructuración de los datos

................................................................

17

  • 5.4. Definición de Conceptos del Modelo Entidad Relacionamiento

18

 

Entidades

18

Clasificación de las

19

Atributos ...............................................................................................................................................

19

Identificador .........................................................................................................................................

20

Atributos de Multivalor

21

  • 5.5. Relacionamientos (Asociación) ........................................................................................................

21

 

Grado de un relacionamiento

................................................................................................................

21

Gerundios

23

Conectividad (Cardinalidad) en el relacionamiento

23

Cardinalidad Mínima y Máxima

23

Dependencia de Existencia ...................................................................................................................

24

Comentarios sobre el Relacionamiento

24

5.6

Modelamiento de atributos multivalor

26

5.7.

Datos Dependientes del Tiempo

27

5.8.

Generalización - Especialización

 

28

Subtipos Y Supertipos

28

 

30

  • 1. Estrategia de Diseño de la Base de Datos

................................................................................................

30

1.1.

Diagrama de las fases del enfoque de bases de datos

30

FASE I: Generación del Modelo Conceptual

30

31

Proceso de Normalización

31

Primera Forma Normal (1ª FN):

31

Segunda forma normal (2ª FN)

32

Tercera forma normal (3 FN)

 

32

Relaciones muchos a muchos

32

........................................................................

33

Relaciones Redundantes ...................................................................................................................

33

Herencia

35

Fase III: Modelo de Procesos de Datos

 

35

  • 2. Modelo Relacional

40

2.1.

Tablas

40

2.2.

Relación .............................................................................................................................................

40

2.3.

Tablas relacionales

40

2.4.

Claves

40

2.5.

Operaciones sobre Tablas

40

40 40 40 Producto 41 Join. ...................................................................................................................................................... 41 Reglas De Transformación 3.1. ................................................................................................................ 42 Tema VII:
 

40

40

40

Producto

41

Join. ......................................................................................................................................................

41

Reglas De Transformación

  • 3.1. ................................................................................................................

42

Tema VII: Lenguaje de programación SQL

46

  • 1. Ejemplo de comandos

48

  • 2. Ejemplo de comandos

52

  • 2.1. INSERT.

...........................................................................................................................................

52

Inserción de un solo

52

Inserción de un solo registro, omitiendo nombres de

53

Inserción de un solo

53

  • 2.2. UPDATE (ACTUALIZAR)

54

Modificación de un solo

54

Modificación de varios

54

  • 2.3. DELETE (ELIMINAR) ....................................................................................................................

54

Eliminación de un solo

55

Eliminación de varios

55

  • 3. Ejemplo de comandos

56

3. SELECT [ ALL | DISTINCT ] select-list

56

  • 1. Tecnologías Web para el Desarrollo de Sistemas de Información

68

  • 1.1. Lenguaje de Hipertexto Basado en Marcas (HTML)

68

  • 1.1.1. Páginas Estáticas y

69

  • 1.1.2. Herramientas para la Construcción de Páginas Web

69

  • 1.2. Lenguaje de Marcas Extensibles (XML)

..........................................................................................

71

  • 1.3. Herramientas para Páginas Web Personales (PHP)

73

  • 1.4. MySQL .............................................................................................................................................

74

  • 1.5. Java ...................................................................................................................................................

74

  • 2. Aplicación de UML en el Modelado de un Sistema de Información de Gestión del Recurso

76

  • 2.1. Contexto de la Situación

...................................................................................................................

76

  • 2.2. Modelo de Proceso de Negocios

77

Tema V: Tecnología de bases de datos 1. Organización de los Datos Un sistema de información

Tema V: Tecnología de bases de datos

1. Organización de los Datos

Un sistema de información eficaz proporciona a los usuarios información oportuna, precisa y relevante. Esta información se almacena en archivos de computadora. Cuando los archivos están adecuadamente ordenados y mantenidos, los usuarios pueden acceder y recuperar fácilmente la información que requieren. Los archivos bien administrados y cuidadosamente ordenados facilitan la obtención de datos para apoyar la toma de las decisiones, mientras que los archivos pobremente administrados llevan a un caos en el procesamiento de la información, con altos costos, un desempeño pobre y muy poca, si es que alguna, flexibilidad. A pesar del uso de hardware y software excelentes, muchas instituciones cuentan con sistemas de información ineficientes a causa de una pobre administración de archivos.

En un sistema computacional se organizan los datos con una jerarquía que se inicia con los bits y los bytes y avanza hacia los campos, registros, archivos y las bases de datos.

Jerarquía

Definición

 

Ejemplo

 

Base de Datos (BD)

Un

grupo de archivos (tablas)

BD Estudiantes: Archivo Curso;

relacionados puede constituir una BD.

Archivo Notas; Archivo Asignaturas

Archivos

Un

grupo de registros del mismo

Archivo Curso:

 

tipo.

Nombre; Código; Fecha; O Taylor Ind401 F20-03-23 K Vincen Ind305 F20-04-21 S Watt Ind405 F20-05-27

Registro

Un grupo de campos relacionados

Nombre; Código;

Fecha

Campo

Una agrupación de caracteres en una palabra, grupo de palabras o

O Taylor Ind401 F20-03-23 O Taylor (Nombre campo)

Byte

número completo. Carácter individual, puede ser un número, una letra o cualquier otro símbolo.

10101010 (letra J en ASCII)

Bit

Unidad más pequeña de datos que la computadora puede manejar.

1

-----------------------------------

-----------------------------------

 

----------------------------------

Entidad

Es una persona, lugar, concepto,

Cuenta Corriente: es una entidad

cosa o hecho sobre el que se

típica

en

un sistema financiero o

conserva información.

crédito.

Atributo

Elemento de

información

que

Por ejemplo, número de la cuenta

describe a una entidad particular.

corriente

1.1. Tipos de organización de datos

En los sistemas de cómputo se almacenan los archivos en dispositivos de almacenamiento secundario. Los registros pueden ser ordenados de diversas maneras en los medios de almacenamiento y la disposición determina la manera según la cual los registros individuales pueden ser accesados o recuperados. Los tipos de organización de datos son:

  • Organización secuencial de archivos: un método de almacenar registros en donde éstos deben ser recuperados en la misma secuencia física en la que se almacenan. Es el único método de organización de archivos que puede ser usado en cintas magnéticas. Se usa todavía en aplicaciones de procesamiento por lotes en donde accesan y procesan secuencialmente cada registro.

  • Organización directa o aleatoria de archivos: método de almacenar registros en donde éstos pueden ser accesados en cualquier secuencia, independientemente de su orden físico real en los medios de almacenamiento. Se utiliza con la tecnología de los discos magnéticos (aun cuando los registros en el disco se pueden almacenar si se desea en orden secuencial).

1.2. Tipos de acceso a los datos

  • Método de acceso secuencial indexado (MASI): aun cuando los registros pueden ser almacenados secuencialmente en dispositivos de acceso directo, los registros individuales pueden ser accesados directamente mediante el método MASI. Este método de acceso descansa en un índice de campos claves para localizar los registros individuales. Un índice es una tabla o listado que relaciona las claves de los registros con las ubicaciones físicas en los archivos de acceso directo. Es semejante a un índice de un libro, ya que enlista el campo clave de cada registro y donde se ubica físicamente tal registro en el almacenamiento para facilitar su localización. Cualquier registro específico puede ser localizado directamente usando el campo llave para encontrar la dirección de su almacenamiento en el índice. El MASI se utiliza en aplicaciones que requieren de un procesamiento secuencial de gran número de sus registros, pero que ocasionalmente necesitan acceso directo de los registros individuales.

  • Método de acceso directo a archivos: se usa con la organización de archivos directos. Este método emplea un campo llave para localizar la dirección física de un registro. Sin embargo, el proceso se lleva a cabo sin un índice. En vez de ello, una expresión matemática llamada algoritmo de transformación se emplea para traducir el campo clave directamente en la ubicación en el almacenamiento físico del registro en el disco. El algoritmo de transformación es una formula matemática usada para traducir el campo llave de un registro directamente en la ubicación del almacenamiento físico de un registro. Este método de acceso es el más adecuado para aplicaciones en donde los registros individuales deben ser localizados directa y rápidamente para su procesamiento inmediato. Sólo unos cuantos registros en el archivo deben ser localizados en un instante dado, y los registros requeridos no se encuentran en alguna secuencia en particular. Un ejemplo de ello podría ser un sistema en línea para reservaciones en hoteles.

2. Sistema tradicional de archivos

En muchas instituciones el procesamiento de la información se inició a escala pequeña, automatizando una operación a la vez. Los sistemas tienden a crecer de manera independiente y no de acuerdo a un gran plan. De manera típica, cada división de una empresa desarrolló sus propias aplicaciones. Dentro de cada división, cada área funcional tendió a desarrollar sistemas aisladamente de otras áreas funcionales. Contabilidad, finanzas, manufactura y mercadotecnia desarrollaron todos sus propios sistemas y archivos de datos.

A medida que este proceso prosigue por 5 o 10 años, la empresa queda atada por nudos de su propia creación. La institución queda amarrada por cientos de programas y aplicaciones, en donde nadie sabe qué hacen, qué datos usan, ni quién los usa. No existe un listado central de los archivos de datos, elementos de datos o definiciones de los datos. La institución obtiene la misma información en demasiados documentos. Los problemas resultantes son redundancia de datos, dependencia de datos por parte de los programas, inflexibilidad, inconsistencia en los datos, seguridad muy pobre en los programas e incapacidad para compartir datos entre las distintas aplicaciones.

Problemas del sistema tradicional de archivos

2. Sistema tradicional de archivos En muchas instituciones el procesamiento de la información se inició
  • La redundancia de datos: es la presencia de datos duplicados en diversos archivos de datos. La redundancia de datos ocurre cuando diferentes divisiones, áreas funcionales y grupos en una institución captan de manera independiente el mismo elemento de información.

  • La dependencia de los datos del programa: es la relación estrecha entre los datos almacenados en los archivos y los programas específicos que se requieren para actualizar y mantener tales archivos. Todo programa de computadora debe describir la localización y naturaleza de los datos con los que opera. Estas declaraciones sobre los datos pueden ser más largas que la parte substantiva del programa. En un ambiente tradicional de datos, cualquier cambio en los datos

requiere de un cambio en todos los programas que accesan los datos. En consecuencia, el desarrollo

requiere de un cambio en todos los programas que accesan los datos. En consecuencia, el desarrollo de nuevas aplicaciones toma más tiempo y cuesta más que cualquier otro cambio. Una gran parte del esfuerzo de programación de la institución consiste en las actualizaciones de los elementos de datos que están dispersos por cientos de archivos. En muchas ocasiones, las aplicaciones operan con datos no actualizados sencillamente a causa de la dificultad de actualizarlos.

  • Falta de flexibilidad: un sistema tradicional de archivos puede dar informes programados de rutina luego de grandes esfuerzos de programación, o pueden proporcionar informes adecuados o responder a requerimientos no previstos de información de manera oportuna. La información requerida por las solicitudes adhoc está “en alguna parte del sistema” pero es demasiado caro recuperarla.

  • Seguridad pobre: como existe poco control o administración de datos, el acceso a ellos y la diseminación de la información virtualmente quedan fuera de control. Aquellas limitaciones al acceso tienden a ser el resultado de la costumbre y la tradición, así como de la fuerte dificultad para encontrar información.

  • Imposibilidad de compartir los datos y de su disponibilidad: la falta de control sobre el acceso a los datos en este ambiente de confusión no facilita que las personas obtengan la información. Como los elementos de información se encuentran en diferentes archivos y en diferentes partes de la institución no pueden relacionarse entre sí, y es virtualmente imposible que la información pueda ser compartida o accesada de manera oportuna.

3. Sistema de Bases de Datos

Puede eliminar muchos de los problemas creados por la organización tradicional de archivos.

  • Una Base de Datos es una colección de datos organizada para dar servicio a muchas aplicaciones al mismo tiempo al combinar los datos de manera que aparezcan estar en una sola ubicación. En lugar de separar los datos en archivos separados para cada aplicación, los datos son almacenados en una sola ubicación.

  • Sistema de Gestión de Bases de Datos (SGBD) o Data Base Management System consiste en un conjunto de programas, procedimientos y lenguajes que nos proporcionan las herramientas necesarias para trabajar con una base de datos. Los Sistemas de gestión de base de datos son un tipo de software muy específico, dedicado a servir de interfaz entre la Base de Datos, el usuario y las Aplicaciones que la utilizan. Incorporar una serie de funciones que nos permita definir los registros, sus campos, sus relaciones, insertar, suprimir, modificar y consultar los datos.

  • Un SGBD es sencillamente el software que permite que una institución centralice sus datos, los administre eficientemente, y proporcione acceso a los datos almacenados mediante programas de aplicación. Tiene los siguientes elementos: un lenguaje de definición de datos; un lenguaje de manejo de datos y un diccionario de datos.

Para diseñar una base de datos debemos establecer un proceso partiendo del mundo real, de manera

Para diseñar una base de datos debemos establecer un proceso partiendo del mundo real, de manera que sea posible plasmarlo mediante una serie de datos. La imagen que obtenemos del mundo real se denomina modelo conceptual y consiste en una serie de elementos que definen lo que queremos plasmar del mundo real en la base de datos. La definición de este modelo se denomina esquema conceptual y está compuesto de una parte estática llamada lenguaje de definición de datos ó DDL (Data Definition Language), donde se define la estructura de la base de datos y una parte dinámica denominada lenguaje de manipulación de datos ó DML (Data Manipulation Language)

Componentes de un ambiente de bases de datos

Para diseñar una base de datos debemos establecer un proceso partiendo del mundo real, de manera

Objetivos de un Sistema Administrador de Base de Datos (DBMS):

Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.

Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición de información repetida o redundante. De entrada, lo ideal es lograr una redundancia nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la aparición de redundancias.

Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea.

Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra asegurada frente a usuarios malintencionados, que intenten leer información privilegiada; frente a ataques que deseen manipular o destruir la información; o simplemente ante las torpezas de algún usuario autorizado pero

despistado. Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de

despistado. Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.

Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper la información almacenada.

Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar copias de seguridad de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.

Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo más habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso concurrente a la información, que podría derivar en inconsistencias.

Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.

Ventajas de un DBMS:

  • Facilidad de manejo de grandes volúmenes de información.

  • Gran velocidad en muy poco tiempo.

  • Independencia del tratamiento de información.

  • Seguridad de la información (acceso a usuarios autorizados), protección de información, de modificaciones, inclusiones, consulta.

  • No hay duplicidad de información, comprobación de información en el momento de introducir la misma.

  • Integridad referencial el terminar los registros.

Inconvenientes de un DBMS:

  • El costo de actualización del hardware y software son muy elevados.

  • Costo (salario) del administrador de la base de datos es costoso.

  • El mal diseño de esta puede originar problemas a futuro.

  • Un mal adiestramiento a los usuarios puede originar problemas a futuro.

  • Si no se encuentra un manual del sistema no se podrán hacer relaciones con facilidad.

  • Generan campos vacíos en exceso.

  • El mal diseño de seguridad genera problemas en esta.

Algunos Tipos de DBMS:

SGBD libres

PostgreSQL (http://www.postgresql.org Postgresql) Licencia BSD

MySQL Licencia Dual, depende el uso.

Firebird basada en la versión 6 de Interbase, Initial Developer's PUBLIC LICENSE Version 1.0.

SQLite (htto://www.sqlite.org SQLite) Licencia Dominio Público

DB2 Express-C (http://www.ibm.com/ar/businesscenter/catalogo/db2_express-c_phtml)

Apache Derby (http://db.apache.or/derby)

SGBD gratuitos

Microsoft SQL Server Compact Edition

Sybase ASE Express Edition para Linux (Edición gratuita para Linux)

Algunos DBMS Comerciales:

• <a href=Advantage Database • dBaseFileMakerFox ProIBM DB2 Universal Database (DB2 UDB) • IBM InformixInterbase de CodeGear , filial de BorlandMAGICMicrosoft AccessMicrosoft SQL ServerNexusDBO p en AccessOracleParadoxPervasiveS Q LPro g ress ( DBMS)S y base ASES y base ASAS y base I QWindowBase 4. Modelos de Base de Datos Existen distintos modos de organizar la información y representar las relaciones entre los datos en una base de datos. Los SGBD convencionales usan uno de los tres modelos lógicos de datos para hacer el seguimiento de las entidades, atributos y relaciones. Los tres modelos lógicos principales de bases de datos son el jerárquico, de redes y el relacional. Cada modelo tiene ciertas ventajas de procesamiento y también ciertas ventajas de negocios. 4.1. Modelo jerárquico de datos Una clase de modelo lógico de bases de datos que tiene una estructura arborescente. Un registro se subdivide en segmentos que se interconectan en relaciones padre-hijo de uno a muchos. Los primeros SABD eran jerárquicos. El modelo jerárquico de datos presenta los datos a los usuarios en una estructura arborescente. El SABD más común de tipo jerárquico es el IMS de IBM (Information Management System). Dentro de cada registro, los elementos de datos quedan organizados en partes llamados segmentos. Para el usuario cada segmento se ve como un organigrama con el segmento de nivel superior llamado raíz. Un segmento superior se conecta de manera lógica con un segmento inferior en una relación de tipo padre-hijo. Un segmento padre puede tener más de un hijo, pero un hijo sólo puede tener un padre. La siguiente figura muestra una estructura jerárquica semejante a la que se emplea en los sistemas de reservaciones de las líneas aéreas. El segmento raíz es “Origen”, que contiene información sobre los aeropuertos desde donde se originan los vuelos. El primer hijo es “Destino” y contiene información sobre hacia dónde van los vuelos. El segundo Profesor. Oscar Saavedra Rodríguez " id="pdf-obj-8-2" src="pdf-obj-8-2.jpg">

4. Modelos de Base de Datos

Existen distintos modos de organizar la información y representar las relaciones entre los datos en una base de datos. Los SGBD convencionales usan uno de los tres modelos lógicos de datos para hacer el seguimiento de las entidades, atributos y relaciones. Los tres modelos lógicos principales de bases de datos son el jerárquico, de redes y el relacional. Cada modelo tiene ciertas ventajas de procesamiento y también ciertas ventajas de negocios.

4.1. Modelo jerárquico de datos

Una clase de modelo lógico de bases de datos que tiene una estructura arborescente. Un registro se subdivide en segmentos que se interconectan en relaciones padre-hijo de uno a muchos.

Los primeros SABD eran jerárquicos. El modelo jerárquico de datos presenta los datos a los usuarios en una estructura arborescente. El SABD más común de tipo jerárquico es el IMS de IBM (Information Management System). Dentro de cada registro, los elementos de datos quedan organizados en partes llamados segmentos. Para el usuario cada segmento se ve como un organigrama con el segmento de nivel superior llamado raíz. Un segmento superior se conecta de manera lógica con un segmento inferior en una relación de tipo padre-hijo. Un segmento padre puede tener más de un hijo, pero un hijo sólo puede tener un padre.

La siguiente figura muestra una estructura jerárquica semejante a la que se emplea en los sistemas de reservaciones de las líneas aéreas. El segmento raíz es “Origen”, que contiene información sobre los aeropuertos desde donde se originan los vuelos. El primer hijo es “Destino” y contiene información sobre hacia dónde van los vuelos. El segundo

hijo es “Fecha” (las líneas aéreas aceptan en general reservaciones con un año de anticipación). El

hijo es “Fecha” (las líneas aéreas aceptan en general reservaciones con un año de anticipación). El tercer hijo es “número de vuelo” porque en un día cualquiera puede haber diversos vuelos a un solo destino. El cuarto hijo es “Listas de pasajeros”, que contiene información sobre el pasajero (como nombre, teléfono local, cuándo se hizo la reservación, dirección de facturación, forma de pago y, en algunos casos, número de asiento).

Detrás de la imagen lógica de los datos hay una cantidad de enlaces físicos y dispositivos para ligar la información en un todo lógico. En los SABD lógicos, los datos están enlazados físicamente mediante una serie de señaladores que forman cadenas de segmentos de datos relacionados. Los señaladores son elementos de datos asociados a los extremos de los segmentos de registros sobre el disco que dirige el sistema hacia los registros relacionados. En el ejemplo, si la ruta fuera LGA (El aeropuerto La Guardia de Nueva York), al final del segmento Origen se tendrían una serie de señaladores hacia todas los posibles destinos. A su vez, al final del segmento Destino se encuentran señaladores hacia las fechas cuando la línea área vuela a este destino.

Como existen muchos aeropuertos desde donde se originan vuelos, sería conveniente que el sistema pueda encontrar rápidamente el segmento raíz adecuado, el aeropuerto de origen. Mejor que leer cada segmento de datos (de los cuales hay millones) uno a la vez hasta que el adecuado (el aeropuerto raíz de origen) se encuentre, todos los aeropuertos de origen pueden ser sacados en un índice que contenga una lista y su localización precisa en un disco. Una vez que este segmento raíz es identificado, los señaladores tomarán el mando para guiar la búsqueda de la base de datos.

93PS274 93PS274 James James Ram Bhawan Ram Bhawan A1 A1 97PS087 97PS087 Alice Alice Meera Bhawan
93PS274
93PS274
James
James
Ram Bhawan
Ram Bhawan
A1
A1
97PS087
97PS087
Alice
Alice
Meera Bhawan
Meera Bhawan
A2
A2
97PS086
97PS086
Anitha
Anitha
Meera Bhawan
Meera Bhawan
A1
A1
97PS085
97PS085
Jose
Jose
A2
A2
A1
A1
A1
Ingeniería
Ingeniería
Ingeniería
A2
A2
A2
Ingeniería
Ingeniería
Ingeniería
A1
A1
A1
Ingeniería
Ingeniería
Ingeniería
A2
A2
A2
Ingeniería
Ingeniería
Ingeniería
Comercial
Comercial
Comercial
Civil Industrial
Civil Industrial
Civil Industrial
Com ercial
Com ercial
Com ercial
Civil Indusria l
Civil Indusria l
Civil Indusria l

4.2 Modelo de datos en red

El modelo de datos en red es una variación del modelo de datos jerárquico. De hecho, las bases pueden traducirse de jerárquicas a en redes y viceversa, con el objeto de optimizar la velocidad y la conveniencia del procesamiento. Mientras que las estructuras describen

relaciones de uno a muchos, las estructuras en redes describen datos lógicamente en relaciones de muchos

relaciones de uno a muchos, las estructuras en redes describen datos lógicamente en relaciones de muchos a muchos.

En una relación de muchos a muchos en la que los SABD en redes tienen un desempeño excelente es la relación entre estudiantes y cursos (ver figura siguiente). Existen muchos cursos en una universidad y muchos estudiantes se inscriben en muchos cursos.

Los datos de la figura anterior podrían haber sido jerárquicamente estructurados. Pero esto hubiera significado una gran redundancia y hubiera hecho más lenta la respuesta a ciertos tipos de solicitudes de información; el mismo estudiante hubiera aparecido en el disco de cada curso que tomara en vez de en uno solo. Las estructuras en red reducen la redundancia y, en ciertas situaciones (en las que existen relaciones muchos a muchos), responden de manera más rápida. Sin embargo, existe un precio por esta reducción en cuanto a redundancia e incremento de velocidad. El número de señaladores en las estructuras de la red se incrementa rápidamente, haciendo el mantenimiento y la operación más caros.

93PS274 James Ram Bhawan A1 A1 Ingeniería Comercial 97PS087 Alice Meera Bhawan A2 97PS086 Anitha Meera
93PS274
James
Ram Bhawan
A1
A1
Ingeniería
Comercial
97PS087
Alice
Meera Bhawan
A2
97PS086
Anitha
Meera Bhawan
A1
A2
Ingeniería
Civil
Industrial
97PS085
Jose
Meera Bhawan
A2

4.3. Modelo relacional de datos

El modelo relacional de datos, el más reciente de estos modelos, supera algunas de las limitaciones de los otros dos. El modelo relacional representa todos los datos en la base de datos como sencillas tablas de dos dimensiones llamadas relaciones. Las tablas son semejantes a los archivos planos, pero la información en más de un archivo puede ser fácilmente extraída y combinada. Algunas veces se llama archivos a las tablas.

Tabla: Estudiante Tabla: Disciplina En la figura se muestra una tabla de proveedores, una de partes

Tabla: Estudiante

Tabla: Estudiante Tabla: Disciplina En la figura se muestra una tabla de proveedores, una de partes

Tabla: Disciplina

Tabla: Estudiante Tabla: Disciplina En la figura se muestra una tabla de proveedores, una de partes

En la figura se muestra una tabla de proveedores, una de partes y una de pedidos. En cada tabla, los renglones son registros únicos y las columnas son los campos. Otro término para un renglón o registro es tupla. Con frecuencia, un usuario requiere información de un número de relaciones para producir un reporte. Aquí se encuentra la fuerza del modelo relacional, puede relacionar datos en cualquier archivo o tabla con datos de otro archivo o tabla, siempre y cuando ambos compartan el mismo elemento.

Para demostrarlo, supóngase que se desea encontrar en la base de datos relacional de la figura los nombres y direcciones que nos pudieran abastecer con la parte número 137 ó 152. Se necesita información de las dos tablas: la tabla de proveedores y la tabla de partes. Nótese que estos dos archivos comparten un elemento de datos NUMERO- PROVEEDOR.

En una base de datos relacional, se usan tres operaciones básicas para desarrollar conjuntos útiles de datos, seleccionar, proyectar y unir. La operación seleccionar crea un subconjunto que contiene todos los registros en el archivo que cumplen con un determinado criterio. “Seleccionar” crea, en otras palabras, un subconjunto de renglones que cumplen con determinados criterios. En el ejemplo, se desea seleccionar registros (renglones) de la tabla de partes en donde el número de parte sea igual a 137 ó 152.

La operación juntar combina las tablas relacionales para proporcionar al usuario más información que la que se encuentra disponible en las tablas individuales. En el ejemplo, se desea unir la ahora acortada tabla de partes (sólo las partes de número 137 ó 152) y la tabla de proveedores en una nueva y única tabla de resultados.

La operación proyecto crea un subconjunto que consiste en columnas en una tabla, que permiten al usuario crear nuevas tablas que contengan nada más la información que se

requiera.

En el ejemplo, se desea extraer de la nueva tabla de resultados sólo las

columnas siguientes:

PROVEEDOR.

NUMERO-PARTE,

NUMERO-PROVEEDOR,

NOMBRE-PROVEEDOR

y

DIRECCION-

Tabla: Estudiante Tabla: Disciplina En la figura se muestra una tabla de proveedores, una de partes
Entre los principales sistemas de administración de bases de datos relacionales para la macrocomputadoras se incluyen

Entre los principales sistemas de administración de bases de datos relacionales para la macrocomputadoras se incluyen el Sybase de Sybase, DB-2 de IBM y el Oracle de la Oracle Corporation, el FoxBase Flus de la Fox Software Inc., y el Paradox de la Borland Internacional Inc, SQL Server y Access de Microsoft.

  • 4.4. Ventajas y desventajas de los tres modelos de bases de datos

La principal ventaja de los modelos de bases de datos jerárquicos y red es la eficiencia en el procesamiento. Por ejemplo, un modelo jerárquico es adecuado para sistemas de procesamiento de operaciones de reservaciones en una línea aérea, que debe manejar millones de solicitudes rutinarias estructuradas cada día para información sobre reservaciones.

Las estructuras jerárquica y de red tienen diversas desventajas. Todas las rutas de acceso, directorios e índices deben ser especificados por adelantado. Una vez especificados, no se pueden cambiar fácilmente sin un esfuerzo importante de programación. Por tanto, estos diseños tienen poca flexibilidad. Por ejemplo, si se llama a una línea aérea y se dice: “Mis padres me dieron un boleto de avión para un lugar extraordinario de vacaciones, que sale del aeropuerto La Guardia de Nueva York, pero no me dijeron exactamente dónde y cuándo. ¿Adónde me mandan?”. Se podría descubrir que no hay manera de que el sistema pueda encontrar la respuesta en un tiempo razonable. Esta trayectoria en los datos no se especificó por adelantado. O si el FBI llamara a una de las líneas principales y le preguntara sobre los movimientos de los últimos seis meses de un terrorista sospechoso que viajara bajo cierto nombre supuesto, la línea aérea podría responder luego de varios meses de esfuerzos de programación (los registros se mantienen durante un período de cinco años en cintas de respaldo).

Los sistemas jerárquicos y de redes requieren de una programación intensiva, consumidora de tiempo, difícil de instalar y más difícil de corregir si ocurrieran errores de diseño. No soportan consultas adhoc en inglés para información.

La fuerza de los SABD relacionales es la gran flexibilidad en cuanto a las consultas ad- hoc, el poder de mezclar la información de fuentes distintas, sencillez en el diseño y mantenimiento y capacidad de añadir nuevos datos a registros sin necesidad de perturbar los programas y las aplicaciones ya existentes. La debilidad de los SABD relacionales es su baja eficiencia relativa en el procesamiento. Estos sistemas son algo más lentos porque en general requieren de muchos accesos a los datos almacenados en disco para llevar a cabo los comandos de selección, fusión y proyección. La selección de un número entre millones, un registro a la vez, puede tomar gran cantidad de tiempo. Por supuesto, la base de datos puede ser indexada y “afinada” para acelerar las consultas previamente especificadas. Los sistemas relacionales no tienen el gran número de señaladores que tienen los sistemas jerárquicos.

Las grandes bases de datos relacionales pueden diseñarse para tener alguna redundancia en cuanto a los datos, con objeto de que la recuperación sea más eficiente. El mismo elemento de datos puede almacenarse en distintas tablas. La actualización de los elementos redundantes de datos no es una actividad automática en muchos SABD relacionales. Por ejemplo, el cambio del cambio estatus del empleado en una tabla no lo

habrá de cambiar en todas las tablas. Arreglos especiales se requieren para asegurar que todas las

habrá de cambiar en todas las tablas. Arreglos especiales se requieren para asegurar que todas las copias del mismo elemento de datos sean actualizadas conjuntamente.

Las bases de datos jerárquicas permanecen como el caballo de batalla para el procesamiento intensivo de un alto volumen de operaciones. Los bancos, compañías de seguros y otros usuarios de altos volúmenes continúan usando las confiables bases de datos jerárquicas, como el IMS de IBM, desarrollado en 1969. Es mucho más fácil programar aplicaciones en un ambiente relacional, pero muchas empresas no desean gastar millones de dólares para reconvertir el software de sistemas de administración de base jerárquica a estos sistemas de base relacional. Muchas empresas han cambiado a DB2, el SABD de IBM para nuevas aplicaciones, al mismo tiempo que retienen al IMS para el procesamiento de las operaciones tradicionales. Por ejemplo, la United States Automobile Association, descrita en la Ventana sobre Tecnología, emplea el DB2 sólo para funciones de programación menos importantes. La Texas Instruments, con sede en Dallas, depende del IMS para sus requerimientos pesados de procesamiento. La Texas manufactura, en el IMS. La empresa ha logrado reunir una inmensa biblioteca de aplicaciones de IMS a lo largo de más de veinte años, una convención total a DB le tomaría otros diez años. A medida que los productos relacionales adquieren más fuerza, las empresas se alejarán por completo de los SABD jerárquicos, pero esto ocurrirá en mucho tiempo.

En la tabla se comparan las características de los distintos modelos de bases de datos. Tabla: Comparación de las alternativas de bases de datos

Tipo de base

Eficiencia de

Flexibilidad

Amigabilidad

Complejidad en la

de datos

procesamiento

para usuarios

programación

finales

Jerárquica

Alta

Baja

Baja

Alta

En redes

Media-alta

Baja-media

Baja moderada

Alta

Relacional

Baja pero mejorando

Alta

Alta

Baja

5. Modelos de Datos Conceptuales (Semánticos)

Se trata de una técnica de diseño de base de datos gráfica, que nos muestra información relativa a los datos y la relación existente entre ellos. Sus características principales son:

Reflejan tan sólo la existencia de los datos sin expresar lo que se hace con ellos. Es independiente de las bases de datos y de los sistemas operativos (por lo que puede ser implementado en cualquier base de datos). Está abierto a la evolución del sistema. Incluye todos los datos que se estudian sin tener en cuenta las aplicaciones que se van a tratar. No tienen en cuenta las restricciones de espacio y almacenamiento del sistema.

5.1. Elementos del Modelo Entidad-Relación

  • Entidades

Son objetos concretos o abstractos que presentan interés para el sistema y sobre los que se recoge información que será representada en un sistema de bases de datos. Por ejemplo, clientes, proveedores y facturas serían entidades en el entorno de una empresa.

  • Atributos

Es una unidad básica e indivisible de información acerca de una entidad o una relación. Por ejemplo la entidad proveedor tendrá los atributos nombre, domicilio, población, CIF.

  • Dominios

Es el conjunto de valores que puede tomar cada atributo. Por ejemplo el dominio del atributo población, será la relación de todas las poblaciones del ámbito de actuación de nuestra empresa.

5.2. Diagramas Entidad - Relacionamiento (objetos de datos y sus relaciones)

OBJETOS
OBJETOS

ATRIBUTOS

Nombre

Dirección Edad P ermiso de Condu c Número

RELACIONES
RELACIONES
Marca Modelo Número de ID Forma Color
Marca
Modelo
Número de ID
Forma
Color
Tiene
Tiene
Objetos de datos, atributos y relaciones Fabricant C onstruy e Coche Tabla de Objetos de Datos
Objetos de datos, atributos y relaciones
Fabricant
C onstruy e
Coche
Tabla de Objetos de Datos
ID
Modelo Forma
Motor
T ransmisió n
.
.
.
5.2. Diagramas Entidad - Relacionamiento (objetos de datos y sus relaciones) OBJETOS ATRIBUTOS Nombre Dirección

Un sencillo diagrama Entidad-Relacionamiento y una tabla de objetos

5.3. Modelo de Datos

Es una representación del mundo real en función de los Datos Relevantes a un sistema. Datos que son necesarios para representar la conducta del SIA.

Fases de la Metodología para la estructuración de los datos

Fase 1: Modelo de datos conceptual Mayor nivel de abstracción del sistema. Es un modelo que representa el problema de gestión en función de los Datos Relevantes. La forma canónica, es la menor expresión del modelo conceptual (normalizado) sin redundancia.

Fase 2: Modelo de Procesos de Datos

Representar como los requerimientos de información de un SIA (o más) solicitan

la estructura del modelo conceptual. Decisión del enfoque de uso y almacenamiento de los datos.

Representar el

contenido y estructura de las B.D., en el particular SABD-g

elegido.

Fase 3: Modelo de Datos Físicos Implementación de los modelos conceptuales en un Administrador de Base de Datos Relacional.

Modelo Conceptual “MC”

Está basado en el modelo “Entidad-Relacionamiento”, de Peter Chen (1976).

ALTERNATIVAS:

  • a) Hacer un M.C. para un Área funcional especifico, por ejemplo:

Racionalizar la administración en esa área.

Se está diseñando un S.I. en esa área.

Integrar los S.I. de apoyo a esa área.

Administrar la información en el área.

  • b) Análisis de la información global de la organización. Determinar cual es el quantum mínimo (o base) de información que la organización necesita para su gestión. Obtenemos el modelo corporativo.

5.4. Definición de Conceptos del Modelo Entidad Relacionamiento

El modelo de datos de Entidad-Relacionamiento (ER) fue introducido por Peter Chen (1976), en donde se describían por primera vez sus principales componentes. El modelo ha sido subsecuentemente extendido (EER) para incluir otros componentes [TEO-86, STO-91, McFadden94]. El ER continúa desarrollándose, con lo cual no ha podido obtenerse una notación estándar definitiva; es así como hoy en día algunos autores fusionan los conceptos de ER y EER bajo un solo nombre: Modelo de Datos Entidad- Relacionamiento (McFadden94).

Es así que, al referirse al ER, no se esta hablando de aquel modelo original de Chen, sino que del nuevo ente propuesto por aquellos autores que juntaron los antiguos y nuevos conceptos y elementos para conformar el modelo que se presentará.

Adentrando un poco en materia, podemos definir un ER como una representación detallada y lógica de los datos; expresado en términos de entidades, relacionamientos (o asociaciones) y atributos (o propiedades); y representado gráficamente en el Diagrama de Entidad-Relacionamiento (ER). Es construido durante la etapa de análisis en el proceso de modelamiento de datos.

Los mayores componentes del ER son las entidades, relaciones, y atributos que serán detallados a continuación.

Entidades

Se define entidad como una persona, lugar, objeto, evento, o concepto que adopte según se requiera en el proceso de modelamiento, por ejemplo:

 

Persona

: EMPLEADOS, PACIENTES, etc.

 

Lugar

: ESTADOS, REGIÓN, etc.

Evento

: VENTAS, COMPRAS, etc.

Su notación corresponde al símbolo:

 
   

CLIENTE

     

FACTURA

     

PRODUCTO

 

RUT

<pi>

VA10

<M>

NUMERO

<pi>

I

<M>

CODIGO

<pi>

I

<M

NOMBRE

VA30

FECHA

D

DESCRIPCION

VA20

DIRECCION

VA30

NUMERO

<pi>

COSTO

I

RUT

<pi>

 

CODIGO

<pi>

Dentro de él va el nombre que identifica a la entidad. Cabe hacer la distinción entre entidades (entity types) e instancias (entity instance). Las entidades son objetos, eventos o personas que pertenecen a una realidad. La cual es alguna organización o parte de ella donde interesa registrar datos.

Objetos;

Ej. : Productos, Materias Primas.

Eventos;

Ej. : Compras, Ventas, Salidas de Bodega.

Personas;

Ej. : Proveedores, Clientes, Empleados.

Se identifican por un nombre en mayúsculas; por ejemplo: EMPLEADO Una instancia es una ocurrencia de

Se identifican por un nombre en mayúsculas; por ejemplo:

EMPLEADO
EMPLEADO

Una instancia es una ocurrencia de una entidad. Una entidad es descrita sólo una vez en una base de datos (esto es conocido como METADATO), en cambio muchas entidades pueden ser. Representadas por los registros de una base de datos. Por ejemplo:

Entidad: EMPLEADOS Atributos: RUT NOMBRE DIRECCIÓN Instancia de EMPLEADO

10.220.712-2

Maxwell, Jonathan Avda. Los Aromos #876

Clasificación de las Entidades.

  • 1. : Si su existencia no depende fundamentalmente del tiempo. : Su existencia depende del tiempo. Salida de Bodega.

Entidad Sujeto

Entidad Evento

  • 2. Entidad Regular: Entidad Débil:

Son aquellas que pueden ser identificadas por sus atributos Si es necesaria una relación para identificar las entidades.

Atributos

Un atributo es una propiedad o característica de una entidad. Un ejemplo es el presentado anteriormente al definir la entidad EMPLEADO.

Para nombrar un

atributo

se

usa

letra mayúscula,

al

igual

que con

la

entidad y

su

representación es por medio del símbolo que se muestra a continuación. Ej. :

NOMBRE

Además de una línea que lo conecte con su respectiva entidad.

Atributos descriptores de una Entidad: Son aquellos datos que caracterizan la Entidad, por ejemplo, dirección, edad, fecha_nacimiento, etc.

Identificador de la Entidad: Generalmente es único para una Entidad Sujeto.

Entidad Atributos (identificador) :

:

(descriptores) Y es compuesto para las Entidades Evento.

PROVEEDOR NUMERO_PROVEEDOR Nombre, Dirección, etc.

Entidad : Cotización Previsional Atributos (identificador) : Rut. Afiliado Mes - de - pago Nombre, Dirección,

Entidad

:

Cotización Previsional

Atributos (identificador)

:

Rut. Afiliado

Mes - de - pago

Nombre, Dirección, ...

PROVEEDOR

 

NUMERO_PROVEEDOR

<pi>

I

<M>

NOMBRE

A 10

DIRECCION

A 20

NUMERO_PROVEEDOR

<pi>

 

PARTE

NUMERO_PARTE

<pi>

I

<M>

DESCRIPCION

A 10

COSTO

I

STOCK

I

NUMERO_PARTE

<pi>

Identificador

Cada entidad debe tener uno o más atributos que identifiquen únicamente a cada una de las instancias, para así, poder distinguirlas claramente. De esta manera, se define un identificador de aquel(los) atributo(s) que identifican exclusivamente a cada instancia de una entidad. Un ejemplo sería el NUMERO_PROVEEDOR, pues no existe otra instancia que lo contenga.

Algunas veces una entidad puede tener varios identificadores; por ejemplo la entidad EMPLEADO puede tener un identificador RUT, y una segundo identificador llamado NOMBRE y DIRECCIÓN (suponiendo que no hay dos empleados con el mismo nombre que vivan en la misma dirección); en todo caso, de varias posibilidades se opta por determinar a uno de ellos como identificador, así pues se define un identificador como uno de los posibles identificadores que ha sido seleccionado para distinguir una entidad. Para dicha selección se aconseja los siguientes consejos propuestos por [BRU-92]:

Criterio 1: Elegir aquel identificador que no cambie su valor durante

toda su existencia en la instancia. Criterio 2: Elegir aquel identificador tal que para cada instancia, el

atributo garantice que su valor no sea vacío (NULL). En el caso de combinaciones de varios atributos este criterio debe cumplirse para cada uno de ellos. Criterio 3: Impedir el uso de las llamadas identificadores inteligentes,

cuya estructura puede indicar varias cosas (clasificaciones, localizaciones, fechas, nombres, etc. (todas en un solo nombre)); ya que alguna de ellas puede cambiar. Criterio 4: Considerar sustituir identificadores por alguna combinación de otros.

Su notación corresponde a subrayar el nombre del atributo para el identificador de la siguiente forma:

RUT
RUT
Atributos de Multivalor Surge cuando un atributo puede tener más de un valor para cada instancia.

Atributos de Multivalor

Surge cuando un atributo puede tener más de un valor para cada instancia. Su notación es por medio del símbolo que se muestra en el ejemplo siguiente:

CARGAS_FAM.
CARGAS_FAM.

En este caso un empleado en particular (una instancia de la entidad EMPLEADO), puede tener varias cargas familiares.

En todo caso, durante etapas posteriores del modelamiento, se normalizan las entidades eliminando estos atributos colocándolos en entidades separadas o en una relación.

5.5. Relacionamientos (Asociación)

Un relacionamiento es aquella por medio de la cual se unen los componentes del modelo ER, o sea, una asociación entre las instancias de una o más entidades. Su notación es por medio del símbolo presentado en el ejemplo a continuación:

T IE N E P A C IE N T E H O S P IT
T IE N E
P A C IE N T E
H O S P IT A L

De esta manera se quiere representar la relación que existe entre la entidad HOSPITAL y la entidad PACIENTE de esta forma: un Hospital puede tener muchos pacientes.

Los símbolos que acompañan a las líneas de unión en la relación, serán explicados más adelante.

Aunque es loable destacar que su omisión es considerada correcta siempre y cuando se deje el nombre de la relación sobre la línea que une a las diferentes entidades. Es recomendable que para nombrar la relación se use un nombre corto y descriptivo.

PROVEEDOR

     

PARTE

 

NUMERO_PROVEEDOR

<pi>

I

<M>

NUMERO_PARTE

<pi>

I

<M>

NOMBRE

A 10

NOMBRE A 10 SOLICITAR DESCRIPCION A 10

SOLICITAR

NOMBRE A 10 SOLICITAR DESCRIPCION A 10

DESCRIPCION

A 10

DIRECCION

A 20

 

COSTO

I

NUMERO_PROVEEDOR

<pi>

STOCK

I

 

NUMERO_PARTE

<pi>

Grado de un relacionamiento

Es el número de entidades que participan en una relación; así por ejemplo, si en una relación participan dos entidades, entonces su grado es dos. Las más comunes relaciones del ER son:

unaria (grado 1),

binaria (grado 2),

ternaria (grado 3),

n-aria.

Por supuesto que la posibilidad de grados mayores está abierta, aunque no es frecuente encontrarlos en

Por supuesto que la posibilidad de grados mayores está abierta, aunque no es frecuente encontrarlos en los modelos ER.

Relación Unaria: también llamada relación recursiva, es una relación entre las instancias de una entidad; esta relación puede ser 1:1, 1:m, m:n ( se lee “cantidad” es a “cantidad”). Por ejemplo, la representación de esposo(a) puede ser:

ES-ESPOSO

PERSONA
PERSONA

Notar que esta relación es 1:1, ya que una persona sólo puede tener un esposo a la vez (excluyendo la bigamia).

Y la de jefe:

ES-JEFE

TRABAJADORES
TRABAJADORES

Notar que la relación es 1:m, ya que un jefe puede tener a su cargo a varios trabajadores.

Relación Binaria: es la relación entre instancias de dos entidades, también prevalece que la relación puede ser entre una entidad y ella misma, entre una entidad y otra(s) distinta(s), o entre muchas entidades con otras muchas. Así por ejemplo:

  • TIENE

 
HOSPITAL
 

HOSPITAL

 
PACIENTE

PACIENTE

 

Como nota al margen, se destaca que este es el tipo de relación que con más frecuencia se encuentra en el proceso de modelamiento.

Relación Ternaria: se define como una relación simultánea entre instancias de tres entidades tipo, como se explicaba anteriormente. Un ejemplo sería como el que sigue a continuación, en el que se muestra la relación que debe existir ante un pedido de productos por parte de los clientes y por medio de una orden de compra

PRODUCTO

 

P E TIC IO N

 

ORDEN DE

 
COMPRA

COMPRA

 
PRODUCTO P E TIC IO N ORDEN DE COMPRA BODEGA
 
   

BODEGA

   

Gerundios

También llamado entidad compuesta, es una relación entre una entidad y muchas otras (1:m) que se ha cambiado por una entidad con varias relaciones 1:m asociadas. La notación que usa como simbología es la que se muestra a continuación.

Gerundios También llamado entidad compuesta, es una relación entre una entidad y muchas otras (1:m)

El gerundio al ser una entidad, posee también todas las características de las entidades. Este componente es tremendamente útil en lo que se refiere a las relaciones ternarias y binarias (sobre todo en las ternarias).

En general, para relaciones ternarias o de mayor orden, en donde cualquier lado de la relación es una “muchos”, podemos mostrar la relación como una entidad.

Conectividad (Cardinalidad) en el relacionamiento

Se define la CONECTIVIDAD de una relación como el número de instancias de dicha entidad que pueden ser asociadas por cada instancia de otra entidad. Así es como surgen los términos 1:1, 1:m, m:n; en todo caso, esta notación ya fue introducida anteriormente para que pueda introducirse una definición intuitiva del significado. La simbología usada para representar dichas relaciones es:

  • ES A UNA

  • ES A MUCHAS

Cardinalidad Mínima y Máxima

La cardinalidad mínima de una relación se define como el mínimo número de instancias de dicha entidad que pueden ser asociadas con cada instancia de otra entidad. El caso contrario a la definición de la cardinalidad máxima, es decir, el máximo número de instancias que pueden relacionarse con cada una de las instancias de otra entidad.

La notación que representa a estos conceptos, se deben colocar sobre la línea que une a las entidades (línea que representa a la relación), con uno de los siguientes tres

I
I
Gerundios También llamado entidad compuesta, es una relación entre una entidad y muchas otras (1:m)

MINIMA (EXCLUYENDO EL CERO)

  • MINIMA (INCLUYENDO EL CERO)

II

símbolos:

MAXIMA

Por ejemplo el siguiente ER define las entidades HOSPITAL y PACIENTE, que se relacionan con diferente conectividad (cardinalidad).

ATIEN D E HOSPITAL PACIENTE En el caso de que la cardinalidad máxima sea un número
ATIEN D E
ATIEN D E
HOSPITAL
HOSPITAL
PACIENTE

PACIENTE

 

En el caso de que la cardinalidad máxima sea un número conocido, este se coloca cerca del símbolo que representa la cardinalidad máxima.

Dependencia de Existencia

Es el concepto que explica el que una instancia perteneciente a una entidad no pueda existir a menos que exista una instancia en otra entidad previamente definida. En el ejemplo anterior si la entidad PACIENTE tuviera atributos tales como nro_hospital y nro_cama, entonces una instancia de esta entidad no podría existir sino existen las correspondientes instancias en la entidad HOSPITAL.

Este concepto es también aplicable a las entidades por lo cual existirían entidades dependientes de otras. Ocurre frecuentemente que la entidad dependiente de otra no tiene un identificador o clave candidata. Para esto, la clave primaria de la entidad de la cual depende es generalmente usada como parte de la clave primaria de ella misma.

De Existencia:

Indica cuando debe existir la relación, dada la existencia de una

ocurrencia de las Entidades involucradas en la relación.

A 1 0 B
A
1
0
B

Significa que: Dado un B debe estar amarrado a un A.

Dado un A, puede haber 0, 1, o más B asociados.

Ejemplo:

Cliente - Factura Empleado - Carga

Comentarios sobre el Relacionamiento

  • a) Entre dos Entidades puede haber más de un relacionamiento

Fecha

Emisión
Vencimiento Prometido - Pago Pago

ATIEN D E HOSPITAL PACIENTE En el caso de que la cardinalidad máxima sea un número

Factura

Condición: Cada relación debe decir algo distinto.

  • b) Una relación puede involucrar a más de dos Entidades.

Resumen Concepto Representación Entidades • Regular • Débil Relación Atributo Atributo Entidad Dominio Este concepto ayuda
Resumen Concepto Representación Entidades • Regular • Débil Relación Atributo Atributo Entidad Dominio
Resumen
Concepto
Representación
Entidades
Regular
Débil
Relación
Atributo
Atributo
Entidad
Dominio

Este concepto ayuda mucho a:

Integridad de datos: ya que la existencia de unos datos depende de la

existencia de otro. Fácil acceso a la entidad dependiente.

Tarea
Tarea
Ingeniero
Ingeniero

Esta

figura

representa

una

asociación

exclusiva,

por

ejemplo:

 

Este ejemplo se entiende de manera que una tarea puede ser

desarrollada por un Ingeniero o por un Técnico pero no por ambos.

desarrollado por

Técnico
Técnico

5.6 Modelamiento de atributos multivalor

Los atributos de multivalor pueden ser eliminados después de varios pasos en el diseño conceptual, como se mencionó anteriormente (sección “Atributos de Multivalor”). Esto se logra cuando cada atributo multivalor es convertido a una entidad separada que contenga sus propios atributos.

GRUPOS REPETIDOS Un conjunto de dos o más atributos de multivalor que están lógicamente relacionados forman, como consecuencia de lo anterior, un grupo repetido. Por ejemplo para una instancia de la entidad EMPLEADO se tendrá muchos valores para el atributo nombre_carga, que formarán un grupo repetido.

Ahora bien, estos grupos repetidos pueden ser eliminados y reemplazados por una nueva entidad que reúna a los atributos; y además, esta nueva entidad es relacionada con la entidad original de donde se sacaron los atributos. Para el ejemplo anterior se tendría una nueva entidad llamada CARGAS, que estaría relacionada con la entidad EMPLEADO de la forma “Un EMPLEADO tiene muchas CARGAS”. La nueva entidad cumple con todas las normas que rigen a las entidades, como lo es definir un atributo como identificador, cardinalidad, etc.

Ejemplo:

La entidad FUNCIONARIO tiene los siguientes atributos:

Nombre Apellido Rut Dirección Teléfono Cargas Nombres de cargas Edad de Cargas Empleos Anteriores Cargos_desempeñados Duración del Empleo Anterior

En el ejemplo se puede notar que los grupos repetidos corresponden a aquellos relacionados con Cargas y Empleos Anteriores. Se pueden crear por tanto, dos nuevas entidades que agrupen estos grupos:

La entidad CARGAS, que poseería los atributos:

Nombre de cargas

Edad de cargas

Rut_Funcionario (para no perder la relación con la entidad de origen)

La entidad EMPLEOS_ANTERIORES, con los atributos:

Nombre_Empresa

Cargo_desempeñado Duración_Empleo Rut_Funcionario

La entidad FUNCIONARIO, con los atributos: Nombre Apellido Rut_Funcionario Dirección Teléfono 5.7. Datos Dependientes del Tiempo

La entidad FUNCIONARIO, con los atributos:

Nombre

Apellido

Rut_Funcionario

Dirección

Teléfono

5.7. Datos Dependientes del Tiempo

Los contenidos de las bases de datos varían con el tiempo, un ejemplo muy didáctico para explicar esta idea es el registrar la temperatura diaria de un paciente hospitalizado; conceptualizando esto, se podría crear una entidad llamada TEMPERATURA DIARIA que contenga los atributos DÍA, HORA, IDENTIFICACIÓN_PACIENTE y TEMPERATURA. Como esto último es un grupo repetido, se puede separar en otra entidad llamada TEMPERATURA DIARIA POR HORAS que los contenga.

Gráficamente lo anterior sería como lo mostrado en el siguiente modelo ER.

DIA
DIA
IIDENTIFICACIÓN_PACIENTE
IIDENTIFICACIÓN_PACIENTE
  • HORA

 

TEMPERATURA

 
 

DIARIA

 
TEMPERATURA
TEMPERATURA
DIA IIDENTIFICACIÓN_PACIENT
DIA
IIDENTIFICACIÓN_PACIENT
TEMPERATURA DIARIA POR
TEMPERATURA
DIARIA
POR
HORA
HORA
DIA
DIA
IDENTIFICACIÓN_PACIENT
IDENTIFICACIÓN_PACIENT
   

TIENE

TEMPERATURA

II

DIARIA

 
La entidad FUNCIONARIO, con los atributos: Nombre Apellido Rut_Funcionario Dirección Teléfono 5.7. Datos Dependientes del Tiempo
TEMPERATURA
TEMPERATURA

HORAS

Así, el valor del atributo temperatura se le estampa en el tiempo una hora una fecha y el nombre de un paciente. Una estampa en el tiempo (time stamp) es un valor en el tiempo (tal como la fecha, la hora y el nombre del paciente) que es asociada a un valor de algún dato que cambia durante el transcurso de su “vida”. De esta manera, se puede registrar cualquier variación de los datos. Esta herramienta es muy útil cuando se trata con datos variables en el tiempo; y en este punto fue donde existió la gran debilidad del antiguo modelo ER, del cual se habló en el punto anterior, pues para datos dependientes del tiempo este modelo era inadecuado. Esto incentivó el desarrollo de un modelo con conceptos orientados a objetos que permitiera un mayor manejo de datos variables.

5.8. Generalización - Especialización Los humanos al ser seres racionales poseen la habilidad de clasificar los

5.8. Generalización - Especialización

Los humanos al ser seres racionales poseen la habilidad de clasificar los objetos y generalizar sus propiedades; por ejemplo un gorrión y un cóndor son clasificados sin mayor titubeo bajo el nombre AVE, generalizándolos y obviando el que uno tenga, y carezcan atributos del otro. Con este ejemplo se introducen los conceptos de generalización y categorización.

Generalización es el concepto que involucra el que algunas cosas (entidades) son subtipos de otras cosas más generales; y como no puede existir un SI sin un NO, especialización es el concepto opuesto, en donde una entidad tiene varios subtipos. A continuación se bosquejan un ejemplo para cada concepto:

Generalización : un IBM es un subtipo de computador.

Especialización : automóviles

tienen

los

subtipos

convertibles, etc.

sedan,

deportivos,

La generalización como estructura formal fue estudiada en el área de la inteligencia artificial, y hasta hace poco estaba limitada a la semántica y a modelos orientados a objetos; hoy en día se incorporó al modelo ER y surgió el modelo EER.

Subtipos Y Supertipos

Una de las mayores dificultades del modelamiento de datos es reconocer y representar claramente las entidades que comparten propiedades, pero tienen una o más distintas que las distinguen de las otras entidades. Ante situaciones como ésta se proponen tres posibilidades:

Definir una entidad que reúna todos los atributos de las otras entidades; aunque esto tiene la desventaja de que al contener todos los atributos, alguno de ellos adopte el valor vacío al no ocuparse diariamente. Definir una entidad separada para cada una de las entidades existentes, y que además reúna los atributos que son comunes a todas las entidades. Este método tiene la desventaja de que los usuarios deben ser cuidadosos en elegir la entidad correcta cuando usen el sistema. Definir un supertipo que reúna los atributos comunes, y subtipos que contengan cada uno de los restantes atributos. En otras palabras, es dejar las entidades originales, pero se les extraen los atributos que son comunes entre ellas, y se reúnen en una sola entidad llamada supertipo.

Esto hace aparecer los conceptos de supertipo y subtipo. Supertipo es una entidad genérica que es dividida en subtipos. Un subtipo es un subconjunto de supertipo que comparten atributos o relaciones distintas desde otros subconjuntos. Cabe mencionar que tanto los supertipos como los subtipos cumplen con las normas de las entidades; eso si que el atributo usado como clave primaria (identificador) del supertipo debe coincidir con la clave primaria de los subtipos.

La relación entre cada supertipo y subtipo es llamada relación ISA, su notación usa el siguiente símbolo

PROFESOR RUT <pi> A 10 <M> RUT <pi> IS_A PRO_JOR_COMPLETA PROF_PARCIAL PRO_HORA
PROFESOR
RUT
<pi>
A 10
<M>
RUT
<pi>
IS_A
PRO_JOR_COMPLETA
PROF_PARCIAL
PRO_HORA

Por ejemplo:

Esta relación es leída desde el subtipo al supertipo. La relación desde el subtipo al supertipo es siempre del tipo obligatorio; es decir, simbólicamente:

II
II

esta cardinalidad es así, pues una instancia de un subtipo es siempre una instancia de un supertipo, y por el otro lado de la relación, el supertipo con respecto al subtipo es opcionalmente cero o uno.

Por lo general, el símbolo usado para la relación ISA es obviado. A esta relación ISA se le suma otro símbolo en forma de curva como se muestra a continuación:

PACIENTE ISA ISA PACIENTE PACIENTE PENSIONADO SIN PENSIÓN
PACIENTE
ISA
ISA
PACIENTE
PACIENTE
PENSIONADO
SIN PENSIÓN

Cuyo significado es el de relación exclusiva. Esta relación involucra que varios subtipos son mutuamente exclusivos, y que exactamente uno, y no más de uno, se requiere para cada una de las instancias del supertipo. Cuando usar un subtipo es una decisión que depende de cada circunstancia, aunque se dan dos criterios que pueden ayudar a tomar dicha decisión:

Diferentes atributos son usados para describir cada entidad subtipo.

Tema VI: Enfoque de Bases de Datos en el Diseño de Sistemas 1. Estrategia de Diseño

Tema VI: Enfoque de Bases de Datos en el Diseño de Sistemas

1. Estrategia de Diseño de la Base de Datos

1.1. Diagrama de las fases del enfoque de bases de datos

USUARIO REQUERIMIENTOS
USUARIO
REQUERIMIENTOS
INICIAL DE DATOS MODELO
INICIAL DE DATOS
MODELO

PLANIFICACIÓN y ANÁLISIS

Y

MODELO CORPORATIVO DATOS

MODELO

ENTIDAD

RELACIÓN

EXTENDIDO

FORMAS

USUARIO REQUERIMIENTOS INICIAL DE DATOS MODELO PLANIFICACIÓN y ANÁLISIS Y MODELO CORPORATIVO DATOS MODELO ENTIDAD RELACIÓN
USUARIO REQUERIMIENTOS INICIAL DE DATOS MODELO PLANIFICACIÓN y ANÁLISIS Y MODELO CORPORATIVO DATOS MODELO ENTIDAD RELACIÓN
PROCESO PROCESO NORMALIZACIÓN NORMALIZACIÓN
PROCESO
PROCESO
NORMALIZACIÓN
NORMALIZACIÓN
PROCESO PROCESO NORMALIZACIÓN NORMALIZACIÓN

NORMALES

COMPUTACIONAL CANONICO LÓGICO LÓGICO DE DATOS DE DATOS INTERFAZ GENERACIÓN COMPUTACIONAL CANONICO MODELO FÍSICO MODELO FÍSICO
COMPUTACIONAL
CANONICO
LÓGICO
LÓGICO
DE DATOS
DE DATOS
INTERFAZ
GENERACIÓN
COMPUTACIONAL
CANONICO
MODELO FÍSICO
MODELO FÍSICO
GENERACIÓN
MODELO CONCEPTUAL
MODELO CONCEPTUAL
DE TRANSFORMACIÓN
DE TRANSFORMACIÓN
REGLAS
PROGRAMA
PROGRAMA
RELACIONAL
DATOS
DAD
LAM
BASE
BASE
DATOS
DATOS
DATOS
MODELO
MODELO
MODELO
REGLAS

B.D-R

FASE I: Generación del Modelo Conceptual

La generación del modelo conceptual de datos se obtiene como una simplificación de un Diagrama de Clases a través del uso de la herramienta CASE.

Dado que el modelo conceptual es una simplificación, sólo contempla las relaciones de asociación y las de generalización entre las clases, las cuales pasan a convertirse en entidades. Las entidades, a diferencia de las clases sólo conservan la estructura de datos, perdiendo las operaciones que se definieron en el Diagrama de Clases.

Las relaciones especiales de un diagrama de clases (Agregación, Composición y dependencia) deben ser convertidas a relaciones de asociación normales, manteniendo sus correspondencias previamente establecidas en el otro modelo.

FASE II: Generación del Modelo Conceptual Canónico

Obtención del Modelo Conceptual Canónico a partir del Modelo Conceptual.

¿Qué es una forma canónica del modelo?

Significa que es un modelo con una estructura simple.

¿Por qué se refina el modelo hasta llegar a la forma canónica? Por razones de mantención futura del modelo y por facilidades de comprensión, a través de su documentación es que se refina el modelo.

¿Cuál es la estructura del modelo en la forma canónica?

La estructura es de tipo estrella.

FASE II: Generación del Modelo Conceptual Canónico Obtención del Modelo Conceptual Canónico a partir del

¿Cómo se obtiene una estructura tipo estrella o modelo canónico?

 

Aplicando normalización a los datos

  • - 1ª Forma Normal

  • - 2ª Forma Normal

  • - 3ª Forma Normal

Proceso de Normalización

Proceso de Normalización

Primera Forma Normal (1ª FN):

Se identifican grupos de atributos repetitivos que existen o pueden existir en cada

entidad. A continuación, se separan estos grupos de la entidad y pasan a constituir una nueva Entidad.

Sin perder la información de la llave de identificación de la entidad que le dio origen.

Ejemplo:

1. -

Entidad: Orden - Pedido

Entidad: Orden - Pedido - Producto

2. - Entidad: Personal Entidad: Personal - Carga

Ventaja: Eliminar la redundancia

  • - actualización

  • - mantención

  • - almacenamiento

Desventaja: Puede perder claridad el modelo o la entidades. Asegurado * Rut, Nombre, Direc. Beneficio *

Desventaja:

Puede

perder

claridad

el

modelo

o

la

entidades. Asegurado * Rut, Nombre, Direc.

Desventaja: Puede perder claridad el modelo o la entidades. Asegurado * Rut, Nombre, Direc. Beneficio *
  • Beneficio * Rut. , Nombre, Direc.

individualidad

de

las

Persona

Segunda forma normal (2ª FN)

Identificar aquellos atributos de la entidad que dependen parcialmente de la llave de identificación de ésta. Estos pasan a constituir una nueva entidad

 
“A” “B” C D
 

“A”

“B”

C

D

Identificador de la Entidad

  • 2 FN

El atributo D, depende del atributo B, únicamente.

 

A”

“B”

C

“B” D
“B”
D

Ejemplo:

Entidad:

Orden - Pedido - Producto

Entidad: Orden - Pedido

Entidad: Producto

Tercera forma normal (3 FN) • Eliminar la dependencia transitiva de los atributos de una entidad.
Tercera forma normal (3 FN)
Eliminar la dependencia transitiva de los atributos de una entidad.
E
F
G
H
E
F
G
G
H
• Una Entidad está en 3FN, cuando está en 2FN y cada atributo NO-PRIMO de la
Entidad es dependiente no transitivamente de cada identificador posible de la
Entidad.
Relaciones muchos a muchos
Una relación mucho es a muchos se debe transformar en una relación uno a
muchos, uno a muchos creando un NUB artificial.
NUB Natural

Eliminación de Relaciones Redundantes (o loop)

Estas relaciones redundantes corresponden a loop o trayectoria cerrada.

Eliminación de Relaciones Redundantes (o loop) • Estas relaciones redundantes corresponden a loop o trayectoria

Una relación es redundante sí:

Al eliminar ésta, se puede establecer a través de otra trayectoria de búsqueda sin perder información.

En caso de que loop no sea redundante:

Relaciones del tipo M : N (normalizadas o no)

Relaciones en que hay entidades evento y sujeto. Por lo tanto, hay relaciones entre distinto tipo de entidades.

Entidad: Factura Entidad: Producto Entidad: Factura - Producto

Eliminación de Relaciones Redundantes (o loop) • Estas relaciones redundantes corresponden a loop o trayectoria

Relaciones Redundantes

La redundancia que debe eliminarse al buscar el M.D. canónico es: la redundancia en las relaciones.

Dos relaciones son redundantes, si ambas entregan la misma información. Aunque, una sea relación directa entre dos entidades, y la otra una relación indirecta.

Ejemplo:

A B C
A
B
C

D

• Es posible encontrar relaciones redundantes en trayectorias cerradas, donde todas las relaciones de las trayectorias

Es posible encontrar relaciones redundantes en trayectorias cerradas, donde todas las relaciones de las trayectorias sean de la misma naturaleza (digan lo mismo), y no existan dos o más relaciones M : N (normalizadas o sin normalizar). llega a

Ejemplo:

Embarque Puerto va en Puerto/Barco va al Barco
Embarque
Puerto
va en
Puerto/Barco
va al
Barco

¿Cómo se analiza, si existen redundancias en las relaciones?

Se ve si hay dos o más relaciones M : N, o si las relaciones son de distinta naturaleza.

Si el resultado es:

si no hay redundancia

no se debe hacer la revisión, relación por relación, analizando sí alguna se puede eliminar.

Ejemplo: Caso anterior: Hay dos relaciones M : N (embarque y puerto/barco), no es de la misma naturaleza.

no se sigue con paso siguiente.

Ejemplo:

Gerencia

Ejemplo: Gerencia Depto. Empleado

Depto.

Ejemplo: Gerencia Depto. Empleado

Empleado

• Es posible encontrar relaciones redundantes en trayectorias cerradas, donde todas las relaciones de las trayectorias

Carga - Familiar

• Es posible encontrar relaciones redundantes en trayectorias cerradas, donde todas las relaciones de las trayectorias

Existe solo una relación M : N que es Carga - Familiar. Las relaciones son de la misma

naturaleza. Si se ha pasado el 1º Test se revisan una a una las relaciones analizando:

  • - Si alguna se puede eliminar

  • - Se elimina la relación directa, ojalá la menos obvia o clara (la que aporte menos)

y si

la relación eliminada en ambos sentidos, es decir, se recorre de arriba hacia

abajo y también hacia arriba.

Gerencia

Depto. Empleado Carga - Familiar
Depto.
Empleado
Carga - Familiar
Herencia Es la propiedad por la cual todos los atributos de un supertipo se traspasan como
Herencia

Herencia

Es

la

propiedad por la cual todos

los atributos de un supertipo se traspasan como

atributos a un subtipo proveniente de éste; esto es porque los atributos no son

explícitamente puestos en los subtipos, a excepción de la clave primaria.

Esta es la Semántica de Agregación y se representa en el ejemplo siguiente, en el cual se muestra la clase o supertipo PERSONA que posee la subclase o subtipo FUNCIONARIO, de la siguiente manera:

PERSONA

FUNCIONARIO
FUNCIONARIO

SUBTIPO EXHAUSTIVO

Indican que no existen otros subtipos adicionales a los modelados, ejemplo, para el Hospital se puede definir dos tipos de funcionarios: con contrato de tiempo completo y con contrato por horas. Entonces un funcionario puede ser un funcionario contratado tiempo completo o un funcionario contratado por horas y no existe otro tipo de contrato para los funcionarios.

SUBTIPOS EXCLUSIVOS

Cada instancia de un supertipo debe ser una instancia de solo uno de los subtipos, es decir, se trata de un OR exclusivo, por ejemplo, un funcionario puede tener un solo tipo de contrato.

Fase III: Modelo de Procesos de Datos

En este modelo se representa la forma en que los Requerimientos de Información (Requerimientos requeridos por un usuario final o una persona que toma decisiones en la Organización y hace uso de la base de datos) acceden a la estructura de datos y utiliza sus trayectorias de búsqueda.

Para construir el modelo de procesos, se utiliza el modelo de datos conceptual canónico y se carga con los requerimientos de información de modo que:

  • 1. Queden definidos los puntos de entrada a la estructura de datos;

  • 2. Queden definidas las trayectorias de búsquedas seguidas al navegar para satisfacer todos y cada uno de los requerimientos de información.

Existen dos formas de “entrar” en la estructura de datos:

  • 1. Accesos directo o selectivo: buscando por una llave de búsqueda.

Ejemplo: Recuperar en pantalla los datos de un determinado cliente (se debe conocer

el identificador del cliente.

Crut Clientes CRut 2. Acceso secuencial o por recorrido. Ejemplo: Recuperar en pantalla los datos de
 

Crut

Clientes

 
 

CRut

  • 2. Acceso secuencial o por recorrido.

Ejemplo: Recuperar en pantalla los datos de todos los clientes, ordenados por apellido

y que pertenecen a la zona = “norte”.

Clientes CRut S-Apellidos CApellidos CNombre CZona
Clientes
CRut
S-Apellidos
CApellidos
CNombre
CZona

De acuerdo a la lista de Requerimientos de Información, se debe “solicitar” la estructura de datos.

Ejemplo:

  • 1. R1.- Recuperar en pantalla los datos de un determinado cliente (se debe conocer el identificador del cliente)

  • 2. R2.- Recuperar en pantalla los datos de todos los clientes, ordenados por apellido y que pertenecen a la zona = “norte”.

  • 3. R3.- Recuperar en pantalla los datos de todos los clientes atendidos por un vendedor determinado (se debe conocer el identificador del vendedor)

  • 4. R4.- Recuperar en pantalla los datos de las últimas 10 compras de un cliente determinado (se debe conocer el identificador del cliente)

  • 5. R5.- .............

CRut

VCodigo

 

Clientes

   

Facturas

 

Vendedores

 
S-Apellidos
S-Apellidos

CRut

 
S-Apellidos CRut FNumero VCodigo

FNumero

S-Apellidos CRut FNumero VCodigo
   

VCodigo

 

CApellidos

 

FACCLIENTE

   

FACVENDEDOR

CNombre

     
 

CZona

 

Revisión del modelo de datos de acuerdo a los Requerimientos de Información:

  • 1. Revisar uno por uno los Requerimientos de Información y ver si los satisface el modelo de datos.

Cada vez que se utiliza una relación o trayectoria de búsqueda, se da un

nombre (y un ordenamiento sí es necesario) Si un requerimiento no se puede satisfacer, hay que volver a la Fase I de la estrategia de diseño. Para agregar las Entidades o Relacionamientos que

faltan e indicar los puntos de acceso “entrada” y nuevas trayectorias de búsqueda.

  • 2. Eliminar las entidades y relacionamientos que quedan sin nombres (no son utilizadas). Porque son irrelevantes.

  • 3. Reestructurar el modelo para lograr eficiencia.

Analizar en detalle los requerimientos de información, de acuerdo a: frecuencia y periodicidad; tiempo de respuesta;

Analizar en detalle los requerimientos de información, de acuerdo a: frecuencia

y periodicidad; tiempo de respuesta; nivel de complejidad; volumen; masivo o selectivo. Desnormalizar, agregar relaciones redundantes que acerquen las entidades en trayectorias de búsquedas muy largas. Sacar o incorporar atributos a una entidad (tercera forma normal).

Ejemplo de desnormalización:

  • 1. Agregar relacionamientos: con esto se optimiza la consulta, porque la trayectoria de búsqueda es más corta, pero se pueden afectar los procesos de actualización. R3.- Recuperar en pantalla los datos de todos los clientes atendidos por un vendedor determinado (se debe conocer el identificador del vendedor).

Atender

Analizar en detalle los requerimientos de información, de acuerdo a: frecuencia y periodicidad; tiempo de respuesta;
   

LOOP

 

CRut

CRut VCodigo
 

VCodigo

   

Clientes

   

Facturas

 

Vendedores

S-Apellidos
S-Apellidos

CRut

   
S-Apellidos CRut FNumero VCodigo

FNumero

S-Apellidos CRut FNumero VCodigo
   

VCodigo

 

CApellidos

 

FACCLIENTE

   

FACVENDEDOR

CNombre

     
 

CZona

 
  • 2. Agregar atributos a una entidad. Al dejar los atributos en la entidad, se tiene la ventaja que al acceder a esta tenemos toda la información inmediatamente. Pero no se puede utilizar como punto de entrada a la estructura. En el modelo de proceso se debe especificar dos tipos de procesos computacionales:

  • 1. Procesos básicos: insertar un nuevo registro en la estructura; modificar un dato; o eliminar un registro de la estructura. Procesos mantenedores de las tablas base;

  • 2. Procesos de consulta: de acuerdo a los Requerimientos de Información se especifica como se debe proveer esta información, al usuario final.

Para cada proceso computacional se debe establecer un LAM (Mapa de Acceso Lógico) y una ESP (Especificación del Proceso).

El LAM es la representación gráfica asociada a un proceso específico, es decir, se presentan las entidades y relacionamientos utilizados en el proceso.

EL ESP es la especificación de cómo funciona el proceso. Utilizando un lenguaje de alto nivel. Y estructuras básicas de especificación.

Las estructuras básicas de especificación son:

1.

Secuencia;

2. Selección (Si <condición> entonces operación ... Sino operación Finsi); 3. Iteración (Mientras <condición> hacer operación
  • 2. Selección (Si <condición> entonces operación

...

Sino operación

Finsi);

  • 3. Iteración

(Mientras <condición> hacer operación

(Repetir operación

Finmientras;

... Hasta que <condición>).

Una operación puede ser simple (leer, grabar, calcular, etc.) o compleja (selección, iteración).

Ejemplos:

  • 1. Proceso básico, insertar un nuevo cliente en la estructura:

LAM:

Atender LOOP CRut Vendedores Clientes VCodigo CRut PROFESION S-Apellidos CApellidos Carga1 CNombre Carga2 CZona
Atender
LOOP
CRut
Vendedores
Clientes
VCodigo
CRut
PROFESION
S-Apellidos
CApellidos
Carga1
CNombre
Carga2
CZona

ESP:

Leer VRut Leer Clientes Si <Cliente existe> entonces enviar mensaje “Cliente existe” ir Finsi Sino

Leer Datos Clientes Leer VCodigoVendedor Leer Vendedores Si <Vendedor Existe> entonces grabar Clientes Sino enviar mensaje “Vendedor no existe” Finsi

Finsi.

  • 2. Recuperar en pantalla los datos de las últimas 10 compras de un cliente determinado (se debe conocer el identificador del cliente).

LAM:

 

CRut

ESP:

Clientes

   

Facturas

CRut

FNumero

CApellidos

CNombre

   
CApellidos CNombre FFecha

FFecha

   

FACCLIENTE

FTotal

CZona

 
 

Leer VRut Leer Clientes Si <Cliente existe> entonces Mientras <Clientes.CRut = Facturas.RutCliente AND Conta <= 10> Hacer Leer Facturas Incrementar Conta

Presentar en Pantalla Datos Cliente y Facturas Finmientras Sino enviar mensaje “Cliente no existe” Finsi Entidad

Presentar en Pantalla Datos Cliente y Facturas Finmientras Sino enviar mensaje “Cliente no existe” Finsi

Entidad Resumen: es información redundante, pero puede facilitar la respuesta a Requerimientos de Información muy exigentes. En general, esta se puede representar como una entidad desconectada de la estructura de datos y es actualizada por procesos especiales.

Historia Ventas

Monto Vendido

Año

Mes

2. Modelo Relacional

  • 2.1. Tablas

Es la forma de estructurar los datos en filas o registros y columnas o atributos.

  • 2.2. Relación

Es la asociación que se efectúa entre entidades. Por ejemplo la relación entre las entidades facturas emitidas y clientes.

  • 2.3. Tablas relacionales

Son tablas que cumplen los siguientes requisitos:

Cada fila debe ser única, es decir no pueden existir filas duplicadas. Cada columna debe ser única Los valores de las columnas deben pertenecer al dominio de cada atributo Debe tener un solo tipo de fila, cuyo formato está definido por el esquema de tabla o la relación. El valor de la columna para cada fila debe ser único. No puede contener columnas duplicadas.

  • 2.4. Claves

En una tabla relacional a veces es necesario poder determinar una tupla (registro) concreta, lo cual es posible mediante la clave. Se debe elegir la clave entre los atributos, de forma que no puedan existir valores duplicados (la clave puede contener uno o más atributos).

  • 2.5. Operaciones sobre Tablas

Todas las operaciones que podamos realizar sobre las tablas, vistas o elementos de ellas, están integradas en el SGDBR (Sistema Gestor de Bases de Datos Relacional) como rutinas. Ejemplos de operaciones son:

Selección.

Obtiene un

subconjunto

de

filas

de

la

tabla

o vista,

que cumplen una determinada

condición.

Proyección.

Obtiene un subconjunto de columnas de todas las filas de la tabla. Unión: Realizamos la unión de varias tablas, cuyo resultado será el conjunto de todas las filas de las tablas origen. Las columnas respectivas de dichas tablas deben ser iguales entre sí.

Diferencia.

Inversa a la anterior, devuelve las filas que estén en una tabla y no pertenezcan a una segunda tabla. Deben por tanto ser iguales también las columnas respectivas entre sí.

Producto cartesiano.

El resultado será una fila por cada combinación entre cada fila de una tabla y todas las de la otra. Los valores de ambas filas se concatenarán. Intersección: Obtiene aquellas filas que sean idénticas en ambas tablas.

Join.

Es la operación de unir filas de dos tablas a través de algún campo común (normalmente la clave), dando como resultado filas con la suma de columnas de ambas tablas cuando se cumpla la condición del Join a través del campo (o campos) relacionados.

Proceso de Transformación del Modelo EER al Modelo Relacional

C

L IE N

T E

 

Rut

N

o m

b re

D

ire c c ió n Fono

G

iro

Producto cartesiano. El resultado será una fila por cada combinación entre cada fila de una

CLIENTE

RUT

NOMBRE

DIRECCIÓN

FONO

GIRO

         

Tablas en el Modelo Relacional

Nombre Tabla: CLIENTE

Nombre

RUTCL

NOMBRE

DIRECCIÓN

FONO

GIRO

SITUACIÓN

Columna

Tipo

Primary Key

         

Clave

PK

Nulo/ Unico

NN, U

NN

   

NN

 

Tipo Dato

char(10)

char(20)

varchar(25)

Numeric(8)

char(20)

char(20)

Datos

6.876.251-9

Oscar

Arturo Leon

789090

Comerciante

Buen Cliente

Ejemplo

Saavedra

678, Valpo

 

7.765.765-7

Olga Díaz

Avda. Matta

212121

Vendedora

Regular

1545, Stgo

Cliente

 

10.456.897-K

Daniel Salas

Ancoa 789

22161616

Comerciante

Mal Cliente

Stgo

Nombre Tabla: CUENTA CORRIENTE CLIENTE

 

Nombre

NUMERO

DEBE

HABER

SALDO

RUTCL

 

Columna

Tipo

Primary Key

     

Foreing Key

Clave

PK

FK

Nulo/ Unico

NN, U

   

NN

NN

Tipo Dato

Numeric(5)

Numeric(8)

Numeric(8)

Numeric(10)

char(10)

Datos

7010

300.000

 

300.000

6.876.251-9

Ejemplo 7020 400.000 400.000 7.765.765-7 7080 100.000 100.000 10.456.897-K 3.1. Reglas De Transformación PASO 1 •

Ejemplo

           
 

7020

 

400.000

  • 400.000 7.765.765-7

 
 

7080

100.000

 
  • 100.000 10.456.897-K

 

3.1. Reglas De Transformación

PASO 1

Transformar cada entidad en una relación, la cual contiene los conjuntos de valores de los identificadores (claves) y descriptores (no claves)

Cada entidad en una jerarquía de generalización o jerarquía de subconjunto es transformada en una relación. Cada una de estas relaciones contiene la clave de la entidad genérica. La relación de la entidad genérica contiene los atributos descriptivos (no claves) específicos a cada subtipo de entidad. Otra opción es incluir todos los atributos de subtipos en el supertipo (entidad genérica) y permitir valores nulos.

PASO 2

 

Transformar cada relacionamiento binario (o unario) de conectividad mucho-a- mucho en una relación con las claves de las entidades y atributos del relacionamiento.

PASO 3

 

Transformar cada relacionamiento ternario (o más alto n-ario)en una relación utilizando las reglas que se dan a continuación.

3.2. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO UNARIO Entidad Representación Ejemplos Vendedor, cada vendedor tiene exactamente uno
3.2. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO UNARIO Entidad Representación Ejemplos Vendedor, cada vendedor tiene exactamente uno
3.2. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO UNARIO
Entidad
Representación
Ejemplos
Vendedor, cada vendedor
tiene exactamente uno de los
otros vendedores como
compañero de zona
Vendedor
(arut,
nombre,
dirección, zona,
VENDEDOR
rut-compañero)
Compañero-de
Empleado, un empleado
puede tener a otro empleado
como su esposo(a)
Empleado
(arut,
nombre,
Empleado
dirección, rut-esposo)
Valores nulos (V.N)
rut.esposo permitido en
empleado
Vendedor, los vendedores
son divididos en grupos para
ciertas zonas.
Cada grupo tiene un jefe.
Vendedor
Vendedor (arut, nombre,
dirección, zona, rut.jefe)
V.N
rut.
Jefe permitido en
vendedor
Jefe de
Vendedor
(arut, nombre, ...
Vendedor,
un
vendedor
Vendedor
rut.dirige)
dirige
a
uno
de
los otros
vendedores.
Uno
debe
ser
dirigido
por
V.N rut.dirige no permitidos
a vendedor
otro vendedor
Dirige
Producto,
cada
producto
Producto
(acódigo,
precio,
puede ser
parte
de
(o
ser
Producto
descripción, stock)
componente)
muchos
otros
productos
Componente(acódigo,
acódigo. compo)
Proporción)
Formar
3.3. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO BINARIO Entidad Representación Ejemplos Cliente, cta. corriente cl. Cliente (arut,
3.3. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO BINARIO Entidad Representación Ejemplos Cliente, cta. corriente cl. Cliente (arut,
3.3. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO BINARIO
Entidad
Representación
Ejemplos
Cliente, cta. corriente cl.
Cliente
(arut,
nombre,
Cada cliente tiene una
Cliente
dirección, fono, giro)
cuenta
corriente
y
cada
cuenta tiene un cliente.
Cta.
corriente
cliente(anúmero, debe,
haber, saldo, RUTCL)
Tiene
V.N. RUTCL no permitidos
en cuenta corriente cliente
Cuenta
Corriente
Cliente, cta. corriente cl.
Cliente
(arut,
nombre,
Un cliente puede tener una
Cliente
dirección, fono, giro)
cuenta
corriente
y
cada
cuenta
pertenece
a
un
Cta.
corriente
cliente.
cliente(anúmero, debe,
haber, saldo, RUTCL)
Tiene
V.N. RUTCL permitido en
cuenta corriente cliente
Cuenta
Corriente
Vendedor, PC.
Un PC puede ser asignado a
un vendedor, pero no
necesariamente a todos.
Vendedor (arut, nombre,
)
Vendedor
PC(número,
Descripción, RutVend)
Tipo,
Tiene
V.
N RutVend permitidos en
Asignado
PC
PC
Cliente, Factura.
Cliente(arut, nombre,
)
Cada
cliente
tiene
una
o
Cliente
muchas facturas
y
cada
Factura(número,
fecha,
factura pertenece a un único
neto,
IVA,
Descuento,
cliente
RutCl)
V.
N RutCl permitidos
Factura
Vendedor, Factura. Vendedor(arut, nombre, ) Cada Vendedor puede Vendedor generar varias facturas, una factura es generada
Vendedor, Factura.
Vendedor(arut, nombre,
)
Cada
Vendedor puede
Vendedor
generar varias facturas, una
factura es generada por un
vendedor
Factura(número,
RutVD)
V. N, RutVD
No permitidos
Genera
Factura
Factura, Producto.
Factura(número, fecha,
...
)
Factura
Cada
factura
tiene
a
lo
Producto(código,
menos un producto, y cada
descripción,
)
Tiene
producto puede
estar
en
muchas facturas, o no.
Esta en
Factura.Producto(númeroF
A, códigoPR, cantidad).
Producto
3.4. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO TERNARIO Entidad Representación Ejemplos Vendedor, PlanVta, Estrategia. Vendedor(arut, nombre, )
3.4. REGLAS DE TRANSFORMACIÓN DE RELACIONAMIENTO TERNARIO
Entidad
Representación
Ejemplos
Vendedor, PlanVta, Estrategia.
Vendedor(arut, nombre,
)
Vendedor
Un vendedor
usará
una
estrategia
en
un
PlanVta(número,
meta,
PlanVta.diferentes vendedores
Uso Estrategia
localización)
usarán
diferentes
estrategias
para el mismo PlanVta.
Estrategia(código,
Vendedores
no
usarán
la
Estrategia
descripción)
Plan Vta
misma
estrategia
para
diferentes
PlanVta,
pero
diferentes vendedores pueden
usar la misma estrategia para
diferentes PlanVta.
Uso.Estrategia(RutVD,
número, código)
Tema VII: Lenguaje de programación SQL Conceptual Data Model Project : MODELO DE VENTAS Model :

Tema VII: Lenguaje de programación SQL

Conceptual Data Model Project : MODELO DE VENTAS Model : Model_CONCEPTUAL DE VENTAS Author : Version
Conceptual Data Model
Project : MODELO DE VENTAS
Model
: Model_CONCEPTUAL DE VENTAS
Author :
Version
28-07-02
JEFE_DE VENDEDORES VRUT VAPELLIDO_PATERNO VAPELLIDO_MATERNO VNOMBRES VDIRECCION VMAIL VMETASEMESTRAL VMETAANUAL VSUELDO VCOMISION VTIPO VFECHA_CONTRATO VCIUDAD
JEFE_DE
VENDEDORES
VRUT
VAPELLIDO_PATERNO
VAPELLIDO_MATERNO
VNOMBRES
VDIRECCION
VMAIL
VMETASEMESTRAL
VMETAANUAL
VSUELDO
VCOMISION
VTIPO
VFECHA_CONTRATO
VCIUDAD
CLIENTES CRUT CAPELLIDOS CNOMBRE CDIRECCION FACTURAS CCIUDAD FNUMERO CPAIS FFECHA CFONO FNETO CFONOMOVIL POSEER FIVA CMAIL
CLIENTES
CRUT
CAPELLIDOS
CNOMBRE
CDIRECCION
FACTURAS
CCIUDAD
FNUMERO
CPAIS
FFECHA
CFONO
FNETO
CFONOMOVIL
POSEER
FIVA
CMAIL
FDESCUENTO
CGIRO
FTOTAL
CSITUACION
CACTIVOS
CPASIVOS
CSALDO
TENER
CLIMITECREDITO
CTIPO
DETALLE
DENUMERO
DECODIGOPRODUCTO
DECANTIDAD
DESUBTOTAL
ESTAR
PRODUCTOS
PCODIGO
PDESCRIPCION
PPRECIO_VENTA
PEXISTENCIA
PSTOCKMINIMO
PESPECIFICACION
PCOLOR
PPESO
Tema VII: Lenguaje de programación SQL Conceptual Data Model Project : MODELO DE VENTAS Model :

GENERA

VENDEDOR NACIONAL VNFONO VNFONO_MOVIL VNANEXO VNZONA VENDEDOR INTERNACIONAL VICODIGO POSTAL VISEGUROS VIFAX VIASIGNACION ASIGNADO PAIS PACODIGO
VENDEDOR NACIONAL
VNFONO
VNFONO_MOVIL
VNANEXO
VNZONA
VENDEDOR INTERNACIONAL
VICODIGO POSTAL
VISEGUROS
VIFAX
VIASIGNACION
ASIGNADO
PAIS
PACODIGO
PANOMBRE
PAPOBLACION
PAUBICACION
PATAMAÑO_MERCADO
PRODUCTO NACIONAL
PNCOSTO
PRODUCTO IMPORTADO
PICIF
PIFOB
PISEGUROS
PICOSTO
PIORIGEN

VRUT = VEN2_VRUT FACTURAS FNUMERO integer VENDEDOR_INTERNACIONAL CRUT varchar(10) VRUT varchar(10) VRUT varchar(10) PACODIGO integer CRUT
VRUT = VEN2_VRUT
FACTURAS
FNUMERO
integer
VENDEDOR_INTERNACIONAL
CRUT
varchar(10)
VRUT
varchar(10)
VRUT
varchar(10)
PACODIGO
integer
CRUT = CRUT
VEN_VRUT
varchar(10)
VEN_VRUT
varchar(10)
FFECHA
date
VEN2_VRUT
varchar(10)
FNETO
integer
VAPELLIDO_PAT
varchar(25)
FIVA
integer
VAPELLIDO_MAT
varchar(25)
FNUMERO = FNUMERO
VRUT = VEN_VRUT
FDESCUENTO
integer
VNOMBRES
varchar(10)
FTOTAL
integer
VDIRECCION
varchar(25)
CLIENTES
VCIUDAD
varchar(20)
CRUT
varchar(10)
VMAIL
varchar(20)
CAPELLIDOS
varchar(25)
VMETASEMESTRAL
integer
CNOMBRE
varchar(25)
VMETAANUAL
integer
CDIRECCION
varchar(25)
VSUELDO
integer
CCIUDAD
varchar(15)
VCOMISION
integer
CPAIS
varchar(15)
VTIPO
varchar(10)
CFONO
integer
VFECHA_CONTRATO
date
CFONOMOVIL
smallint
VICODIGO_POSTAL
varchar(20)
CMAIL
varchar(20)
VISEGUROS
integer
CGIRO
varchar(10)
VIFAX
integer
CSITUACION
varchar(10)
VRUT = VRUT
VIASIGNACION
integer
CACTIVOS
integer
CPASIVOS
integer
CLSALDO
integer
CLIMITECREDITO
integer
CTIPO
varchar(10)
VRUT = VEN_VRUT
DETALLE
VENDEDOR_NACIONAL
FNUMERO
integer
VRUT
varchar(10)
PCODIGO
integer
VEN_VRUT
varchar(10)
PRO_PCODIGO
integer
VAPELLIDO_PAT
varchar(25)
DECANTIDAD
integer
VAPELLIDO_MAT
varchar(25)
DESUBTOTAL
integer
VNOMBRES
varchar(10)
VDIRECCION
varchar(25)
PACODIGO = PACODIGO
VCIUDAD
varchar(20)
VMAIL
varchar(20)
VMETASEMESTRAL
integer
VRUT = VEN_VRUT
VMETAANUAL
integer
VSUELDO
integer
VCOMISION
integer
VTIPO
varchar(10)
PCODIGO = PRO_PCODIGO
PCODIGO = PCODIGO
VFECHA_CONTRATO
date
VNFONO
integer
VNFONO_MOVIL
integer
VNANEXO
integer
VNZONA
varchar(10)
PRODUCTO_NACIIONAL
PCODIGO
integer
PDESCRIPCION
varchar(30)
PPRECIO_VENTA
integer
PEXISTENCIA
integer
PAIS
PSTOCKMINIMO
integer
PACODIGO
integer
PESPECIFICACION
varchar(20)
PANOMBRE
varchar(20)
PCOLOR
varchar(20)
PAPOBLACION
integer
PPESO
integer
PAUBICACION
varchar(20)
PNCOSTO
integer
PATAMANO_MERCADO
integer
PRODUCTO_IMPORTADO
PCODIGO
integer
PDESCRIPCION
varchar(30)
PPRECIO_VENTA
integer
PEXISTENCIA
integer
PSTOCKMINIMO
integer
PESPECIFICACION
varchar(20)
PCOLOR
varchar(20)
PPESO
integer
PICIF
integer
PIFOB
integer
PISEGUROS
integer
PICOSTO
integer
PIORIGEN
varchar(20)
Utilizando como referencia el modelo conceptual de ventas anterior, se definirán los comandos del Lenguaje de

Utilizando como referencia el modelo conceptual de ventas anterior, se definirán los comandos del Lenguaje de programación SQL.

  • SQL es un lenguaje declarativo de cuarta generación y tiene tres funcionalidades básicas.

  • DDL (Data Definition Language), son los comandos que permiten definir la estructura de la base de datos relacional, como por ejemplo: Crear tablas, indexes, Alterar Tablas, Crear Vistas.

  • DML (Data Manipulation Language), son los comandos que permiten insertar nuevos registros, modificar registros en la base de datos y eliminar registros, además, de la recuperación de la información. Los comandos son: Insert, Update y Select.

  • DCL (Data Control Language), son los comandos de control y seguridad del sistema.

1. Ejemplo de comandos DDL.

create table CLIENTES

( CRUT

varchar(10)

not null,

 

CAPELLIDOS

varchar(25)

,

CNOMBRE

varchar(25)

,

CDIRECCION

varchar(25)

,

CCIUDAD

varchar(15)

,

CPAIS

varchar(15)

,

CFONO

integer

,

CFONOMOVIL

smallint

,

CMAIL

varchar(20)

,

CGIRO

varchar(10)

,

CSITUACION

varchar(10)

,

CACTIVOS

integer

,

CPASIVOS

integer

,

CLSALDO

integer

,

CLIMITECREDITO

integer

,

CTIPO

varchar(10)

,

primary key (CRUT)

);

%%

Table: VENDEDORES

 

%% ============================================================ create table VENDEDORES (

VRUT

varchar(10)

not null,

 

VEN_VRUT

varchar(10)

not null,

 

VAPELLIDO_PAT