ELECCION DE UN SISTEMA GESTOR DE UNA BASE DE DATOS

• Se consideran diferentes factores técnicos, económicos y de beneficio, de servicio técnico y formación de usuarios, organizativos de rendimiento, etc. Existen muchas "maneras" de manejar informáticamente esas bases de datos: con Access, Oracle, SQL, PostgreSQL o MySql .. entre otros. Cada sistema tiene unas características, unas ventajas y unos inconvenientes, la elección de uno u otro sistema para gestionar nuestra base de datos vendrá definida por nuestras necesidades.MySql es un gestor de bases de datos, es una manera de gestionar nuestros datos, es un bibliotecario computarizado que administra, gestiona, y opera con nuestros ficheros de datos . Si le hablamos en un idioma que entienda nos los devolverá ordenados, clasificados y/o seleccionados. Constituye el núcleo de la base de datos, contiene todas las rutinas necesarias para la gestión de los datos. Muchos sistemas utilizan como lenguaje del sistema el lenguaje SQL (Structured Query Language) Siendo una base de datos como un sistema de captación y mantenimiento de registros de forma computarizada, en este sistema se van a poder realizar las operaciones de inserción, borrado y modificación de un dato y modificaciones, borrados e inserciones de información de la estructura de la base de datos.
• Por lo que entendi es que existen muchas maneras de manejar informaticamente las bases de datos ya sea con Acces, sql, oracle, entre otros cada uno de estos tiene sus ventajas y sus caracteristicas; nosotros podemos gestionar nuestros datos en un biblotecario computarizado
• http://www.slideshare.net/tramullas/bases-de-datos-1176222

DISEÑO CONCEPRUAL DE LA BASE DE DATOS

• El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta información.
  El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
  El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.

El diseño de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico.

• Este diseño de una base de datos abarca distintos niveles en los que se lleva una estructura de almacenamiento; para realizar un diseño complejo primero se tiene que dividir en grupos asi para hacerlo menos complejo despues; el diseño complejo describe el lenguaje usado para especificar esquemas logicos y el diseño fisico parte del logico el cual es una descripcion de una base de datos en una memoria secundaria
• http://www3.uji.es/~mmarques/f47/apun/node81.htm

RECOLECCION Y ANALISIS DE BASES DE DATOS

• La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la observación, el diagrama de flujo y el diccionario de datos.
  Todas estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información que será útil y utilizada.Se tratan con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas.
  

  TÉCNICAS PARA HALLAR DATOS:
  Se utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.
  LA ENTREVISTA:
  Las entrevistas se utilizan para recabar información en forma verbal. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
  Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.

• Esta recoleccion de datos debe hacer uso de tecnicas para que se pueda llevar acabo los sistemas de informacion como entrevistas, la observacion, etc; esto nos sirve para que mediante varios metodos logremos establecer los datos mas relevantes y asi para tener la finalidad de buscar informacion que nos sera util

• http://www.monografias.com/trabajos12/recoldat/recoldat.shtml

CIGLO DE VIDA DEL SISTEMA DE APLICACION DE BASES DE DATOS

• Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:
  

  *Planificación del proyecto.
  *Definición del sistema.
  *Recolección y análisis de los requisitos.
  *Diseño de la base de datos.
  *Selección del SGBD.
  *Diseño de la aplicación.
  *Prototipado.
  *Implementación.
  *Conversión y carga de datos.
  *Prueba.
  *Mantenimiento.

  Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación.

Planificación del proyecto:
Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación.

Definición del sistema:
En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación.

Recolección y análisis de los requisitos:
En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:
Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
Utilizando la experiencia adquirida en el diseño de sistemas similares. La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.

Diseño de la base de datos:
Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria.
Los objetivos del diseño de la base de datos son:
Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos.

Selección del SGBD:
Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico.
Diseño de la aplicación:
En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.

Prototipado:
Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos.

Implementación:
En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios.
Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación.

Conversión y carga de datos:
Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.
Prueba:
En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de aplicación y en la estructura de la base de datos.

Mantenimiento:
Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:
Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.
Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.

• En una aplicaion de bases de datos se lleva acabo un ciclo de vida el cual contiene etapas, como la planeacion en la cual el modolo de datos se represnta un diagrama de entidad-relacion

Todos estos distintos ciclos de vida necesitan una retroalimentación continua y tiene varios pasos a seguir para determinar cual será éste ciclo de vida.

• http://www3.uji.es/~mmarques/f47/apun/node67.html

