Cap1-Apuntes.pdf

EX UMBRA SOLEM
IN
CAPITULO 1: CONCEPTOS GENERALES
1.1. Dato como un Recurso
En las organizaciones se ha reconocido la necesidad de incorporar al dato como un
recurso más (así como tradicionalmente lo han sido los recursos humanos, financieros y
materiales); por lo cual, el dato debe ser planificado, administrado 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.
El dato, si bien tiene un rol diferente al resto de los recursos de una empresa, tiene
con ellos una característica común importante: tiene un costo y un valor asociado. Siendo
por ello de vital importancia un eficiente y efectivo tratamiento del recurso dato (o
información).
Es posible diferenciar dato de información de la siguiente manera:
Dato: hechos relacionados con personas, objetos, eventos u otras entidades del mundo
real (empresa, sistema, etc.). Pueden ser cuantitativos (financieros) o cualitativos
(subjetivos), 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 lista de productos y su stock sin
ningún orden son datos, pero un lista de productos ordenados por stock (de menor a
mayor) representa información para el encargado de compras de un supermercado quién
debe tomar decisiones del tipo: cuándo y en cuánto reponer el stock de cada producto.
Para lograr un efectivo tratamiento del recurso dato, las organizaciones requieren
usar 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 visualizar en la Figura 1.1, donde se concibe
a la base de datos como un conjunto de archivos relacionados que pueden ser accesados por
numerosos usuarios, a través de distintos medios como por ejemplo programas de
aplicación, directamente a través de una estación de trabajo o vía teléfono.

EX UMBRA SOLEM
IN
!
Usuario A Programa de
Aplicación Bodega
Usuario B Insumo
…….
Usuario N Proveedor
Figura 1.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 van a permitir satisfacer diversos requerimientos de
información (por datos operacionales se entiende a aquellos datos que usa la organización
para su normal funcionamiento). Esta definición de base de datos queda representada en la
Figura 1.2.
Una organización generalmente puede escoger entre una o más bases de datos en un
computador central (servidor); o una base de datos distribuida en los distintos nodos
(clientes) de la red existente en la organización.
Nivel Planificación P F P M
R I E A
O N R R
D A S K BASE DE
Nivel Táctico U N O E
C Z N T DATOS
C A A I
I S L N
Nivel Operacional O G
N
Figura 1.2.- Base de Datos desde perspectiva organizacional

EX UMBRA SOLEM
IN
"
1.2. Enfoque de Procesamiento de Datos
El enfoque utilizado en el desarrollo de sistemas de información (SI) para el
tratamiento de los datos en la década de los 70, se relacionaba con el procesamiento de
datos por departamento (o unidad organizacional), es decir, los sistemas de información
respondían a requerimientos de usuarios por aplicaciones individuales como
remuneraciones, cuentas corrientes, contabilidad, control inventario, etc. Cada sistema
desarrollado era diseñado, entonces, para satisfacer las necesidades de un departamento o
grupo de usuarios, no existiendo una planificación corporativa o un modelo que guiara el
desarrollo de aplicaciones.
Este enfoque se conoce como Enfoque por Agregación y en la Figura 1.3 se puede
visualizar 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 (marcado por
un óvalo) 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 considerados en el momento del
diseño inicial del sistema.
A
B C D
E F G H I
Figura 1.3.- Enfoque por Agregación Perspectiva Organizacional

EX UMBRA SOLEM
IN
#
1.2.1.- Sistemas de Procesamiento de Archivos
Cada nueva aplicación era diseñada con su propio conjunto de archivos de datos.
Muchos de esos datos podían ya existir en archivos de otras aplicaciones, pero para ser
usados en la nueva aplicación requerían de reestructuración, lo cual era muy complejo
dado que era 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 era más
simple diseñar nuevos archivos para cada aplicación.
En la figura 1.4 se ilustra este enfoque desde una perspectiva computacional.
Programas de aplicación pueden accesar, según la figura, uno o más archivos de datos, 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.
Figura 1.4.- Enfoque por Agregación Perspectiva Computacional
Programa
Facturación
Archivo
Clientes
Archivo
Cuentas
Pagadas
Programa
Compras
Archivo
Empleado
Archivo
Inventario
Materiales
Archivo
Proveedor
Programa
Cuentas por
Pagar
Programa
Ventas
Programa
Sueldos
Archivo
Proveedor
Archivo
Factura
Archivo
Clientes
Archivo
Inventario
Productos
Archivo
Emplea-
dos

