Vous êtes sur la page 1sur 43

REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DE EDUCACION SUPERIOR UNIVERSIDAD ALEJANDRO DE HUMBOLDT SEDE LOS DOS CAMINOS, Seccin: DCNN0702II

Prof. RICARDO GUERRA

DATOS Y MODELO ENTIDAD RELACIN (E-R)

Integrantes Yenny Gonzlez; Heiser A. Daz; Jos Peralta; Julio Urbina;

C.I. V-13.533.262 C.I. V-16.472.720 C.I. V- 13.409.489 C.I. V- 15.147.069

Caracas, 13 de Junio de 2011

Tabla de contenidos
Introduccin.................................................................................................................................3 Datos............................................................................................................................................4 Entidad.........................................................................................................................................4 Atributos......................................................................................................................................5 Tipos de atributos.........................................................................................................................6 Relacin.......................................................................................................................................7 Participacin ...............................................................................................................................7 Papel de la entidad ......................................................................................................................8 Restricciones..............................................................................................................................10 Claves.........................................................................................................................................12 Composicin..............................................................................................................................13 Asociacin..................................................................................................................................14 Modelo Entidad-Relacin .........................................................................................................17 Conclusin.................................................................................................................................40 Bibliografa................................................................................................................................42

Introduccin

El ser humano, a travs de su vida diaria, se comunica con sus semejantes a travs de un lenguaje determinado (oral, escrito, etc.) por medio de las denominadas frases u oraciones. Estas pueden tener diferentes significados pero siempre van a comunicar datos, por consiguiente informacin, siendo ste el precedente fundamental para el desarrollo humano. Del latn datum (lo que se da), un dato es un documento, una informacin o un testimonio que permite llegar al conocimiento de algo o deducir las consecuencias legtimas de un hecho Es importa tener en cuenta que el dato no tiene sentido en s mismo, sino que se utiliza en la toma de decisiones o en la realizacin de clculos a partir de un procesamiento adecuado y teniendo en cuenta su contexto. Por lo general, el dato es una representacin simblica o un atributo de una entidad. En el campo de las humanidades, los datos se consideran como una expresin mnima de contenido respecto a un tema. El conjunto de los datos relacionados constituyen una informacin. Para la informtica, los datos son expresiones generales que describen caractersticas de las entidades sobre las que operan los algoritmos. Estas expresiones deben presentarse de una cierta manera para que puedan ser tratadas por una computadora. En este casos, los datos por s solos tampoco constituyen informacin, sino que sta surge del adecuado procesamiento de los datos. El modelo de datos permite describir las estructuras de datos de la base (el tipo de los datos que incluye la base y la forma en que se relacionan), las restricciones de integridad (las condiciones que los datos deben cumplir para reflejar correctamente la realidad deseada) y las operaciones de manipulacin de los datos (agregado, borrado, modificacin y recuperacin de los datos de la base).

Datos

Datos son los hechos que describen sucesos y entidades."Datos" es una palabra en plural que se refiere a ms de un hecho. A un hecho simple se le denomina "datatem" o elemento de dato. Los datos son comunicados por varios tipos de smbolos tales como las letras del alfabeto, nmeros, movimientos de labios, puntos y rayas, seales con la mano, dibujos, etc. Estos smbolos se pueden ordenar y reordenar de forma utilizable y se les denomina informacin. Los datos son smbolos que describen condiciones, hechos, situaciones o valores. Los datos se caracterizan por no contener ninguna informacin. Un dato puede significar un nmero, una letra, un signo ortogrfico o cualquier smbolo que represente una cantidad, una medida, una palabra o una descripcin. La importancia de los datos est en su capacidad de asociarse dentro de un contexto para convertirse en informacin. Por si mismos los datos no tienen capacidad de comunicar un significado y por tanto no pueden afectar el comportamiento de quien los recibe. Para ser tiles, los datos deben convertirse en informacin para ofrecer un significado, conocimiento, ideas o conclusiones. Entidad Una entidad es una cosa u objeto en el mundo real que es distinguible de todos los dems objetos. Por ejemplo, cada persona en un desarrollo es una entidad. Una entidad tiene un conjunto de propiedades, y los valores para algn conjunto de propiedades pueden identificar una entidad de forma unvoca. Por ejemplo, el D.N.I. 67.789.901 identifica unvocamente una persona particular en la empresa. Anlogamente, se puede pensar en los prstamos bancarios como entidades, y un nmero de prstamo P-15 en la sucursal de Castellana identifica unvocamente una entidad de prstamo. Una entidad puede ser concreta, como una persona o un libro, o puede ser abstracta, como un prstamo, unas vacaciones o un concepto.

Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las mismas propiedades, o atributos. El conjunto de todas las personas que son clientes en un banco dado, por ejemplo, se pueden definir como el conjunto de entidades cliente. Anlogamente, el conjunto de entidades prstamo podra representar el conjunto de todos los prstamos concedidos por un banco particular. Las entidades individuales que constituyen un conjunto se llaman la extensin del conjunto de entidades. As, todos los clientes de un banco son la extensin del conjunto de entidades cliente. Los conjuntos de entidades no son necesariamente disjuntos. Por ejemplo, es posible definir el conjunto de entidades de todos los empleados de un banco (empleado) y el conjunto de entidades de todos los clientes del banco (cliente). Una entidad persona puede ser una entidad empleado, una entidad cliente, ambas cosas, o ninguna. Atributos Los atributos describen propiedades que posee cada miembro de un conjunto de entidades. La designacin de un atributo para un conjunto de entidades expresa que la base de datos almacena informacin similar concerniente a cada entidad del conjunto de entidades; sin embargo, cada entidad puede tener su propio valor para cada atributo. Posibles atributos del conjunto de entidades cliente son id-cliente, nombre-cliente, calle-cliente y ciudad-cliente. Ejemplo: En la vida real, habra ms atributos, tales como el nmero de la calle, el nmero del portal, la provincia, el cdigo postal, y la comunidad autnoma, pero no se incluyen en el ejemplo simple.

Tipos de atributos a) Simples o compuestos: Los compuestos estn formados por un conjunto de atributos, Por ejemplo, nombre-cliente podra estar estructurado como un atributo compuesto consistente en nombre, primer-apellido y segundo-apellido. Mientras que los simples no se pueden dividir, es decir, no estn divididos en subpartes. b) Monovaluados o multivaluados: Los monovaluados slo pueden tener un valor para una entidad particular, mientras que los multivaluados pueden tener ms de un valor. Los multivaluados se representan mediante una elipse con trazado doble. (Por ejemplo el atributo color de la entidad COCHE es un atributo multivaluado, pues un coche puede estar pintado de varios colores).

