aprenda workbook sql server 2008 - 2 capítulos

WWoorrkkBBooookk

SSQQLL SSeerrvveerr 22000088

Felipe Ramírez

Facultad de Contaduría Pública y Administración

Facultad de Ingeniería Mecánica y Eléctrica

Universidad Autónoma de Nuevo León, México.

Francisco Salazar

Facultad de Contaduría Pública y Administración

Universidad Autónoma de Nuevo León, México.

MÉXICO WWW.APRENDA.MX

01-800-APRENDA

El contenido de este documento está sujeto a cambios sin previo aviso. Las organizaciones, productos, personas, o eventos referidos en los ejemplos son ficticios, por lo cual no debe establecerse relación alguna, inferirse o atribuirse dicha relación, respecto a organizaciones, produc-tos, personas, o eventos de la realidad.

El contenido del presente material tiene protegidos los derechos de au-tor de la manera más amplia posible, por lo cual queda estrictamente prohibida su reproducción parcial o total.

Queda estrictamente prohibido su almacenamiento o introducción a cualquier sistema de recuperación de datos.

Queda estrictamente prohibida su reproducción o transmisión en cual-quier medio conocido o por conocer, sin importar el propósito. La re-producción sólo podrá realizarse previa autorización por escrito del titular de los derechos.

De acuerdo a lo establecido por la Ley Federal del Derecho de Autor, se someterá a proceso a aquél que PRODUZCA, REPRODUZCA, ALMACENE, DISTRIBUYA, TRANSPORTE O COMERCIALICE COPIAS DE LA OBRA SIN LA AUTORIZACIÓN DEL TITULAR DE LOS DERECHOS.

Los nombres de organizaciones y productos comerciales que aparecen en el presente material son propiedad de sus respectivos dueños y titu-lares de derechos.

© DERECHOS RESERVADOS POR LOS RESPECTIVOS TITULARES

Aprenda Practicando

http://www.Aprenda.mx

I

Índice

Generalidades ........................................................................................ V

Análisis de casos de negocio ................................................................... 1

Objetivos ........................................................................................................................................................................ 2 Información y modelación ..................................................................................................................................... 3 Caso: Cruz Roja Méxicana ...................................................................................................................................... 5 Requerimientos de la aplicación ....................................................................................................... 6 Características de flujo de información .......................................................................................... 6 Concepto de bases de datos .................................................................................................................................. 7 Es una colección ........................................................................................................................................ 7 Es auto descriptiva .................................................................................................................................. 7 Está formada por registros integrados ........................................................................................... 8 Tablas .......................................................................................................................................................................... 9 Registros – Filas - Rows ...................................................................................................................... 10 Campos – Columnas - Columns ....................................................................................................... 10 Concepto de llaves y relaciones........................................................................................................................ 11 Llave primaria......................................................................................................................................... 11 Llave foránea ........................................................................................................................................... 12 Relaciones entre tablas ....................................................................................................................... 12 Dominio ....................................................................................................................................................................... 14 Diagrama de estructura de datos .................................................................................................................... 16 Diagrama de entidad relación ........................................................................................................................... 18 Representar tablas ................................................................................................................................................. 19 Representar relaciones ........................................................................................................................................ 20 Representar cardinalidad ................................................................................................................................... 22 Representar opcionalidad................................................................................................................................... 24 Modelo de documentación para el modelo de datos .............................................................................. 26 Tabla de dominios y tipos de datos ............................................................................................... 28 Diagrama de Entidad Relación ........................................................................................................ 29 Tabla de llaves ........................................................................................................................................ 30 Tabla de relaciones ............................................................................................................................... 30 Vicios del modelo relacional .............................................................................................................................. 31 Redundancia ............................................................................................................................................ 31 Inconsistencia ......................................................................................................................................... 32 Falta de integridad ................................................................................................................................ 32 Ejercicios .................................................................................................................................................................... 33 Lab: Identificación de sujetos y eventos ....................................................................................................... 34 Lab: Elaboración de diagramas de estructura de datos del modelo ................................................ 36 Lab: Elaboración del diagrama de entidad relación ................................................................................ 38 Preguntas de competencia ................................................................................................................................. 39 Investigación ............................................................................................................................................................. 39

II Índice

Normalización ....................................................................................... 41 Objetivos ..................................................................................................................................................................... 42 Qué es la normalización ....................................................................................................................................... 43 Formas normales básicas.................................................................................................................................... 45 Caso de ejemplo ...................................................................................................................................................... 46 Dependencias funcionales .................................................................................................................................. 48 1NF (Primera Forma Normal) .......................................................................................................................... 49 2NF (Segunda Forma Normal) ......................................................................................................................... 52 3NF (Tercera Forma Normal) ........................................................................................................................... 55 BCNF (Forma Normal Boyce Codd) ................................................................................................................ 57 Desnormalización ................................................................................................................................................... 58 Ejercicios .................................................................................................................................................................... 60 Lab: Normalización de un modelo de datos ............................................................................................... 61 Preguntas de competencia ................................................................................................................................. 62 Investigación ............................................................................................................................................................ 62

Diseño de bases de datos con ERWin ..................................................... 63 Objetivos ..................................................................................................................................................................... 64 ¿Qué es una herramienta CASE? ...................................................................................................................... 65 La herramienta CASE ERwin ............................................................................................................................. 66 El entorno de trabajo de ERwin ....................................................................................................................... 67 Ejercicios .................................................................................................................................................................... 68 Lab: Creando una base de datos en abstracto con el software ERwin ............................................ 69 Presentación del caso de negocio. ................................................................................................. 69 Ingresar a CA ERwin ............................................................................................................................ 70 Creación de entidades ......................................................................................................................... 72 Establecer relaciones entre entidades ......................................................................................... 79 Preguntas de competencia ................................................................................................................................. 81 Investigación ............................................................................................................................................................ 81

Fundamentos de SQL Server y su arquitectura ....................................... 83 Objetivos ..................................................................................................................................................................... 84 Elementos que componen a SQL Server 2008 ........................................................................................... 85 Estrategias de implementación de bases de datos .................................................................................. 87 Elementos de una base de datos física .......................................................................................................... 90 Archivos y Filegroups ........................................................................................................................................... 92 Preguntas de competencia ................................................................................................................................. 93 Investigación ............................................................................................................................................................ 93

Creación de bases de datos con SQL Server ........................................... 95 Objetivos ..................................................................................................................................................................... 96 Base de datos ............................................................................................................................................................ 97 CREATE DATABASE .............................................................................................................................................. 98

Índice III

Ejercicios ................................................................................................................................................................. 100 Lab: Creando una base de datos .................................................................................................................... 101 Ingresar a Microsoft SQL Server Management Studio. ....................................................................... 101 Crear una base de datos nueva en modo gráfico ................................................................................... 103 Manejo de soluciones y proyectos ............................................................................................................... 104 Herramientas del Editor de consultas ........................................................................................................ 107 Preguntas de competencia .............................................................................................................................. 110 Investigación .......................................................................................................................................................... 110

Tablas e índices .................................................................................... 111 Objetivos .................................................................................................................................................................. 112 Tablas .................................................................................................................................................................... 113 Columnas ................................................................................................................................................................. 114 Identificadores de Microsoft SQL Server 2008....................................................................................... 115 Tipos de datos ....................................................................................................................................................... 117 Números exactos .................................................................................................................................................. 118 Números aproximados ...................................................................................................................................... 119 Fecha y hora ........................................................................................................................................................... 120 Cadenas .................................................................................................................................................................... 120 Binarios .................................................................................................................................................................... 121 CREATE TABLE ..................................................................................................................................................... 123 Valores IDENTITY y DEFAULT ...................................................................................................................... 124 Índices .................................................................................................................................................................... 126 Índices CLUSTERED y NONCLUSTERED ................................................................................................... 126 Spatial Index, XML Index y Fulltext Index ................................................................................................ 128 CREATE INDEX ..................................................................................................................................................... 129 Ejercicios ................................................................................................................................................................. 131 Lab: Creando tablas ............................................................................................................................................ 132 Crear una tabla de forma gráfica .................................................................................................................. 132 Establecer una llave primaria de forma gráfica ..................................................................................... 134 Generación de Scripts DDL .............................................................................................................................. 135 Definiendo campos IDENTITY y valores DEFAULT .............................................................................. 136 Lab: Creando índices .......................................................................................................................................... 139 Preguntas de competencia .............................................................................................................................. 140 Investigación .......................................................................................................................................................... 140

Relaciones entre tablas ........................................................................ 143 Objetivos .................................................................................................................................................................. 144 Relaciones ............................................................................................................................................................... 145 Ejercicios ................................................................................................................................................................. 148 Lab: Estableciendo relaciones entre tablas .............................................................................................. 149 Estableciendo relaciones usando Table Designer ............................................................... 149 Estableciendo relaciones usando Database Diagram......................................................... 151 Lab: Implementando el modelo de datos completo ............................................................................. 154 Preguntas de competencia .............................................................................................................................. 154 Investigación .......................................................................................................................................................... 155

IV Índice

Consultas básicas con Transact SQL ..................................................... 157 Objetivos ................................................................................................................................................................... 158 Pubs: La base de datos de ejemplo ............................................................................................................... 159 Transact SQL ........................................................................................................................................................... 162 DML – Consultas usando SELECT .................................................................................................................. 164 Uso de literales ...................................................................................................................................................... 167 Columnas calculadas ........................................................................................................................................... 168 Uso de la cláusula WHERE ................................................................................................................................ 169 Uso de calificadores para columnas ............................................................................................................. 170 Uso de WHERE para seleccionar registros................................................................................................ 173 Uso de WHERE para unión de tablas ........................................................................................................... 176 Operadores lógicos .............................................................................................................................................. 178 Recomendaciones para el uso de condiciones ........................................................................................ 180 Ejercicios .................................................................................................................................................................. 182 Lab: Consultas básicas ........................................................................................................................................ 183 Lab: Detectando la necesidad de los calificadores ................................................................................. 188 Lab: Verificando la necesidad de la correcta definición de WHERE .............................................. 189 Preguntas de competencia ............................................................................................................................... 191 Investigación .......................................................................................................................................................... 191

