You are on page 1of 54

Modelo entidad-relación

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas.
Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|Modelo entidad-relación}}

~~~~

Ejemplo de diagrama E-R.

Un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datosque permite representar las entidades relevantes de unsistema de información así como sus interrelaciones y propiedades.
Índice
[ocultar]

 

1 Modelado Entidad-Relación 2 Base teórica y conceptual

o o o o 

2.1 Entidad 2.2 Atributos 2.3 Relación 2.4 Conjunto de relaciones

3 Restricciones

o o  

3.1 Correspondencia de cardinalidades 3.2 Restricciones de participación

4 Claves 5 Diagrama entidad-relación

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 débiles 6.2 Cardinalidad de las relaciones 6.3 Atributos en relaciones 6.4 Herencia 6.5 Agregación

7 Véase también 8 Enlaces externos

Modelado Entidad-Relación[editar · editar código]
El Modelo Entidad-Relación. 1. Se elabora el diagrama (o diagramas) entidad-relación. 2. Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama. El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

 

Transformación de relaciones múltiples en binarias. Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).

Conversión en tablas (en caso de utilizar una base de datos relacional).

Base teórica y conceptual[editar · editar código]
El modelo de datos entidad-relación está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objetos.

Entidad[editar · editar código]
Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se difere ncia unívocamente 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 automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de chasis).

Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).

Una entidad puede ser un objeto con existencia física 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 características o atributos. Por ejemplo, la entidad Persona las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento.

Atributos[editar · editar código]
Los atributos son las características que definen o identifican a una entidad. Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que considere más 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 específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca. Ejemplos: A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades:

   

(1, Sofía, 38 años, 2) (2, Josefa, 19 años, 5) (3, Carlos, 20 años, 2) ...

Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus atributos. Nótese que dos o más 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 número 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, números, solo dos letras, solo números mayores que cero, solo números enteros...).

Cuando algún 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.

Relación[editar · editar código]
Describe cierta dependencia entre entidades o permite la asociación de las mismas.

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

Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un huésped (entidad), se aloja (relación) en una habitación (entidad).

Conjunto de relaciones[editar · editar código]
Consiste en una colección, o conjunto, de relaciones de la misma naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de la forma habitación-huésped, permiten obtener la información de los huéspedes y sus respectivas habitaciones. La dependencia o asociación entre los conjuntos de entidades es llamada participación. En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en el conjunto de relaciones habitación-huésped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relación.

Restricciones[editar · editar código]
Son reglas que deben mantener los datos almacenados en la base de datos.

Correspondencia de cardinalidades[editar · editar código]

Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de cardinalidad indica el número 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 relación vehículo - matrícula: cada vehículo tiene una única matrícula, y cada matrícula está asociada a un único vehículo).

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 asociación, y cada ciudadano puede pertenecer a muchas asociaciones distintas).

Restricciones de participación[editar · editar código]
Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participación puede ser de dos tipos:

 

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

Claves[editar · editar código]
Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar inequívocamente cada una de las entidades pertenecientes a dicha colección. 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 unívocamente cada una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el resultado seguirá siendo una superclave.

los diagramas ER son un lenguaje gráfico para describir conceptos. Clave candidata: Dada una superclave. se deben considerar dos casos:  R NO tiene atributos asociados: En este caso. Formalmente. R. no pueden ser todos iguales para dos o más instancias. como clave primaria de R. .  Clave primaria: Es una clave candidata. Cabe destacar que para todo proceso de modelado. en esta sección profundizaremos en como representarlos gráficamente. Los valores de los atributos de una clave. se consideran los siguientes casos. Informalmente.  R es de muchos a muchos de A a B entonces se toma la unión de los atributos que conforman las claves primarias de A y de B. según sus cardinalidades:  R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A. Diagrama entidad-relación[editar · editar código] Anteriormente detallamos los conceptos relacionados al modelo ER.  R tiene atributos asociados: En este caso. como clave primaria de R. se usa como clave primaria de R la unión de las claves primarias de todos los conjuntos de entidades participantes. con los conjuntos de entidades participantes A y B. para identificar unívocamente las entidades en un conjunto de entidades. Para poder distinguir unívocamente las relaciones en un conjunto de relaciones R. si ésta deja de serlo quitando únicamente uno de los atributos que la componen. estos nos brindan conocimiento necesario y además fundamentan nuestro modelo al momento de presentarlo a terceros.  R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias. sobre las que se pretende determinar la clave primaria está compuesto de relaciones binarias. elegida por el diseñador de la base de datos. como clave primaria de R.  R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B. Si el conjunto de relaciones. son simples dibujos o gráficos que describen información que trata un sistema de información y el software que lo automatiza. entonces ésta es una clave candidata. como clave primaria de R. siempre hay que tener en claro los conceptos. se usa como clave primaria de R la unión de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Diagramas extendidos[editar · editar código] DER extendido Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que tienen limitaciones semánticas. sino descritos textualmente en otros documentos adjuntos.Entidades[editar · editar código] Las entidades son el fundamento del modelo entidad relación. Relaciones[editar · editar código] Se representan mediante un rombo etiquetado en su interior con un verbo. Por ejemplo. como una persona o un avión. transaccionales. Por motivos de legibilidad. historicas y temporales Atributos[editar · editar código] Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Por ese motivo se suelen utilizar losdiagramas Entidad-Relación extendidos que incorporan algunos elementos más al lenguaje: Entidades fuertes y débiles[editar · editar código] . Este rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona. Podemos adoptar como definición de entidad cualquier cosa o parte del mundo que es distinguible del resto. en un sistema bancario. que pueden ser de tipo: maestras. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. los atributos suelen no aparecer representados en el diagrama entidadrelación. para así saber cuál es la relación que lleva cada uno. Se representan por medio de un rectángulo. las personas y las cuentas bancarias se podrían interpretar como entidades. como por ejemplo un préstamo o una reserva. Las entidades pueden representar entes concretos. o abstractas.

