CAPITULO I 1. ADMINISTRACION DE LOS DATOS 1.1.

Sistemas de informacin y bases de datos Del dato a la informacin Es claro que no es lo mismo dato que informacin, "Por si mismos los datos no tienen significado alguno, sino que deben ser presentados en una forma utilizable y colocados en un contexto que les d valor. Los datos se convierten en informacin cuando se les transforma para comunicar un significado o proporcionar un conocimiento, ideas o conclusiones. La informacin es, entonces, conocimientos basados en los datos de los cuales, mediante un procesamiento, se les ha dado significado, propsito y utilidad.

Esta informacin debe poseer los siguientes atributos o propiedades: relevancia, disponibilidad, integridad, cuantificacin, objetividad, sensibilidad, calidad, confiabilidad y exactitud, o sea que debe llegar en forma rpida y oportuna, debe ser veraz y completa para poder cumplir con sus fines; entonces se podr decir que la informacin es til y efectiva.

Todas estas caractersticas de la informacin hacen a su calidad y se debe asegurar que cualquier sistema de informacin (automtico o manual) genere informacin de este tipo, especialmente porque en cualquier tipo de organizacin la informacin se utiliza para tres tareas crticas en su funcionamiento: planificacin, control y decisin; por ende se deduce que es indispensable el manejo de la informacin para el desarrollo y el logro de los objetivos de las organizaciones, empresas e instituciones. Por qu?

Porque el Medio Ambiente es muy cambiante (los sistemas legales, econmicos, financieros, polticos) y dinmico y las organizaciones (sistemas) deben adaptarse a l, puesto que el presente es dinmico y el futuro es incierto, lo nico que disminuye el riesgo es la informacin. Nada es esttico, nada permanece inalterable o congelado durante mucho tiempo

Qu es un sistema de informacin?
En prrafos anteriores se mencionan los procesos que convierten los datos en informacin y se sugiere que estos procesos son los sistemas de informacin. Para entender mejor el concepto y los alcances de un sistema de informacin se presentan a continuacin algunas definiciones: "Un conjunto formal de procesos que, operando sobre una coleccin de datos estructurada segn las necesidades de la empresa, recopilan, elaboran y distribuyen la informacin (o parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de direccin y control correspondientes (decisiones) para desempear su actividad de acuerdo a su estrategia de negocio" "Un sistema de informacin puede definirse tcnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar a la toma de decisiones, la coordinacin y el control en una institucin." Las definiciones anteriores estn en concordancia con lo expresado sobre datos e informacin: ambas coinciden para que se usa la informacin (control, planificacin y decisin) y cmo se obtiene la informacin: por medio de procesos sobre una coleccin de datos. Estas definiciones introducen el concepto que las tareas de almacenar los datos, la informacin y distribuir los mismos son tareas que forman parte de los procesos del sistema de informacin. El almacenamiento de los datos se realiza en bases de datos relacionales, las mismas tienen un conjunto de caractersticas que aseguran la calidad de los datos que se almacenan en la misma y facilitan el trabajo de mantenimiento, procesamiento y consulta de los mismos.

Los sistemas de informacion desde la perspectiva de los negocios

Un sistema de informacin es una solucin organizacional y administrativa, basada en tecnologa de de informacin, a un reto que se presenta en el entorno.2
1Laudon 2Laudon

y Laudon y Laudon

Organizaciones Los elementos de la organizacin son: personal, estructura, procedimientos operativos, las polticas y la cultura. El trabajo se coordina por la estructura y los procedimientos. Administracin Los administradores manejan la organizacin (je, no es obvio?). Las decisiones se clasifican segn el nivel que ocupen en la organizacin quienes deciden: a) decisiones estratgicas: los directivos. b) decisiones tcticas: gerentes (nivel medio). c) decisiones operativas: supervisores. Tecnologa Se incluye: hardware, software, tecnologa de almacenamiento, tecnologa de comunicaciones

Qu es una base de datos?

James Martin define Base de Datos Relacional como "Una coleccin de datos interrelacionados almacenados juntos con redundancia controlada para servir a una o ms aplicaciones. Los datos estn almacenados de manera que son independientes de los programas que los usan y se emplea un procedimiento comn para agregar nuevos datos y para modificar y recuperar los existentes." Otra definicin terica de bases de datos es: Coleccin de datos organizada para dar servicio a muchas aplicaciones al mismo tiempo al combinar los datos de manera que parezcan estar en una sola ubicacin. Se presenta una ltima definicin de base de datos: Es un sistema de mantenimiento de registros basado en computadores, es decir un sistema cuyo propsito general es

registrar y mantener informacin. Tal informacin puede estar relacionada con cualquier cosa que sea significativa para la organizacin donde el sistema opera - en otras palabras, cualquier dato necesario para los procesos de toma de decisiones inherentes a la administracin de esa organizacin.

Es un repositorio de datos almacenados, y es tanto integrada como compartida. Es integrada porque se trata de una unificacin de varios archivos independientes, donde se elimina total o parcialmente cualquier redundancia entre los mismos. Compartida implica que partes individuales de la base de datos pueden compartirse entre varios usuarios distintos, en el sentido de que cada uno de ellos pueda tener acceso a la misma parte de la BD y utilizarla con propsitos diferentes El anlisis, diseo y desarrollo de las bases de datos conlleva el trabajo de un profesional de sistemas que conozca los mtodos y procedimientos de cada uno de esas tres fases y que luego se encargue de su administracin y mantenimiento. Es de suma importancia que estas tareas sean realizadas de forma concienzuda y que se les dedique todo el tiempo necesario para que la estructura de las bases de datos obtenida se la que mejor se adapte a las necesidades del sistema, de no ser as el posterior tratamiento y consulta de los datos se puede volver intratable.

Por qu utilizar estas tecnologas?

A continuacin se presentan algunas de las razones que proporcionan distintos autores para utilizar bases de datos: Date considera que las bases de datos se deben utilizar porque proporcionan a la organizacin un control centralizado de sus datos de operacin, los que constituyen uno de los activos mas valiosos de la misma. Se evita de esta manera que cada aplicacin disponga de sus propios archivos ocasionando que los mismos se encuentren dispersos y haciendo dificultoso su control.

Al utilizar un sistema de BD se hace imperiosa la necesidad de contar con una persona capacitada que tenga responsabilidad sobre la base de datos, este individuo es el administrador de BD. Ventajas Puede evitarse la inconsistencia Los datos pueden compartirse Pueden hacerse cumplir las normas establecidas Pueden aplicarse restricciones de seguridad Puede conservarse la integridad Pueden equilibrarse los requerimientos contradictorios

1.2. Arquitectura de las plataformas (Escritorio, cliente/servidor, n Capas)

El procesamiento distribuido El trmino procesamiento distribuido describe la colocacin de computadoras dnde estas son necesarias, si en el piso de una planta industrial, en un departamento de contabilidad, en un laboratorio, en un campo localizado, o en una oficina ejecutiva. Una red de computadoras hace que ellos puedan intercambiar informacin, compartir recursos y ejecutar procesamiento distribuido. Una red del proceso distribuido permite que la informacin se origine en cualquier parte de la red. Usted puede poner sistemas dnde les necesitan mientras todava tenga el acceso a los medios de otros sistemas ampliamente dispersados. Distintas mquinas pueden estar conectadas en una red de comunicacin tal que una sola tarea de procesamiento de datos puede ocupar muchas mquinas en la red. En general, cada servidor puede servir a muchos clientes, y cada cliente puede accesar muchos servidor. Un sistema de base de datos distribuido es cuando un cliente puede accesar muchos servidores simultneamente. Es decir, que una sola peticin a "la base de datos" puede combinar datos de varios servidores.

OTRA DEFINICION:
Mtodo de procesamiento de la informacin en el que varios procesos(programas en ejecucin) en paralelo, en paralelo, en la misma mquina o distribuidos entre ordenadores o computadoras interconectados a travs de una red de comunicaciones, colaboran en la realizacin de una tarea. Esta colaboracin pude ser tan sencilla como distribuir la carga de trabajo entre procesos idnticos, en el caso por ejemplo de una red de cajeros automticos, o tan complejo como multitud de procesos distintos.

APLICACIONES: Los ambientes en los que se encuentra con mayor frecuencia el uso de las bases de datos distribuidas son: Cualquier organizacin que tiene una estructura descentralizada.

Casos tpicos de lo anterior son: organismos gubernamentales y/o de servicio pblico. La industria de la manufactura, particularmente, aquella con plantas mltiples. Por ejemplo, la industria automotriz. Aplicaciones de control y comando militar. Lneas de transportacin area. Cadenas hoteleras. Servicios bancarios y financieros.

EJEMPLO:

en una compaa, la realizacin de tareas que requieran altas capacidades de proceso, para lo cual se utilizarn los PCs conectados a la intranet de esta empresa. Sin embargo, si queremos afrontar un proyecto de mbito universal y con un elevado grado de complejidad habremos de ser capaces de abordarlo mediante anlisis diferenciales que puedan ser realizados de forma separada, en paralelo mediante diferentes mquinas presentes en nuestro ambicioso terreno de juego: Internet. A continuacin presentaremos dos de estos proyectos. El proyecto SETI @ Home desarrollado por la Universidad de California en Berkeley comienza en Mayo de 1999. Ms de 2 millones de voluntarios lo convierten en la experiencia ms grande de procesamiento distribuido hasta la fecha. SETI (the Search for Extra-Terrestrial Inteligente) es un nombre colectivo para designar los diferentes programas encargados de buscar evidencias de vida en el cosmos. Para ello se utiliza como fuente los datos recogidos por radiotelescopios, que como si de grandes pabellones auditivos se tratase, se encargan de escudriar el cielo en busca de seales de radio provenientes del espacio. Como se comprender, la capacidad de computacin necesaria para analizar todos los datos que se recogen es desmesurada. Pero, ah es precisamente donde nace SETI@Home como proyecto de aplicacin de computacin distribuida de la Universidad de Berkeley. Los datos de partida en este caso son los recogidos por el telescopio de Arecibo en Puerto Rico, el mas grande del mundo.

De una forma similar a SETI@Home surge una nueva iniciativa conjunta de las empresas Intel y United Devices centrada esta vez en la investigacin del cncer. En este caso se pone el procesamiento distribuido de Internet al servicio de la investigacin molecular realizada en el departamento de Qumica de la Universidad de Oxford en Inglaterra y la Fundacin Nacional para la

Investigacin del Cncer en los EE.UU. El objetivo de estos centros es la bsqueda de drogas que acten contra el cncer y la leucemia. Para ello es necesario realizar complejos anlisis de compatibilidad molecular sobre molculas, susceptibles de convertirse en un tratamiento efectivo para lo que se precisa de una alta potencia de proceso.

FUTURO DEL PROCESAMIENTO DISTRIBUIDO

Aunque la idea de distribucin de datos es bastante atractiva, su realizacin conlleva la superacin de una serie de dificultades tecnolgicas entre las que se pueden mencionar:

Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de datos se realice de manera eficiente, presumiblemente ptima. Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un ambiente distribuido. Distribuir datos en los nodos del ambiente distribuido de una manera ptima. Controlar el acceso a los datos disponibles en el ambiente distribuido. Soportar la recuperacin de errores de diferentes mdulos del sistema de manera segura y eficiente. Asegurar que los sistemas locales y globales permanezcan como una imagen fiel del mundo real evitando la interferencia destructiva que pueden ocasionar diferentes transacciones en el sistema. As tambin, la aplicacin de tcnicas de distribucin de informacin requiere de superar algunas dificultades de ndole organizacional y algunas otras relacionadas con los usuarios. Entre ellas se puede mencionar:

El desarrollo de modelos para estimar la capacidad y el trfico esperado en el sistema distribuido. Soportar el diseo de sistemas de informacin distribuidos. Por ejemplo, ayudar a decidir donde localizar algn dato particular o donde es mejor ejecutar un programa de aplicacin. Considerar la competencia que habr por el uso de los recursos entre nodos diferentes. Aun cuando las dificultades mencionadas son importantes, las ventajas de la distribucin de informacin han promovido su aplicacin en ambientes del presente y del futuro.

Centralizar toda la informacin en una sola base de datos comn Para cumplimentar este objetivo es necesario trabajar con el modelo cliente/servidor y armar una base de datos nica que contuviera todas las tablas con la informacin del proyecto. Con este modelo se evitan las duplicaciones (copias y comparaciones de datos), teniendo siempre una versin nica y correcta de los mismos, disponible en lnea para su uso inmediato. Este hecho permite llevar ms fcilmente la informacin a donde se necesita y contribuye a aumentar su precisin, pues se puede obtener de su fuente (el servidor) y no de una copia en papel o en medio magntico. A continuacin se explica de forma ms detallada que es y cmo funciona el modelo cliente servidor.

Modelo de Cliente/Servidor

Cliente/Servidor describe modelos de distribucin fsica en los que el equipo cliente realiza una solicitud al equipo servidor y ste sirve o responde a la solicitud.

Originalmente este modelo se bas en aplicaciones clientes ejecutadas en un equipo personal o de escritorio que obtienen acceso a la informacin de servidores remotos o equipos principales. La parte de cliente de la aplicacin suele estar optimizada para la interaccin del usuario, mientras que la parte del servidor proporciona la funcionalidad centralizada para mltiples usuarios.

Procesamiento cooperativo. Es una arquitectura donde dos o ms computadoras comparten el procesamiento de un programa. Esta arquitectura debe contar con recursos distribuidos: programas, archivos, base de datos, etc. El procesamiento cooperativo debe proveer: acceso transparente al sistema, evitando de esta manera que el usuario se preocupe si el recurso a acceder es local o remoto. Existen varias tcnicas para el procesamiento cooperativo, cada una de ellas aplicable a un cierto tipo de sistema: Procesamiento front-end. Pipes. Llamadas a procedimientos remotos. Interacciones cliente/servidor.

Procesamiento front-end. Se puede escribir un programa en una PC que ejecute una aplicacin de un host sin que se modifique el cdigo de la aplicacin en el host. Esto es posible ya que el cdigo del programa en la PC realiza llamadas a una aplicacin residente por medio de una interfaz de programas de aplicacin (API). El API ms comnmente utilizado para el sistema IBM/3270 es el High Level Language APLI (HLLAPI).

Pipes. Las pipes representan un mecanismo orientado a conexin que pasa datos de un proceso a otro. Las pipes son muy utilizados en sistemas basados en UNIX. Una tubera de agua comn, con agua introducindose en un lugar y saliendo en otros lugares, es una buena

representacin de las pipes de comunicacin. En principio de cuentas, los procesos pueden estar en diferentes mquinas, y se pueden estar ejecutando en diferentes sistemas operativos. Procesamientos remotos El modelo de comunicacin basado en llamadas a procedimientos remotos permite a un procedimiento llamar a otro procedimiento que se encuentra en una computadora remota. Esta operacin se ejecutada de la misma manera en que se ejecuta una llamada a un procedimiento local. El procedimiento que llama se bloquea hasta que el procedimiento llamado termina y se recibe una respuesta. Cuando se hace una llamada, se enva un mensaje de solicitud a la computadora remota donde reside el procedimiento, se crea un proceso para ejecutar este procedimiento, y despus de que este proceso se completa, se enva un mensaje de respuesta al proceso que realiz la llamada. BASES DE DATOS DISTRIBUIDAS Software de Bases de datos han evolucionado, en principio corran en un computador grande accedido por terminales tontas, despus el software de bases de datos llego a ser ms sofisticado y dividi la funcin de bases de datos en dos componentes: el cliente (frontend) y el servidor (backend)

Eventualmente los proveedores de DBMS han movido los componentes del cliente ha cia las microcomputadoras y LANS

Diferencias con los servidores de archivos Fileserver, son responsables de almacenamiento y no del procesamiento de los archivos de datos; una base de datos relacional tiene la funcionalidad y flexibilidad para trabajar con sistemas de computadoras en red.

Ventajas de la arquitectura cliente/servidor

El modelo cliente/servidor se recomienda, en particular, para redes que requieran un alto grado de fiabilidad. Las principales ventajas son:

Independencia de localizacin, la localizacin de la aplicacin cliente es independiente de la localizacin de datos. Transparencia en la localizacin, Los usuarios pueden acceder a las bases de datos sin tener conocimiento acerca de su localizacin recursos centralizados: debido a que el servidor es el centro de la red, puede administrar los recursos que son comunes a todos los usuarios, por ejemplo: una base de datos centralizada se utilizara para evitar problemas provocados por datos contradictorios y redundantes. seguridad mejorada: ya que la cantidad de puntos de entrada que permite el acceso a los datos no es importante. administracin al nivel del servidor: ya que los clientes no juegan un papel importante en este modelo, requieren menos administracin. red escalable: gracias a esta arquitectura, es posible quitar o agregar clientes sin afectar el funcionamiento de la red y sin la necesidad de realizar mayores modificaciones.

Desventajas del modelo cliente/servidor

La arquitectura cliente/servidor tambin tiene las siguientes desventajas:

costo elevado: debido a la complejidad tcnica del servidor. un eslabn dbil: el servidor es el nico eslabn dbil en la red de cliente/servidor, debido a que toda la red est construida en torno a l.

Afortunadamente, el servidor es altamente tolerante a los fallos (principalmente gracias al sistema RAID).

Funcionamiento del sistema cliente/servidor

Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama:

El cliente enva una solicitud al servidor mediante su direccin IP y el puerto, que est reservado para un servicio en particular que se ejecuta en el servidor. El servidor recibe la solicitud y responde con la direccin IP del equipo cliente y su puerto.

2. Poder consultar y cargar

1.3. El programador de aplicaciones

