Вы находитесь на странице: 1из 54

Modelo entidad-relacin

Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas.
Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando: {{subst:Aviso referencias|Modelo entidad-relacin}}

~~~~

Ejemplo de diagrama E-R.

Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas en ingls, E-R "Entity relationship", o del espaol DER "Diagrama de Entidad Relacin") es una herramienta para el modelado de datosque permite representar las entidades relevantes de unsistema de informacin as como sus interrelaciones y propiedades.
ndice
[ocultar]

1 Modelado Entidad-Relacin 2 Base terica y conceptual

o o o o

2.1 Entidad 2.2 Atributos 2.3 Relacin 2.4 Conjunto de relaciones

3 Restricciones

o o

3.1 Correspondencia de cardinalidades 3.2 Restricciones de participacin

4 Claves 5 Diagrama entidad-relacin

o o o

5.1 Entidades 5.2 Atributos 5.3 Relaciones

6 Diagramas extendidos

o o o o o

6.1 Entidades fuertes y dbiles 6.2 Cardinalidad de las relaciones 6.3 Atributos en relaciones 6.4 Herencia 6.5 Agregacin

7 Vase tambin 8 Enlaces externos

Modelado Entidad-Relacin[editar editar cdigo]


El Modelo Entidad-Relacin. 1. Se elabora el diagrama (o diagramas) entidad-relacin. 2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).

Conversin en tablas (en caso de utilizar una base de datos relacional).

Base terica y conceptual[editar editar cdigo]


El modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.

Entidad[editar editar cdigo]


Representa una cosa u "objeto" del mundo real con existencia independiente, es decir, se difere ncia unvocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos:

Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).

Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis).

Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).

Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento.

Atributos[editar editar cdigo]


Los atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades. En un conjunto de entidades del mismo tipo, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca. Ejemplos: A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades:

(1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ...

Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...).

Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.

Relacin[editar editar cdigo]


Describe cierta dependencia entre entidades o permite la asociacin de las mismas.

Ejemplo: Si tenemos dos entidades, "CLIENTE" y "HABITACION", podemos entender la relacin entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podriamos tener la ocurrencia "Habitacin 502", de la entidad "HABITACION" y la ocurrencia "Henry Jonshon Mcfly Bogard", de la entidad "CLIENTE", entre las que es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry.

Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un husped (entidad), se aloja (relacin) en una habitacin (entidad).

Conjunto de relaciones[editar editar cdigo]


Consiste en una coleccin, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones. La dependencia o asociacin entre los conjuntos de entidades es llamada participacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped" participan en el conjunto de relaciones habitacin-husped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.

Restricciones[editar editar cdigo]


Son reglas que deben mantener los datos almacenados en la base de datos.

Correspondencia de cardinalidades[editar editar cdigo]

Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:

Uno a Uno: (1:1) Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo).

Uno a varios: (1:N)Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas).

Varios a Uno: (N:1)Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo).

Varios a Varios: (N:M)Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

Restricciones de participacin[editar editar cdigo]


Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.

Claves[editar editar cdigo]


Es un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar inequvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave.

Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata.

Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:

R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.

R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:

R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R.

R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R.

R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R.

R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

Diagrama entidad-relacin[editar editar cdigo]


Anteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.

Entidades[editar editar cdigo]


Las entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo. que pueden ser de tipo: maestras, transaccionales, historicas y temporales

Atributos[editar editar cdigo]


Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidadrelacin, sino descritos textualmente en otros documentos adjuntos.

Relaciones[editar editar cdigo]


Se representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.

Diagramas extendidos[editar editar cdigo]

DER extendido

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar losdiagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:

Entidades fuertes y dbiles[editar editar cdigo]

Cuando una entidad participa en una relacin puede adquirir un papel fuerte odbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar. Las entidades dbiles se representan- mediante un doble rectngulo; es decir, un rectngulo con doble lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:

Dependencia por existencia.

Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.

Dependencia por identificacin.

La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).

Cardinalidad de las relaciones[editar editar cdigo]


El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin:

"0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez.

"N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.

Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1.

Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N.

Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.

Atributos en relaciones[editar editar cdigo]


Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite".

Herencia[editar editar cdigo]


La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo.

Agregacin[editar editar cdigo]

Ejemplo agregacin

Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se

muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).

Vase tambin[editar editar cdigo]



Ingeniera del software. Disciplina donde se encuadra el anlisis y diseo de datos. Modelo de datos. Es la visin esttica de un sistema de informacin. Base de datos. Es la implementacin de un modelo de datos. Modelo relacional. Una tcnica formal para describir modelos de datos. UML. Otro lenguaje que permite describir modelos de datos (entre otras cosas). Peter Chen. El autor del modelo entidad-relacin.

