Diseño y Almacenamiento de Datos

Vista previa del material en texto

Diseño de Datos
Introducción
La información como ventaja competitiva de la empresa
Tradicionalmente las organizaciones han reconocido la importancia de una administración adecuada de los recursos básicos, tales como la mano de obra y las materias primas. No ha sido hasta estos últimos tiempos que la información tomó una connotación de recurso primordial. Los responsables de la toma de decisiones empiezan a considerar que la información, ya no es un producto exclusivamente colateral de la operación de la empresa, sino que en sí es uno de los promotores de la misma. La información puede llegar a ser el elemento decisivo que determine el éxito o fracaso de un negocio.
Con el fin de lograr la máxima utilidad de la información, ésta debe administrarse de manera correcta, como cualquier otro recurso de la empresa. Debe entenderse que existen costos que se asocian con la producción, distribución, seguridad, almacenamiento y recuperación de la información. Aunque la información aparentemente se encuentra siempre disponible, su uso estratégico como un apoyo a la competitividad del negocio no debe considerarse como un elemento gratuito.
La disponibilidad de las computadoras ha generado todo un incremento y una diversificación de la información, tanto para la sociedad en general, como para las organizaciones en particular. La administración de la información que se genera en computadoras difiere de aquella que se genera en forma manual. Frecuentemente se tiene una mayor cantidad de información si ésta se genera utilizando sistemas computacionales ; los costos para crear y mantener la información computarizada son, aparentemente, mayores ; la información que genera la computadora puede llegar a multiplicarse a velocidades impresionantes.
Objetivos del diseño de almacenamientos
En algunos enfoques se consideran a los almacenamientos de datos como la esencia de los sistemas de información. El impacto de la estructura de datos sobre la estructura de programa y la complejidad procedimental, hace que el diseño de datos tenga una gran influencia en la calidad del software.
Independientemente de las técnicas de diseño usadas, los datos bien diseñados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.
Los objetivos generales del diseño de la organización de almacenamientos son :
1. Disponibilidad de datos : Los datos deben estar disponibles para cuando el usuario desee usarlos. Sólo se debe negar el acceso a datos reservados por razones legales.
2. Accesibilidad: deben ser fáciles de acceder por los usuarios. Si no se puede acceder fácilmente no serán utilizados (y eventualmente pueden ser “inventados”). No deben reflejar las necesidades de un sector particular, o serán difíciles de acceder para los otros.
3. Integridad de datos : Los datos deben ser precisos (cada valor almacenado de estar dentro de un rango aceptable respecto del valor real) y consistentes (no deben reflejar realidades distintas ya en el tiempo (las Cuentas a Pagar no cierran contra las Facturas Pendientes) como en los datos relacionados (un Gerente de Área no puede ser un empleado de categoría mínima)). El conjunto de datos debe representar fielmente a la organización.
4. Almacenamiento eficiente.
5. Actualización y recuperación eficiente.
6. Recuperación dirigida de la información : la información obtenida de los datos almacenados debe contar con un formato útil que facilite la administración, la planeación, el control o la toma de decisiones.
Los datos
Los datos que se obtienen de la realidad (personas, lugares o de eventos de la realidad), eventualmente serán almacenados en archivos o bases de datos. Para poder comprender la forma y estructura de los datos, se requiere de información acerca de los datos mismos. Esta información descriptiva se denomina metadato.
La relación entre la realidad, los datos y los metadatos, puede verse como :
 (
METADATOS
) (
DATOS
) (
REALIDAD
)
En el contexto de la realidad se tienen entidades y atributos ; en el contexto de los datos reales, se tienen registros de eventos y datos de los eventos ; en el contexto de los metadatos hay definiciones de registros y definiciones de los datos.
REALIDAD
DATOS
	VENDEDOR
	(COD. VENDEDOR
	NOMBRE)
	
	25
	Mendoza, Agustín
	
	26
	Aguilar, José
	VENTA
	(NRO-OPERACIÓN
	COD. VENDEDOR
	FECHA
	COD. CLIENTE)
	
	125
	25
	12/02/1997
	256
	
	126
	25
	12/02/1997
	325
	
	127
	26
	13/02/1997
	101
	ITEM VENTA
	(NRO-OPERACIÓN
	COD. ART.
	CANTIDAD
	PRECIO. UNIT)
	
	125
	513
	1
	10,25
	
	126
	513
	1
	10,00
	
	126
	601
	2
	17,00
	CLIENTE
	(COD. CLIENTE
	NOMBRE
	CUIT)
	
	101
	Heuser, Carlos
	30-58503988-4
	
	256
	Michelin, Pablo
	30-58134023-7
	
	325
	Lager, Daniel
	20-18441727-9
	ARTÍCULO
	(COD.ART.
	NOMBRE
	EXISTENCIA
	PRECIO)
	
	513
	MARTILLO
	25
	10,25
	
	601
	PINZA
	30
	8.50
	
	603
	SERRUCHO
	10
	25.36
METADATOS
	Dato
	Descripción
	Tipo
	Formato
	Cód. Vendedor
	Código de identificación asignado a cada vendedor.
	N
	99999
	Nombre
	Apellido y Nombre de un vendedor.
	A
	X(35)
	Cód. Cliente
	Código asignado a un cliente cuando comienza a realizar operaciones con la empresa.
	N
	99999
	Nombre
	Apellido y nombres de un cliente.
	A
	X(35)
	Cód. Art.
	Código asignado a cada artículo disponible para la venta.
	N
	9999
	Nombre
	Nombre de un artículo.
	A
	X(40)
	.........
	.......
	.....
	........
