• Author / Uploaded
• Hilde Yahuana Montalvan

Citation preview

“AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.

U.S.P FACULTAD MEDICINA HUMANA ESCUELA PROFECIONAL DE FARMACIA Y BIOQUIMICA



CURSO: INFORMATICA APLICADA



TEMA: BASES DE DATOS (BDs) Y SU APLICACIÓN EN FARMACIA



ALUMNOS:

Yahuana Montalván Hilde. Ramos Moncada Homero. Correa Matorel Rafael. Dioses Vargas Caroli.



CICLO: X



DOCENTE: ING. Freddy A. Rivera Montero

SULLANA setiembre del 2016.

DEDICATORIA: A nuestro señor Jesucristo, por iluminar

nuestras

mentes

y

guiarnos en el sendero del bien, para lograr realizarnos como hijos

suyos

y

buenos

futuros

profesionales de la salud.

AGRADECIMIENTO

A nuestra Docente. ING. Freddy A. Rivera Montero. Que nos orienta para hacer mejores Profesionales en un futuro, por su labor y desempeño día a día, eso nos enseña a los jóvenes que el ser Docente, es la labor más sublime del mundo, porque no, solo educa mentes, sino, nos enseña a hacer mejores personas.

A nuestra Universidad Particular “San Pedro” de Sullana por ser esta la que consolida nuestros sueños de ser profesionales de éxito.

INTRODUCCIÓN A LAS BASES DE DATOS (BDs) Una base de datos (BD) se define como un “conjunto de datos relacionados entre sí”. Los conceptos relevantes en esta definición son “datos” y “relacionados”. “Datos”: 

Conjunto de hechos relevantes que pueden ser registrados de algún modo, y que cuentan con un significado implícito.



Reflejan situaciones del mundo real y cambios en esas situaciones.

“Relacionados”: 

Debe existir homogeneidad en la colección de datos que conforma una BD. No se trata de un conjunto seleccionado de forma aleatoria.



Los datos se recopilan y registran con una finalidad.



Los datos deben ser relevantes con respecto a esa finalidad.

La particularidad definitiva que convierte a un conjunto de datos en una base de datos es la siguiente: una BD se controlan por medio de Sistemas de Gestión de Bases de Datos (SGBDs). Sistema de Gestión de Bases de Datos: Conjunto de programas de propósito general, que proporcionan funcionalidades horizontales para facilitar la gestión de la información contenida en una base de datos. Los SGBDs actúan de intermediarios entre los datos y los programas de aplicación (y sus usuarios) que los procesan y utilizan.

En ocasiones, los usuarios también podrán acceder a los datos interaccionando directamente con el SGBD.

Necesidad de los SGBDs La pregunta a realizar es ¿por qué son necesarios los SGBDs para gestionar las colecciones de datos (las BDs)? En el enfoque tradicional (el adoptado en los albores de la informática), se sumía que cada quien se construía los programas de aplicación que necesitaba; y para cada programa se creaban un conjunto de ficheros en el almacenamiento secundario (discos...) donde se registraban y mantenían los datos que se necesitaban. Cada uno de estos ficheros se creaba con la estructura y formato internos que se ajustasen más a las necesidades del programa. Por ejemplo, un programa para la gestión de la matriculación de una universidad podría mantener la información sobre los alumnos en un fichero de texto, con una línea por alumno, y los diferentes datos separados por símbolos especiales. DNI || Nombre || FNacimiento || Dirección || CP || Localidad 76.666.999 || Pedro Pérez || 03-07-1913 || Plaza Conchiñas 5678 || 23.879 || A Coruña 01.000.009 || María Blasco || 31-02-1878 || Plaza Armas 329 || 99.369 || Ferrol ...

Y un programa de gestión de socios de la biblioteca de la misma universidad podría mantener su propio fichero con información sobre los mismos, aunque almacenada en diferente orden y formato, con separadores diferentes, e incluso con cierta información diferente. DNI @ Apellidos @ Nombre @ Dirección @ CP @ Localidad @ Teléfono 76.666.999 @ Pérez @ Pedro @ Plaza Conchiñas 5678 @ 23.879 @ A Coruña @ 981 123456 01.000.009 @ Blasco @ María @ Plaza Armas 329 @ 99.369 @ Ferrol @ 981 654321

