Sunteți pe pagina 1din 168

SISTEMAS COMPUTACIONALES - CARRERA DE INGENIERÍA ELECTRÓNICA

FACULTAD DE INGENIERÍA - UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE INGENIERÍA - UNIVERSIDAD MAYOR DE SAN ANDRÉS ETN 1000 – Bases de Datos EL

ETN 1000 – Bases de Datos

EL DOCUMENTO QUE SE PRESENTA A CONTINUACIÓN, ES RECOPILACIÓN DE MONOGRAFÍAS, TRABAJOS, PRESENTACIONES Y OTROS, RELACIONADOS CON LA MATERIA DE BASES DE DATOS. HA SIDO RECOPILADO POR J. A. NAVA A., PARA SU USO EN LA GESTIÓN 2004 DENTRO DE LA ASIGNATURA DE ETN 1000 DE LA UMSA.

La Paz - 2004

INDICE

Cap. I.- Introducción a las bases de datos y los

7

I. Conceptos básicos:

7

 

I.1.

7

I.2. Concepto de base de datos

8

I.3 Concepto de SGBD

10

I.4 Tareas del SGBD

11

I.5 Funciones de la Base de Datos

11

I.6 El Administrador de la BD y el Administrador de los Datos

12

I.7 Beneficios de la Base de Datos

13

I.8 Tipos de Bases de Datos

14

I.9 Estructura de un SGBD

14

II. Arquitectura de un SGBD. El modelo ANSI-SPARC:

16

 

II.1. Introducción

17

II.2. El Nivel Externo

18

II.3. El Nivel Conceptual

19

II.4. El Nivel Interno

19

II.5. Mapeos, Aplicaciones y Correspondencias

20

II.5.1 Correspondencia Conceptual/Interno

20

II.5.2 Correspondencia Externo/Conceptual

20

II.6. El Administrador de la Base de Datos

21

II.6.1 Definición del esquema conceptual

21

II.6.2 Definición del esquema interno

21

II.6.3 Relación con los usuarios

21

II.6.4 Definición de los controles de seguridad e integridad

21

II.6.5 Definición de procedimientos de copia de seguridad y recuperación

22

II.6.6 Analizar y controlar el rendimiento del sistema

22

II.7. El Sistema de Gestión de Bases de Datos

22

II.7.1 Definición de datos

22

II.7.2 Manipulación de datos

22

II.7.3 Seguridad e Integridad de los datos

22

II.7.4 Recuperación de datos y Concurrencia

22

II.7.5 Diccionario de datos

23

II.7.6 Rendimiento

23

II.8. BackEnd y FrontEnd

23

III. Mas sobre ANSI/X3/SPARC:

24

IV. Gráficas relacionadas:

28

Cap. II.- Modelo de Datos

32

I. Introducción:

32

II. Los usuarios:

33

III.

Ciclo de vida de una base de datos:

34

1. - Análisis de las necesidades

35

2. -Estudio de viabilidad

35

3. - Definición de requisitos

36

4. - Diseño

36

 

5. - Implementación

36

6. - Evaluación y Perfeccionamiento

37

IV.

Criterios de calidad

37

Legibilidad

37

Fiabilidad

37

Portabilidad

37

Modificabilidad

37

Eficiencia

38

Auto descripción

38

Trivialidad

38

Claridad

38

Coherencia

38

Completo

38

Concisión

38

Facilidad de Aprendizaje

39

Facilidad de Uso

39

Generalidad

39

Independencia de Usuario

39

Independencia de Sistema

39

Independencia de Instalación

39

Modularidad

39

Observable

39

Precisión

40

Protección

40

Trazabilidad

40

Indicadores de calidad:

40

V.

El modelo lógico:

41

Clasificación

42

Agregación

42

Generalización

42

Asociación

42

VI.

Restricciones de integridad:

43

Cap III.- Modelo Relacional

47

I. Introducción:

47

II.

Proceso de normalización:

51

Definición de la clave

52

Primera forma normal (1NF)

52

Segunda forma normal (2NF)

53

Tercera forma normal (3NF)

54

Cuarta forma normal (4NF)

55

Otras formas normales

56

III.

Las interrelaciones:

56

Interrelaciones uno a uno

56

Interrelaciones uno a varios

56

Interrelaciones varios a varios

57

Problemas con las interrelaciones

58

Atributos de las interrelaciones

59

IV.

Álgebra relacional:

59

Unión

60

Intersección

60

Diferencia

60

 

Producto

61

Selección

61

 

Proyección

61

Reunión

62

División

62

Asignación

63

V.

Cálculo relacional:

63

Cuantificadores existenciales

64

Cuantificadores universales

64

Cap. IV.- Modelo E/R

65

I.

Entidades:

65

II. Atributos:

66

III. Dominios:

68

IV. Claves:

69

V. Interrelaciones:

69

VI. Restricciones en las interrelaciones:

74

 

Restricción de Exclusividad

74

Restricción de Exclusión

74

Restricción de Inclusividad

75

Restricción de Inclusión

76

VII. Ejemplo:

77

Cap. V.- SQL

79

I. Introducción:

79

 

Breve Historia

79

Componentes del SQL

80

Comandos

80

Cláusulas

81

Operadores Lógicos

81

Operadores de Comparación

81

Funciones de Agregado

81

Orden de ejecución de los comandos

82

II. Consultas:

82

II.1. Consultas de Selección:

82

Consultas básicas

82

Devolver Literales

82

Ordenar los registros

83

Uso de Índices de las tablas

83

Consultas con Predicado

84

ALL

84

TOP

84

DISTINCT

85

DISTINCTROW

85

ALIAS

86

Recuperar Información de una base de Datos Externa

87

II.2. Consultas de Acción:

88

 

DELETE

88

INSERT INTO

88

Para insertar un único Registro:

88

Para seleccionar registros e insertarlos en una tabla nueva

89

Para insertar Registros de otra Tabla:

89

Ejemplos

90

UPDATE

91

II.3. Consultas de Unión Internas:

92

Consultas de Combinación entre tablas

92

Consultas de Autocombinación

96

Consultas de Combinaciones no Comunes

96

CROSS JOIN (SQL-SERVER)

97

SELF JOIN

97

FULL JOIN

100

II.4. Consultas de Unión Externas:

100

II:5.

Consultas de Referencias Cruzadas:

102

III.

Criterios de Selección:

106

Operadores Lógicos

107

Valores Nulos

109

Intervalos de Valores

109

El Operador Like

110

El Operador In

111

La cláusula WHERE

111

IV.

Agrupamiento de Registros:

113

GROUP BY

113

AVG

114

Count

114

Max, Min

115

StDev, StDevP

116

Sum

116

Var, VarP

117

COMPUTE de SQL-SERVER

117

V. Tipos de Datos

118

VI. Subconsultas:

120

VII. Estructuras de las Tablas:

127

Creación de Tablas Nuevas

127

La cláusula CONSTRAINT

128

Creación de Índices

129

Modificar el Diseño de una Tabla

130

VIII. Problemas Resueltos

132

VIII.1. Búsqueda de Registros Duplicados:

132

VIII.2. Búsqueda de Registros no Relacionados:

132

IX.

Cursores:

133

X.

FULL TEXT

137

X.1

Resumen:

137

El predicado CONTAINS

137

El predicado FREETEXT

139

El predicado CONTAINSTABLE

139

El predicado FREETEXTTABLE

140

X.2

Freetext y Contains:

140

Consultas e índices de texto

140

Componentes de las consultas de texto de Transact-SQL

141

Funciones de conjunto de filas CONTAINSTABLE y FREETEXTTABLE

142

CONTAINSTABLE (T-SQL)

143

 

Ejemplos

147

FREETEXTTABLE

150

 

Ejemplos

151

Utilizar el predicado CONTAINS

151

Utilizar el predicado FREETEXT

153

Funciones de conjunto de filas CONTAINSTABLE y FREETEXTTABLE

153

Los predicados de texto de las funciones

154

Comparación entre CONTAINSTABLE y CONTAINS

155

Comparación entre FREETEXTTABLE y FREETEXT

156

Identificación del nombre de la columna de la clave única

156

Limitar los conjuntos de resultados

159

Buscar palabras o frases con valores ponderados (término ponderado)

159

Combinar predicados de texto con otros predicados de TRANSACT-SQL

160

Utilizar predicados de texto para consultar columnas de tipo IMAGE

