TES674

Benemrita Universidad Autnoma de Puebla
Facultad de Ciencias de la Computacin
Sistema para el Control de Inventarios de una Farmacia
S. C. I. F.
Tesis profesional que presenta: Javier Conde Iztetzi
Que para obtener el ttulo de
Lic. en Ciencias de la Computacin
Asesor: Lic: Marco Antonio Soriano Ulloa
Puebla, Pue. 2004
Sistema Farmacutico SCIF
INTRODUCCIN GENERAL
INTRODUCCIN
Como Antecedentes de este trabajo, llamado Sistema para el Control de Inventarios de una Farmacia (SCIF), tenemos que el problema radica en cmo aplicar Tecnologa Computacional a los negocios, en nuestro caso a una Farmacia.
Especficamente el control de inventarios en la Farmacia se realiza en base a los siguientes pasos:
De cada unidad podemos tener cero o ms medicamentos con su respectivo (nombre comercial, nombre genrico, precio, cdigo de barras, precio proveedor, control de medicamento, descuento y fecha de caducidad), de tales unidades se debe de estar muy atento en las que van a caducar. Los encargados de surtir la mercanca son los proveedores cuyos datos son: nombre, direccin, telfono, persona de contacto, email. El pedido de la mercanca se obtiene despus de hacer un balance general en la farmacia mediante el conteo, en base a las siguientes caractersticas; nmero de medicamentos en existencia y el ms vendido. La ubicacin real dentro de la farmacia se basa en el orden alfabtico de los medicamentos. El cliente a travs de una receta adquiere medicamentos (no siempre se requiere la receta), la consulta de mercanca la puede realizar cualquier ejecutivo de venta en la farmacia. Para cada medicamento se hace un descuento del 15% al 23% y slo es aplicado en la venta real, despus se entrega la mercanca y un ticket o una factura, en caso de ser factura es necesario que el cliente presente los siguientes datos; nombre, direccin, telfono, RFC, si es usuario registrado estos datos no son requeridos. El administrador se encarga de revisar el reporte de ventas y compras. En ocasiones se harn revisiones fsicas aleatorias de mercanca.
Ciencias de la Computacin
INTRODUCCIN GENERAL
Hasta ahora los pasos antedichos se controlan por medio de tarjetas de la forma siguiente: Cada tarjeta corresponde a un medicamento en especfico, en ella se describen todos los datos que se requieren, como son; nombre, precio, proveedor, existencias etc. Las ventas son anotadas en una libreta de reportes. Por la noche se realiza un reporte que consiste en analizar las ventas totales anotadas, comparndolas con el dinero en efectivo. Adems se toman algunas muestras aleatorias de 2 a 4 medicamentos y se comprueban con las existencias de sus tarjetas correspondientes. Como ya est plenamente probado los avances tecnolgicos nos permiten eliminar los rezagos existentes en los procesos anteriormente descritos y adems dicho sea de paso es el primer proyecto que se propone para el Control de Inventarios de la Empresa. El Objetivo General de este trabajo de tesis es el de: Analizar, Disear e Implantar un Sistema para el Control de Inventarios de la Farmacia LUMY, empleando el Modelo de Cascada en Ingeniera de Software y la herramienta Visual FoxPro para Bases de Datos. Los Objetivos Particulares que se plantean para alcanzar el objetivo general antes mencionado son: I. II. Recopilacin de los requisitos. Recopilacin, anlisis y clasificacin de informacin relacionada con Ingeniera de Software y con la teora de Bases de Datos. III. Hacer un anlisis profundo de los requisitos para realizar la especificacin de los requisitos del Sistema SCIF. IV. V. Realizar el Diseo del Sistema y de la Base de datos involucrada. Realizar la Implantacin del Sistema y de la Base de Datos, y dar a conocer los resultados obtenidos en las pruebas realizadas al Sistema. VI. Generar un documento que avale el desarrollo de este Proyecto de tesis. ii Ciencias de la Computacin
INTRODUCCIN GENERAL
Este Proyecto de Tesis se justifica ya que permite al autor; proporcionar informacin de apoyo, aplicar conocimiento y adquirir experiencia, tales aspectos se precisan an ms como sigue:
Para la Facultad: El documento presentado tendr importancia para los alumnos de la facultad, ya que en posteriores proyectos podrn agrandarlo, migrarlo a otras herramientas o tomarlo como una referencia.
Para la sociedad: No es un secreto que la computacin, a pesar de su juventud es una de las reas ms importante de la actualidad, entre otros motivos, por estar impulsando notablemente el desarrollo de todas las ciencias tecnolgicas. Dado el rpido crecimiento hoy en da, la sociedad se ha visto en la necesidad de modernizar y optimizar las formas de alcanzar el conocimiento y para ello la poblacin debe utilizar los mejores mtodos entre los cuales se encuentran las bases de datos.
Para mi persona: Me permite aplicar los conocimientos recibidos en los

cursos del Diplomado en Bases de Datos y en la formacin que obtuve en la Facultad de Ciencias de la Computacin BUAP. De igual manera poder adquirir experiencia en el desarrollo e implantacin de bases de datos de una manera confiable.
iii
INTRODUCCIN GENERAL
Contenido
Existen cuatro partes claramente diferenciadas:
El Captulo UNO consta de dos secciones, Ingeniara de Software y teora de Bases de Datos. En la parte uno se expone la definicin de Ingeniara de Software, una descripcin de la calidad del software, anlisis del Ciclo de vida de Software y un anlisis ms profundo sobre el Modelo de Cascada. En la parte dos se ver el concepto de Bases de Datos, el Modelos de Datos, un anlisis del Modelo Relacional enfatizando las Formas Normales y las operaciones bsicas del lgebra Relacional, el Modelo Funcional en base a los diagramas de flujo de datos, el comportamiento de los datos referente a los diagramas de transicin de estados y por ltimo sobre el Diccionario de Datos.
El Captulo DOS consta de ocho secciones, en la parte uno presentamos el documento de requisitos de usuario, una manera de cmo lo plantea el administrador, posteriormente se detallan los requisitos del sistema, en la parte tres mostramos el Diseo Conceptual que consta de identificar entidades, en seguida se normaliza cada una de las entidades y en el siguiente punto se presenta el diagrama entidad-relacin. En la seccin sexta especificamos las funciones bsicas y secundarias del desenvolvimiento en el Sistema, en seguida el diagrama funcional del Sistema que presenta el flujo de datos en el Sistema, por ltimo el Diccionario de Datos.
El Captulo TRES se basa en dos partes importantes, diseo lgico y diseo fsico. En el diseo lgico partimos del diagrama entidad relacin, para este diseo se utiliza el Modelo Relacional. Una vez iniciado este modelo, el sistema se divide en esquemas locales; los cuales se analizaron uno a uno, utilizando las tcnicas del modelo relacional, una vez terminado cada esquema se unieron todos los esquemas locales para formar el esquema general; es decir la obtencin del diagrama entidad relacin final. Por ltimo tomamos el diagrama final se mapea y por consecuencia se genern las tablas del Sistema. En el diseo fsico se crea una ambientacin grfica inicial del Sistema.
El Capitulo CUATRO consta de cuatro secciones, anlisis de la herramienta FoxPro, Implantacin del Sistema, Estado del Arte de las Bases de Datos, Conclusiones y Perspectivas. En la parte uno se hace una breve descripcin de FoxPro el por qu de su Utilizacin, la parte dos presenta la Implantacin del Sistema con las pruebas superadas, en la parte tres se habla del Estado del Arte de las Bases de Datos y cul ha sido su comportamiento en los ltimos aos, por ltimo en la parte cuatro se juntan las conclusiones y perspectivas que concluyen con el desarrollo del sistema y de este documento. iv Ciencias de la Computacin
INTRODUCCIN GENERAL
1. Marco Terico
1.1 Ingeniera de Software. 1 1.1.1 Definiciones de Ingeniera de Software.... 1 1.1.2 Calidad del software.... 1 1.1.3 Ciclos de vida de software...... 2 1.1.4 Modelo de cascada...... 3 1.1.4.1 Planificacin del sistema.... 4 1.1.4.2 Anlisis............. 4 1.1.4.3 Diseo. 4 1.1.4.4 Pruebas y mantenimiento... 5 1.2 Teora de Bases de Datos... 5 1.2.1. Definicin de bases de datos. 5 1.2.2 Caractersticas de Bases de Datos........... 5 1.2.3 Modelos de datos..... 7 1.2.4 Modelo relacional.. 8 1.2.4.1 Relaciones, tuplas, atributos y dominios.. 8 1.2.4.2 Claves primarias y claves ajenas... 9 1.2.4.3 Reglas de integridad.... 11 1.2.4.4 Formas normales.. 11 1.2.5 lgebra relacional..... 13 1.2.5.1 Operaciones bsicas.13 1.2.6 Modelo funcional... 14 1.2.6.1 Diagrama de flujo de datos (DFD) ....... 14 1.2.7 Diagrama de transicin de estados........................... 17 1.2.8 Diccionario de datos.......................... 18
2. Anlisis del Sistema S. C. I. F.

2.1 Especificacin de requisitos. 19 2.1.1 Documento de requisitos de usuario..... 19 2.1.2 Encuesta a los clientes del sistema (Administrador).. 19 2.2 Descripcin detallada del sistema... 20 2.2.1 Documento de especificacin del sistema... 22 2.3 Diseo Conceptual.... 22 2.3.1 Identificar las entidades... 22 2.3.2 Identificar relaciones.... 23 2.3.3 Identificar los atributos, asociarlos a entidades y relaciones 24 2.3.4 Determinar los identificadores... 24 2.4 Normalizar las entidades.. 24 2.4.1Primera forma normal (Elimina atributos repetidos)... 24 2.4.2 Segunda forma normal (Eliminamos redundantes)... 25 2.4.3Tercera forma normal (Eliminar datos no dependientes de la clave).26 2.5 Diagrama entidad-relacin... 26 2.5.1 Revisar el esquema conceptual local con el usuario.. 27 2.6 Funciones bsicas y secundarias... 28 2.7Diagrama funcional del sistema... 28 2.7.1 Diagrama de flujo de datos en nivel 0.......... 29 2.7.2 Diagrama de flujo de datos en nivel 1.......... 29
INTRODUCCIN GENERAL
2.7.3 Diagrama de flujo de datos en nivel 2... 30 2.8 Diccionario de datos.. 31
3. Diseo del Sistema S. C. I. F.