Sentencias básicas de DML .................................................................. 193 Objetivos ................................................................................................................................................................... 194 DML – Modificación de datos .......................................................................................................................... 195 INSERT (Agregado de filas) ............................................................................................................................. 196 UPDATE (Modificación de datos) .................................................................................................................. 198 DELETE (Eliminado de filas) ........................................................................................................................... 200 Ejercicios .................................................................................................................................................................. 201 Lab: Agregando, modificando y eliminando filas en una tabla ........................................................ 202 Preguntas de competencia ............................................................................................................................... 203 Investigación .......................................................................................................................................................... 203

1

Análisis de casos de negocio

Contenido:

Objetivos ................................................................................................................ 2 Información y modelación .............................................................................. 3 Caso: Cruz Roja Méxicana ................................................................................ 5

Requerimientos de la aplicación .................................................................6 Características de flujo de información ...................................................6

Concepto de bases de datos ............................................................................ 7 Es una colección ..................................................................................................7 Es auto descriptiva ............................................................................................7 Está formada por registros integrados ....................................................8

Tablas ..................................................................................................................... 9 Registros – Filas - Rows ............................................................................... 10 Campos – Columnas - Columns ................................................................ 10

Concepto de llaves y relaciones .................................................................. 11 Llave primaria ................................................................................................... 11 Llave foránea ..................................................................................................... 12 Relaciones entre tablas ................................................................................ 12

Dominio ............................................................................................................... 14 Diagrama de estructura de datos ............................................................... 16 Diagrama de entidad relación ..................................................................... 18 Representar tablas .......................................................................................... 19 Representar relaciones .................................................................................. 20 Representar cardinalidad ............................................................................. 22 Representar opcionalidad ............................................................................ 24 Modelo de documentación para el modelo de datos .......................... 26

Tabla de dominios y tipos de datos ........................................................ 28 Diagrama de Entidad Relación.................................................................. 29 Tabla de llaves .................................................................................................. 30 Tabla de relaciones ......................................................................................... 30

Vicios del modelo relacional ........................................................................ 31 Redundancia ...................................................................................................... 31 Inconsistencia ................................................................................................... 32 Falta de integridad .......................................................................................... 32

Ejercicios ............................................................................................................. 33 Lab: Identificación de sujetos y eventos .................................................. 34 Lab: Elaboración de diagramas de estructura de datos del modelo .................................................................................................................. 36 Lab: Elaboración del diagrama de entidad relación ........................... 38 Preguntas de competencia ........................................................................... 39 Investigación ...................................................................................................... 39

2 Análisis de casos de negocio

Objetivos

Objetivo de la unidad: El objetivo de la unidad es que el alumno sea com-

petente para analizar una situación del mundo real, y traducirla a un modelo de base de datos relacional.

Al finalizar la unidad…

1. Aprenderá a identificar sujetos y eventos.

2. Aprenderá a desarrollar diagramas de estructura de datos.

3. Aprenderá a desarrollar diagramas de entidad relación.

4. Aprenderá a documentar un modelo de base de datos relacional.

5. Aprenderá a identificar los vicios del modelo relacional.

Análisis de casos de negocio 3

Información y modelación

En la actualidad la gran mayoría de las organizaciones depende de la informa-ción para operar correctamente. La información es, por definición, el conjunto de datos que en determinada cantidad y forma aumenta el conocimiento o redu-ce la incertidumbre respecto a un sujeto, evento o circunstancia. Un dato sería una representación simbólica cuyo significado no excede el inherente a los sig-nos que lo componen. Si decimos simplemente “8”, se trataría de un dato sim-plemente. Si además decimos que se trata de “grados en la escala Richter”, ya nos revela mucho más significado que el simple “8”; en este caso el dato sería in-formación.

Existen tres tratamientos básicos de la información: generarla, transformarla, y divulgarla. La informática es en esencia la ciencia que estudia la manera para generar, trasformar y divulgar información por medios automáticos. En ese sentido, el aprendizaje de bases de datos es una labor informática, que tiene que ver con el almacenamiento de datos para la generación, transformación y divul-gación de información.

Toda nuestra actividad para el análisis de bases de datos comienza al disponer de una parte del mundo real que deja evidencia en forma de datos. La existen-cia de datos derivados de un proceso nos invita a su almacenamiento, pero el almacenamiento en términos computacionales debe hacerse de manera formal y


abstracta, entendible por la computadora. Al proceso de generar (a partir de un análisis profundo de la vida real) una abstracción que refiera los datos involu-crados en un proceso y la interrelación que éstos guardan para integrar infor-mación, se le llama modelación de base de datos. A la situación de la vida real que es modelada, se le puede dar el nombre de caso de negocios. La modelación de bases de datos siempre se realiza en función a una metodología o teoría; en la actualidad, la más importante teoría es la relacional, adoptada por las más im-portantes bases de datos: Oracle, SQL Server, MySql, Access, etcétera.

La mejor forma de entender la modelación de bases de datos para un caso de negocio, es practicando el proceso.


Caso: Cruz Roja Méxicana

La mayor cantidad de donaciones que recibe la Cruz Roja Mexicana (CRM), con-trario a lo que se pudiera pensar, no son derivadas de las campañas nacionales de colecta, sino de las aportaciones voluntarias que personas e instituciones rea-lizan de manera altruista, sin importar que exista una campaña o no.

Toda realidad es un sistema, entendiendo por éste como el conjunto de elemen-tos interrelacionados entre sí que persiguen un resultado común. El análisis es el proceso de descomponer un sistema en sus elementos, para entender cada uno de ellos y su contribución al comportamiento o resultado del sistema. Ob-viamente, el resultado que pretende el sistema es importante, pues delimita el número de elementos que se van a tratar de entender; se conoce como abstrac-ción del modelo al proceso a través del cual se discriminan aquellos elementos del sistema que no aportan datos relevantes para el propósito del mismo. Si tenemos un sistema de reservaciones de viajes en línea y un cliente nos dice que quiere viajar a Cancún este mes, y además nos dice que la vez pasada que fue a Cancún se encontró en la playa una moneda de oro, queda claro que parte de la información nos interesa para la reservación, pero parte de la información no.

Del análisis del caso de negocio podemos desprender dos cosas importantes: a) Requerimientos de la aplicación. b) Características del flujo de información. En el caso de nuestro ejemplo tendríamos el siguiente resultado.


Requerimientos de la aplicación

La CRM desea una aplicación de bases de datos que les permita lo siguiente:

1. Registrar las aportaciones que se realizan.

2. Que permita disponer de un padrón de donadores clasificado.

3. Que permita hacer estudios estadísticos que arrojen información significativa de los sectores que representan mayor captación, a fin de dirigir sus campañas publicitarias de forma adecuada.

4. Que emita comprobantes fiscales para deducción.

5. Que emita un consolidado rápido del monto global aportado por cada una de las sectores que colaboran con donaciones.

Características de flujo de información

Las donaciones tienen las siguientes características:

1. Pueden ser realizadas en todos los estados de la república mexi-cana, incluso por un mismo donador.

2. Pueden ser realizadas por dos tipos de donador: persona física o persona moral.

3. Un donador puede hacer tantas donaciones como desee.

4. Los donadores pueden dedicarse a cualquiera de las siguientes actividades objetivo (sectores): Industria, Comercio, Sector Fi-nanciero, Sector Servicios, Profesionistas Independientes, Otros.

5. Los donadores pudieron haberse enterado de la campaña por: Pe-riódico, Televisión, Notificación de la empresa, Aviso personal de la Cruz Roja, Visitador voluntario.


Concepto de bases de datos

Una base de datos, según la define, Kroenke, se define como “la colección auto descriptiva de registros integrados”.

Es una colección

Se refiere a que un sólo registro o dato, o unos pocos, no constituyen propiamen-te una base de datos; debe tratarse de una cantidad significativa de datos proce-sable, de difícil análisis contemplativo.

Es auto descriptiva

Se refiere a que no son simplemente datos almacenados físicamente; una base de datos contiene información relativa a los tipos de valores almacenados, la rela-ción entre ellos, y el significado que en conjunto representan. En la mayoría de las bases de datos actuales se cuenta con información de tipos de datos, reglas de negocios, comportamientos automáticos, niveles de acceso y permisos de acceso a los datos, etcétera. Ya no sólo se trata de datos, sino de aquello que describe su naturaleza y las posibilidades de su uso.


Está formada por registros integrados

Los datos son representaciones simbólicas cuyo significado no excede el in-herente a los signos que los componen. En una base de datos, los datos se reú-nen para adquirir significado, en forma de registros de una misma naturaleza; los registros, a su vez, se integran con otros registros de otra naturaleza distinta, formando fuentes de información.


Tablas

Una base de datos se compone por tablas. Las tablas son datos almacenados en forma de arreglos bidimensionales, que almacenan datos de una misma natura-leza.

Una tabla puede mantener el registro de dos cosas: 1) Sujetos y 2) Eventos.

1. SS uujj eettooss :: es todo aquello que ejecuta alguna acción, o le sucede

algo (clientes, proveedores, departamentos, artículos, etc.) Se consideran sujetos también los atributos clasificados, es decir, aquello que clasifica a algún atributo de un sujeto (color, tamaño, etc.)

2. EE vv eenn ttooss :: es todo aquello que hace el sujeto, o que le sucede al