161

XI. ACCESS

162

XI.1. Bases de datos externas:

162

Acceso a una base de datos externa de Microsoft Access:

162

Acceso a una base de datos externa de dBASE III o IV:

163

Acceso a una base de datos de Paradox 3.x o 4.x:

163

Acceso a una base de datos de Btrieve:

163

XI.2

Consultas con Parámetros:

163

XI.3. Omitir los permisos de acceso:

164

XI.4. Claúsula PROCEDURE:

165

XII.

OPTIMIZAR SENTENCIAS:

166

Introducción

166

Diseño de las tablas

166

Gestión y elección de los índices

166

Campos a Seleccionar

167

Campos de Filtro

167

Orden de las Tablas

168

Cap. I.- Introducción a las bases de datos y los SGBD.

I. Conceptos básicos:

I.1. Introducción.

Los sistemas de información tradicionales almacenan información en ficheros. Estos sistemas tienen las siguientes características:

Los ficheros se diseñan para una determinada aplicación

Las aplicaciones no suelen compartir los ficheros

Como consecuencia:

Hay una ocupación inútil de memoria secundaria

Suele aparecer un cierto grado de inconsistencia en la información

Aparece una falta de flexibilidad del sistema de ficheros para adaptarse a las nuevas necesidades

Existe cierta dificultad para compartir información

En general, estamos ante un esquema de funcionalidad datos/aplicaciones que puede ser bien representado por el siguiente ejemplo:

que puede ser bien representado por el siguiente ejemplo: Para resolver estos problemas relacion ados con

Para resolver estos problemas relacionados con el tratamiento de los datos y de la información surgieron las Bases de Datos. Se trata de aplicar una

‘orientación al dato’ para resolver todos los problemas relacionados con las necesidades de manejar y tratar la información, bien directamente por los usuarios o bien a través de aplicaciones que hagan uso de la información. Así pues, el esquema de funcionalidad anterior, se podría representar ahora bajo este nuevo concepto de la siguiente forma:

ahora bajo este nuevo concepto de la siguiente forma: I.2. Concepto de base de datos Son

I.2. Concepto de base de datos

Son muy numerosas las definiciones de base de datos, y si se analizan detenidamente, se suele observar en casi todas ellas coincidencias en ciertos elementos, aunque también se detecta la falta de otros fundamentales que son característicos de las bases de datos y que marcan la diferencia entre este concepto y el de ficheros. A continuación se proporcionan algunas definiciones de base de datos:

“Colección de datos interrelacionados almacenados en un conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una aplicación o más, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados. (Martín, 1975).”

“Colección o depósito de datos, donde los datos están lógicamente relacionados entre sí, tienen una definición y descripción comunes y están estructurados de una forma particular. Una base de datos es, también, un modelo del mundo real y, como tal, debe poder servir para toda una gama de usos y aplicaciones. (Conference des Staticiens Européens, 1977).”

“Conjunto de datos de la empresa memorizado por un ordenador, que es utilizado por numerosas personas y cuya organización está regida por un modelo de datos. (Flory, 1982).”

“Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador para satisfacer simultáneamente a varios usuarios de forma selectiva y en tiempo oportuno. (Delobel, 1982).”

“Colección no redundante de datos compartibles entre diferentes sistemas de aplicación. (Howe, 1983).”

“Colección integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios. (Deen, 1985).”

“Conjunto de ficheros maestros, organizados y administrados de una manera flexible de modo que los ficheros puedan ser fácilmente adaptados a nuevas tareas imprevisibles. (Frank, 1988).”

“Colección de datos interrelacionados. (Emasri y Navathe, 1989).”

La aparición de la expresión base de datos se produce a comienzos de los años 60. En 1963 ya aparece el término Data Base en un simposio en Santa Mónica (EEUU), donde se propuso una definición que no fue universalmente aceptada.

Posteriormente, en 1967, el grupo de estandarización CODASYL decidió cambiar su primitiva denominación en la que no aparecía la expresión bases de datos por el de Data Base Task Group.

Algo en lo que coinciden todas las definiciones es que una base de datos es un conjunto, colección o depósito de datos almacenados en un soporte informático de acceso directo. Los datos deben estar estructurados e interrelacionados de acuerdo con un modelo capaz de recoger en máximo contenido semántico.

Dada la importancia que tienen en el mundo real las interrelaciones entre los datos, es imprescindible que la base de datos sea capaz de almacenarlas, al igual que hace con otros elementos, siendo esta diferencia esencial respecto a los ficheros donde no se almacenan las interrelaciones. En el mundo real existen, además, restricciones semánticas a las que se está concediendo una importancia creciente y que, en los sistemas actuales, tienden a almacenarse junto con los datos, igual que las interrelaciones.

La redundancia de los datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni innecesarias, y que las redundancias físicas, en muchos casos convenientes, sean tratadas por el mismo sistema, de modo que no puedan producirse incoherencias. Esto podría resumirse diciendo que en las bases de datos no debe existir redundancia lógica, aunque sí se admite redundancia física por motivos de eficiencia.

Las bases de datos han de atender a múltiples usuarios y diferentes aplicaciones, en contraposición a los sistemas de ficheros, en los que cada

fichero está diseñado para responder a las necesidades de una determinada aplicación.

Otro aspecto importante de las bases de datos es la independencia, tanto física como lógica, entre datos y tratamientos. Esta independencia, objetivo fundamental de las bases de datos, es una característica esencial que distingue a las bases de datos de los ficheros.

La definición y la descripción del conjunto de datos contenidos en la base deben ser únicas y estar integradas con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran almacenados en soporte magnético, mientras su descripción está separada de los mismos, formando parte de los programas. Suele haber, además, una documentación adicional en soporte papel, en muchos casos insuficiente y no actualizada. Este tipo de organización da lugar a infinidad de problemas. En las bases de datos, la descripción y la definición y documentación completa se almacenan junto con los datos, de modo que estos están autodocumentados, y cualquier cambio que se produzca en dicha documentación se ha de reflejar y quedar recogido en el sistema con todas las ventajas que de ello se derivan.

La actualización y recuperación en las bases de datos se debe realizar mediante procesos bien determinados, procedimientos que han de estar diseñados de modo que se mantenga la integridad, seguridad y confidencialidad de la base de datos.

El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo, y en la actualidad podemos definir una base de datos como:

“Colección o depósito de datos integrados, con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de estas, y su definición y descripción, únicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualización y recuperación, comunes y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos.”

I.3 Concepto de SGBD

Se puede definir un sistema de gestión de base de datos (SGBD) como un conjunto coordinado de programas, procedimientos, lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base de datos, manteniendo su integridad, confidencialidad y seguridad.

Dicho con otras palabras, un SGBD es la herramienta que permite interactuar los datos con los usuarios de los datos, de forma que se garanticen todas las propiedades definidas para una base de datos. En algunos casos el SGBD trabajará directamente con los datos, y en otras ocasiones lo hará a través del Sistema Operativo de la máquina donde resida el SGBD.

del Sistema Operativo de la máquina donde resida el SGBD. I.4 Tareas del SGBD Las principales

I.4 Tareas del SGBD

Las principales tareas que debe desarrollar un SGBD son las siguientes:

El SGBD oculta al usuario los detalles del almacenamiento de la información, mostrando una visión ‘abstracta’ de la información.

El SGBD garantiza la independencia lógica y física de los datos.

El SGBD permite integrar distintos tipos de información y permite compartirlos entre distintas aplicaciones y usuarios.

EL SGBD se encarga también de garantizar la seguridad de la información, controlando el acceso a la misma.

El SGBD controla la integridad de la información comprobando la consistencia de la misma cuando se realizan operaciones de inserción, modificación o borrado.

El SGBD organiza el acceso concurrente a la información por parte de distintas aplicaciones y usuarios, eliminando la posibilidad de interferencias o conflictos entre diferentes acciones.

I.5 Funciones de la Base de Datos

Las funciones que realiza una base de datos son las siguientes:

Crear nuevos ficheros. Crear nuevas estructuras que permitan el almacenamiento de nueva información o nuevos datos, así como de las interrelaciones adecuadas entre los mismos.

Introducir datos. Capacidad de insertar nuevos datos sobre las estructuras ya creadas, al igual que la inserción de interrelaciones entre los datos introducidos en el sistema.

