canal visual basic .net

Recursos Visual Basic.NET, VB.NET, Manuales de programación, Tutoriales, Foros de programación, Comunidad de programadores

Usuarios activos:  28

Manuales : Balanceo de modelos

6.1.- INTRODUCCIÓN AL MODELO DE DATOS

El modelado de datos es el proceso de ordenar los datos y sus relaciones con el fin de desarrollar el modelo lógico de la base de datos. Los objetivos que se pretenden so: conseguir estructuras de datos flexibles, estables y normalizadas y, separar procesos de los datos.

La modelización de los datos procesados por un Sistema de información se realiza en diferentes niveles consecutivos de abstracción:

  • Nivel Conceptual: a este nivel se realiza una formalización de los datos almacenados en el sistema (los de los almacenes del DFD) mediante una descripción de las entidades (objetos materiales o inmateriales del sistema), los atributos (propiedades) de estas entidades y las posibles relaciones entre ellas. Este modelo se realiza durante la fase de análisis del sistema.
  • Nivel Lógico: mientras que el modelo conceptual es independiente del tipo de software de gestión de información, en el nivel lógico se realiza la adaptación de aquel modelo (ya validado) al tipo de Sistema de Gestión de Base de Datos (relacional, jerárquico o en red) que se vaya a utilizar. Al final se obtiene un modelo lógico de registros que representa la estructura de los datos (a nivel de registros lógicos) en dicho sistema. Este modelo se realiza durante la fase de diseño del sistema, se suele completar con información adicional sobre el volumen de los datos y la forma de acceso a los mismos.
  • Nivel Físico: a este nivel se debe determinar cómo se organiza físicamente el almacenamiento de los datos en ficheros. Todos estos detalles se pueden ignorar, ya que son competencia del Sistema de Gestión de Base de Datos que se utilice.

Con la modelización de los datos, además de especificar las características de la información, se pretende conseguir la simplificación de las estructuras definidas en el DD del proyecto, buscando y eliminando los elementos de datos (campos de registro) redundantes, para lo cual se produce una reorganización de estas estructuras para eliminar repeticiones, proceso que se conoce con el nombre de normalización.

 

6.2.- MODELO CONCEPTUAL DE DATOS

Es una representación abstracta de los datos utilizados por un sistema. Este modelo tiene un alto nivel de independencia, ya que:

  • no presupone ninguna hipótesis sobre la utilización que se hace de ellos;
  • no tiene en cuenta la localización de los datos en los distintos soportes;
  • traduce las elecciones u opciones de gestión fundamentales, en términos de objetos y relaciones;
  • no hay razón para que se modifique su diseño, a menos que se produzca un cambio radical de los requisitos del sistema.

Se representa mediante el Diagrama de Entidad-Relación (DER)

DEFINICIONES PREVIAS

Entidad o Individuo: es un objeto abstracto o concreto del sistema, con existencia propia y fácilmente identificable. Es una clase de objetos sobre los que se quiere guardar información. Puede ser de tres tipos:

Fundamental: Cuando es de interés por sí misma, independiente de cualquier relación.

Atributiva: Cuando sirve para completar la descripción de otro tipo de entidad.

Asociativa: Su razón de existir es relacionar otras entidades.

Cada miembro de la entidad puede identificarse de manera única por algún medio. El sistema no puede operar sin tener acceso a estos miembros. Cada uno de los miembros puede describirse con uno o más datos.

Atributo o Propiedad: es el mínimo elemento lógico de información que se puede encontrar en una entidad o asociación de entidades. El Atributo Clave de una entidad es aquel que puede ser utilizado para identificar cada ocurrencia de la entidad.

Relación: es una asociación entre entidades, cuya existencia está condicionada por las entidades que relaciona. Tiene asociada una dimensión o número de entidades que relaciona, pudiendo ser 1, 2, .... Para una relación binaria entre A y B, pueden darse de tres casos:

  • uno a uno (1-1): en la cual una ocurrencia de A no está en relación más que con una ocurrencia de B y, cada ocurrencia de B no está en relación más que con una ocurrencia de A.
  • uno a muchos (1-n): en la cual una ocurrencia de A está en relación con una o muchas ocurrencias de B y, cada ocurrencia de B no está en relación más que con una ocurrencia de A.
  • muchos a muchos (n-n): en la cual una ocurrencia de A está en relación con una o muchas ocurrencias de B y, cada ocurrencia de B está en relación con una o muchas ocurrencia de A.

