Unidad 7-Bases de Datos Orientadas a objetos.

Unidad 7. Bases de Datos Orientadas a objetos

7.1 Visión general.

En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system).

Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte.

Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programación.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

  Fuente: http://es.wikipedia.org/wiki/Base_de_datos_orientada_a_objetos

7.2 Tipos de datos complejos.

Los modelos de bases de datos tradicionales (relacional, red y jerárquico) han sido capaces de satisfacer con éxito las necesidades, en cuanto a bases de datos, de las aplicaciones de

gestión tradicionales. Sin embargo, presentan algunas deficiencias cuando se trata de aplicaciones más complejas o sofisticadas como, por ejemplo, el diseño y fabricación en ingeniería (CAD/CAM, CIM), los experimentos científicos, los sistemas de información geográfica o los sistemas multimedia.

Los requerimientos y las características de estas nuevas aplicaciones difieren en gran medida de las típicas aplicaciones de gestión: la estructura de los objetos es más compleja, las transacciones son de larga duración, se necesitan nuevos tipos de datos para almacenar imágenes y textos, y hace falta definir operaciones no estándar, específicas para cada aplicación. Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones.

La orientación a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no está limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. Una característica clave de las bases de datos orientadas a objetos es la potencia que proporcionan al diseñador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos.

Fuente: http://www3.uji.es/~mmarques/e16/teoria/cap2.pdf

Tipos de datos complejos: 

Colecciones: También conocidos como conjuntos, este tipo de datos clasifican los arrays y los conjuntos en que los elementos pueden aparecer varias veces.

Tipos estructurados: Los tipos estructurados permiten representación directa de los atributos compuestos en los diagramas entidad-relación.

Objetos de gran tamaño: Desde ya hace varios años que se necesita almacenar datos con atributos muy grandes (Varios Mbytes), como libros, canciones, etc. E incluso aún más grandes; como mapas de alta resolución, video, etc. que puede llegar fácilmente a los Gigabytes.

Fuente: http://es.wikipedia.org/wiki/Base_de_datos_objeto-relacional#Tipos_Complejos

7.3 Tipos estructurados y herencia en SQL.

Los tipos estructurados permiten representar directamente los atributos compuestos de los diagramas E-R. Por ejemplo, se puede definir el siguiente tipo estructurado para representar el atributo compuesto nombre con los atributos componentes nombre_pila y apellidos:

create type Nombre as

(nombre_pila varchar(20),

apellidos varchar(20))

final

De manera parecida, el tipo estructurado siguiente puede usarse para representar el atributo compuesto dirección:

create type Direccion as

(calle varchar(20),

ciudad varchar(20),

codigo_postal varchar(9))

not final

En SQL estos tipos se denominan tipos definidos por el usuario. Las especificaciones final indica que no se puede crear subtipos de nombre, mientras que la especificación not final de dirección indica que se pueden crear subtipos de dirección. Ahora se pueden usar estos tipos para crear atributos compuestos en las relaciones, con sólo declarar que un atributo es de uno de estos tipos. Por ejemplo, se puede crear una tabla cliente de la siguiente manera:

create table cliente (

nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

O bien, realizando una estructura más del tipo Cliente y generar la tabla a partir de ella:

create type TipoCliente as

(nombre Nombre,

direccion Direccion,

fecha_nacimiento date)

not final

create table cliente of TipoCliente

Se puede tener acceso a los componentes de los atributos compuestos usando la notación “punto”; por ejemplo, nombre.nombre_pila devuelve el componente nombre de pila del atributo nombre. El acceso al atributo nombre devolvería un valor del tipo estructurado Nombre.
La siguiente consulta ilustra la manera de tener acceso a los atributos componentes de los atributos compuestos. La consulta busca el apellido y la ciudad de cada cliente.

select nombre.apellido, direccion.ciudad

from cliente

Herencia.

La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerará la herencia de los tipos y después en el nivel de las tablas:

Herencia de tipos: Los tipos derivados heredan los atributos de superclase; los métodos también se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarándolo de nuevo, y esto será lo que se conoce como sobre escritura (overriding) del método.

Supóngase que se tiene la siguiente definición de tipo para las personas:

create type Persona

(nombre varchar(20),

direccion varchar(20))

Puede que se desee almacenar en la base de datos información adicional sobre las personas que son estudiantes y sobre las que son profesores. Dado que los estudiantes y los profesores también son personas, se puede usar la herencia para definir en SQL los tipos estudiante y profesor:

create type Estudiante

under Persona

(grado varchar(20),

departamento varchar(20))

create type Profesor

under Persona

(sueldo Integer,

departamento varchar(20))

7.4 Herencia de tablas.

Cada tabla almacena la clave primaria, que se puede heredar de una tabla padre; y los atributos definidos localmente. Los atributos heredados, aparte de la clave primaria, no será necesario guardarlos, podrán obtenerse mediante una reunión con la super tabla basada en la clave primaria. Por lo que cada tabla almacena todos los atributos heredados y definidos localmente. Cuando se inserta una tupla, se almacena sólo en la subtabla en la que se inserta y su presencia se infiere en cada supertabla. El acceso a todos los atributos de una tupla es más rápido, dado que no se requiere una reunión:

Las subtablas de SQL se corresponden con el concepto de especialización/generalización de E-R Por ejemplo, supóngase que se define la tabla personas de la siguiente manera:

create table personas of Persona

A continuación se puede definir las tablas estudiantes y profesores como subtablas de personas, de la manera siguiente:

create table estudiantes of Estudiante

under personas

create table profesores of Profesor

under personas

Los tipos de las subtablas deben ser subtipos del tipo de la tabla madre. Por tanto, todos los atributos presentes en personas también están presentes en las subtablas.

Además, cuando se declaran estudiantes y profesores como subtablas de personas, todas las tuplas presentes en estudiantes y profesores pasan a estar también presentes de manera implícita en personas. Por tanto, si una consulta usa la tabla personas, no sólo encuentra tuplas directamente insertadas en esa tabla, sino también tuplas insertadas en sus subtablas, es decir, estudiantes y profesores. No obstante, esa consulta sólo puede tener acceso a los atributos que están presentes en personas.

SQL permite hallar tuplas que se encuentran en personas pero no en sus subtablas usando en las consultas “only personas” en lugar de personas. La palabra clave only también puede usarse en las sentencias delete y update. Sin la palabra clave only, la instrucción delete aplicada a una supertabla, como personas, también borra las tuplas que se insertaron originalmente en las subtablas (como estudiantes); por ejemplo, la instrucción

delete from personas where P

borrará todas las tuplas de la tabla personas, así como de sus subtablas estudiantes y profesores, que satisfagan P. Si se añade la palabra clave only a la instrucción anterior, las tuplas que se insertaron en las subtablas no se ven afectadas, aunque satisfagan las condiciones de la cláusula where.

7.5 Tipos de arreglo multiconjunto en SQL.

SQL soporta dos tipos de conjuntos: arrays y multiconjuntos; los tipos array se añadieron en SQL:1999, mientras que los tipos multiconjuntos se agregaron en SQL:2003. Un multiconjunto es un conjunto no ordenado, en el que cada elemento puede aparecer varias veces.

Supóngase que se desea registrar información sobre libros, incluido un conjunto de palabras clave para cada libro. Supóngase también que se deseara almacenar almacenar el nombre de los autores de un libro en forma de array; a diferencia de los elementos de los multiconjuntos, los elementos de los arrays están ordenados, de modo que se puede distinguir el primer autor del segundo autor, etc. El ejemplo siguiente ilustra la manera en que se puede definir en SQL estos atributos como arrays y como multiconjuntos.

create type Editor as

(nombre varchar(20),

sucursal varchar(20))

create type Libro as

(titulo varchar(20),

array_autores varchar(20) array[10],

fecha_publicacion date,

editor Editor,

conjunto_palabras_clave varchar(20) multiset)

create table libros of Libro

Creación y acceso a los valores de los conjuntos

En SQL:1999 se puede crear un array de valores de esta manera:

array[‘Silberschartz’, ‘Korth’, ‘Sudarshan’]

De manera parecida, se puede crear un multiconjunto de palabras clave de la manera siguiente:

multiset[‘Silberschartz’, ‘Korth’, ‘Sudarshan’]

Por lo tanto, se puede crear una tupla definido por la relación libros como:

insert into libros

values

(‘Compiladores’, array[‘Gómez’, ‘Santos’’],

new Editor(‘McGraw-Hill’, ‘Nueva York’),

multiset[‘análisis sintáctico’, ‘análisis’])

Se puede tener acceso a los elementos del array o actualizarlos especificando el índice del array, por ejemplo, array_autores[1].

Consulta de los atributos valorados como conjuntos
Ahora se considerará la forma de manejar los atributos que se valoran como conjuntos. Las expresiones que se valoran como conjuntos pueden aparecer en cualquier parte en la que pueda aparecer el nombre de una relación, como las cláusulas from.
Si se desea averiguar todos los libros que contengan las palabras “base de datos” entre sus palabras clave, se puede usar la consulta siguiente:

select titulo

from libros

where ‘base de datos’ in

(unnest(conjunto_palabras_clave))

7.6 Identidad de los objetos y tipos de referencia en SQL.

Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la manera siguiente:

create type Departamento(

nombre varchar(20),

director ref(Persona) scope personas)

create table departamentos of Departamento

En este caso, la referencia está restringida a las tuplas de la tabla personas. La restricción del ámbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas.

La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autorreferenciable (self-referential attribute), se declara añadiendo una cláusula ref is a la instrucción create table:

create table personas of Persona

ref is id_persona system generated

En este caso, id_persona es el nombre del atributo, no una palabra clave, y la instrucción system generated especifica que la base de datos genera de manera automática el identificador.

Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente:

insert into departamentos

values (‘CS’, null)

update departamentos set director = (select p.id_persona

from persona as p

where nombre = ‘Martín’)

where nombre = ‘CS’

Una alternativa a los identificadores generados por el sistema es permitir que los usuarios generen los identificadores. El tipo del atributo autoreferencial debe especificarse como parte de la definición de tipos de la tabla a la que se hace referencia, y la definición de la tabla debe especificar que la referencia está generada por el usuario (user generated):

create type Persona

(nombre varchar(20),

direccion varchar(20))

ref using varchar(20)

create table personas of Persona

ref is id_persona user generated

Al insertar tuplas en personas hay que proporcionar el valor del identificador:

insert into personas (id_persona, nombre, direccion) values

(‘01284567’, ‘Martín’, ‘Av del Segura, 23’)

7.7 Implementación de las características OR.

Los sistemas de bases de datos relacionales orientadas a objetos son básicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesarias en muchos niveles del sistema de base de datos.

Las interfaces de programas de aplicación como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el método getObject() que devuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado. También es posible asociar clases de Java con tipos estructurados de SQL, y JDCB puede realizar conversiones entre los tipos.

Lenguajes de programación persistentes

Los lenguajes de las bases de datos se diferencían de los lenguajes de programación tradicionales en que trabajan directamente con datos que son persistentes; es decir, los datos siguen existiendo una vez que el programa que los creó haya concluido. Las relaciones de las bases de datos y las tuplas de las relaciones son ejemplos de datos persistentes.

El acceso a las bases de datos es sólo un componente de las aplicaciones del mundo real. Mientras que los lenguajes para el tratamiento de datos como SQL son bastante efectivos en el acceso a los datos, se necesita un lenguaje de programación para implementar otros componentes de las aplicaciones como las interfaces de usuario o la comunicación con otras computadoras. La manera tradicional de realizar las interfaces de las bases de datos con los lenguajes de programación es incorporar SQL dentro del lenguaje de programación.

Los lenguajes de programación persistentes son lenguajes de programación extendidos con estructuras para el tratamiento de los datos persistentes. Los lenguajes de programación persistentes pueden distinguirse de los lenguajes con SQL incorporado, al menos, de dos maneras:

1.- En los lenguajes incorporados el sistema de tipos del lenguaje anfitrión suele ser diferente del sistema de tipos del lenguaje para el tratamiento de los datos. Los programadores son responsables de las conversiones de tipo entre el lenguaje anfitrión y SQL. Hacer que los programadores lleven a cabo esta tarea presenta varios inconvenientes:

• El código para la conversión entre objetos y tuplas opera fuera del sistema de tipos orientado a objetos y, por lo tanto, tiene más posibilidades de presentar errores no detectados.
• La conversión en la base de datos entre el formato orientado a objetos y el formato relacional de las tuplas necesita gran cantidad de código. El código para la conversión de formatos, junto con el código para cargar y descargar datos de la base de datos, puede suponer un porcentaje significativo del código total necesario para la aplicación.

Por el contrario, en los lenguajes de programación persistentes, el lenguaje de consultas se halla totalmente integrado con el lenguaje anfitrión y ambos comparten el mismo sistema de tipos. Los objetos se pueden crear y guardar en la base de datos sin ninguna modificación explícita del tipo o del formato; los cambios de formato necesarios se realizan de manera transparente.

2.- Los programadores que usan lenguajes de consultas incorporados son responsables de la escritura de código explícito para la búsqueda en la memoria de los datos de la base de datos. Si se realizan actualizaciones, los programadores deben escribir explícitamente código para volver a guardar los datos actualizados en la base de datos.

Por el contrario, en los lenguajes de programación persistentes, los programadores pueden trabajar con datos persistentes sin tener que escribir explícitamente código para buscarlos en la memoria o volver a guardarlos en el disco.

Sin embargo, los lenguajes de programación persistentes presentan ciertos inconvenientes que hay que tener presentes al decidir su conviene usarlos. Dado que los lenguajes de programación suelen ser potentes, resulta relativamente sencillo cometer errores de programación que dañen las bases de datos. La complejidad de los lenguajes hace que la optimización automática de alto nivel, como la reducción de E/S de disco, resulte más difícil. En muchas aplicaciones el soporte de las consultas declarativas resulta de gran importancia, pero los lenguajes de programación persistentes no soportan bien actualmente las consultas declarativas (SQL es un ejemplo).

Tarea Unidad 5 - Tratamiento de los valores nulos

Tratamiento de los valores nulos.

Reunión.- Las reuniones se pueden expresar como un producto cartesiano seguido de una selección.

La definición de la forma en la cual la selección trata los nulos también define la forma en que la operación reunión trata los nulos.

En una reunión natural, si dos tuplas tienen valor nulo en el atributo común, las tuplas no enlazan.

Ejemplos:

Considérese las siguientes relaciones:

De las relaciones anteriores se aplican las operaciones de reunión descritas en la imagen:

Ejemplo 1-Reunión

Ejemplo 2-Reunión

Proyección generalizada.- Los nulos en las expresiones de los atributos en la proyección generalizada se tratan como en cualquier expresión.

Las tuplas duplicadas que contienen valores nulos se tratan como en la operación proyección (trata los nulos como cualquier otro valor al eliminar duplicados, aunque la decisión es un tanto arbitraria porque sin saber cuál es el valor real no se sabe si los dos valores nulos son duplicados o no).

Ejemplos:

Considérese la misma relación Producto y una nueva relación Cliente compras con un nuevo atributo Descuento (%):

a las que se le aplican operaciones de proyección generalizada:

Ejemplo 1-Proyección generalizada

Ejemplo 2-Proyección generalizada

Funciones de agregación.- Cuando hay nulos en atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación.

El tratamiento de los valores nulos aquí es diferente al realizado en las operaciones aritméticas <- aplicarlo como en las operaciones aritméticas significaría que un único valor desconocido en un gran grupo podría hacer que el resultado agregado sobre el grupo fuese nulo, y se perdería una gran cantidad de información útil.

Ejemplos:

Ejemplo 1-Función de agregación promedio (AVG).

Ejemplo 2-Función de agregación cuenta (COUNT).

Reunión externa.- Las operaciones de reunión externa se comportan como las operaciones de reunión, excepto sobre las tuplas que no aparecen en el resultado.

Ejemplos:

Ejemplo 1-Reunión Externa

Ejemplo 2-Reunión Externa

Tarea Unidad 4-Integridad en las bases de datos

Tarea, Unidad 4.

4.9 Integridad en las bases de datos.

Integridad de entidad.- Pretende que cada entidad que se guarda en la base de datos sea identificable de un modo único, es decir, que evitemos la información redundante. La integridad de entidad define una fila como entidad única para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.

Ejemplos:

1.- Ninguna factura puede tener un número duplicado, ni puede ser nulo. En suma, todas las facturas están identificadas de manera única por sus números.

2.- En la siguiente relación, puesto que la clave primaria está formada por edificio y número, no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para número.

Integridad de dominio.- La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.

Ejemplos:

1.-Si en la relación EMPLEADOS (DNI, nombre, apellido, edad_emp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero.

2.- Supongamos ahora que en la relación EMPLEADOS(DNI, nombre, apellido, edad_emp) hemos declarado que dominio(edad_emp) es el dominio definido por el usuario edad. Supongamos también que el dominio edad se ha definido como el conjunto de los enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un empleado con un valor de 90 para edad_emp.

Integridad referencial.- La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se eliminan filas. En SQL Server la integridad referencial se basa en las relaciones entre claves externas y claves principales o entre claves externas y claves exclusivas, mediante restricciones FOREIGN KEY y CHECK. La integridad referencial garantiza que los valores de clave sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos.

Ejemplos:

1.- 

Ejemplo en SQL Server: en las tablas Sales.SalesOrderDetail y Production.Product de la base de datos AdventureWorks2008R2, la integridad referencial se basa en la relación entre la clave externa (ProductID) de la tabla Sales.SalesOrderDetail y la clave principal (ProductID) de la tabla Production.Product. Esta relación garantiza que un pedido de ventas no pueda nunca hacer referencia a un producto que no existe en la tabla Production.Product.

2.- Supongamos una base de datos con las entidades Persona y Factura. Toda factura corresponde a una persona y solamente una. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas. Supongamos que una persona se identifica por su atributo DNI (Documento Nacional de Identidad). También tendrá otros atributos como el nombre y la dirección. La entidad Factura debe tener un atributo DNI_cliente que identifique a quién pertenece la factura. Por sentido común es evidente que todo valor de DNI_cliente debe corresponder con algún valor existente del atributo DNI de la entidadPersona. Esta es la idea intuitiva de la integridad referencial.

Integridad definida por el usuario.-Comprenderán las reglas que se definan para la base de datos. La integridad definida por el usuario permite definir reglas de empresa específicas que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad admiten la integridad definida por el usuario. Esto incluye todas las restricciones de nivel de columna y nivel de tabla en CREATE TABLE, procedimientos almacenados y desencadenadores.

Ejemplos:

1.- Planear y crear tablas requiere identificar los valores válidos para las columnas y decidir cómo exigir la integridad de los datos en las columnas.

2.-Restricciones PRIMARY KEY Restricciones FOREIGN KEY Restricciones UNIQUE Restricciones CHECK Definiciones DEFAULT Permitir valores NULL.

Modelo Relacional

Modelo Relacional. (Usando DBDesigner 4)

Transformando del modelo E-R al Relacional:

Aplicando la primera forma normal queda:

Aplicando la segunda forma normal:

Corrección debida a la eliminación de un dato que no es necesario almacenar (Costo_página):

Corrección debida a la eliminación de datos que no son necesarios almacenar, además de algunos tipos de datos corregidos:

Modelo E-R

Modelo Entidad-Relación.

Enunciado_

Enunciado – revista publicitaria

Una revista de publicidad esta interesada en almacenar información. Los clientes son regularmente empresas pequeñas o medianas que buscan que su producto se de a conocer atrayendo mas clientes, los vendedores entonces ofrecen espacios por página o fracciones de página desde: 1/6 de página, ¼ de página, 1/3 de página, mitad de página, ¾ de página, 1 página entera, la portada y la contraportada, en esta revista donde se publicará el diseño del cliente, ya sea que lo proporcione o que también desee que se le elaboré uno, y  después darles  ejemplares gratuitos de esta. La revista es publicada una ves al mes y dispone de 14 páginas más la portada y contraportada.

La información que se guardará a cerca de sus clientes, los vendedores, y de los espacios en la revista es:

Clientes.-Nombre completo, RFC, Dirección, de la empresa, Teléfono(s), correo electrónico, logotipos.

Vendedores.- Clave de empleado, Nombre, teléfono, dirección.

Revista.- No. Publicación, espacios reservados y disponibles, diseños.

Se desea también poder  consultar cuantos espacios hay disponibles, la información de los clientes, el precio de los espacios y la correspondencia de ventas de espacios totales de cada uno de los vendedores para efectos de pago de comisiones.

Enunciado

Una revista de publicidad esta interesada en almacenar información. Los clientes son regularmente empresas pequeñas o medianas que buscan que su producto se de a conocer atrayendo mas clientes, los vendedores entonces ofrecen espacios por página o fracciones de página desde: 1/8 de página, ¼ de página, mitad de página, ¾ de página, 1 página entera, la portada y la contraportada, en esta revista donde se publicará el diseño del cliente, ya sea que lo proporcione o que también desee que se le elaboré uno, y  después darles  ejemplares gratuitos de esta. La revista es publicada una ves al mes y dispone de 10 páginas más la portada y contraportada.

La información que se guardará a cerca de sus clientes, los vendedores, y de los espacios en la revista es:

Clientes.-Nombre completo, RFC, Dirección, de la empresa, Teléfono(s), correo electrónico, logotipos.

Vendedores.- Clave de empleado, Nombre, teléfono, dirección.

Revista.- No. Publicación, espacios reservados y disponibles, diseños.

Se desea también poder  consultar cuantos espacios hay disponibles, la información de los clientes, el precio de los espacios y la correspondencia de ventas de espacios totales de cada uno de los vendedores para efectos de pago de comisiones.