Victor Andres Vasquez Hernández 0901 – 20 – 3200

Curso Base de Datos II

▪ Sistemas Distribuidos de Base de Datos
▪ Definiciones
▪ Almacenamiento distribuido de datos
▪ Transacciones distribuidas
▪ Control de transacciones en la base de datos distribuida
▪ Ventajas
▪ Desventajas
▪ Diseño de sistemas distribuidos
▪ La distribución de los datos
▪ Centralizada
▪ Distribuida
▪ Repica
▪ Esquema distribuido
▪ Componentes de un sistema gestor distribuido
▪ Los pasos a seguir para diseñar una base de datos distribuida
▪ Esquema de y distribución de datos
▪ Tipos de fragmentación
▪ Analisis multidimensional y datawarehouse
▪ Base de datos OLAP, ROLAP y MOLAP
▪ El esquema estrella y el esquema snowfake
▪ Jerarquías y resúmenes
▪ Datawarehouse y Datamart
▪ Definición Datawarehouse
▪ Definición Datamart
▪ Inteligencia del negocio (bussiness integence)
▪ Data mining
▪ Data science
▪ Data análisis

▪ Base de datos orientada a objetos

▪ Basada en objetos, orientado a objetos y objetos relacionales
▪ Estructura de objetos y jerarquías
▪ SQL de objetos y SQL ANSI 2003
▪ Campos múltiples y arrays
▪ Tablas anidadas y jerarquías
▪ Base de datos NoSQL
▪ Principales tipos de Base de Datos
▪ Que son las bases de datos NoSQL
▪ Características y ventajas de las bases de datos NoSQL
▪ Análisis de fortalezas y debilidades de las BBDD NoSQL
▪ ¿Cuándo utilizar una BBDD NoSQL?
▪ Principales gestores de BBDD NoSQL
Se caracterizan por almacenar la
información en varias computadoras
conectadas entre sí, a las cuales el usuario
puede acceder desde cualquier sitio como
si se tratara de una red local.
se conoce como sistema de almacenamiento distribuido todo aquel que
permite almacenar ficheros online. Su principal característica es la poder
guardar archivos (documentos, imágenes, vídeos, etc.) en la red. En la mayoría
de los casos, este sistema tiene un uso personal, aunque también es utilizado
en muchas empresas. Este tipo de aplicaciones se enmarcan dentro de la
"filosofía 2.0", donde se necesitan usuarios para que las ideas tengan éxito.
El almacenamiento distribuido es un sistema de almacenamiento definido por
software que permite el acceso a los datos, en cualquier momento, desde
cualquier lugar y solo a aquellas personas que queramos que accedan. El
almacenamiento distribuido es un sistema de gestión de volúmenes lógicos
diseñado para procesar el escalado y el acceso a los datos en un entorno de
alta disponibilidad (HA) con inteligencia para detectar y responder ante fallos
y ciberataques. Se reemplaza la arquitectura tradicional de tres capas por un
sistema de archivos distribuido que se compone de datos almacenados en
clústeres de nodos de almacenamiento distribuidos geográficamente. El
sistema de almacenamiento incluye funcionalidades que sincronizan y
coordinan los datos en los nodos del clúster.
Una transacción distribuida es un tipo de transacción con dos o más hosts de red
comprometidos. En general, los hosts proporcionan recursos y un administrador de
transacciones es responsable de desarrollar y manejar la transacción. Como cualquier otra
transacción, una transacción distribuida debe incluir las cuatro propiedades ACID
(atomicidad, consistencia, aislamiento, durabilidad). Dada la naturaleza del trabajo, la
atomicidad es importante para garantizar un resultado de todo o nada para el paquete de
operaciones (unidad de trabajo).

Una transacción distribuida es una transacción que

afecta a varios recursos. Para que una transacción
distribuida se confirme, todos los participantes deben
garantizar que los cambios en los datos serán
permanentes. Los cambios deben conservarse a pesar
de bloqueos del sistema u otros eventos imprevistos. Si
alguno de los participantes no cumple esta garantía,
toda la transacción da error y se revertirán los cambios
en los datos en el ámbito de la transacción.
El manejo de transacciones tiene dos aspectos principales, el control de recuperación y el
control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el
ambiente distribuido.
En cuanto al control de concurrencia, esta función en un ambiente distribuido estará basada
con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos.

• Permiten trabajar a cada nodo de la red con autonomía local

• Aumentan la disponibilidad, confiabilidad y eficiencia en el acceso a la información.
• Se pueden expandir de forma indefinida en función de las necesidades de la empresa u
organización.
• Permiten la escalabilidad sin necesidad de grandes inversiones.
• Los recursos se comparten entre nodos, de manera que se puede acceder a toda la
información desde cualquier sitio.
• Resulta más difícil establecer mecanismos para controlar el acceso a los datos y garantizar
la seguridad.
• Los errores en la red pueden tener graves consecuencias para la privacidad de la
información.
• Es un sistema más complejo de implementar.
• Conseguir una transparencia óptima puede suponer un importante gasto de tiempo y
dinero.
• Falta de experiencia y ausencia de estándares en el desarrollo e implementación de estas
bases de datos.
• Posibles problemas de rendimiento o fiabilidad derivados del punto anterior.
El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre
la ubicación de los programas que accederán a la base de datos y sobre los propios datos
que constituyen esta última, a lo largo de los diferentes puestos que configuren una red de
ordenadores. La ubicación de los programas, a priori, no debería suponer un excesivo
problema dado que se puede tener una copia de ellos en cada máquina de la red (de
hecho, en este documento se asumirá que así es).

Tradicionalmente se ha clasificado la organización de los sistemas de bases de datos

