1. FUNDACIÓN UNIVERSITARIA TECNOLÓGICO COMFENALCO
TECNOLOGÍA EN SISTEMAS DE INFORMACIÓN
FORMATO DE INSCRIPCIÓN DE PROYECTO DE AULA
V SEMESTRE
INFORMACIÓN DEL COLECTIVO
FECHA: _13_/_08_/_2009_
SEMESTRE: _V_
GRUPO: _A_
ESTADO
# NOMBRE DE LOS INTEGRANTES IRR REG
1 Francisco López Vidales X
2 Jaime García Sánchez X
X
3 Luis Rodríguez Simanca
4 Kenny Alfaro Pérez X
CONTEXTO DEL PROYECTO
NOMBRE DE LA EMPRESA: Restaurante La Vitrola
DIRECCIÓN: Calle Baloco No. 201
TELÉFONO: _____________________________
CONTACTO: Luis Tovar Hernández
EMAIL DEL CONTACTO: _________________________________________________

2. INFORMACIÓN DEL PROYECTO
NUCLEO PROBLÉMICO
¿Cómo diseñar un software aplicado estándares internacionales partiendo de los
requerimientos de una situación?
TEMA:
¿Cómo diseñar un software aplicando estándares internacionales partiendo de los
requerimientos para la optimización de factura e inventario de la IPS Centro Médico
Buenos Aires?
TÍTULO:
Software para la optimización de factura e inventario de la IPS Centro Médico
Buenos Aires
PROBLEMA:
La IPS Centro Médico Buenos Aires, es una Institución Prestadora de Servicios en
Salud, especializada en la atención integral ambulatoria, domiciliaria, pre
hospitalaria y de transporte asistencial, que cuenta con servicios idóneos, con alto
nivel de calidad, atención y tecnología. Esta IPS presta sus servicios a las
entidades promotoras de salud (EPS) donde cada paciente afiliado a esta puede
contar con los servicios de esta IPS. La información de cada paciente es registrada
en un software que organiza la información de los mismos. Los productos y servicios
que el paciente utiliza, son registrados en unos formatos de factura los cuales son
enviados a la EPS. Por otro lado, esta IPS cuenta con un control de inventario el
cual es realizado por una persona que vigila constantemente los productos que
entran y salen de la bodega. Debido a esto se presentan casos de pérdida de
productos, esto implica quejas e inconformidades por parte de los pacientes y todo
esto le da una mala imagen a esta IPS.
Nuestro proyecto esta visionado a optimizar y organizar el proceso de inventariado y
facturación de la IPS Centro Médico Buenos Aires para que esta pueda brindar un
mejor servicio a sus clientes.
JUSTIFICACIÓN
Para la IPS será de gran ayuda contar con un Software que le permita optimizar y
organizar los procesos de facturación e inventario; porque esto le permitirá manejar
mejor los proceso de control de sus servicios y esto ayudara que esta empresa sea
eficiente.
Para nosotros es de gran utilidad llevar a cabo este proceso, ya que se aplica los
conceptos aprendidos el semestre y/o carrera a la vida real trayendo consigo
experiencia que ayudara a nivel profesional.
Tabla de contenido

3. 1 PLANTEAMIENTO DEL PROBLEMA.
1.1 DESCRIPCION DEL PROBLEMA.
1.2 FORMULACION.
1.3OBJETIVOS.
1.3.1 OBJETIVO GENERAL.
1.3.2 OBJETIVOS ESÈECIFICOS.
1.4 JUSTIFICACION.
2 MARCO TEORICO.
3 DISEÑO METODOLOGICO.
3.1 Enfoque de la investigación.
3.2 Tipo de investigación.
3.3 Método de Investigación.
3.4 Tipo de estudio.
4 INVENTARIO DE CASOS DE USOS
5.1 Diagrama de actividades
5.2 Diagrama de secuencia
5 BIBLIOGRAFIA.
1 Planteamiento del problema.