"1:N" y "N:M". La entidad débil no puede ser identificada sin la entidad fuerte relacionada. Es una relación 1:1. Las ocurrencias de la entidad débil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada. Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación:   "0" si cada instancia de la entidad no está obligada a participar en la relación. "M". la que más se usa actualmente es el unificado. Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser identificada unívocamente. aquella que no puede ser unívocamente identificada solamente por sus atributos. Las entidades débiles se representan.  Dependencia por identificación.  "N" . Una entidad débil es aquella que no puede existir sin participar en la relación. es decir. Ejemplos de relaciones que expresan cardinalidad:  Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y viceversa. un rectángulo con doble línea. "1" si toda instancia de la entidad está obligada a participar en la relación y. aunque la notación depende del lenguaje utilizado. Cardinalidad de las relaciones[editar · editar código] El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación. se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta última se pueda identificar. . En los casos en que se requiera. es decir.Cuando una entidad participa en una relación puede adquirir un papel fuerte odébil. solamente participa una vez. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades débiles:  Dependencia por existencia. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIÓN. además. ó "*" si cada instancia de la entidad no está obligada a participar en la relación y puede hacerlo cualquier número de veces. para identificar una edición necesitamos conocer el identificador del libro). respectivamente: "1:1".mediante un doble rectángulo.

Un ejemplo típico son las relaciones de tipo "histórico" donde debe constar una fecha o una hora. Atributos en relaciones[editar · editar código] Las relaciones también pueden tener atributos asociados. Es una relación N:M. Agregación[editar · editar código] Ejemplo agregación Es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más alto. Se representan igual que los atributos de las entidades. La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". el atributo "Fecha de emisión" de la factura debería colocarse en la relación "se emite". Las entidades "hijo" se conectan por la base del triángulo. Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Herencia[editar · editar código] La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. En tal caso. La relación de herencia se representa mediante un triángulo interconectado por líneas a las entidades. En la figura se . no necesitan ser representadas dos veces en el diagrama. pero una persona puede tener varias facturas emitidas a su nombre. Por ejemplo. La entidad conectada por el vértice superior del triángulo es la entidad "padre". supongamos que es necesario hacer constar la fecha de emisión de una factura a un cliente. y que es posible emitir duplicados de la factura (con distinta fecha). Todas las facturas se emiten a nombre de alguien. Es una relación 1:N. Por tanto. Solamente puede existir una entidad "padre" (herencia simple).  Un cliente (entidad) puede comprar (relación) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Se representa englobando la relación abstraída y las entidades que participan en ella en un rectángulo. La herencia es un tipo de relación entre una entidad "padre" y una entidad "hijo".

