manual base de datos erwin - sql server

Manual de Base de Datos con ERWIN y SQL Server

1. Definición de base de datos OLTP

La primera pregunta que surge a la hora de comenzar este curso es la

siguiente: ¿Qué es una Base de Datos OLTP?. Existen varias definiciones

para responder a esta pregunta:

"Colección de datos interrelacionados almacenados en conjunto sin

redundancias perjudiciales o innecesarias; su finalidad es servir a una

aplicación transaccional o más, de la mejor manera posible; los datos

se almacenan de modo que resulten independientes de los programas

que los usan; se emplean métodos bien determinados para incluir

nuevos datos y para modificar o extraer los datos almacenados".

(Martin, 1975).

"Colección o depósito de datos, donde los datos están lógicamente

relacionados entre sí, tienen una definición y descripción comunes y

están estructurados de una forma particular. Una base de datos es

también un modelo del mundo real y, como tal, debe poder servir para

toda una gama de usos y aplicaciones transaccionales". (Conference

des Statisticiens Européens, 1977).

"Conjunto de datos de la empresa memorizado en un ordenador,

que es utilizado por numerosas personas y cuya organización está

regida por un modelo de datos". (Flory, 1982).

"Conjunto estructurado de datos registrados sobre soportes

accesibles por ordenador para satisfacer simultáneamente a varios

usuarios de forma selectiva y en tiempo oportuno".

(Delobel, 1982).

"Colección no redundante de datos que son compartidos por

diferentes sistemas de aplicación". (Howe, 1983).

"Colección integrada y generalizada de datos, estructurada

atendiendo a las relaciones naturales de modo que suministre todos

los caminos de acceso necesarios a cada unidad de datos con objeto

de poder atender todas las necesidades de los diferentes usuarios".

(Deen, 1985).

Pág. 1 Ing: Erick Giovanny Flores Chacón


"Conjunto de ficheros maestros, organizados y administrados de una

manera flexible de modo que los ficheros puedan ser fácilmente

adaptados a nuevas tareas imprevisibles". (Frank, 1988).

"Colección de datos interrelacionados". (Elsmari y Navathe, 1989).

Las bases de datos OLTP, son bases de datos que apoyan a los

procesos transaccionales en línea, muy diferentes a bases de datos

orientados a las consultas, análisis de la información y soporte a la

toma de decisiones como es el caso de los Data Warehouse y Data

Mart.

Como se ha visto, el concepto de base de datos ha ido cambiando

a lo largo del tiempo. En la actualidad podemos establecer la definición

de base de datos como sigue.

"Colección o depósito de datos integrados, almacenados en soporte

secundario (no volátil) y con redundancia controlada, producto de

procesos transaccionales del negocio. Los datos, que han de ser

compartidos por diferentes usuarios y aplicaciones, deben mantenerse

independientes de ellos, y su definición (estructura de la base de datos)

única y almacenada junto con los datos, se ha de apoyar en un modelo

de datos, el cual ha de permitir captar las interrelaciones y restricciones

existentes en el mundo real. Los procedimientos de actualización y

recuperación, comunes y bien determinados, facilitarán la seguridad del

conjunto de los datos".

1.1. Conceptos básicos

Sistema de Gestión de Base de Datos (SGBD): Conjunto de

programas que permiten la implantación, acceso y

mantenimiento de la base de datos. El SGBD, junto con la base

de datos y con los usuarios, constituyen el Sistema de Base de

Datos.

Modelo de datos: Conjunto de conceptos que permiten

describir, a distintos niveles de abstracción, la estructura de una



base de datos, a la cual denominamos esquema.

On Line Transation Process. Tipo de base de datos que apoya a

los procesos y sistemas reinformación transaccionales. Proceso de

transacciones en línea

Sistema de Información: Colección de personas,

procedimientos y equipos diseñados, construidos, operados y

mantenidos para recoger, registrar, procesar, almacenar y

recuperar esa información.

Esquema de una Base de Datos: Estructura de la Base de Datos.

Ocurrencia del esquema: Conjunto de datos que se encuentran

almacenados en el esquema en un momento determinado. El

esquema no varía mientras no varíe el mundo real que éste

describe, mientras que una ocurrencia del esquema es distinta en

el transcurso del tiempo.

1.2. Del enfoque tradicional a los sistemas de bases de datos

Para comprender mejor las diferencias entre los sistemas

tradicionales basados en ficheros y los sistemas de bases de

datos, pongamos un ejemplo. Supóngase que disponemos de un

archivo maestro de clientes con la siguiente información: nombre,

dirección, ciudad, provincia y teléfono. Si además de esto, añadimos

dos ficheros, uno para la emisión de facturas, y otro para la

emisión de informes, podemos encontrarnos con los siguientes

problemas:

Producción de inconsistencias o incoherencias, debido a la

replica de información (la misma información puede estar

almacenada en distintos ficheros).

Malgasto de memoria secundaria (por el mismo motivo).

Si en este momento se quiere añadir en número de fax, se

hace necesario una completa reestructuración de dicho fichero,

sin mencionar el rediseño del código de la aplicación, para dar

cabida a este cambio.



En cambio, en un sistema de gestión de bases de datos, estos

problemas no tienen cabida, ya que el control de la información es

inherente al propio sistema.

Algunas de las ventajas que ofrece utilizar un Sistema de Bases de

Datos son las siguientes:

1. Independencia entre datos y tratamientos. El cambio en los

programas no influye en la disponibilidad de los datos, así

como la modificación de éstos no afecta a la reprogramación de

las aplicaciones que los usan.

2. Coherencia de resultados: Debido a que los datos son

almacenados una sola vez, se evitan los problemas que puede

ocasionar la redundancia. Más adelante veremos cómo se

permite una cierta duplicidad de datos, con el fin de conseguir

una mayor eficiencia, controlada por el sistema y que no afecta a

la redundancia lógica.

3. Mejor disponibilidad de datos para los usuarios: Los datos son

compartidos por un conjunto de usuarios, que accede a ellos de

forma concurrente, siempre que estén autorizados a ello.

4. Mayor valor informativo: El conjunto de los datos almacenados

en la BD ofrece un mayor valor informativo, que la suma de ellos

independientemente.

5. Mayor eficiencia en la recogida, validación e introducción de los

datos en el sistema: Al no existir redundancia, los datos se

recogen y validan una sola vez, aumentando así la eficiencia.

6. Reducción del espacio de almacenamiento: La desaparición (o

disminución) de redundancias, unido a las técnicas de



compactación, implica una menor ocupación de

almacenamiento secundario.

A pesar de todas estas ventajas, los Sistemas de Bases Datos no

están exentos de inconvenientes. Aquí se detallan los más

importantes:

1. Instalación costosa: La implantación de un sistema de base de

datos puede implicar un coste elevado, tanto en el equipo físico

(adquisición de nuevas instalaciones, o ampliaciones de las

existentes) como en el lógico (sistemas operativos, programas,

compiladores, etc.), así como el coste de adquisición o

mantenimiento del SGBD.

2. Implantación larga y difícil: Debido a las causas mencionadas

anteriormente, la implantación de un sistema de base de datos

puede convertirse en una tarea larga y complicada.

3. Falta de rentabilidad a corto plazo: Los amplios costes que

conlleva la implantación, implica una rentabilidad no a corto, sino a

medio, o incluso largo plazo.

4. Escasa estandarización: Esto supone una dificultad añadida a los

usuarios de la base de datos.

5. Desfase entre teoría y práctica: Los constantes avances teóricos

en al ámbito de las bases de datos, que muchas veces no se ven

traducidos en la práctica, hacen llevarse a engaño a muchos

usuarios, creyendo que constituyen ya una realidad, cuando no

han sido todavía plasmados.



1.3. El modelo relacional

El modelo más usado, es el modelo relacional. El motivo de que

sea éste el modelo más extendido, radica en la facilidad y en

su amplia base matemática, lo que permitirá, como ya se verá más

adelante, el poder estructurar o reestructurar las relaciones, para

evitar cierto tipo de anomalías, o acelerar las consultas /

actualizaciones. Dicho modelo se basa en la representación de

la información por medio de estructuras tipo tabla, denominadas

relaciones, y que almacenan información para una determinada

entidad. Cada una de estas relaciones representa en sus

columnas los valores significativos, es decir, de los que interesa

conocer su valor, para cada entidad. Dichas columnas se denominan

atributos, y para cada uno de ellos existirá un valor (cabe la

posibilidad de que existan atributos en los que no aparezca ningún

valor). Cada fila representa la información para cada ocurrencia de

una determinada entidad. La información se descompondrá, como ya

se ha dicho, en dar valores para cada uno de los atributos de la

entidad. A dichas filas también se las denomina tuplas. Cada

atributo o conjunto de atributos que identifica unívocamente a cada

tupla de la relación se denomina clave. Las claves se representan

subrayando el / los atributo/s que forman parte de ella.

El siguiente ejemplo (Figura 1) representa una relación

denominada empleado, que almacena información sobre los

empleados de una empresa. La información que se desea saber

de cada empleado es su código, su nombre y apellidos, su sueldo y

su categoría. Por lo tanto, los atributos son cod_empleado, nombre,

apellidos, sueldo y categoría. Además, el atributo cod_empleado es

clave de la relación, ya que si se sabe el valor de dicho atributo, se

puede saber a que empleado nos estamos refiriendo.



Figura 1

1.4. Fases del diseño

El diseño de una base de datos suele descomponerse en tres

grandes fases (diseño conceptual, lógico y físico), lo que permite

