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
1. Diseño de Bases de Datos
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 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
pueda acceder en la totalidad a los datos que lleva a cabo una empresa y 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 la cual se denomina Diseño de Base de la Base de Datos, sin 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, 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ñ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.
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.

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

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:
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
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.

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.
 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. 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.

2. 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.

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.
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.
➢ 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 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.

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.
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.

Normalización

Normalizar es reconocer cualidades no deseadas en una tabla y la 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. 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

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 Loja
04 Ambato

MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS

id_libr Titul Edicion tipo_lib id_e nombre_ Direc_e id_ciud_ed nomb_ciud_

o o ro dit edit dit it edit
NN
PK NN NN
001 A Primera Ciencia 101 LNS M. Aux 02 Loja
F
002 B Segund Terror 102 Don Bosco Xxx 04 Ambato
a
003 C Primera Drama 103 Norma Yyy 07 New york
004 Nach Quinta Enseñan 101 LNS M. Aux 02 Loja
o Lee za
1
005 Nach Segund Enseñan 101 LNS M. Aux 02 Loja
o Lee a za
2

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 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.
 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 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, está en 2FN

id_e nombre_ Direc_e id_ciud_ed nomb_ciud_

dit edit dit it edit

PK
101 LNS aaa 8 Loja
102 LOOS www 4 Ambato

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.

Tabla: LIBROS, está en 1FN, 2FN y 3FN

id_lib titu Id_edicion_l ID_tipo_li id_e

ro lo ibro bro dit
 ANALISIS DE BASE DE DATOS

`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_li tipo_li
bro bro

PK
001 Ciencia
Ficcion
002 Terror

Tabla: EDICION_LIBROS, está en 1FN, 2FN y 3FN

id_edicion_l edició
ibro n

PK
001 Primer
a
002 Segun
da

Tabla: EDITORIALES, está en 1FN, 2FN y 3FN

id_e nombre_ Direc_e id_ciud_ed

dit edit dit it

PK FK
101 LNS aaa 02
102 Don Bosco www 04

Tabla: CIUDADES, está en 1FN, 2FN y 3FN

id_ciudad_ nombre_ciudad
edit _edit

PK
02 Loja
04 Ambato

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
 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 Entidad – Relación: 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 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

Descripción de Tablas: se describe las tablas principales con los atributos

correspondientes como CONSTRAINT – NOMBRE – TIPO DE DATO – LONGITUD.
 ANALISIS DE BASE DE DATOS

FACTURA
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
PK Cod_Empresa Char [3]
PK Nro_Factura Numeric [4,0]
Cedula_Emple
PK ado Nchar [10]
PK Cod_Cliente Nchar [4]
NN Subtotal Money
PK Cod_Impuesto Char [3]
Descuento Money [3,0]
NN Impuesto Money
NN Total Money

CLIENTE
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
PK Cod_Cliente Nchar [4]
Cedula Nchar [10]
NN Nmobre Char [30]
NN Apellido Char [30]
NN Direccion Char [40]
Telefono Nchar [10]

CARGO
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
Pk Cod_Cargo Char [3]
NN Tipo_Cargo Char [20]

EMPLEADO
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
Cedula_Emple
PK ado Nchar [10]
NN-FK Cod_Empleado Char [3]
NN Nombre Char [25]
 ANALISIS DE BASE DE DATOS

NN Apellido Char [25]

NN Direccion Char [30]
NN Telefono Nchar [9]
NN Movil Nchar [9]
NN Fecha_Nac DateTime
NN Fecha_Ing DateTime
NN Sueldo Money

PRODUCTO
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
PK Cod_Producto NChar [4]
NN Nombre Char [30]
NN Cantidad Numeric [3,0]
Precio_Compr
NN a Money
NN Precio_Venta Money
NN Descripcion Char [40]

FACTURA_DESCRIP
CION
CONSTRAI
NT NOMBRE TIPO DE DATO LONGUITUD
PK Nro_Factura Numeric [4,0]
FK Cod_Producto Nchar [4]
NN Cantidad Numeric [4,0]
NN Valor_Unitario Money
NN Valor_Total Money

PRODUCTO_IMPUE
STO
CONSTRAI
NT NOMBRE TIPO DE DATO LONGUITUD
PK Cod_Impuesto Char [3]
NN Impuesto Money

PRODUCTO_PROVEED
ORES
CONSTRAI
NT NOMBRE TIPO DE DATO LONGUITUD
PK Ruc Nchar [13]
FK Cod_Producto Nchar [4]
 ANALISIS DE BASE DE DATOS

PROVEEDOR
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
NN Ruc Nchar [13]
Cod_Proveedo
NN r Nchar [3]
NN Nom_Empresa Char [20]
NN Encargado Char [25]
NN Dir_Empresa Char [30]
NN Telefono Nchar [9]
NN Fax Nchar [9]

EMPRESA
CONSTRAI TIPO DE
NT NOMBRE DATO LONGUITUD
PK Cod_Empresa Char [3]
NN Sucursal Numeric [3,0]
NN Direccion Nchar [30]
NN Telefono Nchar [9]

Modelo Relacional:
ANALISIS DE BASE DE DATOS