Extraer datos. Capacidad de extracción selectiva de la información en base, generalmente, a un lenguaje de consulta que permite interaccionar con la base de datos a través del SGBD.

Actualizar o modificar datos. Alteración de las estructuras de datos y de los contenidos existentes en las estructuras de datos que definen una base de datos.

Borrar datos. Eliminación de datos existentes en la base de datos, pero manteniendo siempre la integridad de la base de datos.

La interacción con la BD se realiza a través de un lenguaje de definición (DDL) y manipulación (DML) de datos. Estos lenguajes permiten realizar operaciones interactivas o diferidas sobre la base de datos.

El SQL (Structured Query Language) es un lenguaje combinado de manipulación y definición de datos, y es el estándar más utilizado en las bases de datos relacionales. Por ejemplo, algunas sentencias en SQL son:

SELECT * FROM MI_TABLA; INSERT INTO MI_TABLA VALUES (‘CLAVE1’,12124); DELETE FROM MI_TABLA; UPDATE MI_TABLA SET MI_CAMPO=‘CLAVE2’ WHERE

MI_CAMPO=’CLAVE1’;

Las instrucciones al SGBD y a la base de datos pueden introducirse interactivamente por el operador o incorporarse a programas de aplicación escritos en cualquier lenguaje de propósito general (C, Pascal, Basic, …). En SQL, este modo de programación se denomina SQL embebido (embeded SQL).

I.6 El Administrador de la BD y el Administrador de los Datos

El Administrador de la Base de Datos es la persona encargada de la operación de sistema, y es el responsable de decidir:

Los datos que se deben almacenar en la base de datos

La política de mantenimiento, tratamiento de los datos y seguridad de la información El Administrador de los Datos es una persona relacionada con las actividades de gestión y dirección en la empresa que conoce a fondo los flujos de información dentro de la empresa y las necesidades de utilización de la misma por cada departamento.

El Administrador de la BD decide la mejor forma de desarrollar las directivas del administrador de datos, organizando la administración del sistema y la operación de los usuarios.

El Administrador de la BD es un especialista en bases de datos e informática que conoce las herramientas de gestión de la base de datos, así como la forma de desarrollar los planes del administrador de datos. Así mismo, decide la política de copias de seguridad, duplicación de la información filtros de acceso de usuarios que aseguren los niveles de seguridad deseados, tanto frente a la pérdida de información como frente al acceso no autorizado.

I.7 Beneficios de la Base de Datos

Independencia de los datos. Podemos definirla como la independencia de la representación de la información respecto a las aplicaciones que la utilizan. De esta forma, se consigue una representación conveniente para todos los usos posibles de los datos y la estandarización de procedimientos.

o

Distintas aplicaciones necesitan distintas ‘vistas’ de los datos.

o

Es posible modificar la estructura de almacenamiento de la información sin afectar a las aplicaciones que los utilizan.

Reducción de la redundancia. Evita el almacenamiento múltiple de una misma información para uso de distintas aplicaciones, o en distintos departamentos con propósitos diferentes. Como veremos, además de la economía importante en coste de mantenimiento de la información y la posibilidad de extender el uso de la información, se consigue también evitar algunos problemas que puede producir la redundancia.

Evitar inconsistencias. Impide que exista información discrepante sobre un mismo y único hecho. La aparición de información inconsistente e incluso contradictoria puede darse si se almacena redundantemente información relativa a un mismo hecho u objeto.

Compartir datos. Permite utilizar los mismos datos entre distintos usuarios y aplicaciones, gestionando el acceso concurrente de todas ellas a la información.

Garantizar la seguridad. Permite garantizar la seguridad de la información, controlando el acceso y la manipulación de la información por las distintas aplicaciones y usuarios. También mantiene la integridad de la información.

Balancear aplicaciones conflictivas. Permite balancear la utilización de los recursos existentes, en capacidad de almacenamiento y de procesamiento entre las necesidades de los distintos usuarios y aplicaciones.

I.8 Tipos de Bases de Datos

Los sistemas de bases de datos se pueden clasificar en forma conveniente atendiendo a las estructuras de datos que manejan y los operadores presentados al usuario y que le permiten acceder a la información almacenada en ella.

Los sistemas más antiguos se han denominado pre-relacionales, y se clasifican en tres categorías. Luego aparecen los sistemas relacionales, que marcan la frontera y definen el antes y el después. Posteriormente, los sistemas post- relacionales, que están todavía en evolución, marcan la pauta de las nuevas tendencias y tecnologías:

De lista invertida (CA-DATACOM/DB, etc.)

Jerárquicos (IMS de IBM, etc.)

De red (CA-IDMS/DB, etc.)

Relacionales (ORACLE, DB2, SQL/DS, Rdb/VMS, INGRES, INFORMIX, SQLSERVER, etc.)

Sistemas deductivos de administración de bases de datos

Sistemas semánticos de administración de bases de datos

SGBD de relación universal

SGBD orientados a objetos

Sistemas extensibles de administración de bases de datos

Sistemas expertos de administración de bases de datos

I.9 Estructura de un SGBD

Un sistema de bases de datos se divide en módulos que se encargan de cada una de las responsabilidades del sistema completo. Algunas de estas funciones del sistema de bases de datos las puede proporcionar el sistema operativo de la computadora. En la mayoría de los casos, los sistemas operativos de la computadora proporcionan sólo los servicios más básicos y los sistemas de bases de datos deben construirse sobre esta base. Así, el diseño de un sistema de bases de datos debe incluir consideraciones de la interfaz entre el sistema de base de datos y el sistema operativo.

Los componentes funcionales de un sistema de base de datos se pueden dividir, a grandes rasgos, en componentes de procesamiento de consultas y componentes de gestión y almacenamiento. Los componentes de procesamiento de consultas incluyen:

Compilador de DML (Data Manipulation Language), que traduce las instrucciones del DML en lenguaje de consultas a instrucciones a bajo nivel que entiende el motor de evaluación de consultas. Además, el compilador del DML intenta transformar las peticiones del usuario en otras equivalentes pero más eficientes, encontrando así una buena estrategia para ejecutar la consulta.

Precompilador del DML embebido, que convierte las instrucciones del DML embebidas en un programa de aplicación en llamadas a procedimientos normales en el lenguaje anfitrión. El precompilador debe interactuar con el compilador del DML para generar el código apropiado.

Intérprete del DDL (Data Definition Language), que interpreta las instrucciones del DDL y las registra en un conjunto de tablas que contienen metadatos.

Motor de evaluación de consultas, que ejecuta las instrucciones a bajo nivel generadas por el compilador de DML.

Los componentes de gestión de almacenamiento proporcionan la interfaz entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación y envío de consultas al sistema. El gestor de almacenamiento incluye:

Gestor de autorización e integridad, que comprueba que se satisfagan las ligaduras de integridad y la autorización de los usuarios para acceder a los datos.

Gestor de transacciones, que asegura que la base de datos quede en un estado consistente a pesar de los fallos del sistema, y que las ejecuciones de transacciones concurrentes ocurran sin conflictos.

Gestor de archivos, que gestiona la reserva de espacio de almacenamiento en disco y las estructuras de datos usadas para representar la información almacenada en disco.

Gestor de memoria intermedia, que es responsable de traer los datos del disco de almacenamiento a memoria principal y decidir qué datos tratar en la memoria caché.

Además, se necesitan varias estructuras de datos como parte de la implementación física del sistema:

Archivos de datos, que almacenan la base de datos en sí.

Diccionario de datos, que almacena metadatos acerca de la estructura de la base de datos. El diccionario de datos se usa mucho. Por lo tanto, se debería poner especial énfasis en el desarrollo de un buen diseño e implementación eficiente del diccionario.

Indices, que proporcionan acceso rápido a elementos de datos que tienen valores particulares.

Datos estadísticos, que almacenan información estadística sobre los datos en la base de datos. El procesador de consultas usa esta información para seleccionar las formas eficientes para ejecutar una consulta.

En la siguiente figura se muestra una estructura completa de un SGBD con sus componentes y las relaciones que existen entre ellos:

sus componentes y las relaciones que existen entre ellos: II. Arquitectura de un SGBD. El modelo

II. Arquitectura de un SGBD. El modelo ANSI-SPARC:

II.1. Introducción

En este punto explicaremos una arquitectura de referencia de sistema de base de datos propuesta por el grupo de trabajo ANSI/SPARC Study Group on Data Base Management Systems (ANSI/X3/SPARC). La arquitectura cubre un doble objetivo:

