1.1.

1 Data WareHouse (DWH)

Es el gran almacén de datos que está estructurado para analizar la información, a diferente
nivel de detalle, de todos los procesos de negocios que tiene la organización. Es la Base de
Datos llamada estratégica o multidimensional. Una vez diseñadas mediante el ETL es
poblada o llenada a partir de las Bases de Datos operacionales. El diseño va orientado a
encontrar medidas (Por ejemplo: montos vendidos, montos cobrados, horas hombre
utilizadas, etc) y dimensiones (Clientes, Productos, Tiempo, Organización, Servicios, etc).

1.1.2 Data Marts

Constituyen una parte de un DWH. Si un DWH está formado por todos los procesos de la
organización, un Data Mart constituye un determinado proceso. Por ejemplo podríamos tener
un Data Mart para Finanzas, otro para Logística. Pueden ser preparados a partir de un DWH
o ser elaborados independientemente.
 1.1.3 Tipos de Sistemas de Información

Los Sistemas de Información que logran la automatización de procesos operativos dentro de

una organización, son llamados Sistemas Transaccionales, ya que su función primordial
consiste en procesar transacciones tales como pagos, cobros, pólizas, entradas, salidas.

Los Sistemas de Información que apoyan el proceso de toma de decisiones son:

 Los Sistemas de Soporte a la Toma de Decisiones.

 Sistemas para la Toma de Decisión de Grupo.
 Sistemas Expertos de Soporte a la Toma de Decisiones.
 Sistema de Información para Ejecutivos.
El tercer tipo de sistema, de acuerdo con su uso u objetivos que cumplen, es el de los Sistemas
Estratégicos, los cuales se desarrollan en las organizaciones con el fin de lograr ventajas
competitivas, a través del uso de la tecnología de información.

Sistemas Transaccionales. Sus principales características son:

- A través de éstos suelen lograrse ahorros significativos de mano de obra, debido a que
automatizan tareas operativas de la organización.

- Con frecuencia son el primer tipo de Sistemas de Información que se implanta en las
organizaciones. Se empieza apoyando las tareas a nivel operativo de la organización.

- Son intensivos en entrada y salid de información; sus cálculos y procesos suelen ser simples
y poco sofisticados.

- Tienen la propiedad de ser recolectores de información, es decir, a través de estos sistemas

se cargan las grandes bases de información para su explotación posterior.

- Son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles y
palpables.

Sistemas de Apoyo de las Decisiones. Las principales características de estos son:

- Suelen introducirse después de haber implantado los Sistemas Transaccionales más

relevantes de la empresa, ya que estos últimos constituyen su plataforma de información.

- La información que generan sirve de apoyo a los mandos intermedios y a la alta

administración en el proceso de toma de decisiones.

- Suelen ser intensivos en cálculos y escasos en entradas y salidas de información.

- No suelen ahorrar mano de obra. Debido a ello, la justificación económica para el desarrollo
de estos sistemas es difícil, ya que no se conocen los ingresos del proyecto de inversión.

- Suelen ser Sistemas de Información interactivos y amigables, con altos estándares de diseño
gráfico y visual, ya que están dirigidos al usuario final.

- Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de decisiones
no estructuradas que no suelen repetirse.

- Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participación
operativa de los analistas y programadores del área de informática.

Sistemas Estratégicos. Sus principales características son:

- Su función primordial no es apoyar la automatización de procesos operativos ni

proporcionar información para apoyar la toma de decisiones.

- Suelen desarrollarse “in house”, es decir, dentro de la organización, por lo tanto no pueden
adaptarse fácilmente a paquetes disponibles en el mercado.

- Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución

dentro de la organización. Se inicia con un proceso o función en particular y a partir de ahí
se van agregando nuevas funciones o procesos.

- Su función es lograr ventajas que los competidores no posean, tales como ventajas en costos
y servicios diferenciados con clientes y proveedores. En este contexto, los Sistema
Estratégicos son creadores de barreras de entrada al negocio.

- Apoyan el proceso de innovación de productos y proceso dentro de la empresa debido a que

buscan ventajas respecto a los competidores y una forma de hacerlo en innovando o creando
productos y procesos.En estos dos enlaces se explica de mejor manera los tipos y usos de los
sistema de información:

1.1.4 Variables de Medición

Son aquellas que representan la medición matemática de un aspecto de negocio. Se utilizan

para medir la productividad. Las pérdidas, las ganancias entre otros aspectos que nos pueden
definir un sin número de indicadores que le permitirá a un ejecutivo tomar decisiones
operativas o estratégicas.
1.1.5 Variables de Análisis

Son aquellas que se incluyen en el proceso estadístico y realizan estudios analíticos sobre las
variables de medición. Las variables de análisis se utilizan principalmente para realizar
estudios estadísticos como factores de riesgo como pre-valencia del producto en el mercado,
entre otras cosas.

Inteligencia de Negocios a Nivel Estratégico

La Inteligencia de Negocios a Nivel Estratégico permite que la alta dirección de las empresas pueda
analizar y monitorear tendencias, patrones, metas y objetivos estratégicos de la organización. Un
ejemplo de Inteligencia de Negocios a nivel estratégico lo constituye el Cuadro de Mando
Integral o Balanced Scorecard concepto introducido por Robert Kaplan y David Norton el cual
definen como:

"Un esquema de trabajo multidimensional para describir, implementar y administrar estrategia a

todo nivel dentro de una empresa, a través de la vinculación de objetivos, iniciativas y mediciones
a la estrategia de la organización"

Con la implementación de un Cuadro de Mando Integral se obtienen los siguientes beneficios:

Promueve la alineación estratégica de toda la organización a partir de la transformación de la

Visión y Estrategia en planes concretos de acción.

Fomenta el trabajo en equipo y por consiguiente la colaboración y la coordinación al conducir a

toda la organización hacia la consecución de la estrategia definida.

Facilita la comunicación de los planes estratégicos a toda la empresa.

Integra y sintetiza un gran volumen de datos e indicadores que surgen de la gestión diaria de las
operaciones.

Desarrolla el conocimiento y el capital humano, bases fundamentales para alcanzar los objetivos
estratégicos.

Delphos es la herramienta que ofrecemos para satisfacer las necesidades de Inteligencia de

Negocios a nivel estratégico.
Inteligencia de Negocios a Nivel Táctico

La Inteligencia de Negocios a Nivel Táctico permite que los analistas de datos y la gerencia media
de la empresa utilicen herramientas de análisis y consulta con el propósito de tener acceso a la
información sin intervención de terceros.

Como ejemplo un gerente de ventas recibe un reporte preimpreso en donde se indica que las
ventas de una determinada categoría de productos o servicios, se incrementaron de manera
inusual con relación al periodo anterior, una herramienta de análisis y consulta le permite analizar
éste incremento y establecer si el mismo se debe a nuevos productos, nuevos clientes o una
estrategia de promociones que haya producido el incremento en la demanda.

Con éste tipo de herramientas también se puede determinar si en un período específico es usual o
inusual que se produzcan éstos comportamientos anormales en la demanda, de manera de poder
anticiparnos a ellos y poder aprovechar ésta situación para aumentar el impacto positivo o
minimizar el impacto negativo según sea el caso.

Apoyo es la herramienta que ofrecemos para satisfacer las necesidades de Inteligencia de

Negocios a nivel táctico.

Inteligencia de Negocios a Nivel Operativo

La Inteligencia de Negocios a Nivel Operativo permite que los empleados que trabajan con
información operativa puedan recibir la misma de una manera oportuna, exacta y adecuada y se
componen básicamente de herramientas de reportes u hojas de cálculo con un formato fijo cuya
información se actualiza frecuentemente.

Un ejemplo de esto podría ser un supervisor de ventas que utiliza una hoja de cálculo para
monitorear el cumplimiento de las cuotas de ventas de los vendedores a su cargo, una de las
columnas tendría una información fija (la cuota de ventas) y a su lado podría estar una columna
que diariamente extraiga el total de ventas para ése vendedor en particular. El supervisor de
ventas a su vez podría aplicar fórmulas tomando en cuenta la columna de cuota y la columna de
venta real sin necesidad de tener que introducirlas de manera manual.