También podría existir un fichero con información sobre los fondos disponibles en la biblioteca: ISBN @ Titulo @ Autor @ Ejemplares disponibles

12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3 12-3128-510 @ XML @ Peter Schönk @ 0

Y, finalmente, otro fichero con información sobre los préstamos de libros realizados hasta la fecha DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución 76.666.999 @ 12-4567-321 @ 05/01/2003 @ 09/01/2003 76.666.999 @ 12-4567-321 @ 09/01/2003 @ 12/01/2003 01.000.009 @ 12-3128-510 @ 10/01/2003 @ --...

Este enfoque presenta ciertos problemas, que pasaremos a analizar a continuación: 

El problema más importante es el de la redundancia: es posible mantener información repetida en múltiples ficheros. Eso puede implicar que cuando se produzcan modificaciones de información se puedan dar problemas de inconsistencia. En el ejemplo de la universidad, podría darse el caso de que un alumno (por ejemplo Pedro) cambie de domicilio, y que notifique ese cambio a la administración de su centro. Los administrativos utilizarán su programa de gestión de datos para modificar la información recogida en su fichero. Pero si no notifican el cambio a los bibliotecarios, el fichero de datos de la biblioteca mantendrá la información antigua sobre el domicilio del alumno, que ahora será errónea. Se trata de un caso de flagrante inconsistencia entre la información recogida en uno y otro fichero; y de inconsistencia entre la información recogida en el fichero de la biblioteca y la



realidad. Un problema relacionado es el del aislamiento de datos: al estar dispersos en varios ficheros, utilizados probablemente por usuarios diferentes, los datos son difíciles de conseguir. Es posible que un usuario desconozca que una información que necesita está disponible en alguno de los ficheros informatizados de la organización en la que trabaja. En el caso de nuestro ejemplo bien podría suceder que los administrativos de la universidad, necesitando en un momento dado contactar urgentemente con un alumno,

desconozcan que los bibliotecarios disponen de su teléfono en su fichero de gestión de usuarios. 

La solución al aislamiento de datos podría pasar por centralizar la información, y por poner de acuerdo a todos los integrantes de una organización para determinar aquellos ficheros necesarios y la estructura de la información que deberían mantener. Aun así, persistirían otros problemas; por ejemplo, problemas de dificultad de acceso. Los programas de aplicación están diseñados para proporcionar una funcionalidad específica. ¿qué sucede si de repente surge una necesidad nueva, específica, puntual, de información? Se hace necesario corregir y rescribir los programas de aplicación para satisfacerla, algo que no necesariamente va a ser trivial, y que posiblemente requeriría de personal especializado (informáticos). En nuestro ejemplo, podría suceder que los bibliotecarios necesiten conocer la media de préstamos por usuario del último mes, información que el programa de gestión no está preparado para calcular: no quedaría más remedio que acudir al fichero mismo y calcular la información “a mano”. El problema de la dificultad de acceso consiste, pues, en que no existe un modo práctico y sencillo, en este enfoque, de adaptarse a nuevas necesidades de información de forma rápida y sencilla.



Otro problema, aunque no exclusivo del enfoque tradicional basado en ficheros, es el del control de la integridad de los datos. Los hechos que se recogen en una BD han de ser un fiel reflejo de la realidad para ser de utilidad. Sin embargo, es posible que se produzcan errores durante la recopilación de los datos, o durante su introducción (errores al teclear la información, por ejemplo) en los ficheros. Se hace necesario introducir, en lo posible, mecanismos de control en los programas de aplicación para asegurarnos que la información recogida en los ficheros es correcta y veraz. Esos mecanismos de control se basan en la aplicación de una serie de reglas, o restricciones, que garantizan esa integridad de los datos. Reglas como por ejemplo “ningún usuario puede tener más de tres libros en préstamo”; o “todo usuario tiene un DNI, con formato 99.999.999”. Cada vez que un programa

de aplicación modifique los datos almacenados en los ficheros, deberá comprobarse que la nueva información no viole ninguna de esas reglas. Por ejemplo, los programas de gestión administrativo y de la biblioteca de nuestro ejemplo deben incluir sendos controles referentes a la corrección de los DNI de los alumnos y socios de la biblioteca que manejen, respectivamente. A partir de este ejemplo es fácil descubrir el mayor inconveniente del enfoque tradicional de gestión de ficheros: un mismo control ha de ser incluido (y realizado) en múltiples programas de aplicación, cuando lo ideal sería que fuese realizado una única vez. 

