Está en la página 1de 34

Modelo entidad-relación Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-R "Entity relationship") es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus interrelaciones y propiedades.

Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos.

Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.

Modelado Entidad-Relación El Modelo Entidad-Relación es un concepto de modelado para bases de datos, propuesto por Peter Chen en 1976, mediante el cual se pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se corresponde al concepto de objeto de la Programación Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones.

Es una representación conceptual de la información. Mediante una serie de procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo relacional.

El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente consiste en los siguientes pasos:

  • 1. Se parte de una descripción textual información a automatizar (los requisitos).

del problema o sistema de

  • 2. Se hace una lista de los sustantivos y verbos que aparecen.

  • 3. Los sustantivos son posibles entidades o atributos.

  • 4. Los verbos son posibles relaciones.

  • 5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.

7.

Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.

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).

Etc.

Base Teórica y Conceptual El modelo entidad-relación se basa en los conceptos descritos a continuación para representar un modelo de la vida real.

Entidad Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo.

Ejemplos:

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

Un automovil. (Aunque sean de la misma marca, el mismo modelo,

...

,

tendrán atributos

diferentes, por ejemplo el numero de motor). Una casa (Aunque sea exactamente igual a otra, aun se diferenciara en su dirección).

Una entidad puede ser un objeto con existencia física (una persona, un animal,

un casa

...

),

o un objeto con existencia conceptual (Un puesto de trabajo, una

asignatura de clases, un nombre

...

).

Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona puede llevar consigo las características:

Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc.

Conjunto de entidades (también denominado instancia u ocurrencia) Es una colección de entidades que comparten los mismos atributos o características.

Ejemplos:

Todos los atletas que participan en los juegos olimpicos, comparten sus atributos: nombre, numero de identificación, edad, peso, categoria ... Todos los paises del mundo, comparten las caracteristicas: nombre, continente, area, lengua principal, lengua secundaria, moneda ...

Atributos Los atributos son las propiedades que describen a cada entidad.

Una entidad dentro de un conjunto de entidades, tiene valores específicos

asignados para cada uno de sus atributos, identificación univoca.

de

esta forma, es

posible su

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, Sophie, 18 años, 2) (2, Penny, 19 años, 5) (3, Sophie, 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 mas 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 una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que no se conoce, que no existe o que no se sabe nada al respecto del mismo.

Relación Describe cierta dependencia entre entidades o permite la asociación de las mismas.

Ejemplo:

Dadas dos instancias de entidades "Habitación 502" y "Mark", es posible relacionar que la habitacion 502 se encuentra ocupada por el huésped de nombre Mark.

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

Cardinalidad de las relaciones Dado un conjunto de relaciones, en el que participan dos o más entidades, la cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada. La cardinalidad puede ser:

Relación 1 a 1: Una elemento de A se relaciona únicamente con una elemento en B y viceversa. (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).

Relación 1 a n: Un elemento en A se relaciona con cero o muchas elementos en B. Pero un elemento en B se relaciona con un única elemento en A. (Ej: la entidad EMPRESA y la entidad TRABAJADOR y entre ellos la relación TRABAJA EN).

n

a

n:

Una

elemento

en

A

se

puede

relacionar con

0

o muchas

elementos en B y viceversa.

(Ej:

la

entidad ALUMNO, la entidad

ASIGNATURA y entre ellos la relación MATRÍCULA).

Clave Es un subconjunto del conjunto de atributos comunes en una entidad, que permite identificar unívocamente cada una de las ocurrencias pertenecientes a dicha colección. Así mismo, permiten distinguir entre si las relaciones de un conjunto de relaciones.

Clave ajena. Cuando una entidad hereda la clave de otra entidad con la que se relaciona.

Entidades fuertes y débiles Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil. Una entidad débil es aquella que no puede existir sin participar en la relación, es decir, aquella que no puede ser unívocamente identificada solamente por sus atributos. Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta última se pueda identificar.

Las entidades débiles se representan mediante un doble rectángulo, es decir, un rectángulo con doble línea.

Diagrama entidad-relación Formalmente, los diagramas E-R son

un

lenguaje gráfico para describir

conceptos. Informalmente, son simples dibujos o gráficos que describen la información que trata un sistema de información y el software que lo automatiza.

Ejemplo de diagrama E-R Entidad Se representa mediante un rectángulo o "caja" etiquetada en su interior

Ejemplo de diagrama E-R

Entidad Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado, etc.

Atributo Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo (clave) de la entidad se suele subrayar dicha etiqueta.

Relaciones Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona.

Cardinalidad de las relaciones El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje utilizado, la que más se usa actualmente es el unificado. 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 la entidad no está obligada a participar en la relación.

"1" si la entidad está obligada a participar en la relación y, además, cada instancia solamente participa una vez.

"N" , "M", ó "*" si la entidad no está obligada a participar en la relación y cada instancia puede participar cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona puede tener varias facturas emitidas a su nombre. Es una relación 1:N.

Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser comprado por varios clientes distintos. Es una relación N:M.

Atributos en relaciones Las relaciones también pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo típico son las relaciones de tipo "histórico" donde debe constar una fecha o una hora. Por ejemplo, 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). En tal caso, el atributo "Fecha de emisión" de la factura debería colocarse en la relación "se emite".