Atributos y Llaves
Los atributos, tanto de entidades como de relaciones, toman sus valores posibles de un conjunto llamado dominio. El dominio es, entonces, el conjunto de valores posibles que puede tomar un atributo dado de un conjunto de entidades dado. Por ejemplo, la fecha de nacimiento de una persona puede ser una fecha cualquiera anterior a la fecha actual. El dominio de las fechas de nacimiento, entonces, es el subconjunto de fechas que son anteriores (o iguales, en algunos casos) a la fecha de hoy. El dominio de los nmeros de telfono, en Chile, podra ser una cadena de caracteres que cumpliera con el formato (XX) XXX-XXXX (simplificado), donde las X son dgitos. En general los dominios sern ms bien amplios, aunque cuando se lleva a cabo la implementacin es preferible restringir los dominios lo ms posible de manera que el gestor de bases de datos automticamente haga algunas verificaciones sobre los datos que se almacenan, para asegurar la integridad de los datos. Veremos cmo hacer esto en la seccin siguiente. Algunos atributos de un conjunto de entidades son especiales. De partida es necesario definir cules de ellos son opcionales y cules son obligatorios. Como el nombre lo indica, un atributo obligatorio es aquel que siempre debe estar definido para toda entidad. Un atributo opcional, en cambio, puede quedar sin definir para algunas de las entidades del conjunto de entidades. En general, es deseable que la mayor cantidad de atributos posible se definan como obligatorios, puesto que permite simplificar mucho algunas operaciones, al tiempo que

asegura una mejor integridad de los datos. Veremos ms sobre esto en la seccin siguiente. Otro concepto importante relacionado con los atributos es el de las llaves. Una superllave de una entidad es un atributo o conjunto de atributos que permite distinguir de modo nico cada entidad dentro de un conjunto de entidades. Por ejemplo, el nombre y RUT de una persona sera una superllave. Slo el nombre no podra serlo, puesto que dos personas pueden tener el mismo nombre. Un conjunto de entidades puede tener ms de una superllave; otra superllave para personas podra ser el nombre, la fecha de nacimiento y la direccin postal, puesto que es muy improbable que dos personas hayan nacido el mismo da, vivan en la misma casa y se llamen igual; pero omitiendo cualquiera de esos atributos es razonable esperar encontrar coincidencias. Adems, una superllave puede contener ms atributos de los necesarios para identificar unvocamente cada entidad. Eliminando los atributos innecesarios de las superllaves se obtienen las llaves candidatas. Por ejemplo, en el caso del nombre y RUT, usando slo el RUT servira tambin como superllave, y por lo tanto como llave candidata. Observe que todos los atributos que forman una llave candidata son obligatorios, puesto que si falta alguno, no es posible identificar completamente la entidad. Finalmente, se escoge una de las llaves candidatas y se designa como llave primaria del conjunto de entidades. Algunos conjuntos de entidades pueden no tener atributos suficientes para formar una llave primaria. En este caso, se dice que es un conjunto de entidades dbil. Un ejemplo claro sera un modelo para almacenar facturas de venta de bienes o servicios. Cada factura en s es una entidad fuerte; cada lnea dentro de una factura es una entidad dbil, puesto que no se puede identificar una lnea en particular sino en tanto pertenece a una factura. As cada factura tendra una lnea nmero 1, una lnea nmero 2, etc; por lo tanto, hablamos de una lnea en particular como la lnea nmero 5 de la factura nmero 18.289. En nuestro ejemplo anterior, todos los conjuntos de entidades son fuertes, puesto que sus elementos cuentan con los atributos suficientes para ser identificados unvocamente. Para ilustrar este nuevo concepto, incluiremos en nuestro modelo los datos de los experimentos que se publican en cada artculo para obtener observaciones sobre las hiptesis que los autores plantean. Cada artculo puede utilizar uno, ninguno o varios experimentos; algunos experimentos sern similares o iguales entre artculos; no hay ningn cdigo asociado intrnsecamente a un experimento, ni modo alguno de distinguirlos de forma

unvoca entre todos los artculos. Pero dentro de cada artculo, cada experimento es nico. As, un experimento tendr un atributo obligatorio que le permitir ser discriminado de entre el conjunto de experimentos de un mismo artculo (por ejemplo, el nmero que el mismo autor le asigna en el artculo). La figura 5 ilustra el nuevo diagrama E-R. Observe que el conjunto de entidades de experimentos se ha marcado como un rectngulo doble, lo cual indica que es dbil.

Figura 5: El diagrama 4 con una entidad dbil

Con respecto a las llaves primarias de nuestro modelo de ejemplo, los conjuntos de entidades fuertes tienen por definicin llaves primarias. Sin embargo, en muchos casos estas llaves primarias son complejas de implementar. En el caso de las personas chilenas, usar el RUT es una eleccin natural. Para personas de otros pases, la eleccin se torna complicada: se podra escoger como llave primaria un nmero identificador por pas en conjunto con el pas que emite dicho nmero. Este esquema puede verse en problemas si existe algn pas que no emite

