Este documento presenta el desarrollo de una base de datos farmacológica por parte de un grupo de estudiantes como proyecto de grado. Incluye la introducción, identificación y descripción del proyecto, marco de referencia, análisis, localización y análisis financiero. El objetivo es diseñar una base de datos para mejorar el manejo de medicamentos en hospitales, farmacias y empresas con el fin de garantizar la seguridad de los pacientes.

1. +

2. PHARMACOLOGICAL DATABASE

3. INTEGRNATES:
Melissa Ibarguen
Alejandra Cano Ospina
Maira Alejandra Alvarez Moreno
Mariana Varela Muñoz
Proyecto como requisito para aprobar el grado once en la modalidad Técnico en Sistemas.
INSTRUCTORES
Yohany Ortiz Acosta
ASESOR SENA
Harvey Meneses
INSTITUCION EDUCATIVA GONZALO RESTERPO JARAMILLO
SECRETARIA DE EDUCACION-SENA
MODALIDADES AUXILIAR EN SOPORTE EN REDES TECNICO EN SISTEMAS
MEDELLIN
2018
DEDICATORIA

4. Este trabajo va dedicado a nuestro instructor, y asesor del SENA porque con sus capacidades e
inteligencia hemos aprendido sobre la importancia de la tecnología hoy en día en nuestro
mundo, esto nos hace sentir entusiasmo e interés por aprender cada día más sobre las nuevas
tecnologías que han hecho evolucionar la capacidad del ser humano.
Gracias a su paciencia y tolerancia, no solo hemos aprendido a manejar la tecnología que nos
rodea, sino, llevarla con responsabilidad para nuestra vida, y podamos inculcar estos
conocimientos a las generaciones futuras.

5. NOTA DE ACEPTACIÓN
_________________________
_________________________
_________________________
_________________________
Jurado
_________________________
Jurado
_________________________
Jurado
Medellín
08/Agosto/2018
TABLA DE CONTENIDO.
INTRODUCCIÓN................................................................6

6. I. IDENTIFICACION DEL PROYECTO...............................7
1.1 TITULO DEL PROYECTO......................................8
1.2 DESCRIPCIÓN DEL PROYECTO...........................9
1.3 INTEGRANTES........................................................10
1.4 JUSTIFICACIÓN.......................................................11
1.5 OBJETIVO GENERAL..............................................12
1.6 OBJETIVOS ESPECIFICOS......................................13
1.7 ALCANCE DEL PROYECTO....................................14
II. MARCO DE REFERENCIA …..............................................15
2.1 MARCO TEORICO.....................................................16
2.2 MARCO CONCEPTUAL............................................17
2.3 ESTADO DEL ARTE..................................................18
III.ANALISIS DEL PROYECTO ….................................................19
3.1 FUENTES DE INFORMACIÓN...................................20
3.2 RECURSOS FÍSICOS....................................................21
3.3 RECUSOS TECNOLOGÍCOS.......................................22
3.4 RECURSOS HUMANOS...............................................23
3.5 DISEÑO PROPUESTO..................................................24
3.6 CRONOGRAMA............................................................2
IV. LOCALIZACION..................................................................................26
4.1 TAMAÑO...............................................................................27
4.2 OPORTUNIDAD DE MERCADO........................................28
V. ANALISIS FINANCIERO ......................................................................29
5.1 INVERSIONES......................................................................30
CONCLUSION..............................................................................................31
BIBLIOGRAFIA...........................................................................................32
ANEXOS.......................................................................................................33

7. INTRODUCCION
En el presente libro se mostrará el desarrollo de una Base de Datos Farmacológica.
Con esto se pretende, dar a conocer nuestra Base de Datos, como segura y Eficiente a un 100%,
mostrando así el control de venta y entrada de diferentes tipos de fármacos, garantizando la:
contabilidad y el buen servicio de nuestra BD. Incluyendo las características que se exigen para tener
el personal capacitado.
Actualmente existen empresas farmacológicas donde su mayor prioridad es tener medicamento de
buena calidad, y al hablar de calidad sus principales características es si son legales o no, su fecha de
producción, de caducidad real, entre otras.
I. IDENTIFICACION DEL PROYECTO.