Ofrece un lenguaje común para explicar los conceptos generales de base de datos.

Ofrece una arquitectura de referencia para el desarrollo de bases de datos.

La arquitectura propuesta está formada por tres niveles diferentes:

Interno: relacionado con el almacenamiento físico de la información.

Conceptual: establece la conexión entre el nivel interno y el externo

Externo: relacionado con la relación del usuario con la base de datos

De forma esquemática, los tres niveles se pueden representar del siguiente modo:

los tres nivele s se pueden representar del siguiente modo: La ANSI/SPARC: siguiente figura muestra la

La

ANSI/SPARC:

siguiente

figura

muestra

la

arquitectura

completa

propuesta

por

La arquitectura muestra: • Los distintos actores que intervienen en un sistema de bases de

La arquitectura muestra:

Los distintos actores que intervienen en un sistema de bases de datos (usuarios, DBA, DBMS, sistema de ficheros).

El papel del Administrador de la Base de Datos y del Sistema de Gestión de la Base de Datos (DBMS).

El papel del DSL y los distintos niveles en el desarrollo de una aplicación (DSL = DDL + DML).

II.2. El Nivel Externo

El usuario interactúa con el nivel externo de la base de datos. Los usuarios tienen vistas externas de la base de datos (organización + contenido). Para estos usuarios la vista es la base de datos.

El programador de aplicaciones utiliza un lenguaje de programación y un sublenguaje de datos (DSL) para desarrollar aplicaciones que manipulan y utilizan información de la base de datos (lenguaje inmerso).

El usuario final que realiza peticiones/operaciones interactivas de consulta, inserción, actualización o borrado sobre la BD.

Los DML consisten muchas veces en llamadas al SGBD a través de funciones predefinidas (API – Application Programming Interface).

Según ANSI/SPARC:

Los usuarios tienen vistas externas de la base de datos (organización + contenido).

Las vistas externas consisten en ocurrencias múltiples de registros externos.

Los registros externos (registros lógicos) no corresponden necesariamente a registros almacenados en la BD. Pueden incluir información de distintas tablas o campos calculados.

Las vistas externas se definen por medio de un esquema externo. Consiste en la definición de los distintos registros externos que la forman.

Los esquemas se definen utilizando el lenguaje DDL externo.

II.3. El Nivel Conceptual

Es la representación de toda la información contenida en la base de datos. Es la representación de los datos ‘como son’.

Según ANSI/SPARC:

Las vistas conceptuales consisten en múltiples ocurrencias de registros conceptuales que no necesariamente coinciden con los registros externos o físicos.

La vista conceptual se define a través del esquema conceptual que incluye definiciones de los distintos registros conceptuales.

El esquema conceptual se define utilizando el DDL conceptual que no tiene en cuenta los aspectos de almacenamiento de la información, la estructura de acceso, la secuencia de acceso o los índices. El esquema conceptual incluye aspectos como controles de seguridad y control de integridad.

II.4. El Nivel Interno

El nivel interno es el que trata los aspectos de almacenamiento físico de la información, y recoge la representación de almacenamiento de la información.

El nivel interno se encuentra en el paso anterior a los aspectos físicos como pista o cilindro, y es independiente de los dispositivos de almacenamiento, que son tratados por el gestor de ficheros o por el propio dispositivo de almacenamiento. Trata, pues, los aspectos lógicos del almacenamiento físico.

Las vistas internas también reciben a veces el nombre de base de datos almacenada.

Según ANSI/SPARC:

El nivel interno consiste en múltiples ocurrencias de registros internos (registros almacenados).

La vista interna se define a través del esquema interno que describe los distintos tipos de registros almacenados, los índices que existen, cómo se representan los valores (entero, doble precisión, coma flotante o fija, EBDIC o ASCII, etc.), así como la secuencia de almacenamiento de los registros.

El esquema interno se crea utilizando un lenguaje DDL interno.

En los siguientes apartados veremos las ventajas que representa la división a tres niveles de la base de datos, que fundamentalmente son aislar la operación de la base de datos frente a modificaciones de la estructura de almacenamiento y a la adición de nueva información.

II.5. Mapeos, Aplicaciones y Correspondencias

Hemos visto las tres capas que según el comité ANSI/SPARC debe tener un sistema de base de datos. Los tres niveles forman un sistema de base de datos, y por lo tanto es necesario desarrollar los mecanismos de transformación de la información entre ellos (aplicaciones que relacionen los tres niveles sobre una misma base de datos).

II.5.1 Correspondencia Conceptual/Interno

Esta correspondencia establece cómo se almacena a nivel interno los registros y campos conceptuales. Si se modifica el almacenamiento de los datos, sólo es necesario modificar la aplicación de correspondencia, y no la vista conceptual.

II.5.2 Correspondencia Externo/Conceptual

Define la correspondencia entre cada una de las vistas externas y la única vista conceptual (diferentes tipos de datos, diferentes nombres de campos, múltiples registros conceptuales fundidos en un único registro externo, etc.).

Se pueden crear vistas externas nuevas o modificar las existentes sin necesidad de modificar la vista conceptual.

La vista conceptual describe la empresa o proyecto del cual almacena información la BD en su globalidad. Por lo tanto, la vista conceptual tiene existencia más allá de los otros niveles: la vista interna se modifica con la

adquisición de nuevos equipos, las vistas externas se crean para nuevas aplicaciones y se modifican para mejorar las aplicaciones anteriores.

II.6. El Administrador de la Base de Datos

En esta sección se describe el papel del Administrador de la Base de Datos (DBA) en la arquitectura ANSI/SPARC

II.6.1 Definición del esquema conceptual

Basándose en las decisiones del Administrador de Datos (DA), el DBA crea el esquema conceptual de la base de datos. El DA decide qué información se ha de almacenar en función de las distintas aplicaciones de la BD de interés para la empresa (Diseño Conceptual). El DA conoce también las relaciones y atributos de cada una de las entidades escogidas.

El DBA decide cómo se debe almacenar la información y crea los esquemas conceptuales. El esquema compilado lo utiliza el SGBD. El esquema fuente se utiliza como documento de referencia.

II.6.2 Definición del esquema interno

El DBA decide la organización del almacenamiento físico de la información y crea la vista interna de la base de datos. Asimismo, establece las correspondencias entre los niveles físico y conceptual.

II.6.3 Relación con los usuarios

El DBA se encarga también de mantener la relación con los usuarios, asegurar que tienen acceso a la información que necesitan y que se cumplen las normas de seguridad establecidas.

El DBA presta apoyo en la definición de esquemas externos y de la correspondencia Externo/Conceptual que se realizan para los distintos grupos de usuarios.

Asimismo, el DBA se encarga de los cursos de formación y soporte técnico de los usuarios de las bases de datos

II.6.4 Definición de los controles de seguridad e integridad

Como se ha visto, forman parte del nivel conceptual

II.6.5 Definición de procedimientos de copia de seguridad y recuperación

El DBA debe definir los procedimientos necesarios para prevenir accidentes fortuitos o intencionados sobre un recurso que se convierte en vital para la empresa: la información. Debe definir también los procedimientos de recuperación ante un error en caso de que se llegue a producir.

II.6.6 Analizar y controlar el rendimiento del sistema

El DBA debe mantener el sistema de modo que se consiga el rendimiento requerido en la operación del sistema por cada usuario.

II.7. El Sistema de Gestión de Bases de Datos

El SGBD es la aplicación que gestiona/maneja todos los accesos u operaciones sobre la base de datos. Sus funciones son:

II.7.1 Definición de datos

Proporcionar lenguajes para la creación de los esquemas externo, conceptual e interno.

II.7.2 Manipulación de datos

Proporcionar un lenguaje para la manipulación de datos y un soporte para gestionar las peticiones del usuario: consulta, modificación, inserción y borrado de datos, manteniendo las propiedades que ya se han estudiado de integridad, seguridad y concurrencia.

Pueden existir dos tipos de peticiones: peticiones planificadas (la base de datos ha sido diseñada para contestarlas) y no planificadas, donde la base de datos no está adaptada a resolverlas. Estas últimas son aquellas para las cuales las correspondencias entre niveles son complejas o no existen índices creados para resolver eficientemente la consulta.

II.7.3 Seguridad e Integridad de los datos