reducir la complejidad que entraña el diseño, a la vez que ayuda a

alcanzar los dos principales objetivos que tienen las bases de datos:

Ser una representación fidedigna del mundo real,

Ser un servidor operacional y eficiente de los datos.

El diseño conceptual parte de la especificación de requerimientos,

y produce como resultado el esquema conceptual de la base de

datos. Un esquema conceptual es una descripción a alto nivel de la

estructura de la base de datos, independientemente de la elección

del equipamiento y del Sistema Gestor de Base de Datos (en

adelante referido como SGBD) que se usen para la implementación

de la base de datos.

El diseño lógico parte del esquema conceptual y genera el esquema

lógico. Un esquema lógico es la descripción de la estructura de la


Clave Principal

Atributos

Tupla


base de datos que puede procesarse por un SGBD. Una vez elegido

el modelo lógico, pueden existir un conjunto de esquemas lógicos

equivalentes al mismo esquema conceptual. Esto incluye la

definición de atributos y llaves de las entidades. La meta del

diseño lógico es producir el esquema lógico más eficiente con

respecto a las operaciones de consulta y actualización.

El diseño físico toma como punto de partida el esquema lógico y

como resultado produce el esquema físico. Un esquema físico es

una descripción de la implementación de la base de datos en

memoria secundaria, manejo de estándares para los

nombres de base de datos, tab las, campos, datos, entre

ot ros; describe las estructuras de almacenamiento y los métodos

de acceso para acceder a los datos de una manera eficiente. Por

ello, el diseño físico se genera para un SGBD y un entorno físico

determinado.

Figura 2. Diseño de una

base de datos



En la Figura 2 se resumen las tres grandes fases del diseño de una

base de datos: primero se diseña el esquema conceptual (que se

realiza con un modelo conceptual de datos), esquema que

proporciona una descripción estable de la base de datos

(independiente del SGBD) que se vaya a utilizar; posteriormente

se pasa del esquema conceptual al modelo de datos propio de

SGBD elegido (diseño lógico); por último se eligen las estructuras

de almacenamiento, los caminos de acceso (índices), y todos los

aspectos relacionados con el diseño físico.

Figura 3. Correspondencia entre el diseño y la arquitectura

La Figura 3 muestra la correspondencia existente entre las fases

de diseño y los niveles de la arquitectura ANSI/X3/SPARC. El

diseño conceptual es una etapa previa al diseño lógico. A su vez, el

diseño lógico se corresponde con los niveles externo (donde se

definen las vistas de usuario, es decir, conjunto de información que

puede ser accedida por un usuario) y lógico (estructura de tablas

y restricciones) de la arquitectura ANSI/X3/SPARC. El diseño físico

se corresponde con el nivel físico de dicha arquitectura.



1.5. Diseño conceptual

El objetivo del diseño conceptual, también denominado modelo

conceptual, y que constituye la primera fase de diseño, es obtener

una buena representación de los recursos de información de la

empresa, con independencia de usuario o aplicaciones en particular

y fuera de consideraciones sobre eficiencia del ordenador. Consta de

dos fases:

Análisis de requisitos: Es en esta etapa donde se debe

responder a la pregunta: ¿qué representar?. Se pretende en

esta etapa elaborar un esquema descriptivo del mundo real,

mediante distintas técnicas, aunque la más usada es la de

entrevistas a los usuarios, lo que implica una descripción de los

datos mediante el uso del lenguaje natural. Los problemas que

presenta esta primera especificación, se irán refinando hasta

obtener el esquema conceptual.

Conceptualización: En esta etapa se intenta responder a la

pregunta: ¿cómo representar?. Consiste en ir refinando

sucesivamente el primer esquema descriptivo, para conseguir

pasar del mundo real al esquema descriptivo y de éste al

esquema conceptual, que deberá ser expresado sin tener en

consideración cuestiones de implementación, es decir, debe

ser independiente del SGBD a usar.

1.6. Diseño lógico

El objetivo del diseño lógico es transformar el esquema

conceptual obtenido en la fase anterior, adaptándolo al modelo de

datos en el que se apoya el SGBD que se va a utilizar.

El modelo relacional es el único modelo que ha permitido abordar la

fase de diseño lógico aplicando una teoría formal: el proceso de



normalización.

Sin embargo, la normalización no cubre toda esta fase, mostrándose

insuficiente para alcanzar todos los objetivos de la misma. En la

práctica a veces es preciso proceder a una reestructuración de las

relaciones.

La Figura 4, resume la fase de diseño lógico, en la que una vez

estructurado el esquema origen, analizando diferentes factores como

las distintas dependencias o la posibilidad de existencia de valores

nulos, se obtiene un esquema relacional, al que se añaden las

claves ajenas y otras restricciones de integridad. Ahora bien, si se

tiene en cuenta el segundo de los objetivos mencionados

anteriormente, el de que la base de datos ha de ser un servidor

operacional y eficiente de los datos, se hace necesaria una

reestructuración de relaciones, con el fin de mejorar la eficiencia de la

base de datos.

Esta reestructuración toma como entrada el esquema relacional

estructurado obtenido anteriormente, así como el análisis de los

requisitos de determinadas vistas o aplicaciones críticas, obteniendo

de esta manera un esquema relacional resultante, en el que priman

las consideraciones de eficiencia.

En la Figura 4, se detallan las dos etapas en las que se divide la

fase de diseño lógico. La primera, consistente en la estructuración

de las relaciones atendiendo a consideraciones de tipo lógico, incluye

la normalización, así como el particionamiento horizontal de las

mismas cuando sea necesario, mientras que en la segunda se

reestructuran las relaciones teniendo en cuenta consideraciones de

tipo físico que pueden llevar a la desnormalización, o al

particionamiento horizontal, vertical o mixto. La razón de esta etapa

de reestructuración se encuentra en la falta de flexibilidad de la

estructura interna de los actuales SGBD, los cuales no ofrecen los



adecuados instrumentos de diseño físico, obligando a trasladar a la

fase de diseño lógico consideraciones de eficiencia que deberían ser

ajenas a dicha fase.

Figura 4. Estructuración y reestructuración de relaciones

El objetivo de la estructuración de relaciones es obtener un esquema

relacional estructurado, tomando como entrada un esquema

relacional origen con todas sus dependencias, valores inaplicables,

etc.



En esta etapa de estructuración se conseguirá, por razones lógicas,

un esquema normalizado, en el cual se han eliminado los valores

nulos (inaplicables) mediante un particionamiento horizontal basado

en la selección, seguido de la proyección.

Las herramientas para llevar a cabo este objetivo son dos:

El proceso de normalización

El particionamiento horizontal de relaciones

El proceso de normalización consiste en sustituir una relación

por un conjunto de esquemas equivalentes, que representan la

misma información que la relación origen, pero que no presentan

cierto tipo de anomalías a la hora de realizar operaciones sobre ella,

como se muestra en la Figura 5, en la que una relación origen ha sido

sustituida por otras dos, mediante un proceso de normalización.

Figura 5. Normalización

de relaciones

En este ejemplo vemos que la Llave Codigo Empleado de la entidad

Empleados se encuentra en la entidad Pedidos y en la zona de

atributos, generando una relación de Tercera Forma Normal.



El particionamiento horizontal de relaciones, permite eliminar valores

nulos inaplicables que pueden aparecer en las relaciones mediante

un proceso de selección, seguido de proyecciones sobre las

relaciones resultantes. El resultado de este particionamiento

horizontal será la división de una relación en la que existen o

pueden existir valores nulos, en varias relaciones en las que los

valores nulos inaplicables no tienen cabida.

Entidad Origen

EmpleadoCodigo Nombre Apellido Telefono

E01 Franco Ruiz 423451E02 Fiorella Piñeiros E03 Luis Alzamora 423456E04 William Chacón E05 Jorge Cerna 428796

Entidad Resultante Entidad Resultante

Codigo Nombre Apellido TelefonoE01 Franco Ruiz 423451E03 Luis Alzamora 423456E05 Jorge Cerna 428796

Figura 6. Particionamiento horizontal de relaciones

El objetivo de la reestructuración es el de mejorar la eficiencia de la

base de datos. En la primera etapa de estructuración de relaciones,

se ha propugnado por razones lógicas, normalizar el esquema, así

como eliminar los valores nulos mediante un proceso de

particionamiento horizontal. Sin embargo, esto no quiere decir que

las relaciones que se vayan a almacenar en la base de datos

sean las resultantes de estos procesos, ya que se ha logrado el

primero de los objetivos de las bases de datos (ser una

representación fidedigna del mundo real), pero puede que no el

segundo: el de que la base de datos ha de ser un servidor

operacional y eficiente de los datos, por lo que se hace necesaria


Codigo Nombre ApellidoE02 Fiorella PiñeirosE04 William Chacón


esta segunda etapa en el diseño lógico. Para lograr este objetivo

existen diversos métodos o formas de organizar los datos,

considerando esta idea de mejora de la eficiencia, que son:

El proceso de desnormalización

El particionamiento de relaciones

El proceso de desnormalización es justamente el proceso inverso al

de normalización. La Figura 7, muestra un ejemplo en el que dos

tablas previamente normalizadas, dan origen a una tabla más grande

(que es justamente la tabla que se tenía antes de realizar la

normalización), mediante un proceso de desnormalización.

Figura 7. Desnormalización de relaciones

El particionamiento de relaciones es otra forma de conseguir una

mayor eficiencia en la base de datos. El objetivo de este proceso es

dada una relación, dividirla en otras relaciones de forma horizontal, o