3.1 Revisin de requerimientos.. 33 3.2 Modelo relacional Justificacin para ACIF............. 33 3.3 Diseo lgico.. 33 3.3.1 Convertir esquemas conceptuales en esquemas lgicos locales. 33 3.3.1.1 Eliminar asociaciones muchos a muchos N:M.... 35 3.3.2 Derivar un conjunto de relaciones para cada esquema lgico..... 36 3.3.2.1 Crear una entidad para cada relacin fuerte 36 3.3.2.2 Crear una entidad para cada relacin dbil. 36 3.3.2.3 Crear entidades de Jerarquas de generalizacin...... 36 3.3.3 Validar cada esquema mediante la normalizacin.... 37 3.3.4 Validar cada esquema frente a las transacciones del usuario.. 39 3.3.5 Restricciones de integridad de las Entidades y Referencial. 40 3.3.6 Revisar esquema lgico local con el usuario.. 40 3.3.7 Mezclar los esquemas lgicos locales en un esquema lgico global41 3.3.8 Validar el esquema lgico global.... 41 3.3.9 Crecimiento a futuro..... 42 3.3.10 Dibujar el diagrama entidad/relacin final....... 42 3.3.11 Revisar el esquema lgico global..... 44 3.4 Ambientacin del sistema (Interfaz).... 45 3.4.1Inicio del sistema....... 45 3.4.2 Buscar precios de Medicamentos...... 45 3.4.3 Reporte de Ganancias......... 46
4. Implantacin y Pruebas
4.1 Anlisis de la herramienta FoxPro.... 47 4.1.1 Nivel externo vistas.... 47 4.1.2 Nivel conceptual... 47 4.1.3 Nivel interno paginacin... 47 4.1.4 Que lenguaje esta incluido en la herramienta.. 48 4.1.5 Organizacin de archivos... 48 4.1.6 Tipos de ndice.. 49 4.1.7 Integridad de los datos.... 50 4.2 Implantacin del Sistema. 50 4.2.1 Inicio del sistema...... 50 4.2.2 Entrada y salida de mercanca..................................................... 52 4.2.3 Interaccin externa 55 4.3 Estado del Arte de las Bases de Datos. 58 4.3.1 Nuevos problemas de presentacin de la informacin.. 58 4.3.2 Alternativas al modelo relacional... 59 4.3.3 Desafos actuales de las Bases de Datos... 60 4.3.3.1 La situacin a principios de los 90s.. 60 4.3.3.2 La situacin sobre 1995-1996... 61
vi
INTRODUCCIN GENERAL
4.3.3.3 Las ltimas consideraciones 1998. 61 4.4 Conclusiones.. 62 4.4.1 Objetivo general... 62 4.4.2 Objetivos particulares.. 62 4.5 Requisitos del Sistema.... 63 4.6 Perspectivas.. 64 4.6.1 Necesidades del cliente...... 64 4.6.2 Implantacin en red..... 65 4.6.3 Diseo conceptual Orientado a Objetos... 66
Bibliografa... 67
vii
MARCO TERICO
1. MARCO TERICO
1.1 Ingeniara de Software
1.1.1 Definiciones de Ingeniera de Software Ingeniera de Software es la aplicacin prctica del conocimiento cientfico en el diseo, construccin de programas de computadora y la documentacin asociada requerida para desarrollarlos, operarlos y mantenerlos. Ingeniera del Software.- Ciencia que estudia y documenta un conjunto de principios, metodologas, mtodos y tcnicas que permiten construir software o Sistemas de informacin de manera repetible y confiable.
1.1.2 Calidad del software En la actualidad los desarrolladores de software, coinciden en que el aplicar los principios de calidad al proceso de desarrollo de software, es una condicin necesaria para garantizar el xito de un proyecto. Se usa el trmino sistema de calidad para describir el proceso que asegura y demuestra la calidad de los productos y servicios que una empresa produce. Inicio del programa de calidad. Consiste en preparar una poltica de calidad y establecer la organizacin y estndares de apoyo a la calidad con los cuales se va operar. Puntos a considerar de acuerdo a la calidad de software: Planificacin de programa de calidad. Realizar una evaluacin y diagnstico de la organizacin, diseo del sistema de calidad y realizar un plan para su implantacin. Implantacin del programa cultural. Generar percepcin por la calidad, incentivar la participacin de todo el personal, y asegurar pertenencia. Implantacin del programa tcnico. Adoptar un ciclo de vida de desarrollo, desarrollar procedimientos y estndares, seleccionar e implantar mtodos y herramientas, definir e implantar un programa de mtricas, y realizar entrenamiento a usuarios.
Pg. 1
MARCO TERICO
Revisin y evaluacin. Las actividades principales son las revisiones del proyecto, auditorias de calidad, revisiones administrativas y control de seguimiento.
1.1.3 Ciclo de vida de software Como todo producto de ingeniera, el software tambin tiene su ciclo de vida. ste corresponde al periodo desde que el sistema se concibe hasta que se deja de usar. Pasando por su especificacin, desarrollo, transferencia, y explotacin. No obstante lo anterior, y dependiendo del problema especifico que se quiera solucionar, as como de las capacidades del equipo de desarrollo y del cliente, habr que utilizar un modelo de ciclo de vida para el desarrollo de entre las muchas alternativas posibles. El ciclo de vida de una aplicacin informtica nos va a llevar desde la definicin de los requisitos hasta la finalizacin de su uso, y esto lo podemos dividir en las siguientes etapas generales: Primera etapa: Definicin de requisitos En esta etapa el problema principal se centra en la formulacin correcta del problema en cuestin. Resulta imprescindible conocer el problema en profundidad para poder construir la aplicacin; igualmente el desarrollo de aplicaciones de informacin ser imprescindible estudiar las necesidades de informacin. Segunda etapa: Especificacin funcional En esta etapa se trata de expresar la estructura de la solucin, centrndonos en las necesidades del usuario de tal forma que ste pueda comprender de la forma ms correcta posible sus necesidades. En esta etapa nos aseguramos de haber entendido las necesidades del usuario. Tercera etapa: Diseo En esta etapa basndose en la tcnica existente, redacta los documentos que tendrn como destinatario al programador. Se ha de expresar el problema y la solucin en trminos informticos para que el programador pueda realizar su trabajo. Cuarta etapa: Realizacin En esta etapa se generan los programas que componen la aplicacin. Quinta etapa: Prueba En esta etapa se comprueba que todos los componentes de la aplicacin funcionan correctamente juntos. Pg. 2 Ciencias de la Computacin
MARCO TERICO
Sexta etapa: Mantenimiento Con la utilizacin de la aplicacin se van descubriendo funcionamientos defectuosos, ya que el cdigo libre de error al 100% es prcticamente imposible de conseguir, o ausencia de funcionalidad que no haba sido descrita con anterioridad. En el mantenimiento se suele volver a iniciar las etapas del ciclo de vida. El ciclo de vida se apoya en la teora de subdividir un problema en problemas ms pequeos como nos dice la teora del divide y vencers o la programacin estructurada.
1.1.4 Modelo de Cascada Este modelo divide el ciclo de vida del producto de programacin en una serie de actividades sucesivas; cada fase requiere informacin de entrada, procesos y resultados, bien definidos. El modelo de fases considera las siguientes partes:
El ciclo de vida clsico segn Roger S. Pressman.
Figura 1.1 modelo de cascada Este es el ciclo de vida clsico, usado en el desarrollo de productos de software. Pg. 3 Ciencias de la Computacin
Sistema Farmacutico SCIF 1.1.4.1 Planificacin del Sistema
MARCO TERICO
Es la etapa en la que se determina si el proyecto es o no factible de realizar y se determinan tiempos y costos aproximados, estableciendo as la ruta crtica de cada actividad. Esto es porque la falta de planeacin de un sistema es la causa principal de retrasos en programacin, incremento de costos, poca calidad, y altos costos de mantenimiento en los desarrollos de productos de software. Con frecuencia se dice que es imposible realizar una planeacin inicial, porque la informacin precisa sobre las metas del proyecto, necesidades del cliente y restricciones del producto no se conocen al comenzar el proyecto de desarrollo, sin embargo, uno de los principales propsitos de esta fase es aclarar los objetivos, problemas o necesidades y restricciones.
1.1.4.2 Anlisis Es indispensable comprender perfectamente los requisitos del software, para que ste no fracase. Abundan los casos en que se puede llegar a malas interpretaciones o falta de informacin. Existe una frase que se utiliza al momento de hacer el anlisis, y es la siguiente: "Se que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creste or sea lo que yo quise decir..."
1.1.4.3 Diseo El diseo del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa: La estructura de los datos La arquitectura del software El detalle procedimental La caracterizacin de la interfaz
El proceso de diseo traduce los requisitos en una representacin del software que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificacin. Al igual que los requisitos, el diseo se documenta y forma parte de la configuracin del software.
Pg. 4
MARCO TERICO
Codificacin El diseo debe traducirse en una forma legible para la mquina. Si el diseo se realiza de una manera detallada, la codificacin puede realizarse mecnicamente.
1.1.4.4 Pruebas y Mantenimiento Prueba Una vez que se ha generado el cdigo, comienza la prueba del programa. La prueba se centra en la lgica interna del software, asegurando que todas las sentencias se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento Es indudable que el software una vez entregado al cliente sufrir cambios Los cambios ocurrirn debido a que se hayan encontrado errores, a que el software deba adaptarse a posibles cambios.
1.2 Teora de Bases de Datos

