Base de Datos

Pinto, O. y Costa, G. (2020)

Base de Datos. [Apunte].
Universidad Andrés Bello, Santiago, Chile.
 1

CONCEPTOS GENERALES BASE DE DATOS

Los Dato son un Recurso

Las organizaciones han visto la necesidad de incorporar al dato como un recurso más; esto implica que,
el dato debe ser administrado, planificado y controlado, y tratado como un activo más de la empresa, de
tal manera de poder con él apoyar el logro de los objetivos organizacionales.

Si bien los datos tienen un rol diferente al resto de los recursos de una organización, comparte con ellos
una característica común importante: tiene un costo y un valor asociado.

Resultando de vital importancia un eficiente y efectivo tratamiento del recurso dato o información.

Diferenciar entre dato e información

! Dato: Hechos relacionados con personas, objetos, eventos u otras entidades del mundo real
(empresa, sistema, etc.). Pueden ser cuantitativos o cualitativos,internos o externos, históricos o
predictivos. Provienen de diversas fuentes dentro de una organización: Finanzas, Producción, Ventas,
Personal, etc.

! Información: Son datos que han sido organizados o preparados en una forma adecuada para apoyar
la toma de decisiones. Por ejemplo, una listado con los nombres de los productos y su stock sin ningún
orden se consideran datos, pero si el listado se encuentra ordenados por stock (de menor a mayor)
representa información importante para el encargado de compras de la organización.

Para el efectivo tratamiento del recurso dato, muchas organizaciones están trabajando con Bases de
Datos. Una base de datos (BD) es un conjunto de datos relacionados, que permiten satisfacer las
necesidades de información de una organización. Tiene dos propiedades importantes: INTEGRAR Y
COMPARTIR; la integración significa que los diferentes archivos de datos han sido lógicamente organizados
para reducir la redundancia de datos y facilitar el acceso a ellos; el compartir significa que todos los
usuarios calificados tienen acceso a los mismos datos, para usarlos en diferentes actividades.

El concepto de base de datos se puede ver en la Figura 1, donde se plasma a la base de datos como un
conjunto de archivos relacionados que pueden ser accesados por muchos usuarios, a través de distintos
medios como por ejemplo programas, computadores o celulares.
 2

Programas
Usuario A De Producto
aplicaciones

Usuario B
Proveedor

Usuario N

Cliente

Figura 1.- Concepto de Base de Datos

Desde una perspectiva organizacional, una base de datos se puede definir como un conjunto de datos
operacionales relevantes para la toma de decisiones involucrada en algún nivel de la organización, y que
permiten satisfacer diversos requerimientos de información de la organización.
Los datos operacionales son aquellos datos que usa la organización para su normal funcionamiento.
Una organización puede decidir implementar una base de datos o varias pequeñas dentro de su servidor;
o una base de datos distribuida en los distintos computadores existente en la organización, o
implementar la base de datos de forma cloud.
Una base de datos desde el punto de vista organizacional puede representarse en la Figura2

NIvel PLanificación

L
O V F
G E I Nivel Táctico
I N N
S T A
T A N
I Z
C A Nivel Operacional
A
S

Figura 2 Base de Datos desde perspectiva organizacional

 3

1.- Enfoque Tradicional de Procesamiento de Datos

El enfoque tradicional utilizado en el desarrollo de sistemas de información (SI) para el tratamiento de

los datos, se relaciona con el procesamiento de datos por departamentos u unidades organizacionales.
Los sistemas de información responden a requerimientos de los distintos usuarios por medio de
aplicaciones individuales. Cada sistema desarrollado es diseñado y desarrollado, para satisfacer las
necesidades de un departamento dentro de la organización.
En este tipo de enfoque NO EXISTE una planificación corporativa o un modelo que guíe el desarrollo de
aplicaciones.

El enfoque es conocido como Enfoque por Agregación y en la Figura 3 se visualiza su esencia. La figura
muestra el organigrama de una organización en el cual diferentes funciones requieren de un SI para
apoyar sus decisiones, cada SI utiliza datos de la organización los cuales son parte del área marcada en
la figura. La superposición de áreas indica la utilización del mismo tipo de datos por uno o más SI; no
implica compartir recursos sino más bien duplicar recursos.
El nombre por agregación representa a un proceso evolutivo que se presenta al ir acoplando a un SI
nuevas funciones, y, por ende, nuevos requerimientos que no habían sido considerado en el momento
del diseño inicial del sistema.

B C D

E F G H I

Figura 3.- Enfoque por Agregación desde punto vista Organizacional

 4

Sistemas de Procesamiento de Archivos

Cada nueva aplicación es diseñada con su propio conjunto de archivos de datos. Muchos de esos datos
pueden ya existir en archivos de otras aplicaciones, pero para ser usados en la nueva aplicación
requerirían de reestructuración, lo cual es complejo dado que es necesario revisar los programas que
usan esos archivos, e incluso a veces, reescribir completamente los programas. Por lo anterior, la mayoría
de las veces es más simple diseñar nuevos archivos para cada aplicación.
En la figura 4. muestra el enfoque de agregación desde una perspectiva computacional. Programas de
aplicación pueden accesar, a uno o más archivos de dato, por lo cual deben contener cada uno de ellos
las definiciones de los archivos que utilizan y las correspondientes instrucciones que permiten
manejarlos. Cada programa es dueño de sus archivos de datos y la lógica del programa es dependiente
de los formatos y descripciones de esos datos.

Programa
Programa
Facturación
Compras

Archivo
Archivo Cuentas Archivo Archivo Archivo
Pagadas Empleado Inventario Proveedor
Clientes Materiales

Programa Programa Programa

Cuentas por Ventas Sueldos
Pagar

Archivo Archivo Archivo

Archivo Archivo Clientes Inventario Emplea-
Proveedor Factura Productos dos

Figura 4.- Enfoque por Agregación Perspectiva Computacional

Desventajas Enfoque Tradicional

Las desventajas del enfoque tradicional de procesamiento de datos se resumen en:

REDUNDANCIA NO CONTROLADA
Al tener cada aplicación sus propios archivos existen un alto grado de redundancia, lo que conlleva a
pérdida de espacio, ingreso repetidamente del dato para actualizar todos los archivos donde él está e
 5

inconsistencias (o varias versiones del dato) lo que requiere de tiempo para corregirlas. En general algo
de redundancia es útil, pero debe ser muy bien controlada.

INCONSISTENCIA DE DATOS
Se produce cuando el dato es almacenado en distintas partes y no se modifica en todas ellas al realizarse
una actualización (update). Es la fuente más común de errores en las aplicaciones, lleva a documentos y
reportes inconsistentes y hace disminuir la confianza del usuario en la integridad del sistema de
información.

INFLEXIBILIDAD
No se puede responder con facilidad a requerimientos de información (reportes, documentos, etc.) que
no hallan sido considerados en el diseño original. Esto origina frustración en los usuarios al no poder
comprender porque el sistema no puede darle la información que necesitan en el nuevo formato
requerido, a pesar de que se cuenta con los archivos respectivos.

ESCASA POSIBILIDAD DE COMPARTIR DATOS

Como cada aplicación tiene sus propios archivos, existe poca oportunidad para los usuarios de compartir
datos. Esto trae como consecuencia que el mismo dato tenga que ser ingresado varias veces para
actualizar los archivos con datos duplicados. Otra consecuencia, es que al desarrollarse nuevas
aplicaciones no es posible a veces, explotar los datos contenidos en archivos que ya existen, teniendo
que crearse nuevos archivos con la consiguiente duplicación de datos.

