Fundamentos de Analisis de Datos

Unidad 1 / Escenario 1
Lectura fundamental
Bases de datos
Contenido
1 Conceptos de las bases de datos
2 Modelos de datos
3 Arquitecturas de las bases de datos
4 Bases de datos NoSQL
Palabras clave: base de datos, sistemas de gestión de archivos, sistema de gestión de bases de datos (SGBD),
sistema de base de datos, metadatos, modelo de datos.
1. Conceptos de las bases de datos
En los negocios y en la vida cotidiana, las bases de datos están presentes desde antes de la apropiación
de las tecnologías de la información en la sociedad. Guardar los teléfonos y direcciones de clientes
en una libreta, registrar las transacciones de una empresa o mantener un registro de inventarios,
son actividades que en el pasado se han llevado a cabo con la ayuda de libretas, fichas o algún otro
mecanismo de registro. En general, los mencionados son ejemplos de bases de datos, aun cuando no
estén soportados sobre plataformas computacionales. En general, una base de datos puede utilizarse
manualmente o aprovechando herramientas informáticas.
1.1. Bases de datos
De acuerdo con Date (2001), una base de datos es “un conjunto de datos persistentes que es
utilizado por los sistemas de aplicación de alguna empresa dada” (Date, 2001, p.10). Es importante
aclarar que la palabra empresa se refiere a cualquier sujeto que haga uso de la base de datos como
tal. Para complementar la anterior definición, según Elmasri y Navathe (2007), una base de datos
“es una colección de datos relacionados. Con la palabra datos nos referimos a los hechos (datos)
conocidos que se pueden grabar y que tienen significado implícito” (Elmasri y Navathe, 2007, p.4).
Es de resaltar que, para aclarar estas definiciones, es necesario mencionar las siguientes propiedades
de las bases de datos (Elmasri y Navathe, 2007):
1. Representa algún aspecto del mundo real (UoD, universo del discurso).
2. Es una colección de datos con algún tipo de significado coherente.
3. Se diseña, construye y registra datos para un propósito específico.
Según lo anterior, una base de datos no es una serie de datos aleatorios. Estos provienen de un origen
dado y tiene una aplicación dada. Como se verá a continuación, el uso de sistemas informáticos
permite un mejor registro, acceso y modificación de los datos, para su mejor aprovechamiento.
POLITÉCNICO
POLITÉCNICO GRANCOLOMBIANO
GRANCOLOMBIANO 2
1.2. Sistemas de gestión de archivos
Aún en nuestros días, es común encontrar oficinas que almacenan y procesan sus datos haciendo uso
de archivos tradicionales. Así, por ejemplo, muchas empresas llevan el registro de sus operaciones
en hojas de cálculo o archivos de texto. Sin embargo, este tratamiento de la información representa
algunos inconvenientes, los cuales se señalan a continuación:
• Redundancia de datos: al registrar información en archivos, estos a veces incluyen campos

que se repiten en distintos registros, lo que implica que al momento de modificar un dato
este se debe cambiar en todos los registros donde esté presente o genera inconsistencias e
información contradictoria.
• Difícil acceso a datos: en especial, cuando se manejan volúmenes crecientes de

información, buscar datos con determinados criterios puede llevar a que no sea
encontrados parcial o totalmente.
• Falta de relaciones entre datos: es común que, de acuerdo con su utilidad, los datos sean
almacenados en archivos diferentes. Esto conlleva a que sea difícil establecer relaciones entre
los datos como tal, que permitan aprovechar los recursos de información.
• Pérdida de integridad referencial: de la misma manera, tener diversos archivos que manejen
información distinta pero relacionada, implica la aparición de problemas de consistencia entre
los datos.
• Falta de atomicidad: cuando existan problemas en el almacenamiento de los datos es necesario

regresar a un estado en el cual el sistema sea consistente; tener la información en archivos no
permite mantener esa consistencia.
• Dificultades para acceso concurrente: si varios usuarios acceden simultáneamente a varios

archivos es difícil mantener la consistencia e integridad en los datos.
• Dificultades en seguridad: el acceso a ciertos recursos de información o a operaciones entre

datos requiere de ciertos privilegios para determinados perfiles de usuario. Los archivos, al
no contar con la estructura necesaria para una adecuada gestión de la información, también
dificultan la restricción adecuada al acceso de los datos.
POLITÉCNICO
GRANCOLOMBIANO 3
Por otra parte, cuando las bases de datos están soportadas sobre sistemas computacionales, las
aplicaciones adecuadas para administrar las bases de datos se denominan sistemas de gestión de bases
de datos (SGBD).
1.3. Sistemas de gestión de bases de datos (SGBD)
Un sistema de gestión de bases de Datos (o en inglés Database Management System – DBMS), es:
“Una colección de programas que permite a los usuarios crear y mantener una base de datos. Es
un sistema de software de propósito general que facilita los procesos de definición, construcción,
manipulación y compartición de las bases de datos entre varios usuario y aplicaciones” (Elmasri y
Navathe, 2007, p.5).
En otras palabras, son aquellos programas informáticos orientados, de manera específica, a definir,
construir y manipular datos por parte de uno o varios usuarios de manera simultánea y efectiva. En
el mercado encontramos algunos ejemplos de sistemas de gestión de bases de datos como: Oracle
Database, Microsoft SQL Server, MySQL, PostgreSQL, DB2 e incluso Access orientado a uso
personal y de pequeños negocios, el cual viene incluido en la suite de Office de Microsoft.
Es importante indicar que los SGBD, para poder efectuar sus tareas, definen a su vez información
acerca de los datos y de la estructura en que estos son almacenados. Dicho de otro modo, son datos
acerca de los datos que están almacenados; a los que se denominarán metadatos.
1.4. Sistemas de bases de datos
De acuerdo con Elmasri y Navathe (2007), se entiende como sistema de bases de datos a la
integración entre una base de datos (es decir, los datos e información como tal) y un sistema de
gestión de bases de datos. En estos sistemas, por lo general, se generan consultas para recuperar la
información almacenada y transacciones en las cuales se almacena o modifica información. La Figura
1 muestra la relación entre los conceptos mencionados.
POLITÉCNICO
GRANCOLOMBIANO 4
Figura 1. Entorno de un sistema de bases de datos
Fuente: elaboración propia
2. Modelos de datos
Un modelo de datos es una “colección de conceptos que se pueden utilizar para describir la estructura
de una base de datos” (Elmasri y Navathe, 2007, p.28). Estas incluyen las operaciones necesarias para
recuperar y actualizar los datos. Asimismo, por estructura de una base de datos entenderemos “los tipos de
datos, relaciones y restricciones que deben mantenerse para los datos” (Elmasri y Navathe, 2007, p.28).
2.1. Categorías de los modelos de datos
En general, se reconocen tres categorías de modelos de datos:
1. Modelos de alto nivel o modelos conceptuales, que representan más la forma en que los usuarios
se relacionan con los datos.
2. Modelos de datos representativos o modelos de implementación, que no se distancian

demasiado de la percepción de los datos por parte del usuario y a la vez no están tan lejos de la
manera en que los datos son almacenados.
POLITÉCNICO
GRANCOLOMBIANO 5
3. Modelos de bajo nivel o modelos físicos, que son más parecidos a la manera en que se
almacenan los datos en el sistema.
2.1.1. Modelos conceptuales
En este tipo de modelo se emplean los conceptos de entidad, atributo y relación. Se entiende por
entidad un objeto de la realidad; por atributos, a aquellas propiedades o características de la entidad
y que la definen; y por relación entenderemos la asociación que se da entre dos o más entidades.
Así, por ejemplo, una entidad puede ser el “cliente” o el “producto” de una compañía; los atributos
de la entidad “cliente” pueden ser “edad”, “estado”, “teléfono” o “dirección” y una relación puede
estar dada por los productos que ha adquirido un cliente. Un modelo representativo de los modelos
conceptuales es el de entidad-relación (Figura 2), que se desarrollará más adelante.
Figura 2. Ejemplo de modelo entidad-relación

2.1.2. Modelos de datos representativos o de implementación
Estos, también denominados modelos lógicos, están más enfocados en las operaciones, que en la
descripción de la realidad. Entre estos modelos tenemos el modelo de datos jerárquico, el modelo de
datos de red, el modelo de datos relacional y el modelo de datos de objetos, los cuales se describen de
manera breve a continuación:
• Modelo de datos jerárquico
POLITÉCNICO
GRANCOLOMBIANO 6
Organiza los registros en una estructura de árbol y emplea segmentos padre e hijo. Cada segmento es
equivalente a un registro de archivo (Figura 3). Entre las ventajas del modelo jerárquico tenemos
que promueve compartir datos, la simplicidad conceptual, la integridad y la eficiencia en las
relaciones 1:M (uno a muchos). Por otro lado, hace de la navegación algo complejo, no está
estandarizado, no posee un lenguaje de manipulación de datos y no permite tener múltiples padres
ni relaciones M:N (muchos a muchos).
Figura 3. Ejemplo de modelo de datos jerárquico

• Modelo de datos de red
A diferencia del modelo anterior, el de datos en red permite la presencia de múltiples padres, pues
posibilita los enlaces que establecen relaciones entre los registros (Figura 4). En este caso, las
relaciones son binarias y es posible tener múltiples relaciones que parten de un mismo registro.
Entre las ventajas de este modelo encontramos que promueve la integridad de las bases de datos
y se ajusta a los estándares y lenguajes de definición y manipulación de los sistemas de gestión de
bases de datos.
POLITÉCNICO
GRANCOLOMBIANO 7
Figura 4. Ejemplo de modelo de datos de red
• Modelo de datos relacional
El modelo de datos relacional fue propuesto por Edgar Frank “Ted” Codd (Codd, 1990), en los años
70. Utilizó el concepto de relación matemática (tabla), basándose en la teoría de conjuntos y la lógica
de predicados. Hoy es uno de los principales paradigmas en el diseño de bases de datos (Figura 5).
El principal concepto del modelo relacional es el uso de relaciones denominadas tuplas, que en la
práctica se encuentran en tablas compuestas por registros o tuplas organizadas en filas (una fila será
entonces una tupla o registro); cada columna correspondería a un campo (Todd, 1976). Entre las
ventajas de este modelo está su facilidad en el diseño, implementación, utilización y administración;
así como su capacidad de acomodarse a lenguajes como SQL y su poder de mantener la integridad
referencial. Por otro lado, requiere de una sólida capacitación a los usuarios.
POLITÉCNICO
GRANCOLOMBIANO 8
Figura 5. Ejemplo de modelo relacional
• Modelo de datos orientado a objetos
Debido al desarrollo de los lenguajes orientados a objetos, como C#, Java C++, entre otros,
en ocasiones existían ciertas dificultades de adaptar las estructuras de datos de los sistemas de
administración de bases de datos a las clases y objetos utilizados en los lenguajes de programación.
Por esta razón, surgió el grupo de modelos de datos de objetos: ODMG (por sus siglas en inglés)
(Object Data Management Group, 2017).
Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes
de programación orientados a objetos, como Java, C#, Visual Basic.NET y C++. Los ODBMS usan
exactamente el mismo modelo que estos lenguajes de programación. De la misma forma, modelos
como los mencionados en los apartados anteriores tienen deficiencias en cumplir los requerimientos
de los sistemas de información geográfica, sistemas de diseño y manufactura asistidos por
computador o multimedia (Figura 6).
POLITÉCNICO
GRANCOLOMBIANO 9
Contar con un modelo orientado a objetos mejora el rendimiento y la consistencia de los datos
cuando se integran con lenguajes de programación.
Figura 6. Ejemplo de modelo de datos de objetos

Fuente: elaboración propia.
• Modelo de lenguaje de marcado extendido (XML eXended Markup Languaje)
Es un modelo ampliamente utilizado para el intercambio electrónico de datos en Internet. Utiliza una
estructura a manera de árbol jerárquico con el apoyo de etiquetas (Figura 7).
POLITÉCNICO
GRANCOLOMBIANO 10
<libros>
<libro ISBN= “213123123”>
<titulo>Los días y noches</titulo>
<autor>Luis Díaz</autor>
</libro>
<libro ISBN= “2133424323”>
<titulo>La caza del enemigo</titulo>
<autor>Pepe Suárez</autor>
</libro>
<libro ISBN= “2131234545”>
<titulo>El ultimo amigo</titulo>
<autor>Javier Sánchez</autor>
</libro>
<libro ISBN= “2145345429”>
<titulo>Cuando los cóndores anidan</ti-
tulo>
<autor>Miguel de la Vega</autor>
Figura 7. Ejemplo de modelo de lenguaje de marcado extendido

3. Arquitecturas de las bases de datos

En este documento se presenta lo que se denomina una arquitectura de tres niveles: nivel interno,
conceptual y externo (Figura 8) (Elmasri y Navathe, 2007, p.31). Esta arquitectura también es
denominada ANSI/SPARC (Tsangaris y Klug, 1978).
3.1. Nivel interno
En este se describe de forma detallada cómo están almacenados físicamente los datos. Incluye
aspectos relacionados con el lugar de almacenamiento de datos, las rutas de acceso, los archivos, los
caracteres separadores, etc.
POLITÉCNICO
GRANCOLOMBIANO 11
3.2. Nivel conceptual
Este se centra de manera principal en describir las entidades, atributos, relaciones, operaciones, tipos
de datos y restricciones de la base de datos, sin tener en cuenta los aspectos físicos de esta.
3.3. Nivel externo
Se enfoca en cómo los usuarios tienen acceso a la información suministrada por la base de datos.
Figura 8. Arquitectura de tres niveles

POLITÉCNICO
GRANCOLOMBIANO 12
4. Bases de datos NoSQL
EL término NoSQL proviene de “Not Only SQL”. Corresponde a una nueva generación de sistemas
de gestión de bases de datos, que busca superar las limitaciones de las bases de datos relacionales. En
general, estas últimas están orientadas a administrar datos estructurados, con un formato fijo y unos
campos muy bien definidos. Sin embargo, en el entorno actual de Internet y de grandes volúmenes
de datos, se requiere mayor flexibilidad en el manejo de los datos. Así, NoSQL maneja tanto los datos
estructurados como los no estructurados. NoSQL está enfocado a proporcionar:
• Escalabilidad
• Rendimiento
• Alta disponibilidad
• API “Interfaz de Programación de Aplicaciones” (Aplication Programming Interface) simple
• Esquema libre
• Fácil replicación.
• Finalmente consistente (no ácido)
POLITÉCNICO
GRANCOLOMBIANO 13
Referencias
Codd, E. F. (1990). The Relational Model for Database Management. USA: Addison - Wesley
Publishing Company.
Date, C. (2001). Introducción a los sistemas de bases de datos. Naucalpan de Juárez, México:
Pearson Education.
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson,

Addison Wesley.
Object Data Management Group. (2017). ODMG Standard. Recuperado de http://www.odbms.org/

odmg-standard/
Todd, S. J. P. (1976). The Peterlee Relational Test Vehicle #x2014;a system overview. IBM Systems
Journal, 15(4), 285–308. https://doi.org/10.1147/sj.154.0285
Tsangaris, M. y Klug, A. (1978). The ANSI/X3/SPARC DBMS Framework. AFIPS Press.
POLITÉCNICO
GRANCOLOMBIANO 14
INFORMACIÓN TÉCNICA
Módulo: Fundamentos de bases de datos
Unidad 1: Generalidades y conceptos de bases de datos
Escenario 1: Generalidades de las bases de datos
Autor: Luis Ernesto Leyva Camargo
Asesor Pedagógico: María del Pilar Rivera Acosta
Diseñador Gráfico: David Alfonso Rivera
Asistente: Jhon Edwar Vargas
Este material pertenece al Politécnico Grancolombiano.

Prohibida su reproducción total o parcial.
POLITÉCNICO
GRANCOLOMBIANO 15
Lectura fundamental
Diseño de bases de datos
Contenido
1 Diseño conceptual de bases de datos
2 Diseño lógico de la base de datos
3 Modelo físico de una base de datos
Palabras clave: modelo entidad-relación o modelo ER, modelo relacional, entidad, conjunto de entidades, atributo o
propiedad, relación o vínculo, clave primaria, grado de una relación.
Introducción
Así como para construir un edificio es necesario tener claro cuál va a ser su utilidad, para la
elaboración de un diseño y establecer cómo se puede realizar la construcción -en térmicos técnicos-
de una base de datos, es importante tener claras las necesidades del cliente, establecer un diseño
adecuado y determinar cuál es la mejor manera de implementarla.
De forma análoga, cuando se desea establecer una base de datos, es necesario tener claro cuál es la
necesidad por la que el cliente desea desarrollarla. Determinar los requerimientos del cliente de forma
adecuada es fundamental para que los diseñadores de bases de datos y los desarrolladores construyan
una solución que se ajuste a estas necesidades de la mejor manera. Para el desarrollo de una base
de datos, frecuentemente se tienen en cuenta las siguientes fases: definición del sistema, diseño,
implementación, carga y conversión de datos, conversión de aplicaciones, prueba y validación, puesta
en marcha, monitorización y mantenimiento (Figura 1).
Figura 1. Ciclo de vida de un sistema de base de datos

POLITÉCNICO
GRANCOLOMBIANO 2
En general podemos establecer tres niveles de abstracción en el diseño de una base de datos, así:
• El diseño conceptual
• El diseño lógico
• El diseño físico
En los siguientes apartados se explicará la forma en que se realizan estos diseños.}
1. Diseño conceptual de bases de datos

Con base en la especificación de los requerimientos, se lleva a cabo el diseño conceptual de la base
de datos. Este consiste en una representación de alto nivel de la manera en que se estructurarán
los datos, desde la perspectiva del usuario, más como una representación de la realidad, que desde
el enfoque del almacenamiento. La forma más común de realizar un diseño conceptual es a través
de un diagrama entidad-relación (ER) o de un diagrama entidad-relación extendido (ER+). Estos
diagramas están compuestos principalmente por entidades, atributos y relaciones.
1.1. Diseño conceptual soportado sobre diagramas entidad-relación (ER)
Un modelo entidad-relación representa los datos en entidades, atributos y relaciones. A continuación,

veremos las características de estos elementos y cómo se representan en el diagrama ER.
1.1.1. Entidades
Se denomina entidad a “una cosa del mundo real con una existencia independiente” (Elmasri y
Navathe, 2007, p.55). Puede representar productos, clientes, empleados, etc. En el diagrama ER se
representa normalmente por un rectángulo de línea sencilla (Figura 2).
POLITÉCNICO
GRANCOLOMBIANO 3
E
Figura 2. Símbolo de entidad regular en el diagrama ER

Cuando la entidad no tiene atributos clave propios (Elmasri y Navathe, 2007, p.67), es decir, no
tiene clave primaria y su existencia depende de la presencia de una identidad regular, tenemos lo que
se denomina una entidad débil. En lugar de clave primaria, la entidad débil tendrá una clave parcial a
la que se le denomina también discriminador. Así, la clave parcial estará compuesta en realidad por la
clave primaria de la entidad fuerte y el discriminador. En el diagrama ER se representa normalmente
por un rectángulo de línea doble (Figura 3).
Figura 3. Símbolo de entidad regular en el diagrama ER

1.1.2. Conjunto de entidades
Un conjunto de entidades corresponde a “un contenedor lógico para las instancias de un tipo de
entidad y las instancias de cualquier tipo que se deriven de ese tipo de entidad” (Microsoft, 2017).
Como se verá más adelante, la instancia de una entidad corresponderá a una fila de una tabla, la cual
equivaldrá al conjunto de entidades como tal. Cada instancia tendrá los atributos del conjunto de
entidades y una clave única dentro de este, y no estará presente en otro conjunto de entidades. En el
modelo conceptual no se definen las instancias de las entidades, por lo cual no se requiere representar
el conjunto de entidades dentro de este.
POLITÉCNICO
GRANCOLOMBIANO 4
1.1.3. Atributos
Un atributo, también denominado propiedad, es la “información que deseamos registrar sobre las
entidades” (Date, 2001, p.13). Por ejemplo, el conjunto de entidades estudiante poseería los atributos
número de identificación, apellidos, nombres y grado, lo que se representa así:
estudiante = (id_alumno, apellidos, nombres, grado)
En el diagrama ER, el atributo o propiedad se representa normalmente por una elipse (Figura 4).
Figura 4. Símbolo de atributo en el diagrama ER

Los atributos o propiedades se pueden clasificar de la siguiente manera:
• Simple: son aquellos que no se pueden dividir; por ejemplo, número cédula.
• Compuesto: está constituido por varios atributos; por ejemplo, dirección_empleado puede estar
conformado por número_calle, número_carrera, número_apto, bloque, etc.
• Univalorado: el atributo solo puede tener un valor.
• Multivalorado: el atributo puede tener varios valores.
• Nulo: la entidad no tiene valor.
• Derivado: depende de los valores de otros atributos.
1.1.4. Claves
Asimismo, si el atributo corresponde a un identificador del registro, es decir, dos elementos del mismo
conjunto de entidades no pueden compartir el valor de ese atributo y, como veremos más adelante,
dos filas de una tabla no pueden tener este valor repetido -pues identifica el registro como tal-,
estamos haciendo referencia a un atributo que corresponde a una clave primaria. En el diagrama ER
se representa por una elipse en la que el atributo está subrayado por una línea continua (Figura 5).
POLITÉCNICO
GRANCOLOMBIANO 5
A
Figura 5. Símbolo de atributo con clave primaria en el diagrama ER

Si el atributo corresponde al discriminador de una entidad débil, en el diagrama ER se representará

por una elipse en la que el atributo está subrayado por una línea discontinua (Figura 6).
_A_
Figura 6. Símbolo de atributo con discriminador en el diagrama ER

1.1.5. Relaciones
Además de las entidades que incluyen atributos, tenemos las relaciones. Una relación o vínculo
corresponde a la interacción que tienen dos o más entidades. El grado de una relación se determina
por la cantidad de tipos de entidades participantes. Si, por ejemplo, están involucrados dos tipos de
entidad, se denominará binaria; y si están involucrados tres tipos de entidad, ternaria. En el diagrama
ER estas relaciones se representarán por un rombo y línea que las conectan con las entidades
(Figuras 7 y 8).
E1 R E2
Figura 7. Representación de relación binaria en el diagrama ER

POLITÉCNICO
GRANCOLOMBIANO 6
E1 R E2
E3
Figura 8. Representación de relación ternaria en el diagrama ER

Si la entidad es débil, se entenderá que es una relación de identificación y su símbolo será un rombo
con doble línea (Figura 9).
Figura 9. Símbolo de relación de identificación en el diagrama ER

1.1.6. Razón de cardinalidad
La razón de cardinalidad de una relación binaria “especifica el número máximo de instancias de

relación en las que una entidad puede participar” (Elmasri y Navathe, 2007, p.65). A continuación, se
describen algunos ejemplos:
La razón de cardinalidad 1:N en la relación binaria TRABAJA_EN, DEPARTAMENTO:EMPLEADO,