1.2.1 Definicin de Base de Datos Coleccin de datos interrelacionados, almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es la de servir a una aplicacin o a varias, de la mejor manera posible. Se emplean mtodos bien determinados para incluir, modificar o extraer datos almacenados " de James Martn. Es un conjunto de datos almacenados, que son procesados por el sistema de aplicaciones de una determinada empresa de C.J. Date.
1.2.2 Caractersticas de Bases de Datos Las bases de datos han evolucionado durante los pasados 30 aos desde sistemas de archivos rudimentarios hasta sistemas administradores de complejas estructuras de datos que ofrecen un gran nmero de posibilidades. Los principales objetivos de un DBMS son los siguientes: 1. Independencia fsica: El modo en el que se almacenan los datos no influye en su manipulacin lgica y, por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico. Pg. 5 Ciencias de la Computacin
MARCO TERICO
2. Independencia lgica: El aadir, eliminar o modificar objetos de la base de datos no repercute en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos. 3. Redundancia mnima: Usar la base de datos como almacn comn de datos para distintas aplicaciones. 4. Acceso concurrente por parte de mltiples usuarios: Control de concurrencia mediante tcnicas de bloqueo o cerrado de datos accedidos. 5. Integridad de los datos: Medidas de seguridad que impiden que se introduzcan datos errneos. Esto puede suceder tanto por motivos fsicos (defectos de hardware, actualizacin incompleta debido a causas externas), como de operacin (Introduccin de datos incoherentes). 6. Consultas complejas optimizadas: La optimizacin de consultas permite la rpida ejecucin de las mismas. 7. Seguridad de acceso y auditoria: Derecho de acceso a los datos contenidos en la base de datos por parte de personas y organismos. El sistema de auditoria mantiene el control de acceso a la base de datos, con el objeto de saber qu o quin realiz una determinada modificacin y en qu momento. 8. Respaldo y recuperacin: Capacidad de un sistema de base de datos de recuperar su estado en un momento previo a la prdida de datos. 9. Acceso a travs de lenguajes de programacin estndar: Posibilidad de acceder a los datos de una base de datos, mediante lenguajes de programacin ajenos al sistema de base de datos. Una base de datos tpica conlleva la existencia de tres tipos de usuario con relacin a su diseo, desarrollo y uso: El administrador de bases de datos (DBA: Datbase Administrator), disea y mantiene la Base de Datos (DB). El desarrollador de aplicaciones transacciones e interfaces. (programador): implementa las
Los usuarios finales: consultan y editan los datos de la base de datos mediante un lenguaje de consulta de alto nivel. En general, el propsito de una base de datos es: responder a consultas sobre los datos que contiene y ejecutar transacciones
Pg. 6
Sistema Farmacutico SCIF 1.2.3 Modelos de Datos
MARCO TERICO
Un conjunto de conceptos, reglas y convenciones bien definidas que nos permiten aplicar una serie de abstracciones a fin de describir y manipular los datos de un cierto mundo real que deseamos almacenar en la base de datos. Los modelos de datos aportan la base conceptual para disear aplicaciones que hacen un uso intensivo de datos, as como la base formal para las herramientas y tcnicas empleadas en el desarrollo y uso de sistemas de informacin. Un modelo de datos es, por tanto, una coleccin de conceptos bien definidos matemticamente que ayudan a expresar las propiedades estticas y dinmicas de una aplicacin con un uso de datos intensivo. La caracterizacin de un modelo conceptual est dada por: Propiedades Estticas: relativamente invariantes en el tiempo, que responden a lo que suele entender como estructuras. Propiedades Dinmicas: son las operaciones que se aplican a los datos en las estructuras, las cuales varan en el transcurso del tiempo. Restricciones de integridad: correccin de los datos y a su consistencia en el mundo real.
As, un modelo de datos se distingue de otro por el tratamiento que da a estas tres categoras. Un esquema consiste en una definicin de todos los tipos de objetos de la aplicacin, incluyendo sus atributos, relaciones y restricciones estticas. Una transaccin consiste en diversas operaciones o acciones sobre las entidades de esquema o subesquema. Una consulta se puede expresar como una expresin lgica sobre los objetos y relaciones definidos en el esquema; una consulta identifica un subconjunto de la base de datos.
Pg. 7
Sistema Farmacutico SCIF 1.2.4 Modelo Relacional
MARCO TERICO
Los lenguajes matemticos sobre los que se asienta el modelo relacional: El lgebra y el clculo relacinales, aportan un sistema de acceso y consultas orientado al conjunto. Su enorme xito se debe a los altos niveles de fiabilidad e integridad que aporta en el manejo de grandes cantidades de datos. Su creador, Ted Codd, bas expresamente su funcionamiento sobre un modelo matemtico muy especfico: el lgebra relacional y el clculo relacional, as como la progresiva adopcin, por parte de su creador y algunos colaboradores, de un nmero de Reglas de Integridad Relacional y de Formas Normales
1.2.4.1 Relaciones, tuplas, atributos y dominios El modelo relacional est basado en la teora de conjuntos. En este modelo, los datos se organizan en un tipo especial de conjunto denominado relacin, que se define de la siguiente manera: Relacin: Dada una serie de conjuntos D1, D2... Dn (no necesariamente distintos), se dice que R es una relacin sobre estos n conjuntos si es un conjunto de n tuplas ordenadas d1, d2... dn; tales que di pertenece a Di, d2 pertenece a D2, ... , dn pertenece a Dn. Los conjuntos D1, D2... Dn, son los dominios de R. El valor n es el grado de R. Los elementos de una relacin se denominan tuplas. El nmero de tuplas en una relacin es la cardinalidad de la relacin. Puesto que una relacin es un conjunto, los elementos de este conjunto, las tuplas, han de ser por fuerza distintas. Esto tambin implica que el orden de las tuplas es irrelevante. El conjunto vaco es una relacin particular: La relacin nula o vaca. Las relaciones tambin pueden ser vistas como tablas, en las que cada tupla es una fila de la tabla. Los nombres de las columnas de la tabla, son los atributos. Nos podemos referir a los atributos de una relacin mediante su nombre o por la posicin (nmero de columna) que el atributo ocupa en el esquema de la relacin. Las tuplas, por tanto, pueden ser consideradas como matrices de pares atributo, valor. Consideremos ahora las caractersticas de los valores de los atributos. Tales valores vienen de un dominio y el domino para un atributo define los valores validos que pueden tomar los atributos de cada tupla.
Pg. 8
MARCO TERICO
Los trminos formales del modelo relacional a menudo son sustituidos por otros de uso ms comn, As obtenemos las siguientes equivalencias.
Entidad o Relacin Tupla Cardinalidad Atributo Grado Dominio
Tabla Registro o Fila No de tuplas Campo o columna No de atributos Fondos de valores legales
Figura 1.2 Algunas equivalencias en el modelo relacional
En cuanto a representacin tabular se dice que una relacin consta de dos partes: cabecera (heading) y cuerpo (body). La cabecera es el conjunto de atributos (columnas) y el cuerpo es el conjunto de tuplas (filas).
Cabecera:
ClaveEmpleado 1000 1001
Nombre Juan Ral Luis Erika
ApePat Flores Montes Barbosa Avendao
ApeMat Cortes Prez Hernndez Almazn
Cuerpo:
1002 1003
Figura 1.3 Modelo de una tabla
1.2.4.2 Claves primarias y claves ajenas Puesto que las tuplas son irrepetibles, una relacin necesita un identifcador nico para cada una de las tuplas, esta es la clave primaria de la relacin, cuyos valores no pueden ser repetidos. Una clave primaria debe ser mnima, en el sentido que en su composicin no intervengan ms que los atributos estrictamente requeridos para identificar las tuplas de forma nica. Puesto que una relacin es un conjunto de tuplas, se debe dar la condicin de que toda relacin deba tener una clave primaria, adems puede ser simple (formada por un solo atributo) o compuesta (formada por ms de uno). Claves ajenas Un RDBMS ofrece la posibilidad de interrelacionar dos o ms relaciones existentes en una base de datos. De hecho, es sta la facultad que dota de mayor potencia al modelo. Pg. 9 Ciencias de la Computacin
MARCO TERICO
Las asociaciones Las asociaciones son las relaciones que existen entre varias entidades del sistema. Existen tres formas de asociaciones dependiendo de la cardinalidad con la que se combinan los elementos de ambas tablas. Asociaciones uno a uno Una entidad es de uno a uno entre la entidad A y la entidad B cuando a cada elemento de la clave de A se le asigna un nico elemento de la entidad B y para cada elemento de la clave entidad B contiene un nico elemento en la entidad A. Ante la presencia de este tipo de relacin nos podemos plantear el caso de unificar todos los datos en una nica entidad pues no es necesario mantener ambas relaciones a la misma vez. Asociaciones uno a varios Una asociacin es de uno a varios entre las entidades A y B cuando una clave de la entidad A posee varios elementos relacionados en la entidad B y cuando una clave de la entidad B posee un nico elemento relacionado en la entidad A. Asociaciones varios a varios Una asociacin es de varios a varios entre las entidades A y B cuando una clave de la entidad A posee varios elementos relacionados en la entidad B y cuando una clave de la entidad B posee varios elementos relacionados en la entidad A. Se debe transformar este tipo de relacin es dos asociaciones de tipo 1: n, empleando para ello una entidad que denominaremos puente y que estar formada por las claves de ambas entidades. Esta entidad puente debe contener una nica clave compuesta formada por los campos clave de las entidades primeras. Problemas con las asociaciones A la hora de establecer las asociaciones existentes en un sistema de bases de datos nos podemos encontrar dos problemas. Asociaciones recursivas: un elemento se relaciona consigo mismo directamente. Asociaciones circulares o cclicas: A se relaciona con B, B se relaciona con C y C se relaciona con A. Atributos de las asociaciones En la mayora de las asociaciones definidas ser conveniente exigir integridad relacional entre las claves. Exigiendo la integridad referencial se consigue que en una relacin de tipo 1: n o de tipo 1: 1, no se puede aadir ningn Pg. 10 Ciencias de la Computacin
MARCO TERICO
valor en la tabla destino si no existe en la tabla origen. Definida la integridad referencial podemos exigir la actualizacin en cascada.
1.2.4.3 Reglas de integridad Con este nombre se designa a aquellas reglas que han de ser aplicadas a una base de datos para asegurar que los datos introducidos sean consistentes con la realidad que pretenden modelar. Existen dos reglas generales que aporta el modelo relacional. Regla de integridad de la entidad: ningn componente de la clave primaria de una relacin base puede aceptar valores nulos. Regla de integridad de referencia: la base de datos no debe contener valores de clave ajena sin concordancia. La primera de estas reglas impide la existencia de una tupla sin identificador nico. Es decir, todas las entidades deben ser distinguibles por definicin, deben tener alguna identificacin nica de alguna clase. Las llaves primarias realizan la funcin de identificacin nica en una base de datos relacional. Hemos de recordar que slo los productos puramente relacinales implementan realmente estas dos reglas generales de integridad relacional. Adems, muchos RDBMS aaden un buen nmero de caractersticas que ayudan al DBA a mantener ms fcilmente la integridad de los datos. Mediante estos mecanismos es posible aadir reglas especficas para cada base de datos; stas son las denominadas restricciones de integridad definidas por el usuario.
1.2.4.4 Formas normales El proceso de normalizacin es un estndar que consiste, bsicamente, en un proceso de conversin de las relaciones entre las entidades, evitando: La redundancia de los datos: repeticin de datos en un sistema. Anomalas de actualizacin: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales. Anomalas de borrado: prdidas no intencionadas de datos debido a que se han borrado otros datos.
Pg. 11
MARCO TERICO
Anomalas de insercin: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos. El proceso de normalizacin nos conduce hasta el modelo fsico de datos y consta de varias fases denominadas formas normales, estas formas se detallan a continuacin. Primera forma normal (1NF) Se dice que una entidad se encuentra en primera forma normal (1NF) si y solo si cada uno de los campos contiene un nico valor para un registro determinado. Los aspectos a considerar son los siguientes: Eliminar grupos repetidos en las entidades individuales. Crear una entidad separada para cada conjunto de datos relacionados. Identificar cada conjunto de datos relacionados con una llave primaria. No usar campos mltiples en una relacin nica para almacenar datos similares. Segunda forma normal (2NF) La segunda forma normal compara todos y cada uno de los campos de la entidad con la clave definida. Si todos los campos dependen directamente de la clave se dice que la entidad est es segunda forma normal (2NF). Los aspectos a considerar son los siguientes: Crear entidades separadas para un conjunto de valores que se apliquen a mltiples registros. Relacionar esta entidad con una llave externa. Los registros no debern depender de nada a excepcin de una llave primaria de la entidad. Tercera forma normal (3NF) Se dice que una entidad est en tercera forma normal si y solo si los campos de la entidad dependen nicamente de la clave, dicho en otras palabras los campos de la entidad no dependen unos de otros. Los aspectos a considerar son los siguientes: Mutuamente independientes Dependientes por completo de la clave primaria
Pg. 12
Sistema Farmacutico SCIF 1.2.5 lgebra relacional
MARCO TERICO
Las operaciones de lgebra relacional manipulan relaciones. Esto significa que estas operaciones usan uno o dos relaciones existentes para crear una nueva relacin. Este poderoso concepto de la creacin de una nueva relacin a partir de relaciones existentes hace considerablemente ms fcil la solucin de las consultas, debido a que se puede experimentar con soluciones parciales hasta encontrar la proposicin con la que se trabajar.
1.2.5.1 Operaciones bsicas Unin La operacin de unin permite combinar datos de varias relaciones. No siempre es posible realizar consultas de unin entre varias entidades, para poder realizar esta operacin es necesario e imprescindible que las entidades a unir tengan las mismas estructuras y que sus campos sean iguales. Interseccin La operacin de interseccin permite identificar filas que son comunes en dos relaciones. Diferencia La operacin diferencia permite identificar filas que estn en una relacin y no en otra. Producto La operacin producto consiste en la realizacin de un producto cartesiano entre dos tablas dando como resultado todas las posibles combinaciones entre los registros de la primera y los registros de la segunda. Seleccin La operacin seleccin consiste en recuperar un conjunto de registros de una entidad o de una relacin indicando las condiciones que deben cumplir los registros recuperados, de tal forma que los registros devueltos por la seleccin han de satisfacer todas las condiciones que se hayan establecido. Esta operacin es la que normalmente se conoce como consulta. En este tipo de consulta se emplean los diferentes operadores de comparacin (=,>, <, >=, <=, <>), los operadores lgicos (and, or, xor) o la negacin lgica (not). Proyeccin Una proyeccin es un caso concreto de la operacin seleccin, esta ltima devuelve todos los campos de aquellos registros que cumplen la condicin que se ha establecido. Una proyeccin es una seleccin en la que seleccionamos aquellos campos que deseamos recuperar. Pg. 13 Ciencias de la Computacin
MARCO TERICO
Reunin La reunin se utiliza para recuperar datos a travs de varias entidades conectadas unas con otras mediante clusulas JOIN, en cualquiera de sus tres variantes INNER, LEFT, RIGHT. La operacin reunin se puede combinar con las operaciones seleccin y proyeccin. Divisin Si dividimos la entidad B entre la entidad A obtendremos como resultado una tercera entidad que: los campos que contiene son aquellos de la entidad B que no existen en la entidad A. Un registro se encuentra en la tabla resultado si y slo si est asociado en tabla B con cada fila de la tabla A Asignacin Esta operacin algebraica consiste en asignar un valor a uno o varios campos de una entidad.
1.2.6 Modelo Funcional 1.2.6.1 Diagramas de Flujo de Datos (DFD). Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre s por los datos. Representa el flujo de la informacin y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida. Se representa el funcionamiento general del sistema como una nica transformacin de informacin. Las entidades externas originan una o ms entradas de informacin, que aparecen como flechas etiquetadas, y la informacin de salida se dirige hacia las entidades externas. Estas representaciones grficas reciben el nombre de diagramas de flujo de datos (DFD).
Notacin de los diagramas de flujo de datos.
Entidades externas
Almacenamiento
Procesos
Flujo de informacin
Pg. 14
MARCO TERICO
Proceso: Corresponde a una parte del sistema que transforma entradas en salidas. El nombre del proceso debe describir lo que el proceso hace. Flujo de datos: Representan datos en movimiento. Su nombre representa el significado de la informacin en movimiento. El sentido de las flechas muestra la direccin del flujo. Las flechas de sentido doble representan dilogos. Las flechas que se separan representan la bifurcacin en flujos menores. Almacenes de datos: Representan conjuntos de datos en reposo. El nombre del almacn es el plural del nombre de la informacin que entra y sale del almacn.
Un DFD no muestra: Composicin del flujo de datos. Relaciones de acceso. Decisiones. Clculos. Cantidades. Representacin del nivel 0
Entrada
Sistema
Salida
Dialogo
Figura 1.4 Modelo de diagrama de flujo En el DFD de nivel 0 no aparecen los almacenamientos de datos, y es en el nico DFD donde aparecen las entidades externas. Pg. 15 Ciencias de la Computacin
MARCO TERICO
Representa al elemento del software completo como una sola burbuja con datos de entrada y de salida representados con flechas y las entidades externas. Con esto no vemos la secuencia en la que se van a producir los movimientos de datos. En cada burbuja se pueden descomponer los procesos en subprocesos o niveles: Los DFD no proporcionan ninguna indicacin explicita de la secuencia de procesamiento, se representa lo que se va a hacer, pero no el orden en que se llevar a cabo. Se puede refinar cada uno de los procesos en distintos niveles para mostrar un mayor detalle, es decir, se hace una descomposicin en subniveles. Normas de elaboracin de los DFDs: Elegir nombres significativos para procesos, flujos, almacenes y terminadores (entidades externas). Numerar los procesos. La numeracin de los procesos se hace de arriba hacia abajo y de izquierda a derecha, manteniendo la numeracin del proceso del nivel anterior. Evitar los DFD demasiado complejos. Redibujar los diagramas tantas veces como sea necesario. Asegurarse que el DFD es consistente consigo mismo y con los DFD asociados.
Puntos importantes: El DFD de nivel 0 da una imagen global, que es la que interesa al usuario, se identifican todos las interfaces de nuestro sistema con el exterior. Para tratar sistemas complejos, se utilizan los niveles, que dan como resultado la aparicin de jerarquas de DFDs. Un DFD no debe contener ms de 7-9 procesos para ser comprensible. Los almacenamientos de datos se pueden representar a distintos niveles tantas veces como sea necesario. A un proceso de un determinado nivel se le llama padre, y mediante la explosin da lugar a un diagrama hijo, situado un nivel por debajo. Este diagrama resultante especifica y descompone la globalidad anterior. La explosin se va ejecutando para todos los elementos que la requieren hasta alcanzar un nivel de especificacin mnimo sencillo, que haga totalmente comprensibles todos y cada uno de los minisistemas.
Pg. 16
Sistema Farmacutico SCIF Tcnicas de construccin de los DFDs: 1.- Basado en los flujos de datos.
MARCO TERICO
Comenzando por los extremos, conectar todas las entradas y salidas netas. Colocar un proceso cuando un dato se transforme. Nombrar todos los flujos de datos. Nombrar todos los procesos. Aadir almacenes cuando los datos se detengan sin sufrir transformacin. 2.- Basado en procesos. Situar los procesos. Aadir los flujos y almacenes de datos. Unir los procesos que comparten flujos de datos y almacenes.
1.2.7 Diagrama de transicin de estados El modelado del comportamiento es uno de los principios fundamentales de todos los mtodos de anlisis de requisitos. El Diagrama de Transicin de Estados (DTEs) representa el comportamiento de los datos. Un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado. El DTE indica que acciones se llevan a cabo como consecuencia de un suceso determinado. Un estado es cualquier modo observable de comportamiento. En el DTEs se indica como cambia el sistema de un estado a otro. En este Diagrama las flechas siempre representan una transicin; Los rectngulos representan estados del sistema, y las flechas representan transiciones entre estados. Cada flecha est etiquetada en forma de fraccin, el numerador indica el suceso o sucesos que hacen que se produzca la transicin, y el denominador indica la accin que se produce como consecuencia del suceso. La especificacin de control describe el comportamiento del sistema, pero no nos proporciona informacin sobre el funcionamiento interno de los procesos que son activados como resultado de ese comportamiento. La especificacin del proceso describe todos los procesos del modelo de flujo que aparecen en el nivel final de refinamiento. Pg. 17 Ciencias de la Computacin
Sistema Farmacutico SCIF 1.2.8 Diccionario de datos
MARCO TERICO
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensin de las entradas, salidas, almacenes de datos y clculos intermedios. El diccionario de datos contiene la siguiente informacin: Nombre: nombre principal del elemento de datos o control, del almacenamiento o de una entidad externa. Alias: otros nombres usados para la entrada. Donde se usa/Como se usa: un listado de los procesos que usan el elemento de datos o de control y como lo usan. Descripcin del contenido: el contenido representado mediante una notacin. Informacin adicional: otra informacin sobre los tipos de datos, los valores implcitos, restricciones, limitaciones. Notacin para la descripcin del contenido del diccionario de datos: SMBOLO = + 1{ } n [I] () SIGNIFICADO Est compuesto de Y conjuntamente con N repeticiones de Seleccionar uno de Dato opcional
Pg. 18
ANLISIS DEL SISTEMA SCIF
2. ANLISIS DEL SISTEMA S. C. I. F.