Herencia La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relación 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 relación de herencia se representa mediante un triángulo interconectado por líneas a las entidades. La entidad conectada por el vértice superior del triángulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del triángulo.

Transformación del modelo entidad-relación al modelo relacional. Para transformar un modelo entidad-relación a modelo relacional seguiremos las siguientes reglas:

Para cada entidad del esquema se creará una tabla con tantos campos como atributos tenga la entidad. Ejemplo:

Tabla 'TRABAJADOR'

DNI

NUM_SS

nombre-apellidos

...

11111111

XXXXXXXXXXX

Fulano de tal

...

22222222

YYYYYYYYYYY

Mengano de cual

...

......

......

......

......

Las relaciones 1-1 se pueden reflejar incluyendo en una de las dos tablas un campo en el que poder colocar la clave del elemento de la otra tabla con el que se está relacionado. Ese nuevo campo que se incluye en la tabla recibe el nombre de clave ajena. Ejemplo:

Tabla 'HOMBRE'

DNI

Nombre

...

11111111

...

...

22222222

...

...

...

...

...

Tabla 'MUJER'

DNI

Nombre

...

DNI-ESPOSO

 

33333333

...

...

11111111

 

44444444

...

...

(nulo)

 

...

...

...

...

Donde el campo DNI-ESPOSO es clave ajena de la tabla HOMBRE. Aquí hay que hacer notar que el campo DNI-ESPOSO puede tomar o bien un valor nulo, en el caso de aquellas mujeres que no estén casadas, o bien el valor de alguno de los DNI de la tabla HOMBRE, en el caso de las mujeres casadas; en este segundo caso, ese DNI (la clave ajena) no se deberá repetir en ningún otro registro de la tabla MUJER.

Las relaciones 1-n se representan de forma muy parecida a como se ha explicado para las relaciones 1-1. La diferencia está en que ahora no es indiferente donde se coloque la clave ajena, esta debe estar obligatoriamente en la tabla del 'mucho' (n); y además, para este caso si se permitirá que haya valores repetidos en dicho campo. Ejemplo:

Tabla 'EMPRESA'

CIF

Nombre

 

...

XX-1111-AA

...

 

...

YY-2222-BB

...

 

...

...

...

 

...

Tabla 'TRABAJADOR'

DNI

Nombre

...

CIF

11111111

...

...

XX-1111-AA

 

22222222

...

...

YY-2222-BB

 

33333333

...

...

YY-2222-BB

 

44444444

...

...

XX-1111-AA

 

...

...

...

...

