Unidad 1

Universidad Nacional Autnoma de Mxico
16/08/2015
Desarrollo de Aplicaciones en
Manejadores de Bases de Datos
Relacionales
Quinto Semestre
Jos Mauricio Estrella Vzquez

bono646@gmail.com

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales
16/08/2015
Desarrollo de Aplicaciones en
Manejadores de Bases de Datos
Relacionales
Unidad 1.
1. PLANEACIN DE LA BASE DE DATOS
ndice.
_Toc436144336
1. PLANEACIN DE LA BASE DE DATOS ............................................................................................................ 2
1.1.
DISEO CONCEPTUAL (MODELO ENTIDAD-RELACION) ...................................................................... 3
1.2.
DISEO LGICO................................................................................................................................... 9
1.2.1 DISEAR RELACIONES (LLAVES PRIMARIAS Y FORANEAS) .................................................................... 10
1.2.2 DISEAR REGLAS DE NEGOCIOS ............................................................................................................ 15
1.2.3 DISEAR VISTAS PARA LOS USUARIOS .................................................................................................. 20
1.2.4 NORMALIZAR LA BASE DE DATOS (1FN, 2FN, 3FN) ............................................................................... 22
1.3 ELECCION DEL MANEJADOR DE BASES DE DATOS (4 EJEMPLOS) ............................................................ 22
1.4 ELECCIN DEL MOTOR DE ALMACENAMIENTO (2 EJEMPLOS) ................................................................ 23
1.5 ESTIMACIN DEL TAMAO DE LA BASE DE DATOS ................................................................................. 26
Bibliografa ....................................................................................................................................................... 28
Pgina 2 de 28

16/08/2015
1.1. DISEO CONCEPTUAL (MODELO ENTIDAD-RELACION)

Fue ideado por Peter Chen en los aos 1976 y 1977 a travs de dos artculos. Se trata de un modelo que sirve
para crear esquemas conceptuales de bases de datos. De hecho es prcticamente un estndar para crear esta
tarea.
Se le llama modelo E/R e incluso EI (Entidad / Interrelacin). Sus siglas ms populares son las E/R por que
sirven para el ingls y el espaol.
Inicialmente (en la propuesta de Chen) slo se incluan los conceptos de entidad, relacin y atributos. Despus
se aadieron otras propuestas (atributos compuestos, generalizaciones,...) que forman el llamado modelo
entidad relacin extendido (se conoce con las siglas ERE)
entidades
entidad
Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda almacenar informacin en
la base de datos. Ejemplos de entidades son Pedro, la factura nmero 32456, el coche matrcula 3452BCW.
Una entidad no es un propiedad concreta sino un objeto que puede poseer mltiples propiedades (atributos).
conjunto de entidades
Las entidades que poseen las mismas propiedades forman conjuntos de entidades. Ejemplos de conjuntos de
entidades son los conjuntos: personas, facturas, coches,...
Ejemplos de entidad y conjunto de entidad.

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como conjunto de entidades.
De este modo hablaramos de la entidad PERSONAS. Mientras que cada persona en concreto sera una
ocurrencia o un ejemplar de la entidad persona.
representacin grfica de las entidades
En el modelo entidad relacin los conjuntos de entidades se representan con un rectngulo dentro del cual se
escribe el nombre de la entidad:
PERSONAS
Representacin de la entidad persona
tipos de entidades
Regulares. Son las entidades normales que tienen existencia por s mismas sin depender de otras. Su
representacin grfica es la indicada arriba
Dbiles. Su existencia depende de otras. Por ejemplo la entidad tarea laboral slo podr tener existencia si
existe la entidad trabajo. Las entidades dbiles se presentan de esta forma:
TAREAS LABORALES
Entidad dbil
Pgina 3 de 28

16/08/2015
relaciones
qu es una relacin
Representan asociaciones entre entidades. Es el elemento del modelo que permite relacionar en s los datos
del modelo. Por ejemplo, en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se
realizan ya que las personas trabajan y los trabajos son realizados por personas:
Ejemplo de relacin
representacin grfica
La representacin grfica de las entidades se realiza con un rombo al que se le unen lneas que se dirigen a las
entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo anterior podra usarse como
nombre de relacin, trabajar:
ejemplos de relaciones
Pgina 4 de 28

16/08/2015
cardinalidad
Indica el nmero de relaciones en las que una entidad puede aparecer. Se anota en trminos de:
cardinalidad mnima. Indica el nmero mnimo de asociaciones en las que aparecer cada ejemplar de la
entidad (el valor que se anota es de cero o uno)
cardinalidad mxima. Indica el nmero mximo de relaciones en las que puede aparecer cada ejemplar de la
entidad (puede ser uno o muchos)
En los esquemas entidad / relacin la cardinalidad se puede indicar de muchas formas. Actualmente una de las
ms populares es esta:
Ejemplo:
En el ejemplo, cada equipo cuanta con varios jugadores. un jugador juega como mucho en un equipo y podra
no jugar en ninguno. Cada entrenador entrena a un equipo (podra no entrenar a ninguno), el cual tiene un
solo entrenador
Pgina 5 de 28

16/08/2015
roles
A veces en las lneas de la relacin se indican roles. Los roles representan el papel que juega una entidad en
una determinada relacin. Ejemplo:
atributos
Describen propiedades de las entidades y las relaciones. En este modelo se representan con un crculo, dentro
del cual se coloca el nombre del atributo. Ejemplo:
tipos de atributos
compuesto
mltiples
Pueden tomar varios valores:
Pgina 6 de 28

16/08/2015
opcionales
Lo son si pueden tener valor nulo:
identificador
Se trata de uno o ms campos cuyos valores son nicos en cada ejemplar de una entidad. Se indican
subrayando el nombre del identificador.
Para que un atributo sea considerado un buen identificador tiene que cumplir:
1> Deben distinguir a cada ejemplar teniendo en cuenta las entidades que utiliza el modelo. No tiene
que ser un identificador absoluto.
2> Todos los ejemplares de una entidad deben tener el mismo identificador.
3> Cuando un atributo es importante aun cuando no tenga una entidad concreta asociada, entonces se
trata de una entidad y no de un atributo
entidades is a
Son relaciones de tipo is a (es un) aquellas en las que una entidad se descompone en entidades especializadas.
Hay dos tipos de entidades is a: especializaciones y generalizaciones.
Las especializaciones consisten en que una entidad se divide en entidades ms concretas. La entidad general
comparte con las especializadas sus atributos. Se observa una especializacin cuando hay ejemplares para los
que no tienen sentido algunos de los atributos, mientras que para otros s.
Se denomina generalizacin si se agrupan varias entidades en una o ms entidades generales. Se observa una
generalizacin si en varias entidades se observan atributos iguales, lo que significa que hay una entidad
superior que posee esos atributos.
En cualquier caso la representacin en el modelo es la misma, se representan con un tringulo que tiene el
texto ISA. Ejemplo:
En estas relaciones se habla tambin de herencia, ya que tanto los profesores como los bedeles como los
otros, heredan atributos de la entidad personal (se habla de la superentidad personal y de la subentidad
profesores)
Se puede colocar un crculo (como el del nmero cero) en lado de la superentidad para indicar que es opcional
la especializacin, de otro modo se tomar como obligatoria (el personal tiene que ser alguna de esas tres
cosas)
Pgina 7 de 28

