PDF de programación - GENERALIDADES DEL DISEÑO DE BASES DE DATOS RELACIONALES

1. GENERALIDADES DEL DISEÑO DE BASES DE DATOS

RELACIONALES



1.1 Ingeniería de software
• El diseño de bases de datos es un subproblema de la Ingeniería de Software.





• Clases de software:

(cid:224) Científico
(cid:224)
Ingeniería
(cid:224) Tiempo real
(cid:224) Soporte a la toma de decisiones
(cid:224) Operacional


Ejemplo: sistema que captura diariamente las transacciones en una organización, controlando
depósitos, cambios de políticas, estado de los inventarios, ventas y personal.
Estos sistemas son críticos en cualquier organización y si se cae el sistema, estará
temporalmente fuera de los negocios.






• Dos dimensiones de la Ingeniería de Software:

(cid:224) Ciclo de vida

(cid:224) Disciplina



Fases del proyecto a través del tiempo

Componentes del software en sí mismo


Identificación de requerimientos a través de entrevistas y revisión bibliográfica.

1.1.1 El ciclo de vida
1. Definición del alcance en términos de los objetivos de la organización.
2.
3. Análisis de los requerimientos dados en las especificaciones del diseño.
4. Diseño esquemático y detallado.
5. Construcción del software y las bases de datos.
6. Prueba e instalación del sistema.
7. Mantenimiento y ampliación repitiendo las fases anteriores.


Típicamente representados por objetos y relaciones entre ellos.


1.1.2 Disciplinas
• Datos.


• Procesos.



• Reglas del negocio.


Parte dinámica del software. En el diseño se representa mediante diagramas de flujo, diagramas
organizacionales, lenguajes 3GL, ...


Reglas que deben cumplir los procesos y los datos para que representen estados válidos del mundo real
(ejemplo: reglas para integridad referencial).



• Presentación.
Manera de presentar al usuario pantallas e informes escritos.




Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 1

• Documentación.
Manuales de referencia, Guía del usuario, Diccionario de datos, tutoriales, ...



1.1.3 Esquema de trabajo en Ingeniería de Software


Requerimientos

Análisis

Diseño

Construcción

Instalación

Mantenimiento



Datos

Reglas

Procesos

Presentación

Documentación



1.1.4 Datos/Análisis
Un diagrama Entidad/Relación, es un ejemplo de cómo la disciplina de Datos está presente en la fase de
análisis de la Ingeniería de Software.
• Diagramas Entidad/Relación

(cid:224) Documento original de Peter Peen y Chan Chen
(cid:224) Metodología Case de Barker



1.1.5 Reglas/Análisis
Las reglas que se deben cumplir en una institución
• Expresadas en lenguaje natural


1.1.6 Proceso/Construcción
• Sentencias SQL


1.2 Diseño de Bases de datos


Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 2

Diseño de BD

Este curso

Requerimientos

Análisis

Diseño

Construcción

Instalación

Mantenimiento

Datos

Reglas

Procesos

Presentación

Documentación



Independencia física de los datos.
El diseño físico es totalmente invisible para el usuario y para el software de aplicaciones


•



Identificación de requerimientos.

a) Diseño relacional.
b) Diseño físico.

1.2.1 El ciclo de vida, revisado
1. Definición del alcance.
2.
3. Análisis.
4. Diseño de la base de datos.


5. Construcción del software utilizando SQL.
6. Prueba e instalación de la base de datos.
7. Mantenimiento y ampliación repitiendo las fases anteriores.




a) Revisión del diseño relacional.
b) Reorganización del diseño físico.

1.2.2 Identificación de requerimientos
• Realizar entrevistas con los usuarios.
• Recopilar documentación.
• Llevar en forma paralela la etapa de análisis.


1.2.3 Análisis
• Definir un modelo, utilizando diagramas de entidad-relación.
• Definir las reglas del negocio.
• Definir los objetivos: claramente, de forma estable y generalizando.
• Esta etapa se conoce también como:

(cid:224) Diseño lógico.
(cid:224) Diseño conceptual.
(cid:224) Modelamiento de datos.

• Debe ser totalmente independiente de la implementación, rendimiento, software y hardware.


Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 3

1.2.4 Diseño relacional
• Definir tablas, columnas y llaves.
• Objetivos:

• A veces llamado: diseño lógico.


(cid:224) Reducir la redundancia para simplificar la administración de los datos y asegurar integridad.
(cid:224) Buscar comportamiento satisfactorio.

1.2.5 Diseño físico
• Especifica la organización interna de las tablas en los discos del computador (estructuras de

almacenamiento, manejo de índices, asignación de tablas a dispositivos, ...).



1.3 Problemas al diseñar bases de datos
• Cuáles son las entidades?
• Cuáles son las relaciones?
• Cuáles son los atributos?


1.3.1 Problemas de relatividad
La naturaleza del análisis es altamente sujetivo.

Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 4



1.3.2 Problema de datos compartidos en L