2.1 Especificacin de requisitos
2.1.1 Documento de requisitos de usuario De cada unidad, a considerar en el Sistema de Control de Inventario de una Farmacia (SCIF), podemos tener cero o ms medicamentos con su respectivo nombre comercial, nombre genrico, precio, cdigo de barras, precio venta, precio proveedor, control de medicamento, descuento, tipo medicamento y fecha de caducidad, de tales unidades se debe de estar muy atento en las que van a caducar. Los encargados de surtir la mercanca a la farmacia son los proveedores cuyos datos son: nombre, direccin, telfono, persona de contacto, email. El pedido de la mercanca se obtiene despus de hacer un balance general en la farmacia mediante el conteo, con las siguientes caractersticas: nmero de medicamentos en existencia y el ms vendido. La ubicacin real se basa en el orden alfabtico de las presentaciones. El cliente a travs de una receta adquiere el medicamento (no siempre se requiere la receta), la consulta y bsqueda de mercanca la puede realizar cualquier ejecutivo de venta que labore en la farmacia actualmente. Para cada presentacin se hace un descuento del 15% al 23% y slo se aplica en la venta real, despus se entrega la mercanca y un ticket o una factura, en caso de que se solicite factura es necesario que el cliente presente: nombre, direccin, telfono y RFC. El administrador se encarga de revisar el reporte de ventas y compras. En ocasiones se harn revisiones fsicas aleatorias de mercanca 2.1.1 Encuesta a los clientes del sistema (Administrador) P: Cul es su labor dentro de la empresa? R: Soy el administrador de la farmacia LUMY y Mdico responsable. P: Qu preparacin necesita una persona para atender la farmacia? R: En principio debe tener estudios bsicos en medicina. P: Cul es el horario de atencin? R: El horario es de 7:00 am a 22:00 Pm. Urgencias las 24 horas. P: Cuntas personas laboran en la farmacia? Pg. 19 Ciencias de la Computacin
R: En la farmacia laboran 6 personas; Contador, 4 ejecutivos de venta y el administrador Mdico Responsable. P: Cules son los requisitos para vender los medicamentos? R: En general ninguno, en caso de ser medicamentos controlados por parte de la Secretaria de Salud, entonces si es requisito indispensable su receta mdica claramente legible. P: Existe un nmero clave para cada medicamento? R: Es a travs de su cdigo de barras o por parte de los proveedores que le asignan una clave de identificacin para cada medicamento. P: Cada qu tiempo se realiza un inventario? R: Cada fin de ao se realiza un inventario general, y mensualmente se toman algunas muestras aleatoriamente. P: Cuando una persona solicita un medicamento, cmo comprueba si es controlado o no? R: En base a una tabla de medicamentos que nos otorga la Secretaria de Salud. P: Qu pasa si el medicamento no lo tienen en ese momento? R: Se le pregunta al cliente si es urgente, en caso afirmativo nosotros en menos de 12 horas tenemos el medicamento.
2.2 Descripcin detallada del sistema

Vamos a construir el siguiente documento que nos permite visualizar el sistema de una forma muy sencilla y fcil de entender, el sistema tiene funciones relevantes que a continuacin se describen: Descripcin de todas las entidades: Medicamentos: Es la entidad bsica central del sistema, define as sus atributos: IdClave, nombre comercial, nombre genrico, precio de venta, cdigo de barras, precio proveedor, control de medicamento, descuento, tipo medicamento y fecha de caducidad. En esta entidad se almacena la informacin ms importante que procesa el sistema. Su trabajo se divide en dos partes fundamentales: La primera ser saber con cuantas presentaciones mdicas contamos en tiempo real y la segunda poder cambiar los precios de los medicamentos. De esta manera podremos concretar el buen funcionamiento de nuestra entidad. Proveedores: Esta entidad se encarga de surtir todas las presentaciones mdicas hacia la entidad bsica Entidad de medicamentos, sus atributos son los siguientes: IdProveedor, Nombre del proveedor, Direccin, Telfono, Persona de Pg. 20 Ciencias de la Computacin
contacto, Email. Es importante sealar que la farmacia en ocasiones ser la que transporte la mercanca a la farmacia, la gran mayora de veces los proveedores envan la mercanca. Pedidos: La forma de realizar el pedido, es a base de una consulta en el sistema, teniendo como mxima prioridad a los dos siguientes atributos de consulta: Nmero de presentaciones mdicas en existencia real y las presentaciones ms vendidas en un rango de 30 das anteriores, tomando como referencia el da que se proceso la consulta al sistema. La organizacin interna de la farmacia en las presentaciones est dada por estantera y un orden alfabtico de los medicamentos, de esta manera nos ayuda a facilitar la bsqueda fsica de cualquier medicamento de una manera ms rpida y eficiente. Cliente: En esta entidad el cliente debe ser registrado en caso de pedir una factura, aclarando que es un nuevo cliente, pero si antes ha sido registrado entonces el sistema lo reconocer y no necesita dar nuevamente sus datos. El cliente ser registrado con los siguientes atributos: IdCliente, RFC, Nombre, Direccin, Telfono. Para el caso del cliente sin necesidad de facturar le ser entregado un ticket de compra. La bsqueda: de medicamentos se basa en dos aspectos fundamentales que son, nombre comercial y nombre genrico sustancia activa; los cuales definen la forma de poder encontrar cualquier medicamento dentro del sistema. El nombre comercial de un medicamento es el que conoce la mayora de la sociedad, pero el nombre genrico es la frmula del medicamento o sustancia activa y casi siempre solo es conocido por un mdico, un laboratorista o un encargado de sistemas farmacuticos. La bsqueda se realiza por el personal que labora en la farmacia, como: Bsqueda por el nombre comercial Bsqueda por el nombre genrico Sustancia activa Aclaracin: Nombre genrico = Sustancia activa = Frmula Empleados: La entidad nos organiza a todos los empleados con sus respectivos atributos: IdEmpleados, Nombre, Direccin, Telfono, Fecha de ingreso, Edad, Sexo, Ocupacin, Clave. La venta: En esta entidad se registran todas las ventas realizadas dentro de la farmacia, cada presentacin mdica podr obtener un descuento del 15% al 23%. Los descuentos son asignados o cambiados por el administrador a cada medicamento dentro del inventario.
Pg. 21
El administrador: obtiene un reporte de las ventas realizadas en el da actual, obteniendo un balance de los medicamentos vendidos.
2.2.1 Documento de especificacin del sistema La farmacia LUMY SA de CV contiene una gran variedad de medicamentos, los cuales se deben organizar en una forma eficiente y as poder ofrecer al cliente una excelente atencin. Los medicamentos son ms conocidos por su nombre comercial que por su nombre genrico. El personal se encarga de realizar:
Los empleados Obtener un listado de los medicamentos controlados. Obtener una bsqueda de los medicamentos en existencia por: a) Nombre comercial b) Nombre genrico Realizar ventas de mercanca con sus dos variantes: a) Sin factura. b) Con factura. Preguntar si es usuario registrado. Obtener una consulta de los medicamentos faltantes. El administrador Calcular las ganancias semanalmente. Cambiar el precio de los medicamentos de acuerdo a su tipo. Cambiar el valor de descuento de los medicamentos. Eliminar medicamentos del sistema Revisar el inventario al menos 2 veces al mes.
2.3 Diseo Conceptual

Con base a los requerimientos ya establecidos anteriormente, iniciaremos con el planteamiento del Modelo Conceptual; el cual nos lleva a una descripcin ms cercana al Modelo Relacional tablas, modelo que utilizaremos ms adelante. El Modelo Conceptual nos permite corregir los detalles que no fueron tomados en cuenta en el anlisis del sistema.
2.3.1 Identificar las entidades Las entidades que a continuacin se muestran, son obtenidas del anlisis del sistema SCIF; son presentadas como una abstraccin de los requisitos que el cliente tiene como una necesidad. Las entidades probables son presentadas de la siguiente manera. Pg. 22 Ciencias de la Computacin
Sistema Farmacutico SCIF Medicamentos Proveedores Clientes Administrador Empleados
En el anlisis de las entidades probables surge un conflicto al observar que las entidades empleado y administrador tienen casi todo en comn, en el contenido de su informacin, es por eso que nos dimos a la tarea de unir ambas entidades a una sola entidad con el nuevo nombre de Personal. De aqu se reducen a solo cuatro entidades posibles. Administrador y empleados = Personal
2.3.2 Identificar relaciones En esta seccin se toman las entidades y se trata de concretar que asociaciones pueden tener una entidad con otra. Tales asociaciones no solo se suponen, si no que se consideran en base al anlisis. Se deben tomar con mucha precaucin para no interpretar mal el funcionamiento del sistema SCIF. Las asociaciones son las acciones que realiza una entidad hacia la otra entidad y viceversa, se presentan las siguientes asociaciones con el objetivo de presentar sus posibles enlaces: Cliente compra medicamentos Empleado vende medicamentos Proveedor surte medicamentos Empleado busca medicamentos Administrador obtiene reportes Administrador asigna claves empleados
Pg. 23
2.3.3 Identificar los atributos, asociarlos a entidades y relaciones 1. Medicamentos (Nombre comercial, Nombre genrico, Tipo medicamento, Cdigo de barras, Precio de venta, Precio proveedor, Medicamento controlado, Descuento, Existencias). 2. Proveedores(Nombre del proveedor, Direccin del proveedor, Telfono del proveedor, Persona de contacto, Email del proveedor) 3. Cliente(RFC cliente, Nombre Cliente, Direccin cliente, Telfono cliente) 4. Empleados(Nombre empleado, Direccin empleado, Telfono empleado, Fecha de ingreso empleado, Clave de acceso, Puesto)
2.3.4 Determinar los identificadores Para cada entidad ser necesario asignarle un identificador nico, dicho de otra manera una clave nica que distinga perfectamente la descripcin bsica de las entidades sin ambigedades. Con esto se garantiza que no se duplica la informacin que se almacena en cada una de las entidades presentadas en el proceso del Modelo Conceptual. Los identificadores se presentan en el orden en que las entidades son descritas.
Nombre del identificador IdMedicamento (IdMed) IdProveedor (IdProv) IdCliente (IdCli) IdEmpleado (IdEmp)
Entidad Medicamentos Proveedores Clientes Empleados
Tipo Numrico 6 Numrico 6 Numrico 6 Numrico 6
Fig. 2.1 Identificadores de entidades del Sistema SCIF
2.4 Normalizar las entidades

Se toma cada una de las entidades para transformarla de acuerdo a las condiciones que se imponen dentro de las formas normales. 2.4.1Primera forma normal (Elimina atributos repetidos) Para cada una de las entidades aqu presentadas, ninguna cuenta con atributos repetidos; por lo tanto ya se encuentran en la primera forma normal.
Pg. 24
MEDICAMENTO I IdMed I NomCom I NomGen I TipMed I CodBa I PreVent I PreProv I ContMed I Desc I Exist I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I
2.4.2 Segunda forma normal (Eliminamos redundantes) En la entidad medicamentos se identifica un pequeo problema, con los dos atributos siguientes TipMed (Tipo de medicamento) y ContMed (Medicamentos controlados), ambos campos van a generar atributos repetidos o perdida de memoria en el almacenamiento de la informacin.
MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I TIPOMED I TipMed I TipoMed I CONTOLMED I ContMed I ControlMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I
Pg. 25
2.4.3Tercera forma normal (Eliminamos datos no dependientes de la clave) No contamos con dependencias transitorias dentro de las entidades mostradas, de esta forma solo se muestran como quedan la entidades ya normalizadas hasta le tercera forma normal.
MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I TIPOMED I TipMed I TipoMed I CONTOLMED I ContMed I ControlMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I
2.5 Diagrama entidad-relacin

Despus de un anlisis completo de todo lo que abarca el sistema SCIF se proyecta el diagrama entidad relacin principal y sus relaciones existentes entre las entidades participantes.
Pg. 26
Fig. 2.2 Diagrama entidad relacin
2.5.1 Revisar el esquema conceptual local con el usuario Al presentar el Modelo Conceptual se obtuvo un resultado satisfactorio por parte del cliente, pues con este modelo se obtuvo una mejor visin del sistema SCIF. El cliente y su equipo de trabajo despus de una revisin da como aprobado el modelo conceptual que se le entrego, el comentario por su parte fue, la forma de entender su problema ya que es muy descriptivo y fcil de entender, sobre todo en el desglose de las entidades que es una descripcin profunda y Pg. 27 Ciencias de la Computacin
fiable. Al explicar los alcances del sistema, el cliente lo vio de una manera clara y optimista, de acuerdo a sus objetivos trazados antes de iniciar con el proyecto. En el diagrama entidad relacin, el cliente y su grupo de trabajo sostuvo que exactamente como est estipulado en el documento presentado as se trabaja dentro de la empresa Farmacia Lumy SA CV, y con lo cual confirmaron el hecho de que las acciones asignadas se vuelven entidades con asociaciones uno a uno.
2.6 Funciones bsicas y secundarias

Dentro de las funciones bsicas tenemos los siguientes: Control de proveedores Control de personal Control de clientes Control de medicamentos
Las funciones secundarias son: Compras: Bsqueda de medicamento faltante o Consulta de medicamentos ms vendidos o Buscar proveedor o Realizar pedido Ventas: Bsqueda de medicamento o Buscar cliente (si necesita factura) o Introducir datos (del cliente, si es nuevo) o Realizar la venta o Cobrar el importe
2.7Diagrama funcional del sistema

En los diagramas funcionales siguientes, se muestra como fluye la informacin de entrada y salida a travs del sistema SCIF en general; pasando por tres niveles que se descomponen de nivel 0 (diagrama funcional bsico) a nivel dos.
Pg. 28
|2.7.1 Diagrama de flujo de datos en nivel 0
2.7.2 Diagrama de flujo de datos en nivel 1
Pg. 29
Sistema Farmacutico SCIF 2.7.3 Diagrama de flujo de datos en nivel 2
Pg. 30
2.8 Diccionario de datos

Una vez conformados todos los atributos de cada entidad, vamos a examinar hasta donde se puede llegar con la informacin de cada atributo o que informacin debe ser aceptada de una forma lgica y semntica. No podemos caer en errores sencillos, como por ejemplo: edad de una persona 234 aos, o ef34 aos; ya que ambos carecen de sentido ante nuestro mundo real.
1 Entidad medicamentos Nombre Nombre comercial (NomCom) Nombre genrico (NomGen) Tipo medicamento (TipMed) Cdigo de barras (CodBa) Precio de venta (PreVen) Medicamento controlado (ContMed) Descuento (Desc) Existencias (Exist) Precio proveedor (PreProv) Tipo Cadena 50 Cadena 50 Cadena 30 Dgitos 15 Numrico 4 Boleano Numrico 2 Numrico 3 Numrico 4 Descripcin Caracteres Caracteres Caracteres Conjunto de 15 dgitos Entero/Moneda Verdadero/falso Entero porcentaje >0 Entero >0 Entero/Moneda
2. Entidad proveedores Nombre Nombre del proveedor (NomProv) Direccin proveedor (DirProv) Telfono proveedor (TelProv) Persona de contacto (PerCont) Email proveedor (Email) Tipo Cadena 50 Cadena 60 Numrico 15 Cadena 50 Cadena 50 Descripcin Caracteres Caracteres Tira de 15 dgitos Caracteres Caracteres
3. Entidad cliente Nombre RFC cliente (Rfc) Nombre cliente (NomCli) Direccin cliente (DirCli) Telfono cliente (TelCli) Tipo Cadena 30 Cadena 50 Cadena 60 Numrico 15 Descripcin Caracteres arreglados Caracteres Caracteres Tira de 15 dgitos
Pg. 31
Sistema Farmacutico SCIF 4. Entidad empleados Nombre Nombre empleado (NomEmp) Direccin empleado (DirEmp) Telfono empleado (TelEmp) Fecha de ingreso (FecIngre) Clave de acceso (ClaAcce) Puesto (Puest) Tipo Cadena 50 Cadena 60 Numrico 15 Fecha/hora Cadena 10 Cadena 30
Descripcin Caracteres Caracteres Tira de 15 dgitos Fecha mediana Caracteres Caracteres
Pg. 32
DISEO DEL SISTEMA S.C.I.F.
3. DISEO DEL SISTEMA S. C .I .F
3.1 Revisin de requerimientos

Despus de realizar un nuevo anlisis de requerimientos nos dimos cuenta de algunos detalles que deben ser refinados en este momento. Si ms adelante existiera un caso similar nos representara un gasto extra en todo el desarrollo del sistema. Con la aplicacin de los siguientes diseos: conceptual, lgico y fsico podemos asegurar el correcto funcionamiento del sistema SCIF (Sistema para el Control de Inventarios de una Farmacia).
3.2 Modelo relacional Justificacin para SCIF

Su enorme xito en la manipulacin de grandes cantidades de informacin, nos lleva a la conclusin de poder tomarlo como un modelo para la implantacin del sistema SCIF. Este modelo trabaja la informacin a travs de tablas, en este sentido las tablas se pueden distinguir y manipular con una gran facilidad y adems toda la informacin que se procesa. Todo el modelo relacional est sustentado matemticamente por la teora de conjuntos y sus operaciones basadas en el lgebra relacional, proporcionan una gran variedad de operaciones sobre las tablas.
3.3 Diseo lgico

Una vez terminado el modelo conceptual nos vamos a concentrar en la realizacin del diseo lgico, utilizando el Modelo Relacional como base, en donde toda entidad base se convierte en una relacin base, y los vnculos de igual manera se convierten en entidades dbiles.
3.3.1 Convertir esquemas conceptuales locales en esquemas lgicos locales Los modelos conceptuales locales que a continuacin se describen son tomados del modelo conceptual, en donde cada uno de estos modelos juntos forman a todo el sistema completo SCIF; las vistas locales se reducen a las siguientes formas:
Pg. 33
Sistema Farmacutico SCIF a) Vista cliente empleado
Clientes
Ventas
Personal
CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I VENTAS (IdCli IdEmp, FecVenta, Cantidad) Clave primaria
b) Vista Empleado Medicamento Personal Pedidos Medicamento
Proveedores
PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I
PEDIDOS (IdEmpIdProveIdMe, FecPed, NoFact, CantPed, FecCaducidad) Clave primaria El primer paso, consta de lo siguiente: tomar los modelos conceptuales locales y convertirlos de esquemas conceptuales locales a esquemas lgicos locales.
Pg. 34
3.3.1.1 Eliminar asociaciones muchos a muchos N:M Sustituyendo cada una de llas por una nueva entidad intermedia y dos asociaciones de uno a muchos de esta nueva entidad con las entidades originales. La nueva entidad ser dbil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales. 1.- Eliminar las asociaciones N:M, en el sistema SCIF dentro de los incisos a) y b), que tienen asociaciones muchos a muchos, las figuras siguientes son el resultado de la eliminacin de asociaciones muchos a muchos N:M.
a) Ventas
Clientes
Recibe
Ventas
Realiza
Personal
VENTAS (IdCli IdEmp, FecVenta, Cantidad)
b) Pedidos Personal
Hac
Pedidos
Agru
Medicamento
Provee
Proveedores
PEDIDOS (IdEmpIdProveIdMe, FecPed, NoFact, CantPed, FecCaducidad)
Despus de llevar acabo el proceso de eliminacin de asociaciones muchos a muchos N:M, a los esquemas locales refinados, se les llamara como esquemas lgicos locales.
Pg. 35
3.3.2 Derivar un conjunto de relaciones para cada esquema lgico La segunda parte es derivar un conjunto de relaciones para cada esquema lgico local. Aqu mostramos las entidades con sus respectivos atributos con letras maysculas, su clave primaria aparece de forma subrayada en la entidad, tambin se dar el caso de las entidades que tengan claves ajenas que sern resaltadas como negritas.
3.3.2.1 Crear una entidad para cada relacin fuerte 1.- Entidades Fuertes-. Son entidades bsicas del sistema SCIF PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I
3.3.2.2 Crear una entidad para cada relacin dbil 2.- Entidades dbiles.- son aquellas entidades que se obtienen de una relacin de muchos a muchos N:M. VENTAS (IdCli IdEmp, FecVenta, Cantidad) PEDIDOS (IdEmpIdProveIdMe, FecPed, NoFact, CantPed, FecCaducidad)
3.3.2.3 Crear entidades de Jerarquas de generalizacin En las jerarquas, se denomina entidad padre a la entidad genrica y entidades hijo a las sub-entidades. Hay tres opciones distintas para representar las jerarquas. La eleccin de la ms adecuada se har en funcin de su tipo. MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I Pg. 36 Ciencias de la Computacin
Sistema Farmacutico SCIF TIPOMED I TipMed I TipoMed I CONTROLMED I ContMed I ControlMed I
Las relaciones binarias uno a uno, uno a muchos no se consideran ya que en nuestro sistema no contamos con ese tipo de casos que se presentan en el modelo relacional.
3.3.3 Validar cada esquema mediante la normalizacin Como tercera parte se realizar una validacin de cada esquema lgico local mediante la normalizacin, de la cual abarcaremos las tres primeras formas normales. Primera forma normal: cada atributo contiene un nico valor.
1.- Entidades Fuertes PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I TIPOMED I TipMed I TipoMed I CONTOLMED I ContMed I ControlMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I
2.- Entidades dbiles.- son aquellas entidades que se obtuvieron de una asociacin de muchos a muchos N:M. VENTAS (IdCli IdEmp, FecVenta, Cantidad) PEDIDOS (IdEmpIdProveIdMe, FecPed, NoFact, CantPed, FecCaducidad)
Pg. 37
Segunda forma normal: Crear nuevas entidades para mltiple registros, a su vez clave ajena. 1.- Entidades Fuertes PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I TIPOMED I TipMed I TipoMed I CONTOLMED I ContMed I ControlMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I
Tercera forma normal: todos los atributos dependen de la clave primaria. 1.- Entidades Fuertes PERSONAL I IdPer I NomPer I DirPer I ClaAcce I Puest I FechIngre I MEDICAMENTO I IdMed I NomCom I NomGen I CodBa I PreVent I PreProv I Desc I Exist I TipMed I ContMed I TIPOMED I TipMed I TipoMed I CONTOLMED I ContMed I ControlMed I PROVEEDOR I IdProv I NomProv I DirProv I TelProv I PerCont I Email I Pg. 38 Ciencias de la Computacin
Sistema Farmacutico SCIF CLIENTES I IdCli I Rfc I NomCli I DirCli I TelCli I
3.3.4 Validar cada esquema frente a las transacciones del usuario Para el siguiente punto se debe validar cada esquema lgico local frente a las transacciones del usuario que ya se han definido anteriormente. a) Clientes
Recibe
Ventas
Realiza
Personal
En el siguiente esquema lgico los medicamentos deben ser vendidos a travs de una receta si el medicamento es controlado, en caso contrario no importa la receta. Los tipos de medicamentos varan segn el cliente lo pida. Adems las ventas solo son recibidas por un cliente que haya realizado el tramite correspondiente Solo ticket o con factura.
b) Personal
Hac
Pedidos
Agru
Medicamento
Provee
Proveedores
En base a la existencia de los medicamentos, se debe crear un pedido de acuerdo a los faltantes. El pedido debe ser surtido por uno o varios proveedores los cuales ya estn bien definidos. Los medicamentos controlados o no son, ordenados de acuerdo al tipo de medicamento que le corresponde.
Pg. 39
3.3.5 Restricciones de integridad de las Entidades y Referencial Medicamento.- para cada medicamento existe una clave nica y no permite valores nulos, de lo contrario se perder su integridad. Pedido.- en esta entidad se cuenta con su clave nica agrupa las claves IdEmp, IdMed e IdProv y no acepta valores nulos. Proveedor.- se cuenta con clave proveedor nico, no acepta valores nulos; para asegurar que el proveedor existe de verdad y no es un proveedor fantasma. Se liga directamente con la entidad Pedido. Venta.- En la entidad su IdVenta es nico, sin aceptar valores nulos o repetidos, es importante sealar que la clave principal es la unin de IdCli e IdEmp; en caso contrario perderamos el control de las ventas y no tendra caso todo el sistema funcionando sin este argumento importante. Empleado.- Tiene clave nica para cada empleado, de esta forma se puede diferenciar una de otra. No acepta valores nulos o repetidos se conecta con la entidad ventas. Cliente.- Solo es registrado el cliente que desea facturar, su clave es nica y no repetible, con el caso particular de no aceptar valores nulos.
3.3.6 Revisar el esquema lgico local con el usuario En el diagrama de flujo de datos del Captulo dos se muestra como se mueven los datos de un extremo a otro, pues bien, en ese diagrama se modela toda la informacin del sistema SCIF (Sistema para el Control de Inventarios de una Farmacia), que debe corresponder con los sistemas locales para su ptimo rendimiento. Para el control de medicamentos que se muestra en el diagrama de flujo de datos, su principal contacto es el control de ventas, que a su vez el empleado realiza las ventas y como nos damos cuenta corresponde a una de las vistas de los esquemas lgicos locales. El control clientes interacta con el control de ventas, ya que el cliente es quien recibe los o el medicamento que es adquirido en la farmacia. El control proveedores su funcin se realiza de la siguiente manera, surte los pedidos en funcin de los medicamentos que maneja la farmacia y es dado en un reporte a un empleado llamado administrador. El control empleado abarca a empleados comunes y administrador. Los empleados hacen la transaccin de pedidos, adems de la funcin principal de la farmacia, realizar la transaccin de ventas, la salida de los medicamentos. Aqu es Pg. 40 Ciencias de la Computacin
donde se pone un nfasis especial ya que se tienen que controlar las fugas que existen fsicamente en la actualidad dentro de la farmacia LUMY.
3.3.7 Mezclar los esquemas lgicos locales en un esquema lgico global Al unir los esquemas lgicos locales en un esquema final, vemos como resultado un esquema ms cercado del final, para esto se deben hacer algunas pruebas de comportamiento y funcionalidad. Vamos a realizar un anlisis del diagrama que se presenta: Los nombres de las entidades y claves primarias si corresponden a los esquemas locales.
Las relaciones entre las entidades, estn de acuerdo a la funcionalidad. Todas las entidades y relaciones estn contenidas. Se mezclaron todas las entidades y relaciones que pertenecen a vistas de usuario. Las claves ajenas de ventas y pedidos estn correctas. Las reglas de integridad antes mencionadas estn fundamentadas para el diagrama.
3.3.8 Validar el esquema lgico global Las relaciones que han cambiado, son: venta, pedido, tipo medicamento, control de medicamentos. Las dos ltimas no tiene que ser ms normalizadas porque solo cuentan con dos atributos de cada una de las relaciones, sus funciones estn definidas claramente. Las otras dos entidades que sufrieron algn cambio al aplicarles las tres primeras formas normales, lo cual implica que no necesitan algn otro proceso. Las transacciones de acceso a pedido dependen de la cantidad de medicamentos que se transfieran por cada venta y a su ves esa cantidad de medicamentos es vista como una venta en general, la cual contiene dos claves: clave de venta y clave de medicamento. La entidad pedido, est relacionada con los medicamentos. Un pedido puede abarcar uno o muchos medicamentos, de los cuales se conoce su cantidad, su fecha de caducidad y su costo unitario. Tambin est relacionada con pedidos, para un pedido es necesario de uno o muchos pedidos.
Pg. 41
Sistema Farmacutico SCIF 3.3.9 Crecimiento a futuro
El presente diseo se puede ampliar para cliente servidor. De la siguiente manera, Se toma una gran parte del diagrama menos las relaciones venta y detalle venta. De todas las que se hayan tomado se irn al servidor como tablas principales y el resto de las entidades, como son; ventas, clientes y empleados actuaran como tablas locales. Este esquema facilitar la traduccin de un crecimiento notable en el diseo propuesto.
3.3.10 Dibujar el diagrama entidad-relacin final
El diagrama siguiente es la representacin final del funcionamiento del sistema, al realizar cada uno de los pasos que condujeron hasta el final, nos damos cuenta de que tan rpido y fcil es crear un diagrama que nos represente a nuestro sistema, sin el temor de que este incorrecto o su funcionamiento sea inadecuado. Cuando se inicio el diseo lgico partimos de un modelo entidad relacin del diseo conceptual, a partir de ah se descompuso el esquema en varias vistas locales. Despus cada uno de los esquemas, se tomaron para analizarlos uno a uno; se eliminaron las posibles relaciones que causaran conflictos, se crearon nuevas relaciones dbiles a partir de las fuertes, y se utilizo la normalizacin para cada esquema local, de igual manera se plantearon las reglas de integridad en todas las entidades que actan en el diseo. Una vez terminado los pasos de cada esquema se unieron los esquemas locales para formar el diseo que se muestra a continuacin.
Pg. 42
Diagrama entidad relacin
Pg. 43
Sistema Farmacutico SCIF 3.3.11 Revisar el esquema lgico global
Solo nos queda revisar el diseo lgico final y aprobarlo, con respecto a las necesidades que fueran planteadas en un inicio. Las preguntas que fueron planteadas son las siguientes, adems se debe comprobar si tales preguntas pueden responderse siguiendo el diagrama. Empleado hace pedidos. Claro en el diagrama muestra como varios empleados pueden hacer un pedido. Cliente recibe ventas.- Con esto probamos que solo el cliente pueden recibir muchas ventas, dependiendo de la frecuencia para concretar una venta. El proveedor surte los medicamentos. Los proveedores, nos indica el diagrama que son los encargados de surtir los medicamentos, a base de un pedido, que el mismo empleado o empleados deben realizar. Los medicamentos son buscados. Implcitamente ya est establecido que a cada una de las entidades se les debe hacer una consulta, por lo tanto no nos preocupemos si no vemos la relacin muy clara entre buscar medicamentos y empleados. En un principio se consider pero al analizar bien se comprob que no tenia caso presentarla ya que solo complicaba ms el diseo y en consecuencia el sistema.
Por ultimo mostramos las tablas, con todas sus relaciones y entidades que se obtuvieron despus de pasar por todo el diseo lgico.
Pg. 44
3.4 Ambientacin del sistema (Interfaz)