16/08/2015
1.2. DISEO LGICO

Diseo lgico de la base de datos : El proceso de construccin de un modelo de los datos utilizados en una
empresa basndose en un modelo de datos especfico, pero de forma independiente de un SGBD concreto y
de cualquier otra consideracin fsica.
La segunda fase del diseo de la base de datos se denomina diseo lgico de la base de datos, el cual tiene
como resultado la creacin de un modelo conceptual de datos creado en la fase anterior se refina y se hace
corresponder con un modelo lgico de los datos. Este modelo lgico est basado en el modelo de datos
objetivo de la base de datos (por ejemplo, el modelo de datos relacional).
Mientras que el modelo conceptual de los datos es independiente de todas las consideraciones fsicas, el
modelo lgico se construye conociendo el modelo de los datos subyacente del SGBD objetivo. En otras
palabras, sabemos que el SGBD es, por ejemplo, relacional, en red, jerrquico u orientado a objetos. Sin
embargo, no tomamos en consideracin ningn otro aspecto del SGBD elegido y, en concreto, hacemos caso
omiso de todos los detalles fsicos, como puedan ser las estructuras de almacenamiento o los ndices.
Durante el proceso de desarrollo de un modelo lgico de los datos, el modelo se prueba y se valida de acuerdo
con los requisitos de los usuarios. Se utiliza la tcnica de la normalizacin para comprobar la correccin de un
modelo lgico de los datos. La normalizacin garantiza que las relaciones extradas del modelo de datos no
presenten redundancia, que podria provocar anomalas de actualizacin en la implementacin.
El modelo lgico de los datos debe tambin examinarse para garantizar que soporta las transacciones
especificadas por los usuarios. El modelo lgico de los datos es una fuente de informacin para la siguiente
fase, la del diseo fsico de la fase de datos, proporcionando al encargado de efectuar ese diseo fisico una
herramienta para alcanzar compromisos que tienen una gran importancia para el diseo eficiente de una base
de datos. El modelo lgico tambin cumple un importante papel durante la etapa de mantenimiento operativo
del sistema de base de datos, dentro del ciclo de vida del desarrollo. Si el modelo de datos se mantiene
adecuadamente y se conserva actualizado, los futuros cambios que se efecten en los programas de aplicacin
o en los datos podrn ser representados de forma precisa y eficiente mediante la base de datos.
Pgina 9 de 28

16/08/2015
1.2.1 DISEAR RELACIONES (LLAVES PRIMARIAS Y FORANEAS)

Las relaciones son un tema complejo pero veamos un sencillo ejemplo con las tablas Alumnos y Cursos para
entenderlo mucho mejor. Inicialmente nuestras tablas estaran definidas del siguiente modo:
En la tabla Alumnos tenemos toda la informacin que necesitamos sobre nuestros alumnos como:
Su nmero de expediente.
Su nombre y apellidos.
Su fecha de nacimiento.
El grupo al que pertenece el alumno.
La ubicacin del grupo, es decir, el aula donde estn los alumnos de ese grupo (Primera planta, edificio
anexo, etctera).
Cualquier tipo de comentario de inters: grupo de compensatoria, apoyo, etctera.
Para la tabla Grupos nos podamos conformar con la denominacin del grupo (1A, 1B, 3A...) pero le hemos
aadido algunos datos que nos pueden resultar de inters:
Nmero total de alumnos que tiene el grupo.
El lugar donde se encuentra ubicado: Aula de msica, Aula 205 Edificio principal, etctera.
Cualquier otro dato de inters: Compensatoria, grupo de apoyo, etctera.
Si saber nada de bases de datos y de relaciones podemos, darnos cuenta que al comprobar los datos incluidos
en las tablas de Alumnos y Grupos existe informacin que se repite en ambas:
Esta situacin no es demasiado favorable cuando trabajamos con bases de datos donde habitualmente la
cantidad de informacin que se maneja es importante. La solucin pasa por RELACIONAR las tablas con
informacin coincidente de modo que no exista duplicidad de informacin. Todo esto, traducido a un lenguaje
ms natural sera: "Para qu escribir dos veces lo mismo, si puedo hacerlo una sola y trabajar del mismo
modo".
Pgina 10 de 28

16/08/2015
Volviendo a nuestro ejemplo, si relacionamos las tablas Alumnos y Grupos mediante el nombre del grupo sera
suficiente con indicar en la tabla Alumnos este valor para obtener el nmero de alumnos del grupo, su
ubicacin y las posibles observaciones:
Tipos de relaciones
No siempre las condiciones para establecer vnculos entre dos tablas son iguales, la manera en que se
relacionan las tablas entre s da lugar a comportamientos diferentes. En la estructutura de cualquier base de
datos encontramos principalmente tres tipos de relaciones que se describen del siguiente modo:
Uno a muchos.
Muchos a muchos.
Uno a uno.
Uno a muchos
Veamos el primer modelo de relacin tomando como referencia las tablas Alumnos y Grupos. Cualquier
alumno (MUCHOS) pertenece slo a un grupo (UNO), un alumno no puede estar en ms de una clase. Pues
bien, ni ms ni menos que este sera el argumento de una relacin MUCHOS A UNO.
Pgina 11 de 28