vertical, o mixta (incluye ambas). A cada una de estas formas de

particionamiento se la denomina, respectivamente, particionamiento

horizontal, particionamiento vertical y particionamiento mixto.



El particionamiento horizontal de relaciones consiste en la división

de las tuplas de una relación en subconjuntos. Esto es muy útil

cuando existen consultas que acceden sólo a determinada parte de

la información dependiendo del valor de algún atributo, o en bases

de datos distribuidas, ya que cada subconjunto puede ubicarse en

distintos nodos de la red, acercándose al lugar de su tratamiento.

En el particionamiento vertical, los atributos de una relación R

son distribuidos en grupos no solapados y la relación R se

proyecta en relaciones fragmentarias de acuerdo a estos grupos

de atributos. Estos fragmentos se colocan en diferentes localizaciones

de la base de datos distribuida. Por ello, el objetivo del

particionamiento vertical es crear fragmentos verticales de una

relación de manera que minimice el coste de acceso a los elementos

de datos durante el procesamiento de la transacción. Si los

fragmentos se ajustan bien a los requisitos del conjunto de

transacciones facilitado, entonces el coste de proceso de las

transacciones podría ser minimizado. El particionamiento vertical

también puede usarse en la partición de tablas individuales en bases

de datos centralizadas, y en la división de datos entre diferentes

niveles de jerarquías de memoria, etc. En el caso de bases de datos

distribuidas, el coste de proceso de transacciones se minimiza

incrementando el proceso local de las transacciones (en un "nodo")

así como reduciendo el número de accesos a objetos de datos que no

son locales.

Como su propio nombre indica, el particionamiento mixto

engloba a ambos tipos de particionamiento (horizontal y

vertical). Consiste en aplicar un particionamiento vertical a uno o más

de los fragmentos obtenidos mediante un particionamiento horizontal,

o viceversa.



1.7. Diseño físico

El objetivo del diseño físico, que es la última fase del proceso

de diseño, es conseguir una instrumentación lo más eficiente

posible del esquema lógico. Aquí se tienen en cuenta aspectos del

hardware, requisitos de procesos, características del SGBD, del

SO y en general, cualquier factor cercano a la "maquina". Con ello

se persigue:

disminuir los tiempos de respuesta

minimizar espacio de almacenamiento

evitar las reorganizaciones

proporcionar la máxima seguridad

optimizar el consumo de recursos

la base de datos en su integridad este estandarizada

El principal problema que se plantea en la fase de diseño físico es el

debido a la poca flexibilidad de los actuales SGBD, los cuales obligan

a trasladar a la fase de diseño lógico, aspectos de carácter físico, que

deberían ser ajenos a dicha fase. Esto obliga a iterar desde la fase

de diseño físico a la de diseño lógico, y viceversa, hasta obtener

conseguir los objetivos anteriormente expuestos, lo que explica la

obligación de la etapa de reestructuración en el diseño lógico.

Como resultado del diseño físico se genera un esquema físico,

que es una descripción de la implementación de la base de

datos estandarizada en memoria secundaria; describe las

estructuras de almacenamiento y los métodos de acceso para

acceder a los datos de una manera eficiente. Por ello el diseño físico

se genera para un SGBD y un entorno físico determinado.



2. Diseño Conceptual

2.1. Introducción

Como ya se ha visto en el tema anterior, el diseño conceptual, que

constituye la primera etapa en el diseño de una base de datos,

consiste en obtener una buena representación de los recursos

de información de la empresa con independencia de usuario o

aplicaciones en particular y fuera de consideraciones sobre

eficiencia del ordenador. Puesto que no se corresponde con ningún

nivel de la arquitectura ANSI/X3/SPARC, sino que es un paso previo,

tiende a ser no tenido en cuenta a la hora de proceder al diseño de

una base de datos. Esto no es aconsejable, ya que el diseño lógico

parte del esquema conceptual y, si éste no es correcto, o no

representa fielmente la información del mundo real, el esquema de la

base de datos no será estable, viéndonos obligados a reajustarlo

constantemente debido a las deficiencias arrastradas desde esta

etapa de diseño. De ahí la importancia de realizar un buen esquema

conceptual, que represente fielmente las características del mundo

real.

Otro error que se suele cometer en esta etapa de diseño es el de

considerar aspectos tales como la eficiencia del equipo hardware en

el que se vaya a montar la base de datos, o SGBD's concretos. Como

ya se ha dicho, el esquema conceptual debe representar la

información valiosa para el sistema de información y la empresa,

fuera de consideraciones sobre hardware y sobre el SGBD sobre el

que se implementará. Por lo tanto, se pueden establecer las

siguientes características que debe cumplir un buen esquema

conceptual:



Debe representar fielmente la información del mundo real

Es independiente del SGBD

Es independiente del Hardware

Identificar las Entidades Empresariales

Identificar las Relaciones entre las Entidades Empresariales

Conviene no olvidar, por lo tanto, que un buen diseño del esquema

conceptual, influirá positivamente en el resto de etapas.

2.2. Etapas del diseño conceptual

En se debe de saber ver el mundo. La percepción del mundo debe

focalizarlo en dos elementos fundamentales; el comportamiento del

sistema y la estructura del sistema. Es este componente

específicamente el que nos interesa para el entendimiento, diseño e

implantación de la base de datos. Partiendo del lenguaje natural (en

nuestro caso el idioma castellano), encontramos en los sustantivos a

fuertes candidatos a ser parte estructural del sistema y que en un

futuro serían posibles bases de datos, tablas, campos, variables.

La fase de diseño conceptual, puede subdividirse a su vez en dos

etapas:

1. Etapa de análisis de requisitos: En esta etapa se debe

responder a la pregunta "¿Qué representar?". El objetivo es

elaborar un esquema descriptivo de la realidad, en el que se

provean detalles de los datos a representar. Dicho esquema se

obtiene mediante el estudio u observación del mundo real

(estudio de las reglas de la empresa, entrevista a los usuarios,

etc.). Aunque existen muchas respuestas sobre el modo de

recoger dicha información, la más utilizada es el lenguaje natural

que, aunque carece del formalismo que pueden infligir otros

métodos, permite una mejor y más fácil comprensión de la



información por parte del usuario, y le permite especificar los

requisitos sin la intervención de formalismos. Este primer esquema

percibido bruto, se ira refinando sucesivamente, hasta llegar al

esquema conceptual.

2. Etapa de conceptualización: En esta etapa se debe

responder a la pregunta "¿Cómo representar?" – lo percibido

del mundo. En ella se transforma el esquema obtenido en

la primera, mediante refinaciones sucesivas. Se deberá

obtener el esquema conceptual mediante una

representación formal del caso, haciendo uso de la técnica

Entidad Relación con la cual podremos representar las Entidades

Empresariales y sus Relaciones entre ellas, de los objetos o

estructuras valiosas para la empresa y el sistema de información.

2.3. El modelo entidad / relación

El modelo E/R fue propuesto por Peter P. Chen en dos artículos que

publicó en los años 1976 y 1977. En ellos define dicho modelo como

una vista unificada de los datos, centrándose en la estructura

lógica y abstracta de los datos, como representación del

mundo real, con independencia de consideraciones de tipo físico.

Posteriormente se fueron proponiendo nuevas aportaciones al

modelo, lo cual explica que no exista uno sólo, sino distintos modelos

según los autores.

A continuación se describirá el proceso de creación de un esquema

conceptual, siguiendo el modelo E/R. Éste se basa en una

representación gráfica de una serie de entidades relacionadas entre

sí. Al utilizar una representación de este tipo, el modelo E/R permite

distinguir fácilmente y a simple vista, las relaciones existentes entre

las distintas entidades. Existen muchas formas de representarlo,

como ya se ha comentado; la que se utilizará aquí no es, por

supuesto, la única forma de hacerlo. Los elementos de los que se



componen son los siguientes:

1. Entidades: Una entidad es "una persona, lugar, cosa, concepto o

suceso, real o abstracto, de interés para la empresa" (ANSI

1977). En el modelo E/R, se representa por un rectángulo,

con el nombre de dicha entidad escrito en la parte superior. Por

ejemplo, la Figura 8 representa la entidad automóvil. Una Entidad

es originada en el Lenguaje Natural a través del Sustantivo.

Figura 8

2. Atributos: Un atributo es cualquier característica que describe a

una entidad. Los atributos de una entidad se colocan dentro del

rectángulo que representa dicha entidad, justo debajo del nombre

de ésta. Por ejemplo, se puede decir que Pedido tiene las

siguientes características: Numero Pedido, Codigo Empleado,

Fecha Pedido, Nombres Cliente, Total Pedido, Total IGV, lo cual

se muestra en la Figura 9.

Figura 9

3. Clave: La clave de una entidad es un atributo o conjunto de

atributos de dicha entidad, que son capaces de identificar

unívocamente una ocurrencia de una entidad. Es decir, si

conocemos el valor de dichos atributos, seremos capaces de

conocer a que ocurrencia de entidad, entre todas las posibles,

hace referencia. Esto implica que los valores de los atributos

clave no se pueden repetir para dos ocurrencias de la misma



entidad. En nuestro ejemplo, seremos capaces de identificar de

que Pedido estamos hablando, con sólo conocer el valor del

atributo Numero Pedido, ya que no existe un mismo Pedido.

Figura 10

4. Relación: Una relación representa, una correspondencia entre

dos entidades. Si tenemos dos entidades Pedidos y Empleados,

podemos tener una relación entre ellas. Dicha relación se puede

establecer en ambos sentidos:

Un Pedido es atendido por un Empleado, y