c) Almacenados o derivados: Los derivados son atributos cuyo valor para una entidad particular puede obtenerse en funcin de los valores almacenados en otros atributos. Se representan mediante una elipse con trazo discontinuo. (Por ejemplo el atributo edad de la entidad PERSONA es un atributo derivado porque se puede obtener en funcin del valor del atributo fecha_ nacimiento).

Un atributo toma un valor nulo cuando una entidad no tiene un valor para un atributo. El valor nulo tambin puede indicar no aplicable, es decir, que el valor no existe para la entidad. Por ejemplo, una persona puede no tener segundo nombre de pila. Nulo puede tambin designar que el valor de un atributo es desconocido.

Relacin Una relacin es una asociacin entre diferentes entidades. Por ejemplo, se puede definir una relacin que asocie al cliente Lpez con el prstamo P-15. Esta relacin especifica que Lpez es un cliente con el prstamo nmero P-15. Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Formalmente es una relacin matemtica con n > = 2 de conjuntos de entidades (posiblemente no distintos). Si E1, E2,,En son conjuntos de entidades, entonces un conjunto de relaciones R es un subconjunto de: {(e1, e2,,en) | e1 E1, e2 E2,,en En} donde (e1,e2,en) es una relacin. Considrense las dos entidades cliente y prstamo de la Figura 2.1. Se define el conjunto de relaciones prestatario para denotar la asociacin entre clientes y prstamos bancarios que los clientes tengan.

Participacin La asociacin entre conjuntos de entidades se conoce como participacin; es decir, los conjuntos de entidades E1, E2,, En participan en el conjunto de relaciones R. Un ejemplar de relacin en un esquema E-R representa que existe una asociacin entre las entidades denominadas en la empresa del mundo real que se modela. Como ilustracin, el cliente individual Lpez, que tiene D.N.I. 67.789.901, y la entidad prstamo P-15 participan en un ejemplar de relacin de prestatario. Este ejemplar de relacin representa que, en la empresa del mundo real, la persona llamada Lpez cuyo nmero de D.N.I. es 67.789.901 ha tomado un prstamo que est numerado como P-15.

Papel de la entidad Es la funcin que desempea una entidad. . Debido a que los conjuntos de entidades que participan en un conjunto de relaciones son generalmente distintos, los papeles estn implcitos y no se especifican normalmente. Sin embargo, son tiles cuando el significado de una relacin necesita aclaracin. Tal es el caso cuando los conjuntos de entidades de una relacin no son distintos; es decir, el mismo conjunto de entidades participa en una relacin ms de una vez con diferentes papeles. En este tipo de conjunto de relaciones, que se llama algunas veces conjunto de relaciones recursivo, es necesario hacer explcitos los papeles para especificar cmo participa una entidad en un ejemplar de relacin. Por ejemplo, considrese un conjunto de entidades empleado que almacena informacin acerca de todos los empleados del banco. Se puede tener un conjunto de relaciones trabaja-para que se modela mediante pares ordenados de entidades empleado. El primer empleado de un par toma el papel de trabajador, mientras el segundo toma el papel de jefe. De esta manera, todas las relaciones trabaja-para son pares (trabajador, jefe); los pares (jefe, trabajador) estn excluidos. manera, todas las relaciones trabaja-para son pares (trabajador, jefe); los pares (jefe, trabajador) estn excluidos. Una relacin puede tambin tener atributos descriptivos. Considrese un conjunto de relaciones impositor con conjuntos de entidades cliente y cuenta. Se podra asociar el atributo fecha-acceso a esta relacin para especificar la fecha ms reciente en que un cliente accedi a una cuenta. La relacin impositor entre las entidades correspondientes al cliente Garca y la cuenta C-217 se describen mediante {(fecha-acceso, 23 mayo 2002)}, lo que significa que la ltima vez que Garca accedi a la cuenta C-217 fue el 23 de mayo de 2002. Un ejemplar de relacin en un conjunto de relaciones determinado debe ser identificado unvocamente a partir de sus entidades participantes, sin usar los atributos descriptivos. Para comprender este punto supngase que deseemos modelar todas las fechas en las que un cliente ha accedido a una cuenta. El atributo

monovalorado fecha-acceso puede almacenar slo una nica fecha de acceso. No se pueden representar varias fechas de acceso por varios ejemplares de relacin entre el mismo cliente y cuenta, ya que los ejemplares de relacin no estaran identificados unvocamente por las entidades participantes. La forma correcta de manejar este caso es crear un atributo multivalorado fechas-acceso que pueda almacenar todas las fechas de acceso. Sin embargo, puede haber ms de un conjunto de relaciones que involucren los mismos conjuntos de entidades. En nuestro ejemplo los conjuntos de entidades cliente y prstamo participan en el conjunto de relaciones prestatario. Adems, supngase que cada prstamo deba tener otro cliente que sirva como avalista para el prstamo. Entonces los conjuntos de entidades cliente y prstamo pueden participar en otro conjunto de relaciones: avalista. Los conjuntos de relaciones prestatario y sucursalprstamo proporcionan un ejemplo de un conjunto de relaciones binario, es decir, uno que implica dos conjuntos de entidades. La mayora de los conjuntos de relaciones en un sistema de bases de datos son binarios. Por ejemplo, considrense los conjuntos de entidades empleado, sucursal y trabajo. Ejemplos de las entidades trabajo podran ser director, cajero, auditor y otros. Las entidades trabajo pueden tener los atributos puesto y nivel. El conjunto de relaciones trabaja-en entre empleado, sucursal y trabajo es un ejemplo de una relacin ternaria. Una relacin ternaria entre Santos, Navacerrada y director indica que Santos acta de director de la sucursal Navacerrada. Santos tambin podra actuar como auditor de la sucursal Centro, que estara representado por otra relacin. Podra haber otra relacin entre Gmez, Centro y cajero, indicando que Gmez acta como cajero en la sucursal Centro. El nmero de conjuntos de entidades que participan En un conjunto de relaciones es tambin el grado del conjunto de relaciones. Un conjunto de relaciones binario tiene grado 2; un conjunto de relaciones ternario tiene grado 3.

Restricciones Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de la base de datos se deben adaptar. En este apartado se examina la correspondencia de cardinalidades y las restricciones de participacin, que son dos de los tipos ms importantes de restricciones. Correspondencia de cardinalidades o razn de cardinalidad, expresa el nmero de entidades a las que otra entidad puede estar asociada va un conjunto de relaciones. La correspondencia de cardinalidades es la ms til describiendo conjuntos de relaciones binarias, aunque ocasionalmente contribuye a la descripcin de conjuntos de relaciones que implican ms de dos conjuntos de entidades. Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de cardinalidades debe ser una de las siguientes: Uno a uno. Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B se asocia con a lo sumo una entidad en A.