3.4.1Inicio del sistema
3.4.2 Buscar precios de medicamentos
Pg. 45
3.4.3 Reporte de ganancias
Pg. 46
IMPLANTACIN Y PRUEBAS
4. IMPLANTACIN Y PRUEBAS
4.1 Anlisis de la herramienta FoxPro
4.1.1 Nivel externo vistas Si deseamos obtener un conjunto de datos personalizado, se deben realizar cambios en los datos y enviar estas actualizaciones a tablas, para ello, podemos utilizar vistas. Las vistas cambian las cualidades de las consultas y las tablas. Las vistas se pueden crear a partir de tablas locales, de otras vistas, de tablas almacenadas en un servidor o de orgenes de datos remotos. Utilizamos vistas cuando deseamos extraer un conjunto actualizable de datos de tablas locales o remotas. Vista
Tabla Vista
Vista remota
Servidor Tabla Vista
Las vistas son una caracterstica de las bases de datos de visual FoxPro, solamente las podemos utilizar cuando la base de datos est abierta. 4.1.2 Nivel Conceptual La capa de reglas de negocio incluye procesos como el clculo de IVA, la validacin de la informacin de clientes y la automatizacin de procesos de negocios. Esta capa es una capa no visual y se actualiza cada vez que cambia una regla del negocio. 4.1.3 Nivel interno paginacin La capa de servicios de datos es la responsable de localizar los datos de la manera ms rpida posible y de asegurar su correcta grabacin. Capacidades de archivos
Nmero mximo de registros por archivo de tabla Tamao mximo de un archivo de tabla Nmero mximo de caracteres por registro Nmero mximo de campos por registro Nmero mximo de tablas abiertas a la vez Caracteres por campo de tabla 1000 millones 2 Gigabytes 65.500 255 255 254
Pg. 47
4.1.4 Que lenguaje est incluido en la herramienta Visual FoxPro admite comandos del Lenguaje Estructurado de Consultas SQL. Los comandos SQL de Visual FoxPro utilizan la tecnologa Rushmore para optimizar el rendimiento y puede utilizarse un slo comando SQL para sustituir a varios comandos Visual FoxPro. SQL (Structured Query Languaje) es un lenguaje universal que permite consultar y actualizar cualquier tipo de bases de datos relacinales. Con visual FoxPro, podemos construir consultas a travs de interfaces grficas que permiten armar la instruccin SQL de manera muy amigable. Estas interfaces pueden ser el diseador de consultas, una vista definida en el diseador de vistas o directamente de cdigo. 4.1.5 Organizacin de archivos Especifica el tamao de los bloques en que se solicita espacio en disco para los campos memo. El valor que escriba especifica el mnimo espacio en disco requerido para un campo memo y el tamao en el cual se incrementan los campos memos a medida que se les agregan datos. Si especifica un valor entre 1 y 32, Visual FoxPro multiplica su valor por 512 y, a continuacin, asigna espacio en disco en un bloque de ese tamao. Si especifica un valor mayor que 32, Visual FoxPro asigna bloques de slo ese tamao; especificar un nmero mayor que 32 puede por lo tanto ahorrar espacio en disco. Esta opcin corresponde al comando SET BLOCKSIZE. Variables de memoria y matrices:
Nmero predefinido de variables de memoria Nmero mximo de variables de memoria Nmero mximo de matrices Nmero mximo de elementos por matriz 1024 65000 65000 65000
Formacin de archivos:
Tamao mximo de campos de caracteres Tamao mximo de campos numricos (y flotantes) Nm. mx. de caracteres en nombres de campos de una tabla libre Contenida en una base de datos Valor mnimo de un entero Valor mximo de un entero Dgitos de precisin en clculos numricos 254 20 10 128 -2.147.483.647 2.147.483.647 16
Pg. 48
Sistema Farmacutico SCIF Archivos de programas y procedimientos:

Nmero mximo de lneas en archivos de programo fuente Tamao mximo de mdulos de programa compilados Nmero mximo de procedimientos por archivo
sin lmite. 64K sin limite 384 27 5
Nmero mximo de comandos de programacin estructurada anidado Nmero mximo de parmetros transferidos Nmero mximo de transacciones
4.1.6 Tipos de ndice Los ndices son la mejor forma para proporcionar diferentes ordenaciones de los datos, puede crear, usar y mantener tres tipos de ndices: ndices independientes (.IDX) ndices estructurales compuestos (.CDX) ndices no estructurales compuestos (.CDX) Los cuales su forma de manejo es dinmico. Los ndices independientes: para cada expresin de ndice se crea un archivo de ndice separado con su propio nombre, los nombres raz de la tabla (.DBF) e ndice (.IDX) no tienen que ser el mismo. ndices compuestos: permiten una cantidad ilimitada de expresiones de ndices separadas en un solo archivo. No se pueden perder los archivos u olvidar los nombres de todos los archivos de ndices que pertenecen a una tabla. Estos ndices compuestos se les conocen como ndices estructurales. Podemos traer ndices locales en una vista igual que en una tabla, mediante el comando INDEX ON. A diferencia de los ndices generados para una tabla, los ndices locales que creemos en una vista no se almacenaran permanentemente, sino que desaparecern cuando cerramos la vista. Como se conforman los ndices
Nmero mximo de bytes por clave de ndice en un ndice no compacto 100 Nmero mximo de bytes por clave de ndice en un ndice compacto 240 sin lmite sin limite Nmero mximo
Nmero mximo de archivos de ndice abiertos por tabla Nmero mximo de ndices abiertos en todas las reas de trabajo de relaciones Longitud mxima de expresiones relacinales sin limite
sin lmite
Pg. 49
Sistema Farmacutico SCIF 4.1.7 Integridad de los datos
Las reglas que rigen la coherencia de datos, especficamente las relaciones entre las claves principal y externa de tablas distintas. Visual FoxPro resuelve la integridad referencial mediante reglas a nivel de campo y a nivel de registro definidas por el usuario. El Generador de integridad referencial le ayuda a definir reglas para controlar cmo ser insertan, actualizan o eliminan registros de tablas relacionadas. En general, la integridad referencial define que operaciones son permisibles entre tablas que estn conectadas con relaciones. La premisa bsica es que un valor de clave primaria en la tabla primaria debe tener una clave de bsqueda o externa correspondiente en otra tabla La IR trata como invlidos a los registros que no cumplen este criterio.
4.2 Implantacin del sistema