Tipos de Datos:
N: Numérico
A: Alfabético
X: Alfanumérico
D: Fecha DD/MM/AAAA
Algunos principios a tener en cuenta en la especificación de datos 
1- Aplicar principios sistemáticos en el análisis de los datos.
Se deben desarrollar y revisar las representaciones del flujo y del contenido de los datos, identificar las entidades, considerar organizaciones de datos alternativas, y evaluar el impacto de la modelización de datos sobre el diseño del software.
2- Identificar todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas.
El diseño de una estructura de datos eficiente debe tener en cuenta las operaciones que han de realizarse sobre dicha estructura de datos.
3- Establecer y usar un diccionario de datos para definir el diseño de los datos.
Un diccionario de datos representa explícitamente las relaciones entre los datos y las restricciones sobre los elementos de una estructura de datos. Se pueden definir más fácilmente algoritmos que aprovechen las relaciones específicas si existe una especificación de los datos en forma de diccionario.
4- Posponer las decisiones de diseño de datos de bajo nivel hasta más adelante en el proceso de diseño.
Para el diseño de datos puede seguirse un proceso de refinamiento sucesivo. Es decir, puede definirse una organización global de los datos durante el análisis de requisitos, refinar durante el diseño preliminar y especificarse en detalle durante el diseño detallado. El enfoque descendente para el diseño de datos proporciona unas ventajas análogas a las del enfoque descendente para el diseño de software
Modelo Entidad-Relación (ER)
Modelo de datos para realizar el diseño conceptual de bases de datos.
Conceptos básicos
· Entidad
· Relación
· Atributo
Conceptos adicionales
· Generalización/Especialización
· Entidad Asociativa
· Atributos compuestos
Entidad
Representa clases de objetos sobre los cuales se desea mantener información.
Las entidades pueden representar tanto objetos concretos de la realidad (una persona, una computadora, ...), como así también objetos abstractos de la realidad (un nombre, rango, ....).
Colección de entidades que, para los fines del modelado, poseen propiedades semejantes.
Un conjunto de entidades se representa en un diagrama ER a través de un rectángulo.
 (
Alumno
)
				Representa un conjunto de entidades alumno
 (
Departamento
)
				representa un conjunto de entidades departamento