Modelo de datos.muestra un ejemplo de agregación en el que se representa la situación en la que un profesor. Atributos y Llaves Los atributos. En general. Por ejemplo. para asegurar la integridad de los datos. Modelo relacional. Veremos cómo hacer esto en la sección siguiente. al tiempo que . en Chile. la fecha de nacimiento de una persona puede ser una fecha cualquiera anterior a la fecha actual. cuando está impartiendo una clase. Base de datos. es deseable que la mayor cantidad de atributos posible se definan como obligatorios. Véase también[editar · editar código]       Ingeniería del software. Peter Chen. en cambio. Como el nombre lo indica. Un atributo opcional. puesto que permite simplificar mucho algunas operaciones. En general los dominios serán más bien amplios. El dominio es. aunque cuando se lleva a cabo la implementación es preferible restringir los dominios lo más posible de manera que el gestor de bases de datos automáticamente haga algunas verificaciones sobre los datos que se almacenan. Es la implementación de un modelo de datos. en algunos casos) a la fecha de hoy. puede quedar sin definir para algunas de las entidades del conjunto de entidades. es el subconjunto de fechas que son anteriores (o iguales. El dominio de los números de teléfono.). etc. UML. entonces. un atributo obligatorio es aquel que siempre debe estar definido para toda entidad. Es la visión estática de un sistema de información. puede poner una incidencia ocurrida a lo largo de ésta (se fue la luz. entonces. Otro lenguaje que permite describir modelos de datos (entre otras cosas). El autor del modelo entidad-relación. Una técnica formal para describir modelos de datos. Disciplina donde se encuadra el análisis y diseño de datos. El dominio de las fechas de nacimiento. donde las X son dígitos. falta la configuración de un determinado software. tanto de entidades como de relaciones. toman sus valores posibles de un conjunto llamado dominio. podría ser una cadena de caracteres que cumpliera con el formato (XX) XXX-XXXX (simplificado). el conjunto de valores posibles que puede tomar un atributo dado de un conjunto de entidades dado. De partida es necesario definir cuáles de ellos son opcionales y cuáles son obligatorios. Algunos atributos de un conjunto de entidades son especiales.

incluiremos en nuestro modelo los datos de los experimentos que se publican en cada artículo para obtener observaciones sobre las hipótesis que los autores plantean. puesto que sus elementos cuentan con los atributos suficientes para ser identificados unívocamente. una línea número 2. Por ejemplo. Además. cada línea dentro de una factura es una entidad débil. ni modo alguno de distinguirlos de forma . Para ilustrar este nuevo concepto. no es posible identificar completamente la entidad. una superllave puede contener más atributos de los necesarios para identificar unívocamente cada entidad. Un ejemplo claro sería un modelo para almacenar facturas de venta de bienes o servicios. En este caso. se dice que es un conjunto de entidades débil. Algunos conjuntos de entidades pueden no tener atributos suficientes para formar una llave primaria. Un conjunto de entidades puede tener más de una superllave. Finalmente. Así cada factura tendría una línea número 1. En nuestro ejemplo anterior. Veremos más sobre esto en la sección siguiente. puesto que si falta alguno. otra superllave para personas podría ser el nombre. el nombre y RUT de una persona sería una superllave. hablamos de una línea en particular como la línea número 5 de la factura número 18. la fecha de nacimiento y la dirección postal. todos los conjuntos de entidades son fuertes. no hay ningún código asociado intrínsecamente a un experimento. Otro concepto importante relacionado con los atributos es el de las llaves. algunos experimentos serán similares o iguales entre artículos. vivan en la misma casa y se llamen igual.asegura una mejor integridad de los datos. etc. Cada artículo puede utilizar uno. Observe que todos los atributos que forman una llave candidata son obligatorios. Cada factura en sí es una entidad fuerte. pero omitiendo cualquiera de esos atributos es razonable esperar encontrar coincidencias. puesto que no se puede identificar una línea en particular sino en tanto pertenece a una factura.289. 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. ninguno o varios experimentos. por lo tanto. se escoge una de las llaves candidatas y se designa como llave primaria del conjunto de entidades. y por lo tanto como llave candidata. en el caso del nombre y RUT. usando sólo el RUT serviría también como superllave. Por ejemplo. puesto que dos personas pueden tener el mismo nombre. Sólo el nombre no podría serlo. Eliminando los atributos innecesarios de las superllaves se obtienen las llaves candidatas. puesto que es muy improbable que dos personas hayan nacido el mismo día.

la elección se torna complicada: se podría escoger como llave primaria un número identificador por país en conjunto con el país que emite dicho número. usar el RUT es una elección natural. en muchos casos estas llaves primarias son complejas de implementar. En el caso de las personas chilenas. Para personas de otros países. Pero dentro de cada artículo. un experimento tendrá un atributo obligatorio que le permitirá ser discriminado de entre el conjunto de experimentos de un mismo artículo (por ejemplo. Así. el número que el mismo autor le asigna en el artículo). lo cual indica que es débil.unívoca entre todos los artículos. La figura 5 ilustra el nuevo diagrama E-R. Este esquema puede verse en problemas si existe algún país que no emite . Sin embargo. Observe que el conjunto de entidades de experimentos se ha marcado como un rectángulo doble. Figura 5: El diagrama 4 con una entidad débil Con respecto a las llaves primarias de nuestro modelo de ejemplo. los conjuntos de entidades fuertes tienen por definición llaves primarias. cada experimento es único.

en singular. se nos ofrece un folleto o catálogo de productos y servicios. y las diferentes formas de pago que podemos utilizar. ficticio. la forma de pago que . puesto que otro artículo podría llevar el mismo título. es decir. Una elección teóricamente mejor sería el uso del resumen como llave primaria.números identificadores para sus habitantes. que suelen funcionar de forma diferente). como en autor_id. independiente de cada uno de los identificadores de los otros conjuntos. con un ejemplo práctico. las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. en la que los alumnos se matriculan y asisten a clase de forma temporal. y el pago parcial de los mismos. En el desarrollo de software para empresas. de alguna forma. Descripción del proceso de matriculación (el caso de uso) Vamos a imaginarnos que nos encontramos en una academia de idiomas. Para resolver este problema práctico agregaremos a cada una de estos conjuntos un identificador numérico. voy a utilizar un ejemplo de uno de esos modelos: la gestión de matriculación de los alumnos. un buen modelado de datos. Voy a explicar en este artículo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementación). Este identificador se generará internamente en la base de datos. estamos especializados en el software de gestión de empresas de enseñanza. en el que se detallan los diferentes cursos en los que nos podemos matricular. daré una idea de los índices. Asimismo. procedimientos almacenados y triggers que nos pueden resultar útiles para que el rendimiento de la base de datos sea bueno. y no tendrá ningún significado fuera de ella. De paso. Cuando llegamos a la academia. elección que en la práctica es irrisoria cuando menos. el almacenamiento de la información de un modo organizado es fundamental… la mayoría 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 aplicación. único dentro de cada conjunto de entidades. En este caso me voy a centrar en lo que se llaman “grupos abiertos”. Una convención usual es ponerle el nombre del conjunto de entidades. incluyendo los recibos que tienen que pagar. En este artículo voy a intentar explicar. Como. identificar un artículo es complejo: el uso del título no es suficiente. grupos en los que cualquiera se puede matricular (en oposición a los grupos de empresa o grupos cerrados. Seleccionamos uno de los cursos. seguido de id.

nosotros no solemos poner campos requeridos… preferimos hacer la gestión dentro de la lógica de negocio. en este caso. el horario al que vamos a asistir. y con esta información nos matriculamos. Primero. en realidad. se calcula como el importe total del recibo menos la suma de los pagos parciales… como hacer este cálculo cada vez que nos hace falta ralentiza el funcionamiento del sistema. Nunca se sabe lo que te vas a encontrar. algunas generalidades sobre cómo crear los campos. llegado este punto. En muchos casos. el importe pendiente de un recibo. y se nos han dado casos de campos de los que estábamos completamente seguros que eran requeridos y hemos tenido que quitar la marca. Es decir. que es una pequeña cantidad del primer recibo. en el que se incluyen todos nuestros datos. En el siguiente día de clase. y empezamos a estudiar. No se duplica información. que paguemos una reserva de plaza. el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. nos presentamos. introducen en su sistema de información nuestros datos y nos imprimen el contrato de prestación de servicios. Nos piden. cosas así). Todas las tablas tienen así un identificador interno. una de las reglas básica es que la misma información no puede estar en dos sitios. En general. En la academia.más nos conviene. vamos a utilizar un pago mensual. mantenido por el sistema. 2. de paso. Como forma de pago. Por ejemplo: 1. hacemos un campo . salvo… 4. y queremos que se nos domicilie el pago a través de nuestra cuenta bancaria. 3. las claves ajenas son más fáciles de mantener. que permiten acceder de forma rápida a información… por ejemplo. y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo… nos da la bienvenida. Generalidades Hay algunas cosas básicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura. creamos campos calculados. Así. La clave primaria de las tablas siempre es un identificador autoincremental. El modelo de datos A partir de aquí haré una descripción de la estructura de tablas y columnas para almacenar la información de este proceso.