Un Empleado atiende uno o muchos Pedidos.

Figura 11

5. Cardinalidad de una relación: La cardinalidad de una relación

representa el número de ocurrencias que se pueden dar de una

relación. A continuación se presentan los símbolos utilizados, en

base a la metodología de la Ingeniería de la Información.


Llave Primaria


Cardinalidad 1: Existe una ocurrencia en la entidad. Se

representa como indica la Figura 12.

Figura 12

Cardinalidad Ninguno: No ex is te a lguna ocur renc ia

en la en t idad . Se representa como muestra la Figura 13.

Figura 13

Cardinalidad Muchos: Existe más de una ocurrencia en la

entidad. Se representa como muestra la Figura 14.

Figura 14

Estos conceptos de Cardinalidad, son aplicados para representar

la relación que existe entre dos entidades de manera recíproca. A

continuación citaremos algunos ejemplos.

Un Pedido es elaborado por Un Empleado

Un Empleado atiende Uno o Muchos Pedidos



Un Cliente tiene Ninguna, Una o Muchas Facturas

Una Factura pertenece a Un Cliente

2.4. Ejemplo de un modelo conceptual



3. Diseño Lógico

3.1 Introducción

Para elaborar el Diseño Lógico de la Base de Datos, tomamos como

referencia y punto de partida el Modelo Conceptual obtenido en la

sección anterior. Con el propósito de tener una estructura lógica, en

esta etapa se amplia el contenido de las entidades empresariales con

sus correspondientes llaves principales, llaves foráneas, atributos y

relaciones, convirtiéndose en las nuevas entidades dato haciendo

uso de la técnica de Normalización. A continuación se tienen

aspectos más ligados con el nivel físico y consiste en modificar el

esquema obtenido en la fase anterior para adaptarlo a

consideraciones de eficiencia, utilizando las técnicas de partición

horizontal y partición vertical.

3.2. Paso del diseño conceptual al diseño lógico

Lo primero que hay que realizar en la fase de diseño lógico, es

obtener el esquema lógico estándar, a partir del esquema conceptual

obtenido en la primera fase. Las reglas que permiten pasar del

modelo E/R al esquema lógico, son las que a continuación se

explican:

Cada entidad empresarial se transforma en una entidad

dato: esto es, cada entidad dato contiene su l lave primaria,

l lave foránea, atributos y relaciones.

Cada relación M u c h o s a M u c h o s ( N-M) genera una

e n t i d a d : las relaciones entre entidades con cardinalidad N-M

generan una entidad, con los atributos clave de ambas entidades.

(Relación de asociación)

Cada relación de Uno a Muchos (1-N) importa las claves de la

entidad con las que se relaciona: cada relación con cardinalidad 1-

N importa los atributos clave que contiene la entidad con



cardinalidad N.

Cada relación dependiente, importa la clave de la otra entidad,

como clave.

3.3 Etapas en el diseño lógico

Como ya se ha comentado, la fase de diseño lógico de una base de

datos consiste en dos etapas:

Etapa de estructuración: donde el objetivo primordial es

encontrar un esquema que sea una representación fidedigna

del mundo real. La forma de lograrlo es mediante el proceso de

normalización.

Etapa de reestructuración: donde se tienen en cuenta aspectos

más ligados con el nivel físico, y que consiste el modificar el

esquema obtenido en la fase anterior para adaptarlo a las

consideraciones de eficiencia. Esta etapa, que debería ser ajena

al diseño lógico, se considera aquí debido a la falta de

flexibilidad de los SGBD, obligando a trasladar a esta etapa

aspectos mas relacionados con el nivel físico. La forma de

lograrlo es mediante la desnormalización, y el particionamiento,

bien sea horizontal y vertical.

3.4. Proceso de Normalización

El proceso de normalización consiste en la aplicación de un

conjunto de reglas, con el objeto de verificar que el esquema

relacional obtenido en esta fase cumple un cierto conjunto de

reglas. La normalización se podría considerar prácticamente como

el grueso de la fase de diseño lógico, ya que es el encargado de

modificar el esquema conceptual obtenido en la fase anterior, para

que cumpla el primero de los objetivos de las bases de datos, el de

que ha de representar fielmente la realidad.



La normalización se puede definir como el proceso de sustituir una

relación o tabla, por un conjunto de esquemas equivalentes que

representen la misma información, pero que no presenten cierto tipo

de anomalías a la hora de realizar operaciones sobre ella.

El proceso de normalización, por lo menos debe de constar de tres

etapas:

Primer Forma Normal (1FN). Una entidad esta en 1FN, cuando

sus atributos tienen la relación de 1 a 1 con la llave primaria.

En este ejemplo de la entidad Empleados, los atributos tienen la

relación de 1 a 1 con la llave primaria Codigo Empleado.

Nombre Empleado Codigo Empleado

Apellidos Empleado Codigo Empleado

Numero Telefono Codigo Empleado



Segunda Forma Normal (2FN). Cuando un atributo se relaciona

con la llave primaria de uno a muchos, este atributo da origen a

otra entidad.

Un Pedido Tiene Uno o Muchos Detalles Pedido

Al existir este tipo de relación entonces detalle de pedido se

convierte en otra entidad con sus propios atributos, teniendo

como entidad padre a pedidos.

Tercer Forma Normal (3FN). Una entidad se encuentra en

tercer forma normal cuando la llave principal de esta se

encuentra en otra entidad y en la zona de atributos y no en la

zona de llave principal.



3.5. Proceso de desnormalización

El proceso de desnormalización hace referencia justo al proceso

inverso de normalización que se acaba de ver. En estos momentos,

el lector puede preguntarse que para qué se procede a normalizar un

esquema, cuando posteriormente se va a desnormalizar, es decir, a

dejarlo como estaba. La respuesta es simple; primero se procede

a estructurar el esquema, y una parte de esta estructuración es la

normalización de relaciones. Posteriormente, y debido a aspectos de

eficiencia, se puede proceder a realizar una reestructuración del

esquema, parte de la cual supone la desnormalización del mismo.

Esto supone que puede que el esquema resultante de la

normalización sea lo suficientemente eficiente como para que no sea

preciso reestructurarlo, o que simplemente no nos interese que el

esquema sea eficiente. Además, puede que normalicemos hasta un

cierto nivel, y que solo interese desnormalizar hasta otro

determinado nivel. En definitiva, el proceso de desnormalización

supone la unión de varias relaciones en un número menor de ellas,

es decir, a medida que disminuya el nivel de normalización, es

frecuente que el número de relaciones disminuya.

3.6. Particionamiento horizontal de entidades

Como su propio nombre indica, el particionamiento horizontal

consiste en dividir longitudinalmente las filas que forman una tabla,

esto es, separar las filas que conforman una relación, para llevarlas

a otra. Para entenderlo mejor, supóngase el siguiente ejemplo en el

que se tiene la tabla publicación, con los siguientes campos:

cod_publicación, título, autor, editorial.

En un momento dado, la información que tenemos en la tabla es la

mostrada en la Tabla 1.



EmpleadoCodigo Nombre Apellido Telefono

E01 Franco Ruiz 423451E02 Fiorella Piñeiros E03 Luis Alzamora 423456E04 William Chacón E05 Jorge Cerna 428796

Tenemos información sobre dos tres empleados de manera

completa, con información de Codigo, Nombre, Apellido y su

Telefono. Existen otros dos empleados que no tienen

información completa, solo tienen Codigo, Nombre y Apellido.

En este caso, podría ser conveniente "partir" dicha tabla

horizontalmente en otras dos, es decir llevar parte de la información a

una tabla, y parte a otra.

Codigo Nombre Apellido TelefonoE01 Franco Ruiz 423451E03 Luis Alzamora 423456E05 Jorge Cerna 428796

Esta entidad contiene información de los empleados que tienen

Telefono, eliminándose así el criterio de campos nulos.

Codigo Nombre ApellidoE02 Fiorella PiñeirosE04 William Chacón

Esta otra entidad contiene ionformación de los empleados que no

tienen telefono.

Con esto, lo que hemos conseguido es eliminar la existencia de

valores nulos no aplicables. Un valor nulo es aquel que representa

información desconocida, inexistente o no válida (en nuestro caso el

valor del atributo telefono en algunos empleados). Los valores nulos

pueden ser aplicables o no aplicables. Mientras los no aplicables no

cambian, es decir, permanecen nulos, los aplicables pueden dejar

de serlo en algún momento.



3.7. Particionamiento vertical de relaciones

El particionamiento vertical de relaciones consiste, al contrario que

en el caso del particionamiento horizontal, en dividir las tablas de

forma transversal, es decir, crear nuevas tablas con la información

correspondiente a un subconjunto de los atributos de las

mismas, pero manteniendo intacta la información correspondiente

a las filas. Veamos un ejemplo para comprenderlo mejor. Supóngase

que tenemos la tabla reparto con la información de todos los repartos

realizados por los proveedores a los clientes. La información que

tenemos de dicha tabla (Tabla 5) es: codigo proveedor, codigo

cliente, codigo material, nombre proveedor, nombre cliente, ciudad

proveedor, ciudad cliente y cantidad.

Codigo Proveedor

Codigo Cliente

Codigo Material

Nombre Proveedor

Nombre Cliente

Ciudad Proveedor

Ciudad Cliente

Cantidad

P01 C01 M01 Alberto Teresa Lima Piura 60P02 C02 M02 Pedro Marianella Huaraz Lima 50P03 C03 M03 Rosa Daniel Trujillo Tacna 40

