Modelamiento de Datos 2013

UNIVERSIDAD NACIONAL DE INGENIERIA
Centro de Extensin y Proyeccin Social
D
MODELAMIENTO DE DATOS
Introduccin
En el desarrollo de las Aplicaciones que sirven para manipular las Bases de datos
nos encontramos con Bases de Datos que ya han sido creadas en algn DBMS
en particular, luego el programador debe conocer su estructura y las reglas que
juegan en dichas B.D. para a continuacin segn las necesidades del usuario
disear la aplicacin ms adecuada.
El conocimiento de cmo se lleg a disear la B.D. se hace importante porque
nos permitir conocer los criterios que se tuvieron en cuenta para llegar a dicho
modelo, esto har que nuestra aplicacin tenga mayor consistencia y ms an se
puedan detectar algunos errores de diseo que tal vez no se tomaron en cuenta el
proceso del modelamiento.
Este curso, tiene como objetivo principal entonces adquirir las tcnicas adecuadas
para disear e implementar, a partir de una realidad concreta, una base de datos
en un servidor determinado y con el DBMS (SQL Server)
Inst. Flores Manco Julio E.
Pg.1

D
CAPTULO
SISTEMAS DE INFORMACION
Sistema
Conjunto de elementos que interactanpara realizar un conjunto de funciones

especficas.
Sistema con realimentacin
La informacin y la toma de decisiones

Las funciones administrativas as como el arte de la toma de decisiones tienen
como materia prima fundamental la informacin. El grado de incertidumbre en la
toma de decisiones depende de la in formacin que se posea. En consecuencia la
informacin otorga ventajas estratgicas a la organizacin en el mercado frente a
los competidores.
Datos
Representacin formal de hechos, conceptos o instrucciones adecuada para su
comunicacin, interpretacin y procesamiento por seres humanos o medios
automticos.
Son nmeros y factores en bruto, sin analizar, acerca de los sucesos. Algo
recogido directamente de la fuente.
Pg.2

D
Informacin
Es el resultado de la organizacin o anlisis de los datos de alguna manera
significativa con un objetivo preestablecido.
Caractersticas de la informacin
La informacin es evaluada de acuerdo a cuatro factores que deben formar parte
de sus caractersticas:
Calidad
Cuanto ms exacta sea la informacin mejor ser su calidad y los usuarios
recurrirn a ella con ms confianza cuando tomen una decisin.
Oportunidad
La informacin debe estar siempre disponible, para la accin correcta y la
toma de decisiones en el momento que se le necesite.
Cantidad
Los administradores casi nunca toman decisiones correctas y acertadas si la
informacin no es acertada, oportuna y suficiente; la informacin debe ser la
suficiente para cubrir el espectro del problema en la toma de decisiones.
Relevancia
Debe darse solo la informacin relevante para la toma de decisiones; toda la
informacin proporcionada debe ser de utilidad; los datos no deben ser de
relleno.
Pg.3

D
Sistemas de Informacin
Un Sistema de informacin es un sistema, automatizado o manual, que engloba
apersonas, mquinas y/o mtodos organizados para recopilar, procesar, transmitir
datos que representan informacin.
Implica la infraestructura, organizacin, personal y componentes para la
recopilacin,
procesamiento,
almacenamiento,
transmisin,
visualizacin,
diseminacin y organizacin de informacin.
Un Sistema de Informacin es entonces, una coleccin integrada de hardware,
software, procedimientos, datos y personas que trabajan en conjunto para genera
informacin. Un S.I. es un mtodo formal de poner a disposicin de los usuarios
informacin confiable y oportuna que se necesita para facilitar el proceso de la toma
de decisiones y permitir que las funciones de planeacin, control y operaciones se
realicen eficazmente en la organizacin.
Lo que se exige al S.I.

Obtencin de ventajas estratgicas para la organizacin.
Lugar correcto, tiempo correcto y forma correcta.
Reduccin de costos.
Proveer funciones de automatizacin para tareas crticas.

Soporte a un nmero creciente de usuarios.
Nuevas aplicaciones en funcin a aplicaciones existentes.
Proveer soporte para periodos largos de tiempo.
Tipos de Sistemas de Informacin

S.I. Transaccionales (OLTP)
(On Line TransactionProcess) Estn orientados a cubrir la operatividad de
la Organizacin, cumplir con cada uno de los procesos que la empresa realiza
como objetivo de negocio. Por ejemplo el Sistema de ventas.
Caractersticas:
Pg.4
Se leen pocas columnas.

La Data es leda por medio de ndices.
SQL simple.
Tiempo de respuesta pequeos.
Orientados al nivel operativo.

D
Sistemas para soporte de decisiones (DSS)

(DecisionSupportSystem) Deben cubrir la demanda de informacin para la
toma de decisiones estos sistemas se orientan al nivel estratgico de la
organizacin y al tctico en un menor grado;
Caractersticas:
Se leen muchas columnas.
La Data es leda secuencialmente.
Tiempo de respuesta en minutos y horas.
Se basan en programas de ejecucin en lotes.
Sistemas Estadsticos o Cientficos

Son S.I. complejos que generalmente apoyan a los procesos de investigacin
y explotacin de sistemas complejos por la naturaleza de las operaciones a la
que est orientada y diseada. Por ejemplo El sistema de laboratorio minero.
Caractersticas:
Se leen muchas columnas.
La Data es leda secuencialmente.
SQL complejo.
Sistemas Mixtos
Combina cualquiera de los S.I. anteriores, por tanto las caractersticas que
puede adoptar este tipo de sistema es la combinacin de los otros tipos de
S.I.
Perspectivas de los Sistemas de Informacin

Perspectiva estratgica
La in formacin y principalmente los Sistemas de Informacin, son vistos
como instrumentos o mecanismos mediante los cuales podemos obtener
ventajas frente a nuestros competidores al momento decidir un nuevo
producto, la ampliacin de mercado, etc.
La perspectiva estratgica que se tiene sobre un sistema de informacin, es
que debe cubrir una serie de factores considerados importantes en el proceso
diario de las operaciones de la organizacin y ayudar a sta a mejorar los
Pg.5

D
productos o servicios que brinde la empresa al mercado, por tanto alinearse a

los planes estratgicos de la organizacin para el desarrollo organizacional.
Es as que bajo esta perspectiva se busca:
Obtener ventajas estratgicas: tiempo correcto, lugar correcto y
forma correcta.
Reduccin de costos.
Automatizar tareas consideradas crticas en los procesos de
negocios.
Soporte a un nmero creciente de usuarios.
Proveer soporte a periodos largos de tiempo.
Perspectiva Tecnolgica
Una vez definidas las caractersticas funcionales, se debe analizar la
perspectiva tecnolgica del S.I.
Se deben considerar los siguientes factores:
Cul es la Arquitectura de sistemas ms convenientepara el S.I.
Con lo cual realmente se puede apoyar a las operaciones de la
Organizacin.
Los cambios tecnolgicos que se presentan cada vez ms aprisa,
cmo afectarn a nuestro S.I.
Se debe tener en cuenta al analizar la perspectiva tecnolgica, alinearnos con

la perspectiva estratgica de la organizacin. Esto es, lo que la Organizacin
espera de su S.I. para en funcin a eso ayudar a sentar las bases de un
sistema que ayude a las operaciones y no las operaciones al sistema.
La Tecnologa debe hacer que:
El negocio se mueva con l, pero no para l.
Los tcnicos decidan qu tecnologa usar.
Se determine si se puede aplicar en la construccin de un
determinado sistema
Pg.6

D
Sistemas de informacin empresarial

Utilidad de los sistemas de informacin:
Gestin de los recursos de una empresa
Factores que favorecen el desarrollode sistemas de informacin:
Complejidad de los sistemas actuales (p.ej. competencia).
Capacidad de los ordenadores.
Ventajas
Econmicas (ahorro de costes, aumento de productividad).
No econmicas (valor percibido).
Recursos principales de una empresa

Recursos fsicos
Personal
Material & Maquinaria

(Infraestructuras& energa)
Recursos conceptuales
Dinero
Informacin
Pg.7

CAPTULO
D
El modelamiento de los Datos

Es el proceso de abstraccin de la realidad (modelo) en funcin de los conceptos
(datos que la componen)
Se realiza de acuerdo a la interpretacin de la realidad que se est observando
Es descrito en funcin de la interpretacin de los conceptos (semntica)
Debe ser consistente con el modelamiento de procesos de negocio
Caractersticas que debe cumplir un Modelo Optimo
Necesidad de Modelar los Datos

Identificar los requerimientos del usuario
Incrementar la productividad
Mantener la consistencia de los datos
Optimizar la performance
Permitir el diseo de informacin integrada
Pg.8

D
Ciclo de Vida del Modelamiento de Datos
Pg.9

D
Base de datos
Una base de datos es un conjunto de datos organizados de manera tal que se
facilita el almacenamiento, la actualizacin, y la consulta de los datos. Una base de
datos relacional est organizada como un conjunto de filas y columnas relacionadas.
Es una coleccin sistematizada de datos, que puede ser usada como fuente de
informacin nica para toda la organizacin.
Coleccin organizada y sistematizada de datos de inters de la organizacin a la
cual accedemos y explotamos para obtener informacin de utilidad para el manejo
de la organizacin.
El objetivo primario de una base de datos es almacenar datos de inters para la

organizacin. Adems de:
Proveer como fuente nica de informacin a toda la organizacin.
Mantener seguridad y privacidad de la informacin.
Tener a la informacin como activo de la organizacin.
Pg.10

D
Necesidad de una Base de Datos

El desarrollo de Sistemas de Informacin trae consigo una nueva necesidad de tener
la informacin almacenada en fuentes de datos uniformes para un acceso a la base
de datos uniformes y homogneos en lo posible.
Por otra parte la concepcin de la informacin como un activo de gran valor para la
organizacin hace que nos apoyemos en sta para salvaguardarla y explotarla al
mximo.
El uso de una base de datos ofrece los siguientes beneficios:
Reduccin de la redundancia de datos.
Se evita la inconsistencia en los datos.
Los datos pueden ser compartidos por las reas relacionadas de la

organizacin.
Permite la estandarizacin de los datos.
Permite aplicar restricciones de seguridad.
Permite controlar la integridad de los datos.
El planeamiento de la base de datos ofrece las siguientes ventajas:
Permite entender la informacin con la que cuenta la organizacin como un

recurso valioso para sus actividades diarias.
Permite establecer los requerimientos de informacin de los usuarios, y la

manera de satisfacerlos.
Permite administrar eficientemente los recursos de informacin.
Permite establecer planes de accin para lograr los objetivos de la

organizacin.
Ayuda a desarrollar una base de datos que permita cumplir con los
requerimientos de la organizacin.
Pg.11

D
Sistema de Administracin de Bases de Datos

(DBMS).
Se conoce como Sistema de Administracin de Base de Datos, o Sistema de
Gestin de Base de Datos, o Database Management System (DBMS) al conjunto de
hardware y software utilizado para almacenar y administrar una base de datos. En el
mercado tenemos una variedad de DBMS, desde aquellos diseados para ser
utilizados en computadoras personales hasta los creados para ser utilizados en
entornos distribuidos:
Microsoft Access
MySQL
PosgreSQL
Microsoft SQL Server
SybaseSystem
DB2 Universal Database
Oracle Database
Razones para usar un DBMS