La relación representa la memoria del sistema, ya que representa algo que debe ser recordado por el sistema. No se muestran las relaciones que se pueden calcular o derivar.

La cardinalidad es el número de objetos que participan en la relación. Es el número de ocurrencias de cada tipo de entidad que intervienen o pueden intervenir en una relación.

La cardinalidad mínima es el número mínimo de veces que una ocurrencia de una entidad está implicada en una ocurrencia de la relación. El valor 0 indica que no participa en la relación o lo que es lo mismo, que una ocurrencia de una entidad puede existir sin estar implicada en ninguna ocurrencia de la relación. El valor 1 que participa una sola ocurrencia o lo que es lo mismo, que no puede existir sin estar implicada en una o más ocurrencia de la relación.

La cardinalidad máxima es el número máximo de veces que una ocurrencia de una entidad está implicada en una ocurrencia de la relación. El valor 1 indica que participa en la relación con una sola ocurrencia, o lo que es lo mismo, que no puede estar implicada más que en un máximo de una ocurrencia de la relación. El valor n que participa con muchas ocurrencias o lo que es lo mismo, que puede estar implicada en n ocurrencias de la relación.

 

6.3.- DIAGRAMA ENTIDAD-RELACIÓN

El modelo conceptual de datos se representa gráficamente mediante el Diagrama Entidad-Relación, en el que aparecen los elementos descritos en el apartado anterior. Los símbolos utilizados por este diagrama son:

  • Un rectángulo para representar una entidad, en cuyo interior se especifica un nombre.
  • Un rombo para una relación, en cuyo interior se especifica el nombre de la relación.
  • Círculos para los atributos identificadores y los atributos normales de las entidades y relaciones.

ENTIDADES ASOCIATIVAS

Una Entidad Asociativa es algo que funciona como objeto y como relación. Una manera de ver esto es considerar que el tipo asociativo representa una relación acerca de la cual se desea mantener alguna información.

Por ejemplo: un cliente adquiere un artículo/s. La relación Compras asocia un Cliente con uno o más Artículos.

Supongamos que existen datos que se quieren conservar acerca de cada instancia de una compra, p.e. a qué hora se hizo. ¿Dónde se puede almacenar dicha información? "Hora del día" no es un atributo de Cliente, ni de Artículo. Más bien se asocia con la compra misma.

Compra se describe ahora dentro de un círculo conectada, por medio de líneas dirigidas a un rombo de relación sin nombre, lo que indica que Compra funciona ahora como un tipo de objeto acerca del cual se desea almacenar información y una relación que conecta dos entidades Cliente y Artículo.

Podemos pensar que una entidad asociativa es que la relación que tiene atributos.

SUBTIPO Y SUPERTIPO

Las entidades Subtipo y Supertipo consisten en tipos de objeto de una o más categorías, conectados por una relación. El Supertipo se describe por datos que se aplican a todos los subtipos. Sin embargo, cada subtipo se describe por medio de datos diferentes.

Por ejemplo, Empleado y las subcategorías Empleado Asalariado y Empleado Por Horas relacionadas a través del atributo Tipo. Este atributo es denominado Atributo Común Particionante y es el que permite fraccionar el conjunto de Empleados en los dos tipos. Las entidades subtipo son mutuamente excluyentes, o lo que es lo mismo, denotan conjuntos disjuntos.

RESTRICCIÓN DE EXISTENCIA Y DE IDENTIFICACIÓN

Se dice que una entidad E1, tiene una Restricción de Existencia respecto de la relación R, cuando toda ocurrencia de E1 debe estar asociada a una ocurrencia de R.

Se dice que una entidad E1, tiene una Restricción de Identificación respecto de la relación R, cuando las ocurrencias de E1 no pueden ser identificadas por sus propios atributos, siendo identificadas a través de su pertenencia a la relación R.

CLASES DERIVADAS Y AGREGACIÓN

Una entidad E1, tiene una Clase Derivada de entidades E si cada ocurrencia de E1 lo es también de E. En este caso, las clases derivadas forman un conjunto no disjunto.

