Clase Jueves

UML 2.0 Diagramas a utilizar en el proyecto

UML

Diagramas de UML 1.x

Diagramas de UML 2.0

Diagrama de Paquetes 



Permite dividir un sistema grande en unidades más pequeñas. Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Paquete 1

Paquete 2

Casos de uso 

Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa con los usuarios.

Diagrama de Secuencia 

Muestra una interacción ordenada según la secuencia temporal de eventos.

Diagrama de estados 



Muestra la secuencia de estados por los que pasa un caso de uso, un objeto a lo largo de su vida, o todo el sistema. Controla la forma con la que el usuario se introduce al sistema.

Diagrama de distribución (despliegue) 

Muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

Diagrama de actividad 

Muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que corresponde con la consecución de un proceso más complejo.

Diagrama de Componentes 



Los diagramas de componentes describen los elementos físicos del sistema y sus interrelaciones. Los componentes representan todos los tipos de elementos de software que entran en la fabricación de aplicaciones informáticas.

Transaccione s

Actualizar_transaccione s

búsqueda

Consultas /reportes

Reservas

Diagrama de Clases 





Es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus interrelaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones.

Diagrama de Objetos 

El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones.

Nuevos diagramas en UML 2.0 

Diagramas de Tiempos. Empleados para mostrar las interacciones donde el propósito fundamental consiste en razonar sobre la ocurrencia de eventos en el tiempo que provocan el cambio de estados de un elemento estructural (clase, componente, etc.).

Nuevos diagramas en UML 2.0 

Diagrama de Comunicación. Equivalente al diagrama de colaboración del OMG UML 1.x. Permite especificar interacciones entre objetos que conforman la estructura interna de un clasificador.

Diagrama de colaboración 



Es una forma de representar interacción entre objetos. El diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.

Nuevos diagramas en UML 2.0 

Diagrama de Estructura Compuesta. Se emplea para visualizar de manera gráfica las partes que definen la estructura interna de un clasificador.

Nuevos diagramas en UML 2.0 

Diagrama General de Interacción. Se emplea fundamentalmente para representar las interacciones, a través de diagramas o fragmentos de diagramas de secuencias, entre los actores y el sistema como una gran caja negra, y de diagramas de actividades en los que aparecen dichos fragmentos.

Modelado conceptual de objetos mediante UML 

Para el diseño de una base de datos se pueden utilizar los diagramas de 



Casos de uso: para el análisis de la base de datos, examinando roles de los usuarios y operaciones a realizarse con la base de datos. Diagrama de clases: para el diseño conceptual de la base de datos.

Caso Práctico 

A realizar en clases

DISEÑO DE BASES DE DATOS

NORMALIZACION DE BASES DE DATOS

CONCEPTO GENERALES LLAVE 

LLAVE/CLAVE.- Conjunto de uno o mas atributos que identifican una tupla y asi a su vez determinan a otros atributos. Ej. No. Factura determina fecha, cliente, etc.



SUPERCLAVE.- Es cualquier llave que identifica de manera única cada entidad. La superclave determina funcionalmente a todos los demás atributos de una entidad.

TABLA STUDENTS

STU_NU M

STU_LNAM E

STU_FNAME

STU_INIT

STU_CLASS

STU_D EPT

STU_PHO NE

324274

Katinga

Raphael

P

21/10/1976

114

SR

ACCT

2267

228

324291

Robertson

Gerald

T

08/04/1970

120

SR

EDU

2267

311

324299

Smith

John

B

30/11/1983

15

FR

ACCT

2315

230

321452

Bowser

William

C

12/02/1972

42

SO

BIOL

2134

205

324257

Smithson

Anne

K

15/11/1977

81

JR

CIS

2256

222

324558

Brewer

Juliette

23/08/1966

36

SO

ACCT

2256

228

324269

Oblonski

Walter

H

16/09/1973

66

JR

CIS

2114

222

324273

Smith

John

D

30/12/1955

102

SR

ENGL

2231

199

STU_DOB

STU_HRS

Por ejemplo en la estructura de la tabla Students la superclave puede ser cualquiera de las siguientes: STU_NUM STU_NUM,STU_LNAME STU_NUM,STU_LNAME, STU_INIT STU_NUM por si solo puede ser una superclave. Se dice que los atributos adicionales son redundantes.

STU_PROF

STU_NAME=321452 determina o define los atributos del estudiante : STU_LNAME=Bowser STU_FNAME=William STU_INIT=C STU_DOB=12/02/1972 Etc, etc