Uno a varios. Una entidad en A se asocia con cualquier nmero de entidades en B (ninguna o varias). Una entidad en B, sin embargo, se puede asociar con a lo sumo una entidad en A.

Varios a uno. Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B, sin embargo, se puede asociar con cualquier nmero de entidades (ninguna o varias) en A

Varios a varios. Una entidad en A se asocia con cualquier nmero de entidades (ninguna o varias) en B, y una entidad en B se asocia con cualquier nmero de entidades (ninguna o varias) en A

La correspondencia de cardinalidades apropiada relaciones modela.

para un conjunto de relaciones

particular depende obviamente de la situacin del mundo real que el conjunto de

Restricciones de participacin La participacin de un conjunto de entidades E en un conjunto de relaciones R se dice que es total si cada entidad en E participa al menos en una relacin en R. Por ejemplo, se puede esperar que cada entidad prstamo est relacionada con al menos un cliente mediante la relacin prestatario. Por lo tanto, la participacin de prstamo en el conjunto de relaciones prestatario es total. Si slo algunas entidades en E participan en relaciones en R, la participacin del conjunto de entidades E en la relacin R se llama parcial. En cambio, un individuo puede ser cliente de un banco tenga o no tenga un prstamo en el banco. As, es posible que slo algunas de las entidades cliente estn relacionadas con el conjunto de entidades prstamo mediante la relacin prestatario, y la participacin de cliente en el conjunto de relaciones prestatario es por lo tanto parcial.

Claves Una clave permite identificar un conjunto de atributos suficiente para distinguir las entidades entre s. Las claves tambin ayudan a identificar unvocamente a las relaciones y as a distinguir las relaciones entre s. Es necesario tener una forma de especificar cmo las entidades dentro de un conjunto de entidades dado y las relaciones dentro de un conjunto de relaciones dado son distinguibles. Conceptualmente las entidades y relaciones individuales son distintas; desde una perspectiva de bases de datos, sin embargo, la diferencia entre ellas se debe expresar en trmino de sus atributos. Por lo tanto, los valores de los atributos de una entidad deben ser tales que permitan identificar unvocamente a la entidad. En otras palabras, no se permite que ningn par de entidades tengan exactamente los mismos valores de sus atributos.

Superclave es un conjunto de uno o ms atributos que, tomados colectivamente, permiten identificar de forma nica una entidad en el conjunto de entidades. Por ejemplo, el atributo id-cliente del conjunto de entidades cliente es suficiente para distinguir una entidad cliente de las otras. Claves candidatas Es posible que conjuntos distintos de atributos pudieran servir como clave candidata. Supngase que una combinacin de nombre-cliente y callecliente es suficiente para distinguir entre los miembros del conjunto de entidades cliente. Entonces, los conjuntos {id-cliente} Es posible que conjuntos distintos de atributos pudieran servir como clave candidata. Clave primaria para denotar una clave candidata que es elegida por el diseador de la base de datos como elemento principal para identificar las entidades dentro de un conjunto de entidades. Una clave (primaria, candidata y superclave) es una propiedad del conjunto de entidades, ms que de las entidades individuales. Cualesquiera dos entidades individuales en el conjunto no pueden tener el mismo valor en sus atributos clave al mismo tiempo. La designacin de una clave representa una restriccin en el desarrollo del mundo real que se modela.

Composicin La composicin de la clave primaria para un conjunto de relaciones depende de la estructura de los atributos asociados al conjunto de relaciones R. Si el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto de atributos: clave-primaria(E1) U clave-primaria(E2) U U clave-primaria(En) Describe una relacin individual en el conjunto R. Si el conjunto de relaciones R tiene atributos a1, a2,,am asociados a l, entonces el conjunto de atributos:

clave-primaria(E1) U clave-primaria(E2) U U clave-primaria(En) U {a1, a2,,am} Describe una relacin individual en el conjunto R. En ambos casos, el conjunto de atributos clave-primaria(E1) U clave-primaria(E2) U U clave-primaria(En) Forma una superclave para el conjunto de relaciones. Asociacin Relacin entre dos o ms personas, ideas, cosas o situaciones que tienen algo en comn o a las que se les atribuye alguna semejanza. Un inconveniente de la organizacin de archivos secuenciales es que hay que acceder a una estructura de ndices para localizar los datos lo cual da como resultado ms operaciones de entrada/salida. La organizacin de archivos basada en la tcnica de asociacin (hashing) permite evitar el acceso a la estructura de ndice. En una organizacin de archivos por asociacin se obtiene la direccin del bloque de disco que contiene el registro deseado mediante el clculo directo de una funcin sobre el valor de la clave de bsqueda del registro El trmino cajn (bucket) indica una unidad de almacenamiento que puede guardar uno a ms registros (normalmente un bloque de disco) Funcin de Asociacin Sea K el conjunto de todos los valores de clave de bsqueda y sea B el conjunto de todas las direcciones de cajn Una Funcin de Asociacin h es una funcin de K a B. La funcin de asociacin se emplea para localizar registros para accesos, inserciones y borrados.

Los registros con diferentes valores de claves de bsqueda pueden asociarse al mismo cajn; de este modo, para localizar un registro, se ha de recorrer secuencialmente el cajn entero. Asociacin extensible Hace frente a los cambios del tamao de la BD separando y uniendo los cajones. Como resultado se conserva eficazmente el espacio. Se elige H de manera que genere valores dentro de un rango de enteros binarios de b-bitSe crean tantos cajones como registros haya insertados en el archivo. Empleamos i bits, 0<i<b, que son utilizados como tamao de la BD. Se requieren i bits de la funcin de asociacin H(K) para determinar el cajn apropiado para K. Para localizar el cajn que contiene el valor de la clave de bsqueda Ki, se toman los primeros i bits de H(Ki), se busca la entrada de la tabla que corresponda a esta cadena de bits, y se sigue el puntero del cajn en la entrada de la tabla. Para insertar, si el cajn j, esta lleno hay que dividir el cajn y redistribuir los registros. Si i=ij, solamente una entrada en la tabla de direcciones apunta al cajn j. Incrementar el tamao de la tabla de direcciones para incluir los punteros a los dos cajones que resultan de la divisin. Si i>ij: mas de una entrada en la tabla de direcciones de cajones apunta al cajn j. Se puede dividir j sin incrementar el tamao de la tabla de dir. En ambos casos solamente se necesita recalcular la funcin de asociacin en los registros del cajn j. desplazamiento en una tabla adicional con las direcciones de los cajones el valor de i aumenta o disminuye con el

Asociacin cerrada: Se debe variar un poco el algoritmo de bsqueda para tratar la cadena de desbordamiento. Como se dijo antes, la funcin de asociacin se emplea

