Post on 20-Oct-2015
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
Manual de Base de Datos con ERWIN y SQL Server
"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
Pág. 2 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 3 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 4 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 5 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 6 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 7 Ing: Erick Giovanny Flores Chacón
Clave Principal
Atributos
Tupla
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 8 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 9 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 10 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 11 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 12 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 13 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 14 Ing: Erick Giovanny Flores Chacón
Codigo Nombre ApellidoE02 Fiorella PiñeirosE04 William Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 15 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 16 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 17 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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:
Pág. 18 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 19 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 20 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 21 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 22 Ing: Erick Giovanny Flores Chacón
Llave Primaria
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 23 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Un Cliente tiene Ninguna, Una o Muchas Facturas
Una Factura pertenece a Un Cliente
2.4. Ejemplo de un modelo conceptual
Pág. 24 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 25 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 26 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 27 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 28 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 29 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 30 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 31 Ing: Erick Giovanny Flores Chacón
Codigo Proveedor
Nombre Proveedor
Ciudad Proveedor
P01 Alberto LimaP02 Pedro HuarazP03 Rosa Trujillo
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 32 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 33 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 34 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 35 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 36 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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ág. 37 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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,
Pág. 38 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 39 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 40 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Código Nombre Precio Stock
J01 Ficus Argentino 3.00 30
Pág. 41 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
J02 Ficus Semi enano 4.00 45
J03 Molle Serrano 7.00 30
J04 Mini schefflera variegada 8.00 35
Familia de Productos: Terrazas
Código Nombre Precio Stock
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:
Pág. 42 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 43 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 44 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 45 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 46 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Tienda para el Hogar "Casa y Familia"
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
Pág. 47 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 48 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Campo lógico Campo físico Tipo de dato Regla
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
Campo lógico Campo físico Tipo de dato Regla
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
Campo lógico Campo físico Tipo de dato Regla
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
Campo lógico Campo físico Tipo de dato Regla
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
Pág. 49 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Tienda para el Hogar "Casa y Familia"
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.
Pág. 50 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y 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:
Pág. 51 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 52 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 53 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Se ingresará al Analizador de Consultas. Mostrándose la siguiente
pantalla.
Pág. 54 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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)
Pág. 55 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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)
Pág. 56 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 57 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
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.
Pág. 58 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
ALTER TABLE TP_Producto
ADD FOREIGN KEY (Cod_FamiliaProducto)
REFERENCES TP_FamiliaProductos
ALTER TABLE TT_Pedido
ADD FOREIGN KEY (Cod_Empleado)
REFERENCES TP_Empleado
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
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.
Pág. 59 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 60 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 61 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
12.6.Finalmente grabar el diagrama, en este caso con el nombre
dgrBDCasa, tal como se muestra a continución.
Pág. 62 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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 ‘)
Insert into TP_FamiliaProductos (Cod_FamiliaProductos, Nom_FamiliaProductos)
Values (‘F02 ‘, ‘Jardin ‘)
Insert into TP_FamiliaProductos (Cod_FamiliaProductos, Nom_FamiliaProductos)
Values (‘F03 ‘, ‘Terrazas ‘)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
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
Pág. 63 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘P02’, ‘F01’, ‘Pintura de interior marca SOFT ‘,14.00,90)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘P03’, ‘F01’, ‘Pintura de exterior marca ABC ‘,17.00,85)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘P04’, ‘F01’, ‘Pintura de exterior marca OUT ‘,19.00,55)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘J01’, ‘F02’, ‘Ficus Argentino’, 3.50, 30)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘J02’, ‘F02’, ‘Ficus Semi enano ‘, 4.00, 45)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘J03’, ‘F02’, ‘Molle Serrano ‘, 7.00, 30)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘J04’, ‘F02’, ‘Mini schefflera variegada ‘, 8.50, 35)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘T01’, ‘F03’, ‘Mesa Tayroma II Blanco ‘, 70.00, 60)
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘T02’, ‘F03’, ‘Silla Minikid ‘, 8.50, 30)
Pág. 64 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Insert into TP_Producto (Cod_Producto, Cod_FamiliaProducto, Nom_Producto,
Mon_Precio, Can_Stock)
Values (‘T03’, ‘F03’, ‘Parrilla a gas ‘, 350.00, 45)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
Para poder ver los datos ingresados en la tabla TP_Producto,
ejecutaremos la siguiente consulta y se mostrarán a continuación sus
resultados.
Select * from TP_Producto
Pág. 65 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Tabla TP_Empleado
Insert into TP_Empleado (Cod_Empleado, Nom_Empleado, Ape_Empleado,
Num_Telefono)
Values (‘E01’, ‘Franco’, ‘Ruiz’, ‘426589’)
Insert into TP_Empleado (Cod_Empleado, Nom_Empleado, Ape_Empleado,
Num_Telefono)
Values (‘E02’, ‘Fiorella’, ‘Piñeiros’, ‘423546’)
Insert into TP_Empleado (Cod_Empleado, Nom_Empleado, Ape_Empleado,
Num_Telefono)
Values (‘E03’, ‘Antonio’, ‘Torrealva’, ‘427654’)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
Para poder ver los datos ingresados en la tabla TP_Empleado,
ejecutaremos la siguiente consulta y se mostrarán a continuación sus
resultados.
Select * from TP_Empleado
Pág. 66 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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)
Insert into TT_Pedido (Num_Pedido, Cod_Empleado, Fec_Pedido, Nom_Cliente,
Mon_TotalPedido, Mon_IGVPedido)
Values (‘S02’, ‘E02’, 15/07/2005, ‘Andrea Chacón’, 34.00, 6.46)
Insert into TT_Pedido (Num_Pedido, Cod_Empleado, Fec_Pedido, Nom_Cliente,
Mon_TotalPedido, Mon_IGVPedido)
Values (‘S03’, ‘E03’, 15/07/2005, ‘Valery Rodriguez’, 112.00, 21.28)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
Para poder ver los datos ingresados en la tabla TT_Pedido,
ejecutaremos la siguiente consulta y se mostrarán a continuación sus
resultados.
Select * from TT_Pedido
Pág. 67 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Tabla TT_DetallePedido
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S01’, ‘P01’,2,30.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S01’, ‘P04’,3,57.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S02’, ‘J01’,4,12.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S02’, ‘J03’,2,14.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S02’, ‘J04’,1,8.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S03’, ‘P03’,2,34.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S03’, ‘J02’,2,8.00)
Insert into TT_DetallePedido (Num_Pedido, Cod_Producto, Can_Pedido,
Mon_SubTotal)
Values (‘S03’, ‘J01’,1,70.00)
De ejecutarse todas estas líneas de código sin problemas, deberá
aparecer el siguiente mensaje. Comandos completados con éxito.
Pág. 68 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Para poder ver los datos ingresados en la tabla TT_DetallePedido,
ejecutaremos la siguiente consulta y se mostrarán a continuación sus
resultados.
Select * from TT_DetallePedido
13.2.Modificación de datos
Ingresaremos un nuevo Empleado, en la tabla TP_Empleado
Insert into TP_Empleado (Cod_Empleado, Nom_Empleado, Ape_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’
Pág. 69 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 70 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
13.3.Eliminación de registros
Ingresaremos una nueva familia a la tabla TP_FamiliaProductos.
Insert into TP_FamiliaProductos (Cod_FamiliaProductos, Nom_FamiliaProductos)
Values (‘F05’, ‘Sala Comedor’)
Visualicemos el registro ingresado.
Select * from TP_FamiliaProductos
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.
Select * from TP_FamiliaProductos
Pág. 71 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
13.4.Consulta de registros
G. Se desea visualizar todos los productos
Select * from TP_Producto
Se desea visualizar los productos correspondientes a la familia Terraza
Select * from TP_Producto
Where Cod_FamiliaProducto = ‘F03’
Se desea visualizar los productos que tengan un stock comprendido
entre 40 y 100 unidades
Select * from TP_Producto
Where Can_Stock Between 40 and 100
Pág. 72 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
Se desea visualizar los productos, cuyo nombre, empiece con la letra F
o la letra P
Select * from TP_Producto
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
Pág. 73 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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
Pág. 74 Ing: Erick Giovanny Flores Chacón
Manual de Base de Datos con ERWIN y SQL Server
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.
Pág. 75 Ing: Erick Giovanny Flores Chacón