señala que un departamento puede tener uno o muchos empleados, mientras que un empleado puede
trabajar en uno y solo un departamento.
La razón de cardinalidad 1:1 en la relación binaria ESTA_CASADO_CON, ESPOSO:ESPOSA,

señala que un esposo está casado con una y solo una esposa, y a su vez esta está casada con un y solo
un esposo.
POLITÉCNICO
GRANCOLOMBIANO 7
La razón de cardinalidad N:M en la relación binaria COMPRA, CLIENTE:PRODUCTO, señala que
un cliente puede comprar uno o muchos productos, y a su vez un producto puede ser comprado por
uno o muchos clientes.
Existen ciertas restricciones que pueden darse en la razón de cardinalidad. Por un lado, tenemos la
dependencia de existencia o participación total, que consiste en que para que tengamos instancias
de una entidad es necesario que exista una instancia de otra; es decir, cada entidad de un conjunto
de entidades participa al menos en una relación del conjunto de relaciones. Por ejemplo, para tener
una instancia de empleado debe existir una instancia de departamento en el que trabaje (no podemos
tener un empleado que no pertenezca a un departamento). Por otro parte, tenemos las restricciones
de participación o participación parcial en la que solo algunas entidades del conjunto de entidades
participan en las relaciones del conjunto de relaciones. En este caso, por ejemplo, no todos los
empleados administran un departamento.
La cardinalidad en el diagrama ER se representa con la presencia de una flecha al final de la línea en la

relación con uno, o la ausencia de la flecha en la relación con varios (Figura 10).
Esposo Casado Esposa
Empleado Trabaja Departamento
Cliente Compra Producto
Figura 10. Relaciones de cardinalidad en el diagrama ER

POLITÉCNICO
GRANCOLOMBIANO 8
1.2. Verificación del diagrama entidad-relación
Para mantener la calidad de los diagramas, se deben incluir ciertas actividades de verificación, las
cuales se describen a continuación.
1.2.1. Completitud del diagrama
Una vez establecida la manera en la que el diagrama representa la realidad, se debe verificar que:
Todos los conceptos del problema estén representados.
El diagrama alcance todos los requerimientos.

En general, que el diagrama satisfaga los requerimientos del sistema.
1.2.2. Corrección del diagrama
Luego, se debe verificar la corrección sintáctica (forma) y semántica (significado). Al verificar la

corrección sintáctica se debe comprobar, en términos de lenguaje, lo siguiente:
Que las cardinalidades de cada relación estén bien orientadas.
Los atributos que determinan cada entidad y cuáles son entidades débiles.
La existencia de una y solo una relación.
Las entidades que intervienen en la relación dentro de cada agregación.
En síntesis, la corrección sintáctica implica que se respete el lenguaje. En ese sentido es aconsejable
utilizar herramientas CASE.
En cuanto a la corrección semántica, esta se asume cuando todos los elementos del problema utilizan
las estructuras que les corresponde. Así, es importante verificar lo siguiente:
La validez de cada atributo, entidad y relación.
Las categorías de entidades.
Establecer si la relación es binaria o múltiple.

Los mecanismos con los que se establecen las entidades.
Las cardinalidades y totalidades.
POLITÉCNICO
GRANCOLOMBIANO 9
1.2.3. Minimalidad del esquema
Los elementos involucrados en el problema deben aparecer una y solo una vez en el diagrama, de tal
forma que se muestren todos los elementos del mundo real y que estos correspondan a los elementos
del esquema.
1.2.4. Expresividad del esquema
Se entiende que un modelo es expresivo cuando de manera natural expresa la realidad empleando
solo la semántica del modelo. Busca determinar cuánto comunica el modelo en términos semánticos.
1.2.5. Explicitud del esquema
El diagrama no utiliza más formalismos que los incluidos en el diagrama entidad-relación; en otras
palabras, los elementos gráficos del modelo son suficientes para modelar la realidad.
1.3. Mecanismos de abstracción
La abstracción es “el proceso mental que se aplica al seleccionar algunas características y propiedades
de un conjunto de objetos y excluir otras” (Carreño, s.f.). Permite tener una definición más ajustada
a las necesidades de los objetos involucrados en la base de datos. En general, tenemos los siguientes
mecanismos:
Clasificación / instanciación
Agregación / descomposición
Generalización / especialización.
POLITÉCNICO
GRANCOLOMBIANO 10
1.3.1. Abstracción por clasificación / instanciación
Una clase en general define un objeto de la realidad, pero no es el objeto de la realidad como tal, sino
solo es la definición del mismo. Un objeto se materializa cuando se crea una instancia. Lo común a
todas las instancias es que posean atributos y métodos comunes a los definidos en la clase. Así, por
ejemplo, la clase vehículo se podría instanciar en un auto rojo e instanciar otro auto azul. Tanto el auto
rojo como el azul, son clasificados como vehículos y son instancias de la clase correspondiente.
1.3.2. Agregación / descomposición
Cuando un conjunto de clases constituye una clase que las comprende, hablamos de agregación. Es
decir, por la agregación de clase constituimos una nueva que las comprende. De modo contrario,
cuando de una clase desprendemos clases que la componen hablamos de descomposición. Si
agregamos las partes chasis, carrocería, silla, llanta (en la cantidad de instancias que sea necesario)
obtenemos un automóvil. A su vez, si descomponemos un automóvil, lo podemos hacer en las partes
que corresponden a clases como tal (Figura 11).
Automóvil
Llanta Chasís Silla Carrocería
Figura 11. Ejemplo de agregación / descomposición

1.3.3. Generalización / especialización
Al aplicar la teoría de conjuntos, vemos como algunas clases son parte de un subconjunto de otra.
Así, entendemos como especialización “el proceso de definir un conjunto de subclases de un tipo de
entidad” (Elmasri y Navathe, 2007, p.91).
POLITÉCNICO
GRANCOLOMBIANO 11
Por otro lado, entenderemos como generalización “el proceso inverso de abstracción en el que
eliminamos las diferencias entre distintas entidades, identifiquemos las características comunes y las
generalizamos en una única superclase” (Elmasri y Navathe, 2007, p.93). La Figura 12 muestra un
ejemplo de generalización / especialización.
Vehículo
Aeronave
Avión de combate Jumbo Helicóptero
Figura 12. Ejemplo de generalización / especialización

2. Diseño lógico de la base de datos

Una vez realizado el diseño del esquema conceptual, se procede al diseño lógico de la base de datos;
en otras palabras, se procede del modelo entidad-relación al modelo relacional. En el presente, con
los sistemas de gestión de bases de datos existentes, el modelo relacional desarrollado por Ted Codd
es el que más se utiliza para el diseño lógico de bases de datos. En este, la estructura fundamental es
la relación (tabla) que representa los objetos y sus asociaciones. Los atributos (campos) corresponden
a las relaciones y están definidos sobre dominios.
2.1. Diagrama relacional (MER)
Los elementos que componen el diagrama relacional son similares a los utilizados en el modelo
entidad-relación; sin embargo, su representación varía, pues busca ajustarse al sistema de gestión de
bases de datos que vamos a emplear.
POLITÉCNICO
GRANCOLOMBIANO 12
2.2. Componentes del diagrama relacional
2.2.1. Relaciones y tuplas
De acuerdo con Date, “dado un conjunto de n tipos o dominios Ti(i=1,2,…,n), que no son
necesariamente todos distintos, r es una relación sobre esos tipos si consta de dos partes: un
encabezado y un cuerpo” (Date, 2001, p.123). Esto corresponde a (aunque no es lo mismo que) una
tabla bidimensional, en la que las filas son los registros y las columnas los campos que corresponden a
los atributos (Tabla 1).
Tabla 1 Ejemplo de tabla para representar una relación
Id_estudiante Nombres Apellidos Grado

2123 Pedro Elías Pérez Sánchez 4
1323 Juan Manuel Mantilla Chacón 3
2132 Javier Eduardo Narváez López 3
La primera fila o cabecera muestra los nombres de los atributos representados en campos. Las
demás filas o cuerpo reciben el nombre de tupla y almacenan instancias (registros) que pertenecen al
conjunto de entidades representadas por la relación (tabla). El grado de la tabla o grado de una relación
corresponde a la cantidad de campos que posee; por ejemplo, cuatro en la relación de la Tabla 1.
La cardinalidad de una relación corresponderá el número de tuplas que contiene. Nótese que la
cardinalidad varía debido a que continuamente se insertan o eliminan registros. Una relación se
representa a través de una tabla, pero son conceptos diferentes. Por ejemplo, una tabla puede tener
filas repetidas, mientras una relación no puede tener tuplas iguales; por consiguiente, una tabla que
represente una relación no podrá tener filas repetidas.
POLITÉCNICO
GRANCOLOMBIANO 13
2.2.2. Dominios
Por dominio entendemos los valores que puede tomar un atributo. Por lo general, en el marco de un
sistema de gestión de bases de datos, el dominio corresponderá a los valores aportados por un tipo de
dato, que es un “conjunto específico de valores de los datos y un conjunto de operaciones que actúan
sobre los datos” (Aguilar, 2008).
Es probable que estos tipos de datos estén definidos por el sistema y por el sistema de gestión de
bases de datos, Así INTEGER, CHAR, VARCHAR, o DATE (Date, 2001) corresponderán a datos
numéricos enteros, caracteres, cadenas de caracteres o fechas correspondientemente. De esta
manera, por ejemplo, si definimos una columna (campo / atributo) denominada fecha_nacimiento
de tipo DATE, su contenido corresponderá a una fecha con las restricciones de sintaxis y de dominio
implicadas. Suponiendo que el formato requerido sea dd-mm-aaaa, colocar a dd un valor inferior a 1 o
superior a 31 (en ocasiones 30 o 28) generaría un error. El siguiente ejemplo de esquema de relación
muestra la manera en que se pueden incluir los dominios:
estudiante = (id_alumno:entero, apellidos:cadena, nombres:cadena, nacimiento:fecha)
Por otro lado, también es posible definir un dominio señalando el conjunto de valores que puede
tomar un dato.
2.2.3. Atributos
En el modelo relacional, un atributo corresponde a una columna o campo de una relación. Cada
atributo tendrá por lo tanto un dominio. Si D es el dominio y A el atributo, D es dominio de A y se
denotará:
D=Dom(A)
Dentro de este marco de referencia, un atributo podrá tomar los valores de un domino. Un atributo
estará asociado siempre con una relación y representa una propiedad de la misma, mientras que el
dominio no depende de las relaciones como tal. Así, varios atributos pueden tener el mismo dominio.
POLITÉCNICO
GRANCOLOMBIANO 14
2.2.4. Llaves
Para identificar las tuplas o para hacer referencia a ellas, existen las llaves. Podemos clasificar las llaves
en llaves primarias, llaves secundarias y llaves foráneas.
Llave primaria: es el atributo o conjunto de atributos no nulos que identifican una tupla en una relación.
Llave secundaria: es un atributo que no fue seleccionada como llave primaria, pero sus características
son únicas en una relación y corresponden solo a una tupla.
Llave foránea: es un atributo de la relación que corresponde a la llave primaria de otra relación de la
cual es referenciada una tupla.
2.3. Integridad referencial
Cuando una llave foránea de una relación haga referencia a la llave primaria de otra relación, es
necesario que la llave primaria corresponda a una tupla válida en su correspondiente relación. Por esa
razón, se aplican los descriptores PK (primary key) y FK (foreign key) para que la llave foránea no
admita valores nulos.
Lo anterior es importante, debido a que entre las operaciones que podemos ejecutar en una relación
r podemos eliminar una tupla que contenga una llave primaria que corresponda a una llave foránea de
otra relación s. Esto conllevaría a que la llave foránea de s apunte a una tupla inexistente en la relación
r, lo que haría inconsistente el modelo. Por lo tanto, para mantener la integridad referencial podemos
tomar alguna de las siguientes acciones:
Rechazar la modificación.
Eliminar las tuplas de la tabla de referencia s y luego eliminar la tupla correpondiente en r.
Asignar un valor nulo a las tuplas de la tabla de referencia s y luego eliminar la tupla
correspondiente en r.
Asignar un valor por defecto a las tuplas de la tabla de referencia s y luego eliminar la tupla
correspondiente en r.
Adicionalmente, es importante tener en cuenta que eliminar una tupla de una relación puede afectar
la integridad referencial de los registros de varias tablas de forma simultánea o en cascada.
POLITÉCNICO
GRANCOLOMBIANO 15
2.4. Operaciones relacionales
Existen varios tipos de operaciones relacionales. Conoceremos alguno a continuación.
2.4.1. Operaciones referenciales de modificación o actualización
Se reconocen tres operaciones básicas. A saber:
• Inserción (insert): permite insertar una tupla en una relación.
• Borrado (delete): elimina una o varias tuplas de una relación.
• Modificación (update): cambia los valores de atributos de tuplas existentes en la relación.
2.4.2. Operaciones referenciales uniarias
Son aquellas que se aplican para consultar una relación. Se reconocen las siguientes operaciones
uniarias:
• Selección (select): permite seleccionar un conjunto de tuplas de una relación que satisfaga unas
condiciones dadas. Su notación es σ_(<condicion de selección>) (R).
• Proyección (project): permite seleccionar un conjunto de columnas o campos de una relación.

Su notación es π_(<lista de atributos>) (R).
• Renombrado (rename): permite cambiar la denominación de los atributos.
2.4.3. Operaciones de algebra relacional de la teoría de conjuntos
Como operaciones de algebra relacional de la teoría de conjuntos, tenemos las siguientes:
• Unión (union): dadas las relaciones R y S, crea una nueva relación que incluye todas las tuplas
que están incluidas en las relaciones preexistentes R o en S. Su notación es RuS.
• Intersección (intersection): dadas las relaciones R y S, crea una nueva relación que incluye solo
las tuplas que están en las relaciones preexistentes R y en S. Su notación es R∩S.
POLITÉCNICO
GRANCOLOMBIANO 16
• Diferencia (minus): dadas las relaciones R y S, crea una nueva relación que incluye solo las
tuplas que están R, pero que no estén en S. Su notación es R - S.
• Producto cartesiano (cartesian product) o concatenación cruzada (cross join): produce nuevas
tuplas concatenando todas las posibles combinaciones entre n relaciones. Su notación es R X S.
2.4.4. Operaciones relacionales binarias
En este conjunto de operaciones tenemos:
Concatenación (join): combina tuplas de dos relaciones en una sola. Su notación es R⋈<condicion de conexión>(S).
División (division): define una relación sobre el conjunto de atributos C, incluido en la relación R, y
que contiene el conjunto de valores de S, que en las filas de R están combinadas con cada una de las
filas de S. Su notación es R(Z)÷S(Y).
Ejemplo de construcción de modelo lógico relacional

En un hospital, se han identificado tres tablas: médicos, salas y pacientes. Un médico se identificará
por la cédula, tendrá nombres, apellidos, dirección, teléfono y una sala que le ha sido asignada. Un
paciente se identificará por la cédula, tendrá nombres y apellidos, y será asignado a una sala para su
intervención. Las salas tendrán un código identificador, un nombre y un número de camas. Una sala
puede ser asignada a varios médicos, pero a cada médico se le asigna solo una sala. Una sala puede
tener varios pacientes, pero una paciente puede estar solo en una sala.
Así el esquema relacional de la base de datos de control de salas quedará así:
SALAS(cod_sala:entero, nombre_sala:cadena, num_camas:entero)
MEDICOS(cedula_medico:entero, Salas_cod_sala:entero, nombres_medico:cadena,
apellidos_medico:cadena, dirección_medico:cadena, telefono_medico:entero)
LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS
PACIENTES(cedula_paciente:entero, Salas_cod_sala:entero ,nombres_
paciente:cadena, apellidos_paciente:cadena,)
LLAVE FORANEA: Salas_cod_sala REFERENCIA cod_sala EN SALAS
POLITÉCNICO
GRANCOLOMBIANO 17
Así, obtenemos el modelo lógico relacional de un control de salas en un hospital:
Figura 13. Modelo lógico relacional de un control de salas en un hospital
3. Modelo físico de una base de datos

Con base en el diseño lógico, podemos modelar un diseño físico, lo que corresponde a describir
cómo se comporta la base de datos en memoria secundaria. En general, el diseño físico busca:
reducir los tiempos de respuesta, el espacio de almacenamiento y el consumo de recursos, mejorar la
organización y la seguridad.
3.1. Fases del diseño físico de una base de datos
El diseño físico de una base de datos consta de cuatro fases, las cuales se describen a continuación.
3.1.1. Traducir el esquema lógico para el sistema de gestión de bases de datos
Se debe conocer la funcionalidad que ofrece el sistema de gestión de bases de datos; soporte de
llaves primarias, foráneas y alternativas; soporte a la definición de datos, dominios y reglas de negocio;
y cómo se crean las relaciones base.
POLITÉCNICO
GRANCOLOMBIANO 18
3.1.2. Diseñar las relaciones base para el sistema de gestión de bases de datos
La definición de las relaciones base se hacen a través del lenguaje de definición de datos (LDD) que
corresponde a cada sistema de gestión de bases de datos. Se utiliza información obtenida del diseño
lógico, como:
• Diccionario de datos: lista estructurada de los datos que pertenecen al sistema (Tabla 2).
• Esquema relacional: este incluye relaciones, atributos, llaves primarias y foráneas, y reglas de integridad.
Tabla 2. Ejemplo de diccionario de datos
Tabla Llave Nombre Campo Tipo Tamaño Descripción
Código del Almacena el código del

Empleados PK empleado cod_empleado Numérico 4 empleado.
Nombre del Almacena el nombre del

Empleados empleado nom_empleado Texto 50 empleado.
Código de Almacena el código de la

ciudades_cod_
Empleados FK ciudad del ciudad Numérico 4 ciudad del empleado.
empleado
3.1.3. Diseñar las reglas de negocio para el sistema de gestión de bases de datos
Se deben tener en cuenta las restricciones impuestas por las reglas de negocio de la empresa. Por
ejemplo, en el caso del hospital señalado en un apartado anterior, es posible restringir que el número
de camas por salas sea inferior o igual a cinco, y que una sala no puede tener asignados más del
número de camas de la sala. Teniendo esto en cuenta, las restricciones quedarían así:
CONSTRAINT num_camas_chk CHECK (num_camas <=5)
CONSTRAINT pacientes_por_sala CHECK (NOT EXIST (SELECT
Salas_cod_sala FROM Pacientes GROUP BY Salas_cod_sala HAVING
COUNT(*)<num_camas))
POLITÉCNICO
GRANCOLOMBIANO 19
3.1.4. Diseñar el nivel físico
En este caso debe tenerse en cuenta:
• La productividad en las transacciones: teniendo en cuenta la cantidad de transacciones

proyectadas sobre unidad de tiempo.
• El tiempo de respuesta: cuánto tarda el sistema en dar respuesta al usuario.
• Espacio en disco: cuánto espacio se requiere para almacenar los datos soportados por el sistema.
• Memoria principal: corresponde al tamaño de la RAM para obtener un buen desempeño del sistema.
• Procesador o procesadores: en la medida que se usen procesadores más rápidos y se empleen

varios procesadores en paralelo el desempeño será mayor.
• Almacenamiento en disco: es diferente al empleado para el sistema operativo, utilización de

“logs”, uso de arreglos de discos, etc.
• Conexiones de red: ancho de banda y uso de múltiples canales.
3.2. Diseño de mecanismos de seguridad
Cada día, la seguridad se convierte en un factor crítico dentro de los negocios y organizaciones. Cada
sistema de gestión de bases de datos aporta mecanismos de seguridad. Además, se recomienda:
• Diseñar las vistas de los usuarios
• Diseñar reglas de acceso.
POLITÉCNICO
GRANCOLOMBIANO 20
Referencias
Aguilar, L. J. (2008). Fundamentos de Programación. Madrid: Mc Graw Hill.
Carreño, J. (s.f.). Fundamentos de Bases de Datos. Bogotá: Politécnico Grancolombiano.
Date, C. (2001). Introducción a los sistemas de bases de datos. Naucalpan de Juárez, México:
Pearson Education.
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson,

Addison Wesley.
Microsoft. (2017). Microsoft Developer Network: Conjunto de Entidades. Disponible en

https://msdn.microsoft.com/es-es/library/ee382830(v=vs.110).aspx
POLITÉCNICO
GRANCOLOMBIANO 21
Unidad 1: Generalidades y conceptos de bases de datos
Escenario 2: Conceptos de diseño de bases de datos
Diseñador Gráfico: David Alfonso Rivera
Asistente: Jhon Edwar Vargas

POLITÉCNICO
GRANCOLOMBIANO 22
Módulo Teórico-Práctico
Actividad en contexto
Módulo
Fundamentos de bases de datos
Nombre de la entrega
Diseño de bases de datos 1
Nivel académico
Especialización
Tipo de entrega
Actividad aplicada
Nota
Tenga en cuenta que el tutor le indicará qué herramienta requiere y qué
estrategia deberá desarrollar para evidenciar su participación individual
en un trabajo colaborativo.
DESCRIPCIÓN
DE LA ACTIVIDAD
Aplicar las fases del diseño de bases de datos en la resolución del siguiente caso aplicando los
conceptos del diseño conceptual, diseño lógico y diseño físico.
CASO O PROBLEMA
Usted es contratado para construir una base de datos para la administración de un taller
mecánico.
La base de datos incluirá información acerca de los clientes, los autos, los empleados que
trabajan en el taller y los repuestos utilizados para cada servicio.
22
La base de datos debe:
• Registrar el cliente y auto de cada servicio.

• Del cliente se registra la cédula, nombres y apellidos, teléfono y dirección.
• Del auto se registra la placa, el modelo, el color, fecha y hora de ingreso.
• A cada servicio se asigna un empleado disponible.
• El empleado a cargo del servicio registrará los repuestos con su referencia, descripción,
marca y precio al igual que las horas empleadas en el servicio.
• Con base en el precio de los repuestos, el número de horas empleadas y la utilidad

estimada se crea una factura que además incluye un IVA del 19%.
PLANTEAMIENTO
DE LA ACTIVIDAD
Diseñe el diagrama Entidad-Relación, el esquema y el modelo relacional, el diccionario

de datos, restricciones, y diseño físico del caso anterior. Se recomienda el uso de alguna
Herramienta Gráfica como Microsoft Visio.
33
Lectura fundamental
Normalización
Contenido
1 Introducción
2 Dependencias
3 Normalización
Palabras clave: normalización, dependencia funcional, forma normal.