•LLAVE/CLAVE CANDIDATO.- Es una superclave sin redundancias. Otra definición sería “es una superclave mínima” que indentifica una entidad. Por ejemplo la combinacion STU_NUM, STU_LNAME no es una clave candidata por que STU_NUM por si solo identifica la entidad, pero si es una SUPERCLAVE.

STU_LNAME,STU_FNAME,STU_INI, STU_PHONE Es una clave candidata siempre y cuando se deseche la posibilidad de que dos estudiantes o más puedan compartir el mismo apellido, primer nombre, inicial y numero de teléfono. •CLAVE PRIMARIA (LLAVE).- Es una clave candidata seleccionada para identificar de manera única a una entidad (INTEGRIDAD DE IDENTIDAD) y a todos los atributos en la fila. No puede contener entradas nulas (NULL).

•CLAVE SECUNDARIA.- Un atributo o combinación de atributos utilizado estrictamente para propositos de recuperación de datos. Esta llave no necesariamente da un resultado único. •CLAVE EXTERNA (FORANEA).- Un atributo o combinación de atributos en una tabla cuyos valores deben igualar a el valor de la llave primaria en otra tabla (INTEGRIDAD REFERENCIAL).

DEPENDENCIA FUNCIONAL   

  

LLAVE COMPÙESTA. Formada por un conjunto de atributos ATRIBUTO DE LLAVE. Cualquier atributo que forme parte de la llave. DETERMINACION O DEPENDENCIA. En el contexto de una tabla de base de datos la expresión “A determina B” indica que si se conoce el valor del atributo A se puede determinar el valor de B. Ej. Si de conoce STU_NUM en la tabla STUDENTS se puede determinar el apellido de ese estudiante, su telefono, su departamento, etc. La notación taquigráfica para “A determina B” es A--->B. Si A determina B,C y D, entonces AB,C,D. Por lo tanto, con los atributos de la tabla STUDENTS se puede expresarse “STU_NUM determina STU_LNAME” STU_NUM-STU_LNAME. De hecho STU_NUM determina todos los valores de atributo del estudiante.

Por el contrario STU_NUM no esta determinado por STU_LNAME por que es muy posible que varios estudiantes se apelliden igual (Smith).

•DEPENDENCIA FUNCIONAL.- El atributo B es funcionalmente de A si A determina a B. Mas preciso “el atributo B es funcionalmente dependiente del atributo A si cada valor de la columna A determina uno y solo un valor en la columna B. •Observando la tabla STUDENTS es apropiado decir que STU_LNAME es funcionalmente dependiente de STU_NUM. Ej. STU_NUM=321452 determina el valor 2134 para STU_PHONE. Por otra parte STU_NUM no es funcionalmente dependiente de STU_PHONE por que el valor de 2267 para STU_PHONE esta asociado con dos valores de STU_NUM : 324274 Y 324291

Igualmente el valor 324273 de STU_NUM determina el valor Smith de STU_LNAME, pero el valor de STU_NUM es funcionalmente dependendiente de STU_LNAME, por que más de un estudiante puede apellidarse “Smith”. La definición de dependencia funcional puede ser generalizada para cubrir el caso en el cual el valor del atributo determinante ocurre más de una vez en una tabla :

El atributo A determina a B (B es funcionalmente dependiente de A) si todas las filas en una tabla, que concuerdan con el valor del atributo A, también deben hacerlo con el atributo B.

Debemos tener cuidado en la definicion de la direccion de la dependencia por ejemplo “La universidad determina la clasificaciòn de sus estudiantes como se muestra en la tabla siguiente:

Horas completadas

Clasificacion

Menos de 30

FR

30-59

SO

60-89

JR

90 ó más

SR

Dada la tabla se analiza que STU_HRS - STU_CLASS STU_CLASS depende funcionalmente de STU_HRS Pero el numero específico de horas (STU_HRS) no depende de la clasificacion del estudiante (STU_CLASS). Por ejemplo una clasificación JR –junior- puede ser determinada con 62 horas completadas o también con 84.

La dependencia funcional se podría definir también con más de un atributo (clave compuesta). Por este caso se puede refinar aún más la DEPENDENCIA FUNCIONAL COMPUESTA como : “Si el atributo B es funcionalmente dependiente de una clave compuesta A, pero no de cualquier subconjunto de la clave compuesta, el atributo B es por completo funcionalmente dependiente de A”.

CONCEPTO DE NORMALIZACION La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos

GRADOS DE NORMALIZACION Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalización. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