Los clientes pueden ser empresas (personas jurídicas). pero también puede que no. la forma de pago. Grupos: dentro de cada curso. domicilación bancaria. a través de Triggers de la base de datos). o Alumnos: la gente que va a clase. anual. la gestión de recibos y pagos que hacemos en realidad es más compleja de lo que voy a describir aquí. o o Clientes: el que paga… puede ser el mismo que el alumno. sí. Como antes. las distintas opciones de pago que existen (es parte del folleto también). ni espacios. Un mismo cliente puede tener múltiples alumnos. 5. etc. Aunque el gestor de base de datos lo admita. Descripción de las entidades El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. incluyendo las cuentas bancarias del cliente. las fechas. Según el caso de uso descrito. Representa el catálogo o folleto que te dan al llegar al centro. Medios de pago: Contiene los diferentes métodos que los clientes pueden usar para pagar (contado. En otro artículo haré una descripción más completa. Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro. etc. Trimestral. se refleja en el contrato que te dan para firmar. son las que nosotros usamos): o o o Cursos: almacena la oferta formativa del centro. etc. . los diferentes horarios a los que se puede asistir. En los nombres de los campos no ponemos caracteres especiales (ni acentos. De forma física. el modelo que utilizamos es bastante más complejo que el que voy a describir aquí… en un artículo posterior lo describiré en detalle. porque luego nunca se sabe desde dónde vas a tener que acceder. las tablas necesarias son las siguientes (al menos. mensual. En este caso. pero por motivos de rendimiento (y siempre está sincronizada). La información está duplicada en dos sitios.). etc). Formas de Pago: para cada curso.calculado que se mantiene automáticamente (en nuestro caso. o o o Matrículas: Refleja en qué curso nos matriculamos. no lo hacemos. los alumnos son personas físicas. Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez).

así que necesitamos una tabla para gestionarlo. Aquí podéis ver el modelo gráficamente: Con PK se marcan las claves primarias. y no queremos perder esa información histórica.o Alumnos en grupos: refleja los alumnos que están asignados a los distintos grupos. . Las flechas indican que una tabla es „hija‟ de otra. El alumno puede cambiar de grupo. no lo puedo evitar. y con FK. las claves ajenas… algunas líneas se cruzan. con la punta de flecha apuntando al padre.

Cursos o o nombre: varchar(100) descripcion: Memo. si creamos uno. se marca aquí. etc. En algún sistema hemos hecho. en el contrato que se imprime para el cliente. En la siguiente sección describiremos los campos de cada tabla. que en cualquier caso deben estar ocultas al usuario final. A la hora de presentárselo al cliente. En uno de los sistemas que tenemos. con fechas. por tipologías. en lugar de esto. Si además del importe del curso hay un importe de matrícula. poder mostrar primero las que más nos interesen. El concepto del recibo de matrícula. Si es 1. Campos para las entidades Sólo describiré los campos más importantes. distintos campos memo. para hacer una descripción larga del curso en el que el alumno se está matriculando. importe_matricula: float. Grupos o nombre: varchar(100) . descripciones. en lugar de tener un campo memo. Es el importe de cada recibo que se cobrará numero_meses: integer.Como podéis ver. tenemos una tabla separada en la que se guardan. o o o numero_orden: integer. una estructura de plantillas de recibos. Eso permite más flexibilidad y más control. Se utilizará. o o fecha_inicio: date fecha_fin: date Formas de pago o o o nombre: varchar(100) importe: float. uno cada tres meses. personalizadas. pero el modelo es bastante más complejo. sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas. si es 3. se creará un recibo cada mes mientras dure la matriculación. etc. y no incluiré los campos de clave primaria y ajena que se describen en el gráfico. El número de meses de cada recibo. que se imprimen en distintos lugares del contrato. concepto_matricula.

Es el número de alumnos existentes en el grupo. En general. a través de una serie de Triggers en la base de datos. email. para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando. Por defecto. Por ejemplo. En nuestros sistemas. teléfonos. Este campo es de sólo lectura para el usuario. Así. en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita. pero eso lo ampliaré en otro artículo. o o o lugar: varchar(100) de impartición del grupo. hacemos una gestión de aulas. y volver después. que se mantiene con Triggers. o o fecha_inicio: date fecha_fin: date. este es el único campo requerido (por código.o codigo: varchar(20). el usuario puede dar de alta el registro aunque no tenga todos los datos. del grupo horario: varchar(100) del grupo. o o maximo_alumnos: Integer. Clientes o nombre: varchar(100). Máximo número de alumnos permitidos en el grupo. o o o primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): Esto es un campo calculado. de datos personales (profesión. no en la base) que tenemos. el horario se trata como una tabla por debajo de esta. las del curso al que pertenece el grupo.) Alumnos . Siempre viene bien tener una codificación además del nombre. normalmente. numero_alumnos: Integer. pero no voy a entrar en tanto nivel de detalle ahora. En realidad. etc. y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen. y es calculado. notas: memo. para poder coger de forma rápida el conjunto Nombre+‟ „+primer_apellido+‟ „+segundo_apellido o o direccion: memo codigo_postal: varchar(20): no hay que ser tacaño… de vez en cuando hay que meter una dirección extranjera y el código postal puede ser más grande. o o o poblacion: varchar(50) notas_internas: memo etc.