Para representar las relaciones n-n en tablas lo que se hace es crear una nueva tabla solamente para la relación. Esta nueva tabla tendrá dos claves ajenas y su propia clave estará formada por la unión de las claves ajenas. Ejemplo:

Tabla 'ALUMNO'

DNI

Nombre

 

...

11111111

...

...

22222222

...

...

...

...

...

Tabla 'ASIGNATURA'

COD-ASIGNATURA

Nombre

...

01

...

...

02

...

...

...

...

...

Tabla 'MATRÍCULA'(esta es la relación)

 

DNI

COD_ASIGNATURA

NOTA

11111111

01

7.5

11111111

02

6.25

22222222

01

5.5

22222222

02

8

...

...

...

En la tabla MATRÍCULA es donde se refleja la relación. La clave de dicha tabla está formada por los campos DNI y COD-ASIGNATURA ; y cada uno de ellos es clave ajena, el primero de ALUMNO y el segundo de ASIGNATURA. Hacer ver aquí que la tabla MATRICULAS puede tener más campos además de los que son clave ajena como ocurre en el ejemplo; la tabla añade además un campo NOTA.

En el caso de las relaciones reflexivas supondremos que se trata de una relación binaria con la particularidad que las dos entidades son iguales y aplicaremos las reglas vistas en los puntos anteriores.

Ejemplos.

Relaciones N:M

Supongamos el siguiente modelo entidad-relación.

02 ... ... ... ... ... Tabla 'MATRÍCULA'(esta es la relación) DNI COD_ASIGNATURA NOTA 11111111 01

En este caso la relación “compra” se transforma en una nueva tabla cuya clave primaria estará formada por los atributos dni, que es la clave primaria de cliente, y código, que es la clave primaria de producto. Además tendrá como campo fecha compra, ya que este atributo forma parte de la relación.

El modelo relacional quedaría de la siguiente forma (en negrita las claves primarias):

CLIENTE(dni,nombre,apellidos)

PRODUCTO(código,descripción)

COMPRAS(dni_cliente,código_producto,fecha_compra)

Relaciones 1:N

Veamos ahora el caso de una relación 1:N. En el siguiente modelo entidad- relación un empleado pertenece a un único departamento (debe pertenecer a uno obligatoriamente), y un departamento tiene 1 o más empleados.

 CLIENTE( dni ,nombre,apellidos)  PRODUCTO( código ,descripción)  COMPRAS( dni_cliente,código_producto , fecha_compra ) Relaciones 1:N

En este caso se propaga el atributo código de departamento a la tabla EMPLEADO. El modelo relacional quedaría de la siguiente manera:

EMPLEADO(dni,nombre,salario,código_departamento)

DEPARTAMENTO(código,nombre,localización)

Relaciones 1:1

Veamos ahora el caso de una relación 1:1 a través del siguiente ejemplo. En el siguiente modelo entidad-relación un equipo de fútbol tiene a un único presidente y un presidente preside a un único club de fútbol.

En este ejemplo, tal y como dicen las reglas, podemos propagar la clave de cualquier tabla

En este ejemplo, tal y como dicen las reglas, podemos propagar la clave de cualquier tabla a la tabla resultante de la otra. Es decir, tenemos dos opciones, o mover la clave de PRESIDENTE a EQUIPO o mover la clave de EQUIPO a PRESIDENTE. El modelo relacional podría quedar de cualquiera de las dos formas siguientes:

EQUIPO(código,nombre,año_fundación)

PRESIDENTE(dni,nombre,código_equipo)

EQUIPO(código,nombre,año_fundación,dni_presidente)

PRESIDENTE(dni,nombre)

Relaciones reflexivas

Veamos ahora como quedaría en el modelo relacional la siguiente relación reflexiva. En el siguiente modelo entidad-relación un ALUMNO es delegado de varios ALUMNOS y un ALUMNO tiene obligatoriamente un delegado y sólo a uno.

Como podemos observar en las reglas de transformación, en este caso la relación reflexiva se trata