sobre la clave de bsqueda para identificar un cajn c. Luego se examinan todos los registros en el cajn c para ver si coinciden con la clave bsqueda, como antes. Adems, si el cajn c tiene cajones de desbordamiento, los registros en todos los cajones de desbordamiento de c se tienen que examinar tambin. La forma de la estructura asociativa que se acaba de describir se denomina algunas veces asociacin cerrada. Asociacin dinmica: Buena para las bases de datos que aumentan y disminuyen de tamao Permite modificar dinmicamente la funcin de asociacin. La funcin de asociacin genera valores en un amplio rango generalmente b-bit enteros, con b = 32. En cualquier momento se emplea slo un prefijo de la funcin de asociacin, para indexar en una tabla de direcciones de cajones. Sea la longitud del prefijo i bits, donde donde 0 <= i <= 32. El tamao de la tabla de direcciones de los cajones es = 2i. Inicialmente i = 0 El valor de i crece y disminuye segn lo hace el tamao de la base de datos. Mltiples entradas en la tabla de direcciones de los cajones pueden apuntar a un cajn. As, el nmero real de cajones es < 2i El nmero de cajones tambin cambia dinmicamente debido a las agrupaciones y divisiones de los cajones. Asociacin extensible una forma de asociacin dinmica

Asociacin esttica: asocia todos los valores de las claves de bsqueda al mismo cajn; esto hace que el tiempo de acceso sea proporcional al nmero de valores de claves de bsqueda en el archivo. En la asociacin esttica la funcin h asocia valores de claves de bsqueda a un determinado conjunto B, de direcciones de cajones. Las bases de datos crecen con el tiempo. Si el nmero inicial de cajones es demasiado pequeo, disminuir el rendimiento debido a los muchos desbordamientos.

Si se anticipa el tamao del archivo en algn momento del futuro, y en consecuencia el nmero de cajones asignados, un aumento significativo de espacio se desperdiciar inicialmente. Si disminuye la base de datos, nuevamente se desperdiciar espacio. Una opcin es la reorganizacin peridica del archivo con una nueva funcin de asociacin, pero es muy costoso. En Estos problemas se pueden evitar empleando tcnicas que permitan que el nmero de cajones se modifique dinmicamente. Modelo Entidad-Relacin Es el modelo ms utilizado en la actualidad para mostrar problemas reales y administrar datos dinmicamente, adems permiten establecer interconexiones (relaciones) entre los datos (que estn guardados en tablas), y trabajar con ellos conjuntamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd de los laboratorios IBM en San Jose (California), no tardo en consolidarse como un nuevo paradigma en los modelos de base de datos. El modelo de datos entidad-relacin (E-R) est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre estos objetos. La estructura lgica general de una base de datos se puede expresar grficamente mediante un diagrama E- R, Los diagramas son simples y claros, cualidades que pueden ser responsables del amplio uso del modelo E-R. Que consta de los siguientes componentes:

Rectngulos, que representan conjuntos de entidades. Elipses, que representan atributos. Rombos, que representan relaciones. Lneas, que unen atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones.

Elipses dobles, que representan atributos multivalorados.

Elipses discontinuas, que denotan atributos derivados. Lneas dobles, que indican participacin total de una entidad en un conjunto de relaciones.

Rectngulos dobles, que representan conjuntos de entidades dbiles

Caractersticas del modelo entidad relacin:


Se compone de varias tablas o relaciones No puede existir dos tablas con el mismo nombre Cada tabla es a su vez un conjunto de registros (filas) Cada registro representa un objeto del mundo real Cada registro consta de varias columnas campos y atributos No pueden existir dos columnas con el mismo nombre en la tabla Los valores almacenados en las columnas deben ser del mismo tipo de datos. Todas las filas poseen el mismo tipo de columnas No se considera el orden como se almacenan los registros en la tabla ni las tablas como se guardan en la base de datos. La informacin puede ser recuperada a travs de sentencias llamadas consultas (querys).

Considrese el diagrama entidad-relacin de la Figura 2.8, que consta de dos conjuntos de entidades, cliente y prstamo, relacionadas a travs de un conjunto de relaciones binarias prestatario. Los atributos asociados con cliente son id-cliente, nombre-cliente, calle-cliente, y ciudad-cliente. Los atributos asociados con prstamo

son nmero-prstamo e importe. Como se muestra en la Figura 2.8, los atributos de un conjunto de entidades que son miembros de la clave primaria estn subrayados. El conjunto de relaciones prestatario puede ser varios a varios, uno a varios, varios a uno o uno a uno. Para distinguir entre estos tipos, se dibuja o una lnea dirigida () o una lnea no dirigida () entre el conjunto de relaciones y el conjunto de entidades en cuestin. Una lnea dirigida desde el conjunto de relaciones prestatario al conjunto de entidades prstamo especifica que prestatario es un conjunto de relaciones uno a uno, o bien varios a uno, desde cliente a prstamo; prestatario no puede ser un conjunto de relaciones varios a varios ni uno a varios, desde cliente a prstamo. Una lnea no dirigida desde el conjunto de relaciones prestatario al conjunto de relaciones prstamo especifica que prestatario es o bien un conjunto de relaciones varios a varios, o bien uno a varios, desde cliente a prstamo. Proceso de diseo en el modelo E-R Identificar las entidades que debe presentar la base de datos. Determinar las cardinalidades de las Interrelaciones establecidas entre las distintas entidades y clasificar estas Interrelaciones entre los tipos: ( 1-1, 1n,n-1, n-n )

Dibujar el diagrama Entidad/interrelacin. Determinar los atributos de cada entidad. Definir la clave primaria (nica) de cada entidad.

Como se realiza un buen modelo entidad relacin El proceso de diseo de una base de datos se gua por algunos principios. El primero de ellos es que se debe evitar la informacin duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y aumentan la probabilidad de que

se produzcan errores e incoherencias. El segundo principio es que es importante que la informacin sea correcta y completa. Si la base de datos contiene informacin incorrecta, los informes que recogen informacin de la base de datos contendrn tambin informacin incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarn mal fundamentadas. Un buen diseo de base de datos es, por tanto, aqul que:

Divide la informacin en tablas basadas en temas para reducir los datos

redundantes.

Proporciona a Access la informacin necesaria para reunir la informacin de

las tablas cuando as se precise.


Ayuda a garantizar la exactitud e integridad de la informacin. Satisface las necesidades de procesamiento de los datos y de generacin

de informes. El proceso de diseo El proceso de diseo consta de los pasos siguientes:

Determinar la finalidad de la base de datos

Esto le ayudar a estar preparado para los dems pasos.

Buscar y organizar la informacin necesaria

Rena todos los tipos de informacin que desee registrar en la base de datos, como los nombres de productos o los nmeros de pedidos.