Matrix y Funcion@ son las herramientas que ofrecemos para satisfacer las necesidades de
Inteligencia de Negocios a nivel operativo
Definir esquemas de bases de datos multidimensionales

El término "esquema de base de datos" puede referirse a una representación visual de una base
de datos, a un conjunto de reglas que rige una base de datos, o bien, a todo el conjunto de objetos
que pertenecen a un usuario en particular. Continúa leyendo para saber más sobre los esquemas
de bases de datos y cómo se usan.

¿Quieres crear un diagrama? Prueba Lucidchart, es fácil rápido y completamente gratis.

Crea un Diagrama

¿Qué es un esquema de base de datos?

Un esquema de base de datos representa la configuración lógica de todo o parte de una base de
datos relacional. Puede existir de dos formas: como representación visual y como un conjunto de
fórmulas conocidas como restricciones de integridad que controlan una base de datos. Estas
fórmulas se expresan en un lenguaje de definición de datos, tal como SQL. Como parte de un
diccionario de datos, un esquema de base de datos indica cómo las entidades que conforman la
base de datos se relacionan entre sí, incluidas las tablas, las vistas, los procedimientos
almacenados y mucho más.

esquema lógico y físico de base de datos

Típicamente, un diseñador de bases de datos crea un esquema de base de datos para ayudar a los
programadores cuyo software interactuará con la base. Al proceso de crear un esquema de base
de datos se le llama modelado de datos. Al seguir el enfoque de tres esquemas para el diseño de
bases de datos, este paso seguiría la creación de un esquema conceptual. Los esquemas
conceptuales se enfocan en las necesidades informativas de una organización, más que en la
estructura de una base de datos.

Hay dos tipos principales de esquemas de bases de datos:

Un esquema lógico de base de datos expresa las restricciones lógicas que se aplican a los datos
almacenados. Puede definir las restricciones de integridad, las vistas y las tablas.

Un esquema físico de base de datos dispone cómo se almacenan los datos físicamente en un
sistema de almacenamiento en términos de archivos e índices.
En el nivel más básico, un esquema de base de datos indica qué tablas o relaciones componen la
base de datos, así como los campos incluidos en cada tabla. Por lo tanto, los términos diagrama de
esquema y diagrama de relaciones de entidades con frecuencia son intercambiables.

Esquema en sistema de base de datos Oracle

En el sistema de base de datos Oracle, el término esquema de base de datos, al cual también se lo
conoce como "esquema SQL", tiene un significado diferente. Aquí, una base de datos puede tener
esquemas múltiples (o "schemata", como se le dice elegantemente en inglés). Cada uno de ellos
contiene todos los objetos creados por un usuario específico de la base de datos. Esos objetos
pueden incluir tablas, vistas, sinónimos y mucho más. Algunos objetos no se pueden incluir en un
esquema, tales como usuarios, contextos, roles y objetos del directorio.

esquema de base de datos relacional

Se puede conceder acceso a los usuarios para que ingresen a esquemas individuales según cada
caso concreto, y la titularidad es transferible. Ya que cada objeto está asociado a un esquema
particular, que sirve como una especie de espacio para nombres, es útil dar algunos sinónimos, lo
cual permite a otros usuarios acceder a ese objeto sin primero consultar el esquema al que
pertenece.

Estos esquemas no necesariamente indican las formas en que los archivos de datos se almacenan
físicamente. En lugar de ello, los objetos de esquemas se almacenan lógicamente dentro de un
espacio de tablas. El administrador de la base de datos puede especificar cuánto espacio asignar a
un objeto particular dentro de un archivo de datos.

Por último, los esquemas y los espacios de tablas no necesariamente se alinean a la perfección: los
objetos de un esquema pueden estar presentes en múltiples espacios de tablas, mientras que un
espacio de tablas puede incluir objetos de varios esquemas.

Crear diagramas en línea es fácil y rápido con Lucidchart

¿Instancia de base de datos o esquema de base de datos?

Estos términos, aunque relacionados, no significan lo mismo. Un esquema de base de datos es un

bosquejo de una base de datos planificada. En realidad no contiene ningún dato.
Por otra parte, una instancia de base de datos es una instantánea de una base de datos, como
existió en un momento determinado. Por lo tanto, las instancias de bases de datos pueden
cambiar con el tiempo, mientras que un esquema de base de datos generalmente es estático, ya
que es difícil cambiar la estructura de una base de datos una vez que está en operación.