POBRE ESTANDARIZACION
Al desarrollar sistemas de información, se requieren estándares básicamente para los nombres de datos,
formatos y restricciones de acceso. Estos estándares son difíciles de tener en un enfoque tradicional,
principalmente porque la responsabilidad por el diseño y operación del sistema es descentralizada. Esto
puede traer dos tipos de inconstencias: sinónimos (uso de nombres diferentes para un mismo ítem de
datos, ej.: #ESTUDIANTE y ROL ALUMNO) y homónimos (uso de un mismo nombre simple para ítems de datos
distintos, ej.: NOTA usado para indicar la calificación de un alumno en un ramo y NOTA usado para almacenar
información narrativa sobre una orden de compra). La estandarización es más difícil en grandes
organizaciones sin control centralizado, ya que cada unidad puede tener sus propias aplicaciones con sus
nombres y formatos particulares. La pobre estandarización dificulta las mantenciones de la aplicación.

BAJA PRODUCTIVIDAD DEL PROGRAMADOR

El programador, en general, debe diseñar cada archivo usado en una nueva aplicación y luego codificar
las definiciones en el programa (en algunos casos esto se simplifica pues se usan descripciones de datos
estándares que existen en bibliotecas). También debe escribir las instrucciones de Input/Output
requeridas por el método de acceso seleccionado. Por lo tanto, se requiere de un mayor esfuerzo de
desarrollo lo que lleva a una baja productividad y por ende aumentan los costos del software.

EXCESIVA MANTENCION
Como las descripciones de archivos, registros e ítems de datos están dentro de los programas, cualquier
modificación de un archivo requiere que se identifiquen el o los programas donde será usado. A esto se
le llama mantención y hoy en día cerca del 80% del esfuerzo de programación es ocupado en esta tarea.
 6

2.- Enfoque de Base de Datos

El enfoque considera los datos como un recurso que debe se compartido entre diferentes usuarios. Cada
usuario puede contar con una visión propia de la base de datos, de acuerdo con sus requerimientos de
información. Los datos son almacenados de tal manera que sean independientes del programa que los
usa. Se tiene un control centralizado de las operaciones de protección, ingreso, modificación,
eliminación y recuperación de datos, a través de un software específico: DBMS (Data Base Management
System).

Una base de datos se puede definir como un conjunto de archivos relacionados; los archivos en cuestión
no están directamente asociados con programas de aplicaciones (ver Figura 5).

Archivo Archivo Archivo Archivo Archivo

Clientes Cuentas Empelados Inventario Proveedor
Pagadas

Archivo Archivo Archivo

Factura Balance Estadísticas
Ventas

Figura 5.- BD como un conjunto de archivos relacionados

 7

Elementos del Enfoque de Base de Datos

Los principales elementos de este enfoque y sus relaciones se muestran en la Figura 6.

Administradores de BD Desarrolladores de SI Usuarios Finales

: : :
Herramienta CASE Interface Usuario Programas de
Aplicaciones

Repositorio
DBMS BD

Figura 6.- Elementos del Enfoque de Bases de Datos

1.- USUARIOS:

Son todas aquellas personas que requieren datos, se clasifican en:

ü Usuarios Finales: Personas de la organización que agregan, borran y modifican datos en la base de
datos y que consultan o reciben información desde la base de datos. Suelen clasificarse en base al
tipo de requerimientos que realizan en: sólo lectura (read only), insertar y borrar (add/delete) y
modificar (update).

ü Desarrolladores de Sistemas: Personas como analistas de sistemas y programadores que diseñan

nuevos programas de aplicación. A menudo se apoyan en herramientas CASE.
 8

ü Administradores de Datos: Personas responsables por el diseño de la base de datos y por fijar normas
que resguardan la seguridad e integridad de ella. Usan herramientas CASE para mejorar su
productividad.

2.- SISTEMA ADMINISTRADOR DE BASE DE DATOS:

El Data Base Management System (DBMS) es un software (y a veces hardware y firmware), que permite
manejar una o más bases de datos, y también el repositorio. Sus principales funciones son:

ü Función Definición de Datos: Permite especificar el tipo de dato que irá en la Base de Datos, su
estructura lógica, las relaciones entre datos y características físicas sobre organización y acceso. Esto
se puede realizar a través del lenguaje de definición de datos (Data Definition Language o DDL) que
provee el DBMS.

ü Función Manipulación de Datos: Permite almacenar, modificar y recuperar los datos de la Base de
Datos. Esto se logra a través del lenguaje de manipulación de datos (Data Manipulation Language o
DML) provisto por el DBMS, que entre otras cosas permite insertar, borrar y modificar datos,
consultarlos y presentarlos en forma adecuada. El lenguaje puede ser del tipo huésped (host
language), al cual se le incorporan instrucciones para manejar la Base de Datos; es el caso de
lenguajes como: COBOL, C, VISUAL BASIC, POWERBUILDER, entre otros. O puede ser un lenguaje propio que no
requiere de un apoyo de un lenguaje de alto nivel (SQL: Structured Query Language).

ü Función Seguridad de Datos: Los datos debe ser protegido para que no sea erróneamente usado o
destruido en forma accidental o intencional. El DBMS provee de mecanismos para controlar el acceso
y para definir qué operaciones (por ejemplo, sólo lectura o actualización) puede realizar cada usuario.
Además, debe proveer de mecanismos de respaldo y recuperación de la Base de Datos, en caso de
alguna caída del sistema (errores del operador, daños en los discos, errores de programa, etc.).
También de mecanismos que permitan prevenir los efectos de que dos o más usuarios intenten
acceder al mismo dato simultáneamente (es decir, debe proveer control concurrente).

3.- BASE DE DATOS (Data Base):

Es el lugar físico donde quedan los datos de un usuario.Puede ser una Base de Datos Centralizada
(completamente almacenada en un computador central, sea éste un mainframe un PC stand alone, un
servidor en una arquitectura C/S, etc.) o una Base de Datos Distribuida (donde los datos están
almacenados en distintos nodos de una red).

4.- REPOSITORIO (Repository):

Lugar donde quedan las definiciones de los datos, formatos de pantallas y reportes y definiciones de
otros sistemas de la organización. Se le conoce también con el nombre de Diccionario de Datos. Esta
herramienta es clave en la administración del recurso dato en la organización y suele estar implementada
como una base de datos.
 9

5.- INTERFACE USUARIO/SISTEMA:

Consiste en lenguajes o paquetes generadores de interfaces, reportes, etc. que permiten a los usuarios
interactuar con la Base de Datos. Diferentes usuarios requieren diferentes tipos de interfaces, por
ejemplo, un programador puede requerir un lenguaje como java o un usuario final preferiría un sistema
web. Con los últimos avances en el software y hardware, la interface es cada día más amigable para el
usuario; avances como los lenguajes visuales, el uso de “mouse”, sistemas de reconocimiento de la voz
y touch, incentivan a usuarios finales no expertos en computación a definir sus propios reportes,
pantallas y a realizar aplicaciones simples.

6.- PROGRAMAS DE APLICACIONES:

Programas computacionales usados para crear y mantener las Base de Datos, además para proveer
información a los usuarios.

7.- HERRAMIENTAS CASE (Computer-Aided Software Engineering)

Herramientas automatizadas que apoyan el desarrollo de software, especialmente en lo que respecta

al diseño de la Base de Datos y sus programas de aplicación. Ayudan al Administrador de Datos (en la
planificación y diseño de Base de la Datos) y a los desarrolladores de sistemas (analistas y programadores
en el análisis de requerimientos y diseño de programas). Las CASE se clasifican en dos categorías:

F Upper-CASE: apoyan las tareas “ front-end “ del ciclo de vida del desarrollo de software, incluyendo
definición de requerimientos, análisis y diseño.
F Lower-CASE: automatizan las tareas finales del ciclo de vida, es decir, generación de código, prueba y
mantención.
 10

IMPLEMENTACIÓN DEL ENFOQUE DE BASE DE DATOS

La implementación de una Base de Datos en la organización puede esquematizarse como en la Figura 7
Uso BD
Modelamiento Datos Creación BD
(rara vez) (rara vez) (pocas veces) (frecuentemente)

Programador Usuario Final

Requerimientos Programa de Consulta

Definición BD (Query)
Aplicación

Compilador Traductor
Modelo de Datos DDL DML
Conceptual

DBMS

BD Lógica
(Schema) BD Física

Figura 7.- Implementación del Enfoque de Bases de Datos

En la figura se muestran dos etapas que se realizan comúnmente al trabajar con BD: Creación de la base
de datos la cual idealmente debiera realizarse una vez (o rara vez), de tal manera de contar con un BD
cuyo contenido sea el que satisface todos los requerimientos y no tener que estar cambiando su
estructura constantemente; y la etapa de operación o utilización de la base de datos, la cual involucra a
los usuarios finales accesándola constantemente, y a los desarrolladores de sistemas realizando
programas que permitan mantenerla actualizada y responder a nuevos requerimientos de los usuarios.

Estas etapas requieren de la utilización del DBMS, especialmente en las tareas de definición y
manipulación de la Base de Datos. Se hace una distinción entre Base de Datos lógica y física; por la
primera se entiende la definición o esquema conceptual de la Base de Datos (descripción de archivos y
asociaciones), y por la segunda, se entiende el lugar físico donde quedan almacenados los archivos y sus
asociaciones. Esta distinción muestra claramente una de las ventajas principales del enfoque de Base de
Datos: independencia de los datos de los programas.

Además, es importante mencionar la necesidad de incorporar una etapa previa denominada

modelamiento de datos, a través de la cual, se busca obtener de la realidad (una organización) aquellos
datos y asociaciones que la representan, expresados en forma de un modelo de datos.
 11

Beneficios y Riesgos de Usar Base de Datos

El enfoque de Base de Datos ofrece ventajas en comparación con el enfoque de archivos tradicionales.
Estos beneficios se pueden resumir en:

MÍNIMA REDUNDANCIA DE DATOS

Al integrar los archivos de datos en una sola estructura lógica y almacenando cada ocurrencia de un ítem
de dato en un solo lugar de la Base de Datos, se reduce la redundancia. Se sugiere que se tenga en mente
que toda la redundancia puede ser eliminada, pero algunas veces existen razones válidas para almacenar
múltiples copias del mismo dato (por ejemplo: para eficiencia en el acceso a los datos, para chequeos de
validación). En un sistema de Base de Datos la redundancia es controlada.

CONSISTENCIA DE DATOS
Al controlar la redundancia de datos, se reduce enormemente la inconsistencia, dado que al almacenarse
un dato en un solo lugar, las actualizaciones no producen inconsistencia. E incluso si existe redundancia,
pero controlada, el enfoque de Base de Datos se preocupa que al producirse una actualización, se
realicen las modificaciones en todos los registros donde esté el dato. Lamentablemente no todos los
sistemas de Base de Datos actuales manejan de esta forma la consistencia de datos.

INTEGRACION DE DATOS
En una Base de Datos, los datos son organizados de una manera lógica que permite definir los
relacionamientos entre ellos. Un usuario puede fácilmente relacionar un dato con otro, por ejemplo,
para un determinado producto un usuario puede determinar que materias primas son requeridas para
fabricarlo y también asociar a las materias primas los proveedores que las venden. Los sistemas de Base
de Datos tienen la función de asociar lógicamente datos relacionados.
COMPARTIR DATOS
Una Base de Datos es creada para ser compartida por todos los usuarios que requieran de sus datos;
muchos sistemas de Base de Datos permiten a múltiples usuarios compartir la Base de Datos en forma
concurrente, aunque bajo ciertas restricciones. Como bajo este enfoque, cada unidad funcional (o
departamento) tiene su visión de la Base de Datos, es más simple el compartir datos puesto que a cada
usuario se le puede asignar una vista precisa de los datos requeridos para tomar sus decisiones y no
necesita conocer toda la Base de Datos.

ESFUERZO POR ESTANDARIZACION

Establecer la función de Administración de Datos es una parte importante de este enfoque, su objetivo
es tener la autoridad para definir y fijar los estándares de los datos, así como también posteriores
cambios de estándares.

FACILITAR EL DESARROLLO DE APLICACIONES

Este enfoque reduce el costo y tiempo para desarrollar nuevas aplicaciones. Hay estudios que indican
que cuando una Base de Datos ha sido diseñada e implementada, un programador puede codificar y
depurar una nueva aplicación en al menos 2 a 4 veces más rápido que si fuese con archivos tradicionales.
La razón de esto, es que el programador no necesita cargar con las tareas de diseño, construcción y
mantención de archivos maestros.
 12

CONTROLES DE SEGURIDAD, PRIVACIDAD E INTEGRIDAD

La función Administración de Datos es responsable por establecer controles de acceso para proteger los
datos. El control centralizado que se ejerce bajo este enfoque puede mejorar la protección de datos en
comparación con archivos tradicionales. Sin embargo, si no se aplican los controles pertinentes, una Base
de Datos puede ser más vulnerable que los archivos tradicionales dado que una gran cantidad de
usuarios están compartiendo un recurso común.

FLEXIBILIDAD EN EL ACCESO
Este enfoque provee múltiples trayectorias de recuperación de cada ítem de dato, permitiendo a un
usuario mayor flexibilidad para ubicar datos que en archivos tradicionales. También, es posible satisfacer
ciertos requerimientos ad-hoc (que se producen de repente y casi por única vez) sin necesidad de un
programa de aplicación, a través de lenguajes de consulta orientados al usuario (query language) o de
generadores de reportes (report writer) que proveen los DBMS. Esto también puede ser provisto por el
enfoque tradicional, pero no con la misma responsabilidad con que lo hacen los sistemas de Base de
Datos.

INDEPENDENCIA DE LOS DATOS

A la separación de las descripciones de datos de los programas de aplicaciones que usan esos datos, se
le llama independencia de datos. Esta permite cambiar la organización de los datos sin necesidad de
alterar los programas de aplicación que procesan los datos. Es uno de los objetivos principales del
enfoque de Base de Datos.

REDUCCIÓN DE LA MANTENCION DE PROGRAMAS

Los datos almacenados deben ser cambiados frecuentemente por diversas razones; se agregan nuevos
datos, se cambian formatos de los datos, aparecen nuevos dispositivos de almacenamiento o métodos
de acceso, etc. En archivos tradicionales, estos cambios generan modificación a los programas de
aplicación (reescribirlos), en sistemas de Base de Datos como los datos son independientes de los
programas se reduce la necesidad de modificar (mantener) los programas.

Los beneficios mencionados dependen del DBMS con que se cuente, es posible por ejemplo que la
independencia de datos no se presenta tan fácilmente en los sistemas de Base de Datos más antiguos.

Otra razón por la cual puede fracasarse en la obtención de los beneficios mencionados es la pobre
planificación organizacional en el diseño de la base de datos. Aunque se tenga el mejor software de Base
de Datos no se puede cubrir esta deficiencia.

Además, es posible identificar algunos riesgos o costos que deben tenerse en cuenta al manejar Base de
Datos, estos son:

PERSONAL ESPECIALIZADO
Generalmente, al usar el enfoque de Base de Datos o comprar un DBMS se necesita contratar o capacitar
a personas para convertir sistemas existentes, desarrollar y estimar nuevos estándares de programación,
diseñar Bases de Datos y administrar al nuevo staff de personas.

NECESIDAD DE RESPALDOS
El hecho de tener mínima redundancia, si bien produce beneficios puede llevar a problemas al no contar
con copias de datos que sirvan de respaldo. Por ello es necesario contar con respaldos independientes
 13

que ayuden a recuperar archivos dañados, los DBMS generalmente proveen de herramientas que
permiten respaldar y recuperar archivos.

PROBLEMAS AL COMPARTIR DATOS

El acceso concurrente a los datos a través de distintos programas de aplicación puede causar algunos
problemas. Primero, si dos usuarios con acceso concurrente desean cambiar el mismo dato o un dato
relacionado, se pueden producir resultados inadecuados si es que el acceso al dato no es sincronizado.
Segundo, cuando los datos son usados sólo para actualización, diferentes usuarios pueden obtener el
control de distintas partes de la Base de Datos y bloquear el uso de algún dato (a esto se le llama “
deadlock”). Los DBMS deben ser diseñados para prevenir o detectar tales interferencias, de una forma
que sea transparente para el usuario.

CONFLICTO ORGANIZACIONAL
El mantener los datos en una Base de Datos para ser compartidos, requiere de un consenso en la
definición y propiedad de los datos como también en la responsabilidad por la exactitud de ellos. La
experiencia ha mostrado que los conflictos en cómo definir los datos, (largo y codificación, derechos de
actualización, etc.), son difíciles de resolver y muy frecuentes. En el enfoque de Base de Datos se hace
necesario contar con un Administrador de Datos astuto y un buen itinerario de desarrollado de
aplicaciones Base de Datos.
 14

LAS BASES DE DATOS EN EL PROCESO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN

Tipos de Sistemas de Información

Los Sistemas de Información,junto a las base de datos deben satisfacer los requerimientos de
información de todos los niveles de la organización (operacional, táctico y estratégico). Sin embargo, los
requerimientos en los distintos niveles son bastantes diferentes. Estos niveles se caracterizan por la
decisión que apoyan, el tipo de decisión, el modelo usado para apoyar tal decisión y el tipo de
información que requieren. Todos estos elementos se muestran en la siguiente tabla:

Características Nivel Estratégico Nivel Táctico Nivel Operacional

Decisión que apoya Planificación Control Control
Largo Plazo Gerencial Operacional
Tipo de Decisión No Estructurada Semi Estructurada
Estructurada
Modelo más usado Predictivo Descriptivo Normativo
Características de la
Información:
F Fuente Medio Ambiente Registros Internos Operación Interna
F Exactitud Razonable Buena Exacta
F Amplitud Resumida Detallada Muy Detallada
F Frecuencia A Solicitud Periódica Tiempo Real
F Rango de Tiempo Años Años Meses
F Uso Predicción Control Acción Diaria

En una organización se pueden identificar tres tipos de Sistemas de Información:

ü SI Operacionales o TPS (Transaction Processing Systems), que apoyan las operaciones diarias de la
organización; entregan información detallada en forma oportuna y exacta.

ü SI Administrativos o MIS (Management Information Systems) proveen información requerida por los
administradores para planificar y controlar; en general es información resumida. Los sistemas tienden
a ser flexibles y de fácil uso, pero esto ha sido un objetivo difícil de lograr, por lo que aparece la
necesidad de sistemas que verdaderamente apoyen la planificación y los procesos de toma de
decisiones (DSS).

ü Sistemas de apoyo a la toma de decisiones o DSS (Decision Support Systems), buscan apoyar al
tomador de decisiones con información y herramientas de análisis. Un DSS debería incluir:
1. Un terminal (a menudo un PC) ubicado en la oficina del tomador de decisiones o en otro lugar
adecuado.
 15

2. Un DBMS para crear, accesar y mantener archivos o Bases de Datos locales o distribuidas.
3. Un lenguaje de alto nivel poderoso para recuperar y manipular datos.
4. Herramientas de modelación que permitan evaluar diferentes alternativas de decisión
(herramientas como simuladores planillas de cálculo, gráficadores, etc), más conocidas como
herramientas clientes en una arquitectura cliente/servidor.

Un típico ejemplo de un DSS simple se visualiza en la Figura 8. En este ejemplo un computador (usado
por un tomador de decisiones) se enlaza al computador central que usa un DBMS para manejar las
Bases de Datos de la organización que contienen datos de nivel operacional. El tomador de decisiones
utiliza un lenguaje de consulta (Query Language) para formular sus requerimientos, éstos son pasados
al computador central quien usa el DBMS para extraer los datos requeridos desde las Bases de Datos.
Estos datos pasan al PC donde pueden ser desplegados o almacenados en un archivo o Base de Datos
local, o ser usados en un modelo financiero para evaluar alternativas, en este caso a través de una
planilla de cálculo.

Requerimientos de Información
Computador Central
Computador Personal

DBMS
Query Planilla

Subcjto.BD