16/08/2015
Otro ejemplo, sabemos que cada profesor pertenece nicamente a un departamento, pero en cada
departamento existe ms de un profesor. De aqu podemos extraer una relacin UNO a MUCHOS entre las
tablas Departamentos y Profesores.
En las relaciones de uno a muchos cada registro de una tabla A, a la que llamaremos tabla primaria, puede
estar enlazado con ms de un registro de otra tabla B, a la que llamaremos tabla secundaria. En cambio, cada
registro de la tabla B slo puede estar enlazado a un registro de la tabla A.
Uno a uno
Las relaciones uno a uno no son demasiado frecuentes pero existen as que debemos conocerlas. Buscando
alguna coincidencia en nuestro entorno que nos pueda servir como ejemplo encontramos el vnculo entre un
tutor y su grupo. Como sabemos, un profesor puede ser tutor de un slo grupo (UNO) y del mismo modo, cada
grupo slo puede tener un tutor. Esta sera una relacin UNO a UNO.
Cada registro de la tabla A se relaciona con un nico registro de la tabla B y cada registro de la tabla B slo se
relaciona con un elemento de la tabla A. Como hemos comentado, este tipo de relaciones son poco comunes.
Muchos a muchos
Resumiendo lo visto hasta ahora podemos decir que el tipo de relacin ideal es uno a muchos o muchos a uno.
Las relaciones uno a uno no aportan demasiado a la base de datos, simplemente nos ayudan a tener mejor
organizada la informacin pero poco ms. Veamos qu ocurre con las relaciones muchos a muchos.
Por ejemplo, si queremos conocer los profesores que dan clase a un grupo o los grupos a los que da clase un
profesor determinado, necesitamos en principio dos tablas: Profesores y Grupos. Y cul sera la relacin entre
estas dos tablas? Pues bien, para establecerla podramos leer que un profesor da clases a varios grupos (1A,
1B, 2C, etctera) y un grupo recibe clases de varios profesores (Carlos Prez, Antonio Garca, etctera). Por lo
tanto, nos encontramos entre una relacin MUCHOS A MUCHOS.
Desde un punto de vista terico diramos que en las relaciones Muchos a muchos a cada registro de la tabla A
se le pueden asociar varios registros de la tabla B y cada registro de la tabla B puede estar relacionado con ms
de un registro de la tabla A.
Pgina 12 de 28

16/08/2015
Otros ejemplos para ilustrar este modelo de relacin podran ser:

Los alumnos que participan en las actividades deportivas del centro. Concretamente un alumno podra
participar en ms de un deporte (Ftbol, Baloncesto, etctera) y a su vez cada equipo est formado
por varios componentes. Esta relacin tambin sera del tipo Muchos a muchos.
Con las actividades extraescolares ocurre lo mismo. Un alumno puede asistir a ms de una
(manualidades, msica, idiomas, etctera) y en cada una de ellas, encontraremos a varios alumnos.
Problemas y solucin para las relaciones Muchos a muchos
Las relaciones Muchos a muchos no son recomendables y debemos tratar de evitarlas utilizando TABLAS
INTERMEDIAS en las que se utilizaran relaciones de uno a muchos. Una tarea sencilla como podra ser obtener
un listado de todos los profesores que imparten clases en 1B se convierte en una verdadera pesadilla si
mantenemos esta relacin. La solucin pasa por crear una TABLA INTERMEDIA que nos permita dividir la
relacin MUCHOS A MUCHOS en dos relaciones UNO A MUCHOS.
Establecer relaciones entre tablas

Como requisito indispensable para establecer una relacin entre dos tablas es necesario que ambas tablas
tengan un campo en comn.
Muy importante, los campos que se utilicen para establecer la relacin entre las dos tablas deben ser del
mismo tipo (INTEGER, TEXTO, SMALL INTEGER, etctera). Habitualmente se suelen utilizar tipos enteros
(INTEGER) para este propsito, aunque nos valdra igualmente cualquier otro tipo siempre y cuando sea el
mismo en las dos tablas. Adems, debes tener en cuenta lo siguiente:
La propiedad Tamao del campo debe ser igual en ambas tablas.
Si el campo en la tabla primaria est definido como de Valor automtico en la tabla secundaria debe
estar definido como INTEGER.
El campo comn debe ser Clave principal en la tabla primaria.
Pgina 13 de 28

16/08/2015
Clave Primaria
La clave primaria es un dato que identifica de forma nica a una entidad o registro. Cuando la clave primaria se
compone de ms de un dato, se trata de una clave concatenada.
Clave Secundaria
La clave secundaria es la agregacin del valor de una clave primaria de una tabla en otra tabla diferente donde
se quiere establecer una relacin con la tabla original mediante la duplicacion del valor para establecer una
referencia. El nombre de clave secundaria se deriva del hecho de que la segunda tabla en la relacin ya tiene
una clave primaria propia, por lo que la clave primaria que se introduce desde la primer tabla es secundaria
a la segunda tabla.
Pgina 14 de 28

16/08/2015
1.2.2 DISEAR REGLAS DE NEGOCIOS

Se pueden considerar como cualquier restriccin, necesidad, requerimiento, o actividad especial que debe ser
verificada al momento de intentar grabar informacin, borrar, actualizar o consultar la ya existente; las mismas
son impuestas por los usuarios o los administradores de la base de datos.
Ejemplo: puedes definir un campo o una tabla que contenga informacin relacionada los clientes a los que se
les vende algn determinado producto. Tal vez, la regla te indique, que las claves para determinados clientes
de una determinada regin empiece con A, para otros con B y as con las claves, pero con los nombres u otros
determinantes de identificacin con un determinado valor, ISO, algo as.
Normalizacin
El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones
obtenidas tras el paso del modelo entidad-relacin al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualizacin de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea considerada
como una relacin tiene que cumplir con algunas restricciones:
Cada columna debe tener su nombre nico.
No puede haber dos filas iguales.
No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.
DML
Es la abreviatura de Lenguaje de Manipulacion de Datos. Es usada para almacenar, modificar, borrar, insertar y
actualizar datos en una base de datos.
Ejemplos: SELECT, UPDATE, INSERT statements
DDL
Es la abreviatura de Lenguade de Definicion de Datos. Es usada para crear y modificar la estructura de los
objetos en la base de datos..Ejemplos: CREATE, ALTER, DROP statements
DCL
Es la abreviatura de Lenguaje de Control de Datos. Es usada para crear los roles, permisos y la integridad
referencial que es usada para controlar el acceso a la base de datos como medida de suguridad.
Ejemplos: GRANT, REVOKE statements
TCL
Es la abreviatura de Lenguaje de Control de Transacciones. Es usada para controlar las diferentes transacciones
que ocurren dentro de una base de datos.
En su forma ms simple, una regla de negocio posee varios parmetros de entrada, una validacin entre stos
y de acuerdo a dicha validacin, realiza una accin de salida. Por ejemplo, tenemos la siguiente regla de
negocio como parte de un proceso real de dictamen y que nos fue proporcionado por el cliente para su
modelado:
Si la reclamacin contiene el nmero de siniestro se toma como una reclamacin complementaria, en caso
contrario se trata de una reclamacin inicial.
Para modelar esta regla de negocio se identifican los siguientes elementos:
Entidades involucradas: Reclamacin.
Parmetros involucrados: nmero de siniestro.
Validaciones a realizar: si nmero de siniestro <> nulo
Accin a tomar: modificar tipo de reclamacin como complementaria.
Caso alterno: modificar tipo de reclamacin como inicial.
Pgina 15 de 28

16/08/2015
Esto en pseudocdigo se expresa como IF Reclamacion.numSiniestro != null THEN Reclamacion.tipo =

complementaria ELSE Reclamacion.tipo = inicial y en un Excel puede quedar de la siguiente manera:
Descripcin de la regla
Nombre de la regla
Descripcin de la Regla
ID
Si la reclamacin contiene el nmero de

