ELECCIÓN DEL SGBD

(DBMS: DATA BASE MANAGEMENTE SYSTEM)

Es el software con capacidad para definir, mantener y utilizar bases de datos. Es aquel que

depende del modelo de con el que deseamos trabajar.

1. Elección del modelo de datos:

Relacional (se establece entre dos o más entidades).

Orientado a objetos

Objeto relacional

Multidimensional

2. Modelo del SGBD (Sistema Gestor de Base de Datos):

Para el modelo relacional existen varios tipos de software para las bases de datos

relacionales, entre ellos anotamos:

Oracle

DB2 de IBM

Interbase de Borland

ACCESS

Hay que tener en cuenta dos tipos de factores al momento de crear una base de datos:

Factores Técnicos:

Fiabilidad

Recuperación – Fallos

Seguridad

Capacidad

Herramientas

Factores No Técnicos:

Costo del software (Licencias)

Costo del Hardware

Costo de mantenimiento

Costo del personal (DBA: Data Base Administrator)

DISEÑO LÓGICO

Es el conjunto de estructuras propias del modelo elegido, por el cual, debe ser acondicionado al

Modelo de Entidad Relacional (MER). Es decir, convertir el modelo a tablas y su resultado será

el Modelo Relaciona o Modelo de Entidad Relacional Normalizado.

Clientes

IdCliente

tipo_documento

numero_documento

nombres

apellidos

dirección

telefono_casa

Celular

Correo

Este diseño contiene una base de datos la cual todavía no está normalizada.

PREPARACIÓN DEL MODELO RELACIONAL MER NORMALIZADO:

Del MER al Modelo Relacional se deben realizar tres pasos para pasar del modelo contextual al

modelo lógico.

Animales

IdAnimal

Nombre

Especie

Raza

color

tamaño

fecha_naciemiento

Facturas

IdFactura

fecha

Servicios

IdServicio

Tipo

Tarifa

1 *

*

*

*

*

*

1

ESQUEMA

CONCEPTUAL

FALTA NORMALIZAR

Registra

Registra

Tiene Tiene

1. Revisión de las relaciones:

Muchos a muchos

Uno a uno

Uno a muchos

2. Revisión de las relaciones (Atributos)

3. Normalización: Existen 6 tipos de normalización, pero se exigen la 3 primeras.

1FN – Primera Forma Normal

2FN – Segunda Forma Normal

3FN – Tercera Forma Normal

Revisión de las Relaciones:

Relación muchos a muchos.- Digamos que tenemos dos tablas, una llamada Profesor y

otra llamada Grupos; en donde la tabla Profesores tiene muchos grupos y la tabla

Grupos puede tener muchos profesores.

En las relaciones muchos a muchos se da origen a una nueva taba y se generan dos

relaciones tipo uno a muchos.

Profesores

(PK)IdProfesor

primernombre

………

Grupos

(PK)IdGrupo

nombre

………

Profesores

(PK)IdProfesor

primernombre

……… ProfesoresGrupos

(FK)IdProfesor

(FK)IdGrupo Grupos

(PK)IdGrupo

nombre

………

Enseña

* *

*

1

*

1

Los atributos de la nueva tabla están compuestos por las Llaves Primarias (PK: Prime Key) de

cada una de las tablas de las relación, más los atributos propios de la relación en las llaves

primarias de ñas tablas, pasan a convertirse en Llaves Foráneas (FK: Foreign Key).

Ahora vemos como quedan las relaciones quitando la relación directa entre profesores y grupos,

y se crea una nueva tabla llamada profesoresgrupos (siempre usar un nombre acorde a la

función que vaya a cumplir dicha tabla), en donde las tablas Profesores y Grupos están

relacionadas con la tabla ProfesoresGrupos. Esta tabla hereda las relaciones de muchos a

muchos, dejando a las otras que interceden en uno a muchos; recordemos que las relaciones

muchos a muchos no deben existir.

Profesores

(PK)IdProfesor Primernombre

1 Robinson

2 Mayra

3 Fernando

Relación uno a uno.- En este tipo de relación se dice que las tablas se deben combinar

y que no deben existir relación uno a uno.

ProfesoresGrupos

(FK)IdProfesor (FK)IdGrupo

1 2

2 5

1 1

3 2

3 1

Grupos

(PK)IdGrupo nombre

2 10-1

1 10-2

5 8

*

1

*

1

Una entidad hereda la clave primaria de las entidades que intervienen en la relación, es