Algo a preguntarse es ¿qué sucede cuando varios usuarios acceden al mismo tiempo (a través de los correspondientes programas de aplicación) a los mismos ficheros? Esas situaciones pueden acabar dando lugar a situaciones de inconsistencia de datos, que serán consecuencia de problemas de concurrencia de acceso y manipulación de los datos. Para verlo con nuestro ejemplo, supongamos el siguiente escenario: - Supongamos que en la biblioteca disponemos de tres ejemplares del mismo libro, el que tiene por ISBN 12-3128-510 y por título ‘Bases de datos’, que no están actualmente en préstamo; y así lo reflejamos en el fichero correspondiente a los fondos.

ISBN @ Titulo @ Autor @ Ejemplares disponibles ... 12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3

- Supongamos ahora que dos usuarios de la biblioteca pretenden llevarse en préstamo dos ejemplares de ese mismo libro. Cada uno acude a un bibliotecario para efectuar la operación.

- El primer bibliotecario accede desde su PC, con su programa de gestión, al fichero de fondos y comprueba que efectivamente hay 3 ejemplares

disponibles en la actualidad. El programa conserva ese dato para no tener que acceder nuevamente al fichero para consultarlo.

- El segundo bibliotecario procede de la misma forma. Su programa de gestión, en su PC, también conserva con el dato de los 3 ejemplares disponibles.

- El primer bibliotecario usa el programa para registrar el préstamo del libro en el fichero de préstamos. Y, a continuación, el programa calcula, a partir del número de ejemplares disponibles que había recuperado del fichero (3) el número de ejemplares que ahora queda libres (3-1=2) y lo graba en el fichero de fondos para actualizarlo. ISBN @ Titulo @ Autor @ Ejemplares disponibles ... 12-4567-321 @ Base de Datos @ Ramez Elmasri @ 2

- El segundo bibliotecario procede de idéntica forma: usa su programa para registrar el préstamo del libro en el fichero de préstamos; y, a continuación, el programa calcula, a partir del número de ejemplares disponibles que había recuperado del fichero (¡que vuelve a ser 3!) el número de ejemplares que ahora quedan libres (3-1=2) y lo graba en el fichero de fondos para actualizarlo. ISBN @ Titulo @ Autor @ Ejemplares disponibles ... 12-4567-321 @ Base de Datos @ Ramez Elmasri @ 2

- Las consecuencias: tenemos un fichero (el de fondos) que contiene información que no es cierta: el fichero indica que hay dos ejemplares disponibles del libro ‘Bases de datos’, cuando hemos visto que ahora en realidad solo hay dos. Es fácil ver que si las dos operaciones (los dos

préstamos) hubiesen sido realizados de forma secuencial, una después de otra, la inconsistencia no se habría producido: el problema surge de combinar dos operaciones que van realizando actualizaciones parciales de los datos, y que no deberían mezclarse: mientras una no hubiese concluido y hubiese completado todos los cambios necesarios de forma definitiva, y no parcial, la otra no debería comenzar. Se hace pues necesario incluir en todos nuestros programas mecanismos que detecten si otros programas están accediendo en un momento dado a los datos que necesitamos, y evitar estas situaciones. 

Un problema íntimamente ligado al anterior es el de la atomicidad de las operaciones a realizar sobre los ficheros. Hemos visto que una operación realizada sobre los ficheros esté compuesta de una serie de pequeñas actualizaciones sobre los datos contenidos en los mismos: en el caso del programa de gestión de la biblioteca, hemos visto que el préstamo de una libro implica cambios sobre el fichero de préstamos y el fichero de fondos. Para ver un ejemplo de este tipo de problema, supongamos ahora el siguiente escenario: - Un usuario solicita el préstamo del libro ‘Bases de datos’, del que nos queda un ejemplar en la biblioteca.

ISBN @ Titulo @ Autor @ Ejemplares disponibles ... 12-4567-321 @ Base de Datos @ Ramez Elmasri @ 1

- El bibliotecario utiliza su programa de gestión para ejecutar el préstamo. El programa registra, en primer lugar, el hecho en el fichero de préstamos. DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución ... 76.666.999 @ 12-4567-321 @ 09/02/2004 @ --...