DESNORMALIZACION Se supone que mientras mas alto sea el nivel de normalización es el mas deseable, pero entre más alto sea el nivel de la base de datos normalizada mas uniones se requerirán para producir ciertas resultados y el DBMS responderá lentamente. Por lo tanto muchas veces es necesario desnormalizar la BD para aumentar el desempeño (velocidad). La desnormalización es producir una tabla normalizada de menor nivel: de 3FN a 2FN, de 2FN a 1FN.

ANOMALIAS POR DESNORMALIZACION 

INSERCION. Al insertar una tupla se tienen que repetir los datos redundantes. Esto puede provocar inconsistencias de datos en la BD.



ACTUALIZACION. Al actualizar se tiene que actualizar todas las tuplas donde se encuentren los daos redundantes. ¿ que pasa si se omite actualizar una tupla ?



ELIMINACION. Al eliminar una tupla se necesita eliminar todas las tuplas donde el dato a eliminar este duplicado.

Regla

Descripción

Primera Forma Normal (1FN)

Incluye la eliminación de todos los grupos repetidos.

Segunda Forma Normal (2FN)

Asegura que todas las columnas que no son llave sean completamente dependientes de la llave primaria (PK).

Tercera Forma Normal (3FN)

Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son llave son dependientes de otras columnas que tampoco son llave.

1FN La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. También deben eliminarse todos los atributos no atómicos.

2FN

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos. Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayoría de los problemas de lógica. Podemos insertar un registro sin un exceso de datos en la mayoría de las tablas.

3FN Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Una dependencia transitiva es aquella en la cual existen atributos que no son llave que dependen de otras atributos que tampoco son llave. Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se insertan o borran registros. Cada columna en una tabla está identificada de manera única por la llave primaria, y no deben haber datos repetidos..

Un bd sin normalizar no cumple con ninguna regla de normalización. Para explicar con un ejemplo en que consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla :

ID_ORDE N

FECHA

ID_CLIENT E

NOM_CLI ENTE

NUM_ITE M

DESC_ITE M

2301

2/23/03

101

MARTI

CA

3786

RED

3

35

2301

2/23/03

101

MARTI

CA

4011

RAQUETA

6

65

2301

2/23/03

101

MARTI

CA

9132

PAQ-3

8

4.75

2302

2/25/03

107

HERMAN

WI

5794

PAQ-6

4

5.0

2303

2/27/03

110

WESPORTS

MI

4011

RAQUETA

2

65

2303

2/27/03

110

WESPORTS

MI

3141

FUNDA

2

10

ESTADO

CANT

PRECIO

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM, DESC_ITEM, CANT y PRECIO.

La 1FN prohibe los grupos repetidos, por lo tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son: Tenemos que eliminar los grupos repetidos. Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido la bd de datos queda ahora conformadada por dos tablas ORDENES ID_ORDEN

FECHA

ID_CLIENTE

NOM_CLIENTE

ESTADO

2301

2/23/03

101

MARTI

CA

2302

2/25/03

107

HERMAN

WI

2303

2/27/03

110

WE-SPORTS

MI

ARTICULOS-ORDENES

ID_ORDEN

NUM_ITEM

DESC_ITEM

CANT

PRECIO

2301

3786

RED

3

35

2301

4011

RAQUETA

6

65

2301

9132

PAQ-3

8

4.75

2302

5794

PAQ-6

4

5.0

2303

4011

RAQUETA

2

65

2303

3141

FUNDA

2

10

Aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son: Determinar cuáles columnas que no son llave no dependen de la llave primaria de la tabla. Eliminar esas columnas de la tabla base. Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.

La tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen. Las tablas quedan ahora de la siguiente manera: ARTICULOS_ORDENES ID_ORDEN

NUM_ITEM

CANT

2301

3786

3

2301

4011

6

2301

9132

8

2302

5794

4

2303

4011

2

2303

3141

2

- ARTICULOS

NUM_ITEM

DESC_ITEM

PRECIO

3786

RED

35

4011

RAQUETA

65

9132

PAQ-3

4.75

5794

PAQ-6

5.0

4011

RAQUETA

65

3141

FUNDA

10

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra columna no llave. Los pasos a seguir son: •Determinar las columnas que son dependientes de otra columna no llave. •Eliminar esas columnas de la tabla base. •Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes. Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria. Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES quedan de la siguiente manera:

ORDENES

ID_ORDEN

FECHA

ID_CLIENTE

2301

2/23/03

101

2302

2/25/03