distribuidos sobre tres dimensiones: el nivel de compartición, las características de acceso a
los datos y el nivel de conocimiento de esas características.
▪ Centralizada:
Los sistemas de bases de datos centralizadas son aquellos que se ejecutan en un único sistema
informático sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el rango
desde los sistemas de base de datos monousuario ejecutándose en computadoras personales
hasta los sistemas de bases de datos de alto rendimiento ejecutándose en grandes sistemas.
▪ Distribuida:
Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada uno de las
cuales puede participar en la ejecución de transacciones que accedan a datos de una o varias
localidades. La diferencia principal entre los sistemas de base de datos centralizados y distribuidos
es que, en los primeros, los datos residen en una sola localidad, mientras que, en los últimos, se
encuentran en varias localidades.
▪ Replicación:
El esquema de base de datos distribuida replicada se basa en que cada nodo debe tener una
réplica completa de la base de datos. Se trata de un método que supone altos costes para el
mantenimiento de la información, ya que cada cambio en una copia debe ser realizada también en
todas las demás. Por ello, es un sistema que resulta muy útil en bases de datos en las que se van a
hacer pocas tareas de escritura, pero muchas de lectura.
▪ Hardware: Los nodos de procesamiento pueden estar formados por múltiples y distintos tipos de
hardware.

▪ Software:
▪ El programa principal que necesitamos considerar en un sistema de base de datos distribuida es el DDBMS.

▪ En un SGBD distribuido, la base de datos se almacena en varios computadores que se pueden comunicar a su vez
por distintos medios de comunicación. Se denomina con el término de emplazamientos o nodos a todos aquellos
computadores que pertenecen a un sistema distribuido.

▪ Datos: Una base de datos distribuida puede no estar duplicada, parcialmente duplicada o totalmente
duplicada. Una base de datos parcialmente duplicada contiene ciertos elementos de datos que están
duplicados y algunos que no lo están.

▪ Procedimientos: Los sistemas de base de datos distribuidos contienen una multitud de componentes de
procesamiento. En los sistemas distribuidos más sencillos, los datos no están duplicados, y sólo el nodo
que almacena los datos puede actualizarlos.

▪ Personal: Los sistemas con un DDBMS complejo y poderoso imponen pocas demandas especiales sobre
los usuarios. De hecho, los usuarios no saben que están procesando datos distribuidos.
▪ FRAGMENTACIÓN HORIZONTAL (HF): La fragmentación horizontal se realiza sobre las tuplas de la
relación. Cada fragmento será un subconjunto de las tuplas de la relación. Existen dos variantes de
la fragmentación horizontal: la primaria y la derivada. La fragmentación horizontal primaria de una
relación se desarrolla empleando los predicados definidos en esa relación. Por el contrario, la
fragmentación horizontal derivada consiste en dividir una relación partiendo de los predicados
definidos sobre alguna otra

▪ FRAGMENTACIÓN VERTICAL (VF): Fragmenta una relación global a través de la proyección de

atributos. El objetivo de la fragmentación vertical consiste en dividir la relación en un conjunto de
relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un
fragmento. Sobre este marco, una fragmentación óptima es aquella que produce un esquema de
división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos.

▪ FRAGMENTACIÓN MIXTA: Generada a través de la aplicación recursiva de operadores del álgebra

relacional en los fragmentos. En muchos casos la fragmentación vertical u horizontal del esquema
de la base de datos no será suficiente para satisfacer los requisitos de las aplicaciones. Podemos
combinar ambas, utilizando por ello la denominada fragmentación mixta.
Es un tipo de base de datos optimizada para
aplicaciones de almacén de datos y
procesamiento analítico en línea, suelen
crearse a partir de base de datos relacionales
existentes.
▪ OLAP:

Los sistemas OLAP son bases de datos orientadas al procesamiento analítico. Este análisis suele
implicar, generalmente, la lectura de grandes cantidades de datos para llegar a extraer algún tipo de
información útil: tendencias de ventas, patrones de comportamiento de los consumidores, elaboración
de informes complejos… etc. Este sistema es típico de los datamarts.
▪ ROLAP:

La arquitectura ROLAP, accede a los datos almacenados en un datawarehouse para proporcionar los
análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor
contra las bases de datos relacionales. El sistema ROLAP utiliza una arquitectura de tres niveles. La base
de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP
proporciona la funcionalidad analítica. El nivel de base de datos usa bases de datos relacionales para el
manejo, acceso y obtención del dato. El nivel de aplicación es el motor que ejecuta las consultas
multidimensionales de los usuarios.
▪ MOLAP:

La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su
principal premisa es que el OLAP está mejor implantado almacenando los datos
multidimensionalmente. El sistema MOLAP utiliza una arquitectura de dos niveles: las bases de datos
multidimensionales y el motor analítico. La base de datos multidimensional es la encargada del manejo,
acceso y obtención del dato.
 Base para la comparación ROLAP
ROLAP significa procesamiento analítico
Forma completa
relacional en línea.
Los datos se almacenan y se obtienen del
Almacenamiento y obtenido
almacén de datos principal.
Los datos se almacenan en forma de
Formulario de datos
tablas relacionales.
Volúmenes de datos Grandes volúmenes de datos.
Utiliza consultas SQL complejas para
Tecnología
obtener datos del almacén principal.
ROLAP crea una vista multidimensional de
Ver
datos de forma dinámica.
Acceso Acceso lento.
MOLAP
MOLAP significa procesamiento analítico
multidimensional en línea.
Los datos se almacenan y se obtienen de
las MDDB de la base de datos propietaria.
Los datos se almacenan en la gran matriz
multidimensional formada por cubos de
datos.
Los datos de resúmenes limitados se
guardan en MDDB.
El motor MOLAP creó cubos de datos
precalculados y prefabricados para vistas
de datos multidimensionales.
La tecnología de matriz dispersa se utiliza
para gestionar la escasez de datos.
MOLAP ya almacena la vista
multidimensional estática de datos en
MDDB.
Acceso más rápido.
El esquema de estrella es un enfoque de modelado maduro ampliamente adoptado por los
almacenes de datos relacionales. Requiere que los modeladores clasifiquen las tablas del
modelo como dimensiones o hechos.