8. 1.1 TITULO DEL PROYECTO.
PHARMACOLOGICAL DATABASE.
1.2 DESCRIPCION DEL PROYECTO.
Este proyecto está basado en el manejo de los diferentes medicamentos en el mercado, la BD tiene como
ventaja el mejoramiento en el manejo de los medicamentos, cada que este sistema se valla actualizando
y dando mejoras, garantizando aún más la calidad, y como excelente sistema de seguridad que queremos
ofrecer, solo aquellos usuarios que tengan licencia para utilizar nuestro Pharmacological Database,
podrán acceder a ella.
1.3 INTEGRANTES.
Melissa Ibarguen
Maira Alejandra Alvarez Moreno
Alejandra Cano Ospina
Mariana Varela
1.4 JUSTIFICACION.
Este proyecto es importante, ya que tiene como punto central la implementación de un sistema de
seguridad de excelente calidad, para la seguridad en salud y bienestar de la comunidad en general, y
así, también entender los beneficios que trae nuestro sistema de seguridad a nivel privado y público.
1.5 OBJETIVO GENERAL.
Diseñar una base de datos administrativa para mejorar el uso de los diferentes medicamentos en diversos
hospitales, farmacias y empresas. Teniendo como objetivo humano, la seguridad de los pacientes y
personas comunes.
1.6 OBJETIVOS ESPECIFICOS.
Generar una buena administración de los diferentes fármacos, esto se aplica en casos de venta ilegal,
extralimitación y fabricación de estas.
1.7 ALCANCE DEL PROYECTO
Nuestro alcance y propósito es tener el máximo nivel de seguridad en nuestras bases de datos,
implementado estas en diferentes empresas a nivel nacional y, alcanzado así, la mayor seguridad nunca
antes vista en la administración de medicamentos, ya que hacemos una investigación profunda sobre la
procedencia de cada una revelando la verdad de estos.
II. MARCO DE REFERENCIA

9. 2.1 MARCO TEORICO
Este proyecto se compone de la modalidad de aprendizaje en sistemas, que tiene como objetivo
que las estudiantes presente un proyecto de grado de acuerdo a todo lo que se les ha enseñado con
los técnicos del SENA y profesores, logrando así presentar este trabajo ante la institución
educativa.
Esta formación consiste en la adquisición de conocimiento sobre sistemas operativos, hardware,
software y finalmente llegar a la práctica de cada uno. Tenemos en cuenta de que eso nos ayudara
para tener un futuro emprendedor, dando uso a todo lo aprendido en clase.
Sabemos claramente el significado de un sistema en conjunto.
Las bibliotecas tienen una gran influencia en los resultados de aprendizaje, pues en el desarrollo
de las actividades lectoras complementadas con el uso de las diferentes redes investigativas nos da
mejores resultados a la hora de presentar una exposición etc. En la biblioteca se puede encontrar
un apoyo, si se busca un alto rendimiento, debe cambiarse el pensamiento de la biblioteca como
un lugar aburrido donde se llegar a leer libros de forma obligatoria, es rotundamente falso ese
pensamiento.
Las bibliotecas son más que leer libro, es adquirir conocimiento, es un lugar de reunión para las
estudiantes, en el cual se puede debatir y compartir ideas.
Para nosotras al investigar leyendo libros sobre medicina, farmacología entre otras áreas
relacionadas, hemos logrado tener más ideas para introducir en nuestro proyecto y que sea el
mejor, ya que se tara de la administración de estupefacientes.
En cualquier caso, particularmente se genera una indeterminada cantidad de información, la cual,
según su importancia, es necesario almacenar para uso posterior. El lugar donde se almacena esta
información se conoce como " Base de Datos", éste lugar puede ser tangible o intangible.
2.2 MARCO CONCEPTUAL.
La base de datos cuenta con una gran cantidad de herramientas que contribuyen para que el
manejo de los datos sea eficiente. En la etapa del diseño se debe tener en cuenta los siguientes
elementos:
DATOS DEL USUARIO: son tablas de datos que contienen la información específica de los
datos que almacena la base, los cuales están ordenados en filas y columnas.
METADATOS: También se conoce como Tablas del Sistema y son las que abarca la
información acerca de la Base de Datos, es decir, el tipo y cantidad de registros que contiene.
ÍNDICE: es el ordenamiento de los datos según la conveniencia del usuario para realizar un
manejo más fácil de los mismos. Es decir, que del tipo de información que se tenga, los campos se
pueden ordenar por ejemplo de acuerdo al nombre, apellido, dirección, etc.
METADATOS DE APLICACIÓN:

10. TIPO DEFINICION/APLICACIO
N
EJEMPLOS
Administrativos Usados en la gestión y
administración de recursos de
información
• Adquisición de
información
• Derechos y
reproducción
• Requerimientos legales
para el acceso
• Localización de
información
• Criterios de selección
para la digitalización
• Control de la versión
2.3 ESTADO DEL ARTE:
INTRODUCCIÓN
Introducción
Un sistema de gestión de base de datos es un sistema automatizado cuyo propósito general es
mantener información y hacer que esté disponible cuando se solicite. La información en cuestión
puede ser cualquier cosa que se considere importante para el individuo u organización a la cual debe
servir el sistema. Para todos está bastante clara a la importancia del uso de una base de datos. Las
ventajas de un Sistema de Gestión de Base de Datos (SGBD), sobre los métodos tradicionales se ha
fundamentado sobre las siguientes bases:
• es compacto
• es rápido
• es menos laborioso
• es actual
• existe un control centralizado de la información
Buscándole solución a la crisis del software surgió, en el campo de la programación, la programación
estructurada, y un poco más tarde la programación modular y el diseño estructurado. A pesar de sus
muchas ventajas, al aumentar las expectativas de los usuarios acerca de lo que podía hacer una
computadora, surgieron un mayor número de problemas más complejos a resolver. Además, para
reducir el tiempo de realización de un producto se hace necesario reutilizar elementos que han sido

11. desarrollados por otros sistemas, pero las técnicas existentes no ayudaban lo necesario en este sentido.
Es por esto que surgió la tecnología orientada a objetos (OO) que introduce nuevos conceptos en el
campo de la informática y que ha provocado una revolución en todos los órdenes.
Todo esto hace bastante evidente que, aunque haya surgido una nueva filosofía en la programación.
cualquier aplicación basada en la tecnología OO trabaja con información y no va a renunciar a todas
las ventajas ya alcanzadas con los SGBD, aunque no esté definido un modelo para los objetos.
Conceptos básicos del modelo orientado a objetos
Todas las ventajas de este enfoque giran alrededor de la posibilidad de aumentar la productividad,
pero esto no es tarea fácil. Depende del analista lograr un diseño que explote todas las posibilidades
que brinda porque todo depende de la manera que miremos y representemos el mundo. Como plantea
Timothy Budd en: “La programación OO es una nueva forma de pensar acerca de lo que significa
computar, acerca de cómo podemos estructurar la información dentro de un computador. Aplicar
con efectividad los nuevos recursos exigen un cambio de percepción, es decir, una forma de pensar
completamente nueva en cuanto a la resolución de problemas.”
Para comprender cómo ha sido el impacto que ha tenido en el campo de los sistemas de gestión es
preciso formalizar antes los principales conceptos que caracterizan a esta nueva tecnología.
CLASE: Es un tipo de datos abstractos con operaciones encapsuladas que combina estructura de
datos y comportamiento. Representa una idea simple o conceptos y características de un objeto los
cuales tienen operaciones semejantes y propiedades útiles. Por lo tanto, agrupa comportamiento y
atributos comunes de objetos del mundo real lo que garantiza independencia de los datos porque:
• Dependencia de los datos: una aplicación es dependiente de los datos si es imposible alterar la
estructura de almacenamiento (la organización física de los datos) o la técnica de acceso (la
forma de llegar a ellos) sin afectar la aplicación. Por lo tanto, la independencia puede
definirse como la inmunidad de las aplicaciones a los cambios en la estructura de
almacenamiento y en la técnica de acceso.