Dada la Tabla 5, podría interesarnos tener varias tablas: una

que contenga la información del proveedor, con los atributos

nombre proveedor y ciudad proveedor, otra con la información del

cliente con los atributos nombre cliente, ciudad cliente y cantidad.

Para ello realizamos un particionamiento vertical, sobre estos

atributos.

Codigo Cliente

Nombre Cliente

Ciudad Cliente

Cantidad

C01 Teresa Piura 60C02 Marianella Lima 50C03 Daniel Tacna 40


Codigo Proveedor

Nombre Proveedor

Ciudad Proveedor

P01 Alberto LimaP02 Pedro HuarazP03 Rosa Trujillo


El resultado es que tenemos el mismo número de filas en todas las

tablas, pero más entidades con menos atributos. Este proceso

ofrecen ventajas relacionadas con la eficiencia.

3.8. Ejemplo de Diseño Lógico



4. Diseño Físico

4.1. Introducción

El diseño físico busca conseguir una instrumentación lo más

eficiente posible del esquema lógico, considerando los aspectos

más cercanos al hardware, es decir, los requisitos de

procesos, características del SGBD, del Sistema Operativo y del

hardware, pretendiendo los siguientes objetivos:

Disminuir los tiempos de respuesta

Minimizar espacio de almacenamiento

Evitar las reorganizaciones

Proporcionar la máxima seguridad

Optimizar el consumo de recursos

Como ya se ha comentado, debido a la falta de flexibilidad de los

actuales SGBD, es preciso llevar a cabo a cabo en muchas

ocasiones un proceso de reestructuración de relaciones para

conseguir una mayor eficiencia, lo que significa que se debe iterar

desde el diseño lógico específico al físico y viceversa, hasta

obtener un esquema aceptable, que optimice el ratio coste /

beneficios.

El diseño físico es fuertemente dependiente del producto comercial

que se vaya a usar, debido a la carencia de un modelo formal,

equivalente al relacional que permita una definición formal de esa

fase de diseño. Sin embargo, existen características que son

comunes a la mayoría de los productos, y que pueden ser utilizadas

para definir un esquema físico.



Se podría considerar el diseño físico como una caja negra, en la

que se toman como entradas los recursos de la máquina, los

recursos lógicos (SO, etc.), el esquema lógico obtenido en la fase

anterior, información sobre las aplicaciones que se ejecutarán en

la máquina así como los objetivos que se plantean en esta fase,

y se obtienen como salidas una estructura interna, que

representa la implementación del esquema lógico en un hardware

específico, junto con unas normas de seguridad y unas

especificaciones para el ajuste, es decir, la forma de iterar entre

la etapa de diseño lógico específico y la fase de diseño físico.

4.2. Estrategias en el diseño físico

Existen tres tipos de estrategias que los fabricantes de SGBD

imponen en sus productos comerciales:

1. Inflexibilidad. El SGBD impone una estructura interna, impidiendo y

dejando al administrador pocas opciones de cambiarlo. La

principal ventaja de esta estrategia es la independencia físico

/ lógica del esquema, aunque por contra, el esquema interno

resultará más ineficiente.

2. Flexibilidad. Es el contrapunto al anterior caso. Implica que el

administrador de la base de datos pueda diseñar la estructura

interna, lo cual supone un aumento de la eficiencia, aunque

también de la dependencia físico / lógica.

3. Híbrido entre ambos. El SGBD proporciona una estructura interna

opcional que el diseñador puede cambiar con el fin de mejorar la

eficiencia. Entre las ventajas que supone utilizar esta técnica

estriba la de que la BD puede empezar a funcionar de

inmediato al disponer del esquema interno opcional, con la

posibilidad de ir mejorando sucesivamente la eficiencia al ir



realizando ajustes, a la par que se mantiene la independencia.

Destacar que esta es la estrategia más utilizada en los actuales

SGBD.

4.3. Conceptos básicos sobre gestión de ficheros

La unidad básica de las estructuras físicas (ficheros) es el registro

físico, también denominado página o bloque, que es la unidad mínima

que puede tratarse en una operación de Entrada / salida. Las tuplas

(en el caso del modelo relacional) se almacenan en dichos registros,

pudiendo almacenar cada uno de éstos varias de aquellas. De aquí

podemos definir el factor de bloqueo para un fichero como el número

de registros lógicos (o tuplas) por bloque para dicho fichero. Del

mismo modo, si los datos son muy grandes, un registro lógico

puede estar almacenado en varios registros físicos. El tamaño de

los bloques depende del producto comercial y del sistema operativo,

oscilando éste entre 2 y 4 Kbytes.

Los bloques, que se encuentran almacenados en los sectores del

disco, deben ser accedidos por el SGBD utilizando los mecanismos

de gestión de ficheros que provee el sistema operativo. El tiempo en

acceder a un sector del disco, que es bastante elevado, está

compuesto por varios factores:

Tiempo de arranque: tiempo que tarda el disco en empezar a

mover las cabezas.

Tiempo de seek: tiempo necesario para mover las cabezas al

cilindro (conjunto de pistas del mismo diámetro) requerido.

Tiempo de latencia: tiempo que debe esperar hasta que el

sector para por debajo de las cabezas.

Tiempo de transferencia: tiempo necesario para transferir la

información, por el bus de datos, a memoria principal.



Para acelerar este proceso, se suele usar un dispositivo de

almacenamiento intermedio, denominado caché o buffer, cuyo

cometido es el de almacenar los datos más usados, aprovechando de

este modo la ley de proximidad temporal, es decir, los datos que han

sido usados más recientemente, tienen una alta probabilidad de

que sean usados en un futuro cercano, evitando de este modo

accesos extra a disco. Este dispositivo es gestionado por el sistema

operativo, utilizando diversas políticas, entre la que la más usada es

la LRU (Least Recently Used), es decir, los bloques que se han

usado hace más tiempo, son candidatos a desalojar la caché para

albergar otros bloques. Otra política es aprovechar la ley de

proximidad referencial, es decir, los datos próximos tienen

mayor probabilidad de ser referenciados.

Algunos SGBD permiten especificar las características de los

registros físicos. Se pueden agrupar determinado número de

bloques contiguos en unidades llamadas extensiones. Los

parámetros que se pueden especificar son:

El porcentaje de espacio libre que se deja en cada bloque

para albergar posteriores actualizaciones de los registros

lógicos. Al modificar un valor de un atributo, puede que éste no

quepa en el espacio reservado. De esta forma se evita la

concatenación de bloques, que incide en un menor tiempo de

respuesta.

Número de bloques que se asignan a las extensiones.

Porcentaje de utilización de cada bloque.



4.4. Organización de ficheros

Existen varias formas de organizar los ficheros, de forma que el

acceso a los mismos se realice de una y otra forma:

Secuencial: El método de acceso es secuencial, es decir, un

registro detrás de otro. Es conveniente usar esta forma de

organización cuando existe una carga masiva de datos, las

tablas son pequeñas o cuando se accede a casi todas las filas,

es decir, un índice (ya se verá más adelante lo que es)

estorbaría, ya que de todas maneras se necesita acceder a

todas las filas.

Hash: Es una forma de organizar los ficheros teniendo como

base una tabla indexada que apunta a la información. Es útil

cuando las filas se recuperan por el valor de la clave, que en este

caso actúa como función para determinar la posición donde se

encuentra la información.

ISAM: Es una opción más amplia que la anterior, ya que soporta

búsquedas por valores de clave, además de por parte de ella o

usando patrones de búsqueda.

Árbol B+: Es una estructura que soporta búsquedas dicotómicas

(el número de búsquedas es menor que log2 n). La ventaja con

respecto al caso anterior es que crece de forma dinámica.

4.5. Técnicas para el aumento de eficiencia

Existen varias técnicas para aumentar la eficiencia del esquema:

Índices: Se puede definir un índice como una estructura que sirve

para mejorar la eficiencia de las consultas a una base de datos.

Un índice se define sobre uno o varios atributos. A la hora de

acceder a dichos atributos, el tiempo de acceso será

instantáneo. Un índice se puede comparar con el índice de un

libro; si disponemos de dicho índice, podemos acceder a la



página del libro de forma inmediata, mientras que si no lo

tenemos, deberemos ir mirando hoja por hoja hasta encontrar

la página deseada. Por ejemplo, supóngase que tenemos la

relación que muestra la Tabla 24.

Codigo jugador

Nombre Apellido Equipo

10 Adrián Torres Sport Valencia20 Fernando Alva Atlético Madrid25 José Fausto Barcelona30 Claudio Ramírez Sport Valencia49 Fernando Rojas Real madrid80 Rafael Villar Ateltico Bilbao

90 Rafael AlvaradoDeportivo Coruña

Tabla 24

Si en este momento se desea hacer una consulta sobre todos

los jugadores que se llamen Fernando, se deberá acceder a

todas las filas, encontrándose dos jugadores que cumplen este

requisito, es decir, se han realizado siete accesos. Sin embargo,

si se dispone de un índice por el atributo Nombre, los accesos

serían inmediatos a las dos únicas filas que cumplen este

requisito, reduciéndose en este caso el número de accesos a

dos. Si ahora se desea buscar todas las filas con el nombre de

Rafael, y que pertenezcan al Deportivo Coruña, se realizarían

siete accesos (toda la tabla). Si tuviésemos un índice por el

atributo Nombre, se encontraría una única fila, pero se debería

acceder a dos, es decir, las filas cuyo nombre es Rafael. Sin

embargo si tuviésemos un índice combinado para los atributos

Nombre y Equipo, solo se realizaría un acceso, la de nombre