▪ Las tablas de dimensiones describen entidades empresariales (las cosas que se modelan).
Las entidades pueden incluir productos, personas, lugares y conceptos, incluido el propio
tiempo. La tabla más coherente de un esquema de estrella es una tabla de dimensiones de
fecha. Una tabla de dimensiones contiene una columna (o columnas) de clave que actúa
como identificador único y columnas descriptivas.

▪ Las tablas de hechos pueden almacenar observaciones o eventos, y pueden ser pedidos de
ventas, existencias, tasas de cambio, temperaturas, etc. Una tabla de hechos contiene
columnas de clave de dimensiones relacionadas con las tablas de dimensiones y columnas
de medida numéricas. Las columnas de clave de dimensiones determinan
la dimensionalidad de una tabla de hechos, mientras que los valores de clave de
dimensiones determinan la granularidad de una tabla de hechos.
A continuación, se destacarán las principales
características del Esquema en Estrella:
• Es el más simple de interpretar .
• Posee los mejores tiempos de respuesta.
• Es soportado por todos los visores OLAP.
• Su diseño es sencillo de mantener y
actualizar.
• Existe paralelismo entre su diseño y la
forma en que l@s usuari@s visualizan y
manipulan los datos.
• Es el modelo elegido para prototipado
rápido.
Esquema en copo de nieve (bola de nieve) es una variedad más compleja del esquema
estrella. El afinamiento está orientado a facilitar mantenimiento de dimensiones.
Lo que distingue a la arquitectura en copo de nieve del esquema estrella, es que las tablas
de dimensiones en este modelo representan relaciones normalizadas (3NF) y forman parte
de un modelo relacional de base de datos.
Con varios usos del esquema en bola de nieve, el más común es cuando las tablas de
dimensiones están muy grandes o complejos y es muy difícil representar los datos en
esquema estrella.
Los esquemas de copo de nieve están hechos para consultas flexibles sobre relaciones y
dimensiones más complicadas. Es ideal para las relaciones uno a muchos y muchos a
muchos entre los niveles de dimensión y, por lo general, se asocia con almacenes de datos y
almacenes de datos dimensionales, en los que la velocidad de recuperación de datos es más
crítica que la eficiencia en la manipulación de datos. Los esquemas de copo de nieve se usan
más comúnmente con herramientas de consulta avanzadas, que crean una capa de
abstracción entre usuarios y tablas sin formato para escenarios que tienen múltiples
consultas con especificaciones elaboradas.
A continuación, se destacarán las principales
características del Esquema Copo de Nieve:
• Posibilita la segregación de los datos de las
tablas de Dimensiones.
• Puede implementarse después de que se
haya desarrollado un Esquema en Estrella.
• Posee mayor complejidad en su estructura.
• Utiliza menos espacio de almacenamiento.
• Es más eficiente en el caso de tablas de
Dimensiones con gran cantidad de registros.
• Su semántica se ajusta a las representaciones
de las diferentes Jerarquías de Dimensiones.
• Se deben planificar correctamente las
uniones e el indexado, a fin de NO generar
sobrecarga en la resolución de consultas.
El concepto de jerarquía permite que la información sé que almacena en las bases de datos
multidimensionales se organice en base a diferentes niveles de abstracción.
• Nivel 1: Todos
• Nivel 2: Continentes > Europa, Asia
• Nivel 3: Países > Europa > Francia, Italia, España
• Nivel 4: Ciudades > España > Madrid, Barcelona, Sevilla
• Nivel 5: Oficinas > Madrid > Oficina 1, Oficina 2, Oficina 3
Un data warehouse es un repositorio unificado para todos los datos que recogen los diversos
sistemas de una empresa. El repositorio puede ser físico o lógico y hace hincapié en la
captura de datos de diversas fuentes sobre todo para fines analíticos y de acceso.

Normalmente, un data warehouse se aloja en un servidor corporativo o cada vez más, en la

nube. Los datos de diferentes aplicaciones de procesamiento de transacciones Online (OLTP)
y otras fuentes se extraen selectivamente para su uso por aplicaciones analíticas y de consultas
por usuarios.

Data Warehouse es una arquitectura de almacenamiento de datos que permite a los

ejecutivos de negocios organizar, comprender y utilizar sus datos para tomar decisiones
estratégicas. Un data warehouse es una arquitectura conocida ya en muchas empresas
modernas.
Estructura de un Data Warehouse

▪ La arquitectura de un data warehouse puede ser dividida en tres estructuras simplificadas:

básica, básica con un área de ensayo y básica con área de ensayo y data marts.

▪ Con una estructura básica, sistemas operativos y archivos planos proporcionan datos en
bruto que se almacenan junto con metadatos. Los usuarios finales pueden acceder a ellos
para su análisis, generación de informes y minería.

▪ Al añadir un área de ensayo que se puede colocar entre las fuentes de datos y el almacén,
ésta proporciona un lugar donde los datos se pueden limpiar antes de entrar en el almacén.
Es posible personalizar la arquitectura del almacén para diferentes grupos dentro de la
organización.

▪ Se puede hacer agregando data marts, que son sistemas diseñados para una línea de
negocio en particular. Se pueden tener data marts separados para ventas, inventario y
compras, por ejemplo, y los usuarios finales pueden acceder a datos de uno o de todos los
data marts del departamento.
▪ Un data mart es un sistema de almacenamiento de datos que contiene información
específica de la unidad de negocio de una organización. Contiene una parte pequeña y
específica de los datos que la empresa almacena en un sistema de almacenamiento más
grande. Las empresas utilizan un data mart para analizar la información específica de cada
departamento de manera más eficiente. Brinda datos resumidos que las partes interesadas
clave pueden utilizar para tomar decisiones informadas rápidamente.

¿Cuáles son los tipos de data mart?

Estos son los diferentes tipos de data marts.

▪ Data mart dependiente

Un data mart dependiente llena su almacenamiento con un subconjunto de información de