Un DBMS evita dos grandes problemas que se presentan en los sistemas
convencionales de almacenamiento de datos:
Redundancia de los datos: cuando cada rea de una organizacin maneja su

propio almacenamiento de datos, la data suele duplicarse en cada una de las
reas que tienen relacin entre s.
Inconsistencias en los datos: como consecuencia de la duplicidad de los datos,

la actualizacin de un dato puede requerir que esta operacin se ejecute en
varios lugares. Si esto no se hace con cuidado, necesariamente se va a
presentar inconsistencia en los datos, ya que algunos estarn actualizados y
otros no.
Pg.12

D
Arquitectura de un DBMS.
Un DBMS se puede dividir en tres niveles:
Nivel externo
Nivel conceptual
Nivel interno
Nivel externo
Es el nivel del SABD ms cercano al usuario por lo que se le conoce tambin como
la vista del usuario. El nivel externo define cmo el usuario ve los datos
almacenados por el SABD.
Nivel conceptual
Es el nivel que define la base de datos tal como es y cmo la ve el DBA
(DatabaseAdministrator). Este nivel define las relaciones entre los datos.
Nivel interno
Es el nivel que tiene que ver con el almacenamiento fsico de los datos. Define cmo
se guardan los datos en el medio fsico.
Pg.13

D
Diseo Conceptual
El diseo conceptual permite describir, de un modo totalmente independiente de
laimplementacin, los datos que el usuario quiere recoger en el sistema.
Dependiendo de la cantidad de informacin que se desee representar, tendremos
aplicaciones ms o menos orientadas a los datos. As, por ejemplo, la gestin de
una biblioteca es una aplicacin pura de Bases de Datos (en adelante BD) ya que
prcticamente toda la funcionalidad del sistema se centra en el mantenimiento de los
datos (introducir un libro, prestar un libro, etc.).
Existen, sin embargo, otras aplicaciones, como por ejemplo un sistema de control de
navegacin area, en las que los datos son algo secundario. Podemos decir que, en
general, los datos son el ncleo de todo SI orientado a la gestin.
El desarrollo estructurado de software, a diferencia de lo que ocurre en el
desarrolloorientado a objetos, mantiene una clara separacin entre los datos y las
funciones del sistema. Por ello, es necesario disponer, en cada una de las etapas
del proceso de desarrollo, de tcnicas especficas para la especificacin de los
datos, que sern diferentes de las tcnicas orientadas a la especificacin de las
funciones o procesos.
El modelado conceptual es una actividad que se realiza en la etapa de
anlisis,paralelamente al modelado de procesos o funciones. Su objetivo, como ya
hemos dicho, es captar toda la informacin del mundo real que se desea representar
en el mundo informtico. En este proceso es importante abstraer los detalles sin
importancia y representar tan slo aquella informacin que sea relevante.
En este punto no nos interesa el cmo ni donde se va a implementar el sistema.
Dehecho,dependiendo del tipo de sistema (ms o menos orientado a los datos), del
volumen de informacin, de los requisitos de eficiencia, etc. se podrn utilizar
distintos mecanismos de persistencia de los datos: Sistemas de Bases de Datos,
Sistemas de Ficheros, etc.
En esta etapa interesa recoger la mxima cantidad de informacin posible, por lo
necesitamos una tcnica que cumpla los siguientes requisitos:
Ser independiente de los modelos o lenguajes de implementacin
Tener una capacidad semntica alta
Ser lo ms cercana posible al usuario
Aunque existen diversas tcnicas, utilizaremos el modelo E/R porque adems

decumplir los requisitos anteriores es la tcnica de modelado conceptual
universalmente aceptada para el desarrollo estructurado.
El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo
conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo
Pg.14

D
Entidad-Relacin est formado por un conjunto de conceptos que permiten describir

la realidad mediante un conjunto de representaciones grficas y lingsticas.
Originalmente, el modelo entidad-relacin slo inclua tres clases de objetos:
entidades, interrelaciones y atributos. Ms tarde, se aadieron al modelo bsico un
conjunto de constructores que ayudaron a recoger una mayor semntica del
universo de discurso (los atributos compuestos, cardinalidades mximas y mnimas,
las jerarquas de generalizacin, dependencia en existencia y en identificacin, etc.)
y este nuevo modelo es lo que se ha denominado modelo E/R extendido.
El Modelo E/R ha tenido una gran difusin en la comunidad informtica dedicada a
las BD, prueba de ello es que ha sido el modelo ms extendido en las herramientas
CASE de ayuda al diseo de BD.
Concepto de Modelo de Datos

Un modelo puede definirse como la construccin mental a partir de la realidad en la
que se reproducen los principales componentes y relaciones del segmento de la
realidad analizada. ste es, efectivamente, el significado de modelo en las ciencias
empricas en las que, a fin de estudiar el comportamiento de una determinada
parcela de la realidad, se crea un modelo de sta. Dicho modelo habr de ser
isomrfico respecto a la realidad que representa y ms simple que sta, destacando
sus principales caractersticas, o aquellas que son relevantes para un determinado
inters de estudio. Sin embargo, sta no es la nica acepcin del trmino modelo, al
que podemos asignar dos significados:
Por un lado, el modelo entendido como una reproduccin simplificada de

la realidad; este es el caso, ya expuesto, de las ciencias empricas, en las
que se definen modelos de comportamiento simplificados de la parcela del
mundo real que es objeto de estudio;
Y, por otro lado, el modelo entendido como la realidad propiamente dicha;

pinsese, por ejemplo, en un pintor, quien reproduce en lienzo a sus modelos;
en este segundo caso, el modelo no es la representacin del mundo real, sino
que constituye el mundo real en s mismo: es un modelo a copiar o a simular.
Esta segunda acepcin de modelo es la que corresponde a la lgica matemtica,

donde la representacin recibe el nombre de teora y lo representado el de modelo,
mientras que la primera corresponde, como ya hemos visto, al concepto de modelo
en las ciencias empricas.
En algunos casos, como en el caso de los modelos de datos, el concepto de modelo
Respondesimultneamente a estas dos acepciones. Quiz resulte esclarecedor el
ejemplo del arquitecto, para quien una maqueta es un modelo a copiar para la
construccin de un nuevo edificio. La maqueta sera, en un primer momento, la
realidad puesto que el edificio an no existe. El arquitecto obtiene un nuevo edificio
tomando dicha maqueta como modelo. A partir de este momento, el edificio
Pg.15

D
constituye la realidad, mientras que la maqueta puede considerarse una copia del
mismo.
En el mbito de la bases de datos es muy comn la utilizacin del trmino modelo
de datos, y existen diferentes definiciones del mismo en la literatura. As, por
ejemplo, Dittrich define modelo de datos como "un conjunto de herramientas
conceptuales para describir la representacin de la informacin en trminos de
datos. Los modelos de datos comprenden aspectos relacionados con: estructuras y
tipos de datos, operaciones yrestricciones".
Un modelo de datos permite representar una parcela de informacin del mundo
realde especial inters, lo que habitualmente se denomina universo del discurso o,
entrminos, de Dittrichmini-mundo. La representacin del universo del discurso se
concibe en dos niveles: el de la informacin en s misma y el de las estructuras que
hacen posible la representacin de tal informacin. Estos dos niveles dan lugar, en
el mbito de las bases de datos, a la distincin entre esquema y base de datos,
conceptos que Dittrich define como sigue: "La descripcin especfica de un
determinado mini-mundo en trminos de un modelo de datos se denomina esquema
(o esquema de datos) del mini-mundo. La coleccin de datos que representan la
informacin acerca del mini-mundo constituya la base de datos".
Teniendo presente que esta terminologa puede variar y que empleamos sta por
ser la ms extendida en el mundo de los datos en el que se centra la presente
unidad,definimos modelo de datos como un:
Conjunto de conceptos, reglas y convenciones que permiten describir y manipular
los datos de la parcela del mundo real que constituye nuestro universo del discurso
Pg.16

D
ELEMENTOS ESTTICOS
En el Modelo E/R, tal como fue propuesto por Chen, se distinguen los siguientes
elementospara la componente esttica:
Entidad, Interrelacin, Dominio y Atributo.
Entidades
El mundo real se compone de una serie de objetos (reales o abstractos) acerca de
los cuales queremos obtener y representar informacin. En general dichos objetos
podrn agruparse en conjuntos de acuerdo a unas caractersticas comunes a todos
aquellos que forman parte de un mismo conjunto. Denominamos entidad a la
abstraccin que permite representar aquellos objetos del mundo real que comparten
una serie de caractersticas comunes.
Las entidades son los objetos principales sobre los que debe recogerse informacin
y generalmente denotan personas, lugares, cosas o eventos de inters. Las
entidades aparecern reflejadas en el enunciado habitualmente como nombres. A
cada una de las posibles ocurrencias (cada persona, lugar, cosa o evento concreto)
de la entidad se denomina Instancia o ejemplar.
Las entidades se representan grficamente mediante rectngulos y su nombre
aparece en el interior. Un nombre de entidad slo puede aparecer una vez en el
esquema conceptual.
Existen dos categoras de entidades:
Regulares o fuertes
Son aquellas que existen por s mismas y que la existencia de una instancia o
ejemplar en la entidad no depende de la existencia de otrasinstancias en otra
entidad. Larepresentacin grfica dentro del diagrama es mediante un rectngulo.
Dbiles
Son aquellas entidades en las que se hace necesaria la existencia deinstancias de
otras entidades distintas para que puedan existir instancias en esta entidad.
La representacin grfica dentro del diagrama es mediante un rectngulo con las
esquinas ovaladas.
Un ejemplo de entidad dbil sera EJEMPLAR, ya que la existencia de unainstancia
depende de la existencia del LIBRO, y por tanto, la desaparicin de un determinado
libro dela base de datos hace que desaparezcan todas las instancias de dicho libro.
Su representacincomo entidades sera la siguiente:
LIBRO
EJEMPLAR
Pg.17

D
Uno de los problemas que existirn en el diseo E/R es la decisin de si un

determinado objeto o concepto se modela como un tipo de entidad o no. Por
ejemplo, el color es habitualmente una propiedad de una entidad (como es el caso
del color de un coche), pero en una fbrica de pinturas probablemente sera
apropiado modelar el color como una entidad con sus propias propiedades.
Por esta razn, algunos autores han intentado precisar el concepto de entidad. As,
TARDIEU (1979) proponen tres reglas generales que debe cumplir una entidad:
tiene que tener existencia propia
cada instancia de un tipo de entidad debe poder distinguirse de las dems
todos los ejemplares de un tipo de entidad deben tener las mismas