decir, si tenemos dos entidades una de ellas hereda la llave primaria de la otra.

En la opción 1 vemos que la tabla Trabajador hereda la llave primaria de Departamento

y en la opción 2 Departamento hereda la llave primaria de Trabajador.

A continuación mostraremos lo que puede suceder en cada opción que se escoja y así

decidir cuál es la mejor opción a escoger.

Profesores

(PK)IdTrabajador

nombre

………

Profesores

(PK)IdTrabajador

nombre

(FK)IdDepartamento

………

Departamento

(PK)IdDepartamento

nombre

………

Departamento

(PK)IdDepartamento

Nombre

………

Profesores

(PK)IdTrabajador

nombre

………

Departamento

(PK)IdDepartamento

nombre

(FK)IdTrabajador

………

1

1

Dirige

Opción 1

1

1

Dirige

Opción 2

1

1

Dirige

Opcion 1

Trabajador

(PK)IdTrabajador Nombre (FK)IdDepartamento

1 Robinson 1

2 Mayra Null

3 Fernando Null

4 Constain 2

5 Libia Null

Los valores nulos (Null) no son convenientes en este diseño. En el gráfico notamos que

la opción 1 no es la más apropiada ya que solo existen dos departamentos y solo dos

personas en cada uno de ellos, dejando con valores nulos a los demás.

Opción 2

En esta opción podemos fijarnos que es la más óptima, ya que no se generan por ningún

motivo valores nulos.

Departamento

(PK)IdDepartamento Nombre

1 Sistemas

2 Ventas

Trabajador

(PK)IdTrabajador Nombre

1 Robinson

2 Mayra

3 Fernando

4 Constain

5 Libia

Departamento

(PK)IdDepartamento Nombre (FK)IdTrabajador

1 Sistemas 1

2 Ventas 4

Uno a muchos.- La entidad con cardinalidad muchos hereda la llave primaria de la

entidad con cardinalidad uno.

Analizando las relaciones en tablas quedaría:

A este tipo de relaciones se la conoce como Entidades Fuertes y Entidades Débiles, es

decir, la entidad débil no existe si no está la entidad fuerte. Por ejemplo en el caso

Cliente

(PK)IdCliente

nombre

………

Cliente

(PK)IdCliente

nombre

………

Pedido

(PK)IdPedido

fecha

………

Pedido

(PK)IdPedido

fecha

(FK)IdCliente

Pedido

(PK)IdPedido Nombre (FK)IdCliente

1 19/01/14 1

2 12/05/14 1

3 16/06/14 2

4 10/09/14 3

9 01/10/14 4

20 24/12/14 4

25 25/12/14 5

Clientes

(PK)IdCliente Nombre

1 Robinson

2 Mayra

3 Fernando

4 Constain

5 Libia

Hace

1

*

Hace

1

*

Entidad

Débil

Entidad

Fuerte

Clientes y Pedido, un pedido no existe si no hay un cliente, o sea, que son dependientes

una de la otra.

Supongamos que en el ejemplo anterior se borra a Robinson, automáticamente se

borran todos los registros que tengan relación con ese nombre, porque como son

dependientes, no puede existir algo en la tabla que no exista en la otra, a eso se le

conoce con el nombre de Integridad Referencial.

Volviendo al Diseño Lógico de las tablas, podemos notar que necesitamos aplicar las

normas que hemos aprendido, quedando de esta manera:

Relación uno a muchos – Ejemplo:

Ahora vamos a resolver como debemos trabajar con las tablas que tienen relaciones de

uno a muchos y cuál es la opción más óptima que debemos utilizar en este tipo de

relación.

Clientes

IdCliente

tipo_documento

numero_documento

nombres

apellidos

dirección

telefono_casa

Celular

Correo

Animales

IdAnimal

Nombre

Especie

Raza

color

tamaño

fecha_naciemiento

Servicios

IdServicio

Tipo

Tarifa

Facturas

IdFactura

fecha

1

*

*

*

* *

*

1

ESQUEMA

CONCEPTUAL

FALTA NORMALIZAR

Registra

Registra

Tiene Tiene

Notemos que tanto la tabla Animales como la tabla Facturas heredan como llaves

foráneas a IdCliente de la tabla Cliente.

Relación muchos a muchos – Ejemplo:

Recordemos que procedimiento debemos utilizar para poder resolver este tipo de

relaciones.

Vemos con claridad que para poder resolver este tipo de casos, debemos crear una

nueva tabla y le asignamos un nombre que vaya de acuerdo a la función que cumpla, en