Persona, Empleado, Hombre, Mujer son ejemplos de entidades.
Terminología
El nombre asignado al conjunto de entidades es un sustantivo singular.
Relaciones
Representan agregaciones de dos o más entidades.Una relación es una asociación entre entidades, representando una asociación entre objetos de la realidad modelada.
Se representan a través de un rombo.
Las relaciones siempre involucran un número fijo de entidades.
Nombres de relaciones
Utilizar sustantivos, si no es posible dejar vacío cuando la relación sea trivial. Alternativamente pueden utilizarse verbos con flechas indicadoras del sentido de lectura.
 (
NACIMIENTO
) (
CIUDAD
) (
PERSONA
)
 (
RESIDENCIA
)
 (
CURSO
AULA
DICTADO
DIA
)
Anillos (Relaciones recursivas): son interrelaciones binarias que conectan una entidad consigo misma.
Una entidad cumple un rol dentro de un relación, y estos pueden indicarse en el diagrama.
Ejemplo: Una relación de casamiento asocia entidades representativas de personas. Ser marido o esposa es un rol ejercido por una entidad en una relación.
 (
p7
) (
p5
) (
p3
) (
p1
)
 (
p6
) (
p4
) (
p2
)
 (
marido
)
 (
marido
) (
esposa
) (
esposa
)
 (
Persona
Casamiento
marido
esposa
)
 (
p5,p7
) (
p1,p3
)
 (
DIRECTOR
)
 (
EMPLEADO
) (
DIRECCION
)
 (
SUBORDINADO
)
Atributos
Representan las propiedades básicas de las entidades o relaciones.
Para los fines didácticos, los atributos pueden ser representados gráficamente. En la práctica, es usual representar los atributos y sus dominios en un diccionario de datos en forma textual.
La notación de atributos utilizada corresponde a Chen.
 (
PROYE
CTO
)
 (
tipo
)
 (
código
)
 (
nombre
)
 (
Nombre
) (
PERSONA
)
 (
DNI
)
 (
Profesión
)
 (
Título
)
Cardinalidad en atributos
En general se considera que cada entidad de un conjunto, tiene asociada exactamente un valor de cada atributo.
Pueden especificarse cantidad mínima y máxima de valores de un atributo asociados a una entidad. 
La cardinalidad mínima indica el número mínimo de valores para el atributo:
· Si la card-min = 0 el atributo es opcional y puede no estar especificado en algunos casos.
· Si la card-min = 1 el atributo es obligatorio y al menos un valor debe especificarse en cada caso.
Ejemplos : card-min (PERSONA, Nombre) = 1 ; card-min (PERSONA, DNI) = 1 ; card-min (PERSONA, Teléfono) = 0.
La cardinalidad máxima indica el máximo de valores para un atributo.
· Si card-max = 1 el atributo es monovalente.
· Si card-max > 1 el atributo es polivalente.
Ejemplos : card-max (PERSONA, Nombre) = 1 ; card-max (PERSONA, DNI) = 1 ; card-max (PERSONA, Teléfono) = n, card-max (PERSONA, Título) = n
La cardinalidad de atributos es el par (card-min, card-max).
Ejemplos :
card (PERSONA, Nombre) = (1,1) ; card (PERSONA, DNI) = (1, 1) ; card (PERSONA, Teléfono) = (0, n), card (PERSONA, Título) = (0,n)
Cada atributo se asocia a un dominio particular.
Dominio: conjunto de valores legítimos para un atributo.
Ejemplos : El dominio de “Nombre” puede ser {“Ariel”, “Natalia”, “Marcela”, “Hugo”, “Marcelo”, ….}
Para “DNI” : {10.000.000 …. 99.999.999}
Como disciplina de modelado, es aconsejable iniciar el proceso restringiéndose a atributos con exactamente un valor (1,1):
· los atributos multi-valorados (cardinalidad máxima “n”) son difíciles de implementar en SGBD relacionales (esto es importante en el Diseño),
· los atributos opcionales (cardinalidad mínima “0”) generalmente indican clases especiales de entidades
Cardinalidad en relaciones
Cardinalidad Máxima
Se consideran dos cardinalidades máximas de una entidad en un conjunto de relaciones:
1 una entidad está asociada como máximo a una entidad a través del conjunto de relaciones.
n una entidad puede estar asociada a muchas entidades a través del conjunto de relaciones.
Los conjuntos de relaciones son clasificados en base a su cardinalidad máxima en:
1:1 uno a uno
1:n uno a muchos
n:n muchos a muchos
Conjunto de relaciones 1:1
 (
Persona
 casamiento
marido
esposa
1
1
Una persona puede tener como máximo una esposa
)
Existe un problema de expresión de semántica, que no puede ser resuelto con la cardinalidad máxima 1. El caso es por ejemplo que el modelo permite que una persona esposa de otra en una relación, sea marido en otra relación; una persona puede ser marido y esposa en la misma relación (en relación consigo mismo).
Relaciones 1:n
 (
n
) (
1
) (
 As
ignación
) (
Departamento
) (
Empleado
)
A través de la relación asignación:
· cada entidad departamento puede estar asociada a muchas (n) entidades empleado.
· cada entidad empleado pude estar asociada a lo máximo una (1) entidad departamento.
Ejemplos
 (
1
) (
n
) (
 Inscripción
) (
Empleado
) (
Alumno
) (
Carrera
)
 (
1
) (
n
)
 (
supervisor
) (
supervisado
)
 (
 Supervisión
)
Límites de expresión de diagramas ER
El poder de expresión de DER es limitado, por ejemplo en la relación entre empleados a través de supervisión, se pretende representar una jerarquía, pero nada impide definir una relación recursiva: empleado 1 supervisa al 3, este al 5, y el empleado 5 al empleado 1. 
En este caso se deben anotar las restricciones de integridad del modelo.
Relacionamiento ternario
 (
DISTRIBUIDOR
) (
CIUDAD
)
 (
Se refiere a un par ciudad y producto
) (
1
) (
n
)
 (
 DISTRIBUCIÓN
)
 (
n
)
 (
PRODUCTO
)
La cardinalidad debe leerse de a dos entidades contra el restante.
Alternativamente una relación ternaria puede remplazarse por una en donde la relación es transformada en una entidad, y luego relacionada individualmente con cada una de las restantes entidades.
Cardinalidad mínima
La cardinalidad mínima es utilizada para especificar cuantas veces una entidad está asociada, como mínimo, a través de un conjunto de relaciones.
Se consideran dos cardinalidades mínimas:
0 indica que una entidad no está obligatoriamente asociada a través de la relación (participación opcional)
1 indica que una entidad debe estar asociada al menos una vez a través de la relación (participación obligatoria)
La cardinalidad mínima es indicada en el diagrama junto a la cardinalidad máxima, en la forma de un par (cardinalidad mínima, cardinalidad máxima).
 (
EMPLEADO
) (
MESA
) (
 ASIGNACIÓN
)
 (
(0,1)
) (
(1,1
)
)
Para definir la cardinalidad mínima es necesario conocer las transacciones, por esto la asignación se dejan para el final del diseño.
Atributos de relaciones
En determinadas situaciones es necesario incorporar atributos a las relaciones, ya que estos no pueden formar parte de ninguna de las entidades relacionadas, debido a que existen sólo cuando se presenta la relación.
Ejemplos:
 (
INGENIERO
PROYECTO
ASIGNACIÓN
(0,n)
(0,n)
función
)
Una función de un ingeniero en un proyecto es un atributo de la asignación, ya que este puede trabajar en muchos proyectos y un proyecto puede tener asignados muchos ingenieros. 
 (
FINANCIERA
VENTA
FINANCIACIÓN
(0,1)
(0,n)
tasa de interés
nro. de cuotas
)
Cómo no toda venta es financiada, los atributos de financiación deben aparecer en la relación.
Generalización
Una entidad E es una generalización de un grupo de entidades E1, E2, E3, ..., En si cada elemento de las clases E1, E2, ....., En es también un elemento de E.
 (
Persona
Mujer
Hombre
) (
Vehículos
Bicicleta
Motoci
cleta
Automóvil
)
Cada entidad puede participar en múltiples generalizaciones: como subconjunto respecto a una generalización, y como entidad genérica respecto a otra generalización.
Las jerarquías de generalización se caracterizan por la propiedad de cobertura.
La cobertura total y exclusiva (t,e) es la que se considera por omisión.
 (
CLIENTE
PERSONA
JURÍDICA
PERSONA
FÍSICA
nombre
CUIL
CUIT
dirección
(t,e)
)
Todas los atributos y relaciones de la entidad genérica serán heredados por sus subentidades (especializaciones).
Subconjuntos
Caso particular de generalización con una sola entidad especializada.
La cobertura en este caso es parcial y exclusiva y no necesita definirse.
Ejemplo:
 (
TRABAJADOR
)
 (
TRABAJADOR
FIJO
)
Atributos compuestos
Grupos de atributos que tienen afinidad en cuanto a su significado o uso.
Ejemplo: DIRECCION (CALLE, NÚMERO, CIUDAD, PROVINCIA, CODIGO_POSTAL, PAÍS).
 (
PERSONADirección
(1,n)
(0, n)
Calle
Ciudad
Provincia
País
Cód. Postal
)
La cardinalidad mínima y máxima se aplica con los mismos criterios que para atributos simples.
Identificación de entidades
El valor de un atributo, o conjunto de atributos combinados, distingue una entidad de las demás del conjunto.
 (
PERSONA
dirección
PERSONA
código
nombre
f
echa de nacimiento
nombre
dirección
Id. Persona
)
Se llaman también claves o claves candidatas.
Un atributo o conjunto de atributos es un identificador de una entidad, si cumple con las siguientes condiciones:
1. No pueden existir dos casos de la entidad con el mismo valor del identificador.
2. Si se omite cualquier atributo del identificador, la condición 1 deja de cumplirse.
Los atributos candidatos a ser identificadores tienen que tener una cardinalidad (1,1).
Los atributos opcionales (card-min = 0) no pueden formar parte de un identificador.
Cada entidad puede tener múltiples identificadores alternativos.
Una entidad puede ser identificada no sólo por los valores de sus atributos, sino también por otra entidad asociada a ella exactamente una vez.
 (
EMPLEADO
HIJO
(1,1)
(0,n)
número secuencia
nombre
)
Clasificación:
1. Identificador simple: formado sólo por un (1) atributo o entidad relacionada.
2. Identificador compuesto: formado por más de un atributo o entidad relacionada.
3. Identificador interno si está formado sólo por atributos, y externo cuando está formado sólo por entidades relacionadas.
4. Identificador mixto si está formado por atributos y entidades relacionadas.
Se prefiere los identificadores internos a los externos, y los simples a los compuestos (son más fáciles de entender y usar).
Al finalizar el Diseño, la fase siguiente, se requiere que cada entidad tenga al menos un identificador.
Identificación de relaciones
Una relación es generalmente identificada por las entidades que participan de ella.
Es posible incluir valores de atributos como identificador de la relación.
 (
MÉDICO
PACIENTE
CONSULTA
n
n
fecha/hora
)
Una consulta es identificada por: su médico, su paciente, y su fecha y hora.
Mecanismos de abstracción en el modelo de ER
Abstracción de clasificación
1. Una entidad es una clase de objetos del mundo real con propiedades comunes.
2. Una relación es una clase de hechos atómicos que relacionan dos o más entidades.
3. Un atributo es una clase de valores que representan propiedades atómicas de las entidades o relaciones.
Abstracción de agregación
1. Una entidad es una agregación de atributos.
2. Una relación es una agregación de entidades y atributos.
3. Un atributo compuesto es una agregación de atributos.
Abstracción de generalización
Se representan a través de las jerarquías de generalización y los subconjuntos.
Archivos convencionales y Bases de Datos
Archivos convencionales
Estos archivos son de diseño y elaboración rápida.
Con un diseño cuidadoso toda la información necesaria queda incluida, teniendo con esto un menor riesgo de omitir datos.
Si ya existen almacenes, para reducir los costos de desarrollo de un nuevo sistema de archivos, se generan archivos separados para la nueva aplicación.
Como ventaja principal puede considerarse el hecho de que la velocidad de procesamiento para un proceso puede optimizarse, pero no para varios procesos.
Los principales problemas son:
· Falta de potencial para evolucionar (solo se piensa en las necesidades inmediatas).
· Las consultas complejas pueden ser difíciles de cubrir.
· El rediseño de archivos impacta en los procesos.
· Se dispone de datos redundantes lo que hace muy difícil el mantenimiento.
Bases de Datos
Constituye una fuente central de datos significativos.
DBMS (Database Management System): es el sistema de creación, modificación y actualización de la BD, como así también la recuperación de información y emisión de reportes.
Los objetivos de eficacia perseguidos son:
· Asegurar que los datos puedan ser compartidos por los usuarios.
· Permitir que el mantenimiento de los datos sea preciso y consistente.
· Asegurar que todos los datos requeridos, presentes y futuros, se encuentren disponibles.
· Permitir la evolución y adaptación a las necesidades de los usuarios.
· Permitir que los usuarios desarrollen su visión de los datos, sin preocuparse del almacenamiento físico.
Ventajas
· Los datos se almacenan una sola vez, favoreciendo la integridad de los datos.
· Mayor probabilidad de encontrar disponible los datos.
· Mayor flexibilidad.
Desventajas
· Todos los datos se encuentran un solo lugar por lo que se tornan más vulnerables, y por lo tanto deben adoptarse mayores medidas de seguridad.
· Menor eficiencia en tiempos de inserción, actualización, eliminación y recuperación de datos.
Tipos de archivos
Los archivos pueden clasificarse de diversas maneras:
· Persistencia:
· Tiempo indefinido
· Temporales
· Archivos Maestros: 
Mantienen registros permanentes para entidades principales del sistema. Se produce sobre estos archivos una actualización permanente de atributos.
Ejemplo: PACIENTES, PERSONAL, INVENTARIO, ALUMNOS, etc..
· Archivos tablas:
Contiene datos utilizados para calcular otros datos.
Ejemplo: IMPUESTOS DGI (IVA), TARIFA POSTALES, CODIGOS POSTALES, etc..
· Archivos de transacciones:
Contiene cambios para la actualización de archivos maestros, es decir modificaciones a estos archivos.
Ejemplo: Novedades de salarios personal, Actualización de datos de Personal, etc..
· Archivos de trabajo (work-file):
Son archivos, generalmente temporales, utilizados para unificar información tomada de otros archivos, con el objeto de facilitar el procesamiento de los datos conjuntos.
Ejemplo: Unir en un archivo información de facturas de ventas y notas de crédito, para reportarlas ordenadas por fecha de comprobante.
· Archivos de impresión:
Mantienen imágenes de salidas de impresión en soportes magnéticos, para su impresión posterior.
Estos archivos permiten una visualización de la salida a través de editores de texto para analizar su contenido.
Son utilizados también para que la impresión se realice en otras instalaciones.
Organización de archivos
Una clasificación posible de los archivos de acuerdo a su organización, es:
· Secuenciales
· Listas enlazadas
· Archivos dispersos (acceso directo)
· Indexada
· Indices secuenciales
· Bases de Datos
De los tipos expuestos nos interesan particularmente las “Bases de Datos”, los otros tipos pueden consultarse en la bibliografía sugerida.
Organización de Bases de Datos (BD)
Una Base de Datos provee de control centralizado de los datos a través de la función de administración de datos.
Los objetivos perseguidos al utilizar BD son:
· Reducción de la redundancia.
· Prevención de inconsistencias (ejemplo: las fechas son siempre dd/mm/aaaa).
· Acceso compartido.
· Imposición de normas.
· Imposición de restricciones de seguridad.
· Integridad de los datos.
· Independencia de los almacenamientos.
La función de administración de datos implica:
· Decidir el contenido de información (DER).
· Decidir la estructura de almacenamiento y la estrategia de acceso.
· Mantener las visiones que los usuarios requieren.
· Definir controles de acceso y procesos de validación.
· Definir una estrategia para recuperación y respaldo ante catástrofes.
· Monitorear el comportamiento de la BD.
· Ajustar la estructura ante cambios.
El proceso de generación de la BD:
Análisis		 MODELO CONCEPTUAL (ERD)
Diseño 	 MODELO LÓGICO (BD, Diccionario de Datos detallado)
Implementación MODELO FÍSICO (Archivos y registros)
Definición del contenido de los almacenamientos de datos
Para definir el contenido de los almacenamientos se presentan dos enfoques:
· Tomando de los DFD y los DD lo que entra y lo que sale.
· Análisis por dato.
Normalización
Términos utilizados
Una estructura de datos se denominan relación en el sentido que relaciona elementos de datos.
Un elemento de datos se denomina dominio, debido a que establece un rango de valores que puede tomar un elemento de datos dado.
Un registro individualde una estructura de datos se denomina tupla.
Cada registro debe tener una única clave mediante la cual puede identificarse unívocamente. Esta clave puede ser simple o concatenada (compuesta por varios atributos).
Convención para representar una relación: 
· Nombre-relacion = @dominio-clave + dominio-1 + dominio-2 + …….
=	está compuesto de o es equivalente a 
+	Y o en conjunción con 
( )	atributo Opcional
{ }	Repetición de los atributos abarcados
[ ]	Seleccionar una de las Alternativas
|	Separador de alternativas en una construcción [ ] 
**	Delimitador de comentario
@	Atributo(s) clave en una estructura compuesta
· Nombre-relación (dominio-clave, dominio-1, dominio-2, ……)
Criterios de selección de clave
1. ¿Puede suprimirse cualquier elemento de datos, y la clave remanente seguir siendo única?.
2. Existe alguna situación en que la clave pueda no ser única?
3. ¿Alguna parte de la clave candidata tiene valores indefinidos?
4. De las claves válidas, ¿cuál tiene menos componentes (dominios)?.
Dependencia funcional
En una relación un conjunto de atributos “Y” es funcionalmente dependiente de otro conjunto “X”, si cada ocurrencia de “X” está siempre asociada a la misma ocurrencia de “Y”.
La determinación de las relaciones, dominios, claves y dependencias funcionales se hace observando la realidad (documentos y/o archivos existentes).
Formas normales
Primera Forma Normal (1FN): Una entidad o relación se encuentra en primera forma normal si esta no incluye grupos repetitivos.
Dividir la entidad o relación para que esta quede sin grupos repetitivos. Asignar la menor clave que identifique unívocamente cada instancia de la estructura de datos.
Segunda Forma Normal (2FN): Para las entidades o relaciones en 1FN, y cuyas claves tengan más de un atributo, cada atributo no clave debe ser función dependiente de toda la clave, y no solo de una parte de esta.
Dividir la relación agrupando los atributos funcionalmente dependientes.
Tercera Forma Normal (3FN): Para una entidad o relación en 2FN, todos los atributos no claves son mutuamente independientes entre sí.
Suprimir atributos redundantes o dividir la relación agrupando los atributos funcionalmente dependientes.
Ejemplos: 
1) Se tiene una relación que representa el pedido de un libro realizado por un cliente.
pedido-libro = @cliente + @fecha + @isbn + titulo + autor + cantidad + precio + total-libro 
No presenta grupos repetitivos, por lo tanto ya se encuentra en primera forma normal (1FN).
Segunda Forma Normal
Se presentan dependencias funcionales entre atributos no claves y parte de la clave:
Título isbn
Autor isbn
Precio isbn
Para eliminar estas dependencias funcionales parciales, y obtener relaciones en 2FN, se divide la relación original de la forma:
pedido-libro = @cliente + @fecha + @isbn + cantidad + total-libro
libro = @isbn + titulo + autor + precio 
Tercera Forma Normal
El atributo “total-libro” puede calcularse como: cantidad * precio, entonces existe una dependencia funcional entre atributos no claves. Eliminando el atributo dependiente se elimina la dependencia, y se obtiene la 3FN:
pedido-libro = @cliente + @fecha + @isbn + cantidad
libro = @isbn + titulo + autor + precio 
2) Se realiza una variación sobre el caso anterior, permitiendo que un pedido incluya varios libros.
pedido-libro = @cliente + @fecha + {isbn + titulo + autor + cantidad + precio + total-libro} + total-pedido
Primera Forma Normal
Eliminación de grupos repetitivos.
pedido = @cliente + @fecha + total-pedido
libro-pedido = @cliente + @fecha + @isbn + titulo + autor + cantidad + precio + total-libro
Segunda Forma Normal
Verificación de dependencia funcional con toda la clave.
pedido = @cliente + @fecha + total-pedido Sin modificaciones
libro-pedido = @cliente + @fecha + @isbn + titulo + autor + cantidad + precio + total-libro
Se detecta una dependencia funcional parcial entre titulo + autor + precio e isbn. Entonces se transforma en:
Quedando la nueva estructura:
pedido = @cliente + @fecha + total-pedido Sin modificaciones
libro-pedido = @cliente + @fecha + @isbn + cantidad + total-libro
libro = @isbn + titulo + autor + precio 
Tercera forma normal
Eliminar dependencia funcional entre atributos no claves.
(1) pedido = @cliente + @fecha + total-pedido 
(2) libro-pedido = @cliente + @fecha + @isbn + cantidad + total-libro 
(3) libro = @isbn + titulo + autor + precio 
En este caso se presentan dependencias funcionales indirectas. En la relación (2) “total-libro” puede ser calculado utilizando “cantidad” y “precio” (en relación (3)), así como “total-pedido” en relación (1) puede ser calculada sumando los “total-libro” obtenidos para cada “libro-pedido”.
Eliminando estas relaciones se obtiene:
pedido = @cliente + @fecha 
libro-pedido = @cliente + @fecha + @isbn + cantidad 
libro = @isbn + titulo + autor + precio 
 