nmeros identificadores para sus habitantes. Asimismo, identificar un artculo es complejo: el uso del ttulo no es suficiente, puesto que otro artculo podra llevar el mismo ttulo. Una eleccin tericamente mejor sera el uso del resumen como llave primaria, eleccin que en la prctica es irrisoria cuando menos. Para resolver este problema prctico agregaremos a cada una de estos conjuntos un identificador numrico, ficticio, nico dentro de cada conjunto de entidades, independiente de cada uno de los identificadores de los otros conjuntos. Este identificador se generar internamente en la base de datos, y no tendr ningn significado fuera de ella. Una convencin usual es ponerle el nombre del conjunto de entidades, en singular, seguido de id, como en autor_id.
En el desarrollo de software para empresas, el almacenamiento de la informacin de un modo organizado es fundamental la mayora de los casos en los que el programador contesta no se puede hacer a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicacin. En este artculo voy a intentar explicar, con un ejemplo prctico, un buen modelado de datos. Como, de alguna forma, estamos especializados en el software de gestin de empresas de enseanza, voy a utilizar un ejemplo de uno de esos modelos: la gestin de matriculacin de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Voy a explicar en este artculo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementacin), las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. De paso, dar una idea de los ndices, procedimientos almacenados y triggers que nos pueden resultar tiles para que el rendimiento de la base de datos sea bueno.

Descripcin del proceso de matriculacin (el caso de uso)


Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman grupos abiertos, es decir, grupos en los que cualquiera se puede matricular (en oposicin a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente). Cuando llegamos a la academia, se nos ofrece un folleto o catlogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que

ms nos conviene, el horario al que vamos a asistir, y con esta informacin nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a travs de nuestra cuenta bancaria. En la academia, llegado este punto, introducen en su sistema de informacin nuestros datos y nos imprimen el contrato de prestacin de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequea cantidad del primer recibo. En el siguiente da de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo nos da la bienvenida, y empezamos a estudiar.

El modelo de datos
A partir de aqu har una descripcin de la estructura de tablas y columnas para almacenar la informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos.

Generalidades
Hay algunas cosas bsicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas as). Por ejemplo: 1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen as un identificador interno, mantenido por el sistema. As, las claves ajenas son ms fciles de mantener. 2. En general, nosotros no solemos poner campos requeridos preferimos hacer la gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estbamos completamente seguros que eran requeridos y hemos tenido que quitar la marca. 3. No se duplica informacin. Es decir, una de las reglas bsica es que la misma informacin no puede estar en dos sitios, salvo 4. En muchos casos, creamos campos calculados, que permiten acceder de forma rpida a informacin por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales como hacer este clculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo

calculado que se mantiene automticamente (en nuestro caso, a travs de Triggers de la base de datos). La informacin est duplicada en dos sitios, s, pero por motivos de rendimiento (y siempre est sincronizada). 5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dnde vas a tener que acceder.

Descripcin de las entidades


El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Segn el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos):
o o o

Cursos: almacena la oferta formativa del centro. Representa el catlogo o folleto que te dan al llegar al centro. Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto tambin). Trimestral, mensual, anual, etc. Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante ms complejo que el que voy a describir aqu en un artculo posterior lo describir en detalle.

o o

Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que no. Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para pagar (contado, domicilacin bancaria, etc), incluyendo las cuentas bancarias del cliente.

Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples alumnos.

o o o

Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago, etc. De forma fsica, se refleja en el contrato que te dan para firmar. Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro. Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestin de recibos y pagos que hacemos en realidad es ms compleja de lo que voy a describir aqu. En otro artculo har una descripcin ms completa.

Alumnos en grupos: refleja los alumnos que estn asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa informacin histrica, as que necesitamos una tabla para gestionarlo.

Aqu podis ver el modelo grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es hija de otra, con la punta de flecha apuntando al padre.

Como podis ver, slo estn indicados los campos que forman el modelo de datos las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente seccin describiremos los campos de cada tabla.

Campos para las entidades


Slo describir los campos ms importantes, y no incluir los campos de clave primaria y ajena que se describen en el grfico.

Cursos
o o

nombre: varchar(100) descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para hacer una descripcin larga del curso en el que el alumno se est matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologas, distintos campos memo, que se imprimen en distintos lugares del contrato.

o o

fecha_inicio: date fecha_fin: date

Formas de pago
o o o

nombre: varchar(100) importe: float. Es el importe de cada recibo que se cobrar numero_meses: integer. El nmero de meses de cada recibo. Si es 1, se crear un recibo cada mes mientras dure la matriculacin, si es 3, uno cada tres meses, etc. En algn sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite ms flexibilidad y ms control, pero el modelo es bastante ms complejo.

o o o

numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero las que ms nos interesen. importe_matricula: float. Si adems del importe del curso hay un importe de matrcula, se marca aqu. concepto_matricula. El concepto del recibo de matrcula, si creamos uno.

Grupos
o

nombre: varchar(100)

codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en la Fundacin Tripartita.

o o

fecha_inicio: date fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.

o o o

lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de aulas, pero eso lo ampliar en otro artculo. notas: memo, del grupo horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.

o o

