Contenido

1.DISEÑAR BASE DE DATOS DE UN SISTEMA DE FACTURACIÓN .................................................................. 3

2.COMPARACION DE MODELO HECHO EN CLASE (BOLETA) Y MODELO BUSCADO (FACTURA) .................. 4
2.1.DISCUSIÓN DEL PROCESO ................................................................................................................... 4
2.1..1.Procedimiento que se siguió en el modelo hecho en clase (boleta). ......................................... 4
2.1.2.Procedimiento que se siguió en el modelo encargado (factura) ................................................. 5
2.2.PROCESO DE NORMALIZACIÓN .......................................................................................................... 5
2.2.1.EJEMPLO ...................................................................................................................................... 6
2.2.2.PRIMER NIVEL DE FORMALIZACIÓN/NORMALIZACIÓN (F/N) ..................................................... 7
2.2.3.SEGUNDO NIVEL DE F/N .............................................................................................................. 7
2.2.4.TERCER NIVEL DE F/N................................................................................................................... 8
3.Referencias............................................................................................................................................... 10
 INTRODUCCION

Los programas procedurales que trabajan con archivos se diseñan pensando en resolver un
problema mediante un flujo o secuencia de operaciones que se efectúan sobre uno o más
archivos de datos. Los archivos de datos normalmente se diseñan en base a los informes que
debe entregar el sistema. Esto funciona bien para los sistemas pequeños o sencillos.
En sistemas más complejos donde no existe uno sino decenas o cientos de archivos relacionados
el diseño de la estructura de los datos se complica mucho, pues aparecen problemas de
redundancia, inconsistencia o perdida de información. Las bases de datos no son estáticas y a
medida que el sistema va creciendo se van requiriendo nuevos informes, cálculos y análisis, sino
existe un modelo de datos bien especificado pueden ocurrir problemas catastróficos.
Los diagramas o modelos de entidad – relación son una herramienta para de modelado de datos
de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de
información, sus interrelaciones y propiedades. Basado en una percepción del mundo real
consiste en objetos llamados entidades y de relaciones entre estos objetos. Se desarrolló para
facilitar el diseño de base de datos permitiendo la especificación de un esquema de la empresa
que representa la estructura lógico completa de una base de datos.
 1. DISEÑAR BASE DE DATOS DE UN SISTEMA DE FACTURACIÓN

MODELO TRABAJO
MODELO ENCARGADO
HECHO EN CLASE
Id Cliente
Nombre
Nombre: Apellido
CLIENTE DNI: Dirección
Código Fecha De Nacimiento
Teléfono
Email
Numero
Num_Factura
Fecha
Hora
FACTURA Num_Pago
Total
Id Cliente
Id_Cliente
Id Boleta
Cantidad
Num_Detalle
Subtotal
DETALLE Id Factura
Id Boleta
Id Producto
Id Producto
Código
Id_Producto
Nombre
Nombre
PRODUCTO Unidad
Precio
Precio
Stock
Stock
Id_Categoria
CATEGORIA Nombre
Descripción
2.COMPARACION DE MODELO HECHO EN CLASE (BOLETA) Y MODELO BUSCADO

(FACTURA)

 Se puede observar que en la tabla cliente del modelo factura tiene más campos como:
apellido, dirección, fecha de nacimiento, teléfono, email, pero no contiene el campo de
DNI como si sucede en el modelo boleta
 En la tabla factura el campo en común entre el modelo boleta y factura es “id cliente” y
“numero”; en el registro factura y los campos diferentes son: (fecha, hora, total, id boleta)
y (num_pago) respectivamente.
 En la tabla detalle en el modelo boleta tiene dos campos adicionales que es cantidad y
subtotal y lo que tienen en común es id boleta e id factura e id producto, y el modelo
factura tiene el num_detalle
 En la tabla producto se evidencia que tienen en común: nombre, precio y stock y los
campos diferentes son (código y precio) en el modelo boleta y el id_producto en el
modelo factura
 En la tabla categoría el modelo boleta no tiene ningún campo mientras que el modelo
factura tiene los campos de id_categoria, nombre y descripción
 Un cliente puede pagar con las siguientes formas de pago: Efectivo, Tarjeta de
crédito, Tarjeta débito, PayPal.
 Un cliente puede generar varias facturas debido a sus distintas compras, pero jamás una
misma factura podrá haber sido generada por más de un cliente.
 En una factura pueden contener varios productos vinculados, al igual que todos los
productos están posibilitados a aparecer en todas las facturas.
 Luego se relacionaron las tablas que el cliente puede tener varias boletas, pero una misma
boleta no puede tener varios clientes; el vendedor puede tener varias boletas, pero la
boleta solo puede tener un vendedor, una boleta puede tener varios detalles y un producto
también puede tener varios detalles.
 Un cliente puede pagar el monto total de una factura con varios métodos de pago.
 El en modelo factura las claves primarias (PK) están representadas por una llave amarilla
mientras que las claves foráneas (FK) están representadas por una llave color plomo.

2.1.DISCUSIÓN DEL PROCESO

2.1..1.Procedimiento que se siguió en el modelo hecho en clase (boleta).

Primero se identificó los campos e identidades que se presentan en una boleta como:
nombre, cantidad, descripción, precio_unitario, precio_total, num_serie, fecha, hora,
nombre_producto, unidad_producto, numero_boleta, RUC, dirección_empresa,
nombre_empresa.
 Luego se clasifico en una tabla a que entidad pertenece cada campo
Después se relacionaron las tablas

2.1.2.Procedimiento que se siguió en el modelo encargado (factura)

 Registra el Id, Nombre, Apellido, Dirección, Teléfono y el Correo electrónico de los

clientes de la empresa
 Registrar para los productos la siguiente información: Código, Nombre, Precio
y Categoría a la que pertenece.
 Se debe especificar en la factura los Datos del cliente y una tabla que muestre
la Especificación del tipo de producto comprado, su precio, la cantidad suministrada y
el total parcial. Al final de la factura debe calcularse el valor antes de impuestos y
descuentos, y luego calcular el valor total de la compra.

2.2.PROCESO DE NORMALIZACIÓN

El proceso de normalización se definen seis formas normales o etapas. Las reglas de

normalización son lineales; por lo tanto, la segunda regla depende de la primera, la tercera
depende de la segunda y asi sucesivamente. 3 FN es el nivel hasta el que la mayoría de los
desarrolladores llevan sus aplicaciones de base de datos cuando normalizan sus bases de datos
¿Por qué? La mayoría de los desarrolladores encuentran que la tercera forma normal es suficiente
para cumplir con los requerimientos de la aplicación y asegurar la consistencia de los datos.
(rob, 2002)
Las ideas de formalización pueden ser empleadas para verificar que el diseño resultante
no viole de manera no intencional cualquiera de los principios de la normalización. No obstante,
el procedimiento de normalización si proporciona una infraestructura conveniente a partir de la
cual podemos describir esos principios. La normalización es una ayuda útil en el proceso, pero
no es una panacea; por lo tanto, aconsejamos a todo diseñador de una base de datos
familiarizarse con los principios de normalización, aunque no pretendemos decir que el diseño
deba basarse necesariamente solo en dichos principios. El proceso de normalización puede ser
caracterizado (muy informalmente) como un procedimiento de eliminar flechas que no parten de
claves candidatas. (date, 2001)
El proceso de formalización se debe de ir comprobando que cada relación cumple una
serie de reglas que se basan en la clave primaria y en las dependencias funcionales entre
atributos. Cada regla que cumple aumenta su grado de normalización. Si una regla no se cumple,
la relación se debe de descomponer en varias relaciones que si cumplan. Esta normalización se
va realizando en varios pasos. Cada uno de ellos corresponde a una forma normal que tiene una
serie de requisitos que tienen que ser cumplidos. A medida que vamos avanzando en el proceso
de normalización las relaciones tienen que cumplir las reglas más estrictas por lo que se ven
menos afectadas por los problemas de actualización. El modelo relacional solo necesita que sus
relaciones estén en primera forma normal. Los demás niveles de normalización con opcionales,
aunque es recomendable llegar a la forma de Boice-Cood. (yanez, 2005)

Regla Descripción
Primera forma
Incluye la eliminación de todos los grupos repetidos.
normal (1FN)
Segunda forma Asegura que todas las columnas que no son llave sean
normal (2FN) completamente dependientes de la llave primaria (PK).
Elimina cualquier dependencia transitiva. Una dependencia
Tercera forma
transitiva es aquella en la cual las columnas que no son llave son
normal (3FN)
dependientes de otras columnas que tampoco son llave.

2.2.1.EJEMPLO

Digamos que queremos crear una tabla con la información de usuarios, y los datos a guardar son
el nombre, la empresa, la dirección de la empresa y algún email, o bien URL si las tienen. En
principio comenzarías definiendo la estructura de una tabla como esta:
Formalización CERO.

USUARIOS
NOMBRE EMPRESA DIRECCIÓN_EMPRESA URL 1 URL 2
Juan Abc Guerrero N°.21 Abc.com Xyz.com
María Xyz Abasolo N°.36 Abc.com Xyz.com

 Diríamos que en la anterior tabla está en nivel de formalización cero porque ninguna de
