ANALISIS DE BASE DE DATOS

Diseo de Base Datos

En la siguiente Base de Datos presentamos hasta cuantas formas de normalizacin se puede utilizar para realizar una Base de Datos completa. Adrian Abad Luis Orden Pablo Serrano Christian Sarmiento 10/06/2009

ANALISIS DE BASE DE DATOS

10 de jun.

ndice de Contenidos
1. Diseo de Bases de Datos Anlisis Modelo entidad / relacin (E/R) Modelo relacional Lenguaje SQL y base de datos final Diseo fsico Diseo conceptual Diseo lgico

2. 3. 4. 5. 6. 7.

Caractersticas de una base de datos Objetivos del Diseo de la Base de Datos Almacenar Solo La Informacin Necesaria. Normalizar la Estructura de las Tablas Seleccionar el Tipo de Dato Adecuado Utilizar ndices Apropiadamente 8. Normalizacin

ANALISIS DE BASE DE DATOS

10 de jun.

INTRODUCCIN En la actualidad en cada una de la empresas tanto grande o pequea se manejan gran cantidad de datos. Por eso cada uno de los propietarios deben conocer la importancia de las bases de datos como aplicacin profesional para el manejo de la informacin, al pasar por alto la utilizacin de bases de datos esto podra ser el causa por la cual no se pueda acceder en la totalidad a los datos que lleva a cabo una empresa y esto causara la prdida de tiempo y dinero. Para la creacin de una base de datos debemos pasar antes por una etapa crucial y muy compleja la cual se denomina Diseo de Base de la Base de Datos, sin importar los datos que esta empresa maneje nuestra base de datos deber ser correctamente diseada para que sea utilizada en un futuro sin problema alguno. Vamos a llevar a cabo el anlisis y diseo de una base de datos de la empresa librera MONSALVE, cual se dedica a la ventas, distribucin de material didctico.

ANALISIS DE BASE DE DATOS

10 de jun. 1. Diseo de Bases de Datos

El objetivo principal del diseo de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra informacin. Anlisis. Diseo del modelo entidad / relacin. Diseo del modelo relacional. Lenguaje SQL y base de datos final.

Anlisis Debemos comenzar estudiando a fondo el mundo real que deseamos representar en la aplicacin y base de datos. A partir de este estudio, debemos crear el UD, que es simplemente la visin del mundo real bajo unos determinados objetivos. Modelo entidad / relacin (E/R) El diseador debe concebir la base de datos en un nivel superior, abstrayndose de cualquier consideracin tcnica o de implementacin en sistema, plataforma o aplicacin. 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 lgica y abstracta de la informacin, siendo capaz de representar toda la semntica del mundo real por medio de entidades y relaciones. Modelo relacional El diseador debe transformar el modelo E/R en el modelo relacional, teniendo muy en cuenta la teora de la normalizacin. Esta es una operacin 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 teoras matemticas de las relaciones, haciendo que los datos se estructuren lgicamente en forma de relaciones -tablas. Presenta beneficios como: Sencillez y uniformidad: Al tener como resultado una coleccin de tablas, y ser la tabla la estructura bsica 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 ms adecuada a su aplicacin. Independencia del interfaz de usuario: El modo en el que se almacena los datos no influye en su manipulacin lgica. Lenguaje SQL y base de datos final Ahora solamente tendremos que codificar en lenguaje SQL el modelo relacional expuesto anteriormente.

ANALISIS DE BASE DE DATOS

10 de jun. Para ello necesitaremos de: LDD: Con el que (por ejemplo) codificar las sentencias para la creacin de las distintas tablas de la base de datos. LMD: Para codificar las instrucciones (que por ejemplo) se encargarn de realizar: Consultas, Adiciones, Eliminaciones de Registros.

Diseo fsico El diseo fsico es el proceso de producir la descripcin de la implementacin de la base de datos en memoria secundaria: estructuras de almacenamiento y mtodos de acceso que garanticen un acceso eficiente a los datos. En general, el propsito del diseo fsico es describir cmo se va a implementar fsicamente el esquema lgico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en: Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. Determinar las estructuras de almacenamiento y los mtodos de acceso que se van a utilizar para conseguir unas prestaciones ptimas. Disear el modelo de seguridad del sistema.