sujeto (factura, movimiento, etc.)

En una tabla nunca se deben mezclar sujetos y eventos: no podríamos, por ejem-plo, registrar a los clientes y las facturas que les hemos expedido, en la misma tabla. Una tabla sólo almacena información de una misma naturaleza, sin ambi-güedades de significado, que nos ponga en conflicto para responder ¿qué alma-cena la tabla?


La identificación de los sujetos y eventos relevantes para el modelo de datos es fundamental en la realización de una aplicación.

Registros – Filas - Rows

Los registros son un conjunto de atributos que componen la naturaleza de lo contenido en una tabla. Una tabla puede contener N registros, todos ellos con el mismo número de atributos, todos ellos conteniendo la misma naturaleza de in-formación por atributo.

Dada la representación de una tabla como un arreglo bidimensional, se suelen conocer a los registros como filas (rows). Este último término es el utilizado por SQL Server.

Campos – Columnas - Columns

Los campos son cada uno de los atributos que componen un registro. Cada re-gistro contiene N campos. Cada uno de los campos posee un dominio, un tipo de dato, y una longitud determinada.

Dada la representación de una tabla como un arreglo bidimensional, se suelen conocer a los campos como columnas (columns). Este último término es el utili-zado por SQL Server.


Concepto de llaves y relaciones

Una llave es un conjunto de campos que permiten identificar o localizar un de-terminado registro dentro de una tabla. También suelen conocerse como cla-ves.

Si la llave está integrada por un solo campo, se le da el nombre de llave simple; en caso de estar integrada por dos o más campos, se le da el nombre de llave com-puesta.

Llave primaria

Una llave primaria es el conjunto de campos mínimos, suficientes y necesarios para identificar como único un registro dentro de una tabla.

Los campos que forman una llave primaria se llaman atributos primos; los cam-pos que no forman parte de la llave primaria se les llama atributos no primos.

En un modelo de datos no deben existir dos tablas cuya llave primaria esté inte-grada por los mismos campos; en ese caso, las dos tablas deben formar una sola.

Los valores que un registro tiene en los atributos primos constituyen su identifi-cador.

Si en una tabla los registros no tienen la necesidad de ser referidos de manera individual, no es necesario disponer de una llave primaria. Un ejemplo: Una ta-


bla que almacena las respuestas dadas a una encuesta anónima, en donde un re-gistro no tiene significado estadístico; lo importante son los registros en su con-junto, y no en lo individual.

Llave foránea

Una llave foránea es la presencia en una tabla de la llave primaria de otra tabla.

Cuando se presenta una llave foránea, realmente hablamos de la existencia de los mismos campos en dos tablas; en una, esos campos constituyen una llave primaria, y no admiten valores repetidos (esto es porque identifican como úni-cos a los registros); en la otra, constituyen una llave foránea, y pueden admitir valores repetidos (esto es posible porque su función no es identificar a los regis-tros). A los campos que están en una y otra tabla, se les llama campos de coinci-dencia.

No siempre la existencia de campos de coincidencia supone una relación; sólo existirá cuando los campos de coincidencia sean, en una tabla la llave primaria, y en otra no.

En algunas bases de datos las llaves se almacenan en índices, que son referencias lógicas a una posición física de datos, atendiendo a una determinada clasifica-ción, ordenamiento y categorización. Por lo general, esos índices o llaves deben tener un nombre bajo el cual identificarse.

Resulta conveniente que las llaves primarias tengan el siguiente convenciona-lismo de nombre:

pkNombreDeTabla

Ejemplo:

pkDonador

Relaciones entre tablas

Una llave foránea siempre apunta hacia la tabla que posee la llave primaria; cuando este fenómeno se presenta, se dice que entre las tablas existe una rela-ción.

En una relación establecida entre la llave primaria en una tabla y la llave foránea en otra, la que posee la llave primaria se le llama entidad fuerte, y la que posee la llave foránea se le llama entidad débil; también suele dársele el nombre de enti-dad servidora a la entidad fuerte, y entidad cliente a la entidad débil. La llave foránea siempre forma parte de la entidad débil.


Para nombrar el índice de una llave foránea, podemos utilizar el siguiente con-vencionalismo:

fkEntidadDébil_EntidadFuerte

Ejemplo:

fkDonador_Actividad


Dominio

Se entiende por dominio el conjunto de valores válidos para un campo.

El dominio puede ser definido por:

1. TT ii ppoo dd ee ddaa ttoo :: cuando el dominio está determinado

sólo por el tipo de dato; por ejemplo, cuando un campo es Date o Integer, la simple definición del tipo de dato ya

define qué valores son válidos. También se considera de este tipo cuando los tipos de datos requieren la defi-nición de longitud, por ejemplo los datos de tipo String.

2. DD eepp eennddii eenntt ee dd eell mm oodd eelloo :: se presenta principal-

mente en las llaves foráneas. Además de que los cam-pos de coincidencia tendrán el mismo dominio de tipo de dato, los valores encontrados en la tabla débil deberán estar registrados previamente en la tabla fuerte. De no ser así, aún con cumplir las limitaciones de dominio de tipo de datos, el dato seguirá siendo inválido.

3. RR eeggllaa dd ee nn eeggoocc iioo :: es el dominio que se especifica por

una regla de negocio determinada. Un ejemplo puede


ser el tener un campo para almacenar la edad de los em-pleados; si el tipo de dato utilizado es Byte, el número

podrá oscilar entre 0 y 255; obviamente, no hay una per-sona con 200 años, por lo que una regla de negocio puede limitar el dominio como números enteros entre los 16 y los 75 años.


Diagrama de estructura de datos

El diagrama de estructura de datos consiste en representar a una tabla (sujeto o evento) en igualdad con los atributos que lo componen.

Reglas:

1. El nombre de la tabla o entidad siempre va en singular, no en plural.

2. Se recomienda escribir el nombre de las tablas en MAYÚSCULAS.

3. Evite los nombres de tablas y campos que contengan es-pacios en blanco o caracteres especiales; concéntrese en utilizar letras, números, y guión bajo (este último como intermedio; nunca al inicio o final).

4. Se representa a una tabla como la igualdad de los atribu-tos que la componen, utilizando para ello el símbolo de igualación “=”.

5. Los atributos primos siempre van más a la derecha que los no primos.


6. Los atributos se separan con el símbolo de más “+”.

7. Los atributos primos siempre se señalan anteponiéndo-les un asterisco “*”.

Por ejemplo:

Tabla = *Campo01 + Campo02 + Campo03 + Campo04

Por ejemplo, en nuestro caso práctico, tenemos un sujeto llamado Donador; de acuerdo a la naturaleza de lo que se quiere registrar, sabemos que los datos que ocupamos del donador son los siguientes: Nombre, Dirección completa, RFC, sa-ber qué tipo de donador es (persona física o moral), y la actividad preponderan-te. También requerimos un identificador único, que sea más sencillo que el RFC.

Sería:

Donador = *IDDonador + NomDonador + DirDonador +

RFC + IDTipoDonador + IDActividad


Diagrama de entidad relación

El Diagrama de Entidad Relación (DER) es una representación gráfica que mues-tra las relaciones existentes entre tablas, y sus particularidades.

La elaboración de un diagrama DER consiste en trabajos de representación.

1. Representar los sujetos y eventos como tablas.

2. Representar las relaciones existentes entre las tablas.

3. Representar la cardinalidad existente entre las tablas.

4. Representar la opcionalidad de los registros de coincidencia.


Representar tablas

El primer paso para elaborar un DER, es representar a las tablas: simplemente se trazan en forma de rectángulo.

Una variante interesante es detallar los campos que componen a cada una de las tablas. Esta variante es mejor, ya que permite identificar rápidamente las llaves primarias y su correspondencia con las foráneas. Si el espacio de trazado lo permite, prefiera esta alternativa.

DONADOR ACTIVIDAD

DONADOR * IDdonador NomDonador DirDonador RFC IDTipoDonador IDActividad

ACTIVIDAD * IDActividad DescripActividad MontoAportado


Representar relaciones

El siguiente paso es agregar relaciones; se colocarán líneas no curvas que unan aquellas tablas que tengan atributos de correspondencia (correspondencia llave primaria / llave foránea). En nuestro ejemplo, la llave primaria de Actividad (Actividad.IDActividad) corresponde a una llave foránea en Donador (Dona-dor.IDActividad).

El número de relaciones en un modelo de datos, será igual al número de llaves foráneas que se tengan en el mismo, obviamente, en correspondencia con las lla-ves primarias de otras tablas.




Definir claramente las relaciones entre tablas es importante por cuestiones de integridad de datos, ya que las relaciones determinan los dominios dependientes del modelo de datos, y limitan las operaciones de agregado, modificación y eli-minado de registros.


Representar cardinalidad

La cardinalidad es la correspondencia de registros de una relación; dicho de otra forma, por cada uno de los registros de una tabla, cuántos de igual valor en llave puede haber en la otra.

Una clave de puesto es única (UNO), pero puede ser que muchos empleados per-tenezcan a una determinada clave de puesto (MUCHOS).

La cardinalidad puede ser de los siguientes tipos:

UNO

UNO O MUCHOS

En el caso de una relación, la tabla que posee la llave primaria siempre tendrá la cardinalidad UNO, mientras que la que posee la llave foránea, siempre tendrá la cardinalidad UNO O MUCHOS. Esta última afirmación es teóricamente cuestio-nable, ya que no es la única posibilidad; nosotros mencionamos el escenario co-mo el más común e indicado.

Esto es lógico: la que tiene la llave primaria no puede repetir su valor de llave, mientras que la que tiene la llave foránea, posee su propia llave primaria, y no existe impedimento de que la llave foránea repita.