Lo mismo que en clientes. Normalmente. teléfonos. y también con el cliente). necesitamos los siguientes campos: o o o fecha_inicio: date. pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): etc. entonces se tiene que rellenar la información bancaria del cliente. fecha_fin: date. pero teniendo uno por defecto. los motivos de baja son una tabla separada. Contado. es necesario que cada matrícula esté asociada con el alumno. .) Medios de pago o o o o o o o o tipo_medio: Integer. forma de pago. Suele ser buena idea dejarlo abierto. pero no lo es… podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar. alumno y cliente (esto último puede parece redundante. de datos personales (profesión. por ejemplo). el de la forma de pago escogida. pero hay gente que puede matricularse después o terminar antes (si se da de baja. por_defecto: boolean. Normalmente. Matrículas Además de los datos de curso. o motivo_baja: varchar(100). al crearse. Así. medio de pago. digamos. inglés y francés… el inglés lo paga el padre y el francés la madre. Banco nombre_titular: varchar(100) direccion_titular: memo entidad: varchar(4) oficina: varchar(4) dc: varchar(2) numero_cuenta: varchar(10). que suelen ser: Sin Pago. pero puede ser también distinto… descuentos por familiares.o o o o o nombre: varchar(100). y se le pone por defecto. para luego poder obtener estadísticas de número de bajas por tipo. para no tener que rellenarlo siempre. para que el cliente lo pueda cambiar. cosas así. las del curso. Por defecto. Por defecto. Se suele preguntar el medio de pago. Normalmente tiene una tabla asociada con los tipos de medios de pago. cosas así. importe: real. Si el tipo_medio es banco. etc. cada cliente. email. se crea un medio de pago “contado”.

tarjeta. . En el ejemplo que estoy describiendo. talón.Recibos o o o o o o fecha_emision: date fecha_cobro_completo: date numero_recibo: varchar(20) concepto: varchar(50) importe_recibo: float. etc. que permite acceder a la información sin tener que sumar. Es un campo de sólo lectura. lo que es muy conveniente para dejar trozos de la lógica de negocio asociados con la base de datos. que actualiza el campo en base al contenido del nombre y los apellidos. pero cuando el alumno cambia de grupo. Los sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados. actualizado a través de triggers. importe_pendiente: float. Puede ser: contado. Alumnos en grupos o o fecha_inicio: date fecha_fin: date. es un trigger BEFORE INSERT y BEFORE UPDATE. Triggers y procedimientos almacenados El modelo de datos y la lógica del negocio están muy estrechamente relacionados. para una matrícula puede haber varios registros de alumnos en grupos. Pagos o o o fecha: date importe: real forma_cobro: varchar(20). Normalmente es una tabla separada. pagando más. tanto por motivos de organización del código como por motivos de rendimiento (un procedimiento almacenado es varios órdenes de magnitud más rápido que hacer el mismo proceso a través de un lenguaje de programación). Suele ser una intersección entre la duración del grupo y la de la matrícula. igual que el caso de los tipos de baja. hay varios triggers y procedimientos que se usan: o Actualización de los campos “NombreCompleto” de alumnos y clientes: normalmente. Hay que tener en cuenta también la posibilidad de que en un mismo curso. un alumno pueda asistir a varios grupos (esto también lo he visto). transferencia.

un ejemplo práctico I” . . Stock Cualquier otra idea será bienvenida… 29 Comentarios » ← Avanza 2 – Puesta en marcha Networking profesional.Yi3UL57Q. que se ejecuta en el proceso de creación de la matrícula (o un trigger AFTER INSERT). que crea los recibos de la matrícula en base al importe y forma de pago seleccionadas.o Actualización del campo “ImportePagado” de recibos.dpuf Modelo relacional El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. la crisis como excusa para hacer buenos amigos → 29 opiniones sobre “Modelo entidad-relación. que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo. describiendo otros submodelos de sistemas que hemos desarrollado… algunas ideas que tengo: 1. UPDATE y DELETE de pagos. de los laboratorios IBM en San José (California). o Es habitual hacer un procedimiento CREARRECIBOS. AFTER INSERT. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd.ender.See more at: http://www. Facturación 3.es/2010/03/modelo-entidad-relacion-un-ejemplo-practico-imatriculacion/#sthash. no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. Gestión de horarios y citas 2. En las próximas semanas continuaré esta serie de artículos. Gestión de horas trabajadas 4.

el Cálculo relacional sólo indica lo que se desea devolver. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo. y columnas (también llamadas campos). una relación representa una tabla que no es más que un conjunto de filas. Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd. la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o tupla). el esquema contiene losmetadatos de la relación.2 Instancias 2 Base de datos relacional 3 Véase también Descripción[editar · editar código] En este modelo todos los datos son almacenados en relaciones. es decir. El Álgebra relacional permite describir la forma de realizar una consulta. en otras palabras. en cambio. Esquema[editar · editar código] Un esquema contiene la definición de una estructura (generalmente relaciones o tablas de una base de datos). . actualmente se cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional. esto es. Para manipular la información utilizamos un lenguaje relacional.Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados «tuplas».1 Esquema 1. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información. determina la identidad de la relación y qué tipo de información podrá ser almacenada dentro de ella. Todo esquema constará de:  Nombre de la relación (su identificador). De manera simple. y como cada relación es un conjunto de datos. cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. el orden en el que éstos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. Este modelo considera la base de datos como una colección de relaciones. Índice [ocultar]  1 Descripción o o   1.

Estrictamente hablando el término se refiere a una colección específica de datos pero a menudo se le usa. Nombre de los atributos (o campos) de la relación y sus dominios. Algunas o todas las filas con todas o algunas columnas   Cada fila es una tupla. Entre las ventajas de este modelo están: 1. Base de datos relacional[editar · editar código] Artículo principal: Base de datos relacional. como por ejemplo:   Ciertos caracteres y números (una sola columna de una sola fila). Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros (líneas) y campos (columnas). Garantiza herramientas para evitar la duplicidad de registros. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del inglés relational database management system). integer. Garantiza la integridad referencial: Así al eliminar un registro elimina todos los registros relacionados dependientes. pero también es valido referirnos a una instancia cuando trabajamos o mostramos únicamente un subconjunto de la información contenida en una relación o tabla. que se vinculan entre sí por un campo en común. en ambos casos posee las mismas características como por ejemplo el nombre de campo. .. Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización de una base de datos.. el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera óptima. En palabras no tan técnicas. tipo y longitud. A esta manera de construir bases de datos se le denomina modelo relacional. en forma errónea como sinónimo del software usado para gestionar esa colección de datos. El número de filas es llamado cardinalidad. El número de columnas es llamado aridad o grado. equivalente al tipo de dato por ejemplo character. date. el dominio de un atributo o campo define los valores permitidos para el mismo. 2. a través de campos claves o llaves. Instancias[editar · editar código] Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos. string. identificador o clave. a este campo generalmente se le denomina ID. se puede definir como el contenido de una tabla en un momento dado.

