Erwin Platinium

ERwin:
PLATINUM ERwin es una herramienta para el diseño de base de datos, que Brinda productividad en su diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, además ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos.
ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad _ relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
La migración automática garantiza la integridad referencial de la base de datos. ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, ERwin genera automáticamente tablas, vistas, índices, reglas de integridad referencial (llaves primarias, llaves foráneas), valores por defecto y restricciones de campos y dominios.
ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
Software para Aplicaciones Compatibles:
* NetDynamics
* PowerBuilder
* PROGRESS
* Visual Basic
Bases de Datos Compatibles:
* CA-Clipper * CA-OpenIngres
* DB2 for MVS * DB2 for OS/390,
* DB2 UDB * dBASE
* FoxPro * HiRDB,
* Informix * InterBase,
* Microsoft Access * Microsoft SQL Server,
* Oracle * Paradox,
* Rdb * red Brick Warehouse,
* SAS * SQL Anywhere,
* SQLBase * Sybase,
* Teradata
Sistemas Operativos Compatibles:
* Windows NT
* Windows 95
* Windows 98
Requerimientos Técnicos:
Mínimo 10 MB de espacio de disco duro, 16 MB RAM (32 MB RAM recomendado para modelos largos.)

Definición de herramientas case

Herramientas Case
De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:

• Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos.
• Herramientas de diseño para dar apoyo al análisis de datos.
• Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico.
• Herramientas para desarrollar los prototipos de las aplicaciones.

El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos.

Normalizacion IV "Casos practicos"

• Ejemplo de relación que no cumple la primera forma normal

  S#	P#	QTY
  s1	p1	300
  	p2	200
  	p3	400
  s2	p1	200
  	p2	100

  
  

  Ejemplo de relación que si cumple la primera forma normal

  S#	P#	QTY
  s1	p1	300
  s1	p2	200
  s1	p3	400
  s2	p1	200
  s2	p2	100

• 2ª Forma Normal

  Descripción

  • Una relación es segunda forma normal si y solo si:
  • Es primera forma normal.
  • Cualquier atributo (columna) no perteneciente a una clave (primaria o extranjera) tiene dependencia funcional total de la clave primaria, es decir, que a cada valor de dicho atributo solo le corresponde un valor de la clave primaria.

  Ejemplo de relación que no cumple la segunda forma normal

  S#	P#	QTY
  s1	p1	300
  s1	p2	200
  s1	p3	400
  s2	p1	200
  s2	p2	100

  
  
  Como puede verse, p1 tiene dos valores distintos (300 y 200), por lo cual no cumple la dependencia funcional total. Lo mismo ocurriría con p2.
  

  Ejemplo de relación que si cumple la segunda forma normal

  S#	P#	QTY
  s1	p1	300
  s1	p2	200
  s1	p3	400
  s2	p1	300
  s2	p2	200

• 3ª Forma Normal

  Descripción

  • Una relación es tercera forma normal si y solo si:
  • Es segunda forma normal.
  • Los atributos (columna) no pertenecientes a una clave (primaria o extranjera) son mutuamente independientes funcionalmente.

  Ejemplo de relación que no cumple la tercera forma normal

  S#	Status	City
  s1	20	London
  s1	10	Paris
  s3	10	Paris
  s4	20	London
  s5	30	Atenas

  Como puede verse, status y City presentan dependencia funcional total, por lo cual esta relación no cumple la tercera forma normal.
  

  Ejemplo de relación que si cumple la tercera forma normal

  S#	Status	City
  s1	20	London
  s1	10	Paris
  s3	10	Granada
  s4	20	Madrid

Normalizacion III "APLICACIONES"

