ANLISIS DE REQUERIMIENTOS
Etapa en que se estudian los requisitos para verificar que sean adecuados a lo solicitado por los usuarios. En la misma se enfocan e intentan solucionar las deficiencias que los requisitos puedan tener.
PLANEACIN ESTRATGICA
Planeacin Qu se quiere lograr? Planeacin Estratgica Qu se quiere lograr?
+
Cmo se va a lograr?
DICCIONARIO DE DATOS
Consiste de un conjunto de metadatos (datos sobre los datos) sobre los datos utilizados o producidos por el sistema:
Tambin se puede incluir otro tipo de informacin como: la fecha de creacin, el creador,
La
INDEPENDENCIA
Independencia LGICA: Ocurre cuando se modifica el esquema conceptual sin afectar al resto de los esquemas. Se modifica el esquema conceptual cuando cambian las caractersticas de los datos a almacenar. Cambio en datos no implica cambio en programas y viceversa. Independencia FSICA: Se presenta cuando es posible la modificacin del esquema fsico sin afectar a los esquemas restantes. Las principales razones para llevar a cabo una modificacin de ste tipo son: un ajuste en el hardware de almacenamiento o una redistribucin de los datos en l. Cambio fsico no implica cambios en la estructura de los datos.
OBJETIVO
Un modelo de datos es un conjunto de herramientas conceptuales para describir los datos, las relaciones entre ellos, su semntica y sus limitantes. El objetivo es definir las estructuras lgicas de almacenamiento y las relaciones que se darn entre ellas. Ejemplos comunes son el diseo de los registros y las ligas que permitirn la conexin entre registros.
Entidad. Objeto real o abstracto sobre el que se tiene informacin, pueden ser: personas, lugares, cosas o eventos.
Smbolo:
NombreEntidad
Tipos de entidades:
Regular o fuerte: Las instancias de este tipo tienen existencia por s mismas en el universo de estudio independientemente de cualquier otro conjunto de entidades. Dbil: Las instancias de este tipo dependen de un conjunto de entidades existente en el universo, al desaparecer este conjunto superior, desaparecern todas los conjuntos de entidades dbiles vinculadas al mismo.
Entidad
Entidad dbil
Banco
Tiene
Sucursal
Nombre
Edad
Persona
NombreAtributo
Nacionalidad
aquellos que deben tomar un valor y no se permite que alguna entidad no tenga un valor en el atributo.
Edad 26
Persona Salvadorea
Nacionalidad
aquellos que deben tomar un valor y no se permite que alguna entidad no tenga un valor en el atributo.
Edad 26
Persona Salvadorea
Nacionalidad
aquellos atributos que pueden tener valores o no tenerlos. Posiblemente nulo (ausencia de valor).
nulo Telfono Edad 26
Persona
Salvadorea Nacionalidad
aquel atributo que slo puede tener un nico valor. Ejemplo: Edad.
Persona
Salvadorea Nacionalidad
aquellos atributos que pueden tener varios valores. Ejemplo: Telfono. Smbolo: 0445512345678
Atributo 56061234
Telfono
Edad 26
Edad
Mes Da
Ao
Fecha de nacimiento
Atributo
Casada R con
Mdico Persona E
atiende R
Paciente E
E Materia
R Obtiene
E Evaluacin
E Estudiante
Una interrelacin puede ser recursiva, si relaciona un conjunto de entidad consigo mismo.
Empleado
Supervisa
Empleado
Supervisa
Supervisor
Uno a uno
Tiene a1 b1
a2
b2
a3 Municipio
b3 Ayuntamiento
Uno a muchos:
Conformada por a1 b2 a2 b3 a3 b4 b5 Departamento b1
Empresa
Muchos a uno
Pertenece a
a1 b1
a2
a3
b2
a4
b3
a5
Empresa
Sucursal
Muchos a muchos
Atiende a a1 b1
a2
b2
a3
b3
a4
Profesor
b4 Estudiante
Atributo
Interrelacin
Semestre
Profesor
Imparte
Asignatura
SIMBOLOGA
Cardinalidad Chen 1 1 N
SIMBOLOGA
Chen
Obligatoria Obligatoria Obligatoria
Opcional
No existe
Opcional
Opcional
Obligatoria
Opcional
Nombre completo
Nombre
Horario
Estudia
Asignatura
Edad
DISEO DE BDS
El
primer paso en el diseo de una base de datos es la produccin del esquema conceptual. Cada esquema conceptual (VISTAS) representa las distintas visiones que los usuarios tienen de la informacin. nociones de conjunto de entidades y conjunto de interrelaciones no son precisas.
Las
Es
posible definir un conjunto de entidades y las interrelaciones entre ellas de diferentes formas.
DISEO DE BDS
Examinar
los diagramas de flujo de datos, que se pueden haber producido previamente, para identificar cada una de las reas funcionales. a los usuarios, examinar los procedimientos, los informes y los formularios, y tambin observar el funcionamiento de la empresa.
Entrevistar
DISEO DE BDS
1.
2.
3.
4. 5. 6. 7.
8.
Identificar los conjuntos de entidades. Identificar los conjuntos de relaciones. Identificar los atributos y asociarlos a entidades y relaciones. Determinar los dominios de los atributos. Determinar los identificadores. Determinar las jerarquas de generalizacin. Dibujar el diagrama entidad-relacin. Revisar el esquema con el usuario.
PROCESO DE NORMALIZACIN
Puede considerarse como un proceso de anlisis de las relaciones para alcanzar las propiedades deseables de:
FORMAS NORMALES
1FN 2FN 3FN FNBC 4FN
(1974) Forma normal Boyce Codd, mejora la 3NF No fueron definidas por Codd, sino por R. Fagin (1977 y 1979, respectivamente) Formas normales bsicas, expuestas por Codd en 1972
5FN
FORMAS NORMALES
1FN 2FN 3FN FNBC 4FN
Basadas en la dependencia multivaluada y dependencias de reunin respectivamente.
La dependencia funcional entre atributos forma la base de las tres formas normales originales de Codd, as como de la FNBC.
5FN
Formas Normales
El procedimiento es reversible, es posible tomar los resultados del procedimiento y transformarlos de nuevo a su origen. La reversibilidad es importante, ya que significa que el proceso de normalizacin conserva la informacin. El procedimiento de descomposicin implica separar o descomponer una determinada variable relacin en otras y adems requiere que la descomposicin sea reversible, de tal forma que no se pierda informacin en el proceso: Descomposicin sin perdida.
EJEMPLO
Variable relacin proveedores (V)
Posibles descomposicione s
El proceso de descomposicin es en realidad un proceso de proyeccin, VST, VC y STC son proyecciones de la variable relacin original V.
Note: en el caso (a) no se perdi informacin, si juntamos de nuevo VST y VC, regresamos a la V original. En contraste, si juntamos de nuevo VST y STC del caso (b), no regresamos a la V original y por lo tanto hemos perdido informacin. La "reversibilidad" significa precisamente que la variable relacional original es igual a la junta de sus proyecciones. De ah que, como proyeccin es el operador de descomposicin para la normalizacin, entonces el operador de recomposicin es el de junta.
1FN
Una relacin est en primera forma normal (1FN) si y slo si todos los dominios de los atributos incluyen valores atmicos. Un dominio es atmico si los elementos del dominio son simples e indivisibles. Se considera que una relacin se encuentra en 1FN cuando cumple lo siguiente:
Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Cada columna debe tener un nombre nico, el orden de las columnas en la tabla no es importante. Dos filas o renglones de una misma tabla no deben ser idnticas, aunque el orden de las filas no es importante.
EJEMPLO 1FN
V# CANT P#
Ciudad Status
Para ilustrar algunas de las dificultades que surgen, se muestra lo siguiente. La redundancia es obvia. Toda tupla de V1 muestra la ciudad como Londres; en forma similar, toda tupla de la ciudad de Londres muestra el status 20.
Insert. No podemos insertar el hecho de que un proveedor en particular est ubicado en una ciudad en particular hasta que ese proveedor suministre por lo menos una parte.
Delete. Si eliminamos la nica tupla de un proveedor en particular, no slo eliminamos el envio que conecta a ese proveedor con alguna parte en particular sino tambin la informacin de que un proveedor esta ubicado en una ciudad en particular. Update. Si el proveedor V1 se cambia de Londres a Alemania, nos enfrentamos al problema de examinar para encontrar todas las tuplas que conectan V1 con Londres (y cambiarlo), o bien la posibilidad de producir un resultado inconsistente.
Alemania
Redundancia de informacin
2FN
Una relacin R est en 2FN si y solo si est en 1FN y los atributos no primos (no llaves, no claves) dependen funcionalmente de la llave primaria (clave). Dependencia funcional: Que atributos dependen de otro(s) atributo(s).
De acuerdo con est definicin, cada relacin que tiene un atributo nico como clave, esta en segunda forma normal.
EJEMPLO 2FN
Ciudad V# Status
P# V#
CANT
Esta estructura supera todos los problemas con operaciones de actualizacin antes mencionados.
Cada valor de V# determina un valor de Ciudad y a su vez, cada valor de ciudad determina el valor de Status
DFs AB y BC, entonces AC
Una relacin 2FN puede presentar anomalas de almacenamiento si cualquiera de sus no-claves depende transitivamente de la clave primaria. Se dice que una no-clave depende transitivamente de la clave primaria si es funcionalmente dependiente de otra no-clave, en otras palabras, depende indirectamente de la clave principal
Insert. No podemos insertar el hecho de que una ciudad tiene un estatus en particular; por ejemplo, no podemos declarar que cualquier proveedor de Roma debe tener un estatus de 50, hasta que tengamos un proveedor ubicado en esa ciudad. Delete. Si eliminamos de SEGUNDA la nica tupla de una ciudad en particular, no slo eliminamos la informacin del proveedor respectivo, sino tambin el status de esa ciudad. Update. El status de una determinada ciudad aparece muchas veces en SEGUNDA (contiene cierta redundancia). Si necesitamos cambiar el status para Londres de 20 a 30, nos enfrentamos al problema de examinar SEGUNDA para encontrar todas las tuplas o la posibilidad de producir un resultado inconsistente.
50
Roma
2FN - PROCEDIMIENTO
Tomar proyecciones para eliminar las dependencias funcionales no irreducibles y se reemplaza R por sus proyecciones R1 y R2
3FN
Est en 3FN si esta en 2FN y ningn atributo no-clave en la relacin es funcionalmente dependiente de algn otro atributo no-clave. Si los atributos que no son claves son:
a.
b.
Mutuamente independientes (ninguno de ellos es dependiente funcional de cualquier combinacin de los otros implica que cada atributo puede ser actualizado independientemente del resto), y Dependientes irreduciblemente sobre la clave primaria (Dos o ms atributos son mutuamente independientes si ninguno de ellos es dependiente funcionalmente de cualquier combinacin de los otros).
EJEMPLO 3FN
La variable relacin P est en 3FN. Los atributos Parte, Color, Peso y Ciudad son todos independientes entre s (es posible, cambiar el Color de una parte sin tener que cambiar al mismo tiempo su peso) y todos son dependientes irreducibles de la clave primaria {P#} Cada tupla de P consiste en un valor de clave primaria que identifica a cierta parte de la realidad, junto con 4 valores adicionales, cada uno de los cuales sirve para describir la parte y es independiente de los dems.
Ciudad
Ciudad
Ciudad
Status
Esta estructura supera todos los problemas con operaciones de actualizacin antes mencionados. Incluimos la
informacin de status para Roma
PROCEDIMIENTO (3FN)
El paso consiste en tomar proyecciones para eliminar las dependencias transitivas. En otras palabras, dada una variable relacin R como sigue: R { A, B, C } PRIMARY KEY { A } la disciplina de la normalizacin recomienda reemplazar R por dos proyecciones R1 y R2, como sigue:
R1 { B, C} PRIMARY KEY { B }
R2 { A, B} PRIMARY KEY { A } FOREING KEY { B } REFERENCES R1 R puede ser recuperada tomando la junta de clave externa a la clave primaria de R2 y R1.
EJERCICIO 1
Tomar como base el archivo Ejercicio_Normalizacion.xlsx y entregar por equipo, a mano la normalizacin a 1FN, 2FN y 3FN
El ms grande problema con ir ms all de la 3FN son la complejidad y caractersticas de desempeo. Actualmente mucha granularidad introduce complejidad, especialmente en una base de datos relacional.
Formas extremas de reduccin no son de beneficio para los modelos de base de datos relacional.
Cuanta ms normalizacin en una BD relacional, mayor es el nmero de tablas. El aumentar el nmero de tablas vuelve ms grandes las consultas join de SQL. El agrandar los join empobrece el desempeo de la base de datos. Niveles extremos de granularidad en una BD relacional son una forma de perfeccin matemtica.
Dejamos la suposicin de que toda variable relacin tiene una sola clave candidata. La definicin de Codd de la 3FN no trataba adecuadamente el caso de una variable relacin que: Tena dos o ms claves candidatas, tales que, Las claves candidatas estaban compuestas, y Se traslapaban (es decir, tenan al menos un atributo en comn). La FNBC atiende estos casos.
Determinante: Uno o ms atributos que, de manera funcional, determinan otro atributo o atributos. En la dependencia funcional (A,B)-->C, (A,B) son los determinantes.
Una variable relacin esta en FNBC si y solamente si toda DF no trivial, irreducible a la izquierda, tiene una clave candidata como su determinante.
Definicin informal: Una relacin R esta en FNBC si y slo si los nicos determinantes son claves candidatas.
EJEMPLO FNBC
V# Proveedor
Status Ciudad
Consideremos un ejemplo que involucra dos claves candidatas inconexas; es decir que no se traslapan. {V#} y {Proveedor}, durante todo el tiempo se da el caso de que todo proveedor tiene un nmero de proveedor nico y tambin un nombre de proveedor nico. Demos el hecho de que los atributos status y ciudad son independientes mutuamente; es decir, ya no es valida la DF CIUDAD STATUS V est en FNBC, dndose el caso que los nicos determinantes son claves candidatas; es decir, las nicas flechas son las que parten de claves candidatas.
Consideremos un ejemplo en el que las claves candidatas se traslapan. Dos claves candidatas se traslapan si cada una involucra dos o ms atributos y tienen por lo menos un atributo en comn. Consideremos VVP {V#, PROVEEDOR, P#, CANT}, en donde, las claves candidatas son {V#, P#} y {PROVEEDOR, P#} No est en FNBC, ya que contiene dos determinantes, V# y PROVEEDOR, que no son claves candidatas para la variable relacin. La solucin es dividir la variable relacin en dos proyecciones.
VV {V#, PROVEEDOR} VP {V#, P#, CANT}
3FN
VS
FNBC
La
3FN vs FNBC
Aplicando un JOIN a R1 y R2, comprobamos que existe una descomposicin sin perdidas, que nos lleva a R.
Pero es necesario observar, que la DF1 se perdi, siendo este el principal problema de Boyce-Codd.
EJERCICIO 2
Tomar como base el ejercicio 1 y entregar por equipo, a mano la normalizacin a FNBC.