Clientes

(PK)IdCliente

tipo_documento

numero_documento

Animales

(PK)IdAnimal

(FK)IdCliente

Nombre

Especie

Facturas

(PK)IdFactura

(FK)IdCliente

fecha

Animales

(PK)IdAnimal

(FK)IdCliente

Nombre

Especie

Servicios

(PK)IdServicio

Tipo

Tarifa

Historial

(FK)IdAnimal

(FK)IdServicio

fecha

Servicios

(PK)IdServicio

Tipo

Tarifa

Facturas

(PK)IdFactura

(FK)IdCliente

Fecha

Detalle

(FK)IdFactura

(FK)IdServicio

cantidad

*

1

*

1

1

* *

1

1

* *

1

este caso son “Historial” en las tablas Animales con Servicios, y “Detalle” en las tablas

Facturas con Servicios. Notemos que las nuevas tablas se colocan llaves foráneas en cada

una de ellas y se agregaron nuevos atributos para tener un mejor control en el manejo

de las relaciones.

NORMALIZACIÓN

La normalización permite obtener un conjunto adecuado de relaciones de tal forma que:

El esquema de la Base de Datos incluya el mínimo número de atributos necesarios para

dar soporte a los requerimientos del sistema.

Resulta más fácil acceder a las Bases de Datos y, sobre todo, mantener los datos

(redundancia mínima: salvo los atributos que forman parte de claves externas, los

demás representaran una única vez en la base de datos).

Si todo lo realizado está bien y teniendo en cuenta que un atributo pertenece a una tabla y no a

otra, entonces la normalización no es necesaria, pero en ocasiones uno no está claro con qué

atributo debe ir a que tabla, entonces si debemos utilizar los métodos de normalización.

En Base de Datos Normalizada:

Las actualizaciones se consiguen realizar con un número mínimo de operaciones

(mejorando la eficiencia de la base de datos y reduciendo la posibilidad de que

aparezcan inconsistencias).

Se reduce al mínimo el espacio de almacenamiento necesario para almacenar los datos

de la base de datos (reduciendo los costes de operación de la base de datos).

Las relaciones que almacenan datos redundantes presentan anomalías de actualización

(la inserción, eliminación o modificación de los datos puede provocar la aparición de

inconsistencias).

Básicamente la normalización nos permite que no haya redundancia en la Base de Datos, que

las consultas sean más fácil de hacer, que sean más entendibles, que si se desea hacer algún

cambio, sea más sencillo y no nos cueste tanto trabajo, mejorando la eficiencia y reduciendo el

almacenamiento de datos repetidos, evitando la redundancia; o sea, que no guardamos datos

que ya están repetidos por ejemplo. No es lo mismo almacenar un nombre en un registro, que

tener que cambiarlo varias veces, ya que nos va a consumir mucho tiempo. Y nos ayuda

eliminando anomalías de actualización cuando insertamos o eliminamos algún dato.

De este gráfico podemos diferenciar los seis tipos de normalización que existen, de las cuales

solo utilizaremos las tres primeras.

Si las tres primeras formas están bien, la Base de Datos está lista para ser implementada en

cualquier sistema gestor y no hay necesidad de usar las otras, salvo el caso en donde si se las

necesite.

1FN – Primera Forma Normal.- Se dice que una taba está en Primera Forma Normal (1FN) si y

solo si, cada uno de los campos contiene un único valor para un registro determinado (Valores

Atómicos).

1FN – Primera Forma Normal: Ejemplo

Creando la nueva tabla auxiliar tendríamos:

C_alumno N_alumno N_asignatura

01 Manuel ADIG

02 Juan PLE, ADIG

03 María ADIG, SIMM

AlumnosAsignaturas

C_alumno N_asignaturas

01 ADIG

02 PLE

02 ADIG

03 ADIG

03 SIMM

Alumnos

C_alumno N_alumno

01 Manuel

02 Juan

03 María

Primera Forma Normal (1FN)

Segunda Forma Normal (2FN)

Tercera Forma Normal (3FN)

Forma Normal de Boyce – Cood (BCNF)

Cuarta Forma Normal (4FN)

Quinta Forma Normal (5FN)

La primera túpla si cumple la primera forma

normal, cada campo de la túpla contiene un

único dato, pero no ocurre así con las túplas

2 y 3 ya que en el campo asignatura contiene

más de un valor.

La solución en este caso es crear dos tablas.

Ahora todos los registros de ambas tablas contienen valores únicos en sus campos, por lo tanto