Cuando establecemos una relación de este tipo, decimos que hay una relación de UNO A MUCHOS, que es la normalidad en la mayoría de los casos.

El diagrama DER, en la teoría, acepta otros supuestos:

Relación UNO A UNO: nosotros la desechamos en imple-mentación, en virtud de que esta relación implicaría que las dos tablas tuvieran la misma llave primaria; si es así, lo que procede es unir los campos de dichas tablas en una sola tabla.

Relación MUCHOS A MUCHOS: nosotros la desechamos en implementación, ya que termina convirtiéndose en una tabla intermedia (o tabla de relación), que está for-mada por las llaves primarias de las tablas que une.

A los registros de tablas relacionadas cuyos valores en los campos de coinciden-cia son los mismos, se les llama registros de coincidencia.

Hasta el momento, nuestro modelo quedaría:




Representar opcionalidad

La opcionalidad es el grado de obligatoriedad que tiene un registro de poseer re-gistros de coincidencia en una tabla relacionada. La verdad es que las relacio-nes entre tablas son por lo general una posibilidad de registros de coincidencia.

Que la relación sea de UNO A MUCHOS, no quiere decir que necesariamente por cada registro en la entidad fuerte debe haber muchos en la entidad débil; es sólo la posibilidad. Hay casos en los cuales la relación es de dependencia necesaria, por ejemplo, si no hay donación no hay donador, entonces, la relación DONA-CION – DONADOR no es opcional.

Hay ocasiones en que la cardinalidad no es necesaria, y en ese caso decimos que hay opcionalidad.

En el caso que hemos sugerido hasta el momento (Relación DONADOR – ACTI-VIDAD), tenemos que ACTIVIDAD es un catálogo de aquello a lo que el donador puede dedicarse. Al iniciar las operaciones con el sistema, no se tienen donado-res registrados, ya que los iremos registrando conforme las donaciones vayan llegando; de acuerdo a nuestro modelo actual, eso no es posible:




Nuestro diagrama nos dice lo siguiente: cada registro de ACTIVIDAD tiene rela-cionados necesariamente UNO O MUCHOS registros en DONADOR. Eso no es cierto, ya que puede ser que exista alguna actividad que no posea a ningún do-nador relacionado todavía. En ese caso, DONADOR tiene opcionalidad.

La opcionalidad se representa con un pequeño círculo que pretende dar a en-tender CERO.

Agregaremos la opcionalidad, del lado del DONADOR; después de la opcionali-dad, quedaría:

Que indicaría lo siguiente: cada registro de ACTIVIDAD tiene relacionados nece-sariamente CERO, UNO O MUCHOS registros en DONADOR. Esto ya es cierto.

La opcionalidad se presenta del lado de las entidades débiles de la relación; casi siempre los catálogos de características clasificadas son entidades fuertes (ES-TADO, ACTIVIDAD, MEDIO, TIPODONADOR), y las entidades débiles de la rela-ción tienen opcionalidad (DONADOR, DONACION), ya que el catálogo existe aun y cuando no existan registros de dicha clasificación.

Cuando la relación se da entre un sujeto que no es atributo clasificado (DONA-DOR), y un evento que le es inherente, no habrá opcionalidad si la razón por la cual se registran los datos del sujeto es la existencia del evento (DONACION). Como seguramente intuye, los donadores existen como tales cuando hacen una donación, y no antes; de no ser así, tendría que registrar a todos los donadores potenciales, que puede ser el mundo entero.




Modelo de documentación para el

modelo de datos

Escapa de nuestro alcance la documentación formal del modelo de datos, pero con el objetivo de desarrollar bien el material que nos interesa, se propone la si-guiente documentación mínima para un modelo de datos:

1. Diagramas de Estructura de Datos.

2. Tabla de dominios y tipos de datos.

3. Diagrama de Entidad Relación.

4. Tabla de llaves.

5. Tabla de relaciones.

A continuación se mostrará cómo son estos documentos, utilizando el modelo de nuestro caso de negocio.


Diagramas de Estructura de Datos

ESTADO = * IDEstado + NomEstado

ACTIVIDAD = * IDActividad + DescripActividad + MontoApor-tado

MEDIO = * IDMedio + DescripMedio

TIPODONADOR = * IDTipoDonador + DescripTipo

DONADOR = * IDDonador + NomDonador + DirDonador + RFC + IDTipoDonador + IDActividad

DONACION = * IDDonacion + FechaDonacion + IDDonador + Monto + IDMedio + IDEstado

Resumen: 6 tablas

Campos: 21 campos.

Relaciones entre tablas: 5

Última actualización: 10-febrero-2005, 15:00 horas.

Revisión: Felipe Ramírez.


Tabla de dominios y tipos de datos

Simbología para el dominio de reglas de negocio: NO, No omitir; EP Entero posi-tivo; TM, Todo en mayúsculas; DU, Dato único; DO, Dato opcional (permite nu-los); >0, Mayor a cero.

Campo Dominio de tipo de dato

Longitud Dominio dependiente del modelo Dominio de reglas de negocio

ESTADO IDEstado TinyInt Auto NO, EP, DU, >0. NomEstado Char 25 NO, TM. ACTIVIDAD IDActividad TinyInt Auto NO, EP, DU, >0. DescripActividad Char 25 NO, TM. MontoAportado Money Auto Se calcula automáticamente cuan-

do alguien registra una donación. El monto de la donación se acumu-la en este campo.

MEDIO IDMedio TinyInt Auto NO, EP, DU, >0. DescripMedio Char 20 NO, TM. TIPODONADOR IDTipoDonador TinyInt Auto NO, EP, DU. DescripTipo Char 25 NO, TM. DONADOR IDDonador Auto

numeric Auto NO, EP, DU, >0.

NomDonador varChar 80 NO, TM. DirDonador varChar 80 NO, TM. RFC Char 13 DO; En caso de proporcionarse, su

longitud es mínimo de 12 posicio-nes.

IDTipoDonador TinyInt Auto FK que depende de idtipodo-nador en tipodonador.

NO, EP.

IDActividad TinyInt Auto FK que depende de IDActividad en actividad.

NO, EP.

DONACION IDDonacion Auto

numeric Auto NO, EP, DU.

FechaDonacion Small Date Time

Auto NO, La fecha debe ser válida, y corresponder a una fecha del mis-mo año que el año del sistema, y no superior a la fecha del sistema.

IDDonador Numeric Auto FK que depende de IDDonador de donador.

NO, EP, >0.

Monto Money Auto NO, > 0. IDMedio TinyInt Auto FK que depende de IDMedio

en medio. NO, EP, DU, >0.

IDEstado TinyInt Auto FK que depende de IDEstado

en estado

NO, EP, DU, >0.


Diagrama de Entidad Relación

ESTADO * IDEstado NomEstado

ACTIVIDAD * IDActividad DescripActividad

DONADOR * IDDonador NomDonador DirDonador RFC IDTipoDonador IDActividad

DONACION * IDDonacion FechaDonacion IDDonador Monto IDMedio IDEstado

MEDIO * IDMedio DescripMedio

TIPODONADOR * IDTipoDonador DescripTipo

MontoAportado


Tabla de llaves

Tabla Llave Tipo Campos

estado pkEstado Primary IDEstado

actividad pkActividad Primary IDActividad

medio pkMedio Primary IDMedio

tipodonador pkTipoDonador Primary IDTipoDonador

donador pkDonador Primary IDDonador

donador fkDonador_TipoDonador Foregin IDTipoDonador

donador fkDonador_Actividad Foregin IDActividad

donacion pkDonacion Primary IDDonacion

donacion fkDonacion_Donador Foregin IDDonador

donacion fkDonacion_Medio Foregin IDMedio

donacion fkDonacion_Estado Foregin IDEstado

Tabla de relaciones

Entidad Fuerte Llave utilizada en la relación

Entidad Débil Llave utilizada en la relación

actividad pkActividad donador fkDonador_Actividad

tipodonador pkTipoDonador donador fkDonador_TipoDonador

donador pkDonador donacion fkDonacion_Donador

medio pkMedio donacion fkDonacion_Medio

estado pkEstado donacion fkDonacion_Estado


Vicios del modelo relacional

Son tres los vicios del modelo relacional: Redundancia, Inconsistencia, y Falta de Integridad.

Redundancia

La redundancia es el almacenamiento de los mismos datos varias veces, dentro de una misma base de datos.

Sólo se permite un tipo de redundancia en el modelo relacional, llamado redun-dancia controlada, que se presenta en la duplicidad de almacenamiento que se tiene en una llave primaria y una llave foránea; esta es necesaria, ya que es la única forma de poder mantener la relación entre los registros de dos tablas.

Este vicio se elimina normalizando la base de datos, de tal forma que los datos queden en la tabla a la que más profundamente pertenezcan, y en ninguna otra parte más. El proceso de normalización excede el alcance de este curso.


Inconsistencia

La inconsistencia se presenta como la diferencia de significado de un mismo dato en diferentes partes de la base de datos.

En un campo en el que se debe capturar el sexo de una persona, por ejemplo, podríamos capturar lo siguiente: Hombre y Mujer, M y F, o H y M; cualquiera ser-ía válida, pero no uniforme.

Al tratar de procesar información en ese formato, deberíamos agregar a las apli-caciones más programación de la necesaria. Hay inconsistencias, por lo que hay que uniformar criterio.

Este vicio se elimina imponiendo restricciones en el momento de captura, o bien generando tablas de atributos clasificado ( sexo = *IDSexo + DescripSexo).

Generar una tabla de atributos clasificados es más eficiente, ya que prepara a su modelo para la explotación de base de datos a gran escala, mediante herramien-tas OLAP, sin necesidad de codificar restricciones al momento de la lectura de datos.

Falta de integridad

