Conceptos de Modelo de Datos y Bases de Datos

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 16

Educación

tecnológica
a
Material de Estudio Unidad 2

Conceptos de modelo de datos y bases de datos.

En el mundo actual impulsado por la información, la capacidad de organizar,


analizar y extraer conocimientos significativos de grandes conjuntos de datos
se ha vuelto esencial para la toma de decisiones informadas en cualquier
organización. Para lograr esto de manera efectiva, es fundamental
comprender los conceptos de modelo de datos y bases de datos.

En el contexto del análisis de datos, un modelo de datos es una


representación estructurada de la información que permite organizar y
relacionar los datos de manera lógica. Proporciona una visión clara y
coherente de cómo se interconectan los datos en una base de datos,
permitiendo que los analistas de datos obtengan información valiosa y
relevante para sus objetivos.

En este tema, exploraremos los fundamentos de los modelos de datos y las


bases de datos, así como la importancia de su construcción y diseño
adecuado en el análisis de datos. Aprenderemos cómo identificar y definir las
entidades y relaciones clave en un conjunto de datos, y cómo utilizar Power
Pivot, una herramienta poderosa de Microsoft Excel, para construir un
modelo de datos dinámicos y efectivos mediante un caso práctico.

01
Caso práctico.
Importaciones SAS es una empresa dedicada a la comercialización de productos
tecnológicos. Con el objetivo de tomar decisiones comerciales fundamentadas, la
compañía busca realizar un análisis exhaustivo de la rentabilidad para el cierre del año
2021 frente al porcentaje crecimiento/decremento, cual es el producto de mayor
demanda y que productos no son rentables para la organización, basándose en los
resultados obtenidos a partir de los datos disponibles.
• La organización maneja tres procesos fundamentales: ventas, compras e
inventarios, cada uno con información clave:
• Ventas: Este proceso incluye datos como la fecha de la venta, el código del
producto, el código del asesor de venta, el código de la región, la cantidad de
unidades vendidas y el precio del producto.
• Compras: Las compras se registran con detalles como la fecha de compra, el código
del producto, el código de la categoría del producto, el código de la región, la
cantidad de unidades compradas y el precio de compra.
• Inventarios: Para controlar los niveles de existencias, se manejan datos de
inventario que contienen la fecha del inventario, el código del producto, el código
de la categoría del producto y el código de la región del inventario.

Además de estos procesos, también existen datos relacionados con la región y el país
(IdRegión, País, Región), los asesores de venta (IdAsesor de Venta, Nombre y Apellido), las
categorías de productos (IdCategoria, Nombre de la categoría del producto) y los detalles
de los productos (IdCategoria, IdProducto, Descripción y Valor del producto).
La organización ha estructurado y almacenado los datos de manera interrelacionada, lo
que permite realizar análisis avanzados y obtener una visión integral del rendimiento.
Algunas de las relaciones relevantes son:
• Un producto puede estar presente en múltiples ventas, compras e inventarios.
• Se pueden realizar múltiples ventas y compras en una región, y una región puede
tener varios registros de inventarios.
• Cada vendedor puede realizar múltiples ventas.
• Los productos pueden pertenecer a diferentes categorías.
Para consulta de base la puede descargar en el siguiente link: https://acortar.link/rbMAqQ

02
Diseño conceptual de la base de datos

El modelo relacional

Históricamente existen varios modelos de bases de datos en donde


encontramos el modelo plano, el modelo jerárquico, el modelo de red, el
modelo orientado a objetos y el modelo relacional, siendo este último uno de
los más usados por su capacidad para almacenar, administrar y extraer la
información.
En esta unidad nos centraremos en el modelo relacional dadas sus ventajas
frente a los demás modelos.

Un sistema de bases de datos con base al modelo relacional se fundamenta


en la relación que existe entre cada una de sus tablas, a este concepto se le
denomina relación entre tablas; y el proceso de relacionar un conjunto de
tablas no es más que presentar una tabla que guarda alguna relación con los
datos de otra; y este procedimiento se realiza durante la estructuración
lógica y el diseño de la base de datos y este concepto para el usuario final es
irrelevante.

03
Etapas de un diseño de base de datos relacional:

En esta unidad se trabajará el nivel conceptual partiendo de la creación de


los diagramas (diagrama entidad relación y posteriormente su
transformación a un modelo relacional); recordemos que el nivel conceptual
es un procedimiento basado en el análisis de los requerimientos que
presenta una organización para el tratamiento de sus datos, con base esta
información se desarrollan una serie de herramientas conceptuales tales
como los diagramas de entidad, que permiten obtener un esquema general
de la base de datos que se va a desarrollar.