ambas tablas cumplen la Primera Forma Normal.

2FN – Segunda Forma Normal:

Se denomina clave o Llave Primaria al subconjunto mínimo y no vacío de atributos que permiten

en forma unívoca una túpla dentro de la relación.

Si existen varios conjuntos que cumplan esta condición se denominan claves o Llaves

Candidatas.

Los atributos que conforman parte de la clave primaria o candidata, se denominan atributos

primos, los atributos que no forman parte de ninguna de estas claves se denominan atributos

no primos.

Se define Dependencia Funcional A B, si para cualquier valor de A le corresponde un único

valor de B.

Por ejemplo; si A es el DNI, y B nombre, está claro que cualquier DNI le corresponde un único

nombre del titular.

Se define como Dependencia Funcional Completa; si B depende de A en su totalidad.

Se dice que una tamba se encuentra en Segunda Forma Normal (2FN) si y solo si:

Está en 1FN.

Todos sus atributos No primos dependen funcionalmente de forma completa de la

clave primaria (Existe dependencia funcional).

2FN – Segunda Forma Normal: Ejemplo

Codigo_empleado Codigo_Dpto Nombre Departamento Años

1 6 Juan Contabilidad 6

2 3 Pedro Sistemas 3

3 2 Sonia Ventas 1

4 3 Verónica Sistemas 10

2 6 Pedro Contabilidad 5

Sea la clave primaria de esta tabla formada por los campos Codigo_empleado y Codigo_Dpto,

podemos decir que la tabla se encuentra en 1FN, por tanto vamos a estudiar si está en segunda

forma normal.

Las dependencias funcionales de las relaciones son las siguientes:

Codigo_empleado Nombre

Codigo_Dpto Departamento

Codigo_empleado, Codigo_empleadoNombre

Realizamos su gráfico de dependencia:

Por tanto, al no existir dependencias funcionales totales respecto a la clave de todos los campos

de la relación no está en Segunda Forma Normal, por ello debemos proceder a normalizarla, se

aplica la descomposición de dependencia sólo a aquellas que no se encuentran en Segunda

Forma Normal:

Codigo_Empleado

Codigo_Dpto

Nombre

Departamento

Años

Codigo_Empleado Nombre

Codigo_Dpto Departame

nto

Codigo_Empleado

Codigo_Dpto

Años

Expresando el gráfico en tablas quedaría:

TABLA R1

Codigo_empleado Nombre

1 Juan

2 Pedro

3 Sonia

4 Verónica

Notemos que la Tabla R3 hereda las claves primarias de R1 y R2 y se agrega un atributo llamado

años, esto es igual a la relación muchos a muchos.

3FN – Tercera Forma Normal:

Se define Dependencia Transitiva, en la que existen las siguientes descendencias funcionales:

X Y

Y Z

Se dice que Z tiene una dependencia transitiva respecto a X a través de Y.

Se dice que una tabla se encuentra en 3FN si y solo si:

Está en 2FN.

TABLA R2

Codigo_Dpto Departamento

6 Juan

3 Pedro

6 Sonia

TABLA R3

Codigo_empleado Codigo_Dpto Años

1 6 6

2 3 3

3 2 1

4 3 10

2 6 5

X Y Z Esto no se debe dar para que exista

una 3FN

Ningún atributo no primos dependen no transitivamente de la clave primaria (no existe

dependencia transitiva). Es decir ningún atributo puede depender de otro que no sea la

llave primaria.

3FN – Tercera Forma Normal: Ejemplo

Cogido_alumno Nombre Curso Aula

1 Marcos Informática Aula A

2 Lucas Inglés Aula B

3 Marta Contabilidad Aula C

Dependencias:

Codigo_alumno Nombre Curso;

Curso Aula;

La tabla está en 1FN y comprobamos que también está en 2FN, pero existe Dependencia

Transitiva por lo cual no está en 3FN.

Aplicamos la descomposición sin pérdidas para la dependencia que impide la 3FN obtenemos:

TABLA R2

Codigo Nombre Curso

1 Marcos Informática

2 Lucas Inglés

3 Marta Contabilidad

TABLA R1

Curso Aula

Informática Aula A

Inglés Aula B

Contabilidad Aula C

Codigo_alumno Nombre

Curso Aula

Codigo_alumno Nombre

Curso

Curso Aula

Bibliografía

http://www.youtube.com/watch?v=22iP_0dVW10

http://www.youtube.com/watch?v=Ouuia3eQKRI