En esta seccin consideramos los aspectos ms importantes a tratar dentro de la implantacin del sistema, as tambin de una descripcin de los elementos ms utilizados dentro del mismo entorno. 4.2.1 Inicio del sistema Para iniciar con el sistema SCIF (Sistema para el Control de Inventarios de una Farmacia), se debe localizar el icono con el nombre de control de farmacia (acceso directo), su ubicacin radica en el escritorio de Windows como lo muestra la figura 4.1. Despus de ubicarlo dar doble clic sobre el icono antes mencionado e inmediatamente dars inicio al sistema SCIF. .
Fig. 4.1 Iniciar la aplicacin
Una vez abierto el sistema SCIF, la primera ventana que muestra es inicio del sistema, figura 4.2, en donde se pide una clave de acceso. La clave se escribe en el cuadro correspondiente y se prosigue con clic en el botn aceptar; para ello existen dos casos a considerar. Caso uno, si la clave otorgada es correcta, entones pasamos a la siguiente figura. Caso dos clave incorrecta, el sistema le informa con un cuadro de dialogo en donde su clave no corresponde, por lo tanto debe introducir otra clave que coincida con la verdadera clave. Pg. 50 Ciencias de la Computacin
Fig. 4.2 Ingresar con clave
Una vez pasado por la clave de entrada, ahora se encuentra en el men principal del sistema figura 4.3. A partir de aqu se puede administrar toda la base de datos con altas, bajas, consultas, ventas y pedidos de todo lo que engloba la farmacia LUMY. En el men principal nos presenta los siguientes mens y sub mens. 1. Administrador Clientes Medicamentos Personal Proveedores 2. Ventas Buscar cliente Historial Nueva Venta 3. Bsqueda Medicamentos Nombre Comercial Nombre Genrico Med Controlados 4. Facturacin No de Venta RFC 5. Pedidos Faltantes Historial Proveedor Nuevo Pedido 6. Reportes Medicamentos Clientes Personal Proveedores 7. Salida del sistema
Figura 4.3 Men principal
Pg. 51
Ahora se describen algunas de las opciones (ventanas) de la barra de men, como son pedidos, ventas, consultas, reportes, operaciones y salida del sistema SCIF. 4.2.2 Entrada y salida de mercanca 1. Pedidos: Clic en la opcin pedidos y nuevo pedido, se abre la ventana de pedidos figura 4.4 se divide en dos partes encabezado y detalle de pedido en donde se debe ingresar todos los pedidos, los cuales se reciben de los proveedores. Iniciamos dando clic en el botn agregar se genera el nuevo pedido e ingresamos los datos correspondientes en el encabezado como son: Nmero de factura, nombre del personal que hace el pedido, fecha del pedido, nombre del proveedor, el nmero de pedido el sistema lo asigna automticamente y para el detalle pedido son nombre del medicamento, cantidad y fecha de caducidad, esto es para cada uno de los medicamentos dicho de otra manera ingresamos un medicamento y para el siguiente solo se debe dar clic en el botn New medicamento; as sucesivamente hasta terminar con toda la factura. Una vez terminado para confirmar y guardar los cambios de la factura se procede a lo siguiente clic en el botn aceptar.
Fig. 4.4 Pedidos Un reporte de los pedidos realizados hasta el momento se muestra en la figura 4.5, el cual se obtiene al ir en la barra de men seleccionando la opcin pedidos y despus historial. Aqu mostramos los detalles de los pedidos
Pg. 52
organizado de la forma descendente, es decir de la ms reciente factura hasta la ltima en orden de fecha de pedidos.
Fig. 4.5 Reporte pedidos
El punto de venta que mostramos va a ser la ventana mas utilizada; por que desde aqu se podrn realizar todas las ventas reales figura 4.6. Su funcin se basa en lo siguiente clic en el botn agregar se incrementa el nmero de venta automticamente, el nombre del cliente si requiere factura de lo contrario se asigna como general, la fecha la toma del sistema fecha actual, nombre del personal que lo atiende, nombre del medicamento y la cantidad. La parte inferior del formulario muestra los siguientes campos, descuento del medicamento, precio de venta unitario, subtotal de precio con descuento por la cantidad requerida y por ltimo el monto total a pagar. El botn New medicamento sirve para ingresar ms medicamentos y solo tenemos que proporcionar el nombre del medicamento y la cantidad y as hasta completar lo que requiere el cliente para concretar la transaccin damos clic en el botn aceptar para confirmar la venta y nos muestra el monto total a pagar. Con el botn eliminar se cancelan los medicamentos y el botn cancelar no actualiza la venta actual. Por ltimo si la venta se hace efectiva solo basta imprimir su ticket figura 4.8 o factura correspondiente dando clic en el botn imprimir. Pg. 53 Ciencias de la Computacin
Fig. 4.6 Punto de venta
La figura 4.7 nos presenta el historial de ventas y se obtiene al ir a la barra de men clic en opcin ventas y despus historial. Se genera la siguiente vista con las caractersticas de nombre de medicamento, cantidad, precio de venta, descuento y subtotal.
Pg. 54
Sistema Farmacutico SCIF Fig. 4.7 historial de ventas
4.8 Ticket de venta
4.2.3 Interaccin externa Damos de alta a nuestros proveedores, para agregar un nuevo proveedor se siguen los pasos. Clic en botn agregar la clave se incrementa automticamente, ingresamos el nombre del proveedor, su direccin, telfono, la persona de contacto del cual se est en constante comunicacin y por ltimo el correo electrnico del proveedor. Una vez ingresado todos los datos solo basta dar click en el botn aceptar. El botn eliminar como su nombre lo indica suprime el proveedor al cual se est haciendo referencia, en la figura 4.8 notamos que el proveedor es el de clave 1 Medicamentos OCMA, es decir si en este momento damos clic al botn eliminar automticamente se da de baja el proveedor. El botn cancelar actualiza los datos y los guarda. Los botones de navegacin nos permiten desplazarnos por todos los proveedores. Adems nos permite buscar a los proveedores por clave o por nombre del proveedor.
Pg. 55
Fig. 4.9 Proveedores
Se agregan y modifican todos los medicamentos existentes en la base de datos; por ejemplo si deseamos eliminar un registro o medicamento tenemos que desplazarnos al registro deseado con los botones de desplazamiento Inicio, Anterior, Siguiente, ltimo o hacer una bsqueda a travs de clave de medicamento, nombre comercial o nombre genrico de los medicamentos. Una vez localizado el registro damos click en el botn eliminar en ese momento se da de baja el medicamento. Por otra parte de la misma manera como se agregaron los proveedores se dan de alta los medicamentos haciendo nfasis que los datos que nos piden deben corresponder los cuales son: clave que se incrementa automticamente, nombre del medicamento, nombre genrico del medicamento, precio de venta, precio proveedor, descuento, existencias se actualiza solo con los pedidos, tipo de medicamento y si es controlado o no el medicamento.
Pg. 56
Fig. 4.10 Medicamentos Para dar de alta a los clientes se procede con los siguientes pasos, clic en el botn agregar la clave del cliente se incrementa en uno con respecto al ltimo cliente dado de alta, los datos a introducir son: RCF, nombre, direccin y telfono una vez terminado con los datos proseguimos con clic en el botn aceptar, de esta manera se guardan los cambios ya ingresados del cliente. Con los botones de navegacin inicio, ltimo, anterior y siguiente podemos buscar clientes de igual manera por clave o RFC. El botn eliminar suprime el cliente actual, haciendo nfasis con una pregunta si la operacin debe continuar y el botn cancelar elimina los cambios realizados hasta la ltima actualizacin.
Fig. 4.11 Clientes Pg. 57 Ciencias de la Computacin
Por ltimo para salir del sistema en la barra de men seleccionamos la opcin salir damos clic e inmediatamente nos aparece un mensaje con la leyenda Saliendo del sistema SCIF, en ese instante se cierra toda la aplicacin.
Fig. 4.12 Medicamentos
4.3 Estado del arte de las bases de datos
4.3.1 Nuevos problemas de representacin de la informacin. Uno de los problemas est relacionado con la representacin de la informacin a travs de estructuras de datos ms complejas que permitan consultar a la informacin ms all de las consultas tpicas tradicionales, y sea posible especificar relaciones de tipo recursivo y en donde adems se incluyan elementos activos que provengan de los lenguajes de programacin. El otro tipo de problemas asociados a la utilizacin de Bases de Datos clsicas aparece cuando parte de la informacin que se posee no se ajusta a los modelos registro, campo, valor, sino que se da mediante "reglas lgicas" que recogen el "conocimiento" de un experto.
Pg. 58
Sistema Farmacutico SCIF 4.3.2 Alternativas al modelo relacional.
Una de las primeras alternativas presentadas fue el Modelo de Datos Semntico. Los primeros modelos surgen a mitad de los 70, siendo el ms popular de todos ellos el Modelo Entidad/Relacion (modelo E/R) introducido por Chen en 1976. A principio de los 80 aparecen nuevos modelos semnticos de los cuales el ms famoso es TAXIS (Wong, Mylopoulos y Bersntein 1983) donde se integran elementos de Bases de Datos, lenguajes de programacin e Inteligencia Artificial (IA). En Ciencias de la Computacin muchos investigadores se preguntaban sobre cmo representar y manipular informacin con un objetivo distinto: se trataba de desarrollar programas que permitiesen al ordenador realizar tareas reconocidas como "inteligentes". Uno de los problemas ms importantes en dicho campo fue la "Representacin del Conocimiento". Si tomamos como definicin de tal cuestin la de Barr y Davidson. Podemos afirmar que la Representacin del Conocimiento es: La combinacin de estructuras de datos y procedimientos interpretativos que utilizados de forma correcta en un programa conducen a una conducta "inteligente". La principal ventaja de la Lgica como sistema de representacin es que incluye de forma natural sus propios mecanismos de manipulacin Desde 1977 a 1985 se pueden encontrar: Tres reuniones de trabajo organizadas por H.Gallaire, mayor de J.M. Nicolas y J. Minker. El tema fundamental, en ellas era "Lgica y Bases de Datos. Una reunin en 1980, otra en 1983 y otra en 1985 promovidas por J, Brodie junto con otros colaboradores donde se trat inicialmente la relacin entre Inteligencia Artificial, Bases de Datos y Lenguajes de Programacin a travs de la Modelizacin Conceptual, y posteriormente, la integracin entre las dos primeras reas utilizando como nexo de unin el concepto de Sistema Base de Conocimiento. Tambin en 1985 se celebra otra reunin en Grecia donde se ponen de manifiesto las ideas de los investigadores europeos acerca del tema y en muchos aspectos puede considerarse la equivalente a la celebrada en USA por esta misma fecha.
En los ltimos tiempos la tendencia es la de construir sistemas que incluyan sus propios mecanismos deductivos un ejemplo de esta idea es el NAIL! construido en Stanford y basado en el modelo Datalog.
Pg. 59
4.3.3 Desafos actuales de las Bases de Datos. 4.3.3.1 La situacin a principios de los 90. En este momento todo lo concerniente a la representacin y tratamiento de la informacin se ha consolidado como disciplina dentro de las Ciencias de la Computacin. Un conjunto de Nuevas Aplicaciones que estaban empezando a plantearse y del tratamiento de Bases de Datos Distribuidas con Informacin Heterognea:
1. Nuevas aplicaciones: (a) El tratamiento de las grandes masas de datos de imgenes va satlite que genera un organismo como la NASA. (b) Bases de Datos que sirven de soporte para sistemas de ayuda al diseo de grandes proyectos de Ingeniera. (c) La Base de Datos que ha de recoger los resultados correspondientes al proyecto GENOMA, donde cada gen es una secuencia de millones de elementos e incluye subcadenas que definen objetos complejos y variables. (d) El manejo de grandes Bases de Datos histricas que recojan transacciones tales como las que generan en un cajero de un supermercado (e) Bases de Datos que soporten informacin organizada de forma distinta a la clsica de registro/atributo, en las que se pueda almacenar tanta informacin tipo registro, como textual, como grfica o cualquier otro tipo de informacin analgica, voz, video etc... 2. El tratamiento de Bases de Datos Distribuidas con informacin heterognea: En este momento el desarrollo de Internet no haca prever la envergadura del problema del acceso a informacin referente a un mismo tema, almacenada de forma diferente en distintos sitios y que un usuario desea ver de forma unificada y (probablemente) resumida. Un ejemplo tpico de esto es el caso del proyecto GENOMA donde distintos equipos cientficos generan datos referentes al proyecto que almacenan en Bases de Datos no homogneas y que deben ser consultadas conjuntamente. La necesidad de investigar sobre los nuevos modelos de datos y nuevos algoritmos de acceso asociados a los mismos de manera que dichos modelos se puedan implantar eficientemente. Insiste en que slo estos nuevos modelos podrn resolver los problemas de representacin e integracin planteados.
Pg. 60
Sistema Farmacutico SCIF 4.3.3.2 La situacin sobre 1995-1996.
La investigacin en Bases de Datos debe seguir jugando un papel crucial en el desarrollo de tecnologa para el acceso a la informacin. La nueva generacin de aplicaciones de Bases de Datos generada por la explosin de almacenamiento de informacin de los ltimos cinco aos requiere solucin para los siguiente problemas de investigacin: 1. 2. 3. 4. 5. Soporte para objetos multimedia. Distribucin de la informacin y acceso a informacin heterognea. Nuevos usos de las Bases de Datos. "Secuenciacin" y gestin de transacciones. Facilidad para la gestin y el uso de Bases de Datos.
Los nuevos desafos de investigacin, asociados a las Bases de Datos, se derivan directamente de los avances de la tecnologa y estos son fundamentalmente: El crecimiento de la capacidad y de la potencia del hardware y El desarrollo de las comunicaciones, especialmente de Internet. Se recomienda potenciar la investigacin bsica con el objetivo de responder a estas nuevas cuestiones.
4.3.3.3 Las ltimas consideraciones, 1998. 1. El Web e Internet Considera que aunque la Web, considerado en global, no es ms que una gran Base de Datos. La Web y el acceso de millones de personas al mismo no han hecho ms que endurecer el problema de acceder a informacin heterognea con consultas no precisas. Existen realmente en este punto dos problemas mezclados, el primero es de desempeo ya que la gestin de informacin distribuida a este nivel. El segundo es un problema ms profundo y est ligado a la representacin de informacin no clara tanto a nivel de consulta como de almacenamiento. 2. La aparicin de aplicaciones cada vez ms complejas que necesitan una mayor integracin de programas y datos 3. Los avances del hardware: servidores cada vez ms grandes, dispositivos cada vez ms pequeos y variados Los grandes avances del hardware en esta poca platean dos cuestiones interesantes: El tamao de la memoria va invalidar muchos de los algoritmos de acceso, paginacin etc... dado que es muy probable que todas las tablas de una Base de Datos puedan estar residentes en memoria. Pg. 61 Ciencias de la Computacin
La relacin entre el costo de los ordenadores y la atencin humana ha cambiado sustancialmente.
Particular importancia tiene el problema del tratamiento de informacin imperfecta en Bases de Datos. Desde el principio de la dcada e incluso mucho antes aparecen aplicaciones donde por distintas razones la calidad de la informacin a tratar no se ajusta a las premisas formales de los modelos de datos establecidos. Tambin en este caso las soluciones a este problema no han venido de la comunidad de Bases de Datos; no obstante ha recibido una considerable atencin por parte de otros grupos, siendo las propuestas que ms xito han alcanzado aquellas que estn basadas en la lgica y tecnologa "fuzzy" (difusa).
4.4 Conclusiones 4.4.1 Objetivo general Objetivo general.-Anlisis, diseo e implantacin de un Sistema para el Control de Inventarios de una Farmacia (SCIF), fue llevado paso a paso cubriendo cada uno de los objetivos particulares en su totalidad de acuerdo al orden estipulado y manejado por parte de la metodologa empleada modelo de cascada y por ltimo generando la aplicacin con la ayuda de la herramienta visual FoxPro. 4.4.2 Objetivos particulares
Recopilacin de los requisitos. La recopilacin de la informacin fue a base de plticas, entrevistas, cuestionarios con los ejecutivos de venta y gerente general; acerca de cules eran sus expectativas y necesidades para automatizar la empresa LUMY. Ya que ambos son los involucrados directamente con el entorno del nuevo sistema (Ver Introduccin Genera)l Recopilacin, anlisis y clasificacin de informacin relacionada con Ingeniera de Software y con la teora de Bases de Datos. La bsqueda de la teora de bases de datos e ingeniara de software est soportada e investigada en libros, direcciones de Internet y los dos cursos impartidos en la Facultad de Ciencias de la Computacin (BUAP) relacionados a la Ingeniera de software y bases de datos (Ver Captulo 1) Hacer un anlisis profundo de los requisitos para realizar la especificacin de los requerimientos del Sistema SCIF. Despus de obtener la recopilacin de los requisitos y toda la teora que conllevan las bases de datos realizamos un anlisis detallado de hasta donde se delimita el sistema y cuales eran otras necesidades. Se propuso un esbozo general de que Pg. 62 Ciencias de la Computacin
es lo que abarca el sistema y que no. Dicha propuesta fue presentada y expuesta ante el personal involucrado, dando como resultado algunos nuevos detalles que se tienen que contemplar y otros omitir, por ltimo la propuesta fue aprobada. (Ver Captulo 2) Realizar el Diseo del Sistema y de la Base de datos involucrada. El diseo fue la parte ms importante en el desarrollo del sistema, por que se contempla el funcionamiento correcto o incorrecto del sistema. Los aspectos ms importantes son diseo conceptual (Obtener las entidades y las relaciones entre llas), lgico (A partir del conceptual llegamos a la tablas del sistema perfectamente relacionadas) y fsico (Como almacena la informacin la herramienta visual FoxPro). (Ver Captulo 3) Realizar la Implantacin del Sistema y de la Base de Datos, y dar a conocer los resultados obtenidos en las pruebas realizadas al Sistema. A travs de visual FoxPro se tomaron las tablas del diseo fsico y se implantaron, se generaron la interfaces necesarias y las consultas de las cuales el cliente requiere un rendimiento ptimo dentro de la empresa LUMY. Las pruebas se realizaron desde el inicio de la implantacin con algunas sugerencias y al final con varios ejemplos claros y concisos de cmo se maneja la informacin dentro del sistema (Ver Captulo 4) Generar un documento que avale el desarrollo de este Proyecto de tesis. El documento se escribi paralelamente con al avance de los objetivos particulares, de esta manera se tiene una mejor perspectiva de cual informacin debe ser asentada en el documento. Se contemplaron cada uno de puntos presentados inicialmente (Ver todo el documento) 4.4.3 Requisitos del sistema P: Cul es su labor dentro de la empresa? R: Como administrador tendr todo el control y acceso del sistema (Altas, bajas, correcciones de venta y pedidos) para su mejor explotacin. (Ver Captulo 4) P: Qu preparacin necesita una persona para atender la farmacia? R: A parte de sus estudios bsicos el sistema le ayuda a la bsqueda de informacin de medicamentos ms rpida, eficaz y concisa, de la misma manera con la consulta de precios en los medicamentos. (Ver Captulo 4) P: Cuntas personas laboran en la farmacia? R: Como habamos mencionado el administrador tiene el control general. Pero el contador tiene acceso a todas las facturas tanto de compras como de ventas. Y los ejecutivos de venta solo se avocaran a la atencin del cliente. (Ver Captulo 2) P: Cuales son los requisitos para vender los medicamentos? Pg. 63 Ciencias de la Computacin
R: El sistema mostrar un mensaje de alerta cuando el medicamento sea controlado, en caso contrario la venta se har efectiva. (Ver Captulo 2) P: Existe un nmero clave para cada medicamento? R: La clave ser asignada a cada medicamento cuando ste sea dado de alta por parte del administrador, dicha clave solo la maneja el sistema para sus operaciones y no la manejar ninguna persona en especial. (Ver Captulo 2) P: Cada qu tiempo se realiza un inventario? R: Semanalmente se genera un reporte de los medicamentos de compra y venta, adems de cada mes y ao se hace un balance para corroborar toda la mercanca. (Ver Captulo 4) P: Cuando una persona solicita un medicamento, cmo comprueba si es controlado o no? R: Por el mensaje de alertas que mandara el sistemas. (Ver Captulo 4)
4.5 Perspectivas 4.5.1 Necesidades del cliente Parte fundamental del sistema es el manejo del inventario farmacutico de una manera local, pero con el avance del tiempo y el pronto crecimiento considerable de la empresa, se prevn y consideran los siguientes aspectos: Apertura de nuevas sucursales Se considera abrir nuevas sucursales en diferentes zonas rurales no cerca de la casa matriz LUMY, con el fin de abarcar ms el territorio hasta considerar un corporativo muy fuerte. Contratacin de nuevos empleados Los empleados saldrn de la sucursal matriz para integrarse como coordinadores de sucursales. Dichos empleados tendrn la capacidad de poder manipular a los nuevos empleados y lo ms importante capacitarlos en su nuevo puesto. Control de inventarios ms sofisticado La mercanca medicamentos se tiene una forma diferente de organizar, ya que en este caso vamos a tratar de repartir los medicamentos de acuerdo a los parmetros consultados y anlisis estadstico que mejor nos convengan, como cliente y empresa. Consulta de medicamentos en lnea La mercanca podr ser consultada desde cualquier sucursal X a otra sucursal Y, el propsito de esta manipulacin est sustentado por el traslado o movimiento rpido de mercanca y no agotar su caducidad. Ya que por esto se pueden considerar muchas perdidas de medicamentos. Pg. 64 Ciencias de la Computacin
Actualizacin de precios Los precios se deben de actualizar desde cualquier sucursal, es decir; si el administrador se encuentra en una de llas, desde ah con su clave de sper usuario lo debe poder hacer. 4.5.2 Implantacin en red El sistema SCIF (Control de Inventarios de una Farmacia), en un futuro prximo se planea el crecimiento de toda la empresa. Un punto importante a considerar es la de integrarse a la red de redes Internet; por tal motivo el sistema SCIF tiene como propsito ampliar su cobertura local. La integracin a Internet del sistema SCIF, con el proyecto de ejecutarlo en un plazo muy cercano, va a considerar los siguientes pasos: Obtener un servidor para nuestras necesidades Crear una base de datos Cliente/Servidor Diseo de una base de datos Implantacin de la misma Dar consultas va Web o Consulta de precios o Consulta de existencias o Consulta de descuentos o Consulta de medicamentos controlados La arquitectura cliente-servidor a utilizar es: Proceso distribuido
Base de datos
Servidor
Procesos
Procesos
Cliente
Presentacin
Pg. 65
4.5.3 Diseo conceptual Orientado a Objetos En la actualidad las bases de datos relacionales se estn quedando atrs y la mira est puesta ya en las bases de datos orientadas a los objetos. Se plantea el siguiente diseo conceptual orientado a objetos con el fin de mejorar el funcionamiento y rendimiento del sistema. Para esto es importante considerar el esquema de la figura 4.1 como un punto de partida hacia la conversin del sistema SCIF (Sistema para el Control de Inventarios de una Farmacia), basado en el modelo relacional, al modelo relacional extendido, dicho de otra manera modelo orientado a objetos
Fig. 4.6 Diseo conceptual de una OORDB

