4) Contenido
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View 4) Contenido as PDF for free.
More details
- Words: 3,528
- Pages: 19
10 de junio de 2009
BASE DE DATOS
1. Diseño de Bases de Datos El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información. ➢ ➢ ➢ ➢
Análisis. Diseño del modelo entidad / relación. Diseño del modelo relacional. Lenguaje SQL y base de datos final.
1.1.Análisis Debemos comenzar estudiando a fondo el mundo real que deseamos representar en la aplicación y base de datos. A partir de este estudio, debemos crear el UD, que es simplemente la visión del mundo real bajo unos determinados objetivos. 1.2.Modelo entidad / relación (E/R) El diseñador debe concebir la base de datos en un nivel superior, abstrayéndose de cualquier consideración técnica o de implementación en sistema, plataforma o aplicación. Para ello puede contar con la ayuda de un modelo de datos como el E/R, presentado por Peter P. Chen. Con él podrá centrarse en la estructura lógica y abstracta de la información, siendo capaz de representar toda la semántica del mundo real por medio de entidades y relaciones. 1.3.Modelo relacional El diseñador debe transformar el modelo E/R en el modelo relacional, teniendo muy en cuenta la teoría de la normalización. Esta es una operación de cierta complejidad. El modelo relacional, presentado por el Dr. E.F.Codd, fue revolucionario puesto que consigue la independencia de las aplicaciones respecto a los datos. Este modelo de datos está basado en las teorías matemáticas de las relaciones, haciendo que los datos se estructuren lógicamente en forma de relaciones -tablas. Presenta beneficios como:
➢ Sencillez y uniformidad: Al tener como resultado una colección de tablas, y ser la tabla la estructura básica se da como resultado una gran uniformidad, junto con la sencillez de los lenguajes de usuario que pueden operar con ellas. ➢ Flexibilidad: Ofreciendo a los usuarios los datos de la forma más adecuada a su aplicación. ➢ Independencia del interfaz de usuario: El modo en el que se almacena los datos no influye en su manipulación lógica. 1.4.Lenguaje SQL y base de datos final Ahora solamente tendremos que codificar en lenguaje SQL el modelo relacional expuesto anteriormente. Para ello necesitaremos de:
➢ LDD: Con el que (por ejemplo) codificar las sentencias para la creación de las distintas tablas de la base de datos.
➢ LMD: Para codificar las instrucciones (que por ejemplo) se encargarán de realizar:
1
10 de junio de 2009
BASE DE DATOS
Consultas, Adiciones, Eliminaciones de Registros.
2.
Diseño físico
El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en: ➢ ➢ ➢
3.
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas prestaciones óptimas. Diseñar el modelo de seguridad del sistema.
Diseño conceptual
En esta etapa se debe construir un esquema de la información que se usa en la empresa, independientemente de cualquier consideración física. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El objetivo es comprender: ➢
La perspectiva que cada usuario tiene de los datos.
➢
La naturaleza de los datos, independientemente de su representación física.
➢
El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita a la empresa lo que ha entendido sobre la información que ésta maneja. Para ello, ambas partes deben estar familiarizadas con la notación utilizada en el esquema. La más popular es la notación del modelo entidad-relación, que se describirá en el capítulo dedicado al diseño conceptual.
4.
Diseño lógico
El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física. En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va probando y validando con los requisitos de usuario. La normalización es una técnica que se utiliza para comprobar la validez de los esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico de bases de datos.
5. Características de una base de datos ➢ ➢
La velocidad de acceso, El tamaño de la información,
2
10 de junio de 2009
BASE DE DATOS
El tipo de la información, Facilidad de acceso a la información, Facilidad para extraer la información requerida, ➢ El comportamiento del manejador de bases de datos con cada tipo de información. ➢ ➢ ➢
6. Objetivos del Diseño de la Base de Datos Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.
7. Almacenar Solo La Información Necesaria Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
7.1. Normalizar la Estructura de las Tablas Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de celdas vacías. El concepto relacional, significa que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común. Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías".
3
10 de junio de 2009
BASE DE DATOS
Podríamos decir que estos son los principales objetivos de la normalización: ➢ ➢ ➢ ➢
Controlar la redundancia de la información. Evitar pérdidas de información. Capacidad para representar toda la información. Mantener la consistencia de los datos.
7.2.Seleccionar el Tipo de Dato Adecuado Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos: ➢ Texto ➢ Números ➢ Fecha y hora Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos. A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:
➢ Identificar si una columna debe ser de tipo texto, numérico o de fecha. ➢ Elegir el subtipo más apropiado para cada columna. ➢ Configurar la longitud máxima para las columnas de texto y numéricas, así como otros atributos. 7.3.Utilizar Índices Apropiadamente Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, SQL tiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos. De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas. 7.4.Usar Consultas REPLACE Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos.
4
10 de junio de 2009
BASE DE DATOS
7.5.Usar Una Versión Reciente de SQL La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de SQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en SQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos. 7.6.Usar Tablas Temporales. Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que SQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla. Una tabla temporal existe mientras dure la conexión a SQL. Cuando se interrumpe la conexión SQL remueve automáticamente la tabla y libera el espacio que ésta usaba.
5
10 de junio de 2009
BASE DE DATOS
8. Normalización Normalizar es reconocer cualidades no deseadas en una tabla y la forma de corregirla. Características: • Cualidades no deseadas • Evitar redundancia de información pero sin perderla Existen dos formas para normalizar:
1. Enfoque intuitivo 2. Metodología.- Dependencia funcional
Dependencia Funcional La dependencia funcional se da cuando hay tablas El atributo A es funcionalmente dependiente del atributo B, si el valor de A está determinado por el valor de B.
Para la tabla Ciudades, que tenia 2 campos, hemos creado el DIAGRAMA DE DEPENDENCIAS FUNCIONALES Valor de Columna de Valor de Columna de Tabla CIUDAD Tabla CIUDAD (DETERMINA PK) Id_ciudad_edit nombre_ciudad_edit B
Para la tabla Editoriales, que tenia DE DEPENDENCIAS FUNCIONALES Valor de Columna de Tabla EDITORIAL (DETERMINA PK)
A
4 campos, hemos creado el DIAGRAMA Valor de Columna de Tabla EDITORIAL
Valor de Column a de
Valor de Columna de Tabla EDITORIAL
6
10 de junio de 2009
BASE DE DATOS
Id_edit
nombre_edit,
B
A,B,C
Tabla EDITOR IAL direc_ed it,
id_ciudad_e dit
Tabla: Ciudades id_ciudad_edit ( PK)
nombre_ciudad_edit
02 04 07
Cuenca Guayaquil Quito
MODELO CORREGIDO Y NORMALIZADO
*debe asignarse * debe publicar Debe ser creado
debe tener asignada
MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS id_libr Titul Edicion tipo_lib o o ro NN PK NN NN 001 A Primera Ciencia F 002 B Segund Terror a 003 C Primera Drama 004 Nach Quinta Enseñan o Lee za 1
id_e dit
nombre_ edit
Direc_e dit
id_ciud_ed it
nomb_ciud_ edit
101
LNS
M. Aux
02
Cuenca
102
Don Bosco Xxx
04
Guayaquil
103 101
Norma LNS
07 02
Quito Cuenca
Yyy M. Aux
7
10 de junio de 2009 005
BASE DE DATOS
Nach Segund o Lee a 2
Enseñan 101 za
LNS
M. Aux
02
Cuenca
09
Ambato
Se debe realizar un diagrama de Dependencias Funcionales (LO PRIMERO ES QUE DEBO HACER ES VERIFICAR QUE “CAMPOS SERIAN DETERMINANTES, SERIA PK”
LUEGO INICIO EL Proceso de Normalización:
1FN
2FN
3FN
4FN
Problemas o Anomalías –
Inserción
–
Actualización
–
Eliminación
Dependencia Multi valorada (DMV)
Solución para el Proceso de Normalización:
Atributos Clave (PK) Atributos NO Clave (normales y los FK) Crear nuevas tablas y que sus columnas no clave dependan total y funcionalmente únicamente de su clave primaria.
(1FN) Primera Forma Normal
Está en primera forma normal cuando los valores para los campos o columnas, en un registro o fila de una tabla, TIENEN UN SOLO VALOR.
Ej.:
Tabla: LIBROS se encuentra en 1FN
8
10 de junio de 2009
BASE DE DATOS
id_libr titul o o 001 A 002
B
003
C
edición tipo_lib ro Primera Ciencia F Segund Terror a Primera Drama
id_e dit 101
nombre_ edit LNS
Direc_e dit zzz
102
Don Bosco xxx
04
Guayaquil
103
Norma
07
Cuenca
yyy
id_ciud_edi nomb_ciud_ t edit 02 Quito
Anomalías de inserción en 1FN. Algunas anomalías de inserción se deben a la dependencia funcional de algunos campos no clave en un subconjunto de atributos de la clave principal en lugar de toda la clave primaria. Anomalías en la eliminación en 1FN. Esto sucede cuando se desea borrar el valor de un campo, y al hacer esto no se puede borrar sólo ese valor sino que se debe borrar todo el registro, y es donde aparece esta anomalía debido a que se puede borrar información importante de una relación. Anomalías de actualización en 1FN. Cuando una relación sin normalizar se convierte en una relación 1FN, algunos datos se duplican. Tal duplicidad de datos almacenados causará problemas en las operaciones de actualización Y ADEMAS GENERARÁ INCONSISTENCIAS O ERRORES EN LOS DATOS.
(2FN)Segunda Forma Normal Si esta en primera forma normal y cada atributo no clave depende totalmente de su clave principal. Ej.: Anomalías de relaciones en 2FN Puede presentar anomalías de almacenamiento si cualquiera de sus atributos no clave depende transitivamente de la clave primaria, es decir depende indirectamente de la clave primaria. Ej.:
9
10 de junio de 2009
BASE DE DATOS
Tabla: LIBROS, está en 1FN, está en 2 FN id_libr titul o o 001 A 002
B
003
C
edición tipo_lib ro Primera Ciencia F Segund Terror a Primera Drama
id_e dit 101 102 103
Tabla: EDITORIALES, está en 1FN, está en 2FN id_e dit
nombre_ edit
Direc_e dit
PK 101 102 103
LNS zzz Don Bosco xxx Norma yyy
id_ciud_ed it
nomb_ciud_ edit
02 04 07
Quito Guayaquil Cuenca
Id_edit ----> nombre_edit, Direc_edit, id_ciud_edit, nomb_ciud_edit (3FN) Tercera Forma Normal Una relación es tercera forma normal si es 2FN y un atributo no clave YA NO ES funcionalmente dependiente de algún otro atributo no clave. Ej.:
Tabla: LIBROS, está en 1FN, 2FN y 3FN id_li bro `PK 001 002 003
t Id_edicion ID_tipo_ itul _libro libro o FK FK A 001 001 B 002 002 C 003 003
id_e dit FK 101 102 103
Tabla: TIPO_LIBROS, está en 1FN, 2FN y 3FN id_TIPO _libro PK 001 002 003
tipo_l ibro Cienci aF Terror Dram a
10
10 de junio de 2009
BASE DE DATOS
Tabla: EDICION_LIBROS, está en 1FN, 2FN y 3FN id_edicio edic n_libro ión PK 001
Prim era Segu nda Prim era
002 003
Tabla: EDITORIALES, está en 1FN, 2FN y 3FN
id_e dit
nombre_ edit
Direc_e dit
PK 101 102 103
LNS zzz Don Bosco xxx Norma yyy
id_ciud_ed it FK 02 04 07
Tabla: CIUDADES, está en 1FN, 2FN y 3FN id_ciud_ed it
nomb_ciud_ edit
PK 02 Quito 04 Guayaquil 07 Cuenca Anomalías debidas a dependencia de valores múltiples. Generalmente un proceso de normalización termina cuando todas las relaciones pertenecen a tercera forma normal. Sin embargo, si una relación contiene dependencias de valores múltiples, es necesaria una normalización posterior. Dada una relación, el atributo A de esta relación se dice ser dependiente de multi valuados (DMV) del atributo B si un rango específico de valores del atributo A está determinado por un valor particular de B. (4FN) Cuarta Forma Normal Una relación es 4FN si es 3FN y no contiene dependencias multi valoradas. La dependencia multi valuada se denota X
Y, y se lee X multi determina a Y.
11
10 de junio de 2009
BASE DE DATOS
9. Proceso de Análisis y Diseño de la Base de Datos 9.1. Identificación de Entidades: En el proceso de identificación de entidades se tiene que obtener las entidades principales que intervienen en los procesos que lleve a cabo la empresa, para esto se tiene que realizar un análisis previo del trabajo que lleva a cabo la empresa y cada una de sus áreas. Realizado un análisis previo de la empresa IMPORCOMPU S.A. se ha identificado las siguientes entidades principales: ➢ ➢ ➢ ➢ ➢
Clientes Productos Proveedores Empleados Factura
9.2. Modelo Entidad – Relación: En esta parte se realizara el esquema previo de las relaciones que lleva cada una de las entidades tomando en cuenta su función dentro de la empresa. Realizando un seguimiento previo del funcionamiento de la empresa se ha llegado a la conclusión de las siguientes relaciones que tiene cada una de las entidades identificadas previamente.
9.3. Proceso de Normalización: En el proceso de normalización analizaremos cada una de las entidades principales elaborando sus tablas y los campos correspondientes para luego primeramente identificar la dependencia funcional de cada uno de sus campos y comenzar el proceso de normalizado ya descrito en la parte anterior del documento.
Clientes Cod_Cliente 12
10 de junio de 2009
BASE DE DATOS
Cod_Descuento Cedula_RUC Nombres Apellidos Direccion e-mail Telefono_Conven sional Telefono_Celular Empleados Cedula_Empleado Nombres Apellidos Direccion e-mail Fecha_Nacimiento Genero Fecha_Ingreso Sueldo_Mensual Productos Cod_Producto Tipo Marca Modelo Descripcion Cantidad Precio_Compra Precio_Venta
Proveedores Prov_RUC Empresa Encargad o Ciudad Direccion
13
10 de junio de 2009
BASE DE DATOS
Factura Factura_Num Cod_Cliente Subtotal Cod_Impuesto Descuento Impuesto Total Cedula_Emplead o En las tablas anteriores se identificado los datos principales que deben llevar las tablas expuestas, estas tablas han sido analizadas y se les a dado un campo el cual va identificar a varios de los datos expuestos en los registros, aplicando así el proceso de dependencia funcional. Siguiendo el proceso de normalización se ha llevado a cabo la extracción de campos los cuales almacenaran información adicional y necesaria para la base de datos.
Cargos Cod_Cargo Cargo Empleados_Cargos Cod_Cargo Cedula_Emplead o Empleados_Telefonos Cedula_Emplead o Telefono Personal Cod_Personal Tipo_Personal
Cliente_Descuentos Cod_Descuento Descuento_Ocacio nal Descuento_Frecue nte Facturas_Descripcion 14
10 de junio de 2009
BASE DE DATOS
Factura_Nu m Cod_Product o Cantidad Decripcion Valor_Unitari o Valor_Total Facturas_Impuestos Cod_Impuest o Impuesto Productos_Proveedo res Cod_Product o Prov_RUC Proveedores_Fax Prov_RUC Fax Proveedores_Telefon os Prov_RUC Telefono Tipo_Personal Cod_Personal Cedula_Emplead o
9.4. Descripción de Tablas: En este paso se mostrara todas las tablas identificadas y normalizadas con sus respectivos campos definidos con CONSTRAINT – NOMBRE – TIPO DE DATO – LONGITUD.
15
10 de junio de 2009
BASE DE DATOS
FACTURA CONSTRAIN T NN-FK NN-FK NN NN-FK NN NN NN NN-FK
NOMBRE Factura_Num Cod_Cliente Subtotal Cod_Impuesto Descuento Impuesto Total Cedula_Empleado
TIPO DE DATO Numeric Numeric Money Char Money Money Money Nchar
FACTURA DESCRIPCION CONSTRAINT NOMBRE TIPO DE DATO NN-PK-UK Factura_Num Numeric NN-FK Cod_Producto Numeric NN Cantidad Numeric Descripcion Char NN Valor_Unitario Money NN Valor_Total Money
LONGITU D [5,0] [3,0] [5]
[10]
LONGITUD [5,0] [4,0] [3,0] [50]
FACTURA IMPUESTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Impuesto Char [5,0] NN Impuesto Money EMPLEADOS CONSTRAIN T NN-PK-UK NN NN NN NN-UN NN NN NN NN
NOMBRE Cedula_Empleado Nombre Apellido Direccion e-mail Fecha de Nacimiento Genero Fecha_Ingreso Sueldo_Mensual
TIPO DE DATO Nchar Char Char Char Char Date/Time Char Date/Time Money
EMPLEADOS_TELEFONOS CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cedula_Empleado Nchar NN Telefono Nchar
LONGITU D [10] [25] [25] [40] [20] [1]
LONGITU D [10] [9] 16
10 de junio de 2009
BASE DE DATOS
TIPO_PERSONAL CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cod_Personal Nchar NN-FK Cedula_Empleado Nchar
LONGITU D [2] [10]
TIPO_PERSONAL CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Personal Nchar [2] NN-UK Tipo_Personal Nchar [15] EMPLEADOS_CARGO CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cod_Cargo Char NN-FK Cedula_Empleado Nchar
LONGITU D [20] [10]
EMPLEADOS_CARGO NOMBRE TIPO DE DATO Cod_Cargo Char Cargo Nchar
LONGITUD [20] [20]
CONSTRAINT NN-PK-UK NN-UK
CLIENTES CONSTRAIN T NN-PK-UK NN-FK NN-UK NN NN NN
NOMBRE Cod_Cliente Cod_Descuento Cedula/RUC Nombre Apellido Direccion e-mail Telefono_Convencional Telefono_Celular
TIPO DE DATO Numeric Nchar Nchar Char Char Char Char Numeric Numeric
LONGITU D [3,0] [2] [13] [25] [25] [40] [30] [9,0] [9,0]
CLIENTES_DESCUENTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Descuento Nchar [2] NN Descuento Money
17
10 de junio de 2009
BASE DE DATOS
PRODUCTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Producto Numeric [4,0] NN Tipo Char [20] NN Marca Char [15] NN Modelo Char [20] NN Descripcion Char [50] NN Cantidad Numeric [3,0] NN Precio_Compra Money NN Precio_Venta Money PRODUCTOS_PROVEEDORES CONSTRAINT NOMBRE TIPO DE DATO NN-FK Cod_Producto Numeric NN-FK Prov_RUC Nchar
LONGITUD [4,0] [13]
CONSTRAINT NN-PK-UK NN NN NN NN
PROVEEDORES NOMBRE TIPO DE DATO Prov_RUC Nchar Empresa Char Encargado Char Ciudad Char Direccion Char
LONGITUD [4,0] [13] [15] [20] [50]
CONSTRAINT NN-FK NN
PROVEEDORES NOMBRE TIPO DE DATO Prov_RUC Nchar Fax Nchar
LONGITUD [13] [9]
PROVEEDORES CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-FK Prov_RUC Nchar [13] NN Telefono Nchar [13] 9.5. Modelo Relacional: El modelo relacional trata del esquema o diagrama realizado en un programa diseñador o modelador de base de datos el cual nos mostrara las tablas con sus principales campos y relaciones, mostrándonos como la base de datos quedara finalmente al momento de trasladarlo a un sistema gestor de base de datos.
18
10 de junio de 2009
BASE DE DATOS
19
BASE DE DATOS
1. Diseño de Bases de Datos El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información. ➢ ➢ ➢ ➢
Análisis. Diseño del modelo entidad / relación. Diseño del modelo relacional. Lenguaje SQL y base de datos final.
1.1.Análisis Debemos comenzar estudiando a fondo el mundo real que deseamos representar en la aplicación y base de datos. A partir de este estudio, debemos crear el UD, que es simplemente la visión del mundo real bajo unos determinados objetivos. 1.2.Modelo entidad / relación (E/R) El diseñador debe concebir la base de datos en un nivel superior, abstrayéndose de cualquier consideración técnica o de implementación en sistema, plataforma o aplicación. Para ello puede contar con la ayuda de un modelo de datos como el E/R, presentado por Peter P. Chen. Con él podrá centrarse en la estructura lógica y abstracta de la información, siendo capaz de representar toda la semántica del mundo real por medio de entidades y relaciones. 1.3.Modelo relacional El diseñador debe transformar el modelo E/R en el modelo relacional, teniendo muy en cuenta la teoría de la normalización. Esta es una operación de cierta complejidad. El modelo relacional, presentado por el Dr. E.F.Codd, fue revolucionario puesto que consigue la independencia de las aplicaciones respecto a los datos. Este modelo de datos está basado en las teorías matemáticas de las relaciones, haciendo que los datos se estructuren lógicamente en forma de relaciones -tablas. Presenta beneficios como:
➢ Sencillez y uniformidad: Al tener como resultado una colección de tablas, y ser la tabla la estructura básica se da como resultado una gran uniformidad, junto con la sencillez de los lenguajes de usuario que pueden operar con ellas. ➢ Flexibilidad: Ofreciendo a los usuarios los datos de la forma más adecuada a su aplicación. ➢ Independencia del interfaz de usuario: El modo en el que se almacena los datos no influye en su manipulación lógica. 1.4.Lenguaje SQL y base de datos final Ahora solamente tendremos que codificar en lenguaje SQL el modelo relacional expuesto anteriormente. Para ello necesitaremos de:
➢ LDD: Con el que (por ejemplo) codificar las sentencias para la creación de las distintas tablas de la base de datos.
➢ LMD: Para codificar las instrucciones (que por ejemplo) se encargarán de realizar:
1
10 de junio de 2009
BASE DE DATOS
Consultas, Adiciones, Eliminaciones de Registros.
2.
Diseño físico
El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en: ➢ ➢ ➢
3.
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas prestaciones óptimas. Diseñar el modelo de seguridad del sistema.
Diseño conceptual
En esta etapa se debe construir un esquema de la información que se usa en la empresa, independientemente de cualquier consideración física. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El objetivo es comprender: ➢
La perspectiva que cada usuario tiene de los datos.
➢
La naturaleza de los datos, independientemente de su representación física.
➢
El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita a la empresa lo que ha entendido sobre la información que ésta maneja. Para ello, ambas partes deben estar familiarizadas con la notación utilizada en el esquema. La más popular es la notación del modelo entidad-relación, que se describirá en el capítulo dedicado al diseño conceptual.
4.
Diseño lógico
El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física. En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va probando y validando con los requisitos de usuario. La normalización es una técnica que se utiliza para comprobar la validez de los esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico de bases de datos.
5. Características de una base de datos ➢ ➢
La velocidad de acceso, El tamaño de la información,
2
10 de junio de 2009
BASE DE DATOS
El tipo de la información, Facilidad de acceso a la información, Facilidad para extraer la información requerida, ➢ El comportamiento del manejador de bases de datos con cada tipo de información. ➢ ➢ ➢
6. Objetivos del Diseño de la Base de Datos Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.
7. Almacenar Solo La Información Necesaria Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
7.1. Normalizar la Estructura de las Tablas Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de celdas vacías. El concepto relacional, significa que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común. Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías".
3
10 de junio de 2009
BASE DE DATOS
Podríamos decir que estos son los principales objetivos de la normalización: ➢ ➢ ➢ ➢
Controlar la redundancia de la información. Evitar pérdidas de información. Capacidad para representar toda la información. Mantener la consistencia de los datos.
7.2.Seleccionar el Tipo de Dato Adecuado Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos: ➢ Texto ➢ Números ➢ Fecha y hora Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos. A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:
➢ Identificar si una columna debe ser de tipo texto, numérico o de fecha. ➢ Elegir el subtipo más apropiado para cada columna. ➢ Configurar la longitud máxima para las columnas de texto y numéricas, así como otros atributos. 7.3.Utilizar Índices Apropiadamente Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, SQL tiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos. De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas. 7.4.Usar Consultas REPLACE Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos.
4
10 de junio de 2009
BASE DE DATOS
7.5.Usar Una Versión Reciente de SQL La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de SQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en SQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos. 7.6.Usar Tablas Temporales. Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que SQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla. Una tabla temporal existe mientras dure la conexión a SQL. Cuando se interrumpe la conexión SQL remueve automáticamente la tabla y libera el espacio que ésta usaba.
5
10 de junio de 2009
BASE DE DATOS
8. Normalización Normalizar es reconocer cualidades no deseadas en una tabla y la forma de corregirla. Características: • Cualidades no deseadas • Evitar redundancia de información pero sin perderla Existen dos formas para normalizar:
1. Enfoque intuitivo 2. Metodología.- Dependencia funcional
Dependencia Funcional La dependencia funcional se da cuando hay tablas El atributo A es funcionalmente dependiente del atributo B, si el valor de A está determinado por el valor de B.
Para la tabla Ciudades, que tenia 2 campos, hemos creado el DIAGRAMA DE DEPENDENCIAS FUNCIONALES Valor de Columna de Valor de Columna de Tabla CIUDAD Tabla CIUDAD (DETERMINA PK) Id_ciudad_edit nombre_ciudad_edit B
Para la tabla Editoriales, que tenia DE DEPENDENCIAS FUNCIONALES Valor de Columna de Tabla EDITORIAL (DETERMINA PK)
A
4 campos, hemos creado el DIAGRAMA Valor de Columna de Tabla EDITORIAL
Valor de Column a de
Valor de Columna de Tabla EDITORIAL
6
10 de junio de 2009
BASE DE DATOS
Id_edit
nombre_edit,
B
A,B,C
Tabla EDITOR IAL direc_ed it,
id_ciudad_e dit
Tabla: Ciudades id_ciudad_edit ( PK)
nombre_ciudad_edit
02 04 07
Cuenca Guayaquil Quito
MODELO CORREGIDO Y NORMALIZADO
*debe asignarse * debe publicar Debe ser creado
debe tener asignada
MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS id_libr Titul Edicion tipo_lib o o ro NN PK NN NN 001 A Primera Ciencia F 002 B Segund Terror a 003 C Primera Drama 004 Nach Quinta Enseñan o Lee za 1
id_e dit
nombre_ edit
Direc_e dit
id_ciud_ed it
nomb_ciud_ edit
101
LNS
M. Aux
02
Cuenca
102
Don Bosco Xxx
04
Guayaquil
103 101
Norma LNS
07 02
Quito Cuenca
Yyy M. Aux
7
10 de junio de 2009 005
BASE DE DATOS
Nach Segund o Lee a 2
Enseñan 101 za
LNS
M. Aux
02
Cuenca
09
Ambato
Se debe realizar un diagrama de Dependencias Funcionales (LO PRIMERO ES QUE DEBO HACER ES VERIFICAR QUE “CAMPOS SERIAN DETERMINANTES, SERIA PK”
LUEGO INICIO EL Proceso de Normalización:
1FN
2FN
3FN
4FN
Problemas o Anomalías –
Inserción
–
Actualización
–
Eliminación
Dependencia Multi valorada (DMV)
Solución para el Proceso de Normalización:
Atributos Clave (PK) Atributos NO Clave (normales y los FK) Crear nuevas tablas y que sus columnas no clave dependan total y funcionalmente únicamente de su clave primaria.
(1FN) Primera Forma Normal
Está en primera forma normal cuando los valores para los campos o columnas, en un registro o fila de una tabla, TIENEN UN SOLO VALOR.
Ej.:
Tabla: LIBROS se encuentra en 1FN
8
10 de junio de 2009
BASE DE DATOS
id_libr titul o o 001 A 002
B
003
C
edición tipo_lib ro Primera Ciencia F Segund Terror a Primera Drama
id_e dit 101
nombre_ edit LNS
Direc_e dit zzz
102
Don Bosco xxx
04
Guayaquil
103
Norma
07
Cuenca
yyy
id_ciud_edi nomb_ciud_ t edit 02 Quito
Anomalías de inserción en 1FN. Algunas anomalías de inserción se deben a la dependencia funcional de algunos campos no clave en un subconjunto de atributos de la clave principal en lugar de toda la clave primaria. Anomalías en la eliminación en 1FN. Esto sucede cuando se desea borrar el valor de un campo, y al hacer esto no se puede borrar sólo ese valor sino que se debe borrar todo el registro, y es donde aparece esta anomalía debido a que se puede borrar información importante de una relación. Anomalías de actualización en 1FN. Cuando una relación sin normalizar se convierte en una relación 1FN, algunos datos se duplican. Tal duplicidad de datos almacenados causará problemas en las operaciones de actualización Y ADEMAS GENERARÁ INCONSISTENCIAS O ERRORES EN LOS DATOS.
(2FN)Segunda Forma Normal Si esta en primera forma normal y cada atributo no clave depende totalmente de su clave principal. Ej.: Anomalías de relaciones en 2FN Puede presentar anomalías de almacenamiento si cualquiera de sus atributos no clave depende transitivamente de la clave primaria, es decir depende indirectamente de la clave primaria. Ej.:
9
10 de junio de 2009
BASE DE DATOS
Tabla: LIBROS, está en 1FN, está en 2 FN id_libr titul o o 001 A 002
B
003
C
edición tipo_lib ro Primera Ciencia F Segund Terror a Primera Drama
id_e dit 101 102 103
Tabla: EDITORIALES, está en 1FN, está en 2FN id_e dit
nombre_ edit
Direc_e dit
PK 101 102 103
LNS zzz Don Bosco xxx Norma yyy
id_ciud_ed it
nomb_ciud_ edit
02 04 07
Quito Guayaquil Cuenca
Id_edit ----> nombre_edit, Direc_edit, id_ciud_edit, nomb_ciud_edit (3FN) Tercera Forma Normal Una relación es tercera forma normal si es 2FN y un atributo no clave YA NO ES funcionalmente dependiente de algún otro atributo no clave. Ej.:
Tabla: LIBROS, está en 1FN, 2FN y 3FN id_li bro `PK 001 002 003
t Id_edicion ID_tipo_ itul _libro libro o FK FK A 001 001 B 002 002 C 003 003
id_e dit FK 101 102 103
Tabla: TIPO_LIBROS, está en 1FN, 2FN y 3FN id_TIPO _libro PK 001 002 003
tipo_l ibro Cienci aF Terror Dram a
10
10 de junio de 2009
BASE DE DATOS
Tabla: EDICION_LIBROS, está en 1FN, 2FN y 3FN id_edicio edic n_libro ión PK 001
Prim era Segu nda Prim era
002 003
Tabla: EDITORIALES, está en 1FN, 2FN y 3FN
id_e dit
nombre_ edit
Direc_e dit
PK 101 102 103
LNS zzz Don Bosco xxx Norma yyy
id_ciud_ed it FK 02 04 07
Tabla: CIUDADES, está en 1FN, 2FN y 3FN id_ciud_ed it
nomb_ciud_ edit
PK 02 Quito 04 Guayaquil 07 Cuenca Anomalías debidas a dependencia de valores múltiples. Generalmente un proceso de normalización termina cuando todas las relaciones pertenecen a tercera forma normal. Sin embargo, si una relación contiene dependencias de valores múltiples, es necesaria una normalización posterior. Dada una relación, el atributo A de esta relación se dice ser dependiente de multi valuados (DMV) del atributo B si un rango específico de valores del atributo A está determinado por un valor particular de B. (4FN) Cuarta Forma Normal Una relación es 4FN si es 3FN y no contiene dependencias multi valoradas. La dependencia multi valuada se denota X
Y, y se lee X multi determina a Y.
11
10 de junio de 2009
BASE DE DATOS
9. Proceso de Análisis y Diseño de la Base de Datos 9.1. Identificación de Entidades: En el proceso de identificación de entidades se tiene que obtener las entidades principales que intervienen en los procesos que lleve a cabo la empresa, para esto se tiene que realizar un análisis previo del trabajo que lleva a cabo la empresa y cada una de sus áreas. Realizado un análisis previo de la empresa IMPORCOMPU S.A. se ha identificado las siguientes entidades principales: ➢ ➢ ➢ ➢ ➢
Clientes Productos Proveedores Empleados Factura
9.2. Modelo Entidad – Relación: En esta parte se realizara el esquema previo de las relaciones que lleva cada una de las entidades tomando en cuenta su función dentro de la empresa. Realizando un seguimiento previo del funcionamiento de la empresa se ha llegado a la conclusión de las siguientes relaciones que tiene cada una de las entidades identificadas previamente.
9.3. Proceso de Normalización: En el proceso de normalización analizaremos cada una de las entidades principales elaborando sus tablas y los campos correspondientes para luego primeramente identificar la dependencia funcional de cada uno de sus campos y comenzar el proceso de normalizado ya descrito en la parte anterior del documento.
Clientes Cod_Cliente 12
10 de junio de 2009
BASE DE DATOS
Cod_Descuento Cedula_RUC Nombres Apellidos Direccion e-mail Telefono_Conven sional Telefono_Celular Empleados Cedula_Empleado Nombres Apellidos Direccion e-mail Fecha_Nacimiento Genero Fecha_Ingreso Sueldo_Mensual Productos Cod_Producto Tipo Marca Modelo Descripcion Cantidad Precio_Compra Precio_Venta
Proveedores Prov_RUC Empresa Encargad o Ciudad Direccion
13
10 de junio de 2009
BASE DE DATOS
Factura Factura_Num Cod_Cliente Subtotal Cod_Impuesto Descuento Impuesto Total Cedula_Emplead o En las tablas anteriores se identificado los datos principales que deben llevar las tablas expuestas, estas tablas han sido analizadas y se les a dado un campo el cual va identificar a varios de los datos expuestos en los registros, aplicando así el proceso de dependencia funcional. Siguiendo el proceso de normalización se ha llevado a cabo la extracción de campos los cuales almacenaran información adicional y necesaria para la base de datos.
Cargos Cod_Cargo Cargo Empleados_Cargos Cod_Cargo Cedula_Emplead o Empleados_Telefonos Cedula_Emplead o Telefono Personal Cod_Personal Tipo_Personal
Cliente_Descuentos Cod_Descuento Descuento_Ocacio nal Descuento_Frecue nte Facturas_Descripcion 14
10 de junio de 2009
BASE DE DATOS
Factura_Nu m Cod_Product o Cantidad Decripcion Valor_Unitari o Valor_Total Facturas_Impuestos Cod_Impuest o Impuesto Productos_Proveedo res Cod_Product o Prov_RUC Proveedores_Fax Prov_RUC Fax Proveedores_Telefon os Prov_RUC Telefono Tipo_Personal Cod_Personal Cedula_Emplead o
9.4. Descripción de Tablas: En este paso se mostrara todas las tablas identificadas y normalizadas con sus respectivos campos definidos con CONSTRAINT – NOMBRE – TIPO DE DATO – LONGITUD.
15
10 de junio de 2009
BASE DE DATOS
FACTURA CONSTRAIN T NN-FK NN-FK NN NN-FK NN NN NN NN-FK
NOMBRE Factura_Num Cod_Cliente Subtotal Cod_Impuesto Descuento Impuesto Total Cedula_Empleado
TIPO DE DATO Numeric Numeric Money Char Money Money Money Nchar
FACTURA DESCRIPCION CONSTRAINT NOMBRE TIPO DE DATO NN-PK-UK Factura_Num Numeric NN-FK Cod_Producto Numeric NN Cantidad Numeric Descripcion Char NN Valor_Unitario Money NN Valor_Total Money
LONGITU D [5,0] [3,0] [5]
[10]
LONGITUD [5,0] [4,0] [3,0] [50]
FACTURA IMPUESTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Impuesto Char [5,0] NN Impuesto Money EMPLEADOS CONSTRAIN T NN-PK-UK NN NN NN NN-UN NN NN NN NN
NOMBRE Cedula_Empleado Nombre Apellido Direccion e-mail Fecha de Nacimiento Genero Fecha_Ingreso Sueldo_Mensual
TIPO DE DATO Nchar Char Char Char Char Date/Time Char Date/Time Money
EMPLEADOS_TELEFONOS CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cedula_Empleado Nchar NN Telefono Nchar
LONGITU D [10] [25] [25] [40] [20] [1]
LONGITU D [10] [9] 16
10 de junio de 2009
BASE DE DATOS
TIPO_PERSONAL CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cod_Personal Nchar NN-FK Cedula_Empleado Nchar
LONGITU D [2] [10]
TIPO_PERSONAL CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Personal Nchar [2] NN-UK Tipo_Personal Nchar [15] EMPLEADOS_CARGO CONSTRAIN TIPO DE T NOMBRE DATO NN-FK Cod_Cargo Char NN-FK Cedula_Empleado Nchar
LONGITU D [20] [10]
EMPLEADOS_CARGO NOMBRE TIPO DE DATO Cod_Cargo Char Cargo Nchar
LONGITUD [20] [20]
CONSTRAINT NN-PK-UK NN-UK
CLIENTES CONSTRAIN T NN-PK-UK NN-FK NN-UK NN NN NN
NOMBRE Cod_Cliente Cod_Descuento Cedula/RUC Nombre Apellido Direccion e-mail Telefono_Convencional Telefono_Celular
TIPO DE DATO Numeric Nchar Nchar Char Char Char Char Numeric Numeric
LONGITU D [3,0] [2] [13] [25] [25] [40] [30] [9,0] [9,0]
CLIENTES_DESCUENTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Descuento Nchar [2] NN Descuento Money
17
10 de junio de 2009
BASE DE DATOS
PRODUCTOS CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-PK-UK Cod_Producto Numeric [4,0] NN Tipo Char [20] NN Marca Char [15] NN Modelo Char [20] NN Descripcion Char [50] NN Cantidad Numeric [3,0] NN Precio_Compra Money NN Precio_Venta Money PRODUCTOS_PROVEEDORES CONSTRAINT NOMBRE TIPO DE DATO NN-FK Cod_Producto Numeric NN-FK Prov_RUC Nchar
LONGITUD [4,0] [13]
CONSTRAINT NN-PK-UK NN NN NN NN
PROVEEDORES NOMBRE TIPO DE DATO Prov_RUC Nchar Empresa Char Encargado Char Ciudad Char Direccion Char
LONGITUD [4,0] [13] [15] [20] [50]
CONSTRAINT NN-FK NN
PROVEEDORES NOMBRE TIPO DE DATO Prov_RUC Nchar Fax Nchar
LONGITUD [13] [9]
PROVEEDORES CONSTRAINT NOMBRE TIPO DE DATO LONGITUD NN-FK Prov_RUC Nchar [13] NN Telefono Nchar [13] 9.5. Modelo Relacional: El modelo relacional trata del esquema o diagrama realizado en un programa diseñador o modelador de base de datos el cual nos mostrara las tablas con sus principales campos y relaciones, mostrándonos como la base de datos quedara finalmente al momento de trasladarlo a un sistema gestor de base de datos.
18
10 de junio de 2009
BASE DE DATOS
19