Y a continuación, se dispone a modificar la información sobre el número de ejemplares disponibles. Comprueba el número de ejemplares disponibles hasta ese momento (1), y en ese momento... se produce un corte de energía. La operación se ha completado sólo parcialmente, con lo que la información de los ficheros vuelve a quedar en un estado inconsistente. Nos encontramos, por lo tanto, ante un nuevo problema: las operaciones a realizar sobre los ficheros deberían presentar un carácter atómico: deben ser realizadas por completo, y en caso de no completarse, ser anulados los cambios realizados hasta ese momento. ¿Cómo conseguir eso con nuestros programas de aplicación?  Nuevos problemas a considerar son los de seguridad: La información que se almacena en los ficheros y que manejan los programas es de muy diferente tipología. También es habitual encontrarse con diferentes categorías de usuarios de esos programas. En nuestro ejemplo, es posible suponer que en la biblioteca, además del personal fijo, se cuente también con algún becario/a que los ayude en la gestión. Podría ser razonable pensar que los becarios no deberían tener acceso a toda la información almacenada en los ficheros informatizados (por ejemplo, la información contable relativa a los presupuestos de la biblioteca). Esa información debe ser también protegida de aquellos usuarios externos que sí tengan acceso a la información del catálogo, por ejemplo. Por lo tanto, se hace patente la necesidad de establecer diferentes niveles de acceso a la información, que deben ser mantenidos por medio de mecanismos de control implementados en los programas de aplicación. 

Un último caso a considerar: problemas de respaldo y recuperación: los datos, y los ficheros que los contienen, se almacenan en algún tipo de soporte informático, que, por diversos motivos, es susceptible de sufrir daños de forma accidental: a causa de un problema físico, por culpa de un virus informático, por un incendio... Es necesario, por lo tanto, establecer mecanismos para la realización, de forma regular, de copias de seguridad, que permitan la recuperación de los ficheros, con los datos existentes con anterioridad al

accidente. Eso implicará, probablemente, la construcción de programas de aplicación especializados que automaticen la realización de dichas copias, y su restauración en caso necesario. Todos estos problemas que hemos presentado tienen dos cosas en común: en primer lugar, son independientes de un dominio o área de aplicación determinada (a pesar de haberlos presentado empleando un ejemplo correspondiente a la gestión de una universidad, en general, y de una biblioteca universitaria en particular); y en segundo lugar, su resolución pasa por modificar nuestros programas de aplicación para poder detectarlos y solventarlos. La pregunta que surge es: ¿es necesario replicar todos estos controles y mecanismos de resolución en todos nuestros programas? Ya que centralizamos e uniformizamos los ficheros, y por tanto los datos que contienen, ¿por qué no hacer lo mismo con la resolución de estos problemas. Esa es la idea que dio lugar a la construcción de los SGBDs: un conjunto de programas destinados exclusivamente a la resolución de estos problemas: a partir de ahora, podemos destinar nuestros esfuerzos a construir eficientemente aquellos programas de aplicación que necesitemos, centrándonos exclusivamente en la funcionalidad que deben proporcionar (la gestión de una biblioteca, de un hospital, de un banco...) Los problemas generales asociados a la gestión de datos de cualquier tipo (precisamente aquellos que acabamos de presentar) ya estará resuelta por cualquier SGBD, que eximirá a nuestros programas de esa responsabilidad. Soluciones proporcionadas por los SGBDs Como hemos visto, el uso de un SGBD no elimina la aparición de los problemas de carácter general asociados al tratamiento de datos y de ficheros; pero si elimina la necesidad de resolverlos, ya que el SGBD proporcionará los mecanismos necesarios para hacerlo. Dedicaremos ahora un tiempo a explicar alguno de estos mecanismos, a partir de la lista de problemas que acabamos de presentar en la sección anterior. 

Redundancia y aislamiento: Estos problemas se resuelven por medio de una gestión centralizada de los datos. Los datos se mantienen ahora en un

conjunto único de ficheros gestionados por el SGBD, de los que habrá sido eliminada cualquier tipo de redundancia. Cualquier acceso a los datos debe ser realizado a través del SGBD; las modificaciones o ampliaciones de los ficheros deben ser gestionados por un conjunto de personas (los administradores) que serán responsables del SGBD y de sus ficheros; y serán los administradores los encargados de resolver cualquier duda de los usuarios acerca de la información mantenida en la base de datos (resolviendo así el problema del aislamiento). 