Diseo conceptual En esta etapa se debe construir un esquema de la informacin que se usa en la empresa, independientemente de cualquier consideracin fsica. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseadores descubren la semntica (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 representacin fsica. El uso de los datos a travs de las reas de aplicacin.

El esquema conceptual se puede utilizar para que el diseador transmita a la empresa lo que ha entendido sobre la informacin que sta maneja. Para ello, ambas partes deben estar familiarizadas con la notacin utilizada en el esquema. La ms popular es la notacin del modelo entidad-relacin, que se describir en el captulo dedicado al diseo conceptual. Diseo lgico El diseo lgico es el proceso de construir un esquema de la informacin que utiliza la empresa, basndose en un modelo de base de datos especfico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideracin fsica. En esta etapa, se transforma el esquema conceptual en un esquema lgico 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 jerrquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lgico, ste se va probando y validando con los requisitos de usuario.

ANALISIS DE BASE DE DATOS

10 de jun. La normalizacin es una tcnica que se utiliza para comprobar la validez de los esquemas lgicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta tcnica se presenta en el captulo dedicado al diseo lgico de bases de datos. Caractersticas de una base de datos 1. La velocidad de acceso, El tamao de la informacin, El tipo de la informacin, Facilidad de acceso a la informacin, Facilidad para extraer la informacin requerida, El comportamiento del manejador de bases de datos con cada tipo de informacin.

Objetivos del Diseo de la Base de Datos

Entre las metas ms importantes que se persiguen al disear un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.

Acceso a la informacin (fcil y Rpido) Diseo de los esquemas con la forma normal

Informacin extra

Especificacin de limitantes

2.

Almacenar Solo La Informacin Necesaria

Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos tambin tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicacin. Normalizar la Estructura de las Tablas 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.

ANALISIS DE BASE DE DATOS

10 de jun. La eficiencia se refiere al hecho de que no tenemos duplicacin de datos, y tampoco tenemos grandes cantidades de "celdas vacas".

Podramos decir que estos son los principales objetivos de la normalizacin: Controlar la redundancia de la informacin. Evitar prdidas de informacin. Capacidad para representar toda la informacin. Mantener la consistencia de los datos.

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 categoras principales que pueden aplicarse prcticamente a cualquier aplicacin de bases de datos: Texto Nmeros Fecha y hora Cada uno de stos presenta sus propias variantes, por lo que la eleccin del tipo de dato correcto no slo influye en el tipo de informacin que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos. A continuacin se dan algunos consejos que nos ayudarn a elegir un tipo de dato adecuado para nuestras tablas: Identificar si una columna debe ser de tipo texto, numrico o de fecha. Elegir el subtipo ms apropiado para cada columna. Configurar la longitud mxima para las columnas de texto y numricas, as como otros atributos. Utilizar ndices Correctos 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 ms rpido, 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.

ANALISIS DE BASE DE DATOS

10 de jun. Normalizacin Normalizar es reconocer cualidades no deseadas en una tabla y la forma de corregirla. Caractersticas: Cualidades no deseadas Evitar redundancia de informacin pero sin perderla Existen dos formas para normalizar: 1. 2. Enfoque intuitivo Metodologa.- 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 Tabla Valor de Columna de Tabla CIUDAD (DETERMINA PK) CIUDAD Id_ciudad_edit nombre_ciudad_edit

Para la tabla Editoriales, que tenia 4 campos, hemos creado el DIAGRAMA DE DEPENDENCIAS FUNCIONALES Valor de Columna de Tabla Valor de Columna de Valor de Valor de EDITORIAL (DETERMINA PK) Tabla EDITORIAL Columna Columna de de Tabla Tabla EDITORIAL EDITORIAL Id_edit nombre_edit, direc_edit, id_ciudad_edit

Tabla: Ciudades id_ciudad_edit ( PK)

nombre_ciudad_edit

02 04

Loja Ambato

MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS id_libro Titulo Edicion tipo_libro id_edit nombre_edit Direc_edit id_ciud_edit PK NN NN NN 001 A Primera Ciencia F 101 LNS M. Aux 02 002 B Segunda Terror 102 Don Bosco Xxx 04

nomb_ciud_edit Loja Ambato

ANALISIS DE BASE DE DATOS

10 de jun. 003 004 005 C Primera Nacho Quinta Lee 1 Nacho Segunda Lee 2 Drama 103 Enseanza 101 Enseanza 101 Norma LNS LNS Yyy M. Aux M. Aux 07 02 02 New york Loja Loja

Se debe realizar un diagrama de Dependencias Funcionales (LO PRIMERO ES QUE DEBO HACER ES VERIFICAR QUE CAMPOS SERIAN DETERMINANTES, SERIA PK Atributos Clave (PK) Atributos NO Clave (normales y los FK) 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. DEFECTOS EN LA INSERCION DE LA PRIMERA FORMA NORMAL. Algunas anomalas de insercin 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. DEFECTOS EN LA ELIMINACION DE LA PRIMERA FORMA NORMAL. Esto sucede cuando se desea borrar el valor de un campo, y al hacer esto no se puede borrar slo ese valor sino que se debe borrar todo el registro, y es donde aparece esta anomala debido a que se puede borrar informacin importante de una relacin. DEFECTOS EN LA ACTUALIZACION DE LA PRIMERA FORMA NORMAL. Cuando una relacin sin normalizar se convierte en una relacin 1FN, algunos datos se duplican. Tal duplicidad de datos almacenados causar problemas en las operaciones de actualizacin Y ADEMAS GENERAR INCONSISTENCIAS O ERRORES EN LOS DATOS. SEGUNDA FORMA NORMAL Si esta en primera forma normal y cada atributo no clave depende totalmente de su clave principal. Anomalas de relaciones en 2FN Puede presentar anomalas de almacenamiento si cualquiera de sus atributos no clave depende transitivamente de la clave primaria, es decir depende indirectamente de la clave primaria. Tabla: EDITORIALES, est en 1FN, est en 2FN id_edit nombre_edit Direc_edit id_ciud_edit PK 101 LNS aaa 8 102 LOOS www 4

nomb_ciud_edit Loja Ambato

ANALISIS DE BASE DE DATOS

10 de jun. TERCERA FORMA NORMAL Una relacin es tercera forma normal si es 2FN y un atributo no clave YA NO ES funcionalmente dependiente de algn otro atributo no clave. Tabla: LIBROS, est en 1FN, 2FN y 3FN id_libro titulo Id_edicion_libro ID_tipo_libro id_edit `PK FK FK FK 001 A 001 001 101 002 B 002 002 102 Tabla: TIPO_LIBROS, est en 1FN, 2FN y 3FN id_TIPO_libro tipo_libro PK 001 Ciencia Ficcion 002 Terror Tabla: EDICION_LIBROS, est en 1FN, 2FN y 3FN id_edicion_libro edicin PK 001 Primera 002 Segunda Tabla: EDITORIALES, est en 1FN, 2FN y 3FN id_edit nombre_edit Direc_edit PK 101 LNS aaa 102 Don Bosco www id_ciud_edit FK 02 04

Tabla: CIUDADES, est en 1FN, 2FN y 3FN id_ciudad_edit nombre_ciudad_edit PK 02 Loja 04 Ambato

Generalmente un proceso de normalizacin termina cuando todas las relaciones pertenecen a tercera forma normal. Sin embargo, si una relacin contiene dependencias de valores mltiples, es necesaria una normalizacin posterior. Dada una relacin, el atributo A de esta relacin se dice ser dependiente de multi valuados (DMV) del atributo B si un rango especfico de valores del atributo A est determinado por un valor particular de B.

ANALISIS DE BASE DE DATOS

10 de jun.

Proceso de Anlisis y Diseo de la Base de Datos Identificacin de las entidades: en al anlisis de esta empresa hemos identificado las siguientes entidades dentro de la papelera Monsalve y sobre salen las entidades principales
Clientes Productos Proveedores Empleados Factura

Modelo Entidad Relacin: en esta etapa se realiza las relaciones entre las entidades las cuales tienen algo que hacen que la una entidad depende de la otro por alguna razn como por ejemplo:

factura genera producto

clientes atiende empleado

producto recibe cliente

ANALISIS DE BASE DE DATOS

10 de jun.

producto entrega proveedor

Proceso de Normalizacin: se realiza el anlisis de la entidades principales para mediante eso poder sacar las 1FN, 2FN,3FN.

Clientes Cod_Cliente Cedula Nombre Apellido Direccin telefono

Producto Cod_producto Nombre Cantidad Precio_Compra Precio_venta Descripcion

Proveedores Prov_RUC Cod_proveedor Nombre Direccin telefono fax

ANALISIS DE BASE DE DATOS

10 de jun.

Empleados Cedula_Empleado Cod_cargo Nombres Apellidos Direccion telefono celular Fecha_nac Fecha_Ingreso Sueldo_Mensual

Factura Cod_emp Num_fac Ced_empleado Cod_cliente Cod_impuesto Descuento Impuesto total

Descripcin de Tablas: se describe las tablas principales con los atributos correspondientes como CONSTRAINT NOMBRE TIPO DE DATO LONGITUD.

FACTURA CONSTRAINT NOMBRE TIPO DE DATO PK Cod_Empresa Char PK Nro_Factura Numeric PK Cedula_Empleado Nchar PK Cod_Cliente Nchar NN Subtotal Money PK Cod_Impuesto Char Descuento Money NN Impuesto Money NN Total Money

LONGUITUD [3] [4,0] [10] [4] [3] [3,0]

ANALISIS DE BASE DE DATOS

10 de jun.

CONSTRAINT NOMBRE PK Cod_Cliente Cedula NN Nmobre NN Apellido NN Direccion Telefono

CLIENTE TIPO DE DATO Nchar Nchar Char Char Char Nchar

LONGUITUD [4] [10] [30] [30] [40] [10]

CONSTRAINT NOMBRE Pk Cod_Cargo NN Tipo_Cargo

CARGO TIPO DE DATO Char Char

LONGUITUD [3] [20]

EMPLEADO CONSTRAINT NOMBRE TIPO DE DATO PK Cedula_Empleado Nchar NN-FK Cod_Empleado Char NN Nombre Char NN Apellido Char NN Direccion Char NN Telefono Nchar NN Movil Nchar NN Fecha_Nac DateTime NN Fecha_Ing DateTime NN Sueldo Money

LONGUITUD [10] [3] [25] [25] [30] [9] [9]

CONSTRAINT PK NN NN NN NN NN

NOMBRE Cod_Producto Nombre Cantidad Precio_Compra Precio_Venta Descripcion

PRODUCTO TIPO DE DATO NChar Char Numeric Money Money Char

LONGUITUD [4] [30] [3,0]

[40]

ANALISIS DE BASE DE DATOS

10 de jun.

CONSTRAINT PK FK NN NN NN

NOMBRE Nro_Factura Cod_Producto Cantidad Valor_Unitario Valor_Total

FACTURA_DESCRIPCION TIPO DE DATO Numeric Nchar Numeric Money Money

LONGUITUD [4,0] [4] [4,0]

CONSTRAINT NOMBRE PK Cod_Impuesto NN Impuesto

PRODUCTO_IMPUESTO TIPO DE DATO LONGUITUD Char [3] Money

CONSTRAINT NOMBRE PK Ruc FK Cod_Producto

PRODUCTO_PROVEEDORES TIPO DE DATO LONGUITUD Nchar [13] Nchar [4]

CONSTRAINT NN NN NN NN NN NN NN

NOMBRE Ruc Cod_Proveedor Nom_Empresa Encargado Dir_Empresa Telefono Fax

PROVEEDOR TIPO DE DATO Nchar Nchar Char Char Char Nchar Nchar

LONGUITUD [13] [3] [20] [25] [30] [9] [9]

CONSTRAINT PK NN NN NN

NOMBRE Cod_Empresa Sucursal Direccion Telefono

EMPRESA TIPO DE DATO Char Numeric Nchar Nchar

LONGUITUD [3] [3,0] [30] [9]

ANALISIS DE BASE DE DATOS

10 de jun.

Modelo Relacional: