ANALISIS Y DISEÑO DE BBDD EN LA

EMPRESA JOYERIA RAYUN

Facultad de ciencias
Carrera: Ingeniería Civil Industrial
Asignatura: Base de Datos

Docente: Loreto Ligia Yáñez

Fecha de envío: 08/11/2020
Nombre(s) de estudiante(s): Francisco Beratto
Daniel Hermosilla
Thomas Redel
Daniel Teke
 Índice

Contenido
Índice......................................................................................................................................................2
I.RESUMEN...........................................................................................................................................4
II.MARCO REFERENCIAL...................................................................................................................5
2.1 Bases de Datos y Tipos.....................................................................................................................5
2.1.1Según su flexibilidad de modificación:............................................................................................5
2.1.2Según el contenido:.........................................................................................................................6
2.1.3Según los modelos utilizados:.........................................................................................................8
2.2 Bases de Datos Relacionales...........................................................................................................12
2.3 Bases de Datos No Relacionales.....................................................................................................12
2.4 Arquitectura de las Bases de Datos.................................................................................................13
2.5 Bases de Datos en la Nube..............................................................................................................14
2.6 Big Data..........................................................................................................................................14
2.7 Datamining......................................................................................................................................15
2.8 Analítica de Datos...........................................................................................................................16
2.9 Servidores Físicos y Servidores en la Nube para el Almacenamiento de los datos..........................17
2.10 Sistemas Gestores de Bases de Datos.................................................................................19
III.ANTECEDENTES GENERALES...................................................................................................31
3.1 Empresa..........................................................................................................................................31
3.1.1 Descripción de la Empresa...........................................................................................................31
3.1.2 Visión............................................................................................................................................31
3.1.3 Misión...........................................................................................................................................31
3.1.4 Objetivos Estratégicos..................................................................................................................31
3.1.5 Localización (mapa)......................................................................................................................32
3.1.6 Mapa organizacional u Organigrama............................................................................................32
3.1.7 Situación Actual de BBDD y herramientas tecnológicas que utiliza la organización.....................32
3.1.8 Muestre y explique brevemente los datos, información, resultados, estadísticas, reportes u
otros que se maneja, proceso y gestiona la información......................................................................33
3.2 Descripción de la problemática.......................................................................................................34
3.2.1Explique claramente la problemática............................................................................................34
3.2.2 Efecto que tiene en la organización la problemática, indicando departamentos y actores
involucrados..........................................................................................................................................34
3.3 Objetivo general y Objetivos específicos.........................................................................................36
3.3.1 Objetivo general de la propuesta de solución de la Base de Datos..............................................36
3.3.2 Objetivos específicos....................................................................................................................36
Con el diseño e implementación de la base de datos se busca:..............................................................36
IV.ANÁLISIS DE LA BASE DE DATOS...........................................................................................36
4.1 Descripción de la situación de la Empresa.......................................................................................36
4.2 Entidades Necesarias para el Almacenamiento en la Base de Datos...............................................37
4.3 Modelo Entidad Relación................................................................................................................39
V. DISEÑO DE LA BASE DE DATOS..........................................................................................................49
5.1 Transformación Modelo Entidad Relación a Modelo Relacional.....................................................49

P á g i n a 2 | 73
5.2 Normalización Modelo Relacional...................................................................................................59
5.3 Modelo Relacional Normalizado.....................................................................................................69
VI.CREACION, IMPLEMENTACIÓN Y GESTION DE DATOS EN SQL SERVER.............................................69
6.1Definición, Características y entorno de desarrollo de SQL Server y Manegement Studio..............69
6.2Bases de Datos en SQL Server y Manegement Studio (casos de uso reales, proveedores, etc).......69
6.3Implementación de la BBDD del Proyecto en SQL Server y Manegement Studio............................69
6.4 Gestión de la Base de Datos............................................................................................................69
6.4.1 Consultas a la Base de Datos........................................................................................................69
6.4.2 Sintaxis en SQL y resultado de las Consultas a la BBDD................................................................69
6.4.3 Aporte de cada consulta realizada...............................................................................................69
VII. RESULTADOS Y APORTES.................................................................................................................69
7.1 Resultados.......................................................................................................................................69
7.2 Aportes............................................................................................................................................69
VIII. REFERENCIA ELECTRÓNICA.................................................................................................70
IX.TABLA DESCRIPTIVA de Aportes en el PROYECTO de BBDD – Evaluación N°2...................................72

P á g i n a 3 | 73
 I.RESUMEN

En este trabajo se analizará a la empresa Joyería Rayun, en específico al manejo de los datos
generados por la misma, la factibilidad de mejorar o implementar una base de datos relacional
(SQL), en conjunto con todos los problemas que presenta o pueda presentar al implementar el
sistema gestor. Para esto se efectuará un modelo Entidad-Relación de la empresa, una
descripción de la problemática y en base a eso se determinará un diseño para la joyería en
cuestión. Con el fin de optimizar el diseño de la base de datos en cuestión, se creará la entidad
de Central, a su vez se hará uso de los departamentos (Finanzas, Marketing, R. Humanos,
Manufactura, e Informática) como entidades propias, en conjunto con sus respectivos jefes y
empleados de los mismos.
Para los apartados de Proveedores, se creará adicionalmente una entidad del Insumo/Materia
Prima en cuestión. Ante las posibles problemáticas que se puedan generar en el apartado de
medios de venta de los productos, se crean las siguientes entidades: Producto, Proveedores,
Tienda Física e Internet. Esta última a su vez para poder realizar la venta del producto necesita
un Envió que es efectuado por un Transportista. Cabe destacar que cada producto posee un
Stock en la empresa mencionada.

Todo esto será implementado dentro de un diagrama Entidad-Relación, el cual, con el fin de
facilitar su implementación a la futura base de datos, será transformado por medio del modelo
Relacional y de manera subsecuente se le aplicará una normalización al modelo ya relacional.

Después de tener el esquema o diagrama listo para ser empleado en una base de datos, se
procederá a implementar las tablas a la base de datos creada en Microsoft SQL Server,
adicionando una serie de comandos para poder hacer uso de los datos contenidos en cada tabla
previamente generada, cada comando cumplirá una función específica requerida por la
empresa en cuestión.

Palabras claves: base de datos, modelo entidad-relación, análisis de datos, SGBD,

almacenamiento de datos

P á g i n a 4 | 73
 II.MARCO REFERENCIAL

2.1 Bases de Datos y Tipos

Se llama base de datos, o también banco de datos, a un conjunto de información perteneciente

a un mismo contexto, ordenada de modo sistemático para su posterior
recuperación, análisis y/o transmisión. Existen actualmente muchas formas de bases de datos,
que van desde una biblioteca hasta los vastos conjuntos de datos de usuarios de
una empresa de telecomunicaciones.

Las bases de datos son el producto de la necesidad humana de almacenar la información, es

decir, de preservarla contra el tiempo y el deterioro, para poder acudir a ella posteriormente.
En ese sentido, la aparición de la electrónica y la computación brindó el elemento digital
indispensable para almacenar enormes cantidades de datos en espacios físicos limitados,
gracias a su conversión en señales eléctricas o magnéticas.

El manejo de las bases de datos se lleva mediante sistemas de gestión (llamados DBMS por sus
siglas en inglés: Database Management Systems o Sistemas de Gestión de Bases de Datos),
actualmente digitales y automatizados, que permiten el almacenamiento ordenado y la rápida
recuperación de la información. En esta tecnología se halla el principio mismo de
la informática. Se pueden clasificar de la siguiente manera:

Imagen n°1 “Bases de datos”

Fuente: https://www.capterra.es/blog/639/software-base-de-datos-gratuitos-codigo-abierto

2.1.1Según su flexibilidad de modificación:

->Bases de Datos Dinámicas: Son bases de datos que poseen la capacidad de modificación a
través del pasar del tiempo, permitiendo funciones constantes de actualización, edición y
eliminación de datos.

P á g i n a 5 | 73
 Imagen n°2 “Base de Datos Dinámica”

Fuente: https://sites.google.com/site/tipobasedat/base-de-datos-dinamicas

->Bases de Datos Estáticas: Son bases de datos diseñadas especialmente para la lectura de
sus datos. Su implementación en la mayoría de los casos es para almacenar y registrar
datos históricos y desarrollar estudios que permitan entender su comportamiento a través del
tiempo.

Imagen n°3” Base de Datos Estática”

Fuente: https://sites.google.com/site/tipobasedat/base-de-atos-dinamicas

2.1.2Según el contenido:

->Bases de Datos Bibliográficas: Base de datos de registros bibliográficos, que pueden tener
un soporte de carácter físico o más frecuentemente de carácter electrónico (Catalogo).
Ayudan a clasificar diversos campos de datos, algunos ejemplos de campos frecuentes son:
autor, fecha de publicación, editorial, titulo, etc.

Imagen n°4 “Base de Datos Bibliográficas”

P á g i n a 6 | 73
 Fuentes: https://es.slideshare.net/lmichan/bases-de-datos-bibliogrficas-bibliogrficas

->Directorios: Base de datos comúnmente utilizada con fines empresariales, contiene los
elementos básicos que nos permiten ordenar y organizar la información, algunos ejemplos de
elementos son: Nombres, direcciones, contacto telefónico, direcciones de correo electrónico,
códigos postales, entre otros.

Imagen n°5 “Directorios”

Fuente: https://es.justexw.com/plantillas/agenda-telefonica-para-excel

->Bases de Datos de Texto Completo: Base de datos que nos permite buscar términos
específicos, palabras claves y todas las opciones de una BBDD de datos bibliográficos, con la
gran diferencia que en esta BBDD podemos consultar el texto íntegro que está archivado.
Estás bases de datos son de especial utilidad para cumplir con objetivos académicos y de
investigación científica.

Imagen n°6 “Base de Datos de Texto Completo”

Fuente: https://sites.google.com/site/tipobasedat/base-de-datos-de-texto-completo

2.1.3Según los modelos utilizados:

->Bases de Datos Jerárquicas: Base de datos en la que se almacena la información en

una estructura jerárquica o con un orden de importancia. En este modelo los datos están
organizados en una figura que nos hacer recordar a árbol puesto al revés. La estructura
jerárquica que conseguimos en los árboles se construye con segmentos que conocemos
como nodos y ramas.

P á g i n a 7 | 73
Los segmentos o nodos para construir el árbol pueden ser de tres formas o categorías:

 Padre: es un nodo del cual se desprenden descendientes. Todos los padres están
ubicados al mismo nivel y tienen el mismo valor de importancia.
 Hijo: es un nodo que depende del nodo padre. Se puede decir que es una derivación del
anterior.
 Raíz: es el origen de los datos, debido a que no tiene un nodo padre. Está situado en el
nivel superior del árbol. De él se desprenden todos los nodos.

Entre sus ventajas destaca la mantener la integridad de la información, la capacidad de

compartir información entre los usuarios de la base de datos y la globalización de la misma.

Imagen n°7 “Base de Datos Jerárquica”

Fuente: https://dbdb.io/db/adabas
->Bases de Datos de Red: Base de datos muy parecido al modelo jerárquico, si bien
comparten muchas similitudes, su rasgo distintivo es la diferencia en la composición del
nodo, ya que estos pueden poseer diferentes padres. Actualmente este modelo no es utilizado
con mucha frecuencia debido a que posee gran dificultad al modificar y adaptar, lo que
aumenta el grado de complejidad.

Imagen n°9 “Bases de Datos de Red”

Fuente: https://es.wikipedia.org/wiki/Archivo:DB_red.png

->Bases de Datos Transaccionales: Se encargan del envío y recepción de datos a gran

velocidad. Las BBDD transaccionales en realidad son poco comunes para usuarios de
ordenadores que no estén relacionados con el ámbito industrial y de producción en líneas
complejas. Su mayor uso es en los sistemas bancarios que registran operaciones de
intercambio de dinero entre cuentas.

P á g i n a 8 | 73
 Imagen n°9 “Bases de Datos Transaccional”

Fuente:https://blog.enzymeadvisinggroup.com/base-de-datos-transaccionales#:~:text=Una%20base
%20de%20datos%20transaccionales%20es%20un%20sistema%20de%20gesti%C3%B3n,en%20su
%20defecto%2C%20se%20reviertan.

->Bases de Datos Relacionales (SQL): Bases de datos con un modelo basado en el uso de
relaciones entre los datos. En este tipo de BBDD predomina el lenguaje SQL (“Structure
Query Language”), su funcionamiento radica en la inclusión todos los datos en registros, que
más adelante será organizada en tablas. Puesto que las tablas están organizadas, se pueden
instaurar las relaciones existentes entre datos de manera fácil y cruzar de manera veloz para
emitir los reportes y análisis necesarios. Se caracterizan por poseer un margen de error nulo y
no poseer la necesidad de constantes modificaciones.

Imagen n°11 “Bases de Datos Relacionales”

Fuente: https://neuronet.cl/licenciamiento-oracle/

->Bases de Datos Deductivas: Es una BBDD que permite la posibilidad de hacer deducciones
a través de una inferencia. Su funcionalidad depende de las condiciones y hechos que se

P á g i n a 9 | 73
almacenan en la base de datos. También son conocidas como bases de datos lógicas ya que sus
principios están fundamentados en la lógica matemática.

Nacen como respuesta a las limitaciones que surgen en las bases de datos relacionales a la
hora de ejecutar consultas recursivas y teorizar sobre las relaciones indirectas que pudiesen
generarse entre los datos almacenados.

Esta base de datos utiliza un lenguaje llamado data log que le permite al ordenador resolver las
deducciones para contestar consultas.

Imagen n°11 “Bases de Datos Deductivas”

Fuente: https://10tipos.com/tipos-de-bases-de-datos/
->Bases de Datos Documentales (NoSQL): Modelo de conjuntos de información que utilizan
documentos como la estructura de almacenamiento y consulta de datos.
Estos documentos están compuestos de forma múltiple por registros y datos. Están construidas
con lenguaje NoSQL lo que le proporciona un gran número de ventajas técnicas y de
flexibilidad.
Este modelo de base de datos permite el manejo de pesados volúmenes de información en
periodos mínimos de tiempo. Su diversidad de funciones y módulos adaptables a múltiples
mecanismos de consulta la han convertido en uno de los modelos preferidos de trabajo en la
actualidad por parte de los programadores.

Imagen n°12 “Bases de Datos NoSQL”

Fuente: https://www.upf.edu/hipertextnet/numero-3/bases-datos.html

->Bases de Datos Orientadas a Objetos: Son de las más modernas con las que contamos.
Posee una gran capacidad y potencia. En este tipo de base de datos, no se almacena
información detallada sobre el objeto, se almacena por completo al objeto.

P á g i n a 10 | 73
En ella se dota al objeto de un conjunto de características propias para diferenciarlo de objetos
que puedan ser similares. Las ventajas de este modelo son obvias frente a las descritas con
anterioridad. Admiten mayor cantidad de contenido y permiten al usuario tener más
información de primera mano.

Imagen n°13 “Bases de Datos Orientadas a Objetos”

Fuente: https://www.monografias.com/trabajos87/base-datos-orientada-objetos/base-datos-
orientada-objetos.shtml

->Bases de Datos Multidimensionales: Base de datos pensada para funciones específicas,

posee muchas similitudes con las bases de datos relacionales. La diferencia radica en que en
estas los campos o atributos puede ser de dos tipos: Representación de dimensiones dentro de
una tabla, o representación de métricas que se pretenden obtener.

Imagen n°14 “Bases de Datos Multidimensionales”

Fuente: https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/rol-de-la-base-de-datos-
multidimensional-en-las-organizaciones-modernas

2.2 Bases de Datos Relacionales

Una base de datos relacional es una colección de elementos de datos organizados en un

conjunto de tablas formalmente descritas, desde donde se puede acceder a los datos o volver a
montarlos de muchas maneras diferentes sin tener que reorganizar las tablas de la base. La
interfaz estándar de programa de usuario y aplicación a una base de datos relacional, es el
Lenguaje de Consultas Estructuradas (SQL). Los comandos SQL se utilizan tanto para
consultas interactivas como para obtener información de una base de datos relacional y la
recopilación de datos para informes.

P á g i n a 11 | 73
Las bases de datos relacionales se basan en la organización de la información en partes
pequeñas que se integran mediante identificadores; a diferencia de las bases de datos no
relacionales que, como su nombre lo indica, no tienen un identificador que sirva para
relacionar dos o más conjuntos de datos. Además, son más robustas, es decir, tienen mayor
capacidad de almacenamiento, y son menos vulnerables ante fallas, estas son sus principales
características. Son las más utilizadas actualmente.

La determinación de su implementación radica en la presencia de alguno de los siguientes

casos:

 Cuando el volumen de los datos no crece o lo hace de manera gradual.

 Cuando las necesidades de proceso se pueden asumir en un solo servidor.
 Cuando no existen picos del sistema por parte de usuarios más allá de los previstos.

Imagen n°15 “Base de Datos Relacional”

Fuente:https://www.campusmvp.es/recursos/post/Disenando-una-base-de-datos-en-el-
modelo-relacional.aspx

2.3 Bases de Datos No Relacionales

Base de datos diseñadas específicamente para modelos de datos específicos y tienen esquemas
flexibles para crear aplicaciones modernas. Son ampliamente reconocidas porque son fáciles
de desarrollar, tanto en funcionalidad como en rendimiento a escala. Usan una variedad de
modelos de datos, que incluyen documentos, gráficos, clave-valor, en-memoria y búsqueda.

Las bases de datos no relacionales (NoSQL) son las que, a diferencia de las relacionales, no
tienen un identificador que sirva de relación entre un conjunto de datos y otros. Como
veremos, la información se organiza normalmente mediante documentos y es muy útil cuando
no tenemos un esquema exacto de lo que se va a almacenar.

La determinación de su implementación radica en la presencia de alguno de los siguientes

casos:

 Cuando el volumen de los datos crece muy rápidamente en momentos puntuales.

 Cuando tenemos picos de uso del sistema por parte de los usuarios en múltiples ocasiones.
 Cuando las necesidades de proceso no se pueden prever.

Imagen n°16 “Base de Datos No Relacional”

P á g i n a 12 | 73
Fuente: https://www.pragma.com.co/academia/lecciones/bases-de-datos-relacionales-vs.-no-
relacionales
2.4 Arquitectura de las Bases de Datos
Hay tres características importantes inherentes a los sistemas de bases de datos: la separación
entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los
usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de
la base de datos física. En esta arquitectura, el esquema de una base de datos se define en tres
niveles de abstracción distintos:

1. En el nivel interno se describe la estructura física de la base de datos mediante

un esquema interno. Este esquema se especifica mediante un modelo físico y
describe todos los detalles para el almacenamiento de la base de datos, así como
los métodos de acceso.
2. En el nivel conceptual se describe la estructura de toda la base de datos para una
comunidad de usuarios (todos los de una empresa u organización), mediante un
esquema conceptual. Este esquema oculta los detalles de las estructuras de
almacenamiento y se concentra en describir entidades, atributos, relaciones,
operaciones de los usuarios y restricciones. En este nivel se puede utilizar un
modelo conceptual o un modelo lógico para especificar el esquema.
3. En el nivel externo se describen varios esquemas externos o vistas de usuario.
Cada esquema externo describe la parte de la base de datos que interesa a un
grupo de usuarios determinados y ocultos a ese grupo el resto de la base de
datos. En este nivel se puede utilizar un modelo conceptual o un modelo lógico
para especificar los esquemas.

Imagen n°17 “Arquitectura de las Bases de Datos”

Fuente: https://desarrolloweb.com/articulos/arquitectura-base-de-datos.html

2.5 Bases de Datos en la Nube

Hay dos tipos principales de modelos de bases de datos en la nube.
P á g i n a 13 | 73
  El tradicional, que es muy similar a una base de datos in-situ y administrada
internamente, con la única diferencia del suministro de la infraestructura. En este
caso, una organización compra espacio de máquina virtual de un proveedor de
servicios en la nube y la base de datos se implementa en la nube. Los
desarrolladores de la empresa utilizan un modelo DevOps o personal informático
tradicional para controlar la base de datos. La organización se encarga de la
supervisión y la gestión de la base de datos.

 La base de datos como servicio (DBaaS), en el que una organización contrata un

servicio de suscripción de pago con un proveedor de servicios en la nube. El
proveedor de servicios ofrece diferentes tareas operativas, de mantenimiento,
administrativas y de gestión de bases de datos en tiempo real para el usuario
final. La base de datos se ejecuta en la infraestructura del proveedor de servicios.
Este modelo de uso suele incluir la automatización en las zonas de suministro,
copia de seguridad, escalabilidad, alta disponibilidad, seguridad, aplicación de
parches y supervisión del estado. El modelo DBaaS es el que aporta el mayor
valor a las organizaciones, ya que les permite emplear una gestión de base de
datos subcontratada y optimizada mediante la automatización de software, en
lugar de contratar y gestionar expertos internos.

Imagen n°18 “Base de Datos en la Nube”

Fuente: https://internet.com.co/base-de-datos-en-la-nube/
2.6 Big Data

Cuando hablamos de Big Data nos referimos a conjuntos de datos o combinaciones de

conjuntos de datos cuyo tamaño (volumen), complejidad (variabilidad) y velocidad de
crecimiento (velocidad) dificultan su captura, gestión, procesamiento o análisis mediante
tecnologías y herramientas convencionales, tales como bases de datos relacionales y
estadísticas convencionales o paquetes de visualización, dentro del tiempo necesario para que
sean útiles.

Aunque el tamaño utilizado para determinar si un conjunto de datos determinado se considera

Big Data no está firmemente definido y sigue cambiando con el tiempo, la mayoría de los
analistas y profesionales actualmente se refieren a conjuntos de datos que van desde 30-50
Terabytes a varios Petabytes.

 La naturaleza compleja del Big Data se debe principalmente a la naturaleza no estructurada de
gran parte de los datos generados por las tecnologías modernas, como los  web logs, la
identificación por radiofrecuencia (RFID), los sensores incorporados en dispositivos, la
maquinaria, los vehículos, las búsquedas en Internet, las redes sociales como Facebook,
computadoras portátiles, teléfonos inteligentes y otros teléfonos móviles, dispositivos GPS y
registros de centros de llamadas.

 En la mayoría de los casos, con el fin de utilizar eficazmente el Big Data, debe combinarse
con datos estructurados (normalmente de una base de datos relacional) de una aplicación

P á g i n a 14 | 73
comercial más convencional, como un ERP (Enterprise Resource Planning) o un CRM
(Customer Relationship Management).

Lo que hace que Big Data sea tan útil para muchas empresas es el hecho de que proporciona
respuestas a muchas preguntas que las empresas ni siquiera sabían que tenían. En otras
palabras, proporciona un punto de referencia. Con una cantidad tan grande de información, los
datos pueden ser moldeados o probados de cualquier manera que la empresa considere
adecuada. Al hacerlo, las organizaciones son capaces de identificar los problemas de una
forma más comprensible.

 La recopilación de grandes cantidades de datos y la búsqueda de tendencias dentro de los

datos permiten que las empresas se muevan mucho más rápidamente, sin problemas y de
manera eficiente. También les permite eliminar las áreas problemáticas antes de que los
problemas acaben con sus beneficios o su reputación.

Imagen n°19 “Big Data”

Fuente: https://www.akamai.com/es/es/products/network-operator/dnsi-big-data-
connector.jsp

2.7 Datamining

Data Mining (minería de datos) es el proceso de extracción de información significativa de

grandes bases de datos, información que revela inteligencia del negocio, a través de factores
ocultos, tendencias y correlaciones para permitir al usuario realizar predicciones que
resuelven problemas del negocio proporcionando una ventaja competitiva. Las herramientas
de Data Mining predicen las nuevas perspectivas y pronostican la situación futura de la
empresa, esto ayuda a los mismos a tomar decisiones de negocios proactivamente.
La minería de datos, Data Mining, es un proceso de descubrimiento de nuevas y
significativas relaciones, patrones y tendencias al examinar grandes cantidades de datos. La
disponibilidad de grandes volúmenes de información y el uso generalizado de herramientas
informáticas ha transformado el análisis de datos orientándose hacia determinadas técnicas
especializadas englobadas bajo el nombre de minería de datos o Data Mining. Las técnicas de
minería de datos persiguen el descubrimiento automático del conocimiento contenido en la
información almacenada de modo ordenado en grandes bases de datos. Estas técnicas tienen
como objetivo descubrir patrones, perfiles y tendencias a través del análisis de los datos
utilizando tecnologías de reconocimiento de patrones, redes neuronales, lógica difusa,
algoritmos genéticos y otras técnicas avanzadas de análisis de datos.
SAS Institute define el concepto de Data Mining como el proceso de Seleccionar (Selecting),
Explorar (Exploring), Modificar (Modifying), Modelizar (Modeling) y Valorar (Assessment)
grandes cantidades de datos con el objetivo de descubrir patrones desconocidos que puedan
ser utilizados como ventaja comparativa respecto a los competidores. Este proceso es
resumido con las siglas SEMMA. La siguiente figura ilustra las fases del proceso de minería
de datos según SAS Institute.
P á g i n a 15 | 73
 La minería de datos está incluida en un proceso mayor denominado Descubrimiento de
Conocimientos en Base de Datos, Knowledge Discovery in Data Dase (KDD).
Rigurosamente el Data Mining se restringe a la obtención de modelos, restando las etapas
anteriores y el propio Data Mining como instancias del KDD. La siguiente figura presenta el
esquema para la generación de conocimiento en bases de datos KDD.

Imagen n°20 “Data Mining”

Fuente: https://www.gestiopolis.com/que-es-data-mining/

2.8 Analítica de Datos

La analítica de datos se refiere a las técnicas y procesos cualitativos y cuantitativos utilizados

para mejorar la productividad y la ganancia de los negocios. Los datos se extraen y
categorizan para identificar y analizar datos y patrones de comportamiento, y las técnicas
varían según los requisitos de la organización.
La analítica de datos también se conoce como analítica de datos.

El análisis de datos se realiza principalmente en aplicaciones de empresa a consumidor

(B2C). Las organizaciones globales recopilan y analizan datos asociados con clientes,
procesos de negocios, mercados o experiencia práctica. Los datos son categorizados,
almacenados y analizados para estudiar las tendencias y patrones de compra.

La evolución de los datos facilita la toma de decisiones a fondo. Por ejemplo, un sitio web de
redes sociales recopila datos relacionados con las preferencias del usuario y los intereses y
segmentos de la comunidad de acuerdo con criterios específicos, como demografía, edad o
sexo. Un análisis adecuado revela las principales tendencias de los usuarios y los clientes y
facilita la alineación de contenido, diseño y estrategia general de la red social.

Las herramientas más populares de análisis de datos incluyen KNIME, Data Applied, R,
DevInfo y Zeptospace.

Imagen n°21 “Analítica de Datos”

P á g i n a 16 | 73
Fuente: https://cio.com.mx/que-veremos-en-la-analitica-de-datos-este-2019/

2.9 Servidores Físicos y Servidores en la Nube para el

Almacenamiento de los datos

El almacenamiento en la Nube sustituye al tradicional disco físico en todas las empresas que
pretende jugarse por la tecnología sin pagar de más.

Hay que considerar que los cambios en la tecnología se dan a gran velocidad, por lo que es
habitual que la dependencia de estructuras físicas por más capacidad que tengan, provoque
obsolescencia en los medios de tratamiento de la información de la empresa.

No se discute que en una empresa hay que mantener sistemas de almacenamiento y esto
supone un alto riesgo de seguridad para los datos almacenados. Aunque las grandes empresas
(que aún continúan manteniendo sus propios sistemas) se ven obligadas a contratar servicios
externos de seguridad informática.

Que almacenaje es mejor para una empresa

Inconvenientes del almacenamiento físico en la empresa. Las Pymes, en los últimos tiempos
son el objetivo de hackers y de virus Ransomware o Cryptolocker. Por estas falencias e
irregularidades, las pequeñas y medianas empresas son vulnerables a incidentes locales. No
son pocos los casos de empresas que usando un almacenamiento local han tenido que cerrar
debido a incidentes locales como: robos, incendios o inundaciones.

Ventajas de empresas al almacenar en la Nube

 Seguridad: El proveedor del almacenamiento en la Nube dispone de medidas de

seguridad excepcionales. Un proveedor Cloud dispone de equipos y personal que se
dedican en exclusiva a esta labor.
 Ahorro: El uso de la Nube para el almacenamiento online permite ahorros de hasta el
40% en hardware y software, del 31% en costes laborales de informática y del 80%
en el consumo energético de equipos.
 Movilidad: Todo el mundo maneja varios dispositivos como ordenadores, portátiles o
móviles. No se depende de un ordenador o un dispositivo para tener un documento a
mano.
 Independencia: Cuando se compraba un determinado software y un hardware
quedabas al resguardo cautivo de un sistema durante años. Se almacenaba en
servidores y discos duros que nos vendían y quedaban en casa.
 Productividad: El almacenamiento en la Nube o Cloud proporciona un entorno
colaborativo tanto para los individuos como a las empresas.

Problemas de disco físico

P á g i n a 17 | 73
 Existen muchos casos comunes en que la información se pierde simplemente por la rotura de
discos.
 Rotura disco duro almacenamiento físico
Costes de instalación y mantenimiento: En el coste de instalación han de incluirse la
compra de servidores, del software, elementos de red, su instalación y puesta en
marcha.

Además, los servidores son ruidosos y generan bastante calor por lo que es necesario adecuar
una ubicación bien refrigerada y que además no sea accesible fácilmente.

 Los cortes de sistema eléctrico o las subidas de tensión pueden provocar graves fallos
en los sistemas y para evitarlos, será necesario asumir también el coste de los
elementos de protección eléctrica necesarios.
 Movilidad y acceso a los datos: En plena era de la movilidad tanto los empleados
como los clientes consideran natural el acceso externo a la información.
 En la actualidad incluso existen argumentos sociales para exigir esa movilidad:
Proporcionar posibilidad de teletrabajo para evitar desplazamientos reduciendo el
impacto ecológico.
 Conciliación laboral: Escasa flexibilidad y escalabilidad de los medios. El
almacenamiento físico se encuentra limitado a la capacidad de los medios locales.
o
Es por ello que cuando se adquieren estos medios, ya sean servidores o dispositivo de
almacenamiento como discos NAS se tiende a sobredimensionar sus capacidades para no
quedarse corto a medio plazo.

Imagen n°22 “Servicio Físico y Servidores en la Nube para el Almacenamiento de los datos”

Fuente: http://openaccess.uoc.edu/webapps/o2/bitstream/10609/75925/11/Dise%C3%B1o
%20y%20administraci%C3%B3n%20de%20arquitecturas%20Cloud_M%C3%B3dulo%201_
%20Fundamentos%20y%20plataformas%20de%20cloud%20computing.pdf

2.10 Sistemas Gestores de Bases de Datos (mínimo 4 SGBD SQL y 4 SGBD

NoSQL)

Un gestor de base de datos o SGBD es una colección de programas cuyo objetivo es servir de
interfaz entre la base de datos, el usuario y las aplicaciones. Se compone de un lenguaje de
definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.

Un SGBD permite definir los datos a distintos niveles de abstracción y manipular dichos
datos, garantizando la seguridad e integridad de estos.

Un SGBD debe poseer las siguientes facultades:

 Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
 Construir la base de datos: guardar los datos en algún medio controlado por el mismo
SGBD
 Manipular la base de datos: realizar consultas, actualizarla, generar informes.

P á g i n a 18 | 73
Las características de un Sistema Gestor de Base de Datos SGBD son:
 Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del
almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o
cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios
niveles de abstracción.
 Independencia. La independencia de los datos consiste en la capacidad de modificar el
esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las
aplicaciones que se sirven de ella.
 Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición
de información repetida o redundante. De entrada, lo ideal es lograr una redundancia
nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la
aparición de redundancias.
 Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, será
necesario vigilar que aquella información que aparece repetida se actualice de forma
coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea.
 Seguridad. La información almacenada en una base de datos puede llegar a tener un
gran valor. Los SGBD deben garantizar que esta información se encuentra seguridad
frente a usuarios malintencionados, que intenten leer información privilegiada; frente a
ataques que deseen manipular o destruir la información; o simplemente ante las
torpezas de algún usuario autorizado pero despistado. Normalmente, los SGBD
disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que
permiten otorgar diversas categorías de permisos.
 Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los
datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware,
datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de
corromper la información almacenada.
 Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de
realizar copias de respaldo de la información almacenada en ellos, y de restaurar a
partir de estas copias los datos que se hayan podido perder.
 Control de la concurrencia. En la mayoría de los entornos (excepto quizás el
doméstico), lo más habitual es que sean muchas las personas que acceden a una base
de datos, bien para recuperar información, bien para almacenarla. Y es también
frecuente que dichos accesos se realicen de forma simultánea. Así pues, un SGBD
debe controlar este acceso concurrente a la información, que podría derivar en
inconsistencias.

Imagen n°23 “Teorema Cap SGBD”

Fuente: https://openwebinars.net/blog/que-es-apache-cassandra/

P á g i n a 19 | 73
Ejemplos de SGBD SQL

 Oracle Database: Base de datos de estilo SQL de tipo objeto-relacional (ORDBMS)

desarrollada por Larry Ellison, Bob Miner yEd Oates en 1979 para su empresa Oracle
(Fundada en 1977), la cual cuenta con lenguajes de programación como Java, C y C++.
Cabe destacar que se primera versión se llamo Oracle2, para generar confianza en el
producto por parte de los consumidores. Esta a su vez fue la primera base de datos
relacional del mundo.

Dentro de sus funciones están:

 Oracle Database es multiplataforma. Puede ejecutarse en varios hardware en

sistemas operativos, incluidos Windows Server, Unix y varias distribuciones de
GNU / Linux.

 Oracle Database tiene su pila de redes que permite que las aplicaciones de una
plataforma diferente se comuniquen sin problemas con Oracle Database. Por
ejemplo, las aplicaciones que se ejecutan en Windows pueden conectarse a la
base de datos de Oracle que se ejecuta en Unix.

 Compatible con ACID: Oracle es una base de datos compatible con ACID que
ayuda a mantener la integridad y confiabilidad de los datos.

 Compromiso con las tecnologías abiertas: Oracle es una de las primeras bases de
datos que admitió GNU / Linux a fines de la década de 1990 antes de que GNU /
Linux se convirtiera en un producto comercial. Ha estado apoyando esta
plataforma abierta desde entonces.

También posee las siguientes características:

 Estructura de datos lógica: Oracle usa la estructura de datos lógica para

almacenar datos de modo que pueda interactuar con la base de datos sin saber
dónde se almacenan físicamente.

 Partición: es una función de alto rendimiento que le permite dividir una mesa
grande en diferentes piezas y almacenar cada pieza en los dispositivos de
almacenamiento.

 Almacenamiento en caché de memoria: la arquitectura de almacenamiento en

caché de memoria le permite escalar una base de datos muy grande que aún
puede funcionar a alta velocidad.

 El diccionario de datos es un conjunto de tablas y vistas internas que permiten

administrar Oracle Database de forma más eficaz.

 Copia de seguridad y recuperación: asegure la integridad de los datos en caso de

falla del sistema. Oracle incluye una poderosa herramienta llamada Recovery
Manager (RMAN): permite al DBA realizar copias de seguridad de bases de
datos en frío, en caliente e incrementales y recuperaciones puntuales.

 Agrupación: Oracle Real Application Clusters (RAC): Oracle permite una alta
disponibilidad que permite que el sistema esté en funcionamiento sin interrupción
de los servicios en caso de que falle uno o más servidores de un clúster.

Actualmente posee las siguientes ediciones:

1) Enterprise Edition (EE).
2) Standard Edition (SE).
P á g i n a 20 | 73
 3) Standard Edition One (SE1)
4) Standard Edition 2 (SE2)
5) Express Edition (XE).
6) Personal Edition (PE).
7) Lite Edition (LE).

Dentro de sus versiones destacan

 Oracle 2 (1979) Comprada en 1979 por la base de la Fuerza Aérea
Estadounidense de Wright-Patterson
 Oracle 3 ( ) Podía correr sobre 30 plataformas distintas
 Oracle 6 (1991) Puede ser ejecutado en plataformas masivas y paralelas
 Oracle 7 (1993) Cuenta con optimizadores sugeridos por el usuario y
programación a nivel de base de datos
 Oracle 8 (1997) Incorpora Orientación a objetos y capacidad masiva de
almacenamiento
 Oracle 8i (1999) Incorpora orientación a servicios de internet y adición de
programación en java
 Oracle 9i (2000) Aplicaciones con servicios de 3 capas
 Oracle 9i(2001) Adición de Clústeres para servicios críticos
 Oracle 19c (Versión actual)

Imagen n°24 “Oracle Database”

Fuente: https://neuronet.cl/licenciamiento-oracle-standard-edition2/

 Microsoft SQL Server: Base de datos de estilo SQL desarrollada por Microsoft
lanzado el 24 de abril de 1989, teniendo como antecesor a Sybase SQL en 1988. SQL
Server esta escrito en C y C++. Su función principal es la de almacenar y recuperar
datos según lo solicitado por otras aplicaciones.

Dentro de sus características se encuentran:

 Soporte de transacciones.
 Escalabilidad, estabilidad y seguridad.
 Soporte de procedimientos almacenados.
 Incluye también un potente entorno gráfico de administración, que permite el
 uso de comandos DDL y DML gráficamente.
 Permite trabajar en modo cliente-servidor, donde la información y datos se
alojan en el servidor y las terminales o clientes de la red solo acceden a la
información.
 Permite administrar información de otros servidores de datos.

Sus ediciones son:

P á g i n a 21 | 73
 1) DataCenter
2) Enterprise
3) Standard
4) Web (Azure)
5) Business Intelligence
6) Express

Dentro de sus versiones destacan:

 SQL Server 2000

 SQL Server 2005
 SQL Server 2008
 SQL Server 2012
 SQL Server 2014
 SQL Server 2016
Imagen n°25 “Microsoft SQL Server”

Fuente: https://www.muylinux.com/2018/02/16/sql-server-on-linux-evento/

 Postgre SQL:  Gestor de bases de datos relacional y orientado a objetos. Su licencia y

desarrollo es de código abierto, siendo mantenida por una comunidad de
desarrolladores, colaboradores y organizaciones comerciales de forma libre y
desinteresadamente. Esta comunidad es denominada PDGD (PostgreSQL Global
Development Group, por sus siglas en inglés). presenta varias características por las
que destaca, siendo uno de los mejores y más utilizados motores de BD en la
actualidad. Dentro del teorema CAP, PostgreSQL se encuentra en CA, puesto que está
enfocada en la alta disponibilidad (Aviability) y la consistencia (Consistency) de los
datos, sacrificando la tolerancia a las particiones (Partition tolerance).

 Entre sus características destacan:

 Presenta un sistema de alta concurrencia: Presenta un sistema denominado

MVCC, el cual permite que mientras un proceso escribe una tabla, otros puedan
acceder a la misma tabla sin necesidad de verse bloqueados, y cada usuario obtiene
una visión consistente.

 Sistema "Hot Standby": Este proceso permite a los usuarios poder conectarse con
el servidor y ejecutar búsquedas en la BBDD mientras la misma está en modo de
recuperación o "stand by". También se puede pasar de este modo a modo normal
sin detener el flujo de búsquedas o consultas de los usuarios, manteniendo las
conexiones abiertas. Esto es posible únicamente cuando la base de datos se
encuentra en modo de solo-lectura.

 Soporte nativo: PostgreSQL presenta soporte nativo para los siguientes tipos de

datos:

P á g i n a 22 | 73
 1. Texto de largo ilimitado.
2. Números de precisión arbitraria.
3. Figuras geométricas con funciones asociadas.
4. Direcciones MAC.
5. Protocolos de direcciones IP (tanto IPv4 como IPv6).
6. Bloques de direcciones CDIR.
7. Arrays.
8. Tipos de datos propios de los usuarios.

 Uso de formato JSON: El formato JSON se convierte en el punto débil de muchos

sistemas de bases de datos relacionales. Sin embargo, PostgreSQL presenta buenas
herramientas con las que es posible indexar elementos y realizar búsquedas en
dicho formato. Aunque no se recomienda manejar toda la base de datos en JSON, y
se utiliza para el guardado de información de algunos elementos e indexar sus
propiedades.

 Notificaciones a tiempo real: A pesar de que PostgreSQL no fue diseñada para ser
una BD que trabaje al 100% en tiempo real, si es posible mantener sincronizado en
varios dispositivos un sistema de notificación para cuando se hacen cambios
específicos en la base de datos, gracias a las funciones LISTEN, UNLISTEN y
NOTIFY.

 Registro y guardado de transacciones: Una de las características más

interesantes de PostgreSQL, es su capacidad de registrar cada transacción en un
WAL (Write-Ahead-Log). Esto permite restaurar la base de datos a cualquier punto
previamente guardado, una especie de "Checkpoint". Esto permite que no sea
necesario realizar respaldos completos de forma frecuente, en especial para los
casos en los que se trabaja con una BBDD que es muy grande o que contiene
mucha cantidad de datos.

 Disparadores o triggers: En PostgreSQL, un disparador se define como la

ejecución de un procedimiento almacenado, basado en una acción determinada
sobre una tabla específica en la base de datos.
Estos disparadores se pueden definir por 6 características:

1. Nombre del disparador.

2. Momento de arranque definido.
3. Evento del disparador.
4. Tabla dónde se ejecuta.
5. Frecuencia de ejecución.
6. Función llamada / Función correcta o incorrecta.

Ventajas de PostgreSQL
 Instalación y uso gratuito.
 Sistema disponible Multiplataforma
 Estabilidad
 Escalabilidad y configuración
 Estándar SQL
 Herramienta gráfica 
 Robustez y fiabilidad 
 Soporte y ayuda

Imagen n°26 “Postgre SQL”

P á g i n a 23 | 73
 Fuente: https://ubunlog.com/liberada-la-nueva-version-de-postgresql-12-y-estas-son-
sus-novedades/

 MySQL: Base de datos SQL desarrollada inicialmente Michael Widenius quien

posteriormente fundo MySQL AB como empresa que continuaría el proyecto hasta que
MySQL fue adquirida por Sun MicroSystems en 2008 y esta su vez comprada por Oracle
Corporation en 2010, la cual ya era dueña de un motor propio InnoDB para MySQL. Este
sistema posee doble licencia, puesto que por una parte es de código abierto, pero también
posee una versión comercial gestionada por la compañía Oracle.

Dentro del teorema CAP, MySQL se encuentra en CA, puesto que está enfocada en la
alta disponibilidad (Aviability) y la consistencia (Consistency) de los datos,
sacrificando la tolerancia a las particiones (Partition tolerance).

Dentro de sus características se encuentran:

 Arquitectura Cliente y Servidor: MySQL basa su funcionamiento en un modelo

cliente y servidor. Es decir, clientes y servidores se comunican entre sí de
manera diferenciada para un mejor rendimiento. Cada cliente puede hacer
consultas a través del sistema de registro para obtener datos, modificarlos,
guardar estos cambios o establecer nuevas tablas de registros, por ejemplo.

 Compatibilidad con SQL: SQL es un lenguaje generalizado dentro de la

industria. Al ser un estándar MySQL ofrece plena compatibilidad por lo que si
has trabajado en otro motor de bases de datos no tendrás problemas en migrar a
MySQL.

 Vistas: Desde la versión 5.0 de MySQL se ofrece compatibilidad para poder

configurar vistas personalizadas del mismo modo que podemos hacerlo en otras
bases de datos SQL. En bases de datos de gran tamaño las vistas se hacen un
recurso imprescindible.

 Procedimientos almacenados. MySQL posee la característica de no procesar las

tablas directamente, sino que a través de procedimientos almacenados es
posible incrementar la eficacia de nuestra implementación.

 Desencadenantes. MySQL permite además poder automatizar ciertas tareas

dentro de nuestra base de datos. En el momento que se produce un evento otro
es lanzado para actualizar registros o optimizar su funcionalidad.

 Transacciones. Una transacción representa la actuación de diversas operaciones

en la base de datos como un dispositivo. El sistema de base de registros avala
que todos los procedimientos se establezcan correctamente o ninguna de ellas.
En caso por ejemplo de una falla de energía, cuando el monitor falla u ocurre
algún otro inconveniente, el sistema opta por preservar la integridad de la base
de datos resguardando la información.

También su elección conlleva ciertas ventajas, es una opción diseñada para el

ámbito empresarial, permitiendo gracias a su código abierto la disposición de
una solución fiable y estandarizada tanto para desarrolladores como para
pequeñas empresas.

P á g i n a 24 | 73
 Dentro de su historial de versiones destacan:

1) First Release (1995)

2) Open Source (2000)
3) v3.23 (2001)
4) v4.0 (2003)
5) v5.0 (2005)
6) v5.1 (2008)
7) v5.5 (2009)

Imagen n°27 “MySQL”

Fuente: https://www.anerbarrena.com/mysql-limit-5553/

Ejemplos SGBD NoSQL

 Cassandra: Base de Datos No-SQL lanzada en el año 2008, creada inicialmente por
Facebook y posteriormente traspasada a Fundación Apache, lo que trajo consigo la
transformación a una herramienta Open Source, que a la fecha sigue manteniendo.
Dentro del teorema CAP, Cassandra se encuentra en AP, puesto que está enfocada en
la alta disponibilidad (Aviability) y la tolerancia a las particiones (Partition tolerance),
sacrificando su consistencia (Consistency).

Entre sus características se encuentran:

 Es una base de datos distribuida, es decir, vamos a tener nuestros servidores

distribuidos.

 Escala linealmente, lo que significa que, como vemos en la imagen, si tenemos dos
nodos, vamos a poder realizar 100000 operaciones por segundo. Si tuviéramos
cuatro nodos podremos realizar el doble de operaciones, y así sucesivamente, cada
vez que dupliquemos el número de nodos, duplicaremos el número de operaciones
por segundo.

 No sigue un patrón maestro-esclavo, sino que es peer-to-peer o P2P. Esto lo que

conlleva es que, si se cae un nodo, el servicio puede seguir funcionando, no como
en el patrón maestro-esclavo, en el que, de forma resumida, si se cae el maestro el
sistema cae también.

 Permite la escalabilidad horizontal, que es diferente a la escalabilidad vertical. En

la segunda lo que se aumenta es la máquina, como por ejemplo tener una máquina
con 16 gigas de RAM y la aumentamos a 32 gigas de RAM. Y en la primera
tenemos una máquina con 16 gigas de RAM y lo que hacemos es poner otra
máquina también con 16 gigas de RAM trabajando en paralelo con la otra.

 Es tolerante a fallos, gracias a que posee la replicación de datos, es decir, los datos
cuando son escritos en un nodo se replican en otros nodos, por lo que, si uno de
estos nodos cae, no pasa nada porque el dato está replicado en otros dos.

 Permite definir el nivel de consistencia.

 Usa el lenguaje CQL, que es un lenguaje muy similar a SQL.

P á g i n a 25 | 73
  Permite la replicación en varios data center, siendo cada data center un anillo de
máquinas Cassandra, ya que permite que el anillo 1 replique sus datos en el anillo
2.

 Es Open Source.

 Tiene una consistencia ajustable, es decir, en el Teorema CAP podemos tirar un

poco más de consistencia a costa de perder de las siglas del mismo.

 Tiene una fácil escalabilidad.

Ventajas:

 Alta disponibilidad, lo que es muy interesante para el sistema en los que una caída
sea crucial.

 Tolerancia a particiones y escalado.

 Cantidad de recursos que se tienen disponibles.

Imagen n°28 “Cassandra”

Fuente: https://www.dblandit.com/cassandra.html

 Riak: Base de datos Key-Value distribuida de código abierto escrita principalmente en

Erlang, también escrita en C y JavaScript, que posee gran disponibilidad, con alta
escalabilidad y se basa en el sistema de almacenamiento Dynamo

Dentro del teorema CAP, Riak se encuentra en AP, puesto que está enfocada en la alta
disponibilidad (Aviability) y la tolerancia a las particiones (Partition tolerance),
sacrificando su consistencia (Consistency).

Dentro de sus características se encuentran:

 RESISTENCIA: Incluso si las particiones de la red o las fallas de hardware causan

interrupciones imprevistas, Riak KV aún puede leer y escribir sus datos.

 ESCALABILIDAD MASIVA: La arquitectura de escalamiento horizontal de Riak KV

le permite agregar capacidad sin problemas utilizando hardware básico para una
mejora del rendimiento casi lineal.

 SIMPLICIDAD OPERACIONAL: Agregue fácilmente nodos a Riak KV para que sus

datos se puedan distribuir de manera automática y uniforme en todo el clúster.

 REPLICACIÓN INTELIGENTE: .Riak KV está diseñado para replicar y recuperar

datos de manera inteligente para que su aplicación de Big Data, IoT o nube híbrida esté
siempre disponible.

P á g i n a 26 | 73
 SOPORTE PARA CONSULTAS COMPLEJAS: Riak KV le ofrece tres formas de
consultar datos mediante la búsqueda de texto completo de Solr, índices secundarios y
Map Reduce.

 VENCIMIENTO DEL OBJETO GLOBAL: Riak KV incluye Vencimiento de objeto

global para permitirle especificar cuándo se eliminan los datos antiguos de la base de
datos. Una vez configurados, los datos se eliminarán de forma automática y eficaz.

 VECTORES DE VERSIÓN CON PUNTOS (DVV s ): Riak KV realiza un

seguimiento del tiempo lógico en lugar del tiempo cronológico para resolver conflictos
de objetos de forma rápida y automática.

 TIPOS DE DATOS DISTRIBUIDOS DE RIAK: Riak KV proporciona tipos de datos

prediseñados para las estructuras de datos más comunes que requieren las cargas de
trabajo activas distribuidas.
 POTENTE API s Y LIBRERÍAS CLIENTE: Código en Java, Ruby, Python, C #,
Erlang, Node.js o .NET: Riak KV facilita la selección del idioma que necesita su
aplicación.

 CONECTOR CHISPA: La integración de Apache Spark con Riak KV proporciona el

análisis en tiempo real de Spark con la disponibilidad y escalabilidad de Riak.

 MARCO APACHE MESOS: Riak Meso Framework proporciona administración de

recursos de clúster y escalado hacia arriba o hacia abajo de "botón pulsador" para los
nodos Riak.

 INTEGRACIÓN DE LA BASE DE DATOS REDIS: Redis Add-on une el poder del

almacenamiento en caché de Redis con las eventuales garantías de consistencia de
Riak KV.

 REPLICACIÓN MULTI-CLÚSTER: Riak KV facilita la replicación de clústeres en su

centro de datos o en todo el mundo para la geolocalización de datos, análisis
secundarios o continuidad comercial.

Imagen n°29 “Riak”

Fuente: https://www.master-bigdata.com/riak-sistemas-nosql-todos-los-gustos/

 CouchDB: Base de datos orientada a documentos desarrollada por Damien Katz en

abril de 2005, en 2008 paso a ser parte de Apache Incubator y su licencia cambio a
Apache Licence, es de genero RDBMS y parte de la familia Apache. Posee una
semántica ACID y se puede consultar en ella utilizando el lenguaje JavaScript en una
forma MapReduce (funciones que se definen en JavaScript), donde la función Map
recibe como parámetro el propio documento donde se ejecuta y puede devolver pares
de clave-valor y la función Reduce agrupa los resultados del Map para obtener un
número. También ofrece replicación incremental con detección de conflictos
bidireccional y resolución.

Dentro del teorema CAP, Riak se encuentra en AP, puesto que está enfocada en la alta
disponibilidad (Aviability) y la tolerancia a las particiones (Partition tolerance),
sacrificando su consistencia (Consistency).

Dentro de sus características están:

P á g i n a 27 | 73
  Base de datos de nodo único: CouchDB es una excelente base de datos de un solo
nodo que funciona como cualquier otra base de datos detrás de un servidor de
aplicaciones de su elección.
La mayoría de las personas comienzan con una instancia de CouchDB de un solo
nodo. Los proyectos más exigentes pueden actualizarse sin problemas a un clúster.

 Racimo: CouchDB es también una base de datos agrupada que le permite ejecutar

un único servidor de base de datos lógica en cualquier número de servidores o
máquinas virtuales.
Un clúster de CouchDB mejora la configuración de un solo nodo con mayor
capacidad y alta disponibilidad sin cambiar ninguna API.

 HTTP / JSON: CouchDB utiliza el omnipresente protocolo HTTP y el formato de

datos JSON y es compatible con cualquier software que los admita. CouchDB
también funciona muy bien con herramientas externas como servidores proxy
HTTP, balanceadores de carga.

 Primera sincronización de datos sin conexión: El protocolo de replicación único de

CouchDB es la base de toda una nueva generación de aplicaciones "Offline
First" para aplicaciones móviles y otros entornos con infraestructuras de red
desafiantes .

 Ecosistema: CouchDB está diseñado para servidores (desde una Raspberry Pi hasta
grandes instalaciones en la nube), mientras que PouchDB está diseñado para
navegadores web móviles y de escritorio y Couchbase Lite está diseñado para
aplicaciones nativas de iOS y Android.
Y todos ellos pueden replicar datos entre sí sin problemas.

 Fiabilidad: CouchDB se toma en serio la fiabilidad de los datos.

Los nodos individuales utilizan una estructura de datos de solo adición resistente a
fallas. Un clúster CouchDB de varios nodos guarda todos los datos de forma
redundante, por lo que siempre están disponibles cuando los necesita.

Imagen n°30 “CouchBD”

Fuente: https://prezi.com/0hyzdzgjddeq/couchdb/

 MongoDB: Base de datos de documentos que ofrece una gran escalabilidad y

flexibilidad, en conjunto con un modelo de consultas e indexación avanzado. Los datos
en esta base de datos son almacenados en documentos, los cuales a su vez son
almacenados en BSON, que es una representación binaria de JSON. Este escrito en C+
+, aun así las consultas se realizan pasando objetos JSON como parámetro. También
posee drivers para la implementación de lenguajes como C#, Java, Node.JS, PHP,
Python, Ruby, C, Perl o Scala. Esta base de datos puede ser utilizada siempre y cuando
no se necesiten las transacciones, tampoco posee JOINS.

Dentro de sus características están:

P á g i n a 28 | 73
  Alta disponibilidad a través de la replicación y la conmutación por error
integradas
 Escalabilidad horizontal con fragmentación nativa
 Seguridad de extremo a extremo
 Validación de documentos nativos y exploración de esquemas con Compass
 Herramientas de administración para automatización, monitoreo y respaldo
 Base de datos como servicio totalmente elástico con mejores prácticas
integradas
 MongoDB almacena datos en documentos flexibles similares a JSON, lo que
significa que los campos pueden variar de un documento a otro y la estructura
de los datos se puede cambiar con el tiempo
 El modelo de documento se asigna a los objetos en el código de su aplicación,
lo que facilita el trabajo con los datos.
 Las consultas ad hoc, la indexación y la agregación en tiempo real brindan
formas poderosas de acceder y analizar sus datos
 MongoDB es una base de datos distribuida en su núcleo, por lo que la alta
disponibilidad, el escalado horizontal y la distribución geográfica están
integradas y son fáciles de usar
 MongoDB es de uso gratuito. Las versiones publicadas antes del 16 de octubre
de 2018 se publican bajo la AGPL. Todas las versiones publicadas después del
16 de octubre de 2018, incluidas las correcciones de parches para versiones
anteriores, se publican bajo la Licencia pública del lado del servidor (SSPL)
v1 .

Imagen n°31 “MongoBD”

Fuente: http://www.bacula.lat/backup-bases-mongodb-com-plugin-bacula-
bpipe/?lang=es

P á g i n a 29 | 73
 III.ANTECEDENTES GENERALES

3.1 Empresa

3.1.1 Descripción de la Empresa

Empresa con rubro de Joyería, enfocada en la distribución de joyas de oro, baño de oro y
plata, joyas de plata 925 y 950(Mapuche), joyas de acero quirúrgico y bisutería.

Imagen n°32

Fuente: https://www.joyeriarayun.cl/

3.1.2 Visión

Lograr una mayor accesibilidad a productos de gran calidad y diseños exclusivos a precios
justos para todos los consumidores.

3.1.3 Misión

Nuestra misión es servir a las diversas necesidades de estilo de accesorios ornamentales para
el cuerpo, con una atención personalizada y cálida, generando un ambiente de confianza para
nuestros clientes.

3.1.4 Objetivos Estratégicos

P á g i n a 30 | 73
->Innovación permanente en los diseños de los productos.
->Mantener la exclusividad de la mayoría de nuestros productos a nivel nacional.
->Precios acorde al diseño y materiales utilizados.
-> Dentro de nuestra línea de joyería Mapuche, buscamos dar a conocer tanto los diseños
como la técnica empleada por nuestros orfebres originarios del pueblo Mapuche.

3.1.5 Localización (mapa)

Imagen n°33“Localización de la Joyería”

Fuente:https://www.google.com/maps/place/Arturo+Prat+439,+Temuco,
+Araucan%C3%ADa/data=!4m2!3m1!
1s0x9614d3dd74dbaf25:0x1ddf9e1e607204e2?sa=X&ved=2ahUKEwjRh6-
Rqt_sAhWoIbkGHchlDCkQ8gEwAHoECAsQAQ

3.1.6 Mapa organizacional u Organigrama

Diagrama n°1 “Mapa Organizacional”

P á g i n a 31 | 73
 EMPRESA

CEO

DEPTO INFORMATICA DEPTO MARKETING DEPTO R.HUMANOS DEPTO FINANZAS DEPTO MANUFACTURA TIENDAS

VENDEDOR

JEFE DEPTO JEFE DEPTO JEFE DEPTO JEFE DEPTO JEFE DEPTO

EMPLEADOS EMPLEADOS EMPLEADOS EMPLEADOS EMPLEADOS

Fuente: Diagrama Propio (Visio)

3.1.7 Situación Actual de BBDD y herramientas tecnológicas que

utiliza la organización
. Utilice una tabla para el nombre, descripción del software y la utilización que
tiene en la organización. Entregue la arquitectura tecnológica que tiene la
organización. Utilice imágenes, esquemas u otros.
Actualmente la empresa no ha implementado un sistema gestor de base de datos. Las
herramientas empleadas tanto para el apartado Informático como para el apartado contable,
se utiliza Excel, drive, Gmail, con respecto a los ámbitos de Marketing, Ventas, R. Humanos,
Manufactura, Proveedores y web, se utiliza tanto drive, como la página web correspondiente,
Transbank.

Tabla n°1
Nombre Descripción Utilización
Excel Hoja de Calculo Balances de cuenta, Manejo
de stock, registro de clientes
Drive Almacenamiento en la Nube Almacenamiento de
Información
Gmail Correo Electrónico Coordinar y Envió de
información
Transbank Plataforma Transferencias Medio de transferencia de
Bancarias fondos de consumidor a
empresa
Pag Web Plataforma Venta por Venta por Internet
Internet
Plataforma de Facturación Plataforma de Facturación Facturación a revendedores
y venta por internet

3.1.8 Muestre y explique brevemente los datos, información,

resultados, estadísticas, reportes u otros que se maneja, proceso y
gestiona la información.

P á g i n a 32 | 73
 Para las compras de un revendedor:

 Identificación Revendedor
 Rubro
 Nombre Revendedor
 Cantidad
 Precio al cual adquiere el/los productos
 Código Producto
 Fecha
 Identificación Factura
 Rut revendedor (empresa o persona natural)

Para las Compras por Internet:

 Identificación Transacción
 Identificación cliente
 Fecha de Compra
 Cantidad
 Precio al cual adquiere el/los productos
 Cupón de descuento
 Identificación Factura
 Identificación Envió
 Identificación de la Orden

Para las ventas en tienda física:

 Identificación de la tienda
 Identificación del vendedor
 Cantidad
 Precio al cual se adquiere el producto
 Medio de Pago
 Numero de Boleta
 Identificación Cliente

En los departamentos en conjunto comparten

 Identificación del jefe

 Identificación empleados
 Código del departamento
 Atributos exclusivos de cada departamento

Se estima que la empresa posee un patrimonio de $100M, con unos pasivos evaluados en
$100M, a su vez a nivel contable, ha reportado ganancias por $50 M.

En conjunto con lo anterior, se tasa que la cantidad promedio de joyas vendidas según su
categoría es la siguiente:

Tabla n°2
Tipo de Joya Unidades vendidas estimadas
Oro 18k 50
Bañada en Oro 1000
Bañada en Plata 600
Plata 925 1000
Acero Quirúrgico 3000
Bisutería 700
Plata 950 (Mapuche) 1000

3.2 Descripción de la problemática

3.2.1Explique claramente la problemática

Últimamente la joyería Rayun, como muchas otras empresas se ha visto afectada por la
contingencia mundial del COVID-19, teniendo que reinventarse y adaptarse a una forma
mucho más “online” de llevar el negocio, específicamente en tema de movimiento de datos

P á g i n a 33 | 73
es de suma urgencia pasar todo a modalidad virtual, ya que la atención y manipulación de
manera presencial será solo para casos en los que se necesita demasiado.

3.2.2 Efecto que tiene en la organización la problemática,

indicando departamentos y actores involucrados.

Tanto el departamento de Marketing como el departamento de Informática se han visto

obligados a cambiar los enfoques, por lo que la cantidad de horas y recursos destinados a los
mismos se ha visto aumentada.

Por parte de las tiendas físicas, por la situación se encuentra operativa solo la primaria,
siempre y cuando no se decrete cuarentena en la zona. También se ha visto reducido el
presupuesto de recursos humanos con el fin de mantener los gastos a números anteriores a la
problemática.

De manera momentánea se ha disminuido la cantidad de horas de trabajo y muchos

empleados en conjunto con joyeros han tenido que ser trasladados, por lo que los gastos de
traslado se han visto incrementados.

El departamento de Finanzas si bien se ha visto obligado a ajustar su horario, no ha visto un

descenso en su presupuesto.

Diagrama n°2 “Efecto en la Organización”

PARA RECURSOS MANTIENE COVID DISMINUIR RECURSOS

AUMENTAR PARA TIENDAS

FINANZAS

RECURSOS R.HUMANOS

MARKETING PARA MANUFACTURA

INFORMATICA

Fuente: Propia (Visio)

P á g i n a 34 | 73
 3.3 Objetivo general y Objetivos específicos

3.3.1 Objetivo general de la propuesta de solución de la Base de

Datos

Analizar y diseñar una base de datos en la que la empresa puede organizar su infraestructura,
procesos internos y externos en un solo lugar, evitando errores, repeticiones o pérdida de
datos. En esta base datos se encontrarán las principales entidades relacionadas y se podrán
almacenar todos los datos de pertinencia la empresa rayun.

3.3.2 Objetivos específicos.

Con el diseño e implementación de la base de datos se busca:

->organizar un diagrama de todas las entidades correspondientes.
->relacionar las entidades mediante claves - llevar registro de todos los movimientos
ocurridos.
->Generar tablas que permitan organizar la información registrada.
->Disminución la perdida de información por incompatibilidad de formatos.
->Implementación de un ambiente más ergonómico para los departamentos que lo utilicen.
->Permitir un acceso de manera remota a la información de manera rápida y eficiente.
->Aumentar la seguridad en la recopilación y almacenamiento de datos.
->Aumentar la productividad

IV.ANÁLISIS DE LA BASE DE DATOS

4.1 Descripción de la situación de la Empresa

La empresa rayun necesita con urgencia una modernización de sistema, para la cual se
requerirá una base de datos que pueda virtualizar toda la información en un solo lugar. 

Esta empresa es del tipo joyería y cuenta con acreedores, su respectivo Rut y número
de empleados específicos; también posee un valor específico en el mercado. 

La empresa posee un stock de productos, y dicho stock está determinado por la fecha
actual, la cantidad, la ubicación, el precio actual de la unidad y precio especial en caso
de corresponder.

Los productos mencionados en stock se venden con id propia, un diseño específico,

tamaño determinado, tipo, material y precio.

Las ventas pueden ser de 3 distintas maneras y según la forma contar o no con factura
(id, desglose, fecha, nom_empresa, nom_P.N. N, tel.).

-Ventas en Tienda física:

La cual posee un id, y lleva registro de la cantidad vendida, el medio de pago, el precio
total a pagar y el número de boleta correspondiente a la compra.

Para este caso la tienda posee un vendedor que cuenta con su id, su salario, comisión
por venta, y las horas que dispone (hrs_base y hrs_extra) 

-Ventas por internet:

En las que se registra fecha de compra, cantidad comprada, precio, id de la orden y el

código de descuento en caso de haberlo. Para realizar la compra se realiza una

P á g i n a 35 | 73
 transacción que cuenta con datos específicos (id, medio de pago, precio total, nombre
titular, hora transacción).

En estas ventas se realiza factura. Al ser comprado un producto de esta forma se realiza
un envío, para los que se registran datos necesarios del mismo (id, destino, fecha de
orden, cod postal, fecha envío y destinatario), estos envíos se realizan mediante de un
transportista contratado del que se sabe su id, compañía y patente. Además de los datos
que él solicita (peso y dimensión del paquete)

-Ventas a revendedores: por último, la joyería también realiza ventas a revendedores a

los que se les piden ciertos datos antes de poder vender la marca como: id, cantidad,
nombre, Rut, rubro, correo y precio de reventa. Para estas ventas también se realiza
factura.

Los primeros dos tipos de ventas son adquiridos por clientes propios de la empresa a
los cuales se les almacenan datos de información (id, nombre, teléfono, Rut, código
postal, correo).

La empresa a su vez también tiene que comprar insumos (descripción, cantidad,

id_insumo, precio unidad, precio total, material) de materia prima para generar sus
productos, estos insumos son suministrados por un proveedor (id, dir_facturación,
medio de pago, nom_titular, tel.).

En cuanto a la organización de rayun, esta cuenta con un central,(provincia, capacidad,

ciudad, infraestructura, dirección) y la central tiene distintos departamentos, 5  para ser
exactos, cada cual cuenta con sus datos específicos: Manufactura (diseños,
cod_manu, detalle, materiales, producción, piso), Recursos Rumanos (id_caso,
id_reclamos, cód_R.Humanos, id_recursos, piso), Marketing (campañas, proyectos,
piso, cod_mark, equipos de trabajo), Informática (cod_infor, gestión plataformas,
actualizaciones, dispositivos, fecha_mant) y Finanzas (cod_finanzas, piso,
contrataciones, estados financieros, despidos).

Por último, cada uno de estos departamentos tiene un respectivo jefe y empleados,
cada jefe tiene id, código de departamento, teléfono, fecha nacimiento, correo, nombre
y sueldo.

A su vez cada jefe tiene muchos empleados de los cuales se registra su rol, código de
departamento, id, sueldo, teléfono, correo y fecha de nacimiento.

4.2 Entidades Necesarias para el Almacenamiento en la Base de

Datos

1) JEFE (ID_JEFE, COD_DEPTO, TEL, FECHA_NAC, NOMBRE, SUELDO,

CORREO): Es de vital importancia de almacenamiento en esta base de datos ya que es
el encargado de todos los departamentos registrados en nuestra bbdd.

2) EMPLEADO (ROL, COD_DEPTO, ID_EMPLEADO, SUELDO, TEL,

FECHA_NAC, CORREO): Esta entidad está en nuestra base de datos ya que es la que
hace funcionar los departamentos ya que muchos empleados trabajan en un
departamento.

3) DEPTO_MANUFACTURA (DISEÑOS. COD_MANU, DETALLE, MATERIALES,

PRODUCCION, PISO): Esta entidad está en nuestra base de datos ya que es la
encargada de la producción de nuestra empresa, lo que es de vital importancia
almacenarla en la bbdd.

4) DEPTO_R. HUMANOS (ID_CASO, ID_RECLAMOS, COD_RH, ID_RECURSOS,

PISO): Por el departamento de recursos humanos pasa toda la gestión administrativa
del personal, por lo que se requiere guardar en nuestra bbdd.

P á g i n a 36 | 73
5) DEPTO_MARKETING (COD_MARK, EQUIPOS DE TRABAJO, CAMPAÑAS,
PROYECTOS, PISO): Este departamento se encarga de manejar y coordinar
estrategias de ventas para posicionar la empresa en el mercado, es decir nos ayuda a
vender nuestro producto.

6) DEPTO_INFORMATICA (COD_INFOR, GESTION_PLATAFORMAS”

GESTION_PLAT”, ACTUALIZACIONES BD, DISPOSITIVOS, FECHA_MANT
“Fecha_Mantenciones”): Entre las funciones principales de la informática se enumeran
las siguientes: Creación de nuevas especificaciones de trabajo. Optimización de los
métodos y sistemas informáticos existentes. Facilitar la automatización de datos y
formatos. Creación de nuestra bbdd.

7) DEPTO_FINANZAS (COD_FINANZAS, PISO, CONTRATACIONES, ESTADOS_

FINANCIEROS, DESPIDOS): El Departamento Financiero (FIN) es responsable de la
movilización y administración de los recursos financieros del Banco, correspondientes
tanto al activo como el pasivo de la organización.
Como todos los demás departamentos, estos son de vital importancia para el
funcionamiento independiente de una empresa.

8) CENTRAL (DIR_COMERCIAL, INFRAESTRUCTURA, CIUDAD, CAPACIDAD,

PROVINCIA): Para que todos los departamentos funcionen, se deben ubicar en una
central. Es por esto que esta entidad está en nuestra bbdd.

9) EMPRESA (ACREEDORES, RUT, N_EMPLEADOS, TIPO_EMPRESA,

VALOR_EMPRESA): Una empresa es una organización de personas que comparten
unos objetivos con el fin de obtener beneficios, y estos objetivos son realizados gracias
a todas las entidades mencionadas anteriormente, es decir que todas las entidades
mencionadas crean en si la empresa.

10) INSUMO/MATERIA.PRIMA (DESCRIPCION, CANTIDAD, ID_INSUMO,

PRECIO_UNIDAD, PRECIO_TOTAL, MATERIAL): Las materias primas son todos
aquellos materiales que se extrae principalmente de la naturaleza y que constituye la
base de algún producto. Los insumos son elementos ya procesados que ayudan a
desarrollar un producto o servicio final.
De esta manera, los insumos pueden estar hechos de materia prima, en cambio, la
materia prima nunca será hecho de insumos.
Es decir que con esta entidad procedemos a generar nuestro producto final que
posteriormente será vendido.

11) PROVEEDOR (ID_PROVEEDOR, TEL, JNOM_TITULAR, DIR_FACTURACION,

MEDIO DE PAGO): El proveedor es aquel tercero que abastece de materiales u otros
suministros a la empresa, los cuales son necesarios para su desarrollo y
funcionamiento.

12) STOCK (FECHA, CANTIDAD, PRECIO_UNIDAD, PRECIO_ESPECIAL,

UBICACION): Está en nuestra bbdd ya que indica la cantidad de productos o materias
primas que posee nuestra empresa en su almacén a la espera de su venta o
comercialización.

13) PRODUCTO (ID_PRODUCTO, DISEÑO, TAMAÑO, TIPO, MATERIAL,

PRECIO): El producto es el conjunto de características y atributos tangibles e
intangibles que el comprador acepta, en principio, como algo que va a satisfacer sus
necesidades, lo que será la creación de la producción de nuestra empresa

14) TIENDA_FISICA (ID_TIENDA, CANTIDAD, MEDIO DE PAGO,

PRECIO_TOTAL, NUM_BOLETA): Es el lugar donde se comercializará nuestro
producto, pues con esta información en nuestra base de datos, tendremos un correcto
orden y administración de nuestra empresa.

P á g i n a 37 | 73
 15) VENDEDOR (ID_VENDEDOR, SALARIO_BASE, COMISION, HRS_BASE,
HRS_EXTRA): Esta entidad está encargada del funcionamiento de nuestra entidad
Tienda Física.

16) INTERNET (ID_ORDEN, COD_DESCUENTO, FECHA_COMPRA, CANTIDAD,

PRECIO_INTERNET): Nuestro producto también será comercializado por vía internet
lo que es importante llevar la administración de la venta por este método.

17) CLIENTE (ID_CLIENTE, NOM_TITULAR, TEL, RUT, COD_POSTAL, CORREO):

Esta entidad es la que adquiere nuestros productos, y genera ganancias para nuestra
empresa.

18) REVENDEDOR (ID_REVENDEDOR, CANTIDAD, NOM_REVENDEDOR,

RUT_REVENDEDOR, RUBRO, PRECIO_REVENDEDOR, CORREO): El
revendedor compra bienes o servicios con la intención de venderlos en lugar de
consumirlos o usarlos, de todas formas, genera ganancias para la empresa.

19) FACTURA (ID_FACTURA, DESGLOZE, FECHA_FACTURA, NOM_EMPRESA,

NOM_PERNAT, TEL): Es el documento mercantil que refleja toda la información de
una operación de compraventa de nuestra empresa, lo que en nuestra base de datos
tenemos que tener registrado.

20) ENVIO (ID_ENVIO, DESTINO, FECHA_ORDEN, COD_POSTAL,

FECHA_ENVIO, DESTINATARIO): El envío es el traslado físico de nuestro
producto de un punto a otro, como el traslado de mercancías del almacén al cliente.
Necesitamos esta entidad para una correcta administración de nuestras ventas.

21) TRANSACCION (ID_TRANSACCION, MEDIO DE PAGO, PRECIO_TOT,

NOM_TITULAR, HORA_TRANSACCION): Registrado en nuestra bbdd ya que es el
acuerdo comercial que se lleva a cabo entre el vendedor y comprador. En efecto,
sencillamente es entregar dinero a cambio de obtener un bien o servicio dentro de
nuestra empresa.

22) TRANSPORTISTA (ID_TRANSPORTISTA, COMPAÑIA, PATENTE_VEH,

PESO_PAQUETE, DIM_PAQUETE): Es la persona que se encargara de transportar
nuestro producto a donde sea necesario para concretar una venta y ganancia para la
empresa.

4.3 Modelo Entidad Relación

Acotación:
* Con el fin de evitar problemas al momento de la normalización, se adiciona la clave
ID_REGISTRO a las entidades departamentales. Esta estará destacada en verde para evitar
confusiones en el desarrollo del ejercicio.

Diagrama n°3 “Modelo Entidad-Relación”

Fuente: Propia (Visio)

P á g i n a 38 | 73
 ID_REGISTRO DISEÑOS COD_MANU DETALLE TEL CANTIDAD
ID_PROVEEDOR NOM_TITULAR DESCRIPCION ID_INSUMO
CORREO
COD_DEPTO PRECIO_UNIDAD FECHA_FACTURA NOM_EMPRESA
ID_JEFE TEL
DEPTO_MANUFACTURA IN SUMO/MATERIA DESGLOZE NOM_PERNAT

P á g i n a 39 | 73
PROVEEDOR N SUMINISTRA M PRECIO_TOTAL ID _TRANSPORTISTA COMPAÑIA
PRIMA Rut_Revendedor RUBRO
1 PRECIO_REVENDEDOR ID _FACTURA TEL PATENTE_VEH
MATERIAL
JEFE MATERIALES
PRODUCCION PISO NOM_REVENDEDOR PESO_PAQUETE
DIR_FACTURACION MEDIO DE PAGO M
CANTIDAD REVENDEDOR 1 POSEE M FACTURA TRANSPORTISTA DIM_PAQUETE
CORREO
FECHA_NAC SUELDO ID _CASO ID _REGISTRO ID _RECLAMOS
1 ID _REVENDEDOR
NOMBRE
1
COMPRA
CORREO
1 DEPTO_R.HUMANOS
TAMAÑO TIPO FECHA_ORDEN COD_POSTAL
M M DESTINO M
DISEÑO MATERIAL FECHA_ENVIO
ACREEDORES 1 COD_DESCUENTO FECHA_COMPRA ID_ENVIO
COD_RH PISO ID_PRODUCTO PRECIO DESTINATARIO
ID _RECURSOS
RUT
ID _REGISTRO N_EMPLEADOS
COD_MARK EQUIPOS DE
TRABAJO EMPRESA 1 VENDE M PRODUCTO N SE VENDE POR M IN TERNET 1 REALIZA M ENVIO N MEDIANTE
1 TIPO_EMPRESA
TIENE 1 DEPTO_MARKETING 1 VALOR_EMPRESA
ID _ORDEN CANTIDAD
COD_DEPTO PRECIO_INTERNET
CAMPAÑAS PISO 1 M M 1
ROL ID_EMPLEADO PROYECTOS
ID _TRANSACCION
M
MEDIO DE PAGO
EMPLEADO
GESTION PLATAFORMAS ID_REGISTRO TIENE 1 CENTRAL M POSEE M STOCK N DE TIENDA_FISICA N ADQUIRIDO POR PRECIO_TOT
COD_INFOR M TRANSACCION
NOM.TITULAR
SUELDO FECHA_NAC 1 DEPTO_INFORMATICA 1 DIR_COMERCIAL PROVINCIA FECHA ID_TIENDA
PRECIO_TOTAL HORA_TRANSACCION
TEL INFRAESTRUCT UBICACION CANTIDAD
CAPACIDAD CANTIDAD 1 NUM_BOLETA M
URA MEDIO DE
ACTUALIZACIONES BD FECHA_MANT CIUDAD CORREO
PAGO
CORREO DISPOSITIVOS PRECIO_UNIDAD PRECIO_ESPECIAL
ID _CLIENTE
COD_FINANZAS NOM_TITULAR
1 PISO POSEE CLIENTE
1 TEL
DEPTO_FINANZAS
RUT
COD_POSTAL RUT
CONTRATACIONES M
ID_REGISTRO
ESTADOS
DESPIDOS ID _VENDEDOR
FINANCIEROS
SALARIO_BASE
COMISION
VENDEDOR
HRS_BASE
HRS_EXTRA
Tabla n°3
Entidad: CLIENTE

Atributos Clave Relaciones Cardinalidad

Id_Cliente X TIENDA_FISICA (M,N)

Nombre_Titula INTERNET (M,1)

r

Direccion

Telefono(Tel)

RUT X

Correo
Fuente: Propia
Justificación: La relacion Clientes y Tiendas Físicas es (M,N) ya que varios clientes pueden ir
a comprar a varias tiendas físicas.
Por su parte Clientes con Internet es (M,1) porque muchos clientes pueden tener solo un
internet.

Tabla n°4
Entidad: JEFE

Atributos Clave Relaciones Cardinalidad

Id_jefe X DEPTO_MANUFACTUR (1,1)

A

Sueldo DEPTO_R.HUMANOS (1,1)

Fecha_Nac DEPTO_MARKETING (1,1)

Telefono(Tel DEPTO_INFORMATICO (1,1)

)

Nom_Jefe DEPTO_FINANZAS (1,1)

Correo
Fuente: Propia

Justificación: Todas las relaciones son (1,1) porque cada Departamento puede tener solo un
Jefe y un jefe sólo puede tener un departamento.

Tabla n°5
Entidad: DEPTO_FINANZAS

Atributos Clave Relaciones Cardinalidad

Cod_Finanzas X CENTRAL (1,1)

Despidos JEFE (1,1)

Estados_Financiero EMPLEADOS (1,M)

s

Contrataciones

Piso

Id_Registro
Fuente: Propia

P á g i n a 40 | 73
Justificación: En el caso de Central y Jefe son (1,1) porque un Departamento de Finanzas solo
puede tener una central y un solo jefe, en cambio Empleados es (1,M) ya que el departamento
puede tener muchos empleados.

Tabla n°6
Entidad: DEPTO_R.HUMANOS

Atributos Clav Relaciones Cardinalidad

e

Cod_R.Hum X CENTRAL (1,1)

ID_Reclamo JEFE (1,1)

s

ID_Casos EMPLEADOS (1,M)

Recursos

Id_Registro X

Piso
Fuente: Propia

Justificación: En el caso de Central y Jefe son (1,1) porque un Departamento de Recursos

Humanos solo puede tener una central y un solo jefe, en cambio Empleados es (1,M) ya que el
departamento puede tener muchos empleados.

Tabla n°7
Entidad: DEPTO_MANUFACTURA

Atributos Clave Relaciones Cardinalidad

Cod_Manu X CENTRAL (1,1)

Produccion JEFE (1,1)

Materiales EMPLEADOS (1,M)

Diseños

Piso

Id_Registr X
o
Fuente: Propia

Justificación: En el caso de Central y Jefe son (1,1) porque un departamento de Manufactura

solo puede tener una central y un solo jefe, en cambio Empleados es (1,M) ya que el
departamento puede tener muchos empleados.

Tabla n°8
Entidad: DEPTO_MARKETING

Atributos Clave Relaciones Cardinalidad

Cod_Mark X CENTRAL (1,1)

P á g i n a 41 | 73
Campañas JEFE (1,1)

Proyectos EMPLEADOS (1,M)

Equipo de Trabajo

Piso

Id_Registro X
Fuente: Propia

Justificación: En el caso de Central y Jefe son (1,1) porque un Departamento de Marketing

solo puede tener una central y un solo jefe, en cambio Empleados es (1,M) ya que el
departamento puede tener muchos empleados.

Tabla n°9
Entidad: DEPTO_INFORMATICA

Atributos Clave Relaciones Cardinalidad

Cod_Informatica X CENTRAL (1,1)

Fecha_Mant JEFE (1,1)

Actualizaciones EMPLEADOS (1,M)

BD

Dispositivos

Gestion_Plat

Id_Registro X
Fuente: Propia

Justificación: En el caso de Central y Jefe son (1,1) porque un Departamento de Informática

solo puede tener una Central y un solo jefe, en cambio Empleados es (1,M) ya que el
departamento puede tener muchos empleados.

Tabla n°10
Entidad: EMPLEADOS

Atributos Clave Relaciones Cardinalidad

Id_Empleado X DEPTO_MANUFACTURAS (M,1)

Rol DEPTO_R.HUMANOS (M,1)

Fecha_nac DEPTO_MARKETING (M,1)

Sueldo DEPTO_INFORMATICA (M,1)

Nom_Empleado DEPTO_FINANZAS (M,1)

Telefono(Tel)

Correo
Fuente: Propia

Justificación: La relacion con los diferentes Departamentos son (M,1) ya que pueden existir
muchos Empleados para un solo departamento

Tabla n°11

P á g i n a 42 | 73
Entidad: INSUMOS/MATERIA PRIMA

Atributos Clave Relaciones Cardinalidad

Id_Insumo X PROVEEDOR (M,N)

Cantidad EMPRESA (M,1)

Detalle

Precio
Unitario

Precio Total

Material
Fuente: Propia

Justificación: La relación de Insumos con Proveedor es (M,N) ya que puede entregar mucha
materia prima a muchos proveedores.
A su vez Insumos con Empresa es (M,1) ya que le puedo dar muchos insumos a solo una
empresa.

Tabla n°12
Entidad: PROVEEDOR

Atributos Clave Relaciones Cardinalidad

Id_Proveedor X INSUMO/MATERIA (N,M)

PRIMA

Dir_facturacio
n

Medio de pago

Telefono(Tel)

Nom_Titular

Correo
Fuente: Propia

Justificación: La relacion de Insumos con Proveedor es (N,M) ya que puede entregar mucha
materia prima a muchos proveedores.

Tabla n°13
Entidad: Central

Atributos Clave Relaciones Cardinalidad

Dir_Comercia X DEPTO_MANUFACTURA (1,1)

l

Provincia DEPTO_R.HUMANOS (1,1)

Capacidad DEPTO_MARKETING (1,1)

Ciudad DEPTO_INFORMATICA (1,1)

Infraestructura DEPTO_FINANZAS (1,1)

EMPRESA (M,1)
Fuente: Propia

P á g i n a 43 | 73
Justificación: La Central con los diferentes Departamentos son (1,1) ya que solo puede existir
una central para un departamento.
La Central con Empresa es (M,1) ya que puede existir muchas centrales para una empresa.

Tabla n°14
Entidad: EMPRESA

Atributos Clav Relaciones Cardinalidad

e

RUT X CENTRAL (1,M)

Acreedores STOCK (1,M)

Num_Empleado INSUMO/MATERIA PRIMA (1,M)

s

Tipo_Empresa PRODUCTO (1,M)

Val_Empresa
Fuente: Propia

Justificación: La relacion de Empresa con Central, Stock, Insumo y Producto es (1,M) ya que
hay una empresa para muchas centrales, stock insumos y productos.

Tabla n°15
Entidad: VENDEDOR

Atributos Clave Relaciones Cardinalidad

Id_Vendedor X TIENDA_FISICA (M,1)

Salario_Base

Comision

Hrs_Trabajada
s

Hrs_Extra
Fuente: Propia

Justificación: La relación de Vendedor y Tienda Física es (M,1) ya que pueden existir varios
vendedores en una tienda.

Tabla n°16
Entidad: STOCK

Atributos Clave Relaciones Cardinalidad

Fecha EMPRESA (M,1)

Cantidad PRODUCTO (1,M)

Precio unitario

Precio Especial

Ubicación X
Fuente: Propia

P á g i n a 44 | 73
Justificación: La relación entre Stock y Empresa es (M,1) ya que puede existir mucho stock de
algo para una empresa.
A su vez Stock y Producto es (1,M) ya que hay un stock para muchos productos.

Tabla n°17
Entidad: PRODUCTO

Atributos Clav Relaciones Cardinalidad

e

Id_Producto X EMPRESA (M,1)

Diseño INTERNET (N,M)

Tamaño REVENDEDOR (N,M)

Tipo TIENDA_FISICA (N,M)

Material

Precio
Fuente: Propia

Justificación: La relación entre Producto y Empresa es (M,1) ya que existen muchos productos
para una empresa.
A su vez Producto con Internet, Revendedor y Tienda Física es (N,M), ya que existen varios
productos para muchos revendedores, tiendas físicas e internet.

Tabla n°18
Entidad: REVENDEDOR

Atributos Clave Relaciones Cardinalidad

Id_Revendedor X FACTURA (1.M)

Precio_Revendedo PRODUCTO (M,N)

r

Cantidad

Nom_Revendedor

Rubro

Correo
Fuente: Propia

Justificación: La relación entre Revendedor y Factura es (1,M) porque un revendedor puede

hacer muchas facturas.
Por su parte Revendedor y Producto es (M,N) porque un revendedor puede vender muchos
productos.

Tabla n°19
Entidad: INTERNET

Atributos Clave Relaciones Cardinalidad

Id_Orden X PRODUCTO (M,N)

P á g i n a 45 | 73
 Precio Internet FACTURA (1,M)

Cantidad ENVIO (1,M)

Fecha Compra TRANSACCION (1,M)

Cupon Descuento
Fuente: Propia

Justificación: La relacion generada entre Internet y las entidades Factura, Envío, Transacción y
Producto es (1,M) puesto que el canal de ventas internet puede tener varias facturas, envíos,
transacciones y productos.

Tabla n°20
Entidad: ENVIO

Atributos Clave Relaciones Cardinalidad

Id_Envio X INTERNET (M,1)

Num_Orden X TRANSPORTIST (N,M)

A

Fecha_Orde
n

Cod_Postal

Destino

Destinatario

Fecha_Envio
Fuente: Propia
Justificación: La relación Envío e Internet es (M,1) ya que se pueden hacer muchos envíos por
un solo internet. Mientras que Envío a Transportista es (N,M) ya que se pueden efectuar
muchos envíos con varios transportistas.

Tabla n°21
Entidad: TRANSPORTISTA

Atributos Clave Relaciones Cardinalidad

Id_Transportista X ENVIO (M,N)

Compañia

Patente_Vehiculo

Peso_Paquete

Dimension_Paquete

Precio
Fuente: Propia

Justificación: La relación efectuada entre Transportista y Envío es (M,N) ya que varios

transportistas pueden hacer muchos envíos.

Tabla n°22
Entidad: TRANSACCION

Atributos Clave Relaciones Cardinalidad

P á g i n a 46 | 73
 Id_Transaccion X INTERNET (M,1)

Medio_pago

Precio_Total

Nom_Titular

Hora_Transaccio
n
Fuente: Propia

Justificación: La relación entre Transacción e Internet es ( M,1) porque se puede hacer muchas
transacciones en un solo internet.

Tabla n°23
Entidad: TIENDA_FISICA

Atributos Clave Relaciones Cardinalidad

Id_Tienda X PRODUCTO (M,N)

Cantidad CLIENTE (N,M)

Precio_Tota VENDEDOR (1,M)

l

Medio_Pago

Num_Boleta
Fuente: Propia

Justificación: La relación entre tienda Física y Producto es (M,N) porque muchas tiendas
pueden vender varios productos.
A su vez Tienda Física y cliente es (N,M) porque a varias tiendas físicas pueden llegar
muchos clientes.
Por su parte Tienda física y Vendedor es (1,M) ya que en una tienda física pueden existir
varios vendedores.

Tabla n°24
Entidad: FACTURA

Atributos Clave Relaciones Cardinalidad

Id_Factura X REVENDEDOR (M,1)

Fecha INTERNET (M,1)

Desgloze

Telefono(Tel
)

Nombre_P.N

Rubro
Fuente: Propia

Justificación: La relación entre Factura con Revendedor e internet es (M,1) ya que pueden
existir varias facturas para solo un revendedor e internet.

P á g i n a 47 | 73
 V. DISEÑO DE LA BASE DE DATOS
(Debe incluir imágenes)

5.1 Transformación Modelo Entidad Relación a Modelo Relacional

Paso 1 Transformación de entidades (Claves en Amarillo)

Con el fin de evitar problemas al momento de la normalización, se adiciona la clave

ID_REGISTRO a las entidades departamentales. Esta estará destacada en verde para
evitar confusiones en el desarrollo del ejercicio.

->JEFE (ID_JEFE, COD_DEPTO, TEL, FECHA_NAC, NOMBRE, SUELDO, CORREO)