1. Introducción
Para una adecuada gestión de la información en una base de datos, es importante que esta se
encuentre adecuadamente estructurada. Esto con el fin de evitar la repetición de datos y mantener
la integridad referencial. Por esa razón, en este escenario se trabajará una técnica denominada
“normalización”, que consiste en un proceso en el que, aplicando un conjunto de reglas, se evitan
las redundancias, se reducen los inconvenientes al momento de actualizar los datos y se protege la
integridad de los mismos. Así, por ejemplo, estudiemos la relación: ESCRIBE
ESCRIBE(id autor, autor, nacionalidad, ISBN, titulo, editorial, anio)
Podemos evidenciar que hay problemas en aspectos como:
Redundancia: si un autor escribe más de un libro, la nacionalidad del autor se repetirá en todas las
ocasiones.
Anomalías de actualización: si se modifica el nombre de la editorial en una tupla, sería necesario

hacerlo en todas en las que esté presente.
Anomalías de inserción: si deseamos insertar un libro de un autor que no tengamos no sería posible
pues el id del autor hace parte de la llave primaria.
Anomalía de borrado: si borramos un libro se borran a, la su vez, los datos del autor.
Atributo atómico: se entiende que un atributo es atómico si este no puede dividirse en otros
atributos.
Una manera de solucionar los problemas planteados sería, a partir de la relación ESCRIBE, definir las
siguientes relaciones:
LIBRO(ISBN, Titulo, Editorial, Anio)
AUTOR(IdAutor, Nombre, Nacionalidad)
ESCRIBE(IdAutor,ISBN)
A continuación, se describirán una serie de conceptos y técnicas para normalizar una base de datos.
POLITÉCNICO GRANCOLOMBIANO 2
2. Dependencias
Una dependencia es una característica propia del contenido semántico de los datos. Consiste en una
serie de restricciones de usuario en el modelo relacional, que afectan a los atributos en una relación que
se cumplen para cualquier extensión de un esquema de relación. Se representa de la siguiente forma:
R(A,DEP)
Donde R es la relación, A es el conjunto de atributos de la relación y DEP son las dependencias que
existen entre atributos. Entre las dependencias existentes encontramos las siguientes:
• Dependencias de combinación
• Dependencias jerárquicas
• Dependencias multivaluadas
• Dependencias funcionales
Para el desarrollo del curso, nos concentraremos en las dependencias funcionales, las cuales se
describen a continuación.
2.1. Dependencias funcionales
El concepto de dependencia funcional se puede considerar uno de los más relevantes en la teoría
del diseño del esquema relacional. Una dependencia funcional (DF) es un “vínculo muchos a uno
que va de un conjunto de atributos a otros dentro de una determinada tabla” (Date, 2001, p.330).
También podemos decir que una dependencia funcional es “una restricción que se establece entre dos
conjuntos de atributos de la base de datos” (Elmasri & Navathe, 2007, p.291). Una definición formal
de dependencia funcional, de acuerdo con Elmasri & Navathe, es la siguiente:
Una dependencia funcional, denotada X → Y, entre dos conjuntos de atributos X e Y que son
subconjuntos de R, especifica una restricción en las posibles tuplas que pueden formar un
estado en la relación r de R. La restricción dice que dos tuplas t1 y t2 en r que cumplen que
t1[X]=t2[X], deben cumplir también que t1[Y]=t2[Y] (2007, p.292).
Para entender mejor esta definición, decimos que los valores que toma Y en la tupla r están determinados
por los valores de X (Figura 1). Así podemos encontrar dependencias funcionales tales como:
»» ISBN → Titulo
»» IdUsuario → NombreUsuario
»» FechaDeNacimiento → {Edad ,FechaDeJubilacion}
»» {Cargo, NumeroDeHijos} → Subsidio
Figura 1. Dependencia Funcional X → Y, Y es funcionalmente dependiente de X

En el proceso de normalización se comprueba que en cada relación o tabla se cumplan las reglas
basadas en la clave primaria y las dependencias funcionales. De tal manera que una relación se
descompone en otras relaciones, hasta que cada una cumpla con dichas reglas.
2.1.1. Descriptores equivalentes
Cuando X → Y y Y → X, se dice que X e Y son descriptores equivalentes X ↔ Y. Por ejemplo, un

estudiante puede ser identificado por el atributo “Cedula” o por el atributo “Codigo” por tanto:
Cedula ↔ Codigo
2.1.1. Dependencias transitivas
Si se tiene una relación R(A, DF), donde X e Y son dos descriptores sobre A,
se tiene una relación de dependencia transitiva.
2.1.2. Reglas de inferencia para dependencias funcionales - axiomas de Armstrong
Existe un conjunto de reglas que permiten deducir todas las dependencias funcionales que se dan al
interior de un conjunto dado de atributos. Estas reglas se denominan los axiomas de Armstrong, los
cuales son:
• Axioma de reflexividad:
Teniendo un atributo o un conjunto de atributos, de este puede deducirse él mismo. Así, por
ejemplo, si el título de un libro está incluido en el ISBN, entonces, a partir del ISBN es posible
obtener el título del libro.
• Axioma de aumentatividad:
Esta regla indica que se adicionamos el mismo conjunto de atributos a ambos lados de la
dependencia, obtenemos también dependencias válidas. Así si tenemos la dependencia X → Y
sería válida la relación XZ → YZ.
• Axioma de transitividad:
Este axioma indica que se la dependencia funcional X → Y es válida y, a su vez, la dependencia

funcional Y → Z es también válida; entonces, la dependencia funcional X → Z será válida.
A partir de los anteriores axiomas se desprenden los axiomas derivados de Armstrong, los cuales son:
• Axioma de descomposición o proyectividad:
Esta regla establece que podemos eliminar atributos del lado derecho de una dependencia, es
decir, se puede descomponer la dependencia funcional X → {A1, A2…, An} en las dependencias
{X → A1, X → A2, …, X → An}
• Axioma de unión o aditividad:
Este axioma tiene el comportamiento opuesto al de descomposición o proyectividad. De tal

forma que podemos combinar un conjunto de dependencias funcionales {X → A1, X → A2, …,
X → An} en la dependencia X → {A1, A2…, An}
• Axioma de pseudotransitividad:
Este axioma indica que se la dependencia funcional X → Y es válida y, a su vez, la dependencia

funcional WY → Z también es válida; entonces, la dependencia funcional WX → Z será válida.
3. Normalización
Una vez comprendidos los conceptos relacionados con las dependencias funcionales y sus
propiedades, podemos definir las dependencias funcionales para cada relación, de tal forma que cada
una tenga una clave principal en lo que denominan formas normales.
La normalización se entiende como el proceso en el que se aplican reglas a las relaciones obtenidas
del modelo entidad-relación al modelo relacional, con el fin de evitar redundancias, reducir problemas
de actualización de datos y proteger la integridad de los mismos. Es importante mencionar que la
normalización es un proceso posterior al esquema conceptual y ofrece las siguientes ventajas:
• Evita anomalías de inserción, modificación y borrado.
• Optimiza la interdependencia de datos.
• No impone a la estructura de los datos restricciones artificiales.
El proceso de normalización consta de varios pasos que, a su vez, corresponden a formas normales.
En la medida que se ha llegado a una forma normal con un índice más alto, se puede decir que las
relaciones tienen una forma más fuerte y son menos vulnerables a los problemas planteados. Se
recomienda llegar por lo menos a la tercera forma normal.
3.1. Formas normales
Se dice que una tabla está en una forma normal determinada si cumple las condiciones establecidas
para esa forma normal. Se dice que si una forma normal es de grado superior, cumple las
características de las formas normales de nivel inferior, como se observa en la Figura 2.
Primera forma normal 1FN
Segunda forma normal 2FN

Tercera forma normal 3FN
Boyce Codd NF
Cuarta forma normal 4FN
Quinta forma normal 5FN
Forma normal de dominio/dave DKNF
Figura 2. Formas normales

Por lo general, basta con obtener la tercera forma normal para satisfacer las necesidades que
se presentan en entornos cotidianos. A continuación, se presentan las características de cada
forma normal.
3.1.1. Primera forma normal (1FN)
Se considera que una tabla está en primera forma normal, si y solo si en cada campo de un registro
se tiene un único valor, es decir, es atómico. Esta se puede expresar de manera tabular sin grupos
repetitivos. Se entiende que un atributo es atómico si este no se puede dividir en otros atributos.
Las condiciones con las que debe cumplir la primera forma normal son:
• Todos los atributos son atómicos.
• La tabla tiene una única clave primaria.
• El número de columnas no varía.
• La clave identifica a los campos que no son clave (dependencia funcional).
• El orden de los datos o el cambio de los mismos no debe afectar el significado de estos.
Para llegar a la primera forma normal se lleva a cabo el siguiente procedimiento:
1. Se eliminan los grupos repetidos de cada tabla.
2. Se crea una tabla independiente para cada conjunto de datos relacionados.
3. Cada conjunto de datos relacionados se identificará con una clave principal.
Por ejemplo, el siguiente caso ilustra la primera forma normal. Se desea hacer un sistema que
almacene la facturación de una tienda; la orden contiene la siguiente información:
ORDEN(no_orden, fecha_orden, no_cliente, nombre_cliente,

dirección_cliente, (no_producto, descripción_producto, precio_
unitario, cantidad, precio_producto)*, cuenta_orden)
La tabla no normalizada tendría la siguiente representación (Tabla 1).
Tabla 1. Tabla no normalizada
Orden
No_ No_ No_ Precio_

Fecha_orden Nom_cliente Dir_cliente Desc_producto Pre_unit Cantidad Precio_prod
orden cliente producto orden
1 11/4/2017 12 Pedro Díaz Cll 10 – 25 – 27 23 Martillo $10000 1 $10000 $73000
1 11/4/2017 12 Pedro Díaz Cll 10 – 25 – 27 34 Taladro $30000 2 $60000 $73000
1 11/4/2017 12 Pedro Díaz Cll 10 – 25 – 27 24 Destornillador $1000 3 $3000 $73000
2 10/4/2017 3 Juan Pérez Kr 11– 12 – 14 23 Martillo $10000 2 $20000 $45000
2 10/4/2017 3 Juan Pérez Kr 11– 12 – 14 54 Formol $1500 1 $1500 $45000
2 10/4/2017 3 Juan Pérez Kr 11– 12 – 14 65 Alicate $800 4 $24000 $45000
Como se puede observar, hay atributos con el mismo significado: como No_producto y Desc_
producto (Figura 3).
Figura 3. Dependencias funcionales de la tabla no normalizada

Como se puede observar en la tabla, lo anterior conlleva a anomalías de actualización, pues al insertar
un dato se requiere tanto el número del cliente como el nombre del cliente. Al eliminar una tupla en
la que esta sea la única en la que aparezca un cliente, se perderá la información de este; y cuando se
modifique una tupla, puede generar una incoherencia con otra tupla. Para solucionar esta situación,
dividimos esta tabla en dos, de la siguiente manera:

dirección_cliente, cuenta_orden)
ORDEN_PRODUCTO(no_orden, no_producto, descripción_producto,

precio_unitario, cantidad, precio_producto)
Por último, establecemos la clave primaria de la nueva entidad:

ORDEN_PRODUCTO(no_orden, no_producto, descripción_producto,

precio_unitario, cantidad, precio_producto)
Así llegamos a la primera forma normal (Tabla 2).
Tabla 2. Tablas en primera forma normal
Orden
No_orden Fecha_orden No_cliente Nom_cliente Dir_cliente Precio_orden
1 11/4/2017 12 Pedro Díaz Cll 10 – 25 – 27 $73000
2 10/4/2017 3 Juan Pérez Kr 11– 12 – 14 $45000
Orden_producto
No_orden No_producto Desc_producto Pre_unit Cantidad Precio_prod
1 23 Martillo $10000 1 $10000
1 34 Taladro $30000 2 $60000
1 24 Destornillador $1000 3 $3000
2 23 Martillo $10000 2 $20000
2 54 Formol $1500 1 $1500
2 65 Alicate $800 4 $24000
3.1.2. Segunda forma normal (2FN)
Se considera que una relación satisface la segunda forma normal (2FN) si, además de satisfacer
la primera forma normal, todos los atributos que no son clave dependen funcionalmente de forma
irreductible de la clave primaria (Tabla 3). Para llegar a la 2FN:
• Se eliminan los atributos que dependen de forma parcial de la clave primaria, para crear nuevas
relaciones.
• Se adicionan a la nueva relación los atributos del cual dependen.
Continuando con el ejemplo, tenemos lo siguiente:

ORDEN_PRODUCTO(no_orden, no_producto, cantidad, precio_producto)
PRODUCTO(no_producto, descripción_producto, precio_unitario)
Tabla 3. Tablas en segunda forma normal
Orden
No_orden Fecha_orden No_cliente Nom_cliente Dir_cliente Precio_orden
1 11/4/2017 12 Pedro Díaz Cll 10 – 25 – 27 $73000
2 10/4/2017 3 Juan Pérez Kr 11– 12 – 14 $45000
Orden_producto
No_orden No_producto Cantidad Precio_prod
1 23 1 $10000
1 34 2 $60000
1 24 3 $3000
2 23 2 $20000
2 54 1 $1500
2 65 4 $24000
Producto
No_producto Desc_producto Pre_unit
23 Martillo $10000
34 Taladro $30000
24 Destornillador $1000
54 Formol $1500
65 Alicate $800
3.1.3. Tercera forma normal (3FN)
Se considera que una relación satisface la tercera forma normal (3FN) si, además de satisfacer la
segunda Forma normal, todos los atributos que no corresponden a claves primarias dependen de
forma no transitiva de la clave primaria (Tabla 4). Para llegar a la 3FN:
1. Se eliminan los atributos que representan dependencias transitivas y se crean nuevas relaciones
con ellos.
2. Se añaden a la nueva relación los atributos que son determinantes que serán la clave primaria de
la nueva relación.
Continuando con el ejemplo, tenemos lo siguiente:
ORDEN(no_orden, fecha_orden, no_cliente, cuenta_orden)
CLIENTE(no_cliente, nombre_cliente, dirección_cliente)
ORDEN_PRODUCTO(no_orden, no_producto, cantidad, precio_producto)
PRODUCTO(no_producto, descripción_producto, precio_unitario)
Tabla 4. Tablas en tercera forma normal
Orden
No_orden Fecha_orden No_cliente Precio_orden
1 11/4/2017 12 $73000
2 10/4/2017 3 $45000
Cliente
No_cliente Nom_cliente Dir_cliente
12 Pedro Díaz Cll 10 – 25 – 27
3 Juan Pérez Kr 11– 12 – 14
Orden_producto
No_orden No_producto Cantidad Precio_prod
1 23 1 $10000
1 34 2 $60000
1 24 3 $3000
2 23 2 $20000
2 54 1 $1500
2 65 4 $24000
Producto
No_producto Desc_producto Pre_unit
23 Martillo $10000
34 Taladro $30000
24 Destornillador $1000
54 Formol $1500
65 Alicate $800
Por regla general, se llega a tercera forma normal; sin embargo, se mencionarán las otras formas normales.
3.1.4. Forma normal Boyce Codd (Boyce Codd NF)
Se considera que una relación está en forma normal Boyce Codd si toda dependencia funcional
no trivial e irreductible a la izquierda tiene como clave una candidata determinante. Es una forma
más precisa de 3FN, en la que se descomponen las relaciones de tal forma que la clave primaria sea
siempre determinante.
3.1.5. Cuarta forma normal (4FN)
Una relación está en cuarta forma normal (4NF) si y solo si cumple con la tercera forma normal
o en BCNF, y no posee dependencias multivaluadas no triviales. Una tabla con una dependencia
multivaluada es aquella en la que existen dos o más relaciones independientes muchos a muchos, que
causan redundancia, la cual se elimina por la cuarta forma normal. En la práctica, se ha comprobado
que no siempre es la más eficiente de las formas normales.
3.1.6. Quinta forma normal (5FN)
Una relación se dice que está en quinta forma normal 5NF si y solo si, además de estar en cuarta
forma normal, cada dependencia de unión en ella se implica por las claves candidatas.
3.1.7. Forma normal de dominio/clave DKNF
La forma normal de dominio/clave (DKNF) corresponde a una forma normal que exige que la base de
datos contenga restricciones de dominios y claves.
Referencias
Codd, E. (1990). The Relational Model for Database Management. USA: Addison - Wesley Publishing
Company.
Object Data Management Group. (2017). ODMG Standard. Recuperado de http://www.odbms.org/

odmg-standard/
Todd, E. (1976). The Peterlee Relational Test Vehicle. IBM Journal.
American Federation of Information Processing Societies. Press. (1979). The ANSI/X3/SPARC DBMS
framework: report of the Study Group on Database Management Systems. Computer Systems Research
Group.
Date, C. (2001). Introducción a los sistemas de bases de datos. Naucalpan de Juárez, México: Pearson
Education.
Elmasri, R. & Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson,
Addison Wesley.
Unidad 2: Normalización en las bases de datos
Escenario 3: Normalización

Diseñador Gráfico: Paola Andrea Melo
Asistente: Ana Milena Raga Amador

Lectura fundamental
Álgebra relacional y cálculo

relacional
Contenido
1 Introducción
2 Algebra relacional
3 Cálculo relacional
Palabras clave: álgebra relacional, cálculo relacional, restricción, proyección, producto, unión, intersección,
diferencia, concatenación, división.
1. Introducción
En este escenario se hará referencia a los lenguajes formales propios del modelo relacional: el álgebra
relacional y el cálculo relacional. El primero está centrado en el procedimiento o algoritmo, a través
del cual se desea llegar a un resultado; por esto, se considera que el álgebra relacional es de tipo
procedimental. El segundo modelo está centrado en el resultado, sin importar el mecanismo a través
del cual se obtiene; este se considera de tipo declarativo. Sin embargo, existe equivalencia entre los
lenguajes como tal. A continuación, se desarrollarán tanto el álgebra como el cálculo relacional.
2. Algebra relacional
El álgebra relacional es “el conjunto de operadores que toman relaciones como sus operandos y regresan
una relación como resultado” (Date, 2001, p.150). Esta tuvo su origen gracias a las investigaciones de
Edgar F. Codd, quien definió ocho operadores, los cuales trataremos a continuación.
2.1. Restricción o selección σ
Supongamos que en una empresa en la que 5000 clientes han realizado compras, se desea identificar
aquellos 300 que han llevado a cabo transacciones por mayor valor, para ofrecerles una membresía.
En ese caso se requieren solo los registros que cumplan con la condición dada. La operación más
acertada, desde el punto de vista del álgebra relacional, será la restricción o selección.
Se entiende por restricción o selección la operación que “regresa una relación que contiene todas las
tuplas de una relación especificada que satisfacen una condición especificada” (Date, 2001, p.150).
La Figura 1 muestra en qué consiste la operación de restricción o selección.
Figura 1. Operación de restricción o selección

Por regla general, la operación de selección es representada por el carácter sigma (σ). Para mayor
claridad, se presentará el siguiente ejemplo. Supongamos que tenemos el siguiente esquema relacional:
empleado (DNI: carácter, nombre: cadena, salario: flotante, fecha ingreso)
Dicha relación está representada a través de la Tabla 1.
Tabla 1. Relación empleado
DNI Nombre Salario Fecha_ingreso

2134323 Luis Pérez 2500000 2002-5-25
2312342 Javier Molina 1500000 2005-12-15
1231232 Alex Neira 4800000 2013-1-25
2312312 Jim Cotes 2900000 2017-1-1
4345543 Martha Castillo 7300000 2010-9-26
4564534 Fabio Buitrago 5200000 2011-1-31
Aplicando la siguiente operación:
Selección ← σsalario>3000000(empleado)
Obtenemos los resultados que se muestran en la Tabla 2.
Tabla 2. Relación resultado de la operación de selección σsalario>3000000(empleado)
DNI Nombre Salario Fecha_ingreso

1231232 Alex Neira 4800000 2013-1-25
4345543 Martha Castillo 7300000 2010-9-26
4564534 Fabio Buitrago 5200000 2011-1-31
2.2. Proyección π
Pensemos en una relación que representa contablemente a una compañía. En ocasiones, el número
de columnas podría ser inmanejable, porque se requiere solo obtener las columnas que aporten la
información más relevante para la toma de decisiones financieras. En este caso, la operación más
acertada, desde el punto de vista del álgebra relacional, será la proyección.
Se entiende por proyección la operación que “regresa una relación que contiene todas las tuplas o
subtuplas de una relación especificada después de quitar los atributos especificados” (Date, 2001,
p.150). La Figura 2 muestra en qué consiste la operación de proyección.
Figura 2. Operación de proyección

De la misma forma, la operación de selección es representada por el carácter pi (π). Continuando con
el ejemplo representado en la Tabla 1, se desea una tabla que no me muestre datos distintos al nombre
del empleado y la fecha de ingreso (Tabla 3). La operación a realizar sería entonces:
Proyección ← π <nombre,fecha_ingreso>(empleado)
Tabla 3. Relación resultado de la operación de proyección π <nombre,fecha_ingreso>(empleado)
Nombre Fecha_ingreso
Luis Pérez 2002-5-25
Javier Molina 2005-12-15
Alex Neira 2013-1-25
Jim Cotes 2017-1-1
Martha Castillo 2010-9-26
Fabio Buitrago 2011-1-31
Ahora, es posible combinar operaciones de tal forma que una operación se aplique al resultado de
otra. Por ejemplo, se desea conocer solo la fecha de ingreso de los empleados que ganen más de $3
000 000 (Tabla 4). En este caso, la operación se daría de la siguiente manera:
Selección ← σsalario>3000000(empleado)
Proyección ← π <nombre,fecha_ingreso>(selección)
Tabla 4. Relación resultado de la composición de las operaciones de selección y proyección
Nombre Fecha_ingreso
Alex Neira 2013-1-25
Martha Castillo 2010-9-26
Fabio Buitrago 2011-1-31
2.3. Producto x
También denominado producto cartesiano, producto cruzado o concatenación cruzada, el producto

x es una operación de álgebra relacional. En la operación de producto se obtiene la combinación de
relaciones para obtener una nueva relación. La operación de producto es representada por el carácter
equis (x). El producto está definido como la operación que “regresa una relación que contiene
todas las tuplas posibles que son una combinación de dos tuplas, una de cada una de dos relaciones
especificadas” (Date, 2001, p.151). La Figura 3 muestra en qué consiste la operación de producto.
Figura 3. Operación de producto

Para dar mayor claridad sobre el comportamiento de la operación producto, observemos el siguiente
ejemplo, en el cual se presenta el producto cartesiano entre las relaciones (zapato) x (chaqueta)
(Tablas 5-7).
Tabla 5. Relación zapato
ID_zapatos Zapatos
1 Mocasín
2 Tenis
3 Botas
Tabla 6. Relación chaqueta
ID_chaqueta Chaqueta
1 Cuero
2 Paño
Tabla 7. Relación resultante del producto (zapato) x (chaqueta)
ID_zapatos Zapatos ID_chaqueta Chaqueta