Asignacin de tipo de siniestro se toma como una reclamacin
M_1218_RN001
reclamacin
complementaria, en caso contrario se trata
de una reclamacin inicial.
Objetos
negocio
de
Atributo
Reclamacion numSiniestro
Criterios de validacin (IF x AND y)

Objetos
Operador
Operador
de
Atributo
Lgico
negocio
<>
Operador
Valor
VACO
Accin (THEN z)
Objetos de Atribut
Operador
negocio
os
Operador
Lgico
Reclamacion tipo
Objetos
de
negocio
Atributo Operador
Valor
Excepciones
Observaciones
1. Todas las reclamaciones nacern
como Iniciales (tipo = 0) a menos que en
esta
regla
se
asignen
como
complementarias
Ntese que se est modelando un IF/THEN/ELSE de manera que un usuario de negocio pueda
entenderlo y modelarlo.
Una regla un poco ms compleja
Pero qu ocurre cuando una regla posee varias validaciones? Y si al validar una condicin debe ejecutar
caminos alternos? Este mismo formato de documentacin de reglas de negocio permite acomodar mayor
complejidad:
Para reembolsos, verificar que la factura est cubierta por la vigencia de la pliza. En caso de ser correctos,
verificar el periodo de prescripcin de gastos; en caso contrario, registrar una incidencia.
En este caso, falta detalle cmo generar una nueva incidencia, qu es la "verificacin de periodo de
prescripcin de gastos" pero podemos dejarlo igualmente como un IF/THEN/ELSE que podemos modelar as:
Entidades involucradas: Pliza, Factura.
Parmetros involucrados: echa de emisin de la factura, fechas de inicio y fin de la pliza.
Validaciones a realizar: si fecha de emisin > fecha inicio pliza Y fecha de emisin < fecha fin pliza
Accin a tomar: ejecutar la regla "verificar periodo de prescripcin de gastos".
Caso alterno: generar una nueva incidencia.
Que en pseudocdigo se expresa como IF Factura.fechaEmision > Poliza.fechaInicioVigencia &&
Factura.fechaEmision < Poliza.fechaFinVigencia THEN ejecuta "verificar periodo de prescripcin de gastos" ELSE
new Incidencia.
Pgina 16 de 28

16/08/2015
Ntese que la ejecucin de otras reglas de negocio a partir de una validacin ya conforma procesos de negocio.
Descripcin de la regla
Nombre de la regla
Descripcin de la Regla
ID
S_1165_RN0156
Objetos
negocio
Factura
de
Para reembolsos, verificar que la factura est

cubierta por la vigencia de la pliza. En caso de
Verificacin de fecha de
ser correctos, verificar el periodo de
gasto Iniciales
prescripcin de gastos; en caso contrario,
registrar una incidencia.
Criterios de validacin (IF x AND y)

Objetos
Operador
Operador
de
Atributo
Lgico
negocio
Atributo
FechaEmision
<>
Poliza
fechaInicio
Vigencia
Operador
Valor
And
ELSE
Objetos de
Atributos
negocio
S_1717_PN02
18
Incidencia
Incidencia
Incidencia
Incidencia
Incidencia
Operador
Nivel
idNivel
cdigo
descripcion
severidad
Operador
Operador
Lgico
Objetos
de
negocio
Atributo
=
=
=
=
=
Factura
idFactura
Valor
Excepciones
1
FAC
S_1165_RN0156{ID}
S_1165_RN0156{DESC}
FATAL
Observaciones
En caso exitoso ejecutar

regla S_1717_PN0218
Y bueno, con esto ya tenemos un modelado de tareas e incluso empezamos a conformar procesos de negocio
ms complejos.
Pgina 17 de 28

16/08/2015
Implementando las reglas

Y bueno, todo este modelado debe tener como objetivo el facilitar su implementacin dentro de un gestor de
reglas de negocio (Business Rules Management System BRMS). Por ejemplo, la extraccin de las entidades
necesarias para un proceso de ejecucin de reglas de negocio nos permitir crear los POJOs (Plain Old Java
Objects objetos de Java planos y simples) necesarios para extraer informacin as como su uso dentro de
dichos procesos. Usando el ejemplo de la entidad Asegurado de ms arriba, tenemos el siguiente cdigo en
Java:
package com.cliente.mx.sistema.brvo;
import java.util.Date;
public class Asegurado {
private Date fechaAlta;
private Date fechaNacimiento;
private String numPoliza;
private char sexo;
private String tipo;
public Date getFechaAlta() {
return fechaAlta;
}
public void setFechaAlta(Date fechaAlta) {
this.fechaAlta = fechaAlta;
}
public Date getFechaNacimiento() {
return fechaNacimiento;
}
public void setFechaNacimiento(Date fechaNacimiento) {
this.fechaNacimiento = fechaNacimiento;
}
public String getNumPoliza() {
return numPoliza;
}
public void setNumPoliza(String numPoliza) {
this.numPoliza = numPoliza;
}
public char getSexo() {
return sexo;
}
public void setSexo(char sexo) {
this.sexo = sexo;
}
public String getTipo() {
return tipo;
}
public void setTipo(String tipo) {
this.tipo = tipo;
}
}
Pgina 18 de 28

16/08/2015
Que utilizaremos como objeto de valor al extraer informacin de la base de datos y durante el proceso de
ejecucin. Por otro lado, con el modelado de las reglas podemos usar de manera ms eficiente un BRMS, pues
se tiene la "receta" para construir las sentencias de las reglas de negocio:
Finalmente dentro de nuestro modelo, aquellas reglas que poseen como accin la ejecucin de otras reglas,
son los bloques constitutivos de procesos de negocio:
Hasta ahora hemos trabajado bajo el supuesto que las entidades de negocio existen y toda la informacin que
las compone es accesible desde nuestro sistema. Un punto crtico para el xito consiste en determinar
justamente, a qu bases de datos conectarnos o qu servicios consumir para obtener esta informacin. En
caso de sistemas como ERPs, CRMs o "legados", tendremos que sentarnos con el rea IT correspondiente para
cerrar temas de acceso, seguridad y desempeo; mientras ms pronto, mucho mejor.
Por otro lado, no todos los sistemas son iguales: algunas fuentes de datos de nuestros procesos de negocio
trabajan por lotes mientras otras permiten ser llamadas en tiempo real. Saber de dnde vienen los datos de
nuestro sistema puede hacer toda la diferencia. Por ejemplo, en nuestro caso particular nos dimos cuenta que
no todos los sistemas que usbamos podan ser llamados en tiempo real, sobre todo por el pequeo detalle de
que son sistemas endebles que no soportan mucha carga. Y si consideramos que nuestro sistema ejecuta un
mximo de 1,166 reglas de negocio por segundo, tenamos un stopper en nuestras manos. Para resolverlo,
existen varias opciones, pero propusimos dos: hacer todos los procesos mediante llamadas asncronas a los
sistemas que utilizan, o hacer una precarga de la informacin en bases de datos locales para despus correr
todo como un proceso por lotes. Como el cliente es ms bien del tipo "legado", se decidi que la precarga era
la mejor opcin.
Otro tema es la seguridad. Existen algunas reglas de negocio que no todos deberan poder ver, como el clculo
de primas o descuentos por antigedad. Esto implica coordinarse con todos los involucrados desde un inicio
para saber quin ve qu, y no llegar a malos entendidos con diferentes reas usuarias.
Finalmente, el BRMS. Los hay algunos muy buenos, pero si vamos por la opcin de uno comercial, es
indispensable que el cliente haya adquirido todas las licencias necesarias; si es posible, incluso antes de que
empiece la etapa de construccin. En este proyecto, a alguien se le ocurri decir que "somos partners de IBM",
por lo que el cliente asume que ya tenemos las licencias para usar el producto. Sin embargo, "la realidad es un
poco diferente" y aunque tenemos derecho a bajar algunas cosas, no podemos descargar la versin comercial
del BRMS con estadsticas y funcionalidad completa, por lo que a la hora de sentarse a implementar nos dimos
un par de topes contra la pared antes de llegar al punto de decir "si no consigues las licencias, no podemos
continuar".
Pgina 19 de 28