Dificultad de acceso: los SGBDs presentan a los usuarios (y a sus programas de aplicación) diferentes interfaces de acceso a la información. Entre esas interfaces se encontrarán: - Menús (programas genéricos de consulta y actualización de datos.) - Lenguajes de consulta y actualización de bajo (APIs) y de alto nivel (SQL)

Lenguajes como SQL (siglas de Structured Query Language, lenguaje de consulta estructurado) permiten a cualquier usuario recuperar información de una BD no prevista en los programas de aplicación que utiliza de un modo sencillo. Se dice que SQL es un lenguaje de alto nivel – y además no procedimental - porque permite especificar, en un lenguaje muy próximo al inglés, la definición de todo tipo de consultas sin necesidad de indicar cómo debe ser recuperada la información: solo hay que especificar qué información se necesita. De ese modo se simplifica el problema de la dificultad de acceso: proporcionando un procedimiento simple y flexible de responder a nuevas necesidades de información. 

Control de integridad: los SGBDs permiten definir, por medio de lenguajes especiales, reglas que expresen restricciones de integridad: condiciones que deben ser cumplidas por los datos almacenados en una BD. De este modo, el SGBD libera a los programas de la comprobación de estas condiciones; cada vez que se realice alguna modificación de la BD, será el propio SGBD el que

se encargue de verificar, una por una, cada una de las restricciones previamente establecidas. De no ser así, os cambios serán rechazados. 

Concurrencia: el SGBD impedirá que se produzcan situaciones de concurrencia susceptibles de producir inconsistencias. Para ello se encargará de bloquear el acceso a ciertos datos si fuese necesario (y será el propio gestor quien decida, en la mayoría de los casos, cuándo es necesario el bloqueo). En el caso de nuestro ejemplo, el gestor bloquearía temporalmente la reserva del segundo libro hasta que la del primero hubiese concluido totalmente.

Paso 1: Comprobación del número de ejemplares libres (3) por parte del primer bibliotecario. ¡Bloqueo automático de esta información! Paso 2: Grabación de la reserva por parte del primer bibliotecario Paso 3: Grabación del nuevo número de ejemplares libres (2) por parte del primer bibliotecario. Desbloqueo automático de esta información. Paso 4: Comprobación del número de ejemplares libres (2) por parte del segundo bibliotecario, una vez desbloqueada esta información. Paso 5: Grabación de la reserva por parte del segundo bibliotecario. Paso 6: Grabación del nuevo número de ejemplares libres (1) por parte del segundo bibliotecario. 

Atomicidad: el SGBD se encargará de almacenar toda la información necesaria para conseguir que, si una operación compleja se queda a medias, los cambios realizados hasta ese momento sean invalidados y la BD se devuelva al estado válido y consistente inmediatamente anterior a la ejecución de la operación. En el caso de nuestro ejemplo, la grabación de la reserva en el fichero de préstamos sería borrada, al no haberse completado la operación en su total integridad.

DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución ... 76.666.999 @ 12-4567-321 @ 09/02/2004 @ ---



Seguridad: El SGBD distingue diferentes perfiles de usuario, y para cada perfil o para cada usuario concreto de una BD, permite establecer: - Los datos a los que tiene acceso - El tipo de acceso permitido a esos datos (consulta, modificación...)

Para poder identificar el perfil de cada usuario, cada uno habrá de contar con una cuenta personal de acceso, validada normalmente a través de una contraseña. 

Respaldo: Los SGBDs vienen normalmente acompañados de herramientas que automatizan la realización de copias de seguridad de todas las BDs bajo su “responsabilidad”.

Arquitectura en tres niveles Además de toda la funcionalidad que acabamos de ver, el SGBD se encarga de la gestión de los ficheros en los que se almacenan los datos, incluida la intermediación en todas las operaciones de acceso y actualización a los mismos. El problema que surge es el siguiente: la organización y gestión de los ficheros en los que se mantiene la información puede resultar muy compleja, e incluye aspectos como el número de ficheros utilizados, el espacio ocupado, su estructura interna... Por ejemplo, en el caso de la biblioteca que hemos utilizado como ejemplo, hemos estado utilizando dos ficheros separados para almacenar los datos de los libros y sus préstamos; aunque nada nos habría impedido utilizar sólo uno: ISBN @ Titulo @ Autor @ Ejemplares disponibles DNI Socio @ ISBN Libro @ Fecha préstamo @ Fecha devolución 12-4567-321 @ Base de Datos @ Ramez Elmasri @ 3 76.666.999 @ 12-4567-321 @ 05/01/2003 @ 09/01/2003 76.666.999 @ 12-4567-321 @ 09/01/2003 @ 12/01/2003