3) empleado = @nro-empleado + nombre + dirección + {fecha-cambio + tarea + salario + revisión}
Primera Forma Normal
empleado = @nro-empleado + nombre + dirección 
salario-historia = @nro-empleado + @fecha-cambio + tarea + salario + revisión
Cumple segunda y tercera forma normal.
4) PROYECTO (COD-PROYECTO, TIPO-PROYECTO, DESCRIPCION, (NRO-EMPLEADO, NOMBRE, CATEGORÍA, SALARIO, FECHA-INICIO, TIEMPO-ASIGNADO))
Primera Forma Normal (PFN):
Se elimina el grupo repetitivo interno a PROYECTO, dividiendo la relación en dos nuevas relaciones.
PROYECTO (COD-PROYECTO, TIPO-PROYECTO, DESCRIPCION)
PROY-EMPL (COD-PROYECTO, NRO-EMPLEADO, NOMBRE, CATEGORÍA, SALARIO, FECHA-INICIO, TIEMPO-ASIGNADO)
Para la nueva tabla PROY-EMPL se selecciona como clave única de identificación a los atributos COD-PROYECTO (clave primaria de la relación externa de la cual deriva) y NRO-EMPLEADO (identificación unívoca de cada empleado). De esta manera se refleja el hecho de que un empleado puede estar asignado a múltiples proyectos.
Segunda Forma Normal (SFN):
Toda tabla en PFN con clave primaria compuesta de un atributo solamente está en SFN.
La relación PROYECTO al tener un clave primaria compuesta por un único atributo está en SFN.
Analizando la relación PROY-EMPL podemos ver :
Nombre : para conocer el nombre de un empleado sólo es necesario saber cual es su NRO-EMPLEADO. Por lo tanto el atributo NOMBRE depende funcionalmente solo de NRO-EMPLEADO, y no de la clave completa.
Categoría : para conocer la categoría de un empleado sólo es necesario saber cual es su NRO-EMPLEADO. Su categoría no cambia en los distintos proyectos. Por lo tanto el atributo CATEGORÍA depende funcionalmente solo de NRO-EMPLEADO, y no de la clave completa.
Salario : para conocer el salario de un empleado sólo es necesario saber cual es su NRO-EMPLEADO. El salario de un empleado no cambia de acuerdo al proyecto en el que esté trabajando. Por lo tanto el atributo SALARIO depende funcionalmente solo de NRO-EMPLEADO, y no de la clave completa.
Fecha-Inicio : para conocer la fecha en que un empleado comenzó a trabajar en un proyecto es necesario saber cual es su NRO-EMPLEADO y de qué proyecto (COD-PROYECTO) se trata. Por lo tanto el atributo FECHA-INICIO depende funcionalmente de la clave completa.
Tiempo-Asignado : para conocer el tiempo que se ha asignado a un empleado a trabajar en un proyecto es necesario saber cual es su NRO-EMPLEADO y de qué proyecto (COD-PROYECTO) se trata. Por lo tanto el atributo TIEMPO-ASIGNADO depende funcionalmente de la clave completa.
De acuerdo a esto, se observan atributos que dependen funcionalmente de sólo una parte de la clave de identificación. Por esto se divide la relación PROY-EMPL en dos nuevas relaciones :
PROY-EMPL ( COD-PROYECTO, NRO-EMPLEADO, FECHA-INICIO, TIEMPO-ASIGNADO )
EMPLEADO ( NRO-EMPLEADO, NOMBRE, CATEGORÍA, SALARIO )
Para la nueva relación EMPLEADO se ha seleccionado como clave primaria a NRO-EMPLEADO, que era la parte de la clave primaria de la relación original, de la cual dependían los atributos NOMBRE, CATEGORÍA y SALARIO.
Tercera Forma Normal (TFN):
Toda tabla en SFN que posee menos de dos atributos no claves ya se encuentraen TFN.
Analizando la relación PRY-EMPL, podemos observar que la única relación dependencia entre atributos no claves puede darse entre los atributos FECHA-INICIO y TIEMPO-ASIGNADO, pero esta no existe debido a que ninguno de los dos atributos puede obtenerse a partir del otro. Por lo tanto la relación PRY-EMPL está en TFN.
En el caso de la relación EMPLEADO, podemos ver que entre los atributos CATEGORÍA y SALARIO puede establecerse una dependencia funcional, debido a que el salario de un empleado puede determinarse de acuerdo a la categoría del mismo. Entonces la relación EMPLEADO no está en TFN. Para obtener la TFN es necesario dividir la relación en dos nuevas relaciones :
EMPLEADO ( NRO-EMPLEADO, NOMBRE, CATEGORÍA ) 
CATEGORÍA ( CATEGORÍA, SALARIO )
En la relación EMPLEADO se mantiene el atributo CATEGORÍA que es el que permite obtener el SALARIO de un empleado (a través de la relación CATEGORÍA). En tanto que para la nueva relación CATEGORÍA, se selecciona el atributo CATEGORÍA que es el atributo cuyo dominio no tiene entradas duplicadas. 
Entonces la relación no normalizada :
PROYECTO (COD-PROYECTO, TIPO-PROYECTO, DESCRIPCION, (NRO-EMPLEADO, NOMBRE, CATEGORÍA, SALARIO, FECHA-INICIO, TIEMPO-ASIGNADO))
En TFN es :
PROYECTO (COD-PROYECTO, TIPO-PROYECTO, DESCRIPCION)
PROY-EMPL ( COD-PROYECTO, NRO-EMPLEADO, FECHA-INICIO, TIEMPO-ASIGNADO )
EMPLEADO ( NRO-EMPLEADO, NOMBRE, CATEGORÍA ) 
CATEGORÍA ( CATEGORÍA, SALARIO )
La importancia de la normalización
Las estructuras de datos normalizadas proveen de :
· Reducción de la redundancia de datos.
Se minimiza la cantidad de información que se necesita mantener para resolver un problema concreto.
· Se obtienen representaciones de datos más simples.
· Las representaciones tabulares facilitan la comprensión de las estructuras.
· Las estructuras de datos son más flexibles y fáciles de cambiar.
· Existe una relación directa con los DBMS relacionales.
· La calidad de los modelos de datos obtenidos aplicando Diagramas de Entidad Relación deben cumplir con los conceptos de normalización, para ser considerados modelos con calidad (el modelo puede ser utilizado para implementar directamente una base de datos relacional).
Discusiones sobre la normalización
El concepto de tercera forma normal se aplica a todas las bases de datos.
Las objeciones a la tercera forma normal son generalmente dirigidas a que esta requiere mayor espacio de almacenamiento o más tiempo de máquina. Es cierto que la tercera forma normal genera más registros (entidades) luego de las divisiones, pero esto no implica necesariamente mayor espacio de almacenamiento, por el contrario contra formas no normalizadas ocupa menos espacio. La razón es generalmente las formas no normalizadas tienen mucha más redundancia de valores.
En cuanto al tiempo de procesamiento, generalmente es menor después de la normalización. Antes de la normalización muchos aspectos de los datos se encuentran juntos y deben ser leídos todos a la vez. Después de la normalización, estos se encuentran separados, y solo pequeños registros deben ser leídos.
Por otra parte, al haber menor redundancia de datos, hay menos actualizaciones duplicadas de los valores redundantes.
No obstante, en ciertas ocasiones, debe optarse por estructuras que no están en tercera forma normal para obtener mayor performance. En estos caso la decisión es del diseñador y debe estar perfectamente justificada.
Integración de visiones
El modelo obtenido aplicando normalización a cada archivo o documento del dominio del problema, representa visiones particulares del modelo de datos completo del sistema.
Para obtener el modelo de datos completo de la base de datos es necesario integrar las diferentes visiones obtenidas de los distintos archivos o documentos. En este proceso de integración deben tenerse las siguientes consideraciones :
· Consiste en juntar todas las tablas que tengan una misma clave primaria, es decir, diferentes visiones de una misma entidad o relación.
· En este proceso de integración pueden presentarse inconvenientes con los homónimos (diferentes atributos o tablas poseen un mismo nombre) y sinónimos (un mismo atributo o tabla aparece con diferentes nombres) entre las tablas y atributos representados.
· Pueden presentarse tablas que a pesar de tener claves primarias con el mismo nombre, representan conjuntos diferentes de entidades (o relaciones) que tienen atributos diferentes. Ejemplo : proveedores y clientes identificados a través de su CUIT.
· Al hacer la integración es posible volver a obtener visiones en SFN, entonces se deben verificar las nuevas visiones.
Ejemplo:
Visión número 1
PROY (CODPROY, TIPOPROY, DESCR)
PROYEMP (CODPROY, NUEMP, FECHAINICIO, TIEMPOASIG)
EMP (NUEMP, NOMBRE, CAT)
CAT (CAT, SAL)
Visión número 2
EMP (NUEMP, NOMBRE, CODDEP)
DEPTO (CODDEP, NOMBRE)
Visión número 3
PROY (CODPROY, DESCR, FECHAINICIO)
PROYEQUIP (CODPROY, NUEQUIP, FECHAINICIO, TIEMPOASIG)
EQUIP (NUEQUIP, DESCR)
Base de Datos integrada
PROY (CODPROY, TIPOPROY, DESCR, FECHAINICIO)
PROYEMP (CODPROY, NUEMP, FECHAINICIO, TIEMPOASIG)
EMP (NUEMP, NOMBRE, CAT, CODDEP)
DEPTO (CODDEP, NOMBRE)
CAT (CAT, SAL)
PROYEQUIP (CODPROY, NUEQUIP, FECHAINICIO, TIEMPOASIG)
EQUIP (NUEQUIP, DESCR)
Análisis de consultas sobre los datos
Los requerimientos de información a partir de los datos disponibles, tienen factores distintivos, a pesar de la diversidad de consultas que pueden producirse :
1. Predecibilidad en el tiempo.
¿La consulta puede ser programada con anticipación ?
“Todas las mañanas a las 9 horas debe generarse un listado con todos los pedidos recibos el día anterior.”
¿La consulta es activada por algún evento predecible ?
“Cada vez que el nivel de stock de un artículo llegue a estar debajo del nivel de stock mínimo del mismo, generar un reporte con el estado de las órdenes de pedido de compra para el mismo. Este reporte debe estar disponible, a más tardar, a las 8 horas del día siguiente.”
¿La consulta es a pedido ?
“¿Cuántas veces en los últimos seis meses el proveedor “XXX” dejó cumplir con las fechas de entrega prometidas ?”.
En cualquier caso, ¿qué volumen de transacciones se puede predecir ?.
2. Naturaleza del requerimiento.
Mientras los requerimientos programables y activables son predecibles por definición, los requerimientos exigibles pueden variar ampliamente tanto en los elementos de datos que necesitan, como en el procesamiento necesario para estos elementos de datos.
“¿Cuántas veces en los últimos seis meses el proveedor “XXX” dejó cumplir con las fechas de entrega prometidas ?. Lo tengo al teléfono.”.
“Necesito un informe que muestre qué porcentaje de nuestro presupuesto en los últimos cinco años financieros se realizó con firmas por menos de $ 100.000 anuales. Tengo que presentar un informe el mes próximo.”.
“Deme los nombres y teléfonos particulares de todos nuestros ingenieros electrónicos que hablen bien árabe, que hayan atendido el modelo X-25 y que no estén asignados a proyectos urgentes. Destacar los solteros. Listarlos por orden de antigüedad, y en forma urgente. Esta tarde debe partir uno a Arabia Saudita.”.
3. Antigüedad de los datos.
¿Cuán reciente o frescos deberán ser los datos ?. ¿Será suficiente tener su valor correcto al finalizar el último mes, o será necesario que esté correcto hasta la última transacción realizada ?.
4. Tiempo de respuesta
¿Cuán rápidamente deberá ser atendido el requerimiento ?.
Todos estos aspectos deberán ser tenidos en cuenta cuando se diseñe las estructuras físicas de los almacenamientos de datos.
Tanto la velocidad de respuesta como los datos disponibles serán puntos críticos que deberán ser contemplados con especial cuidado, analizando los accesos inmediatos a los datos. Todos los requerimientos plantean una complejidad y costo de diferente magnitud.
Otros aspectos que deberán ser contemplados son la seguridad (quién está autorizado a realizar requerimientos y/o a recibir la respuesta) y la importancia que para el negocio tiene este requerimiento (si es “bueno tenerlo” o si se “debe tener”).
Los temassobre predecibilidad, acceso inmediato y lo reciente del dato son las claves que más afectan al costo y la utilidad del sistema.
image3.wmf
Persona
ALUMNO
PROFESOR
FUNCIONARIO
(t,s)
oleObject3.bin
ALUMNO
FUNCIONARIO
PROFESOR
Persona
(t,s)
image1.wmf
Entidades
Registro de
eventos
Definición de
registros
Atributos
Datos de
eventos
Definición de
los datos
oleObject1.bin
�������������������
Entidades
Registro de eventos
Definición de registros
Atributos
Datos de eventos
Definición de los datos
image2.wmf
VENDEDOR
VENTA
CLIENTE
ARTICULO
ITEM 
VENTA
1
n
n
n
1
n
cantidad
Prec. Unit.