Rafael y equipo Deportivo Coruña.

Ya se ha visto entonces la ventaja de usar este tipo de

estructuras para acceder rápidamente a la información. Sin

embargo no todo son ventajas, ya que cuanto mayor sea esta

estructura, mayor espacio de almacenamiento será necesario,



sin contar el tiempo que se pierde en actualizar el índice

cuando se modifica algún valor de los atributos que forman parte

de él. Por este motivo, se suele indexar la clave primaria

(mediante un índice único, es decir, que no permita valores

repetidos), o aquellos atributos que no vayan a ser modificados.

La siguiente lista resume una serie de consejos a la hora de

indexar campos:

a. Indexar la clave primaria con un índice único

b. Indexar las claves ajenas, es decir los atributos de una tabla

que son clave que otras tablas

c. Indexar aquellos atributos que se van a consultar con más

frecuencia, y que no van a ser alterados

d. No indexar tablas pequeñas

e. No indexar tablas que se van a recorrer secuencialmente

f. No indexar atributos de tipo carácter muy largos

Agrupamiento o "clustering": Se entiende por "clustering" de

tablas la agrupación de tablas cuyas filas comparten un grupo

de atributos llamado clave de agrupamiento. Esta técnica

supone una desnormalización física de las tablas, que se

encuentran físicamente agrupadas, pero que lógicamente siguen

siendo dos tablas independientes, por lo que el agrupamiento será

transparente al usuario. La Figura 35 muestra un agrupamiento de

dos relaciones Empleado y Departamento.



Figura

Con este método se consigue mejorar la eficiencia en la consulta

simultánea de ambas tablas, pero empeora cuando se recorren de

forma separada.

Compresión de datos: Por un lado, la compresión de datos

permite reducir el espacio requerido para almacenar la

información, lo que radica en un menor número de operaciones de

Entrada / salida. Sin embargo, se requiere un mayor tiempo de

proceso debido a la necesidad de descomprimir los datos que se

recuperan.

La técnica de compresión más utilizada es la de compresión

diferencial, que consiste en almacenar la diferencia entre el valor

de un atributo y el que le precede.

Redundancia de datos: La redundancia de datos consiste en

duplicar el valor de ciertos atributos de una tabla en otra, con el

fin de evitar accesos a tablas consultadas frecuentemente. Sin

embargo, esta redundancia debe ser controlada, es decir, se debe

garantizar la consistencia de la base de datos. La forma más

segura de controlarlo es mediante disparadores o triggers, que



cambien el valor de todos los atributos duplicados, cuando cambia

uno de éstos.

5. Descripción del caso

Para un mejor entendimiento del marco teórico sobre modelamiento e

implantación de las bases de datos, presentamos a continuación el caso

Tienda para el Hogar “Casa y Familia”, con el cual complementaremos de

manera práctica los temas de modelamiento e implantación de las bases de

datos.

Tienda para el Hogar “Casa y Familia”, es una empresa que vende

productos para la construcción, mantenimiento y arreglo de la casa. El

Proceso de “Atención de Pedidos del Cliente”, se detalla a continuación:

El Cliente, antes de hacer su pedido tiene la opción de revisar el “Catalogo

de Productos”, los cuales están ordenados por Familia de Productos, por

ejemplo:

CATALOGO DE PRODUCTOS

Familia de Productos: Pinturas

Código Nombre Precio Stock

P01 Pintura de interior marca ABC 15.00 100

P02 Pintura de interior marca SOFT 14.00 90

P03 Pintura de exterior marca ABC 17.00 85

P04 Pintura de exterior marca OUT 19.00 55

Familia de Productos: Jardín


J01 Ficus Argentino 3.00 30



J02 Ficus Semi enano 4.00 45

J03 Molle Serrano 7.00 30

J04 Mini schefflera variegada 8.00 35

Familia de Productos: Terrazas


T01 Mesa Tayroma II Blanco 70.00 60

T02 Silla Minikid 8.00 30

T03 Parrilla a gas 350.00 45

Una vez que el cliente sabe que pedido va efectuar, se acerca a caja, hace

su pedido, cancela y recibe una boleta o factura para reclamar su compra.

Luego de unos minutos de espera, es llamado a despacho para que se le

entregue la mercadería, previa verificación de la boleta o factura cancelada.

El formato de pedido, se muestra a continuación.

PEDIDOS DEL CLIENTE

Nº Pedido : Fecha :

Empleado :

Cliente :

Código Producto Nombre Producto Cantidad Precio Total

Total IGV : Total:

Actualmente todo el proceso de “Atención de pedidos del cliente”, se

desarrolla manualmente y presenta los siguientes problemas:



El proceso de “Atención de pedidos del cliente”, se desarrolla

lentamente, lo cual genera descontento en los clientes.

Se utilizan muchos “Catálogos de Precios”, en formatos físicos. Estos

debido a la mucha manipulación, son deteriorados rápidamente.

La elaboración de informes para el gerente de comercialización es lenta

y lo ejecutan dos asistentes.

No se elaboran estadísticas para el análisis de la información y la toma

de decisiones

El inventario físico no tiene relación con el inventario lógico, que figura

en las tarjetas manuales de los productos.

Las acciones de este proceso se desarrollan bajo la siguiente regla del

negocio. El pago de las compras efectuadas por los clientes es al contado y

en efectivo y en moneda nacional.

La empresa cuenta con tres empleados de ventas, se los cuales sus datos

se registran en la ficha de personal.

Código de

empleado

Nombres de

empleado

Apellidos de

empleado

Número de

teléfono

E01 Franco Ruiz 426589

E02 Fiorella Piñeiros 423546

E03 Antonio Torrealva 427654

Tienda para el Hogar “Casa y Familia”, atiende un promedio de 100 clientes

por hora con gran tendencia a aumentar, por lo que es necesario

implementar un “Sistemas de información de atención de pedidos al cliente”

que apoye al proceso de “Atención de pedidos del cliente” y valore la

información utilizada en este proceso.



6. Modelo de base de datos en el ciclo de vida del software

Sabemos que todo ciclo de software tiene las siguientes fases:

Análisis del sistema

Diseño del software

Construcción del software

Mantenimiento del software

En la etapa de diseño del software se requiere modelar; tanto el

comportamiento del software, expresado por el modelo de las aplicaciones y

la estructura del software expresado por el modelo de la base de datos.

En el proceso de modelamiento de la base de datos, se tienen que llevar a

cabo las siguientes actividades de modelamiento:

Modelamiento conceptual de la base de datos

Modelamiento lógico de la base de datos

Modelamiento físico de la base de datos

7. Modelo conceptual de la base de datos

En esta actividad lo que se pretende es identificar las entidades del negocio

así como las relaciones existente entre estas. No es necesario identificar los

atributos, llaves primarias, ni llaves foráneas.

Para el caso tienda para el Hogar “Casa y Familia”, se identificaron las

siguientes entidades:

Familia productos

Producto

Empleados

Pedido



Y estas se relacionan, tal como se muestran a continuación:

Una Familia de productos TIENE Uno o Muchos Productos

Un Producto PERTENECE a Una Familia de productos

Un Pedido ES ATENDIDO por Un Empleado

Un Empleado ATIENDE Uno o Muchos Pedidos

Un Pedido TIENE Uno o Muchos Productos

Un Producto PERTENECE a Uno o Muchos Pedidos

Estas entidades y sus relaciones se pueden modelar en la herramientas

CASE (Ingeniería de Software Asistido por Computador) ERWIN 3.5.2 o

superior, tal como se muestran en el siguiente diagrama.

Modelo Conceptual

Tienda para el Hogar "Casa y Familia"

Modelo Entida Relación

Atiende

Es Atendido

TienePertenece

Pertenece

Tiene

Pedido Empleados

ProductosFamilia productos



8. Modelo lógico de la base de datos

Una vez obtenido el modelo conceptual de la base de datos se comienza

con la actividad de Normalización. Se detallan las Entidades con sus

atributos y llaves primarias (Primera Forma Normal), así como las

relaciones entre las Entidades (Segunda y Tercera Forma Normal).

Para el caso tienda para el Hogar “Casa y Familia”, se tienen las siguientes

entidades con sus atributos, llaves primarias y llaves foráneas:

Entidad Familias Producto

Código de familia PK

Nombre de la familia

Entidad Productos

Código de producto PK

Nombre de producto

Precio de producto

Stock

Entidad Empleados

Código de empleado PK

Nombres de empleado

Apellidos de empleado

Número de teléfono

Entidad Pedidos

Número de pedido PK

Código de empleado

Fecha de pedido

Nombres del cliente

Total del pedido

Total IGV del pedido

Entidad Detalles del pedido

Número de pedido PK

Código de producto PK

Cantidad del producto

Total producto

Y estas se relacionan, tal como se muestran a continuación:

Una Familia de productos TIENE Uno o Muchos Productos

Un Producto PERTENECE a Una Familia de productos



Un Pedido ES ATENDIDO por Un Empleado

Un Empleado ATIENDE Uno o Muchos Pedidos

Un Pedido TIENE Uno o Muchos Productos

Un Producto PERTENECE a Uno o Muchos Pedidos

Un Pedido TIENE Uno o Muchos Detalles Pedido

Un Detalle Pedido PERTENECE a Un Pedido

Estas entidades y sus atributos así como sus relaciones se pueden modelar

en la herramientas CASE (Ingeniería de Software Asistido por Computador),

tal como se muestran en el siguiente diagrama.

Pertenece

Tiene

PerteneceTiene

Es Atendido

Atiende