Los programadores de aplicaciones informticas desarrollan, crean y modifican aplicaciones informticas de software generales o programas de utilidad especializada; analizan las necesidades del usuario y desarrollan soluciones de software, disean o personalizan software para el uso del cliente con el objetivo de optimizar la eficiencia operativa; pueden analizar y disear las bases de datos dentro de un rea de aplicacin, trabajando individualmente o coordinando el desarrollo de la base de datos como parte de un equipo.

1.4. El Administrador de Bases de datos (DBA)

La informacin es uno los activos ms valiosos de la empresa, es indispensable contar con una persona -el administrador de datos- que conozca la informacin, y las necesidades de la empresa en este aspecto, en un nivel gerencial superior. As la labor del administrador de datos es decidir en primer trmino cules datos deben almacenarse en la base de datos, y establecer polticas para mantener y manejar los datos uan vez almacenados. El administrador de datos es por lo general, un gerente, no un tcnico. El tcnico responsable de poner en prctica las decisiones del administrador de datos es el administrador de bases de datos(DBA, database administrator). El alcance de la actividad de la Administracin de Datos es la organizacin completa (empresa, institucin u otro organismo), mientras que el alcance de la Administracin de Bases de Datos queda restringido a una Base de Datos en particular y a los sistemas que los procesan. La Administracin de la Base de Datos opera dentro de un marco proporcionado por la Administracin de Datos facilitndose de esta manera el desarrollo y el uso de una Base de Datos y sus aplicaciones. Las siglas DBA suelen utilizarse para designar tanto la funcin Administracin de Base de Datos como al titulo del puesto administrador de Base de Datos. En los distintos niveles y aplicaciones de Base de Datos existe la funcin DBA, aunque varia en complejidad. Esta es ms sencilla cuando se trata de una Base de Datos Personal que cuando se refiere a una Base de Datos de grupos de trabajo, y esta a su vez es ms sencilla que en una Base de Datos Organizacional. En una Base de Datos Personal comnmente el mismo usuario es el Administrador de la Base de Datos; las Bases de Datos de grupos de trabajo requieren de una o dos personas que normalmente no se dedican a esta funcin de tiempo completo puesto que tienen otras responsabilidades dentro o fuera de la organizacin. En las Bases de Datos Organizacionales, que comnmente permiten el acceso a decenas e incluso centenas de usuarios, se requiere de un administrador de Base de Datos de tiempo completo; lo anterior debido al alto volumen de procesos que deben desarrollarse, controlarse y supervisarse. Un Administrador de Base de Datos de tiempo completo normalmente tiene aptitudes tcnicas para el manejo del sistema en cuestin a dems, son cualidades deseables nociones de administracin, manejo de personal e incluso un cierto grado de diplomacia. La caracterstica ms importante que debe poseer es un conocimiento profundo de las polticas y normas de la empresa as como el criterio de la empresa para aplicarlas en un momento dado. Funciones del DBA As, el DBA, a diferencia del administrador de datos, es un profesional en procesamiento de datos. La tarea del DBA es crear la base de datos en s y poner en vigor los controles tcnicos necesarios para apoyar las polticas dictadas por el administrador de datos. El DBA se encarga tambin de garantizar el funcionamiento adecuado del sistema y de proporcionar otros servicios de ndole tcnica relacionados.

El DBA cuenta por lo regular con un grupo de programadores de sistemas y otros asistentes tcnicos.

La responsabilidad general del DBA es facilitar el desarrollo y el uso de la Base de Datos dentro de las guas de accin definidas por la administracin de los datos. El DBA es responsable primordialmente de:

o o o o o o

Administrar la estructura de la Base de Datos Administrar la actividad de los datos Administrar el Sistema Manejador de Base de Datos Establecer el Diccionario de Datos Asegurar la confiabilidad de la Base de Datos Confirmar la seguridad de la Base de Datos

Funciones del Administrador de Bases de Datos (DATE)

Definir el esquema conceptual: es tarea del administrador de datos decidir con exactitud cual es la informacin que debe mantenerse en la base de datos, es decir, identificar las entidades que interesan a la empresa y la informacin que debe registrarse acerca de esas entidades. Este proceso por lo general se denomina diseo lgico a veces conceptual- de bases de datos. Cuando el administrador de datos decide el contenido de la base de datos en un nivel abstracto, el DBA crea a continuacin el esquema conceptual correspondiente, empleando el DDL conceptual. El DBMS utilizar la versin objeto (compilada) de ese esquema para responder a las solicitudes de acceso. La versin fuente sin compilar servir como documento de referencia para los usuarios del sistema. Definir el esquema interno: el DBA debe decidir tambin como se representar la informacin en la base de datos almacenada. A este proceso suele llamrsele diseo fsico de la base de datos. Una vez hecho esto el DBA deber crear la definicin de estructura de almacenamiento correspondiente (es decir el esquema interno) valindose del DDL interno. Adems deber definir la correspondencia pertinente entre los esquemas interno y conceptual. En la prctica, ya sea el DDL conceptual o bien el DDL interno incluirn seguramente los medios para definir dicha correspondencia, pero las dos funciones (crear el esquema, definir la correspondencia) debern poder separarse con nitidez. Al igual que el esquema conceptual, el esquema interno y la correspondencia asociada existirn tanto en la versin fuente como en la versin objeto. Vincularse con los usuarios: el DBA debe encargarse de la comunicacin con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir - o ayudar a los usuarios a escribir- los esquemas externos necesarios, empleando el DDL externo aplicable. Adems, ser preciso definir la correspondencia entre cualquier esquema externo y el esquema conceptual. En la prctica, el DDL externo incluir con toda probabilidad los medios para especificar dicha correspondencia, pero en este caso tambin el esquema y la correspondencia debern poder separarse con claridad. Cada esquema externo y la correspondencia asociada existirn en ambas versiones fuentes y objeto. Otros aspectos de la funcin de enlace con los usuarios incluyen las consultas

sobre diseo de aplicaciones, la impetracin de instruccin tcnica, la ayuda en la localizacin y resolucin de problemas, y otros servicios profesionales similares relacionados con el sistema.

Definir las verificaciones de seguridad e integridad: las verificaciones de seguridad y de integridad pueden considerarse parte del esquema conceptual. El DDL conceptual incluir los medios para especificar dichas verificaciones. Definir procedimientos de respaldo y recuperacin: cuando una empresa se decide a utilizar un sistema de base de datos, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra dao cualquier porcin de la base de datos por causa de un error humano, digamos, o una falla en el equipo o en el sistema que lo apoya resulta esencial poder reparar los datos implicados con un mnimo de retraso y afectando lo menos posible el resto del sistema. En teora, por ejemplo la disponibilidad de los datos no daados no debera verse afectada. El DBA debe definir y poner en practica un plan de recuperacin adecuado que incluya, por ejemplo una descarga o "vaciado" peridico de la base de datos en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a partir de vaciado ms reciente cuando sea necesario. Supervisar el desempeo y responder a cambios en los requerimientos: es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeo que sea "mejor para la empresa", y realizar los ajustes apropiados cuando cambien los requerimientos.

Administracin del DBMS A dems de administrar la actividad de datos y la estructura de la BD, el DBA debe administrar el DBMS mismo. Deber compilar y analizar estadsticas relativas al rendimiento del sistema e identificar reas potenciales del problema. Dado que la BD esta sirviendo a muchos grupos de usuarios, el DBA requiere investigar todas las quejas sobre el tiempo de respuesta del sistema, la precisin de los datos y la facilidad de uso. Si se requieren cambios el DBA deber planearlos y ponerlos en practica.

El DBA deber vigilar peridica y continuamente las actividades de los usuarios en la BD. Los productos DBMS incluyen tecnologas que renen y publican estadsticas. Estos informes pudieran indicar cuales fueron los usuarios activos, que archivos y que elementos de datos han sido utilizados, e incluso el mtodo de acceso que se ha aplicado. Pueden capturarse y reportarse las tasas de error y los tipos de errores. El DBA analizar estos datos para determinar si se necesita una modificacin en el diseo de la BD para manejar su rendimiento o para facilitar las tareas de los usuarios; de ser as, el DBA la llevar a cabo. El DBA deber analizar las estadsticas de tiempo de ejecucin sobre la actividad de la BD y su rendimiento. Cuando se identifique un problema de rendimiento, ya sea mediante una queja o un informe, el DBA deber determinar si resulta apropiada una modificacin a la estructura de la BD o al sistema. Casos como la adicin de nuevas claves o su eliminacin, nuevas relaciones entre los datos y otras situaciones tpicas debern ser analizadas para determinar el tipo de modificacin procedente.