El diagrama Entidad Relación (E/R)


Consiste en un diseño esquemático al modo gráfico donde se ilustran los
diferentes elementos que conforman un sistema (Las entidades y sus
relaciones), la relación que existe entre ellos y las características que lo
componen. En estos diagramas se usa una simbología que permite
caracterizar cada uno de los objetos anteriormente mencionados, este tipo
de diagramas se asemeja mucho a los diagramas de flujo tradicionales que
utilizan las organizaciones para el modelamiento de la información
organizacional. Para el diseño de este tipo de diagramas se recomienda
utilizar herramientas CASE (ArgoUML, StarUML, LucidChart, Drawio), las
cuales son esenciales para generar este tipo de diagramas; para la creación
de los diagramas ejemplos de nuestro caso de estudio se ha utilizado la
herramienta online Drawio.

Componentes: para realizar un diagrama entidad relación o también llamado


modelo E/R se requiere definir varios elementos; las entidades que son
elemento principal del diagrama, éstas pueden ser débiles o fuertes, las
cuales están relacionadas con otras entidades; pero cada entidad puede
tener uno o varios

04
atributos, estos atributos a su vez puede ser simples o compuestos; las
entidades, relaciones y atributos van unidos con líneas de conexión

Las entidades: Es un objeto del mundo real o conceptual, que posee unas
características únicas que permiten diferenciarlas de otras entidades. Una
entidad puede ser fuerte o débil, donde la primera debe tener atributos
claves, en cambio las entidades débiles se caracterizan por no poseer llaves
propias, pero sí pueden tener llaves de relación (llaves de otras tablas, son las
llamadas foráneas). Son ejemplos de entidades: un vehículo, una persona,
una VENTA, un servicio, una COMPRA, un tratamiento, una historia clínica,
un medicamento, un PRODUCTO. Un INVENTARIO
En la figura 2 se representan algunas entidades resultantes de nuestro caso
de estudio, las cuales son fuertes en su totalidad.
Ventas Compras Productos Inventario
Figura 2: representación gráfica de las entidades fuertes de nuestro caso práctico

05
También existe el conjunto de entidades que se caracterizan por poseer los
mismos atributos (En nuestro caso práctico no se presenta este fenómeno);
pero suele ocurrir en muchas bases de datos; por ejemplo, si hubiese una
entidad llamada empleados, podrá haber atributos similares a los de la
entidad CLIENTES, tales como el nombre, la ciudad, entre otros; dado este
caso, los atributos similares se podrían agrupar en otra entidad genérica
(personas) para evitar redundancia.
Los atributos: Son características que tiene cada una de las entidades del
sistema; y éstos pueden ser:

• Simples: son atributos atómicos o que no se subdividen; por ejemplo,


en la tabla Asesores de ventas, Categoría, Región.

• Compuestos: estos son divisibles, o pueden contener otros atributos


que especifican las características de este; por ejemplo, en la tabla
Asesores de venta está nombre, que se puede dividir en nombres y
apellidos; en otros casos también se podría incluir la fecha de ingreso,
la dirección, entre otros.

• Multivalorados: son atributos que pueden tener múltiples ocurrencias


(en nuestro caso no se relacionan atributos de este tipo), pero un
ejemplo puede ser, las especialidades de un profesional (un
profesional puede tener múltiples especialidades), o el teléfono (puede
tener varios números de teléfono).

• Derivados: son los que surgen o se derivan de un dato ya existente, por


ejemplo, la antigüedad de la factura, que se puede generar a partir de
la fecha en caso de que sea requerida.

06
También pueden existir aquellos atributos en los que no es necesario o no
aplica asignarle algún valor, a estos se les llama atributos nulos, los cuales,
dentro de la tabla quedarán vacíos. En la figura 3 se puede apreciar el
ejemplo de la entidad con relación a nuestro caso práctico.

Figura 3: Una entidad fuerte con atributos simples y compuestos.

En este punto es importante aclarar que los atributos se deben denominar


con una sola palabra y que puede incluir números, pero no incluyen espacios
ni caracteres especiales; en muchas ocasiones se relacionan con palabras
nemotécnicas que caractericen su significado, por ejemplo para identificar el
número de la factura se podría utilizar el nombre “Id_Region” ó
“Cat_Regiones como nombre de la entidad tal como se evidencia en la figura
3; en nuestro caso práctico la relación de los atributos para cada una de las
entidades quedaría de la siguiente manera:

07
Entidades Atributos
Ventas IDProducto_Categoria,IDProducto, ID_Región,
ID_Asesor
Compras IDProducto_Categoria,IDProducto, ID_Región
Inventario IDProducto_Categoria,IDProducto, ID_Región
Producto IDCategoria, ID_Producto

Existen algunos atributos que no se incluyen dentro de este modelo


conceptual tales como el del valor total de la factura (este ya no se evidencia
en el modelo de la figura 3), esto porque es un dato de consulta; es decir que
suele ser el resultado de la suma los valores unitarios de los productos y se
genera como resultado de operaciones matemáticas, lo que los hace
atributos de salida que generalmente se evidencian en los reportes o en la
mismos registros de ventas, pero no es un dato que se requiere ingresar a la
base de datos. De igual manera es importante aclarar que el atributo que
corresponde a la cantidad de productos vendidos hasta este punto se
encuentra en las entidades VENTAS y PRODUCTOS, lo cual crearía
redundancia y será necesario identificar a qué entidad pertenece realmente
(este caso se profundizará más adelante).

Finalmente, la información que corresponde a cada uno de los atributos es la


relación de datos que se puede especificar de acuerdo con lo que allí se
solicita, por ejemplo, para el nombre y el apellido del cliente claro que el
dato puede ser algo como “Juan” o “Marisela”.

Las relaciones: permiten la relación o asociación entre las diferentes


entidades; estas se representan con un rombo y en su interior se le puede
destacar un nombre que generalmente es un verbo. Las relaciones también
pueden o no tener uno o varios atributos que hacen parte de las entidades

08
que estén asociadas a través de la relación (en un siguiente apartado se hará
claridad en cuales de los casos una relación podrá tener atributos asociados).
En la figura 4, se representan las entidades PRODUCTOS y VENTAS
relacionadas a través de una relación llamada tiene.

Figura 4: relación de entidades.

Las entidades débiles se relacionan a través de una relación para entidades


débiles (rombo con líneas dobles), y las entidades fuertes se relacionan a
través de una relación para entidades fuertes (rombo con líneas sencilla), el
caso de la figura 4 es una relación de entidades fuertes tal como se puede
apreciar.
La cardinalidad: indica el nivel de relación que existe entre entidades, o la
forma en la que éstas se relaciona:
1. Con respecto a la forma existen cuatro tipos de relaciones:
• Uno a uno: este tipo de relación se da cuando un registro de una
entidad A tiene una relación únicamente con otro de la entidad B; un
ejemplo es el caso de un paciente tiene una sola historia clínica y como
consecuencia una historia clínica sólo pertenecía a un único paciente
(En nuestro caso práctico ninguna de las relaciones tiene este tipo de
cardinalidad).
• Uno a muchos: este tipo de relación se da cuando un registro de la
entidad A, se relaciona con varios registros de la entidad B; por
ejemplo, un CLIENTE puede tener muchas facturas asociadas, pero una
FACTURA solo será de un único CLIENTE.

09
• Muchos a muchos: este tipo de relación será cuando muchos atributos
de la entidad A se relacionan con varios de una entidad B; por ejemplo,
una VENTA tendrá asociada muchos PRODUCTOS, de igual manera un
PRODUCTO estará relacionado en muchas VENTAS.
En la figura 6, se representan los ejemplos anteriores de cada cardinalidad.

Figura 6: tipo de relaciones con base a su cardinalidad


2. De acuerdo con el nivel de relación: al establecer una relación entre dos
tablas estas se comparten información, pero en ocasiones es necesario
establecer una restricción para compartir cierta información bajo unos
extremos o limites definidos como mínimos o máximos, es decir, que se
pueda compartir información bajo ciertos límites.
• Cardinalidad mínima: corresponde a la cantidad mínima de ocurrencias
con la que puede estar relacionada una entidad (éste puede ser un
valor de 0 o 1, lo que significa que puede haber un mínimo de cero o
una ocurrencia); por ejemplo, un PRODUCTO puede estar mínimo 1
(una) o hasta varias

10
VENTAS asociadas dadas sus compras; pero una VENTA va a corresponder a
uno y solo un PRODUCTO.

• Cardinalidad máxima: corresponde a la cantidad máxima de