12-3128-510 @ XML @ Peter Schönk @ 0 01.000.009 @ 12-3128-510 @ 10/01/2003 @ --...

Este formato de almacenamiento agilizaría la búsqueda de información sobre los préstamos de un determinado libro realizados hasta la fecha: Bastaría con localizar la línea correspondiente a un libro dentro del fichero, y las líneas siguientes corresponderían a todos sus préstamos. En el formato anterior (dos ficheros) sería necesario (1) localizar la línea correspondiente al libro en el fichero de fondos bibliográficos; y (2) localizar todas las líneas correspondientes al libro en el fichero de préstamos (lo que podría implicar comprobar una por una todas las líneas del fichero). En cambio, el formato con un único fichero complicaría enormemente otras operaciones. Por ejemplo, el registro de un nuevo préstamo. Eso implicará (1) hacer sitio en el fichero para incluir una nueva línea (lo cual requerirá desplazar una a una todas las líneas siguientes que haya en el fichero); y (2) grabar la línea correspondiente al nuevo préstamo. Cuando en el formato anterior, era suficiente con añadir una nueva línea al final del fichero de préstamos. Como se ve, la organización de los ficheros de la BD influye enormemente en la eficiencia de las operaciones realizadas sobre los datos. Los SGBDs organizarán la información de la forma que la eficiencia de dichas operaciones sea mayor, a veces utilizando estructuras de almacenamiento realmente complejas. Esas estructuras complejas deberán ser entendidas por los usuarios de la BD y por los técnicos encargados de elaborar los programas de aplicación para poder utilizar convenientemente cada BD; algo que supone una complicación a la hora de desarrollar su trabajo. Para evitarlo, los SGBD cumplen una función más: la de enmascarar los datos. Mejor dicho, la de enmascarar la estructura de bajo nivel de los datos y las operaciones a ese nivel (los métodos de acceso). El SGBD nos va a proporcionar un nivel de abstracción superior, una visión conceptual (virtual, en el sentido de no real) de los datos, que no es la real, pero que facilita nuestro acceso a la información.

Por ejemplo, los SGBDs más comunes son los relacionales, los cuales, sea cual sea la organización de sus ficheros, nos muestran la información de forma que los datos parecen estar contenidos en tablas, sobre las que operaremos directamente. De ese modo nos olvidamos de que estamos trabajando sobre ficheros, y de problemas como, por ejemplo, la necesidad de hacer “sitio” en los mismos para introducir nuevas líneas. Esas cuestiones serán responsabilidad del SGBD, que las llevará a cabo de forma automática. Para poder dar esa visión abstracta de los datos, nos basamos habitualmente en modelos de referencia (el modelo relacional es un ejemplo), que definen formas de organizar la información de una forma más comprensible y manejable. Se trata de herramientas conceptuales, que definen conceptos o elementos genéricos para organizar y describir la información. Por otro lado, habíamos comentado que no todos los usuarios de una BD tendrán el mismo nivel de acceso a los datos contenidos en la misma, en cuanto a la información a la que tendrán acceso, y en cuanto a las operaciones que podrán realizar sobre la misma. Dicho de otro modo, no todos los usuarios tendrán la misma visión de los datos. Eso significa que podemos definir un tercer punto de vista de los datos, unido al punto de vista físico (los ficheros) y conceptual (las tablas, por ejemplo): el punto de vista de cada perfil de usuario, al que se conoce con la denominación genérica de punto de vista externo. Siguiendo con el caso de los SGBDs relacionales, cada perfil de usuario tendrá asociada una vista externa formada por aquellas tablas o secciones de las tablas - de entre todas las que constituyan la BD - a las que un usuario con ese perfil tendrá acceso. A este triple punto de vista de los datos (la visión física, la visión conceptual y la visión externa) se la conoce como la arquitectura en tres niveles de la información: ya que los tres puntos de vista originan tres niveles de abstracción de los datos. Para cada nivel es posible desarrollar un esquema de datos: una descripción de la organización de los datos tal y como son vistos a ese nivel de abstracción. Por analogías con la teoría de conjuntos, a los esquemas se los conoce también como la