TERCERA FORMA NORMAL

• La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
  Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
  Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

• Por lo que entendi es que esta tercera debe estar entrelazada con la segunda y no debe tener ninguna dependencia funcional, esta dependencia no es es dependiente si no parcial

• http://es.wikipedia.org/

wiki/Normalización_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

SEGUNDA FORMA NORMAL

• Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
  

  En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.
  Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.

• Esta segunda forma debe estar en la primera; pero esta segunda debe de valerse por si misma osea que sus datos debed de estar ligados de alguna manera ya que esta segunda sera dependiende de la primera informacion ya que la segunda no valdria por si misma

• http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

PRIMERA FORMA NORMAL

• Una tabla está en Primera Forma Normal si:

*Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
*La tabla contiene una clave primaria.
*La llave primaria no contiene atributos nulos.
*No posee ciclos repetitivos.
*No debe de existir variación en el número de columnas.
*Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
*Esta forma normal elimina los valores repetidos dentro de una BD.

• La primer forma normal no debe tener variociones en sus columnas ya que esta forma normal las eliminara a los valores repetidos dentro de una tabla es por esto que es la primer forma normal ya los atributos son atomicos

• http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

NORMALIZACION DE UNA BASE DE DATOS

• El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
  

  Las bases de datos relacionales se normalizan para:
  

  *Evitar la redundancia de los datos.
  *Evitar problemas de actualización de los datos en las tablas.
  *Proteger la integridad de los datos.
  

  En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
  

  *Cada columna debe tener su nombre único.
  *No puede haber dos filas iguales. No se permiten los duplicados.
  *Todos los datos en una columna deben ser del mismo tipo.

• Esta noramalizacion nos sirve para seguir una serie de reglas en el modelo relacional para que no aya problemas como perdida de informacion, dcumentos, etc. para esto nos sirve la normalizacion de datos para que no tengamos ninguna perdida de informacion.

• http://es.wikipedia.org/wiki/Normalizaci

Generación De Un Sistema De Base De Datos

• Un Sistema de Bases de Datos (SBD) es una serie de recursos para manejar grandes volúmenes de información, sin embargo no todos los sistemas que manejan información son bases de datos.
  Un sistema de bases de datos debe responder a las siguientes características:
  Independencia de los Datos. Es decir, que los datos no dependen del programa y por tanto cualquier aplicación puede hacer uso de los datos.
  Reducción de la Redundancia. Llamamos redundancia a la existencia de duplicación de los datos, al reducir ésta al máximo conseguimos un mayor aprovechamiento del espacio y además evitamos que existan inconsistencias entre los datos. Las inconsistencias se dan cuando nos encontramos con datos contradictorios.
  Seguridad. Un SBD debe permitir que tengamos un control sobre la seguridad de los datos.
  Un SBD está formado por:
  Personas
  Maquinas
  Programas
  Son los encargados de manejar los datos, son conocidos como DBMS (Data Base Management System) o también SGBD (Sistema Gestor de Base de Datos). Los DBMS tienen dos funciones principales que son:
  La definición de las estructuras para almacenar los datos.
  La manipulacion de datos.
  Es lo que se conoce como base de datos propiamente dicha. Para manejar estos datos utilizamos una serie de programas.
  Los SBD pueden ser estudiados desde tres niveles distintos:
  
  
  1 Nivel Físico Es el nivel real de los datos almacenados. Es decir como se almacenan los datos, ya sea en registros, o como sea. Este nivel es usado por muy pocas personas que deben estar cualificadas para ello. Este nivel lleva asociada una representación de los datos, que es lo que denominamos Esquema Físico. 2 Nivel Conceptual Es el correspondiente a una visión de la base de datos desde el punto de vista del mundo real. Es decir tratamos con la entidad u objeto representado, sin importarnos como está representado o almacenado. Este nivel lleva asociado el Esquema Conceptual. 3 Nivel Visión Son partes del esquema conceptual. El nivel conceptual presenta toda la base de datos, mientras que los usuarios por lo general sólo tienen acceso a pequeñas parcelas de ésta. El nivel visión es el encargado de dividir estas parcelas. Un ejemplo sería el caso del empleado que no tiene porqué tener acceso al sueldo de sus compañeros o de sus superiores. El esquema asociado a éste nivel es el Esquema de Visión.
  Los tres niveles vistos, componen lo que conocemos como arquitectura de base de datos a tres niveles. A menudo el nivel físico no es facilitado por muchos DBMS, esto es, no permiten al usuario elegir como se almacenan sus datos y vienen con una forma estándar de almacenamiento y manipulación de los datos. La arquitectura a tres niveles se puede representar como sigue:
  Modelo Relacional de Datos
  Modelo de Red
  Modelo Jerarquico