un almacenamiento de datos centralizado. El almacenamiento de datos recopila toda la
información de los orígenes de datos. A continuación, el data mart consulta y recupera
información específica del sujeto del almacenamiento de datos.
▪ Ventajas y desventajas: La mayoría de los trabajos de gestión y administración de datos se realizan en el
almacenamiento de datos. Esto significa que los analistas de negocios no necesitan estar altamente
capacitados en la administración de bases de datos para usar la información del data mart. Si bien los data
marts dependientes facilitan mucho la recuperación de información, presentan un único punto de falla. Si el
almacenamiento de datos falla, todos los data marts conectados también fallarán.

▪ Data mart independiente

Un data mart independiente no depende de un almacenamiento de datos central ni de ningún otro data mart.
Cada data mart recopila información de sus fuentes en lugar de hacerlo de un almacenamiento de datos. Los
data marts independientes son adecuados para las empresas más pequeñas, pero solo los departamentos en
específico deben acceder a la información y analizarla.

▪ Ventajas y desventajas: Las empresas pueden configurar data marts independientes con relativa facilidad. Sin
embargo, administrarlos puede resultar difícil. Esto se debe a que los analistas de negocios deben realizar
tareas administrativas de bases de datos en cada data mart. Es sencillo compartir datos entre diferentes data
marts por medio de estrategias como el uso compartido de datos. Los departamentos pueden leer los datos
de otro departamento e incluso aumentarlos con sus propios datos. Sin embargo, se debe implementar una
estrategia sólida de catalogación de datos para garantizar que cada departamento sepa lo que está
buscando.
El modelado de datos es el proceso de analizar y definir todos los diferentes datos que su
negocio recopila y produce, así como las relaciones entre esos bits de datos. Los conceptos
de modelado de datos crean representaciones visuales de los datos a medida que se utilizan
en su negocio, y el propio proceso es un ejercicio de conocimiento y aclaración de sus
requisitos de datos.
Al modelar sus datos, documentará los datos que tiene, cómo los usa y cuáles son sus
requisitos relacionados con el uso, la protección y la gobernanza. Mediante el modelado de
datos, su organización:
• Crea una estructura para la colaboración entre su equipo de TI y sus equipos comerciales.
• Expone oportunidades para mejorar los procesos comerciales, al definir las necesidades y los usos
de los datos.
• Ahorra tiempo y dinero en TI y en inversiones en procesos, mediante una planificación adecuada
por adelantado.
• Reduce los errores (y la entrada de datos redundantes propensa a errores), al tiempo que mejora la
integridad de los datos.
• Aumenta la velocidad y el rendimiento de la recuperación y el análisis de datos, al planificar la
capacidad y el crecimiento.
• Establezca y supervise indicadores clave de rendimiento adaptados a sus objetivos empresariales.
El minado de datos es un conjunto de técnicas y tecnologías que permiten explorar grandes
bases de datos, de manera automática o semiautomática, con el objetivo de encontrar
patrones repetitivos que expliquen el comportamiento de estos datos.
A pesar de que la idea del Data Mining puede parecer una innovación tecnológica muy
reciente, en realidad este término apareció en los años sesenta conjuntamente con otros
conceptos como, por ejemplo, el data fishing o data archeology. No obstante, no fue hasta los
años ochenta cuando empezó su consolidación.
La minería de datos surgió con la intención o el objetivo de ayudar a comprender una enorme
cantidad de datos y que estos pudieran ser utilizados para extraer conclusiones para
contribuir en la mejora y el crecimiento de las empresas. Sobre todo, por lo que hace a las
ventas o fidelización de clientes.
Su principal finalidad es explorar, mediante la utilización de distintas técnicas y tecnologías,
bases de datos enormes de manera automática. El objetivo es encontrar patrones repetitivos,
tendencias o reglas que expliquen el comportamiento de los datos que se han ido
recopilando con el tiempo. Estos patrones pueden encontrarse utilizando estadísticas o
algoritmos de búsqueda próximos a la Inteligencia Artificial y a las redes neuronales.
La Ciencia de Datos es una de las disciplinas con mayor demanda profesional, dado que la
cantidad de usos y aplicaciones en el mundo real es cada vez mayor. El reconocimiento
facial, las órdenes por voz a los asistentes virtuales, los chatbots, la prevención del fraude
bancario, el otorgamiento de préstamos y el diagnóstico médico nos dan una idea de las
oportunidades que se presentan en diferentes industrias.

Data science está intrínsecamente ligado con inteligencia artificial, machine learning, deep
learning, estadística y procesamiento de lenguaje natural, entre otras disciplinas. La ciencia
de datos está presente en nuestras vidas en todo momento, aunque no nos demos cuenta:
cuando hacemos una búsqueda en Google, cuando Netflix nos recomienda una película o
cuando LinkedIn nos sugiere una búsqueda laboral.

Los profesionales que cuenten con las herramientas adecuadas, visión de negocios,
creatividad y espíritu emprendedor estarán frente a una gran oportunidad para tener una
ventaja competitiva en el mundo laboral.
El análisis de datos es el proceso de exploración, transformación y examinación de datos para
identificar tendencias y patrones que revelen insights importantes y aumenten la eficiencia
para respaldar la toma de decisiones. Una estrategia moderna de análisis de datos les
permite a los sistemas y a las organizaciones trabajar a partir de análisis automatizados
en tiempo real, lo que garantiza resultados inmediatos y de gran impacto.