16/08/2015
1.2.3 DISEAR VISTAS PARA LOS USUARIOS

Una vista es una alternativa para mostrar datos de varias tablas. Una vista es como una tabla virtual que
almacena una consulta. Los datos accesibles a travs de la vista no estn almacenados en la base de datos
como un objeto.
Entonces, una vista almacena una consulta como un objeto para utilizarse posteriormente. Las tablas
consultadas en una vista se llaman tablas base. En general, se puede dar un nombre a cualquier consulta y
almacenarla como una vista.
Una vista suele llamarse tambin tabla virtual porque los resultados que retorna y la manera de referenciarlas
es la misma que para una tabla.
Las vistas permiten:
ocultar informacin: permitiendo el acceso a algunos datos y manteniendo oculto el resto de la
informacin que no se incluye en la vista. El usuario opera con los datos de una vista como si se tratara
de una tabla, pudiendo modificar tales datos.
simplificar la administracin de los permisos de usuario: se pueden dar al usuario permisos para que
solamente pueda acceder a los datos a travs de vistas, en lugar de concederle permisos para acceder
a ciertos campos, as se protegen las tablas base de cambios en su estructura.
mejorar el rendimiento: se puede evitar tipear instrucciones repetidamente almacenando en una vista
el resultado de una consulta compleja que incluya informacin de varias tablas.
Podemos crear vistas con: un subconjunto de registros y campos de una tabla; una unin de varias tablas; una
combinacin de varias tablas; un resumen estadstico de una tabla; un subconjunto de otra vista, combinacin
de vistas y tablas.
Una vista se define usando un "select".
La sintaxis bsica parcial para crear una vista es la siguiente:
create view NOMBREVISTA as
SENTENCIASSELECT
from TABLA;
El contenido de una vista se muestra con un "select":
select *from NOMBREVISTA;
En el siguiente ejemplo creamos la vista "vista_empleados", que es resultado de una combinacin en la cual se
muestran 4 campos:
create view vista_empleados as
select (apellido+' '+e.nombre) as nombre,sexo,
s.nombre as seccion, cantidadhijos
from empleados as e
join secciones as s
on codigo=seccion
Para ver la informacin contenida en la vista creada anteriormente tipeamos:
select *from vista_empleados;
Podemos realizar consultas a una vista como si se tratara de una tabla:
select seccion,count(*) as cantidad
from vista_empleados;
Los nombres para vistas deben seguir las mismas reglas que cualquier identificador. Para distinguir una tabla
de una vista podemos fijar una convencin para darle nombres, por ejemplo, colocar el sufijo vista y luego el
nombre de las tablas consultadas en ellas.
Los campos y expresiones de la consulta que define una vista DEBEN tener un nombre. Se debe colocar
nombre de campo cuando es un campo calculado o si hay 2 campos con el mismo nombre. Note que en el
ejemplo, al concatenar los campos "apellido" y "nombre" colocamos un alias; si no lo hubisemos hecho
aparecera un mensaje de error porque dicha expresin DEBE tener un encabezado, SQL Server no lo coloca
por defecto.
Pgina 20 de 28

16/08/2015
Los nombres de los campos y expresiones de la consulta que define una vista DEBEN ser nicos (no puede
haber dos campos o encabezados con igual nombre). Note que en la vista definida en el ejemplo, al campo
"s.nombre" le colocamos un alias porque ya haba un encabezado (el alias de la concatenacin) llamado
"nombre" y no pueden repetirse, si sucediera, aparecera un mensaje de error.
Otra sintaxis es la siguiente:
create view NOMBREVISTA (NOMBRESDEENCABEZADOS)

as
SENTENCIASSELECT
from TABLA;
Creamos otra vista de "empleados" denominada "vista_empleados_ingreso" que almacena la cantidad de
empleados por ao:
create view vista_empleados_ingreso (fecha,cantidad)
as
select datepart(year,fechaingreso),count(*)
from empleados
group by datepart(year,fechaingreso)
La diferencia es que se colocan entre parntesis los encabezados de las columnas que aparecern en la vista. Si
no los colocamos y empleamos la sintaxis vista anteriormente, se emplean los nombres de los campos o alias
(que en este caso habra que agregar) colocados en el "select" que define la vista. Los nombres que se colocan
entre parntesis deben ser tantos como los campos o expresiones que se definen en la vista.
Las vistas se crean en la base de datos activa.
Al crear una vista, SQL Server verifica que existan las tablas a las que se hacen referencia en ella.
Se aconseja probar la sentencia "select" con la cual definiremos la vista antes de crearla para asegurarnos que
el resultado que retorna es el imaginado.
Existen algunas restricciones para el uso de "create view", a saber:
no puede incluir las clusulas "compute" ni "compute by" ni la palabra clave "into";
no se pueden crear vistas temporales ni crear vistas sobre tablas temporales.
no se pueden asociar reglas ni valores por defecto a las vistas.
no puede combinarse con otras instrucciones en un mismo lote.
Se pueden construir vistas sobre otras vistas.
Pgina 21 de 28

16/08/2015
1.2.4 NORMALIZAR LA BASE DE DATOS (1FN, 2FN, 3FN)