Dividir la informacin en tablas

Divida los elementos de informacin en entidades o temas principales, como Productos o Pedidos. Cada tema pasar a ser una tabla.

Convertir los elementos de informacin en columnas

Decida qu informacin desea almacenar en cada tabla. Cada elemento se convertir en un campo y se mostrar como una columna en la tabla. Por ejemplo, una tabla Empleados podra incluir campos como Apellido y Fecha de contratacin.

Especificar claves principales

Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequvocamente cada fila, como Id. de producto o Id. de pedido.

Definir relaciones entre las tablas

Examine cada tabla y decida cmo se relacionan los datos de una tabla con las dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones segn sea necesario.

Ajustar el diseo

Analice el diseo para detectar errores. Cree las tablas y agregue algunos registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes necesarios en el diseo.

Aplicar las reglas de normalizacin

Aplique reglas de normalizacin de los datos para comprobar si las tablas estn estructuradas correctamente. Realice los ajustes necesarios en las tablas. Determinar la finalidad de la base de datos Es conveniente plasmar en papel el propsito de la base de datos: cmo piensa utilizarla y quin va a utilizarla. Para una pequea base de datos de un negocio particular, por ejemplo, podra escribir algo tan simple como "La base de datos de

clientes contiene una lista de informacin de los clientes para el envo masivo de correo y la generacin de informes". Si la base de datos es ms compleja o la utilizan muchas personas, como ocurre normalmente en un entorno corporativo, la finalidad podra definirse fcilmente en uno o varios prrafos y debera incluir cundo y cmo va a utilizar cada persona la base de datos. La idea es desarrollar una declaracin de intenciones bien definida que sirva de referencia durante todo el proceso de diseo. Esta declaracin de intenciones le permitir centrarse en los objetivos a la hora de tomar decisiones. Buscar y organizar la informacin necesaria Para buscar y organizar la informacin necesaria, empiece con la informacin existente. Por ejemplo, si registra los pedidos de compra en un libro contable o guarda la informacin de los clientes en formularios en papel en un archivador, puede reunir esos documentos y enumerar cada tipo de informacin que contienen (por ejemplo, cada casilla de un formulario). Si no dispone de formularios, imagine que tiene que disear uno para registrar la informacin de los clientes. Qu informacin incluira en el formulario? Qu casillas creara? Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo, que guarda la lista de clientes en fichas. Cada ficha podra contener un nombre de cliente, su direccin, ciudad, provincia, cdigo postal y nmero de telfono. Cada uno de estos elementos representa una columna posible de una tabla. Cuando prepare esta lista, no se preocupe si no es perfecta al principio. Simplemente, enumere cada elemento que se le ocurra. Si alguien ms va a utilizar la base de datos, pdale tambin su opinin. Ms tarde podr ajustar la lista. A continuacin, considere los tipos de informes o la correspondencia que desea producir con la base de datos. Por ejemplo, tal vez desee crear un informe de ventas de productos que contenga las ventas por regin, o un informe de resumen de inventario con los niveles de inventario de los productos. Es posible que tambin desee generar cartas modelo para envirselas a los clientes con un anuncio de una

actividad de ventas o una oferta. Disee el informe en su imaginacin y piense cmo le gustara que fuera. Qu informacin incluira en el informe? Cree un listado de cada elemento. Haga lo mismo para la carta modelo y para cualquier otro informe que tenga pensado crear.

Detenerse a pensar en los informes y en la correspondencia que desea crear le ayudar a identificar los elementos que necesita incluir en la base de datos. Suponga, por ejemplo, que ofrece a sus clientes la oportunidad de inscribirse o borrarse de las actualizaciones peridicas de correo electrnico y desea imprimir un listado de los que han decidido inscribirse. Para registrar esa informacin, agrega una columna "Enviar correo electrnico" a la tabla de clientes. Para cada cliente, puede definir el campo en S o No. La necesidad de enviar mensajes de correo electrnico a los clientes implica la inclusin de otro elemento. Cuando sepa que un cliente desea recibir mensajes de correo electrnico, tendr que conocer tambin la direccin de correo electrnico a la que stos deben enviarse. Por tanto, tendr que registrar una direccin de correo electrnico para cada cliente. Parece lgico crear un prototipo de cada informe o listado de salida y considerar qu elementos necesita para crear el informe. Por ejemplo, cuando examine una carta modelo, puede que se le ocurran algunas ideas. Si desea incluir un saludo (por

ejemplo, las abreviaturas "Sr." o "Sra." con las que comienza un saludo), tendr que crear un elemento de saludo. Adems, tal vez desee comenzar las cartas con el saludo "Estimado Sr. Garca", en lugar de "Estimado Sr. Miguel ngel Garca". Esto implicara almacenar el apellido independientemente del nombre. Un punto clave que hay que recordar es que debe descomponer cada pieza de informacin en sus partes lgicas ms pequeas. En el caso de un nombre, para poder utilizar el apellido, dividir el nombre en dos partes: el nombre y el apellido. Para ordenar un informe por nombre, por ejemplo, sera til que el apellido de los clientes estuviera almacenado de forma independiente. En general, si desea ordenar, buscar, calcular o generar informes a partir de un elemento de informacin, debe incluir ese elemento en su propio campo. Piense en las preguntas que le gustara que la base de datos contestara. Por ejemplo, cuntas ventas de un determinado producto se cerraron el pasado mes? Dnde viven sus mejores clientes? Quin es el proveedor del producto mejor vendido? Prever esas preguntas le ayudar a determinar los elementos adicionales que necesita registrar. Una vez reunida esta informacin, ya puede continuar con el paso siguiente. Dividir la informacin en tablas Para dividir la informacin en tablas, elija las entidades o los temas principales. Por ejemplo, despus de buscar y organizar la informacin de una base de datos de ventas de productos, la lista preliminar podra ser similar a la siguiente:

Las entidades principales mostradas aqu son los productos, los proveedores, los clientes y los pedidos. Por tanto, parece lgico empezar con estas cuatro tablas: una para los datos sobre los productos, otra para los datos sobre los proveedores, otra para los datos sobre los clientes y otra para los datos sobre los pedidos. Aunque esto no complete la lista, es un buen punto de partida. Puede seguir ajustando la lista hasta obtener un diseo correcto. Cuando examine por primera vez la lista preliminar de elementos, podra estar tentado a incluirlos todos ellos en una sola tabla en lugar de en las cuatro tablas mostradas en la ilustracin anterior. A continuacin le explicaremos por qu eso no es una buena idea. Considere por un momento la tabla que se muestra a continuacin:

En este caso, cada fila contiene informacin sobre el producto y su proveedor. Como hay muchos productos del mismo proveedor, la informacin del nombre y la direccin del proveedor debe repetirse muchas veces, con lo que se malgasta el espacio en

disco. Registrar la informacin del proveedor una sola vez en una tabla Proveedores distinta y luego vincular esa tabla a la tabla Productos es una solucin mucho mejor. Otro problema de este diseo surge cuando es necesario modificar la informacin del proveedor. Suponga, por ejemplo, que necesita cambiar la direccin de un proveedor. Como sta aparece en muchos lugares, podra sin querer cambiar la direccin en un lugar y olvidarse de cambiarla en los dems lugares. Ese problema se resuelve registrando la informacin del proveedor en un nico lugar. Cuando disee la base de datos, intente registrar siempre cada dato una sola vez. Si descubre que est repitiendo la misma informacin en varios lugares, como la direccin de un determinado proveedor, coloque esa informacin en una tabla distinta. Por ltimo, suponga que el proveedor Bodega Sol slo suministra un producto y desea eliminar ese producto pero conservar el nombre del proveedor y la informacin de direccin. Cmo eliminara el producto sin perder la informacin del proveedor? No puede. Como cada registro contiene datos sobre un producto, adems de datos sobre un proveedor, no puede eliminar unos sin eliminar los otros. Para mantener estos datos separados, debe dividir la tabla en dos: una tabla para la informacin sobre los productos y otra tabla para la informacin sobre los proveedores. Al eliminar un registro de producto slo se eliminaran los datos del producto y no los datos del proveedor. Una vez seleccionado el tema representado por una tabla, las columnas de esa tabla deben almacenar datos nicamente sobre ese tema. Por ejemplo, la tabla de productos slo debe contener datos de productos. Como la direccin del proveedor es un dato del proveedor, pertenece a la tabla de proveedores. Convertir los elementos de informacin en columnas Para determinar las columnas de una tabla, decida qu informacin necesita registrar sobre el tema representado por la tabla. Por ejemplo, para la tabla Clientes, una

buena lista de columnas iniciales sera Nombre, Direccin, Ciudad-Provincia-Cdigo postal, Enviar correo electrnico, Saludo y Correo electrnico. Cada registro de la tabla contiene el mismo nmero de columnas, por lo que puede almacenar informacin sobre el nombre, direccin, ciudad-provincia-cdigo postal, envo de correo electrnico, saludo y direccin de correo electrnico para cada registro. Por ejemplo, la columna de direccin podra contener las direcciones de los clientes. Cada registro contendr datos sobre un cliente y el campo de direccin, la direccin de ese cliente. Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede ajustar con mayor precisin las columnas. Por ejemplo, tiene sentido almacenar los nombres de los clientes en dos columnas distintas (el nombre y el apellido) para poder ordenar, buscar e indizar por esas columnas. De igual forma, la direccin consta en realidad de cinco componentes distintos: direccin, ciudad, provincia, cdigo postal y pas o regin, y parece lgico tambin almacenarlos en columnas distintas. Si desea realizar, por ejemplo, una bsqueda o una operacin de ordenacin o filtrado por provincia, necesita que la informacin de provincia est almacenada en una columna distinta. Debe considerar tambin si la base de datos va a contener informacin slo de procedencia nacional o internacional. Por ejemplo, si piensa almacenar direcciones internacionales, es preferible tener una columna Regin en lugar de Provincia, ya que esa columna puede incluir provincias del propio pas y regiones de otros pases o regiones. De igual forma, es ms lgico incluir una columna Regin en lugar de Comunidad Autnoma si va a almacenar direcciones internacionales. En la lista siguiente se incluyen algunas sugerencias para determinar las columnas de la base de datos.

No incluya datos calculados

En la mayora de los casos, no debe almacenar el resultado de los clculos en las tablas. En lugar de ello, puede dejar que Access realice los clculos cuando

desee ver el resultado. Suponga, por ejemplo, que tiene un informe Productos bajo pedido que contiene el subtotal de unidades de un pedido para cada categora de producto de la base de datos. Sin embargo, no hay ninguna tabla que contenga una columna de subtotal Unidades en pedido. La tabla Productos contiene una columna Unidades en pedido que almacena las unidades incluidas en un pedido de cada producto. Con esos datos, Access calcula el subtotal cada vez que se imprime el informe, pero el subtotal propiamente dicho no debe almacenarse en una tabla.

Almacene la informacin en sus partes lgicas ms pequeas

Puede ceder a la tentacin de habilitar un nico campo para los nombres completos o para los nombres de productos junto con sus descripciones. Si combina varios tipos de informacin en un campo, ser difcil recuperar datos individuales ms adelante. Intente dividir la informacin en partes lgicas. Por ejemplo, cree campos distintos para el nombre y el apellido, o para el nombre del producto, la categora y la descripcin.

Una vez ajustadas las columnas de datos de cada tabla, ya puede seleccionar la clave principal de cada tabla. Especificar claves principales Cada tabla debe incluir una columna o conjunto de columnas que identifiquen inequvocamente cada fila almacenada en la tabla. sta suele ser un nmero de identificacin exclusivo, como un nmero de identificador de empleado o un nmero de serie. En la terminologa de bases de datos, esta informacin recibe el nombre de clave principal de la tabla. Access utiliza los campos de clave principal para asociar rpidamente datos de varias tablas y reunir automticamente esos datos. Si ya tiene un identificador exclusivo para una tabla, como un nmero de producto que identifica inequvocamente cada producto del catlogo, puede utilizar ese identificador como clave principal de la tabla, pero slo si los valores de esa columna son siempre diferentes para cada registro. No puede tener valores duplicados en una clave principal. Por ejemplo, no utilice los nombres de las personas como clave principal, ya que los nombres no son exclusivos. Es muy fcil que dos personas tengan el mismo nombre en la misma tabla. Una clave principal siempre debe tener un valor. Si el valor de una columna puede quedar sin asignar o vaco (porque no se conoce) en algn momento, no puede utilizarlo como componente de una clave principal. Debe elegir siempre una clave principal cuyo valor no cambie. En una base de datos con varias tablas, la clave principal de una tabla se puede utilizar como referencia en las dems tablas. Si la clave principal cambia, el cambio debe aplicarse tambin a todos los lugares donde se haga referencia a la clave. Usar una clave principal que no cambie reduce la posibilidad de que se pierda su sincronizacin con las otras tablas en las que se hace referencia a ella.