El SGBD debe controlar las operaciones de los usuarios sobre la base de datos e impedir acciones que pongan en peligro la integridad y seguridad de la BD. La BD debe controlar el acceso a los usuarios autorizados, confirmando a través de palabras de paso la identidad de los mismos.

II.7.4 Recuperación de datos y Concurrencia

El SGBD debe contener un gestor de transacciones capaz de recuperar un estado consistente de la base de datos ante errores del sistema (fallo de la alimentación, errores provocados por usuarios, etc.).

El SGBD debe permitir el acceso concurrente de distintos usuarios a la base de datos a través del bloqueo de transacciones.

II.7.5 Diccionario de datos

El diccionario de datos contiene información sobre los ‘datos sobre los datos’, los distintos esquemas externo, conceptual e interno, y las operaciones de correspondencia entre niveles.

El diccionario de datos debe incluir también información sobre las aplicaciones que utilizan la base de datos, usuarios, etc.

II.7.6 Rendimiento

El SGBD debe proveer las herramientas para medir y ajustar el rendimiento de todas las operaciones anteriores, facilitando a cada usuario el rendimiento requerido por su aplicación dentro de las restricciones del equipo.

II.8. BackEnd y FrontEnd

Una visión más simplificada de la base de datos permite su estructuración en dos partes principales:

BackEnd, o Sección posterior. Es el DBMS en sí, y permite llevar a cabo las funciones básicas de un DBMS. En particular, permite establecer todos los aspectos de los niveles externo, conceptual e interno. Por tanto, éste es sólo otro nombre para el DBMS.

FrontEnd, o Secciones frontales. Son las diversas aplicaciones ejecutadas dentro del DBMS, tanto las escritas por los usuarios como las integradas que son proporcionadas por el proveedor del DBMS o bien por otros proveedores de programas.

el prov eedor del DBMS o bien por otros proveedores de programas. Apuntes de ETN 1000

III. Mas sobre

ANSI/X3/SPARC:

La definición de un sistema de información es la descripción detallada de la arquitectura del sistema. Las arquitecturas de bases de datos han evolucionado mucho desde sus comienzos, aunque la considerada estándar hoy en día es la descrita por el comité ANSI/X3/SPARC (Standard Planning and Requirements Committee of the American National Standards Institute on Computers and Information Processing), que data de finales de los años setenta. Este comité propuso una arquitectura general para DBMSs basada en tres niveles o esquemas: el nivel físico, o de máquina, el nivel externo, o de usuario, y el nivel conceptual. Así mismo describió las interacciones entre estos tres niveles y todos los elementos que conforman cada uno de ellos.

La arquitectura que vamos a describir brevemente corresponde a un sistema centralizado. Esta arquitectura tiene dos partes fundamentales: la de descripción de datos y la de manipulación de datos, organizadas en torno al diccionario de datos. A su vez, cada una de estas dos partes se organiza en torno a tres niveles: externo, conceptual e interno.

En la figura (arquitectura funcional ANSI/X3/SPARC), un hexágono representa el papel del DBA y un

En la figura (arquitectura funcional ANSI/X3/SPARC), un hexágono representa el papel del DBA y un rectángulo representa un procesador. En realidad, la figura del DBA agrupa los papeles de administrador de sistema, administrador de empresa y administrador de aplicaciones en lo que se refiere a la base de datos. El papel del administrador de empresa es definir el esquema conceptual usando el interfaz 1. El procesador de esquema conceptual compila este esquema y si es correcto se almacena en el diccionario de datos, que contiene todos los esquemas y reglas de proyección. Los administradores de aplicaciones se encargan de definir los esquemas externos, usando lenguajes específicos de descripción de esquemas externos (interfaz 2), según las necesidades de los usuarios y las posibilidades del sistema. Para especificar las reglas de proyección entre un esquema externo y el esquema conceptual, el administrador de aplicaciones puede consultar el esquema conceptual mediante el interfaz 3. Cuando se define correctamente un esquema externo con sus reglas de proyección asociadas, es compilado por el procesador de

esquema externo y almacenado en el diccionario de datos. Por último el administrador del sistema, mediante un lenguaje de descripción interno (interfaz 6) completa la descripción de la base de datos definiendo su esquema interno y las reglas que lo proyectan sobre el esquema conceptual. Estos diferentes lenguajes se agrupan en los dos tipos generales que antes mencionamos: lenguajes de descripción de datos (DDL) y lenguajes de manipulación de datos (DML).

El nivel clave en esta arquitectura, como se puede adivinar, es el conceptual. Éste contiene la descripción de las entidades, relaciones y propiedades de interés para la empresa (UoD), y constituye una plataforma estable desde la que proyectar los distintos esquemas externos, que describen los datos según los programadores, sobre el esquema interno, que describe los datos según el sistema físico. Las posibles proyecciones de datos quedan resumidas en la siguiente figura:

ones de datos quedan resumidas en la siguiente figura: Como cabría esperar, en la práctica cotidiana

Como cabría esperar, en la práctica cotidiana de implementación de bases de datos, esta arquitectura no es seguida al cien por cien por los DBMSs comerciales. Existen muy pocos productos que contengan aplicaciones para facilitar la fase de análisis. Por lo general, el nivel conceptual se obvia en los productos comerciales, salvo honrosas excepciones. Lo habitual es que el DBA realice el modelado conceptual usando sus propios recursos, o tal vez asistido por alguna aplicación de análisis, ya sea general o específica. El procesador del esquema conceptual, es por tanto el propio DBA. Los DBMSs sí suelen ofrecer facilidades para la creación de esquemas externos, pero sin pasar por el nivel conceptual. Por supuesto, un DBMS comercial no está obligado a seguir las recomendaciones de estandarización de arquitecturas del comité ANSI/X3/SPARC. Por lo que respecta al modelo relacional de bases de datos, los fabricantes de RDBMSs se ajustan en mayor o menor medida al modelo teórico y, en cuanto a la arquitectura, han intentado seguir las recomendaciones del grupo RDBTG (Relational Data Base Task Group), parte del comité ANSI/X3/SPARC.

El resultado de este grupo fue restar importancia a las arquitecturas y realzar la de los lenguajes e interfaces. Como consecuencia, el lenguaje SQL, está hoy en día totalmente estandarizado, y en cambio encontramos distintas arquitecturas de RDBMS. Sin embargo se pueden distinguir dos tipos generales de arquitecturas para estos sistemas de bases de datos, que mostramos gráficamente:

sistemas de bases de datos, que mostramos gráficamente: Arquitectura separada de RDBMS Arquitectura integrada de

Arquitectura separada de RDBMS

que mostramos gráficamente: Arquitectura separada de RDBMS Arquitectura integrada de RDBMS El tipo de arquitectura

Arquitectura integrada de RDBMS

El tipo de arquitectura integrada es en general preferible a la arquitectura separada y el más común entre los RDBMSs comerciales. De todos modos, la consecuencia de una integración de los lenguajes de definición de datos (DDL)

y los de manipulación de datos (DML) en un sólo lenguaje (DMDL: Data

Manipulation and Description Language), son positivas y negativas. Por un lado, esta integración resulta muy cómoda para el DBA, puesto que le basta con aprender un solo lenguaje formal para realizar todas las tareas de creación y mantenimiento de la base de datos. Pero por otro lado, estos sistemas (tanto los separados como los uniformes) fuerzan una proyección directa desde el nivel externo al interno, haciendo que el nivel conceptual, el fundamental según la arquitectura ANSI/X3/SPARC, desaparezca o se implemente en el nivel externo como una vista global externa. Por esta razón algunos DBAs

inexpertos tienden a obviar la fase de análisis, cuando de hecho es la vital para

la correcta implementación de la base de datos. Se insiste en que un buen

modelado conceptual es una condición indispensable para el correcto desarrollo de una base de datos. Se piensa que lo ideal es usar un DBMS que permita desarrollar todas las tareas (de descripción y de manipulación) lo más fácilmente posible, pero no sin antes disponer de todas las herramientas

necesarias para un correcto modelado conceptual, estén éstas o no incluidas en el DBMS.

IV. Gráficas relacionadas:

o no incluidas en el DBMS. IV. Gráficas relacionadas: Arquitectura de un SGBD Estándar. Apuntes de

Arquitectura de un SGBD Estándar.

Componentes de un sistema de información. Sistemas de información como islas interconectadas por una red

Componentes de un sistema de información.

Componentes de un sistema de información. Sistemas de información como islas interconectadas por una red de