1 Mocasín 1 Cuero
1 Mocasín 2 Paño
2 Tenis 1 Cuero
2 Tenis 2 Paño
3 Botas 1 Cuero
3 Botas 2 Paño
Como se puede observar, para que las relaciones que participan en el producto cartesiano sean
compatibles es necesario que los campos de las relaciones tengan nombres distintos.
2.4. Unión ∪
La operación de unión, dadas las relaciones A y B, en realidad genera un conjunto que contiene
aquellas tuplas que pertenezcan a la relación A o a la relación B. Es importante aclarar que para poder
aplicar la operación de unión se requiere que las tuplas sean homogéneas.
Se define la operación de unión como aquella que contiene todas las tuplas que aparecen en una o en
las dos relaciones especificadas. La Figura 4 muestra en qué consiste la operación de unión.
Figura 4. Operación de unión

ejemplo, en el cual se presenta la unión entre relaciones (Tablas 8-10).
Tabla 8. Relación A
ID_zapatos Zapatos
1 Mocasín
3 Tenis
4 Botas
Tabla 9. Relación B
ID_zapatos Zapatos
2 Chanclas
4 Botas
Tabla 10. Relación resultante de la unión (A) ∪ (B)
ID_zapatos Zapatos
1 Mocasín
2 Chanclas
3 Tenis
4 Botas
2.5. Intersección ∩
Al contrario de la operación de unión, la operación de intersección establece que dadas las relaciones
A y B, se genera un conjunto que contiene aquellas tuplas que pertenezcan tanto a la relación A
como o a la relación B. Es importante mencionar que, al igual que en la operación de unión, en la
intersección se requiere que las tuplas sean homogéneas.
Se define la operación de intersección como aquella que “regresa una relación que contiene todas
las tuplas que aparecen en las dos relaciones especificadas (en ambas, no en una o en otra)” (Date,
2001, p.152). La Figura 5 muestra en qué consiste la operación de intersección.
Figura 5. Operación de intersección

ejemplo, en el cual se presenta la intersección entre relaciones (Tablas 11-13).
Tabla 11. Relación A
ID_zapatos Zapatos
1 Mocasín
3 Tenis
4 Botas
Tabla 12. Relación B
ID_zapatos Zapatos
2 Chanclas
4 Botas
Tabla 13. Relación resultante de la unión (A) ∩ (B)
ID_zapatos Zapatos
4 Botas
2.6. Diferencia -
De manera análoga a lo que ocurre con la unión y la intersección, la operación diferencia establece
que dadas las relaciones A y B, se genera un conjunto que contiene aquellas tuplas que pertenezcan
a la relación A, pero no a la relación B. Al igual que en las operaciones de unión e Intersección, en la
operación de diferencia se requiere que las tuplas sean homogéneas. Por otro lado, el orden en que se
ejecuta la operación de diferencia produce un resultado distinto.
Se define la operación de intersección como aquella que “regresa una relación que contiene todas las
tuplas que aparecen en la primera relación, pero no en la segunda de las dos relaciones especificadas”
(Date, 2001, p.152). La Figura 6 muestra en qué consiste la operación de diferencia.
Figura 6. Operación de diferencia
Continuando con el ejemplo señalado en los apartados de unión e Intersección, las Tablas 14 y 15
representan las relaciones (A)-(B) y (B)-(A):
Tabla 14. Relación (A)-(B)
ID_zapatos Zapatos
1 Mocasín
3 Tenis
Tabla 15. Relación (B)-(A)
ID_ZAPATOS ZAPATOS
2 Chanclas
2.7. Concatenación |x|
La operación de concatenación |x| aprovecha las operaciones de restricción y producto. Funciona

de tal manera que, dadas las relaciones A y B, primero establece la relación A x B y enseguida,
empleando un criterio de selección, elimina determinadas tuplas.
La concatenación está definida como la operación que “regresa una relación que contiene todas las
tuplas posibles que son combinación de 2 tuplas de cada una de 2 relaciones especificadas, tales que
las dos tuplas que contribuyen a cualquier combinación dada tengan un valor común para los atributos
comunes de las dos relaciones y ese valor común aparece una vez, y no dos, en la tupla resultante)”
(Date, 2001, p.152). La Figura 7 ilustra mejor el comportamiento de la concatenación.
Figura 7. Operación de concatenación

2.8. División /
Al igual que en la aritmética tradicional, la operación división es opuesta al producto. En esta

operación se definen 2 operadores que serán divididos por otro. La operación de división está definida
como aquella que “toma dos relaciones uniarias y una relación binaria y regresa una relación que
contiene todas las tuplas de una relación uniaria que aparecen en la relación binaria y que a la vez
coinciden con todas las tuplas de la otra relación uniaria” (Date, 2001, p.152). La Figura 8 muestra
mejor la operación de división.
Figura 8. Operación de división

El siguiente ejemplo (Tablas 16-18) ilustra la operación de división.
Tabla 16. Relación (viajes)
Viajero Destino Viajero Destino

Luis Díaz Panamá Beatriz Dávila México
Luis Díaz Brasil Beatriz Dávila Argentina
Luis Díaz México Julio Consuegra Chile
Pedro Suárez Panamá Julio Consuegra Panamá
Camila Cortés Panamá Pedro Suárez Brasil
Beatriz Dávila Panamá
Tabla 17. Relación (destinos)
Destino
Panamá
Brasil
Tabla 18. Relación (viajes / destinos)
Viajero
Luis Díaz
Pedro Suárez
Nótese que tanto Luis como Pedro son viajeros que tiene como destino a Panamá y a Brasil.
Las operaciones que acabamos de ver son las más representativas, pero se han definido otras
operaciones cuyos resultados pueden ser obtenidos a través de la combinación de las operaciones
presentadas y están fuera del alcance del curso.
3. Cálculo relacional
Como se presentaba al comienzo de este escenario, el cálculo relacional no se centra tanto en
el procedimiento sino en el resultado. Mientras en el álgebra relacional podríamos especificar
operaciones tales como seleccionar las tuplas que contienen salarios mayores a $3.000.000 o
proyectar los campos que correspondan al nombre del empleado y el salario; en el cálculo relacional
se declararía: obtener los empleados que ganen $3.000.000 o más. Es decir, el cálculo relacional es
descriptivo, en cambio el álgebra relacional es prescriptiva.
En general, podemos encontrar cálculo relacional orientado a tuplas y cálculo relacional orientado a
dominios. Veamos.
3.1. Cálculo relacional orientado a tuplas
La idea del cálculo orientado a tuplas es que se hallen las tuplas en las que se cumpla un predicado
específico. Este cálculo se basa en variables tupla que corresponden a tuplas que tienen un rango de
valores posibles en una relación. A continuación, se presentan algunas declaraciones que se ajustan al
cálculo relacional orientado a tuplas:
• Para cada producto de la bodega, obtener el SKU y el número de unidades en inventario.
• Obtener las ciudades cuya población sea de más de un millón de habitantes.
• Obtener los proveedores que ofrecen, entre sus productos, tornillos.
• Obtener los clientes cuya ciudad de residencia es Bogotá.
• Obtener los clientes con ingresos mayores o iguales a $3’.000.000.
Como se puede evidenciar, la redacción de las declaraciones está orientada a la relación entre variables
de las tuplas; a diferencia del cálculo relacional, orientado a dominios que hacen énfasis en los rangos.
3.2. Cálculo relacional orientado a dominios
El cálculo relacional orientado a dominios se centra en que las variables de alcance cubren dominios,
en lugar de relaciones. La principal relación es de pertenencia a un conjunto o subconjunto de datos.
En seguida, se presentan ejemplos de declaraciones que se ajustan al cálculo relacional orientado
a dominios.
• Obtener los productos cuyo SKU tenga el mismo número de unidades en bodega.
• Obtener las ciudades que correspondan a las que tengan más de un millón de habitantes.
• Obtener los proveedores que por lo menos, entre sus productos, tengan tornillos.
• Obtener los clientes que pertenecen a la ciudad de Bogotá.
• Obtener los clientes con ingresos de por lo menos a $3’.000.000.
Nótese que la redacción puede ser similar, pero en el caso del cálculo orientado a tuplas se hace
énfasis en la relación entre variables, mientras que en el cálculo orientado a dominios se hace hincapié
en la pertenencia a un conjunto.
3.3. Cuantificadores del cálculo relacional
En el cálculo relacional existen 2 cuantificadores: EXISTS, el cual es un cuantificador existencial que

representa –‘Existen tuplas’– en un rango de valores; y FORALL, que es el cuantificador universal
que representa –‘Para todas las tuplas’– en el rango de valores dentro de una relación.
El cuantificador EXISTS se asocia con el cuantificador “Existe algún”, que se denota con el símbolo ∃
de tal manera que para decir “existe algún x tal que x es mayor que y” se denotaría: ∃x/x > y.
De forma análoga, el cuantificador FORALL se asocia con el cuantificador “Para todo” que se denota
por el símbolo de tal manera que para declarar “para todo x tal que x sea mayor que y” se denotaría
x/x>y.
Desde una óptica del cálculo orientado a dominios, se podría aprovechar la relación de pertenencia
denotada por el símbolo . De tal forma que podríamos tener declaraciones tales como “Existe
algún x tal que x pertenece a la relación R” denotada ∃ x/x, o “Para todo x tal que x pertenezca a la
relación R” denotada como x/x.
Referencias
Education.
Aguilar, L. (2008). Fundamentos de Programación. Madrid: Mc Graw Hill.
Carreño, J. (s.f.). Fundamentos de Bases de Datos. Bogotá: Politécnico Grancolombiano.
Addison Wesley.
Microsoft. (2017). Microsoft Developer Network: Conjunto de Entidades. Recuperado de https://msdn.

microsoft.com/es-es/library/ee382830(v=vs.110).aspx
Unidad 2: Normalización en las bases de datos
Escenario 4: Álgebra y cálculo relacional

Diseñador Gráfico: Paola Andrea Melo

Unidad 13 / Escenario
Escenario 52
fundamental
Lectura Fundamental
Lenguaje
Etapas deSQL
un plan de comunicación
estratégica
Contenido
1 Generalidades del lenguaje de consulta estructurada SQL
2 Lenguajes SQL
3 Tipos de datos SQL
4 Sintaxis del lenguaje SQL
5 Instrucciones comunes en SQL
Palabras clave: SQL -Structured Query Languaje.

Introducción
En el presente escenario se aborda el lenguaje de consulta estructurada SQL (por sus siglas en inglés
Structured Query Languaje), con el que se espera concretar los conceptos vistos en los escenarios
anteriores, en aplicaciones específicas en sistemas de gestión de bases de datos (SGBD). Este
lenguaje es declarativo y no procedimental. Dicho de otra forma, las consultas están orientadas a
determinar lo que hay que hacer y no a la manera en que se alcanza el objetivo propuesto, como
ocurre en lenguajes de programación como C++ o Java. De esta forma, el SQL es un lenguaje
que busca ofrecer al usuario capacidades para la definición, manipulación y control de los datos.
En los siguientes apartados, se presentarán las principales características del lenguaje y sus
instrucciones particulares.
1. Generalidades del lenguaje de consulta estructurada SQL

El SQL es un lenguaje estándar ampliamente difundido, que es empleado por la mayoría de los
sistemas de gestión de bases de datos (SGBD), cuyo nombre oficial es “Estándar Internacional
de Lenguaje de Base de Datos SQL” (Date, 2001, p.83), con algunas muy leves variaciones entre
fabricantes. El SQL fue desarrollado originalmente por IBM Research durante la década de los 70,
con el nombre de SEQUEL (Structured English Query Language). Por esta razón, en el mercado,
la mayoría de los productos relacionados con SQL son pronunciados de la manera en que se leería
su predecesor.
En 1986, adquiere el nombre SQL-86 y es publicado por ANSI en 1987. El lenguaje ha tenido
revisiones posteriores en 1987, 1989, 1992, 1999, 2003 2005 y 2008, para introducir, a lo largo
de las distintas versiones y revisiones, características como consultas recursivas, disparadores,
características XML, entre otras funcionalidades.
SQL es un lenguaje basado en los conceptos de álgebra relacional y cálculo relacional descritos en
el escenario anterior. Incluye lenguaje de definición de datos (DDL), lenguaje de manipulación de
datos (DML) y lenguaje de control de Datos (DCL), los cuales se desarrollarán en este escenario. Si
bien, como se indicó anteriormente, SQL es un lenguaje declarativo, en la actualidad incluye algunas
capacidades procedimentales para lograr un mayor aprovechamiento del mismo. A continuación, se
presentan las instrucciones que componen el lenguaje.
2. Lenguajes SQL
Como de señalaba en el apartado anterior, existen tres grupos de instrucciones que componen el
lenguaje de consulta estructurado:
• Data definition languaje – DDL: corresponde al conjunto de instrucciones a través de las cuales
se puede implementar una base de datos previamente diseñada. Entre las instrucciones más
comunes del lenguaje encontramos: CREATE, ALTER, DROP y TRUNCATE.
• Data manipulation languaje – DML: establece el conjunto de instrucciones por medio de

las cuales se realizan actividades para insertar, consultar, modificar o eliminar datos. Las
instrucciones representativas de este lenguaje son: SELECT, INSERT, UPDATE, DELETE.
• Data control languaje – DCL: establece mecanismos de acceso o negación del mismo a la base
de datos; por lo general, son relevantes en lo que a seguridad se refiere.
En seguida, se desarrolla la sintaxis general de SQL y las principales instrucciones de los lenguajes
especificados.
3. Tipos de datos SQL

Cada SGBD contiene una definición propia de los tipos de datos. Así, si se desea almacenar un valor
monetario que contenga centavos, es necesario emplear un tipo que contenga decimales, tal como un
NUMERIC o un FLOAT. Si se desea almacenar el número de integrantes de un equipo se empleará
un INTEGER y si se desea almacenar un nombre se podría emplear un VARCHAR ().
A continuación, señalamos algunos tipos de dato de uso común. Vale la pena mencionar que, al
momento de utilizar un SGBD, es importante consultar la referencia ofrecida por el fabricante para
cada caso (Tabla 1).
Tabla 1. Tipos de datos SQL
Enteros
Tipo de datos Rango Tamaño bytes
-263 (-9.223.372.036.854.775.808) a
BIGINT 8
263-1 (9.223.372.036.854.775.807)
-231 (-2.147.483.648) a 231-1
INT, INTEGER 4
(2.147.483.647)
SMALLINT -215 (-32.768) a 215-1 (32.767) 2
TINYINT 0 a 255 1
Decimal o de punto flotante

Máximo 38 dígitos según parámetros –
DECIMAL(), NUMERIC() Varía
valores exactos
FLOAT(), DOUBLE() Varía según parámetros – valores aproximados Varía
REAL() Varía según parámetros – valores aproximados Varía
Tiempo
DATE Fechas desde 0001-01-01 3
DATETIME Fechas desde 0001-01-01 8
Desde 00:00:00.0000000 hasta
TIME Varía
23:59:59.9999999
Cadenas y caracteres
CHAR, CHARACTER 1 carácter 1

VARCHAR(), Cadena de caracteres –
Varía
CHARACTER VARYNG () Hasta 4000 caracteres
Booleanos
BOOLEAN, BIT true o false 1
4. Sintaxis del lenguaje SQL
En primer lugar, el SQL es un lenguaje que en la mayoría de los casos es “case-insensitive”; es decir,
es indiferente a si se escribe en mayúsculas o minúsculas. Sin embargo, en algunos casos, la forma en
que se escriben los nombres de las tablas, las columnas o los datos puede tener relevancia. Por esa
razón, no se recomienda el uso de la convención "CamelCase” (palabras separadas por mayúsculas
como por ejemplo ‘código, Ciudad’), pues es posible que sea difícil de interpretar el significado de
la variable por parte del programador. En ese caso, se recomienda el uso de palabras separadas por
delimitadores (por ejemplo, código ciudad).
Una instrucción será ejecutada así: desde donde aparece el primer carácter hasta donde aparezca el
carácter punto y coma(;), de la forma en que se presenta en el siguiente ejemplo:
SELECT * FROM grupos;

Si bien, la mayoría de los sistemas de gestión de bases de datos no son sensibles a las mayúsculas, se
emplea con frecuencia una convención en la que se escriben en mayúsculas las palabras reservadas
del sistema, como SELECT, FROM, ORDER BY, etc.; y en minúsculas, aquellas expresiones propias
de denominaciones de tablas, atributos o datos. En el caso del ejemplo anterior, es una línea en la que
se seleccionan todos los campos (al emplearse el carácter *) de la tabla grupos.
También es posible encontrar instrucciones que toman más de una línea y, por lo tanto, requieren
de un tratamiento distinto para mantener la legibilidad, como el caso del ejemplo que se presenta a
continuación:
CREATE TABLE empresa
(
nit_empresa INT PRIMARY KEY,
nombre_empresa VARCHAR(30),
direccion_empresa VARCHAR(50),
telefono_empresa VARCHAR(16)
);
Al observar el código escrito, se entenderá que el SGBD lo asumirá como una única instrucción
separada en varias líneas, pues tiene un único punto y coma (;). De hecho, si se escribiera en una
única línea generaría exactamente el mismo resultado:
CREATE TABLE empresa(nit_empresa INT PRIMARY KEY,nombre_

empresa VARCHAR(30),direccion_empresa VARCHAR(50),telefono_
empresa VARCHAR(16));
No obstante, es posible que se pierda legibilidad, en especial cuando las instrucciones son cada vez
más complejas. También nótese que tenemos presente que empresa es la entidad y se desarrolla
con los atributos indicados entre paréntesis, que a su vez están separados por coma (,); y que entre
el último atributo y el último paréntesis no hay coma. La sentencia que se acaba de presentar corre
adecuadamente en MySQL; sin embargo, si la corriéramos en PostgreSQL quedaría así:
CREATE TABLE empresa

(
nit_empresa INTEGER PRIMARY KEY,
nombre_empresa CHARACTER VARYNG(30),
direccion_empresa CHARACTER VARYNG (50),
telefono_empresa CHARACTER VARYNG (16)
);
Vale la pena señalar esta diferencia / similitud para indicar que, si bien SQL tiene una sintaxis general
uniforme, existen diferencias entre SGBD, como ocurre en este caso por los tipos de datos. Por
último, los sistemas de gestión de bases de datos, por lo general fueron creados para trabajar en modo
consola. Sin embargo, hoy existen numerosas interfaces gráficas que facilitan en trabajo en SQL.
5. Instrucciones comunes en SQL

El presente escenario no pretende abarcar todas las instrucciones contenidas en el lenguaje SQL,
debido al tiempo, espacio, complejidad y diferencias entre los SGBD. Aunque, existen diferencias
entre los sistemas de gestión de bases de datos, en general vamos a tratar las instrucciones más
comunes al lenguaje SQL. Para efectos del presente escenario, se presentarán las instrucciones en
PostgreSQL y MySQL (del cual se deriva MariaDB); los demás SGBD tienen sintaxis similares con
algunas variaciones.
5.1. Creación de una base de datos
Para crear una base de datos se emplea la instrucción CREATE, la cual tiene la siguiente sintaxis:
CREATE DATABASE nombre_bd;
Así, si por ejemplo si se desea crear una base de datos en PostgreSQL para listar las bases de datos,
se empleará la instrucción \l, que producirá un resultado similar al siguiente, en el cual se listan las
bases de datos existentes en el sistema:
postgres-# \l
Listado de base de datos
Nombre Dueño Codificación Collate Ctype Privilegios
Spanish_ Spanish_
llevamos postgres UTF8
Spain.1252 Spain.1252
Spanish_ Spanish_
postgres postgres UTF8
Spanish_ Spanish_
samp_db postgres UTF8
Spanish_ Spanish_ =c/postgres
template 0 postgres UTF8
Spain.1252 Spain.1252 postgres=CTc/postgres
Al ejecutarse la instrucción:
CREATE DATABASE mi_db WITH OWNER postgres;
Se presentará el siguiente cambio mostrando que la base de datos ha sido creada:
postgres-# \l
Spanish_ Spanish_
Spanish_ Spanish_
mi_db postgres UTF8
Spanish_ Spanish_
Spanish_ Spanish_
Supongamos que deseamos cambiar el nombre de la base de datos, la sintaxis de la instrucción será la
siguiente:
ALTER DATABASE nombre_anterior RENAME TO nuevo_nombre;

De tal manera, que al ejecutar la instrucción:
ALTER DATABASE mi_db RENAME TO mi_bd;

Obtendremos:
postgres=# ALTER DATABASE mi_db RENAME TO mi_bd;

ALTER DATABASE
postgres-# \l
Spanish_ Spanish_
Spanish_ Spanish_
mi_db postgres UTF8
Spanish_ Spanish_
Spanish_ Spanish_
(6 filas)
Para seleccionar la base de datos se escribirá la siguiente instrucción
\c nombre_db;
De tal forma que obtendremos:
postgres=# \c mi_bd;
ADVERTENCIA: El código de página de la consola (850) difiere del código
de página de Windows (1252).
Los caracteres de 8 bits pueden funcionar incorrectamente.
Vea la página de referencia de psql «Notes for Windows users»
para obtener más detalles.
Ahora está conectado a la base de datos «mi_bd» con el usuario «postgres».
mi_bd=#
Lo anterior nos indica que la base de datos ha sido seleccionada.
Para eliminar una base de datos se utiliza la instrucción DROP DATABASE, empleando la siguiente
sintaxis:
DROP DATABASE nombre_db;

Si llevamos a cabo acciones similares en MySQL, se establecerán las siguientes instrucciones:
Nótese que MySQL no tiene una instrucción para cambiar el nombre de la base de datos.
5.2. Gestión de tablas
A continuación, se presentarán las instrucciones más comunes para la gestión de tablas al interior de
una base de datos.
5.2.1. Creación de tablas
mysql> SHOW DATABASES; mysql> CREATE DATABASE mi_db;

Query OK, 1 row affected (0.15 sec)
Database mysql> SHOW DATABASES;
information_schema Database
mysql
information_schema
performance_schema
mi_db
sakila
mysql
sys
performance_schema
world
sakila
sys
world
mysql> SELECT DATABASE(); mysql> USE mi_db;

Database changed
DATABASE() mysql> SELECT DATABASE();
NULL
DATABASE()
mi_db
Para mostrar las tablas de la base de datos seleccionada, la instrucción en PostgreSQL es \d y en
MySQL se emplea la instrucción SHOW TABLES;:
PostgreSQL MySQL
mi_bd=# \d mysql> SHOW TABLES;
No se encontraron
Empty set (0.02 sec)
relaciones.
Para crear una tabla se emplea la siguiente construcción sintáctica:
CREATE TABLE nombre_tabla(campo_1 TIPO, … campo_n TIPO);
Por ejemplo, para crear una tabla de estudiantes se tendrán los siguientes campos:
• Id_estudiante de tipo entero, el cual no podrá ser nulo. Este será un código que el
sistema dará de forma automática e incremental y será una llave primaria.
• Nombre será el nombre del estudiante, una cadena de caracteres de tamaño 30 y no podrá
ser nula.
• Sexo será un dato que tendrá solo 2 opciones 'F' y 'M'.
Entonces, las sentencias para crear las tablas quedarán así:
PostgreSQL
CREATE TYPE sex AS ENUM ('F', 'M');
CREATE TABLE estudiante(
id_estudiante SERIAL NOT NULL PRIMARY KEY,
nombre VARCHAR(30) NOT NULL,
sexo SEX NOT NULL
);
Cuya ejecución desplegará de la siguiente manera:
mi_bd=# CREATE TYPE sex AS ENUM ('F', 'M');