El proceso de análisis de datos se basa en varios pasos y fases. Es posible que las
conclusiones de fases posteriores requieran volver a trabajar en una fase anterior, lo que
implica un proceso más cíclico que lineal. Lo más importante es que el éxito de los procesos
de análisis de datos depende de la capacidad de repetición y automatización de cada uno de
estos pasos.
Es una base de datos en la que la información
está representada mediante objetos, como los
presentes en la programación orientada a
objetos.
▪ Base de datos de objetos:
El modelo de base de datos orientada a objetos agrupa la información en paquetes
relacionados entre sí: los datos de cada registro se combinan en un solo objeto, con todos sus
atributos. De esta manera, toda la información está disponible en el objeto, ya que sus datos
quedan agrupados en lugar de distribuidos en diferentes tablas. En los objetos no solo pueden
guardarse los atributos, sino también los métodos, lo que refleja la afinidad de estas bases de
datos con los lenguajes de programación orientados a objetos: al igual que en estos, cada
objeto presenta un conjunto de acciones que pueden llevarse a cabo.
Los objetos se dividen a su vez en clases. Más concretamente, un objeto es una unidad
concreta de una clase abstracta, lo que crea una jerarquía de clases y subclases. Dentro de esta
estructura, las subclases adoptan las propiedades de las clases superordinadas y las
complementan con sus propios atributos. Al mismo tiempo, los objetos de una clase también
pueden relacionarse con otras clases, lo que rompe la jerarquía estricta y permite formar redes.
Los objetos simples también pueden combinarse para crear objetos más complejos.
Para gestionar los diversos objetos, el SGBD orientado a objetos correspondiente asigna
automáticamente un código de identificación único a cada registro, que permite recuperar los
objetos una vez que se han guardado.
▪ Base de datos orientadas a objetos:
Una base de datos orientada a objetos es un sistema de gestión de base de datos mediante
el cual representamos la información en forma de objetos que son utilizados en
programación orientada a objetos.

Algunas bases de datos orientadas a objetos han sido diseñadas para trabajar bien con
lenguajes de programación orientados a objetos tales como Delphi, Ruby, Python, Perl, Java,
Visual Basic.NET, etc.

La base de datos orientada a objetos ha encontrado su nicho de aplicación en áreas tales

como la ingeniería, las bases de datos espaciales, las telecomunicaciones y en áreas
científicas como la física de alta energía y la biología molecular.
Otro conjunto de bases de datos orientadas a objetos se centra en el uso integrado en
dispositivos, paquetes de software y sistemas en tiempo real.
La estructura de una base de datos orientada a objetos se basa en encapsular los datos y el
código relacionado con cada objeto en una sola unidad. Las interacciones entre los objetos y
el resto del sistema se realizan mediante una interfaz que se define mediante un conjunto de
mensajes permitidos. Hay que tener en cuenta que los mensajes en redes informáticas hacen
referencia al intercambio de solicitudes entre los objetos.
▪ Base de datos relacionada a objetos relacionales:
Las bases de datos relacionales se basan en la relación entre la información y diferentes
factores. En la práctica, puedes verlo como una tabla, donde cada columna representa un
tipo de información asociada con una fila. Una base de datos orientada a objetos se
organiza en forma de diferentes objetos, que contienen archivos e información agrupados,
así como procedimientos para leerlos y ejecutarlos.
Las bases de datos relacionales se basan en la relación entre la información y diferentes
factores. En la práctica, puedes verlo como una tabla, donde cada columna representa un
tipo de información asociada con una fila. Cada una de estas filas y columnas se llama clave.
La primera columna suele representar una clave principal, que servirá como base para
identificar la fila. Cada clave principal debe ser única, evitando la mezcla de
información. Esto significa, por ejemplo, que dos clientes no pueden registrarse con el
mismo nombre, pero pueden registrarse en la misma ciudad.
Gran parte de la diferencia entre las bases de datos relacionales y orientadas a objetos es
técnica, no siempre visible para el usuario final. Sin embargo, desde una perspectiva
tecnológica y especialmente de gestión, es importante reconocer cómo cada formato
maneja los datos y cómo encaja con tu contexto.
La estructura se compone de los siguientes elementos:

▪ Objetos: Son las entidades fundamentales en una BOO.

▪ Clases: Las clases son plantillas o prototipos que definen la estructura y el comportamiento de
un grupo de objetos relacionados.

▪ Métodos y procedimientos almacenados: Las BOO permiten la definición de métodos y

procedimientos almacenados asociados a las clases.

▪ Asociaciones: Las asociaciones representan conexiones entre objetos sin una dependencia
directa de herencia.

▪ Herencia: Las BOO permiten la herencia entre clases, lo que significa que una clase puede
heredar atributos y métodos de otra clase superior, también conocida como superclase o clase
padre.

▪ Relaciones entre objetos: Las BOO pueden establecer relaciones entre objetos, estas relaciones
pueden ser uno a uno, uno a muchos o muchos a muchos.
▪ SQL de objetos:
Un objeto es cualquier recurso de SQL Server , como un bloqueo de SQL Server o un proceso
de Windows. Cada objeto contiene uno o más contadores que determinan diversos aspectos
de los objetos que se van a supervisar. Por ejemplo, el objeto Bloqueos de SQL
Server contiene los contadores Número de interbloqueos/seg. y Tiempos de espera de
bloqueos/seg.
Algunos objetos tienen varias instancias si existen varios recursos de un determinado tipo en
el equipo. Por ejemplo, el tipo de objeto Procesador tendrá varias instancias si un sistema
contiene varios procesadores. El tipo de objeto Bases de datos tiene una instancia para cada
base de datos de SQL Server. Algunos tipos de objetos (por ejemplo, el objeto Administrador
de memoria ) tienen solo una instancia. Si un tipo de objeto tiene varias instancias, puede
agregar contadores para realizar un seguimiento de las estadísticas relativas a cada instancia
o, en muchos casos, de todas las instancias a la vez. Los contadores de la instancia
predeterminada aparecen con el formato SQLServer:nombre> de< objeto. Los contadores de
las instancias con nombre aparecen con el formato MSSQL$<instance name>:<counter
name> o SQLAgent$<instance name>:<counter name>.
SQL ANSI 2003:
El estándar SQL:2003 hace pequeñas modificaciones sobre la versión
anterior, SQL:1999 (también conocido como SQL3), y oficialmente introduce algunas
características nuevas como:
Las características relacionadas con XML
• Funciones de ventana
• Generador de la secuencia, lo que permite secuencias estandarizadas
• Dos nuevos tipos de columna: valores auto-generados (auto-generated values) y la
identidad de columnas (identity-columns)
• La nueva sentencia MERGE
• Ampliaciones de la sentencia CREATE TABLE, para permitir "CREATE TABLE AS" y
"CREATE TABLE LIKE"
• Eliminación de los tipos de datos "BIT" y "BIT VARYING"
▪ Referencia objetos:
Un objeto de la base de datos que tiene un puntero a otro elemento de la base de datos se
conoce como objeto de referencia, por nombre o por otros medios de identificación, este
puntero se puede utilizar para acceder al objeto al que se hace referencia, las relaciones entre
varios elementos de la base de datos se establecen con frecuencia utilizando objetos de
referencia.