Cuando el fabricante del DBMS en uso anuncie una nueva versin del producto, debe realizarse un anlisis de las caractersticas que esta incorpora e insopesarlas contra las necesidades de la comunidad de usuarios. Si se decide la adquisicin del producto, los usuarios deben ser notificados y capacitados en su uso. El DBA deber administrar y controlar la migracin tanto de las estructuras, como de los datos y las aplicaciones. El software de soporte y otras caractersticas de hardware pueden implicar tambin modificaciones de las que el DBA es responsable ocasionalmente, estas modificaciones traen como consecuencia cambios en la configuracin o en algunos parmetros de operacin del DBMS. Las opciones del DBMS son ajustadas al principio, es decir, en la puesta en marcha del sistema; en este momento se conoce muy poca informacin sobre las caractersticas de funcionamiento y respuesta que proporcionar a los grupos de usuarios. El anlisis de la experiencia operacional y su rendimiento en un periodo determinado de tiempo pudieran revelar que se requiere un campo. Si el rendimiento parece aceptable, el DBA puede considerar a un modificar algunas opciones y observar su efecto sobre el sistema, esto en bsqueda de la optimizacin o afinacin del mismo. 1.5. Diseadores de Bases de Datos (DBD) El diseador de bases de datos, es la persona que se encarga de identificar los datos que se almacenarn en la base de datos y elegir las estructuras apropiadas para la misma. Esta tarea suele realizarse antes de que se implemente y se llene de datos la base de datos, aunque muchas veces un diseador debe trabajar sobre la misma cuando ya est en funcionamiento. El o los diseadores de bases de datos se encargan de determinar los requerimientos de los usuarios que usarn la base de datos. A partir de estos requerimientos, disearn y crearn la base de datos.

En definitiva, el objetivo fundamental de los diseadores de bases de datos es disear la base de datos. 1.6. Sistemas Manejadores de Bases de Datos (DBMS). Rpidamente surgi la necesidad de contar con un sistema de administracin para controlar tanto los datos como los usuarios. La administracin de bases de datos se realiza con un sistema llamado DBMS (Database management system [Sistema de administracin de bases de datos]). El DBMS es un conjunto de servicios (aplicaciones de software) para administrar bases de datos, que permite:

un fcil acceso a los datos el acceso a la informacin por parte de mltiples usuarios la manipulacin de los datos encontrados en la base de datos (insertar, eliminar, editar)

El DBMS puede dividirse en tres subsistemas:

El sistema de administracin de archivos: para almacenar informacin en un medio fsico El DBMS interno: para ubicar la informacin en orden El DBMS externo: representa la interfaz del usuario

LOS DBMS MAS POPULARES

Principales Diferencias entre DBMS

6.2.2.1 Diferencias
Costo Gratuitos: MySQL, PostgreSQL, mSQL, Interbase Comerciales: Tcnicas Sub-selects Select into table Transactions UDF (user defined functions)

DB2, Sybase, Informix, Oracle Otros de dominio pblico: http://www.faqs.org/faqs/databases/freedatabases/

Foreign keys Views Tipos de Datos Manejo de memoria (Virtual Memory, Shared Memory) Manejo de disco (Archivos, Chunks)

6.2.2.3 Escogiendo la combinacin perfecta

Consideraciones al elegir un DBMS

Nmero de usuarios Nmero de transacciones Cantidad de datos para almacenar Consistencia en la informacin Presupuesto Experiencia propia o externa*

*SQL Server, Informix, Oracle SQL server is OK for very small installations. Do not try to run a major organization on this product. If horsepower (CPU number crunching for example) is required, move on to the real relation databases. Oracle is popular, expensive, global in its reach, and can do most any thing you need, (for a small fee). It tends to be more labour intensive then INFORMIX, and from my experience crashes far too often for my taste. You will hardly ever find an Oracle DBA alone. Be careful, because Oracle has the best marketing going right now, not necessarily the best product. Sort of like MS. Informix is fast, scalable ,affordable,stable if you have good code and does not require a herd of DBA's to keep the database operational. Set it up on good hardware and leave it alone. Case in point: Walmart runs every store and their Corp offices on INFORMIX databases. There are several thousand servers involved, all managed by less then 10 fulltime DBA's. Take a look at the number of DBA's in an average Oracle shop and please note they are all very busy, all the time. Best thing to do is get some loaner boxes and try them both. One Consultant/DBA's opinion

6.3 Arquitectura de un manejador de bases de datos (DBMS)

Nota: Las partes utilizadas para ejemplificar la arquitectura se refieren a Oracle

Una base de datos en ejecucin consta de 3 cosas:

Archivos o Control (ctl): almacenan informacin acerca de la estructura de archivos de la base. o Rollback (rbs): cuando se modifica el valor de alguna tupla en una transaccin, los valores nuevos y anteriores se almacenan en un archivo, de modo que si ocurre algn error, se puede regresar (rollback) a un estado anterior. o Redo (rdo): bitcora de toda transaccin, en muchos dbms incluye todo tipo de consulta incluyendo aquellas que no modifican los datos. o Datos (dbf): el tipo ms comn, almacena la informacin que es accesada en la base de datos. o Indices (dbf) (dbi): archivos hermanos de los datos para acceso rpido. o Temp (tmp): localidades en disco dedicadas a operaciones de ordenamiento o alguna actividad particular que requiera espacio temporal adicional. Memoria o Shared Global Area (SGA): es el rea ms grande de memoria y quizs el ms importante Shared Pool: es una cach que mejora el rendimiento ya que almacena parte del diccionario de datos y el parsing de algunas consultas en SQL Redo Log Buffer: contiene un registro de todas las transacciones dentro de la base, las cuales se almacenan en el respectivo archivo de Redo y en caso de siniestro se vuelven a ejecutar aquellos cambios que an no se hayan reflejado en el archivo de datos (commit). Large Pool: espacio adicional, generalmente usado en casos de multithreading y esclavos de I/O. Java Pool: usado principalmente para almacenar objetos Java o Program Global Area (PGA): informacin del estado de cursores/apuntadores o User Global Area(UGA): informacin de sesin, espacio de stack Procesos o Threading o System Monitor: despierta peridicamente y realiza algunas actividades entre las que se encuentran la recuperacin de errores, recuperacin de espacio libre en tablespaces y en segmentos temporales. o Process Monitor: limpia aquellos procesos que el usuario termina de manera anormal, verificando consistencias, liberacin de recursos, bloqueos. o Database Writer: escribe bloques de datos modificados del buffer al disco, aquellas transacciones que llegan a un estado de commit.

o o

Log Writer: escribe todo lo que se encuentra en el redo log buffer hacia el redo file Checkpoint: sincroniza todo lo que se tenga en memoria, con sus correspondientes archivos en disco

6.5 Administracin de un DBMS real

6.5.1 MySQL

MySQL (pronunciado mai-es-quiu-el), es una manejador de bases de datos relacional bastante robusto, de cdigo abierto bajo la licencia GPL el cual se ha convertido en el ms popular hoy en da. Su origen se debi a la bsqueda por parte de los fundadores de crear un manejador de bases de datos que fuera "rpido", todava ms rapido que mSQL. As surgi MySQL, primero como un producto de la empresa y despes como software de dominio pblico. El nombre de My se debe probablemente a que la hija del cofundador Monty Widenius reciba ese sobrenombre, aunque a ciencia cierta nunca se ha revelado el origen. Por otro lado en el ao 2002 MySQL tuvo un logo ms original que el simple nombre, incluyendo un delfn, el cual a travs de una encuesta en la pgina web recibi su nombre: "Sakila", de origen africano.
6.5.1.1 Por qu usar MySQL ?

Es importante resaltar que no se trata de una herramienta de juguete o aprendizaje, MySQL es un manejador que puede competir competir con sus famosas contrapartes comerciales: Oracle, DB2, Informix, Sybase. Bsicamente los motivos por los cuales se podra optar por usar MySQL en lugar de otro manejador seran:

Es gratis Es extensible Es robusto Es rpido No requiere de una gran nmero de recursos para funcionar (obviamente para aplicaciones a gran escala es mejor contar con una buena infraestructura) Es fcil de administrar

6.5.1.2 Instalacin Bsica

MySQL posee varias versiones 3, 4 y 5 siendo la 3 la ms estable y la 5 la ms experimental Los cambios en la versin 4 permiten tener mayor funcionalidad, teniendo por ejemplo queries anidados y bsquedas a texto completo.

MySQL posee 4 tipos de tablas (y en consecuencia de ndices): Index MyISAM

Heap

Versin Standard, Max

Standard, Max

BerkeleyDB Max Innodb Max

Tabla 3.1 Indexamiento en MySQL

CAPITULO II

2. INGENIERIA DE LAS BASES DE DATOS

Arquitectura de los sistemas de bases de datos