En la Agregación se forman objetos compuestos partiendo de otros objetos simples y, estableciendo relaciones con estos objetos compuestos.

 

6.4.- PASOS PARA LA CONSTRUCCIÓN DEL DIAGRAMA ENTIDAD-RELACIÓN

Veamos los pasos necesarios para la elaboración del modelo conceptual de datos o DER.

IDENTIFICAR LA LISTA DE DATOS

Se enumeran todos los datos del campo de estudio que afectan al sistema. A continuación se debe depurar la lista de datos, eliminando los sinónimos o datos que, con diferente semántica expresan el mismo concepto. De esta lista de datos se deben detectar las entidades y las relaciones entre ellas.

CLASIFICAR LOS ATRIBUTOS

La forma de desarrollar esta clasificación es la siguiente:

  • Se buscan los atributos de la lista que puedan ser identificadores (claves) de una entidad.
  • Se describen las entidades, asignando atributos a cada una de ellas, además del identificador clave previamente asignado.
  • El resto de los atributos que quede en la lista y que no se han asignado a ninguna entidad, pertenecerán a las relaciones.

Si durante esta fase se descubre que algunos datos no pueden aplicarse a todas las instancias de algún tipo de objeto dado (entidad), se necesitará crear una entidad Subtipo/Supertipo.

Si se tiene un tipo de objeto que solo tiene un atributo asignado, existe la oportunidad de eliminar el tipo de objeto y asociar el identificador como dato a una entidad relacionada. Esto solo tiene sentida si la relación que las conecta es de tipo 1:1.

CONTROLAR LA COHERENCIA Y ELIMINAR REDUNDANCIAS

Una vez realizado el primer modelo de datos, se comprueba que cada entidad es determinada sin ambigüedad por su clave y que todas las entidades asociadas a cada relación son necesarias para definir cada atributo de la relación. También se procede a eliminar redundancias mediante la normalización.

 

6.5.- EXTENSIONES AL DICCIONARIO DE DATOS

En general, las entidades del DER corresponden con almacenes del DFD, por lo que la definición en el DD servirá tanto para el almacén como para la entidad. En el DD se tendrá que incluir una definición de cada relación que aparezca en el DER, indicando su significado en el contexto de la aplicación.

 

6.6.- MODELO LÓGICO DE DATOS

El Modelo Conceptual de Datos es independiente del software de gestión de bases de datos utilizado. Para proceder al diseño de los ficheros y de las bases de datos del sistema, se debe convertir previamente el modelo conceptual que incluía tipos de entidades y relaciones con atributos asociados, en un modelo lógico que únicamente considere tipos de registros compuestos por campos de datos. Al Modelo Lógico de Datos normalmente se le suele llamar Diagrama de Estructura de Datos (DED) o Diagrama de Bachman.

Existen tres tipos de SGBD. Basados en una base de datos relacional, en el que se almacenan los datos como un conjunto de tablas o relaciones. Basados en una base de datos en red, en el que la estructura de los registros establece una relación subordinada "padre-hijo" entre ellos. (P.e. un registro Departamento puede poseer registros Proyectos que, a su vez, poseen registros Empleados). Basados en una base de datos jerárquica, similar a la anterior, con la diferencia que cada registro sólo puede tener un padre. Nos limitaremos a las basadas en bases de datos relacionales, ya que son las más utilizadas y poseen la ventaja de que la conversión del modelo conceptual es directa, sin más que considerar las entidades como registros y los atributos como campos de éstos.

ESTRUCTURA DE UN MODELO RELACIONAL

La estructura es la tabla. Veamos algunos conceptos importantes:

Clave Primaria: es el atributo o grupo de atributos que identifica a la tabla. No pueden haber dos o más registros en una tabla con el mismo valor en el campo clave.

Clave Candidata o Alternativa: una posible clave principal.

Clave Ajena: atributo o conjunto de atributos cuyo valor debe coincidir con el valor de la clave primaria de alguna tupla de la relación R a la cual referencia.

Restricción de clave: los valores de las claves candidatas deben ser únicos para cada tupla en cualquier caso de la tabla.

Restricción de integridad de entidades: ningún valor de la clave primaria puede ser nulo.