BD`s Corporativas

Archivo
Local

Figura 8.- Ejemplo de un DSS

Es importante mencionar, además, el concepto de Data Warehouse que en el último tiempo ha ido
ganando su espacio en lo que a bases de datos se refiere. Se trata de un “almacén” donde las
organizaciones pueden depositar todos aquellos datos con importancia crítica para la toma de
decisiones. Un Data Warehouse consiste básicamente de tres componentes:
F Herramientas extractoras, de transformación y carga para los datos operacionales y fuentes
externas.
F Un warehouse (almacén) para almacenar los datos seleccionados.
F Herramientas para referenciar y analizar los datos contenidos en el warehouse.

Este nuevo concepto nace frente a la problemática asociada a las bases de datos operacionales, y a los
sistemas de información tradicionales, que no han logrado aún dar un soporte real y efectivo a la toma
 16

de decisiones. Los datos básicos de una organización son transformados, integrados y cargados en el
Data Warehouse de una forma tal que tenga sentido para el tomador de decisiones.

El Data Warehouse es un concepto que trata de resolver la problemática que tienen actualmente las
empresas en el análisis rápido de situaciones, la integración de datos procedente de diversas fuentes, el
contar con una perspectiva histórica de los datos y el aprovechamiento óptimo de la información
organizacional, apoyándose para ello en un proceso actualmente conocido como Data Mining.

En síntesis, se puede establecer que hoy en día, los sistemas de información en general son clasificables
en aquellos que están orientados a las transacciones (sistemas OLTP: On-Line Transaction Processing) y
aquellos orientados a analizar temas de interés específico del tomador de decisiones (sistemas OLAP:
On-Line Analytic Processing). Los TPS y MIS, apoyados la mayoría de las veces en bases de datos
relacionales, son ejemplos de sistemas OLTP. En cambio, el Data Warehouse permite desarrollar
aplicaciones del tipo OLAP, integrando los datos de los distintos sistemas OLTP de una organización. Pero
para no quedarse sólo como herramientas de apoyo a sistemas OLTP, las bases de datos relacionales
están apoyando la generación de aplicaciones del tipo ROLAP (Relational On-Line Analytic Processing),
a través de las Bases de Datos Multidimensionales que se basan en el concepto de Data Warehouse.
 17

METODOLOGÍAS DE DESARROLLO

El enfoque de BD altera el desarrollo tradicional de SI en las etapas de Análisis (Diseño Lógico) y en

especial en la de Diseño (Diseño Físico).

En el Análisis se debe poner mayor énfasis en el manejo integrado de los datos y en la generación de una
estructura lógica de la Base de Datos que se adapte a los requerimientos de los usuarios y a las
capacidades del DBMS disponible.

En el Diseño se debe convertir la estructura lógica en especificaciones para archivos y programas que
puedan ser implementados por el DBMS disponible, se debe definir la Base de Datos (su schema), la
manera de poblarla inicialmente y los programas que permitirán manejarla posteriormente.

La estructura lógica de la Base de Datos es el elemento fundamental, si ella no contiene todos los datos
que el sistema requiere, la Base de Datos no permitirá satisfacer los requerimientos del usuario por lo
que el Sistema de Información fracasará. Para asegurar que el contenido de esta estructura es el
correcto, se utilizan metodologías de Modelamiento de Datos que ayudan a extraer desde un sistema o
área de aplicación aquellos datos relevantes y además permiten verificar que todos los requerimientos
puedan ser satisfechos por el modelo de datos generado. También permiten generar un modelo de datos
que represente a toda la organización y de allí detectar áreas que deben ser cubiertas por SI particulares.

De utilizarse una metodología de desarrollo de sistemas como el Análisis y Diseño Estructurado, el

enfoque de Base de Datos tiene mayor incidencia en la etapa de Diseño por las mismas causas
mencionadas para el Diseño Físico. La etapa de análisis puede ser apoyada fuertemente por un
metodología de Modelamiento de Datos, de tal manera de complementar el enfoque por procesos del
Análisis Estructurado con el enfoque de datos que provee el modelamiento.

Es posible además considerar el desarrollo de aplicaciones sólo desde la perspectiva de los datos, para
ello hay autores que han propuesto la necesidad de realizar una planificación de Base de Datos (proceso
top-down) y un diseño de Base de Datos (proceso bottom-up), a partir de los cuales se obtienen la o las
Base de Datos requeridas por la organización, incluyendo los programas de aplicación que las manejan.
Este enfoque orientado a los datos es el que se verá en los próximos capítulos, como metodología de
modelamiento de datos.(Ver figura 9)
 18

Estudio de Factibilidad

Definición de Requerimientos

Análisis (Diseño Lógico) Upper-CASE

Diseño (Diseño Físico) Prototipo

Programación Aproximaciones
y Pruebas Sucesivas

Lower-CASE

Implementación

Mantención

Figura 9.- Etapas Tradicionales del Ciclo de Vida de un SI

 19

ARQUITECTURA E INDEPENDENCIA DE LOS DATOS

Arquitectura de tres esquemas

Su objetivo, es separar las aplicaciones del usuario y la base de datos físicas.
En esta arquitectura se pueden definir tres niveles:
Nivel interno :
Describe la estructura de almacenamiento físico de la base de datos. Utiliza un modelo de
datos físico y describe todos los detalles del almacenamiento de datos y las rutas de acceso
a la base de datos.
Nivel conceptual:
Describe la estructura de toda la base de datos. Oculta los detalles de almacenamiento físico
y se concentra en describir las entidades.
Nivel externo:
Describe la parte de la base de datos en la que un grupo de usuarios están interesado y le
oculta el resto de la base de datos.

Figura 10.a.- Etapas Tradicionales del Ciclo de Vida de un SI

 20

Figura 10.B- Etapas Tradicionales del Ciclo de Vida de un SI

TIPOS DE ARQUITECTURAS DE DBMS

1.- Arquitectura centralizada de los DBMSs

Las primeras arquitecturas de base de datos utilizaban mainframes para proporcionar el procesamiento
principal a todas las funciones del sistema, incluyendo las aplicaciones de usuario y los programas de
interfaz de usuario, así como a toda la funcionalidad del DBMS. La razón era que la mayoría de los
usuarios accedía a esos sistemas a través de terminales de computador que no tenían potencia de
procesamiento y sólo ofrecían capacidades de visualización. Por tanto, todo el procesamiento se
realizaba remotamente en el sistema computador, y sólo se enviaba la información de visualización y los
controles desde el computador a los terminales de visualización, que estaban conectados con el
computador central a través de diferentes tipos de redes de comunicaciones.
A medida que bajaban los precios del hardware, la mayoría de los usuarios reemplazaban sus terminales
por PCs y estaciones de trabajo. Al principio, los sistemas de bases de datos utilizaban esos computadores
de un modo parecido a como utilizaban los terminales de visualización, de modo que el DBMS seguía
siendo un DBMS centralizado en el que toda la funcionalidad DBMS, ejecución de aplicaciones e
interacción con el usuario se llevaba a cabo en una máquina. Gradualmente, los sistemas DBMS
empezaron a aprovecharse de la potencia de procesamiento disponible en el lado del usuario, lo que
llevó a las arquitecturas DBMS cliente/servidor. La figura 11 muestra los componentes fisicos de una
arquitectura centralizada.
 21

Figura 11.- Arquitecura Centralizada

2.- Arquitecturas cliente/servidor básicas

La arquitectura cliente/servidor se desarrolló para ocuparse de los entornos de computación en los que
una gran cantidad de computadores, estaciones de trabajo, servidores de archivos, impresoras,
servidores de bases de datos, servidores web y otros equipos están conectados a través de una red. La
idea es definir servidores especializados con funcionalidades específicas. Ejemplo: conectar varios PC
como clientes a un servidor de archivos que mantiene los archivos de las máquinas cliente. Los servidores
web o servidores de correos también han caído en la categoría de servidores especializados. De este
modo, muchas máquinas cliente pueden acceder a los recursos proporcionados por servidores
especializados. Las máquinas cliente proporcionan al usuario las interfaces apropiadas para utilizar estos
servidores, así como potencia de procesamiento local para ejecutar aplicaciones locales.
La siguiente figura muestra una arquitectura cliente/servidor en el nivel lógico.

Figura 12.- Arquitectura Cliente Servidor

Los dos tipos principales de arquitecturas DBMS básicas se crearon sobre esta estructura
cliente/servidor fundamental: dos capas y tres capas.

2.1.- Arquitecturas cliente/servidor de dos capas para los DBMSs

La arquitectura cliente/servidor se está incorporando progresivamente a los paquetes DBMS

comerciales.
 22

En una arquitectura cliente/servidor, los programas de interfaz de usuario y los programas de aplicación
se pueden ejecutar en el lado del cliente. Cuando se necesita acceso DBMS, el programa establece una
conexión con el DBMS (que se encuentra en el lado del servidor); una vez establecida la conexión, el
programa cliente puede comunicarse con el DBMS. El estándar Conectividad abierta de bases de datos
(ODBC, Open Database Connectivity) proporciona una interfaz de programación de aplicaciones (API,
application programming interface) , que permite a los programas del lado del cliente llamar al DBMS,
siempre y cuando las máquinas cliente y servidor tengan instalado el software necesario. La mayoría de
los fabricantes de DBMSs proporcionan controladores ODBC para sus sistemas. Un programa cliente
puede conectar realmente con varios RDBMSs y enviar solicitudes de consulta y transacción utilizando
la API ODBC, que después son procesadas en los sitios servidor. Los resultados de una consulta se envían
de regreso al programa cliente, que procesará o visualizará los resultados según las necesidades.

2.2.- Arquitecturas de tres capas y n capas para las aplicaciones web

Muchas aplicaciones web utilizan una arquitectura de tres capas, la cual añade una capa intermedia
entre el cliente y el servidor de la base de datos, como se ilustra en la Figura 13.-
Esta capa intermedia se denomina a veces servidor de aplicaciones y, en ocasiones, servidor web. Este
servidor juega un papel intermedio almacenando las reglas comerciales (procedimientos o restricciones)
Los clientes contienen interfaces GUI y algunas reglas comerciales adicionales específicas de la
aplicación.
El servidor intermedio acepta solicitudes del cliente, las procesa y envía comandos de bases de datos al
servidor de bases de datos, y después actúa como un conducto para pasar datos procesados
(parcialmente) desde el servidor de bases de datos a los clientes, donde son procesados de forma más
avanzada para su presentación en formato GUI a los usuarios. De este modo, la interfaz de usuario, las
reglas de aplicación y el acceso de datos actúan como las tres capas.

Figura 13.- Arquitectura tres capas

Es costumbre dividir las capas entre el usuario y los datos almacenados en componentes aún
más sutiles, para de este modo llegar a arquitecturas de n capas, donde n puede ser cuatro
o cinco. Normalmente, la capa lógica comercial está dividida en varias capas. Además de
distribuir la programación y los datos por la red, las aplicaciones de n capas ofrecen la ventaja
de que cualquiera de las capas se puede ejecutar en un procesador adecuado o plataforma
de sistema operativo, además de poderse manipular independientemente. Otra capa que los
 23

fabricantes de paquetes ERP (planificación de recursos empresariales) y CRM (administración

de la relación con el cliente) suelen utilizar es la capa middleware, que da cuenta de los
módulos front-end que comunican con una determinada cantidad de bases de datos back-
end.
Los avances en la tecnología de cifrado y descifrado hace más segura la transferencia de datos
sensibles cifrados desde el servidor hasta el cliente, donde se descifran. Esto último lo puede
hacer hardware o software avanzado. Esta tecnología otorga unos niveles altos de seguridad
en los datos, aunque los problemas de segu- ridad en las redes siguen siendo la principal
inquietud. Distintas tecnologías de compresión de datos también ayudan a transferir grandes
cantidades de datos desde los servidores hasta los clientes a través de redes cableadas e
inalámbricas.
 24

MODELOS DE DATOS
Una característica relevante de la metodología de bases de datos es que ofrece algún nivel
de abstracción de los datos. La abstracción de datos corresponde a suprimir detalles de la
organización y el almacenamiento de datos, dando relevancia a las características
fundamentales para un conocimiento mejorado de los datos.
Una de las características principales de la metodología de bases de datos es que soporta la
abstracción de datos para que diferentes usuarios.

Un modelo de datos (colección de conceptos que se pueden utilizar para describir la estructura
de una base de datos) proporciona los medios necesarios para conseguir la abstracción de lols
datos y representar las propiedades estáticas y dinámicas del mundo real.

Todo modelo de datos deben representar las siguientes propiedades:

Propiedades estáticas: objetos de información (entidades), propiedades de los objetos

(atributos), relaciones entre objetos, y restricciones sobre los objetos o sus relaciones.
Propiedades dinámicas: operaciones sobre los objetos o sus relaciones, relaciones entre
operaciones (transacciones), y restricciones sobre la evolución de los objetos y sus relaciones
Los modelos de datos tienen por objetivo conseguir un mayor grado de independencia de datos,
separar la definición estructural (lógica) de la base de datos de su definición física (interna), de
forma que los programas sean independientes.

I.- Modelos de Datos Dependientes de la Tecnología

Corresponden a aquellos modelos de datos procesables por algún DBMS, generalmente, utilizado como
modelo interno. Los modelos serán analizados en base a la estructura de datos sobre la cual se sustentan.

1.- MODELOS DE DATOS JERÁRQUICO

Uno de los primeros modelos de datos utiliza jerarquías o árboles para la representación lógica de los
datos.
Este modelo representa problemas por su poca flexibilidad, lo que da origen a una falta de adaptación a
muchas organizaciones reales.

Este modelo fue desarrollado para permitir la representación de aquellas situaciones de la vida real en
las que predominan las relaciones de tipo 1 : N.
Es un modelo muy rígido en el que las diferentes entidades de las que está compuesta una determinada
situación, se organizan en niveles múltiples de acuerdo a una estricta relación PADRE/HIJO, de manera
que un padre puede tener más de un hijo, todos ellos localizados en el mismo nivel, y un hijo únicamente
puede tener un padre situado en el nivel inmediatamente superior al suyo. Esta estricta relación
 25

PADRE/HIJO implica que no puedan establecerse relaciones entre segmentos dentro de un mismo nivel.
La representación gráfica de un modelo jerárquico se realiza mediante la estructura de ARBOL
INVERTIDO, en la que el nivel superior está ocupado por una única entidad, bajo la cual se distribuyen el
resto de las entidades en niveles que se van ramificando.
Los diferentes niveles quedan unidos por medio de las relaciones, Las entidades se denominan en el caso
particular del modelo jerárquico SEGMENTOS, mientras que los atributos reciben el nombre de CAMPOS.
Los segmentos, se organizan en niveles de manera que en un mismo nivel estén todos aquellos
segmentos que dependen de un segmento de nivel inmediatamente superior.

Figura 14.- Modelo de datos Jerarquico

2.- MODELOS DE DATOS DE RED

En este modelo las entidades se representan como nodos y sus relaciones son las líneas que los unen.
En esta estructura cualquier componente puede relacionarse con cualquier otro. El Modelo de Red se
puede entender como una extensión del modelo jerárquico. También se presenta mediante un árbol,
pero en este caso, cada hijo puede tener varios padres. De este modo se reducen, o eliminan, las
redundancias, Pero desaparece la herencia de los campos. La integridad de datos, asociada a los arcos
padre-hijo, se mantiene. Una Base de Datos de Red se compone de dos conjuntos:
• El Conjunto de los Registros. Un conjunto de instancias múltiples de varios tipos de registros.
• El Conjunto de las Relaciones. Un conjunto de instancias múltiples de varios tipos de relaciones.

Este modelo representa a los datos como un conjunto (set) de tipos de registros y asociaciones entre
ellos. Se utiliza como estructura de datos un grafo, por lo que un tipo de registro puede tener numerosas
asociaciones con otros tipos de registros, del tipo 1:1, 1:M y M:N.
 26

Figura 15.- Modelo de datos de Red

II.- Modelos Independientes de la Tecnología

1. MODELO DE DATOS ORIENTADO DE OBJETOS

Los sistemas basados en modelos de datos orientados a objeto fueron inspirados a partir del paradigma
de programación orientada a objeto. El paradigma de programación orientada a objetos incluye el
concepto de tipos abstractos de datos en lenguajes de programación.
Las declaraciones de tipos abstractos de datos explícitamente se definen públicos y privadas en algunas
porciones de la estructura de datos, u objetos.
Los tipos abstractos de datos en unlenguaje orientado a objeto, son implementados en clases, es decir,
encapsula porción privada de datos del objeto en procedimientos públicos, llamados métodos. El
argumento para la encapsulación es uno de los más simples en la construcción y mantenimiento de
programas através de modularización. Un objeto es como una caja negra, que puede ser construida y
modificada independientemente del resto delsistema, tan grande como una interfaz pública(método) en
la cual las definiciones no cambian.No hay un sólo paradigma orientado a objeto, y por lo tanto hay una
variedad de modelos y como consecuencia diferentes estándares. Generalmente, los lenguajes de
programación orientados a objeto parten de conceptos comunes además de encapsulación, en particular
el uso de jerarquías de tipos de objetos con herencias en sus atributos y métodos. De cualquier modo,
las características específicas varían, y pueden regular la definición estricta de encapsulación provista
por tipos abstractos de datos - que los procedimientos son públicos, cuando los datos son privados. El
tipo de modelado también influye en la manera como son manejados los DBMS´s Orientados a Objeto.
Las bases de datos orientadas a objetos surgen básicamente para tratar de paliar las deficiencias de los
modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones.

Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos Orientadas a Objetos son:
• Pobre representación de las entidades del “mundo real”.

• Sobrecarga y poca riqueza semánticas.

 27

• Soporte inadecuado para las restricciones de integridad empresariales

• Estructura de datos homogénea

• Operaciones limitadas

• Dificultades para gestionar las consultas recursivas

• Problemas de impedancias de datos

• Problemas de concurrencia

• Inadecuado acceso navegacional.

Además no ofrece soporte para distintos tipos de usuarios(sólo dominios).

Los Sistema Gestor de Bases de Datos Orientadas a Objetos, son recomentadados en las siguientes
condiciones:
• Un gran número de tipos de datos diferentes

• Un gran número de relaciones entre los objetos

• Objetos con comportamientos complejos

Este tipo de condiciones se encuenyran de forma frecuente en aplicaciones de ingeniería,
manufacturación, simulaciones, automatización de oficina y en sistemas de información.

2.- MODELOS DE DATOS RELACIONAL

El modelo relacional es anterior al modelo orientado a objetos.

Este es el modelo de datos más utilizado hasta el día de hoy.
El modelo relacional es totalmente diferente a los modelos jerárquico y de red, no sólo en su
arquitectura, sino que también en los siguientes puntos:

F Independencia en la implementación: no es necesario conocer como se representan físicamente

los datos (no se necesita trabajar con punteros, listas enlazadas, grafos, etc.)
F Terminología: el modelo relacional tiene su propia terminología.
F Claves lógicas como punteros: usa claves primarias y foráneas para representar las asociaciones
entre dos archivos. No obstante, debido a la independencia en la implementación la base de
datos física puede usar punteros u otros métodos, pero éstos son transparentes para el usuario.
F Teoría de Normalización: esta teoría fue desarrollada en el contexto del modelo relacional, pero
hoy en día sus propiedades han sido extendidas a otros modelos. Consiste en un conjunto de
propiedades que deben cumplir los datos para lograr un diseño de base de datos libre de
dependencias y con el mínimo de redundancia.
F Lenguaje de programación comprensivo: existen lenguajes simples para accesar las bases de
datos relacionales, son lenguajes que permiten manipular datos como grupos o archivos, en vez
de un registro a la vez como los lenguajes procedurales tradicionales.
 28

Conceptos y Características de los Datos

Datos Versus Información

Estos dos términos son comúnmente usados como sinónimos, pero en el ámbito de este curso interesa
insistir en la diferencia que hay entre ellos.
Por dato se entiende a aquellos hechos relacionados con personas, objetos y eventos del mundo real,
que se almacenan en algún medio procesable por el computador. Normalmente los datos son poco útiles
para los tomadores de decisiones hasta que hallan sido procesados de alguna forma.
Por información se entiende al dato que ha sido procesado y formateado con el objetivo de apoyar la
toma de decisiones, o en general, las actividades de una organización.
En la práctica, sin embargo, la distinción es difícil de mantener. El dato pasa a ser información cuando es
usado en un contexto o escenario específico, o se aplica a la solución de un problema particular. Por lo
que su definición depende de como los datos (o información) son usados, más que de propiedades
inherentes a ellos.

Naturaleza del Dato

Para describir un dato deben considerarse tres niveles de abstracción o estados en que se encuentra el
dato. Estos se pueden visualizar en la Figura 16 y son: realidad, metadato y dato.

Eventos, Objetos Diccionario de Datos Base de Datos

y J J

Definición Tipo de Ocurrencia de

Clase de Entidades Registro Registro

Definición Itemes Ocurrencia de

Atributos de Dato Itemes de Dato

Realidad Metadato Dato (o valor)

Figura 16.- Niveles de Abstracción del Dato

REALIDAD

Comprende el mundo real (una organización), con sus componentes y el medio ambiente en el cual
opera. Cualquier organización se considera como un conjunto de personas, recursos financieros,
materiales y equipos, que son organizados para satisfacer ciertos objetivos; además posee una
interacción con el medio.
 29

Una entidad es una persona, objeto o evento sobre lo que la organización decide coleccionar y almacenar
datos. Una entidad puede ser tangible como un empleado, un producto, un computador o un cliente; o
intangible como una cuenta de un banco, un vuelo, un centro de costos.

Una clase de entidades es un conjunto de entidades que poseen características similares. Por ejemplo,
todos los clientes de una empresa. También se le llama tipo de entidades, y a veces, suele usarse
indistintamente el término entidad o clase de entidad.
En general, cada entidad es asociada a una y solo una clase de entidades. Sin embargo, esta asignación,
así como la definición de clase de entidades puede ser arbitraria, por ejemplo, la clase Empleados
involucra a los empleados con contrato fijo solamente o también a los con contrato a honorarios, la
respuesta va a depender del criterio del diseñador.
El número de clases de entidades por organización depende del tamaño y complejidad de ella. Por
ejemplo, una organización de tamaño medio define generalmente varios cientos de clases de entidades.

Un atributo es una propiedad de una clase de entidades que se desea almacenar. Para cada clase existe
un conjunto de atributos de interés para la organización. Por ejemplo, para la clase Empleado algunos
atributos de interés serían: Rut, Nombre, Dirección, Teléfono y Cargo.
Cada entidad dentro de una clase, debe poseer al menos un atributo (o una combinación de ellos) que
la distinga de otras entidades dentro de su clase. A este atributo se le llama identificador, llave o clave
primaria. Por ejemplo, el Rut para Empleado, Nro.Producto para Producto, Nro.Factura + Nro.Producto
para Pedido. Este atributo debe ser único, es decir, no pueden existir dos entidades con un mismo valor
para ese atributo dentro de una clase.

Otra propiedad de una entidad es la asociación o relacionamiento (relationship) entre dos o más clases
de entidades. Esta se verá más adelante.

Las entidades son del mundo real, pero en la práctica es difícil para un administrador tomar decisiones
en base a la observación directa de ellas. Por eso la organización requiere modelar estas entidades.

METADATO

Es información acerca de los datos de una organización. Se usa para desarrollar modelos lógicos de las
entidades y asociaciones de una organización. El metadato es almacenado y mantenido en el diccionario
de datos (o repositorio) de una organización.
Cada clase de entidad tiene un tipo de registro definido como metadato, cada atributo tiene un tipo de
ítem de dato como metadato.

Un ítem de dato es la unidad de dato más pequeña en una Base de Datos. Por ejemplo, Nombre del
Empleado, Rol del Alumno, Fecha de Orden de Compra. En el diccionario de datos se registra por cada
ítem de dato, información sobre su nombre, largo, tipo y una breve descripción narrativa de él.

Un dato agregado, es un conjunto de ítems de datos que son nombrados y referidos como un todo. Por
ejemplo, Fecha está compuesto de Día, Mes y Año. Debe registrarse información sobre ellos en el
diccionario de datos.
 30

Un tipo de registro es un conjunto de ítems de datos y/o datos agregados. La definición de un tipo de
registro para cada clase de entidades que se guarda en el diccionario de datos contiene por ejemplo:
nombre del registro, descripción, tamaño (o largo), ítems de datos, datos agregados e identificación de
clave primaria.

DATO (o valor)

Corresponde a ocurrencias de datos. Por cada entidad, existe una ocurrencia de registro que contiene
valores de ítem de datos que la representan.
Es importante distinguir la diferencia entre metadatos (definiciones del dato) y dato (ocurrencias del
dato). Los metadatos no son almacenados en la base de datos sino que en el diccionario de datos, los
datos (ocurrencias de datos) son almacenados en la base de datos.

Representación del Dato

Para representar los datos de una determinada realidad, consideremos dos aspectos básicos del
modelamiento de datos: entidades y asociaciones.
Una entidad, como ya se definió, es un objeto, evento o persona sobre la cual la organización decide
coleccionar y almacenar datos.

La asociación, es una conexión lógica entre entidades.

Para representar gráficamente estos elementos, utilizaremos la siguiente simbología propuesta por
Bachmann:

A Entidad A

A
Entidad A con atributos a, b, c y d
a b c d

Asociación
 31

Las asociaciones se caracterizan por:

a) Asociación del tipo UNA
UNA asociación de la entidad A a la B, significa que para un cierto período de tiempo habrá una
ocurrencia de la entidad A que tiene una y sólo una ocurrencia de la entidad B asociada a ella. Por
ejemplo, en un cierto instante un PACIENTE de un hospital está asignado a una CAMA. Esto se
representa:

PACIENTE CAMA

b) Asociación del tipo MUCHAS

Una asociación del tipo MUCHAS entre entidades A y B, significa que para un cierto período de
tiempo, habrá una ocurrencia de la entidad A que tiene cero, una o más ocurrencias de la entidad B
asociada a ella. Por ejemplo, un EMPLEADO puede tener cero, una o más CARGAS FAMILIARES. Esto
se representa:

EMPLEADO CARGAS

c) Asociación Condicional
Establece que para una ocurrencia de la entidad A existen dos posibilidades: que exista una ocurrencia
de una entidad B asociada a ella, o que no exista. Por ejemplo, en un hospital una CAMA es asignada
a solo un PACIENTE o está desocupada en un cierto instante de tiempo. Esto se representa:

PACIENTE CAMA

d) Asociaciones en ambos sentidos

Si existe una asociación entre ocurrencias de la entidad A con la B, también existe entre B con A. Esto
genera tres tipos de asociaciones:

1:1 PACIENTE CAMA UNO-A-UNO

1:M EMPLEADO CARGAS UNO-A-MUCHOS

M:N ALUMNO ASIGNATURAS MUCHOS-A-MUCHOS

 32

Considerando este tipo de asociaciones entre entidades, ya podemos comenzar a obtener un Modelo de
Datos (MD) que represente a un conjunto de entidades y asociaciones. Por ejemplo, en la Figura 17 se
visualiza un posible MD para una Universidad.
En este ejemplo, se puede visualizar una situación muy común en las asociaciones M:N, esto es que sean
transformadas en dos asociaciones de 1:N, con una nueva entidad haciendo de intersección entre las
entidades asociadas como M:N, a esta nueva entidad se le denomina NUB. En nuestro caso entre
ALUMNO y ASIGNATURA es posible crear una nueva entidad NOTA que contenga la calificación del
alumno al cursar ese ramo (suponer que si el alumno reprueba, siempre se guarda la nota de la última
vez en que cursó el ramo). Gráficamente, esto se visualiza en la Figura 17.
La nueva entidad generada requiere de una clave primaria compuesta o concatenada. Esto es dos o más
ítems de datos que permiten identificar en forma única a cada entidad.

DEPTO. CARRERA

ALUMNO ASIGNATURA

SOLICITUD

Figura 17.- Ejemplo Modelo de Datos para una Universidad

ALUMNO ASIGNATURA

CLAVE-ASIGNATURA
ROL-ALUMNO
NOM-ASIGNATURA
NOM-ALUMNO
CREDITOS
DESCRIPCION

NOTA

ROL-ALUMNO
CLAVE-ASIGNATURA
NOTA

Figura 18.- Ejemplo Transformación de Asociación M:N en dos Asociaciones 1:N

 33

Es posible que se requiera asociar tres o más entidades, para ello también se utiliza un tipo de registro
de intersección, el cual tendrá como clave primaria una clave compuesta por los ítems de datos que son
clave primaria en cada una de las entidades involucradas. Por ejemplo, en la Figura 19 se visualiza un MD
para el Sistema de Abastecimiento de una Fábrica en donde la entidad ORDEN-COMPRA hace de
intersección entre las entidades MATERIA-PRIMA, BODEGA y PROVEEDOR.

MATERIA-PRIMA BODEGA

#BODEGA
#MAT-PRIMA
DIRECCION-B
DESCRIPCION

INVENTARIO

#MAT-PRIMA
#BODEGA
CANTIDAD

ORDEN-COMPRA PROVEEDOR

#MAT-PRIMA #PROVEEDOR
#BODEGA NOMBRE-P
#PROVEEDOR DIRECCION-P
CANT-A-ORDENAR

Figura 19.- Ejemplo de Asociación entre más de dos Entidades

e) Múltiples asociaciones entre dos entidades

Al modelar datos a veces es conveniente dos o más asociaciones entre dos tipos de entidades para
aprovechar una misma descripción o contenido de un tipo de registro. Por ejemplo si se tiene lo
siguiente:

ASEGURADO BENEFICIARIO

RUT RUT
NOMBRE NOMBRE
DIRECCION
DIRECCION

POLIZA

#POLIZA
FECHA, MONTO
RUT-A
RUT-B
 34

Es posible definir una sola clase de entidad (PERSONA) la cual se relacionaría con PÓLIZA de dos formas:
como asegurado o como beneficiario.

PERSONA POLIZA
Asegurado
#POLIZA
RUT FECHA, MONTO
NOMBRE RUT-A, RUT-B
Beneficiario
DIRECCION

Cuando existen dos o más asociaciones entre dos entidades, cada asociación debe ser rotulada con
un nombre que clarifique la asociación. En general, esto complica la legibilidad del modelo, por ello
es conveniente ser lo más simple para representar estas asociaciones.

f) Asociaciones Recursivas (Loops)

Es posible que se requiera describir asociaciones entre entidades de una misma clase, a esto se le
llama asociaciones recursivas o loops. Existen de tres tipos:

1:1
Existen EMPLEADOS que son casados
entre ellos, es decir, tienen una
EMPLEADO Casado-con asociación 1:1, pero es posible que
sólo algunos sean casados entre
ellos, por lo que deberá ser una
asociación condicional.

1:N
Si se supone que cada empleado
tiene sólo un jefe, entonces puede
EMPLEADO existir una asociación de jefe a
Jefe-de
subordinado.
 35

M:N Un PRODUCTO se compone de otros

PRODUCTOS (piezas) y éstos a su vez de
PRODUCTO otros, y así sucesivamente.
Componentes

Una asociación M:N como la anterior, puede también ser reducida a una o más asociaciones 1:N usando
una entidad de intersección. Nuestro ejemplo anterior quedaría:

PRODUCTO PIEZA

#PRODUCTO #PIEZA
NOMBRE #COMPONENTE
ETC. CANT-USADA

El #PIEZA corresponde al #PRODUCTO de aquel producto que se divide en otras componentes. Cada
componente de ese producto se identifica por el #COMPONENTE (el cual también corresponde a un
#PRODUCTO). CANT-USADA indica cuanto usa la pieza #X del componente #Y. Por ejemplo, si se tiene
la siguiente ocurrencia de PIEZA:

X Y 20

Estos datos corresponderían al evento que la pieza (o producto) X, usa 20 unidades de la componente
Y (o producto).
 36

Referencias
1. Elmasri, R., Díaz Martín, J. and Navathe, S., (2011) Fundamentos de Sistemas de Bases de
Datos. Pearson Educación. Madrid.

2. Date, C. J. (2001). Introducción a los sistemas de bases de datos. Pearson Educación