Hay tres caractersticas importantes inherentes a los sistemas de bases de datos: la separacin entre los programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los usuarios y el uso de un catlogo para almacenar el esquema de la base de datos. En 1975, el comit ANSI-SPARC (American National Standard Institute Standards Planning and Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy til a la hora de conseguir estas tres caractersticas.

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicacin de la base de datos fsica. En esta arquitectura, el esquema de una base de datos se define en tres niveles de abstraccin distintos:
1. En el nivel interno se describe la estructura fsica de la base de datos mediante un esquema interno. Este esquema se especifica mediante un modelo fsico y describe todos los detalles para el almacenamiento de la base de datos, as como los mtodos de acceso. 2. En el nivel conceptual se describe la estructura de toda la base de datos para una comunidad de usuarios (todos los de una empresa u organizacin), mediante un esquema conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se concentra en describir entidades, atributos, relaciones, operaciones de los usuarios y restricciones. En este nivel se puede utilizar un modelo conceptual o un modelo lgico para especificar el esquema. 3. En el nivel externo se describen varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinado y oculta a ese grupo el resto de la base de datos. En este nivel se puede utilizar un modelo conceptual o un modelo lgico para especificar los esquemas.

La mayora de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel fsico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario, los esquemas externos se especifican con el mismo modelo de datos que describe la informacin a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los niveles conceptual y externo. Hay que destacar que los tres esquemas no son ms que descripciones de los mismos datos pero con distintos niveles de abstraccin. Los nicos datos que existen realmente estn a nivel fsico, almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar cualquier peticin expresada en trminos de un esquema externo a una peticin expresada en trminos del esquema conceptual, y luego, a una peticin en el esquema interno, que se procesar sobre la base de datos almacenada. Si la peticin es de una obtencin (consulta) de datos, ser preciso modificar el formato de la informacin extrada de la base de datos almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o transformacin. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas. La arquitectura de tres niveles es til para explicar el concepto de independencia de datos que podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior. Se pueden definir dos tipos de independencia de datos:

La independencia lgica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicacin. Se puede modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran a ella no debern verse afectados.

La independencia fsica es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros fsicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualizacin de datos. Dado que la independencia fsica se refiere slo a la separacin entre las aplicaciones y las estructuras fsicas de almacenamiento, es ms fcil de conseguir que la independencia lgica.

En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catlogo o diccionario, de modo que incluya informacin sobre cmo establecer la correspondencia entre las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar estas correspondencias haciendo referencia a la informacin de correspondencia que se encuentra en el catlogo. La independencia de datos se consigue porque al modificarse el esquema en algn nivel, el esquema del nivel inmediato superior permanece sin cambios, slo se modifica la correspondencia entre los dos niveles. No es preciso modificar los programas de aplicacin que hacen referencia al esquema del nivel superior. Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecucin de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta arquitectura completa. 2.1. Planificacin de soluciones al manejo de la informacin Modelo de Creacin de aplicaciones software Waterfall?

La fase de planificacin, involucra el desarrollo de un cronograma de actividades por cada una de las etapas principales del ciclo de vida de desarrollo de la solucin, se puede utilizar un software para automatizar la planificacin.

DESCRIPCION DE PROCESOS Un proceso puede ser definido como un conjunto de actividades enlazadas entre s que, partiendo de uno o ms inputs (entradas) los transforma, generando un output (resultado). Las actividades de cualquier organizacin pueden ser concebidas como integrantes de un proceso determinado. Desde este punto de vista, una organizacin cualquiera puede ser considerada como un sistema de procesos, ms o menos relacionados entre s, en los que buena parte de los inputs sern generados por proveedores internos, y cuyos resultados irn frecuentemente dirigidos hacia clientes tambin internos. Documentacin de procesos. Es un mtodo estructurado que utiliza un preciso manual para comprender el contexto y los detalles de los procesos clave. Siempre que un proceso vaya a ser rediseado o mejorado, su documentacin es esencial como punto de partida. Lo habitual en las organizaciones es que los procesos no estn identificados y, por consiguiente, no se documenten ni se delimiten. Los procesos fluyen a travs de distintos departamentos y puestos de la organizacin funcional, que no suele percibirlos en su totalidad y como conjuntos diferenciados y, en muchos casos, interrelacionados. 4. ELEMENTOS Los elementos que forman parte del anlisis de la documentacin de procesos son: Identificacin y documentacin. Lo habitual en las organizaciones es que los procesos no estn identificados y, por consiguiente, no se documenten ni se delimiten. Los procesos fluyen a travs de distintos departamentos y puestos de la organizacin funcional, que no suele percibirlos en su totalidad y como conjuntos diferenciados y, en muchos casos, interrelacionados.

Definicin de objetivos. La descripcin y definicin operativa de los objetivos es una actividad propia de la documentacin. Esto permitir orientar los procesos hacia la Calidad, es decir hacia la satisfaccin de necesidades y expectativas. Identificacin de responsables de los procesos. Al estar, por lo comn, distribuidas las actividades de un proceso entre diferentes reas funcionales, lo habitual es que nadie se responsabilice del mismo, ni de sus resultados finales. El encargado del proceso puede delegar este liderazgo en un equipo o en otra persona que tenga un conocimiento importante sobre el proceso, pero es vital que, este primero est informado de las acciones y decisiones que afectan al proceso, ya que la responsabilidad no se delega por lo tanto debe tener control sobre el mismo desde el principio hasta el final. Reduccin de etapas y tiempos. Generalmente existe una sustancial diferencia entre los tiempos de proceso y de ciclo. La documentacin de procesos permite conocer los pasos que incluye un proceso, esto genera una reduccin de las etapas, de manera que el tiempo total del proceso disminuya. Simplificacin. Con esta se intenta reducir el nmero de personas y departamentos implicados en un proceso o ciclo. Reduccin y eliminacin de actividades sin valor aadido. Es frecuente encontrar que buena parte de las actividades de un proceso no aportan nada al resultado final. La documentacin de procesos cuestiona estas actividades dejando perdurar las estrictamente necesarias, como aquellas de evaluacin imprescindibles para controlar el proceso o las que deban realizarse por cumplimiento de la legalidad y normatividad vigente. Reduccin de burocracia Ampliacin de las funciones y responsabilidades del personal. Con frecuencia es necesario dotar de ms funciones y de mayor responsabilidad al personal que interviene en el proceso, como medio para reducir etapas y acortar tiempos de ciclo, siempre procurando actuar cuidadosamente para no llegar a generar conflictos. Inclusin de actividades de valor aadido. Que incrementen la satisfaccin del cliente. 5. CARACTERISTICAS Los beneficios que resultan de una documentacin de procesos son: Incrementar la eficacia. Reducir costos. Mejorar la calidad. Acortar los tiempos y reducir, as, los ciclos de entrega del servicio.

Estos objetivos pueden llegar a alcanzarse conjuntamente dada la relacin existente entre ellos. Por ejemplo, si se acortan los tiempos es probable que mejore la calidad. 6. PROCESO Los pasos que deben llevarse a cabo para la realizacin de la documentacin de procesos y la creacin de un manual son: 1) El primer paso que implica una documentacin de procesos es la seleccin del proceso a documentar 2) Posteriormente, la recoleccin de la informacin relacionada con el proceso 3) Anlisis de la informacin 4) El cuarto paso es el desarrollo de un manual de documentacin de procesos, que implica la creacin de un modelo o formato de procesos. Modelado de Procesos Frecuentemente los sistemas (conjuntos de procesos y subprocesos integrados en una organizacin) son difciles de comprender, amplios, complejos y confusos; con mltiples puntos de contacto entre s y con un buen nmero de reas funcionales, departamentos y puestos implicados. Un modelo puede dar la oportunidad de organizar y documentar la informacin sobre un sistema. Qu es un modelo? Un modelo es una representacin de una realidad compleja. Modelar es desarrollar una descripcin lo ms exacta posible de un sistema y de las actividades llevadas a cabo en l.. De acuerdo a lo anterior; una vez seleccionado y analizado el proceso a documentar, el modelo que se utiliza para desarrollarlo se conforma de dos pasos: 1. Identificacin del Proceso 1.1 Sealar a que departamento pertenece el proceso 1.2 Asignar una clave para diferenciarlo de otros existentes dentro de la organizacin 1.3 Asignar un nmero de emisin de acuerdo al orden en que fue analizado y documentado, as como para diferenciarlo de otros existentes dentro del mismo departamento o rea 1.4 Sealar a l o los responsables de llevarlo a cabo 2. Desglose del contenido que incluye el manual del proceso 2.1 Justificacin de la existencia de ese proceso dentro de la organizacin una determinada rea departamento 2.2 Objetivo de la elaboracin del manual de ese proceso