12. • Se puede cambiar la representación de los objetos y la forma de acceso la información sin
tener que volver a escribir ninguna de las aplicaciones que utilizan esos objetos. Por esto al
encapsulamiento de los objetos se le conoce como abstracción de la información (se esconde
de la vista del usuario la información que no necesita).
OBJETOS
Es un concepto del mundo real que puede ser modelado por una clase. Tiene un tipo, es decir, es una
variable de un tipo de clase dada. Posee un valor por lo que en cada momento está en un estado que
depende del valor de sus atributos. Se caracteriza por un identificador de objeto único generado por
el sistema que nunca será modificado, no es una propiedad del objeto (como lo eran las llaves
primarias) y el programador no conoce su valor no le interesa (puede considerarse como un atributo
oculto en el sentido de que por lo general no puede percibirse ni manipularse directamente). los
atributos pueden ser sencillos (los definidos por el sistema, por ejemplo, integer) y complejos (otros
objetos).
MENSAJE
Es la forma en que un objeto interactúa con otros. Un objeto (emisor) envía un mensaje a otro (el
receptor). El receptor puede ignorarlo, contestar o ejecutar una acción que implique modificaciones
internas de su estado, enviar un mensaje a otro, etcétera. La forma en que ese objeto responde puede
cambiar, mientras que el mensaje recibe el mismo nombre. Cuando hacemos referencia a la
comunicación con mensajes, nos referimos a que los objetos proporcionan resultados en respuesta a
peticiones de servicio de los usuarios. cada objeto será capaz de responder a diferentes peticiones de
servicios. esto no debe confundirse con tradicionales llamadas de funciones de la programación
tradicional. Las llamadas a funciones son utilizadas para aplicar algún proceso estándar a los datos,
que se reciben como parámetros, como parte de la ejecución de otra función.
ABSTRACCIONES DEFINIDAS EN EL MODELO OO
El término abstracción “proviene de un reconocimiento de semejanzas entre ciertos objetos,
situaciones o procesos en el mundo real, y la decisión para concentrar esas semejanzas e ignorar
por el tiempo la ausencia de diferencia” . Abstraer significa separar por medio de una operación
intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo

13. objeto en su pura esencia o noción. Además de los objetos, en este enfoque se definen las siguientes
abstracciones [1,9]:
• Agregación o categorización: Es un tipo de datos definido en término de otros, si tenemos tipos
de objetos E1, E2, se puede definir un objetos agregado o categoría E tal que E1,E2, son
componentes del objeto tipo E si todos se relacionan para cumplir una función. E1, E2, estos
pueden ser simples o complejos. De estos últimos se tiene el identificador.
• Generalización: Sean los Object1, Object2, Object3 tipos de objetos con propiedades comunes,
entonces se puede definir un tipo de objeto “Object” tal que posee el comportamiento y atributos
comunes para Objecti/i=1,2, de forma que los Objecti son subtipos de Object. Dentro de este
tipo de abstracción pueden identificarse:
• Generalización total sin solapamiento
• Generalización total con solapamiento
• Generalización parcial sin solapamiento
• Generalización parcial con solapamiento
• Agrupamiento o colección/miembro: Un tipo de objeto es un grupo de objeto M (tipo miembro)
si toda la instancia de E (tipo grupo) corresponde a un conjunto de instancias de M.
¿Por qué no el modelo relacional para Base de Datos Orientada a Objetos (BDOO)?
El modelo relacional se basa en a teoría matemática de relaciones. Una Base de Datos Relacional (BDR)
es aquella que los usuarios perciben como un conjunto de tablas (las entidades son tablas y las relaciones
son tablas). Un ejemplo de esto es el conocido caso de suministradores y productos en el que se definen
tres tablas: suministradores (datos de todos los suministradores), productos (datos de y todos los
productos) y oferta (indica los productos que son suministrados por cada suministrador y la cantidad
que ofertan).
El modelo relacional de Codd se basa en almacenar datos en tablas de dos dimensiones (registros-
filas o tuplas- y campos-columnas o atributos). Las relaciones entre las tablas se establecen mediante
la conexión de atributos (llave). Pero el modelo relacional no es la solución a todos los problemas
y nunca se aseguró que lo fuera. En el campo de Los SGBD han existido dos generaciones:
1ra generación - Jerárquicos y reticulares
- Sistemas unificados con lenguajes de definición de los datos y de
manipulación de los datos.
2da generación - Relacionales
- Se logra una mayor independencia de los datos.
- Uso de un lenguaje de manipulación de datos sin procedimientos.
Hay un conjunto de problemas a los cuales los SGBDR no le dan directamente solución:
1- Los SGBDR centran su atención en sistemas de gestión por lo que hay aplicaciones para los
cuales resultan inadecuados.
Ej: - CAD (Computer-Aided Design)