La falta de integridad se presenta cuando teniendo dos tablas relacionadas, se eliminan registros en la entidad fuerte, que tienen relacionados registros en la entidad débil de la relación.

En este caso, si se eliminan o modifican los datos de la entidad fuerte, deberán eliminarse o modificarse también los registros en la entidad débil.

Este vicio se elimina imponiendo restricciones para que no sea posible eliminar o modificar un registro de una entidad fuerte, si este tiene registros relacionados en la entidad débil, o bien, haciendo que los registros en la entidad débil tengan la misma suerte que el registro en la entidad fuerte.


Ejercicios


Lab: Identificación de sujetos y eventos

Analice el caso de negocios con detenimiento y trate de identificar los sujetos y eventos. Al final de este ejercicio se encuentra una lista de sujetos y eventos dentro de los cuales podrá escoger.

Eventos:

¿Qué transacciones se desea registrar?

Sujetos:

¿Quién hace las donaciones?

¿En dónde se pueden hacer las donaciones?

¿Qué clasificación se da para los donadores?

¿A qué se dedican los donadores?


¿Cómo se enteraron los donadores?

Opciones a escoger:

Estado Tipo de Donador

Pais Donador

Actividad Donacion

Contribuyente Transaccion

Medio

Empleado

Cliente

FIN DEL EJERCICIO


Lab: Elaboración de diagramas de estructura de

datos del modelo

A partir de la información que proporcionamos en el caso de negocios, elabore los dia-gramas DED de todas las tablas restantes del modelo:

Se tiene un catálogo de Estados, que está compuesto por un identificador del estado de la república en el cual se realizó la donación, y el nombre de dicho estado.

ESTADO = * +

Se tiene un catálogo de Actividades, que está compuesto por el identificador de la actividad preponderante (fuen-te de ingresos) del donador, y la descripción corta de la actividad. Por cuestiones prácticas, en este mismo regis-tro se debe llevar el monto total aportado por actividad preponderante.

ACTIVIDAD = * + +

Se tiene un catálogo de Medios, que está compuesto por el identificador del medio de comunicación a través del cual se enteró el donador de la campaña o petición de donaciones, y la descripción corta de dicho medio.

MEDIO = * +


Se tiene un catálogo de Tipos de donador, que está compuesto por el identificador del tipo de donador, y la descripción del tipo.

TIPODONADOR = * +

Se tienen registradas las Donaciones, que están com-puestas por un identificador de la donación, la fecha en que se realizó la donación, el identificador del donador que la realizó, el monto de la donación, el identificador del medio a través del cual se enteró de la campaña o ne-cesidad, y el identificador del estado en el que se realizó la donación.

DONACION = * + + +

+ +

Se privilegian las claves o identificadores numéricos, en primera instancia porque los manejadores de bases de datos son más eficientes con los datos numéricos, y por-que representan facilidad para captura.

FIN DEL EJERCICIO


Lab: Elaboración del diagrama de entidad

relación

Elabore el Diagrama de Entidad Relación del modelo. Como apoyo, podemos decirle la siguiente estadística.

Número de tablas: 6.

Número de campos: 21.

Número de relaciones: 5.

Opcionalidades: 4.

FIN DEL EJERCICIO


Preguntas de competencia

1. ¿Qué procedimiento seguiría para determinar la composición de una llave primaria para una tabla?

2. ¿Todas las tablas deben tener llave primaria?

3. Considerando una factura ¿Es un sujeto o un evento? Explique su res-puesta.

4. Suponga que se integrara a un proyecto de diseño de modelo de base de datos que ya se encuentra al 50% de avance. Usted detecta irregularida-des y vicios en el modelo. En otras palabras, lo que está diseñado está equivocado ¿Qué haría?

5. Un cliente desea que usted realice un modelo de datos que permita alma-cenar toda la información de su empresa. En la primera entrevista le soli-cita que le de la cotización, señalando cuánto costaría ese trabajo, y cuán-to se tardaría. ¿Qué respuesta le daría al cliente?

Investigación

1. Existen diferentes notaciones para la elaboración de diagramas de enti-dad relación. Investigue al menos 3 notaciones distintas, y mantenga una memoria técnica de las reglas de sintaxis de cada una de las metodolog-ías.

2. Explique qué son las relaciones de no identidad (Non identifying Rela-tionships).

3. Explique el origen del nombre “base de datos relacional”.

4. ¿Se puede documentar una base de datos relacional utilizando UML?

5. Enumere los 4 manejadores de bases de datos relacional líderes en el mercado, señalando la cuota del mercado que está cubriendo cada uno de los productos.

41

Normalización

Contenido:

Objetivos .............................................................................................................. 42 Qué es la normalización................................................................................. 43 Formas normales básicas .............................................................................. 45 Caso de ejemplo ................................................................................................ 46 Dependencias funcionales ............................................................................ 48 1NF (Primera Forma Normal) ..................................................................... 49 2NF (Segunda Forma Normal) ..................................................................... 52 3NF (Tercera Forma Normal) ...................................................................... 55 BCNF (Forma Normal Boyce Codd) ............................................................ 57 Desnormalización ............................................................................................ 58 Ejercicios ............................................................................................................. 60 Lab: Normalización de un modelo de datos ........................................... 61 Preguntas de competencia ........................................................................... 62 Investigación ...................................................................................................... 62

42 Normalizacion

Objetivos

Objetivo de la unidad: Aprenderá el concepto de normalización de bases

de datos y su importancia, y aprenderá a normalizar una base, atendiendo a las formas normales, y las excepciones que apliquen.


1. Aprenderá qué es el proceso de normalización, y por qué es recomendable aplicarlo a un modelo de datos.

2. Aprenderá los conceptos de dependencias funcionales.

3. Aprenderá la aplicación de las formas normales elementales para el manejo de bases de datos (1NF, 2NF, 3NF, BCNF).

4. Aprenderá los supuestos en donde se recomienda desnormalizar.

Normalización 43

Qué es la normalización

El modelo relacional de bases de datos está basado en el modelo de álgebra rela-cional y en la teoría de conjuntos. Esto quiere decir que entre más se apeguen las estructuras de datos a los esquemas del modelo relacional, más eficiente será la recuperación y explotación de información.

Una forma de procurar que las estructuras de las bases de datos se apeguen a las reglas del álgebra relacional, es aplicando el proceso denominado normalización, que consiste en aplicar reglas específicas que permitan a los datos tener una es-tructura de cohesión que permita llegar de cualquier elemento del modelo a cualquier otro elemento, utilizando relaciones entre los elementos en un am-biente de redundancia controlada.

Los beneficios que se obtienen con la normalización son los siguientes:

Se evita la redundancia innecesaria de datos. Sólo se permite la re-dundancia de valores en los atributos llave (primaria, foránea), y sólo con el fin de que sean posibles las relaciones entre elementos.

Se evitan la inconsistencia de los datos. Al evitarse la redundancia in-necesaria, al actualizar un dato, ese dato queda actualizado para cual-quier aplicación.

44 Normalizacion

Se evita la falta de integridad de los datos. Al formar relaciones obliga-torias entre los elementos, se evita la eliminación o actualización de en un elemento, que son requeridos por otro elemento.

Normalización 45

Formas normales básicas

Al conjunto de reglas que deben aplicarse al modelo de datos para que sea con-siderada normalizada, se le llaman formas normales (normal forms, o NF). Aun-que hay un gran número de reglas en el álgebra relacional, para efectos de las bases de datos, se consideran básicas las primeras tres formas normales, que son:

1NF (Primera forma normal): Todos los atributos son atómicos.

2NF (Segunda forma normal): Todos los atributos no atómicos tienen dependencia funcional completa con la llave primaria.

3NF (Tercera forma normal): No existen dependencias funcionales transitivas.

Las formas normales son acumulativas, es decir, que cada forma normal exige el cumplimiento de la anterior.

46 Normalizacion

Caso de ejemplo

Imagine que la facturación de una compañía de venta de suministros de cómputo está siendo mantenida en una hoja electrónica de cálculo, y desea ponerse en una base de datos. Cada vez que un cliente realiza una compra, se registra la in-formación de la factura, del cliente, de los productos que está comprando y las promociones que le fueron otorgadas.

La compañía por lo pronto maneja un límite máximo de 3 promociones por pro-ducto, en cada venta.

Una parte de los registros están así:

Donde:

NumFact: Número de la factura.

FechaFact: Fecha en que se realiza la factura.

NumClie: Número que identifica a un cliente.

NumFact FechaFact NumClie Correos CodProd DescProd PR1 PR2 PR3 PrecioVenta Cant Umed DescUMed

2345 01/01/2011 101 [email protected], [email protected] 3903 Unidad USB 20GB 6M D15 200.00$ 2 PZA Pieza

2345 01/01/2011 101 [email protected], [email protected] 5632 Monitor HDTV 40" 6M 6,000.00$ 1 KIT Kit

2346 02/01/2011 124 [email protected] 3903 Unidad USB 20GB 6M D15 200.00$ 3 PZA Pieza

2347 02/01/2011 150 6722 Impresora láser HP D15 3,000.00$ 2 PZA Pieza

Normalización 47

NomClie: Nombre del cliente al que se le emite la factura.

Correos: Correos electrónicos del cliente.

CodProd: Código del producto que se está comprando.

DescProd: Descripción del producto.

PR1: Código de promoción aplicable.



PrecioVenta: Precio al que se vendió el producto.

Cant: Cantidad de unidades vendidas.

UMed: Unidad de medida del producto vendido.

DescUMed: Descripción de la unidad de medida.

Se desea pasar la información a una base de datos relacional que esté bien nor-malizada.

48 Normalizacion

Dependencias funcionales