2.3 Definicin de los conceptos principales que lo integran 2.4 Elementos que forman parte de l 2.5 Caractersticas principales del proceso 2.6 Descripcin de los pasos actividades que lo integran. Esta descripcin se desarrollar despus de haber recolectado y posteriormente analizado la informacin, de modo que sea un extracto del proceso que contenga los pasos netamente necesarios para llevarlo a cabo; as como la reduccin de etapas y tiempos, reduccin y eliminacin de actividades sin valor aadido, ampliacin de las funciones y responsabilidades del personal y la inclusin de actividades de valor aadido que promueven la Calidad en los procesos 2.7 Observaciones y recomendaciones 2.8 Diagrama de flujo. Cuando un proceso es modelado, con ayuda de una representacin grfica (diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, as como identificar los subprocesos existentes Diagramar es establecer una representacin visual de los procesos y subprocesos, lo que permite obtener una informacin preliminar sobre la amplitud de los mismos, sus tiempos y los de sus actividades. La representacin grfica facilita el anlisis, tambin hace posible la distincin entre aquellas actividades que aportan valor aadido de las que no lo hacen, es decir que no proveen directamente nada al cliente del proceso o al resultado deseado. En este ltimo sentido cabe hacer una precisin, ya que no todas las actividades que no proveen valor aadido han de ser innecesarias; stas pueden ser actividades de apoyo y ser requeridas para hacer ms eficaces las funciones de direccin y control, por razones de seguridad o por motivos normativos y de legislacin. 2.9 Anexos que complementan la informacin 2.10 Bibliografa ( si lo requiere) Cabe hacer mencin de que no todos los procesos deben necesariamente de incluir este seguimiento de pasos en el contenido del manual, ya que cada proceso tiene caractersticas diferentes segn el rea funcional a la que corresponde.

Ejemplos Descripcin del proceso de matriculacin (el caso de uso)

Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman grupos abiertos, es decir, grupos en los que cualquiera se puede matricular (en oposicin a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente). Cuando llegamos a la academia, se nos ofrece un folleto o catlogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que ms nos conviene, el horario al que vamos a asistir, y con esta informacin nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a travs de nuestra cuenta bancaria. En la academia, llegado este punto, introducen en su sistema de informacin nuestros datos y nos imprimen el contrato de prestacin de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequea cantidad del primer recibo. En el siguiente da de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo nos da la bienvenida, y empezamos a estudiar.

El modelo de datos
A partir de aqu har una descripcin de la estructura de tablas y columnas para almacenar la informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos.

Generalidades
Hay algunas cosas bsicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas as). Por ejemplo:
1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen as un identificador interno, mantenido por el sistema. As, las claves ajenas son ms fciles de mantener. 2. En general, nosotros no solemos poner campos requeridos preferimos hacer la gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estbamos completamente seguros que eran requeridos y hemos tenido que quitar la marca.

3. No se duplica informacin. Es decir, una de las reglas bsica es que la misma informacin no puede estar en dos sitios, salvo 4. En muchos casos, creamos campos calculados, que permiten acceder de forma rpida a informacin por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales como hacer este clculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automticamente (en nuestro caso, a travs de Triggers de la base de datos). La informacin est duplicada en dos sitios, s, pero por motivos de rendimiento (y siempre est sincronizada). 5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dnde vas a tener que acceder.

Descripcin de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Segn el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos):

Cursos: almacena la oferta formativa del centro. Representa el catlogo o folleto que te dan al llegar al centro. Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto tambin). Trimestral, mensual, anual, etc. Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante ms complejo que el que voy a describir aqu en un artculo posterior lo describir en detalle. Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que no. Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para pagar (contado, domicilacin bancaria, etc), incluyendo las cuentas bancarias del cliente. Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples alumnos. Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago, etc. De forma fsica, se refleja en el contrato que te dan para firmar. Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro. Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestin de recibos y pagos que hacemos en realidad es ms compleja de lo que voy a describir aqu. En otro artculo har una descripcin ms completa. Alumnos en grupos: refleja los alumnos que estn asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa informacin histrica, as que necesitamos una tabla para gestionarlo.

En la Empresa "Educando S.A." se lleva control de sus Bienes y Servicios. El inters primario es poder hacer que los Bienes se manejen de forma rpida y con el menor grado de error. Para esto quien maneja la seccin de "Bienes y Suministros" plantea las siguientes condiciones del negocio para la construccin de una base de datos.

Sistema de ventas Le contratan para hacer una BD que permita apoyar la gestin de un sistema de ventas. La empresa necesita llevar un control de proveedores, clientes, productos y ventas. Un proveedor tiene un RUT, nombre, direccin, telfono y pgina web. Un cliente tambin tiene RUT, nombre, direccin, pero puede tener varios telfonos de contacto. La direccin se entiende por calle, nmero, comuna y ciudad. Un producto tiene un id nico, nombre, precio actual, stock y nombre del proveedor. Adems se organiza en categoras, y cada producto va slo en una categora. Una categora tiene id, nombre y descripcin. Por razones de contabilidad, se debe registrar la informacin de cada venta con un id, fecha, cliente, descuento y monto final. Adems se debe guardar el precio al momento de la venta, la cantidad vendida y el monto total por el producto.

2.2. Modelo Entidad-Relacin (Herramienta CASE) Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigacin Preliminar, Anlisis, Diseo, Implementacin e Instalacin. CASE se define tambin como:

Conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases.

La sigla genrica para una serie de programas y una filosofa de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas. Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa con un potencial efecto profundo en la organizacin. Se puede ver al CASE como la unin de las herramientas automticas de software y las metodologas de desarrollo de software formales.

La realizacin de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinacin de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. La mejor razn para la creacin de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compaas pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. Tambin permite a las compaas competir ms efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales. En un mercado altamente competitivo, esto puede hacer la diferencia entre el xito y el fracaso. Las herramientas CASE tambin permiten a los analistas tener ms tiempo para el anlisis y diseo y minimizar el tiempo para codificar y probar. La introduccin de CASE integradas est comenzando a tener un impacto significativo en los negocios y sistemas de informacin de las organizaciones. Con un CASE integrado, las organizaciones pueden desarrollar rpidamente sistemas de mejor calidad para soportar procesos crticos del negocio y asistir en el desarrollo y promocin intensiva de la informacin de productos y servicios. Estas herramientas pueden proveer muchos beneficios en todas las etapas del proceso de desarrollo de software, algunas de ellas son: Verificar el uso de todos los elementos en el sistema diseado. Automatizar el dibujo de diagramas. Ayudar en la documentacin del sistema. Ayudar en la creacin de relaciones en la Base de Datos. Generar estructuras de cdigo. La principal ventaja de la utilizacin de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo trmino, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organizacin y una metodologa de trabajo, adems de la propia herramienta. La mejora de calidad se consigue reduciendo sustancialmente muchos de los problemas de anlisis y diseo, inherentes a los proyectos de mediano y gran tamao (lgica del diseo, coherencia, consolidacin, etc.). La mejora de productividad se consigue a travs de la automatizacin de determinadas tareas, como la generacin de cdigo y la reutilizacin de objetos o mdulos.

Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje, y por lo tanto un producto, que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statement Analyzer). Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software. Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software. 2. Aumentar la calidad del software. 3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. 4. Mejorar la planificacin de un proyecto 5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. 6. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto. 7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin 8. Gestin global en todas las fases de desarrollo de software con una misma herramienta. 9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.

Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros: 1. 2. 3. 4. Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.

La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.

Por funcionalidad podramos diferenciar algunas como:

Herramientas de generacin semiautomtica de cdigo. Editores UML. Herramientas de Refactorizacin de cdigo. Herramientas de mantenimiento como los sistemas de control de versiones

Visita el enlace y conoce ms acerca de estas herramientas

www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf http://es.scribd.com/doc/3062020/Capitulo-I-HERRAMIENTAS-CASE

Ejemplos de Herramientas Case ms utilizadas. ERwin: PLATINUM ERwin es una herramienta para el diseo de base de datos, que Brinda productividad en su diseo, generacin, y mantenimiento de aplicaciones. Desde un modelo lgico de los requerimientos de informacin, hasta el modelo fsico perfeccionado para las caractersticas especficas de la base de datos diseada, adems ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseo de la base de datos. Genera automticamente las tablas y miles de lneas de stored procedure y triggers para los principales tipos de base de datos. ERwin hace fcil el diseo de una base de datos. Los diseadores de bases de datos slo apuntan y pulsan un botn para crear un grfico del modelo E-R (Entidad _ relacin) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lgico, mostrando todas las entidades, atributos, relaciones, y llaves importantes. La migracin automtica garantiza la integridad referencial de la base de datos. ERwin establece una conexin entre una base de datos diseada y una base de datos, permitiendo transferencia entre ambas y la aplicacin de ingeniera reversa. Usando esta conexin, ERwin genera automticamente tablas, vistas, ndices, reglas de integridad referencial (llaves primarias, llaves forneas), valores por defecto y restricciones de campos y dominios. ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar mltiples bases de datos, o convertir una aplicacin de una plataforma de base de datos a otra. EasyCASE EasyCASE Profesional - el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniera de Base de Datos- es un producto para la generacin de esquemas de base de datos e ingeniera reversa - trabaja para proveer una solucin comprensible para el diseo, consistencia y documentacin del sistema en conjunto. Esta herramienta permite automatizar las fases de anlisis y diseo dentro del desarrollo de una aplicacin, para poder crear las aplicaciones eficazmente desde el procesamiento de transacciones a la aplicacin de bases de datos de cliente/servidor, as como sistemas de tiempo real. EasyCASE Profesional, una herramienta multi-usuario, es ideal para aquellos que necesitan compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder proyectos localizados en el servidor de la red concurrentemente. Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al registro, al archivo y al proyecto, y niveles de control de acceso. Oracle Designer:

Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el usuario y automatizar la construccin rpida de aplicaciones cliente/servidor grficas. Integrado con Oracle Developer, Oracle Designer, que provee una solucin para desarrollar sistemas empresariales de segunda generacin.