A menudo, se utiliza como clave principal un nmero nico arbitrario. Por ejemplo, puede asignar a cada pedido un nmero de pedido distinto. La nica finalidad de este nmero de pedido es identificar el pedido. Una vez asignado, nunca cambia. Si piensa que no hay ninguna columna o conjunto de columnas que pueda constituir una buena clave principal, considere la posibilidad de utilizar una columna que tenga el tipo de datos Autonumrico. Cuando se utiliza el tipo de datos Autonumrico, Access asigna automticamente un valor. Este tipo de identificador no es "fctico", es decir, no contiene informacin objetiva sobre la fila que representa. Los identificadores de este tipo son perfectos para usarlos como claves principales, ya que no cambian. Una clave principal que contiene datos sobre una fila, como un nmero de telfono o el nombre de un cliente, es ms probable que cambie, ya que la propia informacin "fctica" podra cambiar.

Una columna establecida en el tipo de datos Autonumrico suele constituir una buena clave principal. No hay dos identificadores de producto iguales. En algunos casos, tal vez considere conveniente utilizar dos o ms campos juntos como clave principal de una tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artculos de lnea de pedidos tendra dos columnas en su clave principal: Id. de pedido e Id. de producto. Cuando una clave principal est formada por ms de una columna se denomina clave compuesta. Para la base de datos de ventas de productos, puede crear una columna autonumrica para cada una de las tablas que funcione como clave principal: IdProducto para la tabla Productos, IdPedido para la tabla Pedidos, IdCliente para la tabla Clientes e IdProveedores para la tabla Proveedores.

Crear relaciones entre las tablas Ahora que ha dividido la informacin en tablas necesita un modo de reunir de nuevo la informacin de forma provechosa. Por ejemplo, el siguiente formulario incluye informacin de varias tablas.

La informacin de este formulario procede de la tabla Clientes... ...la tabla Empleados... ...la tabla Pedidos... ...la tabla Productos... ...y la tabla Detalles de pedidos.

Access es un sistema de administracin de bases de datos relacionales. En una base de datos relacional, la informacin se divide en tablas distintas en funcin del tema. A continuacin, se utilizan relaciones entre las tablas para reunir la informacin segn se precise. Crear una relacin de uno a varios Considere este ejemplo: las tablas Proveedores y Productos de la base de datos de pedidos de productos. Un proveedor puede suministrar cualquier nmero de productos y, por consiguiente, para cada proveedor representado en la tabla Proveedores, puede haber muchos productos representados en la tabla Productos.

La relacin entre la tabla Proveedores y la tabla Productos es, por tanto, una relacin de uno a varios.

Para representar una relacin de uno a varios en el diseo de la base de datos, tome la clave principal del lado "uno" de la relacin y agrguela como columna o columnas adicionales a la tabla en el lado "varios" de la relacin. En este caso, por ejemplo, agregara la columna Id. de proveedor de la tabla Proveedores a la tabla Productos. Access utilizara entonces el nmero de identificador de proveedor de la tabla Productos para localizar el proveedor correcto de cada producto. La columna Id. de proveedor de la tabla Productos se denomina clave externa. Una clave externa es la clave principal de otra tabla. La columna Id. de proveedor de la tabla Productos en una clave externa porque tambin es la clave principal en la tabla Proveedores.

El punto de partida para la unin de tablas relacionadas se proporciona estableciendo parejas de claves principales y claves externas. Si no est seguro de las tablas que deben compartir una columna comn, al identificar una relacin de uno a varios se asegurar de que las dos tablas implicadas requerirn una columna compartida. Crear una relacin de varios a varios Considere la relacin entre la tabla Productos y la tabla Pedidos. Un solo pedido puede incluir varios productos. Por otro lado, un nico producto puede aparecer en muchos pedidos. Por tanto, para cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos. Y para cada registro de la tabla Productos puede haber varios registros en la tabla Pedidos. Este tipo de relacin se denomina relacin de varios a varios porque para un producto puede haber varios pedidos, y para un pedido puede haber varios productos. Tenga en cuenta que para detectar las relaciones de varios a varios entre las tablas, es importante que considere ambas partes de la relacin.

Los temas de las dos tablas (pedidos y productos) tienen una relacin de varios a varios. Esto presenta un problema. Para comprender el problema, imagine qu sucedera si intenta crear la relacin entre las dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para que haya ms de un producto por pedido, necesita ms de un registro en la tabla Pedidos para cada pedido y, en ese caso, tendra que repetir la informacin de pedido para cada fila relacionada con un nico pedido, lo que dara lugar a un diseo ineficaz que podra producir datos inexactos. El mismo problema aparece si coloca el campo Id. de pedido en la tabla Productos: tendra varios registros en la tabla Productos para cada producto. Cmo se soluciona este problema? La solucin a este problema consiste en crear una tercera tabla que descomponga la relacin de varios a varios en dos relaciones de uno a varios. Insertara la clave principal de cada una de las dos tablas en la tercera tabla y, por consiguiente, la tercera tabla registrara todas las apariciones o instancias de la relacin.

Cada registro de la tabla Detalles de pedidos representa un artculo de lnea de un pedido. La clave principal de la tabla Detalles de pedidos consta de dos campos: las claves externas de las tablas Pedidos y Productos. El campo Id. de pedido no se puede utilizar en solitario como clave principal, ya que un pedido puede tener varios

artculos de lnea. El identificador de pedido se repite para cada artculo de lnea del pedido, por lo que el campo no contiene valores nicos. Tampoco servira utilizar solamente el campo Id. de producto, porque un producto puede aparecer en varios pedidos. Pero los dos campos juntos producen un valor exclusivo para cada registro. En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no se relacionan directamente entre s, sino indirectamente a travs de la tabla Detalles de pedidos. La relacin de varios a varios entre los pedidos y los productos se representa en la base de datos mediante dos relaciones de uno a varios:

La tabla Pedidos y la tabla Detalles de pedidos tienen una relacin de uno a

varios. Cada pedido tiene varios artculos de lnea, pero cada artculo est asociado a un nico pedido.

La tabla Productos y la tabla Detalles de pedidos tienen una relacin de uno

a varios. Cada producto puede tener varios artculos asociados, pero cada artculo de lnea hace referencia nicamente a un producto. Desde la tabla Detalles de pedidos puede determinar todos los productos de un determinado pedido, as como todos los pedidos de un determinado producto. Despus de incorporar la tabla Detalles de pedidos, la lista de tablas y campos sera similar a la siguiente:

Crear una relacin de uno a uno Otro tipo de relacin es la relacin de uno a uno. Suponga, por ejemplo, que necesita registrar informacin complementaria sobre productos que apenas va a necesitar o que slo se aplica a unos pocos productos. Como no necesita la informacin con frecuencia, y como almacenar la informacin en la tabla Productos creara un espacio vaco para todos los productos que no necesitan esa informacin, la coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza el identificador de producto como clave principal. La relacin entre esta tabla complementaria y la tabla Productos es una relacin de uno a uno. Para cada registro de la tabla Productos hay un nico registro coincidente en la tabla complementaria. Cuando identifique esta relacin, ambas tablas deben compartir un campo comn. Cuando necesite crear una relacin de uno a uno en la base de datos, considere si puede incluir la informacin de las dos tablas en una tabla. Si no desea hacer eso por