propiedades
Como se puede observar por la propia definicin, las entidades dbiles nunca
cumplirn la primera regla.
Atributos
Los atributos se utilizan para detallar las entidades asignndoles propiedades
descriptivas tales como nombre, color y peso. Los atributos son cada una de las
propiedades o caractersticas que tiene un tipo de entidad o un tipo de interrelacin.
La existencia de un atributo est ligada a la del correspondiente tipo (de entidad o de
interrelacin.
Existen dos tipos de atributos: identificadores y descriptores. Los primeros se utilizan
para distinguir de manera nica cada una de las ocurrencias de una entidad
(distinguindose entre identificadores principales e identificadores alternativos),
mientras que los descriptores de utilizan para describir una ocurrencia de entidad.
No slo es posible especificar atributos en las entidades sino tambin en las
interrelaciones (en este caso slo tiene sentido hablar de atributos descriptores y no
de identificadores)
Identificadores
Entre todos los atributos de un tipo de entidad han de existir uno o varios conjuntos
de atributos (simples y/o compuestos) que identifiquen unvocamente cada una de
las instancias de ese tipo de entidad.
Cada uno de estos conjuntos de atributos se denomina Identificador Candidato
(IC). Todo IC debe cumplir la condicin de ser unvoco y mnimo(Criterio de
Unicidad y Criterio de Minimidad).
Cuando un IC es compuesto, el nmero de los atributos que lo componen debe ser
mnimo, en el sentido de que la eliminacin de cualquiera de ellos le hara perder su
carcter de identificador.
Pg.18

D
Entre los IC se elige uno como Identificador Principal (IP) y el resto sern
Identificadores Alternativos (IA).
En la notacin los atributos de una entidad se representan grficamente as:
El atributo identificador o atributo clave se muestra subrayado. En el Modelo

Conceptual se deben considerar solo los atributos ms relevantes.
Pg.19

D
Atributos Multivaluados vs Univaluados

Los atributos Multivaluadosson aquellos que pueden tomar ms de un valor a la
vez (una persona puede tener ms de un telfono). Los atributos Univaluados:
toman un solo valor.
Atributos Opcionales vs Obligatorios:

Opcionales: Por otro lado, puede obligarse a un atributo de un tipo de entidad a que
tome, como mnimo, un valor del (o de los) dominio(s) subyacente(s) para cada
ejemplar de entidad, es decir, el valor de ese atributo es obligatorio(no puede ser
nulo) para toda instancia de la entidad
Relaciones
Se entiende por relacin una asociacin, vinculacin o correspondencia entre
entidades.
Distinguiremos entre el tipo de relacin o estructura genrica que describe un
conjunto de relaciones, y cada relacin, es decir, cada uno de las instancias
concretas.
Un ejemplo de relacin sera: imparte es un tipo de relacin que vincula los tipos de
entidad PROFESOR y CURSO; una instancia del tipo de relacin imparte es la
vinculacin entre el profesor Carrasco y el curso Modelamiento de Datos.
Elementos de un tipo de interrelacin

En una interrelacin podemos encontrar lo siguientes elementos:
Nombre: identificador nico en el esquema.
Pg.20

D
Cardinalidad de una relacin

La cardinalidad establece cuntas instancias de una entidad estn relacionadas con
una instancia de la otra entidad.
Segn su cardinalidad, las relaciones pueden ser:
De uno a uno
De uno a muchos
De muchos a muchos
Ejemplos de la cardinalidad
Ventajas del Diseo Conceptual

Finalmente podemos observar los siguientes beneficios del Diseo Conceptual:
Herramienta de comunicacin para audiencias no tcnicas y tcnicas
Permite la Implementacin de mltiples DBMSs
Las bases de datos y aplicaciones son mas adaptables a los cambios
Las bases de datos y aplicaciones representan mejor a las necesidades de
los negocios y usuarios finales
Disminuye horas de diseo inicial y posterior mantenimiento.
Pg.21

D
EJERCICIO 2 de Modelo Conceptual

Se desea disear una base de datos que guarde la informacin de las
reservas de una empresa dedicada al alquiler de automviles. Los supuestos
semnticos son los siguientes:
1. Un determinado cliente puede tener en un momento dado varias reservas.
2. Una reserva la realiza un nico cliente, pero puede involucrar a varios
coches.
3. Es importante registrar la fecha de comienzo de la reserva y la de
terminacin.
4. Todo coche tiene siempre asignado un nmero determinado de garaje, que
no puede cambiar.
5. Cada reserva se realiza en una determinada agencia.
6. En la base de datos pueden existir clientes que no hayan hecho ninguna
reserva.
7. Todas las entidades tienen una clave alfanumrica que las identifica
unvocamente.
Se pide realizar el diseo del modelo Conceptual e indicar aquellos supuestos

que no se han considerado.
Solucin:
Primero se identifican las Entidades existentes:
CLIENTE
RESERVA
AGENCIA
COCHE
GARAJE
Se verifican si son entidades si cumplen con:
tener varias Instancias
tener varios atributos
Luego se grafican las entidades en un diagrama, relacionando las entidades

segn las reglas de negocios y la forma en que se comunican las entidades
unas con otras.
Pg.22

D
Por ejemplo un cliente se relaciona con un coche por que este lo a usar, pero
antes de llevarse el coche, primero tiene que separa una reserva, luego la
relacin ms inmediata de la entidad Cliente es con la entidad Reserva.
Luego debemos encontrar las cardinalidades de cada relacin verificando las

siguientes posibilidades.
Suponiendo que tenemos dos entidades A y B :
Se verifican todas las posibilidades de A hacia B y de B hacia A

1
1
M
M
1
Luego el modelo con sus cardinalidades incluidas seria:
Pg.23

D
EJERCICIO 2
A partir dela siguiente realidad propuesta, disear el modelo conceptual
correspondiente:
La clnica SANTO TOMAS necesita llevar un control informatizado de su gestin de
pacientes y mdicos.
De cada paciente se desea guardar el cdigo, nombre, apellidos, direccin,
poblacin, provincia, cdigo postal, telfono y fecha de nacimiento.
De cada mdico se desea guardar el cdigo, nombre, apellidos, telfono y
especialidad.
Se desea llevar el control de cada uno de los ingresos que el paciente hace en el
hospital.
Cada ingreso que realiza el paciente queda registrado en la base de datos. De cada
ingreso se guarda el cdigo de ingreso (que se incrementar automticamente cada
vez que el paciente realice un ingreso), el nmero de habitacin y cama en la que el
paciente realiza el ingreso y la fecha de ingreso.
Un mdico puede atender varios ingresos, pero el ingreso de un paciente solo puede
ser atendido por un nico mdico. Un paciente puede realizar varios ingresos en la
clnica.
Pg.24

D
EJERCICIO 3
A partir del siguiente enunciado se desea realizar el modelo conceptual
correspondiente.
Se desea informatizar la gestin de una empresa de transportes que reparte
paquetes por todo el Pas. Los encargados de llevar los paquetes son los
camioneros, de los que se quiere guardar el DNI, nombre, telfono, direccin, salario
y poblacin en la que vive. De los paquetes transportados interesa conocer el cdigo
de paquete, descripcin, destinatario y direccin del destinatario. Un camionero
distribuye muchos paquetes, y un paquete slo puede ser distribuido por un
camionero.
De las provincias a las que llegan los paquetes interesa guardar el cdigo de
provincia y el nombre. Un paquete slo puede llegar a una provincia. Sin embargo, a
una provincia pueden llegar varios paquetes.
De los camiones que llevan los camioneros, interesa conocer la matrcula, modelo,
tipo y potencia. Un camionero puede conducir diferentes camiones en fechas
diferentes, y un camin puede ser conducido por varios camioneros.
Ejercicio 4
La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio,
emplear una base de datos para almacenar la informacin referente a las pelculas
que ofrece en alquiler. Esta informacin es la siguiente:
Una pelcula se caracteriza por su ttulo, nacionalidad, productora y fecha (p.e., Quo
Vadis, Estados Unidos, M.G.M., 1955).
En una pelcula pueden participar varios actores (nombre, nacionalidad, sexo)
algunos de ellos como actores principales.
Una pelcula est dirigida por un director (nombre, nacionalidad).
De cada pelcula se dispone de uno o varios ejemplares diferenciados por un
nmero de ejemplar y caracterizados por su estado de conservacin.
Un ejemplar se puede encontrar alquilado a algn cliente (nombre, direccin,
telfono). Se desea almacenar la fecha de comienzo del alquiler y la de devolucin.
Cada socio puede alquilar como mximo 4 ejemplares.
Un socio tiene que ser avalado por otro socio, que responda de l en caso de tener
problemas en el alquiler.
Pg.25

D
Ejercicio 5
Una empresa de transporte de pasajeros requiere se le disee una Base de Datos
que cumpla con los siguientes requerimientos:
La empresa se dedica al transporte interprovincial de pasajeros entre las principales
ciudades del pas.
Todas sus rutas son directas; es decir, que partiendo de la ciudad de origen se
dirigen sin escalas a la ciudad destino.
Cada ruta tiene una ciudad de origen, una hora de salida programada, una hora de
salida real, una ciudad destino, una hora de llegada programada, una hora de
llegada real.
Para cada ruta se tiene dos tipos de pasajes: Estndar (asiento pulman) y Premium
(asiento-cama).
Las unidades de transporte se han adquirido de distintos fabricantes y tienen distinta
capacidad e pasajeros. Hay unidades para 30 pasajeros, unidades para 40
pasajeros, etc.
Para cada viaje se asignan 2 choferes. Adems, en cada viaje se tiene a bordo a
una azafata para la atencin a los pasajeros.
En los controles de salida y entrada de las ciudades se debe entregar una relacin
de pasajeros que van en el viaje, as como de la tripulacin.
La BD debe permitir el control de la venta de pasajes, de las unidades de transporte
utilizadas, de la tripulacin asignada, y del viaje.
Presentar el modelo de datos conceptual.
Solucin:
Pg.26

D
EJERCICIO 6
A partir del siguiente supuesto disear el modelo conceptual:
Se desea disear una base de datos para almacenar y gestionar la informacin
empleada por una empresa dedicada a la venta de automviles, teniendo en cuenta
los siguientes aspectos:
La empresa dispone de una serie de coches para su venta. Se necesita conocer la
matrcula, marca y modelo, el color y el precio de venta de cada coche.
Los datos que interesa conocer de cada cliente son el RUC, nombre, direccin,
ciudad y nmero de telfono: adems, los clientes se diferencian por un cdigo
interno de la empresa que se incrementa automticamente cuando un cliente se da
de alta en ella. Un cliente puede comprar tantos coches como desee a la empresa.
Un coche determinado solo puede ser comprado por un nico cliente.
El concesionario tambin se encarga de llevar a cabo las revisiones que se realizan
a cada coche. Cada revisin tiene asociado un cdigo que se incrementa
automticamente por cada revisin que se haga. De cada revisin se desea saber si
se ha hecho cambio de filtro, si se ha hecho cambio de aceite, si se ha hecho
cambio de frenos u otros. Los coches pueden pasar varias revisiones en el
concesionario.
Pg.27

CAPTULO
D
Diseo Lgico
El diseo lgico parte del esquema conceptual y se obtiene como resultado un
esquema lgico de base de datos. Un esquema lgico es una descripcin de la
estructura de la base de datos que puede procesar el software de DBMS. Un
modelo lgico es un lenguaje usado para especificar esquemas lgicos. Los
modelos lgicos ms utilizados son:
Redes
Jerrquico
Relacional
El modelo relacional
En el modelo relacional los datos tienen una estructura de registros de longitud
fija con un nmero fijo de campos o atributos. Los datos se representan en
formato de filas y columnas.
La base del modelo relacional es la tabla o relacin, un ordenamiento
rectangular de filas y columnas de los valores de los datos.
Pg.28

D
Tabla
La estructura fundamental del modelo relacional es la tabla bidimensional
constituida por filas (tuplas) y columnas (atributos). Las relaciones representan
las entidades que se consideran interesantes en la base de datos. Cada
instancia de la entidad encontrar sitio en una tupla de la relacin, mientras
que los atributos de la relacin representan las propiedades de la entidad.
Por ejemplo, si en la base de datos se tienen que representar personas, podr
definirse una relacin llamada "Personas", cuyos atributos describen las
caractersticas de las personas. Cada tupla de la relacin "Personas"
representar una persona concreta.
Por ejemplo, la relacin: Personas (DNI, nombre, apellido, sexo, estadoCivil,
fechaNacimiento) es apenas una definicin de la estructura de la tabla, es
decir su nombre y la lista de atributos que la componen. Si esta estructura se
puebla con datos, entonces tendremos una lista de valores individuales para
cada tupla, atributo por atributo.
Fila, registro tupla

Las tuplas en una relacin son un conjunto en el sentido matemtico del
trmino, es decir una coleccin no ordenada de elementos diferentes. Para
distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea un
atributo o conjunto de atributos que permiten identificar unvocamente una
tupla en una relacin (en el ejemplo, el atributo DNI cumple con esta funcin).
Columna, campo o atributo

Una relacin o tabla contienen un conjunto de atributos que tambin se
conocen como columna o campo. Cada atributo debe estar definido sobre un
dominio
Dominio.
Cada atributo de una relacin se caracteriza por un nombre y por un dominio.
El dominio indica qu valores pueden ser asumidos por una columna de la
relacin. A menudo un dominio se define a travs de la declaracin de un tipo
para el atributo (por ejemplo diciendo que es una cadena de diez caracteres),
pero tambin es posible definir dominios ms complejos y precisos.
Por ejemplo, para el atributo "sexo" de nuestra relacin "Personas" podemos
definir un dominio por el cual los nicos valores vlidos son 'M' y 'F'; o bien
para el atributo "fechaNacimiento" podremos definir un dominio por el que se
consideren vlidas slo las fechas de nacimiento despus del uno de enero de
1960, si en nuestra base de datos no est previsto que haya personas con
fecha de nacimiento anterior a esa.
Pg.29

D
En forma general podemos definir cuatro tipos de dominio para el Modelo

Lgico:
Texto
Numero
Fecha
Otros
Como podemos observar estos dominios son muy genricos, es decir no se

entra en muchos detalles todava, un dominio tipo numero puede ser un entero
grande o pequeo real o dinero, este detalle no interesa todava en el modelo
Lgico. Posteriormente se entrar en un detalle msespecfico del tipo de dato
en el Modelo Fsico.
Clave primaria
La clave primaria sirve para identificar unvocamente a cada instancia de la
entidad, y puede estar formada por uno o ms atributos. Cuando una clave
est formada por ms de un atributo se la conoce como clave compuesta. A
la clave primaria se le conoce tambin como PK (PrimaryKey). En ocasiones,
para una entidad dada, ms de un atributo o conjunto de atributos puede ser
seleccionado como clave. Estos atributos o conjuntos de atributos se conocen
como claves candidatas.
Criterios para establecer la PK

Para establecer la PK se debe tener en cuenta los siguientes criterios:
Criterio de Unicidad. Los atributos seleccionados como PK deben identificar

unvocamente a una instancia de la entidad (no puede existir dos instancias con
un mismo valor para la PK).
Criterio de Minimidad. El nmero de atributos que se selecciona como la clave

primaria (PK) debe ser el mnimo.
Las claves que solo cumplen con el criterio de unicidad, son solo claves
candidatas.
Clave fornea
La clave fornea, tambin denominada FK (ForeignKey) es el atributo de una
entidad que la relaciona con otra entidad a travs de la clave primaria de sta.
La clave fornea es un atributo que es clave primaria en la otra entidad.
Pg.30

D
Como se observa en el diagrama, el atributo IdCliente es la clave primaria de

la entidad CLIENTE, y se ha definido como la clave fornea de la entidad
PEDIDO.
Para que dos entidades se relacionen deben tener datos en comn; esto es,
atributos en comn. Los atributos relacionados no necesitan tener el mismo
nombre. Es suficiente que sus valores posibles correspondan al mismo
dominio.
Transformacin del Modelo Conceptual en el Modelo

Lgico correspondiente.
Para obtener el esquema lgico de base de datos, en primer lugar se debe
tener a la mano el esquema conceptual de base de datos.
En segundo lugar se debe seleccionar el modelo lgico a utilizar. En el curso
utilizamos el modelo lgico Relacional explicado anteriormente.
Finalmente se aplicar las reglas de transformacin que a continuacin se
detallan.
Reglas de transformacin
1. Toda entidad se convierte en una tabla o relacin que toma el nombre de la
entidad. Los atributos de la entidad sern las columnas de la tabla y el
atributo identificador principal ser la clave primaria. A menos que se indique
lo contrario los atributos no identificadores podrn tomar valores nulos.
2. Las interrelaciones 1:N1:1se transforman propagando el atributo
identificador principal de la entidad que tiene cardinalidad mxima 1 a la que
tiene cardinalidad mxima N. Si la relacin fuese 1:1 la propagacin de clave
Pg.31

D
podra hacerse en cualquier sentido. El atributo propagado es una clave

ajena que referencia a la tabla con cardinalidad mxima de 1.
3. Las interrelaciones N:M se transforman en una tabla cuya clave primaria
ser la concatenacin de los atributos principales de las entidades que se
asocia; estos atributos sern claves ajenas que referencian a las respectivas
tablas donde son claves primarias. Los atributos de la interrelacin sern
columnas de la tabla.
Ejemplos de Transformacin
Transformando al Modelo Lgico:
Los atributos identificadores se transforman en Claves Primarias (PK)

La relacin de cardinalidad de uno a muchos se transforma en una relacin No
Identificadora, y se grafica con lnea discontinua.
Pg.32

D
Otro ejemplo de transformacin
Transformando al Modelo Lgico correspondiente:
La relacin de cardinalidad de muchos a muchos se transforma en una

relacin Identificadora.
Entre las dos entidades iniciales se grafica una entidad intermedia cuya PK
est conformada por las PKs de las otras dos.
La PK de la nueva entidad intermedia se compone por las PKs de las otras
dos, las cuales pasan a la entidad intermedia como Claves Forneas (FK)
La relacin Identificadora se grafica con lneacontinua.
Pg.33

D
Ejemplo 1 de Transformacin
Se desea disear una base de datos que guarde la informacin de las
reservas de una empresa dedicada al alquiler de automviles. Los supuestos
semnticos son los siguientes:
Un determinado cliente puede tener en un momento dado varias reservas.
Una reserva la realiza un nico cliente, pero puede involucrar a varios coches.
Es importante registrar la fecha de comienzo de la reserva y la de
terminacin.
Todo coche tiene siempre asignado un nmero determinado de garaje, que no
puede cambiar.
Cada reserva se realiza en una determinada agencia.
En la base de datos pueden existir clientes que no hayan hecho ninguna
reserva.
Todas las entidades tienen una clave alfanumrica que las identifica
unvocamente.
Se pide realizar el diseo del modelo E/R e indicar aquellos supuestos que no
se han considerado.
Solucin:
Modelo Conceptual
Pg.34

D
Transformado el Modelo Conceptual al Modelo Lgico correspondiente:
Este Modelo puede pasarse a una herramienta CASE como es el caso del
ERWIN.
El docente indicara los pasos para usar el ERWIN en clase.
Pg.35

D
Ejemplo 2 de Transformacin
La base de datos COMPAIA debe almacenar informacin de los empleados,
departamentos y proyectos de una empresa, de acuerdo con los siguientes
requisitos:
La compaa est organizada en departamentos. Cada departamento tiene un
nombre nico, un nmero nico y un empleado que la dirige y estamos
interesados en guardar la fecha en que dicho empleado comenz a dirigir el
departamento.
Un departamento puede estar distribuido en varios lugares.
Cada departamento controla un cierto nmero de proyectos, cada uno de los
cuales tiene un nombre y un nmero nicos, y se realiza en un slo lugar.
Se almacena el nombre, nmero de la Seguridad Social, direccin, salario,
sexoy fecha de nacimiento de cada empleado. Todo empleado est asignado
a un Departamento, pero puede trabajar en varios proyectos que no tienen por
qu ser del mismo departamento. Nos interesa saber el nmero de horas que
un empleado trabaja en cada proyecto a los que est asignado.
Tambin se quiere guardar la relacin de las cargas familiares de cada
empleado para administrar el seguro que poseen. Almacenaremos el nombre,
sexo y fecha de nacimiento de cada una de las cargas familiares y su
parentesco con el empleado.
Solucin:
Pg.36

D
Tipos de relaciones adicionales

Subtipos y supertipos
Un subtipo o sub-entidad es un subconjunto de otra entidad. Consideremos
el modelo de datos de una entidad financiera que tiene distintos tipos de
CUENTAs:
Cuenta de ahorros: nmero de la cuenta de ahorros, fecha de apertura, fecha
de revisin, balance, tasa de inters, inters ganado.
Cuenta corriente: nmero de la cuenta corriente, fecha de apertura, fecha de
revisin, balance, balance disponible, cargo por cuenta corriente.
Cuenta de prstamo: nmero de la cuenta de prstamo, fecha de apertura,
fecha de revisin, monto del prstamo, tasa de inters, balance actual.
Observe que las distintas cuentas tienen atributos comunes que se pueden
agrupar en un supertipoo entidad generalizada, crendose de esta manera
una estructura jerrquica de entidades.
Cada una de las cuentas y los atributos que son exclusivos de ella formara un
subtipo o sub-entidad.
Su representacin en el Modelo Conceptual sera el siguiente
Pg.37

D
Al transformar al Modelo Lgico tendramos:
Pg.38

D
Relaciones Ternarias
Supongamos el caso de varias COMPAIAs que venden varios PRODUCTOs
a varios CLIENTEs. Esta situacin se puede representar mediante dos
relaciones binarias, tal como se muestra en el diagrama siguiente.
En el Modelo Conceptual tendramos:
Y su transformacin en el Modelo Lgico sera:
El Modelo Conceptual anterior se puede convertir en uno que utiliza relaciones

ternarias.
Pg.39

D
Y su equivalente en el Modelo Lgico sera:
El diagrama demuestra que un CONTRATO representa tres formas de relaciones

entre COMPAA, PRODUCTO y CLIENTE: la relacin entre la compaa y el
producto que es vendido, la relacin entre el cliente y el producto que compra, y la
relacin del cliente con la compaa.
Ejercicio 1 de Relacin Ternaria

La empresa de desarrollo de software ABC.NET tiene en la actualidad 5 proyectos
en ejecucin y 4 proyectos por iniciar. Cada uno de los proyectos incluye software,
equipos y repuestos (hardware) que son abastecidos por 8 empresas mayoristas. El
gerente general desea que se elabore un reporte donde se indique la cantidad de
productos que cada proveedor abasteci a cada uno de los proyectos. Dibujar el
diagrama E/R.
Disear el Modelo Conceptual y el Modelo Lgico.

Solucin:
Las Entidades involucradas son:
PROYECTO
EQUIPO
PROVEEDOR
Pg.40

D
El Modelo Conceptual sera:
Pg.41

CAPTULO
D
NORMALIZACION
La Normalizacin es un proceso que permite remplazar las relaciones
complejas entre los Datos por relaciones ms sencillas de tal manera que se
facilita la comprensin y el desarrollo del procesamiento de datos.
La idea bsica de la normalizacin es reducir una estructura de datos compleja
(multidimensional) a un grupo de entidades y relaciones ms simples.
Los objetivos principales de la Normalizacin son facilitar la actualizacin de la
Base de Datos, eliminar las redundancias y las anomalas de actualizacin, de
manera tal que se maneje adecuadamente la integridad y consistencia de los
datos. El modelo normalizado finalmente debe corresponder y reflejar la
realidad a partir de la cual se dise.
La integridad de datos, se puede asociar en general a restricciones que
permitan asegurar que los cambios o actualizaciones que efectan los
usuarios en la Base de Datos, no resulten en una prdida de consistencia de
stas, es decir se debe contar con mecanismos que permitan proteger la Base
de Datos.
El concepto de la Normalizacin de los datos tuvo su origen en la teora
relacional numrica y fue planteada formalmente por Edgard F. Codd. Codd
encontr en esta teora una forma elegante de presentar un mtodo para el
trabajo de modelar los datos; esta es la razn por la cual debe seguir estos
procedimientos, llamados formas normales, de manera rgida y en forma
ordenada. Esto quiere decir que primero se debe pasar a la Primera Forma
normal, luego a la Segunda Forma Normal luego a la Tercera y as
sucesivamente. No se debe alterar esta secuencia.
Codd planteo inicialmente la Primera Forma Normal (1FN) , la Segunda Forma
Normal (2FN) y la Tercera Forma Normal (3FN), posteriormente en 1971
Heath reformul la 3FN y en 1977 Fagin defini la Cuarta Forma Normal
(4FN).
La presentacin formal de la teora de la Normalizacin exige un bagaje
matemtico, con sus correspondientes algoritmos, y es solo indispensable en
una formacin acadmica universitaria. No pretendo desarrollar esta
formalizacin, sino ms bien presentar estas ideas de una manera intuitiva
para que los lectores a quienes va dirigido este trabajo, que por lo general son
personas que quieren llegar directo al grano, puedan comprender esta teora
de manera muy simple y prctica.
A continuacin plantearemos las principales formas normales, desde el punto
de vista que nos hemos propuesto
Pg.42

D
PRIMERA FORMA NORMAL ( 1FN )

Una entidad se encuentra en la primera forma normal si todos sus atributos
son simples (no descomponibles), y si no tiene grupos repetitivos.
Un atributo que forma parte del grupo repetitivo es aquel que no permite
presentar a la entidad en forma Planar. Esto quiere decir que no se puede
dibujar a la entidad en un plano debido a que puede admitir varios valores en
una misma instancia de la entidad; esto es en una misma celda.
Para obtener la 1FN debemos proceder de la siguiente manera:
Identificar la clave primaria en la entidad compleja

Identificar los grupos repetitivos en la entidad compleja.
Rescribir la entidad compleja original sin los grupos repetitivos.
Crear una segunda entidad con los grupos repetitivos
Aadir la clave de la primera entidad (la original) a la segunda entidad.
Para observar con mayor claridad la forma de aplicar las formas normales voy
a plantear un caso prctico, y en l iremos desarrollando las diferentes formas
normales. Supongamos que al estudiar una realidad de un negocio se nos
presenta un documento como el que se muestra a continuacin:
Identificar la clave primaria en la entidad compleja

Lo primero que debemos hacer es, a partir del documento obtenido de la
realidad capturar los Atributos que se presentan el este en una entidad
compleja en forma de datos, y establecer un nombre apropiado a cada
atributo reconocido
Pg.43

D
Entidad Compleja
A continuacin determinaremos la Clave Primaria (PK), usando los criterios de

Unicidad y de Minimidad reconocemos como PK al Atributo NroBol. Con el
NroBol podemos identificar unvocamente a cualquiera de las diferentes
boletas que conforman las instancias de la entidad compleja.
Identificar los grupos repetitivos en la entidad compleja.

Luego debemos identificar a los atributos que forman el Grupo Repetitivo, para
lo cual utilizaremos un mtodo prctico que consiste en tratar de representar a
la entidad compleja como una Tabla con filas y columnas, donde cada fila
representa una instancia de la entidad, y las columnas sus atributos.
Como se puede observar los atributos que forman parte del grupo repetitivo
son desde Cod hasta Subtotal que son los atributos que tienen varios datos
para una misma celda. Por ejemplo en la celda que corresponde a la columna
del Cod en la primera fila debe estar el dato P104, pero tambin en esta
misma fila deberan estar los datos P089 y P133, ya que corresponden a la
misma Boleta o sea a la misma instancia; estos datos no se podran ubicar
mas abajo, en al siguiente fila, porque estos lugares corresponden a otra fila
a otra instancia. Luego estos tres datos deben ubicarse en la misma celda
yuxtaponindose entre ellos; por lo tanto los datos de este atributo no
permiten representar a la entidad en un plano sino ms bien en una
representacin espacial.; luego este atributo se dice forma parte del grupo
repetitivo.
Lo anterior tambin se aplica para los atributos Producto, Unidad, Can, PU, y
SubTotal
Pg.44

D
Rescribir la entidad compleja original sin los grupos repetitivos.
La entidad compleja anterior quedara sin los atributos que conforman el grupo
repetitivo. A esta entidad resultante le llamaremos momentneamente Entidad
A :
Crear una segunda entidad con los grupos repetitivos y

Aadir la clave de la primera entidad (la original) a la segunda entidad.
Con los atributos extrados se forma otra entidad, agregndole la PK de la
entidad A, de manera que se conserva la relacin entre estas dos entidades
resultantes. A esta entidad la llamaremos
Entidad B.
NroBol
Cod
Producto Unidad
Can
PU
SubTotal
Luego tenemos como resultado de aplicar la 1FN a la entidad compleja, las

entidades A y B , las cuales se encuentran en primera forma normal, lo cual
quiere decir que se pueden representar dichas entidades en forma planar.
SEGUNDA FORMA NORMAL ( 2FN )

Para pasar una entidad a la segunda forma norma, el primer requisito es que
ya se encuentre en primera forma normal; luego se deben eliminar los
atributos que tengan Dependencias parciales.
Con estos atributos extrados se den formar otras entidades. Una entidad se
encuentra en la segunda forma normal si ya est en la 1FN y adems cada
atributo no clave es completamente dependiente de la Clave primaria.
Dependencia Parcial.
Supongamos que tenemos una entidad como la siguiente, donde la PK es
compuesta y est formada por los atributos A y B:
Pg.45

D
El atributo C depende funcionalmente de la PK; esto quiere decir que para

identificar plenamente al atributo C se necesitan conocer a todos los atributos
que conforman la PK ( A y B ). Lo mismo se aplica para el atributo D de la
figura.
Por otro lado el atributo E se puede identificar tan solo conociendo el atributo
B, sin necesidad de conocer el atributo A. Luego se puede afirmar que el
atributo E tiene una dependencia funcional parcial de la PK.
En nuestro caso ejemplo, tenemos dos entidades A y B resultantes que se
encuentran en Primera Forma Normal; luego son candidatas a aplicarles la
Segunda Forma Normal.
En el caso de la entidad A, podemos observar que la PK est formada por un
solo atributo, luego es imposible encontrar alguna dependencia parcial de
cualquier atributo que se identifique con la PK, ya que al depender
funcionalmente de la PK depender de toda, no de una parte de ella.
Por ejemplo un cliente ( IdCli ) se identifica con un nmero de boleta ( NroBol )
no puede ser con una parte del nmero de boleta
Podemos concluir entonces que, si una entidad ya est en 1FN, y su PK es

simple, (formada por un solo atributo), no tendr dependencias parciales,
luego ya se encuentra en 2FN. O como corolario, que solo existir posibilidad
de encontrar dependencias parciales en una entidad, si su PK es compuesta
(formada por ms de un atributo).
En la entidad B debemos encontrar la PK para luego buscar dependencias
parciales. La PK debe cumplir con el criterio de unicidad, luego graficamos a la
entidad en una tabla donde cada fila es una instancia:
Pg.46

D
NroBol
Cod
Producto
Unid
Can
ad
PU
1356
P104
Arroz del No
Saco
130.00 260.00
1356
P089
Leche Gloria
Caja
120.00 360.00
1356
P133
Aceite El Sol
Caja
90.00
1357
P104
Arroz del No
Saco
135.00 540.00
...
SubTotal
450.00
Aqu se puede observar que el NroBol se puede repetir en diferentes

instancias de la entidad B, esto se debe a que es una Clave Fornea (FK).
Pero con solo este atributo no se puede identificar plenamente a una instancia
en particular de esta entidad.
Por ejemplo si tuviramos el NroBol 356 tendramos tres casos que cumplen
con este valor. Luego, se debe recurrir a otro atributo adicional para formar la
PK.
Un posible candidato podra ser el atributo Producto; Si tenemos el NroBol
356 y el Producto Arroz del Norte, identificamos inmediatamente a la primera
fila de la tabla. La cuarta fila no podra ser por pertenecer a otra boleta ( 357 ).
Por lo tanto la combinacin NroBol + Producto cumple con el criterio de
Unicidad.
Otra posible combinacin sera NroBol + idProd, y como podemos observar
tambin cumple con el primer criterio de Minimidad. Pero adems es ms
pequea que la primera candidata; Por lo tanto tambin cumple con el criterio
de Minimidad.
Finalmente elegimos a la combinacin NroBol + idProd como la PK de la
entidad B:
A continuacin graficamos a la entidad identificando a su PK, para investigar si
existen dependencias parciales.
Pg.47

D
En el grafico se puede observar que los atributos Producto (Nombre del

producto) y Unidad (unidad en que se comercializa el producto), se pueden
identificar solo con conocer el Cod(el cdigo del producto debe ser nico por
producto).
Luego no necesitan al toda la PK para ser identificados, por lo tanto tienen
dependencia funcional parcial de la PK.
Para pasar a la 2FN se deben eliminar los atributos que originen dependencias
parciales:
Pg.48

D
Entidad B1
Y con los atributos eliminados tenemos:
Entidad B2
Aqu podemos observar que tambin se llev al atributo del cual dependan
funcionalmente en la entidad B, esto asegura la relacin entre las entidades
resultantes. Adems identificamos al atributo Cod como PK en esta nueva
entidad resultante B2.
Hasta este momento, en este ejemplo, tenemos tres entidades resultantes en
2FN :A, B1, y B2.
TERCERA FORMA NORMAL ( 3FN )

Una entidad se encuentra en la Tercera Forma Normal si ya est en la 2FN, y
adems no tiene atributos con dependencia Transitiva; es decir, atributos
que se pueden obtener a partir de otros.
Para obtener la 3FN se deben seguir los siguientes pasos:
Remover los atributos transitivos
Formar nuevas entidades con estos atributos y encontrar en estas su

clave primaria
En nuestro ejemplo anterior, notamos que las entidades B1 y B2 tienen

dependencias funcionales directas, luego no existen dependencias transitivas,
por lo tanto estas entidades ya se encuentran en tercera Forma Normal.
Pg.49

D
En el caso de la entidad A debemos investigar las dependencias funcionales

de sus atributos, para ello trazamos las lneas de dependencia respectivas:
Podemos reconocer dos atributos con dependencias transitivas; Cliente (el

nombre del cliente) se puede identificar con el IdCli (cdigo del cliente), a su
vez el IdCli se puede identificar con el NroBol (el nmero de boleta), que es la
PK de la entidad; as podemos afirmar que el atributo Cliente tiene una
dependencia transitiva de la PK.
Del mismo modo se puede afirmar que el atributo NomVend tiene otra
dependencia transitiva de la PK.
A continuacin procedemos a eliminar estas dependencias transitivas de la
entidad A y obtenemos la siguiente entidad resultante:
Entidad A1
A continuacin con los atributos extrados formamos otras entidades:
Entidad A2
Pg.50

D
Entidad A3
Observaremos que, en la entidad A2 se ha incluido tambin el atributo IdCli del

cual dependa en la entidad A. Esto asegura la relacin entre las entidades
resultantes. Adems el atributo IdCli es ahora PK en la entidad A2.
Del mismo modo se observa que en la entidad A3 la PK es ahora NomVend.
Cuando se tiene, que las entidades resultantes solo tienen dependencias
directas y totales (obsrvese las lneas de dependencia), podemos afirmar que
el proceso de normalizacin ha terminado.
Como resultado final entonces tenemos en este caso cinco entidades:
A1
A2 A3 B1 B2
A continuacin se debe poner nombres ms especficos, que reflejen su

esencia, (en singular), a estas entidades resultantes:
A1
BOLETA
A2
CLIENTE
A3
VENDEDOR
B1
DETALLEBOLETA
B2
PRODUCTO
El siguiente paso es construir el Diagrama Entidad Relacin con estas

entidades resultantes del proceso de normalizacin.
Primero se dibujan las entidades con sus atributos indicado en la parte
superior del cuadriltero que representa a cada entidad a la PK en un
recuadro. Las claves forneas se deben indicar para establecer luego las
relaciones. El diagrama debe mostrar lo siguiente:
Pg.51

D
Luego hay que definir el tipo de relacin a establecer entre las entidades; por
ejemplo vamos determinar el tipo de relacin que existe entre la entidad
VENDEDOR y la entidad BOLETA, que como ya se haba determinado en el
proceso de la Normalizacin, el nexo entre estas dos entidades es el atributo
IdVend.
Se observa que el atributo nexo es PK en la entidad VENDEDOR y , a su vez
es FK en la entidad BOLETA; por esta razn, para esta relacin en particular
VENDEDOR es la Entidad Padre, y BOLETA es la Entidad Hija.
Adems para determinar una instancia en particular en la entidad Hija no se
necesita conocer IdVend (al vendedor); luego podemos especificar un nmero
de boleta, por ejemplo 356 y ya podemos esa boleta; no hubo necesidad de
especificar el vendedor (IdVend).
Adems si solo tuviramos como dato el cdigo del vendedor (IdVend) no
podramos particularizar una boleta, pues pueden existir muchas boletas
relacionadas con un mismo vendedor. Por lo tanto podemos afirmar que la
relacin existente entre VENDEDOR y BOLETA es una RELACIN NO
IDENTIFICADORA.
A continuacin tazamos la lnea de relacin entre las dos entidades:
Pg.52

D
La lnea de relacin parte de la entidad Padre, sealando a la PK con

Cardinalidad uno, y llegando a la entidad Hija con Cardinalidad uno o muchos.
Esta Cardinalidad inicial podr variarse luego verificando las reglas de
negocio de la realidad que estamos modelando.
Ntese que en una relacin identificadora, la entidad Hija tiene a la FK como
un atributo comn ms.
En el caso de la relacin entre CLIENTE y BOLETA tambin se cumple algo
similar, y luego se determina que la relacin existente entre esta dos
entidades tambin es una RELACION NO IDENTIFICADORA.
Con respecto a la relacin entre BOLETA y DETALLEBOLETA, el atributo que
sirve de nexo entre las entidades en el atributo NroBol podemos anotar que
para identificar una instancia de DETALLEBOLETA se necesita conocer un
nmero de boleta (NroBol), si este dato ser imposible ubicar una instancia en
DETALLEBOLETA. Luego la relacin existente entre esta dos entidades en
una RELACION IDENTIFICADORA porque con la PK de BOLETA podremos
identificar alguna instancia que represente a algn detalle de la venta de un
Producto. Luego se hace tambin necesario conocer el producto que se vendi
en dicha boleta (IdProd). De esto ltimo entonces tambin se infiere que la
relacin existente entre PRODUCTO y DETALLEBOLETA es tambin una
RELACIN IDENTIFICADORA.
Finalmente llegaremos al siguiente Diagrama Entidad Relacin (E-R):
Podemos sealar que para la Relacin Identificadora la FK en la entidad Hija

figura como parte de la PK.
Podemos tambin afirmar que la entidad DETALLEBOLETA tiene instancias
que solo podrn existir si existen Boletas y Productos, luego esta entidad es
una Entidad DEPENDIENTE tambin conocida como DEBIL.
En cambio las otras entidades no necesitan de atributos forneos para
identificar a cada una de sus respectivas instancias. Luego podemos afirmar
que son Entidades INDEPENDIENTES o tambin conocidas como FUERTES.
Pg.53

D
Ejercicio 2 de Normalizacin.
Normalizar estructuras complejas de datos.
Establecer las dependencias funcionales entre los atributos.
Identificar las claves primarias y forneas.
Construir diagramas E-R
Dado el siguiente documento correspondiente a la Ficha de Matricula de un
Alumno del CEPS, obtener las Estructura compleja correspondiente y luego
aplicar las tcnicas de Normalizacin desarrolladas en clase
FICHA DE MARTICULA
Fecha:
N 20023
24/09/2011
Carrera Tcnica: Programador en Bases de Datos
Cdigo: C
Modulo: C04
Alumno: Crdova Tello, Javier
Mes Acd.
CodCurso
Nombre del Curso
3
3
2
VB2
SQ2
SQ1
Visual Basic Nivel II

SQL Server Nivel II
SQL Server Nivel I
Cdigo: 99409
Observaciones: .
Pasos a realizar en el laboratorio:

Del documento obtener las entidades que conformaran la estructura compleja.
Identificar la clave primaria.
Reconocer los Grupos Repetitivos. Utilizar la tcnica desarrollada en clase.
Aplique la primera Forma Normal.
En las entidades resultantes reconocer las dependencias parciales. (Dibujar
las lneas de dependencia )
Aplicar la Segunda Forma Normal
En las entidades resultantes reconocer las dependencias transitivas.
Aplicar la Tercera Forma Normal.
Con las entidades resultantes dibuje el Diagrama E-R correspondiente.
Pg.54

D
Identificar los Atributos que sern las Claves Principales y los Atributos que
sern Claves Forneas.
Trazar las lneas de relacin entre las entidades partiendo desde la PK en la
entidad Padre hacia la FK en la entidad Hija
Con el diagrama E-R del papel se debe construir el Modelo Lgico en Erwin
Establecer las cardinalidades correspondientes a las relaciones.
Pg.55

D
A partir del siguiente documento Normalizar y construir Diagrama E-R, El Modelo
Lgico, el Modelo Fsico. Implementar la BD en SQL Server
Biblioteca Municipal de Los Cipreses

Registro de prstamo de
libros
Nro. de Prstamo : 40289
Cd. de Lector 501
Telfono :
5447291
Nombre de Lector : Ros Prez, Juan
Cod Libro Nro Copia Titulo
Autor
CodEdit
Nombre Editorial
1005
Estadstica
Murray Spiegel
901
McGraw Hill
1007
Visual Basic. Net
E. Petroustsos
803
Anaya
Cantidad de Libros prestados : 2
1.
2.
3.
4.
5.
Fecha de Prstamo 15/03/2009
Descubrir los atributos y presentar la Entidad Compleja.

Encontrar la PK y Normalizar a la 1FN.
Normalizar a la 2FN.
Normalizar a la 3FN.
Construir el diagrama E-R.
En base al diag. Anterior construir el Modelo Lgico en Erwin.

Considerar un Precio de referencia para cada libro.
Solucin:
Pg.56

D
Dado el siguiente documento correspondiente al estado de cuenta de una tarjeta de
crdito de una entidad bancaria. Normalizar hasta la tercera forma normal y luego
dibujar el diagrama de entidades correspondiente.
Pg.57

D
En el siguiente documento se presentan los gastos por cobrar de una cadena de
edificios. El Documento tiene el cdigo NumGPCM (Numero de Gastos por cobrar
mensual). Cada edificio tiene direccin y su cdigo (E1, E2, etc.)
NumGPCM: 1003
Se pide elaborar :
La Entidad Compleja y Normalizar hasta la 3FN
Dibujar el diagrama de entidades y sus relaciones.
Pasar este diagrama al Modelo Lgico en Erwin
Solucin:
Identificamos la Entidad Compleja con los atributos que se describen en el
documento; y a continuacin encontramos los atributos que forman parte del Grupo
Repetitivo:
Pg.58

D
1FN
Luego para pasar a la Primera Forma Normal separamos el Grupo repetitivo en
otra entidad aparte llevndonos una copia de la PK para mantener el vinculo entre
las entidades resultantes:
2FN
Para pasar a la Segunda Forma Norma identificamos los atributos con
Dependencia Parcial de la Clave Primaria.
Ntese que la entidad A ya se encuentra en 2FN porque su PK es Simple (est
formada por un solo atributo).
3FN
Para pasar a la tercera forma normal verificamos las dependencias transitivas de
atributos con respecto de su clave primaria y separamos estos atributos en otra
entidad llevndonos una copia del atributo del cual dependen transitivamente de la
PK.
Pg.59

D
Finalmente representamos estas entidades resultantes en un Diagrama EntidadRelacin y luego implementamos el Modelo Lgico correspondiente en Erwin.
Pg.60

D
En el siguiente documento se presenta un listado de Ventas totales por zona y
vendedor.
Los Vendedores tienen un cdigo que los identifica (V103, V102, etc.). Cada ZONA
corresponde a un grupo de ciudades del Pas. Las lneas tienen cdigos como L1,
L2, L3, etc.
Se pide elaborar:
La entidad compleja
Normalizar hasta la 3FN
Dibujar el diagrama de Entidades con sus relaciones
Pasar al Modelo Lgico en Erwin.
Pg.61

D
ANOMALIAS ADICIONALES
Anomala de la Dependencia Condicional ( ValorNull )
Se establece cuando en una campo de una entidad para algunas instancias no
existen datos, o sea tienen valores nulos.
Por ejemplo existen algunos clientes que no tiene crdito en un grupo de clientes.
Luego en el atributo Credito de la entidad cliente existen algunas instancias que en
el atributo Credito no tienen valor alguno,(Tienen nulos).
Luego en el grafico de la entidad CLIENTE tendramos la siguiente figura:
Si se quiere eliminar esta dependencia condicional en la entidad CLIENTE, debemos

separar los atributos con dependencia Condicional y con una copia de la PK para
mantener la referencia entre las entidades resultantes.
Llevando estas entidades al modelo Lgico:
Se observa que este tipo particular de relacin la cardinalidadsiempre ser de uno

a ninguno o uno.
Pg.62

D
Se tiene una organizacin que cuenta con un sistema de lneas conectadas a una
central telefnica
Se tiene entonces a continuacin una muestra de las llamadas realizadas desde las
diferentes dependencias de la organizacin
Cada Dependencia solo dispone de un anexo para recibir o hacer llamadas.
Pg.63

D
Solucin:
Pg.64

D
Se tiene el siguiente documento correspondiente a la Planilla de Empleados deuna
empresa determinada.Obtener las Estructura compleja correspondiente y luego
aplicar las tcnicas de Normalizacin.
Planilla de empleados del mes de Enero del 2011N 200-01

Cod
Apellidos y Nombres
Dependencia
Sueldo SNP AFP NombAFP
100
Pensin Salud Vivienda Total
Logstica
95001 Coronel Castillo, Gustav 2500 S

250
95010 Flores Ramrez, Julio
2000 N INT Integra
100
96014 Marcelo Villalobos, Ricar 1000 N HOR Horizonte
100
....
..................
....
....
.........
....
..................
....
....
.........
Dependencia
900
250
200
100
125
100
50
......
......
1875
1600
750
.... ...
.... ...
....
....
Contabilidad
96601 MatsukawaMaeda, Sergi 2500 N HOR

97098 Carrasco Salas, Javier
2000 N ITG
94073 Prez Castro, Carmen
2500 S
....
..................
....
....
..................
....
Totalesxxxx
Horizonte
Integra
....
....
250
100
250
.........
.........
xxx
250
200
250
125
1875
100
1600
125
1875
......
.... ...
......
.... ...
....
....
xxxxxxxxxx
Pasos a realizar en el laboratorio:

Del documento obtener las entidades que conformaran la estructura compleja.
Identificar la clave primaria.
Aplique la primera Forma Normal.
En las entidades resultantes reconocer las dependencias parciales
Aplicar la Segunda Forma Normal
Aplicar la Tercera Forma Normal.
Identifique las dependencias condicionales
Identificar las de pendencias condicionales y separarlas en otra entidad.
Con las entidades resultantes dibuje el Diagrama E-R correspondiente.
Pg.65

D
Con el diagrama E-R del papel se debe construir el Modelo Lgico en Erwin
Establecer las cardinalidades correspondientes a las relaciones.
Solucin:
Pg.66

D
Se tiene el caso de una Empresa de fabricacin de insumos de oficina y tiles de
escritorio. El centro de produccin se encuentra en Santa Anita; El departamento de
comercializacin y marketing se encuentra en San Isidro; Los Almacenes se
encuentran en Lince y El Departamento de Contabilidad y Gerencia General se
ubica en Miraflores.
Se enva equipos a los diferentes locales con el fin de recaudar los datos necesarios
para realizar un modelo de datos y luego implementar una base de datos en SQL
Server.
Los equipos han reportado unas muestras de los documentos de Pedidos, Guas de
Remisin, Facturas y de las Boletas de Ingreso a Almacn.
Pg.67

D
GUIA DE PEDIDOS
Numero
Nombre
Cliente
Direccin Cli
Cdart.
Cantidad
Artculo
Unidad
med.
Nombre Artculo
P
u
Pedido
Fecha
Cod.Vend
Vend
Nombre Cli.
P001
14/08/2010
V004
RUIZ
ALVA
23456789
Av. Tacna 333
4234567
A004
CIENTO
Lapicero
20
P001
14/08/2010
V004
RUIZ
ALVA
23456789
Av. Tacna 333
4234567
A001
10
DOCENA
Cuaderno
10
P001
14/08/2010
V004
RUIZ
ALVA
23456789
Av. Tacna 333
4234567
A003
RESMA
Papel Bond A4
50
P002
15/08/2010
V001
CALLE
BELTRAN
87654123
Jr Trujillo 214
5566789
A002
DOCENA
Borrador
P002
15/08/2010
V001
CALLE
BELTRAN
87654123
Jr Trujillo 214
5566789
A004
CIENTO
Lapicero
20
P002
15/08/2010
V001
CALLE
BELTRAN
87654123
Jr Trujillo 214
5566789
A003
RESMA
Papel Bond A4
50
Pg.68
RUC Cli
Telfono
Cli

D
GUIA DE REMISION
Numero
Nmero
Nombre
Cliente
Rem.
Fecha
Pedido
Cod.Vend
Vendedor
Nombre
Cli.
R101
15/08/2010
P001
V004
RUIZ
ALVA
R101
15/08/2010
P001
V004
RUIZ
R101
15/08/2000
P001
V004
R104
16/08/2010
P002
R104
16/08/2010
P002
R104
16/08/2010
P002
Artculo
Unidad
med.
Nombre
Artculo
Pu
CIENTO
Lapicero
20,00
A001
10
DOCENA
Cuaderno
10,00
4234567
A003
RESMA
Papel Bond A4
50,00
Jr Trujillo 214
5566789
A002
DOCENA
Borrador
4,00
Jr Trujillo 214
5566789
A004
CIENTO
Lapicero
20,00
Jr Trujillo 214
5566789
A003
RESMA
Papel Bond A4
50,00
Direccin Cli
TelfCli
CdArt.
23456789
Av. Tacna 333
4234567
A004
ALVA
23456789
Av. Tacna 333
4234567
RUIZ
ALVA
23456789
Av. Tacna 333
V001
CALLE
BELTRAN
87654123
V001
CALLE
BELTRAN
87654123
V001
CALLE
BELTRAN
87654123
RUC Cli
Cant
Pg.69

D
FACTURA
Nmero
Factura
Num
Fecha
Cliente
Rem
Cod.Ve
Nombre
Cli.
RUC Cli
Direccin Cli
Telf. Cli
Cd
art.
Cant
Artculo
Unidad
med.
Nombre
Artculo
Prec
un
Monto
Total
Total
Total
Articulo
Venta
IGV
Factura
370,00
66,60
436,60
338,00
60,84
398,84
F00234
15/08/2010
R101
V004
ALVA
23456789
Av. Tacna 333
4234567
A004
CIENTO
Lapicero
20,00
20,00
F00234
15/08/2010
R101
V004
ALVA
23456789
Av. Tacna 333
4234567
A001
10
DOCENA
Cuaderno
10,00
100,00
F00234
15/08/2010
R101
V004
ALVA
23456789
Av. Tacna 333
4234567
A003
RESMA
Papel Bond A4
50,00
250,00
F00235
16/08/2010
R104
V001
BELTRAN
87654123
Jr Trujillo 214
5566789
A002
DOCENA
Borrador
4,00
8,00
F00235
16/08/2010
R104
V001
BELTRAN
87654123
Jr Trujillo 214
5566789
A004
CIENTO
Lapicero
20,00
80,00
F00235
16/08/2010
R104
V001
BELTRAN
87654123
Jr Trujillo 214
5566789
A003
RESMA
Papel Bond A4
50,00
250,00
Pg.70

D
BOLETA DE
INGRESO DE ALMACEN
Nmero de
Ingreso
Artculo
Fecha
Cod.Art.
Nombre Art.
Cantidad
Unidad
I0984
01/06/2010 A004
Lapicero
I0984
01/06/2010 A001
Cuaderno
60 DOCENA
I0984
01/06/2010 A003
Papel Bond A4
50 RESMA
100 CIENTO
Pg.71

D
Con las entidades resultantes creamos un solo diagrama donde convergen todas las
Entidades. Se han asignado nombres a cada Entidad
Se elimina la Entidad Redundante y obtenemos el Diagrama E-R Final
Pg.72

CAPTULO
D
Diseo Fsico
El modelo fsico es un modelo que representa la realidad en la implementacin y por
lo tanto es dependiente de la plataforma que se use. Se necesita definir por lo tanto
el DBMDS con el que se va a implementar finalmente la Base de Datos. En nuestro
caso vamos a usar el SQL Server de Microsoft.
El Modelo Fsico se usa entonces para plasmar la solucin a nivel fsico, en el caso
de una base de datos, ac se tendr que modelar de acuerdo al motor de base de
datos que uses, por ejemplo ac se tiene que colocar el tipo de datos de los
conceptos lgicamente relacionados en los modelos anteriores (ejemplo: Char,
String, Int, var, etc.)
DBMS
Data Base Management System.Son las siglas en Ingles para los Sistemas de
Gestin o Administracin de Bases de Datos.
Es una aplicacin que permite a los usuarios definir, crear y mantener una Base de
Datos, adems de proporcionar un acceso controlado a la misma.
Es una aplicacin que interacciona con los usuarios de los programas de aplicacin
y la base de datos.
Pg.73

D
A continuacin presentamos algunos de los DBMS'smascomerciales.
Oracle: Uno de los ms reconocidos a nivel mundial como de los mejores DBMS's.
Multiplataforma, confiable y seguro. Su administracin puede ser un poco difcil pero
nada que no se pueda resolver
DB2
DB2: Heredero de System R de IBM. Es un gran DBMS que ofrece una seguridad
casi impenetrable cuando se instala sobre una mquina AS/400
Informix
Informix: Otra opcin de IBM para el mundo empresarial que necesita un DBMS
sencillo y confiable.
MS SQL Server: Es la opcin de Microsoft para los usuarios de servidores NT o 2k.

Posee muchos asistentes y herramientas de administracin, aunque maneja el
estndar a su antojo y tiene uno de los lenguajes de procedimientos ms difciles
para programar.
SyBase: Un DBMS con bastantes aos en el mercado, tiene 3 versiones para

ajustarse a las necesidades reales de cada empresa.
D3: Un nuevo DBMS que pretende abrirse camino con caractersticas novedosas
Pg.74

D
InterBase: Pequeo y sin hacer mucho ruido estametido en varias organizaciones

importantes como: Nokia, US Army, Compaas Telefnicas de Canad y Francia,
etc. Es fcil de instalar y usar. Seguro y Robusto. Soporte Tcnico tanto con Borland
como con otras compaas especializadas.
Progress: Otro DBMS con aos en el mercado, con una nueva cara y un nuevo
espritu. Esta enfocado a los grandes negocios.
En el desarrollo de este curso usaremos el DBMS DE Microsoft; SQL Server
Microsoft SQL Server es un sistema para la gestin de bases de datos producido por
Microsoft basado en el modelo relacional. Sus lenguajes para consultas son El
Transac SQL (T-SQL) y ANSI SQL.
Microsoft SQL Server constituye la alternativa de Microsoft a otros potentes sistemas
gestores de bases de datos como son Oracle, PostgreSQL o MySQL.
Uso de SQLServer
Creacin de una Base de datos.
Hacer click en el icono de acceso directo SQLServer Management Studio
Pg.75

D
Aparece la ventana de Ingreso
Y luego nos pide elegir el tipo de autenticacin con el que se va a ingresar
Pg.76

D
En este caso elegimos la Autenticacin Windows (por defecto)
Para crear una nueva Base de Datos Nos ubicamos en el Explorador de Objetos de
la izquierda y hacemos click con derecha en la carpeta de Databases
Elegimos New Database (Nueva Base de datos)
Pg.77

D
En la ventana de New Database digitamos el nombre de la nueva Base de datos que

vamos a crear, en este caso Market
Pg.78

D
Para verificar la Base de datos nueva hacemos click con derecha en Databases y
elegimos Refresh (Actualizar)
Y ya podemos visualizar la nueva Base de datos que hemos creado (Market)
Pg.79

D
Tipos de datos msusados en SQL Server

CHAR(n).
Almacena n caracteres en formato ASCII, un byte por cada letra. Cuando
almacenamos datos en el tipo char, siempre se utilizan los n caracteres indicados,
incluso si la entrada de datos es inferior. Por ejemplo, si en un char(5), guardamos el
valor 'A', se almacena A ', ocupando los cinco bytes.
VARCHAR: se usa para almacenar cadenas de caracteres. Una cadena es una

secuencia de caracteres. Se coloca entre comillas (simples); ejemplo: 'Hola', 'Juan
Prez'. El tipo "varchar" define una cadena de longitud variable en la cual
determinamos el mximo de caracteres entre parntesis. Puede guardar hasta 8000
caracteres. Por ejemplo, para almacenar cadenas de hasta 30 caracteres, definimos
un campo de tipo varchar(30), es decir, entre parntesis, junto al nombre del campo
colocamos la longitud.
Si asignamos una cadena de caracteres de mayor longitud que la definida, la cadena
no se carga, aparece un mensaje indicando tal situacin y la sentencia no se
ejecuta.
Por ejemplo, si definimos un campo de tipo varchar(10) e intentamos asignarle la
cadena 'Buenas tardes', aparece un mensaje de error y la sentencia no se ejecuta.
INTEGER: se usa para guardar valores numricos enteros, de -2000000000 a
2000000000 aprox. Definimos campos de este tipo cuando queremos representar,
por ejemplo, cantidades.
FLOAT: se usa para almacenar valores numricos con decimales. Se utiliza como
separador el punto (.). Definimos campos de este tipo para precios, por ejemplo.
TINYINT :Una columna o variable de tipo tinyint puede almacenar el rango de
valores de 0 a255.
DECIMAL(p,s).Una columna de tipo decimal puede almacenar datos numricos
decimales sin redondear. Donde p es la precisin (nmero total del dgitos) y s la
escala (nmero de valores decimales)
MONEY:Almacena valores numricos monetarios de -263 a 263-1, con una
precisin de hasta diez milsimas de la unidad monetaria.
DATETIME :Almacena fechas con una precisin de milisegundo. Debe usarse para
fechas muy especficas. El formato que presenta es de fecha y hora (0:00:00).
Ocupa 8 bytes
Pg.80

D
Existen por supuesto ms tipos, pero solo mencionaremos por ahora

necesitaremos para los ejemplos que se van a desarrollar.
los que
Antes de crear una tabla debemos pensar en sus campos y optar por el tipo de dato
adecuado para cada uno de ellos.
Por ejemplo, si en un campo almacenaremos nmeros enteros, el tipo "float" sera
una mala eleccin; si vamos a guardar precios, el tipo "float" es ms adecuado, no
as "integer" que no tiene decimales. Otro ejemplo, si en un campo vamos a guardar
un nmero telefnico o un nmero de documento, usamos "varchar", no "integer"
porque si bien son dgitos, con ellos no realizamos operaciones matemticas.
Creacin de una Base de datos usando el cdigo generado

por el ERWIN.
Vamos a crear un modelo Lgico y luego lo convertiremos en Fsico
Ingresamos al men de inicio y elegimos Todos los programas:
Luego buscamos la carpeta CA Erwin Erwin Data Modeler r8 y hacemos

click en el icono
Pg.81

D
Aparece la ventana siguiente:
Elegimos la opcin Use Local license y hacemos click en OK

Luego aparece la ventana de Tips
Cerramos la ventana de Tips para continuar. Hacemos click en Close.

Se presenta la ventana principal del Erwin:
Pg.82

D
Vamos a la esquina superior izquierda y del men File elegimos New
Aparece la ventana para crear un nuevo modelo:
Elegimos la opcin Logical/Physical y se activan las opciones de Target Database
Elegimos en Database a SQL Server y la versin ms actualizada (2008)
Pg.83

D
Se presenta la ventana de diseo del Erwin:
Ingresamos una nueva entidad con el botn
Entity
de la barra de mens, Lugo se hace click en la zona de diseo y se ingresa un

nueva entidad E/1 en el modelo
Se puede digitar directamente el nombre de la entidad, por ejemplo cliente y el

modelo se presenta as ahora:
Pg.84

D
De la misma forma, siguiendo la metodologa anterior, ingresamos las entidades

PEDIDO, DETALLE_PEDIDO y ARTICULO.
Vamos a ingresar las propiedades de la Entidad CLIENTE:
Hacemos click con derecha sobre la entidad y del men contextual que aparece,
elegimos Atribute Properties
Aparece la ventana para agregar propiedades a la entidad:
Pg.85

D
Hacemos click en el botn New de la parte superior para agregar propiedades
Aparece una nueva propiedad en la ventana de propiedades
Digitamos el nombre de la propiedad NomCli

Pg.86

D
Luego elegimos el tipo de dominio String (cadena de caracteres)
Otra vez elegimos el botn New para agregar otra propiedad:
Siguiendo la misma rutina agregamos las propiedades DirCli y NomCli
Tambin le agregamos el atributo IdCliente, pero adems marcamos la opcin

Primary Key, para establecer a este atributo como Clave primaria (PK)
Pg.87

D
Luego la entidad se presenta si en el modelo:
Ingresamos luego siguiendo el mtodo anterioralgunas propiedades a la entidad

PEDIDO. Luego elegimos la herramienta para establecer una relacin No
Identificadora
Pg.88

D
A continuacin hacemos click en la entidad CLIENTE y a continuacin un segundo

click en la otra entidad PEDIDO, para relacionarlas
Automticamente se trasmite como clave fornea IdCliente (FK) en la entidad

PEDIDO
Vamos a afinar lascardinalidades de esta relacin
Se hace click con derecha en la relacin, y del men emergente se elige la opcin
Properties
Pg.89

D
Aparece luego la siguiente ventana de propiedades de la relacin:
Para cambiar la cardinalidad del lado de la entidad padre (CLIENTE)

CAMBIAMOS LA OPCION DE NullsAllowed (Nulos permitidos) a
NullsNotAllowed (Nulos no permitidos)
Luego cerramos la venta haciendo click en Close
Pg.90

D
La relacin se muestra as ahora:
Ahora vamos a relacionar PEDIDO con DETALLE_PEDIDO con una relacin de tipio
Identificadorapara lo cual elegimos a la herramienta de la parte superior,
Identifyingrelationship;
hacemosclick en la entidad PEDIDO, y luego
Hacemos click por segunda vez en la entidad DETALLE_PEDIDO
se observa que se transmite la PK como FK a la parte superior de la entidad:
A continuacin relacionamos de la misma manera la entidad ARTICULO con la

entidad DETALLE_PEDIDO, usando la herramienta de relacin Identificadora
Pg.91

D
La PK IdArticulo de la entidad ARTICULO, se transmite como Fk a la parte superior

de la entidad DETALLE_PEDIDO, pasando a formar parte de su clave primaria
compuesta
El modelo finalmente quedara as:
Grabamos el modelo, elegimos del men File la opcin Save As (Guardar como)
Pg.92

D
Luego elegimos la carpeta mas adecuada y guardamos el modelo:
Con un nombre, por ejemplo en este caso lo gradaremos como Ejemplo01
Pg.93

D
Transformando un Modelo Lgico en Fsico con Erwin

Tomemos el siguiente Modelo Lgico del ejemplo anterior
De la lista desplegable que se encuentra en la parte superior, elegimos Physical:
Hacemos click con derecha en alguna parte libre del modelo, y del men contextual
que aparece elegimos la opcin Properties
Pg.94

D
Aparecer la ventana siguiente, nos ubicamos en la ficha Table y marcamos la opcin

DisplayColumn Data Type
Luego en el modelo se podrn observar los tipos correspondientes a SQL Server
Vamos a cambiar a continuacin los tipos de datos especficos.

Hacemos click con derecha en la entidad CLIENTE, elegimos ColumnsProperties
Pg.95

D
Para el atributo IdCliente cambiamos al tipo CHAR y entre los parntesis digitamos
5 ose le cambiamos al tipo CHAR(5)
Realizamos cambios similares en las dems entidades, teniendo cuidado de no

cambiar los tipos de las claves forneas, ya que ellas se transmiten
automticamente de los tipos de sus calves primarias a las que se referencian.
Luego el modelo Fsico se presenta de la siguiente forma:
Ahora vamos a generar el cdigo para implementar los objetos de bases de datos en
el servidor.
Del men Actionselegimos Forward Engineer y luego Schema
Pg.96

D
Aparece la siguiente ventana
En la parte inferior hacemos click en el boto Preview
Se presenta la siguiente ventana, con el cdigo que genera Erwin en lenguaje SQL
Pg.97

D
Seleccionamos con cuidado todo el cdigo, lo copiamos y lo pegamos en un Block

de notas
Como se muestra a continuacin
Luego este archivo lo guardamos en una carpeta determinada
Pg.98

D
Implementacin de la Base de datos en el servidor SQL Server

A continuacin nos ubicamos en el servidor, en una base de datos que tenemos
creada, como es el caso de Market, que creamos anteriormente y abrimos una
nueva ventana de Consulta
Abrimos el archivo que guardamos en el block de notas
Copiamos y pegamos su contenido en la nueva consulta abierta en SQL Server
Pg.99

D
Asegurndonos que estamos ubicados en la base de datos correcta, en este caso

Market
Luego ejecutamos el cdigo haciendo clic en el botn Ejecutar
En la ventana de mensajes (Messages) debe mostrarse el aviso de comandos

ejecutados satisfactoriamente.
Ahora nos ubicamos en la ventana del explorador de objetos en la base de datos
Market. Elegimos la carpeta de diagramas de bases de datos (DatabaseDiagrams)
Hacemos click con derecha y elegimos New DatabaseDiagram
Pg.100

D
Se muestra la ventana para agregar las tablas al nuevo diagrama, seleccionamos

todas y hacemos click en el botn Add
A continuacin se muestra el diagrama de la Base de datos mostrando las tablas y

sus relaciones
Finalmente hemos implementado la Base de Datos en el Servidor.
Pg.101

D
Ejercicio adicional:
En el caso del ejemplo Ejercicio 9 de Normalizacin, el modelo Lgico se debe
convertir al modelo fsicocorrespondiente e implementar la base de datos en SQL
Server
Pg.102

Modelamiento de Datos 2013

Cargado por

Copyright:

Formatos disponibles

Modelamiento de Datos 2013

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelamiento de Datos 2013

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE INGENIERIA

Centro de Extensin y Proyeccin Social

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Conjunto de elementos que interactanpara realizar un conjunto de funciones

Sistema con realimentacin

La informacin y la toma de decisiones

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Lo que se exige al S.I.

Proveer funciones de automatizacin para tareas crticas.

Tipos de Sistemas de Informacin

Se leen pocas columnas.

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Sistemas para soporte de decisiones (DSS)

Sistemas Estadsticos o Cientficos

Perspectivas de los Sistemas de Informacin

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

productos o servicios que brinde la empresa al mercado, por tanto alinearse a

Se debe tener en cuenta al analizar la perspectiva tecnolgica, alinearnos con

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Sistemas de informacin empresarial

Complejidad de los sistemas actuales (p.ej. competencia).

Capacidad de los ordenadores.

Econmicas (ahorro de costes, aumento de productividad).

No econmicas (valor percibido).

Recursos principales de una empresa

Material & Maquinaria

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

El modelamiento de los Datos

Necesidad de Modelar los Datos

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Ciclo de Vida del Modelamiento de Datos

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

El objetivo primario de una base de datos es almacenar datos de inters para la

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA

Necesidad de una Base de Datos

Reduccin de la redundancia de datos.

Se evita la inconsistencia en los datos.

Los datos pueden ser compartidos por las reas relacionadas de la

Permite la estandarizacin de los datos.

Permite aplicar restricciones de seguridad.

Permite controlar la integridad de los datos.

El planeamiento de la base de datos ofrece las siguientes ventajas:

Permite entender la informacin con la que cuenta la organizacin como un

Permite establecer los requerimientos de informacin de los usuarios, y la

Permite administrar eficientemente los recursos de informacin.

Permite establecer planes de accin para lograr los objetivos de la

Inst. Flores Manco Julio E.

UNIVERSIDAD NACIONAL DE INGENIERIA