Restricción de integridad referencial: se especifica entre dos tablas o relaciones y se usa para mantener la consistencia entre las tablas relacionadas. Establece que una tupla de una tabla que haga referencia a otra tabla, debe referirse a una tupla existente en esa tabla.

El esquema lógico es un conjunto de tablas en el cual, cada tabla tiene un identificador. Se trata de pasar del DER al esquema lógico correspondiente, para lo que se tendrá que realizar una transformación para las entidades y otra para las relaciones del DER. Para cada entidad del DER se obtendrá una tabla con tantos campos como atributos tenga. Esta transformación es directa. Para las relaciones N:N es necesario crear una nueva tabla, mientras que el resto de relaciones puede ser modelada añadiendo atributos a las tablas existentes.

TRANSFORMACIÓN DE RELACIONES 1:1

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:1. En principio, tanto E1 como E2 producen tablas individuales. En cuanto a la relación, se tiene que estudiar el comportamiento de las entidades E1 y E2 .

Si las dos entidades participan de forma total y tienen las mismas claves primarias, se fusionan en una única tabla formada por los campos de ambas e incluyendo la clave primaria una sola vez.

Si las dos entidades tienen claves primarias diferentes, se fusionan en una única tabla formada por los campos de ambas. Una de las dos claves primarias es la clave primaria de la tabla resultante.

Cuando una de las entidades participa de forma parcial en la relación, se obtiene una nueva tabla para la relación, en la que aparecerán las claves principales de las entidades participantes.

TRANSFORMACIÓN DE RELACIONES 1:N

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N.

Si la entidad del lado de "muchos" participa de forma obligatoria, la clave primaria de la entidad del lado de "uno" se debe incluir en la tabla del lado de "muchos".

Si la entidad del lado de "muchos" tiene una participación parcial, se establece una nueva tabla formada por las claves primarias de las entidades y, como clave primaria, la clave de la tabla del lado obligatorio.

TRANSFORMACIÓN DE RELACIONES N:N

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N. En este caso, se crea una nueva tabla que tiene como clave primaria la combinación de atributos que constituyen las claves primarias tanto de E1 como E2 y que incluye los atributos de R.

 

6.7.- MODELO FÍSICO DE DATOS

El último paso en la relación con los datos que utilizará un sistema de información, consiste en la elección de la organización física que soporte los métodos de acceso a los datos establecidos anteriormente. Durante el diseño físico también se seleccionan las claves de acceso a los ficheros de datos (tablas), y se eligen las claves alternativas. Se crean, por tanto, los ficheros índices para posibilitar accesos alternativos.

 

6.8.- NORMALIZACIÓN DE DATOS

Con la modelización de los datos, además de especificar las características de la información, se pretende conseguir la simplificación de las estructuras de datos definidas, localizando los elementos de datos (atributos o campos de registros) redundantes, para lo cual se procede a una reorganización de estas estructuras para eliminar las repeticiones, proceso que se conoce como normalización. La normalización es un proceso progresivo, en el que se pasa por la Primera Forma Normal (1FN) en el que las entidades no contienen atributos repetidos, Segunda Forma Normal (2FN) en el que las entidades tienen claves simples o si es compuesta, los atributos clave no dependen de la totalidad de la clave, Tercera Forma Normal (3FN) en el que las entidades no contienen dependencias funcionales entre sus atributos no clave, Forma Normal de Boyce-Codd (FNBC) también conocida cono Forma Normal Óptima, en el que para toda dependencia funcional entre cualquier atributo de la entidad, los atributos que originan la dependencia son una clave de la relación, Cuarta Forma Normal (4FN) en el que la entidad no debe contener más de una dependencia multievaluada independiente o una dependencia multievaluada independiente junto con una dependencia funcional, y Quinta Forma Normal (5FN) que es una extensión de la 4FN en el que las dependencias multievaluadas no son independientes.

Una vez obtenido el modelo de datos normalizado, se procede a su optimización, ya que la normalización también supone un aumento del tiempo de acceso a la información, al implicar un aumento del número de entidades y, por tanto de accesos.

DEFINICIONES PREVIAS

Dependencia Funcional: Un atributo X (campo o atributo) depende funcionalmente de otro atributo (o grupo de atributos) Y de la misma entidad si a cada valor de Y le corresponde sólo un valor de X. Se representa como: Y ---> X