14. - CASE (Computer- Aided Software Engineering)
- Hipertexto - El diseño de un periódico exige el almacenamiento de fragmentos de texto,
gráficos, iconos y una infinidad de elementos de datos que ofrecen los entornos
hipertextos.
2- No soportan igualmente bien todos los sistemas de gestión
Ej.: Sistema de seguros que procese reclamaciones: Requiere de datos tradicionales (nombre y
cobertura de cada persona asegurada), pero sería recomendable almacenar imágenes
fotográficas del suceso al que se refiere la reclamación, así como un facsímil del impreso
original en el que se escribió la reclamación. Además, toda esta información (datos
tradicionales, imágenes y quizás algunos datos procesales) se agregan a una carpeta (tabla) que
a menudo es muy compleja.
3- Enriquecimiento de la base de datos a partir de aplicar reglas que deduzcan nueva información
partiendo de la existente.
Ej.: Para el periódico, se puede tener toda la información que puede aparecer un sus páginas y se
incluyen reglas que, a partir de ella, generan nueva información relacionada con la ubicación
en cada página de la información y además nuevos textos que tendría que existir para garantizar
un buen diseño. Algunas reglas podrían estar relacionadas con la ubicación de la propaganda,
de manera que, por ejemplo, en una misma página no pueden aparecer anuncios de
competidores.
4- Necesidad de hacer consultas recursivas
Ej.: Una situación real podría ser la siguiente:
Ensamblajes
Ensamblajes
Equipo Piezas
Piezas
Cualquier recuperación aquí requiere interactuar con el mismo tipo de clase, para objetos que
pueden o no ser diferentes.
Las soluciones brindadas han seguido dos maneras diferentes de abordar el problema:
a) Ampliar el modelo relacional en forma apropiada. En este sentido han surgido extensiones del
modelo que agregan más semántica de manera que se pueden representar otras abstracciones como
las agregaciones.
Ej.: - Los tipos de datos de una columna pueden ser otra tabla (para datos complejos).
- Los métodos asociados con una tabla.

15. - Las tablas organizadas en jerarquías que heredan los esquemas de las tablas ancestras (clases).
b) Desechar por completo el modelo relacional y sustituir por algo nuevo. Los nuevos modelos que
han aparecido son:
- Modelo semántico: incluyen más semántica a la representación, representando información
más compleja.
- Modelo deductivo: permiten añadir nuevo conocimiento a partir de la inferencia.
- Modelo OO: permiten representar datos complejos y los métodos para procesarlos.
El modelo deductivo está muy bien fundamentado en la lógica de predicado de 1er orden, pero
en la práctica no se han logrado concretar en un sistema de gestión por lo que su actividad
experimental es casi nula. En el caso del modelo orientado a objetos se han hecho varios
intentos que han dado como fruto sistemas de gestión más o menos potentes, pero que tiene
dos problemas fundamentales: la falta de un modelo común de datos y falta de fundamentos
formales.
Los nuevos modelos definen a los sistemas de base de datos de 3ra generación. hay consenso en que
deben cumplir los siguientes principios [17]:
1- Más allá de los servicios tradicionales de gestión de datos, los SGBD de 3ra generación
proporcionarán apoyo a estructuras del objeto y reglas más ricas.
2- Los SGBD de 3ra generación deben subsimir a los SGBD de 2da generación.
3- Deben estar abiertos a otros subsistemas.
Hay muchas propuestas de estas que cumplen los sistemas de gestión orientados a objetos, pero hay
otras donde hay profundos desacuerdos. No es nuestro objetivo profundizar en esto, solo que
conozcan qué es lo que se espera de los SGBD de 3ra generación donde caen los OO.
Situación actual El modelo relacional se basa en fundamentos tan sólidos como el
álgebra y cálculo relacionales por lo que resulta casi imposible
desechar por completo el modelo relacional y sustituirlo por
algo nuevo, pero requiere de grandes cambios que para
imponerse deben estar bien fundamentados desde el punto de
vista matemático.
SGBDOO
Una BDOO es una colección de objetos que pueden ser almacenados y recuperados por un sistema
de gestión orientado a objetos.
Los SGBDOO surgen de la convergencia entre la tecnología de las BD y el paradigma de la