• Normalización de relaciones en bases de datos

  • 1ª Forma Normal

    Descripción

    • Una relación es primera forma normal si y solo si sus tuplas (filas) contienen valores atómicos, es decir, no contienen valores que a su vez sean conjuntos.
    • En resumen, que todos los atributos (columnas) deben tener todos sus valores, o lo que es lo mismo, no debe haber celdas en blanco.

    Ejemplo de relación que no cumple la primera forma normal

    S#	P#	QTY
    s1	p1	300
    	p2	200
    	p3	400
    s2	p1	200
    	p2	100

    
    

    Ejemplo de relación que si cumple la primera forma normal

    S#	P#	QTY
    s1	p1	300
    s1	p2	200
    s1	p3	400
    s2	p1	200
    s2	p2	100

  • 2ª Forma Normal

    Descripción

    • Una relación es segunda forma normal si y solo si:
    • Es primera forma normal.
    • Cualquier atributo (columna) no perteneciente a una clave (primaria o extranjera) tiene dependencia funcional total de la clave primaria, es decir, que a cada valor de dicho atributo solo le corresponde un valor de la clave primaria.

    Ejemplo de relación que no cumple la segunda forma normal

    S#	P#	QTY
    s1	p1	300
    s1	p2	200
    s1	p3	400
    s2	p1	200
    s2	p2	100

    
    
    Como puede verse, p1 tiene dos valores distintos (300 y 200), por lo cual no cumple la dependencia funcional total. Lo mismo ocurriría con p2.
    

    Ejemplo de relación que si cumple la segunda forma normal

    S#	P#	QTY
    s1	p1	300
    s1	p2	200
    s1	p3	400
    s2	p1	300
    s2	p2	200

  • 3ª Forma Normal

    Descripción

    • Una relación es tercera forma normal si y solo si:
    • Es segunda forma normal.
    • Los atributos (columna) no pertenecientes a una clave (primaria o extranjera) son mutuamente independientes funcionalmente.

    Ejemplo de relación que no cumple la tercera forma normal

    S#	Status	City
    s1	20	London
    s1	10	Paris
    s3	10	Paris
    s4	20	London
    s5	30	Atenas

    Como puede verse, status y City presentan dependencia funcional total, por lo cual esta relación no cumple la tercera forma normal.
    

    Ejemplo de relación que si cumple la tercera forma normal

    S#	Status	City
    s1	20	London
    s1	10	Paris
    s3	10	Granada
    s4	20	Madrid
    s5	30	Atenas

  • 4ª Forma Normal

    Descripción

    • Una relación es cuarta forma normal si y solo si:
    • Es forma normal de BCNF.
    • Para toda la dependencia multivalor todos los atributos (columna) distintos de A dependen funcionalmente de A, es decir, A es clave.
    • Es decir, si la relación es BCNF y las únicas dependencias multivalor permitidas son las definidas sobre las claves candidatas, entonces se cumple.

  • 5ª Forma Normal

    Descripción

    • Una relación es quinta forma normal si y solo si:
    • Cada dependencia de JOIN que exista en dicha relación está implicada exclusivamente por claves candidatas.

  • Forma BCNF

    Normalización de relaciones con más de una clave candidata (BCNF)

    • Aun siendo formas 3 Normal pueden aparecer problemas en una relación si esta presenta más de una clave.
    • Para resolver estos problemas recurrimos a la forma normal de Boyce y Codd (BCNF).
    • Llamaremos determinante al atributo o conjunto de estos del cual depende funcionalmente algún otro atributo de la relación.
    • Se dice que una relación está en forma normalizada de Boyce y Codd si y solo si cada determinante es una clave candidata.
    • Toda forma BCNF es también 3ª forma normal, pero no a la inversa.

    Ejemplo de relación que no es BCNF

    s#	sname	p#	qty
    s1	smith	p1	300
    s1	smith	p2	200
    s1	smith	p3	400
    s1	smith	p4	200
    s1	smith	p5	100
    s1	smith	p6	100
    s2	jones	p1	300
    s2	jones	p2	400
    s3	clark	p2	200
    s4	brown	p2	200
    s4	brown	p4	300
    s4	brown	p5	400

    
    
    

    • Esta relación no es BCNF porque tiene como determinantes: s#; sname; s#,p# y sname#p#.
    • Y como claves tiene: s#,p# y sname,p#.
    • Como ambos conjuntos no coinciden no se cumple la normalidad BCNF.
    • Sin embargo, en el siguiente ejemplo, esa misma tabla dividida en las dos siguientes unidas mediante un JOIN si serían normales BCNF.

    Ejemplo de relación que es BCNF

    s#	p#	qty
    s1	p1	300
    s1	p2	200
    s1	p3	400
    s1	p4	200
    s1	p5	100
    s1	p6	100
    s2	p1	300
    s2	p2	400
    s3	p2	200
    s4	p2	200
    s4	p4	300
    s4	p5	400

    JOIN

    s#	sname
    s1	smith
    s2	jones
    s3	clark
    s4	brown

    
    

    • De esta forma la primera tabla tendría como determinante s#,p# y como clave s#,p#.
    • La segunda tabla tendría como determinantes s# y sname.
    • Como clave tendría s#,p#, por lo cual esta tabla cumple la normalidad BCNF, al igual que ocurre con la primera.