4. 1.1 Descripción del problema.
La IPS Centro Médico Buenos Aires, está ubicada en el barrio Buenos aires
carretera transversal 54 N 49-45; esta entidad lleva prestando servicios a sus
clientes durante 6 años. Es una Institución Prestadora de Servicios en Salud,
especializada en la atención integral ambulatoria, domiciliaria, pre hospitalaria
y de transporte asistencial, que cuenta con servicios idóneos, con alto nivel
de calidad, atención y tecnología. Está entidad está organizada por un gerente,
un subgerente, una parte asistencial (médicos, etc.) y una parte administrativa
(facturación, contabilidad, auditoria, etc.).
Esta IPS presta sus servicios a las entidades promotoras de salud (EPS) donde
cada paciente afiliado a ésta puede contar con los servicios de esta IPS. La
información de cada paciente es registrada en un software que organiza la
información de los mismos. Los productos y servicios que el paciente utiliza,
son registrados en unos formatos de factura los cuales son enviados a la EPS.
Por otro lado, esta IPS cuenta con un control de inventario el cual es realizado
por una persona que vigila constantemente los productos que entran y salen de
la bodega, este inventariado se realiza de forma manual. Debido a esto se
presentan casos de pérdida de productos, además el hacerlo de esta manera
ocasiona pérdida de tiempo y a su vez un déficits en el centro médico. Todo
esto implica quejas e inconformidades por parte de los pacientes y todo esto le
dar una mala imagen a esta IPS.
Nuestro proyecto esta visionado a optimizar y organizar el proceso de
facturación e inventario de la IPS Centro Médico Buenos Aires para que esta
pueda prestar un mejor servicio a sus clientes y que evite además pérdida de
productos y a su vez no tengan inconvenientes con quejas por parte de los
clientes
1.2 FORMULACION DEL PROBLEMA

5. ¿Cómo diseñar un software aplicando estándares internacionales partiendo de
los requerimientos para la optimización de factura e inventario de la IPS Centro
Médico Buenos Aires?
1.3 OBJETIVOS

6. 1.3.1 General
Diseñar un software aplicando estándares internacionales partiendo de los
requerimientos para la optimización de factura e inventario de la IPS Centro
Médico Buenos Aires
1.3.2 Específicos.
1. Identificar los diferentes factores que influyen en el funcionamiento de
las facturas, para aplicar los diferentes métodos en el proceso de
facturaciones.
2. Analizar los modelos funcionales de los requerimientos de
facturaciones para aplicar los más adecuados a las necesidades del
centro médico.
3. Determinar los modelos de proceso de negocios en la información útil
para analizar, investigar y diseñar los conceptos que se requieren
para el buen funcionamiento del programa

7. 1.4 JUSTIFICACION
Para la IPS será de gran ayuda contar con un software que le permita
optimizar y organizar los procesos de facturación e inventario; porque esto
le proporcionará una manera mejor de manejar los proceso de control de
sus servicios y esto ayudara que esta empresa sea eficiente.
Para los usuarios representara una mejoría, debido a que se le brindara
una mayor calidad en los servicios que la IPS le presta a sus usuarios.
Para nosotros es de gran utilidad llevar a cabo este proceso, ya que se
aplica los conceptos aprendidos el semestre y/o carrera a la vida real
trayendo consigo experiencia que ayudara a nivel profesional.