Antes de entender las reglas de normalización, es necesario entender el concep-to de dependencias funcionales. Una dependencia funcional se entiende cuando un atributo es determinante de otro: X → Y.

Es fundamental que recordemos que hay atributos primos (forman parte de la llave primaria), y atributos no primos (no forman parte de la llave primaria). También debemos recordar que las llaves pueden ser simples (un atributo pri-mo), o compuestas (dos o más atributos). La llave está formada por la totalidad de los atributos primos.

Existen diferentes tipos de dependencia funcional:

Dependencia Funcional Completa: Es cuando un atributo no primo está determinado por la totalidad de la llave primaria.

Dependencia Funcional Parcial: Es cuando, existiendo una llave prima-ria compuesta, un atributo no primo es determinado por parte de la llave primaria, pero no por su totalidad.

Dependencia Funcional Transitiva: Es cuando un atributo no primo es determinado por otro atributo no primo.

Normalización 49

1NF (Primera Forma Normal)

Se cumple con la primera forma normal (1NF), sí y sólo sí:

1. La tabla tiene una llave primaria.

2. La llave primaria no contiene valores nulos.

3. Se tienen atributos uniformes a nivel registro.

4. Todos los atributos son atómicos.

Un atributo atómico es aquél que contiene un solo dato, y no puede dividirse. La división puede darse de varias maneras: a) un atributo contiene varios datos, o b) porque un mismo dato puede ponerse sin problemas en varios atributos, dado que en esencia es lo mismo.

Por atributos uniformes, nos referimos a que en una tabla todos los registros tie-nen el mismo número de atributos (no hay registros con más o con menos atri-butos que otros), y además, los datos contenidos en los atributos tienen el mis-mo dominio (no se permite que para un registro, un dato sea Numérico, y para otro registro sea Alfabético, por ejemplo).

En el ejemplo, se tiene una llave primaria teórica, que es el número de factura, dado que es lo que queremos registrar (NumFact). Se cumple la condición 1.

50 Normalizacion

Como se puede ver, no se tienen valores nulos en los atributos primos, por lo que se cumple la condición 2.

Los atributos son uniformes (condición 3), puesto que todos los registros tienen el mismo número de atributos, y la información contenida es consistente en cuanto al dominio de tipo.

Sin embargo, se dan ciertas violaciones respecto a los atributos atómicos.

Por ejemplo, el dato Correo contiene más de un dato en su contenido.

La forma de resolverlo es generando copias del registro. Cada valor distinto con-tenido en Correo constituye la variación entre uno y otro registro. La tabla que-daría como sigue.

Otra violación es que se coloca el mismo dato en diferentes atributos. Cualquier clave de promoción puede ser alimentada en PR1, PR2 y PR3, de forma indistin-ta. En ese caso, estamos hablando del mismo dato en tres atributos. En nuestra última solución, vea cómo se manifiesta este fenómeno.

La forma de resolverlo también es generar copias de registro para cada promo-ción encontrada y eliminar los atributos innecesarios, dejándose sólo un atributo para el dato.

NumFact FechaFact NumClie NomClie Correos CodProd DescProd PR1 PR2 PR3 PrecioVenta Cant

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB 6M D15 200.00$ 2

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB 6M D15 200.00$ 2

2345 01/01/2011 101 Juan Pérez [email protected] 5632 Monitor HDTV 40" 6M 6,000.00$ 1


2346 02/01/2011 124 Ana Aguilar [email protected] 3903 Unidad USB 20GB 6M D15 200.00$ 3

2347 02/01/2011 150 Antonio Ortiz 6722 Impresora láser HP D15 3,000.00$ 2

Normalización 51

La solución quedaría como sigue:

Obviamente, el resultado de aplicar la 1NF dista mucho de ser ineficiente. Mu-chos datos se repiten muchas veces sin necesidad, pero es en las siguientes for-mas normales donde eso se corrige.

NumFact FechaFact NumClie NomClie Correos CodProd DescProd PR1 PR2 PR3 PrecioVenta Cant

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB 6M 200.00$ 2

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB D15 200.00$ 2

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB 6M 200.00$ 2

2345 01/01/2011 101 Juan Pérez [email protected] 3903 Unidad USB 20GB D15 200.00$ 2



2346 02/01/2011 124 Ana Aguilar [email protected] 3903 Unidad USB 20GB 6M 200.00$ 3

2346 02/01/2011 124 Ana Aguilar [email protected] 3903 Unidad USB 20GB D15 200.00$ 3

2347 02/01/2011 150 Antonio Ortiz 6722 Impresora láser HP D15 3,000.00$ 2

52 Normalizacion

2NF (Segunda Forma Normal)

Se está en segunda forma normal (2NF), si se cumple con la primera forma nor-mal (1NF), y sí y sólo sí, todos los atributos no primos tienen dependencia fun-cional completa, es decir, que están determinados por la totalidad de la llave primaria. Esto significa, que no debe haber dependencias funcionales parciales, o ausencia de dependencia.

Una forma empírica de explorar las dependencias funcionales, es observar si, pa-ra cada valor de llave, el valor de un atributo no primo permanece constante.

En caso que se detecte que no existe dependencia funcional completa por parte de algún atributo no primo, es necesario separar los datos en una tabla alterna, a la cual generalmente deberá agregarse la llave de la tabla original, a fin de man-tener la relación de los datos.

Concentrémonos en a siguiente porción de datos de ejemplo, relacionado con la factura 2345:

NumFact FechaFact NumClie CodProd DescProd PrecioVenta Cant Umed DescUMed

2345 01/01/2011 101 3903 Unidad USB 20GB 200.00$ 2 PZA Pieza

2345 01/01/2011 101 5632 Monitor HDTV 40" 6,000.00$ 1 KIT Kit

Normalización 53

Queda claro que cuando NumFact es 2345, FechaFact es 01/01/2011, y que NumClie es 101; si observamos bien, se trata de los datos generales de la factu-ra. Pero CodProd, DescProd, PrecioVenta, Cant, UMed y DescUMed no son constantes, así que dan lugar a una nueva tabla, que hereda la llave de la tabla original; si observamos bien, se trata de los productos facturados.

La solución a este dilema sería como sigue (solución no definitiva):

Y en otra tabla:

Nótese que para la nueva tabla, la llave es compuesta, incluyendo la llave de la tabla original. Otra solución que suele darse, es que a la nueva tabla se le agrega un atributo identificador, y los datos que antes deberían ser llave, quedan como atributos no primos, que a fin de cuentas serán llave foránea para darle integri-dad al modelo. Esta alternativa se sugiere cuando la llave primaria es compuesta por muchos atributos. Visto en datos, sería de esta forma:

Entendido lo que es necesario hacer para alcanzar la segunda forma normal, nuestro modelo quedaría de la siguiente manera:

FACTURA

NumFact FechaFact NumClie

2345 01/01/2011 101

NumFact CodProd DescProd PrecioVenta Cant Umed DescUMed

2345 3903 Unidad USB 20GB 200.00$ 2 PZA Pieza

2345 5632 Monitor HDTV 40" 6,000.00$ 1 KIT Kit

Partida NumFact CodProd DescProd PrecioVenta Cant Umed DescUMed

435 2345 3903 Unidad USB 20GB 200.00$ 2 PZA Pieza

436 2345 5632 Monitor HDTV 40" 6,000.00$ 1 KIT Kit

NumFact FechaFact NumClie

2345 01/01/2011 101

2346 02/01/2011 124

2347 02/01/2011 150

54 Normalizacion

DETALLEFACTURA

CLIENTES

CORREOSCLIENTE

PRODUCTOS

PROMOCIONESPRODUCTOS

NumFact CodProd PrecioVenta Cant Umed DescUMed

2345 3903 200.00$ 2 PZA Pieza

2345 5632 6,000.00$ 1 KIT Kit

2346 3903 200.00$ 3 PZA Pieza

2347 6722 3,000.00$ 2 PZA Pieza

NumClie NomClie

101 Juan Pérez

124 Ana Aguilar

150 Antonio Ortiz

NumClie Correos

101 [email protected]



CodProd DescProd

3903 Unidad USB 20GB

5632 Monitor HDTV 40"

3903 Unidad USB 20GB

6722 Impresora láser HP

CodProd PR1

3903 6M

3903 D15

5632 6M

6722 D15

Normalización 55

3NF (Tercera Forma Normal)

Se está en tercera forma normal (3NF), si se cumple con la segunda forma nor-mal (2NF), y sí y sólo sí, no existen dependencias funcionales transitivas (depen-dencia de un atributo no primo, de otro atributo no primo que actúa como llave).

En nuestro ejemplo, la única dependencia funcional transitiva se da en la tabla que almacena el detalle de la factura.

56 Normalizacion

En este caso, existe una dependencia funcional transitiva entre UMed y Des-cUMed, en ese sentido, se debe decidir cuál de los dos campos es el que ope-rará como llave, y es el campo que permanecerá en la tabla. Los campos que tienen la dependencia funcional, pasarán a formar una nueva tabla, quedan-do como sigue.

DETALLEFACTURA

UNIDADMEDIDA

NumFact CodProd PrecioVenta Cant Umed

2345 3903 200.00$ 2 PZA

2345 5632 6,000.00$ 1 KIT

2346 3903 200.00$ 3 PZA

2347 6722 3,000.00$ 2 PZA

Umed DescUMed

PZA Pieza

KIT Kit

PZA Pieza

PZA Pieza

Normalización 57

BCNF (Forma Normal Boyce Codd)

Se le llama llave candidata al conjunto de atributos mínimo, suficiente y necesa-rio para identificar como único un registro dentro de una tabla, pero que no es la llave primaria, aunque podría serlo.