EX UMBRA SOLEM
IN
$
1.2.2.- Desventajas
Las desventajas del enfoque tradicional de procesamiento de datos se resumen en:
REDUNDANCIA NO CONTROLADA
Al tener cada aplicación sus propios archivos existe 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 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 porqué el sistema no puede darles la
información que necesitan en el nuevo formato requerido, a pesar 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.

EX UMBRA SOLEM
IN
%
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. Es así como el esfuerzo de programación que se realizaba en
los Departamentos de Procesamiento de Datos, era mayoritariamente (cerca del 80%)
centrado en tareas de mantención de los programas existentes.
1.3.- Enfoque de Base de Datos
En este enfoque los datos son vistos como un recurso que debe ser compartido entre
diferentes usuarios. Cada usuario puede contar con una visión (view) propia de la base de
datos, de acuerdo a sus requerimientos de información. Los datos son almacenados de tal
manera que son 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
que no están directamente asociados con los programas de aplicaciones (ver Figura 1.5).
Figura 1.5.- BD como un conjunto de archivos relacionados
Archivo
Clientes
Archivo
Cuentas
Pagadas
Archivo
Empelados
Archivo
Inventario
Archivo
Proveedor
Archivo
Factura
Archivo
Balance
Archivo
Estadísticas
Ventas

EX UMBRA SOLEM
IN
&
1.3.1.- Elementos del Enfoque de Base de Datos
Los principales elementos de este enfoque y sus relaciones se muestran en la Figura 1.6.
Administradores de BD Desarrolladores de SI Usuarios Finales
Herramienta CASE Interface Usuario Programas de
Aplicaciones
Reposi-
torio DBMS BD
Figura 1.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.
Corresponden a ejecutivos, contadores, secretarias, etc. y son quienes utilizan la base de
datos durante su ciclo de vida. 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: o de aplicaciones, personas como analistas de sistemas y
programadores que diseñan nuevos programas de aplicación. A menudo se apoyan en
herramientas CASE.