Todos los datos ingresados por cualquier herramienta de Oracle Designer, en cualquier fase de desarrollo, se guardan en un repositorio central, habilitando el trabajo fcil del equipo y la direccin del proyecto. En el lado del Servidor, Oracle Designer soporta la definicin, generacin y captura de diseo de los siguientes tipos de bases de datos, por conexin de Oracle: System Architect Esta herramienta posee un repositorio nico que integra todas las herramientas, y metodologas usadas. En la elaboracin de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de validaciones, normalizacin, etc. Posee control automtico de diagramas y datos, normalizaciones y balanceamiento entre diagramas "Padre e Hijo", adems de balanceamiento horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Esta herramienta tambin Genera en Windows DDL, definiciones de datos para lenguaje C/C++ y estructuras de datos en Cobol. En esta ultima versin del System Architect es posible a travs de ODBC, la creacin de bases de datos a partir del modelo de entidades, adems Posee esquemas de seguridad e integridad a travs de contraseas que posibilitan el acceso al sistema en diversos niveles, pudindose integrar a la seguridad de la red. MODELAMIENTO LOGICO DE DATOS

ENTIDADES Y RELACIONES El modelo de datos ms extendido es el denominado ENTIDAD/RELACIN (E/R) En el modelo E/R se parte de una situacin real a partir de la cual se definen entidades y relaciones entre dichas entidades:

Entidad.- Objeto del mundo real sobre el que queremos almacenar informacin (Ej: una persona). Las entidades estn compuestas de atributos que son los datos que definen el objeto (para la entidad persona seran DNI, nombre, apellidos, direccin,...). De entre los atributos habr uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estar formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas: Que sea nica. Que se tenga pleno conocimiento de ella.- Por qu en las empresas se asigna a cada cliente un nmero de cliente?. Que sea mnima, ya que ser muy utilizada por el gestor de base de datos. Relacin.- Asociacin entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:

Relaciones 1-1.- Las entidades que intervienen en la relacin se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relacin MATRIMONIO). Relaciones 1-n.- Una ocurrencia de una entidad est asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relacin TRABAJAR-EN). Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relacin, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relacin MATRCULA).

Representacin grfica de Entidades y Relaciones

Para asimilar fcilmente un diseo de datos cuando se emplea el modelo E/R se utilizan los siguientes elementos grficos:

La utilizacin de estos elementos dar como resultado lo que se denomina el esquema entidad-relacin de la base de datos. Los ejemplos que se incluyen en el apartado anterior, grficamente quedaran como sigue:

ATRIBUTOS Y DOMINIOS Los atributos son simplemente caracteristicas de las entidades, estas identifican o describen a una entidad, atributos identificativos son tambin llamados claves, asi como EMPLOYEE-NUMBER, CUSTOMERNUMBER and SSN (social security number). Ejemplos de atributos descriptivos son EMPLOYEE-NAME, CUSTOMER-ADDRESS and PRODUCTDESCRIPTION. En la transformacion de un diseo fisico en lgico, los atributos vienen a ser columnas de la tabla Los dominios son el conjunto de valores que puede tener un atributo, asi por ejemplo el dominio de un atributo sexo ser (Masculino y femenino) LLAVES PRIMARIAS Y FORANEAS Los dos tipos mas importantes de llaves en las bases de datos son PK y FK, proporciona en la mayora de los dbms el concepto de integridad referencial, para un modelo lgico toda entidad debe tener una llave primaria, una llave primaria puede estar compuesta de uno o ms atributos en ese caso son llamdas claves compuestas o concatenadas, algunas tcnicas de diagramacin utilizan el trmino de relaciones de tipo mandatorias. Las dos caractersticas crticas de una clave son: unicidad y no redundancia.

MODELADO CON ERWIN

Definicin de Modelo Representacin grafica de la realidad que son clarificados a travs de texto explicativo. Ejemplo: Una representacin a escala de una casa, Una representacin de un automvil, etc. Definicin de Modelo de Datos Estructuras de datos y reglas de negocio que representan los requerimientos de un sistema. Tipos de Modelo de Datos Los modelos de datos pueden ser: Lgico: Orientado a la empresa, Definiciones y Reglas de Negocio Fsico: Restringido por el DBMS Dimensional: DataWarehousing, Diseo de DataMart Atributo Propiedad de una entidad que almacenara datos Llave Primaria (PK) Un atributo (Llave simple) o conjunto de atributos (Llave compuesta) que identifican nicamente una instancia (fila o registro) de una entidad. En ERwin la llave primaria esta posicionada sobre la lnea en una entidad. Llave Alterna (AK) Un atributo (Llave simple) o conjunto de atributos (Llave compuesta) que identifican nicamente una instancia (fila o registro) de una entidad, pero que NO ES ESCOGIDA como llave primaria. En ERwin, se muestra por el diagrama (AKx,y) donde x representa un numero entero incrementado para cada llave alterna en una entidad; y representa el orden del atributo llave. Entrada Inversa (IE) Se utilizan cuando uno o mas atributos son usados frecuentemente para acceder a una o mas instancias (filas o registros) de las entidades. EN ERwin son mostrados en diagramas (IEx,y) despus de cada atributo de la entrada inversa. donde x representa un numero entero incrementado para cada llave alterna en una entidad; y representa el orden del atributo llave. Relacin Un enlace lgico entre dos entidades que representan una regla de negocio o una restriccin. Llave Fornea (FK) Una llave fornea es una llave primaria de una entidad padre (Fuerte) que es AGREGADA a la entidad hijo (Dbil) a travs de su relacin.

Rol de ERwin en el Modelamiento de Datos ERwin es una herramienta de base de datos que le ayuda a disear, generar y mantener plicaciones de base de datos de calidad y alto rendimiento. Desde un modelo lgico de sus requerimientos de informacin y reglas del negocio que definen su base de datos, hasta un modelo fsico, optimizado por las caractersticas especficas de su base de datos de destino, ERwin le permite visualizar la estructura adecuada, los elementos clave y un diseo optimizado de su base de datos. ERwin genera tablas automticamente y miles de lneas de stored procedures y cdigo trigger para las principales bases de datos. Su tecnologa "complete-compare" permite el desarrollo interactivo, de manera que su modelo est siempre sincronizado con su base de datos. A travs de la integracin con los ambientes de desarrollo lderes en la industria, ERwin tambin acelera la creacin de aplicaciones data-centric. Beneficios de ERwin Asegura consistencia, reuso, e integracin de los datos del proyecto al proporcionar el bosquejo que las IT necesitan para entender, analizar y comunicar la estructura de la base de datos. Mejora la productividad entre los desarrolladores cuando los diseos de la base de datos son divididos, compartidos, y reutilizados. El ambiente grfico facilita la visualizacin de la estructura completa, los elementos claves y el diseo optimizado de la base de datos. Le ahorra tiempo al acelerar la creacin de bases de datos de alta calidad, transaccionales de alto rendimiento y para data warehouse. Mantiene los recursos y mejora la precisin al sincronizar el modelo y la base de datos.

Tipos de Entidades en ERwin En ERwin el modelo lgico puede contener dos tipos de entidades: independiente y dependiente. Una entidad independiente es una entidad que puede identificarse sin determinar su relacin con otra entidad. Cada entidad tiene llave propia, se representa como una caja con rincones cuadrados. Una entidad dependiente es una entidad que para identificarse requiere de su relacin a otra entidad o entidades. Se representa como una caja con rincones redondeados.

El Editor de Entidades Utilice el editor de entidades para ingresar/editar, definiciones de entidades y sus notas, para explorar definiciones, cambiar el nombre a la entidad o para asignar propiedades definidas por el usuario UPD. Para ello realizar lo siguiente

Explora la herramienta, puedes guiarte del manual http://es.scribd.com/doc/3075477/Manual-de-Usuario-de-Erwin

2.3. Esquema de integridad

Relacin Identificada La llave primaria de la entidad padre es migrada a travs de la RELACION para FORMAR parte de la llave primaria de la entidad hijo. Relacin Obligatoria No-Identificada La llave primaria de la entidad padre es migrada como un atributo no llave (no forma parte de la llave primaria de la entidad hijo) de la entidad hijo. La FK necesariamente tiene que tener un valor real de la PK. Relacin No-Obligatoria No-Identificada La llave primaria de la entidad padre es migrada como un atributo no llave (no forma parte de la llave primaria de la entidad hijo) de la entidad hijo. La opcionalidad en el lado del padre indica que la FK en la entidad hijo puede existir sin la informacin de la PK de la entidad padre. Relacin Muchos a Muchos La llave primaria de la entidad padre no es migrada como llave fornea. Cada frase representa la regla desde la perspectiva Padre a Hijo Hijo a Padre