maximo_alumnos: Integer. Mximo nmero de alumnos permitidos en el grupo. numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este campo es de slo lectura para el usuario, y es calculado, a travs de una serie de Triggers en la base de datos, para poder saber rpidamente el nmero de alumnos activos en cada grupo sin tener que estar sumando.

Clientes
o

nombre: varchar(100). En nuestros sistemas, normalmente, este es el nico campo requerido (por cdigo, no en la base) que tenemos. As, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver despus.

o o o

primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para poder coger de forma rpida el conjunto Nombre+ +primer_apellido+ +segundo_apellido

o o

direccion: memo codigo_postal: varchar(20): no hay que ser tacao de vez en cuando hay que meter una direccin extranjera y el cdigo postal puede ser ms grande.

o o o

poblacion: varchar(50) notas_internas: memo etc. de datos personales (profesin, telfonos, email, etc.)

Alumnos

o o o o o

nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es slo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): etc. de datos personales (profesin, telfonos, email, etc.)

Medios de pago
o o o o o o o o

tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que suelen ser: Sin Pago, Contado, Banco nombre_titular: varchar(100) direccion_titular: memo entidad: varchar(4) oficina: varchar(4) dc: varchar(2) numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la informacin bancaria del cliente. por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se crea un medio de pago contado, y se le pone por defecto.

Matrculas
Adems de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto ltimo puede parece redundante, pero no lo es podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar, digamos, ingls y francs el ingls lo paga el padre y el francs la madre. As, es necesario que cada matrcula est asociada con el alumno, y tambin con el cliente), necesitamos los siguientes campos:
o o o

fecha_inicio: date. fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse despus o terminar antes (si se da de baja, por ejemplo). importe: real. Por defecto, el de la forma de pago escogida, pero puede ser tambin distinto descuentos por familiares, cosas as. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda cambiar.

motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego poder obtener estadsticas de nmero de bajas por tipo, cosas as.

Recibos
o o o o o o

fecha_emision: date fecha_cobro_completo: date numero_recibo: varchar(20) concepto: varchar(50) importe_recibo: float. importe_pendiente: float. Es un campo de slo lectura, actualizado a travs de triggers, que permite acceder a la informacin sin tener que sumar.

Pagos
o o o

fecha: date importe: real forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja. Puede ser: contado, transferencia, tarjeta, taln, etc.

Alumnos en grupos
o o

fecha_inicio: date fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta tambin la posibilidad de que en un mismo curso, pagando ms, un alumno pueda asistir a varios grupos (esto tambin lo he visto).

Triggers y procedimientos almacenados


El modelo de datos y la lgica del negocio estn muy estrechamente relacionados. Los sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados, lo que es muy conveniente para dejar trozos de la lgica de negocio asociados con la base de datos, tanto por motivos de organizacin del cdigo como por motivos de rendimiento (un procedimiento almacenado es varios rdenes de magnitud ms rpido que hacer el mismo proceso a travs de un lenguaje de programacin). En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan:
o

Actualizacin de los campos NombreCompleto de alumnos y clientes: normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al contenido del nombre y los apellidos.

Actualizacin del campo ImportePagado de recibos, AFTER INSERT, UPDATE y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo.

Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso de creacin de la matrcula (o un trigger AFTER INSERT), que crea los recibos de la matrcula en base al importe y forma de pago seleccionadas.

En las prximas semanas continuar esta serie de artculos, describiendo otros submodelos de sistemas que hemos desarrollado algunas ideas que tengo: 1. Gestin de horarios y citas 2. Facturacin 3. Gestin de horas trabajadas 4. Stock Cualquier otra idea ser bienvenida

29 Comentarios Avanza 2 Puesta en marcha Networking profesional, la crisis como excusa para hacer buenos amigos

29 opiniones sobre Modelo entidad-relacin, un ejemplo prctico I


- See more at: http://www.ender.es/2010/03/modelo-entidad-relacion-un-ejemplo-practico-imatriculacion/#sthash.Yi3UL57Q.dpuf

Modelo relacional
El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos.

Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tabla que est compuesta por registros (cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos).
ndice
[ocultar]

1 Descripcin

o o

1.1 Esquema 1.2 Instancias

2 Base de datos relacional 3 Vase tambin

Descripcin[editar editar cdigo]


En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que stos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver.

Esquema[editar editar cdigo]


Un esquema contiene la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y qu tipo de informacin podr ser almacenada dentro de ella; en otras palabras, el esquema contiene losmetadatos de la relacin. Todo esquema constar de:

Nombre de la relacin (su identificador).

Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, equivalente al tipo de dato por ejemplo character, integer, date, string...

Instancias[editar editar cdigo]


Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es valido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por ejemplo:

Ciertos caracteres y nmeros (una sola columna de una sola fila). Algunas o todas las filas con todas o algunas columnas

Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado.

Base de datos relacional[editar editar cdigo]


Artculo principal: Base de datos relacional.

Una base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves. 2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes.

3.

Favorece la normalizacin por ser ms comprensible y aplicable.