Sistemas de información como islas interconectadas por una red de ordenadores.

como islas interconectadas por una red de ordenadores. Interoperabilidad centralizada. Apuntes de ETN 1000 –

Interoperabilidad centralizada.

Interoperabilidad distribuida. Ejemplo de interoperabilidad front- end con SGBD back-end heterogéneos. Apuntes de ETN

Interoperabilidad distribuida.

Interoperabilidad distribuida. Ejemplo de interoperabilidad front- end con SGBD back-end heterogéneos. Apuntes de ETN

Ejemplo de interoperabilidad front-end con SGBD back-end heterogéneos.

Alternativas de arquitectura e implementación de los SGBD Apuntes de ETN 1000 – gestión 2004

Alternativas de arquitectura e implementación de los SGBD

Cap. II.- Modelo de Datos

I. Introducción:

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

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

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

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

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

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

B) Modelo Lógico: se trata de una representación gráfica, mediante símbolos y signos normalizados, de

B) Modelo Lógico: se trata de una representación gráfica, mediante símbolos y

signos normalizados, de la base de datos. Su objetivo es representar la estructura de los datos y las dependencias de los mismos, garantizando la consistencia y evitando la duplicidad. Este modelo de datos se estudiará con profundidad en los capítulos siguientes.

C) Modelo Físico: se trata del almacén de los datos, es la base de datos en sí

misma, el soporte donde se almacenan los datos y de donde se extraen para convertir los datos en información. En función del gestor de bases de datos empleado las reglas de almacenamiento varían.

II. Los usuarios:

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

El primer grupo de usuarios es el PED (Procesamiento Electrónico de Datos),

normalmente compuestos por los operarios de la organización. Las

necesidades básicas de este grupo de usuarios son:

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

Generan informes de tipo listados;

Poseen acceso restringido a la información.

El

segundo grupo de usuarios es el SIM (Sistemas de Información de Gestión)

y

suele estar formado por los mandos medios de la organización. Las

necesidades básicas de este grupo de usuarios son:

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

No poseen acceso medianamente restringido a la información;

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

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

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

No tienen acceso restringido;

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

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

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

Ayudar en la toma de decisiones;

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

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

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

III. Ciclo de vida de una base de datos:

El ciclo de vida de un desarrollo de una base de datos consta de siete pasos:

1. Análisis de las necesidades

2. Estudio de viabilidad

3. Definición de requisitos

4. Diseño conceptual / lógico

5. Implementación

6. Evaluación y Mantenimiento

1.

- Análisis de las necesidades

En reunión con el cliente se deben documentar los tres grupos de usuarios definidos en la introducción de la guía, las necesidades de información de cada uno de ellos, así como los informes que cada uno necesita para su actividad y el contenido de los mismos. Cuanta más precisión exista en estos requisitos iniciales más preciso será el desarrollo de la base de datos.

En esta reunión también deben quedar documentados los niveles de seguridad de los grupos de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas informáticos del cliente (sistema operativo, tipo de red, servidores, etc.) y la ubicación de los usuarios.

No hay que olvidar que normalmente en las empresas existen ya sistemas de almacenamiento de datos, por tanto es conveniente analizar los datos ya existentes y analizar las posibles relaciones con la base de datos a desarrollar.

Un cuestionario muy sencillo pero muy útil para el administrador es el siguiente (a rellenar por todos los usuarios):

Nombre

Cargo

Área de Responsabilidad

Obligaciones principales que requieren información de la base datos

¿De qué aplicaciones recibe información?

¿Con cuánta frecuencia recibe información?

¿Qué hace con esta información?

¿Qué

precauciones

de

seguridad

debe

tomar

con

respecto

información?

a

la

¿Para que aplicación proporciona datos?

¿Están contemplados cambios para alguna de sus actividades actuales que involucren alguna de las informaciones anteriores?

2. -Estudio de viabilidad

Un estudio de viabilidad implica la preparación de un informe con las características siguientes:

1. Viabilidad tecnológica. ¿Hay tecnología suficiente para el desarrollo?

2. Viabilidad

operacional.

¿Existen

suficientes

recursos

humanos,

presupuesto, experiencia y formación para el desarrollo?

3. Viabilidad económica. ¿Se pueden identificar los beneficios? ¿Los beneficios costearían el desarrollo del sistema? ¿Se pueden medir los costes y los beneficios?

3. - Definición de requisitos

Los requisitos de desarrollo involucran el software y hardware necesario para la implementación, los recursos humanos necesarios (tanto internos como externos), la formación al personal.

Aunque un poco al margen del tema es conveniente parar en este momento y planificar las acciones a realizar elaborando un cronograma del proyecto y un organigrama con las responsabilidades de cada miembro del equipo. Conviene señalar quienes van a ser los interlocutores y fijar un calendario de reuniones de seguimiento del proyecto.

Hay que definir la figura del validador, esta persona será la encargada de velar en cada momento que no se está rebasando el alcance del proyecto, así como asegurar que la implementación está encaminada a subsanar las necesidades del cliente.

4. - Diseño

En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementación. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulación de los diferentes grupos de usuarios.

Si parte de la información necesaria para crear algún elemento establecido ya se encuentra implementado en otro sistema de almacenamiento hay que documentar que relación existirá entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos.

El diseño consta, como se vio anteriormente, de tres fases: el diseño global o conceptual, el diseño lógico y el modelo físico.

5. - Implementación

Una vez totalmente detallado el modelo conceptual se comienza con la implementación física del modelo de datos, a medida que se va avanzando en el modelo el administrador del sistema va asegurando la corrección del modelo y el validador la utilidad del mismo.

La implementación consiste en el desarrollo de las tablas, los índices de los mismos, las condiciones de validación de los datos, la relación entre las diferentes tablas. Por otro lado, la definición de las consultas y los parámetros a utilizar por cada una de ellas.

finalizada la implementación física, se asignan las

correspondientes medidas de seguridad y se ubica la base de datos en el lugar correspondiente.

Una vez

6. - Evaluación y Perfeccionamiento

En esta última etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposición cuanta información necesiten. También deberán asegurarse que el acceso a los datos es cómodo, práctico, seguro y que se han eliminado, en la medida de lo posible, las posibilidades de error.

El administrador se asegura que todos los derechos y todas las restricciones han sido implementadas correctamente y que se ha seguido en manual de estilo en la totalidad de la implementación.

El validador se asegurará que todas las necesidades del cliente han sido satisfechas.

IV. Criterios de calidad

Legibilidad

El diseño de una base de datos ha de estar redactado con la suficiente claridad para que pueda ser entendido rápidamente. El lenguaje utilizado debe ser lo suficientemente claro, conciso y detallado para que explique con total claridad el diseño del modelo, sus objetivos, sus restricciones, en general todo aquello que afecte al sistema de forma directa o indirecta. En este punto conviene aplicar el principio que una imagen vale más que mil palabras, pero en ocasiones son necesarias esas mil palabras y obviar la imagen.

Fiabilidad

Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas necesarias para la reparación de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz.

Portabilidad

El diseño deber permitir la implementación del modelo físico en diferentes gestores de bases de datos.

Modificabilidad

Ningún sistema informático es estático, las necesidades de los usuarios varían con el tiempo y por lo tanto las bases de datos se deben adaptar a las nuevas necesidades, por lo que se precisa que un buen diseño facilite el mantenimiento, esto es, las modificaciones y actualizaciones necesarias para adaptarlo a una nueva situación.

Eficiencia

Se deben aprovechar al máximo los recursos de la computadora, minimizando la memoria utilizada y el tiempo de proceso o ejecución, siempre que no sea a costa de los requisitos anteriores. En este punto se debe tener en cuenta los gestores cliente / servidor de bases de datos. En muchas ocasiones es más rentable cargar de trabajo al servidor y liberar recursos de los clientes, pero no todos los gestores permiten este tipo de trabajo, por lo tanto se ha de tener en cuenta estas dos circunstancias en el diseño de la base de datos.

Auto descripción

En la documentación generada debe estar todo el detalle del diseño, evitando referencias a otros documentos que no estén incluidos dentro de la documentación de la base de datos.

Trivialidad

Tanto el diseño como la implantación se deben realizar utilizando los estándares fijados a priori, estos estándares deberán quedar reflejados al inicio del documento.

Claridad