PerteneceTiene

Modelo Lógico


Modelo Entidad Relación

Detalles PedidoNumero Pedido (FK)Codigo Producto (FK)

Cantidad ProductoTotal Producto

PedidosNumero Pedido

Codigo Empleado (FK)Fecha PedidoNombres ClienteTotal PedidoTotal IGV

EmpleadosCodigo Empleado

Nombre EmpleadoApellidos EmpleadoNumero Telefono

ProductoCodigo Producto

Codigo Familia (FK)Nombre ProductoPrecioStock

FamiliaCodigo Familia

Nombre Famila



9. Modelo físico de la base de datos

Una vez obtenido el modelo lógico de la base de datos, se determinan los

nombres de las entidades, nombres de los atributos y tipos de datos de

acuerdo a ciertos estándares con el propósito de dejar expedita la base de

datos para implantarla en un DBMS.

Previamente se han definido ciertos estándares para dar los nombres a las

tablas y atributos:

Las Tablas Principales, empiezan sus nombres con TP.

Las Tablas Transaccionales, empiezan sus nombres con TT

Además se ha elaborado una serie de prefijos:

Prefijo Nombre

Cod Código

Nom Nombre

Mon Monto

Can Cantidad

Ape Apellido

Num Número

Para el caso tienda para el Hogar “Casa y Familia”, se tienen las siguientes

entidades con sus atributos, llaves primarias y llaves foráneas en el modelo

físico.

Nombre Lógico: Familia Nombre Físico: TP_FamiliaProducto

Campo lógico Campo físico Tipo de dato Regla

Código de familia Cod_FamiliaProducto Char(3) Not Null

Nombre de la familia Nom_FamiliaProducto Varchar(30) Not Null

Nombre Lógico: Producto Nombre Físico: TP_Producto




Código de producto Cod_Producto Char(3) Not Null

Nombre de producto Nom_Producto Varchar(30) Not Null

Precio de producto Mon_Precio Money Null

Stock Can_Stock Int Null

Nombre Lógico: Empleado Nombre Físico: TP_Empleado


Código de empleado Cod_Empleado Char(3) Not Null

Nombres de empleado Nom_Empleado Varchar(20) Not Null

Apellidos de empleado Ape_Empleado Varchar(20) Not Null

Número de teléfono Num_Telefono Char(14) Null

Nombre Lógico: Pedido Nombre Físico: TT_Pedido


Número de pedido Num_Pedido Char(4) Not Null

Código de empleado Cod_Empleado Char(3) Not Null

Fecha de pedido Fec_Pedido Datetime Null

Nombres del cliente Nom_Cliente Varchar(30) Null

Total del pedido Mon_TotalPedido Money Null

Total IGV del pedido Mon_IGVPedido Money Null

Nombre Lógico: Detalle Pedido Nombre Físico: TT_DetallePedido


Número de pedido Num_Pedido Char(4) Not Null

Código de producto Cod_Producto Char(3) Not Null

Cantidad del producto Can_Pedido Int Null

Total producto Mon_SubTotal Int Null



El modelo físico de la base de datos, fue diseñado con la herramienta

ERWIN y se muestra a continuación

Modelo Físico


Modelo Entidad Relación

Atiende

Es Atendido

PerteneceTiene

Pertenece

Tiene

PerteneceTiene

TP_FamiliaProductosCod_FamiliaProducto: char(3)

Nom_FamiliaProducto: varchar(30)

TT_DetallePedidoNum_Pedido: char(4)Cod_Producto: char(3)

Can_Pedido: intMon_SubTotal: money

TP_EmpleadoCod_Empleado: char(3)

Nom_Empleado: varchar(20)Ape_Empleado: varchar(20)Num_Telefono: char(14)

TT_PedidoNum_Pedido: char(4)

Cod_Empleado: char(3)Fec_Pedido: datetimeNom_Cliente: varchar(30)Mon_TotalPedido: moneyMon_IGVPedido: money

TP_ProductoCod_Producto: char(3)

Cod_FamiliaProducto: char(3)Nom_Producto: varchar(30)Mon_Precio: intCan_Stock: char(18)

Este Modelo Físico esta expedito para implantar la base de datos para la

Tienda para el Hogar “Casa y Familia”. Para ello vamos a contar con la

herramienta DBMS SQL Server.



10.Acceso a las herramientas del DBMS – SQL Server

Previamente a la implantación de la base de datos en el DBMS SQL Server,

es necesario activar ciertos servicios y herramientas de esta. A continuación

mostraremos como se activan dichos servicios y herramientas de manera

detallada.

10.1.Confirmar que el Administrador de Servicios de SQL Server esta

activado, tal como se muestra a continuación.

Esto significa que, el Servidor este activado, en este caso SISTEMAS

así como el Servicio SQL Server actualizado. Si todo es correcto

visualizará en la parte izquierda de la barra de herramientas de la

pantalla un símbolo similar a:



10.2.Inicializar la opción Enterprise Manager, teniendo en cuenta la

siguiente ruta:

Inicio / Todos los programas / Microsoft SQL Server / Administrador Corporativo

Se ingresará al SQL Server Enterprise Manager. Mostrándose la

siguiente pantalla.



Se tendrá que activar Servidores Microsoft SQL Server, Grupo de SQL

Server y el Servidor (Dando Clic al signo + que tienen cada uno de

estos, deberá mostrarse esta pantalla.

10.3.Inicializar la opción Analizador de Consultas, teniendo en cuenta la

siguiente ruta:

Inicio / Todos los programas / Microsoft SQL Server / Analizador de consultas



Se ingresará al Analizador de Consultas. Mostrándose la siguiente

pantalla.



11. Implantación de la base de datos mediante Transact / SQL

La implantación de la base de datos es una actividad que se lleva a cabo

con algún tipo de herramienta DBMS, en nuestro caso utilizaremos el SQL

Server 2000, específicamente Transact / SQL del Analizador de Consultas.

El implantar la base de datos consta de: Implantar la Base de Datos, Crear

las Tablas (En el modelamiento se les llamaba Entidades), Crear las Llaves

Primarias y las Llaves Foráneas (Relaciones).

A continuación mostraremos las actividades necesarias para la Implantación

de la Base de Datos.

11.1 En el Analizador de Consultas escribir las líneas de código (LDC)

necesarias para crear la Base de Datos. En este caso crearemos la

Base de Datos BDCasa. Previamente se tendrá que crear la carpeta:

C: \ Data

CREATE DATABASE BDCasa

ON

PRIMARY (NAME = BDCasa_data,

FILENAME='c:\Data\BDCasa.mdf',

SIZE= 8,

MAXSIZE=10,

FILEGROWTH=25%)

LOG ON

(NAME = BDCasa_log,

FILENAME='c:\Data\BDCasa.ldf',

SIZE= 3,

MAXSIZE=5,

FILEGROWTH=1 mb)



Posteriormente presionar F5, para ejecutar las líneas de código,

mostrándose a continuación la conformidad de la ejecución y la

creación de la Base de Datos BDCasa.

11.2.A continuación se procederán a crear las tablas de la base de datos,

para ello se utilizará como fuente referencial el modelo físico de la

base de datos y se digitara en el Analizador de Consultas las

siguientes líneas de código.

CREATE TABLE TP_FamiliaProductos (

Cod_FamiliaProductos char(3) not null,

Nom_FamiliaProductos varchar(30) not null)



CREATE TABLE TP_Producto (

Cod_Producto char(3) Not Null,

Cod_FamiliaProducto char(3) Not Null,

Nom_Producto Varchar(30),

Mon_Precio money,

Can_Stock int)

CREATE TABLE TP_Empleado (

Cod_Empleado char(3) Not Null,

Nom_Empleado varchar(20) Not Null,

Ape_Empleado varchar(20) Not Null,

Num_Telefono char(14))

CREATE TABLE TT_Pedido (

Num_Pedido char(3) Not Null,

Cod_Empleado char(3) Not Null,

Fec_Pedido datetime,

Nom_Cliente varchar(30),

Mon_TotalPedido money,

Mon_IGVPedido money)

CREATE TABLE TT_DetallePedido (

Num_Pedido char(3) Not Null,

Cod_Producto char(3) Not Null,

Can_Pedido int,

Mon_SubTotal money)

De ejecutarse todas estas líneas de código sin problemas, deberá

aparecer el siguiente mensaje. Comandos completados con éxito.



11.3.Inmediatamente procederemos a implantar las Llaves Primarias y

Llaves Foráneas. Para ello, igualmente, se utilizará como fuente

referencial el modelo físico de la base de datos y se digitara en el

Analizador de Consultas las siguientes líneas de código.

A. Primeramente implantaremos las Llaves Primarias de cada una de

las tablas, tal como se muestra a continuación.

ALTER TABLE TP_FamiliaProductos

ADD PRIMARY KEY (Cod_FamiliaProductos)

ALTER TABLE TP_Producto

ADD PRIMARY KEY (Cod_Producto)

ALTER TABLE TP_Empleado

ADD PRIMARY KEY (Cod_Empleado)

ALTER TABLE TT_Pedido

ADD PRIMARY KEY (Num_Pedido)

ALTER TABLE TT_DetallePedido

ADD PRIMARY KEY (Num_Pedido, Cod_Producto)



B. Inmediatamente procederemos a implantar las Llaves Foráneas.

Para ello, igualmente, se utilizará como fuente referencial el

modelo físico de la base de datos y se digitará en el Analizador de

Consultas las siguientes líneas de código.

Ahora implantaremos las Llaves Foráneas necesarias , tal como se

muestra a continuación.



ALTER TABLE TP_Producto

ADD FOREIGN KEY (Cod_FamiliaProducto)

REFERENCES TP_FamiliaProductos

ALTER TABLE TT_Pedido

ADD FOREIGN KEY (Cod_Empleado)

REFERENCES TP_Empleado



12.Visualización de la base de datos en el Asistente de Diagramas de

base de datos

Una vez implantada la base de datos BDCasa, podremos ver este modelo

en el Asistente de Diagramas de Base de Datos del SQL Enterprise

Manager. Siguiendo las acciones construiremos el modelo de datos de

BDCasa.

12.1.Ubicarse en el objeto Diagramas de la Base de Datos Casa y presionar

el clic derecho, tal como lo podemos mostrar en el siguiente gráfico.



12.2.A continuación se mostrará la pantalla del Asistente para la Creación

de Diagramas de Base de Datos, presionar el botón siguiente.

12.3.A continuación se muestra la pantalla que nos permite Seleccionar

tablas para agregar. Al lado izquierdo se mostrarán las tablas

disponibles, de las cuales seleccionaremos las tablas requeridas y las

enviaremos al lado derecho.



12.4.Seguidamente presionar el botón siguiente. A 0onctinucación se

muestra la pantalla que nos indica que se ha completado el asistente

para la creación de diagramas de base de datos.

12.5.Ahora presionaremos el botón Finalizar para poder visualizar el

diagrama de base de datos.



12.6.Finalmente grabar el diagrama, en este caso con el nombre

dgrBDCasa, tal como se muestra a continución.



13.Manipulación de los datos con Tranasact / SQL

Teniendo ya la base de datos BDCasa implantada, procederemos ahora a

manipular los datos utilizando el Transact / SQL.

13.1.Ingreso de datos y visualización de datos ingresados (Consulta de

datos)

Tabla TP_FamiliaProductos

Insert into TP_FamiliaProductos (Cod_FamiliaProductos, Nom_FamiliaProductos)

Values (‘F01 ‘, ‘Pinturas ‘)


Values (‘F02 ‘, ‘Jardin ‘)


Values (‘F03 ‘, ‘Terrazas ‘)



Para poder ver los datos ingresados en la tabla TP_FamiliaProductos,

ejecutaremos la siguiente consulta y se mostrarán a continuación sus

resultados.

Select * from TP_FamiliaProductos



Tabla TP_Producto

Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,

Mon_Precio, Can_Stock)