CREATE TYPE
mi_bd=#
mi_bd=# CREATE TABLE estudiante(
mi_bd(# id_estudiante SERIAL NOT NULL PRIMARY KEY,
mi_bd(# nombre VARCHAR(30) NOT NULL,
mi_bd(# sexo SEX NOT NULL
mi_bd(# );
CREATE TABLE
mi_bd=# \d
Listado de relaciones
Esquema Nombre Tipo Due±o
public estudiante tabla postgres

public estudiante_id_estudiante_seq secuencia postgres
mi_bd=# \d estudiante
Tabla public.estudiante
Columna Tipo Modificadores
not null valor por omisión nextval('estudiante_id_

id_estudiante integer
estudiante_seq'::regclass)
nombre character varying(30) not null
sexo sex not null

"estudiante_pkey" PRIMARY KEY, btree (id_estudiante)
MySQL

id_estudiante INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
sexo ENUM('F', 'M') NOT NULL
);
Cuya ejecución desplegará así:
mysql> CREATE TABLE estudiante(

-> id_estudiante INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
-> nombre VARCHAR(30) NOT NULL,
-> sexo ENUM('F', 'M') NOT NULL
-> );
mysql> SHOW TABLES

Tables_in_mi_db
estudiante
mysql> DESCRIBE estudiante;

Field Type Null Key Default Extra
id_estudiante int(11) NO PRI NULL auto_increment
nombre varchar(30) NO NULL
sexo enum('F','M' NO NULL
En el caso anterior, la instrucción ENUM, que permite de dar un conjunto de opciones cerrada de
valores al campo, podrá escribirse directamente en MySQL, mientras que requerirá de la creación de
un tipo de dato en PostgreSQL.
Si se deseara crear dos llaves primarias, las instrucciones serán en MySQL y PostgreSQL así,
respectivamente:

id_estudiante INT NOT NULL AUTO_INCREMENT,
sexo ENUM('F', 'M') NOT NULL,
PRIMARY KEY(id_estudiante,nombre);
);
id_estudiante SERIAL NOT NULL,
sexo SEX NOT NULL,
CONSTRAINT estudiante_pkey PRIMARY KEY (id_estudiante,
nombre)
);
Para indicar la presencia de llaves foráneas se incluirá la instrucción FOREIGN KEY con la siguiente
sintaxis:
CONSTRAINT fk_tabla_tablaforanea
FOREIGN KEY (tablaforanea_id_tablaforanea)
REFERENCES nombre_bd.tabla_foranea (id_tabla_foranea)
ON UPDATE accion ON DELETE accion,,
ON UPDATE CASCADE(,/;)
CONSTRAINT fk_tabla_tablaforanea
FOREIGN KEY (tablaforanea_id_tablaforanea)
REFERENCES nombre_bd.tabla_foranea (id_tabla_foranea)) MATCH
SIMPLE
ON UPDATE accion ON DELETE accion,
En la Tabla 2 se muestran las acciones que se pueden llevar a cabo.
Tabla 2. Acciones en cascada para mantener integridad referencial
Acción Resultado
NO ACTION, Al eliminar o modificar un registro genera un error que indica que existe una
RESTRICT violación de la llave foránea especficada.
CASCADE Elimina o actualiza las referencias en las otras tablas de manera automática.
SET NULL Asigna el valor de NULL a todas las referencias.

SET DEFAULT Asigna a las referencias un valor definido.
También es posible incluir índices. Un índice permite agilizar las búsquedas por parte del SGBD,
pues organiza los datos de ese índice a manera de lista ordenada. Para crear un índice se emplea la
siguiente sintaxis:
CREATE INDEX identificador_indice ON tabla(campo);
5.2.2. Manipulación de tablas
A continuación, se presentarán una serie de instrucciones para la modificación de tablas:
Renombrar tablas
ALTER TABLE nombre_tabla RENAME nuevo_nombre;
Adicionar una columna a la tabla.

ALTER TABLE nombre_tabla ADD nueva_columna [información del
dato];
Por ejemplo:
ALTER TABLE estudiantes ADD programa VARCHAR(20) NULL, anio_ingreso
INT NULL;
Modificar columna en la tabla

ALTER TABLE nombre_tabla MODIFY columna [nueva información del
dato]
ALTER TABLE nombre_tabla ALTER COLUMN columna TYPE nuevo_tipo;
ALTER TABLE nombre_tabla RENAME COLUMN nombre_actual TO nombre_
nuevo;
Eliminar columna en la tabla

ALTER TABLE nombre_tabla DROP COLUMN columna;
Eliminar índice
DROP INDEX identificador_indice;
Eliminar tabla
DROP TABLE IF EXIST nombre_tabla;
Las anteriores son algunos de los formatos de las sentencias más representativas. Sin embargo, se
recomienda consultar las referencias de los fabricantes para establecer variaciones en la sintaxis, al
igual que para establecer otras instrucciones que se ajusten a las necesidades concretas.
5.2.3. Manipulación de datos
Para manipular los datos incluidos en una tabla, se emplean principalmente las instrucciones INSERT,
SELECT, UPDATE y DELETE. A continuación, se describen algunas maneras en que se presenta la
sintaxis para la manipulación de datos.
Inserción de registros: para insertar valores de registros en una tabla se emplea, de forma genérica, la
siguiente sintaxis:
INSERT INTO nombre_tabla VALUES (Valor_campo1,Valor_campo2,…

Vcalor_campoN);
Sin embargo, al tener llaves primarias, el campo 1 no requeriría de la asignación de valor. Por esa razón
se recomienda la siguiente sintaxis:
INSERT INTO nombre_tabla (columna1,…columnaN)

VALUES (Valor_campo1,…Vcalor_campoN);
Así, para el ejemplo que venimos trabajando en secciones anteriores tendríamos, tanto para
PostgreSQL como para MySQL, lo siguiente:
mi_bd=# INSERT INTO estudiante (nombre,sexo) VALUES ('Luis Leyva', 'M');
INSERT 0 1
mi_bd=# INSERT INTO estudiante (nombre,sexo) VALUES ('Monica Galindo', 'M');
INSERT 0 1
mi_bd=# INSERT INTO estudiante (nombre,sexo) VALUES ('Pedro Jaramillo','M');
INSERT 0 1
mysql> INSERT INTO estudiante VALUES (NULL, 'Luis Leyva', 'M');
mi_bd=# SELECT * FROM estudiante;

Columna nombre sexo
1 Luis Leyva M
2 Monica Galindo M
3 Pedro Jaramillo | M
(3 filas)
mysql> INSERT INTO estudiante VALUES (NULL, 'Monica Galindo', 'M');

mysql> INSERT INTO estudiante (nombre,sexo) VALUES ('Pedro Jaramillo','M');
Por otro lado, podemos hacer inserción de un registro empleando las siguientes sintaxis:
mysql> SELECT * FROM estudiante;
Columna nombre sexo
1 Luis Leyva M
2 Monica Galindo M
3 Pedro Jaramillo | M
3 rows in set (0.00 sec)
INSERT INTO nombre_tabla SET columna1=valor1,

columna2=valor2…;
Modificación de registros
Para insertar valores de registros en una tabla se emplea, de forma genérica, la siguiente sintaxis:
UPDATE nombre_tabla SET columna=valor WHERE condición;
En este punto, empleamos la expresión WHERE, la cual permite colocar una condición a partir
de la cual se hacen búsquedas o modificaciones. Al igual que en la mayoría de los lenguajes de
programación, el SQL emplea operadores para comparar campos con valores o campos entre sí. Los
operadores incluidos en el SQL se muestran en las Tablas 3 y 4.
Así, aplicando esta instrucción al ejercicio que se viene trabajando, tenemos:
Tabla 3. Operadores de comparación en SQL
Operador de comparación Significado

= Igual
< Menor que
<= Menor o igual que
> Mayor que
>= Mayor o igual que
<> Diferente
Fuente: Elaboración propia (2017)
Tabla 4. Operadores lógicos en SQL
Operador Lógico Es TRUE si:

ALL Todas las comparaciones del conjunto es TRUE
AND Las dos expresiones booleanas tienen el valor TRUE
ANY Por lo menos una de las comparaciones del conjunto es TRUE
BETWEEN Si el operando está entre un intervalo
EXIST Cualquiera de las filas está contenida en una subconsulta
IN El dato es igual a alguno de la lista de expresiones
LIKE Si hay coincidencia entre un operando y un patrón
NOT Un operador booleano tiene el valor FALSE (invierte el valor)
OR Alguna de las dos expresiones booleanas tienen el valor TRUE
SOME Alguna comparación es TRUE
Fuente: Elaboración propia (2017)
UPDATE estudiante SET sexo='F' WHERE id_estudiante = 2;
Y obtenemos, respectivamente:
Eliminación de registros: para eliminar registros completos de una tabla se emplea, de forma genérica,
mi_bd=# SELECT * FROM estudiante;

Columna nombre sexo
1 Luis Leyva M
2 Monica Galindo F
3 Pedro Jaramillo M
(3 filas)

Columna nombre sexo
1 Luis Leyva M
2 Monica Galindo F
3 Pedro Jaramillo M
la siguiente sintaxis:
DELETE FROM nombre_tabla WHERE criterio;
5.2.4. Consultas
Para consultar el contenido completo de una tabla, como ya lo hemos hecho en apartados anteriores,
se emplea la siguiente sintaxis:
SELECT * FROM nombre_tabla;
Si solo se desea obtener un conjunto de columnas, se aplicará la siguiente sintaxis:

SELECT columna(s) FROM nombre_tabla;
Si se desea obtener un conjunto de columnas y también una condición que sirva como criterio de
consulta, se aplicará la siguiente sintaxis:
SELECT columna(s) FROM nombre_tabla; WHERE condición;
mysql> SELECT nombre FROM estudiante WHERE sexo='F';

nombre
Monica Galindo
1 row in set (0.00 sec)
mi_bd=# SELECT nombre FROM estudiante WHERE sexo='F';

nombre
Monica Galindo
(1 fila)
Para consultar los datos con ordenamiento se emplea la expresión ORDER BY. Por otro lado, si la
consulta se desea ascendente, se acompaña por la expresión ASC. En caso de esperar una consulta
descendiente, se incluye la expresión DESC.
SELECT columna(s) FROM nombre_tabla ORDER BY columna ASC;
SELECT columna(s) FROM nombre_tabla ORDER BY columna DESC;
SELECT nombre, sexo FROM estudiante
ORDER BY nombre DESC;
nombre sexo nombre sexo
Luis Leyva M Luis Leyva M
Monica Galindo F Monica Galindo F
Pedro Jaramillo M Pedro Jaramillo M

3 rows in set (0.00 sec) 3 rows in set (0.00 sec)
Continuando con el ejemplo propuesto, veamos la aplicación de ORDER BY:

En algunos casos, al definir los nombres de las columnas, una palabra se queda corta para nombrar las
columnas. Por esta razón, vale la pena emplear un ALIAS, de tal manera que hace que la tabla tenga
una lectura más clara. Un ejemplo del uso de alias se expresa en la siguiente sintaxis y ejemplo:
mysql> SELECT id_estudiante, nombre AS 'nombres y

apellidos', sexo FROM estudiante;
id_estudiante nombre sexo
1 Luis Leyva M
2 Monica Galindo F
3 Pedro Jaramillo M
SELECT columna AS alias FROM nombre_tabla;
Al emplear los operadores mencionados anteriormente, es posible obtener datos que se encuentren
en un rango de valores. A continuación, se presentan algunas sintaxis propuestas para obtener este
objetivo:
SELECT columna(s) FROM nombre_tabla WHERE columna > valor;
SELECT columna(s) FROM nombre_tabla WHERE columna < valor;
SELECT columna(s) FROM nombre_tabla WHERE columna BETWEEN valor
AND valor;
Es posible buscar cadenas o subcadenas al interior de una columna mediante el uso de la expresión
LIKE, como se presenta a continuación:
SELECT columna(s) FROM nombre_tabla WHERE columna LIKE '%valor%';
(%=cualquiera)
mysql> SELECT nombre FROM estudiante WHERE nombre LIKE '%e%';
nombre
Luis Leyva
Pedro Jaramillo
En el ejemplo anterior, buscaremos las filas cuyo nombre contenga la cadena ‘e’:
De forma análoga, es posible buscar cadenas al interior de una columna que no contengan
determinadas cadenas de caracteres al utilizar NOT LIKE;
SELECT columna(s)FROM nombre_tabla WHERE columna NOT LIKE
'%valor%';
mysql> SELECT nombre FROM estudiante WHERE nombre NOT LIKE '%va';
nombre
Monica Galindo
Pedro Jaramillo
Por ejemplo, buscar los nombres de los estudiantes que no terminen en ‘va’:
Es posible buscar coincidencia de valores de datos en una columna al emplear la expresión IN. La
sintaxis es la siguiente:
SELECT columna(s) FROM nombre_tabla WHERE columna IN (valor,
valor);
mysql> SELECT nombre FROM estudiante WHERE id_estudiante IN ('1', '3');

nombre
Luis Leyva
Pedro Jaramillo
Aplicándolo al ejemplo, tenemos:
Una consulta es finalmente una tabla que corresponde a un subconjunto de otra tabla más amplia.
De tal forma que es posible realizar una subconsulta a partir de otra consulta, como se presenta en la
siguiente sintaxis:
SELECT columna(s) FROM nombre_tabla
WHERE columna = ANY(SELECT columna(s) FROM nombre_tabla; WHERE
condición);
5.2.5. Operaciones
A continuación, se presenta la sintaxis de algunas operaciones útiles para la obtención de datos que
permiten interpretar lo contenido en las tablas.
Suma (SUM): la suma de los datos de una columna. Por ejemplo:
SELECT SUM(columna)FROM nombre_tabla;
Promedio (AVG): el promedio de los datos de una columna. Por ejemplo:
SELECT AVG(columna)FROM nombre_tabla;
Desviación estándar (STDDEV): la desviación estándar de los datos de una columna. Por ejemplo:
SELECT STDDEV(columna) FROM nombre_tabla;
Contar (COUNT): cuenta la cantidad de veces que están presentes los datos en una columna. Por
ejemplo:
SELECT COUNT(columna) FROM nombre_tabla;
Máximo (MAX): devuelve el mayor de los datos de una columna. A saber:
MÁXIMO:SELECT MAX(columna) FROM nombre_tabla;
Mínimo (MIN): devuelve el mínimo de los datos de una columna, así:
MÍNIMO:SELECT MIN(columna) FROM nombre_tabla;
5.2.6. Consultas entre tablas
Como se están empleando tablas relacionales, es probable que la llave primara de una tabla
corresponda a un campo que contenga una llave foránea en otra tabla. Es posible unir columnas de
ambas tablas empleando la expresión INNER JOIN, de acuerdo con la siguiente sintaxis:
SELECT columna(s) FROM tabla1 INNER JOIN tabla2 ON tabla1.campo =
tabla2.campo;
También es posible unir las filas de dos tablas al emplear la instrucción UNION. Las columnas que se
unirán deben ser del mismo tipo.
SELECT columna(s) FROM tabla1 WHERE condición UNION SELECT
columna(s) FROM tabla2 WHERE condición;
5.3. Vistas
Hay otro tipo de relaciones SQL que se asemejan a las consultas, pero que no tienen un registro
físico. En realidad, corresponden a tablas virtuales. Se denominan vistas y existen solo en memoria.
Para su creación se emplea la expresión CREATE VIEW y la sintaxis general es como se presenta a
continuación.
CREATE VIEW nombre_vista AS SELECT columna(s) FROM nombre_tabla

WHERE condición;
Referencias
Education.
Addison Wesley.
Unidad 3: Lenguaje de consulta estructurado-SQL
Escenario 5: Fundamentos del lenguaje SQL
Diseñador Gráfico: David A. Rivera Virgüez

Unidad 13 / Escenario
Escenario 62
fundamental
Lectura Fundamental
Programación de bases
Etapas de un plan de datos,
de comunicación
transacciones,
estratégica concurrencia y
recuperación
Contenido
1 Programación en bases de datos
2 Transacciones y control de concurrencia
Palabras clave: SQL, función, procedimiento almacenado, cursor, disparador, transacción, concurrencia.
1. Programación en bases de datos
Si bien, el SQL es un lenguaje de alto nivel, no es uno que esté orientado a la programación
como tal, sino más bien, como su nombre lo dice, está orientado a la consulta. Sin embargo, los
procesos involucrados en SQL, al ser programados, incrementan el potencial del uso de las bases
de datos involucradas.
Una de las maneras de implementar técnicas de programación en SQL consiste en insertar

instrucciones de consulta SQL en lenguajes como Java o C#. Por otro lado, es posible involucrar
programación procedimental en los sistemas de gestión de bases de datos, lo que hace posible la
automatización de procesos y, además, se simplifica la aplicación de SQL mismo.
Empresas como Oracle han incluido lenguajes procedimentales de programación en PL/SQL,

como: PostgreSQL (Procedural Language / Structured Query Language), PL/pgSQL (Procedural
Language / PostgreSQL Structured Query Language) o Microsoft y SyBase el Transact-sql.
En general, los sistemas de gestión de bases de datos no se emplean de manera aislada, sino que
están integrados a otro tipo de aplicaciones o a lenguajes de programación. Estos, a su vez, están
incorporados con sistemas de acceso al usuario, sea en escritorio o en la web. Por esta razón, de
acuerdo con Elmasri y Navathe (2007, p.252), podemos identificar algunas metodologías para la
programación de bases de datos.
1.1. Comandos SQL incrustados en un lenguaje de programación
En esta metodología se incluye código SQL (lenguaje de datos) embebido en el código de un

lenguaje de programación host (Elmasri & Navathe, 2007, p.252), como Java o C#, por ejemplo.
Para poder integrar el lenguaje de programación con la correspondiente base de datos, conviene
descargar del sitio del fabricante del sistema de gestión de bases de datos, un “conector”. Este no
es más que un programa que, una vez instalado, permite establecer intercambio de información
entre el lenguaje de programación y la base de datos. Adicionalmente, en el código debe incluirse
lo que se denomina una “cadena de conexión”, que es la instrucción que permite establecer la
conexión entre el lenguaje de programación y la base de datos.
A continuación, en la Figura 1 se presentan algunos ejemplos de código para integrar Java con
PostgreSQL. La integración entre otros lenguajes y sistemas de gestión de bases de datos se dejan al
estudiante como investigación.
public static void conectar(){
try {
Class.forName("org.postgresql.Driver");
Connection conexion = DriverManager.getConnection("jdbc:postgresql://
localhost:5432/mydb","postgres", "password");
conexion.setAutoCommit(false);
System .out.println("Base de datos abierta exitosamente");
}
catch (ClassNotFoundException | SQLException e) {
System.out.println("La base de datos no pudo conectarse");
System.err.println(e.getClass().getName() + ": " + e.getMessage());
System.exit(0);
}
}
Figura 1. Ejemplo de código para conectar Java con PostgreSQL

En el ejemplo anterior, el texto señalado en marrón corresponde a la cadena de conexión. A

continuación, se muestra cómo obtener los datos a partir de una consulta (Figura 2).
String SentenciaSQL = "SELECT * FROM registros"

public static LstRegistros conSelReg(LstRegistros lr, String SentenciaSQL){
try {
try (Connection conexion =
DriverManager.getConnection("jdbc:postgresql://localhost:5432/mydb","postgres", "password")) {
System .out.println("Base de datos abierta exitosamente");
try (Statement declaracion = conexion.createStatement();ResultSet resultado = declaracion.
executeQuery(SentenciaSQL)) {
while(resultado.next()){
int id = resultado.getInt("id ");
String campo = resultado.getString("campo");
Date fecha = resultado.getDate("fecha");
Instancia inst = new Instancia(id, campo, fecha);
lr.addInstancia(inst);
}
resultado.close();
declaracion.close();
}
conexion.close();
System.out.println("Base de datos cerrada exitosamente");
}
}
System.out.println("La base de datos no pudo conectarse"); System.err.println(e.getClass().
getName() + ": " + e.getMessage());
System.exit(0);
}
return lr;
}
Figura 2. Ejemplo de código para realizar consulta desde Java conectado con PostgreSQL
En el ejemplo anterior se incluyó, como parámetro, una lista de registros y la sentencia SQL que, una
vez ejecutada, permite recuperar de la base de datos una serie de registros que quedan almacenados
en la variable “resultado”. Luego, los valores almacenados en cada registro son guardados en variables
que, a su vez, permite crear una instancia del objeto equivalente al registro, para ser agregado a la lista
que será retornada al final de la función.
También, se pueden ejecutar otras sentencias SQL como INSERT, UPDATE o DELETE, a través de
códigos como el que se presenta a continuación en la Figura 3.
public static void operacionSQL(String valor){
try {
try (Connection conexion = DriverManager.getConnection("jdbc:postgresql://
localhost:5432/mydb","postgres", "password")) {
Statement declaracion = null;
declaracion = conexion.createStatement();
String SentenciaSQL = "INSERT INTO registros(nombre) VALUES('" +valor+
"');";
declaracion.executeUpdate(SentenciaSQL);
declaracion.close();
conexion.commit();
conexion.close();
}
}
System.out.println("La base de datos no pudo conectarse");
System.err.println(e.getClass().getName() + ": " + e.getMessage());
System.exit(0);
}
Figura 3. Ejemplo de código para insertar en una tabla de una base de datos desde Java conectado con PostgreSQL
En el ejemplo anterior se incluye la sentencia SQL en el código, para hacer modificaciones sobre la
base de datos. Los aspectos propios del lenguaje de programación se dejan al análisis por parte del
estudiante, por estar fuera del alcance del curso.
1.2. Uso de funciones y procedimientos almacenados de bases de datos de SQL
Como se indicaba en el apartado anterior, en muchas ocasiones las operaciones que se realizan
sobre SQL, se hacen desde un lenguaje de programación con el que se ha establecido una conexión.
Sin embargo, a veces es útil implementar módulos de programa de bases de datos que, valga la
redundancia, son ejecutados en el servidor de bases de datos. Las funciones y procedimientos
son útiles si:
• Existe un acceso simultáneo de varias aplicaciones a la misma base de datos.
• Se reduce el uso de recursos y tiempo por evitar la transferencia de datos.
• Se puede mejorar la potencia del modelado de vistas.
A continuación, se presenta de forma genérica, la manera en que se implementan las funciones y

procedimientos almacenados.
1.2.1. Funciones y procedimientos almacenados
Tanto la función como el procedimiento —dados o no unos parámetros— ejecutan una serie de
operaciones o transformaciones en los datos. Un procedimiento se distingue de una función en
cuanto la función puede retornar un valor, mientras que el procedimiento no lo hace. Un formato
genérico para la declaración de procedimientos es el siguiente (Figura 4) (Elmasri & Navathe,
2007, p.272):
CREATE PROCEDURE nombre_procedimiento(parámetros)

declaraciones
cuerpo;
Figura 4.Sintaxis para construcción de procedimientos almacenados

Por otro lado, un formato genérico para declarar una función tiene la siguiente sintaxis (Figura 5):
CREATE FUNCTION nombre_funcion(parámetros)

RETURNS tipo_de_retorno
declaraciones
cuerpo;
Figura 5.Sintaxis para construcción de procedimientos almacenados

Así, por ejemplo, crearemos una función para obtener el saldo de una cuenta dato el identificador de la
misma (Figura 6).
CREATE OR REPLACE FUNCTION consultar_saldo(no_cuenta NUMBER)
RETURNS decimal(12,2)
BEGIN
DECLARE saldo decimal(12,2)
SELECT saldo_cuenta INTO saldo FROM cuenta WHERE id_cuenta = no_cuenta;
RETURN saldo;
END;
Figura 6. Ejemplo de procedimiento almacenado

Para llamar la función se puede emplear, por ejemplo, la siguiente expresión (Figura 7):
SELECT consultar_saldo('043123546')
Figura 7. Ejemplo de llamado a procedimiento almacenado

Esto dará como resultado el saldo de la cuenta identificada como 043123546.
De la misma manera, si se desea hacer un procedimiento similar se podría redactar de la siguiente

manera (Figura 8):
CREATE OR REPLACE PROCEDURE consultar_saldo(no_cuenta NUMBER)

BEGIN
SELECT saldo_cuenta FROM cuenta WHERE id_cuenta = no_cuenta;
END;
Figura 8. Ejemplo de función

Y para llamarlo se puede emplear la siguiente instrucción (Figura 9):
EXEC consultar_saldo('043123546')
Figura 9. Ejemplo de llamado a función

Cada SGBD tiene matices en la sintaxis que deben ser consultados en la documentación puesta a
disposición de cada fabricante.
1.2.2. Cursores
Un cursor es una herramienta que permite que, en lugar de ejecutar una consulta completa a la vez,
sea posible establecer la consulta y, a continuación, leer del resultado de esta un número determinado
de filas a la vez. Entre las razones por las que puede ser conveniente el uso de cursores, tenemos el
emplear la memoria de tal forma que no se ocupe con un gran número de filas. A continuación, en la
Figura 10 vemos cómo se declara un cursor.
BEGIN WORK;
DECLARE mi_cursor CURSOR
FOR SELECT campos FROM tabla;
Figura 10. Declaración de cursor

En general, se emplea la instrucción FETCH para seleccionar la fila que toma el cursor,
FORDWARD la siguiente y BACKWARD la anterior. Por ejemplo, si se desea seleccionar las 5
primeras filas de una consulta se puede indicar de la siguiente manera (Figura 11):
FETCH FORDWARD 5 IN mi_cursor
Figura 11. Llamado de cursor

De la misma forma, en cada SGBD la escritura de instrucciones tiene matices que deben ser
consultados en la documentación suministrada por el fabricante.
1.2.3. Disparadores / trigger
Los disparadores o triggers son acciones definidas sobre la base de datos, de tal forma que está será
activada antes o después de que se realice alguna operación sobre una tabla, tal como un INSERT,
DELETE o UPDATE, cuando sea llamada por un comando SQL o cuando se ejecute una línea
afectada por comandos SQL.
A continuación, se presenta un ejemplo de trigger empleado para registrar cuando un usuario ha
realizado una inserción de un dato en una tabla (Figura 12).
CREATE OR REPLACE FUNCTION insertar_trigger_log()

RETURNS TRIGGER AS $insertar$
DECLARE BEGIN
INSERT INTO log( fecha_log, accion ) VALUES(current_
timestamp,'inserción' );
RETURN NULL;
END;
$insertar$ LANGUAGE plpgsql;
CREATE TRIGGER insertar_log AFTER INSERT ON alquileres

EXECUTE PROCEDURE insertar_trigger_log();
Figura 12. Llamado de cursor

2. Transacciones y control de concurrencia

Si bien en las bases de datos se registra y almacena información, para darle una utilidad real a estas es
necesario incluir el concepto de transacción. La transacción se define como:
(…) una unidad única de trabajo. Si una transacción tiene éxito, todas las modificaciones de los
datos realizadas durante la transacción se confirman y se convierten en una parte permanente
de la base de datos. Si una transacción encuentra errores y debe cancelarse o revertirse, se
borran todas las modificaciones de los datos (Microsoft, 2017).
Otro concepto de importancia es la concurrencia. Se entiende como concurrencia:
(…) la capacidad de múltiples procesos para acceder o cambiar datos compartidos al mismo
tiempo. Cuanto mayor es el número de procesos de usuario simultáneos que pueden
ejecutarse sin bloquearse entre sí, mayor es la capacidad concurrencia del sistema de base de
datos (Microsoft, 2005).
En la práctica, las bases de datos están siendo afectadas continuamente por procesos transaccionales,
muchas veces concurrentes, los cuales se originan en los usuarios o en los mismos procesos del
sistema. Sin embargo, en caso de existir problemas en alguna transacción es posible que se produzcan
inconsistencias en los datos, que pueden conllevar a errores en la información, problemas para el
usuario o para el propietario del sistema, costos por servicio e, inclusive, problemas legales. De allí la
importancia del control de concurrencia.
2.1. Control de concurrencia
Como se señalaba anteriormente, al hablar de concurrencia nos referimos a la ejecución de procesos

simultáneos en la base de datos. El principal objetivo del control de concurrencia es coordinar los
procesos que se ejecutan sobre los datos de forma simultánea, de tal manera que no se presente
interferencia entre estos. Por esta razón, se debe implementar un modelo que mantenga la
consistencia sobre los datos cuando se presenten transacciones concurrentes.
2.2. Propiedades de transacción ACID
En los momentos en que se presentan transacciones concurrentes sobre las bases de datos, se
deben cumplir las propiedades ACID. Esta denominación es dada por las iniciales en inglés de las
propiedades involucradas.
2.2.1. Atomicidad (atomicity)
Esta propiedad entiende a cada transacción como una unidad completa. Es decir, todas las acciones
o procesos involucrados en la transacción se llevan a cabo cuando esta es ejecutada o, por el
contrario, no hay ninguna acción o proceso. En caso de que exista alguna interrupción en los procesos
o acciones involucrados en la transacción, estos serán reversados o anulados, y la base de datos
regresará al estado anterior a la ejecución de la transacción.
2.2.2. Consistencia (consistency preservation)
Los datos, en toda la base de datos, deben ser siempre consistentes entre sí. No debe haber
referencias a datos que no existan o que contengan información errónea. Así, en toda transacción,
la base de datos debe partir de un estado consistente y terminar en otro estado consistente, para
mantener la integridad referencial.
2.2.3. Aislamiento (isolation)
Supongamos que diversos usuarios estén tratando de acceder y modificar simultáneamente los mismos
datos; esto puede generar inconsistencias entre los datos almacenados. Por esa razón, los datos
involucrados en una transacción no pueden ser empleados por otra transacción hasta que la primera
haya terminado.
2.2.4. Durabilidad o permanencia (durability)
Implica que, una vez se confirme que ha concluido exitosamente una transacción en una base de datos,
esta pasa a un estado de consistencia de los datos. Esto con el objetivo de que, incluso si el sistema falla,
los datos se mantengan de forma permanente hasta que puedan llegar a ser modificados por una nueva
transacción.
2.3. Estados de las bases de datos
La base de datos puede estar en dos estados: de consistencia y de inconsistencia. Por lo general, antes
de iniciar la transacción, la base de datos se encuentra en estado de consistencia (debe estarlo). Una
vez inicia la transacción, al involucrar esta con un conjunto de acciones, operaciones o procesos, es
posible que la base de datos entre en un estado temporal de inconsistencia. No obstante, al final de la
transacción, la base de datos debe regresar a un estado de consistencia.
2.4. Estados de las transacciones
Tabla 1. Operaciones sobre transacciones
OPERACIÓN DEFINICIÓN
READ En la transacción se está leyendo algún elemento de la base de datos.
WRITE En la transacción se está escribiendo sobre algún elemento de la base de datos.
En la transacción se confirma que las modificaciones hechas deben ser
COMMIT permanentes.
En la transacción se confirma que ninguna de las modificaciones hechas debe ser
ABORT permanente.
La Tabla 1 presenta las operaciones que pueden ser aplicadas en una transacción:
Tabla 2. Estados de transacciones
La transacción se está ejecutando.
ACTIVA
PARCIALMENTE Se confirma que la última operación de la transacción fue ejecutada.
CONFIRMADA
CONFIRMADA Se confirma que la transacción fue ejecutada correctamente en su totalidad.
Se presentó algún problema durante la ejecución y la base de datos debe restaurar
FALLA su estado al anterior de la ejecución de la transacción.
COMPLETADA Se ha terminado la transacción.
La Tabla 2 muestra los estados en los cuales se puede encontrar una transacción:
Para facilitar el trabajo con transacciones sobre la base de datos, se emplea el denominado manejador
de transacciones. Este es una aplicación que permite administrar las transacciones que se presentan
en la base de datos y facilitar la implementación de ACID.
2.5. Bloqueos
El sistema puede detener temporalmente la ejecución de transacciones, mientras realiza alguna otra
operación. El objetivo de los bloqueos es evitar conflictos, que sean resultado de la actualización,
ocurridos por la lectura o modificación de datos por parte de los usuarios. Los bloqueos se
caracterizan por:
• Aplicar la serialización en las transacciones. Solo un usuario puede modificar un dato a la vez.
• Permite transacciones simultáneas por parte de distintos usuarios.
Como se puede evidenciar, ayuda a mantener propiedades tales como el aislamiento. En general,
podemos encontrar bloqueos exclusivos o bloqueos compartidos. Se entiende que un bloqueo es
exclusivo cuando este es solicitado por un único recurso para una transacción; mientras el bloqueo es
compartido cuando se aplica sobre un recurso al que desean acceder varias transacciones.
Referencias
Elmasri, R. & Navathe, S. (2007). Funamentos de Sistemas de Bases de Datos. Madrid: Pearson,
Addison Wesley.
Microsoft. (30 de abril de 2005). Microsoft TechNet. Concurrencia de base de datos y versión de
nivel de fila en SQL Server. Recuperado de https://technet.microsoft.com/en-us/library/cc917674.
aspx
Microsoft. (2017). Microsoft Developer Network Library. Instrucciones de transacción (Transact-SQL).

Recuperado de https://msdn.microsoft.com/es-es/library/ms174377(v=sql.120).aspx
Education.
Unidad 3: Lenguaje de consulta estructurado-SQL
Escenario 6: Programación de bases de datos.
Autor: Teresa del Pilar Niño Benavides

Unidad 14 // Escenario 72
fundamental
Lectura Fundamental
Bases
Etapasdededatos e inteligencia
un plan de comunicación
de negocios
estratégica
Contenido
1 Administración estratégica e inteligencia de negocios
2 Inteligencia de negocios
Palabras clave: almacén operacional de datos (ODS, Operational Data Store), bases de datos gerenciales, bases de
datos transaccionales, carga, cubo, Data Mart (DM), Data Warehouse (DW).
Introducción
Las empresas de este siglo no son las mismas del siglo pasado. De acuerdo con Laudon (2012), en el
año 2010, en los Estados Unidos, las empresas invirtieron aproximadamente U$562.000.000.000
en hardware, software y sistemas de telecomunicaciones. Esto se debe a que los sistemas de
información dejaron de ser una herramienta para facilitar los procesos en los negocios, y pasaron a ser
transformadores de las organizaciones mismas. La información se ha convertido en apalancador de
valor, lo cual genera ventajas competitivas, acerca a los clientes a las empresas y marca la diferencia
entre crecer o desaparecer del mercado.
Entre las novedades de los sistemas de información gerencial tenemos las siguientes (Laudon &
Laudon, 2012):
• Las organizaciones pasan de invertir enormes cantidades en infraestructura a utilizar la

computación en la nube.
• Crece el concepto de software como servicio.
• Se impone el uso de las tecnologías móviles frente a las fijas por parte de los usuarios.
• Los gerentes adoptan software para trabajo colaborativo.
• Se expanden las aplicaciones de inteligencia de negocios.
• Se incrementan las reuniones en línea.
• La web pasa de ser estática y unidireccional a ser dinámica, la cual es adecuada a las necesidades
del cliente y personalizada, en muchos casos construida principalmente por los mismos usuarios.
• El cliente se convierte en un sujeto activo en el proceso de producción de bienes y servicios.
• Hay una co-creación de valor comercial.
• Emerge la empresa digital.
• La cadena de suministro está cada vez más integrada y coordinada a través de las tecnologías de
información.
• Los activos corporativos son cada vez más intangibles.
Como se puede evidenciar, los sistemas de información gerencial pasaron de tener una importancia
operativa a una importancia estratégica para las empresas. De allí que valga la pena analizar la relación
entre los sistemas de información y la gestión estratégica.
2
1. Administración estratégica e inteligencia de negocios
De acuerdo con Michael Porter, “La estrategia es un conjunto de compromisos y actos integrados
y coordinados, cuyo objetivo es explotar las competencias centrales y conseguir una ventaja
competitiva” (Hitt, Ireland & Hoskisson, 2004). Así, los procesos de administración estratégica
buscan en última instancia lo que se denomina “competitividad estratégica”, concepto que
básicamente se traduce en la consecución de utilidades superiores al promedio. Así mismo, de acuerdo
con Laudon:
Los gerentes y las empresas de negocios invierten en tecnología y sistemas de

información porque ofrecen un valor económico real para la empresa. La decisión de
crear o mantener un sistema de información asume que los rendimientos sobre esta
inversión serán superiores a otras inversiones en edificios, máquinas u otros activos.
Estos rendimientos superiores se expresarán como aumentos en la productividad,
aumentos en los ingresos (lo cual incrementará el valor de la empresa en el mercado
bursátil) o tal vez como un posicionamiento estratégico superior a largo plazo de la
empresa en ciertos mercados (que producirá mayores ingresos en el futuro) (Laudon
& Laudon, 2012).
Así, desde el punto de vista gerencial, se tiene que:
(…) los sistemas de información forman parte de una serie de actividades que agregan
valor para adquirir, transformar y distribuir la información que los gerentes pueden
usar para mejorar la toma de decisiones, el desempeño de la organización y, en última
instancia, incrementar la rentabilidad de la empresa (Laudon & Laudon, 2012).
3
1.1. Cadena de valor y sistemas de información
Si se observa la cadena de valor propuesta por Michael Porter, se puede evidenciar cómo el desarrollo
tecnológico hace parte de lo que se denomina “actividades de apoyo” (Figura 1) (Hitt, Ireland, &
Hoskisson, 2004).
Cadena de valor industrial
Figura 1. Cadena de Valor de Michael Porter. Modificado de Laudon & Laudon (2012)
4
Sin embargo, al involucrar los sistemas de información de manera transversal a lo largo de todas
las actividades de la organización, la tecnología se integra con las actividades primarias y cobra
importancia estratégica en la organización y permite la creación constante de valor (Figura 2).
Administración y gerencia:
Sistemas de programación electrónica y mensajeria
Recursos humanos:
Actividades Sistemas de planificación de la fuerza de trabajo
de apoyo Tecnologia:
Sistemas de diseño auciliado por computadora
Abastecimiento: Cadena de
Sistemas de pedidos computarizados valor de la
Logística Operaciones Ventas y ServicioL ogística
empresa
de entrada marketing de salida
Actividades Sistemas de Sistemas de Sistemas de Sistemas de

Sistemas de maquinado pedidos manteni- programa-
primarias almacenes controlados computari- miento a cion de
automati- por compu- zados equipo envios
zados tadora automáticos
Sistemas de
Sistemas de
administración
suministros y
de relaciones
abastecimiento
con el clinete
Proveedores de Proveedores Empresa Distribuidores Clientes

los proveedores
Cadena de valor industrial
Figura 2. Tecnologías representativas en la cadena de valor de una empresa. Modificado de Laudon & Laudon (2012).
De la misma manera, la información en los negocios tendrá su propia cadena de valor, como se ilustra
en la Figura 3.
5
Figura 3. La cadena de valor de la información de negocios. Modificado de Laudon & Laudon (2012).
La información, entonces, se convierte en un activo de la empresa; y la tecnología, en medio de

creación de valor. Sin embargo, para que esta última sea sostenible debe estar alineada con los
objetivos organizacionales y, aún más, con los sistemas de información, que tendrán sus propios
objetivos estratégicos.
1.2. Objetivos estratégicos de los sistemas de información
Independientemente del tamaño de las organizaciones, desde PYMES hasta grandes corporaciones, las
empresas se ven obligadas a tomar decisiones, y para tal tarea deben tener conocimiento de su empresa.
Para esto, los sistemas de información son más un medio, que un fin (Aranibar, 2013).
De acuerdo con Laudon (2012), las empresas invierten en sus sistemas de información para lograr
seis objetivos estratégicos:
1. Lograr una excelencia operacional
2. Generar nuevos productos, servicios, modelos de negocios
3. Alcanzar una relación íntima con clientes y proveedores
4. Mejorar la toma de decisiones
5. Crear de ventajas competitivas
6. Sobrevivir en el mercado
6
Respecto al primer objetivo, este busca reducir costos y aumentar la productividad (Turban, Volonio &
Wood, 2013). Dicha productividad en general viene dada por la siguiente fórmula:
Productividad= Salidas
Entradas
Los tipos de salidas dependen de la industria; estos pueden ser: número de unidades manufacturadas,
vendidas, servicios prestados, etc. Como entradas tenemos aquello que es nuestro insumo, como
horas-hombre, materias primas, etc. Las ganancias en productividad se ven representadas en:
• Incremento de las salidas, mientras se mantiene el mismo nivel de entradas.
• Mantenimiento de las salidas y reducción del nivel de entradas.
• Incremento de salidas y reducción del nivel de entradas.
Para alcanzar el segundo objetivo, en la creación de nuevos productos, servicios o modelos de

negocio, ya no basta con un ingrediente netamente creativo; existen herramientas que permiten
identificar qué es lo que el cliente espera de manera objetiva y sustentada.
Por un lado, es posible que el cliente encuentre mecanismos para participar en el desarrollo de
productos; y por otro, en la interacción cotidiana con el cliente, este aporta información valiosa
acerca de su comportamiento, hábitos y necesidades. Gestionar la información en este sentido,
permite alinear el enfoque de la empresa con las necesidades del cliente.
Para lograr este es necesario desarrollar el tercer objetivo, que es establecer una relación íntima con
el cliente. Él ya no es solo un “consumidor”, es un “co-productor”. En ocasiones, puede pasar a tener
el estatus de asociado, pues ya no se espera solo brindarle beneficios al cliente, sino crear una relación
simbiótica en la que este participe en los procesos de negocio.
Los objetivos anteriores permiten establecer, por un lado, el conocimiento del comportamiento
del negocio; y, por otro, crear y administrar el conocimiento de toda la cadena de valor. Este
conocimiento posibilita alcanzar el cuarto objetivo, lo que mejora la toma de decisiones, reduce el
riesgo, alinea los recursos de tecnologías de la información con la estrategia de negocio, e identifica
nuevas oportunidades, riesgos, fortalezas y limitaciones.
Por último, al tener mayor conocimiento del negocio, se podrá aumentar la rentabilidad de la empresa
y obtener ingresos superiores al promedio (Hitt, Ireland, & Hoskisson, 2004). También se generará
valor a los stakeholders, a través de ventajas competitivas, agilidad y velocidad en responder a las
necesidades del mercado; en general, permitirá que la empresa crezca y se mantenga en el tiempo.
7
1.3. Decisiones estructuradas, semiestructuradas y no estructuradas
En la operación de la empresa, el gerente se enfrenta cotidianamente a la toma de decisiones,

sin embargo, no todas las decisiones son iguales. En algunos casos, el gerente solo debe seguir un
procedimiento; y en otros, debe enfrentar situaciones coyunturales (Turban, Aronson & Peng Liang,
2005). Por esa razón, las decisiones se clasificarán en decisiones estructuradas, semiestructuradas y
no estructuradas.
1.3.1. Decisiones estructuradas
En las decisiones estructuradas existen procedimientos o métodos definidos que se deben aplicar,
antes de que el problema tenga que ser resuelto. Este tipo de decisiones son comunes en el nivel
operativo y, en ocasiones, en el táctico. A nivel estratégico, también podemos encontrar decisiones
estructuradas; por ejemplo, si se desea establecer la localización de una planta, pueden existir criterios
medibles y concretos, que son el resultado de modelos matemáticos y definen la ubicación exacta de
esta, de acuerdo con los objetivos de la organización. No obstante, a nivel estratégico, este tipo de
decisiones son poco comunes.
1.3.2. Decisiones semiestructuradas
En las decisiones semiestructuradas no siempre es posible establecer un método para detectar

el problema, aunque sí es posible establecer un modelo para su solución. Usualmente, responde
a situaciones no programadas, pero a las cuales se puede responder de algún modo en concreto.
Normalmente, corresponde a decisiones de los niveles táctico y estratégico.
1.3.3. Decisiones no estructuradas
En estas no se establece un modelo en ninguna de las etapas de la solución del problema.

Normalmente, corresponde a decisiones del nivel estratégico.
8
2. Inteligencia de negocios
La inteligencia de negocios (BI, por sus siglas en inglés) ayuda a que “los negocios funcionen
de forma más eficiente, identificando tendencias y relaciones en los datos de la organización
y cree o aproveche ventajas competitivas u oportunidades de negocio” (Turban, Volonio &
Wood, 2013). Así mismo, de acuerdo con Turban, la implementación exitosa de la inteligencia
de negocios implica un desafío técnico, debido principalmente a que requiere de la integración,
computación y análisis de repositorios de datos masivos, los cual no siempre es sencillo.
En general, tenemos dos tipos de sistemas de información (Aranibar, 2013):
• Transaccionales
• Gerenciales
Una organización funciona en un modelo de tres capas en términos de:
• Gestión estratégica
• Gestión táctica
• Gestión operativa
Así, en la cadena de valor de la información, a nivel operativo, los sistemas generan datos; a
nivel táctico, se trabaja con información; y a nivel estratégico, se toman decisiones a partir del
conocimiento.
• Nivel operativo: datos
• Nivel táctico: información
• Nivel estratégico: conocimiento
La Figura 4 ilustra mejor este modelo.
9
Figura 4. Modelo piramidal empresarial. Modificado de Aranibar (2013)
Cuando de toma de decisiones se trata, se pueden tener en cuenta criterios subjetivos u objetivos.
Los criterios subjetivos dependen de la habilidad y criterio que tenga el tomador de decisiones;
la presente lectura no tiene en cuenta este tipo de criterios. Por su parte, los criterios objetivos
generalmente tienen en cuenta modelos en los cuales se trata de representar la realidad y en los
que se considera la situación a la que se desea llegar. Este ejercicio se desarrolla a través de la
identificación de variables independientes, relaciones entre ellas y variables dependientes. Esto se
lleva a cabo mediante metodologías que permitan obtener información y conocimiento, que aporten
suficientes criterios para la toma de decisiones.
Aunque es posible que el gerente aplique modelos para la toma de decisiones a través de cálculos
manuales, tendría la dificultad de tener que realizarlos cada vez que requiera tomar una decisión; y en
caso de que las condiciones cambien, realizar nuevos modelos.
Gracias al apoyo de los sistemas de información, el decisor puede contar con herramientas a través de
las cuales puede extraer los datos, a partir de las fuentes o repositorios de información.
Estos se transforman para que puedan ser cargados (ETL) (Kimball & Ross, 2013) en un sistema de
inteligencia de negocios, que aporte información y conocimiento que permita mejorar la toma de
decisiones y reducir la incertidumbre.
En la actualidad, los sistemas de información para la toma de decisiones se pueden clasificar como se
muestra en la Tabla 1.
10
Tabla 1. Comparación de sistemas de información
Sistema de
Entrada Procesamiento Salida Usuarios Caso
información
Datos Proyecciones, Directorio,
Sistema agregados, Simulación, pronósticos, alta Sistema de
de soporte externos e animación respuestas gerencia, proyección
ejecutivo (ESS, internos, gráfica, a consultas, comités financiera a largo
EIS) estadísticas, interacción resúmenes ejecutivos plazo
indicadores ejecutivos y directivos
Datos de
bajo volumen
Gerencia
optimizados Reportes
funcional,
Sistema de para análisis, especiales, Sistema de apoyo
Simulación, toma gerencia
soporte de modelos análisis de a decisiones
de decisiones, media,
decisiones analíticos, decisión, de inversión y
análisis tomadores
(DSS) modelos de respuestas a financiamiento
de
decisión, consultas
decisiones
herramientas
de análisis
Datos Reportes, Reportes Gerencia

transaccionales modelamiento dinámicos funcional,
Sistema de resumidos, simple, análisis y estáticos, gerencia Sistema de análisis
información datos de alto de bajo nivel, reportes de media, financiero y
gerencial (SIG) volumen, análisis “que pasa resumen, mandos presupuestario
modelos si”, análisis de reportes de medios,
simples sensibilidad excepción. supervisión
Sistema de Reportes de- Personal

Eventos opera- Ordenamiento, Módulo de conta-
procesamiento tallados, listas, operativo,
tivos, transac- validación, fusión, bilidad general de
de transaccio- resúmenes superviso-
ciones actualización un sistema ERP
nes (TPS) operativos res
Fuente: Aranibar (2013)
Estos sistemas, por lo general, están relacionados entre sí.
11
2.1. Arquitectura para inteligencia de negocios
La inteligencia de negocios, más que un producto o aplicativo, es un concepto a partir del cual se
pueden crear un conjunto de soluciones, que permiten obtener de los datos de la operación del
negocio, así como información y conocimiento para la toma de decisiones. Para esto se hace uso
de herramientas tecnológicas que facilitan el aprovechamiento de este concepto en la creación de
valor. Entre las herramientas que permiten apoyar la aplicación de inteligencia de negocios en la
organización tenemos las siguientes (Aranibar, 2013):
• Repositorios de información o bases de datos
• Análisis multidimensional
• Minería de datos
• Consultas y reportes complejos
• Visualización.
La representación de estas herramientas se puede observar en la Figura 5.
Figura 5. Arquitectura de inteligencia de negocios. Modificado de Aranibar (2013)

12
En la Figura 5 se puede observar cómo en los sistemas transaccionales se encuentran todos los
registros y repositorios de información, tales como sistemas de planeación de recursos empresariales
(ERP), administración de la relación con el cliente (CRM), hojas electrónicas, archivos planos o datos
almacenados en los sistemas de gestión de bases de datos (DBMS.
A partir de la extracción, transformación y carga (ETL) (Kimball & Ross, 2013), se da un proceso de
selección, filtrado, resumen o sumarización de datos, del cual se obtienen el Data Warehouses (DW,
almacenes de datos), Data Marts (DM, almacenes de datos pero para áreas de negocio) o almacenes
operacionales de datos (ODS). Estos integran los sistemas de procesamiento de transacciones en
línea (OLTP) de diferentes fuentes en sistemas de procesamiento analítico en línea (OLAP), ya sean
soportados por cubos multidimensionales a través de sistemas de procesamiento analítico en línea
multidimensionales (MOLAP) o en sistemas de procesamiento analítico en línea relacional (ROLAP)
—que son similares, pero soportados sobre bases de datos relacionales—.
Por último, los usuarios tendrán acceso a interfaces de sistemas gerenciales, tales como sistemas de
soporte Ejecutivo (ESS / EIS), sistemas de soporte de decisiones (DSS), sistemas de información gerencial
(SIG) o sistemas de procesamiento de transacciones (TPS), que ya fue explicado en la Tabla 1.
2.2. Bases de datos e Inteligencia de Negocios
En principio, una base de datos es una colección de datos organizados de tal forma que el usuario
pueda acceder a la información cuando necesite de esta. Puede estar soportada en una libreta, una
hoja de Excel o en un complejo sistema de administración de bases de datos. No obstante, para
efectos de la intención de esta lectura fundamental, hablamos de bases de datos para referirnos a las
soportadas sobre sistemas de administración de bases de datos.
En general, se pueden encontrar dos tipos de bases de datos, según su aplicación, involucradas en los
sistemas de inteligencia de negocios (Aranibar, 2013):
• Bases de datos transaccionales
• Bases de datos gerenciales
De acuerdo con Aranibar, se pueden señalar las diferencias de estos dos tipos de bases de datos en la
Tabla 2.
13
Tabla 2. Comparación entre bases de datos transaccionales y gerenciales
Función Bases de datos transaccionales Bases de datos gerenciales
Históricos y resumidos según

Datos Actuales
puntos del tiempo
No estructurado y analítico
Uso Estructurado y repetitivo (día a día)
(eventual)
Alto a pequeñas cantidades de Moderado a bajo, a grandes
Acceso
información cantidades de información
Extracción transformación
Altas, bajas, modificaciones y
Operación y carga (ETL), con base en
consultas simples
consultas complejas
Procesamiento transaccional en Procesamiento analítico en
Procesamiento línea (OLTP, OnLine Transactional línea (OLAP, OnLine Analytical
Procesing) Procesing)
Estáticos e incrementales
Naturaleza de los datos Dinámicos mediante procesos de
actualización
Retención A requerimiento Indeterminada e histórica
Disponibilidad Alta, crítica Discreta, no crítica
Volumen de datos Según el volumen de transacciones Mayor volumen de transacciones
Por dimensiones (múltiples áreas
Organización Por funciones (un área a la vez)
a la vez)
Compleja de alto rendimiento y Simple de moderado rendimiento
Estructura de datos
flexibilidad limitada (normalizado) y alta flexibilidad (desnormalizada)
En función a validación de entradas En función de extracción,
Calidad y confiabilidad
y procesos transformación y carga (ETL)
Tradicionalmente, cuando nos referimos a bases de datos transaccionales, se hace con respecto a aquellas
que registran la información de la operación normal de la empresa, las cuales evitan redundancias y
permiten trabajar sobre ella en tiempo real. Por otro lado, cuando la base de datos está orientada a la toma
de decisiones, principalmente a decisiones semiestructuradas y no estructuradas, dentro de esquemas
como un Data Warehouse o un Data Mart, se refiere a una base de datos gerenciales.
14
Los Data Warehouse en los que se soportan las bases de datos gerenciales, se caracterizan por (Aranibar,
2013):
• Ser repositorios integrados, normalmente a partir de varias fuentes operacionales de datos, tanto
internas como externas a la organización.
• Son orientados al sujeto, es decir, se centran en información que pueda ser considerada relevante
sobre las actividades básicas de la empresa.
• Son variantes en el tiempo, es decir, la captura de información está en función de la necesidad de

generar reportes.
• No es volátil, pues la información que se almacena no debe ser modificada. En ocasiones, por razones
técnicas surge la necesidad de eliminar datos después de cumplido determinado plazo; pero, esto
hace que pueda perderse información histórica.
Por otro lado, mientras en las bases de datos transaccionales se busca eliminar las redundancias, pues
resultan indeseables para el adecuado funcionamiento del sistema; en las bases de datos gerenciales lo que
se busca es generar reportes. Aquí evitar la redundancia pasa a un segundo plano, ya que es más importante
que la información sea adecuada para trabajar de forma analítica, lo cual permitiría redundancias.
2.3. Paradigmas de Data Warehouse
El término Data Warehouse (Turban, Volonio & Wood, 2013) se utiliza para hacer referencia a un almacén
de datos que corresponde a una base empresarial. Esta integra y depura información de una o más fuentes
distintas, para luego procesarla y permitir su análisis desde muchas de perspectivas, con buenas velocidades
de respuesta. Un Data Warehouse es una respuesta a la necesidad de consolidar la información para la
inteligencia de negocios. Por otro lado, un Data Mart es un almacén de datos más especializado, el cual está
relacionado normalmente con fines departamentales o sectoriales.
En general, existen dos corrientes en el desarrollo teórico de Data Warehouse: una basada en la teoría de
Inmon (2002) y la otra en la teoría de Kimball (Kimball & Ross, 2013). Para Inmon, el Data Warehouse es una
parte del todo lo que conforma a un sistema de BI. Una empresa tiene un Data Warehouse y los Data Marts
tienen como fuente de información este primero en una aproximación To-Down (Figura 6).
15
Data mart 1
Data mart 2
Data mart 3
Datawarehouse
Figura 6. Arquitectura Inmon. Modificado de Bernabeu (2009)

Para Kimball y Ross (2013), el Data Warehouse se compone por un conglomerado de todos los Data
Mart generados por la empresa. La información siempre se almacena en un modelo dimensional en
una configuración Botton-Up (Figura 7).
Data mart 1
Datawarehouse
Data mart 2
Data mart 3
Figura 7. Arquitectura Kimball. Modificado de Bernabeu (2009)

16
Por otro lado, se pueden encontrar otras arquitecturas tales como:
• Híbrida, que integra los beneficios de las arquitecturas Inmon y Kimball de tal forma que
coexistan.
• Federada, la cual está distribuida de tal forma que permite cambios permanentes, de acuerdo
con las exigencias de los usuarios.
Si bien existen diferencias entre las arquitecturas, también tienen mucho en común. En general, toda
organización necesita almacenar sus datos y analizar e interpretar sus recursos con el fin de tomar
decisiones críticas o estratégicas. La Tabla 3 muestra una comparación entre arquitecturas.
Tabla 3. Comparación entre arquitecturas Data Warehouse
Enfoque Top-Down Botton-Up Híbrido Federado

• Aplica una • Se implementa • Permite una
vista macro gradualmente personalización
empresarial. reduciendo más sencilla
costos. de interfaces • No necesita
• Se centra en
la consistencia • Fácil de y reportes de ETL
de diseño y en construir usuario.
• No necesita
Pros la calidad de a nivel • Soluciona una plataforma
los datos. organizacional requerimientos separada
• Aplica • Fácil de empresariales
reusabilidad de construir y funcionales a
datos. técnicamente la vez
17
Enfoque Top-Down Botton-Up Híbrido Federado
• No existe una • La vista
• Requiere
vista global de empresarial es
liderazgo un reto. • Aplicable
la organización
ejecutivo y a bajos
visión. • Existen costos • Altos costos
volúmenes de
de redundancia operativos y
• Consume datos
de datos de gestión de
muchos bases de datos • Pueden existir
Contras recursos en un
solo proyecto.
• Altos costos
operativos, • Existen costos
barreras de
infraestructura
de ETL, de redundancia
• Requiere de red y
aplicaciones, de datos
plataformas aplicaciones al
administración • Demora cliente
integralmente
de bases de relativa de
depuradas.
datos datos
Proponente Inmon Ralph Kimball Varios Doug Hackney

2.4. Modelos lógicos de bases de datos gerenciales
El modelo lógico de las bases de datos está soportado sobre las siguientes premisas (Aranibar, 2013):
• Deben preparar a las bases de datos para soportar la recuperación de una gran cantidad de filas
de datos en forma rápida.
• Deben definir los cálculos a ser almacenados, de forma que se optimice la atención de consultas
recurrentes.
• Debe establecer un nivel de detalle que satisfaga las consultas necesarias por usuarios o analistas.
• Debe estar en función del acceso y uso de la información, en otras palabras, en función en la
frecuencia y velocidad de los reportes.
18
• Debe reconsiderar la normalización de tablas que afecte la interpretación intuitiva de usuarios no
técnicos.
• Los datos provienen de fuentes transaccionales
Para lo anterior, se tendrán en cuenta los conceptos que se describen a continuación.
2.4.1. Tablas de dimensiones
Son datos organizados lógicamente y que suministran información sobre el contexto del negocio.
Contienen datos cualitativos, como ubicación, productos, clientes y fechas. Es importante resaltar
que en las tablas de dimensiones es obligatoria una tabla de dimensión tiempo. Asimismo, estas tablas
tienen una llave primaria.
2.4.2. Tablas de hechos
Estas tablas contienen precisamente los hechos que se analizarán del negocio, para apoyar la toma
de decisiones. Estas contienen datos cuantitativos y tienen llaves primarias compuestas por las llaves
primarias de las tablas de dimensiones (Figura 8).
CLIENTE FECHAS
id_Cliente 1 VENTAS
NombreCliente id_Cliente 1 id_Fecha
n id_Producto Año
n id_Fecha Trimestral
PRDUCTO n Mes
ImporteTotal
id_Producto 1 Día
Utilidad
Rubro
Tipo
NombreProducto
Figura 8. Tablas de hechos y de dimensiones. Modificado de Bernabeu (2009).

19
Así mismo, existen dos tipos de hechos: básicos y derivados.
• Hechos básicos: están representados en una tabla de hechos.
• Hechos derivados: son el resultado de cálculos.
Las tablas de hechos pueden ser agregadas y preagregadas. Así:
• Tablas agregadas: se generan luego de que se procesa la consulta.
• Tabla preagregadas: se generan antes de que se procese la consulta en los procesos ETL.
2.4.3 Cubos multidimensionales
La estructura de datos en la cual se consolida la información en un Data Warehouse se denomina cubo

multidimensional (Figura 9).
Dimensión 1
Hechos
DIM 1 3
n
s ió
DIM 3
en
Dimensión 2 Di
m
DIM 2
Figura 9. Hechos y dimensiones de un cubo multidimensional. Modificado de Aranibar (2013).

Básicamente, un cubo multidimensional convierte tablas de datos planos de dos dimensiones en

una estructura más compleja de n dimensiones. Los cubos comprenden una serie de características
(Figura 10) que vale la pena referenciar:
• Indicadores: son sumatorias sobre algún hecho.
• Atributos: corresponden a campos o criterios de análisis.
• Jerarquías: constituyen una relación lógica entre atributos.
20
Indicador 1= (atributo 1, valor 5;
Atributo 2, valor 4;
atributo 3, valor 3)
Atributo 1
1ra dimensión)
5
2
Atributo 3
(3da dimensión)
1 3
2
1
1 2 34 Atributo 2
(2da dimensión)
Figura 10. Representación de un cubo multidimensional. Modificado de Bernabeu (2009).

2.4.4 Tipos de modelos lógicos de un Data Warehouse
De acuerdo con Aranibar (2013), se han planteado tres modelos lógicos:
• Esquema estrella
• Esquema copo de nieve
• Esquema constelación.
El esquema estrella tiene una única tabla de hechos central y varias tablas de dimensiones que se
relacionan de forma directa con ella (Figura 11).
21
Dimensión 1 Dimensión 2
id_dimensión1
1 id_Dimensión2
Campo1
Campo2
HECHOS 1 Campo1
n id_Dimensión1 Campo2
campoN
n id_Dimensión2 CampoN
n
id_Dimensión3
Dimensión 3 1 Dimensión 4
id_Dmiensión4 n
id_Dimensión3 Hecho1 id_Dimensión4
Campo1 Hecho2 1 Campo1
Campo2 HechoN Campo2
CampoN CampoN
Figura 11. Modelo lógico en estrella. Modificado de Bernabeu (2009).

En este modelo se desmota la normalización en su totalidad. Por esa razón, las tablas de dimensiones
se vinculan directamente a la tabla de hechos. Esto hace que tenga los mejores tiempos de respuesta,
sea fácil de modificar, fácil de operar y de analizar, y facilita el uso de herramientas de análisis
(Bernabeu, 2009).
Por su parte, en el esquema copo de nieve, a diferencia del de estrella, existen jerarquías en las
dimensiones y existe una tabla de hechos vinculada a tablas de dimensiones que, a su vez, están
relacionadas con otras tablas de dimensiones (Figura 12).
Dimensión 1 Dimensión 2 Dimensión2a

id_dimensión1 id_Dimensión2 1 id_Dimensión2a
1
id_Dimensión2a Campo1
Campo1 HECHOS 1
n Campo2
Campo2 n id_Dimensión1 Campo1
campoN Campo2 CampoN
n id_Dimensión2
n CampoN
id_Dimensión3
Dimensión3a 1
Dimensión 3 1
id_Dimensión3 id_Dmiensión4 n
id_Dimensión3a
Hecho1
Dimensión 4
id_Dimensión3a
Campo1 n 1 id_Dimensión4
Campo1 Hecho2
Campo2 Campo1
Campo2 HechoN
CampoN Campo2
CampoN
CampoN
Figura 12. Modelo lógico en copo de nieve. Modificado de Bernabeu (2009).

22
Entre las ventajas de este esquema está que aprovecha mejor el espacio, es útil cuando hay tablas de
muchas tuplas, está normalizada (por lo que el diseño es más sencillo) y utiliza jerarquías. Sin embargo,
aumenta la complejidad y reduce el desempeño.
Finalmente, el esquema constelación tiene más de una tabla de hechos, a partir de la cual se
establecen vínculos con tablas de dimensiones al estilo estrella (Figura 13).
Dimensión 1 Dimensión 2
id_Dimensión2
id_dimensión1 1 HECHOS_A id_Dimensión2a
Campo1 1 Campo1
Campo2 n id_Dimensión1
Campo2
campoN id_Dimensión2
n CampoN
Dimensión 3 id_Dimensión3
id_Dimensión3 1 n id_Dmiensión4 HECHOS_B
Campo1 Hecho1 n
id_Dimensión2
Campo2 n Hecho2
id_Dimensión5
CampoN HechoN Hecho1 n
Hecho2 1 Dimensión 5
Dimensión3 HechoN
id_Dimensión5
1
id_ Dimensión3 Campo1
Campo1 Campo2
Campo2 CampoN
CampoN
Figura 13. Modelo lógico en constelación. Modificado de Bernabeu (2009).

Al tener más de una tabla de hachos, permite analizar más aspectos clave del negocio y permite la
reutilización de tablas. No lo soportan todas las herramientas.
2.5. Extracción, transformación y carga
Un procesamiento de transacciones en línea (OLTP) consiste en la información transaccional de la

empresa en su operar cotidiano y proviene de diversas fuentes, tales como:
• Bases de datos transaccionales
• Archivos de textos
• Hojas de cálculo
• Informes
• Hipertextos
23
Con base en lo anterior, es necesario establecer un sistema para tomar la información de las fuentes
y llevarlas al Data Warehouse. Esto se realiza a través de un proceso de extracción, transformación y
carga (Figura 14) (Bernabeu, 2009).
2.5.1. Extracción
En muchas ocasiones la extracción se reduce a la realización de consultas en SQL. No obstante,

cuando las fuentes de información no están en un SGBD, el proceso suele ser más difícil y es
probable que se requieran herramientas específicas. Una vez los datos son seleccionados y extraídos,
se almacenan en un repositorio intermedio. En la mayoría de las ocasiones, ese repositorio consiste en
una base de datos.
2.5.2. Transformación
La idea es convertir los datos inconsistentes en un conjunto de datos coherentes, para que puedan
ser cargados en un Data Warehouse. En esta función también se llevan a cabo actividades como las
siguientes:
• Unificar la codificación.
• Unificar medida de atributos.
• Unificar convenciones de nombramiento.
• Consolidación de fuentes múltiples.
• Realizar limpieza de datos.
2.5.3. Carga
Esta función se ocupa de:
• Hacer la carga inicial de datos en el Data Warehouse.
• Realizar actualizaciones o mantenimiento del Data Warehouse.
24
A través de acciones tales como (Bernabeu, 2009):
• Cotejar instancias de los OLTP involucrados.
• Utilizar disparadores en los OLTP.
• Recurrir a marcas de tiempo (Time Stamp) en los registros de los OLTP.
• Comparar los datos existentes en los dos ambientes (OLTP y DW).
• Usar técnicas mixtas.
Extracción
Carga
Transformación
Figura 14. Modelo lógico en constelación. Modificado de Bernabeu (2009).

2.6. Análisis multidimensional
Como se señaló en los apartados anteriores, un Data Warehouse no permite tener acceso
a información que muestre el comportamiento de un hecho, desde la perspectiva de varias
dimensiones. También es importante mencionar que mientras tenemos dos dimensiones, la
información normalmente se procesa en tablas; pero al querer determinar el comportamiento de un
hecho desde varias dimensiones de forma simultánea, estamos tratando de determinar cómo se da
este frente a múltiples variables. Lo anterior nos permite un análisis multidimensional.
Cuando se trabaja con tres dimensiones o más, estamos hablando de un hipercubo, difícil de abstraer
mentalmente; que, sin embargo, es posible representar con cierta dificultad en dos dimensiones
(Figuras 15 y 16).
25
Bidimensional
Bidimensional multiple o Tridimensionalidad en
tridimensional plano
Figura 15. Representación de un hipercubo en un plano. Modificado de Aranibar (2013)

Figura 16. Ejemplo de representación de un hipercubo en un plano

26
Así mismo, también se puede representar el hipercubo viéndolo por capas (Figura 17).
Dimensiones páginas
(filtros) Dimensiones columna
(vertical)
Dimensiones fila
(horizontal) Hechos
Figura 17. Formato genérico de un hipercubo. Modificado de Aranibar (2013)

Es posible observar cómo las tablas dinámicas de Excel se comportan como una herramienta de
análisis multidimensional, que es aplicable a la inteligencia de negocios.
2.6.1 Operaciones de análisis multidimensional
Existen algunas operaciones que pueden aplicarse al análisis multidimensional. A saber:
• Expandir: en la visualización se puede mostrar el contenido del cubo de forma expandida.
• Abstraer o colapsar: genera resúmenes de la información.
• Detallar o asociar: la información de un cubo se sustenta con la de otro cubo.
• Rotar: intercambia dimensiones para tener otra visualización.
• Anidar o jerarquizar: incluye dimensiones de mayor detalle de forma anidada.
• Rebanar: fija valores para obtener celdas, planos, segmentos o subcubos. Permite alto grado de
análisis.
• Pivotear: si bien la rotación y anidación son operaciones de pivoteo, esta consiste

específicamente en la ubicación de dimensiones como filtros para rebanarlas (Figura 18).
27
Región por
tiempo
Tiempo Tiempo
Tiempo Producto
por tiempo
Producto
Producto
Producto
Región Región Región
Figura 18. Rebanadas de un cubo tridimensional. Modificado de Aranibar (2013).
En la Figura 19 podemos ver algunos resultados de operaciones.
Plano Selda
Subcubo Segmento
Figura 19. Resultados de operaciones. Modificada de Aranibar (2013).

2.6.2. Procesamiento analítico
Puede pensarse que el análisis multidimensional requiere de aplicaciones costosas y complejas. Sin
embargo, herramientas como Excel ya ofrecen recursos para el análisis multidimensional de datos,
a través del aprovechamiento de las tablas dinámicas. En general existen varias tecnologías de
procesamiento analítico:
• Procesamiento analítico en línea (OLAP, On-Line Analytical Processing): es la denominación

genérica de la tecnología, que se encarga de volver operativo el análisis multidimensional.
Este tiene básicamente enfoques orientados a la implementación, con modelos relacionales,
multidimensionales o híbridos (BidWBooks, s.f.).
28
• Procesamiento analítico multidimensional en línea (MOLAP, Multidimensional On-Line
Analytical Processing): en este enfoque, los datos se almacenan en cubos indexados basados en
dimensiones.
• Procesamiento analítico relacional en línea (ROLAP, Relational On-Line Analytical Processing):

utiliza fuentes de bases de datos relacionales tradicionales, organizados en modelos tabulares
tipo estrella o copo de nieve.
• Procesamiento analítico híbrido en línea (HOLAP, Hybrid Online Analytical Process): los datos
utilizan almacenamiento multidimensional y relacional a la vez. En la actualidad, la mayoría de los
productos OLAP son híbridos.
29
Referencias
Aranibar, J. (2013). Sistemas de Información Gerencial para la administración del desempeño
empresarial, La convergencia entre Business Intelligence y Balanced Scorecard. La Paz: Holding.
Bernabeu, D. (2009). Data Mart. (Data Prix). Recuperado el 30 de septiembre de 2017 de http://
www.dataprix.com/data-warehousing-y-metodologia-hefesto/i-data- warehousing-investigacion-y-
sistematizacion-concepto-13
BidWBooks (Ed.). (s.f.). Data Warehousing. Recuperado el 15 de septiembre de 2017 de http://www.

bidwbooks.com/bill-inmon-vs-ralph-kimball/
Hitt, M., Ireland, D. & Hoskisson, R. (2004). Administración Estratégica (5.a ed.). (P. De la Garza,
Ed.). México: Thompson.
Inmon, W. (2002). Building the data warehouse. John Wiley and Sons.
Kimball, R. & Ross, M. (2013). The Data Warehouse Tollkit (3.a ed.). Indianapolis, United States of
America: Wiley.
Laudon, K. & Laudon, J. (2012). Sistemas de Información Gerencial. (L. Cruz Castillo, Ed.) Naucalpan
de Juárez, México: Pearson.
Laudon, K. & Carol, G. (2014). E-Commerce, Negocios, Tecnología, Sociedad (9.a ed.). (L. Cruz
Castillo, Ed.). México: Pearson Prentice Hall.
Turban, E., Aronson, J. & Peng Liang, T. (2005). Decision Support Systems and Intelligent Systems (7.a
ed.). (B. Horan, Ed.) New Jersey: Pearson Prentice Hall.
Turban, E., Volonio, L. & Wood, G. (2013). Information Technology for Management (9.a ed.). (B. Lang,
Ed.) United States of America.
Castillo, R., Morata, J. & Del Árbol, L. (s.f.). Operational Data Store (ODS). Recuperado de http://
www.lsi.us.es/redmidas/CEDI/papers/933.pdf
Education.
Addison Wesley.
Referencias de imágenes y tablas

Bernabeu, D. (2009). Data Mart. (Data Prix). Recuperado el 30 de septiembre de 2017 de http://
www.dataprix.com/data-warehousing-y-metodologia-hefesto/i-data- warehousing-investigacion-y-
sistematizacion-concepto-13
Laudon, K. & Laudon, J. (2012). Sistemas de Información Gerencial. (L. Cruz Castillo, Ed.) Naucalpan
de Juárez, México: Pearson.

Unidad 4: Arquitectura de bases de datos
Escenario 7: Bases de datos e inteligencia de negocios


Módulo Teórico-Práctico
Actividad en contexto
Módulo
Fundamentos de bases de datos
Nombre de la entrega
Diseño de bases de datos 2
Nivel académico
Especialización
Tipo de entrega
Actividad aplicada
Nota
Tenga en cuenta que el tutor le indicará qué herramienta requiere y qué
estrategia deberá desarrollar para evidenciar su participación individual
en un trabajo colaborativo.
DESCRIPCIÓN
DE LA ACTIVIDAD
Aplicar las fases del diseño de bases de datos en la resolución del siguiente caso aplicando los
conceptos del escenario.
CASO O PROBLEMA
Usted es contratado para construir una base de datos para la administración de

un taller mecánico.
La base de datos incluirá información acerca de los clientes, los autos, los empleados que
trabajan en taller y los repuestos utilizados en cada servicio.
22
La base de datos debe:
• Registrar el cliente y auto de cada servicio.

• Del cliente se registra la cédula, nombres y apellidos, teléfono, dirección.
• Del auto se registra la placa, el modelo, el color, fecha y hora de ingreso.
• A cada servicio se asigna un empleado disponible.
• El empleado a cargo del servicio registrará los repuestos con su referencia, descripción,
marca y precio al igual que las horas empleadas en el servicio.
• Con base en el precio de los repuestos, el número de horas empleadas y la utilidad
estimada se crea una factura que además incluye un IVA del 19%.
PLANTEAMIENTO
DE LA ACTIVIDAD
Establezca y escriba funciones, procedimientos, cursores y triggers pertinentes para el

caso propuesto.
Además indique como puede asegurar las propiedades ACID.
33
Unidad 14 // Escenario 8
2
fundamental
Lectura Fundamental
Metodología
Etapas de unpara la de
plan implementación
comunicación de
un sistema de inteligencia de negocios
estratégica
Contenido
1 Metodología para la implementación de un sistema de inteligencia de negocios
2 Gestión empresarial e inteligencia de negocios
Palabras clave: inteligencia de negocios, minería de datos.

1. Metodología para la implementación de un sistema de inteligencia
de negocios
Kimball y Ross (2013) plantean una metodología para la construcción de un Data warehouse, en lo
que se denomina el ciclo de vida dimensional del negocio (Business Dimensional Lifecycle). Este está
basado en cuatro principios básicos (Kimball & Ross, 2013):
1. Centrarse en el negocio
2. Construir una infraestructura de información adecuada
3. Realizar entregas en incrementos significativos
4. Ofrecer una solución completa
Las tareas de la metodología del ciclo de vida se representan en la Figura 1.
A continuación, se describirá con más detalle cada una de las etapas (Kimball & Ross, 2013):
Figura 1. Ciclo de vida dimensional del negocio. Modificado de Kimball & Ross (2013)
1.1. Planificación del proyecto
En esta primera etapa se determina el propósito del proyecto de inteligencia de negocios, los
objetivos y el alcance. Incluye tareas como las que se describen a continuación:
• Definir el alcance
• Establecer tareas
• Programar tareas
• Planificar recursos
• Asignar carga de trabajo a los recursos
• Elaborar el plan del proyecto
1.1.1. Definición de requerimientos del negocio
Esta definición implica tener entrevistas con el personal del negocio, al igual que con el personal
técnico involucrado. Existen diversos tipos de requerimientos; entre estos tenemos los siguientes:
1.1.2. Requerimientos de negocio
Los requerimientos de negocio consisten en aquellos que son resultado de las prácticas del negocio
actual. Existen diversas técnicas para obtener estos requerimientos; entre ellas tenemos:
• Descomposición funcional de procesos
• Casos de uso
• BPM
1.1.3. Requerimientos de usuario
Corresponden a los requerimientos que hacen uso del sistema y deben ser establecidos en trabajo
conjunto con estos.
1.1.4. Requerimientos del sistema
En este caso se hace referencia a los requerimientos funcionales y no funcionales:
• Requerimientos funcionales: estos requerimientos describen lo que el sistema debe hacer.

Hacen referencia a funciones concretas que debe hacer la aplicación.
• Requerimientos no funcionales: estos requerimientos se refieren a propiedades del sistema

y se caracterizan porque requieren de la existencia de los requerimientos funcionales; en
se estos pueden indicar restricciones y estándares de calidad. La Figura 2 muestra algunos
requerimientos no funcionales.
1.2. Diseño lógico
En este diseño se lleva a cabo el modelado dimensional, en el cual se elige el área a modelizar, se
establece el nivel de granularidad (detalle) y se seleccionan las dimensiones, medidas y tablas de
hechos (lo anterior de acuerdo con lo visto en el escenario 7).
Producto
Funcionalidad
Requerimientos Lo que el Requerimientos Fiabilidad
funcionales sistema hace no funcionales Usabilidad
Eficiencia
Mantenibilidad
Portabilidad
Organizacionales
De entrega
De implementación
Requerimientos de
estándares
Externos
Seguridad
Éticos
Interoperabilidad
Figura 2. Requerimientos funcionales o no funcionales

1.3. Diseño físico
En este diseño se establece lo siguiente:
• El tamaño de la solución de inteligencia de negocios
• Los factores de configuración
• El Hardware
• La instalación, desarrollo, prueba y producción
• La manera cómo llevar el modelo lógico a físico
• Las bases de datos, aplicaciones, cubos, etc.
1.4. Diseño e implementación del subsistema de ETL
Es el diseño del sistema que soporta el Data Warehouse y se define por:
• Cómo se extraen los datos del origen de estos.
• Cómo se consolida la información proveniente de distintos sistemas.
• La carga de la información en el Data Warehouse.
1.5. Implementación
Esta corresponde a la etapa en la que se materializa la solución. Implica la integración de los datos,
los sistemas y los usuarios, así como la puesta en marcha del sistema y la realización de las pruebas y
actividades necesarias para que este funcione adecuadamente.
1.6. Mantenimiento y crecimiento
Aquí se tiene en cuenta la perspectiva de los usuarios y se establecen canales de retroalimentación,

para dar mantenimiento y crecimiento.
1.7. Especificación de aplicaciones BI
En esta se establecen los informes estándar y las aplicaciones analíticas que produce el sistema.
1.8. Diseño de la arquitectura técnica
Acá se define la arquitectura, tanto del Back end como del Front end; es decir, de la arquitectura
desde la preparación de los datos, hasta la forma en que se entregan los datos al usuario.
1.9. Gestión del proyecto
Es una actividad transversal a todo el proyecto que busca asegurar que este cumpla con sus objetivos
y que termine exitosamente.
2. Gestión empresarial e inteligencia de negocios

Según Kaplan —Cuadro de Mando Integral— (2004), “(...) la capacidad de ejecutar una estrategia es más
importante que la calidad de la estrategia en sí.” En otras palabras, muchas veces no es la estrategia la que
está mal, sino su aplicación. Para que esto se pueda llevar a cabo, Kaplan define algunos principios en las
organizaciones basadas en la estrategia, los cuales presentamos a continuación:
1. Traducir la estrategia en términos operativos: esto es posible a través de mapas estratégicos y el

cuadro de mando integral.
2. Alinear la organización con la estrategia: esta acción evidencia el papel de la empresa y las
sinergias entre las unidades de negocio y de los servicios compartidos.
3. Hacer que la estrategia sea el trabajo diario de todo el mundo: crea conciencia de la estrategia y
establece cuadros de mando personales y salarios con incentivos.
4. Hacer que la estrategia sea un proceso continuo: esto se lleva a cabo al vincular el presupuesto con la
estrategia, crear sistemas analíticos y de información, y establecer un aprendizaje estratégico.
5. Movilizar el cambio a través del liderazgo directivo: esto se logra a través de la movilización, un
proceso de gobernabilidad y un sistema de gestión estratégica.

Entre los problemas que tienen los gerentes en la toma de decisiones encontramos los siguientes:
• Una visión fraccionada de la organización
• Factores ocultos que deterioran el desempeño de la organización
• Prevalencia de la intuición sobre el control gerencial
• Acción correctiva en lugar de preventiva y oportuna
• Alineación con los objetivos estratégicos de la empresa
Partiendo de estas situaciones, se evidencia la necesidad del gerente para la adecuada toma de
decisiones sobre:
• Una visión holística de la organización; es decir, una decisión que afecta positivamente a un área
puede afectar de forma negativa el conjunto de la empresa.
• La identificación del comportamiento de los factores críticos de desempeño de acuerdo con la

estrategia de la empresa.
• Información y conocimiento objetivo, que permite mejorar la toma de decisiones y reducir el riesgo.
• Tener información oportuna sobre el desempeño de la organización en conjunto y en cada uno de sus
componentes, para evidenciar desviaciones con respecto a lo planificado y planeado.
• Mantener claro el rumbo de las acciones de acuerdo con los objetivos de la organización.

2.1. Indicadores clave de desempeño (KPI)
Los indicadores clave de desempeño (KPI, por sus siglas en inglés: Key Performance Indicator) corresponden
a las medidas de desempeño asociadas con procesos, los cuales son aplicables totalmente a la gestión de
proyectos. El indicador busca mostrar “cómo” ha sido el progreso en un aspecto concreto a evaluar. En las
empresas, estas mediciones suelen estar relacionadas con factores tales como compras, logística, ventas,
servicio al cliente, finanzas, etc. Normalmente, estos indicadores buscan estar asociados con el plan
estratégico del negocio.
Para tener un verdadero control gerencial es necesario establecer indicadores clave de desempeño.
La inteligencia de negocios utiliza un término para designar las métricas que permiten evidenciar
el comportamiento del desempeño y se denominan Indicadores Clave de Desempeño (Key
Performance Indicators – KPI). Un sistema de inteligencia de negocios puede manejar volúmenes
importantes de datos de diferentes fuentes. Según Rozner (2013), las características con las que
debe cumplir un KPI son, las siguientes:
• (S) específicos
• (M) medibles
• (A) alcanzables
• (R) relevantes
• (T) temporales
Sin embargo, no siempre los KPI del funcionamiento tradicional de una empresa se ajustan a las
necesidades de un proyecto.
2.1.1. KPI y proyectos
Muchas veces, para hacer seguimiento a los proyectos, los KPI no son los más adecuados; en especial
porque en el funcionamiento tradicional de la empresa lo que ocurre al final del proceso tiene un
efecto de retroalimentación o mejoramiento continuo. Recordemos que en el funcionamiento de una
empresa, las actividades son continuas y repetitivas. En cambio, en un proyecto las actividades que
se realizan son necesarias para la consecución de los objetivos y, una vez alcanzados, el proyecto ha
concluido de forma definitiva.
Así, los indicadores que son útiles para el desempeño normal de una empresa, no necesariamente lo son
para el desempeño de un proyecto. En especial, porque cuando se obtienen ya no hay nada que hacer, ni
generan ningún beneficio.
Por otro lado, lo planeado en un proyecto no siempre se ajusta a lo que se ejecuta, lo cual hace que ciertos
KPI pierdan vigencia en la medida que se dan cambios. En tercer lugar, el mismo KPI puede afectar el
desempeño del proyecto en la medida que el proyectista puede tratar de ajustar sus metas al cumplimiento
de los KPI, en lugar de ajustarlos al cumplimiento de los objetivos del proyecto. En la medida que se dan
desviaciones, las decisiones se pueden ver afectadas por los mismos KPI.
2.1.2. Elección de KPI correctos para proyectos
De acuerdo con la experiencia, podemos decir que los KPI deben cumplir con algunas características:
• Deben basarse en información veraz, vigente y disponible.
• Deben permitir que se realicen acciones correctivas en el curso de las actividades y no esperar a
que termine el proyecto.
• Deben estar sujetos a los objetivos del proyecto y a la estrategia de la organización involucrada.
• Deben tener en cuenta los riesgos y los costos, al igual que el flujo de caja.
• Si afectan el desempeño del proyecto, deben hacerlo de forma positiva para ajustarse a los
objetivos del mismo y de la organización.
• Deben involucrar al equipo de trabajo.
• Deben permitir ser comunicados a los interesados.
2.2. Cuadro de mando integral (BSC, Balanced Scorecard)
A principios de los años 90, Robert Kaplan y David Norton desarrollaron lo que se denomina el
cuadro de mando integral o Balanced Scorecard en la Escuela de Negocios de Harvard. La ventaja
que ofrece este cuadro de mando es que ofrece una visión integral de la organización y de su
desempeño, desde cuatro perspectivas (Kaplan & Norton, 2004). A saber:
• Perspectiva financiera: si tenemos éxito, ¿cómo atendemos los intereses de los accionistas?
• Perspectiva del cliente: ¿cómo debemos atender a nuestros clientes?
• Perspectiva operativa o del proceso interno: ¿cómo podemos ser excelentes en los procesos?
• Perspectiva de aprendizaje: ¿en qué y cómo nuestra organización debe seguir aprendiendo,
mejorando y creando valor?
En algunas ocasiones, la perspectiva de aprendizaje se extiende a la gestión del recurso humano o la

comprende. Para desarrollar el cuadro de mando integral, primero se deben identificar los objetivos
estratégicos del negocio en cada una de las cuatro perspectivas; y se definen indicadores y metas para
cada objetivo.
El paso siguiente es establecer las relaciones e influencias de los objetivos entre sí, en lo que se
denomina un mapa estratégico. Esto permite evidenciar cómo al afectar un objetivo (medido a través
de un KPI correspondiente) se afectan los objetivos estratégicos de la empresa. Para concluir, se
pueden establecer tableros de comando y visualización de indicadores.
Finalmente, los tableros de control o tableros de comando permiten identificar, de forma resumida,
gráfica y sencilla, el comportamiento de los indicadores de la compañía. Con estos se pueden
establecer semáforos que permitan determinar el grado de cumplimiento de una meta relacionada
con un objetivo organizacional. Esto facilita la toma de decisiones y, por consiguiente, aporta valor
a la organización.
Referencias
Kaplan, R. & Norton, D. (2004). Cuadro de Mando Integral. Bogotá: Editorial Planeta Colombiana S.A.
Kimball, R. & Ross, M. (2013). The Data Warehouse Tollkit (3.a ed.). Indianapolis, United States of
America: Wiley.
Rozner, S. (2013). Developing Key Performance Indicators, A toolkit for Health Sector Managers.
Bethesda, MD: Health Finance & Governance Project, Abt Associates Inc.
Inmon, W. (2002). Building the data warehouse. John Wiley and Sons.
Referencias de imágenes
Kimball, R., & Ross, M. (2013). The Data Warehouse Tollkit (3.a ed.). Indianapolis, United States of
America: Wiley.

Unidad 4: Arquitectura de bases de datos
Escenario 8: Implementación de un sistema de inteligencia
de negocios



Fundamentos de Analisis de Datos

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Fundamentos de Analisis de Datos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fundamentos de Analisis de Datos

Cargado por

Copyright:

Formatos disponibles

Unidad 1 / Escenario 1

1 Conceptos de las bases de datos

3 Arquitecturas de las bases de datos

4 Bases de datos NoSQL

1.1. Bases de datos

2. Es una colección de datos con algún tipo de significado coherente.

3. Se diseña, construye y registra datos para un propósito específico.

• Redundancia de datos: al registrar información en archivos, estos a veces incluyen campos

• Difícil acceso a datos: en especial, cuando se manejan volúmenes crecientes de

• Falta de atomicidad: cuando existan problemas en el almacenamiento de los datos es necesario

• Dificultades para acceso concurrente: si varios usuarios acceden simultáneamente a varios

• Dificultades en seguridad: el acceso a ciertos recursos de información o a operaciones entre

1.3. Sistemas de gestión de bases de datos (SGBD)

1.4. Sistemas de bases de datos

2.1. Categorías de los modelos de datos

En general, se reconocen tres categorías de modelos de datos:

2. Modelos de datos representativos o modelos de implementación, que no se distancian

2.1.1. Modelos conceptuales

Figura 2. Ejemplo de modelo entidad-relación

2.1.2. Modelos de datos representativos o de implementación

• Modelo de datos jerárquico

Figura 3. Ejemplo de modelo de datos jerárquico

• Modelo de datos de red

• Modelo de datos relacional

• Modelo de datos orientado a objetos

Figura 6. Ejemplo de modelo de datos de objetos

• Modelo de lenguaje de marcado extendido (XML eXended Markup Languaje)

Figura 7. Ejemplo de modelo de lenguaje de marcado extendido

3. Arquitecturas de las bases de datos

3.1. Nivel interno

3.3. Nivel externo

Figura 8. Arquitectura de tres niveles

• API “Interfaz de Programación de Aplicaciones” (Aplication Programming Interface) simple

• Finalmente consistente (no ácido)

Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: Pearson,

Object Data Management Group. (2017). ODMG Standard. Recuperado de http://www.odbms.org/

Tsangaris, M. y Klug, A. (1978). The ANSI/X3/SPARC DBMS Framework. AFIPS Press.

Módulo: Fundamentos de bases de datos

Unidad 1: Generalidades y conceptos de bases de datos

Escenario 1: Generalidades de las bases de datos

Autor: Luis Ernesto Leyva Camargo

Asesor Pedagógico: María del Pilar Rivera Acosta

Diseñador Gráfico: David Alfonso Rivera

Asistente: Jhon Edwar Vargas

Este material pertenece al Politécnico Grancolombiano.

Diseño de bases de datos

1 Diseño conceptual de bases de datos

2 Diseño lógico de la base de datos

3 Modelo físico de una base de datos

Figura 1. Ciclo de vida de un sistema de base de datos

En los siguientes apartados se explicará la forma en que se realizan estos diseños.}

1. Diseño conceptual de bases de datos

1.1. Diseño conceptual soportado sobre diagramas entidad-relación (ER)

Un modelo entidad-relación representa los datos en entidades, atributos y relaciones. A continuación,

Figura 2. Símbolo de entidad regular en el diagrama ER

Figura 3. Símbolo de entidad regular en el diagrama ER

1.1.2. Conjunto de entidades

estudiante = (id_alumno, apellidos, nombres, grado)

Figura 4. Símbolo de atributo en el diagrama ER