Todos los documentos deben estar redactados de forma clara y fácil de entender, los nombre utilizados para las tablas, los campos, índices, etc. deben ser autodescriptivos y estar perfectamente documentados.

Coherencia

Las anotaciones y terminología utilizada deben ser uniformes, para ello se debe seguir algún tipo de metodología estándar, indicando cual se ha empleado, en los casos en que se utilice alguna metodología no estándar se debe adjuntar a la documentación.

Completo

Todos los elementos constitutivos de la base de datos existen, no se han dejado partes incompletas, sin documentar o sin implementar.

Concisión

No existen elementos inútiles ni repetitivos. En este apartado hay que hacer un especial hincapié en la repetición de datos en diferentes tablas, hay que evitar a toda costa que el mismo dato se repita en varias tablas para conseguir así una optimización del tamaño de la base de datos.

Facilidad de Aprendizaje

La documentación de la base de datos se puede utilizar sin necesidad de otros conocimientos informáticos fuera del alcance del diseño e implementación de la base de datos.

Facilidad de Uso

Los datos deben ser fáciles de elaborar y los resultados fáciles de entender.

Generalidad

La base de datos debe ser capaz de adaptarse a cualquier tipo de empresa y a cualquier casuística.

Independencia de Usuario

La base de datos no debe estar ligada a la utilización en una única

instalación, hay que tener en cuenta que, aunque se trate de un desarrollo

a medida, en un futuro se podría realizar la instalación en un cliente diferente al inicial.

Independencia de Sistema

Las prestaciones y diseño de la base de datos no están vinculadas al entorno.

Independencia de Instalación

La base de datos se puede transportar fácilmente de una instalación a otra.

Modularidad

La base de datos puede ser descompuesta en elementos independientes.

Si se trata de un diseño grande, en donde hay un gran número de tablas,

conviene realizar agrupaciones entre ella, creando módulos funcionales que permitan la mejor compresión del diseño y de la implantación.

Observable

La base de datos debe permitir observar los accesos a los datos. Siempre que se pueda hay que dejar un rastro de la utilización de los datos por parte de los usuarios, esta información ayuda al redimensionado de la base de datos y a conocer el número de accesos a los datos.

Precisión

Los cálculos efectuados se deben realizar con la precisión requerida.

Protección

La base de datos debe permitir la protección de los datos frente a usos no debidos, para ello hay que elaborar un sistema de accesos definiendo diferentes usuarios con diferentes claves y especificar que autorizaciones tendrá cada usuario sobre los diferentes datos.

Trazabilidad

Tomando como punto de partida la versión actual se puede remontar su diseño hasta las especificaciones iniciales.

Indicadores de calidad:

Al finalizar el diseño de una base de datos podemos utilizar la siguiente tabla para comprobar el grado de calidad del trabajo.

1 2 3 4 5 6 7 8 9 10 Legibilidad Fiabilidad Portabilidad Modificabilidad Eficiencia
1
2
3
4
5
6
7
8
9
10
Legibilidad
Fiabilidad
Portabilidad
Modificabilidad
Eficiencia
Auto Descripción
Trivialidad
Claridad
Coherencia
Completo
Conciso
Facilidad de Aprendizaje
Facilidad de Uso
Generalidad
Independencia de Usuario
Independencia del Sistema
Independencia de Instalación
Modularidad
Observable
Precisión
Protección
Trazable
Legibilidad
TOTAL
PUNTUACION FINAL

V. El modelo lógico:

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

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

Clasificación

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

cada uno de los diferentes cursos que se imparten. Agregación Consiste en separar cada una de

Agregación

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

definir utilizando las entidades rueda, motor y chasis. Generalización Consiste en ir generando entidades de di

Generalización

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

entidad de nivel superior ag rupe las de nivel inferior. Asociación Apuntes de ETN 1000 –

Asociación

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

de entidades a partir de entidades ya existentes. VI. Restricciones de integridad: En el mundo real

VI. Restricciones de integridad:

En el mundo real existen ciertas restricciones que deben cumplir los elementos en él existentes; por ejemplo, una persona sólo puede tener un número de DNI y una única dirección oficial. Cuando se diseña una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es los mismo, reflejar las restricciones existentes en el mundo real.

Los componentes de una restricción son los siguientes:

La operación de actualización (inserción, borrado o eliminación) cuya ejecución ha de dar lugar a la comprobación del cumplimiento de la restricción.

La condición que debe cumplirse, la cual es en general una proposición lógica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso).

La acción que debe llevarse a cabo dependiendo del resultado de la condición.

En general, se puede decir que existen tres tipos de integridad:

Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su dominio, por ejemplo EDAD >= 18 - 65.

Integridad de entidad: la clave primaria de una entidad no puede tener valores nulos y siempre deberá ser única, por ejemplo DNI.

Integridad referencial: las claves ajenas de una tabla hija se tienen que corresponder con la clave primaria de la tabla padre con la que se relaciona. Por ejemplo, en la tabla familiares de los empleados necesitaremos el DNI de empleado, que es la clave ajena de la tabla.

Las restricciones se clasifican en:

A. Inherentes

Están impuestas por el modelo,

No tiene que ser definidas por el usuario, ya que se encuentran en el propio modelo,

Se activan en el momento de la definición del esquema cuando se produce un intento de violación,

Se rechaza todo esquema que no cumple estas restricciones,

Introducen rigideces en el modelo.

B. Semánticas

Impuestas por el universo del discurso,

Tienen que ser definidas por los diseñadores,

Se activan en el momento de la actualización de la base de datos,

Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha otros medios a fin de que no se produzca un estado de inconsistencia),

su

Ayudan

a

capturar

la

semántica

de

los

datos

y

a

conseguir

consistencia.

1. Ajenas Se especifican en los programas de aplicación, No están almacenadas en el esquema de la base de datos, Pueden ser violadas por actualizaciones en las que no se haya programado la restricción, El sistema de bases de datos no puede comprobar si son consistentes en sí mismas. El optimizador no puede tomarlas en consideración, Proporcionan el máximo de flexibilidad, Pueden ser programadas en un lenguaje de propósito general o en algún lenguaje propio del sistema de bases de datos, Suponen una importante carga de programación y mantenimiento.

2. Propias Se identifican en el esquema, Están almacenadas en el esquema de la base de datos, No pueden ser violadas por ninguna actualización.

a). Acción General

Es obligatorio especificar la condición y la acción, Son procedimentales (al menos en parte, ya que la acción se especifica siempre mediante un procedimiento), Suponen carga de programación, Es muy difícil (prácticamente imposible en la mayor parte de los casos) que el sistema de bases de datos pueda comprobar su consistencia, El optimizador no puede tomarlas en consideración, Hasta ahora no están estandarizadas, Están muy ligadas a los productos, Son muy flexibles, Tienen nombre y existencia propia dentro del programa.

i. Procedimientos almacenados Es obligatorio especificar la condición (además de la acción),

ii.

Son totalmente procedimentales, Pueden ser tan complejas como imponga la semántica del mundo real (tanto en la condición como en la acción), Son las más flexibles dentro de las restricciones propias. Disparadores Combinan los enfoques declarativo (en la condición) y procedimental (en la acción), Pueden ser tan complejas como imponga la semántica del mundo real en cuanto a la acción, y bastantes complejas en la condición (todo lo que permite la proposición lógica mediante la que se expresa la condición), El cumplimiento de la condición dispara la acción, Son más flexibles que las restricciones de acción específica.

b). Acción Específica

La acción está implícita en la misma restricción, por lo que no hay que definirla, Son declarativas, puesto que no especifica la acción y la condición, si se define, es declarativa, El no cumplimiento de la condición lleva a aplicar la acción, Podrían ser definidas mediante un lenguaje de tipo general, El sistema de bases de datos puede comprobar si son consistentes en sí mismas, El optimizador puede tomarlas en consideración, No suponen carga de programación, sólo de definición.

Condición General No se especifica la acción, que es siempre de rechazo (el no cumplimiento de la condición lleva consigo el rechazo de la actualización), Es obligatorio declarar la condición mediante una proposición lógica que permite condiciones de complejidad arbitraria, Además de la condición, se puede especificar algún otro componente, Son más flexibles que las de condición específica,

i.

Es más difícil optimizar su ejecución

que

de condición

específica.

en

el

caso de

las

I.

Verificación

No tienen existencia en sí mismas,

Su definición forma parte de la definición del elemento afectado por la restricción,

Se aplican a un único elemento

y

aunque pueden afectar a

otros, en este caso se complica

su

definición,

Pueden no tener nombre.

II.

Aserción

existencia

Tienen

por

mismas,

Se definen con independencia de cualquier elemento del esquema,

Pueden afectar a más de un elemento,

Tienen nombre.

ii. Condición Específica

Son opciones proporcionadas por el

propio modelo, No se especifica ninguno de los componentes relativos a una restricción

(ni

la operación, ni la condición, ni la

acción), Son poco flexibles,

El optimizador puede tomarlas en

consideración, Su ejecución puede ser más fácilmente optimizada que las de condición general.

Cap

III.-

Relacional

Modelo

I. Introducción:

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

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

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

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

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

Persona

Nombre

Apellido

Nacimiento

Sexo

Estado Civil

Juan

Loza

15/06/1971

H

Soltero

Isabel

Galvez

23/12/1969

M

Casada

Micaela

Ruiz

02/10/1985

M

Soltera

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

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

A continuación, se indicarán ambas (relación e instancia de relación) con el

término "relación", a no ser que no quede claro por el contexto a qué

acepción se refiere.

Las tuplas en una relación son un conjunto en el sentido matemático del término, es decir una colección no ordenada de elementos diferentes. Para

distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea

a un conjunto de atributos que permiten identificar unívocamente una tupla

en una relación. Naturalmente, en una relación puede haber más combinaciones de atributos que permitan identificar unívocamente una tupla ("llaves candidatas"), pero entre éstas se elegirá una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el

valor nulo (que significa un valor no determinado), en tanto que ya no permitirían identificar una tupla concreta en una relación. Esta propiedad de las relaciones y de sus llaves primarias está bajo el nombre de integridad de las entidades (entity integrity).

A menudo, para obtener una llave primaria "económica", es decir

compuesta de pocos atributos fácilmente manipulables, se introducen uno

o más atributos ficticios, con códigos identificativos unívocos para cada

tupla de la relación.

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

multivalor (multivalued). Por ejemplo, si una característica de las personas

en nuestra base de datos fuese la de tener uno o más hijos, no sería

posible escribir la relación Personas de la siguiente manera:

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

En efecto, el atributo hijos es un atributo no-atómico, bien porque una persona puede tener más de un hijo o porque cada hijo tendrá diferentes

características que lo describen. Para representar estas entidades en una base de datos relacional hay que definir dos relaciones:

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

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

Una de las grandes ventajas del modelo relacional es que define también un álgebra, llamada "álgebra relacional". Todas las manipulaciones posibles sobre las relaciones se obtienen gracias a la combinación de tan sólo cinco operadores: RESTRICT, PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido también tres operadores adicionales que de todos modos se pueden obtener aplicando los cinco fundamentales:

JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben como argumento una relación o un conjunto de relaciones y restituyen una única relación como resultado.

Veamos brevemente estos ocho operadores:

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

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

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

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

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

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

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

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

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

Personas

 

número_persona

nombre

apellido

fecha_nacimiento

sexo

estado_civil

2

Mario

Rossi

29/03/1965

M

Casado

1

Giuseppe

Russo

15/11/1972

M

Soltero

3

Alessandra

Mondella

13/06/1970

F

Soltera

Hijos

número_persona

nombre_apellido

edad

sexo

2

Maria Rossi

3

F

2

Gianni Rossi

5

M

RESTRICT (Personas)

sexo='M'

'

número_persona

nombre

apellido

fecha_nacimiento

sexo

estado_civil

2

Mario

Rossi

29/03/1965

M

Casado

1

Giuseppe

Russo

15/11/1972

M

Soltero

PROJECT sexo (Personas)

sexo

M

F

RESTRICT (Personas)

sexo='M'

'

n.

nombre

apellido

nacimiento

sexo

Estado_civil

nombre

edad

sexo

Mario

Rossi

apellido

29/03/1965

M

Casado

Maria Rossi

3

F

Mario

Rossi

Apellido

29/03/1965

M

Casado

Gianni Rossi

5

M

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

II. Proceso de normalización:

El proceso de normalización es un estándar que consiste, básicamente, en un proceso de conversión de las relaciones entre las entidades, evitando:

La redundancia de los datos: repetición de datos en un sistema.

Anomalías de actualización: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.

Anomalías de borrado: pérdidas no intencionadas de datos debido a que se han borrado otros datos.

Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.

Tomando como referencia la tabla siguiente:

 

AUTORES Y LIBROS

 

NOMBRE

NACION

CODLIBRO

TITULO

EDITOR

Date

USA

999

IBD

AW

Ad.Mig.

ESP

888

CyD

RM

Ma.Piat.

ITA

777

CyD

RM

Date

USA

666

BdD

AW

Se plantean una serie de problemas:

Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.

Anomalías de modificación: Si Ad.Mig. y Ma.Piat. desean cambiar de editor, se modifica en los 2 lugares. A priori no podemos saber cuántos autores tiene un libro. Los errores son frecuentes al olvidar la modificación de un autor. Se pretende modificar en un sólo sitio.

Anomalías de inserción: Se desea dar de alta un autor sin libros, en un principio. NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores nulos.

Asegurando:

Integridad entre los datos: consistencia de la información.

El proceso de normalización nos conduce hasta el modelo físico de datos y consta de varias fases denominadas formas normales, estas formas se detallan a continuación.

Definición de la clave

Antes de proceder a la normalización de la tabla lo primero que debemos de definir es una clave, esta clave deberá contener un valor único para cada registro (no podrán existir dos valores iguales en toda la tabla) y podrá estar formado por un único campo o por un grupo de campos.

En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el nombre del alumno ya que pueden existir varios alumnos con el mismo nombre. Podríamos considerar la posibilidad de definir como clave los campos nombre y apellidos, pero estamos en la misma situación:

podría darse el caso de alumnos que tuvieran los mismo apellidos y el mismo nombre (Juan Fernández Martín).

La solución en este caso es asignar un código de alumno a cada uno, un número que identifique al alumno y que estemos seguros que es único.

Una vez definida la clave podremos pasar a estudiar la primera forma normal.

Primera forma normal (1NF)

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de los campos contiene un único valor para un registro determinado. Supongamos que deseamos realizar una tabla para guardar los cursos que están realizando los alumnos de un determinado centro de estudios, podríamos considerar el siguiente diseño:

Código

Nombre

Cursos

1

Marcos

Inglés

2

Lucas

Contabilidad, Informática

3

Marta

Inglés, Contabilidad

Podemos observar que el registro de código 1 si cumple la primera forma normal, cada campo del registro contiene un único dato, pero no ocurre así con los registros 2 y 3 ya que en el campo cursos contiene más de un dato cada uno. La solución en este caso es crear dos tablas del siguiente modo:

TABLA A

 

TABLA B

Código

Nombre

Código

Curso

1

Marcos

1

Inglés

2

Lucas

2

Contabilidad

3

Marta

2

Informática

   

3

Inglés

   

3

Informática

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores únicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.

Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.

Segunda forma normal (2NF)

La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave definida. Si todos los campos dependen directamente de la clave se dice que la tabla está es segunda forma normal (2NF).

Supongamos que construimos una tabla con los años que cada empleado ha estado trabajando en cada departamento de una empresa:

Código Empleado

Código Dpto.

Nombre

Departamento

Años

1

6

Juan

Contabilidad

6

2

3

Pedro

Sistemas

3

3

2

Sonia

I+D

1

4

3

Verónica

Sistemas

10

2

6

Pedro

Contabilidad

5

Tomando como punto de partida que la clave de esta tabla está formada por los campos código de empleado y código de departamento, podemos decir que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la segunda:

1. El campo nombre no depende funcionalmente de toda la clave, sólo depende del código del empleado.

2. El campo departamento no depende funcionalmente de toda la clave, sólo del código del departamento.

3. El campo años si que depende funcionalmente de la clave ya que depende del código del empleado y del código del departamento

(representa el número de años que cada empleado ha trabajado en cada departamento)

Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no está en segunda forma normal, la solución es la siguiente:

Tabla A

Tabla B

 

Tabla C

Código

Nombre

Código

Dpto.

Código

Código

Años

Empleado

Departamento

Empleado

Departamento

1 Juan

 

2

I+D

1

6

6

2 Pedro

 

3

Sistemas

2

3

3

3 Sonia

 

6

Contabilidad

3

2