3. Como se mencionó en la sección anterior. Favorece la normalización por ser más comprensible y aplicable. En este capítulo nos concentraremos en desarrollar un buen modelo "lógico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podrá realizar el modelado físico en el DBMS. 3. Modelo relacional 3. lógico y físico. no se puede partir de un modelo conceptual para realizar un físico. el objetivo del modelo relacional es crear un "esquema" (schema). El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la información utilizada en algun problema o negocio.2 Por qué "modelo relacional" ? Puede resultar confuso el concepto de modelo entidad-relación vs modelo relacional.1 Introducción En el capítulo anterior se mencionaron 3 tipos de modelado: conceptual. es importante mencionar que es un paso necesario. pueden ser construídas de diversas maneras: . relaciones entre los datos. Estas tablas. lo cual como se mencionará posteriormente consiste de un conjunto de "tablas" que representan "relaciones". quizás porque ambos comparten casi las mismas palabras.

Las técnicas de nomalización se explican más adelante en este capítulo. título Star Wars año 1977 duración 124 104 95 tipo color color color Mighty Ducks 1991 Wayne's World 1992 Relación Películas . se garantiza un esquema aceptable. 3. en la primer técnica no es así. de ahí que se llame modelo conceptual. pero la ventaja de partir del modelo e-r es que la "normalización" es mínima por lo general. La primer técnica fue de las primeras en existir y.1 Tablas El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relación.3. El crear las tablas iniciales es mucho más simple a través de las reglas de conversión. la segunda al ser más reciente es mucho más conveniente en varios aspectos:     El partir de un diagrama visual es muy útil para apreciar los detalles. aún cuando se normalice de manera deficiente. Se podría pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas. Convertir el diagrama e-r a tablas y posteriormente aplicar también operaciones de normalización hasta conseguir el esquema óptimo.3 Conceptos básicos 3. Lo anterior tiene otra ventaja. como es de suponerse.  Creando un conjunto de tablas iniciales y aplicar operaciones de normalización hasta conseguir el esquema más óptimo.

Sin embargo las relaciones pueden representar más que entidades.3. duración.La relación Películas tiene la intención de manejar la información de las instancias en la entidad Películas. 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. que no sea divisible.3 Esquemas Es el nombre que se le da a una relación y el conjunto de atributos en ella.3. 3. no se puede pensar en un atributo como un "registro" o "estructura" de datos. (Star Wars. 1977. tipo) En un modelo relación. Películas (título.3. es decir. un diseño consiste de uno o más esquemas.2 Atributos Los atributos son las columnas de un relación y describen características particulares de ella.6 Representaciones equivalentes de una relación Las relaciones son un conjunto de tuplas. 3. . como se explicará más adelante. 3. El orden en que aparecen las tuplas es irrelevante.3.5 Dominios Se debe considerar que cada atributo (columna) debe ser atómico. cada renglón corresponde a una entidad película y cada columna corresponde a uno de los atributos de la entidad. 124.4 Tuplas Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos. no una lista de tuplas.3. color) 3. año.

Por eso es conveniente crear un "esquema".Así mismo el orden de los atributos tampoco es relevante año 1991 1992 1977 título tipo duración 104 95 124 Mighty Ducks color Wayne's World Star Wars color color Otra representación de la relación Películas 3. modelo e-r conversión a tablas .1 Introducción El modelo es una representación visual que gráficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organización.1-m. 3.4.4 Conversión del modelo e-r a un esquema de base de datos (Conversión a tablas) 3. el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos.2 Conversión a tablas desde un modelo con relaciones (11.m-m) Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema. un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Pero el modelo no nos presenta propiamente una instancia de los datos.4.

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) .   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 definición de columnas para cada tabla o conjuntos fuertes de entidades  columnas = nombre de atributos o conjuntos débiles de entidades  columnas = llave_primaria (dominante) U atributos(subordinado) o conjunto de relaciones R (m-m) entre A.

El diagrama anterior se convertiría 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 tendríamos 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 Conversión a tablas desde un modelo con generalización .

crear una tabla tal que:  columns (B) = atributos (B) U llave_primaria (A) o 2.modelo e-r de generalización 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. 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 generalización se convertiría al siguiente esquema: 1) A LLP_A atribs_A B1 atribs_B1 LLP_A B2 atribs_B2 LLP_A .

Si la entidad de nivel superior está relacionada con otra(s) entidades puede sugerirse emplear el método (1) ya que de esa manera la tabla (A) será la única involucrada en la relación. no hay una regla exacta de cual usar en determinado caso.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 métodos para convertir una generalización a tablas. de otra . A continuación se mencionan algunos consejos útiles para la determinación de cual método emplear: 1.

quizás sea recomendable el método (1). si se considera que hablamos de una generalización disjunta.forma se tendrían tres tablas (B1.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 relación se toman las llaves primarias de ambas entidades y éstas conforman la nueva llave primaria.B2 y B3) formando parte de la relación 2. en otro caso se podría pensar en el método (2). 3. excepto en un caso como el que sigue: . 3. También es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto también determina en muchos casos el método a emplear. donde no se puede pertenecer a varias entidades de nivel inferior. Es importante tomar en cuenta la pertenencia de instancias.

demostrando que un actor puede actuar en muchas series y que muchas series tendrán a los mismos actores.Podemos observar que existe una relación m-m entre "actor" y "serie". La tabla que se crearía sería: actor_serie id_actor Joaquín Pardavé id_serie Génesis Qué bonita familia Génesis id_personaje Abel hermano bueno Dulce abuelita Caín hermano Evita Muñoz (Chachita) Joaquín Pardavé .

En la relación siguiente. Génesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Caín hermano malo". pero entonces la llave "id_actor. id_personaje" 3. Los principales tipos son: 1. . Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relación son llamados anomalías. Si en la relación encontramos que el length de StarWars es 125 podríamos cambiarlo únicamente para la primer tupla y olvidar actualizar las demás. id_serie. Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación. La relación es correcta ya que un actor puede representar a varios personajes en la misma obra.5 Normalización Una vez creadas las tablas hay que verificarlas y revisar si aún se puede reducir u optimizar de alguna manera. Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra. 2. 3. id_serie" como la llave primaria caemos en un problema porque esa combinación no identifica de manera única a la tupla. Redundancia: la información se repite innecesariamente en muchas tuplas. perdemos también la tupla de la película MightyDucks. como es el caso de "Joaquín Pardavé. Si eliminamos al actor Emilio Estevez. length y filmType.malo Evita Muñoz (Chachita) Hermelinda linda Bruja Hermelinda si se considera "id_actor. id_serie" no es la correcta y en este caso lo más recomendable sería emplear los tres atributos de la relación "id_actor.