• Dependencias

  • Dependencias funcionales

    Descripción

    • En una relación un atributo X es funcionalmente dependiente de otro Y si y solo si para cada valor de Y hay un único valor de X.
    • Por ejemplo: La persona es funcionalmente dependiente del DNI.

    DNI	Persona
    1000001	Pepe López
    1000002	Juan Martín
    1000003	Marisa Puertas

    Esta dependencia funcional no tiene porque darse solo entre atributos (columnas) aislados, sino que también puede darse entre grupos de atributos.

  • Dependencias funcionales totales

    Descripción

    • Se dice que un atributo/grupo de atributos Y tienen dependencia funcional total del grupo de atributos X si y solo si depende funcionalmente de X pero no depende funcionalmente de ningún subconjunto de atributos de X distinto del total.
    • Por ejemplo: Status y city dependen funcionalmente de s#,p# pero como también dependen funcionalmente de s# no tienen dependencia funcional total de s#,p#.

    
    

    S#	Status	City	P#	QTY
    s1	20	London	p1	300
    s1	20	London	p2	200
    s1	20	London	p3	400
    s1	20	London	p4	200
    s1	20	London	p5	100
    s1	20	London	p6	100
    s2	10	Paris	p1	300
    s2	10	Paris	p2	400
    s3	10	Paris	p2	200
    s4	20	London	p2	200
    s4	20	London	p4	300
    s4	20	London	p5	400

  • Dependencias multivalor

    Descripción

    • También pueden aparecer dependencias multivalor, caso aplicable exclusivamente a relaciones con al menos tres atributos.
    • Se dice que en una relación con atributos A, B y C (estos atributos también pueden ser compuestos) existe dependencia multivalor entre los atributos A y B cuando tomada cualquier pareja de valores A,C de la relación el conjunto de valores de B que acompañan a esa pareja en cualquier tupla (columna) de la relación solo depende funcionalmente del valor de A y no depende funcionalmente del valor de C.
    • Esta dependencia se representa: A -> B|C
    • Ejemplo de dependencia multivalor:

    
    

    Asignatura	Profesor	Lección
    Física	López	Mecánica
    Física	López	Óptica
    Física	Martín	Mecánica
    Física	Martín	Óptica
    Física	Moral	Mecánica
    Física	Moral	Óptica
    Matemáticas	Antón	Álgebra
    Matemáticas	Antón	Geometría

    Asignatura --> profesor|lección Asignatura -/-> profesor|lección

  • Dependencias de JOIN

    Descripción

    • En ocasiones, no nos basta con realizar la descomposición de una relación y unirla mediante un JOIN para recomponerla, sino que es necesario descomponerla en tres o mas relaciones.
    • Existe entonces la llamada independencia de JOIN, en la cual sean X, Y, ... Z un subconjunto del conjunto de atributos de una relación R.
    • Se dice que la relación satisface la dependencia de JOIN si y solo si la relación R queda recompuesta a su estado original efectuando el JOIN de las relaciones obtenidas proyectando R en X, Y... Z respectivamente.
    • Por ejemplo: descomponemos la relación SPJ en tres realciones:

    SPJ

    s#	p#	j#
    s1	p1	j2
    s1	p2	j1
    s2	p1	j1
    s1	p1	j1

    
    
    

    SP	PJ	JS

    s# p# s1 p1 s1 p2 s2 p1

    p# j# p1 j2 p2 j1 p1 j1

    j# s# j2 s1 j1 s1 j1 s2

    Si hacemos un JOIN sobre p# entre la tabla SP y la PJ obtenemos la siguiente tabla:

    s#	p#	j#
    s1	p1	j2
    s1	p1	j1
    s1	p2	j1
    s2	p1	j2
    s2	p1	j1

    Si con esta tabla realizamos un JOIN con JS sobre j#,s# volveremos a la tabla original:

    SPJ

    s#	p#	j#
    s1	p1	j2
    s1	p2	j1
    s2	p1	j1

NORMALIZACION II "Aplicacion del alumno"

Normalizacion II "4FN-5FN"

Cuarta Forma Normal (4FN)

Artículo principal: Cuarta forma normal

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN)

Artículo principal: Quinta forma normal

Una tabla se encuentra en 5FN si:

• La tabla está en 4FN
• No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.

NORMALIZACION I "Aplicaciones"

uando se diseña una base de datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales y no todos son equivalentes, ya que algunos van a representar la realidad mejor que otros.
Es necesario conocer qué propiedades debe tener un esquema relacional para representar adecuadamente una realidad y cuáles son los problemas que se pueden derivar de un diseño inadecuado.
La teoría de la Normalización es un método objetivo y riguroso que se aplica en el diseño de bases de datos relacionales.
Cuando estudiamos la estructura del modelo relacional, nos dimos cuenta que la base de datos puede representarse por medio de un conjunto de objetos (dominios y relaciones) y de un conjunto de reglas de integridad.
El esquema relacional puede obtenerse de dos formas distintas:

• Directamente a partir de la observación de nuestro universo del discurso, en donde especificamos conjuntos de atributos, relaciones y restricciones que corresponden a los observados en el mundo real.
• Realizando el proceso de diseño en dos fases, primero el diseño conceptual (E/R) obteniendo el esquema conceptual y posteriormente transformar éste a un esquema relacional, siguiendo algunas reglas generales, que fueron dadas anteriormente.

Algunos problemas que se pueden presentar son:

• Incapacidad para almacenar ciertos hechos
• Redundancias y por tanto, posibilidad de incoherencias
• Ambigüedades
• Pérdida de información (aparición de tuplas espúreas)

• Pérdida de dependencias funcionales, es decir, ciertas restricciones de integridad que dan lugar a interdependencias entre los datos.
• Aparición en la BD de estados no válidos, es decir, anomalías de inserción, borrado y modificación.