Inventario Existencias Existencia (Producto) Salida venta Entrada compra Prdida Medicamentos Nombre Propiedades Inicializar Borrar Cliente Nombre Direccin Telfono
Tipo
Controlados Control Med
Pedido
Producto Presentacin Cantidad Proveedor Cancelar Inicializar Reporte
Presentacin Frmula Proveedores
Compras Inventario Programa de Compra Anlisis de Compra Nuevo pedido
Pg. 66
BIBLIOGRAFA
[ 1 ] Edward Yourdon, Anlisis Estructurado Moderno. Ed. Prentice Hall, 1993. [ 2 ] C.J. Date, Introduccin a los Sistemas de Bases de Datos, Ed Prentice Hall, 2000. [ 3 ] James Martin; Organizacin de las Bases de Datos; 1ra edicin; Ed. Prentice Hall. [ 4 ] Mario Gerardo Piattini Velthuis; Fundamentos y Modelos de las Bases de Datos: segunda edicin, Ed. Alfaomega. [ 5 ] Roger S. Pressman: Ingeniera del Software; Quinta Edicin. Editorial McGraw Hill. [ 6 ] Bazian Menachem; Visual FoxPro; Sexta Edicin; editorial Mc-Graw Hill. [ 7 ] Jorge Jimnez; Ingeniara de Software; Diplomado de bases de datos; FCC; BUAP 2003. [ 8 ] Marco Antonio Soriano; Introduccin al desarrollo de aplicaciones de bases de datos; Diplomado de bases de datos; FCC; BUAP 2002. [ 9 ] Josefa Somodevilla; Aplicaciones Cliente-Servidor; Diplomado de bases de datos; FCC; BUAP 2003. [ 10 ] Marco Antonio Soriano; Nuevas tendencias de bases de datos; Diplomado de bases de datos; FCC; BUAP 2004.
Pg. 67

TES674

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TES674

Enviado por

Direitos autorais:

Formatos disponíveis

Benemrita Universidad Autnoma de Puebla

Facultad de Ciencias de la Computacin

Sistema para el Control de Inventarios de una Farmacia

Tesis profesional que presenta: Javier Conde Iztetzi

Que para obtener el ttulo de

Lic. en Ciencias de la Computacin

Asesor: Lic: Marco Antonio Soriano Ulloa

Puebla, Pue. 2004

Sistema Farmacutico SCIF

Especficamente el control de inventarios en la Farmacia se realiza en base a los siguientes pasos:

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Para mi persona: Me permite aplicar los conocimientos recibidos en los

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

2. Anlisis del Sistema S. C. I. F.

Sistema Farmacutico SCIF

2.7.3 Diagrama de flujo de datos en nivel 2... 30 2.8 Diccionario de datos.. 31

3. Diseo del Sistema S. C. I. F.

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

El ciclo de vida clsico segn Roger S. Pressman.

Sistema Farmacutico SCIF 1.1.4.1 Planificacin del Sistema

Sistema Farmacutico SCIF

1.2 Teora de Bases de Datos

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF 1.2.3 Modelos de Datos

Sistema Farmacutico SCIF 1.2.4 Modelo Relacional

Sistema Farmacutico SCIF

Entidad o Relacin Tupla Cardinalidad Atributo Grado Dominio

Figura 1.2 Algunas equivalencias en el modelo relacional

ClaveEmpleado 1000 1001

Nombre Juan Ral Luis Erika

ApePat Flores Montes Barbosa Avendao

ApeMat Cortes Prez Hernndez Almazn

Figura 1.3 Modelo de una tabla

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF 1.2.5 lgebra relacional

Sistema Farmacutico SCIF

Notacin de los diagramas de flujo de datos.

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF

Sistema Farmacutico SCIF 1.2.8 Diccionario de datos

Sistema Farmacutico SCIF

ANLISIS DEL SISTEMA SCIF

2. ANLISIS DEL SISTEMA S. C. I. F.

Sistema Farmacutico SCIF

ANLISIS DEL SISTEMA SCIF

2.2 Descripcin detallada del sistema

Sistema Farmacutico SCIF

ANLISIS DEL SISTEMA SCIF

Sistema Farmacutico SCIF

ANLISIS DEL SISTEMA SCIF

2.3 Diseo Conceptual

Sistema Farmacutico SCIF Medicamentos Proveedores Clientes Administrador Empleados

ANLISIS DEL SISTEMA SCIF

Sistema Farmacutico SCIF

ANLISIS DEL SISTEMA SCIF

Entidad Medicamentos Proveedores Clientes Empleados

Tipo Numrico 6 Numrico 6 Numrico 6 Numrico 6