Primera forma normal (1FN)
Una relacin est en primera forma normal si, y slo si, todos los dominios de la misma contienen valores
atmicos, es decir, no hay grupos repetitivos. Si se ve la relacin grficamente como una tabla, estar en 1FN
si tiene un solo valor en la interseccin de cada fila con cada columna.
Si una relacin no est en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo ser el
atributo o grupo de atributos que tiene mltiples valores para cada tupla de la relacin. Hay dos formas de
eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del
grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas
redundancias se eliminarn despus mediante las restantes formas normales. La segunda forma de eliminar
los grupos repetitivos consiste en poner cada uno de ellos en una relacin aparte, heredando la clave primaria
de la relacin en la que se encontraban.
Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos.
Segunda forma normal (2FN)
Una relacin est en segunda forma normal si, y slo si, est en 1FN y, adems, cada atributo que no est en la
clave primaria es completamente dependiente de la clave primaria.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una
relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN. Las
relaciones que no estn en 2FN pueden sufrir anomalas cuando se realizan actualizaciones.
Para pasar una relacin en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Para
ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva relacin con una
copia de su determinante (los atributos de la clave primaria de los que dependen).
Tercera forma normal (3FN)
Una relacin est en tercera forma normal si, y slo si, est en 2FN y, adems, cada atributo que no est en la
clave primaria no depende transitivamente de la clave primaria. La dependencia es transitiva si existen las
dependencias , , siendo , , atributos o conjuntos de atributos de una misma relacin.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todava pueden sufrir
anomalas frente a las actualizaciones. Para pasar una relacin de 2FN a 3FN hay que eliminar las
dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en una
nueva relacin con una copia de su determinante (el atributo o atributos no clave de los que dependen).
1.3 ELECCION DEL MANEJADOR DE BASES DE DATOS (4 EJEMPLOS)

Para seleccionar correctamente un SGBD se deben analizar y reconocer ciertos aspectos. Por ejemplo:
Caractersticas, virtudes, ventajas y desventajas de cada uno que permitan reconocer y seleccionar el mejor al
momento de encontrarse con determinada solucin.
Primero comenzaremos por entender que los siguientes SGBD pertenecen al modelo
Cliente/Servidor:
MySQL
PostgreSQL
Mientras que los siguientes pertenecen al modelo embebido:
SQLite
Microsoft Access
Paradox
Microsoft SQL Server

Oracle
dBase
Microsoft SQL Server
Ntese como este ltimo (SQL Server) se filtra en ambos, y es que proporciona versiones para
ambas situaciones o modelos.
Pgina 22 de 28

16/08/2015
Ahora bien, los SGBD Cliente/Servidor son aquellos que como tal permiten realizar una conexin remota o
local mediante la ejecucin de un servicio o aplicacin que opera mediante un puerto lgico de datos. Esto es
entonces que para poder emplear un SGBD de este tipo se requiere siempre tener instalado dicho software en
un equipo como mnimo, de otra manera la administracin o acceso a la base de datos es imposible.
Por otro lado los SGBD embebidos permiten tener acceso a la base de datos sin necesidad de tener algn
software instalado. Aunque si bien es cierto debe haber un punto de partida, por lo que el desarrollador de la
base de datos si deber instalarse ciertas herramientas para la creacin de la BD. Esto claro depender del
SGBD embebido que desee utilizar.
El tipo embebido entonces puede generar uno o ms archivos por base de datos, permitiendo tener una
portabilidad ms cmoda. Pues como ya se menciono, los equipos a donde se distribuya no requerirn ningn
software extra como SGBD, pues ese trabajo ya estar hecho previamente por el desarrollador en su equipo.
Pero Qu tiene uno que no tenga el otro? Esta pregunta nos lleva visualizar aspectos resaltantes entre uno u
otro. Y es que por ejemplo debemos resaltar que en aspectos de seguridad, los SGBD Cliente/Servidor se llevan
el premio. Pues estos son ms ptimos que los embebidos en cuestiones de seguridad. Y es que si
Cliente/Servidor significa acceso remoto, entonces debemos de prevenir cualquier acceso mal intencionado.
Esto lleva a concluir que dichos SGBD por tanto deben proveerse de capacidades que contribuyan
enormemente a la proteccin de informacin.
1.4 ELECCIN DEL MOTOR DE ALMACENAMIENTO (2 EJEMPLOS)

Criterios para el proceso de seleccin
1. Todas las bases de datos son diferentes
Este primero no es un criterio en s. Este primero es ms bien una premisa que debe entender en todo este
proceso cada base de datos es particular como los autos de distintas marcas. Los carros varan desde un
Zaporozhec hasta un Ferrari, Maybach y tractores monstruosos. Esa situacin es igual en las bases de datos.
Usted no podra cargar una carga pesada en un Ferrari. Si tratara de usar las mismas velocidades en una caja
de cambios manual que en una automtica la rompera. Es lo mismo con las bases de datos, existen muchos
fabricantes, tienen diferentes arquitecturas y no puedes aplicar las mis buenas prcticas a todos.
2. Entender los requerimientos actuales pero planear a futuro
Este es el criterio principal. Usted debe entender los requerimientos funcionales y no funcionales y escoger la
base de datos que mejor se ajuste a estos requerimientos. Los requerimientos deberan de ser al menos los
siguientes:
Cantidad de datos y tipo de datos (texto, binarios, espacial u otros tipos especficos)
Nmero simultaneo de usuarios (concurrencia a la base de datos)
Disponibilidad: cuanto tiempo puede permitir tener de baja su base de datos.
Escalabilidad: qu har cuando la cantidad de datos y el nmero de usuarios aumente.
Seguridad: cuanto necesitar de caractersiticas como seguridad de encripcin de datos,
administracin de usuarios, privilegios.
Manejo y administracin: cuan amigable quiere que sea la administracin de su base de datos.
Que otras caractersticas cool quiere obtener de su base de datos.
Es razonable elaborar los requerimientos en funcin de sus recursos y necesidades reales. Por su puesto que
es recomendable ver un poco hacia el futuro y modificar los requerimientos acorde al mismo, pero eso debe
hacer con cuidad.
Pgina 23 de 28

16/08/2015
3. Tome en cuenta sus experiencias previas

