ANALISIS DE BASE DE DATOS Diseño de Base Datos
En la siguiente Base de Datos presentamos hasta cuantas formas de normalización 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
Índice de Contenidos Bas es de Datos 1. Diseño de Bases
Análisis Modelo entidad / relación (E/R) Modelo relacional Lenguaje SQL y base de datos final 2. Diseño físico 3. Diseño conceptual 4. Diseño lógico 5. Características de una base de datos 6. Objetivos del Diseño de la Base de Datos 7. Almacenar Solo La Información Necesaria. Normalizar la Estructura de las Tablas Seleccionar Selecc ionar el Tipo de Dato Adecuado Utilizar Índices Apropiadamente 8. Normalización
_
ANALISIS DE BASE DE DATOS
INTRODUCCIÒN En la actualidad en cada una de la empresas tanto grande o pequeña se manejan gran cantidad de datos. Por eso cada uno de los propietarios deben conocer la importancia de las bases de datos como aplicación profesional para el manejo de la información, al pasar por alto la utilización de bases de datos esto podría ser el causa por la cual no se pued pueda a acce acceder der en la tota totalid lidad ad a los los dato datoss que que lleva lleva a cabo cabo una empre empresa sa y esto esto causaría la pérdida de tiempo y dinero. Para la creación de una base de datos debemos pasar antes por una etapa crucial y muy compleja compleja la cual se denomina denomina Diseño de Base Base de la Base de Datos, Datos, sin importar importar los datos que esta empresa maneje nuestra base de datos deberá ser correctamente diseñada para que sea utilizada en un futuro sin problema alguno. Vamos a llevar a cabo el análisis y diseño de una base de datos de la empresa librería MONSALVE, MONSALVE, cual se dedica a la ventas, distribución de material didáctico.
ANALISIS DE 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.
➢
➢ ➢
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. Modelo entidad / relación (E/R) El dise diseñ ñador ador debe ebe con concebir ebir la base ase de datos atos en un nive nivell supe superi rior or,, 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. 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 normalización ó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 Este mode modelo lo de dato datoss está está basa basado do en las las teor teoría íass mate matemá máti tica cass de las las relaciones, haciendo que los datos se estructuren lógicamente en forma de relaciones -tablas. Presenta beneficios como: Sencillez Sencillez y uniformidad uniformidad:: Al tener como resultado resultado una colección colección de tablas, 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. Lenguaje SQL y base de datos final Ahor Ahora a sola solame ment nte e tend tendre remo moss que que codi codifi fica carr en leng lengua uaje je SQL SQL el mode modelo lo relacional expuesto anteriormente.
ANALISIS DE BASE DE DATOS Para ello necesitaremos de: LDD: Con Con el que que (por (por ejem ejempl plo) o) codi codifi fica carr las las sent senten enci cias as pa para ra la ➢ LDD: creación de las distintas tablas de la base de datos. LMD: Para ara codi codifi fica carr las las inst instru rucc ccio ione nes s (que (que por por ejem ejempl plo o) se ➢ LMD: encargarán de realizar: Consultas, Adiciones, Eliminaciones de Registros. 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: 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 acce acceso so que que se van van a util utiliz izar ar pa para ra cons conseg egui uirr unas unas pres presta taci cion ones es ó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 semántica (significado) (significado) de los datos de la empresa: empresa: encuentran entidades, 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 familiarizadas con la notación 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. 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 esta etapa, etapa, se transf transform orma a el esquem esquema a concep conceptua tuall en un esquem esquema a lógico lógico que 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 una técn técnic ica a que que se utili utiliza za para para comp compro roba barr la valid validez ez de los los esquemas esquemas lógicos basados en el modelo relacional, relacional, ya que asegura que las relaciones 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.
ANALISIS DE BASE DE DATOS Características de una base de datos
➢
La velocidad de acceso, El tamaño de la información, 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.
1. Obj Objeti etivos vos del del Diseño Diseño de de la Base Base de Datos 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.
2. Almace Almacenar nar Solo La Inform Información ación Neces Necesaria aria Frecuent recuenteme emente nte podemos podemos generar generar alguno algunoss datos datos sobre sobre la marcha marcha sin tener 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. Normalizar la Estructura de las Tablas Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está está en el hech hecho o que que pode podemo moss agre agrega garr dato datoss 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".
ANALISIS DE 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. i nformación. Mantener la consistencia de los datos. 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 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, texto, numérico o de fecha. Elegir el subtipo más apropiado para cada columna. Config Configura urarr la longit longitud ud máxima máxima para para las columnas columnas de texto texto y numéricas, 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 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. 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 mane manera ra simp simple le,, depe depend nde e que que tipo tipo de cons consul ulta tass ejec ejecut utam amos os y que que tan tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas.
Normalización Normalizar es reconocer cualidades no deseadas en una tabla y l a forma de corregirla.
ANALISIS DE BASE DE DATOS Características: Cualidades no deseadas Evitar redundancia de información pero sin perderla Existen dos formas para normalizar:
1. Enfo Enfoqu que e int intui uitiv tivo o 2. Metodología Metodología..- Dependencia Dependencia funcional funcional
DEPENDENCIA FUNCIONAL La dependencia funcional se da cuando hay tablas El atributo A es funcionalmente dependiente del atributo B, 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
Para la tabla Editoriales, que tenia 4 campos, hemos creado el DIAGRAMA DE DEPENDENCIAS FUNCIONALES Valor de Columna de Valor de Columna Valor Valor de Tabla EDITORIAL de Tabla de Columna (DETERMINA PK) EDITORIAL Column de Tabla a de EDITORIAL Tabla EDITOR IAL Id_edit nombre_edit, direc_ed id_ciudad_e it, dit
Tabla: Ciudades id_ciudad_edit ( PK)
nombre_ciudad_edit
ANALISIS DE BASE DE DATOS 02 04
Loja Ambato
MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS id_libr Titul Edicion tipo_lib id_e nombre_ Direc_e o o ro dit edit dit NN PK NN NN 001 A Primera Ciencia 101 LNS M. Aux F 002 B Segund Terror 102 Don Bosco Xxx a 003 C Primera Drama 103 Norma Yyy 004 Nach Quinta Enseñan 101 LNS M. Aux o Lee za 1 005 Nach Segund Enseñan 101 LNS M. Aux o Lee a za 2
id_ciud_ed nomb_ciud_ it edit 02 04
Loja Ambato
07 02
New york Loja
02
Loja
Se debe realizar un diagrama de Dependencias Funcionales 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 SOLO VALOR. VALOR. DEFECTOS EN LA INSERCION DE LA PRIMERA FORMA NORMAL.
Alguna Algunass anomal anomalías ías de inserc inserción ión se deben deben a la depend dependenc encia ia funcio funcional nal de algunos algunos campos no clave en un subconjunto de atributos de la clave principal en lugar de toda la clave primaria.
ANALISIS DE BASE DE DATOS
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 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. DEFECTOS EN LA ACTUALIZACION DE LA PRIMERA FORMA NORMAL.
Cuando una relación sin normalizar se convierte en una relación 1FN, algunos datos se duplican. Tal Tal duplicidad de datos almacenados causará problemas en las operaciones de actualización 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.
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.
Tabla: EDITORIALES, está en 1FN, 1 FN, está en 2FN id_e dit
nombre_ edit
Direc_e id_ciud_ed nomb_ciud_ dit it edit
PK 101 102
LNS LOOS
aaa www
8 4
Loja Ambato
TERCERA FORMA NORMAL Una relación es tercera forma normal si es 2FN 2F N y un atributo no clave YA NO ES funcionalmente dependiente de algún otro atributo no clave. Tabla: LIBROS, está en 1FN, 2FN y 3FN id_lib titu Id_edicion_l ID_tipo_li ro lo ibro bro
id_e dit
ANALISIS DE BASE DE DATOS `PK 001 002
FK 001 002
A B
FK 001 002
FK 101 102
Tabla: TIPO_LIBROS, está en 1FN, 2FN y 3FN id_TIPO_li bro PK 001
tipo_li bro Ciencia Ficcion Terror
002
Tabla: EDICION_LIBROS, está en 1FN, 2FN y 3FN id_edicion_l edició ibro n PK 001 002
Primer a Segun da
Tabla: EDITORIALES, está en 1FN, 2FN y 3FN
id_e dit
nombre_ edit
Direc_e id_ciud_ed dit it
PK 101 LNS 102 Don Bosco
aaa w ww
FK 02 04
Tabla: CIUDADES, está en 1FN, 2FN y 3FN id_ciudad_ nombre_ciudad edit _edit PK 02 04
Loja Ambato
Gene Genera ralm lmen ente te un proc proces eso o de norm normal aliz izac ació ión n term termin ina a cuan cuando do toda todas s las las relaciones relaciones pertenecen pertenecen a tercera 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
ANALISIS DE BASE DE DATOS valuados (DMV) del atributo B si un rango específico de valores del atributo A está determinado por un valor particular de B.
Proceso de Análisis y Diseño de la Base de Datos Identificación de las entidades: en al análisis de esta empresa hemos identificado las siguientes entidades dentro de la papelería Monsalve y sobre salen las entidades principales ➢ ➢ ➢ ➢ ➢
Clientes Productos Proveedores Empleados Factura
Modelo Modelo Entida Entidad d – Relaci Relación ón:: en esta esta etap etapa a se reali realiza za las las relac relacion iones es entr entre e las las entidades entidades las cuales tienen algo que hacen que la una entidad depende de la otro por alguna razón como por ejemplo:
Proceso de Normalización: se realiza el análisis de la entidades principales para mediante eso poder sacar las 1FN, 2FN,3FN.
Clientes Cod_Cliente Cedula Nombre Apellido Dirección telefono
Producto Cod_producto Nombre
ANALISIS DE BASE DE DATOS Cantidad Precio_Compra Precio_venta Descripcion Proveedores Prov_RUC Cod_provee dor Nombre Dirección telefono fax
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
Descri Descripci pción ón de Tablas: ablas: se desc descri ribe be las las tabl tablas as prin princi cipa pale less con con los los atri atribu buto toss correspondientes como CONSTRAINT – NOMBRE – TIPO DE DATO – LONGITUD.
ANALISIS DE BASE DE DATOS
CONSTRAI NT PK PK PK PK NN PK NN NN
CONSTRAI NT PK NN NN NN
CONSTRAI NT Pk NN
CONSTRAI NT PK NN-FK NN
FACTURA TIPO DE NOMBRE DATO Cod_Empresa Char Nro_Factura Numeric Cedula_Emple ado Nchar Cod_Cliente Nchar Subtotal Money Cod_Impuesto Char Descuento Money Impuesto Money Total Money
LONGUITUD [3] [4,0] [10] [4] [3] [3,0]
NOMBRE Cod_Cliente Cedula Nmobre Apellido Direccion Telefono
CLIENTE TIPO DE DATO Nchar Nchar Char Char Char Nchar
LONGUITUD [4] [10] [30] [30] [40] [10]
NOMBRE Cod_Cargo Tipo_Cargo
CARGO TIPO DE DATO Char Char
LONGUITUD [3] [20]
EMPLEADO TIPO DE DATO
LONGUITUD
NOMBRE Cedula_Emple ado Nchar Cod_Empleado Char Nombre Char
[10] [3] [25]
ANALISIS DE BASE DE DATOS NN NN NN NN NN NN NN
CONSTRAI NT PK NN NN NN NN NN
Apellido Direccion Telefono Movil Fecha_Nac Fecha_Ing Sueldo
Char Char Nchar Nchar DateTime DateTime Money
PRODUCTO TIPO DE NOMBRE DATO Cod_Producto NChar Nombre Char Cantidad Numeric Precio_Compr a Money Precio_Venta Money Descripcion Char
[25] [30] [9] [9]
LONGUITUD [4] [30] [3,0]
[40]
FACTURA_DESCRIP CION CONSTRAI NT PK FK NN NN NN
NOMBRE Nro_Factura Cod_Producto Cantidad Valor_Unitario Valor_Total
TIPO DE DATO Numeric Nchar Numeric Money Money
LONGUITUD [4,0] [4] [4,0]
PRODUCTO_IMPUE STO CONSTRAI NT NOMBRE TIPO DE DATO PK Cod_Impuesto Char NN Impuesto Money
LONGUITUD [3]
PRODUCTO_PROVEED ORES CONSTRAI NT NOMBRE TIPO DE DATO PK Ruc Nchar FK Cod_Producto Nchar
LONGUITUD [13] [4]
ANALISIS DE BASE DE DATOS
CONSTRAI NT NN
PROVEEDOR TIPO DE DATO Nchar
LONGUITUD [13]
Nchar Char Char Char Nchar Nchar
[3] [20] [25] [30] [9] [9]
NN NN NN NN NN NN
NOMBRE Ruc Cod_Proveedo r Nom_Empresa Encargado Dir_Empresa Telefono Fax
CONSTRAI NT PK NN NN NN
EMPRESA TIPO DE NOMBRE DATO Cod_Empresa Char Sucursal Numeric Direccion Nchar Telefono Nchar
Modelo Relacional:
LONGUITUD [3] [3,0] [30] [9]
ANALISIS DE BASE DE DATOS