.. A2... Una dependencia funcional en una relación R es una enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1.An ---> B1.B2.An --> Por otro lado.... An ---> B2 A1. ..1..1 Dependencias funcionales (FD) 3.. A2.. A2.A2.5.. A2. los mismos valores para cada atributo).A2.... otros factores sería el manejo de dependencias multivaluadas y las restricciones de integridad referencial.. An ---> B1 A1...Bm . .1 Definición En el diseño de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia".An (tienen B y se dice que "A1. si un conjunto de atributos A1... An ---> Bm entonces podemos simplemente escribir este conjunto de FDs como: A1..5.. entonces deben concordar también con otro atributo B" . .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..An determina funcionalmente a B". .. Esta FD se escribiría como A1.A2. A2. A1.An determina funcionalmente a más de un atributo.

year --> filmType title. year --> length title. filmType. length. Decimos que un conjunto { A1.An } es una llave de un relación si: 1. 1977 124 color Fox 1991 104 color Disney 1992 95 color Paramount 1992 95 color Paramount title... year --> length. . 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 . year --> studioName title. filmType...Movies(title. studioName. year -/-> starName podemos entonces afirmar que: title. year. studioName Quizás las dependencias funcionales más evidentes sean las llaves... Esos atributos determinan funcionalmente a "todos" los demás atributos de una relación. A2.

2 Axiomas de Armstrong:  Reflexividad: sea y entonces Aumentación: 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 algún elemento de no pertenece a se considera una dependencia no trivial. recordemos que una llave primaria se escoge de entre el conjunto de superllaves mínimas. Es importante hacer notar que una llave mínima no se refiere al número de atributos incluídos.. A2.1.3 Reglas adicionales   Unión: si --> y Decomposición: si --> --> entonces --> entonces --> y --> . No hay un subconjunto de { A1.An } que determine funcionalmente a "todos" los demás atributos (incluyendo al resto del conjunto { A1. Al conjunto de dependencia funcionales de una relación R se le denominará F..5.An }) La definición anterior de llave es similar a la que se mencionó anteriormente de superllave.... Si ningún elemento de pertenece a entonces se considera una dependencia completamente no trivial 3.. se puede tener una llave mínima ABC y otra DE donde ambas son mínimas aún cuando una de ellas sea todavía de menor tamaño que la otra. 3.. A2.1.. sin embargo las superllaves no son llaves "mínimas".5.2.

D.C. BC-->AD.F teniendo R (A.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.D. D-->E.C.B.B.E) si A+=(A.E). Pseudotransitividad: si > --> y --> entonces -- 3.B. CF-->B. todos los atributos . (transitividad) --> --> F ) = =result .D.E.1.F) y F las dependencias: AB-->C. Comprobar que {A.5.C.C.B}+ ={A.B.E} .D. 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) --> . si -- +.