Modelo relacional
3.1 Introduccin
En el captulo anterior se mencionaron 3 tipos de modelado: conceptual, lgico y fsico. El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la informacin utilizada en algun problema o negocio. En este captulo nos concentraremos en desarrollar un buen modelo "lgico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podr realizar el modelado fsico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un fsico.

3.2 Por qu "modelo relacional" ?


Puede resultar confuso el concepto de modelo entidad-relacin vs modelo relacional, quizs porque ambos comparten casi las mismas palabras. Como se mencion en la seccin anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se mencionar posteriormente consiste de un conjunto de "tablas" que representan "relaciones", relaciones entre los datos. Estas tablas, pueden ser construdas de diversas maneras:

Creando un conjunto de tablas iniciales y aplicar operaciones de normalizacin hasta conseguir el esquema ms ptimo. Las tcnicas de nomalizacin se explican ms adelante en este captulo. Convertir el diagrama e-r a tablas y posteriormente aplicar tambin operaciones de normalizacin hasta conseguir el esquema ptimo.

La primer tcnica fue de las primeras en existir y, como es de suponerse, la segunda al ser ms reciente es mucho ms conveniente en varios aspectos:

El partir de un diagrama visual es muy til para apreciar los detalles, de ah que se llame modelo conceptual. El crear las tablas iniciales es mucho ms simple a travs de las reglas de conversin. Se podra pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo e-r es que la "normalizacin" es mnima por lo general. Lo anterior tiene otra ventaja, an cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer tcnica no es as.

3.3 Conceptos bsicos


3.3.1 Tablas El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relacin.
ttulo Star Wars ao 1977 duracin 124 104 95 tipo color color color

Mighty Ducks 1991 Wayne's World 1992

Relacin Pelculas

La relacin Pelculas tiene la intencin de manejar la informacin de las instancias en la entidad Pelculas, cada rengln corresponde a una entidad pelcula y cada columna corresponde a uno de los atributos de la entidad. Sin embargo las relaciones pueden representar ms que entidades, como se explicar ms adelante. 3.3.2 Atributos Los atributos son las columnas de un relacin y describen caractersticas particulares de ella. 3.3.3 Esquemas Es el nombre que se le da a una relacin y el conjunto de atributos en ella. Pelculas (ttulo, ao, duracin, tipo) En un modelo relacin, un diseo consiste de uno o ms esquemas, a este conjunto se le conoce como "esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de datos" (database schema) 3.3.4 Tuplas Cada uno de los renglones en una relacin conteniendo valores para cada uno de los atributos. (Star Wars, 1977, 124, color) 3.3.5 Dominios Se debe considerar que cada atributo (columna) debe ser atmico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos. 3.3.6 Representaciones equivalentes de una relacin Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.

As mismo el orden de los atributos tampoco es relevante


ao 1991 1992 1977 ttulo tipo duracin 104 95 124

Mighty Ducks color Wayne's World Star Wars color color

Otra representacin de la relacin Pelculas

3.4 Conversin del modelo e-r a un esquema de base de datos (Conversin a tablas)
3.4.1 Introduccin El modelo es una representacin visual que grficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organizacin. Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos. 3.4.2 Conversin a tablas desde un modelo con relaciones (11,1-m,m-m) Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.

modelo e-r conversin a tablas

una tabla por cada conjunto de entidades o nombre de tabla = nombre de conjunto de entidades una tabla por cada conjunto de relaciones m-m o nombre de tabla = nombre de conjunto de relaciones definicin de columnas para cada tabla o conjuntos fuertes de entidades columnas = nombre de atributos o conjuntos dbiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) o conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) o conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) o conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R)

El diagrama anterior se convertira al siguiente esquema: Debil


atribs_Debil LLP_A atribs_rel_0

A
LLP_A atribs_A

B1

LLP_B1

atribs_B1

B2
LLP_B2 atribs_B2 LLP_A attribs_rel_2

B3
LLP_B3 atribs_B3 LLP_A atribs_rel_3

A_B1
LLP_A LLP_B1 atribs_rel_1

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

Ejemplo:

Para el ejemplo de la figura tendramos el esquema:

escuela
id url nombre

departamento
clave url nombre id_escuela

curso
clave seccion nombre clave_depto

profesor
id nombre extension

estudiante
id nombre carrera

profesor_curso
id_prof clave_curso seccion_curso

estudiante_curso
id_estud clave_curso seccion_curso

3.4.3 Conversin a tablas desde un modelo con generalizacin

modelo e-r de generalizacin a tablas dos posibilidades:


1.
o

crear una tabla para el conjunto de entidades A de mayor nivel columnas (A) = atributos(A) para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columns (B) = atributos (B) U llave_primaria (A)

2.
o

si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A)

La generalizacin se convertira al siguiente esquema: 1) A


LLP_A atribs_A

B1
atribs_B1 LLP_A

B2
atribs_B2 LLP_A

B3
atribs_B3 LLP_A

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

2) B1
atribs_B1 LLP_A atribs_A