2.4. Esquema de seguridad y autorizacin 2.5. Interfaces para conexin al DBMS 2.6. Ingeniera inversa a las Bases de Datos CAPITULO III 3. MANIPULACION Y CONTROL DE DATOS CON SQL

Aunque estos apuntes sirven como gua de uso deSQL estndar; la base de datos que utilizamos de referencia es la base de datos Oracle (utilizando la versin gratuita para fines no comerciales Oracle XE 10g, aunque valdran para casi cualquier versin de Oracle). Normalmente se indican las diferencias entre Oracle y SQL estndar, pero todos los ejemplos han sido probados para utilizarse en Oracle. La razn de utilizar Oracle como base de trabajo se debe a su respeto por SQL estndar (hasta cierto punto) y por ser el SGBD de referencia ms importante desde hace ya muchos aos.

formato de las instrucciones en los apuntes

En este manual en muchos apartados se indica sintaxis de comandos. Esta sintaxis sirve para aprender a utilizar el comando, e indica la forma de escribir dicho comando en el programa utilizado para escribir SQL. En el presente manual la sintaxis de los comandos se escribe en prrafos sombreados de verde claro con el reborde en azul grisceo. Ejemplo:

Otras veces se describen cdigos de ejemplo de un comando. Los ejemplos se escriben tambin con fondo verde claro, pero sin el reborde. Ejemplo:

Los ejemplos sirven para escenificar una instruccin concreta, la sintaxis se utiliza para indicar las forma de utilizar un comando. Para indicar la sintaxis de un comando se usan smbolos especiales. Los smbolos que utiliza este libro (de acuerdo con la sintaxis que se utiliza normalmente en cualquier documentacin de este tipo) son: PALABRA Cuando en la sintaxis se utiliza una palabra en negrita, significa que es una palabra que hay que escribir literalmente (aunque sin importar si en maysculas o minsculas). texto El texto que aparece en cursiva sirve para indicar que no hay que escribirle literalmente, sino que se refiere a un tipo de elemento que se puede utilizar en el comando. Ejemplo:
SELECTcolumna FROMtabla;

El texto columna hay que cambiarlo por un nombre concreto de columna (nombre, apellidos,...), al igual que tabla se refiere a un nombre de tabla concreto. [ ] (corchetes). Los corchetes sirven para encerrar texto que no es obligatorio en el comando, es decir para indicar una parte opcional. | (barra vertical). Este smbolo (|), la barra vertical, indica opcin. Las palabras separadas con este signo indican que se debe elegir una de entre todas las palabras. ... (puntos suspensivos) Indica que se puede repetir el texto anterior en el comando continuamente (significara, y as sucesivamente) {} (llaves) Las llaves sirven para indicar opciones mutuamente exclusivas pero obligatorias. Es decir, opciones de las que slo se puede elegir una opcin, pero de las que es obligado elegir una. Ejemplo:
SELECT{ *| columna FROM tabla; | expresin }

El ejemplo anterior indicara que se debe elegir obligatoriamente el asterisco o un nombre de columna o una expresin. Si las llaves del ejemplo fueran corchetes, entonces indicaran que incluso podra no aparecer ninguna opcin.

(3.2
SQL es el lenguaje fundamental de los SGBD relacionales. Se trata de uno de los lenguajes ms utilizados de la historia de la informtica.

SQL pretende ser un lenguaje que simula el funcionamiento del lenguaje normal. De ah que se le considere un lenguaje de cuarta generacin. Consta de palabras especiales y de expresiones. Se trata de un lenguaje que intenta agrupar todas las funciones que se le pueden pedir a una base de datos, por lo que es el lenguaje utilizado tanto por administradores como por programadores o incluso usuarios avanzados. Es un lenguaje de tipo declarativo, se especificaqu es lo que desea realizar, no el cmo queremos realizarlo (elcmo es la pregunta de los lenguajes imperativos, comoC,C++ oJava).

modos de utilizacin
ejecucin directa. SQL interactivo

Las instrucciones SQL se introducen a travs de una herramienta que las traduce inmediatamente a la base de datos, por lo que se ejecutan al instante.
ejecucin incrustada o embebida

Las instrucciones SQL se colocan como parte del cdigo de otro lenguaje anfitrin (C, Java, Pascal, Visual Basic,...). Estas instrucciones estn separadas del resto del cdigo de forma conveniente. Al compilar el cdigo se utiliza un precompilador de la propia base de datos para traducir el SQL.
ejecucin dinmica

Se trata de SQL incrustado en mdulos especiales que pueden ser invocados una y otra vez desde distintas aplicaciones.

historia del lenguaje SQL

El nacimiento del lenguaje SQL data de 1970 cuando E. F. Codd publica su libro:
"Un modelo de datos relacional para grandes bancos de datos compartidos". Ese libro dictara las direcrices de las bases de datos relacionales. Apenas dos aos despusIBM (para quien trabajaba Codd) utiliza las directrices de Codd para crear el Standard English Query Language (Lenguaje Estndar Ingls para Consultas) al que se le llam SEQUEL. Ms adelante se le asignaron las siglasSQL (Standard Query Language, lenguaje estndar de consulta) aunque en ingls se siguen pronunciandosecuel. En espaol se le llamaesecuele.

En 1979 Oracle presenta la primera implementacin comercial del lenguaje. Poco despus se converta en un estndar en el mundo de las bases de datos avalado por los organismosISO yANSI. En el ao 1986 se toma como lenguaje estndar por ANSI de los SGBD relacionales. Un ao despus lo adopta ISO, lo que convierte a SQL en estndar mundial como lenguaje de bases de datos relacionales. En 1989 aparece el estndar ISO (y ANSI) llamadoSQL89 oSQL1. En 1992 aparece la nueva versin estndar de SQL (a da de hoy sigue siendo la ms conocida) llamadaSQL92. En 1999 se aprueba un nuevo SQL estndar que incorpora mejoras que incluyen triggers,

procedimientos, funciones, y otras caractersticas de las bases de datos objeto-relacionales; dicho estndar se conoce como SQL99. El ltimo estndar es el del ao 2003 (SQL2003) que aade secuencias y sobre todo el soporte para XML (actual estndar de documentos).

(3.4) elementos del lenguaje SQL

cdigo SQL El cdigo SQL consta de los siguientes elementos: Comandos. Las distintas instrucciones que se pueden realizar desde SQL SELECT. Se trata del comando que permite realizar consultas sobre los datos de la base de datos. Obtiene datos de la base de datos. A sta parte del lenguaje se la conoce comoDQL (Data Query Language, Lenguaje de consulta de datos); pero es parte del DML del lenguaje. DML, Data Manipulation Language (Lenguaje de manipulacin de datos). Modifica filas (registros) de la base de datos. Lo forman las instrucciones INSERT, UPDATE, MERGE y DELETE. DDL, Data Definition Language(Lenguaje de definicin de datos). Permiten modificar la estructura de las tablas de la base de datos. Lo forman las instruccionesCREATE,ALTER,DROP,RENAME y TRUNCATE.

DCL, Data Control Language (Lenguaje de control de datos).

Administran los derechos y restricciones de los usuarios. Lo forman las Instrucciones GRANT yREVOKE. Instrucciones de control de transacciones (DTL). Administran las modificaciones creadas por las instrucciones DML. Lo forman las instrucciones ROLLBACK, COMMIT y SAVEPOINT. Se las considera parte del DCL. Clusulas. Son palabras especiales que permiten modificar el funcionamiento de un comando (WHERE, ORDER BY,...) Operadores. Permiten crear expresiones complejas. Pueden ser aritmticos (+,-,*,/,...) lgicos (>, <, !=,<>, AND, OR,...) Funciones. Para conseguir valores complejos (SUM(), DATE(),...) Constantes. Valores literales para las consultas, nmeros, textos, caracteres,... Datos. Obtenidos de la propia base de datos

3.1. Instrucciones para consulta de datos (SELECT) 3.2. Instrucciones INSERT 3.3. Actualizaciones (Instrucciones UPDATE) 3.4. Eliminacin (Sentencias DELETE) 3.5. Manipulacin de usuarios y permisos 3.6. Optimizacin de consultas

CAPITULO IV 4. ESTIMACIONES DE TAMAO DE LA BASE DE DATOS 4.1. Pginas de Datos 4.2. Pginas de ndices 4.3. Pginas de control 4.4. Asignacin y eliminacin de pginas 4.5. Indices b-tree, hashed 4.6. Estimacin de tamao CAPITULO V 5. GESTION DE TRANSACCIONES 5.1. Transacciones y ResultSets 5.2. Serializaran de transacciones 5.3. Tipos de bloqueos 5.4. Niveles de aislamiento 5.5. Recuperacin 5.6. Triggers y Store Procedures