Como podemos observar en las reglas de transformación, en este caso la relación reflexiva se trata como si fuera una relación binaria con la particularidad de que las dos entidades son iguales. Al tratarse de una relación 1:N se propagará la clave de la entidad ALUMNO a la entidad ALUMNO, quedando el modelo relacional de la siguiente forma:

ALUMNO(num_expediente,nombre,num_expediente_delegado)

Ejemplo de una Universidad (Access) Creación de Tablas

Tabla Alumno

En una Universidad, si tenemos la entidad Alumno que definimos como:

Tabla

ALUMNO(DNI,

Nombre,

Apellido1,

Apellido2,

Telefono,

Calle,

Ciudad,

Provincia,

FNacimiento, EstadoCivil)

 

CP: DNI

Creando la tabla en vista "Diseño"
Creando
la
tabla
en
vista
"Diseño"

Tabla Asignatura

Y la entidad Asignatura definida como:

obtenemos:

ASIGNATURA(Codigo, Nombre, Creditos, Dni_prof, Observaciones) CP:Codigo

Tabla Matricula

Y sabiendo que un alumno se puede matricular de muchas asignaturas y que una asignatura a su vez puede tener muchos alumnos matriculados, podemos definir entre ambas entidades la relación (n-m) matricula como:

MATRICULA(DNI, Codigo_asig, Fecha, Nota) CP:DNI,Codigo_asig,Fecha

Y la tabla
Y
la
tabla

quedaría

como:

Creación de Relaciones Seleccionamos la opción Relaciones del menú Herramientas:

Tabla Matricula Y sabiendo que un alumno se puede matricular de muchas asignaturas y que una

Agregamos las tablas (Alumno,Asignatura y Matricula):

Que son:

Que son:

Y por último sólo falta arrastrar los campos relacionados de la tabla con la relación 1

Y por último sólo falta arrastrar los campos relacionados de la tabla con la relación 1 a la tabla con la relación muchos, es decir crear las relaciones, en las que seleccionaremos siempre :

Exigir Integridad Referencial Actualizar en cascada los campos relacionados Eliminar en cascada los registros relacionados

En el caso de Alumno-Matricula (1 Alumno.DNI se puede repetir n veces en Matricula.DNI) arrastramos el Alumno.DNI sobre la Matricula.DNI:

Y

si

repetimos

la

misma

operación

entre

Asignatura.Codigo

y

Matricula.Codigo_asig queda el esquema E-R en Access según se muestra en la figura siguiente:

Normalización de bases de datos Formas Normales Las formas normales son aplicadas a las tablas deEdgar F. Codd . Primera Forma Normal (1FN) Se dice que una tabla se encuentra en primera forma normal si y solo si cada uno de los campos contiene un único valor para un registro determinado. Segunda Forma Normal (2FN) Una tabla está en Segunda Forma Normal si y solo si todos los campos dependen directamente de la clave. " id="pdf-obj-15-2" src="pdf-obj-15-2.jpg">

Normalización de bases de datos Formas Normales Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd. [1]

Primera Forma Normal (1FN) Se dice que una tabla se encuentra en primera forma normal si y solo si cada uno de los campos contiene un único valor para un registro determinado. Segunda Forma Normal (2FN) Una tabla está en Segunda Forma Normal si y solo si todos los campos dependen directamente de la clave.

Tercera Forma Normal (3FN) Se dice que una tabla está en tercera forma normal si y solo si los campos de la tabla dependen únicamente de la clave. Ejemplo 1 Normalización A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con un ejemplo simplificado de una base de datos para una pequeña biblioteca.

CodLibro Titulo

Autor

Editorial

NombreLector FechaDev

 

Variable

Murray

McGraw

Pérez

Gómez,

1001

compleja

Spiegel

Hill

Juan

15/04/2005

 

Visual Basic

E.

Ríos

Terán,

1004

5

Petroustsos

Anaya

Ana

17/04/2005

1005

Estadística

Murray

McGraw

Roca, René