-> EMPLEADO (ROL, COD_DEPTO, ID_EMPLEADO, SUELDO, TEL, FECHA_NAC,

CORREO)

-> DEPTO_MANUFACTURA (DISEÑOS, COD_MANU, DETALLE, MATERIALES,

PRODUCCION, PISO, ID_REGISTRO)

-> DEPTO_R.HUMANOS (ID_CASO, ID_RECLAMOS, COD_RH, ID_RECURSOS, PISO,

ID_REGISTRO)

-> DEPTO_MARKETING (COD_MARK, EQUIPOS DE TRABAJO, CAMPAÑAS,

PROYECTOS, PISO, ID_REGISTRO)

-> DEPTO_INFORMATICA (COD_INFOR, GESTION PLATAFORMAS,

ACTUALIZACIONES BD, DISPOSITIVOS, FECHA_MANT, ID_REGISTRO)

-> DEPTO_FINANZAS (COD_FINANZAS, PISO, CONTRATACIONES, ESTADOS

FINANCIEROS, DESPIDOS, ID_REGISTRO)

-> CENTRAL (DIR_COMERCIAL, INFRAESTRUCTURA, CIUDAD, CAPACIDAD,

PROVINCIA)

-> EMPRESA (ACREEDORES, RUT, N_EMPLEADOS, TIPO_EMPRESA,

VALOR_EMPRESA)

-> INSUMO/MATERIA.PRIMA (DESCRIPCION, CANTIDAD, ID_INSUMO,

PRECIO_UNIDAD, PRECIO_TOTAL, MATERIAL)

-> PROVEEDOR (ID_PROVEEDOR, TEL, JNOM_TITULAR, DIR_FACTURACION,

MEDIO DE PAGO, CORREO)

-> STOCK (FECHA, CANTIDAD, PRECIO_UNIDAD, PRECIO_ESPECIAL,

UBICACION)

-> PRODUCTO (ID_PRODUCTO, DISEÑO, TAMAÑO, TIPO, MATERIAL, PRECIO)

-> TIENDA_FISICA (ID_TIENDA, CANTIDAD, MEDIO DE PAGO, PRECIO_TOTAL,

NUM_BOLETA)

P á g i n a 48 | 73
-> VENDEDOR (ID_VENDEDOR, SALARIO_BASE, COMISION, HRS_BASE,
HRS_EXTRA)

-> INTERNET (ID_ORDEN, COD_DESCUENTO, FECHA_COMPRA, CANTIDAD,

PRECIO_INTERNET)

-> CLIENTE (ID_CLIENTE, NOM_TITULAR, TEL, RUT, COD_POSTAL, CORREO)

-> REVENDEDOR (ID_REVENDEDOR, CANTIDAD, NOM_REVENDEDOR,

RUT_REVENDEDOR, RUBRO, PRECIO_REVENDEDOR, CORREO)

-> FACTURA (ID_FACTURA, DESGLOZE, FECHA_FACTURA, NOM_EMPRESA,

NOM_PERNAT, TEL)

-> ENVIO (ID_ENVIO, DESTINO, FECHA_ORDEN, COD_POSTAL, FECHA_ENVIO,

DESTINATARIO)

-> TRANSACCION (ID_TRANSACCION, MEDIO DE PAGO, PRECIO_TOT,

NOM_TITULAR, HORA_TRANSACCION)

->TRANSPORTISTA (ID_TRANSPORTISTA, COMPAÑIA, PATENTE_VEH,

PESO_PAQUETE, DIM_PAQUETE)

Paso 2 Explicación Relaciones y Cardinalidad

Tabla n°25
TABLA RELACION: TIENE (JEFE/EMPLEADO-DEPTOS)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓN
FK JEFE (1:1) ID_JEFE N(5) X
FK EMPLEADO (N:1) ID_EMPLEAD N(1500) X Mayor a 0
O
FK DEPTO_(i) (1:1)/(1:N) COD_DEPTO C(5) x
FK DEPTO_(i) (N:1)/(N:1) ID_REGISTRO N(100000) X

Fuente: Propia

R: En el caso de jefe es (1:1) ya que un departamento solo tiene un jefe.

En el caso de empleados es (N:1) porque los departamentos funcionan con más de un
empleado, es decir; solo un departamento tiene muchos empleados.

Tabla n°26
TABLA RELACION: (DEPTOS-CENTRAL)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
CAMPO NULL
PK O TABLA CARDINALIDAD
FK RELACIONADA INTERRELACIÓ
N
FK CENTRAL (1:N) DIR_COMERCIA C(15) X
L
FK DEPTO_(i) (N:1) COD_DEPTO C(5) X

Fuente: Propia

R: La central tiene los cinco departamentos, es decir que una sola central tiene muchos
departamentos

Tabla n°27
TABLA RELACION: POSEE(EMPRESA/CENTRAL-STOCK)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES

P á g i n a 49 | 73
 CAMPO NULL
PK O TABLA CARDINALIDAD
FK RELACIONADA INTERRELACIÓ
N
FK EMPRESA (1:N) RUT C(10) X
FK CENTRAL (1:1) DIR_COMERCIA C(15) X
L
FK STOCK (N:1)/(1:1) UBICACION C(15) X

Fuente: Propia

R: La empresa tiene mucho stock, por su parte la central posee solo un lugar de
almacenamiento. Esto debido a que las centrales son locaciones de una misma empresa.

Tabla n°28
TABLA RELACION: COMPRA(EMPRESA-INSUMO)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O FK TABLA CARDINALIDAD CAMPO NULL
RELACIONADA INTERRELACIÓN
FK INSUMO (N:1) ID_INSUMO N(5) X Mayor a 0
FK EMPRESA (1:N) RUT C(10) X

Fuente: Propia

R: Esto es porque la empresa compra muchos insumos o reciproco, muchos insumos son
comprados por una sola empresa.

Tabla n°29
TABLA RELACION: SUMINISTRA(INSUMO-PROVEEDOR)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDAD CAMPO NULL
O RELACIONADA INTERRELACIÓ
FK N
FK PROVEEDOR (1:N) DIR_FACTURACION C(25) X
FK INSUMO (N:1) ID_INSUMO N(5) X Mayor a 0

Fuente: Propia

R: Esto porque un proveedor, provee de muchos insumos y reciproco, muchos insumos son
provistos por un solo proveedor.

Tabla n°30
TABLA RELACION: VENDE(EMPRESA-PRODUCTO)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓN
FK EMPRESA (1:N) RUT N(1) X
FK PRODUCTO (N:1) ID_PRODUCTO C(15) X Mayor a 0

Fuente: Propia

R: Las empresas venden más de un producto, es decir muchos productos son vendidos por una
sola empresa.

Tabla n°31
TABLA RELACION: DE(STOCK-PRODUCTO)

P á g i n a 50 | 73
 CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓN
FK PRODUCTO (N:1) ID_PRODUCTO C(15) X Mayor a 0
FK STOCK (1:M) UBICACION C(15) X Mayor a 0

Fuente: Propia

R: Un producto puede estar localizado en varios lugares, como en un lugar pueden estar
localizados varios productos

Tabla n°32
TABLA RELACION: SE VENDE POR(PRODUCTO-REVENDEDOR/INTERNET/TIENDA_FISICA)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDAD CAMPO NULL
O RELACIONADA INTERRELACIÓ
FK N
FK PRODUCTO (1:1) ID_PRODUCTO C(12) X Mayor a 0
FK REVENDEDOR (1:N) ID_REVENDEDOR C(12) X
FK INTERNET (1:N) ID_ORDEN C(12) X
FK TIENDA_FISICA (1:N) ID_TIENDA C(12) X

Fuente: Propia

R: En este caso los revendedores, tiendas en internet y tiendas físicas venden muchos
productos cada una por separado.

Tabla n°33
TABLA RELACION: POSEE(REVENDEDOR-FACTURA)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓN
FK REVENDEDOR (1:N) ID_REVENDEDO C(12) X Mayor a 0
R
FK FACTURA (N:1) ID_FACTURA C(15) X Mayor a 0

Fuente: Propia

R: Un revendedor posee muchas facturas, en caso reciproco seria que muchas fracturas son
poseídas por un solo revendedor.

Tabla n°34
TABLA RELACION: POSEE(TIENDA_FISICA-VENDEDOR)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓ
N
FK TIENDA_FISICA (1:N) ID_TIENDA C(12) X
FK VENDEDOR (N:1) ID_VENDEDOR N(5) X Mayor a 0

Fuente: Propia

R: Una tienda física posee muchos vendedores, en caso reciproco seria que muchos
vendedores trabajan en una sola tienda física.

P á g i n a 51 | 73
Tabla n°35
TABLA RELACION: ADQUIRIDO POR(INTERNET/TIENDA_FISICA-CLIENTE)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O FK TABLA CARDINALIDAD CAMPO NULL
RELACIONADA INTERRELACIÓN
FK INTERNET (1:N) ID_ORDEN N(1) X
FK TIENDA_FISICA (1:N) ID_TIENDA N(1) X
FK CLIENTE (N:N) ID_CLIENT N(2) X Mayor a 0
E

Fuente: Propia

R: Una tienda en internet, una tienda física adquiere muchos clientes.

Tabla n°36
TABLA RELACION: REALIZA(INTERNET-FACTURA/ENVIO/TRANSACCION)
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDAD CAMPO NULL
O RELACIONADA INTERRELACIÓN
FK
FK INTERNET (1:N) ID_ORDEN N(1) X
FK FACTURA (N:1) ID_FACTURA C(10) X Mayor a 0
FK ENVIO (N:1) ID_ENVIO N(1500) X Mayor a 0
FK TRANSACCION (N:1) ID_TRANSACCION C(12) X Mayor a 0

Fuente: Propia

R: Las facturas, envíos y transacciones son emitidas por una sola tienda en internet.

Tabla n°37
TABLA RELACION: MEDIANTE(ENVIO-TRANSPORTISTA)
CLAVE NOMBRE DOMINI NOT RESTRICCIONE
PK TABLA CARDINALIDAD CAMPO O NUL S
O RELACIONADA INTERRELACIÓ L
FK N
F ENVIO (N:N) ID_ENVIO N(1500) X Mayor a 0
K
F TRANSPORTIST (1:N) ID_TRANSPORTIST N(5) X
K A A

Fuente: Propia

R: Un transportista lleva muchos envíos, mientras que muchos envíos son realizados mediante
muchos transportistas.

Paso 3 Tablas con adición de atributos PK y FK (Tamaño 10)

 Simbología:
1. (i) = Tablas que presenten el mismo nombre antes del guion
2. * o ** = clave candidata a primaria

Tabla n°38
TABLA: CENTRAL
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL

P á g i n a 52 | 73
 FK RELACIONA
DA
PK DIR_COMERCIAL C(25) X
CIUDAD N(1) X
PROVINCIA N(1)
CAPACIDAD N(1800) MAYOR A 0
INFRAESTRUCTUR N(30000)
A
Fuente: Propia

Tabla n°39
TABLA: CLIENTES
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA INTERRELACIÓN
PK ID_CLIENTE C(25) X
NOM_TITULAR C(20) X
COD_POSTAL C(7)
TEL C(9) X
PK* RUT C(12) X
CORREO C(12)
Fuente: Propia

Tabla n°40
TABLA: JEFE
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
CAMPO NULL
PK O TABLA CARDINALIDA
FK RELACIONADA D
PK ID_JEFE C(20) X
FK DEPTO_(i) (1:1) COD_DEPTO C(5) X
FK DEPTO_(i) (1:N) ID_REGISTRO N(1000000) X
SUELDO N(5000000) X
FEC_NAC F(8) X Ser una fecha
TEL C(9) X
NOM_JEFE C(25) X
CORREO C(25) X
Fuente: Propia

Tabla n°41
TABLA: DEPTO_FINANZAS
CLAVE NOMBRE DOMINIO NOT RESTRICCIONE
PK TABLA CARDINALIDA CAMPO NUL S
O RELACIONAD D L
FK A
P COD_FINANZAS C(5) X
K
P ID_REGISTRO N(1000000 X
K )
F JEFE (1:1) ID_JEFE C(12) X
K
F EMPLEADO (1:N) ID_EMPLEADO C(12) X
K
ESTADOS_FINANCIERO N(1000) X Mayor a 0
S
CONTRATACIONES N(2500) Mayor a 0
DESPIDOS N(1000) Mayor a 0
PISO N(1) X
Fuente: Propia

Tabla n°42
TABLA: DEPTO_R.HUMANOS

P á g i n a 53 | 73
 CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O FK TABLA CARDINALIDAD CAMPO NULL
RELACIONAD
A
PK COD_RH C(5) X
PK ID_REGISTRO N(1000000) X
FK JEFE (1:1) ID_JEFE C(12) X
FK EMPLEADO (1:N) ID_EMPLEAD C(12) X
O
ID_RECLAMO C(12)
ID_RECURSO C(12)
PISO N(1) X
ID_CASO C(12)
Fuente: Propia

Tabla n°43
TABLA: DEPTO_MANUFACTURA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
CAMPO NULL
PK O TABLA CARDINALIDA
FK RELACIONADA D
PK COD_MANU C(5) X
PK ID_REGISTRO N(1000000) X
FK JEFE (1:1) ID_JEFE C(12) X
FK EMPLEADO (1:N) ID_EMPLEAD C(12) X
O
PISO N(1) X
PRODUCCION N(1700) Mayor a 0
MATERIALES N(1700) X Mayor a 0
DISEÑOS C(15) X Mayor a 0
Fuente: Propia

Tabla n°44
TABLA: DEPTO_MARKETING
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDA CAMPO NULL
FK RELACIONADA D
PK COD_MARK C(5) X
PK ID_REGISTRO N(1000000) X
FK JEFE (1:1) ID_JEFE C(12) X
FK EMPLEADO (1:N) ID_EMPLEAD C(12) X
O
PISO N(1) X
EQUIPOS DE N(20) Mayor a 0
TRABAJO
PROYECTOS N(25) Mayor a 0
CAMPAÑAS C(15) Mayor a 0
Fuente: Propia

Tabla n°45
TABLA: DEPTO_INFORMATICA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDA CAMPO NULL
O RELACIONADA D
FK
PK COD_INFOR C(5) X
PK ID_REGISTRO N(1000000) X
FK JEFE (1:1) ID_JEFE C(12) X
FK EMPLEADO (1:N) ID_EMPLEADO C(12) X
FECHA_MANT F(8) X Ser una fecha
ACTUALIZACIONES N(1500) Mayor a 0
DISPOSITIVOS N(2500) X Mayor a 0

P á g i n a 54 | 73
 GESTION_ PLAT N(2500)
PISO N(1) X
Fuente: Propia

Tabla n°46
TABLA: EMPLEADOS
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDA CAMPO NULL
FK RELACIONADA D
PK ID_EMPLEADO C(5) X
FK DEPTO_(i) (N:1) COD_DEPTO C(9) X
FK DEPTO_(i) (N:1) ID_REGISTRO N(1000000) X
ROL C(16)
FECHA_NAC F(8) X Ser una fecha
SUELDO N(500000) X Mayor a 0
NOM_EMPLEADO C(25)
TEL C(9) X
CORREO C(25) X
Fuente: Propia

Tabla n°47
TABLA: INSUMOS/ MATERIA PRIMA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK ID_INSUMO C(12) X
FK PROVEEDOR (1:1) ID_PROVEEDOR C(9) X
CANTIDAD N(1500) X Mayor a 0
DETALLE N(2000)
PRECIO_UNIT C(6) Mayor a 0
PRECIO_TOT C(6) Mayor a 0
MATERIAL N(150) X
Fuente: Propia

Tabla n°48
TABLA: PROVEEDOR
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDAD CAMPO NULL
O RELACIONADA
FK
PK ID_PROVEEDOR N(9) X
FK EMPRESA (1:1) ID_EMPRESA C(9) X
FK INSUMO/MATERI (1:1) ID_INSUMO C(9) X
A PRIMA
DIR_FACT C(20) X
MEDIO_PAGO C(13) X Mayor a 0
TEL N(9) X
NOM_TITULAR C(25) X
CORREO C(25) X
Fuente: Propia

Tabla n°49
TABLA: EMPRESA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK RUT C(12) X

P á g i n a 55 | 73
 FK CENTRAL (1:1) DIR_COMERCIAL C(30) X
ACREEDORES N(10) Mayor a 0
TIPO_EMPRESA C(20) X
VAL_EMPRESA N(12) X Mayor a 0
NUM_EMPLEADO N(2500) X Mayor a 0
S
Fuente: Propia

Tabla n°50
TABLA: VENDEDOR
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK ID_VENDEDOR C(9) X
FK TIENDA (1:1) ID_TIENDA C(9) X
SALARIO_BASE N(350000) X
COMISION N(100000) X Mayor a 0
HRS_TRABAJADAS N(45) X Mayor a 0
HRS_EXTRA N(12) Mayor a 0
Fuente: Propia

Tabla n°51
TABLA: STOCK
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
FECHA F(8) X Ser una fecha
PK UBICACION C(15) X
FK PRODUCTO (1:M) ID_PRODUCTO C(12) X
PRECIO_UNIT N(3000) Mayor a 0
PRECIO_ESP N(3000) Mayor a 0
CANTIDAD N(15000) X Mayor a 0
Fuente: Propia

Tabla n°52
TABLA: PRODUCTO
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK ID_PRODUCTO C(10) X
DISEÑO N(15) X
TAMAÑO C(20) X Mayor a 0
TIPO N(12) X
MATERIAL C(45) X Mayor a 0
PRECIO N(9) X Mayor a 0
Fuente: Propia

Tabla n°53
TABLA: REVENDEDOR
CLAVE NOMBRE DOMINI NOT RESTRICCIONES
CAMPO O NULL
PK TABLA CARDINALIDA
O RELACIONADA D
FK
P ID_REVENDEDOR C(12) X
K
F FACTURA (1:1) ID_FACTURA C(12) X
K
F PRODUCTO (1:1) ID_PRODUCTO C(10) X
K

P á g i n a 56 | 73
 CANTIDAD N(150) X Mayor a 0
PRECIO_REVENDEDOR C(6) X Mayor a 0
RUBRO N(5) X
NOM_REVENDEDOR C(25) X
CORREO C(25) X
Fuente: Propia