16. orientación al objeto con el fin de atender a requisitos para los cuales los productos relacionales no
daban una respuesta plenamente satisfactoria.
Los sistemas OO tienen sus orígenes en los lenguajes de programación OO por lo que deben cumplir
las 4 características básicas que definen a estos últimos:
- encapsulamiento,
- abstracción de tipos de datos,
- herencia y
- polimorfismo
, pero los lenguajes carecen de una capacidad muy importante: la capacidad de un objeto de mantener
su contenido de instancia a instancia (persistencia). Es decir, si se quiere almacenar en fichero un objeto
entero (no solo sus datos) hay que buscar otras soluciones porque los lenguajes OO no soportan esto.
La forma en que se resuelve este problema ha definido lo distintos SGBDOO [5].
BDR: es una colección de relaciones
BDOO: es una colección de clases e instancias de clases.
Un SGBDOO es un sistema diseñado para almacenar y recuperar objetos complejos en lugar de artículos
contenidos en tipos de datos simples. No existe una definición estándar de lo que es un SGBDOO, no
obstante, se aceptan las reglas propuestas en la 1ra conferencia internacional de BDOO y base de datos
deductivas [10]. Según este artículo los SGBDOO deben tener las siguientes
CARACTERÍSTICAS:
Características obligatorias: reglas de oro
1- Tratamiento de objetos complejos que liberan a la aplicación de manejar las relaciones entre
objetos.
2- Cada objeto debe poseer un identificador (OID-Object Identifer) que suministra automáticamente
el sistema lo que reduce la duplicación y libera al diseñador de la necesidad de crear llaves únicas.
3- Encapsulamiento que proporciona una independencia lógica de los datos.
4- Soportan la noción de tipos (tipos abstractos de datos) y clases.
5- Herencia.
6- Sobrecarga (con un nombre se denotan programas distintos), enlace tardío y redefinición.
7- Posibilidad de hacer cálculos complejos.
8- Posibilidad de crear nuevos tipos a partir de los existentes.
9- Persistencia: capacidad de un objeto de conservar su valor en el espacio y en el tiempo.
10- Gestión de almacenamiento secundario
- índice
- agrupamiento de datos
- introducción de datos en memoria interna

17. - selección de la vía de acceso
- optimización de la consulta
11- Concurrencia.
12- Recuperación ante fallas de hardware y el software.
13- Mecanismo simple de consulta de datos.
Características opcionales: los "bombones"
1- Herencia múltiple.
2- Comprobación e inferencia de tipo.
3- Distribución: objetos ubicados en diferentes procesadores. En el medio distribuido cliente-servidor
es donde más auge ha tomado.
4- Transición de diseño.
5- Versiones: posibilidad de mantener las distintas versiones que de un objeto (como objeto no como
clase) puede haber.
Las características antes mencionadas no son obligatorias para un SGBDOO solo buscan mejorar la
gestión. Sobre la opcionalidad de alguna de ellas se puede discutir, pero no nos pararemos a analizarlas.
ALGUNOS PRODUCTOS
Si clasificáramos a los lenguajes OO pudiéramos definir tres grandes grupos:
- Puros (Smaltalk, Eifel),
- Basados en objetos (ADA) y
- Híbridos (Pascal, C++)
, dentro de los productos que tratan de manipular BDOO podrán definirse estos grupos de alguna
manera:
• Basados en objetos
Ej.: Paradox - 4Mb RAM
- 8 Mb disco duro
- Ega o superior
- BDR con conceptos orientados a objetos, pero no se permite la
herencia.
- Soporta multitablas y multirecords para relaciones de 1:m y m:m.
Clipper 5.0 Se definen algunas clases que pueden ser usadas, pero no se permite la herencia. Los
objetos son valores complejos de datos que tiene una estructura y
comportamientos predefinidos. El sistema suministra un pequeño grupo de objetos
predefinidos (llamados clases). No es posible crear nuevas clases.