B2
atribs_B2 LLP_A atribs_A

B3
atribs_B3 LLP_A atribs_A

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

Es importante mencionar que a pesar de que existen 2 mtodos para convertir una generalizacin a tablas, no hay una regla exacta de cual usar en determinado caso. A continuacin se mencionan algunos consejos tiles para la determinacin de cual mtodo emplear: 1. Si la entidad de nivel superior est relacionada con otra(s) entidades puede sugerirse emplear el mtodo (1) ya que de esa manera la tabla (A) ser la nica involucrada en la relacin, de otra

forma se tendran tres tablas (B1,B2 y B3) formando parte de la relacin 2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalizacin disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizs sea recomendable el mtodo (1), en otro caso se podra pensar en el mtodo (2). 3. Tambin es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto tambin determina en muchos casos el mtodo a emplear. 3.4.4 Descubrimiento de llaves en las relaciones Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera: 1) Cada tabla que provenga de una entidad contiene por si misma una llave 2) Para las tablas resultado de una relacin se toman las llaves primarias de ambas entidades y stas conforman la nueva llave primaria, excepto en un caso como el que sigue:

Podemos observar que existe una relacin m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas series tendrn a los mismos actores. La tabla que se creara sera: actor_serie
id_actor Joaqun Pardav id_serie Gnesis Qu bonita familia Gnesis id_personaje Abel hermano bueno Dulce abuelita Can hermano

Evita Muoz (Chachita) Joaqun Pardav

malo Evita Muoz (Chachita) Hermelinda linda Bruja Hermelinda

si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinacin no identifica de manera nica a la tupla, como es el caso de "Joaqun Pardav, Gnesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Can hermano malo". La relacin es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo ms recomendable sera emplear los tres atributos de la relacin "id_actor, id_serie, id_personaje"

3.5 Normalizacin
Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son: 1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la relacin siguiente, length y filmType. 2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Si en la relacin encontramos que el length de StarWars es 125 podramos cambiarlo nicamente para la primer tupla y olvidar actualizar las dems. 3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio Estevez, perdemos tambin la tupla de la pelcula MightyDucks.

title Star Wars Star Wars Star Wars

year length filmType studioName starName 1977 1977 1977 124 124 124 104 95 95 color color color color color color Fox Fox Fox Disney Paramount Paramount Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers

Mighty Ducks 1991 Wayne's World 1992 Wayne's World 1992

3.5.1 Dependencias funcionales (FD)

3.5.1.1 Definicin
En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias multivaluadas y las restricciones de integridad referencial. Una dependencia funcional en una relacin R es una enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen B y se dice que "A1, A2,....An determina funcionalmente a B".

los mismos valores para cada atributo), entonces deben concordar tambin con otro atributo B" . Esta FD se escribira como A1,A2,....An -->
Por otro lado, si un conjunto de atributos A1,A2...An determina funcionalmente a ms de un atributo, A1, A2, ... An ---> B1 A1, A2, ... An ---> B2 A1, A2, ... An ---> Bm entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm

Movies(title, year, length, filmType, studioName, starName)


title Star Wars year length 1977 124 filmType studioName starName color Fox Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers

Star Wars

1977 124

color

Fox

Star Wars Mighty Ducks Wayne's World Wayne's World ...

1977 124

color

Fox

1991 104

color

Disney

1992 95

color

Paramount

1992 95

color

Paramount

title, year --> length title, year --> filmType title, year --> studioName title, year -/-> starName podemos entonces afirmar que: title, year --> length, filmType, studioName Quizs las dependencias funcionales ms evidentes sean las llaves. Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si: 1. Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin.

2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An }) La definicin anterior de llave es similar a la que se mencion anteriormente de superllave, sin embargo las superllaves no son llaves "mnimas", recordemos que una llave primaria se escoge de entre el conjunto de superllaves mnimas. Es importante hacer notar que una llave mnima no se refiere al nmero de atributos includos, se puede tener una llave mnima ABC y otra DE donde ambas son mnimas an cuando una de ellas sea todava de menor tamao que la otra. Al conjunto de dependencia funcionales de una relacin R se le denominar F.

3.5.1.2 Axiomas de Armstrong:

Reflexividad: sea y entonces Aumentacin: si entonces --> Transitividad: si

un conjunto de atributos --> * --> y es un conjunto de atributos --> y --> entonces -->

*Nota:

De manera general una dependencia funcional de la forma > se considera "dependencia funcional trivial" si

--

Si al menos algn elemento de no pertenece a se considera una dependencia no trivial. Si ningn elemento de pertenece a entonces se considera una dependencia completamente no trivial

3.5.1.3 Reglas adicionales


Unin: si --> y Decomposicin: si

--> -->

entonces --> entonces -->

-->

Pseudotransitividad: si >

-->

-->

entonces

--

3.5.1.4 Cerradura de un conjunto de atributos