Los esquemas y las instancias de bases de datos pueden afectarse entre sí a través de un sistema
de administración de bases de datos (DBMS). El DBMS asegura que cada instancia de la base de
datos cumpla con las restricciones impuestas por los diseñadores de la base en el esquema de la
base de datos.

Requisitos de integración de esquema

Puede ser útil integrar múltiples fuentes a un esquema individual. Asegúrate de que estos
requisitos se cumplan para tener una transición transparente:

Conservación de superposición

Cada elemento superpuesto en los esquemas que estés integrando debe estar en una tabla de
esquemas de base de datos.

Conservación de superposición ampliada

Los elementos que solo aparecen en una fuente, pero que están asociados a elementos
superpuestos, se deben copiar al esquema de base de datos resultante.

Normalización

Las entidades y las relaciones independientes no se deben agrupar en la misma tabla en el

esquema de base de datos.

Minimalidad

Es ideal que ninguno de los elementos en ninguna de las fuentes se pierda.

Tipos de esquemas de bases de datos

Se han desarrollado ciertos patrones en el diseño de esquemas de bases de datos.

El esquema de estrella ampliamente utilizado es también el más simple. En este, una o más tablas
de datos están vinculadas a un número indefinido de tablas dimensionales. Es mejor para
gestionar consultas simples.

El esquema de copo de nieve relacionado también se usa para representar una base de datos
multidimensional. No obstante, en este patrón, las dimensiones se normalizan en lotes de tablas
separadas, creando el efecto expansivo de una estructura similar a un copo de nieve.

Tutorial de estructura y diseño de bases de datos

Índice

El proceso de diseño de base de datos

Análisis de los requisitos: identificar el propósito de la base de datos

Estructura de la base de datos: los bloques de creación de una base de datos

Creación de relaciones entre entidades

Normalización de la base de datos

Datos multidimensionales

Reglas de integridad de datos

Agregar índices y visualizaciones

Propiedades extendidas

SQL y UML

Sistemas de gestión de bases de datos

Una base de datos bien diseñada brinda a los usuarios acceso a información fundamental. Al
seguir los principios de esta página, puedes diseñar una base de datos que funcione bien y se
adapte a tus necesidades futuras. Explicaremos los aspectos básicos sobre el diseño de una base
de datos y cómo perfeccionarlo para obtener resultados óptimos.

Una base de datos bien estructurada:

Ahorra espacio en el disco eliminando los datos redundantes.

Mantiene la precisión e integridad de los datos.

Ofrece acceso a los datos de formas útiles.

Diseñar una base de datos útil y eficiente requiere seguir el proceso adecuado, incluidas las
siguientes etapas:

Análisis de los requisitos o identificación del propósito de tu base de datos.

Organización de los datos en tablas.

Especificación de las claves primarias y análisis de las relaciones.

Normalización para estandarizar las tablas.

Realicemos un análisis detallado de cada paso. Ten en cuenta que esta guía se centra en el modelo
de base de datos relacional de Edgar Codd escrito en SQL (en lugar de modelos jerárquicos, de red
o de datos de objetos). Para saber más sobre los modelos de base de datos, lee nuestra guía aquí.

Análisis de los requisitos: identificar el propósito de la base de datos

Comprender el propósito de tu base de datos determinará tus opciones en todo el proceso de

diseño. Asegúrate de observar la base de datos desde todas las perspectivas. Por ejemplo, si
estuvieras creando una base de datos para una biblioteca pública, deberías considerar las formas
en que los clientes y bibliotecarios necesitarían acceder a los datos.

Aquí te mostramos algunas formas de reunir información antes de crear la base de datos:

Entrevistar a las personas que la usarán.

Analizar formularios de negocio, como facturas, plantillas de horas trabajadas, encuestas.

Examinar cualquier sistema de datos existente (incluidos archivos físicos y digitales).

Comienza reuniendo cualquier dato existente que se incluirá en la base de datos. Luego enumera
los tipos de datos que quieres almacenar y las entidades o personas, cosas, ubicaciones y eventos
que esos datos describen, del siguiente modo:

Clientes

Nombre

Dirección
Ciudad, estado, código postal

Dirección de correo electrónico

Productos

Nombre

Precio

Cantidad en stock

Cantidad en el pedido

Pedidos

Número del pedido

Representante de ventas

Fecha

Producto(s)

CANTIDAD

Precio

Total

Más adelante, esta información se volverá parte del directorio de datos, que describe las tablas y
los campos dentro de la base de datos. Asegúrate de dividir la información en partes útiles lo más
pequeñas posibles. Por ejemplo, considera separar el nombre de la calle del país para poder filtrar
más adelante a los individuos según su país de residencia. Además, evita ubicar el mismo punto de
datos en más de una tabla porque agregarás una complejidad innecesaria.

Cuando sepas qué tipos de datos incluirán las bases de datos, de dónde provienen esos datos y
cómo se usarán, estarás listo para comenzar a planificar la base de datos real.

Estructura de la base de datos: los bloques de creación de una base de datos

El siguiente paso es organizar la representación visual de tu base de datos. Para ello, debes
comprender exactamente cómo se estructuran las bases de datos relacionales.
Dentro de una base de datos, los datos relacionados se agrupan en tablas, cada una de ellas
consiste en filas (también llamadas "tuplas") y columnas, como una hoja de cálculo.

Para convertir tus listas de datos en tablas, comienza creando una tabla para cada tipo de entidad,
como productos, ventas, clientes y pedidos.

Ejemplo:

Cada fila de una tabla se llama "registro". Los registros incluyen datos sobre algo o alguien, como
un cliente específico. En cambio, las columnas (también conocidas como "campos" o "atributos")
contienen un único tipo de información que aparece en cada registro, como las direcciones de
todos los clientes enumerados en la tabla.

Nombre Apellido Edad Código postal

Roger Williams 43 34760

Jerrica Jorgensen 32 97453

Samantha Hopkins 56 64829

Con el fin de que los datos sean consistentes de un registro al siguiente, asigna el tipo de datos
apropiado a cada columna. Los tipos de datos comunes incluyen:

CHAR - una longitud específica de texto.

VARCHAR - texto de longitudes variables.

TEXT - grandes cantidades de texto.

INT - número entero positivo o negativo.

FLOAT, DOUBLE - también puede almacenar números de punto flotante.

BLOB - datos binarios.

Algunos sistemas de gestión de bases de datos también ofrecen el tipo de datos denominado
"Autonumeración", que genera automáticamente un número único en cada fila.

A los efectos de crear una visión general de la base de datos, conocida como un diagrama entidad-
relación, no incluiremos las tablas reales, sino que cada tabla se convertirá en un recuadro del
diagrama. El título de cada recuadro debería indicar qué describen los datos en la tabla, mientras
que los atributos están enumerados a continuación, del siguiente modo:
tabla de base de datos

Por último, deberías decidir qué atributo o atributos funcionarán como clave primaria para cada
tabla, si procede. Una clave primaria (PK) es un identificador único para una entidad determinada,
esto significa que puedes seleccionar un cliente concreto incluso si solo conoces ese valor.

Los atributos seleccionados como claves primarias deben ser únicos, inalterables y estar siempre
presentes (nunca NULL o vacíos). Por este motivo, los números de pedido y los nombres de
usuario son excelentes claves primarias, mientras que los números de teléfono o direcciones
postales no lo son. También puedes usar múltiples campos conjuntamente como la clave primaria
(esto se denomina "clave compuesta").

Cuando llegue el momento de crear la base de datos real, ubicarás la estructura de datos lógicos y
la estructura de datos físicos en el lenguaje de definición de datos admitido por nuestro sistema
de gestión de base de datos. En este punto, también deberías calcular el tamaño aproximado de la
base de datos para asegurarte de tener el nivel de rendimiento y el espacio de almacenamiento
necesarios.

Creación de relaciones entre entidades

Cuando tus tablas de base de datos se conviertan en tablas, estarás listo para analizar las
relaciones entre esas tablas. La cardinalidad se refiere a la cantidad de elementos que interactúan
entre dos tablas relacionadas. Identificar la cardinalidad te ayuda a asegurarte de que has dividido
los datos en tablas de la forma más eficiente.