16/04/2005

 

Spiegel

Hill

   

Nancy

     

1006

Oracle

University

Greenberg y

Priya Nathan

Oracle

Corp.

García

Luis

Roque,

20/04/2005

 

McGraw

Pérez

Gómez,

1007

Clipper 5.01

Ramalho

Hill

Juan

18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla.

1NF

CodLibr

Titulo

Autor

Editoria

Patern

Matern

Nombre

FechaDev

o

l

o

o

s

1001

Variable

Murray

McGraw

Pérez

Gómez

Juan

15/04/200

compleja

Spiegel

Hill

5

1004

Visual

E.

Anaya

Ríos

Terán

Ana

17/04/200

Basic 5

Petroustso

5

CodLibr

Titulo

Autor

Editoria

Patern

Matern

Nombre

FechaDev

o

l

o

o

s

 

s

1005

Estadístic

Murray

McGraw

Roca

René

16/04/200

a

Spiegel

Hill

5

1006

Oracle

Nancy

Oracle

García

Roque

Luis

20/04/200

University

Greenberg

Corp.

5

1006

Oracle

Priya

Oracle

García

Roque

Luis

20/04/200

University

Nathan

Corp.

5

1007

Clipper

Ramalho

McGraw

Pérez

Gómez

Juan

18/04/200

5.01

Hill

5

Como se puede ver, hay cierta redundancia característica de 1NF.

 

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro.

Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra tabla.

2NF

CodLibro

Titulo

Autor

Editorial

 

1001

Variable

Murray

McGraw

compleja

Spiegel

 

Hill

 

E.

1004

Visual Basic 5

Petroustsos

Anaya

1005

Estadística

Murray

McGraw

 

Spiegel

 

Hill

1006

Oracle

Nancy

Oracle

CodLibro

Titulo

Autor

Editorial

 

University

Greenberg

Corp.

  • 1006 Oracle

Priya

Oracle

University

Nathan

Corp.

 

McGraw

  • 1007 Clipper 5.01

Ramalho

Hill

La nueva tabla sólo contendrá datos del lector.

CodLec

Pater

Mater

Nombr

tor

no

no

es

  • 501 Pérez

Góme

Juan

 

z

  • 502 Ríos

Terán

Ana

  • 503 Roca

René

 

Garcí

  • 504 Roque Luis

a

Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de la base de datos necesita que exista otra tabla para mantener la información de qué libros están prestados a qué lectores. Esta tabla se muestra a continuación:

CodLib

CodLec

FechaD

ro

tor

ev

1001

501

15/04/2

CodLib

CodLec

FechaD

ro

tor

ev

 

005

17/04/2

  • 1004 502

005

16/04/2

  • 1005 503

005

20/04/2

  • 1006 504

005

18/04/2

  • 1007 501

005

Para la Tercera Forma Normal (3NF) la relación debe estar en 2NF y además los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. También recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente información sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva información acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.

3NF

CodLibro

Titulo

 

Variable

1001

compleja

 

Visual

Basic

1004

5

1005

Estadística

1006

Oracle

CodLibro

Titulo

 

University

1007

Clipper 5.01

CodAutor

Autor

 

Murray

  • 801 Spiegel

 

E.

  • 802 Petroustsos

 

Nancy

  • 803 Greenberg

 

Priya

  • 804 Nathan

  • 806 Ramalho

CodEditorial Editorial

 

McGraw

  • 901 Hill

  • 902 Anaya

 

Oracle

  • 903 Corp.

Aunque hemos creado nuevas tablas para que cada una tenga sólo información acerca de una entidad, también hemos perdido la información acerca de qué autor ha escrito qué libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.

CodLibr

codAuto

 

o

r

1001

801

1004

802

1005

801

1006

803

1006

804

1007

806

 

CodLibr

codEditori

o

al

1001

901

1004

902

1005

901

1006

903

1007

901

Y el resto de las tablas no necesitan modificación.

CodLec