Existen dos tipos principales de objetos referencia los cuales son:

▪ Claves foráneas: Las claves foráneas se utilizan para crear relaciones de uno a varios entre
tablas, una clave externa en una tabla hace referencia a la clave principal de otra tabla, y
esto le permite acceder a todas las filas de la tabla a la que se hace referencia para
cualquier fila determinada de la tabla de referencia.

▪ Referencias definidas por el usuario: las referencias definidas por el usuario se utilizan para
crear relaciones arbitrarias entre dos objetos de base de datos cualesquiera, las referencias
definidas por el usuario no se limitan a relaciones de uno a varios y se pueden usar para
crear relaciones entre tablas, vistas, procedimientos almacenados y otros objetos de bases
de datos.
▪ Llaves primarias:
Una clave principal o llave primaria es una columna especial o conjunto de columnas en una
tabla de base de datos que identifica de manera única cada registro en la tabla. La clave
puede ser una cadena corta o una combinación de múltiples columnas. Cuando se usa en una
consulta SQL, la clave principal puede ayudar a recuperar los datos que está buscando más
rápidamente.
Crear una clave primaria es un aspecto importante del diseño de la base de datos. Idealmente,
la clave principal será la única columna en una tabla, pero puede ser útil definir una clave en
más de una columna. Esto ayuda a evitar la duplicación de registros en una base de datos.
Una llave primaria debe:
• Contener un valor único para cada registro de la tabla de datos
• No puede contener un valor nulo. Esto es, debe contener siempre un valor.
▪ Campos múltiples:
Podemos agregar muchos tipos de campos que formarán parte de nuestra base de datos. Cada
campo admite distintos tipos de datos, con diferentes interfaces. Después de crear los campos
deseados podemos añadir información en la base de datos.
Un campo es el nombre de la unidad de información. Cada entrada en una base de
datos puede tener múltiples campos de diversos tipos. Por ejemplo, un campo de texto llamado
'color favorito', que permite escribirlo, o un menú llamado 'población' que permita escoger de
un listado de poblaciones posibles. La combinación de campos diversos nos permitirá recabar
toda la información que consideremos relevante sobre los ítems que constituyen la base de
datos.
▪ Arrays:
Las bases de datos arrays son sistemas de gestión aplicados a matrices. Proporcionan
la aplicación de colecciones homogéneas de datos, ubicados en matrices o
cuadrículas rectangulares de una, dos o más dimensiones.
Generalmente estas matrices se utilizan en los procesos de representación de datos
provenientes de sensores, simulaciones, imágenes y resultados estadísticos.
Las bases de datos arrays ofrecen un nivel de escalamiento muy alto. Esto combinado
con su gran flexibilidad en la recuperación y manipulación de los datos a pesar de
tratarse de archivos de gran tamaño.
La administración de estos modelos de gestión requiere técnicas novedosas.
Particularmente debido al hecho de que, en las bases de datos tradicionales, tienden
a encajar en una sola etapa o página. En cambio, estos datos, pueden abarcar
diversos medios o páginas. La tarea principal del administrador de almacenamiento
de la matriz es dinamizar el acceso y garantizar su rapidez a matrices secundarias.
▪ Tablas anidadas:
Una tabla anidada se representa en la tabla de casos como una columna especial que tiene un
tipo de datos TABLE. En las filas específicas de caso, esta clase de columna contiene filas
seleccionadas de la tabla secundaria que forman parte de la tabla primaria.
Los datos de una tabla anidada se pueden utilizar para la predicción, como entrada o para
ambos. Por ejemplo, podría tener dos columnas de tabla anidada en un modelo: una podría
contener una lista de los productos que un cliente ha comprado, mientras que la otra podría
contener información sobre las aficiones e intereses del cliente, posiblemente obtenidas en un
estudio. Podría utilizar las aficiones e intereses del cliente como entrada para analizar el
comportamiento de compra y predecir las compras probables.
Una expresión de tabla anidada es la especificación de una subconsulta en la cláusula FROM de
una sentencia SELECT de SQL. El proceso de las expresiones de tablas es similar al de una vista.
▪ Jerarquías:
Los datos jerárquicos se definen como un conjunto de elementos de datos que se
relacionan entre sí mediante relaciones jerárquicas. Las relaciones jerárquicas existen
allí donde un elemento de los datos es el elemento primario de otro elemento. Entre
los ejemplos de datos jerárquicos que se almacenan normalmente en las bases de
datos se incluyen los siguientes:
• Una estructura organizativa
• Un sistema de archivos
• Un conjunto de tareas de un proyecto
• Una taxonomía de términos de idioma
• Un gráfico de vínculos entre páginas web

Las tablas anidadas y las jerarquías se pueden usar juntas para almacenar datos aún
más complejos.
Están diseñadas para modelos de datos
específicos y tienen esquemas flexibles
para crear aplicaciones modernas, son
ampliamente conocidas porque son fáciles
de desarrollar, por su funcionalidad y el
rendimiento a escala.
▪ La base de datos relacional es una recopilación de la información empresarial organizada de tal forma que se
puede consultar, actualizar, analizar y sacar los datos fácilmente. La información se encuentra en tablas y
campos relacionados entre sí.