107

2303

2/27/03

110

CLIENTES ID_CLIENTE

NOM_CLIENTE

ESTADO

101

MARTI

CA

107

HERMAN

WI

110

WE-SPORTS

MI

¿ QUE TAN LEJOS NORMALIZAR ? 

La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de nosotros. Si nuestra base de datos va a proveer información a un solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo exagerado. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel más alto no tenga sentido.



Existen mas niveles de normalización que no se han tratado aquí ellas son:Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesitamos. Éstas existen para hacer una base de datos realmente relacional.

CONCEPCION INICIAL DE UNA BASE DE DATOS PARA EL CONTROL DE PROYECTOS Num_proy

Nombre_proy

Num_emp

Nom_emp

Clas_puesto

15

Control escolar

103 101 105 106 102

Denisse Carlos Hristo* Aymme Jesus

18

Ingresos

114 118 104 112

22

Egresos

23

Presupuestos

* Indica líder de proyecto

cargo_hora

Horas

Cargo

Ing. Sistemas Diseñador bd Diseñador bd Programador Analista

84.50 105.00 105.00 35.75 96.75

23.8 19.4 35.7 12.6 23.8

2011.10 2037.00 3748.50 450.45 2302.65

Alfonso Radames Aurelio* Abigail

Diseñador ap. Apoyo general Analista Analista DSS

48.10 18.36 96.75 45.95

24.6 45.3 32.4 44.0

1183.26 831.71 3134.70 2021.80

105 104 113 111 106

Hristo Aurelio Cuitlahuac* Jesus Joel Aymme

Diseñador bd Analista Diseñador ap. Trabajo oficina Programador

105.00 96.75 48.10 26.87 35.75

64.7 48.4 23.6 22.0 12.8

6793.50 4682.70 1135.16 591.14 457.60

107 115 101 114 108 118 112

Christian Javier Carlos* Alfonso Emmanuel Radames Abigail

Programador Analista Diseñador bd Diseñador ap. Analista Apoyo general Analista DSS

35.75 96.75 105.00 48.10 96.75 18.36 45.95

24.6 45.8 56.3 33.1 23.6 30.5 41.4

879.45 4431.15 5911.50 1592.11 2283.30 559.98 1902.33

CONVERSION A 1FN: Se hacen atómicos los datos y se asigna una llave que identifique la tupa (Num_proy,Num_emp) Num_proy

Nombre_proy

Num_emp

Nom_emp

Clas_puesto

cargo_hora

Horas

Cargo

15 15 15 15 15

Control escolar Control escolar Control escolar Control escolar Control escolar

103 101 105 106 102

Denisse Carlos Hristo* Aymme Jesus

Ing. Sistemas Diseñador bd Diseñador bd Programador Analista

84.50 105.00 105.00 35.75 96.75

23.8 19.4 35.7 12.6 23.8

2011.10 2037.00 3748.50 450.45 2302.65

18 18 18 18

Ingresos Ingresos Ingresos Ingresos

114 118 104 112

Alfonso Radames Aurelio* Abigail

Diseñador ap. Apoyo general Analista Analista DSS

48.10 18.36 96.75 45.95

24.6 45.3 32.4 44.0

1183.26 831.71 3134.70 2021.80

22 22 22 22 22

Egresos Egresos Egresos Egresos Egresos

105 104 113 111 106

Hristo Aurelio Cuitlahuac* Jesus Joel Aymme

Diseñador bd Analista Diseñador ap. Trabajo oficina Programador

105.00 96.75 48.10 26.87 35.75

64.7 48.4 23.6 22.0 12.8

6793.50 4682.70 1135.16 591.14 457.60

23 23 23 23 23 23 23

Presupuestos Presupuestos Presupuestos Presupuestos Presupuestos Presupuestos Presupuestos

107 115 101 114 108 118 112

Christian Javier Carlos* Alfonso Emmanuel Radames Abigail

Programador Analista Diseñador bd Diseñador ap. Analista Apoyo general Analista DSS

35.75 96.75 105.00 48.10 96.75 18.36 45.95

24.6 45.8 56.3 33.1 23.6 30.5 41.4

879.45 4431.15 5911.50 1592.11 2283.30 559.98 1902.33

DEPENDENCIAS DETECTADAS -DIAGRAMA DE DEPENDECIAS-

Num_proy

Nombre_proy

Num_emp

Nom_emp

Clas_puesto

cargo_hora

Dependencia transitiva

Dependencia parcial

Dependencia parcial

Horas