Cada entidad puede, potencialmente, tener una relación con todas las demás, pero por lo general
esas relaciones pueden ser de uno de tres tipos:

Relaciones uno a uno

Si hay una única instancia de la Entidad A para cada instancia de la Entidad B, se dice que tienen
una relación de uno a uno (a menudo se escribe 1:1). Puedes indicar este tipo de relación en un
diagrama ER mediante una línea con un guión en cada extremo:
relación uno a uno

A menos que tengas un buen motivo para no hacerlo, una relación 1:1 generalmente indica que la
mejor opción sería combinar los datos de las dos tablas en una sola tabla.

Sin embargo, quizás desees crear tablas con una relación de uno a uno en una serie particular de
circunstancias. Si tienes un campo con datos opcionales, como "descripción", que está en blanco
para muchos registros, puedes mover todas las descripciones a su propia tabla, eliminando
espacio vacío y mejorando el rendimiento de la base de datos.

Para garantizar que los datos coincidan correctamente, luego tendrías que incluir al menos una
columna idéntica en cada tabla, lo más probable es que sea la clave primaria.

Relaciones uno a muchos

Estas relaciones suceden cuando un registro de una tabla está asociado a múltiples entradas en
otra tabla. Por ejemplo, un solo cliente puede haber solicitado múltiples pedidos o una persona
haberse llevado muchos libros de la biblioteca a la vez. Las relaciones uno a muchos (1:M) se
indican con lo que se denomina "notación patas de gallo" como en el siguiente ejemplo:

relación uno a muchos

Para implementar una relación uno a muchos (1:M) mientras preparas una base de datos,
simplemente agrega la clave primaria de "un" lado de la relación como un atributo en la otra tabla.
Cuando una clave primaria se detalla en otra tabla de esta manera, se denomina "clave
extranjera". La tabla en el lado "1" de la relación es considerada una tabla principal respecto de la
tabla secundaria que se encuentra del otro lado.

Relaciones muchos a muchos

Cuando múltiples entidades de una tabla se pueden asociar a múltiples entidades de otra tabla, se
dice que tienen una relación de muchos a muchos (M:N). Esto puede suceder en el caso de
estudiantes y clases, ya que un estudiante puede inscribirse en muchas clases, y una clase puede
tener numerosos estudiantes.
En un diagrama ER, estas relaciones se representan con estas líneas:

relación muchos a muchos

Lamentablemente, no es posible implementar directamente este tipo de relación en una base de

datos. En cambio, debes dividirlo en dos relaciones uno a muchos.

Para ello, debes crear una nueva entidad entre esas dos tablas. Si la relación M:N existe entre
ventas y productos, quizás llames a esa nueva entidad "productos_vendidos", ya que mostraría los
contenidos de cada venta. Tanto las tablas de ventas como de productos tendrían una relación
1:M con "productos_vendidos". Esta clase de entidad intermedia se llama "tabla de enlaces",
"entidad asociativa" o "tabla de unión" en diversos modelos.

Cada registro de la tabla de enlaces se correspondería con dos de las entidades de las tablas
contiguas (también puede incluir información adicional). Por ejemplo, una tabla de enlaces entre
estudiantes y clases podría verse así:

tabla de enlaces

¿Es obligatorio o no?

Otra forma de analizar las relaciones es considerar qué lado de la relación debe existir para que el
otro lado exista. El lado no obligatorio puede marcarse con un círculo en la línea donde debería
haber un guión. Por ejemplo, un país tiene que existir para tener un representante en las Naciones
Unidas, pero lo opuesto no se cumple:

Dos entidades pueden ser mutuamente dependientes (una no podría existir sin la otra).

Relaciones recursivas

A veces una tabla se relaciona consigo misma. Por ejemplo, una tabla de empleados puede tener
un atributo que sea "director" y que se refiera a otro individuo de la misma tabla. Esto se llama
"relación recursiva".

Relaciones redundantes