Pater

Mater

Nombr

 

tor

no

no

es

 

Pérez

Góme

Juan

  • 501 z

 
  • 502 Terán

Ríos

Ana

  • 503 René

Roca

 
 

Garcí

Roque Luis

   
  • 504 a

 
 

CodLibro

CodLector

FechaDev

  • 1001 501

 

15/04/2005

  • 1004 502

 

17/04/2005

  • 1005 503

 

16/04/2005

  • 1006 504

 

20/04/2005

  • 1007 501

 

18/04/2005

Ejemplo 2 Normalización

 

usuarios

nombre

empresa

direccion_empresa

url1

url2

Joe

ABC

1 Work Lane

abc.com

xyz.com

Jill

XYZ

1 Job Street

abc.com

xyz.com

Diríamos que la anterior tabla esta en nivel de Formalizacion Cero porque ninguna de nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y url2 -- ¿Qué haremos cuando en nuestra aplicación necesitemos una tercera url ? ¿ Quieres tener que añadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu código PHP ? Obviamente no, tu quieres crear un sistema funcional que pueda crecer y adaptarse fácilmente a los nuevos requisitos. Hechemos un vistazo a las reglas del Primer Nivel de Formalización-Normalización, y las aplicaremos a nuestra tabla.

1FN

  • 1. Eliminar los grupos repetitivos de la tablas individuales.

  • 2. Crear una tabla separada por cada grupo de datos relacionados.

  • 3. Identificar cada grupo de datos relacionados con una clave primaria. ¿Ves que estamos rompiendo la primera regla cuando repetimos los campos url1 y url2? ¿Y que pasa con la tercera regla, la clave primaria? La regla tres básicamente significa que tenemos que poner una campo tipo contador autoincrementable para cada registro. De otra forma, ¿Qué pasaria si tuvieramos dos usuarios llamados Joe y queremos diferenciarlos. Una vez que aplicaramos el primer nivel de F/N nos encontrariamos con la siguiente tabla:

usuarios

userId

nombre

empresa

direccion_empresa

url

  • 1 Joe

ABC

1 Work Lane

abc.com

  • 1 Joe

ABC

1 Work Lane

xyz.com

  • 2 Jill

XYZ

1 Job Street

abc.com

  • 2 Jill

XYZ

1 Job Street

xyz.com

Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos solucionado el problema de la limitación del campo url. Pero sin

embargo vemos otros problemas

....

Cada

vez que introducimos un nuevo

registro en la tabla usuarios, tenemos que duplicar el nombre de la

empresa y del usuario. No sólo nuestra BD crecerá muchísimo, sino que

será muy facil que la BD se corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos pues el segundo nivel de F/N:

2 FN

  • 1 Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.

  • 2 Relacionar estas tablas mediante una clave externa. Hemos separado el campo url en otra tabla, de forma que podemos añadir más en el futuro si tener que duplicar los demás datos. También vamos a usar nuestra clave primaria para relacionar estos campos:

usuarios

userId

nombre

empresa

direccion_empresa

1

Joe

ABC

1 Work Lane

2

Jill

XYZ

1 Job Street

urls

urlId

relUserId

 

url

1

1

abc.com

2

1

xyz.com

3

2

abc.com

4

2

xyz.com

Vale, hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, esta relacionada ahora con la clave externa en la tabla urls, relUserId. Esto esta mejor. ¿ Pero que ocurre cuando queremos añadir otro empleado a la empresa ABC ? ¿ o 200 empleados ? Ahora tenemos el nombre de la empresa y su dirección duplicandose, otra situación que puede inducirnos a introducir errores en nuestros datos. Así que tendrémos que aplicar el tercer nivel de F/N:

3 FN

  • 1 Eliminar aquellos campos que no dependan de la clave. Nuestro nombre de empresa y su dirección no tienen nada que ver con el campo userId, asi que tienen que tener su propio empresaId:

usuarios

userId

nombre

relEmpresaId

1

Joe