• 
  
• http://www.wikilearning.com/curso_gratis/sistemas_de_bases_de_datos/3621-1

Diseño Físico De Una Base De Datos

• El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
  Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones, pueden provocar una reestructuración del esquema lógico.
  Metodología de diseño físico para bases de datos relacionales
  El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
  El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
  Traducir el esquema lógico global para el SGBD específico. Diseñar las relaciones base para el SGBD específico. Diseñar las reglas de negocio para el SGBD específico. Diseñar la representación física. Analizar las transacciones. Escoger las organizaciones de ficheros. Escoger los índices secundarios. Considerar la introducción de redundancias controladas. Estimar la necesidad de espacio en disco. Diseñar los mecanismos de seguridad. Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. Monitorizar y afinar el sistema. Traducir el esquema lógico global
  La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber:
  Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas. Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos). Si el sistema soporta la definición de dominios. Si el sistema soporta la definición de reglas de negocio. Cómo se crean las relaciones base
• La transformación de una Base de Datos quiere decir que los usuarios deben o mas bien pueden transformar la Base de acuerdo a sus necesidades; por ejemplo: si yo necesito que esa información este clasificada u organizada de una manera específica puedo hacer (en una base de datos) esta operación. Y también nos proporciona la opción de recuperar datos que hayan sido perdidos, etc.
• http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

TRANSFORMACION AL MODELO DE DATOS

• En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos, al modelo de datos ofrecido por el SGBD.
  El método para el desarrollo de BD XML parte del modelo conceptual de datos representado
  mediante un diagrama de clases UML. Este modelo se abstrae completamente de la
  plataforma final en la que se desplegará la BD y por tanto se considera el modelo a nivel PIM.
  Este PIM se podría utilizar como modelo de partida en el desarrollo de cualquier otro tipo de
  BD, y de hecho en la propuesta de MIDAS se contempla también como punto de partida en el
  desarrollo de la BDOR [15] y se utiliza para el desarrollo del hipertexto [16]. El siguiente
  paso es la generación del modelo de datos para una plataforma concreta, es decir se piensa ya
  en la plataforma en la que se desplegará finalmente la BD y se habla por tanto de modelo
  PSM. Éste modelo no es más que la representación del esquema de la BD, que en el caso de
  una BD XML, se recoge en un XML Schema que define la estructura de los documentos
  XML que se almacenarán en la BD. MIDAS propone la utilización de estándares a lo largo de
  Juan M. Vara, Belén Vela, Esperanza Marcos
  4
  todo el proceso de desarrollo, y más concretamente el uso de UML como notación para
  cualquier actividad de modelado, pero UML no incluye soporte para el modelado de XML
  Schemas. Una posible solución sería modificar el metamodelo de UML, pero esta solución es
  demasiado drástica. UML, sin embargo, ha sido diseñado para que pueda extenderse de una
  forma controlada y proporciona para ello sus propios mecanismos de extensión para cubrir la
  necesidad de flexibilidad. Dichos mecanismos permiten crear nuevos bloques de construcción
  por medio de estereotipos, valores etiquetados y restricciones recogidos todos ellos en lo que
  se denomina perfil UML. Así, como parte de la propuesta para el desarrollo de BD XML, se
  ha definido un perfil UML para el modelado de XML Schemas. Dicho perfil permite
  representar gráficamente los componentes específicos del estándar XML Schema
  conservando el orden y grado de anidamiento dado.
  Tanto el perfil propuesto como el metamodelo que resulta de aplicar el perfil se han
  presentado anteriormente en [13] y [14], así pues se remite al lector a dichos trabajos para una
  mejor comprensión del modelado de XML Schemas en UML.
  3. DEL MODELO CONCEPTUAL AL ESQUEMA DE LA BD
  Como ya se ha mencionado, MIDAS sigue una aproximación dirigida por modelos para el
  desarrollo de SIW y por tanto, considera los modelos como actores de primer orden a lo largo
  de todo el proceso de desarrollo. En este contexto se puede pensar en el proceso de desarrollo
  como el conjunto de tareas a completar para generar los distintos modelos incluidos en el
  proceso. En el caso concreto que se aborda en este trabajo, la transformación resulta
  relativamente sencilla: se toma como entrada el modelo conceptual y se obtiene como salida
  del proceso el modelo que representa el esquema de la BD XML, esto es, el XML Schema
  que dicta la estructura de la BD XML que almacenará los documentos XML. A continuación
  se definen formalmente estas transformaciones, primero definiéndolas como reglas
  expresadas en lenguaje natural para posteriormente formalizarlas utilizando una aproximación
  basada en gramáticas de grafos.
  3.1. Reglas de Transformación entre PIM y PSM expresadas en lenguaje natural
  De acuerdo con [12], “la descripción de los mappings puede realizarse en lenguaje natural,
  un algoritmo en un action language o un modelo en un lenguaje de transformación”. En
  nuestro caso, y como una primera aproximación a las transformaciones de modelos para el
  desarrollo de BD XML, se ha optado por describir las reglas de transformación en
  lenguaje natural, para después expresarlas por medio de gramáticas de grafos. Dichas
  reglas se recogen en la tabla 1.
  Reglas de Transformación de PIM a PSM
  Modelo Conceptual a Modelo XML Schema
  1. Cada clase del modelo conceptual corresponderá a un elemento en el XML Schema con el mismo nombre
  de la clase. Además, para especificar el tipo del elemento, se incluirá un nuevo complexType inline, o si se
  opta por definirlo con nombre se utilizará la expresión nombreclase_type para nombrarlo. El elemento y el
  complexType se relacionarán por medio de una asociación uses
  Juan M. Vara, Belén Vela, Esperanza Marcos
  5
  2. Los atributos de una clase se recogerán en el XML Schema como subelementos del complexType que
  sirve para definir el tipo del elemento que representa a la clase
  2.1. En el caso de atributos obligatorios el valor de la propiedad minOccurs del subelemento será 1 (éste
  es el valor por defecto)
  2.2. En el caso de atributos opcionales el valor de la propiedad minOccurs del subelemento será 0
  2.3. En el caso de atributos multivaluados el valor de la propiedad maxOccurs del subelemento será
  unbounded
  2.4. En el caso de atributos compuestos el subelemento será de tipo complexType anónimo. Dicho
  complexType utilizará el compositor sequence para incluir un subelemento por cada componente del
  atributo compuesto
  2.5. En el caso de atributos enumerados el subelemento será de un tipo simpleType anónimo. Este
  simpleType se relacionará con una clase enumeration donde se especificaran los posibles valores del
  atributo
  3. Una asociación entre 2 clases se recogerá incluyendo un subelemento en uno de los complexType
  correspondiente a las clases que participan en la asociación, ya que se recogerán siempre como
  asociaciones unidireccionales. El subelemento recibirá el mismo nombre que la asociación que representa.
  Dicho subelemento, de tipo REF, referenciará al elemento que corresponde a la otra clase que participa en
  la asociación. El valor del atributo minOccurs de dicho subelemento dependerá de la multiplicidad mínima
  de la asociación (0 ó 1) y el valor del atributo maxOccurs será 1
  3.1. Si la multiplicidad es 1:N el subelemento se incluirá forzosamente en el complexType que
  corresponde a la clase de multiplicidad N.
  3.2. Si la multiplicidad es N:M el valor del atributo maxOccurs será unbounded
  4. Las relaciones de agregación se recogerán incluyendo un subelemento en el complexType
  correspondiente a la clase que actúa como TODO en la relación. Para nombrarlo se utilizará el nombre de
  la relación y, en su defecto, la cadena is_aggregated_of. El subelemento será de tipo REF y referenciará al
  elemento correspondiente a la clase que actúa como PARTE. El valor del atributo minOccurs de dicho
  subelemento dependerá de la multiplicidad mínima de la asociación (0 ó 1)
  4.1. Si la multiplicidad máxima de la relación es N, el valor de la propiedad maxOccurs del subelemento
  será unbounded
  5. Las relaciones de composición se recogerán incluyendo un subelemento en el complexType
  correspondiente a la clase que actúa como TODO. Para nombrarlo se utilizará el nombre de la relación y,
  en su defecto, la cadena is_composed_of. Este subelemento será de tipo complexType anónimo y utilizará
  el compositor all para incluir un conjunto de elementos del tipo del complexType correspondiente a la/s
  clase/s que actúan como PARTE en la composición
  6. En las relaciones de generalización el complexType utilizado para definir el tipo del elemento que
  representa a la clase hija será una extensión del complexType correspondiente a la clase padre.
• Esta transformacion al modelo le permite al usuario transformar la base de acuerdo a sus necesidades Tambien nos ayuda a poder recuperar datos que ya han sido perdidos
  
• http://www.slideshare.net/tramullas/bases-de-datos-1176222
  http://personales.unican.es/ruizfr/bda/doc/teo/5/bda-t5-diseno-kybele.pdf

OPERADORES PRIMITIVOS, DERIVADOS Y ADICIONALES DE CONSULTA

• Operadores primitivos: Los operadores primitivos son parte del modelo relacional y pueden realizar diferentes acciones como Unión, Diferencia, etc. Operadores derivados: Los operadores derivados son aquellos que se pueden expresar siempre en función de operadores primitivos, pero su introducción tiene por fin la simplificación de las consultas. Los operadores derivados son aquellos que se obtienen de otros en este caso podrian ser los primitivos Operadores adicionales: Los operadores permiten realizar operaciones aritméticas, comparaciones, concatenaciones o asignaciones de valores. Por ejemplo, puede probar datos para comprobar que la columna de país o región de los datos de clientes está llena o no es NULL En las consultas, cualquier persona que pueda ver los datos de la tabla que se deben usar con algún tipo de operador puede realizar operaciones. Para poder cambiar los datos correctamente, debe disponer de los permisos adecuados. Permite cambiar datos, permanente o temporalmente.
• Nos ayudan a tener un mejor entendimiento con la bases de datos de uhna manera explicita y entendible que se llevan a traves de consultas.
• http://www.gedlc.ulpgc.es/docencia/NGA/tipos_general.html

ARQUITECTURA DE TRES NIVELES

• La arquitectura a tres niveles del grupo ANSI, con su esquema conceptual, ha marcado una clara línea de investigación en el campo de las bases de datos. Aun cuando en trabajos y propuestas de normalización anteriores ya se había indicado la conveniencia de separar los tres niveles de estructuras, ninguno de estos estudios había tenido un impacto semejante al del esquema conceptual de ANSI. Consideramos, por tanto, de interés presentar dicha arquitectura.Una de las primeras tareas del grupo de estudio consistió en buscar una terminología común e intentar desarrollar un vocabulario consistente y comprensible. Otro trabajo que se abordó desde las primeras etapas fue el análisis de los componentesLa arquitectura ANSI/X3/SPARC está parcialmente basada en el concepto de máquinas anidadas (lo que se llama a veces tipo cebolla). El flujo de datos pasa a través de las distintas capas, que están separadas por inter-faces y cuyas funciones se describen con cierto detalle en el documento. Los múltiples interfaces, cuyo número se ha considerado excesivo, tienden a aislar los diversos componentes del sistema con vistas a conseguir el objetivo de independencia.En esta arquitectura se definen distintas funciones: humanas, representadas en la Figura por hexágonos; funciones de programa, que se presentan por medio de rectángulos; interfaces, que se representan mediante líneas y para cuya instrumentación el informe no dicta ninguna norma, pu-diendo ser, por tanto, interfaces físico, lógico, microprogramador, etc., y metadatos o diccionario de datos, representado por medio de un triángulo y que tiene un papel fundamental en esta arquitectura.
• Estos tres modelos ayudan al usuario a un mejor entendimiento para el uso de bases de datos y se utilizan para una separacion de programas de aplicacion

• http://www3.uji.es/~mmarques/f47/apun/node33.html

MODELO ANSI-PARK

• Nivel interno: Tiene un esquema interno que describe la estructura física de almacenamiento de base de datos. Emplea un modelo físico de datos y los únicos datos que existen están realmente en este nivel.Nivel conceptual: tiene esquema conceptual. Describe la estructura de toda la base de datos para una comunidad de usuarios. Oculta los detalles físicos de almacenamiento y trabaja con elementos lógicos como entidades, atributos y relaciones.Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada esquema describe la visión que tiene de la base de datos a un grupo de usuarios, ocultando el resto.
• Este modelo nos ayuda a tener un mejor entendimiento sobre datos almacenados en una base de datos asi tambien para poder tener una mejor utilizacion de ella
• http://www.monografias.com/trabajos37/arquitectura-de-sistemas/arquitectura-de-sistemas.shtml#ansi;html.rincondelvago.com/bases-de-datos_7.html - 53k -

REQUERIMIENTOS PARA UNA CONSTRUCCION DE BASES DE DATOS

• La construcción de bases de datos es una de las especialidades, el diseño de bases de datos en MySQL, PostgreSQL, Access, Progress. Utilizando lenguajes para ello como PHP, JavaScript, Visual Basic o 4GL, que son herramientas utilizadas con frecuencia.El análisis de requerimientos para una base de datos incorpora las mismas tareas que el análisis de requerimientos del software. Es necesario un contacto estrecho con el cliente; es esencial la identificación de las funciones e interfaces; se requiere la especificación del flujo, estructura y asociatividad de la información y debe desarrollarse un documento formal de los requerimientos. Un tratamiento completo del análisis de las bases de datos va mas allá del ámbito de este paper.
• Se debe de tener en mente los requerimientos de esta para poder llevarlos acabo, tener un analisis de la informacion y los conocimientos basicos para la construccion de una base de datos
  

• http://www.wikilearning.com/curso_gratis/guia_del_desarrollo_de_software-requerimientos_de_las_bases_de_datos/3471-21

MODELO ENTIDAD RELACIONAL

• Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido. El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas.
• El modelo se lleva a traves de representaciones lingüisticas y graficas para tener un mejor entendimiento de la base de datos
• http://www3.uji.es/~mmarques/f47/apun/node83.html

MODELO RELACIONAL

• El modelo relacional fue presentado por la E. F. Codd en 1970 [2] como un modo de hacer sistemas de gestión de datos más independientes de cualquier uso particular. Esto es un modelo matemático definido en términos de predicado lógico y la teoría de juego.La estructura de datos básica del modelo relacional es la tabla, donde la información sobre una entidad particular (decir, un empleado) es representado en columnas y filas (también llamado tuples). Así, "la relación" en "la base de datos relacionada" se refiere a varias tablas en la base de datos; una relación es un juego de tuples. Las columnas enumeran varios atributos de la entidad (el nombre del empleado, la dirección o el número de teléfono, por ejemplo), y una fila es un caso real de la entidad (un empleado específico) que es representado por la relación.
• Este modelo se lleva acabo en tablas y columnas para mejorar el entendimiento de una base de datos.

• http://es.wikipedia.org/wiki/Modelo_de_base_de_datos;
  

MODELO JERARQUICO

• Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que repite y usa relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad.los datos son organizados en una estructura parecida a un árbol, implicando un eslabón solo ascendente en cada registro para describir anidar, y un campo de clase para guardar los registros en un orden particular en cada lista de mismo-nivel. Las estructuras jerárquicas fueron usadas extensamente en los primeros sistemas de gestión de datos de unidad central, como el Sistema de Dirección de Información (IMS) por la IBM, y ahora describen la estructura de documentos XML. Esta estructura permite un 1:N en una relación entre dos tipos de datos. Esta estructura es muy eficiente para describir muchas relaciones en el verdadero real; recetas, índice, ordenamiento de párrafos/versos, alguno anidó y clasificó la información. Sin embargo, la estructura jerárquica es ineficaz para ciertas operaciones de base de datos cuando un camino lleno (a diferencia del eslabón ascendente y el campo de clase) también no es incluido para cada registro.
• El modelo jerarquico tiene una forma de un diagrama de arbol que nos ayuda a que la informacion este organizada y tener mejor comprension de la informacion.

• http://es.wikipedia.org/wiki/Modelo_de_base_de_datos

MODELO DE RED

• El modelo de red es un Modelo de base de datos concebido como un modo flexible de representar objetos y su relacion.El inventor original del modelo de red fue Charles Bachman, y con ello fue desarrollado en una especificación estándar publicada en 1969 por el consorcio CODASYL. El modelo de red (definido por la especificación CODASYL) organiza datos que usan dos fundamental construcciones, registros llamados y conjuntos. Los registros contienen campos (que puede ser organizado jerárquicamente, como en el lenguaje COBOL de lenguaje de programación). Los conjuntos (para no ser confundido con conjuntos matemáticos) definen de uno a varios relaciones entre registros: un propietario, muchos miembros. Un registro puede ser un propietario en cualquier número de conjuntos, y un miembro en cualquier número de conjuntos.
  

• Este modelo nos ayuda a representar en una base de datos los objetos; este nos permite organizar datos .

• http://www.desarrolloweb.com/articulos/modelos-base-datos.html; http://es.wikipedia.org/wiki/Modelo_de_base_de_datos
  

MODELOS DE BASES DE DATOS

• Un modelo de datos para las bases de datos es una colección de conceptos que se emplean para describir la estructura de una base de datos. Esa colección de conceptos incluyen entidades, atributos y relaciones.
  
  La mayoría de los modelos de datos poseen un conjunto de operaciones básicas para especificar consultas y actualizaciones de la base de datos.
  
  

  • ---

  Los modelos de datos pueden clasificarse en:
  
  * Modelos de datos de alto nivel o conceptuales: disponen de conceptos cercanos a la forma en que los usuarios finales perciben una base de datos.
  
  * Modelos de datos de bajo nivel o físicos: disponen de conceptos que describen detalles sobre el almacenamiento de los datos en la computadora.
  
  
  • * Modelos de datos de representación (o de implementación): disponen de conceptos que pueden entender los usuarios finales, pero que no están alejados de la forma en que se almacenan los datos en la computadora

• Nos sirven para comprender mejor la base de datos ya que son estructurales; estos se pueden clasificar en varios tipos como representacion, bajo o fisicos y nivel alto; sus datos de estos son estructurales.
• http://es.wikipedia.org/wiki/Modelo_de_base_de_datos, www.desarrolloweb.com/.../modelos-base-datos.html -

Tipos de gestores de bases de datos

• Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se este manejando, o la utilidad de la misma:

  Bases de datos estáticas

  Éstas son bases de datos de sólo lectura, utilizadas primordialmente para almacenar datos históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones y tomar decisiones.

  Bases de datos dinámicas

  Éstas son bases de datos donde la información almacenada se modifica con el tiempo, permitiendo operaciones como actualización, borrado y adición de datos, además de las operaciones fundamentales de consulta.

• El tipo de gestores es un conjunto de programas que nos permiten crear y mantener una una bases de datos asegurando su integridad, confidencialidad y seguridad. Esto nos permite especificar tipos y estructuras de datos.

• http://es.wikipedia.org/wiki/Base_de_datos;http://bvs.sld.cu/revistas/aci/vol12_2_04/aci06204..htm

Concepto de datos, campo y registro

• Registro: un registro (también llamado fila) representa un ítem único de datos implícitamente estructurados en una tabla. En términos simples, una tabla de una base de datos puede imaginarse formada de filas y columnas o campos. Cada fila de una tabla representa un conjunto de datos relacionados, y todas las filas de la misma tabla tienen la misma estructura.Un registro es un conjunto de campos que contienen los datos que pertenecen a una misma repetición de entidad. Se le asigna automáticamente un número consecutivo (número de registro) que en ocasiones es usado como índice aunque lo normal y práctico es asignarle a cada registro un campo clave para su búsqueda. Campo: En el contexto de una tabla de base de datos relacional, una columna es un conjunto de valores de datos de un simple tipo particular, uno por cada fila de la tabla. Las columnas proporcionan la estructura según la cual se componen las filas. El término campo es frecuentemente intercambiable con el de columna, aunque muchos consideran más correcto usar el término campo (o valor de campo) para referirse específicamente al simple elemento que existe en la intersección entre una fila y una columna. Datos: Los datos son aquello que un programa manipula. Sin datos un programa no funcionaría correctamente. Los programas manipulan datos de manera muy diferente según el tipo de dato del que se trate. Es un conjunto discreto, de factores objetivos sobre un hecho real o bien un registro de transacciones que por sí mismo tiene poca o ninguna relevancia o propósito. Dato. Un dato es la representación de un hecho o una entidad. Registro. Es el conjunto de datos relacionadospertenecientes a una entidad. Este conjunto de datos es una colección finita, ordenada y posiblemente heterogénea en sus elementos que son tratados como una unidad. Campo.Campo es un área especifica de un registro, usada para representar una clase particular de información.Registro Lógico.Es una unidad de información significativa para el programador.Registro físico.Es una serie de registros continuos registrados como una sola unidad.

• El campo es algo discreto de informacion en un registro que se interactua en filas y columnas, el registro es la informacion relacionada con una persona o suceso, el dato es aquel que una computadora registra y que no tiene relevancia por si mismo.

• htpp://monografias.com/trabajos5/basede/basede.shtml.
  

Concepto de tabla, relaciones y clave