EX UMBRA SOLEM
IN
'
Administradores de Bases de Datos: personas responsables por el diseño, construcción,
implementación y desempeño en el tiempo de la base de datos, además, de 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 en forma centralizada o
distribuida, y también el repositorio. Dependiendo de la estructura de datos utilizada para
organizar los datos, se clasifican en: jerárquicos (árbol), redes (grafo), relacional (tabla),
objetual (objeto). Los DBMS más usados son los relacionales (RDBMS), ejemplos de ellos
son: Oracle, DB/2 de IBM, Microsoft SQL Server, SYBASE, PostgreSQL, MySQL.
En general, las principales funciones de un DBMS son:
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 (por ejemplo SQL: Structured
Query Language).
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 (por ejemplo SQL), 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, PHP, ASP, HTML, XML, Java, JavaScript, entre otros.
Seguridad de Datos: el dato 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 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, por ejemplo, los datos de
estudiantes están dentro de una Base de Datos universitaria. Puede ser una Base de Datos
Centralizada (completamente almacenada en un computador central, sea éste un mainframe

EX UMBRA SOLEM
IN
(
un PC stand alone, un servidor en una arquitectura Cliente/Servidos, 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.
5.- INTERFACE USUARIO:
Son lenguajes, menus, pantallas, sistemas Web, sistemas de reconocimiento de la voz, etc.
que permiten a los usuarios interactuar con los distintos componentes del sistema. La
interface es cada día más amigable para el usuario de tal manera de incentivar 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 poblar y mantener las Bases 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 Bases 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:
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.
Lower-CASE: automatizan las tareas finales del ciclo de vida, es decir, generación de
código, prueba y mantención.

EX UMBRA SOLEM
IN
)
1.3.2.- Implementación del Enfoque de Base de Datos
Los elementos mencionados en tópico anterior son los componentes principales de
un enfoque de Base de Datos, cabe ahora mencionar que la implementación de una Base de
Datos en la organización puede esquematizarse como en la Figura 1.7.
Figura 1.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 BD. Se hace una distinción entre BD lógica y física; por
la primera se entiende al esquema conceptual de la Base de Datos (definición de archivos y
asociaciones), y por la segunda, al lugar físico donde quedan almacenados los archivos y
sus asociaciones. Esta distinción muestra claramente una de las ventajas del enfoque de
BD: independencia de los datos de los programas.
Modelo de Datos
Conceptual
Consulta
(Query)
Compilador
DDL
Traductor
DML
BD Lógica
(Schema)
Requerimientos
Definición BD
Programa de
Aplicación
DBMS
BD Física
Modelamiento Datos
(rara vez)
Creación BD
(rara vez) (pocas veces) (frecuentemente)
Programador Usuario Final
Uso BD

EX UMBRA SOLEM
IN
Además, es importante mencionar 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. Esta etapa
puede ser apoyada por herramientas de software del tipo CASE.
1.3.3.- 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.
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 qué 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.

EX UMBRA SOLEM
IN
!
ESFUERZO POR ESTANDARIZACION
Establecer la función de Administración de Bases 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 (convenciones de nombres, controles para la calidad de los datos, procedimientos
uniformes, etc.), así como también posteriores cambios de estándares. El Diccionario de
Datos se constituye en una poderosa herramienta para apoyar la estandarización.
CONTROLES DE PRIVACIDAD E INTEGRIDAD
La función Administración de de Bases de Datos es responsable por establecer controles
que permitan asegurar la calidad de 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. El DBMS para esto, provee mecanismos para definir
perfiles de acceso que controlen accesos no autorizados, y reglas de validación que
aseguren la integridad del dato ingresado.
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. En el caso de Base de Datos Relacionales
se destaca el SQL como un poderoso lenguaje de consultas.
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.
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.

EX UMBRA SOLEM
IN
"
Los beneficios mencionados dependen mucho del DBMS con que se cuente, es
posible por ejemplo que la independencia de datos (y por ende, la reducción en la
mantención) no esté presente tan fácilmente en los sistemas de Base de Datos más antiguos,
pero no así en los sistemas relacionales.
Otra razón por la cual puede fracasarse en la obtención de los beneficios
mencionados, es la pobre planificación organizacional en informática (y en 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 y administrar Bases de Datos, como también
organizar a un nuevo staff de personas.
NECESIDAD DE RESPALDOS Y MECANISMOS DE RECUPERACION
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 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.

EX UMBRA SOLEM
IN
#
1.4. Las Bases de Datos en el Proceso de Desarrollo de Sistemas de Información
1.4.1.- Tipos de Sistemas de Información
Los Sistemas de Información (y las Bases 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
Largo Plazo
Control
Gerencial
Control
Operacional
Tipo de Decisión No Estructurada Semi
Estructurada
Estructurada
Modelo más usado Predictivo Descriptivo Normativo
Características de la
Información:
Fuente Medio Ambiente Registros Internos Operación Interna
Exactitud Razonable Buena Exacta
Amplitud Resumida Detallada Muy Detallada
Frecuencia A Solicitud Periódica Tiempo Real
Rango de Tiempo Años Años Meses
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).

EX UMBRA SOLEM
IN
$
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. Una estación de trabajo (a menudo un PC) ubicado en la oficina del tomador de
decisiones o en otro lugar adecuado.
2. Un DBMS para crear, accesar y mantener Bases de Datos centralizadas 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 1.8. En este ejemplo un
PC (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.
Figura 1.8.- Ejemplo de un DSS
Requerimientos de Información
Computador Central
Computador Personal
Query Planilla
DBMS
Subcjto.BD
BD`s Corporativas
Archivo
Local

EX UMBRA SOLEM
IN
%
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:
Herramientas extractoras, de transformación y carga para los datos operacionales
y fuentes externas.
Un warehouse (almacén) para almacenar los datos seleccionados.
Herramientas para 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 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, para a partir de ella generar
conocimiento que permita rentabilizar mejor a la organización. Para ello, se necesitan
sistemas de información inteligentes, así aparece una nueva generación de sistemas, dentro
de los cuales están los sistemas OLAP, y el uso de algoritmos de Data Mining (redes
neuronales, árboles de decisión, análisis estadístico, etc.), que junto al Data Warehouse
constituyen las tendencias más importantes en el área de bases de datos del último tiempo,
y que se engloban todas ellas bajo el nombre de Inteligencia de Negocios (para mayores
antecedentes ver Capítulo 6).
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, los sistemas OLAP funcionan mejor si hay un Data
Warehouse (implementado como una Bases de Datos Multidimensional) que integre y
depure los datos provenientes de los distintos sistemas OLTP de una organización, y que
permita visualizarlos como un cubo multidimensional y no como una tabla bidimensional.

EX UMBRA SOLEM
IN
&
1.4.2.- Metodologías de Desarrollo
El enfoque de BD altera el desarrollo tradicional de SI (Figura 1.9) 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 una realidad 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 (ver capítulos 2 y 3). 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.
El proceso de desarrollo de un sistema o software puede ser abordado desde la
perpectiva de los procesos que se desean automatizar (esto se estudia en la asignatura
Fundamentos de Ingeniería de Software) o desde la perspectiva de los datos que el sistema
require manejar (enfoque de la asignatura Bases de Datos).
Desde la perspectiva de los datos, se considera necesario 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.

EX UMBRA SOLEM
IN
'
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 1.9.- Etapas Tradicionales del Ciclo de Vida de un SI

EX UMBRA SOLEM
IN
(
1.5.- Tipos de Bases de Datos
Evolución. Base de Datos Centralizada versus Base de Datos Distribuida
En los años 70, el acceso a los computadores (en su mayoría equipos tipo
mainframes) era controlado estrictamente por los Departamentos de Informática (o
Procesamiento de Datos), y se accedía a los datos allí almacenados a través de tarjetas
perforadas o terminales primitivos. Se presenció posteriormente una evolución en el
almacenamiento y recuperación de los datos, a través del modelo de datos relacional; sin
embargo, los recursos computacionales seguían siendo centralizados y con interfaces
hostiles al usuario.
En los años 80, se produce el gran cambio con la llegada del PC. El usuario cuenta
ahora con ciclos de CPU, almacenamiento y recuperación de datos, y software amistoso, en
su propio escritorio. Sin embargo, los PCs son incapaces de manejar las necesidades de
procesamiento de datos de la mayoría de los grandes negocios. La solución a esto, la
proporcionan las redes de área local, al conectar los PCs con los mainframes; así el PC, se
comienza a usar como un terminal amistoso para el usuario. Al mismo tiempo, se produce
la evolución de los servidores de archivos e impresión basados en redes.
En los últimos años, la creciente tendencia en las organizaciones a delegar
responsabilidad informática a los departamentos usuarios, se ha visto sustentada en un
modelo computacional que se presta particularmente bien para ello, se trata del modelo
cliente/servidor (C/S), que conceptualmente, no es sino la separación de funciones de
procesamiento de información entre un sistema que requiere de uno o más servicios
(cliente) y uno o más sistemas que proveen dichos servicios (servidor). Ambos requieren
estar enlazados a través de una red.
Por otra parte, se puede establecer que desde la perspectiva de los datos, esta
evolución se ve reflejada en los modelos que sustentan las bases de datos, y en específico,
los DBMS que permiten definirla y manejarla.
Las primeras bases de datos, se sustentan en un modelo jerárquico que organiza los
datos bajo la visión de una estructura de árbol, luego dada la imposibilidad de manejar
relaciones complejas en él, aparece el modelo de redes basado en un grafo, que si bien
elimina las dificultades del modelo jerárquico, su complejidad en la manipulación lo deja
rápidamente obsoleto.
En los años 80, el modelo relacional aparece como una alternativa sencilla de
manejar: los datos son concebidos como tablas (o relaciones matemáticas) que poseen
asociaciones entre ellas (columnas o atributos claves comunes).
Es así como el almacenamiento y recuperación de los datos se simplifica, pero
siempre con un control centralizado de ellos. Luego al aparecer las redes de computadores,

EX UMBRA SOLEM
IN
!)
y la arquitectura cliente/servidor (1990); el modelo relacional se adapta a ellas, permitiendo
la distribución de sus tablas a través de los distintos nodos de una red.
Base de Datos Centralizada
Cuando la base de datos reside completamente en el computador central, sea éste un
mainframe, un PC aislado o un servidor central en una arquitectura C/S (ver Figura 1.10),
se dice que se tiene una base de datos centralizada. Esto implica que allí también reside el
DBMS que la soporta. Estas bases de datos en comparación con las bases de datos
distribuidas, se caracterizan por ser fáciles de implementar, difíciles de acceder desde sitios
remotos, generan un alto costo de comunicación y una baja disponibilidad, ya que cualquier
caída en el sistema central, significa que no hay acceso a los datos contenidos en ella.
Figura 1.10. Base de Datos Centralizada en Arquitectura C/S
Arquitectura Cliente/Servidor
Es importante mencionar algunos antecedentes sobre la arquitectura cliente/servidor
antes de estudiar las bases de datos distribuidas. Esta arquitectura es, en su esencia, una
arquitectura de procesos distribuidos en una red, en donde se definen claramente dos roles:
los procesos clientes, que solicitan servicios; y los procesos llamados servidores, cuyo
papel es atender estas solicitudes.
Sin embargo, clientes y servidores son independientes entre sí, debido a que un
proceso servidor puede atender requerimientos de cualquier proceso cliente, sin importar el
ambiente de hardware o software en que residan ambos procesos. Por concepción, el
proceso cliente lo es siempre, en cambio, un proceso servidor puede transformarse en
cliente de otro servidor en un momento dado.
B D
N o d o 3
N o d o 1
N o d o 2
S e r v i d o r B D
N o d o
C e n t r a l

EX UMBRA SOLEM
IN
!
Además, existen algunos conceptos que es necesario diferenciar en una arquitectura
cliente/servidor como son:
La Base de Datos, pudiendo ser relacional o no relacional (bidimensional o
multidimensional), en uno o más servidores, locales o remotos.
La Lógica del Negocio o de la Aplicación, que contiene las reglas del negocio que
accesan los datos, los transforman y resuelven algún requerimiento cualquiera.
Corresponden a los procedimientos almacenados y triggers escritos en SQL.
La Lógica de la Presentación, que le permite a la aplicación mostrar los datos básicos
o ya transformados en información, en algún formato adecuado para el usuario final.
Corresponde al código que representa la GUI (Graphic User Interfaces).
Es decir, una aplicación a ser desarrollada en esta arquitectura tiene tres partes o capas:
presentación (front-end), reglas del negocio y datos (back-end).
La presentación son los forms, menúes, ventanas, y validaciones en el ingreso de datos
(código escrito por ejemplo en Power Builder, Visual Basic o Java). Las reglas del negocio
son los procesos mismos que realiza el negocio y que se desean automatizar. Los datos
representan el almacenamiento, acceso y mantención de la base de datos que contiene el
registro de las transacciones que se llevan a cabo en el negocio.
De esta manera una aplicación desarrollada bajo esta arquitectura tiene estos tres
elementos. Dependiendo donde se ubiquen estos conceptos o que tan separados están entre
ellos es el tipo de arquitectura cliente/servidor utilizada.
Estas tres capas definen el modelo cliente/servidor; una aplicación desarrollada en él,
sigue una de las cinco clases que se visualizan en la Figura 1.11. Cualquiera de las capas de
una aplicación puede residir tanto en el cliente como en el servidor. Pero la aplicación
obtiene su mejor rendimiento cuando el código de la presentación reside en el cliente y la
capa de datos en el servidor. Esta separación permite que el procesamiento de aplicaciones
distribuidas sea muy rápido, dejando en el escritorio del cliente (donde los ciclos de
procesamiento son más baratos) código que libera de carga al servidor, quién sólo se
debiera preocupar del código que maneja los datos. Presentación Remota y Manejo de
Datos Remoto son las clases más comunes en el ambiente cliente/servidor. Manejo de
Datos Distribuido, si bien no es tan usada, tiene la gracia de entregar una plataforma que
facilita la implementación de Bases de Datos Distribuidas (BDD).

EX UMBRA SOLEM
IN
!!
Figura 1.11. Clases de Arquitectura Cliente/Servidor
En una base de datos en una arquitectura cliente/servidor el cliente corre una
aplicación que envía un comando al servidor (tradicionalmente, un comando SQL). Esta
aplicación debe tener una API (Application Program Interface) que le permita
interactuar con el DBMS que se va a utilizar. Una API es una biblioteca de llamadas a
funciones que enrutan los comandos SQL desde la aplicación cliente (front-end) hacia el
servidor de base de datos (back-end). Las APIs permiten tener clientes con diversos tipos
de sistemas operativos, corriendo aplicaciones diferentes, que están unidas por una base de
datos común. A este tipo de software se le denomina en forma genérica middleware.
Es decir, una API es una colección de funciones que un programador puede usar
para hacer que una base de datos efectúe las tareas que se desean. La API proporciona una
forma de abrir conexiones a la base de datos, enviar y recibir datos y efectuar casi cualquier
otra operación. Una API habilita a un front-end para interactuar con el servidor de la base
de datos a un nivel íntimo que permita un mejor desempeño.
Una de las APIs más comúnmente usada es ODBC (Open Data Base
Connectivity) que permite tener acceso a cualquier base de datos que posea un controlador
(o driver) ODBC. Es la API que utilizan las aplicaciones clientes/servidor basadas en
Windows. Ver Figura 1.12.
Presentación
Lógica Negocio
Manejo de datos Manejo de datos Manejo de datos Manejo de datos Manejo de datos
Lógica Negocio Lógica Negocio
Lógica Negocio Lógica Negocio Lógica Negocio
Manejo de datos
Presentación Presentación Presentación Presentación Presentación
1
Presentación
Distribuida
2
Presentación
Remota
3
Función
Distribuida
4
Manejo de Datos
Remoto
5
Manejo de Datos
Distribuido
C
L
I
E
N
T
E
S
ER
VI
DO
R
R
E
D

EX UMBRA SOLEM
IN
!"
Figura 1.12. Aplicación con Base de Datos en Arquitectura Cliente/Servidor
Una API debe incorporarse al código de la aplicación front-end escrita en algún
lenguaje de tercera o cuarta generación. Cuando existen APIs para varias herramientas de
desarrollo, se tiene una independencia considerable para desarrollar aplicaciones clientes en
cualquier lenguaje, siendo posible para los desarrolladores enlazar una aplicación
fácilmente a cualquiera de las bases de datos (o DBMSs) más populares.
En este caso, trabajar con API para bases de datos diferentes, implica que el
programador, utilizando las bibliotecas provistas por la API, debe abrir una conexión con el
motor de la base de datos deseado, luego se devolverá un identificador (handle) del
proceso, que identifica la conexión con una base de datos particular. Es posible mantener
varias conexiones y cada una de ellas tendrá un identificador exclusivo.
Después de hecha la conexión, se pueden ejecutar consultas que son enviadas a la
base de datos; si la consulta falla se devuelve una clave de error, si tiene éxito, se continúa
con el proceso. Después que un programa ha terminado de procesar los datos, se llama una
función para liberar la memoria asociada con las consultas y se cierra la conexión con la
base de datos.
Algunas herramientas de aplicación traen su propio motor de base de datos, por lo
cual no requieren de una API, ya que no se necesitan conectar a una base de datos externa a
ellas. Por ejemplo, Microsoft Visual Basic trae incorporado el motor Microsoft Jet que
permite manejar una base de datos nativa; en caso que se requiera acceso a una base de
datos externa como SQL Server de Microsoft, se deben utilizar la API ODBC y el motor
de base de datos debe tener el controlador VBSQL.
Muchas bases de datos ofrecen actualmente APIs basadas en el estándar ODBC, se
considera un estándar de hecho, lo cual significa que un API que declara cumplir con
ODBC debe satisfacer ciertas condiciones relativas a su funcionamiento. Si un API
realmente cumple con las normas ODBC, los programas escritos para accesar una base de
datos utilizando ODBC, deben ser capaces de accesar a cualquier otra base de datos usando
las mismas llamadas de función. Esto simplifica enormemente la tarea de interactuar con
bases de datos de diferentes proveedores.
En aplicaciones desarrolladas para Internet que requieren establecer conectividad
con alguna base de datos, se tiene por ejemplo la API JDBC (Java Data Base Connectivity).
Esta es un middleware que permite accesar desde alguna aplicación Java, algún motor de
base de datos sin necesidad de conocer las características propias de él.
Aplicación escrita
en Herramienta
Cliente
API
ODBC
Driver
ODBC
DBMS

EX UMBRA SOLEM
IN
!#
Base de Datos Distribuida
Cuando los datos de la base de datos son repartidos físicamente entre computadores
que están en múltiples sitios y conectados por una red, se está frente a una base de datos
distribuida. Al igual que para las bases de datos centralizadas, se requiere de un DBMS
para administrarla. Las BDD se caracterizan por ser muy difíciles de implementar
(requieren entre otras cosas, de una evaluación costo/beneficio para determinar en qué nodo
dejar qué datos, controles especiales de seguridad y de actualización de datos para evitar
inconsistencias), pero permiten un alto grado de disponibilidad de los datos, ya que no son
dependientes completamente de lo que suceda en el nodo central.
Existen diferentes estrategias de distribución de datos: fragmentación (horizontal y
vertical), replicación y una estrategia híbrida que combina las dos anteriores.
La fragmentación consiste en dividir algún archivo de la base de datos en
fragmentos dependientes de alguna característica propia de los datos, para dejarlos lo más
cerca de los usuarios que los requieran. Por ejemplo, un archivo CLIENTE puede ser
fragmentado horizontalmente, dividiéndolos según su categoría: clientes del tipo A, B, C o
D; y esos fragmentos distribuirlos en los nodos de la red (ver Figura 1.13). Este mismo
archivo puede ser fragmentado verticalmente, si se divide en base a sus atributos o
columnas, por ejemplo, en un nodo podrían dejarse los atributos que identifican al cliente y
en otro aquellos atributos que registran sus antecedentes comerciales, dado que serían
utilizados por usuarios que estarían en distintos nodos. Cuando existe fragmentación, es
necesario hacer una unión de fragmentos en caso que para algún requerimiento se necesiten
los datos de todos los clientes.
Figura 1.13. Base de Datos Distribuida (fragmentos)
La replicación consiste en copiar un archivo de la base de datos en cada nodo, de
tal manera que sus datos siempre estén disponibles, incluso cuando el nodo central esté
caído. El mayor problema es mantener la consistencia de los datos cuando se producen
CL IE N
T E D
N o d o 3
N o d o 1
N o d o 2
N o d o 4
CL IE N
T E C
CL IE N
T E A
CL IE N
T E B

EX UMBRA SOLEM
IN
!$
actualizaciones. Por ejemplo, si se replica el archivo CLIENTE, existirá una copia en cada
nodo de la red (ver Figura 1.14).
Figura 1.14. Base de Datos Distribuida (réplicas)
La estrategia híbrida consiste en particionar el archivo de la base de datos en
fragmentos críticos (sus datos requieren alta disponibilidad por lo que se almacenan en
múltiples sitios, es decir, se replican) y fragmentos no críticos (se almacenan en un sitio, es
decir, se particionan horizontal o verticalmente). Por ejemplo, el archivo CLIENTE puede
distribuirse pensando que los datos de los clientes VIP deben estar en todos los nodos, de
tal manera de entregar un buen servicio a ellos (fragmentación horizontal con replicación,
ver Figura 1.15).
Figura 1.15. Base de Datos Distribuida (híbrida)
CLIENTE
Nodo 3
Nodo 1
Nodo 2
Nodo 4
CLIENTE
VIP
CLIENTE
VIP
CLIENTE
VIP
C L IE N T E
N o d o 3
N o d o 1
N o d o 2
N o d o 4
C L IE N T E
C L IE N T E
C L IE N T E

EX UMBRA SOLEM
IN
!%
1.6.- 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.
1.5.1.- 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 1.16 y son: realidad,
metadato y dato.
Eventos, Objetos Diccionario de Datos Base de Datos
y
Realidad Metadato Dato (o valor)
Figura 1.16.- Niveles de Abstracción del Dato
Entidad
Definición Tabla o
Archivo
Ocurrencias de
Filas o Registros
Atributos
Definición
Columnas o
Campos
Ocurrencias de
Columnas o
Campos

EX UMBRA SOLEM
IN
!&
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.
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.

EX UMBRA SOLEM
IN
!'
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.
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.
1.5.2.- Representación del Dato (entidad, asociaciones o relacionamientos)
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.

EX UMBRA SOLEM
IN
!(
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
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

EX UMBRA SOLEM
IN
")
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:
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
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 1.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 1.18.
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.
PACIENTE CAMA

EX UMBRA SOLEM
IN
"
Figura 1.17.- Ejemplo Modelo de Datos para una Universidad
Figura 1.18.- Ejemplo Transformación de Asociación M:N en dos Asociaciones 1:N
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 1.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.
ALUMNO
ROL-ALUMNO
NOM-ALUMNO
ASIGNATURA
CLAVE-ASIGNATURA
NOM-ASIGNATURA
CREDITOS
DESCRIPCION
NOTA
ROL-ALUMNO
CLAVE-ASIGNATURA
NOTA
DEPTO. CARRERA
ALUMNO
SOLICITUD
ASIGNATURA

EX UMBRA SOLEM
IN
"!
Figura 1.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
RUT
NOMBRE
DIRECCION
BENEFICIARIO
RUT
NOMBRE
DIRECCION
POLIZA
#POLIZA
FECHA, MONTO
RUT-A
RUT-B
ORDEN-COMPRA
#MAT-PRIMA
#BODEGA
#PROVEEDOR
CANT-A-ORDENAR
PROVEEDOR
#PROVEEDOR
NOMBRE-P
DIRECCION-P
MATERIA-PRIMA
#MAT-PRIMA
DESCRIPCION
BODEGA
#BODEGA
DIRECCION-B
INVENTARIO
#MAT-PRIMA
#BODEGA
CANTIDAD

EX UMBRA SOLEM
IN
""
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.
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
PERSONA
RUT
NOMBRE
DIRECCION
POLIZA
#POLIZA
FECHA, MONTO
RUT-A, RUT-B
Asegurado
Beneficiario
EMPLEADO
Existen EMPLEADOS que son casados
entre ellos, es decir, tienen una
asociación 1:1, pero es posible que
sólo algunos sean casados entre
ellos, por lo que deberá ser una
asociación condicional.
Casado-con

EX UMBRA SOLEM
IN
"#
1:N
M:N
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:
En la entidad PIEZA, el #PIEZA corresponde al #PRODUCTO de aquel producto que para su
fabricación requiere de otros componentes que también son PRODUCTOS y que se identifican
a través del #COMPONENTE. La CANT-USADA indica cuántas unidades del componente requiere
la pieza. Por ejemplo si se tiene la siguiente fila dentro de la tabla PIEZA: X, Y, 20; podríamos
decir que para fabricar el PRODUCTO X se necesitan 20 unidades del PRODUCTO o COMPONENTE Y.
PRODUCTO
Un PRODUCTO se compone de otros
PRODUCTOS (piezas) y éstos a su vez
de otros, y así sucesivamente.
Componentes
PRODUCTO
#PRODUCTO
NOMBRE
ETC.
PIEZA
#PIEZA
#COMPONENTE
CANT-USADA
EMPLEADO
Si se supone que cada empleado
tiene sólo un jefe, entonces puede
existir una asociación de jefe a
subordinado.
Jefe-de

Cap1-Apuntes.pdf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a Cap1-Apuntes.pdf

Similar a Cap1-Apuntes.pdf (20)

Último

Último (20)

Cap1-Apuntes.pdf