Tabla n°54
TABLA: INTERNET
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
CAMPO NULL
PK TABLA CARDINALIDA
O RELACIONADA D
FK
PK ID_ORDEN C(12) X
FK PRODUCTO (1:1) ID_PRODUCTO C(12) X
FK TRANSACCION (1:1) ID_TRANSACCION C(12) X
FK ENVIO (1:1) ID_ENVIO C(12) X
FK CLIENTE (1:1) ID_CLIENTE C(12) X
CANTIDAD N(150) X Mayor a 0
CUPON_DESCT N(20) Mayor a 0
FECHA_COMPRA F(8) X Ser una fecha
PRECIO_INTERNE N(150) X
T
Fuente: Propia
Tabla n°55
TABLA: ENVIO
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDAD CAMPO NULL
O RELACIONADA
FK
PK ID_ENVIO C(12) X
PK NUM_SEGUIMIENT C(9) X Mayor a 0
* O
FK TRANSPORTISTA (N:M) ID_TRANSPORTISTA C(12) X
COD_POSTAL C(12) X
FECHA_ORDEN F(8) X Ser una fecha
DESTINO C(30) X
DESTINATARIO C(20) X
FECHA_ENVIO F(8) X Ser una fecha
Fuente: Propia

Tabla n°56
TABLA: TRANSACCION
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDA CAMPO NULL
O RELACIONADA D
FK
PK ID_TRANSACCION C(12) X
FK INTERNET (1:1) ID-ORDEN C(12) X
MEDIO_PAGO N(2) X Mayor a 0
PRECIO_TOT N(1) X
NOM_TITULAR C(25)
HR_TRANSACCION N(24) X Mayor a 0
Fuente: Propia

Tabla n°57
TABLA: TRANSPORTISTA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK TABLA CARDINALIDA CAMPO NULL
O RELACIONADA D
FK

P á g i n a 57 | 73
 PK ID_TRANSPORTISTA C(12) X
FK ENVIO (1:1) NUM_SEGUIMIENTO C(9) X
PESO_PAQUETE C(3) X
COMPAÑÍA N(1) X
PATENTE_VEH C(9) X
DIM_PAQUETE C(20) X
Fuente: Propia

Tabla n°58
TABLA: FACTURA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK ID_FACTURA C(12) X
FECHA F(8) X Ser una fecha
DESGLOZE C(8)
TEL C(9) X
NOM_EMPRES C(25)
A
NOM_PNAT C(25)
RUBRO N(3) X Mayor a 0
Fuente: Propia

Tabla n°59
TABLA: TIENDA_FISICA
CLAVE NOMBRE DOMINIO NOT RESTRICCIONES
PK O TABLA CARDINALIDAD CAMPO NULL
FK RELACIONADA
PK ID_TIENDA C(12) X
FK VENDEDOR (N:M) ID_VENDEDOR C(12) X
FK CLIENTE (N:M) ID_CLIENTE C(12) X
NUM_BOLETA N(9) X Mayor a 0
CANTIDAD C(7) X Mayor a 0
PRECIO_TOT N(150) X Mayor a 0
MEDIO_PAGO N(150) X
Fuente: Propia

5.2 Normalización Modelo Relacional

Entregue la descripción, explicación y justificación de la primera, segunda,
tercera y demás formas normales requeridas para que los datos cumplan con
todas las propiedades de la etapa de diseño de la base de datos.

->Tabla Departamentos

 Aplicamos la primera forma normal (1fn) en el atributo piso ya que se repetía en varias
tablas individuales y creamos una tabla independiente, donde piso ahora aplica para
todos los departamentos asignando diferentes valores.

 Podemos ver que se aplicó la segunda forma normal (2fn) porque la clave
id_trabajador depende totalmente de la clave principal cod_depto.

->Tabla Trabajadores

 En esta tabla podemos saber que se aplicó la tercera forma normal (3fn) porque los
atributos secundarios solo se conocen por la clave principal o secundarias de la tabla y
no por otros atributos primarios.

P á g i n a 58 | 73
 ->Entregue el aporte de normalizar una BBDD

1. Evita anomalías en inserciones, modificaciones y borrados.

2. Mejora la independencia de datos.
3. No establece restricciones artificiales en la estructura de los datos.
4. Facilidad de uso.
5. Flexibilidad.
6. Precisión.
7. Seguridad.
8. Facilidad de implementación.
9. Independencia de datos.
10. Claridad.
11. Facilidad de gestión.
12. Mínima redundancia.
13. Máximo rendimiento de las aplicaciones.

->Identifique y justifique las claves primarias y foráneas de cada entidad o tabla de la BD

Al momento de evaluar las tablas del punto 5.1 nos dimos cuenta que en un par de casos, es
posible ahorrar información en datos normalizando. Estos casos son los de los departamentos
y los respectivos trabajadores que laburan en estos. Además, la tabla de empresa se considera
innecesaria al momento de definir las entidades finales, esto ya que solo cumplía la función de
ancla entre el resto de entidades.

Tabla n°60 “Trabajadores”

ID_TRABAJAD COD_DEPT SUELD FECHA_NA NOMBR TELEFON
OR ROL O O C E O CORREO
emplead 202673
20802281863 o FINAN 4 09-07-1967 juan 983748374 juan@gmail.com
emplead 233224 pedro@gmail.co
2093093202 o INFO_ 1 23-11-1965 pedro 926548832 m
676234 matias@gmail.co
14018877438 jefe MANU_ 4 02-05-1970 matias 964382634 m
emplead 825988
95229476648 o INFO_ 1 15-08-1969 jose 923455318 jose@gmail.com
848666 ignacio@gmail.c
75771771583 jefe REHUM 2 30-12-1965 ignacio 988682233 om
Fuente: Propia

En el caso de trabajadores, se nos ocurrió que la entidad jefe, puede a su vez ser interpretado
como atributo de rol, y dado que presenta muchas similitudes respecto a la tabla empleado, se
tomó la decisión de prescindir de la tabla jefe, creando una tabla llamada trabajadores, la cual
incorpora tanto a la entidad empleado como a la entidad jefe. Por lo que al normalizar queda
de la siguiente manera:

 ID_TRABAJADOR:
 ROL:
 COD_DEPTO: PROVENIENTE DE LA TABLA DEPARTAMENTOS
 SUELDO:
 FECHA_NAC:
 NOMBRE:
 TEL:
 CORREO: CORRESPONDE AL CORREO PERSONAL DE LOS TRABAJADORES
DE LA EMPRESA

P á g i n a 59 | 73
Tabla n°61 “Departamentos”
ID_RE COD_ ID_TRA PI atributo atributo atributo atribut atributo atribut
GISTR DEPT BAJAD S numeri numeri numeri o cadena o
O O OR O co (1) co (2) co (3) cadena (2) cadena
(1) (3)
51284 FINA 6054159 1 9929 5902 5288      
42388 N 3
90469 FINA 6749636 1 1845 6645 3716      
79087 N 9
60916 RHU 6765137 2       RECL RECU CASO
3986 N 7 _35753 R_474 _39404
89 859 92
71176 RHU 3238944 2       RECL RECU CASO
14553 M _43738 R_495 _43039
94 028 45
26102 MAN 4684616 3 700 105  Spring    
73375 U 5 _2020
74677 MAN 2630972 3 536 464  Spring    
22551 U 6 _2020
11041 MAR 8693181 4 2 29  Autu    
26842 K 8 mn_20
20
84402 MAR 6376433 4 67 42   Sprin    
07576 K 2 g_2020
94548 INFO 5296637 5 1198 7848 8021 02_10_    
3872 R 0 19
77613 INFO 2013187 5 5063 2168 1964 24_04_    
41792 R 2 20
Fuente: Propia

Para el caso de los departamentos, puesto que poseen en común las claves id_trabajador y
cod_depto, y todas poseen el atributo piso, se adiciona los atributos de carácter numérico y de
cadena, con el fin de facilitar la normalización, por lo que al normalizar queda de la siguiente
manera:

 Atributo_Numérico (1): ESTADOS_FINANCIEROS(FINANZAS); PRODUCCION

(MANUFACTURA); EQUIPO_DE _TRABAJO(MARKETING);
ACTUALIZACIONES(INFORMATICA)

 Atributo_Numérico(2):CONTRATACIONES(FINANZAS);
MATERIALES(MANUFACTURA);PROYECTOS(MARKETING);
DISPOSITIVOS(INFORMATICA)

 Atributo_Numérico(3):DESPIDOS(FINANZAS);
GESTION_PLATAFORMAS(INFORMATICA)

 Atributo_Cadena(1):ID_EMPLEADO(R.HUMANOS);DISEÑOS(MANUFACTURA)
;CAMPAÑAS(MARKETING);FECHA_MANTENCION(INFORMATICA)

 Atributo_Cadena (2):ID_RECURSO (R. HUMANOS)

 Atributo_Cadena (3):ID_CASO (R. HUMANOS)

 COD_DEPARTAMENTO: FINAN(FINANZAS), RHUM (RECURSOS

HUMANOS), MANU(MANUFACTURA), MARK(MARKETING),
INFOR(INFORMATICA).

 ID_REGISTRO: NUMERO DE REGISTRO REALIZADO POR CADA

DEPARTAMENTO.

P á g i n a 60 | 73
  ID_TRABAJADOR: PROVIENE DE LA TABLA TRABAJADOR.

 PISO: CORRESPONDE AL PISO DONDE SE ENCUENTRA EL

DEPARTAMENTO.

Con respecto al resto de Entidades, como no poseen de manera “Natural” atributos en común
que precisen la implementación de la normalización (Ósea, no está dentro de sus atributos
originales), se ha decidido mantener su estructura original. A continuación, se presentarán las
entidades en formato de tabla con sus respectivos registros.

Tabla n°62.1 “Tienda Física”

ID_TIEND ID_CLIENT CANTIDA PRECIO_T MEDIO_PAG
A E D OT O
TCO00001  15247 13  3500135  Efectivo
STGO0004  45387 75  15000000  Tarjeta
CABA002
0  52312  22  4653799  Efecitvo
TCO00003  98752  03  125000  Efectivo
LAX00070  12457  95  23000850  Tarjeta
TCO00008  65328  45  12990457  Tarjeta
RIO00027  95145  43  12000990  Tarjeta
SAN00013  36528  79  15750352  Efectivo
Fuente: Propia

Tabla n°62.2 “Unión Tienda Física con Vendedor”

ID_TIENDA ID_VENDEDOR NUM_BOLETA
TCO00001 0325 0.0001245
STGO0004 0578 0.0007458
CABA0020 1523 0.2147558
TCO00003 0123 0.003597
LAX00070 1789 0.0456753
TCO00008 0589 0.0000658
RIO00027 0423 0.0048723
SAN00013 0129 0.1234777
Fuente: Propia

Tabla n°63 “Cliente”

ID_CLIE NOM_TITU COD_POS
NTE LAR TEL TAL CORREO RUT
 Cristian  927824  12.523.9
20452 
Perez 65  0000478  c.perez@gmail.com 54-6
 Humberto  963562  humbertocrack@gmai 13.203.65
14230 
Contreras 14  0000235 l.com 4-9 
 Rodolfo  853264  rodolfoelreno@gmail.  15.323.6
16358 
Renn 75  0000235 com 57-9
 Ulises  852314  ulisesdepredador@hot  17.323.5
43598 
Parada 67  0000495 mail.cl 27-2
 Rogelio  124563  Rogeeelio_123@hot  14.365.1
47520 
Fernandez 98  0000478 mail.com 48-0
 956478  jeanelbbcito@hotmail  13.655.7
74356 
 Jean Lock 45  0000235 .com 72-2
 Roberto  953261  caceresmypassion@g  16.208.9
24530 
Caceres 45  0000622 mail.cl 52-K
 Eugenia  953216  Euge.matu@gmail.co  12.988.7
10328 
Matulich 54  0000622 m 42-5
Fuente: Propia

P á g i n a 61 | 73
Tabla n°64 “Factura”
ID_FACTUR DESGLOZ NOM_EMPRES NOM_PNA
A FECHA E TEL A T RUBRO
 AN056*10  Hardy
000007523 
 17/10/2020 0  95236574   Schell  Industrial
000012457   14/08/2020   AN15*100  35624758  Pororas S.A    Industrial
  AO056*10  Carlos
000035222 
 22/01/2020 0  95647712   Sauterel  Comercial
 AP1350*20
000044457 
 26/02/2020 0  85520136  Artesanías TCO    Comercial
 Barbaba
000233314 
 10/10/2020  CO056*16  45402319   Villouta  Comercial
 Maria
000000785 
 13/09/2020 AP8753*12  85743692   Ejivaja  Industrial
000003564   18/09/2020  AP8753*19  91357486  Blond S.A    Industrial
 Teodoro  
000000011 
 01/02/2020  AP7852*21  90362289   Wickel Comercial
Fuente: Propia

Tabla n°65.1 “Transportista”

Matricula PESO_PQTE COMPAÑÍA DIM_PQTE
1  1.35  Starken  44x7.2
2  2.2  Starken  12x6.2
3  4.5  Chilexpress  11x4.3
4  7  Starken  26x1.6
5  3.2  Chilexpress  11x5.4
6  5.2  Chilexpress  74x6.3
7  6.3  Blue  65x2.2
8  8.1  Blue  94x3.3
Fuente: Propia
Tabla n°65.2 “Tabla transición Transportista”
MATRICUL
A ID_TRANSPORTISTA PATENTE
1 004578  DHJK75
2 012876  LFMB97
3 032568  RTGS45
4 000369  BC2324
5 000421  ABCD63
6 000852  BPLS74
7 012444  BP4775
8 035552  NMPS77
Fuente: Propia

Tabla n°66 “Transaccion”

ID_TRANSACCIO MEDIO_PAG PRECIO_TO HR_TRANSACCIO
N ID_ORDEN O T NOM_TITULAR N
02354785   1212321  Tarjeta  220114  Claudio Bravo  15:35
21457523   4533121   Tarjeta  235500  Alexis Sanchez  14:20
00224578   0002121   Tarjeta  122044  Marcelo Diaz  19:00
00124578  0012447   Tarjeta  750225  Eduardo Vargas  17:15
00002001  2214472   Tarjeta  955141  Gary Medel  12:06
00321174   0000124   Tarjeta  335122  Jorge Valdivia  12:15
00012455   0001214   Tarjeta  795504  Marcelo Salas  14:00
35521124   0003312   Tarjeta  442551  Ivan Zamorano  13:50
Fuente: Propia

Tabla n°67.1 “Central”

DIR_COMERCIA CAPACIDA INFRAESTRUCTUR
L ID_CIUDAD D A
Los Avellanedos
0775   8C23  18500  Metal

P á g i n a 62 | 73
Los Avellanedos
098  8C23  18500  Vidrio
Los Avellanedos
045 8C23  18500  Madera
Alameda 1432   MC46  25000  Vidrio
Alameda 9876   MC46  2500  Metal
Alameda 6543  MC46  4500  Vidrio
Rudecindo Ortega
675  9C17  1900  Vidrio
Rudecindo Ortega
355  9C17  1900  Metal
Fuente: Propia

Tabla n°67.2 “Tabla transición Central”

ID_CIUDAD CIUDAD
8C23 Concepción
MC46 Santiago
9C17 Temuco
Fuente: Propia

Tabla n°68 “Insumos”

ID_INSUM ID_PROVEE CANTID PRECIO_U PRECIO_T
OS DOR AD DETALLE NIT OT MATERIAL
254421  3541278  211 Anillo Oro  72000  15192000  Oro
546321   3545478  144 Aros baño Oro  72000  10368000  Oro
574621   1235578  001  Pulsera Bronce  10000  10000  Bronce
124475   5333516  200  Colgante Plata  12000  2400000  Plata
312445   3556132  321  Anillo Plata  12000  3852000  Plata
123123   2313278  457 Aros bebe Oro  72000  32904000  Oro
546763   9564323  655  Colgante Plata  12000  7860000  Plata
354348   3231477  663  Anillo Titaneo  65000  43095000  Titaneo
Fuente: Propia
Tabla n°69.1 “Proveedor”
ID_PROVEEEDO
AGENTE R CORREO NOM_TITULAR TEL
1 1235482 aravena.real@gmail.com Rigoberto Araneda 9596321
2 7123458 alberti.cat@gmail.com Catalina Alberti 65623147
3 2313358 barbosa.capitan@gmail.com Jean Barbosa 5242136
4 3535321 poret@gmail.com Daniel Poret 124213512
5 6385385 huahuasquil@gmail.com Julio Troncoso 3252362
6 3535122 klein@gmail.com Cristina Klein 4578125
7 3535333 borussia@gmail.com Dortmund Eche 1245125
8 8846452 loleant@gmail.com Lorena Capetillo 45123695
Fuente: Propia

Tabla n°69.2 “Tabla unión Proveedor con Insumo”

ID_INSUM MEDIO_PAG
Agente O DIR_FACT O
1  3251353  Costanera Norte 755  Tarjeta
2  2121351  Av Alemania 022  Tarjeta
3  2288855  Jorge Troncoso 1752  Efectivo
4   5331223  Los Estudiantes 122  Tarjeta
5  8945622  General Mackena 1545  Efectivo
6  7945666  Costanera Sur 758  Efectivo
7  5387354  Av Kennedy 788  Tarjeta
8  3895642  Los Pablos 1745  Efectivo
Fuente: Propia

Tabla n°70 “Vendedor”

ID_VENDED SALARIO_BAS COMISIO HRS_TRABAJAD HRS_EXTR
OR E N AS A
01015645   450350  352114  22  0

P á g i n a 63 | 73
51010213   622132  121455  12  12
01235644   447550  322047  22  5
01233021   1250355  200000  18  0
02485635   2000350  420000  40  10
01245832   444522  355211  23  0
27797899   322014  1220355  20  35
00440467   2500000  125000  45  5
Fuente: Propia

Tabla n°71 “Stock”