1

2

Jill

2

empresas

emprId

empresa

direccion_empresa

1

ABC

1 Work Lane

2

XYZ

1 Job Street

urls

urlId

 

RelUserId

url

1

1

abc.com

2

1

xyz.com

3

2

abc.com

4

2

xyz.com

Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con la clave externa recEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios mientras que sólo tenemos que insertar el

nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicación ni corrupción de datos. La mayoria de los desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede manejar facilmente los datos obtenidos de una cualquier empresa en su totalidad, y en la mayoria de los casos esto será cierto.

Pero hechemos un vistazo a nuestro campo urls - ¿ Ves duplicación de datos ? Esto es perfectamente aceptable si la entrada de datos de este campo es solicitada al usuario en nuestra apliación para que teclee libremente su url, y por lo tanto es sólo una coincidencia que Joe y Jill teclearon la misma url. ¿ Pero que pasa si en lugar de entrada libre de texto usáramos un menú desplegable con 20 o incluso más urls predefinidas ? Entonces tendríamos que llevar nuestro diseño de BD al siguiente nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende mucho de un tipo muy específico de relación, la relación 'varios-con-varios', la cual aún no hemos encontrado en nuestra aplicación.

Relaciones entre los Datos

Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varios-con-varios. Mira la tabla usuarios en el Primer Nivel de F/N del ejemplo de arriba. Por un momento imaginámos que ponemos el campo url en una tabla separada, y cada vez que introducimos un registro en la tabla usuarios tambien introducimos una sola fila en la tabla urls. Entonces tendríamos una relacion uno-a-uno: cada fila en la tabla usuarios tendría exactamente una fila correspondiente en la tabla urls. Para los propósitos de nuestra aplicación no sería útil la normalización.

Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas permiten a un sólo usuario tener asociadas varias urls. Esta es una relación uno-con-varios, el tipo de relación más común, y hasta que se nos presentó el dilema del Tercer Nivel de F/N. la única clase de relación que necesitamos.

La relación varios-con-varios, sin embargo, es ligeramente más compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado con varias urls. Como dijímos, vamos a cambiar la estructura para permitir que varios usuarios esten relacionados con varias urls y así tendremos una relación varios-con- varios. Veamos como quedarían nuestras tablas antes de seguir con este planteamiento:

usuarios

userId

nombre

relEmpresaId

1

Joe

 

1

2

Jill

 

2

empresas

emprId

empresa

 

direccion_empresa

1

ABC

 

1 Work Lane

2

XYZ

 

1 Job Street

urls

urlId

url

1

abc.com

 

2

xyz.com

 

url_relations

 

relationId

relatedUrlId

 

relatedUserId

1

1

1

2

1

2

3

2

1

4

2

2

Base de datos relacional Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. 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. [1]

Características

Una

base

de

datos

relacional

se

compone

de

varias

o

relaciones.

 

No pueden existir dos tablas con el mismo nombre.

 

Cada tabla es a su vez un conjunto de registros, filas o tuplas.

 

Cada registro representa un objeto del mundo real.

 

Cada una

de estos registros consta de varios

campos, columnas o

atributos.

 

No pueden existir dos campos con el mismo nombre en la una misma tabla.

Los valores almacenados en una columna deben ser del mismo tipo de dato.

Todas las filas de una misma tabla poseen el mismo número de campos.

No

se

considera el

orden

en

que se

almacenan los registros en las

tablas.

 

No se considera el orden en que se almacenan las tablas en la base de datos.

La información puede ser recuperada o almacenada por medio de sentencias llamadas «consultas».

Elementos Relaciones base y derivadas En una base de datos relacional, todos los datos se almacenan y se acceden a ellos por medio de relaciones. Las relaciones que almacenan datos son llamados "relaciones base" y su implementación es llamada "tabla". Otras relaciones no almacenan datos, pero que son calculadas al aplicar operaciones relacionales. Estas relaciones son llamadas "relaciones derivadas" y su implementación es llamada "vista" o "consulta". Las relaciones derivadas son convenientes ya que expresan información de varias relaciones actuando como si fuera una sola.