Esto se da cuando se tienen dos atributos identificadores, y hay que elegir uno para que sea la llave primaria. Un ejemplo clásico es cuando todos los trabajado-res de una compañía cuentan con identificación de seguridad social: el número de empleado es la llave primaria de la tabla EMPLEADOS, pero el ID de seguri-dad social podría ser también la llave primaria.

Se está en BCNF cuando todos los atributos no primos tienen dependencia fun-cional completa con la llave candidata.

Si un modelo está en BCNF, está indudablemente en 3NF, pero no todo el modelo que está en 3NF, está en BCNF; esto principalmente sucede cuando la llave pri-maria es compuesta, y la llave candidata es simple, lo que nos lleva a cuestionar si no era más eficiente elegir como llave primaria a la candidata.

58 Normalizacion

Desnormalización

El proceso de desnormalización implica violar las formas normales con el fin de proporcionarle al uso de la base prestaciones de desempeño o de economía de recursos.

El modelo de base de datos relacional se basa en el álgebra relacional, y la nor-malización es un proceso que ayuda a que el modelo esté estructurado y pueda utilizarse de una manera eficiente. Esto es, al menos en teoría.

Existen tres formas básicas de desnormalizar:

Creación de llave primaria ficticia.

Partición horizontal.

Partición vertical.

La creación de llave primaria se da cuando, para no tener una llave primaria compuesta de muchos campos, se genera una llave que no forma parte de los da-tos inherentes a lo que se quiere registrar: generalmente es una clave numérica consecutiva, y se pone sólo con el objeto de identificar. Esto origina que los cam-pos que originalmente eran la llave primaria se constituyen como una llave can-didata, y con ello se generen dependencias funcionales transitivas.

Normalización 59

Por otro lado, un modelo de base de datos normalizado no siempre es eficiente dependiendo de la volumetría de los datos. Muchos datos complican la acción de recuperar información, o de cálculo de información.

Al normalizar, las dependencias entre tablas terminan siendo siempre relaciones uno a muchos. Las reglas de normalización ordenan que dos tablas que tienen la misma llave primaria deben juntarse en una sola, por lo cual las relaciones uno a uno no son válidas.

Pero imagine que hay una tabla de una biblioteca, con millones de registros, en donde se hacen miles de consultas, pero el resultado del 90% de las consultas tienen que ver sólo con los libros más demandados, que son el 5% del total de los libros. ¿Tiene caso barrer los millones de registros cada vez? La respuesta es que, desde el punto de vista del performance sería conveniente tener una tabla con el 5% más utilizado, y en caso de que no se encuentre el libro en esa tabla, se proceda a buscar en una tabla con los mismos atributos y la misma llave, que contenga el resto de los registros. Cuando se divide una misma tabla, dejando una parte de los registros en una tabla y el resto en otra, se le llama partición horizontal. Otro uso muy común de las particiones horizontales son la división de datos por periodo de tiempo, es decir, en la tabla de operación se dejan los datos del año en curso, mientras que los datos de los años anteriores se guardan en una tabla de datos históricos, por ejemplo.

También se da el caso que una tabla tenga una gran cantidad de atributos, pero que una gran cantidad de ellos se encuentren sin datos para la mayoría de los registros. En ese caso, se puede dejar una tabla con los atributos que general-mente tienen contenido, y crear otra tabla con la misma llave, que contenga los atributos que generalmente están vacíos o sin valor. A esta división se le llama partición vertical.

60 Normalizacion

Ejercicios

Normalización 61

Lab: Normalización de un modelo de datos

Se tiene la siguiente información. Aplique el proceso de normalización. Conteste las pre-guntas:

1. Cuántas violaciones encontró respecto a la 1NF. ¿Cómo se resolvieron?

2. ¿Cuántas tablas quedaron después de aplicar la 2NF?

3. ¿Cuántas tablas quedaron después de aplicar la 3NF?

4. ¿Es necesario aplicar BCNF? Explique su respuesta.

FIN DEL EJERCICIO

IDPeli IDActor IDNacPeli NomPeli NomActor DNacionalidaPeli Genero1 Genero2 OtroGen

1892 2 1 Rambo Sylvester Stallone Estadounidense Acción Romance

1893 3 1 Batman Dark Knight Christian Bale Estadounidense Acción Drama SC, Heroes

1893 4 1 Batman Dark Knight Gary Oldman Estadounidense Acción Drama SC, Heroes

1894 5 2 Pepe El toro Pedro Infante Mexicana Drama Comedia

1895 4 1 The Professional Gary Oldman Estadounidense Drama

62 Normalizacion


1. En una empresa las consultas son complicadas de desarrollar, y el des-empeño de la recuperación de datos es muy lento. ¿Cómo podría la nor-malización agilizar las consultas?

2. El administrador de base de datos, por cuestiones de espacio en disco, decidió aplicar de emergencia una partición horizontal. No le avisó a los desarrolladores de la aplicación que consume la base de datos. ¿Qué po-sibles efectos puede tener eso para los usuarios de la aplicación?

3. Refiera un escenario en el cual usted recomendaría la partición horizon-tal. Sustente su respuesta.

4. Un cliente se niega a que la base de datos que usted está diseñando sea normalizada, porque él no cree que sea benéfico. ¿Aceptaría esa restric-ción por parte de su cliente?

5. ¿Se puede normalizar una base de datos en Excel?

6. Una compañía tiene una base de datos en operación, con una gran canti-dad de información. La quiere normalizar, pero no quiere perder datos en el proceso. ¿Cuál sería la estrategia que usted propondría para realizar la tarea sin riesgos?

7. ¿Considera usted que el volumen de registros es determinante respecto a si de debe normalizar o no?

Investigación

1. Investigue si hay más reglas de normalización, posteriores a BCNF, y en su caso, explíquelas.

2. Visite al menos 4 organizaciones que tengan bases de datos en operación e identifique incumplimientos en las reglas de normalización hasta BCNF.

63

Diseño de bases de datos con

ERwin

Contenido:

Objetivos .............................................................................................................. 64 ¿Qué es una herramienta CASE? ................................................................. 65 La herramienta CASE ERwin ........................................................................ 66 El entorno de trabajo de ERwin .................................................................. 67 Ejercicios ............................................................................................................. 68 Lab: Creando una base de datos en abstracto con el software ERwin .................................................................................................................... 69

Presentación del caso de negocio. ........................................................... 69 Ingresar a CA ERwin ...................................................................................... 70 Creación de entidades ................................................................................... 72 Establecer relaciones entre entidades .................................................. 79

Preguntas de competencia ........................................................................... 81 Investigación ...................................................................................................... 81

64 Diseño de bases de datos con ERwin

Objetivos

www.Aprenda.mx :: Knowledge Providers

Objetivos del módulo

1. Conocerá los la interfaz de la herramienta CASE Erwin

2. Comprenderá los apoyos que Erwin ofrece para el diseño de bases de datos.

3. Aprovechará las ventajas de contar con una herramienta CASE para el desarrollo conceptual de un modelo de datos.

Objetivo de la unidad: El objetivo de la unidad es que el alumno sea com-

petente para aprovechar las facilidades de una herramienta CASE como es el ca-so de ERwin para realizar la actividad del modelado de datos.


1. Conocerá la interfaz de la herramienta CASE ERwin.

2. Comprenderá los apoyos que ERwin ofrece para el diseño de bases de datos

3. Aprovechará las ventajas de contar con una herramienta CASE para el desa-rrollo conceptual de un modelo de datos.

Diseño de bases de datos con ERwin 65

¿Qué es una herramienta CASE?


¿Qué es una herramienta CASE?

1. Un software cuyo propósito es ayudar al profesional en TI a obtener resultados de calidad al ayudar en la automatización de actividades durante varias de las etapas del ciclo de vida de una aplicación

2. Las etapas pueden ser tales como:

– Identificar requerimientos

– Diseñar modelos de datos

– Producir prototipos

Desde sus comienzos, el software se pensó como una manera de apoyar a diver-sas profesiones tales como la contabilidad, administración, medicina, etc. Fue so-lo cuestión de tiempo para que surgiera la idea de tener software que apoye en el desarrollo de mas software. Debido a esto surgieron las herramientas CASE (Computer Aided Software Engineering).

El propósito de estas, es apoyar en los procesos de producción y mantenimiento de soluciones informáticas en casi todas sus fases y rubros.

Este tipo de apoyos, se pueden manifestar entre otros en fases tales como:

Identificación de requerimientos

Diseño de modelos de datos

Producción de prototipos

Para nuestro objeto de estudio, hemos elegido ERwin por sus facilidades para el modelado de datos; característica afín a nuestro tema de estudio que son las ba-ses de datos.


La herramienta CASE ERwin


La herramienta CASE ERwin

1. Es una herramienta CASE especializada en modelado de datos y diseño de bases de datos

2. Posee las siguientes capacidades:

– Modelado de datos físico

– Transformación de modelo de datos lógicos a físicos

– Generación automatizada de scripts a partir de modelos físicos

– Etc.

La herramienta ERwin, es una herramienta CASE cuya orientación es hacia apo-yar al profesional de TI en cuanto a la concepción, desarrollo e implementación de modelos de datos.

El software ERwin posee muy variadas capacidades, pero entre las más impor-tantes podemos mencionar:

Modelado de datos físico –representaciones lógicas a través de las cua-les se pueden obtener los modelos físicos.

Transformación de modelo de datos lógicos a físicos – Modelos que implementa detalles de atributos, udts, etc.

Generación automatizada de scripts a partir de modelos físicos – Lis-tos para su ejecución por parte del RDBMS que se esté utilizando (soporta la mayoría de los gestores de base de datos disponibles)


El entorno de trabajo de ERwin


El entorno de trabajo de ERwin

Toolbar

ModelExplorer

DiagramWindow