ocurrencias con la que puede estar relacionada una entidad (éste
puede ser un 1 o M, lo que significa que puede haber un máximo de
una o muchas ocurrencias); por ejemplo, una VENTA podrá tener
mínimo uno o hasta varios PRODUCTOS, al igual que un PRODUCTO
podrá estar mínimo una VENTA o varias de ellas.

La cardinalidad se puede expresar como un conjunto de pares donde el


primer elemento del conjunto es la expresión mínima y el segundo la máxima
así: (mínima ocurrencia, máxima ocurrencia) por ejemplo, (0,1) – (1,1) – (0,M)
– (1,M) – (N,M). Finalmente, para definir la forma de la relación se toman
solo los extremos máximos; por ejemplo, en la relación PRODUCTO –
VENTAS, un producto puede estar una o muchas VENTAS.

Figura 7 Relación entre tablas con base a sus cardinalidades.

11
El caso que representa la Figura 7, es nuestro caso puntual de la VENTA con
los PRODUCTOS; en el problema se logra entender que la cantidad de
productos vendidos hace referencia a los productos y debería de estar en la
tabla PRODUCTOS, pero como están relacionados en la venta se entendería
que también hace parte de la entidad VENTAS, y esta afirmación es correcta;
pero en lo posible se debe de evitar la redundancia al máximo durante el
diseño de la base de datos, y como se evidencia que hay relación de muchos
a muchos entre las entidades PRODUCTOS y VENTAS entonces es posible
asignar este atributo directamente a esta relación, lo cual indicaría que el
atributo CANTIDAD hace parte de las 2 entidades y de esta manera no se
relaciona en cada entidad y se evita esta redundancia.
Las llaves primarias: Una llave primaria es un campo especial definido para
identificar en forma única cada registro de una tabla; estos se definen desde
el modelo entidad relación, sobre ese atributo que representará de manera
única cada registro; basta con resaltarlo para que se diferencie con los demás
atributos.

12
GLOSARIO DE TÉRMINOS
Atributo: es un hecho unitario que caracteriza o describe de alguna manera a
una entidad. (andy oppel, 2009, p.32)
Atributo nulo: es un atributo que no tiene ningún contenido. (pablo
valderrey sanz, 2014, p. 45)
Cardinalidad: es el número de tuplas que contiene una relación. (mercedes
marqués, 2011, p. 16)
Cardinalidad máxima: es la cantidad máxima de instancias de una entidad
que se puede asociar con la entidad en el extremo opuesto de la línea. (andy
oppel, 2009, p.32)
Cardinalidad mínima: es la cantidad mínima de instancias de una entidad
que se puede asociar con la entidad en el extremo opuesto de la línea. (andy
oppel, 2009, p.33)
Entidad: es una persona, lugar, cosa, suceso o concepto sobre el que se
compilan datos. (andy oppel, 2009, p.30)
Modelo Entidad Relación: es una herramienta para el modelado de datos de
un sistema de información. (Pablo Valderrey Sanz, 2014, p. 25)
Modelo relacional: que es el modelo de datos en el que se basan la mayoría
de los SGBD en uso hoy en día donde los datos se describen como un
conjunto de tablas con referencias lógicas entre ellas. (Mercedes Marqués,
2011, p. 14)
Redundancia: campos repetidos en diferentes tablas. (pablo valderrey sanz,
2014, p. 31)

13
Relación muchos a muchos: es una asociación entre dos entidades en que
cualquier instancia de la primera entidad puede asociarse con cero, una o
más instancias de la segunda, y viceversa. (andy oppel, 2009, p.36)
Relación uno a muchos: es una asociación entre dos entidades en que
cualquier instancia de la primera entidad puede asociarse con una o más
instancias de la segunda entidad y cualquier instancia de la segunda entidad
puede asociarse con cuando mucho una instancia la primera. (andy oppel,
2009, p.35)
Relación uno a uno: es una asociación en que una instancia de una entidad
se puede asociar cuando mucho con una instancia de la otra entidad. (andy
oppel, 2009, p.34)

Referencias.

• ¿Qué es el modelado de datos?: https://aws.amazon.com/es/what-


is/data-modeling/
• Conceptos básicos sobre bases de datos:
https://support.microsoft.com/es-es/office/conceptos-b%C3%A1sicos-
sobre-bases-de-datos-a849ac16-07c7-4a31-9948-3c8c94a7c204
• Modelo de base de datos:
https://es.wikipedia.org/wiki/Modelo_de_base_de_datos

14
Educación
tecnológica

También podría gustarte