▪ La base de datos distribuida consiste en el almacenamiento de porciones de la base de datos en diferentes

ubicaciones físicas y, por tanto, el procesamiento está distribuido o replicado entre los distintos puntos de
una red de trabajo.

▪ La base de datos orientada a objetos, o Object-Oriented Database, representa los datos en forma de objetos
y clases. El objeto puede ser desde un resultado de búsqueda a una tabla; y una clase es una colección de
objetos.

▪ En cuanto a la base de datos gráfica, también conocida como orientada a grafos, se diferencian de las
anteriores en que están especializadas en establecer relaciones entre los datos de forma visual y navegar por
dichas relaciones.

▪ Base de datos NoSQL proviene de Not only SQL o, en español, no solo SQL. Esto se debe a que este tipo de
base de datos suele evitar el uso del SQL o lo usa de apoyo, pero no como consulta. El hecho de evitar el
SQL es porque se usa para proyectos en los que se necesita trabajar en la base de datos con un gran
volumen.
NoSQL, también conocido como "no solo SQL", "no SQL", es un enfoque de diseño de base
de datos que permite almacenar y consultar datos fuera de las estructuras tradicionales que se
encuentran en las bases de datos relacionales. Aunque puede almacenar los datos que se
encuentran dentro de los sistemas de gestión de bases de datos relacionales (RDBMS, por sus
siglas en inglés), los almacena de manera diferente a un RDBMS. La decisión de utilizar una
base de datos relacional frente a una base de datos no relacional es en gran medida
contextual y varía según el caso de uso.

En lugar de la típica estructura tabular de una base de datos relacional, las bases de datos
NoSQL alojan datos dentro de una estructura de datos, como un documento JSON. Dado que
este diseño de base de datos no relacional no requiere un esquema, ofrece una rápida
escalabilidad para gestionar grandes conjuntos de datos normalmente no estructurados.

NoSQL es también un tipo de base de datos distribuida, lo que significa que la información se
copia y almacena en varios servidores, que pueden ser remotos o locales. De esta manera, se
garantiza la disponibilidad y la fiabilidad de los datos. Si alguno de los datos queda fuera de
línea, el resto de la base de datos puede seguir ejecutándose.
Ventajas:
• Flexibilidad: Con las bases de datos SQL, los datos se almacenan en una estructura predefinida
mucho más rígida. Sin embargo, con NoSQL se pueden almacenar de forma más libre sin la rigidez
de esos esquemas. Este diseño impulsa la innovación y el rápido desarrollo de aplicaciones. Los
desarrolladores pueden centrarse en crear sistemas que ofrezcan un servicio mejor a sus clientes
sin preocuparse por los esquemas. Las bases de datos NoSQL pueden manejar fácilmente
cualquier formato de datos, como estructurados, semiestructurados y no estructurados en un único
almacén.
• Escalabilidad: En lugar de escalar verticalmente agregando más servidores, las bases de datos
NoSQL pueden escalarse horizontalmente utilizando hardware básico. De esta forma se puede
admitir un mayor volumen de tráfico para satisfacer la demanda sin tiempo de inactividad. Con el
escalado horizontal, las bases de datos NoSQL pueden ganar en tamaño y potencia, por lo que se
han convertido en la opción preferida para la evolución de los conjuntos de datos.
• Alto rendimiento: La arquitectura con escalabilidad horizotnal de las bases de datos NoSQL puede
resultar especialmente valiosa cuando aumenta el volumen de datos o el tráfico. Como se muestra
en el gráfico siguiente, esta arquitectura garantiza tiempos de respuesta rápidos y predecibles de
milisegundos de un solo dígito. Las bases de datos NoSQL también pueden ingerir datos y
entregarlos de forma rápida y fiable. Por esta razón, las bases de datos NoSQL se utilizan en
aplicaciones que recopilan terabytes de datos todos los días y que requieren una experiencia de
usuario altamente interactiva.
• Disponibilidad: Las bases de datos NoSQL replican datos de forma automática en múltiples servidores,
centros de datos o recursos en la nube. A su vez, esto minimiza la latencia de los usuarios,
independientemente de dónde se encuentren. Esta función también sirve para reducir la carga de la
gestión de bases de datos. De esta forma, se libera tiempo para dedicarlo a otras prioridades.
• Altamente funcional: Las bases de datos NoSQL están diseñadas para almacenes de datos distribuidos
que precisan una capacidad de almacenamiento de datos extremadamente grande. Esta característica
hace que NoSQL sea la opción ideal para big data, aplicaciones web en tiempo real, cliente 360,
compras en línea, juegos en línea, Internet de las cosas, redes sociales y aplicaciones de publicidad en
línea.
Características:
• SQL no es el lenguaje de consulta/modificación de datos principal, aunque sí lo soportan, de ahí el
nombre No Solo SQL.
• Los datos no tienen que almacenarse en tablas.

• Generalmente, su arquitectura es distribuida, almacenándose la información en más de una máquina