algn motivo (quizs porque se creara una gran cantidad de espacio vaco), puede representar esa relacin en su diseo guindose por las pautas siguientes:

Si las dos tablas tienen el mismo tema, probablemente podr definir la

relacin utilizando la misma clave principal en ambas tablas.

Si las dos tablas tienen temas diferentes con claves principales distintas,

elija una de las tablas (cualquiera de ellas) e inserte su clave principal en la otra tabla como clave externa. Determinar las relaciones entre las tablas le ayudar a asegurarse de que tiene las tablas y columnas correctas. Cuando existe una relacin de uno a uno o de uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando la relacin es de varios a varios, se necesita una tercera tabla para representar la relacin. Ajustar el diseo Cuando tenga las tablas, los campos y las relaciones necesarias, debe crear y rellenar las tablas con datos de ejemplo y probar que funcionan con la informacin: creando consultas, agregando nuevos registros, etc. Esto le permitir encontrar posibles problemas, como la necesidad de agregar una columna que olvid insertar durante la fase de diseo, o dividir una tabla en dos tablas para eliminar datos duplicados. Compruebe si puede usar la base de datos para obtener las respuestas que desea. Cree formularios e informes provisionales y compruebe si muestran los datos segn lo previsto. Compruebe si existen datos duplicados innecesarios y, si encuentra alguno, modifique el diseo para eliminar la duplicacin. Cuando pruebe la base de datos inicial, probablemente se dar cuenta de que se puede mejorar. stas son algunas comprobaciones que puede hacer:

Olvid incluir alguna columna? Y, en ese caso, pertenece la informacin a alguna de las tablas existentes? Si se trata de informacin sobre otro tema, tal vez necesite crear otra tabla. Cree una columna para cada elemento de informacin que desee registrar. Si la informacin no se puede calcular a partir de otras columnas, es probable que necesite una nueva columna para esa informacin.

Hay alguna columna innecesaria porque se puede calcular con los campos

existentes? Si un elemento de informacin se puede calcular a partir de otras columnas existentes (como un descuento calculado a partir del precio de venta al pblico), normalmente es preferible que se calcule en lugar de crear una nueva columna.

Ha proporcionada informacin duplicada en alguna de las tablas? Si es

as, probablemente tendr que dividir la tabla en dos tablas que tengan una relacin de uno a varios.

Tiene tablas con muchos campos, un nmero limitado de registros y

muchos campos vacos en cada registro? En ese caso, considere la posibilidad de volver a disear la tabla de forma que tenga menos campos y ms registros.

Ha dividido cada elemento de informacin en sus partes lgicas ms

pequeas? Si necesita generar informes, ordenar, buscar o calcular a partir de un elemento de informacin, incluya ese elemento en su propia columna.

Contiene cada columna datos sobre el tema de la tabla? Si una columna

no contiene informacin sobre el tema de la tabla, pertenece a una tabla distinta.

Estn representadas todas las relaciones entres las tablas mediante

campos comunes o mediante una tercera tabla? Las relaciones de uno a uno y de uno a varios requieren columnas comunes. Las relaciones de varios a varios requieren una tercera tabla.

Conclusin Un dato puede significar un nmero, una letra, un signo ortogrfico o cualquier smbolo que represente una cantidad, una medida, una palabra o una descripcin. Los datos se caracterizan por no contener ninguna informacin. La importancia de los datos est en su capacidad de asociarse dentro de un contexto para convertirse en informacin. Por si mismos los datos no tienen capacidad de comunicar un significado y por tanto no pueden afectar el comportamiento de quien los recibe. Para ser tiles, los datos deben convertirse en informacin para ofrecer un significado, conocimiento, ideas o conclusiones. Se conoce como base de datos (o database, de acuerdo al trmino ingls) al conjunto de los datos que pertenecen a un mismo contexto y que son almacenados de manera sistemtica para que puedan utilizarse en el futuro. En un enfoque ms amplio, un modelo de datos permite describir los elementos que intervienen en una realidad o en un problema dado y la forma en que se relacionan dichos elementos entre s. El modelo E-R es extremadamente til para hacer corresponder los significados e interacciones de las empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas herramientas de diseo de bases de datos se basan en los conceptos del modelo E-R. entre las ventajas que ofrece este modelo tenemos:

Globalizacin de la informacin: permite a los diferentes usuarios considerar la informacin como un recurso corporativo que carece de dueos especficos.

Eliminacin de informacin inconsistente: si existen dos o ms archivos con la misma informacin, los cambios que se hagan a stos debern hacerse a todas las copias del archivo de facturas.

Permite compartir informacin: Permite mantener la integridad en la informacin: la integridad de la informacin es una de sus cualidades altamente deseable y tiene por objetivo que slo se almacena la informacin correcta.

Independencia de datos: La independencia de datos implica un divorcio entre programas y datos.

Seguridad: Al asegurar que el nico medio de acceso a la base de datos sea a travs de canales adecuados se pueden definir las restricciones de seguridad que sern verificadas siempre que se intente acceder a datos sensibles.

Bibliografa

CAMPBELl, Mary. base IV Gua de Autoenseanza. Espaa. Editorial McGraw Hill Interamericana. 1990. pp110/111,121/122,161,169, 179-191/192. HARWRYSZKIEWYCZ, I T. Anlisis y diseo de base de datos. Editorial Megabyte. Noriega Editores. Mxico. 1994. pp29/31

LAUDON, Kenneth C. Administracin de los sistemas de informacin. 3ra. Edicin. Mxico. 1996. pp 271/295 Aprende computacin. Editorial ocano. Espaa. Pp36/39 Stallings,William SISTEMAS OPERATIVOS. Prentice Hall, 2da edicin Piattini Mario, Adoracin de Miguel, Marcos Esperanza. DISEO DE BASES DE DATOS RELACIONALES. Ed. Alfaomega.

Abraham Silberschatz, Henry F. Korth, S. Sudarshan, FUNDAMENTOS DE BASES DE DATOS, Cuarta edicin mcGrawHill, Madrid 2002.

Paginas WEB consultadas:

http://www.ur.mx/ur/faciya/carreras/cursos/sis/mod-dat1/graph.HTM

www.yudy.8m.com/Sistemasmanejador.htmberzal.freeservers.com/freeware/dbms/sp anish.html

http://www.lafacu.com/apuntes/informatica/base_datos/default.htm#Introduccin

http://www.dbinternet.com.ar/metodo.htm

Vous aimerez peut-être aussi