Values (‘P01’, ‘F01’, ‘Pintura de interior marca ABC’,15.00,100)



Values (‘P02’, ‘F01’, ‘Pintura de interior marca SOFT ‘,14.00,90)



Values (‘P03’, ‘F01’, ‘Pintura de exterior marca ABC ‘,17.00,85)



Values (‘P04’, ‘F01’, ‘Pintura de exterior marca OUT ‘,19.00,55)



Values (‘J01’, ‘F02’, ‘Ficus Argentino’, 3.50, 30)



Values (‘J02’, ‘F02’, ‘Ficus Semi enano ‘, 4.00, 45)



Values (‘J03’, ‘F02’, ‘Molle Serrano ‘, 7.00, 30)



Values (‘J04’, ‘F02’, ‘Mini schefflera variegada ‘, 8.50, 35)



Values (‘T01’, ‘F03’, ‘Mesa Tayroma II Blanco ‘, 70.00, 60)



Values (‘T02’, ‘F03’, ‘Silla Minikid ‘, 8.50, 30)





Values (‘T03’, ‘F03’, ‘Parrilla a gas ‘, 350.00, 45)



Para poder ver los datos ingresados en la tabla TP_Producto,


resultados.

Select * from TP_Producto



Tabla TP_Empleado

Insert into TP_Empleado (Cod_Empleado, Nom_Empleado, Ape_Empleado,

Num_Telefono)

Values (‘E01’, ‘Franco’, ‘Ruiz’, ‘426589’)


Num_Telefono)

Values (‘E02’, ‘Fiorella’, ‘Piñeiros’, ‘423546’)


Num_Telefono)

Values (‘E03’, ‘Antonio’, ‘Torrealva’, ‘427654’)



Para poder ver los datos ingresados en la tabla TP_Empleado,


resultados.

Select * from TP_Empleado



Tabla TT_Pedido

Insert into TT_Pedido (Num_Pedido, Cod_Empleado, Fec_Pedido, Nom_Cliente,

Mon_TotalPedido, Mon_IGVPedido)

Values (‘S01’, ‘E01’, 14/07/2005, ‘Ximena Estela’, 87.00, 16.53)



Values (‘S02’, ‘E02’, 15/07/2005, ‘Andrea Chacón’, 34.00, 6.46)



Values (‘S03’, ‘E03’, 15/07/2005, ‘Valery Rodriguez’, 112.00, 21.28)



Para poder ver los datos ingresados en la tabla TT_Pedido,


resultados.

Select * from TT_Pedido



Tabla TT_DetallePedido

Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,

Mon_SubTotal)

Values (‘S01’, ‘P01’,2,30.00)


Mon_SubTotal)

Values (‘S01’, ‘P04’,3,57.00)


Mon_SubTotal)

Values (‘S02’, ‘J01’,4,12.00)


Mon_SubTotal)

Values (‘S02’, ‘J03’,2,14.00)


Mon_SubTotal)

Values (‘S02’, ‘J04’,1,8.00)


Mon_SubTotal)

Values (‘S03’, ‘P03’,2,34.00)


Mon_SubTotal)

Values (‘S03’, ‘J02’,2,8.00)


Mon_SubTotal)

Values (‘S03’, ‘J01’,1,70.00)





Para poder ver los datos ingresados en la tabla TT_DetallePedido,


resultados.

Select * from TT_DetallePedido

13.2.Modificación de datos

Ingresaremos un nuevo Empleado, en la tabla TP_Empleado


Num_Telefono)

Values (‘E04’, ‘Luis’, ‘Agurto’, ‘52333’)

Al consultar el ingreso de estos datos, se visualiza lo siguiente.

Select * from TP_Empleado

where Cod_empleado = ‘E04’



Ahora modificaremos el Nombre por Andre y el Teléfono por 421111

Update TP_Empleado

Set Nom_Empleado = ‘Andre’

Where Cod_Empleado = ‘E04’

Update TP_Empleado

Set Num_Telefono = ‘421111’

Where Cod_Empleado = ‘E04’

Se obtendrán los siguientes resultados.

Se produce un incremento en el Stock de los Productos de la

Familia F01, incremento del 10% del stock actual. Por lo que

procederemos a modificar el Stock y visualizar los cambios.

Update TP_Producto

Set Can_Stock = Can_Stock + Round((Can_Stock * 0.10),0)

Where Cod_FamiliaProducto = ‘F01’

Se obtendrán los siguientes resultados.



13.3.Eliminación de registros

Ingresaremos una nueva familia a la tabla TP_FamiliaProductos.


Values (‘F05’, ‘Sala Comedor’)

Visualicemos el registro ingresado.


Ahora procederemos a eliminar este registro.

Delete From TP_FamiliaProductos

Where Cod_FamiliaProductos = ‘F05’

Visualicemos los registro de la tabla TP_FamiliaProductos, ya no se

encuentra el Codigo de Familia F05.




13.4.Consulta de registros

G. Se desea visualizar todos los productos


Se desea visualizar los productos correspondientes a la familia Terraza


Where Cod_FamiliaProducto = ‘F03’

Se desea visualizar los productos que tengan un stock comprendido

entre 40 y 100 unidades


Where Can_Stock Between 40 and 100



Se desea visualizar los productos, cuyo nombre, empiece con la letra F

o la letra P


Where Nom_Producto Like ‘F%’ or Nom_Producto Like ‘P%’

Se desea visualizar los pedidos con el nombre de los clientes y el

monto total que pagaron por el pedido.

Select Num_Pedido, Nom_Cliente, Mon_TotalPedido+Mon_IGVPedido

from TT_Pedido



Se desea visualizar Codigo de Producto y Nombre del Producto cuyo

nombre empiecen con la letra F o P y la segunda letra sea la i.

Select Cod_Producto, Nom_Producto

From TP_Producto

Where Nom_Producto Like ‘[FP]i%’

Se desea visualizar los pedidos, ordenados de mayor a menor

select Num_Pedido, Nom_Cliente, Mon_TotalPedido

From TT_Pedido

Order by Mon_TotalPedido Desc



14. Bibliografía

5.1. Linda G. DeMichiel, Donald D. Chamberlin, Bruce G. Lindsay

“Poliglot: Extensions to Relational Database for Sharable Types and

Functions “ IBM Research Report – Julio 1995

5.2. Martin James. “Diagrama Entidad Relación”. Traducido de

“Recommended diagramming Standard for Análisis and

programmers”. Primera Edición Prentice Hall 1993.

5.3. C.J. Date “Introducción a los Sistemas de Base de Datos”. Séptima

Edición. Prentice Hall 2001.

5.4. Patrick Dalton & Paul Whitehead. “La Biblia de SQL Server 2000”.

Ediciones Anaya 2001.

5.5. Jorge Moratalla. “Base de Datos con SQL Server – Transact SQL”.

Grupo Eidos 2000.

5.6. G. Coronel & C. Bustamante. “Diseño de aplicaciones Cliente

Servidor”. Primer Edición Grapp Perú 2001.


manual base de datos erwin - sql server

Documents

conjunto de datos

datos almacenados

modelo de datos

datos estn

unidad de datos

datos registrados

datos integrados

datos manual