Una relación redundante es aquella que se expresa más de una vez. Por lo general, puedes
eliminar una de las relaciones sin perder información importante. Por ejemplo, si la entidad
"estudiantes" tiene una relación directa con otra entidad llamada "profesores", pero también
tiene una relación con profesores indirectamente mediante "clases", querrás eliminar la relación
entre "estudiantes" y "profesores". Es mejor eliminar esa relación porque la única forma de que
los estudiantes se asignan a los profesores es mediante las clases.

Normalización de la base de datos

Una vez que tengas un diseño preliminar para tu base de datos, puedes aplicar reglas de
normalización para asegurarte de que las tablas estén estructuradas correctamente. Piensa en
estas reglas como los estándares de la industria.

Dicho esto, no todas las bases de datos son buenas candidatas para la normalización.
Generalmente, las bases de datos de procesamiento de transacciones en línea (OLTP), en las que
los usuarios se encargan de la creación, lectura, actualización y eliminación de los registros,
deberían estar normalizadas.

Las bases de datos de procesamiento analítico en línea (OLAP) que favorecen el análisis y la
generación de informes funcionarían mejor con un grado de desnormalización, ya que el énfasis
está en la velocidad de cálculo. Estas incluyen aplicaciones de soporte de decisiones en las que los
datos se deben analizar rápidamente, pero no deben modificarse.

Cada forma, o nivel de normalización, incluye las reglas asociadas a las formas inferiores.

La primera forma normal

La primera forma normal (abreviada como "1FN") especifica que cada celda de la tabla puede
tener un solo valor, nunca una lista de valores. Por lo tanto, una tabla como esta no cumple con
los requisitos:

ID del producto Color Precio

1 marrón, amarillo $15

2 rojo, verde $13

3 azul, naranja $11

Quizás pienses que la mejor solución sea dividir los datos en columnas adicionales, pero eso
también rompería las reglas: una tabla con grupos de atributos repetidos o estrechamente
relacionados entre sí no cumple con la primera forma normal. Por ejemplo, la tabla a continuación
no cumple con los requisitos:
En cambio, divide los datos en múltiples tablas o registros hasta que cada celda contenga solo un
valor y no halla columnas adicionales. En este punto, se dice que los datos son "atómicos", es decir
que se dividen en partes útiles lo más pequeñas posibles. Para la tabla anterior, podrías crear una
tabla adicional llamada "Datos de ventas", que haría coincidir productos específicos con ventas.
Así, "Ventas" tendría una relación 1:M con "Datos de ventas".

La segunda forma normal

La segunda forma normal (2NF) establece que todos los atributos deben ser totalmente
dependientes de toda la clave primaria. Eso significa que cada atributo debería depender
directamente de la clave primaria, en lugar de indirectamente a través de algún otro atributo.

Por ejemplo, se considera que el atributo "edad" que depende de "fecha de nacimiento", que a su
vez depende de "ID de estudiante" tiene una dependencia funcional parcial; y una tabla que
contenga estos atributos no cumpliría con la segunda forma normal.

Además, una tabla con una clave primaria compuesta de múltiples campos viola la segunda forma
normal si uno o más de los otros campos no dependen de cada parte de la clave.

Por lo tanto, una tabla con estos campos no respetaría la segunda forma normal porque el
atributo "Nombre del producto" depende del ID del producto, pero no del número de pedido:

Número de pedido (clave primaria)

ID de producto (clave primaria)

Nombre del producto

La tercera forma normal

La tercera forma normal (3NF) agrega a estas reglas el requisito de que cada columna que no sea
de clave sea independiente de las demás columnas. Si modificar el valor en una columna que no
sea de clave hace que cambie otro valor, entonces esa tabla no cumple con los requisitos de la
tercera forma normal.
Esto evita que almacenes cualquier dato derivado en la tabla, tal como la columna "Impuestos" a
continuación, que depende directamente del precio final del pedido:

Pedido Precio Impuestos

14325 $40.99 $2.05

14326 $13.73 $.69

14327 $24.15 $1.21

Se han propuesto formas adicionales de normalización, incluidas la forma normal de Boyce-Codd,

la cuarta, quinta y sexta forma normal, y la forma normal de dominio/clave, pero las primeras tres
son las más comunes.

Si bien estas formas explican las buenas prácticas que se deben seguir generalmente, el grado de
normalización depende del contexto de la base de datos.