PROGRAMADOR

VENDEDOR

Nombre

Meta

Salario

Comisión

Depto






1.3.3 Problema de llaves artificiales
• Cómo se identifican de manera única cada fila de una tabla?

(cid:224) Natural, utilizando la información de varias columnas (Ejemplo: Proveedor, Parte, Fecha).
(cid:224) Artificial, utilizando una columna (Ejemplo: Código).



1.3.4 Problema de los datos tipo vector






EN FORMA DE FILA










# año



1995
1996



civil









eléctrica

mecánica

química

sistemas

1430
1870

1020
990

2050
1630

2570
1200

500
380









Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 5


















# año



1995
1995
1995
1995
1995
1996
1996
1996
1996
1996

EN FORMA DE COLUMNA



# carrera

civil

eléctrica
mecánica
química
sistemas

civil

eléctrica
mecánica
química
sistemas



alumnos

1430
1020
2050
2570
500
1870
990
1630
1200
380

1.3.5 Administración de la base de datos
• El administrador de la base de datos.

(cid:224) Una o varias personas, dependiendo del tamaño de la organización.
(cid:224) Enfocadosa una base de datos específica o a un motor específico de bases de datos.
(cid:224) Encargado de:

* Diseñar las bases de datos.
* Rediseñar las bases de datos.
* Construir las bases de datos.
* Reponder por la seguridad, integridad y disponibilidad de los datos.
* Hacer monitoreo.
* Chequear el rendimiento.
* Hacer el ajuste de los parámetros generales de comportamiento.




• El administrador de los datos.

(cid:224) Responsable de los datos, a nivel global.
(cid:224) Responsable de proporcionar las vistas necesarias de los datos a los usuarios.
(cid:224) De importancia especial en la fase de análisis.




• El diccionario de datos.

(cid:224) Sitio donde se encuentra la documentación relacionada con el análisis, diseño y construcción de

las bases de datos.

(cid:224) También denominado:

* Metabase de datos.
* Repositorio.
* Enciclopedia.
* Directorio.
* Catálogo.



1.3.6 Tipos de diccionarios
• Dinámicos.

• Activos.

• Pasivos.


Están en línea con el motor de bases de datos y el sistema en producción.

Están en línea únicamente con las herramientas de desarrollo (CASE).

Están fuera de línea, utilizados sólo para documentación.

Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 6



1.3.7 Diccionarios estándar
• ANSI Information Resource Dictionary System (IRDS).
•
•
• DEC A tools Integration Standard (CDD+).

ISO IRDS.
IBM Repository (AD/Cycle).

Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 7

2. ANÁLISIS BÁSICO


• Modelo Entidad Relación de Peter Peen y Chan Chen.
• Case Designer de Barker.
• Nissjen’s Information Analysis Methodology (NIAM).
• Objects-oriented approaches.
• Ventajas del modelo Entidad Relación:

(cid:224) Cercano al lenguaje natural: una Entidad es como un Sustantivo, una Relación es como un Verbo

y un Atributo es como una frase proposicional. Esto hace que sea relativamente sencillo
convertir una entrevista en un modelo de datos.

(cid:224) La mayoría de las herramientas CASE lo han adoptado.



2.1 Entidades
• Entidad: Cualquier cosa de interés sobre la que podemos decir algo.

(cid:224) Persona.
(cid:224) Lugar.
(cid:224) Objeto.
(cid:224) Actividad.
(cid:224) Evento.

• Nombre de la Entidad: Escrito en mayúsculas.
• Tipo de Entidad: conjunto de cosas.
•
• Una Entidad generalmente se convierte en una tabla en el diseño de bases de datos relacionales.


Instancia de una Entidad: una cosa individual.

2.1.1 Descubrir y documentar Entidades:

E1

Identificar Entidades en las Entrevistas
• Las Entidades siempre son sustantivos, pero no todos los sustantivos son Entidades.
•

Ignore sustantivos que:

(cid:224) Se refieren a datos específicos.
(cid:224) No son significativos para el estudio.

• No confunda una forma, con la información contenida en ella.



E2 Clasificar la Entidades

Se hará más adelante.



E3 Determinar la llave primaria

• La llave primaria debe identificar de manera inequívoca una instancia de una entidad.
• Características obligatorias:

(cid:224) Valor único.
(cid:224) Valor siempre conocido.

• Características deseables:
(cid:224) Valor estable.
(cid:224) Valor controlado por el administrador de los datos.
(cid:224) Disponible para todos los usuarios.
(cid:224) Desprovisto de información descriptiva.

Documento en preparación.
Ing. Ismael Castañeda Fuentes

Página 8

• Si no encuentra una buena llave primaria, invéntese una.
• Si no la descubre:

(cid:224) Pregunte al usuario cómo identifica la Entidad.
(cid:224) Reconsidere la Entidad. Posiblemente no es una cosa sino corresponde a un dato o no

es importante en esa lugar de estudio o está pobre