18. FoxPro Visual: El lenguaje de programación tiene algunas características del enfoque
sobre todo, para la interfaz, pero el sistema de gestión es
relacional.
• Productos que cumplen algunas de las características, pero no pueden ser considerados
SGBDOO.
Son una alternativa al modelo relacional que no es un auténtico modelo, sino un compromiso con
la realidad.
Primeros productos. G-Base 1986 por French Company
. GemStone 1987 por American Company Servio Corp
. VBase 1988 por Ontos
GemStone[2] - combina los conceptos del lenguaje OO Smaltalk con elementos de manipulación de
datos.
- Posee una jerarquía de clases predefinida que se inicia en la clase "Object". Todas
las definidas deben heredar de ellas.
- La comunicación es a través de mensajes compuestos por un OID del objeto
receptor, uno o más identificadores que especifican los métodos que pueden ser
invocados y uno o más argumentos.
- Herencia - Simple
- Subclases solo pueden añadir atributos y redefinir métodos. Se
heredan las restricciones de los atributos que solo pueden aumentarse.
- Todos los objetos creados no son automáticamente persistentes, hay
que especificarlos.
- Incluye abstracciones: Generalización/especialización y
agrupación.
Estos productos se corresponden con la 1ra generación de SGBDOO que realmente no eran lenguajes
persistentes, es decir, son bibliotecas de clases en C++ que pueden ser utilizados en una aplicación
en C++. Cuando se compilan actúan como un preprocesador en los programas en C++.
La 2da generación ocurrió en 1989, los productos desarrollados usan la arquitectura cliente/servidor
y soportan diferentes plataformas.
Ej.: - Poet [16] - Fuerte - Implementación de la persistencia.
- Múltiples plataformas.
- Preparado para versiones futuras.
- Almacenamiento de objetos complejos.

19. - Habilidad para explorar, seleccionar y navegar a través de
BDOO.
- Poco consistente - Documentación incompleta
- No permiten que clases persistentes tengan punteros a clases no
persistentes.
- No puede heredarse de clases no persistentes.
- Versión 2.0 - 4 Mb RAM
- 3 Mb disco duro
- Permite extender capacidades (inteligencia) a aplicaciones en el tiempo sin tener que
recompilar.
• Hay productos más fuertes y con grandes perspectivas. Por lo general se corresponden con los
de la 3ra generación, aunque están la mayoría en la 2da versión o superior. De manera general
poseen avanzadas características y lenguajes de manipulación de datos orientados a objetos.
Ej.: IDB Object Database[8] - Versión 2.0
- 4 Mb RAM
- 10 Mb RAM
- Datos complejos
- Soporta casi todos los conceptos de la: polimorfismo, herencia (simple y
múltiple), enlace dinámico, etcétera.
- Puede correr como una aplicación solo o puede ser
usada para compartir datos en una red.
Limitaciones de los SGBDOO
La tecnología OO es muy joven por lo que son muchas las limitaciones que va a tener los SGBDOO:
1- La tecnología no está madura, no se ha definido un modelo común por lo que cada uno resuelve
los problemas de manera particular sin considerar criterios de compatibilidad.
Ej.: Los OID pueden ser físicos (es decir, contienen la dirección actual del objeto) o lógicos (tiene
un índice que sirve para llegar a la localización del objeto). A partir de esto se han definido 4
tipos de OIDs [15]:
1. Dirección: Es la forma más simple de identificar un objeto por lo que es la forma
tradicional que usan los lenguajes de programación: dirección física. Las direcciones
son generalmente de 32 bits o menos y es la forma más eficiente para llegar
rápidamente a la información. Esta forma es raramente usada por los sistemas de
gestión porque ellos no permiten a un objeto ser movido o eliminado si todas las
referencias a ese objeto son encontradas y restablecidas.