Para un esquema R y un conjunto de atributos > R entonces es superllave para determinar lo anterior se puede encontrar que dependen funcionalmente de teniendo R(A,B,C,D,E) si A+=(A,B,C,D,E), entonces A--> R entonces A es superllave La cerradura se puede calcular siguiendo el siguiente algoritmo: entrada: salida: +
result= while changes to result do for each ( do begin if result then result=result end end result --> (reflexividad) --> , (transitividad) --> --> F ) = =result

, si

--

+, todos los atributos

,F

teniendo R (A,B,C,D,E,F) y F las dependencias: AB-->C, BC-->AD, D-->E, CF-->B. Comprobar que {A,B}+ ={A,B,C,D,E}

Si {A,B}+ = {A,B,C,D,E,F} entonces podramos afirmar que AB es superllave, pero para ello sera necesaria alguna dependencia adicional ej. AB --> CF El calcular la cerradura es empleado para:

Verificar si es una superllave, calculando + y revisando si + contiene a todos los atributos de la relacin R. Verificar una dependencia funcional --> (es decir, si pertenece a F+) checando si +. Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relacin R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional --> S.

3.5.2 Primera forma normal Una tabla se encuentra en 1a NF, si todos sus atributos son atmicos (indivisibles) El ejemplo clsico:
nombre direccin telfono

En 1a. NF
nombre apellido_paterno apellido_materno direccin telfono

3.5.3 Segunda forma normal Una tabla se encuentra en 2a NF, si est en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave. Si tenemos la tabla:

calificaciones_cursos
id_estudiante depto clave_curso descripcin calificacin

NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin Analizando todas las dependencias funcionales: { id,clave,depto} --> descripcin {clave,depto} --> descripcin { id,clave,depto} --> calificacin Para realizar la normalizacin (2NF) la relacin se descompondra en:
curso
depto clave_curso descripcin

estud_curso
id depto clave_curso calificacin

La descomposicin se basa bsicamente en:


La intuicin Las dependencias funcionales

Es importante que al descomponer una relacin exista:


Descomposicin sin prdida Preservacin de dependencias funcionales

3.5.4 Descomposicin sin prdida

Al descomponer una relacin R en varias relaciones R1 y R2 se debe verificar que no haya prdidas, es decir, que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas. Decimos entonces que para una descomposicin en R1 y R2 no hay prdida si: { R1 R2 --> R1 } F+

o bien si { R1 R2 --> R2 } F+

Para el ejemplo anterior la relacin


id_estudiante depto clave_curso descripcin calificacin

F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } tiene F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y dicha relacin se descompone en:
depto clave_curso descripcin

id_estudiante

depto

clave_curso

calificacin

donde R1 R2 = depto,clave_curso donde depto,clave_curso ->descripcin y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

3.5.5 Preservacin de dependencias Al descomponer una relacin R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las dependencias funcionales iniciales. De esta manera se garantiza que una actualizacin no provoque una relacin invlida, verificando las FDs o bien a travs de combinaciones de relaciones(productos o joins) aunque esto ltimo no es muy eficiente. Para ello se analizan todas la dependencias funcionales Fi para cada Ri que debern ser un subconjunto de F+ De manera que F' = F1 F2 ...Fn

y la preservacin se verifica si F'+= F+ para el ejemplo anterior teniendo: F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } F1= depto,clave_curso--> descripcin F2= id_estudiante,depto,clave_curso --> calificacin F' = F1 F2

depto,clave_curso--> descripcin id_estudiante,depto,clave_curso --> calificacin

F'+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y como F'+= F+ entonces si hay preservacin de dependencias.

3.5.6 Forma normal de Boyce-Codd (BCNF)

3.5.6.1 Caractersticas
Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:

X --> A es una dependencia funcional trivial

X es una super llave

BCNF no necesariamente preserva las dependencias funcionales F'+ != F+

3.5.6.2 Algoritmo general de descomposicin tratando de alcanzar BCNF

result= {R} done=false calcular F+ while (! done) do if(existe un esquema Ri en result que no est en BCNF) then si no trivial en Ri --> es una dependencia funcional tal que est en F+ y else done=true end =0 result= ( result - Ri ) ( Ri ) ( , ) --> Ri no

Ejemplo: R(A,B,C,D)
B--> C
B-->D (B)+ = {CD}

La superllave sera {AB} por lo tanto no cumple con BCNF (B-->CD y B no es superllave). Descomponiendo usando B-->CD (A,B) (B,C,D) Esta ltima en BCNF

3.5.7 Tercera forma normal

3.5.7.1 Caractersticas
Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:

X --> A es una dependencia funcional trivial

X es una super llave

A es miembro de una llave candidata de R Lo anterior no quiere decir que una sola llave candidata deba contener a todos los atributos de A, cada atributo de A puede estar contenido en llaves candidatas diferentes.

Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que da flexibilidad a las relaciones.

Podemos afirmar entonces que: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". ejemplo, dada la relacin
branch-name customer-name banker-name office-number

banker-name --> branch-name office-number customer-name branch-name --> banker-name Se puede observar {customer-name branch-name} determina al resto de los atributos as que es la superllave de R. No est en 3NF porque:

Las DFs no son triviales En la primer dependencia, "banker-name" no es superllave de R Se puede observar que office-number y banker-name no son parte de alguna llave candidata

se descompondra en:
banker-name branch-name office-number

banker-name --> branch-name office-number


customer-name branch-name banker-name

customer-name branch-name --> banker-name banker-name --> branch-name Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales En la segunda relacin, la segunda DF no cumple que banker-name es superllave

En la segunda relacin, la segunda DF, branch-name es miembro de la llave candidata {customer-name, branch-name}

Al cumplirse la 3er regla se confirma que la descomposicin est en 3NF. Se puede observar que al no cumplir con las 2 primeras no est en BCNF pero gracias al relajamiento si est en 3NF Otro ejemplo:
deptos
nombre_depto extensin id_jefe

nombre_depto --> extensin, jefe empleados


id_empleado nombre_depto id_jefe

id_empleado --> nombre_depto, id_jefe nombre_depto --> id_jefe

No est en 3NF porque:


Las DFs no son triviales En la dependencia "nombre_depto-->id_jefe" de la segunda relacin, "nombre_depto" no es superllave de R Se puede observar nuevamente para la segunda relacin que id_jefe no es parte de alguna llave candidata

Aplicando la descomposicin:
deptos
nombre_depto extensin id_jefe

nombre_depto --> extensin, jefe empleados


id_empleado nombre_depto

id_empleado --> nombre_depto

Esta descomposicin si est en 3NF porque:


No hay dependencias funcionales triviales Para toda dependencia X--> A , X es superllave.

Se observa como la relacin no solo est en 3NF sino tambin en BCNF por cumplir con la segunda regla.

3.5.7.2 Algoritmo general de descomposicin tratando de alcanzar 3NF 3.5.7.2.1 Forma cannica de las FDs (Fc)
La forma cannica de F es aquel conjunto mnimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias. Para obtener la Fc se deben extraer todos los miembros "extraos", suponga un conjunto F de dependencias funcionales y la dependencia --> est en F.

El atributo A es extrao en F lgicamente implica (F - { Ejemplo: F = { A --> C , AB --> C }

si A -->

y }) {( - A ) --> }

B es extrao en AB --> C porque { A --> C, AB --> C } lgicamente implica A --> C (el resultado de quitar B de AB --> C ).

El atributo A es extrao en si A el conjunto de dependencias (F - { implica lgicamente a F Ejemplo: F = { A --> C , AB --> CD}

y -->

})

--> (

-A)}

C es extrao en AB --> CD porque A B --> C puede ser inferido an despus de eliminar C Test para verificar si un atributo es extrao Dado un conjunto de dependencias F y

-->

est en F

Para verificar si A
o o

es extrao en } - A )+ usando las dependencias en F

calcular ( {

verificar si ( { } - A )+ contiene a , si lo hace entonces A es extrao Para verificar si A es extrao en o calcular + usando solo las dependencias en: F'=(F - {
o

-->

})

--> (

- A) }

verificar si

+ contiene a A, si lo hace entonces A es extrao

3.5.7.2.2 Algoritmo basado en Fc


Fc: Forma cannica de las FDs

1. Para cada dependencia X --> Y en Fc, crear una relacin Ri (X,Y) 2. Si ninguna de las Ris contiene una de las superllaves de la relacin, crear Ri(X) donde X es una de las superllaves de la relacin original 3. Si Ri y Rj tienen una llave en comn, mezclar Ri y Rj 4. Eliminar relaciones redundantes

*El algoritmo anterior garantiza que en una descomposicin no haya prdida (al incluir por lo menos en una relacin una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas). Ejemplo:
sid name street city zip

student Fc: sid -->name,street,city street, city-->zip zip --> city Descomponer en 3NF 1. 2. 3. 4. R1(sid, name, street, city), R2(zip, street, city), R3(zip, city) Eliminar R3
sid name street city

R1 sid -->name,street,city
zip street city

R2 street, city-->zip zip --> city 3.5.8 BCNF vs 3NF

Como se mencion anteriormente: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". En la prctica la mayora de los esquemas en 3NF tambin estn en BCNF, contraejemplo: (Sucursal, Cliente, Banquero) banquero --> sucursal sucursal, cliente --> banquero est en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando: suc-banquero (sucursal, banquero) suc-cliente (sucursal, cliente) Nuevamente se presentan las prdidas de dependencias Qu es mejor ? BCNF o 3NF ?

De manera general se puede decir que ambas son buenas. El caso ideal es conseguir BCNF sin prdidas y con preservacin de dependencias. Si se alcanza BCNF pero no hay preservacin de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de prdidas y debe preservar dependencias).

3.6 Conclusiones
De manera que las metas del diseo de bases de datos con dependencias funcionales son:

BCNF* Descomposicin sin prdida Preservacin de dependencias

* Llegar a una forma BCNF puede llegar a ser complicado, debido a esto en muchas ocasiones es suficiente con

Вам также может понравиться