del sistema. Por lo tanto, los sistemas que las soportan tienen una mayor escalabilidad horizontal (a
mayor número de nodos mayor rendimiento) y también mayor tolerancia ante fallos en los distintos
nodos.
• Son más eficientes en el procesamiento de los datos que las BBDD relacionales, por eso, son la elección
para aplicaciones que hacen un uso intensivo de estos (“streaming”, etc.).
• Utilizan lo que se conoce como consistencia eventual, que consiste en que los cambios realizados en los
datos serán replicados a todos los nodos del sistema, lo cual aumenta el rendimiento de estos sistemas
en contraposición a las propiedades ACID de las BBDD relacionales.
Los Sistemas de Gestión de Bases de Datos NoSQL no contemplan por definición la
atomicidad de las instrucciones, es decir, cuando una operación sobre los datos
consta de varios pasos, no se tienen que ejecutar todos, cosa que sí sucede en los
modelos relacionales (transacciones completas). Hay algunas BBDD NoSQL que
contemplan la atomicidad.
Los gestores NoSQL no contemplan obligatoriamente la consistencia o integridad de
la BBDD, esto quiere decir que no se comprueba que la operación a ejecutar sobre
los datos se pueda completar desde un estado de la Base de Datos válido a otro
válido (por ejemplo, no violación de ninguna restricción de tipos de datos o reglas).
Al utilizar el mecanismo de consistencia eventual se puede dar el caso de que la
misma consulta a diferentes máquinas del sistema produzca resultados diferentes
porque las modificaciones de la BBDD aún no han sido replicadas a todos los nodos.
Algunas BBDD de este tipo contemplan la propiedad de consistencia.
• Estas BBDD utilizan sus propios lenguajes de consulta de datos y APIs, por lo
que no tienen una gran interoperabilidad (por ejemplo, dificultad de
migraciones de una BBDD a otra, integración con aplicaciones, consultas
heredadas en SQL, etc.).
• No hay estandarización para este tipo de BBDD, algo que sí es un punto fuerte
de las relacionales.
• Las Bases de Datos NoSQL funcionan ampliamente en máquinas Linux, pero
no existe en general soporte a otros Sistemas Operativos.
• Las interfaces de gestión de estas BBDD no son intuitivas ni sencillas y en
algunos casos carecen de ellas gestionándose directamente desde consola de
comandos.
Algunas razones por la cual utilizarla son:
▪ Cuando se necesita una BBDD para una aplicación que hace
una consulta/lectura intensiva de grandes cantidades de datos.
▪ Cuando no hay la necesidad de que los datos sean consistentes.
▪ Si los datos a almacenar no tienen una estructura fija.
▪ Una misma aplicación puede usar una BBDD relacional y una BBDD NoSQL y
guardar cosas diferentes en cada una de ellas.
Algunos ejemplos de uso de este tipo de BBDD:
• Amazon.
• Facebook.
• Google.
• Cassandra
• Redis
• MongoDB
• CouchDB
▪ Sistemas distribuidos de base de datos:
▪ https://ayudaleyprotecciondatos.es/bases-de-datos/distribuida/
▪ https://www.tokioschool.com/noticias/bases-datos-distribuidas/
▪ https://www.nutanix.com/es/info/distributed-storage
▪ https://cs.uns.edu.ar/~sd/data/apuntes/SD-2019-mod%2009.pdf
▪ http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro21/53_manejo_de_una_base_de
_datos_distribuida.html#:~:text=El%20manejo%20de%20transacciones%20tiene,t%C3%A
9rmino%20nuevo%2C%20%22agente%22
▪ http://basesdatosdistribuidas.blogspot.com/2012/08/investigacion-de-conceptos-
cuadro.html
▪ https://modelosbd2012t1.wordpress.com/2012/03/08/bases-de-datos-distribuidas/
▪ http://repositorio.utn.edu.ec/bitstream/123456789/522/3/04%20ISC%20151%20CAPITUL
O%20I.pdf
▪ http://repositorio.utn.edu.ec/bitstream/123456789/522/4/04%20ISC%20151%20CAPITUL
O%20II.pdf
▪ Analisis multidimensional y datawarehouse:
▪ https://ayudaleyprotecciondatos.es/bases-de-datos/multidimensionales/
▪ https://datascientest.com/es/olap-saber-todo-sobre-esta-potente-organizacion-de-bases-
de-datos
▪ https://www.sinnexus.com/business_intelligence/olap_avanzado.aspx
▪ https://es1.surveillancepackages.com/difference-between-rolap-and-molap-2a60
▪ https://learn.microsoft.com/es-es/power-bi/guidance/star-schema
▪ https://geekflare.com/es/star-vs-snowflake-schema/
▪ https://troyanx.com/Hefesto/estrella.html
▪ https://etl-tools.info/es/bi/almacendedatos_esquema-copo-de-nieve.htm
▪ https://troyanx.com/Hefesto/copo-de-nieve.html
▪ https://www.powerdata.es/data-
warehouse#:~:text=Un%20Data%20Warehouse%20es%20un,recuperar%20y%20f%C3%A
1cil%20de%20administrar.
▪ https://aws.amazon.com/es/what-is/data-
mart/#:~:text=Un%20data%20mart%20es%20un,sistema%20de%20almacenamiento%20
m%C3%A1s%20grande.
▪ https://powerbi.microsoft.com/es-es/what-is-data-modeling/
▪ https://www.iebschool.com/blog/data-mining-mineria-datos-big-data/
▪ Base de datos orientadas a objetos:
▪ https://ayudaleyprotecciondatos.es/bases-de-datos/orientas-a-objetos/
▪ https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/base-de-datos-orientada-a-
objetos/
▪ https://rockcontent.com/es/blog/bases-de-datos-relacionales-orientadas-a-objetos/
▪ https://learn.microsoft.com/es-es/sql/relational-databases/performance-monitor/use-sql-
server-objects?view=sql-server-ver16
▪ https://es.wikipedia.org/wiki/SQL:2003
▪ https://codigosql.top/bases-de-datos/llave-primaria/
▪ https://www.gnomi.club/llave-primaria/
▪ https://docs.moodle.org/all/es/19/Campos_de_la_base_de_datos
▪ https://learn.microsoft.com/es-es/analysis-services/data-mining/nested-tables-analysis-
services-data-mining?view=asallproducts-allversions
▪ Base de datos NoSQL:
▪ https://aws.amazon.com/es/nosql/
▪ https://www.ticportal.es/glosario-tic/base-datos-
database#:~:text=Adem%C3%A1s%2C%20es%20importante%20saber%20que,que%20se
%20requiere%20de%20ellas.
▪ https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf
▪ https://www.ibm.com/es-es/topics/nosql-databases
▪ https://www.oracle.com/pe/database/nosql/what-is-nosql/
▪ https://mexico.unir.net/ingenieria/noticias/bases-de-datos-nosql/