nuestras reglas de formalización ha sido aplicada.

Observa los campos URL 1 Y URL 2

 ¿Qué haremos cuando en nuestra aplicación necesitaremos una tercera URL?

 ¿Quieres tener que añadir otro campo/columna a tu tabla y tener que reprogramar toda la
entrada de tus datos de tu código?
 Obviamente no, tú quieres crear un sistema funcional que pueda crecer y adaptarse
fácilmente a los nuevos requisitos. Echemos un vistazo a las reglas del primer nivel de
formalización - normalización, y las aplicaremos a nuestra tabla.
2.2.2.PRIMER NIVEL DE FORMALIZACIÓN/NORMALIZACIÓN (F/N)

 La regla de la primera forma normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas.
 Poner la tabla de base de datos en la primera forma normal resuelve el problema de los
encabezados de columna múltiples.

¿En qué consiste la primera forma?

 Eliminar los grupos repetitivos de las tablas individuales.

 Crear una tabla separada por cada grupo de datos relacionados.
 Identificar cada grupo de datos relacionados con una clave primaria.
 Estamos rompiendo la primera regla cuando repetimos los campos URL1 Y URL2
 ¿Y qué pasa con la tercera regla, la clave primaria? La regla tres básicamente
significa que tenemos que poner un campo tipo contador auto incrementable para
cada registro
 De otra forma, ¿Qué pasaría si tuviéramos dos usuarios llamados Joe y queremos
diferenciarlos?
 Una vez que aplicáramos el primer nivel de F/N nos encontraríamos con la
siguiente tabla:

USUARIOS
NOMBRE EMPRESA DIRECCION_EMPRESA URL
1 Juan Abc Guerrero N°.21 Abc.com
1 Juan Abc Guerrero N°.21 Abc.com
2 María Xyz Abasolo N°.36 Xyz.com
2 María Xyz Abasolo N°.36 Xyz.com

 Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos
solucionado el problema de limitación del campo URL.
 Pero sin embargo vemos otros problemas; cada vez que introducimos un nuevo
registro en la tabla de usuarios, tenemos que duplicar el nombre de la empresa y
del usuario. No solo nuestra BD crecerá muchísimo, sino que será muy fácil que
la BD se corrompa si escribimos mal alguno de los datos redundantes.

2.2.3.SEGUNDO NIVEL DE F/N

 Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros
  Relacionar estas tablas mediante una clave externa.
 Hemos separado el campo URL en otra tabla, de forma que podemos añadir más en el
futuro si tener que duplicar los demás datos. También vamos a usar nuestra clave
primaria para relacionar estos campos:

USUARIOS
USERID NOMBRE EMPRESA DIRECCION_EMPRESA
1 Juan Abc Guerrero N°.21
2 María xyz Abasolo N°.36

URLS
URLID RelUserId URL 1
1 1 Abc.com
2 1 Xyz.com
3 2 Abc.com
4 2 Xyz.com

 Hemos creado tablas separadas y la clave primaria en la tabla de usuarios, userId,

está relacionada ahora con la clave externa en la tabla urls, relUserId.
 Pero ¿Qué ocurre cuando queremos añadir otro empleado a la empresa ABC? ¿o
200 empleados? Ahora tenemos el nombre de la empresa y su dirección
duplicándose, otra situación que puede inducirnos a introducir errores en nuestros
datos. Así que tendremos que aplicar el tercer nivel de F/N.

2.2.4.TERCER NIVEL DE F/N

 Eliminar aquellos campos que no dependan de la clave.

 Nuestro nombre de la empresa y su dirección no tienen nada que ver con el campo userId,
así que tienen que tener su propia empresa id:

USUARIOS
UserId Empresa relEmpresaId
1 Juan 1
2 María 2

EMPRESAS
emprId Empresa Dirección_empresa
1 ABC Guerrero N°.21
2 XYZ Abasolo N°.36
 URLS
UrlId RelUserId url
1 1
2 1
3 2
4 2

“En primer lugar, tenemos que dar un nombre a nuestra base de datos. La llamaremos
facsys de (sistema de facturación). La distinción de mayúsculas y minúsculas en el nombre en la
base de datos puede influir en la programación” (Thibaud, 2006)

El modelo de entidad relación es la percepción de un mundo real que consiste en un

conjunto de objetos básicos llamados entidades y de unas relaciones entre estos objetos. Se le
utiliza para esquematizar la estructura lógica general de lo que será la base de datos. Una entidad
es un objeto que existe y puede distinguirse de otros objetos. Las entidades pueden ser de dos
tipos concretas y abstractas. (Rivera, 2008)