Restricciones Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base de datos. Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el simple hecho de que la base de datos sea relacional. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.

Las restricciones proveen un método de implementar reglas en la base de datos. Las restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente se definen usando expresiones que dan como resultado un valor booleano, indicando si los datos satisfacen la restricción o no.

Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos relacionales.

Dominios Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha, etc.

Clave única Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores en dichos campos sean idénticos. Este conjunto de campos se llama clave única.

Pueden existir varias claves únicas en una determinada tabla, y a cada una de éstas suele llamársele candidata a clave primaria.

Clave primaria Una clave primaria es una clave única elegida entre todas las candidatas, para especificar los datos que serán relacionados con las demás tablas. La forma de hacer esto es por medio de claves foráneas.

Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave puede contener valores NULL.

Clave foránea Una clave foránea es una referencia a una clave en otra tabla. Las claves foráneas necesitan no ser claves únicas.

Clave índice Las claves índice surgen con la necesidad de tener un acceso más rápido a los datos. Los índices pueden ser creados con cualquier combinación de campos de una tabla. Las consultas que filtran registros por medio de estos campos, pueden encontrar los registros de forma no secuencial usando la clave índice.

Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de ellas es óptima para cierta distribución de datos y tamaño de la relación.

Los índices generalmente no se consideran parte de la base de datos, pues son un detalle agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de programadores que las otras partes de la base de datos.

Procedimientos almacenados Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la base de datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones comunes, como insertar un registro dentro de una tabla, recopilar información estadística, o encapsular cálculos complejos. Son frecuentemente usandos por un API por seguridad o simplicidad.

Los procedimientos almacenados no son parte del modelo relacional, pero todas las implementaciones comerciales los incluyen.

Estructura La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia).

El

esquema

es

la

definición

de

la

estructura

de la base de datos y

principalmente almacena los siguientes datos:

El nombre de cada tabla

El nombre de cada campo

El tipo de dato de cada campo

La tabla a la que pertenece cada campo

Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización, el resultado de dicho proceso es un esquema que permite que la base de datos sea usada de manera óptima.

Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si, el contenido de todos los registros.

Manipulación de la información Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el álgebra relacional y el cálculo relacional. El álgebra relacional permite describir la forma de realizar una consulta, en cambio, el cálculo relacional sólo indica lo que se desea devolver.

El

lenguaje más común para construir las consultas a bases de datos

relacionales es SQL (Structured Query Language), un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.

En el modelo relacional los atributos deben estar explícitamente relacionados a un nombre en todas las operaciones, en cambio, el estándar SQL permite usar

columnas sin nombre en conjuntos de resultados, como el asterisco taquigráfico (*) como notación de consultas.

Al contrario del modelo relacional, el estándar SQL requiere que las columnas tengan un orden definido, lo cual es fácil de implementar en una computadora, ya que la memoria es lineal.

Es de notar, sin embargo, que en SQL el orden de las columnas y los registros devueltos en cierto conjunto de resultado nunca está garantizado, a no ser que explícitamente sea especificado por el usuario.

sin embargo, todo lo dicho es dicho y una base de datos relacional es utilizada para la formacion de el ingreso de datos de forma sistematizada, "facil", y ordenada

Manejadores de base de datos relacionales Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este software se conoce como SGBD (Sistema de gestión de

base de datos relacional) o management system).

RDBMS

(del

inglés

Relational

database

Entre los gestores o manejadores más actuales y populares encontramos:

Ventajas y desventajas

Ventajas

Provee herramientas que garantizan evitar la duplicidad de registros.

Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros relacionados dependientes.

Favorece la normalización por ser más comprensible y aplicable.

Desventajas

Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información geográfica.

No se manipulan de forma manejable los bloques de texto como tipo de dato.

Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no sustituir a las bases de datos relacionales.