2 Primera forma normal Una tabla se encuentra en 1a NF.5. Verificar una dependencia funcional --> (es decir. NF nombre apellido_paterno apellido_materno dirección teléfono 3.3 Segunda forma normal Una tabla se encuentra en 2a NF. pero para ello sería necesaria alguna dependencia adicional ej.5. Si tenemos la tabla: .D. Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relación R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional --> S. si pertenece a F+) checando si +. si está en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave. si todos sus atributos son atómicos (indivisibles) El ejemplo clásico: nombre dirección teléfono En 1a.B. AB --> CF El calcular la cerradura es empleado para:    Verificar si es una superllave.E.B}+ = {A. 3.F} entonces podríamos afirmar que AB es superllave. calculando + y revisando si + contiene a todos los atributos de la relación R.C.Si {A.

depto} --> descripción {clave.clave.calificaciones_cursos id_estudiante depto clave_curso descripción calificación NO se encuentra en 2a NF ya que { id.depto} --> descripción Analizando todas las dependencias funcionales: { id.depto} --> descripción {clave.clave.clave.depto} --> calificación Para realizar la normalización (2NF) la relación se descompondría en: curso depto clave_curso descripción estud_curso id depto clave_curso calificación La descomposición se basa básicamente en:   La intuición Las dependencias funcionales Es importante que al descomponer una relación exista:   Descomposición sin pérdida Preservación de dependencias funcionales .depto} --> descripción { id.

calificación.depto} --> descripción } y dicha relación se descompone en: depto clave_curso descripción id_estudiante depto clave_curso calificación . es decir.clave.4 Descomposición sin pérdida Al descomponer una relación R en varias relaciones R1 y R2 se debe verificar que no haya pérdidas.depto} --> descripción.depto. {clave. Decimos entonces que para una descomposición en R1 y R2 no hay pérdida si: { R1 R2 --> R1 } F+ o bien si { R1 R2 --> R2 } F+ Para el ejemplo anterior la relación id_estudiante depto clave_curso descripción calificación F={ { id.3.5.clave. que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas.depto} --> id.clave. {clave.depto} --> descripción.descripción. { id.depto} --> calificación } tiene F+= { { id.clave.

{ id..depto.descripción.Fn y la preservación se verifica si F'+= F+ para el ejemplo anterior teniendo: F={ { id.depto} --> descripción..calificación.clave. {clave.depto} --> descripción } 3.calificación.R2.. De esta manera se garantiza que una actualización no provoque una relación inválida.5 Preservación de dependencias Al descomponer una relación R en varias relaciones R1.clave_curso--> descripción F2= id_estudiante.clave_curso -->descripción} { { id.clave_curso donde depto. {clave.clave_curso--> descripción id_estudiante.clave.depto.descripción.donde R1 R2 = depto.depto.5.depto} --> descripción. verificando las FDs o bien a través de combinaciones de relaciones(productos o joins) aunque esto último no es muy eficiente.depto} --> id.depto} --> descripción } F1= depto.clave.clave.depto} --> id.clave_curso --> calificación F' = F1 F2 depto.clave.depto} --> calificación } F+= { { id. {clave. Para ello se analizan todas la dependencias funcionales Fi para cada Ri que deberán ser un subconjunto de F+ De manera que F' = F1 F2 .clave_curso ->descripción y {depto.clave_curso --> calificación .depto.clave..Rn es importante revisar que se preserven las dependencias funcionales iniciales.

5.6.clave. {clave.6.2 Algoritmo general de descomposición 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 .clave.calificación.5.1 Características Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:  X --> A es una dependencia funcional trivial o  X es una super llave BCNF no necesariamente preserva las dependencias funcionales F'+ != F+ 3.descripción.5.depto.6 Forma normal de Boyce-Codd (BCNF) 3.depto} --> id.depto} --> descripción } y como F'+= F+ entonces si hay preservación de dependencias. ) --> Ri no .F'+= { { id.Ri ) ( Ri ) ( . 3.

7 Tercera forma normal 3. cada atributo de A puede estar contenido en llaves candidatas diferentes.5.5. .D) Esta última en BCNF 3.7.D) B--> C B-->D (B)+ = {CD} La superllave sería {AB} por lo tanto no cumple con BCNF (B-->CD y B no es superllave).C.B) (B. Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que da flexibilidad a las relaciones.Ejemplo: R(A. Descomponiendo usando B-->CD (A.C.B.1 Características Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:  X --> A es una dependencia funcional trivial o  X es una super llave o  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.

"banker-name" no es superllave de R Se puede observar que office-number y banker-name no son parte de alguna llave candidata se descompondría 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 descomposición si está en 3NF porque:   No hay dependencias funcionales triviales En la segunda relación. la segunda DF no cumple que banker-name es superllave . ejemplo. dada la relación 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. pero si una relación está en 3NF no necesariamente está en BCNF". No está en 3NF porque:    Las DFs no son triviales En la primer dependencia. está también 3NF.Podemos afirmar entonces que: "Si una relación está en BCNF.

la segunda DF. jefe empleados id_empleado nombre_depto id_jefe id_empleado --> nombre_depto. branch-name} Al cumplirse la 3er regla se confirma que la descomposición 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 extensión id_jefe nombre_depto --> extensión. 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 relación. branch-name es miembro de la llave candidata {customer-name. En la segunda relación. "nombre_depto" no es superllave de R Se puede observar nuevamente para la segunda relación que id_jefe no es parte de alguna llave candidata Aplicando la descomposición: deptos nombre_depto extensión id_jefe .

suponga un conjunto F de dependencias funcionales y la dependencia --> está en F.2.7.5.7. AB --> C } lógicamente implica A --> C (el resultado de quitar B de AB --> C ).{ Ejemplo: F = { A --> C .1 Forma canónica de las FDs (Fc) La forma canónica de F es aquel conjunto mínimo de dependencias funcionales equivalentes a F.A ) --> } B es extraño en AB --> C porque { A --> C. X es superllave. Se observa como la relación no solo está en 3NF sino también en BCNF por cumplir con la segunda regla. AB --> C } si A --> y }) {( . . jefe empleados id_empleado nombre_depto id_empleado --> nombre_depto Esta descomposición si está en 3NF porque:   No hay dependencias funcionales triviales Para toda dependencia X--> A .5. 3.  El atributo A es extraño en F lógicamente implica (F . Para obtener la Fc se deben extraer todos los miembros "extraños".nombre_depto --> extensión. sin dependencias redundantes o partes redundantes de dependencias.2 Algoritmo general de descomposición tratando de alcanzar 3NF 3.

2 Algoritmo basado en Fc Fc: Forma canónica de las FDs 1. Eliminar relaciones redundantes .Y) 2.A )+ contiene a .5. El atributo A es extraño en si A el conjunto de dependencias (F . mezclar Ri y Rj 4. Para cada dependencia X --> Y en Fc.7. crear una relación Ri (X. Si Ri y Rj tienen una llave en común. crear Ri(X) donde X es una de las superllaves de la relación original 3. si lo hace entonces A es extraño 3. si lo hace entonces A es extraño Para verificar si A es extraño en o calcular + usando solo las dependencias en: F'=(F .A )+ usando las dependencias en F calcular ( {  verificar si ( { } .{ o --> }) { --> ( .{ implica lógicamente a F Ejemplo: F = { A --> C .2. AB --> CD} y --> }) { --> ( -A)} C es extraño en AB --> CD porque A B --> C puede ser inferido aún después de eliminar C Test para verificar si un atributo es extraño Dado un conjunto de dependencias F y  --> está en F Para verificar si A o o es extraño en } .A) } verificar si + contiene a A. Si ninguna de las Ris contiene una de las superllaves de la relación.

name. city-->zip zip --> city 3.street. city). street.5.city street. 3. R1(sid. R2(zip.street. city).8 BCNF vs 3NF . R3(zip.*El algoritmo anterior garantiza que en una descomposición no haya pérdida (al incluir por lo menos en una relación una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas). city-->zip zip --> city Descomponer en 3NF 1. street.city zip street city R2 street. Ejemplo: sid name street city zip student Fc: sid -->name. 2. city) Eliminar R3 sid name street city R1 sid -->name. 4.

Banquero) banquero --> sucursal sucursal. Si se alcanza BCNF pero no hay preservación de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de pérdidas y debe preservar dependencias). cliente) Nuevamente se presentan las pérdidas de dependencias Qué es mejor ? BCNF o 3NF ?    De manera general se puede decir que ambas son buenas. normalizando: suc-banquero (sucursal. Cliente. El caso ideal es conseguir BCNF sin pérdidas y con preservación de dependencias.Como se mencionó anteriormente: "Si una relación está en BCNF. 3. banquero) suc-cliente (sucursal. cliente --> banquero está en 3NF pero no en BCNF puesto que "banquero" no es una superllave. está también 3NF.6 Conclusiones De manera que las metas del diseño de bases de datos con dependencias funcionales son:    BCNF* Descomposición sin pérdida Preservación de dependencias . pero si una relación está en 3NF no necesariamente está en BCNF". contraejemplo: (Sucursal. En la práctica la mayoría de los esquemas en 3NF también están en BCNF.

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