intensión de los datos, mientras que los datos se pueden ver como la extensión (las instancias) de un esquema. Por supuesto, la finalidad de estos esquemas es ayudarnos a comprender, de una forma sencilla e inmediata, la organización de la información en la BD. A continuación la arquitectura en tres niveles de la información y sus principales características: Nivel externo - A este nivel se describen las diferentes visiones que de los datos tiene cada usuario de un determinado perfil o tipo, por medio de un conjunto de esquemas externos. - Cada esquema externo omite aquellos datos que el usuario correspondiente no necesita, o a los que no tiene permiso de acceso; describe sólo los datos a los que se tiene acceso - Se basa en un modelo de referencia de alto nivel. Nivel conceptual - A este nivel se describe la organización de la BD al completo, a partir de un modelo de datos de referencia de alto nivel. - La descripción se ciñe exclusivamente a los datos, y omite de forma intencionada los detalles referentes al modo de almacenamiento y de acceso a los mismos. - La descripción constituye el esquema conceptual de la BD. Nivel interno - A este nivel se describe la organización real de la BD al completo.

- La descripción constituye el esquema físico de la BD, e incluye los ficheros que la componen, la organización de los mismos, y los métodos de acceso utilizados. - Los usuarios de la BD no necesitan conocer esta información. Es el administrador de la BD el que gestiona estos ficheros SQL Como explicábamos en el apartado anterior, los SGBDs nos proporcionan la transparencia necesaria para no tener que conocer, como usuarios de una BD, los detalles de su organización física. La visión que tendremos de la información será de más alto nivel: todas las operaciones que realicemos sobre una BD serán realizadas tomando como referencia la descripción establecida en el esquema conceptual. El SGBD se encargará, de forma automática, de hacer posible esa ilusión. Uno de los modelos de referencia más utilizados para construir una visión de los datos a tan alto nivel es el modelo relacional. Como se ha comentado también en el apartado anterior, el modelo relacional implica la organización de los datos en forma de tablas. Se trata de uno de los modelos más utilizados por los SGBDs comerciales, y al que se ha dedicado un mayor esfuerzo de investigación. Tal es su importancia que se ha acabado convirtiendo en un estándar: es el modelo de datos de alto nivel de referencia en el mundo de las bases de datos. Buena parte del éxito de este modelo se debe al lenguaje SQL (Structured Query Language): se trata de un lenguaje, también de alto nivel, que permite construir todo tipo de consultas sobre la información contenida en una BD relacional, con una sintaxis muy similar a la del inglés. Todos los SGBDS basados en el modelo relacional van a soportar este lenguaje. Eso significa que si aprendemos a utilizar SQL podremos realizar consultas sobre múltiples SGBDs diferentes, aunque estos estén construidos de diferente manera y

organicen internamente la información de acuerdo a estructuras muy distintas. De ahí la importancia que ha cobrado este lenguaje. En realidad, SQL es un lenguaje muy completo: no solo permite consultar la información almacenada en una base de datos, sino que también: - Permite gestionar la estructura de las tablas que forman la BD, e incluso definir nuevas tablas si es necesario, o eliminar alguna de las ya existentes. - Permite actualizar el contenido de las tablas, insertando o eliminando filas, o modificando los valores de las ya existentes.

BASE DE DATOS Y APLICACIÓN EN FARMACIA En el ámbito farmacéutico la base de datos significa una herramienta de mucha importancia y utilidad, ya que permite guardar todo tipo de datos de forma ordenada y segura, de manera que facilita el acceso a información de distintas áreas de la FARMACIA o BOTICA tanto administrativa, comercial, proveedores, laboratorios farmacéuticos, entre otros. Es así que se puede acceder a los stocks de medicamentos, la rotación de los mismos, ventas diarias, mensuales, anuales, también ayudara a separar los medicamentos

por clase (antibióticos, aines,

antiácidos, corticoides, etc.), forma farmacéutica (tabletas, jarabes, sol. Inyectable, etc.), laboratorio (Medifarma, Hersil, Farmindustria, etc.), etc. Base de Datos. Farmacia 1. Pasos 2. Resumen 3. Bibliografía Pasos Estos pasos demuestran el proceso de normalización de una tabla de Farmacia. 1. Tabla sin normalizar: CODIGO 1022 4123