8. 1.5 MARCO TEORICO
A continuación se expondrán los temas claves que ayudan a la realización
del proyecto para un mejor entendimiento de este, unos de estos temas
están en relación con la ingeniería de software que es la disciplina o área
de la informática que ofrece métodos y técnicas para desarrollar y
mantener software de calidad.
Esta ingeniería trata con áreas muy diversas de la informática y de
las ciencias de la computación, tales como construcción de compiladores,
sistemas operativos, o desarrollos Intranet/Internet, abordando todas las
fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de
información y aplicables a infinidad de áreas (negocios, investigación
científica, medicina, producción, logística, banca, control de tráfico,
meteorología, derecho, Internet, Intranet, etc.
Etapas del proceso.
La ingeniería de software requiere llevar a cabo numerosas tareas, dentro
de etapas como las siguientes:
Análisis de requisitos.
Extraer los requisitos de un producto de software es la primera etapa para
crearlo. Mientras que los clientes piensan que ellos saben lo que el
software tiene que hacer, se requiere de habilidad y experiencia en la
ingeniería de software para reconocer requisitos incompletos, ambiguos o
contradictorios. El resultado del análisis de requisitos con el cliente se
plasma en el documento ERS, Especificación de Requerimientos del
Sistema, cuya estructura puede venir definida por varios estándares, tales
como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el
que se plasman las principales entidades que participarán en el desarrollo
del software.
La captura, análisis y especificación de requisitos (incluso pruebas de
ellos), es una parte crucial; de esta etapa depende en gran medida el logro
de los objetivos finales. Se han ideado modelos y diversos procesos de
trabajo para estos fines
Ingeniería de requerimiento.
Un requerimiento es una condición o necesidad de un usuario para resolver
un problema o alcanzar un objetivo.
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.

9. Los requerimientos funcionales definen las funciones que el sistema será
capaz de realizar. Describen las transformaciones que el sistema realiza
sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que
de una u otra forma puedan limitar el sistema, como por ejemplo, el
rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estándares, etc.
Características de los requerimientos.
Las características de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar una
serie de características tanto individualmente como en grupo. A
continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser reemplazados por
otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en
un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles
en su redacción, es decir, si se proporciona la información suficiente para
su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar
confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado
de manera que permita hacer uso de los siguientes métodos de
verificación: inspección, análisis, demostración o pruebas.
Dificultades para definir los requerimientos
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de
manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más
importantes o más estables que otros.

10. • Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.
A pesar de las dificultades al momento de definir los requerimientos para
que se conviertan en una gran herramienta en el desarrollo del proyecto,
existen métodos enmarcado en la especificación.
Especificación
La Especificación de Requerimientos describe el comportamiento esperado
en el software una vez desarrollado. Gran parte del éxito de un proyecto de
software radicará en la identificación de las necesidades del negocio
(definidas por la alta dirección), así como la interacción con los usuarios
funcionales para la recolección, clasificación, identificación, priorización y
especificación de los requerimientos del software.
Entre las técnicas utilizadas para la especificación de requerimientos se
encuentran:
Casos de Uso
Un caso de uso es una técnica para la captura de requisitos potenciales de
un nuevo sistema o una actualización de software. Cada caso de uso
proporciona uno o más escenarios que indican cómo debería interactuar el
sistema con el usuario o con otro sistema para conseguir un objetivo
específico. Normalmente, en los casos de usos se evita el empleo de jergas
técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final.
En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para
el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que
se desarrollarán entre un sistema y sus actores en respuesta a un evento
que inicia un actor principal sobre el propio sistema. Los diagramas de
casos de uso sirven para especificar la comunicación y el comportamiento
de un sistema mediante su interacción con los usuarios y/u otros sistemas.
O lo que es igual, un diagrama que muestra la relación entre los actores y
los casos de uso en un sistema. Una relación es una conexión entre los
elementos del modelo, por ejemplo la especialización y la generalización
son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los
requerimientos del sistema al mostrar cómo reacciona una respuesta a
eventos que se producen en el mismo.
Definiciones básicas de los componentes grafico de un caso de uso.

11. Actores.
Se le llama Actor a toda entidad externa al sistema que guarda una relación
con este y que le demanda una funcionalidad. Esto incluye a los operadores
humanos pero también incluye a todos los sistemas externos así como a
entidades abstractas como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como
definiciones de rol, por lo que un mismo individuo puede corresponder a uno
o más Actores. Suele suceder sin embargo, que es el sistema quien va a
tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas
deben efectuar operaciones automáticas en determinados momentos; y
siendo esto un requisito funcional obvio, resulta de interés desarrollar
alguna forma de capturar dicho requisito en el modelo de caso de uso.
Tipo de relaciones
Comunica (<<communicates>>): Relación (asociación) entre un actor y un
caso de uso que denota la participación del actor en dicho caso de uso.
Usa (<<uses>>) (o <<include>> en la nueva versión de UML): Relación de
dependencia entre dos casos de uso que denota la inclusión del
comportamiento de un escenario en otro.
Extiende (<< extends>>): Relación de dependencia entre dos casos de uso
que denota que un caso de uso es una especialización de otro. Por
ejemplo, podría tenerse un caso de uso que extienda la forma de pedir
azúcar, para que permita escoger el tipo de azúcar (normal, dietético o
moreno) y además la cantidad en las unidades adecuadas (cucharadas o
bolsas). Un posible diagrama se muestra en la figura
Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos
encontramos con un caso de uso similar a otro pero que hace algo más que
éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando
nos encontramos con una parte de comportamiento similar en dos casos de
uso y no queremos repetir la descripción de dicho comportamiento común.
En una relación << extends>>, un actor que lleve a cabo el caso de uso
base puede realizar o no sus extensiones. Mientras, en una relación
<<include>> el actor que realiza el caso de uso base también realiza el caso
de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del
comportamiento normal, y <<include>> cuando se repite un comportamiento
en dos casos de uso y queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre
casos de uso y actor (asociaciones) y las dependencias entre casos de uso
(<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea
entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus
correspondientes diagramas. Los modelos de casos de uso se suelen

12. acompañar por un glosario que describe la terminología utilizada. El glosario
y el modelo de casos de uso son importantes puntos de partida para el
desarrollo de los diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede
llevar a diferentes realizaciones, es importante reflejar en cada
representación el motivo que nos ha llevado a descartarla, si es el caso.
NORMAS DE APLICACIÓN.
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua
del usuario final o del experto del campo del saber al que se va a aplicar.
Los casos del uso son a menudo elaborados en colaboración por los
analistas de requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o
tarea de negocio. Desde una perspectiva tradicional de la ingeniería de
software, un caso de uso describe una característica del sistema. Para la
mayoría de proyectos de software, esto significa que quizás a veces es
necesario especificar diez o centenares de casos de uso para definir
completamente el nuevo sistema. El grado de la formalidad de un proyecto
particular del software y de la etapa del proyecto influenciará el nivel del
detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas. Un caso del uso contiene
una descripción textual de todas las maneras que los actores previstos
podrían trabajar con el software o el sistema. Los casos de uso no
describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni
explican cómo se implementará. Simplemente muestran los pasos que el
actor sigue para realizar una tarea.
Un caso de uso debe:
 describir una tarea del negocio que sirva a una meta de negocio
 tener un nivel apropiado del detalle
 ser bastante sencillo como que un desarrollador lo elabore en un único
lanzamiento
Situaciones que pueden darse:
 Un actor se comunica con un caso de uso (si se trata de un actor
primario la comunicación la iniciará el actor, en cambio si es secundario,
el sistema será el que inicie la comunicación).
 Un caso de uso extiende otro caso de uso.
 Un caso de uso usa otro caso de uso.
Ventajas

13. La técnica de caso de uso tiene éxito en sistemas interactivos, ya que
expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se
centre en las necesidades del usuario, qué espera éste lograr al utilizar el
sistema, evitando que la gente especializada en informática dirija la
funcionalidad del nuevo sistema basándose solamente en criterios
tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se
concentra en las tareas centrales del usuario describiendo por lo tanto los
casos de uso que mayor valor aportan al negocio. Esto facilita luego la
priorización del requerimiento.
Limitaciones
Los casos de uso pueden ser útiles para establecer requisitos de
comportamiento, pero no establecen completamente los requisitos
funcionales ni permiten determinar los requisitos no funcionales. Los casos
de uso deben complementarse con información adicional como reglas de
negocio, requisitos no funcionales, diccionario de datos que complementen
los requerimientos del sistema. Sin embargo la ingeniería del
funcionamiento especifica que cada caso crítico del uso debe tener un
requisito no funcional centrado en el funcionamiento asociado.
Descripción de caso de uso:
Precondición.
Las precondiciones son un conjunto de condiciones que deben ser ciertas
antes de iniciar el caso de uso. Es muy común que la precondición sea el
resultado exitoso de un caso de uso anterior.
Flujo de eventos.
Es la interacción del sistema con el usuario a partir de las precondiciones,
en donde, se indican todos los eventos positivos en un lenguajes natural.
Flujo alternativo.
Son las correcciones que se le hace al flujo de eventos cuando en esta se
presenta una respuesta inadecuada producidas por el usuario.
Poscondición.
Las poscondiciones indican el estado final de las cosas después de que el
caso de uso termine exitosamente a través de cualquiera de sus flujos. No
son acciones del sistema sino resultados de acciones. Se deben tener en
cuenta las necesidades de todos los stakeholders para la definición de las
poscondiciones.

14. 2. Marco Teórico
- Preparedstatement
Un representante Objeto Que Una Sentencia SQL precompilada.
Una instrucción SQL es precompilado y almacenado en un objeto
PreparedStatement. Una Instrucción SQL es precompilado y almacenado en
Objeto PreparedStatement las Naciones Unidas. Este objeto puede ser
utilizado para ejecutar de manera eficiente esta declaración varias veces. Este
Objeto Puede Ser utilizado párr ejecutar "de Manera Eficiente this Declaración
Varias Veces.
Nota: Los métodos setter (setShort, setString, y así sucesivamente) para el
establecimiento de valores de los parámetros IN debe especificar los tipos que
son compatibles con el tipo definido por el SQL del parámetro de entrada. Nota:
Los setter MÉTODOS (setShort, setString, y Así sucesivamente) PARA EL
Establecimiento de Valores de Parámetros los en Los Especificar debe Tipos
compatibles Que Son Con El Tipo definido Por El SQL del Parámetro de
Entrada. Por ejemplo, si el parámetro IN ha ENTERO tipo SQL, entonces el
setInt método a utilizar. Por Ejemplo, si es El Parámetro de tipo, SQL ES
ENTERO, El Método debe setInt servicio utilizado.
Si arbitraria conversiones de tipos de parámetros son necesarios, el setObject
método debe ser utilizado con un objetivo de tipo SQL. Si arbitraria
Conversiones de Tipos de Parámetros necesarios hijo, El Método utilizado
debe setObject Con servicios sin Objetivo de tipo, SQL.
En el siguiente ejemplo de establecer un parámetro, Con representa una
conexión activa: En El Siguiente Ejemplo de Parámetro establecer las Naciones
Unidas, Con Una representación Conexión activa:
PreparedStatement pstmt con.prepareStatement = ("UPDATE EMPLEADOS
con.prepareStatement PreparedStatement pstmt = (" UPDATE Empleados
AJUSTE DE SUELDOS =? Bras DE sueldos =?
WHERE ID =? "); WHERE ID =?");
pstmt.setBigDecimal (1, 153,833.00) pstmt.setBigDecimal (1, 153,833.00)
pstmt.setInt (2, 110,592) pstmt.setInt (2, 110,592)

15. - Reportes
JasperReports es una fuente abierta de Java de presentación de informes
herramienta que puede escribir en la pantalla, una impresora o en PDF ,
HTML , Microsoft Excel , RTF , ODT , separados por comas los valores y XML
archivos.
It can be used in Java-enabled applications, including Java EE or Web
applications, to generate dynamic content. Puede ser utilizado en aplicaciones
Java, incluyendo Java EE o aplicaciones Web, para generar contenido
dinámico. It reads its instructions from an XML or .jasper file. Lee las
instrucciones de un archivo XML o el jaspe..
JasperReports es una fuente de una información de la biblioteca que se puede
incrustar en cualquier aplicación Java. Features include: Las características
incluyen:
• PDF, HTML, Microsoft Excel, RTF, ODT, CSV and XML files. PDF,
HTML, Microsoft Excel, RTF, ODT, CSV y XML. The engine allows
report definitions to include charts, with the rendering provided by the
JFreeChart library which supports many chart layouts, such as Pie, Bar,
Stacked Bar, Line, Area, Scatter Plot, Bubble, and Time series. El motor
permite a las definiciones de informe, incluyendo diagramas, con la
prestación prevista por la JFreeChart biblioteca que soporta diseños de
muchos éxitos, tales como pastel, barras, barras apiladas, Línea, Área,
Gráfico de dispersión, de burbujas, y series de tiempo.
• Multiple sources can be merged together. The data can be retrieved from
defined data sources such as JDBC , CALS Table Models , JavaBeans ,
EJBQL , XML, Hibernate , and Comma-separated values , and additional
data sources can be added to the JasperReports framework by plugging
in a custom JRQueryExecuter . Múltiples fuentes pueden ser
combinados entre sí. Los datos pueden ser recuperados a partir de
fuentes de datos definidos como JDBC , el cuadro Modelos CALS ,
JavaBeans , EJBQL , XML, Hibérnate , y comas de valores separados ,
y fuentes de datos adicionales se pueden agregar a la JasperReports
marco enchufando una costumbre JRQueryExecuter. An extension is
available to use Oracle PL/SQL stored procedures as a data source. Una

16. extensión está disponible para el uso de Oracle PL / SQL los
procedimientos almacenados como una fuente de datos.
- Base de datos
Una base de datos o banco de datos (en ocasiones abreviada BB.DD.) es un
conjunto de datos pertenecientes a un mismo contexto y almacenados
sistemáticamente para su posterior uso. En este sentido, una biblioteca puede
considerarse una base de datos compuesta en su mayoría por documentos y
textos impresos en papel e indexados para su consulta. En la actualidad, y
debido al desarrollo tecnológico de campos como la informática y la electrónica,
la mayoría de las bases de datos están en formato digital (electrónico), que
ofrece un amplio rango de soluciones al problema de almacenar datos.
Existen programas denominados sistemas gestores de bases de datos,
abreviado SGBD, que permiten almacenar y posteriormente acceder a los
datos de forma rápida y estructurada. Las propiedades de estos SGBD, así
como su utilización y administración, se estudian dentro del ámbito de la
informática.
Las aplicaciones más usuales son para la gestión de empresas e instituciones
públicas. También son ampliamente utilizadas en entornos científicos con el
objeto de almacenar la información experimental.
Las bases de datos pueden clasificarse de varias maneras, de acuerdo al
contexto que se este manejando, o la utilidad de la misma:
Según la variabilidad de los datos almacenados
Bases de datos estáticas
Éstas son bases de datos de sólo lectura, utilizadas primordialmente para
almacenar datos históricos que posteriormente se pueden utilizar para estudiar
el comportamiento de un conjunto de datos a través del tiempo, realizar
proyecciones y tomar decisiones.
Bases de datos dinámicas
Éstas son bases de datos donde la información almacenada se modifica con el
tiempo, permitiendo operaciones como actualización, borrado y adición de
datos, además de las operaciones fundamentales de consulta. Un ejemplo de
esto puede ser la base de datos utilizada en un sistema de información de una
tienda de abarrotes, una farmacia, un videoclub.
Según el contenido
Bases de datos bibliográficas
Solo contienen un surrogante (representante) de la fuente primaria, que permite
localizarla. Un registro típico de una base de datos bibliográfica contiene
información sobre el autor, fecha de publicación, editorial, título, edición, de una
determinada publicación, etc. Puede contener un resumen o extracto de la
publicación original, pero nunca el texto completo, porque si no, estaríamos en
presencia de una base de datos a texto completo (o de fuentes primarias —ver

17. más abajo). Como su nombre lo indica, el contenido son cifras o números. Por
ejemplo, una colección de resultados de análisis de laboratorio, entre otras.
Bases de datos de texto completo
Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas
las ediciones de una colección de revistas científicas.
Directorios
Un ejemplo son las guías telefónicas en formato electrónico.
Bases de datos o "bibliotecas" de información química o biológica
Son bases de datos que almacenan diferentes tipos de información proveniente
de la química, las ciencias de la vida o médicas. Se pueden considerar en
varios subtipos:
• Las que almacenan secuencias de nucleótidos o proteínas.
• Las bases de datos de rutas metabólicas.
• Bases de datos de estructura, comprende los registros de datos
experimentales sobre estructuras 3D de biomoléculas-
• Bases de datos clínicas.
• Bases de datos bibliográficas (biológicas, químicas, médicas y de otros
campos): PubChem, Medline, EBSCOhost.
Modelos de bases de datos
Además de la clasificación por la función de las bases de datos, éstas también
se pueden clasificar de acuerdo a su modelo de administración de datos.
Un modelo de datos es básicamente una "descripción" de algo conocido como
contenedor de datos (algo en donde se guarda la información), así como de los
métodos para almacenar y recuperar información de esos contenedores. Los
modelos de datos no son cosas físicas: son abstracciones que permiten la
implementación de un sistema eficiente de base de datos; por lo general se
refieren a algoritmos, y conceptos matemáticos.
Algunos modelos con frecuencia utilizados en las bases de datos:
Bases de datos jerárquicas
Artículo principal: Base de datos jerárquica
Éstas son bases de datos que, como su nombre indica, almacenan su
información en una estructura jerárquica. En este modelo los datos se
organizan en una forma similar a un árbol (visto al revés), en donde un nodo
padre de información puede tener varios hijos. El nodo que no tiene padres es
llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas.
Las bases de datos jerárquicas son especialmente útiles en el caso de
aplicaciones que manejan un gran volumen de información y datos muy
compartidos permitiendo crear estructuras estables y de gran rendimiento.
Una de las principales limitaciones de este modelo es su incapacidad de
representar eficientemente la redundancia de datos.
Base de datos de red
Artículo principal: Base de datos de red

18. Éste es un modelo ligeramente distinto del jerárquico; su diferencia
fundamental es la modificación del concepto de nodo: se permite que un mismo
nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).
Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una
solución eficiente al problema de redundancia de datos; pero, aun así, la
dificultad que significa administrar la información en una base de datos de red
ha significado que sea un modelo utilizado en su mayoría por programadores
más que por usuarios finales.
Bases de datos transaccionales
Son bases de datos cuyo único fin es el envío y recepción de datos a grandes
velocidades, estas bases son muy poco comunes y están dirigidas por lo
general al entorno de análisis de calidad, datos de producción e industrial, es
importante entender que su fin único es recolectar y recuperar los datos a la
mayor velocidad posible, por lo tanto la redundancia y duplicación de
información no es un problema como con las demás bases de datos, por lo
general para poderlas aprovechar al máximo permiten algún tipo de
conectividad a bases de datos relacionales.
Bases de datos relacionales
Artículo principal: Modelo relacional
Artículo principal: Base de datos relacional
Éste es el modelo utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente. Tras ser postulados sus fundamentos en
1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California),
no tardó en consolidarse como un nuevo paradigma en los modelos de base de
datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían
considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese
a que ésta es la teoría de las bases de datos relacionales creadas por Codd, la
mayoría de las veces se conceptualiza de una manera más fácil de imaginar.
Esto es pensando en cada relación como si fuese una tabla que está
compuesta por registros (las filas de una tabla), que representarían las tuplas, y
campos (las columnas de una tabla).
En este modelo, el lugar y la forma en que se almacenen los datos no tienen
relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto
tiene la considerable ventaja de que es más fácil de entender y de utilizar para
un usuario esporádico de la base de datos. La información puede ser
recuperada o almacenada mediante "consultas" que ofrecen una amplia
flexibilidad y poder para administrar la información.
El lenguaje más habitual para construir las consultas a bases de datos
relacionales es SQL, Structured Query Language o Lenguaje Estructurado de
Consultas, un estándar implementado por los principales motores o sistemas
de gestión de bases de datos relacionales.
Durante su diseño, una base de datos relacional pasa por un proceso al que se
le conoce como normalización de una base de datos.
Durante los años 80 la aparición de dBASE produjo una revolución en los
lenguajes de programación y sistemas de administración de datos. Aunque
nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su
gestión.
Bases de datos multidimensionales

19. Artículo principal: Base de datos multidimensional
Son bases de datos ideadas para desarrollar aplicaciones muy concretas,
como creación de Cubos OLAP. Básicamente no se diferencian demasiado de
las bases de datos relacionales (una tabla en una base de datos relacional
podría serlo también en una base de datos multidimensional), la diferencia está
más bien a nivel conceptual; en las bases de datos multidimensionales los
campos o atributos de una tabla pueden ser de dos tipos, o bien representan
dimensiones de la tabla, o bien representan métricas que se desean estudiar.
Bases de datos orientadas a objetos
Artículo principal: Base de datos orientada a objetos
Este modelo, bastante reciente, y propio de los modelos informáticos
orientados a objetos, trata de almacenar en la base de datos los objetos
completos (estado y comportamiento).
Una base de datos orientada a objetos es una base de datos que incorpora
todos los conceptos importantes del paradigma de objetos:
• Encapsulación - Propiedad que permite ocultar la información al resto de
los objetos, impidiendo así accesos incorrectos o conflictos.
• Herencia - Propiedad a través de la cual los objetos heredan
comportamiento dentro de una jerarquía de clases.
• Polimorfismo - Propiedad de una operación mediante la cual puede ser
aplicada a distintos tipos de objetos.
En bases de datos orientadas a objetos, los usuarios pueden definir
operaciones sobre los datos como parte de la definición de la base de datos.
Una operación (llamada función) se especifica en dos partes. La interfaz (o
signatura) de una operación incluye el nombre de la operación y los tipos de
datos de sus argumentos (o parámetros). La implementación (o método) de la
operación se especifica separadamente y puede modificarse sin afectar la
interfaz. Los programas de aplicación de los usuarios pueden operar sobre los
datos invocando a dichas operaciones a través de sus nombres y argumentos,
sea cual sea la forma en la que se han implementado. Esto podría
denominarse independencia entre programas y operaciones.
SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos
orientados a objetos y mantiene la compatibilidad con SQL92.
Bases de datos documentales
Permiten la indexación a texto completo, y en líneas generales realizar
búsquedas más potentes. Tesaurus es un sistema de índices optimizado para
este tipo de bases de datos.
Bases de datos deductivas
Un sistema de base de datos deductiva, es un sistema de base de datos pero
con la diferencia de que permite hacer deducciones a través de inferencias. Se
basa principalmente en reglas y hechos que son almacenados en la base de
datos. Las bases de datos deductivas son también llamadas bases de datos
lógicas, a raíz de que se basa en lógica matemática.
Gestión de bases de datos distribuida
La base de datos está almacenada en varias computadoras conectadas en red.
Surgen debido a la existencia física de organismos descentralizados. Esto les

20. da la capacidad de unir las bases de datos de cada localidad y acceder así a
distintas universidades, sucursales de tiendas, etcétera.