Tome en cuenta sus experiencias previas y las habilidades desarrolladas trabajando con bases de datos. Como
dije, son diferentes. S usted escoge una base desconocida o semi-desconocida, necesitar tiempo para
familiarizare con ella, para entender sus herramientas, para entender en gran medida sus caractersticas, sus
fortalezas y sus debilidades (que por lo general no estn listadas juntas). Probablemente va a necesitar que sus
administradores y desarrolladores de bases de datos asistan a un curso, generando un costo extra y la
ausencia de su personal.
4. Situacin actual -> La base de datos debe cooperar con sistemas existentes o es el primero.
Hay una gran diferencia si su proyecto es el primero en determinada rea o si debe considerar a otros sistemas
con los que debe colaborar. En el primer caso tiene mucho mayor libertad con sus opciones. En el segundo
caso, debe lidiar con el hecho que usualmente las bases de de datos se integran ms fcilmente con bases de
datos del mismo fabricante que las de la empresa rival. En el caso de que su eleccin de base de datos y las
actuales sean diferentes, usted o su cliente deben lidiar con diferentes niveles de soporte no solo a nivel
tcnico sino tambin administrativo.
5. Evaluar la oferta laboral
Asegrese de podr encontrar a una persona experta en caso de que su base datos falle. Aunque sea su
empleado o un especialista de una empresa consultora, debe tener al menos una persona mas en quien
confe. Es muy desagradable pagar mucho porque un da alguien tenga que restaurar su base de datos pero es
mucho ms desagradable darse cuenta de que no hay nadie que lo pueda hacer.
Debe considerar que los administradores y desarrolladores de bases de datos de diferentes fabricantes
pueden tener diferentes salarios. Esto puede variar de vez en cuando y segn el lugar pero definitivamente se
presentan estas variaciones. La oferta laboral para una base de datos repercute en los salarios, de igual forma
repercute en la posibilidad de conseguir nuevos desarrolladores.
6. Evaluar costos directos
6.1. Licencias
Este es el aspecto ms comn del que todos hablan en el proceso de seleccin. Usted puede encontrar
numerosos artculos que aseguran que una base de datos X es ms barata que una base de datos Y
comparando solo los costos de licenciamiento. El costo de la licencia es tan solo uno de los factores que
influyen en el costo directo, sin mencionar de costos indirectos asociados a determinada base de datos.
Mientras analiza los costos recuerde:
Las diferentes bases de datos tienen diferentes modelos de licenciamiento, por ejemplo, basado en
nmero de usuarios, nmero de procesadores o cantidad de memoria RAM.
El precio de lista es solo una referencia, probablemente pueda conseguir precios especiales,
especialmente si es un cliente grande.
Las bases de datos de ciertos fabricantes tienen diferentes versiones, por ejemplo versin empresarial
o versin estndar las cuales tienen diferencias significativas en costos. En realidad necesita la
versin empresarial? Usualmente la primera eleccin. De nuevo recuerde el primer punto, las bases de
datos son diferentes, por lo tanto nunca compare los precios de la misma edicin entre bases de
datos categricamente. Vea adentro para saber que contiene cada edicin, lo que para unas es
empresarial para otras podra ser estndar.
Explore los modelos de licenciamiento, los descuento, las caractersticas y opciones adicionales, no
deje que el vendedor de encasille el precio, exija el detalle de la licencia.
6.2. Soporte
Investigue cunto cuesta el soporte, y que ofrece ese soporte. Usualmente existen muchos niveles con
diferentes caractersticas y precios.
Pgina 24 de 28

16/08/2015
6.3. Caractersticas adicionales

Algunas bases de datos contienen caractersticas adicionales ms all de la versin empresarial, por un
precio adicional. Si realmente no necesita esas caractersticas puede solicitar descuentos adicionales de su
representante de ventas.
6.4. Requisitos del sistema operativo
Algunas bases de datos requieren sistemas operativos especficos. Los sistemas operativos como las bases de
datos son diferentes, requieren diferentes tipos de administracin y de habilidades. En el proceso de
evaluacin los costos de un sistema de operativo debe utilizar criterios anlogos a sistemas operativos.
7. Fallo de la base de datos
Cul es la probabilidad de que la base de datos que escogi no responda?Quin la recuperar?En cunto
tiempo?Cunto tiempo pierde usted o su cliente durante ese tiempo?
8. Industrias especficas
Existen industrias (sistemas de informacin geogrfica por ejemplo) que requieren bases de datos especiales o
al menos que tenga soporte para esa industria en particular. Por supuesto que si usted as lo quiere puede ser
un pionero e iniciar la adaptacin de esa base de datos a una industria pero eso podra costar mucho tiempo y
recursos.
9. Productos especficos
Si ha escogido un producto en particular y que el mismo trabaje con una base de datos diferente, debe
asegurarse que no tendr consecuencias negativas al mismo. Si no est seguro, consulte cual es la base de
datos preferible. Si todas son igual de buenas puede estar seguro que todas son igual de malas ;).
Definitivamente no le deseo a nadie que sea el primer usuario en una base de datos para un producto.
10. Comunidad de usuarios existente, recursos en lnea y popularidad
Es importante entender que son los recursos de la comunidad de usuarios, foros, listas de correo,
conferencias, seminarios. Tambin identifique cuales de los artculos, publicaciones, manuales harn su vida
ms fcil en caso de una emergencia. No querr tener que ser el primero en solucionar una gran cantidad de
problemas, ser el primero en solucionar algunos es suficiente.
11. Hardware necesario
Entienda que plataformas de hardware son las soportadas y cules son los parmetros mnimos. Por supuesto
que depende la cantidad de datos esperada, de la cantidad de usuarios y la carga esperada en general.
12. Criterios de decisin
Para ser sincero, no espero que usted siga el proceso de decisin que describo arriba. ;) Todava ms, estoy
muy seguro que muchas veces crear un pequeo sistema para 5 usuarios para el que no le importa la
disponibilidad ni la seguridad. Pero la cosa ms importante, la que quisiera relatar-> el costo de la base de
datos no es el mismo que el costo de la licencia. No! Entre ms crezca su sistema menor es el impacto el costo
de la licencia.
Si decide utilizar un mtodo CTP (costo total de la propiedad) para escoger su base de datos, los criterios
mencionados arriba pueden ser datos importantes para dicho anlisis.
13. Enlaces similares
Existe un artculo de Lewis Cunningham Una gua completa para escoger bases de datos para novatos que
explica temas similares.
Pgina 25 de 28

16/08/2015
Bases de datos ms populares

Segn el artculo de Gartner Participacin de mercado de bases de datos relacionales existen tres fabricantes
principales. Estos son: Oracle, DB2 y SQL Server de Oracle, IBM y Microsoft respectivamente. La competencia
es usualmente algo bueno, existe una rivalidad sin fin por ser el mejor ( sin saber exactamente el significado de
el mejor) que tambin permite la distribucin de licencias express (sin costo) de sus productos.
De los productos de cdigo abierto me gustara primero mencionar a dos de ellos, MySQL y PostgreSQL. El
lema del primero es La base de datos cdigo abierto ms popular del mundo, para el segundo el lema es La
base de datos cdigo abierta ms avanzada del mundo. Como ya debe haberlo imaginado, estas tambin
tienen su propia pelea y estn tratando de tomar un pedazo del pastel.
De nuevo, un listado de las bases de datos ms populares:
DB2
PostgreSQL
MySQL
SQL Server
Oracle
1.5 ESTIMACIN DEL TAMAO DE LA BASE DE DATOS