PRODUCTO GENURIN ADVIL

CANTIDAD 412 216

TIPO 1 101-07 201-01

2. Primera forma normal: no hay grupos repetidos

TIPO 2 143-01 211-02

TIPO 3 159-02 214-01

Las tablas sólo deben tener dos dimensiones. Puesto que un producto tiene varios tipos, estas clases deben aparecer en una tabla independiente. Los campos Tipo1, Tipo2 y Tipo3 de los registros anteriores son indicativos de un problema de diseño. Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Tipo), según se muestra a continuación: CODIGO

PRODUCTO

CANTIDAD

TIPO

1022 1022 1022 4123 4123 4123

Genurin Genurin Genurin Advil Advil Advil

412 412 412 216 216 216

101-07 143-01 159-02 201-01 211-02 214-01

3. Segunda forma normal: eliminar los datos redundantes Observe los diversos valores de Tipos para cada valor de Código en la tabla anterior. Código no depende funcionalmente de Producto (la clave principal), de modo que la relación no cumple la segunda forma normal. Las dos tablas siguientes demuestran la segunda forma normal:

Código 1022 4123

Producto Genurin Advil

Cantidad 412 216

Código 1022 1022 1022 4123 4123 4123

Tipo 101-07 143-01 159-02 201-01 211-02 214-01

4. Tercera forma normal: Eliminar los datos no dependientes de la clave. En el último ejemplo, Código (Código) es funcionalmente dependiente del atributo Producto La solución es pasar ese atributo de la tabla, según se muestra a continuación: Código 1022 4123

Producto Genurin Advil

Producto Genurin Advil

Código 412 216

Dept 42 42

Resumen El diseño de bases de datos consta de tres etapas: diseño conceptual, lógico y físico. El diseño lógico es el proceso mediante el que se construye un esquema que representa la información que maneja una empresa, basándose en un modelo lógico

determinado, pero independientemente del SGBD concreto que se vaya a utilizar para implementar la base de datos e independientemente de cualquier otra consideración física. Las dos fases de que consta el diseño lógico son la construcción y validación de los esquemas lógicos locales para cada vista de usuario, y la construcción y validación de un esquema lógico global. Cada una de estas fases consta de una serie de pasos. Un paso importante es la conversión del esquema conceptual a un esquema lógico adecuado al modelo relacional. Para ello, se deben hacer algunas transformaciones: eliminar las relaciones de muchos a muchos, eliminar las relaciones complejas, eliminar las relaciones recursivas, eliminar las relaciones con atributos, eliminar los atributos multievaluados, reconsiderar las relaciones de uno a uno y eliminar las relaciones redundantes. Los esquemas lógicos se pueden validar mediante la normalización y frente a las transacciones de los usuarios. La normalización se utiliza para mejorar el esquema, de modo que éste satisface ciertas restricciones que evitan la duplicidad de datos. La normalización garantiza que el esquema resultante está más próximo al modelo de la empresa, es consistente, tiene la mínima redundancia y la máxima estabilidad. Las restricciones de integridad son las restricciones que se imponen para que la base de datos nunca llegue a un estado inconsistente. Hay cinco tipos de restricciones de integridad: datos requeridos, restricciones de dominio, integridad de entidades, integridad referencial y reglas de negocio. Para garantizar la integridad referencial se debe especificar el comportamiento de las claves ajenas: si aceptan nulos y qué hacer cuando se borra la tupla a la que se hace referencia, o cuando se modifica el valor de su clave primaria. Bibliografía

El diseño de bases de datos relacionales es un tema de consenso, coincidiendo la mayoría de autores en las tres etapas de diseño conceptual, diseño lógico y diseño físico. Sin embargo, los pasos de que consta cada una de estas etapas y la terminología utilizada no es muy uniforme. Este capítulo se ha elaborado siguiendo los pasos que se especifican en el texto de Connolly, Begg y Strachan (1996), combinado con la terminología de Batini, Ceri y Navathe (1994). Autor: Thais Londoño [email protected] República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Superior Instituto Universitario Politécnico Santiago Mariño Ciudad Ojeda Estado Zulia Informe Proyecto Final

Referencias Bibliografías 1. R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3ª edición). Addison-Wesley, 2002.

2. A. Silberschatz, H. F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4ª edición). McGraw Hill, 2002