ID_PRODUCT PRECIO_ES CANTIDA
UBICACIÓN O FECHA PRECIO_U P D
NORTE1222   85432  17/08/2020  10000  10000  2
ESTE01215   53421  14/10/2020  15000  12000  15
SUDOESTE12
2   53153  12/11/2020  13000  12000  22
NORTE1355   38752  23/06/2020  14580  13000  15
SUR0025   87642  22/04/2020  12550  6500  29
SUR0033   13485  12/03/2020  23000  10000  14
SURESTE144   35438  14/09/2020  28550  2200  25
SUROESTE25
5   01205  28/01/2020  20200  1500  35
Fuente: Propia

Tabla n°72 “Producto”

ID_PRODUCT
O DISEÑO TAMAÑO TIPO MATERIAL PRECIO
 CONTEMPORAN
348351 
EO  MEDIANO  ANILLO  ORO  20000
 CONTEMPORAN
834523
EO  MEDIANO  ANILLO  ORO  10000
 CONTEMPORAN
538453 
EO  GRANDE  CADENA  ORO  15000
 CONTEMPORAN
238584 
EO  PEQUEÑO  AROS  TITANEO  32550
 CONTEMPORAN
315202 
EO  PEQUEÑO  CADENA  PLATA  78500
CONTEMPORANE
003158 
O   GRANDE  PULSERA  PLATA  52000
 CONTEMPORAN
384855 
EO MEDIANO  AROS  BRONCE  15200
 CONTEMPORAN
351535 
EO  MEDIANO  AROS  BRONCE  45700
Fuente: Propia

Tabla n°73 “Internet”

ID_OR ID_PRO ID_TRANS ID_E ID_CLI CANTI CUPON FECHA_C PRECIO_IN
DEN DUCTO ACCION NVIO ENTE DAD _DESC OMPRA TERNET
 02/02/202
53120 
 2251  0001241  2531  02001  01  NO 0  150000
 02/01/202
45421 
 2415  0001214  5235  00214  01  NO 0  125000

P á g i n a 64 | 73
  04/10/202
12455 
 0124  0035214  4471  00014  01  NO 0  130000
 12/10/202
24130 
 2035  0000022  0112  00002  05  NO 0  650000
 25/06/202
78850 
 6571  0001255  0215  00057  05  NO 0  350000
 21/03/202
54540 
 3521  0000025  0558  00003  07  NO 0  700000
 23/07/202
65521 
 1022  0000142  0001  00011  08  NO 0  7250000
 02/09/202
12335 
 1351  0000587  0003  00002  07  NO 0  950000
Fuente: Propia

Tabla n°74 “Envió”

ID_EN NUM_S ID_TRANSPO COD_PO FECHA_O DESTINAT FECHA_E
VIO EG RTISTA STAL RDEN DESTINO ARIO NVIO
 000001  TEMUC  RAUL  13/02/202
000254 
3213  222351  00124  12/02/2020 O JIMENEZ 0
 000000  CONCEP  ESTEBAN  06/06/202
000035 
2220  223542  00474  05/06/2020 CION LASTRA 0
 LOS  JORGE
000021  000044 ANGELE REBOLLE  03/07/202
4500  000331  00213  01/07/2020 S DO 0
 JUAN
000131
 000001  CHOL- ESPINDOL  08/09/202
1 
3512  002154  00135  07/09/2020 CHOL A 0
000023  000012  PITRUFQ  MARIA  12/05/202
2  3522  111545  00315  12/05/2020 UEN GRACIA 0
 000003  HELENA  24/06/202
000845 
5215  354841  00351  23/06/2020  GORBEA TORRES 0
000125  000001  LONCOC  PATRICIA  15/03/202
0  2351  848531  00315  14/03/2020 HE NOACK 0
 000000  SANTIA  JULIA  03/01/202
000250 
5315  384553  00153  01/01/2020 GO ROBERTS 0
Fuente: Propia

Tabla n°75 “Revendedor”

ID_REVEND ID_FACT ID_PROD CANTI PRECIO_ RUBR NOM_
EDOR URA UCTO DAD REV O REV CORREO
 02123561  Comer  Julio  nails@gmail.co
01202 
4  01020  2  12000 cial Cortez m
 01231351  Comer  Oscar  huerta@gmail.c
01240 
4  00201  1  15000 cial Huerta om
 12547874  Comer  Polo  prors@gmail.c
22568 
1  00023  6  20000 cial Res om
 Lorena
54110   01515643  Comer Tschuli  lots@gmail.co
2  85444  10  57400 cial a m
 09893453  Comer  Linda  garambito@gm
24525 
4  13162  11  78000 cial Flores ail.com
 Colom
29489   45689452  Comer ba  nasia@gmail.c
1  38452  7  12500 cial Sapunar om
 Rodrig
72854   96485420  Comer o  nomore@gmail
0  10102  2  15000 cial Flandez .com
 01564894  Comer  Andrea  harat@gmail.co
25422 
0  10684  15  32500 cial Harmon m
Fuente: Propia

Entidades:

1. Cliente

P á g i n a 65 | 73
 (PK)ID_CLIENTE: Es única y necesaria, para que bajo un ID se pueda identificar
quién es el usuario que compro un producto ya sea por venta.

 (PK)RUT: También es único, por lo que servirá como clave secundaria o foránea en
caso de ser necesario relacionar al cliente con una identidad existente en el país.

2. Trabajadores

 (PK)ID_TRABAJADOR: Engloba tanto a jefes como empleados, los relaciona entre sí

y con sus respectivos departamentos.

 (FK)COD_DEPTO: Clave foránea que relaciona al empleado con el departamento

correspondiente.

3. Departamentos

 (PK)ID_REGISTRO: Identificación única que permite almacenar los datos del

departamento en cuestión.

 (PK)COD_DEPTO: Código que asocia al departamento a su rubro y atributos

respectivos.

 (FK)ID_TRABAJADOR: Engloba tanto a jefes como empleados, los relaciona entre sí

y con sus respectivos departamentos.

4. Insumos

 (PK)ID_INSUMOS: Permite identificarlos de entre el resto de los productos además

de asociarlo al proveedor correspondiente.

 (FK) ID_PROVEEDOR: Identifica al proveedor y lo asocia al insumo que provee.

5. Proveedor

 (PK)ID_PROVEEDOR: Identifica al proveedor y lo asocia al insumo que provee.

 (FK)AGENTE: Permite Relacionar Proveedor con Insumos

#TABLA TRANSICION PROVEEDOR

 (PK)AGENTE: Permite Relacionar Proveedor con Insumos

 (FK)ID_INSUMOS: Permite identificarlos de entre el resto de los productos además

de asociarlo al proveedor correspondiente

6. Central

 (PK)DIR_COMERCIAL: La dirección comercial de la central permite identificarla por

ser una posición única, además de relacionarlo con sus departamentos
correspondientes. 

 (FK)ID_CIUDAD: Permite relacionar la dirección comercial con su respectiva ciudad

#TABLA DE TRANSICIÓN CENTRAL

 (PK) ID_CIUDAD: Permite relacionar la dirección comercial con su respectiva ciudad

7. Vendedor

 (PK)ID_VENDEDOR: Identifica al vendedor de entre el resto de personal.

8. Stock

P á g i n a 66 | 73
 (PK)UBICACIÓN: Lugar donde se localizan lo(s) producto(s), la cual puede ser en
alguna de las tiendas físicas o en alguna de las locaciones de
almacenamiento(bodegas).

 (FK)ID_PRODUCTO: Lo identifica del resto de productos que se venden por la

empresa de las distintas formas existentes.

9. Producto

 (PK)ID_PRODUCTO: Lo identifica del resto de productos que se venden por la

empresa de las distintas formas existentes.

10. Revendedor

 (PK)ID_REVENDEDOR: Permite que cada factura esté asignada a un revendedor

específico, además de identificar entre todos los revendedores que compran los
distintos productos.

 (FK)ID_FACTURA: Este número permite relacionar la factura con la compra por

internet y con la venta a revendedores.

 (FK)ID_PRODUCTO: Lo identifica del resto de productos que se venden por la

empresa de las distintas formas existentes.

11. Internet

 (PK)ID_ORDEN: Esta id de orden relaciona a las transacciones realizadas con la orden

específica de compra por internet, además asocia a los clientes a la compra online
específica y a su factura correspondiente. por último, los envíos también están
asignados a esta id, para saber cuál es la compra que se está enviando.

 (FK)ID_PRODUCTO: Lo identifica del resto de productos que se venden por la

empresa de las distintas formas existentes.

 (FK)ID_TRANSACCION: Permite identificar el proceso específico de compra vía

online en base a una id de la transacción. 

 (FK)ID_ENVIO: Este ID nos permite hacer el seguimiento del producto el cual fue
comprado por internet, evitando pérdidas del producto o para que nuestro cliente sepa
dónde se encuentra su producto en cualquier momento.

 (FK)ID_CLIENTE: Es única y necesaria, para que bajo un ID se pueda identificar

quién es el usuario que compro un producto ya sea por venta.

12. Envio

 (PK)ID_ENVIO: Este ID nos permite hacer el seguimiento del producto el cual fue
comprado por internet, evitando pérdidas del producto o para que nuestro cliente sepa
dónde se encuentra su producto en cualquier momento.

 (PK)NUM_SEGUIMIENTO: Numero de envió, el cual permite al usuario ver la

localización de su compra hecha por internet.

 (FK)ID_TRANSPORTISTA: Con este ID sabemos quién es el transportista al cual se

le ha designado el envío del producto comprado vía internet.

13. Transportista

 (PK)MATRICULA: Permite relacionar Transportista con Internet

#TABLA DE TRANSICIÓN TRANSPORTISTA

 (FK)MATRICULA: Permite relacionar Transportista con Internet

P á g i n a 67 | 73
  (PK)ID_TRANSPORTISTA: Con este ID sabemos quién es el transportista al
cual se le ha designado el envío del producto comprado vía internet.

14. Transaccion

 (PK)ID_TRANSACCION: Permite identificar el proceso específico de compra vía

online en base a una id de la transacción. 

 (FK)ID_ORDEN: Esta id de orden relaciona a las transacciones realizadas con la orden

específica de compra por internet, además asocia a los clientes a la compra online
específica y a su factura correspondiente. por último, los envíos también están
asignados a esta id, para saber cuál es la compra que se está enviando.

15. Tienda

 (PK)ID_TIENDA: Se le asocia a los distintos vendedores para saber a qué tienda

pertenecen, además de identificar qué tienda visitaron los clientes y los productos que
vende.

 (FK)ID_CLIENTE: Es única y necesaria, para que bajo un ID se pueda identificar

quién es el usuario que compro un producto ya sea por venta.

 (FK)NUM_BOLETA: Permite relacionar Tienda Fisica con Vendedor

#TABLA DE RELACION TIENDA FISICA CON VENDEDOR

 (PK)NUM_BOLETA: Permite relacionar Tienda Fisica con Vendedor

 (FK)ID_TIENDA: Se le asocia a los distintos vendedores para saber a qué tienda

pertenecen, además de identificar qué tienda visitaron los clientes y los productos que
vende.

 (FK)ID_VENDEDOR: Identifica al vendedor de entre el resto de personal.

16. Factura

 (PK)ID_FACTURA: Este número permite relacionar la factura con la compra por

internet y con la venta a revendedores.

5.3 Modelo Relacional Normalizado

P á g i n a 68 | 73
P á g i n a 69 | 73
 VII. RESULTADOS Y APORTES

7.1 Resultados

7.2 Aportes

P á g i n a 70 | 73
 VIII. REFERENCIA ELECTRÓNICA

1) (2020). Retrieved 3 November 2020, from

2) (2020). Retrieved 4 November 2020, from

http://www.codecompiling.net/files/slides/BD_clase_07_ERE_relacional.pdf

3) ¿Qué es MongoDB?. (2020). Retrieved 3 November 2020, from

https://www.mongodb.com/es/what-is-mongodb

4) ¿Qué es una base de datos en la nube?. (2020). Retrieved 3 November 2020, from
https://www.oracle.com/es/database/what-is-a-cloud-database/

5) 03. ARQUITECTURA DE UNA BASE DE DATOS. (2007). Retrieved 3

November 2020, from https://basesdedatos.wordpress.com/arquitectura-de-una-
base-de-datos/

6) Alexan15ve, M. (2020). Oracle - Monografias.com. Retrieved 3 November 2020,

from https://www.monografias.com/trabajos25/oracle/oracle.shtml#mejoras

7) Análisis de Datos: Definición, elementos y procesos. (2020). Retrieved 1 November

2020, from https://www.tecnologias-informacion.com/analisis.html

8) Apache CouchDB. (2020). Retrieved 3 November 2020, from

https://couchdb.apache.org/

9) Base de Datos - Concepto, tipos y ejemplos. (2020). Retrieved 13 November 2020,

from https://concepto.de/base-de-datos/

10) Betancourt, G. G., Vergara, M. P. L., & Ramírez, J. B. B. (2009). Estudio

exploratorio sobre la influencia de la visión familiar y la visión patrimonial en el
crecimiento en ventas de la empresa familiar colombiana. Cuadernos de
administración, 22(39).

11) CouchDB - EcuRed. (2020). Retrieved 3 November 2020, from

https://www.ecured.cu/CouchDB

12) CouchDB. (2020). Retrieved 3 November 2020, from

https://prezi.com/0hyzdzgjddeq/couchdb/

13) GestioPolis.com, E. (2001). ¿Qué es Data Mining? • GestioPolis. Retrieved 1

November 2020, from https://www.gestiopolis.com/que-es-data-mining/

14) https://videlcloud.wordpress.com/2017/01/06/las-reglas-de-normalizacion-
explicadas-facilmente/

15) JeisonGrajales. (2018). Bases de datos dinamicas y estaticas. Retrieved 3

November 2020, from https://es.slideshare.net/JeisonGrajales/bases-de-datos-
dinamicas-y-estaticas#:~:text=%EF%81%B5%20Las%20bases%20de
%20datos,realizar%20proyecciones%20y%20tomar%20decisiones

16) MongoDB: qué es, cómo funciona y cuándo podemos usarlo (o no). (2014).
Retrieved 3 November 2020, from https://www.genbeta.com/desarrollo/mongodb-
que-es-como-funciona-y-cuando-podemos-usarlo-o-no

17) PostgreSQL: ¿Qué es? Características, Ventajas y Desventajas. (2020). Retrieved

3 November 2020, from https://hostingpedia.net/postgresql.html
18) PowerData, G. (2020). Big Data: ¿En qué consiste? Su importancia, desafíos y
gobernabilidad. Retrieved 1 November 2020, from https://www.powerdata.es/big-
data

P á g i n a 71 | 73
19) Qué es Apache Cassandra. (2019). Retrieved 3 November 2020, from
https://openwebinars.net/blog/que-es-apache-cassandra/

20) Qué es MySQL: Características y ventajas. (2019). Retrieved 3 November 2020,

from https://openwebinars.net/blog/que-es-mysql/

21) Qué es SQL Server. (2019). Retrieved 3 November 2020, from

https://openwebinars.net/blog/que-es-sql-server/

22) Redis. (2020). Retrieved 1 November 2020, from https://redis.io/

23) Rendón, Y. (2020). Bases de datos relacionales vs. no relacionales. Retrieved 1

November 2020, from https://www.pragma.com.co/academia/lecciones/bases-de-
datos-relacionales-vs.-no-relacionales

24) Riak KV. (2020). Retrieved 3 November 2020, from

https://riak.com/products/riak-enterprise/index.html

25) Tipos de bases de datos | Clasificación por contenido y modelo. (2019). Retrieved
1 November 2020, from https://www.grapheverywhere.com/tipos-bases-de-datos-
clasificacion/

26) Urrutia, V. (2017). LAS REGLAS DE NORMALIZACIÓN EXPLICADAS

FACILMENTE. Retrieved 9 November 2020, from

27) What is Oracle Database. (2020). Retrieved 3 November 2020, from

https://www.oracletutorial.com/getting-started/what-is-oracle-database/

P á g i n a 72 | 73
 IX.TABLA DESCRIPTIVA de Aportes en el
PROYECTO de BBDD – Evaluación N°2
INTEGRANTE Indicar los Reflexión sobre lo aprendido Punt
ítems por s
realizados traba
en el 7]
Proyecto
Evaluación
N°2
1 Francisco Beratto Items 2,4,5 Lo que he aprendido en este trabajo fue lo importante que es una base de 2. 7
datos para una empresa ya que puede almacenar todos los datos de la
3. 7
empresa en un único lugar, facilitando que se compartan los datos entre los
mismos. 4. 7
También aprendí a normalizar diferentes tipos de tablas para evitar que se
repitan datos en múltiples tablas y dejar todo en una sola tabla.
2 Daniel Hermosilla Items 2,3,4,5 Gracias a este trabajo pude aprender lo importante y necesario que es una 1. 7
base de datos para almacenar y relacionar datos que generalmente si no se
3. 7
lleva un registro adecuado o simplemente no se registra. Además de entender
como múltiples empresas y marcas usan este sistema, ya que si bien se ve 4. 7
siempre es mucho más complejo de lo que parece y su nivel de importancia
es claramente alto.
3 Thomas Redel Items 2,4,5 Aprendí mucho de la materia, ya que en una parte del trabajo me toco buscar 1. 7
los significados y luego aplicarla. Por otra parte, repasé bastante la materia
2. 7
pasada y aprendí a relacionarla con los nuevos aprendizajes sobre bases de
datos. Creo que es un trabajo bastante extenso, pero a la vez necesario porque 4. 7
es una materia que no solo se aprende en horarios de clase si no que con esta
clase de trabajos que demanda hacerlo en horas extras.
4 Daniel Teke Items 1,2,3,4,5,6 Si bien al principio dude si usar SQL para la base de datos sea lo mejor, 1. 6,5
debido a que al utilizar NO-SQL se puede extraer de manera más rápido los
2. 6,5
datos, SQL permite una edición de los datos de manera mucho más rápida y
sencilla. Y puesto que el precio de las joyas está en relación al precio actual 3. 7
de los insumos, SQL es más práctico. A su vez, este trabajo me motivo a
seguir aprendiendo sobre programación, por lo que actualmente estoy
mejorando mis habilidades de Python , JavaScript, M.S.SQL y aprendiendo
Assembler en conjunto con C++.

P á g i n a 73 | 73