Por ejemplo, en una entidad EMPLEADO cuyos atributos son COD_EMPLEADO, NOMBRE, DIRECCIÓN, los atributos NOMBRE y DIRECCIÓN dependen funcionalmente de COD_EMPLEADO. Simbólicamente:

COD_EMPLEADO ---> NOMBRE

COD_EMPLEADO ---> DIRECCIÓN

Dependencia Funcional Completa: Un atributo X tiene dependencia funcional completa de un grupo de atributos Y de la misma entidad, si X depende funcionalmente de Y pero no de ningún subconjunto obtenido de los posibles atributos que forman Y.

Por ejemplo, la entidad asociativa PERSONAL cuyos atributos son COD_PROYECTO, COD_EMPLEADO, FECHA_INCORPORACIÓN, HORAS_DEDICADAS, los atributos FECHA_INCORPORACIÓN y HORAS_DEDICADAS tienen una dependencia funcional completa respecto de COD_PROYECTO y COD_EMPLEADO. Simbólicamente:

COD_PROYECTO, COD_EMPLEADO ---> FECHA_INCORPORACIÓN

COD_PROYECTO, COD_EMPLEADO ---> HORAS_DEDICADAS

Dependencia Funcional Transitiva: Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice que Z depende transitivamente de X. Simbólicamente sería:

X ---> Y ---> Z entonces X ---> Z

Por ejemplo, la entidad PROYECTO cuyos atributos son COD_PROYECTO, COD_DIRECTOR, FECHA_COMIENZO, PRESUPUESTO, si un proyecto puede tener un director, los atributos FECHA_COMIENZO y PRESUPUESTO tienen una dependencia transitiva de COD_DIRECTOR. Simbólicamente:

COD_DIRECTOR ---> COD_PROYECTO ---> FECHA_COMIENZO

COD_DIRECTOR ---> COD_PROYECTO ---> PRESUPUESTO

Clave: es el atributo o grupo de atributos que identifica a la tabla y cuyo valor no puede ser nunca nulo (para garantizar la integridad de clave) tal que todos los demás atributos tienen una dependencia funcional completa de él.

Por ejemplo, la entidad EMPLEADO cuyos atributos son COD_EMPLEADO, NOMBRE, DIRECCIÓN, la combinación de atributos COD_EMPLEADO y NOMBRE no es una clave a pesar de que se cumple:

COD_EMPLEADO + NOMBRE ---> DIRECCIÓN

pero no se cumple NOMBRE ---> DIRECCIÓN, al poder haber empleados con el mismo nombre. En cambio COD_EMPLEADO si es clave, pues se cumple: COD_EMPLEADO ---> NOMBRE y COD_EMPLEADO ---> DIRECCIÓN

Clave Ajena: En algunas entidades, pueden existir atributos que sean claves de otras entidades. En este caso, tal atributo recibe el nombre de clave ajena y su valor ha de coincidir con alguna de las ocurrencias de la entidad de la que es clave. De esta forma se garantiza la integridad referencial. Cuando se elimine del sistema alguna ocurrencia de la entidad de la que es clave principal, se deben borrar también todas las ocurrencias de otras entidades en las que aparece como clave ajena, o bien darle un valor nulo a ese atributo.

Por ejemplo, la entidad PROYECTO tiene como clava COD_PROYECTO, pero existe el atributo COD_DIRECTOR que es clave de otra entidad denominada DIRECTOR. En este caso, COD_DIRECTOR en la entidad PROYECTO deberá tener el valor correspondiente a alguno de los directores que existan en la entidad DIRECTOR.

COD_DIRECTOR ---> COD_PROYECTO ---> FECHA_COMIENZO

COD_DIRECTOR ---> COD_PROYECTO ---> PRESUPUESTO

Determinante: Atributo o grupo de atributos del que depende funcionalmente de forma completa otro atributo.

REGLAS DE NORMALIZACIÓN

PRIMERA FORMA NORMAL (1FN) Una entidad está en 1FN si todos sus atributos son simples, es decir, no contiene grupos repetidos. En este caso se cumple que todos los atributos dependen funcionalmente de la clave.

Ejemplo:

Una entidad que aparece en el DD con la siguiente descripción: PEDIDO = @COD_PEDIDO + FECHA_PEDIDO + COD_PROVEEDOR + NOMBRE_PROVEEDOR + DIRECCIÓN_PROVEEDOR + {COD_PRODUCTO + NOMBRE_PRODUCTO + CANTIDAD_PEDIDA_PRODUCTO + PRECIO_UNITARIO_PRODUCTO}

No está en 1FN por contener un grupo repetido.

Para conseguir obtener entidades en 1FN, se debe eliminar el grupo repetido, o lo que es lo mismo, los atributos que no dependen funcionalmente de la clave, formando con ellos una nueva entidad, cuya clave principal estará formada por la concatencación del atributo (o grupo de atributos) que la identifica y la clave principal de la entidad original.

Ejemplo:

Por tanto, del ejemplo anterior se obtiene:

PEDIDO LÍNEA_PEDIDO

@COD_PEDIDO @COD_PEDIDO

FECHA_PEDIDO @COD_PRODUCTO

COD_PROVEEDOR NOMBRE_PRODUCTO

NOMBRE_PROVEEDOR CANTIDAD_PEDIDO_PRODUCTO

DIRECCIÓN_PROVEEDOR PRECIO_UNITARIO_PRODUCTO

SEGUNDA FORMA NORMAL (2FN) Una entidad está en 2FN si está en 1FN y cada atributo que no pertenezca a la clave tiene una dependencia funcional completa de la clave, es decir, si cada uno de los atributos de la entidad depende de toda la clave.

Ejemplo:

En el ejemplo anterior la entidad LÍNEA_PEDIDO no está en 2FN, ya que los atributos NOMBRE_PRODUCTO y PRECIO_UNITARIO_PRODUCTO no tienen una dependencia funcional completa de la clave, sino sólo de la parte COD_PRODUCTO, al ser atributos propios de un producto, independientemente del pedido en el que esté implicado.

Para conseguir obtener entidades en 2FN, se debe eliminar de la entidad original los atributos que no dependen funcionalmente de toda la clave, sino solo de una parte de la misma y, forman con ellos una nueva entidad, cuya clave principal estará formada por la parte de la original de la que dependen funcionalmente.

Ejemplo:

Por tanto, del ejemplo anterior se obtiene:

LÍNEA_PEDIDO PRODUCTO

@COD_PEDIDO @COD_PRODUCTO

@COD_PRODUCTO NOMBRE_PRODUCTO

CANTIDAD_PEDIDO_PRODUCTO PRECIO_UNITARIO_PRODUCTO

Una entidad que esté en 1FN pero no en 2FN ha de tener una clave primaria compuesta. Una entidad que está en 1FN pero no en 2FN siempre se podrá reducir a un conjunto de entidades en 2FN.

TERCERA FORMA NORMAL (3FN) Una entidad está en 3FN si está en 2FN y cada atributo que no pertenezca a la clave no dependen transitivamente de la clave, es decir, si cada uno de los atributos de la entidad dependen solo de la clave.

Ejemplo:

En el ejemplo anterior la entidad PEDIDO no está en 3FN, ya que los atributos NOMBRE_PROVEEDOR y DIRECCIÓN_PROVEEDOR dependen transitivamente de la clave COD_PEDIDO, es decir, no dependen sólo de la clave COD_PEDIDO, sino que además dependen del atributo COD_PROVEEDOR.

Para conseguir obtener entidades en 3FN, se debe eliminar de la entidad original los atributos que dependen de otro atributo distinto de la clave (dependencia transitiva) y, se forma con ellos una nueva entidad, cuya clave principal será el atributo del cual dependen.

Ejemplo:

Por tanto, del ejemplo anterior se obtiene:

PEDIDO PROVEEDOR

@COD_PEDIDO @COD_PROVEEDOR

FECHA_PEDIDO NOMBRE_PROVEEDOR

COD_PROVEEDOR DIRECCIÓN_PROVEEDOR

Visual Studio .VisualBasic.net .ADO.NET .ASP.NET .Framework .Crystal report
[Visual Basic .NET · Información legal · Condiciones de uso · Publicidad · Contacto · RSS novedades Foro · Inicio]
Un sitio web de Internelia (Ontecnia) © Copyright 2010 canalvisualbasic.net. Todos los derechos reservados