El entorno de trabajo, es el medio a través del cual interactuaremos con el soft-ware en cuestión; en el caso de ERwin tiene tres secciones principales cuyos nombres hemos mantenido en inglés para facilitar su identificación en la docu-mentación del producto:

Toolbar: En esta area podemos encontrar el acceso a todas las opciones de formateo, creación de elementos y control de la funcionalidad del pro-grama en conjunto con los menús superiores a esta.

Model Explorer: Es una representación gráfica en forma de árbol que nos permite un rápido acceso a los diferentes elementos de nuestro modelo, sean estos entidades, atributos de las mismas, relaciones, etc.

Diagram Window: Es la sección donde encontraremos la representación gráfica de nuestro modelo, podemos tener múltiples diagramas abiertos a la vez en cuyo caso nos apoyaremos con los tabs que aparecen en su parte inferior para un más ágil acceso.

Naturalmente, dentro de estas tres grandes áreas, se tiene acceso a las diversas funcionalidades del software.

Sin embargo, es mejor si las conocemos mediante la realización de una práctica y las iremos comentando conforme las vayamos utilizando.


Ejercicios


Lab: Creando una base de datos en abstracto

con el software ERwin

En este laboratorio se conocerán los elementos básicos de CA ERwin durante la creación de un modelo lógico de base de datos.

Presentación del caso de negocio.

Se nos ha solicitado un modelo de datos tal que sirva para controlar la asistencia a las citas de una estética canina; esto a modo de prueba de concepto por lo que los requerimientos de registro son bastante básicos y laxos en sus demandas, les interesa tener un catálogo de las mascotas que se atienden y a las que se les pro-grama una cita así como de quienes son sus dueños y poder contactarlos para confirmar la cita.

De las mascotas les interesa saber la raza y la edad y a quién pertenecen; de los dueños, les interesa la información de contacto y en cuanto a la cita lo que les gustaría tener a la mano es la hora de las citas programadas para cada día y si se asistió por parte del cliente o no.

Con base a lo expuesto, podemos elaborar una lista de entidades identificadas y sus atributos (la definición formal de los tipos correspondientes la haremos en unos momentos:

Cita

Mascota

Raza

Propietario

Al investigar con el cliente, percibimos las siguientes observaciones:

1. Un propietario puede tener múltiples mascotas, pero cada mascota solo tiene un responsable de ella

2. Todo perro tiene una raza, aunque sea la denominada “mestiza”

3. Las citas se generan para la mascota en específico.


Definamos la siguiente tabla para que sea nuestra guía documental:

Campo Dominio de tipo de dato

RAZA ClaveRaza int (identity) NombreRaza varchar MASCOTA ClaveMascota int (identity) ClavePropietario Int ClaveRaza Int Nombre varchar FNacimiento smalldatetime PROPIETARIO ClavePropietario int (identity) Direccion varchar Telefono1 varchar Telefono2 varchar Nombre varchar CITA Folio int (identity) FechaHora smalldatetime Asistio int

Complementémosla con una abreviada tabla de relaciones:

Entidad Fuerte Entidad Débil

Raza Mascota

Propietario Mascota

Mascota Cita

Es hora de poner a funcionar la herramienta al utilizarla para crear la base de datos de ejemplo.

Ingresar a CA ERwin

1. Ejecute el programa CA ERwin, haciendo clic en Inicio – Todos los progra-mas – Computer Associates ERwin 4.0 – Erwin 4.0.

2. De inicio se nos preguntará si deseamos abrir algún modelo ya existente o crearemos uno nuevo, tal como es nuestro caso, por lo que solicitaremos esta última opción.


3. Seleccionemos un tipo de modelo Logical (Lógico), la diferencia contra las op-ciones que incluyen la parte física es que especificaríamos de una vez en el modelo el RDBMS destino y los tipos de datos nativos para tal efecto. Para efectos del ejercicio con la parte lógica es suficiente por ahora. La respuesta será accesar al area de trabajo de ERwin que se muestra a continuación.


Creación de entidades

4. Creemos ahora nuestra primera entidad Raza, seleccionemos el elemento En-tities dentro del Model Explorer e invoquemos su menú contextual con el botón derecho del mouse, este aparecerá y nos permitirá indicarle que de-seamos una nueva entidad.

De inmediato ERwin generará la entidad en el área Diagram Window, pero muy hacia esquina superior izquieda, siéntase libre de arrastrar la entidad provisio-nalmente generada con un nombre genérico a donde se pueda trabajar con más comodidad dentro del área correspondiente.


5. Observe que ahora ha aparecido la entidad debajo del grupo Entities y que podemos expandirlo para ver que posee aún un par de cosas por debajo del nivel de entidad.

6. Asignemos ahora el nombre correspondiente a la entidad, acordamos que ser-ía la entidad Raza, esto lo hacemos escribiendo directamente en el título de la misma o bien acudimos de nuevo al menú contextual pero ahora en la entidad específica que deseamos renombrar; incluso una tercera alternativa muy con-veniente es invocar el menú contextual directamente de la figura de la entidad en nuestro diagrama; tomemos la opción del menú contextual


7. Una vez renombrada, procedamos a indicar los atributos que restan, esto lo podemos lograr nuevamente con un menú contextual sobre la entidad a afec-tar en nuestro Model Explorer, pero es más conveniente obtener el siguiente menú contextual sobre la entidad en nuestro Diagram Window y seleccionar la opción Attributes como se muestra en la siguiente figura:

Esto nos dará acceso al siguiente cuadro de diálogo donde agregaremos el re-sto de los atributos

Note el botón New, selecciónelo para acceder al siguiente cuadro de diálogo donde especificaremos los detalles del atributo a agregar.


Indique como nombre del atributo ClaveRaza y seleccione el tipo Number co-mo corresponde; pulse OK y volveremos al anterior cuadro de diálogo pero ahora podemos ver que ya se despliega el atributo en la lista de la izquierda del mismo. Agregue por su cuenta el siguiente atributo: NombreRaza y con-sidérelo de cadena de caracteres, al tener éxito el listado de atributos debe lu-cir parecido a este:

Note el checkbox que dice Primary Key, asegurándose de que en la lista se encuentra seleccionado el atributo ClaveRaza, active ese checkbox y vea como se convierte el atributo en llave primaria de nuestra entidad. Con esto hemos


terminado con la definición de esta, y lo podemos validar al pulsar OK y ce-rrar el cuadro de diálogo actual y ver como se ha modificado nuestro diagra-ma. Es buen momento para guardar nuestro avance.

Repita el proceso para generar la entidad Mascota de acuerdo a los campos especificados en nuestras anteriores tablas

Su diagrama resultante debe lucir similar a este.


Establecer relaciones entre entidades

8. Como puede verlo, ahora ya tenemos dos entidades que en nuestro concepto estarán relacionadas ya que un perro debe tener una raza (lo señalamos en nuestro apartado de requerimientos); por lo tanto, desde un principio, dise-ñamos la entidad Mascota con un campo llamado ClaveRaza homónimo al campo que conforma la llave primaria de la entidad Raza. Resumamos seña-lando que la entidad Raza será la entidad fuerte y la entidad Mascota será la entidad débil.

Para lograr esto, ubiquemos en la toolbar, la sección dedicada a las relaciones que es la que se muestra a continuación.

Por omisión, ERwin muestra las relaciones utilizando la notación IDEF1X; si se desea, se puede cambiar a que utilice la notación IE (Information Enginee-ring) que es la que utiliza la “pata de cuervo” como símbolo en la entidad débil. Esto se logra a través del menú Model – Model Properties – Notation.

9. Para establecer la relación propiamente entre estas dos entidades, seleccione el botón Identifying relationship en la barra mencionada (Es el que presenta una línea continua con solo un extremo con un círculo sólido).

10. Una vez presionado el referido botón, dé click una sola vez sobre la entidad que será la entidad fuerte (Raza) e inmediatamente después, dé click sobre la entidad débil (Mascota). Como en este caso, preparamos el campo de coinci-dencia para que tuviera exactamente el mismo nombre, ERwin lo reconoce, pero nos pide confirmar si deseamos establecerlo como llave foránea en la en-tidad débil o que tratamiento le debe dar a dichos campos.


11. Como precisamente, esa es nuestra intención, pulsamos OK y se adoptará la correspondiente llave foránea. Su diagrama será algo como lo siguiente

Observe que han cambiado algunas cosas además de la indicación gráfica de la relación establecida señala por el conector terminado en círculo sólido que denota a la entidad Mascota como la entidad débil en la relación:

Las esquinas de la entidad Mascota se han redondeado, para acentuar el recordatorio que es la entidad débil

En nuestro Model Explorer se puede apreciar que los nodos correspon-dientes a ambas entidades poseen nuevos elementos y presentan símbo-los de suma en algunos para indicar que contienen datos adicionales.


12. Demuestre su comprensión completando la creación de las dos restantes en-

tidades y las dos restantes relaciones para cumplir los requerimientos esta-blecidos en el caso de negocios.

FIN DEL EJERCICIO


1. ¿ERWin ayuda a modelar una base de datos, o simplemente permite dia-gramar un modelo ya diseñado?

2. ¿Qué se puede hacer en ERWin, además de diagramar un modelo?

Investigación

1. ¿Qué otras herramientas de diseño y modelo de bases de datos existen en el mercado? Enumere al menos tres productos similares a ERWin.

2. Investigue cuál es la última versión de ERWin, y cuáles son sus principa-les capacidades.

3. ¿Permite ERWin el uso de teclas de atajo (Shortcuts)?

4. Enliste cuántas notaciones de diagrama de entidad relación soporta ER-Win.

5. Elabore el modelo de base de datos de ejemplo (Cruz Roja) en ERWin.

aprenda workbook sql server 2008 - 2 capítulos

Documents