• Concepto de tabla: Unidad donde se crea el conjunto de datos de la base de datos. Estos datos estarán ordenados en columnas verticales.Concepto de clave: Campo que permite identificar y localizar un registro de manera ágil y organizada. Concepto de relaciones:Una relación es una tabla con columnas y filas. Un SGBD sólo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede implementar con distintas estructuras de almacenamiento.

• Las relaciones es una tabla en la base de datos ya que es mas facil percibir los datos que se encuentran; La tabla es una forma de ordenar mas facil los datos, estas tablas se efectuan de una forma vertical ya que de otra manera no se podran, La clave es una forma mas facil de encontrar algun registro, esta clave te ayudara a localizar mas rapido el registro.

• http://www.monografías.com; http://www3.uji.es/~mmarques/f47/apun/node47.html

Consultas y Formularios

• Una consulta recupera informaciones de la Base de Datos y eventualmente las presenta en la pantalla. Serán estudiados tres tipos de consultas: De selección: selecciona y presenta registros en formato patrón;De referencias cruzadas: selecciona y presenta registros en formato de planilla;De acción: altera el contenido de registros en una única operaciónConsultas: Con una consulta se pueden recuperar datos contenidos en las tablas.En Access, las consultas se diseñan mediante una cuadricula QBE, y se pueden hacer consultas para seleccionar campos de mas de una tabla, ordenar registros, realizar cálculos, actualizar y eliminar registros o crear nuevas tablas. Las consultas pueden servir de base para realizar formularios e informes.Una consulta es un objeto que proporciona una visión personal de los datos almacenados en las tablas ya creadas.Existen varios tipos de consultas para seleccionar, actualizar, borrar datos, etc; pero en principio se utilizan para extraer de las tablas los datos que cumplen ciertas condiciones.Formularios: Los formularios se utilizan para almacenar información en las tablas, actualizarlas o simplemente visualizarlas y también se pueden confeccionar tomando de base consultas. Se pueden confeccionar formularios que contengan a otros, a estos últimos se les llama subformularios.Un formulario es el objeto de Access diseñado para la introducción, visualización y modificación de los datos de las tablas.Existen diferentes tipos de formularios pero los que más se utilizan tienen la forma de fichas de datos para la introducción.
  

• Los formularios nos permiten organizar datos de una manera nas facil y rapida en documentos, tambien a introducir los datos ed la base de datos poder verlos con facilidad e imprimirlos. Las consultas te ayudan a recuperar datos de una forma muy facil en una tabla con estas se pueden llevar acabo informes.

• http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/manualdeaccess/formproy.htm,
  

http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/manualdeaccess/consultas.htm

Informes o Reportes

• El Informe o reporte es un documento de calidad académica en el que se da cuenta de lo que se hizo, con qué criterios se hizo lo que se hizo (necesidad a satisfacer, problema a resolver, objetivo u objetivos a lograr),cómo se hizo y qué resultados se obtuvieron.
  El informe o reporte se emplea información ya creada cuando se elaboró el proyecto o el plan de trabajo a realizar o , también, al recuperar la forma como se realizó el trabajo (cómo se hizo), así como al concluir y revisar los resultado obtenidos.Conjunto de información procedente de los datos contenidos en las tablas, diseñado para ser impreso, puede contener campos calculados, totales y otras formas de agrupar la información. Las consultas también pueden servir de soportes para los informes. También se les acostumbra llamar reportes.Un informe es el objeto de Access diseñado para dar formato, calcular, imprimir y resumir datos seleccionados de una tabla. Reporte: Los reportes se ocupan para hacer impresiones o se les denomina impresiones en Access 2007, antes de imprimir el trabajo puedes ver el diseño en vista preeliminar y se le denomina reporte; ya es el trabajo o los datos bien estructurados.

• El informe o reporte es un escrito mediante el cual se constituye o se hace con bloques de informacion, estos tambien nos sirven para llevar un control impreso y observar algunos movimientos que se efectuan con alguna informacion

• http://iteso.mx/~carlosc/curso2003/Temas/crea_informe.html

Concepto de bases de datos.

• Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. En la actualidad, y debido al desarrollo tecnológico de campos como la informatica y la electrónica, la mayoría de las bases de datos están en formato digital (electrónico), que ofrece un amplio rango de soluciones al problema de almacenar datos.
• Una base de datos es una colección de información organizada de forma que un programa de ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite. Una base de datos es un sistema de archivos electrónico.
• http://es.wikipedia.org/wiki/Base_de_datos,http://www.monografias.com/trabajos11/basda/basda.shtml