Una relación es una asociación entre varias entidades. Por ejemplo, se puede definir una
relación que asocie al alumno “ANA MARIA MUÑOZ” con el programa “INGENIERIA
CIVIL”, lo cual indicaría que el alumno está matriculado en ese programa. Llamaríamos al
conjunto de tales relaciones alumno programa. Un conjunto de relaciones es un grupo de
relaciones del mismo tipo. (Rivera, 2008)

Una base de datos está compuesta por tablas base que están almacenadas físicamente. A
veces es necesario combinar diferentes columnas de las tablas de una base de datos en una
consulta para crear tablas virtuales denominadas vistas. Estas tablas no se almacenan
físicamente, cada vez que un usuario consulta una de estas vistas recoge datos de las tablas base
sobre la que estas construida la vista, y muestra el resultado. (Hurtado, 2015)

El objetivo de esta actividad (diseño de base de datos) es convertir los modelos lógicos
de datos en modelos físicos de datos a través de archivos convencionales y/o base de datos. Con
esta meta, a continuación, se introducen algunos conceptos sobre base de datos y los archivos
convencionales. (Vicenç,2006, p.103)
Un campo es la implementación de un atributo de datos de un modelo lógico de datos
(por ejemplo, de un diagrama entidad-relación). Los campos son las unidades mínimas de
información y pueden clasificarse en campos claves y descriptores. Los campos claves permiten
identificar a uno y solo un registro de un archivo. Es posible encontrar claves primarias,
secundarias y externas, cuyos significados son equivalentes a los expuestos en el modelo lógico
de datos. El resto de campo se denominan descriptores. (Vicenç, 2006, p.103)
 Un registro es una colección de campos dispuestos en un formato predefinido. La
unidad mínima de información que una aplicación informativa es el registro.es este caso, el
registro equivale a la instancia del modelo lógico de datos. (Vincenç,2006, p.103)
La normalización intenta convertir un modelo lógico de datos es un buen modelo de
datos. Según la literatura del tema, un buen modelo de datos es aquel que es simple (es decir, que
los atributos de una entidad solo describan a esa entidad), no redundante (es decir, que la
información no se repite y por lo tanto existe un alto grado de integridad) y flexible a los
cambios del futuro. La idea básica de la normalización es simplificar las estructuras de datos para
conseguir que su acceso sea la más sencilla y manejable posible, y por lo tanto de alcanzar un
buen modelo. (Vicenç,2006, p.104)
El modelo entidad-relación es una técnica de ingeniería de la información que se utiliza
para desarrollar un modelo de datos de alta calidad. El modelo de datos ofrece una forma
estándar de definir datos de alta calidad. El modelo de datos ofrece una forma estándar de definir
los datos y las relaciones entre estos para los sistemas de información. Esto mejora enormemente
la calidad del sistema e incrementa la productividad del software. (Barker,1994, p.1).
En informática, entidad específica.
El registro o también llamado fila o tupla

3.Referencias

anonimo. (15 de febrero de 2017). Obtenido de https://es.wikipedia.org/wiki/Campo_(informática)

anonimo. (22 de abril de 2019). Obtenido de https://docs.microsoft.com/es-es/sql/relational-

databases/tables/tables?view=sql-server-2017

anonimo. (s.f). Obtenido de https://www.lucidchart.com/pages/es/que-es-un-modelo-de-base-de-datos

anonimo. (s.f). base de datos. Obtenido de

http://cursos.aiu.edu/Base%20de%20Datos/pdf/Tema%203.pdf

date, c. j. (2001). introduccion a los sistemas de base de datos . mexico : pearson educacion .

Hurtado, A. C. (2015). definicion y manipulacion de datos . españa: elearning s.l .

Revelo, J. (24 de julio de 2014). Hermosa programacion. Obtenido de

http://www.hermosaprogramacion.com/2014/07/sistema-facturacion-base-datos/

Rivera, F. L. (2008). colombia: itm.

Rivera, F. L. (2008). base de datos relacionales. colombia : itm.

Rivera, F. L. (2008). base de datos relacionales . colombia: itm.

rob, h. (2002). desarrollo de base de datos een microsoft . mexico : pearson educacion .
s.r, j. p. (27 de octubre de 2014). Obtenido de https://basededatos99.weebly.com/base-de-datos/6-que-
es-un-campo-y-un-registro-en-una-base-de-datos

Thibaud, C. (2006). recursos informaticos mysql 5. españa: eni.

yanez, j. m. (2005). sistemas de informacion medioambiental . españa: netbiblo.