Cuando disea una base de datos, puede que necesite realizar una estimacin del tamao que tendr la base
de datos cuando est llena. Esta estimacin puede ayudarle a determinar la configuracin de hardware que
necesitar para realizar lo siguiente:
Conseguir el rendimiento que necesitan las aplicaciones.
Asegurar la cantidad fsica adecuada de espacio en disco necesario para almacenar los datos y los
ndices.
Asimismo, la estimacin del tamao de la base de datos puede ayudarle a determinar si el diseo de su base
de datos necesita reajustes. Por ejemplo, puede determinar que el tamao estimado de la base de datos es
demasiado grande para una implementacin en su organizacin, y que se necesita un mayor grado de
normalizacin. Por el contrario, el tamao estimado puede inferior al esperado, con lo que podr reducir la
normalizacin de la base de datos para mejorar el rendimiento de las consultas.
Para realizar una estimacin del tamao de una base de datos, efecte una estimacin del tamao de cada
tabla por separado y sume los valores obtenidos. El tamao de una tabla depende de si tiene ndices y, si los
tiene, del tipo de ndices.
Para la estimacin del tamao que ocupara una base de datos se deben tener en cuenta los siguientes valores:
Ti: Tamao inicial de la base "limpia". Este valor depender del motor seleccionado, de su versin y del
SO.
Td: Tamao de las tablas con sus datos. es el valor que ocuparan los datos, este es el ms estndar de
los valores ya que se obtiene calculando el tamao de cada una de las tablas sumando lo que ocuparan
cada una de sus filas. Si hay que tener en cuenta que no todos los motores poseen exactamente los
mismos tipos de datos por lo que los tamaos podran variar. Adems hay que tener en cuenta que
cada motor maneja diferente las caractersticas de las columnas.
Tidx: Tamao de los ndices. Este tamao se obtiene de la suma de todos los ndices que tenga cada
una de las tablas. Y para su clculo se deber tener en cuenta el tipo de ndice (cluster, no cluster) y el
mtodo que utilice el motor seleccionado para almacenarlo.
Tc: Tamao de las funciones y/o procedimientos (generalmente este tamao es insignificante respecto
de los dems.
Tud: este tamao depende de la configuracin de la base y de los tipos de procesos que se ejecuten.
En la mayora de los casos suele ser un espacio a considerar si se tiene un alto volumen de
transacciones concurrentes o si las transacciones ejecutan muchas sentencias en cada transaccin.
Tlog: Tamao para logs de transacciones. Este valor puede variar de acuerdo a la configuracin de la
base.
CS: Coeficiente de seguridad
Tdb: Tamao de la base de datos

Pgina 26 de 28

16/08/2015
El valor ms complejo de estimar es que cantidad de filas tendr cada tabla.

Para estimar el nmero de filas se debe tener en cuenta:
La cantidad de transacciones estimadas y en base a esto determinar el porcentaje de dichas
transacciones que agregaran o eliminaran registros de cada tabla.
Si existe una base de datos similar en un contexto similar podra tomarse como parmetro para
realizar la estimacin
En algunos casos es posible estimar este valor mediante informacin de marketing.
Ejemplo sencillo de estimacin del tamao de una tabla para MS-SqlServer 2008
Clientes
Clie_id
Int
Clie_detalle
Varchar (50)
Clie_provincia Int
NULL
NULL
NULL
Para este ejemplo estimaremos que el nro de filas de la tabla ser de 1000.
Como primer paso se debe calcular el tamao que ocupara 1 fila.

El valor 4 de la frmula representa la sobrecarga del encabezado de la fila de datos.
Luego calculamos el tamao de las columnas de tamao variable:
2
2

Para nuestro ejemplo:
2 1 2
50
Suponemos que siempre se ocupar el mximo, si se conoce el valor promedio es conveniente ajustar el valor
de Max_Var_Size. Los bytes agregados a Max_Var_Size son para el seguimiento de cada columna de longitud
variable.
Entonces:
54

NuN_Btmap: el mapa de bits NULL, se reserva para administrar la nulabilidad en las columnas
2
Para nuestro ejemplo:
solo se toma la parte entera

2
Entonces:
Finalmente una fila ocupara:
8
54

Entonces el tamao de la tabla ser:
69
1000 69000
3
3

67.4
69
Pgina 27 de 28

16/08/2015
Bibliografa
Aulaclic.com. (s.f.). Curso de SQL Server. Recuperado el 08 de Septiembre de 2015, de
http://www.aulaclic.es/sqlserver/index.htm
Garca, A. F. (Enero de 2000). Conceptos bsicos de la Programacin Orientada a Objetos. Recuperado el 18
de Septiembre de 2015, de http://www.sc.ehu.es/sbweb/fisica/cursoJava/fundamentos/clases1/clases.htm
Gutirrez, P. (2015 de 10 de 10). Genbeta:dev. Obtenido de http://www.genbetadev.com/bases-dedatos/fundamento-de-las-bases-de-datos-modelo-entidad-relacion
May, F. G. (4 de Junio de 2012). PROGRAMACION ORIENTADA A OBJETOS (POO) . Recuperado el 18 de
Septiembre de 2015, de http://itzoisc.blogspot.mx/2012/06/43-definicion-implementacion-y-herencia.html
Microsoft. (s.f.). Microsoft Developer Network. Recuperado el 08 de Septiembre de 2015, de
https://msdn.microsoft.com/es-es/library/ms187445%28v=sql.120%29.aspx
Roque, E. G. (2007). Principios Basicos de Informtica. Madrid: Dykinson.
Pgina 28 de 28

Unidad 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unidad 1

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Nacional Autnoma de Mxico

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

1.1. DISEO CONCEPTUAL (MODELO ENTIDAD-RELACION)

Ejemplos de entidad y conjunto de entidad.

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

1.2. DISEO LGICO

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

1.2.1 DISEAR RELACIONES (LLAVES PRIMARIAS Y FORANEAS)

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Otros ejemplos para ilustrar este modelo de relacin podran ser:

Establecer relaciones entre tablas

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

1.2.2 DISEAR REGLAS DE NEGOCIOS

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Esto en pseudocdigo se expresa como IF Reclamacion.numSiniestro != null THEN Reclamacion.tipo =

Si la reclamacin contiene el nmero de

Criterios de validacin (IF x AND y)

Universidad Nacional Autnoma de Mxico

Para reembolsos, verificar que la factura est

Criterios de validacin (IF x AND y)

En caso exitoso ejecutar

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Implementando las reglas

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

Jos Mauricio Estrella Vzquez

Universidad Nacional Autnoma de Mxico

Desarrollo de Aplicaciones en Manejadores de Bases de Datos Relacionales

1.2.3 DISEAR VISTAS PARA LOS USUARIOS

Universidad Nacional Autnoma de Mxico