20. 2. Dirección estructura: Es la más usada por los modelos relacional, extensiones del
relacional y el orientado a objetos. Contiene componentes lógicos y físicos, por lo tanto
está formado por dos partes:
- # segmento y # página en el disco (físico).
- # lógico del canal para poder determinar la posición dentro de la
página.
Con esta representación el objeto puede ser movido o eliminado relocalizando dentro
de la página el canal.
3. Sustituto: Un OID puramente lógico se genera usando cualquier algoritmo que
garantice la producción de identificadores únicos (por ejemplo, usar hora y fecha).
4. Sustituto tipado: Es una variante del anterior que contiene una identificación del tipo
y una identificación del objeto. La porción del objeto es generada para diferentes
contadores para cada tipo, segmentando el espacio de direcciones. Permite identificar
el tipo de un objeto con facilidad.
Ejemplos de implementación de identificadores en SGBDOO.
Producto
Año
Generación
Implementación
Orion [14,45]
1990
3ra
Es un par (identificador de clase,
modelo de identificador), donde el
identificador de clase es el identificador
de la clase a la cual el object pertenece
y el identificador de modelo es el
identificador del modelo sin la clase o
sin la base de datos completa. Cuando
un mensaje es enviado a un objeto, el
sistema puede extraer el identificador
de clase del objeto del identificador de
objeto especificado, y mirar la clase

21. para determinar si el mensaje es válido,
y entonces puede buscar el objeto y
enviar el método correspondiente.
GemStone [13]
1987
1988
1ra- versión 1.0
2da- Versión 2.0
El identificador es implementado
físicamente con un puntero. Cuando un
puntero a un objeto cesa de ser
referenciado, entonces deja de existir.
No existe una función “borrar un
objeto” y se garantiza que un objeto
existe mientras lo referencien. Los
métodos y las estructuras comunes de
todas las instancias de una clase son
contenidas en un objeto conocido como
definidor de objetos de una clase
(CDO-Class Defining Object). Todas
las instancias de una clase contienen
una referencia a su CDO como parte del
identifcador del objeto.
Permite a los usuarios asignar a los
objetos nombres y crea un diccionario
de símbolos de manera que cada
usuario tiene su propio diccionario.
Estos nombres permiten a los usuarios
acceder directamente a los objetos de
una base de datos.
2- Como no existe gran experiencia cada paso es un proceso de aprendizaje.
3- El desarrollo de instrumentos tales como generadores de aplicación y lenguajes de 4ta generación
es lento, existen pocos. Esto hace más lento el proceso de aprendizaje.

22. 4- Los productos son débiles en cuanto al manejo de os datos sobre todo para la concurrencia, salva/
restaura, optimización y lenguaje de consulta.
CONCLUSIONES
La situación actual no ha cambiado substancialmente a la referida en el congreso de 1988 porque a
los SGBDOO les sigue caracterizando una fuerte actividad experimental y falta de un modelo formal.
En estos momentos están apareciendo nuevas versiones de sistemas de gestión fuerte en el modelo
relacional que incluyen algunas posibilidades del enfoque orientado a objetos aún cuando no usan un
modelo orientado a objetos, pero anuncian cambios en este sentido para próximas versiones (por
ejemplo, Informix).
En un futuro no muy lejano, podremos explotar las facilidades que esperamos nos brinden los
SGBDOO en los productos que desarrollemos.
II.ANALISIS DEL PROYECTO
3.1 FUENTES DE INFORMACIÓN.
Todo nuestro trabajo se ha basado no solo en los conocimientos ya obtenidos, sino también en diferentes
fuentes bibliográficas analizadas con determinación, puesto que, no todas las fuentes donde se encuentra
esta información son totalmente verdadera o acertada.
3.2 RECURSOS FÍSICOS.
No hubo necesidad de tener contacto físico, todo este proyecto se realizó por vía tecnológica.
3.3 RECURSOS TECNOLÓGICOS.
Necesitamos de computadores para realizar el proyecto, de un programa de visual studio, un formulario.
3.4 RECURSOS HUMANOS.

23. Este proyecto beneficiara a diferentes empresas y a la comunidad, dando así la seguridad completa y de
excelente calidad para el manejo adecuado de los medicamentos
3.5 DISEÑO PROPUESTO.
IV. LOCALIZACION
4.1 TAMAÑO.
4.2 OPORTUNIDAD DE MERCADEO
Posiblemente en un futuro no muy lejano se pueda implementar esto en el mundo del mercadeo ya que
cabe recalcar esto es un proyecto el cual no tenemos ahora los elementos suficientes para llevarlo esos
extremos lo cuales realmente son comprometedores.

24. V. ANALISIS FINANCIERO
5.1 INVERSIONES
Tiempo de trabajo y diseño de la página no tienen costo alguno.
Empastada de proyecto: $18.000
La impresión no tuvo costo alguno ya que una de nuestras integrantes tiene impresora en casa.